業務システム外注のアクセス権限と操作ログの要件

最初に作るのは、データと役割の一覧です

権限と操作ログの要件は、扱うデータの種類と社内の役割を一覧にすることから始めます。先に機能の要望を並べると、権限の話が「管理者と一般の2種類で」という粗い指定に落ち着き、納品後に「この人には取引金額を見せたくない」という要望が後から出てきます。

扱うデータを種類ごとに書き出す

最初に、システムに入れるデータを種類ごとに書き出します。顧客の氏名と連絡先、取引の金額、見積の内容、社内のやり取りの記録、添付したファイルのように、見せてよい範囲が変わる単位で分けます。

1. 画面に出る項目を一覧にします (所要時間の目安: 既存の帳票や表計算ファイルが揃っていれば2時間程度)
2. 項目ごとに、社外に出てはいけないか、社内でも限られた人だけかを印を付けます (つまずきやすい点: 氏名よりも、取引金額と社内のやり取りの記録の方が社内で揉めやすい部分です)
3. 個人情報にあたる項目に別の印を付けます

役割を職名ではなく業務で分ける

次に役割です。役職や部署の名前で分けると、兼任や異動のたびに合わなくなります。実務では、営業の担当者、営業の管理者、事務、経理、外部の協力者、システムの管理者のように、何をする人かで分けた方が長く使えます。

役割の数は、最初は4つから6つに収めることをおすすめします。種類を増やすほど、設定の確認と納品時の検証の手間が増えます。詳しくは後述します。

一覧をそのまま要件定義の付表にする

データの一覧と役割の一覧は、要件定義書の付表としてそのまま使えます。発注側が作って渡す形にすると、見積の前提が明確になり、後からの変更が「追加の要望」なのか「最初の指定の確認漏れ」なのかを切り分けられます。

実装者としての注意点を1つ挙げます。権限は、画面を見せるかどうかだけでは足りません。一覧の画面を隠しても、検索の機能やCSVの書き出し、印刷用の画面、通知のメールの本文から同じ項目が出てしまうことがあります。一覧を作るときは、項目ごとに「どの出口から出るか」まで書き添えてください。発注の段階でこれを渡しておくと、見積にも検証の工数が入ります。

公的なガイドラインが求めている項目

アクセス制御とアクセス者の識別と認証は、個人情報保護委員会のガイドラインが技術的安全管理措置として挙げている項目です。つまり、権限とログは「あると安心なもの」ではなく、個人データを扱うなら求められている措置として要件に書けます。

技術的安全管理措置の4項目

個人情報保護委員会のガイドライン (通則編) の別添「講ずべき安全管理措置の内容」では、技術的安全管理措置として次の4項目が挙げられています。

項目	発注時の要件として書くもの
アクセス制御	役割ごとに見られるデータと行える操作の範囲
アクセス者の識別と認証	利用者ごとのアカウントと、本人を確かめる方法
外部からの不正アクセス等の防止	通信の暗号化や管理画面の公開範囲
情報システムの使用に伴う漏えい等の防止	書き出しや印刷、添付ファイルの扱い

誰がどのデータを見られるかを絞ることと、操作した人を特定できるようにすることは、このうち前の2つに対応します。前のセクションで作ったデータと役割の一覧は、1つ目と2つ目の項目にそのまま対応します。

システムで実現する部分と運用で守る部分の境目

同じ別添の第10章は、安全管理措置を組織的安全管理措置、人的安全管理措置、物理的安全管理措置、技術的安全管理措置の4区分で整理しており、これに加えて基本方針の策定、個人データの取扱いに係る規律の整備、外的環境の把握が示されています。

システムで実現するのは技術的安全管理措置の部分であり、運用の規律は発注側が別に定める前提になっています。見積に入らない作業がここに残ります。アカウントを誰が発行するか、退職した人のアカウントをいつ止めるか、書き出したCSVをどこに置くかは、システムを作っても自社で決める必要があります。発注の範囲を切り分けるときは、この区分を目安にしてください。

発注側の義務としての委託先の監督

外注する場合は、委託先の監督が発注側の義務になります。ガイドライン (通則編) 3-4-4では、委託先の選定に当たって、委託先の安全管理措置が少なくとも法第23条およびガイドラインで委託元に求められるものと同等であることを、委託業務に沿ってあらかじめ確認する必要があるとされています。

委託契約には、双方が同意した安全管理措置の内容とともに、委託先における個人データの取扱状況を委託元が合理的に把握することを盛り込むことが望ましいとされています。あわせて、取扱状況の把握には定期的な監査等により実施の程度を調査して評価することが望ましいとされています。

