need-to-knowの原則

読み：にーどとぅのうのげんそく　／　英語表記：Need-to-Know Principle

• セキュリティ

情報を知る必要がある人にだけ、その仕事に必要な情報を開示するという情報セキュリティの原則である。所属や役職だけで判断せず、業務上の必要性に基づいて情報の開示範囲を決める。

イマシルちゃんの解説

同じ会社の社員でも、給与の明細や開発中の設計図を全員が見られてよいわけではないよ。
担当していない仕事の資料まで見えてしまうと、うっかり広めたり盗み出されたりする範囲も広がるんだ。
そこで、その人の仕事に必要な情報だけを渡すという考え方をneed-to-knowの原則というよ。
役職が高いから何でも見せるのではなく、どの資料を何のために使うのかを確かめるの。
例えば給与の計算をする担当者には明細を見せても、部署の予算を考える人には合計額だけで足りる場合があるね。
必要な人には仕事に足りる情報を届けながら、関係のない情報は見せないようにするんだ。

より深い解説

何を基準に情報を渡すのか

need-to-knowの原則は、利用者が特定の情報を知ることを、その人の担当業務に結び付けて判断する原則である。企業の内部にいることや、システムへログインできることだけでは、そのシステムにあるすべての情報を見てよい理由にはならない。情報を必要な相手にだけ開示することで、情報セキュリティの機密性を保つ。

NISTの用語集には、権限を持つ情報の保有者が、相手の職務に特定の情報が必要かを判断するという定義が収録されている。この定義は公的情報の管理を背景とする。企業のシステムで考える場合も、本人の「見たい」という希望と、仕事のために知る必要があることを区別する点が要になる（NIST：need-to-know）。

例えば、機器の保守担当者に障害調査を依頼した場合、エラーの発生時刻や機器の設定は必要でも、同じサーバに保存された顧客全員の取引履歴まで必要とは限らない。担当作業を明確にしてから、渡す資料や見られるデータを決める。保守担当者という肩書だけで一括して開示しない。

本人確認や操作権限との違い

利用者が誰であるかを確認する処理を認証という。一方、その利用者に対象の操作を許可するかを決める処理は認可である。本人であることを確認できても、資料を見ることまで許可されるとは限らない。need-to-knowの原則は、閲覧を許可する範囲を設計するときの判断基準になる（OWASP：Authorization Cheat Sheet）。

読取り専用にすれば安全だと考えるのも誤りである。変更や削除を禁止していても、担当外の顧客名簿を読めるなら、その内容は知られてしまう。更新を禁止することと、そもそも知る必要がない情報を見せないことは別々に設計する。

権限に関する原則は重なる部分があるため、何に注目しているかで整理すると分かりやすい。

二つ目の原則は、情報の読取りも含めた操作全般を対象にする。そのため、need-to-knowの原則と完全に別の領域を扱うわけではない。三つ目は、一人で不正な処理を完結できる組合せを避ける考え方である。閲覧範囲を絞るだけでは、登録者が自分の申請を承認できる問題は解決しない（NIST：least privilege、NIST：separation of duty）。

必要な情報を業務から切り出す

情報を扱う責任者を、組織によってはデータオーナーと呼ぶ。システムの設定担当者とは別に、どの業務で誰に情報を開示するかを判断する役割を明確にする。申請者が必要だと述べるだけで許可せず、担当作業と規則に照らして確認する。

確認するのは、資料全体を見る必要があるかだけではない。対象となる顧客や案件、必要な項目、過去のどの期間の記録かまで絞る。業務を終える時期が分かっているなら、許可する有効期限も決める。次は業務と情報を対応させた独自の設計例である。

同じデータから作られた資料でも、明細と集計では知ることのできる内容が違う。ただし、少人数の集計や別資料との組合せから個人の値を推測できる場合がある。列を削ったという形式だけで判断せず、受け取る人が何を知ることになるかまで考える。

規則をシステムへ反映する

原則を決めただけでは閲覧を止められない。ファイルの権限、アプリケーションの閲覧条件、データベースの検索条件などのアクセス制御に落とし込む必要がある。許可の規則に当てはまらない要求を拒否するデフォルト拒否を基本にすると、新しい資料や利用者が意図せず公開範囲へ入るのを避けやすい。

