AWS Identity and Access Management (IAM)

AWS上のサービスを操作するときは必ずIAMによる認証と認可が必要になります。認証とは「誰が（ユーザー、ロール）」をコントロールし、認可とは「何を（ポリシーによるAPIアクション）」をコントロールします。
IAMでは、一般的に必要な人に必要最低限の権限のみを付与することが推奨されています。

IAMの基本

AWSアカウントを作成するときに設定するメールアドレスとパスワードでログインするユーザーはルートユーザーです。ルートユーザーは、アカウント内におけるすべての操作権限が与えられていて、権限を制限することなどは不可能です。ルートユーザーのログイン情報が流出すると完全にアカウントを乗っ取られてしまうため、ルートユーザーは原則使用せず、後述のIAMユーザーを使用して操作を行います。
IAMユーザーは、AWSアカウントを利用する各利用者向けに作成されるアカウントです。IAMユーザーではAWSの各サービス操作に関する権限を細かく設定することが可能です。IAMユーザーは最初に作成されないため、ルートユーザーでログイン後作成する必要があります。IAMユーザーはグループでまとめて管理が可能で、利用すると運用が楽になります。

IAMの機能

IAMはAWS操作をセキュアに行えるように、認証・認可の仕組みを提供しています。IAMには数多くの機能がありますが、とくに基本となる以下5つの機能をまとめます。

• IAMユーザー
• IAMグループ
• IAMポリシー
• IAMロール
• パーミッション・バウンダリー

IAMユーザー

IAMユーザーは認証を実施します。IAMユーザーの認証には2種類あり、IDとパスワードの組み合わせと、アクセスキー・シークレットアクセスキーの組み合わせが利用可能です。
IDとパスワードの組み合わせによりAWSマネージメントコンソールにログインすることができ、アクセスキー・シークレットアクセスキーの組み合わせによりAWS CLIやSDKによる操作ができます。

1つのAWSアカウント内に複数のIAMユーザーを作成でき、利用者1人ずつ個別のユーザーを作成することが推奨されています。1つのIAMユーザーを共有して複数人で使用することはセキュリティー的に推奨できません。

IAMユーザーは認証を提供する機能であるため、作成段階ではAWSサービスへのアクセス許可がありません。後述するIAMポリシーをアタッチすることにより、アクセス制御を行います。

IAMグループ

IAMグループは、同一の役割を持つIAMユーザーをグループ化する機能です。
IAMグループを利用することで、利用者の所属する部署や役職に応じた権限を容易に、かつ、正確に管理できます。IAMユーザーに直接IAMポリシーをアタッチすることも可能ですが、権限漏れや過剰付与などのミス発生確率が高くなるため、複数人でAWSアカウントを操作する場合はグループを作成することが推奨されます。

IAMポリシー

IAMポリシーは、AWSリソースへのアクセス権限や制御権限をまとめたものです。ポリシー自体はJSON形式で記述します。
ポリシーでは「どのリソースに対して」「なんの操作を」「許可するか拒否するか」を定義します。

以下の例ではsample-bucketというS3バケットに対して、GetObject（オブジェクトの取得）のみを許可するというポリシーとなります。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:GetObject"
            ],
            "Resource": [
                "arn:aws:s3:::sample-bucket/*"
            ]
        }
    ]
}

• Statement: 許可（拒否）を複数設定する
• Effect: 許可（Allow）か拒否（Deny）を設定する
• Action: 許可（拒否）するアクションのAPIを設定する
• Resource: アクションの対象リソースを指定する

Action、Resourceはワイルドカード（*）を使用できます。

上記の例ではGetObjectのみ明示的に許可しているため、この操作が許可されます。明示的に許可や拒否していないPutObjectなど他のさまざまなAPIは暗黙的に拒否されます。

IAMポリシーの評価論理は基本的に以下の順で評価されます。
明示的なDeny > 明示的な許可 > 暗黙的な拒否（デフォルト）

より詳細なIAMポリシーの評価論理に関しては以下の図のようになっています。

IAMロール

IAMロールはAWSサービス（LambdaやEC2、Kinesisなど）やアプリケーションに対してAWSの操作権限を一時的に渡してくれる機能です。
たとえば、EC2に対してIAMロールをアタッチすることで、EC2上で実行されるアプリケーションはアクセスキーID・シークレットアクセスキー（IAMユーザー）を設定することなく、そのEC2に割り当てられたAWSの操作権限を利用できます。
同様にサーバーレスであるLambdaやコンテナサービスのECSなど、IAMユーザーを割り振れないサービスに対してもIAMロールを利用します。

IAMユーザーとIAMロールの両方が使えるサービスを利用する場合は、IAMロールによる権限管理を行うほうが推奨されます。IAMロールでは一時的なアクセスキーとシークレットアクセスキー、トークンを利用して認証するためよりセキュアと言えます。一時的な認証情報は約6時間おきに自動更新されます。

パーミッション・バウンダリー

Permissions boundaryはIAMユーザーもしくはロールに設定することで、それらが持つ権限に境界を設定することができるものです。それに対していわゆる「IAMポリシー」はPermissions policyと呼ばれます。そこで定義された内容とPermissions boundaryの内容で重なりあう部分のみ（AND条件）有効な権限として動作します。
Permissions policyでどんなに強い権限が与えられていたとしても、Permissions boundaryによって設定された境界を超えたアクションは実行できません。

IAMのベストプラクティス

AWSでは、IAMの利用におけるベストプラクティスを公開しています。
https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/best-practices.html

IAMやAWSを使用する上で推奨されるセキュリティーが記載されているため、内容を確認することをオススメします。

IAMベストプラクティスのリスト

• AWSアカウント ルートユーザー アクセスキーをロックする
• 個々のIAMユーザーを作成する
• IAMユーザーにアクセス許可を割り当てるためには、ユーザーグループを使用する
• 最小限の特権を認める。
• AWS管理ポリシーを使用したアクセス許可の使用開始
• ポリシーの検証
• インラインポリシーではなくカスタマー管理ポリシーを使用する
• アクセスレベルを使用して、IAMアクセス許可を確認する
• ユーザーのために強度の高いパスワードポリシーを設定する。
• MFAの有効化
• Amazon EC2インスタンスで実行するアプリケーションに対し、ロールを使用する
• ロールを使用してアクセス許可を委任する
• アクセスキーを共有しない
• 認証情報を定期的にローテーションする。
• 不要な認証情報の削除
• 追加セキュリティに対するポリシー条件を使用する。
• AWSアカウントのアクティビティの監視

まとめ

AWS IAMはAWSを利用する上でもっとも重要といえる機能です。
本番環境では不必要な権限付与は事故の拡大を招く可能性があるため、IAMの仕組みを理解し、最小権限の原則に則った管理を行うことが大切になります。

今回はIAMのみのまとめでしたが、マルチアカウントで管理する場合はAWS Organizationsの機能であるSCP(Service Control Policy)などを利用した管理も検討する必要があります。

パーミッション・バウンダリーなどは使用したことがないため、機会がありましたら試してみて、ユースケースを模索したいと思います。

参考

• AWS Identity and Access Managementユーザーガイド
• 初心者からマニアまで必読 AWS IAMのマニアックな話
• ポケットスタディ AWS認定 デベロッパーアソシエイト
• IAM Permissions boundary（アクセス権限の境界）で明示的に許可していないアクションでも条件次第で実行できるということを評価論理の流れを眺めて再認識してみた