実務では、開発の委託先が本番のデータを見られる状態になることがあります。不具合の調査のために本番の環境へ入る場合があるためです。この点は、権限の要件を決めるときに自社の社員と同じ枠で考えられず、委託先の担当者用の役割と、入るときの申請の手順を別に決めることになります。契約と監督の具体の進め方は本記事の範囲を超えるため、ここでは要件に含めるべき対象として押さえてください。

アクセス権限を要件として書く

権限は、役割と操作の組み合わせを表にして、できることとできないことを両方書きます。「営業は顧客情報を閲覧できる」だけでは、どの範囲の顧客を、どの項目まで見られるのかが決まりません。

役割と操作の対応表の作り方

表の縦に役割、横に操作を並べます。操作は、閲覧、登録、修正、削除、書き出し、印刷の6つで足りることが多いです。

役割	閲覧	登録	修正	削除	書き出し	印刷
営業の担当者	自分の担当分	可	自分の担当分	不可	不可	可
営業の管理者	全件	可	全件	可	可	可
事務	全件 (取引金額を除く)	可	全件 (取引金額を除く)	不可	不可	可
経理	全件	不可	不可	不可	可	可
システムの管理者	全件	可	全件	可	可	可

このままの形で要件定義書の付表にできます。空欄を作らず、すべてのマスを埋めるのがこの表の役目です。つまずきやすい点は、削除の列です。削除を不可にする場合、間違って登録したデータをどう扱うかを別に決める必要があり、無効にする印を付ける機能が必要になります。

自分の担当分しか見えない形にするかを決める

表の「自分の担当分」という指定は、見積に効きます。全件を見せる形に比べて、画面ごとに絞り込みの条件が増え、検索や集計の画面にも同じ条件を入れることになります。

判断の目安は、顧客の情報が担当者の間で取り合いになるかどうか、そして人の入れ替わりが多いかどうかです。全件を見せる形で始めて、必要になった時点で絞る形に変える場合は、担当者の情報をデータに持たせておく必要があります。これは後から足しにくい部分です。

権限を変更できる人を決める

役割の割り当てを変えられる人を決め、要件に書きます。システムの管理者の役割を社内の誰が持つのか、委託先が持つのかも含めて決めます。

1. 役割を割り当てる権限を持つ人を決めます (つまずきやすい点: 全員がシステムの管理者になっている状態は、権限を分けた意味が無くなります)
2. 割り当ての変更が記録として残る形を要件に入れます (所要時間の目安: 要件の文を書くだけなら30分程度)
3. 退職や異動のときに誰が止めるかを運用の手順として決めます

書き方の例

要件定義書に書く文の形も示します。曖昧さが残らない書き方は次のとおりです。

• 利用者は個人ごとのアカウントで利用し、共用のアカウントは作らないこと
• 役割は別表のとおりとし、役割ごとに閲覧できるデータの範囲と行える操作を別表に従って制御すること
• 取引金額の項目は、別表で閲覧を可としている役割以外には、一覧、詳細、検索の結果、書き出したファイル、通知のメールのいずれにも表示しないこと
• 役割の割り当ての変更は、システムの管理者の役割を持つ利用者のみが行えること

最後の例のように、出口をすべて列挙する書き方にすると、画面だけ隠して書き出しから漏れる作りを防げます。

操作ログに何を記録し、どれだけ残すか

誰が、いつ、どのデータに、何をしたかの4つを記録し、保存する期間は漏えい等の報告の期限から逆算して決めます。ログは不正を疑うためのものではなく、何が起きたのかを後から説明するための記録です。

記録する4つの項目

要件に書く項目は次の4つです。

記録する項目	書き方の例
誰が	利用者のアカウントの識別子 (氏名ではなく変わらない値)
いつ	操作した日時 (秒まで)
どのデータに	対象の種類と件の識別子 (顧客の件なら顧客の番号)
何をしたか	閲覧、登録、修正、削除、書き出し、ログインの成功と失敗

修正については、変わる前の値と変わった後の値も残すかを決めます。残す形にすると、誤って上書きした場合に元の値を確認できます。つまずきやすい点は、この指定が無いと「修正した」という事実だけが残り、何がどう変わったのかが分からない作りになることです。

閲覧も記録の対象にするかを決める

閲覧の記録は、要件に入れるかどうかで判断が分かれます。件数が多くなり、保存する容量と画面の応答に影響するためです。

実務的な落としどころは、一覧の表示は記録せず、個別の詳細の表示、検索の結果の書き出し、印刷の3つを記録する形です。漏えいの経路になりやすいのは、1件ずつ開いて見る操作よりも、まとまった件数を取り出す操作です。書き出しと印刷は、件数と条件もあわせて記録するよう要件に書いてください。

保存期間を報告の期限から決める

