最小権限とMFAのシナリオ判断
ある部署では、監査担当にもアプリにも管理者権限を配っていました。MFAの導入だけで改善を終えず、人の認証、アプリの認証情報、実際に必要な操作、異動時の見直しを分けて修正します。
この単元で学ぶこと
- MFAだけでは残る過剰権限を事例から見つけられる
- 人とアプリの認証情報の改善策を選べる
- 権限を絞る際の許可・拒否の検証を具体化できる
本文解説
事例の前提 監査担当は請求に関するログを読むだけですが、作業開始時に全管理者権限を付与されました。EC2上の集計アプリは一つのS3範囲を読むだけなのに、社員の長期アクセスキーをコードへ保存しています。社員はコンソールMFAを使っています。この状態を「MFAがあるので安全」と一括評価しないようにします。
人の問題：認証は強くても許可が広い MFAは本人以外によるサインインを難しくしますが、本人が誤ってログを削除できる権限はそのままです。監査担当に必要な閲覧・検索などを洗い出し、削除や無関係なサービスの管理は外します。読み取り専用という名前のポリシーでも対象範囲が広すぎないか内容を確認します。
アプリの問題：人のキーを配布している アプリの実行にはIAMロールによる一時認証情報を利用し、人の長期キーをコードへ置かない設計を検討します。権限はアプリ専用にし、人の管理者権限をそのまま引き継がせません。長期キーが漏れた疑いがあれば、MFAの登録だけで解決したとせず、そのキーの無効化や利用状況の調査を行います。
権限を絞る単位 集計アプリは売上ファイルの読取りが必要ですが、顧客原簿の削除や別部署の保管領域へのアクセスは不要です。API、対象リソース、必要な条件を確認してポリシーを設計します。一覧取得とオブジェクト読取りなど、異なる操作が必要な場合もあるため、名前だけで一つの許可へ決めつけません。
変更の検証 検証環境で必要なファイルが読めること、削除を拒否すること、対象外のデータを読めないことを確認します。必要な月次処理がまだ試せていない場合、直近のログに登場しないという理由だけで許可を削るのも危険です。利用記録を手掛かりにしつつ、業務担当の必要条件と照合します。
人のアクセスを集中管理する 社員が複数アカウントを使うなら、IAM Identity Centerなどと既存のID基盤を組み合わせ、職務別の権限を管理する方法を検討します。退職者のアクセス停止を漏らさない運用を用意します。ただし一元管理を導入しただけで、古いキーや別経路が全て消えるとは限らないので、移行元の認証情報も棚卸しします。
異動のケース 監査担当が開発部署へ移った場合、旧監査アクセスが今も必要かを確認して除去します。MFA端末を新しくしただけでは権限は変わりません。「本人である」「現在の業務上必要である」「その必要範囲だけ許可される」の三つを合わせて維持します。
例題：削除を拒否したら集計も止まった 権限を縮小した後に必要な一覧取得まで失敗したなら、最小権限を実現したとはいえません。失敗したAPIを調べ、業務に必要な対象だけ許可を修正します。安易に管理者権限へ戻すのではなく、必要な範囲を証拠に基づいて調整します。
図解
重要ポイント
- MFA導入後も監査担当の過剰な操作権限は残り得る。
- EC2アプリは必要範囲のロールと一時認証情報を使う。
- 利用記録だけでなく月次など低頻度の業務も照合する。
- 移行時には旧キーや旧権限の残存を点検する。
間違えやすい点
- コンソールMFAで漏れたAPIキーへの対処を完了しない。
- 利用履歴にないだけで業務上不要と即断しない。
- 必要操作の失敗を最小権限の達成と誤解しない。
用語解説
- 認証
- アクセスする主体が誰であるかを確認すること。パスワードやMFAなどを利用する。
- 認可
- 認証された主体などに、どのリソースのどの操作を許すか判断すること。
- 最小権限
- 業務に必要な操作・対象・条件に限定して権限を与える原則。何もできなくすることではない。
- MFA（多要素認証）
- 知識・所持・生体など異なる種類の要素を組み合わせて本人確認を強める仕組み。パスワードを二つ入力するだけとは異なる。
- 一時認証情報
- 有効期限を持つ認証情報。IAMロールなどを通して取得し、長期的な秘密情報の配布を減らせる。
- IAMポリシー
- 許可または拒否する操作、対象リソース、条件などを記述し、アクセス制御に用いる文書。
関連教材
参考資料
教材データに登録された参考リンクです。リンク先の内容や更新日は提供元でご確認ください。
確認問題の出題・採点や学習履歴の保存にはログインが必要です。