IAM設計で意識すべきこと3選
こんにちは。新人エンジニアのiidahです。
アイソルートに入社して4か月。業務ではAmazon IAMの設計(IAMポリシーの編集)をしていました。
IAMとはIdentitiy and Access Management の略で、
IAMポリシーと呼ばれる「どのサービスに対し、何ができるか(できないか)」をルールによって記述し、
IAMユーザーやグループ、AWSロールにアタッチし、「誰に適用するのか」を指定することで、
ユーザーやサービスのアクセス権限を制御するサービスです。
自分がIAM設計をしていく上で、意識するとより良い設計ができるなと感じたことがいくつかあったので、記事にしようと思いました。
IAM設計で悩んでいる人や、IAM設計で意識すべき部分が知りたいという方は、是非ご一読ください!
目次
この記事の目的
この記事では、自分がIAM設計の業務を通して意識すると良いと感じたことを3つ示しています。これらの内容と通して初めてIAM設計をする人や、IAM設計で悩んでいる人の助けになってほしいという想いがあり、記事にしました。
①IAMポリシーの基本構造の把握する
1つ目はIAMポリシーの基本構造の把握です。IAM設計ではIAMポリシーを作成し、それらをユーザーやグループ、ロールにアタッチし、アクセス権の制御を行います。
IAMポリシーはJSON形式で作成することが多いです。理由として
・GitやCodecCommit等でバージョン管理が可能
・詳細な設計を行うことがことが可能
などが挙げられます。
JSON形式でポリシーを書く場合に、各要素がどのような役割を持つかを把握することで、適切にIAMポリシーを設計することができます。
IAMポリシーの基本構造は以下のようになります。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "hoge",
"Effect": "Allow",
"Action": "*",
"Resource": "*"
"Condition":{}
},
{
"Sid": "hoge2",
"Effect": "Allow",
"Action": "*",
"Resource": "*"
"Condition":{}
}
...
]
}次に、基本構造内の各要素について簡単に説明します。
Version
VersionではIAMポリシーの構文のルールを指定しています。2025/08/27現在では、「2012-10-17」と「2008-10-17」の2種類のみが定義されています。「2012-10-17」が最新バージョンになるので、こちらを使うことが多いです。
Statement
Statementでは具体的なIAMポリシーのルールを記載していきます。上記の図のように、Statementの中では複数のルールを記載することが一般的です。
Statemantの中には様々な要素がありますが、今回はその中から自分が扱った5つの要素について解説していきます。
Sid
Sidではの名前を定義します。基本的には何でも良いので、開発チーム内で命名規則がある場合はそれに従い、ない場合は「このStatementがどんなルールなのか」を名前にすると良いです。
例えばEC2インスタンスへのアクセスを拒否するStatementなら「DenyAccessEC2Instance」のように命名すると良いでしょう
Effect
Effectではそのルールが拒否(禁止)するルールなのか、許可するルールなのかを定義します。拒否の場合は「Deny」、許可の場合は「Allow」を設定します。
Action
Actionでは拒否(または許可)する具体的なルールの内容を設定していきます。例えばSidので例示したEC2インスタンスへのアクセスを拒否するStatementの場合、Actionは以下のようになります。
"Action": "EC2:*"EC2はサービスを表し、右の「*」はEC2に関するすべてのActionを表します。
Actionはサービスごとにかなりの数あるので、以下の公式ドキュメントを参照して、必要なActionを探すと良いです。
Actionを指定するにあたり、S3などのデータストアサービスから情報や権限など、何かを得る場合はGetで始まるActionが、何かの一覧を取得する場合はListで始まるActionになっていることが多いので、その部分を参考にActionを探すと良いです。
Resource
ResourceではAWSサービスのどのオブジェクトにルールを適用するのかを指定します。以下のような形で指定します。
"Resource":"arn:aws:AWSサービス名:リージョン名:アカウントID:サービス内のリソース名"例えばS3(サービス名)のhogehogeというバケット(リソース)に対し、ルールを適用する場合は以下のようにResourceを指定します。
"Resource":"arn:aws:s3:::hogehoge"Condition
Condition要素ではポリシーを実行する条件を指定することができます。「特定のユーザーにのみこのルールを適用したい」や「特定のIPアドレスからのアクセスの場合、このルールを適用したい」といった場合にこの要素を用います。
例えば192.0.12.1/24からアクセスされた場合にこのルールを適用する場合、ルールに以下のような要素を指定します。
"Condition": {
"IpAddress": {
"aws:SourceIp": "192.0.12.1/24"
}
}上記のように各要素の役割を理解することで、適切なIAM設計をすることができます。
②公式ドキュメントのケースの利用する
「①IAMポリシーの基本構造の把握する」で述べたように、Actionの要素はかなりの数あるので、
要件に対し、どのようなActionを指定すればよいか分からなくなることがあります。
そういったときは公式ドキュメントのアイデンティティベースポリシーを参照しましょう。
「 (サービス名) iamポリシー アイデンティティベース」と検索すると、サービスごとのアイデンティティベースのポリシーを見ることができます。
アイデンティティベースのポリシーでは、サービスごとにユースケースとそれに対応するIAMポリシーが記載されています。
例えばGuardDutyの検査結果の閲覧のみを参照するIAMポリシーを設計する場合、この章の章末に記載しているドキュメントの
「GuardDuty への読み取り専用アクセス権を付与するカスタム IAM ポリシー」
に書かれているポリシーを利用することで、閲覧権限のみのポリシーを設計できます。
このように、公式ドキュメントに記載されているポリシーを活用することで、要件に沿ったIAMポリシーを効率的に設計できます。
GuardDutyのアイデンティティベースポリシー:https://docs.aws.amazon.com/ja_jp/guardduty/latest/ug/security_iam_id-based-policy-examples.html
③現状のポリシーを確認する
保守などでIAMポリシーを改善する場合には、現状のIAMポリシーやアタッチ先を確認することが重要です。
自分が業務でIAM設計を扱った時は、以下のように、
ユーザーグループにアタッチされているポリシーによってユーザにロール(にアタッチされているIAMポリシー)を付与するような構造をしていました。
この構造を把握することによって要件によってどのIAMポリシーを編集すればよいのかがすぐにわかり、業務をより効率よく行うことができました。
このように、既存のIAMポリシーの改善を行う場合、あらかじめIAM設計の構造を把握しておくことで、どの部分を修正すればよいかが分かるようになります。
最後に
今回述べた3つのことを意識することで、IAM設計をより効率的に行うことができます。この記事を通して、IAM設計で困っている人や、初めてIAM設計を行う人の助けになればと思います。
