女性向けエンジニアスクール
3秒でわかる
誰がどのリソースに何をしてよいかをJSONで書いた許可の定義。クラウドの権限はこの単位で決まり、最小限だけを与える設計が事故の範囲を狭めます。
もう少し詳しく
どういうものか
ポリシーは、アクセスの可否を機械が読める形で書いた文書です。AWS の IAM では JSON で記述し、許可か拒否かを表す Effect、操作を表す Action、対象を表す Resource、条件を表す Condition を並べます。これを利用者やロールに割り当てると、そこに書かれた操作だけが通り、書かれていない操作は既定で拒否されます。
なぜ必要か
クラウドでは、アカウントを 1 つ乗っ取られた影響がそのまま全リソースへ広がります。権限を人ごとに口頭で決めていると、誰が何をできるのか誰も把握できません。ポリシーはその取り決めをファイルとして残し、レビューでき、git で差分を追え、複数の環境へ同じ内容を配れる形にしたものです。必要最小限だけを与える設計にしておくと、事故が起きても被害が及ぶ範囲が限定されます。
具体例
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": ["s3:GetObject", "s3:PutObject"],
"Resource": "arn:aws:s3:::report-bucket/uploads/*"
},
{
"Effect": "Deny",
"Action": "s3:DeleteObject",
"Resource": "arn:aws:s3:::report-bucket/*"
}
]
}このポリシーでは、uploads 配下の読み書きだけができ、削除はバケット全体で禁止されます。
つまずきやすいところ
もっとも多いのは Resource の末尾の書き分けです。arn:aws:s3:::my-bucket はバケット自体を指し、中のファイルを操作するには arn:aws:s3:::my-bucket/* が別途要ります。一覧取得と読み取りで対象が違うため、片方だけ書いて権限エラーになる事例が絶えません。もうひとつは評価順の誤解で、Deny は他のどのポリシーの Allow よりも強く、1 つでも該当すれば通りません。作業を急いで "Action": "*" を付けると、その場は動きますが監査で必ず指摘されます。
似た用語との違い
| 用語 | 役割 |
|---|---|
| ポリシー | 許可と拒否の内容そのものを書いた文書 |
| ロール | ポリシーを束ね、一時的に引き受ける権限のまとまり |
| ユーザー | 人や機械に対応する恒久的な主体 |
覚え方
誰が、何を、どれに、どんなときに。この 4 つが揃って初めて 1 つの文になります。
