Updated:
テクニカルブログ

AWSの薄い本 IAMのマニアックな話 その2

前回まで

前回はIAMについてと、IAMの基本機能5つの説明のところまですすみました。
今回はIAMポリシーの具体的な設定方法、デザインパターンについて理解したいと思います。
（書籍の中では具体的なカスタマー管理ポリシーの作成のチュートリアルに入っていくのですが、ここでは重要だと思うポイントにしぼって記します。）

IAMポリシー

IAMポリシーを構成する要素（エレメント）は大きく以下の2つです。

  • Version
  • Statement

Version

Versionは2008-10-17と2012-10-17があります。指定しない場合は2008-10-17になるので、必ず明示的に2012-10-17を指定しましょう。

Statement

Statementは大きくEffect, Action, Resourceの3つがあります。
EffectはAllowかDenyを指定します。
ActionはAWSサービスを指定します。全てを指定するアスタリスクも利用できます。
Resourceは利用するリソース（リージョン、IAMユーザー名、S3バケットなど）を指定します。

チュートリアルで紹介されていた特定のIPアドレスを許可するポリシーはこんな感じです。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "IpAddress": {
          "aws:SourceIp": [
            "8.8.8.8/32"
          ]
        }
      }
    }
  ]
}

ここで新しくConditionというStatementが出てきています。制限を追加する場合に利用します。
この例は送信元IPが8.8.8.8/32であれば全て許可されるということです。aws:SourceIpで指定するIPアドレスはグローバルIPでなければなりません。VPC内のリソースを制限したい場合は、VPCのプライベートIPを指定するのではなく、VPC IDもしくはVPC Endpoint IDを指定します。
6章で紹介されているVPC Endpoint IDが指定されている例を記します。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
{
  "Version": "2012-10-17",
  "Id": "ListrictAccess",
  "Statement": [
    {
      "Sid": "Allow-from-specific-VPC-only",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": [
        "arn:aws:s3:::kindle-iam-test",
        "arn:aws:s3:::kindle-iam-test/*"
      ],
      "Condition": {
        "StringNotEquals": {
          "aws:sourceVpce": "vpce-id1234"
        }
      }
    }
  ]
}

Conditionのところに、VPC Endpointが指定されていることがわかります。

IAMの許可・拒否ポリシーの挙動

権限の指定の優先度は以下の順序になっています。

明示的なDeny > 明示的なAllow > 暗黙的なDeny（デフォルト）

設定しなければ暗黙的なDenyとなります。こう言った優先度になるので、明示的なAllowをAWS管理ポリシーで設定し、明示的なDenyをカスタマー管理ポリシーで設定するのがよさそうです。この設定方法は後にハイブリッドパターンとして紹介します。

IAMポリシーのデザインパターン

大きく3つのパターンに分けられます。

  • ホワイトリストパターン
  • ブラックリストパターン
  • ハイブリッドパターン

一つずつみていきましょう。

ホワイトリストパターン

許可する権限のみ付与していくパターン。
サービス単位で指定する場合は、AWS管理ポリシーを利用します。

メリット

必要最小限の権限のみ付与するので、セキュリティ面での信頼性が高くなります。

デメリット

事前に役割が決まっていないと権限を付与できない。
アクション単位で指定する場合、AWSサービスが拡大したときなど、都度それに対応しないといけない。

ユースケース

業務、運用、設計が確立している本番環境に適用すべきです。
AWS管理ポリシーもほぼホワイトリストパターンの実装になっています。

ブラックリストパターン

許可してはいけない権限のみを剥奪するパターン

メリット

禁止事項のみを定義すれば良いので、IAMポリシーの設計、設定が最小ですみます。

デメリット

予期せぬ機能が突然使えるようになる点。

ユースケース

  • 一般的なIAMの運用としては、ブラックリストパターンの利用が多くなる。
  • AWSの権限のデフォルトは暗黙的拒否。
    そのため、どこかで許可のステートメントを作った上でブラックリストで拒否するというタイミングになります。

ハイブリッドパターン

AWS管理ポリシーによる許可と、カスタマー管理ポリシーによる拒否の組み合わせ。

メリット

AWSの定義済ポリシーと自分で作ったブラックリストを組み合わせて利用することにより、最小の労力で実用的なポリシーを作ることもできる。個々のポリシーもシンプルにできる。

デメリット

特になし

ユースケース

1ポリシーで管理すべきか、グループで組み合わせて1ポリシー管理するか、どちらが良いのでしょうか。

1ポリシでーで全て書くことのメリット

視認性が高い
そのポリシーを付与するだけで良い

デメリット

再利用性（モジュラリティ）が低い

グループでの組み合わせで書くことのメリット

各ポリシーの再利用性が高い＝管理するポリシーが少なくて済みます。
各ポリシーは独立していて、疎な関係を持ちます。

まとめ

IAMロールを付与するパターンはホワイトリストかブラックリスト
どちらかだけで良いと言うわけではなくどちらも重要なのでこれらの組み合わせで権限を制御します。
〇〇以外という反転のパターンを考えられるようになると記載できるルールの幅が広がりそうです。

次回はIAMグループのデザインパターンをみていきます。