保存期間の目安は、報告の期限から逆算します。個人情報保護委員会の漏えい等の対応のページでは、速報は発覚日から3日から5日以内、確報は発覚日から30日以内とされており、不正な目的で行われたおそれがある場合は発覚日から60日以内とされています。

報告対象となる事態には、要配慮個人情報を含む漏えい等、財産的被害が生じるおそれがある漏えい等、不正の目的で行われたおそれがある行為による漏えい等、本人の数が1,000人を超える漏えい等が挙げられており、いずれも「そのおそれ」を含みます。何件が誰に見られたのかを後から説明できる記録がなければ、この期間内の報告は組み立てられません。

ここで効いてくるのは、漏えいは発生した直後に気づくとは限らない点です。気づいた日から60日の猶予があっても、調べる対象の記録が残っていなければ件数を確定できず、「おそれ」のまま報告することになります。発覚までの時間を見込んで保存期間を決める形になり、1年を下回る設定は後から足せません。要件には、保存期間と、期間を過ぎた記録をどう扱うか (削除するか、別の場所へ移すか) の両方を書いてください。

ログを誰が見るかを決める

ログ自体も個人データを含みます。誰がログを見られるかを、前のセクションの役割の表に行として足してください。実装者としての注意点は、ログの画面をシステムの管理者だけに見せる作りにすると、その役割を委託先が持っている場合に、自社では確認できない状態になることです。社内の責任者が自分で見られる形を要件に入れておくと、報告が必要になった場面で外部に依頼せずに済みます。

見積もりが膨らむ要件と、削れる要件

権限の種類を増やすほど確認の工数が増えるため、役割は少なく始め、ログは後から足せない部分を優先します。権限とログの要件は、書けば書くほど安全になりますが、費用は作る手間ではなく確かめる手間で増えます。

費用が増えやすい要件

見積に効きやすい要件を挙げます。

要件	費用が増える理由
役割の種類が多い	役割の数だけ画面の確認が必要になります
項目ごとに見せる見せないを分ける	一覧、詳細、検索、書き出し、印刷のそれぞれで分岐が増えます
自分の担当分だけに絞る	画面ごとに絞り込みの条件が入り、集計にも同じ条件が必要になります
修正の前後の値を残す	データの持ち方が変わり、画面も必要になります
閲覧をすべて記録する	件数が増え、保存の容量と応答の確認が必要になります

役割を6つから4つに減らし、項目ごとの分岐を取引金額のように本当に必要な項目に絞るだけで、確認の対象はかなり小さくなります。

後から足せる要件と、足せない要件

優先順位を決めるときの分かれ目は、後から足せるかどうかです。

• 後から足しやすい: 役割の追加、ログを見る画面、ログの絞り込み、権限の割り当ての変更の記録
• 後から足しにくい: 担当者をデータに持たせること、修正の前後の値を残すこと、過去にさかのぼった記録

足しにくいものは、仕組みを作ったあとに過去のデータが埋まらない点が理由です。担当者の情報を持っていなければ、後から「自分の担当分だけ」に絞る形へ変えても、過去のデータには担当者が入りません。ログも同じで、記録を始める前の操作は復元できません。

段階に分けて発注する考え方

費用を抑えつつ、足せない部分を落とさない進め方は次のとおりです。

1. データと役割の一覧を作り、足せない部分 (担当者の保持、修正の前後の値、記録の開始) を第1段階に入れます (つまずきやすい点: ここを「後で」と言われたら、後から足せない理由を伝えて交渉してください)
2. 役割は4つ程度で始め、項目ごとの制御は取引金額など必要な項目に絞ります (所要時間の目安: 要件の見直しに半日程度)
3. 運用を3か月ほど続けて、実際に不便だった点を集めます
4. 役割の追加やログの画面の改善を第2段階として発注します

この形にすると、第1段階の見積が現実的な範囲に収まり、第2段階は実際に困った点だけを足せます。なお、可用性やバックアップ、復旧の水準は別の軸の要件であり、本記事では扱いません。

納品時に確かめる項目と、運用の引き継ぎ

納品時は、役割ごとに実際にログインして見える範囲を確かめ、ログが記録されていることを画面で確認します。仕様書の文面を読み合わせるだけでは、画面は隠れているのに書き出しから出る、という作りを見つけられません。

役割ごとの確認の手順

確認は、役割の数だけログインをやり直す形になります。

1. 役割ごとに確認用のアカウントを作ってもらいます (つまずきやすい点: 自分のアカウントの役割を切り替える形だと、切り替え漏れで確認が曖昧になります)
2. 役割ごとに、見えてはいけない項目が一覧、詳細、検索の結果、書き出したファイル、印刷の画面に出ていないかを確かめます (所要時間の目安: 役割4つで半日程度)
3. 行えてはいけない操作のボタンが押せない状態かを確かめます
4. 結果を役割と操作の表に記入し、検収の記録として残します

