【入門編】IAMポリシー設計のポイントを整理してみる

週1回のサウナが習慣になったCI部1課の山﨑です。

今回はIAMポリシー設計のポイントを考えて整理してみました。

はじめに
IAMポリシーの基本
- IAMポリシーの要素
  - ポリシー例
IAMポリシー設計のポイント
- 5Wで要件を整理する
まとめ

はじめに

AWSにおいて認証・認可（権限の付与）を司るサービスと言えば IAM（Identity and Access Management）です。IAMではJSON形式でポリシーステートメントに具体的に許可したい操作、拒否したい操作を記述して認可（権限の付与）を行い、IAMユーザーやIAMロールに関連付けたりしてポリシーを適用します。今回は実際にポリシーを設計する際のポイントを考えて整理してみました。なおAWSが扱うポリシーはいくつかの種類と評価の優先順位があるため本ブログを読み始める前にまずは以下のブログをご覧頂くと理解がよりスムーズになります。

blog.serverworks.co.jp

IAMポリシーの基本

IAMポリシーの要素

IAMポリシーを構成する要素はいくつかありますが、まずは以下の5つの要素を押さえておけば基本的なIAMポリシーの記述内容を理解することができます。その他の要素については参考ドキュメントをご覧ください。

要素	説明
Sid	記述するポリシーの説明を記述し、他のポリシーとの区別する。
Effect	操作を許可(Allow)するか、拒否(Deny)するかを記述する。
Action	具体的な操作内容を記述する。
Resource	ポリシーの適用範囲(どのAWSリソースに適用するか)を記述する。
Condition	どういった条件下でポリシーを適用するのかを記述する。

※参考ドキュメント：IAM JSON ポリシーの要素のリファレンス - AWS Identity and Access Management

ポリシー例

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "EC2FullAccess",
            "Effect": "Allow",
            "Action": "ec2:*",
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "aws:PrincipalArn": "arn:aws:iam::123456789123:user/yamasaki-user"
            }
        }
    ]
}

上記のポリシー例の内容を咀嚼すると以下のようになります。

要素	説明
Sid	EC2へのフルアクセス権限を付与するポリシーなので「EC2FullAccess」と記述する。
Effect	操作を許可(Allow)する。
Action	EC2の全ての操作を。
Resource	ポリシーの適用範囲(どのAWSリソースに適用するか)に制限は設けない。
Condition	Account IDが123456789123のyamasaki-userというIAMユーザーが操作主体だったらポリシーを適用する。

IAMポリシーの基本については以下のブログもご参照ください。

blog.serverworks.co.jp

IAMポリシー設計のポイント

5Wで要件を整理する

以下の5Wで要件を整理することで定義すべきポリシーが可視化されます。

Who(何が)
- ポリシーの適用主体
Where(何に対して)
- Resource要素
When(どんな条件下で)
- Condition要素
What(どんな操作を)
- Action要素
Want(どうしたい)
- Effect要素

ポリシーを関連付ける対象別に5Wを表で整理してみます。今回は利用頻度を考慮してIAM Permissions Boundary とセッションポリシーは対象から除外しました。

ポリシーの関連付け対象	Who(何が)	Where(何に対して)	When(どんな条件下で)	What(どんな操作を)	Want(どうしたい)
Organizations SCP	・メンバーアカウント・OU内の全アカウント	要定義	要定義	要定義	要定義(Allow or Deny)
リソースベースのポリシー	要定義	ポリシーを適用したAWSリソース ※AWSリソースを絞ることは可	要定義	要定義	要定義(Allow or Deny)
IAMユーザー	IAMユーザー	要定義	要定義	要定義	要定義(Allow or Deny)
IAMロール	要定義	要定義	要定義	要定義	要定義(Allow or Deny)

ポリシーを関連付ける対象によってはWho(何が)やWhere(何に対して)が決まっているので「要定義」と記載がある箇所について検討し、ポリシーを設計する必要があります。

Organizations SCP

Who(何が)	Where(何に対して)	When(どんな条件下で)	What(どんな操作を)	Want(どうしたい)
・メンバーアカウント・OU内の全アカウント	要定義	要定義	要定義	要定義(Allow or Deny)

Organizations SCP ではWho(何が)は決まっているので、残りは以下を設計すれば良さそうです。

Who(何が)
- どのメンバーアカウント、どのOUに適用するのか
Where(何に対して)
- Resource要素
When(どんな条件下で)
- Condition要素
What(どんな操作を)
- Action要素
Want(どうしたい)
- Effect要素

