クラウドとIAMで守るべき最小権限の考え方
この教材の要約
クラウドとIAMを、便利な権限付与の仕組みではなく、責任分界と最小権限で守るべき運用対象として整理します。
概念図
クラウドとIAM
├─ 共有責任モデル
│ ├─ クラウド事業者が守る範囲
│ └─ 利用者が設定、運用する範囲
├─ IAM
│ ├─ 人の権限
│ ├─ システムの権限
│ └─ 一時的な権限
└─ 運用
├─ 最小権限
├─ 権限棚卸し
└─ 設定不備の見直し
はじめに
クラウド環境では、設定ミスや権限過多が大きな事故の入口になります。
とくにIAMは、「動くようにする」都合で広げられやすく、そのまま放置されがちです。1
この章では、共有責任モデルと最小権限の考え方を中心に整理します。
共有責任モデルをどう見るか
クラウド事業者が基盤の一部を守っていても、利用者側が考えるべきことは多く残ります。1
典型的には、次のようなものです。
- アカウント管理
- 権限設計
- 公開設定
- ログ取得
- 鍵や秘密情報管理
つまり、クラウドは「運用が消える環境」ではなく、責任の持ち方が変わる環境です。
IAMで最小権限を考える
最小権限とは、「念のため広く与える」の反対です。
その人、そのシステム、その役割に必要な範囲だけ権限を持たせる考え方です。1
ここで見るべき観点は次のとおりです。
- 何のための権限か
- 誰に必要か
- どの期間必要か
- どの操作まで許すか
権限過多が危険な理由
権限が広すぎると、次の問題が起きます。
- 誤操作の影響範囲が広がる
- アカウント侵害時の被害が大きくなる
- レビュー時に異常を見つけにくくなる
- 役割分担が崩れる
「動かないと困るから管理者権限で」という判断は、短期的には楽でも、長期的には危険です。
人とシステムの両方で権限を見る
IAMは人のアカウントだけの話ではありません。
アプリケーション、バッチ、CI/CD、サーバ間通信にも権限が付きます。
そのため、次の2種類を分けて考える必要があります。
- 人に与える権限
- システムやサービスに与える権限
どちらも、「何でもできる」状態を漫然と作らないことが重要です。
権限付与と棚卸し
権限管理では、付与時よりも、残し続けることの方が問題になりやすいことがあります。
見直したい場面は次のとおりです。
- 異動
- 案件終了
- 一時対応の終了
- 委託先作業の終了
付けることだけでなく、外すことを運用に組み込む必要があります。
クラウド設定不備とのつながり
IAMの弱さは、公開設定や構成ミスとも結び付きます。1
たとえば、次のような状態は危険です。
- 誰でも変更できる重要設定
- 本番環境への不要な管理権限
- 監査ログを止められる権限
- ストレージを広く公開できる権限
最小権限は、権限の美しさのためではなく、事故の広がりを抑えるために必要です。
起こしやすい誤り
一時的な管理者権限を戻し忘れる
短期間のつもりでも、そのまま恒久化するとリスクになります。
「同じチームだから同じ権限」で済ませる
同じチームでも、担当業務や責任範囲は違うことがあります。
役割と業務に応じた切り分けが必要です。
人の権限だけ見てシステム権限を見ない
CI/CDやアプリの権限は、人の操作よりも目立ちにくく、過大になりやすいポイントです。
日常で意識したい原則
- 権限は必要最小限にする
- 人とシステムの権限を分けて見る
- 一時権限は戻す前提で運用する
- 設定変更権限も重要資産として扱う
- 自社のクラウド運用ルールに従ってレビューする
ミニ確認
- 共有責任モデルで利用者側が考えるべきことには何があるか
- 最小権限が必要なのはなぜか
- 人の権限とシステム権限を分けて見るべき理由は何か
- 権限の棚卸しが重要なのはどんな場面か
次に読む
関連トピック
| 関係 | 教材 | 使い方 |
|---|---|---|
| 前提 | インフラとOSハードニングの基本 | 基盤防御からクラウド権限へ視点を広げる |
| 次に読む | ログ、監視、検知の初歩 | 権限利用と設定変更を観測する考え方へ進む |
| 横断参照 | セキュリティ基礎シリーズ教材マトリクス | クラウドと権限に関係する教材を探す |