ログの確認の手順

ログは、記録されているかと、必要な項目が入っているかの2点を見ます。確認のために、自分で操作してからその記録を探す形が確実です。

• 1件を閲覧し、その操作が記録に出るかを確かめます
• データを修正し、変わる前の値と変わった後の値が残るかを確かめます (要件に入れた場合)
• CSVを書き出し、件数と条件が記録に残るかを確かめます
• ログインに失敗し、その記録が残るかを確かめます

運用で決めておく規律

システムの納品で終わらない部分があります。アカウントを誰が発行し、退職や異動のときに誰が止めるか、書き出したファイルをどこに置き、いつ消すかは、自社で決めて文書にしておく必要があります。前に触れたとおり、運用の規律は発注側が定める前提です。

最低限、次の3つを決めてください。

• アカウントの発行と停止を依頼する窓口と、停止までの期限
• 役割の割り当てを変更できる人と、変更の記録の残し方
• 書き出したファイルの置き場所と、保存の期間

非機能要件としての記録の扱い

権限と記録は、機能の一覧とは別に、非機能要件として書面に残す形が整理しやすくなります。IPA (独立行政法人情報処理推進機構) の非機能要求グレードは、非機能要求を可用性、性能・拡張性、運用・保守性、移行性、セキュリティ、システム環境・エコロジーの6つの大項目に分けて整理する枠組みで、権限と記録の要求はセキュリティの大項目で扱う対象になります。

要求の分解の仕方も公式に示されています。IPAの資料では、大項目が最も広い分類、中項目が検討すべき単位、小項目がユーザと開発ベンダの間で合意される項目、メトリクスが小項目を定量的に表す指標という位置づけが示されています。発注側が合意の対象とすべき単位は小項目であり、見積もりや契約で数値として確認する対象がメトリクスにあたります。

この整理に当てはめると、「操作ログを記録する」は小項目、「保存期間は何年」「記録する項目は4つ」は数値として確認するメトリクスにあたります。曖昧なまま合意すると、後から水準を争う材料がありません。納品の確認の項目も、この単位で書いておくと検収の基準になります。

よくあるご質問

この記事に関して多い質問と回答をまとめます。

アクセス権限は何種類に分ければよいですか。

4つから6つが現実的な範囲です。役職や部署ではなく、営業の担当者、営業の管理者、事務、経理、システムの管理者のように、何をする人かで分けます。種類を増やすほど納品時の確認と設定の手間が増えるため、まず4つ程度で始め、運用して不便だった点を第2段階で足す形をおすすめします。

操作ログには閲覧も記録する必要がありますか。

すべての閲覧を記録すると件数が多くなるため、実務的な落としどころは、一覧の表示は記録せず、個別の詳細の表示、検索の結果の書き出し、印刷の3つを記録する形です。まとまった件数を取り出す操作は、件数と条件もあわせて記録するよう要件に書いてください。

操作ログは何年残せばよいですか。

法令で年数が一律に定められているわけではないため、漏えい等が起きたときに何が起きたかを説明できる期間から逆算します。個人情報保護委員会の漏えい等の対応のページでは、速報は発覚日から3日から5日以内、確報は発覚日から30日以内、不正な目的で行われたおそれがある場合は発覚日から60日以内とされています。漏えいは発生の直後に気づくとは限らないため、発覚までの時間を見込む形になり、1年を下回る設定は後から足せません。

権限と操作ログの要件を入れると、見積もりはどのくらい増えますか。

増え方は要件の作りによって変わるため、金額の目安を一律には示せません。費用が増えるのは作る手間よりも確かめる手間で、役割の種類、項目ごとに見せる見せないを分ける範囲、自分の担当分だけに絞るかどうかが大きく効きます。見積を比べるときは、役割の数と制御する項目の数を揃えた条件で出してもらってください。

クラウドのサービスを使う場合も、権限とログの要件は必要ですか。

必要です。既製のサービスを使う場合は、要件として作ってもらう代わりに、そのサービスで実現できる範囲を確かめる作業になります。役割と操作の表を作り、サービスの設定でその表を再現できるかを確認してください。あわせて、ログがどの項目まで残り、どのくらいの期間参照できるかを提供元の資料で確かめます。再現できない部分は、運用の規律で補うか、別のサービスを検討する判断になります。

関連リンク

• 業務システムの外注で決める要件を無料で診断する
• 業務システムの要件定義と発注の手順をまとめたガイドブック
• 業務システムの外注と要件定義に関する記事の一覧
• 業務システム開発の料金と対応範囲