Want(どうしたい) についてですが、AWSのIAMのベストプラクティス（最小権限の許可）にしたがって細かい制御を行うのは運用負荷が高いので、SCPでは許可したいことではなく、拒否させたいことを設計する方が良いと思います。

SCPについては以下のブログもご覧ください

blog.serverworks.co.jp

リソースベースのポリシー

Who(何が)	Where(何に対して)	When(どんな条件下で)	What(どんな操作を)	Want(どうしたい)
要定義	ポリシーを適用したリソース	要定義	要定義	要定義(Allow or Deny)

リソースベースのポリシーではWhere(何に対して) は決まっているので、残りは以下を設計すれば良さそうです。

Who(何が)
- ポリシーの適用主体
Where(何に対して)
- AWSリソースを絞ることが可能です。例えばS3のバケットポリシーであればS3のARNを使ってディレクトリパスのレベルでWhere(何に対して)を絞り込むことが可能です
When(どんな条件下で)
- Condition要素
What(どんな操作を)
- Action要素
Want(どうしたい)
- Effect要素

Who(何が) についてですが、Principal というIAMポリシーの要素を利用することで指定することが可能です。例えば以下のポリシー例ではWho(何が) をCloudTrail に指定することでCloudTrail からsample-bucket/AWSLogs/123456789123/ 配下のディレクトリに対して書き込み許可を付与しています。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AWSCloudTrailWrite",
            "Effect": "Allow",
            "Principal": {
                "Service": "cloudtrail.amazonaws.com"
            },
            "Action": "s3:PutObject",
            "Resource": "arn:aws:s3:::sample-bucket/AWSLogs/123456789123/*"
        }
    ]
}

IAMユーザー

Who(何が)	Where(何に対して)	When(どんな条件下で)	What(どんな操作を)	Want(どうしたい)
IAMユーザー	要定義	要定義	要定義	要定義(Allow or Deny)

IAMユーザーではWho(何が)は決まっているので、残りは以下を設計すれば良さそうです。

Who(何が)
- どのIAMユーザーに適用するか
Where(何に対して)
- Resource要素
When(どんな条件下で)
- Condition要素
What(どんな操作を)
- Action要素
Want(どうしたい)
- Effect要素

IAMエンティティに対して適用するポリシーに対して、AWSは予めよく利用するであろうポリシーをAWS管理ポリシーとしてパッケージ化して用意してくれています。管理ポリシーを含めポリシーは以下の3つに分類することができます。

ポリシー分類	説明
AWS管理ポリシー	AWSが用意しているポリシー群で複数のIAMエンティティで再利用可能。ユーザーによる編集は不可。
カスタマー管理ポリシー	ユーザーが作成するポリシー群で複数のIAMエンティティで再利用可能。ユーザーによる編集は可能。
インラインポリシー	各IAMエンティティ固有のポリシー群。再利用不可。ユーザーによる編集は可能。

IAMロール

Who(何が)	Where(何に対して)	When(どんな条件下で)	What(どんな操作を)	Want(どうしたい)
要定義	要定義	要定義	要定義	要定義(Allow or Deny)

IAMロールはこれまでのポリシーの関連付け対象とは異なり5Wの全てをイチから定義する必要があります。

Who(何が)
- ポリシーの適用主体
Where(何に対して)
- Resource要素
When(どんな条件下で)
- Condition要素
What(どんな操作を)
- Action要素
Want(どうしたい)
- Effect要素

Who(何が) についてですが、IAMロールでこれを定義するのはポリシーステートメント内ではなく信頼関係です。

f:id:swx-yamasaki:20210922125842p:plain — IAMロール - 信頼関係 -

信頼関係では以下のようにしてIAMロールのWho(何が) を定義します。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "",
      "Effect": "Allow",
      "Principal": {
        "Service": "ec2.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

IAMロールはAWS Security Token Service (AWS STS) というサービスを利用して一時的な認証情報を得ることで、IAMロールを関連付けた対象に対してIAMポリシーのポリシーステートメントに記載された権限を一時的に付与することができます。そのためAction要素にはSTSに関する操作を記述しています。この信頼関係の記述はリソースベースのポリシーに分類されるポリシーです。

上述の信頼関係のポリシーステートメントではEC2サービスをIAMロールのWho(何が) として定義しています。このIAMロールをEC2に関連付けることによってEC2はポリシーステートメント内の権限を利用することが可能になります。