前回のWebサイト接続障害は、上流から切り分ける課題でした。今回は性質を変えて、IAM（＝AWSの権限を管理する仕組み）の権限追加を扱います。切り分けではなく、権限を設計・判断させる課題です。同じ器で、こんなに毛色の違う課題を扱えるかを試す意味もありました。
クリックは数回でも、判断は複雑
権限追加は、操作だけ見れば数クリックで終わります。ポリシーを選んでアタッチする、それだけと言えばそれだけです。だからこそ、確認観点を持たないと「それらしいポリシーを選んで終わり」になりがちな作業でもあります。作業が軽く見えるぶん、判断の重さが見落とされやすいのです。
でも、実際に難しいのは操作ではなく判断のほうです。誰に付与するのか、本当に必要なのはどの操作か、対象はどのリソースか、条件で絞れないか、恒久でいいのか期限を付けるのか。ここを飛ばすと、いつのまにか過剰な権限が積み上がっていきます。しかも、付けすぎた権限は、あとから「これは本当に必要か」を判断するのが難しく、なかなか外せません。付けるときの判断が甘いと、その負債が長く残るわけです。
そこでこの課題は、「ポリシーを選ぶ作業」ではなく「最小権限を設計・判断する作業」として、12ステップに組みました。
12ステップの流れ
題材は、開発担当者から「特定のS3バケットの、指定したプレフィックス配下を一覧・読取・書込したい。削除は不要」という依頼が来た、という想定です。よくある、しかし判断を省きやすい依頼を選びました。
- 依頼内容の確認
- 対象アカウント・リージョンの確認
- 対象IAMアイデンティティの特定
- 現在の権限確認
- 必要な操作とリソースの整理
- 権限付与方法の選択
- 最小権限ポリシーの作成
- 変更前レビュー
- ダミー変更の実施
- 変更後の確認
- 証跡・完了報告
- 完了
誰に付与するか、から始める
ステップ3では、まず「誰に付与するか」を判断させます。ここで、IAMユーザーへ直接、とくにインラインで権限を貼り付けるやり方は避けたい選択肢として扱いました。
代わりに、既存のロール、グループ、あるいはIAM Identity Centerの許可セット（Permission Set）を再利用できないかを先に考えます。個々のユーザーに権限を直付けしていくと、後で誰が何を持っているのかを追いにくくなり、棚卸しが難しくなるからです。正常な進め方として、再利用を優先するよう置いています。似た権限が必要な人が他にもいるなら、そのグループに寄せたほうが、あとの管理がずっと楽になります。
必要なActionとResourceを、依頼から写す
ステップ5が、この課題の中心です。依頼の言葉を、実際の権限に写していきます。曖昧な日本語の依頼を、具体的な操作へ翻訳する作業です。
- 一覧したい →
s3:ListBucket - 読取したい →
s3:GetObject - 書込したい →
s3:PutObject
そして大事なのが、依頼に「削除は不要」とある以上、s3:DeleteObject は入れないことです。頼まれていない操作を「ついでに」付けない、という判断をここで残します。「たぶん後で必要になるから」と先回りして付けるのは、最小権限とは逆方向です。
Resource（対象リソース）も絞ります。読取・書込は、依頼にあったプレフィックス配下のオブジェクトだけに限定します。バケット全体ではなく、その下の特定の範囲だけを対象にする、という指定です。さらに一覧については、Condition（条件）でプレフィックスを絞れます。同じ「一覧」でも、バケット全部が見える状態と、指定した範囲だけが見える状態は別物です。ここを分けて考えられるかどうかが、最小権限の分かれ目になります。ステップ6では、この権限を恒久にするか、見直し日を決めた期限付きにするかも選ばせます。一時的な作業なら、期限を付けておくほうが安全です。
フルアクセスを正解にしない
意識して避けたのが、AdministratorAccess や AmazonS3FullAccess のような広い権限を「正解」として置くことです。とりあえず動くようにするだけなら、広い権限を付けてしまえば済みます。手っ取り早いぶん、誘惑も強い。でもそれは、最小権限の考え方とは逆方向です。
この課題では、s3: やリソースを にする指定、管理者相当の権限を、正常例のほうには一切置いていません。むしろ異常例や注意事項として、避けるべき選択だと明示しています。ここは考え方の根幹なので、データを書いた本人の気の緩みで正常例に紛れ込まないよう、テストでも機械的に確認するようにしました。「正常例にフルアクセスやワイルドカードが入っていないこと」を自動でチェックしています。
許可テストだけでなく、拒否テストも
ステップ10の変更後確認では、「できるようになったか」だけでなく「できてはいけないことが、ちゃんとできないか」も見ます。ここは、意識しないと片方だけで満足してしまうところです。
許可すべき操作が許可されているのは当然として、依頼になかった削除や、対象外のプレフィックス、無関係な操作が拒否されること。この拒否側の確認まで含めて、初めて最小権限が守れているといえます。許可だけ確認して「動いたからOK」とすると、実は余計な権限まで通っていた、ということが起こり得ます。片面だけ見て安心しない、という観点をステップに組み込みました。
すべてダミーで、実適用は引き継ぐ
念のため書いておくと、この課題でもAWSの実環境は変更しません。ポリシーの作成も変更の実施も、性質としてはダミー操作です。ポリシーのJSONは作成・表示・コピーまでで、実際にアタッチはしません。ステップ7と9は、その旨を注意事項として明示しています。
完了制約も、要求どおりに証跡へ対応づけました。対象アイデンティティ、必要なAction、対象Resource、除外した権限の判断、変更前レビュー、ダミー確認、変更後の結果、そして完了報告。これらが空欄のままだと、そのステップは完了できません。実際の適用は、正式な変更作業の手順に引き継ぐ設計です。ここでも、練習と本番の変更をはっきり分けています。
作ってみて感じたこと
同じ「権限を付ける」でも、判断の道筋を分解して並べるだけで、作業の見え方がかなり変わりました。とくに「頼まれていないものを付けない」「拒否側も確認する」は、言葉にして固定するだけで効く観点だと感じます。当たり前のようでいて、急いでいると真っ先に飛ばしてしまうところだからです。
一方で、実際のIAMはもっと複雑で、この12ステップは代表的な一本道にすぎません。条件の書き方一つとっても奥が深く、複数の依頼が絡む場面や、既存ポリシーとの重なりまでは、今のデータでは扱えていません。ここも、型を示した段階だと考えています。
次回は、3つ目の課題として、既存AWS環境の調査・引き継ぎを15ステップに整理した話を書きます。