役割に権限を割り当てる方式がRBAC（Role-Based Access Control、ロールベースアクセス制御）である。給与計算の担当者など、共通する仕事をまとめて管理できる。ただし、「人事部員」という大きな役割に全社員の情報を割り当てるだけでは、担当していない業務の情報も見えてしまう。役割の粒度と、対象にする情報の範囲を業務に合わせる（NIST：role-based access control）。

利用者・情報・操作・環境の属性を規則と照合する方式はABAC（Attribute-Based Access Control、属性ベースアクセス制御）である。例えば「利用者の担当案件と資料の案件が一致し、その案件への参加期間内である」といった条件を組み合わせる。所属や案件の情報が古ければ判断も誤るので、属性を誰が更新するかも運用に含める（NIST SP 800-162）。

これらは原則を実施するための方式であり、導入しただけで適切な開示範囲が自動的に決まるわけではない。方式そのものの説明はアクセス制御の記事へつながる。ここでは、仕事に必要な対象と条件が規則に表れているかを確認する。

通信を許可した後も対象を確認する

ネットワークへの接続を許可することと、その先の業務データを開示することは別の判断である。例えば、委託先から保守用サーバへの接続をファイアウォールで許可しても、その先で全顧客の記録を見られる設定が適切になるわけではない。接続元やポートによる制限に加え、アプリケーション側で対象の資料や記録を限定する。

Web画面で担当外の案件を一覧から隠しても、URLの案件番号を変えて資料を取得できるなら制御は不十分である。データを返すサーバ側で、要求のたびに利用者と対象案件の関係を確認する。画面だけでなく、APIやファイルのダウンロードでも同じ規則を適用する必要がある（OWASP：要求ごとの権限確認）。

確認試験では、許可された人が資料を読めることと、担当外の人が読めないことの両方を確かめる。同じ役割の別案件担当者、参加期間を過ぎた人、管理画面だけを使う保守担当者などを用意すると、単に「ログイン済みか」だけで許可する不備を見つけやすい。

業務の変更と例外に対応する

必要な情報は、人事異動や案件の終了によって変わる。新しい権限を追加するだけで古い権限を残すと、かつての業務の資料まで見られ続ける。定期的な権限の棚卸しと、異動・退職・契約終了をきっかけにした見直しを組み合わせる。

NIST SP 800-53のAC-2は、異動や知る必要の変化をアカウント管理へ反映することを扱う。AC-6(7)も、付与した権限が引き続き必要かを確認し、必要に応じて変更・削除する管理策である。点検の間隔を決めるだけでなく、変更の連絡が担当者へ届く経路を設計する（NIST SP 800-53 Rev. 5：AC-2、AC-6）。

障害復旧などで通常より広い情報が必要になる場合は、緊急時の手続きを事前に定める。対象と理由を記録し、限定した期間だけ追加で許可する。誰が何を閲覧・取得したかを残す監査ログを使い、作業後に必要な範囲だったか確認して権限を戻す。緊急対応を理由に、広い権限を恒久的に残さない。

規則を厳しくしすぎて必要な担当者にも情報が届かないと、調査や意思決定が遅れる。必要な共有を止めることが目的ではない。通常の申請と緊急時の手続きが実際の業務に間に合うようにする。

持ち出された情報と設計上の判断

システム上の権限を外しても、すでにダウンロードされたファイルや送信済みのメールまで自動的に回収できるとは限らない。資料の配布方法、共有リンクの対象と期間、不要になった複製の削除まで含めて扱う。通信の暗号化も、受け取る相手がその情報を必要としているかという判断の代わりにはならない。

need-to-knowの原則は、閲覧できる情報を限定して漏えいの機会や影響範囲を減らす考え方である。許可された人による不正な持出しや、システムの脆弱性による迂回を単独で完全に防ぐものではない。取得量の監視や操作記録などを組み合わせる。

設計や試験の記述では、「必要な人だけにする」で終わらせず、業務と制御対象を対応させる。例えば「保守担当者には全顧客のデータを読取り専用で渡す」という案なら、更新できない点だけを評価してはならない。調査対象の顧客・項目・時間帯に限定し、作業に不要な値を除く案へ具体化する。誰が何のためにどの情報をいつまで使うかを説明できれば、原則を設定や運用の判断へつなげられる。

この用語が出てくる記事

• アクセス制御
• 最小特権の原則