管理システムのビジネス要件とセキュリティ要件をどう整理するか
はじめに
システム開発では、ビジネス要件とセキュリティ要件がぶつかることがあります。管理システムでは、この衝突が一般向けシステムより複雑になります。
一般向けシステムでは、本人が自分の情報を閲覧・変更する場面が中心です。一方、管理システムでは、管理者、オペレーター、コールセンター担当者、委託先担当者などが、業務として他人の顧客情報を閲覧・検索・変更します。
顧客情報を扱う管理システムでは、たとえば次のような要望が出ます。
- 顧客を探しやすくするため、顧客一覧を表示したい。
- 顧客情報の修正が頻繁にあるため、編集のたびに再認証は求めたくない。
- コールセンター業務を効率化するため、氏名・電話番号・住所・メールアドレスで柔軟に検索したい。
- 業務上必要なので、CSV出力や一括更新もできるようにしたい。
いずれも現場から見れば筋の通った要望です。ただ、セキュリティ側から見ると、同じ機能は次のリスクにもつながります。
| 業務要望 | 主なリスク |
|---|---|
| 顧客一覧表示 | 大量閲覧、内部不正、画面のぞき見、CSV化の温床 |
| 柔軟な検索 | 担当外顧客の探索、名寄せ、過剰ヒット |
| 頻繁な編集 | 誤更新、不正変更、なりすまし操作 |
| 再認証なし | 離席時操作、セッション乗っ取り、重要操作の不正実行 |
| CSV出力・一括処理 | 大量漏えい、大量誤更新、システム外での統制喪失 |
管理システムでは「閲覧すること」自体が業務です。単純に「重要情報だから表示禁止」「重要操作だから毎回再認証」とすると、業務が成立しないことがあります。
反対に、「業務上必要だから一覧表示も検索も編集も出力も自由でよい」とすると、管理システムそのものが内部不正や大量漏えいの主要な入口になります。
必要なのは、ビジネス要件とセキュリティ要件を勝ち負けで扱うことではありません。業務行為の危険度に応じて、どの摩擦なら許容できるかを設計することです。
全体像
画面単位で「許可/禁止」を決めると、議論が詰まりやすくなります。検索、一覧表示、詳細表示、編集、出力、一括処理、例外操作といった業務行為に分解すると、業務影響と統制の強さを調整しやすくなります。
一般向けシステムと管理システムの違い
管理システムでは、業務効率を上げるほど、情報探索ツールとしても強くなります。顧客を探しやすい画面は、悪用されれば顧客情報を探しやすい画面でもあります。柔軟な検索条件は、少ない手がかりから個人を特定する手段にもなります。CSV出力は便利ですが、システム外に出た瞬間に、行単位の権限制御や詳細な閲覧ログの多くが弱くなります。
典型的な衝突点は次のとおりです。
| 観点 | ビジネス側の要求 | セキュリティ側の懸念 |
|---|---|---|
| 一覧表示 | 顧客を探しやすくしたい | 大量閲覧、内部不正、画面のぞき見、CSV化 |
| 検索 | 名前、電話番号、住所、メールで柔軟に探したい | 曖昧検索による過剰ヒット、担当外閲覧、名寄せ |
| 編集 | 顧客情報を素早く修正したい | 誤更新、不正変更、権限外変更 |
| 再認証 | 頻繁な再認証は業務効率を落とす | セッション乗っ取り、離席時操作、重要操作の不正実行 |
| 権限分離 | 担当者が一画面で完結したい | 閲覧権限と変更権限の過剰付与 |
| 監査ログ | 操作のたびに理由入力は面倒 | 事後追跡できない、内部不正を説明できない |
| 承認 | 即時処理したい | 高リスク変更を単独実行できてしまう |
| マス処理 | 一括更新、一括出力したい | 大量漏えい、大量誤更新 |
セキュリティレビューで最初に確認したいのは、次の3点です。
- 誰が、何の業務目的で、どの範囲の情報に、どの操作を行うのか。
- その操作が誤用・悪用された場合、どの程度の被害になるのか。
- 被害を下げるために、どの程度の摩擦なら業務上許容できるのか。
この考え方は、NIST CSF 2.0が示すリスク管理の考え方とも整合します。CSF 2.0は、組織がサイバーセキュリティの取り組みを理解・評価・優先順位付け・伝達するための枠組みであり、特定の実装方法を一律に処方するものではありません。1
顧客一覧表示は一律禁止ではなく初期全件表示を避ける
顧客情報を変更する業務フローがあるとして、顧客一覧から対象顧客を選択して編集する機能を作ってよいのでしょうか。
顧客一覧表示そのものを一律禁止にする必要はありません。ただし、初期表示で大量の顧客情報を出す設計は避けます。
判断する際は、次のように分解します。
| 論点 | 確認すべきこと |
|---|---|
| 一覧が本当に必要か | 案件番号・顧客番号から開く運用で足りないか |
| 何件表示されるか | 初期全件表示か、検索後のみ表示か |
| 表示項目は何か | 氏名、住所、電話、メール、生年月日、契約内容まで必要か |
| 曖昧検索を許すか | 部分一致、前方一致、電話下4桁検索などを許すか |
| マス操作があるか | CSV出力、コピー、印刷、一括編集ができるか |
| 業務ロールは何か | 全社共通、支店単位、担当顧客単位、委託先単位か |
| 証跡は残るか | 一覧表示、詳細表示、編集、検索条件までログ化するか |
| 異常検知できるか | 短時間大量閲覧、担当外閲覧、深夜閲覧、連続検索を検知するか |
実務上は、次の設計に寄せると衝突を減らせます。
- 顧客一覧表示そのものを一律禁止にはしない。
- 初期表示で大量の顧客を出す設計は避ける。
- 検索条件入力後に、業務上必要な最小項目だけを一覧表示する。
- 詳細情報、機微情報、変更操作は、追加の権限、理由入力、ログ、再認証、承認で制御する。
一覧画面では、顧客番号、氏名の一部、ステータス概要、担当拠点、最終更新日などに抑えます。住所、電話番号、メールアドレス、生年月日、本人確認情報、口座情報、契約詳細などは、詳細画面で必要な権限とログを前提に表示するほうが扱いやすくなります。
OWASP ASVS 5.0.0も、アプリケーションが必要最小限の機微データだけを返すこと、完全なデータが必要な場合でもUIではマスクすることを検証項目として扱っています。2
検索機能は利便性と探索リスクを同時に持つ
検索機能は、管理システムの利便性を大きく左右します。一方で、柔軟すぎる検索は内部者にとって強力な探索機能になります。
たとえば、次の検索が自由にできる場合を考えます。
- 氏名の部分一致
- 電話番号の下4桁
- 住所の一部
- メールアドレスのドメイン
- 生年月日
- かな氏名
- 契約状態
業務上は便利です。しかし、悪用されれば「知人の情報を探す」「著名人の情報を探す」「特定地域の顧客を抽出する」「少ない手がかりから個人を特定する」といった行為につながります。
検索機能には、次のような制御を組み合わせます。
| 統制 | 内容 |
|---|---|
| 初期表示なし | 検索前に全件を出さない |
| 検索条件必須 | 何らかの絞り込み条件を必須にする |
| 条件の組合せ | 曖昧検索では複数条件を要求する |
| 最大件数制限 | 結果が多すぎる場合は表示しない、追加条件を求める |
| 一覧項目最小化 | 検索結果には最小限の識別情報だけ表示する |
| 曖昧検索のロール制限 | 部分一致や広域検索は特定ロールに限定する |
| 検索条件ログ | 誰が、いつ、何を条件に検索したか残す |
| 異常検知 | 短時間大量検索、担当外検索、深夜検索を検知する |
検索ログには「検索した」という事実だけでなく、検索条件も残します。監査ログの粒度は、NIST SP 800-53 Rev. 5のAudit and Accountability系統が扱う、イベント種別、発生時刻、発生場所、発生元、結果、関係する主体・客体を追える状態に近づけると、事後調査に使いやすくなります。3
ログ項目の例は次のとおりです。
| ログ項目 | 用途 |
|---|---|
| 操作者ID | 誰が実行したか |
| 操作日時 | いつ実行したか |
| 端末・IP・拠点 | どこから実行したか |
| 検索条件 | 何を探したか |
| 検索結果件数 | 結果が過剰でないか |
| 表示した顧客ID | 一覧で誰が見えたか |
| 詳細表示した顧客ID | 実際に誰を開いたか |
| 操作理由 | 例外操作や高リスク操作の説明材料 |
ログ自体にも個人情報が含まれ得ます。検索条件をすべて無制限に残せばよいわけではありません。監査に必要な粒度と、ログに含まれる個人情報の最小化を同時に設計します。
再認証は毎回ではなくリスクに応じて設計する
重要情報の編集前に再認証を求める設計はよくあります。ただし、管理システムでは、重要情報の編集が日常業務そのものである場合があります。コールセンター担当者が1日に数十件から数百件、住所・電話番号・メールアドレスを修正する業務で、毎回MFAを求めると現実的でないことがあります。
避けたいのは、次の二択です。
- 重要情報だから毎回再認証する。
- 業務が止まるから再認証は一切しない。
NIST SP 800-63B-4は、再認証とセッション管理について、全体タイムアウトと非活動タイムアウトを分け、AAL、利用環境、端末種別、管理端末かどうか、アプリケーションの性質などを考慮すると説明しています。AAL2では全体タイムアウトを24時間以内、非活動タイムアウトを1時間以内、AAL3では全体12時間以内、非活動15分以内とする要件を示しています。45
管理システムでは、次の軸で再認証を設計します。
- 操作の危険度
- 業務頻度
- セッション状態
- 端末の信頼度
- 利用場所
- 時間帯
- 操作者のロール
- 直近の認証状態
- 異常操作の有無
段階制にすると、業務影響とリスクを合わせやすくなります。
| 操作 | 再認証・追加統制の考え方 |
|---|---|
| 通常の詳細閲覧 | 再認証なし。ただし権限、担当範囲、ログ、異常検知を前提にする |
| 軽微な属性修正 | 再認証なし、または一定時間内の認証済み状態で許可 |
| 住所・電話・メール変更 | 毎操作再認証ではなく、短時間のステップアップ認証有効期間を設定する |
| 返金先口座・送付先変更 | 再認証、理由入力、変更前後ログ、顧客通知を要求する |
| 権限・契約状態変更 | 再認証、二者承認、事後レビューを要求する |
| 一括更新・CSV出力 | 申請承認、件数制限、出力識別子、ログ、DLP連携を重視する |
| 異常時 | 普段と違う端末、場所、時間帯、大量操作で再認証またはブロックする |
「頻繁に発生する通常業務について、毎操作の再認証は採用しない」という判断はあり得ます。ただし、それは再認証を完全に捨てるという意味ではありません。ログイン時MFA、短い非活動タイムアウト、一定時間ごとの再認証、高リスク操作のみステップアップ認証、大量操作や異常操作の検知、理由入力、承認、監査ログを組み合わせて設計します。
OWASP ASVS 5.0.0も、セッションの非活動タイムアウトと絶対有効期限を文書化し、リスク分析と文書化された判断に基づいて再認証を実施すること、機微な取引や操作では追加認証や二次確認を求めることを検証項目にしています。2
RBACを基本にし、ABACで業務範囲を補正する
管理システムのアクセス制御では、RBACとABACの使い分けが重要です。
RBACは、管理者、支店担当者、コールセンター担当者、承認者、委託先担当者、監査担当者といったロールごとに権限を定義します。分かりやすく、棚卸もしやすい一方で、細かな業務範囲を表現しにくくなります。
ABACは、所属部門、担当拠点、担当顧客、案件状態、委託先区分、契約期間、端末種別、アクセス元ネットワーク、時間帯などの属性を使ってアクセス可否を判断します。NIST SP 800-162は、ABACを、主体、客体、操作、環境条件などの属性をポリシーやルールに照らして評価するアクセス制御方式として説明しています。6
ABACは柔軟ですが、属性の品質、属性更新の責任、ポリシーの説明可能性を管理しないと運用が重くなります。実務上は、次のハイブリッドが扱いやすいです。
- RBACで大枠の職務権限を定義する。
- ABACで担当範囲、拠点、委託先、案件状態、時間帯などを補正する。
| 制御対象 | 基本方針 |
|---|---|
| ロール | RBACで管理する |
| 担当範囲 | ABACで補正する |
| 委託先 | RBACで専用ロールを作り、ABACで契約期間や対象業務を制限する |
| 高リスク操作 | RBACで実行権限を絞り、ABACで条件を追加する |
| 一時的な特権 | JITアクセスや申請承認で一時付与する |
細かすぎる権限制御は業務に乗りません。しかし、大雑把すぎる権限制御は内部不正や説明責任の問題になります。まずは全社、部門、拠点、担当、委託先、監査、承認者、システム管理者といった粒度で始め、高リスク操作だけ属性条件を厚くするのが現実的です。
CSV出力と一括処理はデータ持ち出しとして扱う
管理システムで特にリスクが高いのが、CSV出力、一括ダウンロード、一括更新です。
CSV出力は、業務上は単なる便利機能に見えます。しかし、セキュリティ上はデータの持ち出しイベントとして扱います。CSVとしてシステム外に出た瞬間に、次の制御が弱くなるためです。
- 行単位のアクセス制御
- 画面上のマスキング
- 詳細な閲覧ログ
- 担当範囲制限
- コピーや再共有の制御
- 最新性の保証
- 削除要求への対応
さらに、CSVはローカルPC、メール、共有フォルダ、クラウドストレージ、個人端末などに拡散しやすくなります。Excelやスプレッドシートで開かれる前提なら、CSV/Formula Injectionのような別のリスクも見ます。OWASP ASVS 5.0.0は、CSVや表計算形式への出力で、先頭文字が数式として解釈され得る値を適切にエスケープすることも検証項目にしています。2
CSV出力や一括処理には、通常の画面閲覧より強い統制を置きます。
| 統制 | 内容 |
|---|---|
| 権限限定 | CSV出力できるロールを限定する |
| 件数上限 | 大量出力を禁止または承認制にする |
| 申請承認 | 高件数・高機微データの出力は申請制にする |
| 出力理由 | 業務目的を記録する |
| 出力識別子 | ファイル名、ヘッダー、監査用シート等にユーザーID、日時、用途を埋め込む |
| 有効期限 | ダウンロードファイルを短期間で削除・無効化する |
| DLP連携 | メール添付や外部共有を検知・制御する |
| 出力ログ | 出力条件、件数、項目、操作者を記録する |
| 一括更新プレビュー | 更新前に差分確認を必須にする |
| ロールバック | 誤更新時に戻せるよう変更前データを保持する |
呼び方も大事です。レビュー上は、次のように扱ったほうが認識がそろいます。
| 機能名 | レビュー上の見方 |
|---|---|
| CSV出力 | 管理システム外への個人情報持ち出し |
| 一括更新 | 大量誤処理・大量不正変更の可能性がある高リスク操作 |
重要情報変更フローは即時反映だけが正解ではない
顧客情報の変更にもリスクの差があります。住所の表記ゆれ修正と、返金先口座の変更は同じ「顧客情報変更」でもリスクが違います。
変更対象ごとに統制を分けます。
| 変更対象 | リスク | 統制例 |
|---|---|---|
| 表記ゆれ、メモ、軽微な属性 | 低 | 通常権限、変更ログ |
| 住所、電話、メール | 中 | 変更前後ログ、顧客通知、必要に応じて理由入力 |
| 送付先、返金先口座 | 高 | 再認証、理由入力、顧客通知、事後レビュー |
| 契約状態、支払状態 | 高 | 承認、変更前後ログ、監査対象化 |
| 権限、削除、一括更新 | 最高 | 二者承認、申請制、強監査、ロールバック |
すべてを承認制にすると業務が止まります。しかし、すべてを即時反映にすると、不正や誤操作時に説明できません。現実的には、次の組合せです。
| リスク水準 | 処理方針 |
|---|---|
| 低リスク変更 | 即時反映 |
| 中リスク変更 | 理由入力 + 変更前後ログ + 必要に応じた顧客通知 |
| 高リスク変更 | 再認証 + 事後レビュー、または二者承認 |
| 最高リスク変更 | 申請承認 + 二者承認 + 強監査 + ロールバック |
承認は常に事前である必要はありません。業務を止められない場合は、事後レビューでも牽制効果があります。
| 操作特性 | 統制の寄せ方 |
|---|---|
| 高頻度・中リスク操作 | 事後レビュー |
| 低頻度・高リスク操作 | 事前承認 |
| 大量・不可逆操作 | 事前承認 + 二者承認 |
OWASP ASVS 5.0.0も、高価値の業務フローでは不正または偶発的な操作を防ぐために複数ユーザー承認を求める項目を置いています。2
理由入力は高リスク操作に絞る
管理システムでは、「理由入力」が求められることがあります。しかし、何でも必須にすると形骸化します。
- 確認のため
- 顧客対応のため
- 依頼対応のため
- その他
このような定型文だけが大量に残ると、監査上あまり役に立ちません。理由入力は、使いどころを絞ります。
| 対象 | 理由入力の要否 |
|---|---|
| 通常検索 | 原則不要 |
| 担当範囲内の詳細閲覧 | 原則不要 |
| 担当外閲覧 | 必須 |
| 高リスク変更 | 必須 |
| CSV出力 | 必須 |
| 一括更新 | 必須 |
| 例外権限利用 | 必須 |
自由記述だけに頼らず、選択式と自由記述を組み合わせるとレビューしやすくなります。
| 項目 | 例 |
|---|---|
| 理由区分 | 顧客申出、社内依頼、調査対応、障害対応、監査対応、その他 |
| チケット番号 | 任意または必須 |
| 補足理由 | 自由記述 |
理由入力は、操作を止めるためではなく、後から説明できる状態を作るための統制です。
衝突パターン別に整理する
管理システムのビジネス要件とセキュリティ要件の衝突は、いくつかの型に分けられます。
業務効率と最小権限の衝突
よくある要求は次のようなものです。
- 顧客一覧を全担当者に表示したい。
- 全支店の顧客を検索できるようにしたい。
- 委託先にも社員と同じ画面を使わせたい。
懸念は、担当範囲外閲覧、内部不正、委託先からの情報漏えい、権限棚卸の困難化です。対応は、ロールだけでなく、業務範囲・担当範囲・組織・案件状態でアクセス制御することです。ただし細かすぎるABACは運用負荷が高いため、最初は「全社」「部門」「拠点」「担当」「委託先」程度の粒度で始めます。
検索性と情報露出の衝突
よくある要求は次のようなものです。
- 氏名、住所、電話番号、生年月日、メールアドレスで検索したい。
- 部分一致検索したい。
- 検索結果を一覧で多項目表示したい。
懸念は、少ない手がかりから顧客情報を広く探索できることです。対応は、初期表示なし、検索条件必須、検索結果の最大件数制限、一覧表示項目の最小化、機微項目のマスク、詳細表示ログ、検索条件ログです。
即時処理と承認・牽制の衝突
よくある要求は次のようなものです。
- 顧客の属性変更をその場で完了したい。
- 返金、契約状態、送付先を即時変更したい。
懸念は、不正変更、誤変更、なりすまし対応、単独操作による不正です。対応は、低リスク変更は即時反映、中リスク変更は理由入力とログ、高リスク変更は二者承認または事後レビューに分けることです。
オペレーター負荷と再認証の衝突
よくある要求は次のようなものです。
- 1日に数十件から数百件の顧客情報を修正する。
- そのたびにMFAを求めると業務が止まる。
懸念は、離席時操作、セッション乗っ取り、なりすまし操作です。対応は、毎操作再認証ではなく、ステップアップ認証の有効時間を設けることです。端末ロック、VDI、IP制限、デバイス証明書、MFA済みセッション、非活動タイムアウト、操作ログ、異常検知を組み合わせます。
一括処理・出力と大量漏えいの衝突
よくある要求は次のようなものです。
- CSV出力したい。
- 顧客一覧をコピーしたい。
- 一括更新したい。
懸念は、大量持ち出し、Excel経由の二次漏えい、誤った一括更新、証跡の欠落です。対応は、CSV出力権限の限定、件数上限、申請承認、出力理由、出力識別子、出力ログ、ダウンロードファイルの有効期限、一括更新のプレビューとロールバックです。
業務行為別コントロール選定表
画面単位ではなく、業務行為単位で整理すると実務に落とし込みやすくなります。
| 業務行為 | 例 | 主なリスク | 推奨統制 |
|---|---|---|---|
| 検索 | 顧客を探す | 探索、名寄せ、担当外閲覧 | 検索条件必須、件数制限、検索条件ログ |
| 一覧表示 | 検索結果を見る | 大量露出 | 初期表示なし、項目最小化、マスキング |
| 詳細表示 | 個別顧客を見る | 個人情報閲覧 | 担当範囲制御、詳細表示ログ、異常検知 |
| 軽微編集 | 表記ゆれ修正 | 誤更新 | 変更前後ログ |
| 中リスク編集 | 住所、電話、メール変更 | 誤変更、なりすまし | 理由入力、顧客通知、変更前後ログ |
| 高リスク変更 | 口座、送付先、契約状態 | 金銭被害、重大事故 | 再認証、承認、事後レビュー |
| 出力 | CSV、印刷 | 大量漏えい | 権限限定、件数上限、出力識別子、DLP、ログ |
| 一括処理 | 一括更新、一括送信 | 大量誤処理 | 申請承認、プレビュー、差分確認、ロールバック |
| 代理操作 | 顧客の代わりに手続き | なりすまし、説明責任 | 本人確認記録、理由入力、通知、監査ログ |
| 例外操作 | 担当外閲覧、緊急対応 | 権限濫用 | 例外理由、時間制限、事後レビュー |
この表をベースに、システムごとに詳細化すると、レビュー観点として使いやすくなります。
ビジネスフローを見直すべきケース
セキュリティ要件は、単なる後付けの制約ではありません。場合によっては、ビジネスフローそのものを見直す根拠になります。
| ビジネス要件 | 見直しを提言すべき理由 |
|---|---|
| 顧客一覧を全件初期表示したい | 探すための一覧ではなく、情報露出そのものになっている |
| 担当外顧客も自由検索したい | 業務上の必要性が説明できない場合、最小権限に反する |
| 重要項目を誰でも即時変更したい | 不正・誤変更時の説明責任を果たせない |
| CSVで自由に持ち出したい | システム外に出た後の統制が弱い |
| 理由入力もログも不要にしたい | 事後調査・監査・牽制が成立しない |
| 委託先にも社員と同じ権限を付けたい | 責任分界・契約・監査の観点で過剰 |
とはいえ、セキュリティ部門が「危険です」「禁止です」と言うだけでは、議論は進みません。業務要件を否定するのではなく、複数案と残余リスクを提示し、どのリスクを誰が受容するかを明確にします。
顧客一覧表示であれば、次のように並べます。
| 案 | 内容 | 業務影響 | 残余リスク | リスク受容者 |
|---|---|---|---|---|
| A | 初期全件表示 | 低 | 大量閲覧・内部不正リスクが高い | 業務責任者 |
| B | 検索後のみ一覧表示 | 中 | 検索条件次第で過剰ヒット | 業務責任者 + システム責任者 |
| C | 顧客番号・案件番号検索のみ | 高 | 探しにくいが露出は低い | 業務責任者 |
| D | 担当範囲内のみ検索可能 | 中 | 担当設定の正確性に依存 | 業務責任者 + 権限管理者 |
この形にすると、セキュリティ部門が一方的に反対しているのではなく、選択肢、業務影響、残余リスク、意思決定者を並べている状態になります。
判断の型
管理システムのセキュリティレビューでは、次の順番で確認すると整理しやすくなります。
| 順番 | 問い |
|---|---|
| 1. 業務目的 | その機能は何のために必要か |
| 2. 業務頻度 | 日常的に大量発生するのか、例外的な操作なのか |
| 3. 事故時影響 | 誤操作・不正操作・漏えい時に何が起きるか |
| 4. 代替手段 | 一覧表示でなく検索で足りないか / 毎回再認証でなくステップアップ認証で足りないか / 承認でなく事後レビューで足りないか |
| 5. 残余リスク | 統制後に残るリスクは何か |
| 6. リスク受容者 | 誰がその残余リスクを受け入れるのか |
この型を使うと、ビジネス要件とセキュリティ要件の衝突を、感覚論ではなく意思決定の問題として扱えます。
おわりに
管理システムでは、重要情報を扱う操作が日常業務そのものになります。そのため、一般向けシステムのように「重要操作のたびに再認証」という単純な整理は、業務と衝突しやすくなります。
一方で、業務上必要だからといって、一覧表示、広範検索、即時編集、一括出力、再認証なしを無制限に認めると、管理システムは内部不正・大量漏えい・誤更新の主要リスク源になります。
必要なのは、画面単位ではなく、業務行為単位でリスクを分類することです。検索、一覧表示、詳細表示、編集、高リスク変更、出力、一括処理、代理操作、例外操作ごとに、再認証、権限制御、マスキング、承認、理由入力、ログ、異常検知、事後レビューを組み合わせます。
最後に答えるべき問いは、次の5つです。
- その業務行為は本当に必要か。
- 必要だとして、どの範囲まで許すのか。
- 誤用・悪用されたときに、何が起きるのか。
- そのリスクを下げるために、どの摩擦なら業務上許容できるのか。
- それでも残るリスクを、誰が受け入れるのか。
この問いに答えられるなら、セキュリティ要件とビジネス要件の衝突は、単なる対立ではなく、設計と意思決定の問題として扱えるようになります。