ちゃんと考えよう、IAMのはなし

はじめに

AWSを利用する際に必ず使用するIAM。
なんとなく利用することも多いのではないでしょうか。
IAMについて考える機会があったので、今一度整理してみようと思います。

目次

1. IAMとは
2. IAMポリシーとは
3. IAM設計で意識すべき４つのこと
4. 本番運用に耐えうるIAMとは

1. IAMとは

AWS Identity and Access Management(IAM)

• AWSリソースへのアクセスを安全に管理
• 下記のいずれかの方法でアクセス許可を付与
  • 適切なアクセス許可ポリシーがアタッチされたグループのメンバーにする (推奨)
  • ポリシーをユーザーに直接アタッチする

2. IAMポリシーとは

AWSでのアクセスを管理するために権限を定義したもの。
IAMポリシーには６つのタイプがあります。
1. アイデンティティベースのポリシー
2. リソースベースのポリシー
3. アクセス許可の境界
4. 組織 SCP
5. アクセスコントロール (ACL)
6. セッションポリシー

このうち、アイデンティティベースのポリシーには大きく分けて３つの種類があります。

AWS管理ポリシー

• AWS が作成および管理するスタンドアロンポリシー

カスタマー管理ポリシー

• AWS利用者が作成および管理するスタンドアロンポリシー

インラインポリシー

• IAM アイデンティティ (ユーザー、グループ、またはロール) に埋め込まれたポリシー

3. IAM設計で意識すべき４つのこと

個人的所感ですが、IAM設計する場合は以下のことに気を付ける必要があります。

1. 権限を付与する方法をどうするか？
   • IAMロール
   • IAMグループ
   • インラインポリシー
2. 付与する権限は頻繁に変更が入るか？
3. 権限のパターンは多いか？少ないか？
4. 独自の権限ルールが必要か？

4. 運用に耐えうるIAMとは

よくあるパターンを考えてみます。

1. 権限を付与する方法はIAMグループ
2. 付与する権限は頻繁に変更する可能性が高い
3. 権限パターンは少ない
4. 独自の権限ルールが必要

上記を満たすために、何をすべきか考えます。
1. 必要なAWSマネージドポリシーを洗い出します。
2. 要件に即したカスタマー管理ポリシーを作成します。
3. 必要となる権限要件を満たすように、AWSポリシーとカスタマー管理ポリシーを組み合わせたIAMグループを作成します。
4. 作成したIAMグループに該当IAMユーザーをアタッチします。

図にすると下記のようになります。

この設計の良いところは、下記だと思っています。
1. AWS管理ポリシーとカスタマー管理ポリシーを組み合わせて権限要件を満たすことで、メンテナンス対象ポリシーを絞ることができる
2. 権限パターンごとにIAMグループを作成するので、付与する権限を変更する場合はIAMグループを変更するだけで良い

逆にデメリットとしては下記ですかね。
1. 権限パターンが多いと、IAMグループが乱立する
2. ポリシーの組み合わせでは、複雑な権限ルールを表現することが難しい

最後に

IAMはAWSにおけるアクセス管理において非常に重要なサービスです。
権限設定を間違えると、AWSアカウントへの不正アクセスを許してしまい被害は計り知れません。
適切な権限を設定し、安全にAWSを利用しましょう。

参考資料

https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/introduction.html
https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/access_policies_managed-vs-inline.html