IAMユーザー、ポリシーまとめ

記事について

AWS初心者が
【AWS Black Belt Online Seminar】AWS Identity and Access Management (AWS IAM) Part1
https://www.youtube.com/watch?v=K7F5yTThynw
を見て内容をまとめたものです。

IAMの概要

AWSリソースをセキュアに操作するために、認証・認可の仕組みを提供するマネージドサービス
（AWSリソース：EC2インスタンス、S3バケット等AWSサービスを利用して生成したオブジェクト）

AWSリソースにアクセスするしくみ

プリンシパル（ユーザー/ロール/アプリケーション）からのリクエストには、
誰が、どんなアクションを、誰に対して、どんな条件下で行うのか、についての情報が載っており、
それをアクセス許可（ポリシー）によって許可/拒否を判断する

IDと認証情報の管理

AWSアカウントのルートユーザー

AWSアカウントを作成したときのメールアドレス/パスワードでサインインするユーザー
そのアカウントの全てのAWSサービスとAWSリソース全てに完全にアクセス権を持つユーザー

！極力ルートユーザーは使用しないこと（IAMユーザーを使用すること）
！ルートユーザーのアクセスキーは削除しておく（初期状態では生成されていない）

アクセスキー

アクセスキーID/シークレットアクセスキーで構成されている
AWS CLI等のプログラムからAWSリソースにアクセスするために使用するもの
EC2, Lambda等AWSサービスからAWSリソースにアクセスする場合は、極力アクセスキーではなくIAMロールを使用する
IAMロールでSecurity Token Service(STS)から取得したトークンは期限があるが、AWS SDKを使うようなケースではでは自動的に取得/再取得が行われる。

！アクセスキーはソースコード、設計書等に埋め込まないこと。

IAMユーザー

AWSで作成するエンティティ（ユーザーまたはアプリケーション）

IAMユーザーを識別する方法

• ユーザーの「フレンドリ名」：ユーザー作成時に指定
  　　（例）"Alice", "Bob"
• ユーザーのARN：AWS 全体でユーザーを一意に識別する必要がある場合に使用
  　　（例）arn:aws:iam::0123456789012:user/Alice
• ユーザーの一意の意識別子：ほとんど見ることはない
  　　（例）AIDAJQABLZS4A3QDU576Q

認証に使用される情報

• コンソールパスワード
• アクセスキー（必要な場合に生成する）

MFA(Multi-Factor Authentication)

特権ユーザーに対してMFAを有効化して、パスワードやアクセスキー認証に追加してセキュリティを強化する
無料のスマホアプリ「Google Authenticator」が良い

アクセス権限の管理

ポリシー

IAMアイデンティティ（ユーザー/ロール/アプリケーション等）やAWSリソースに関連づけることによってアクセス許可を定義することができるオブジェクト
通常、JSONポリシードキュメントでアクセス条件を記述する
「誰が」「どのAWSサービスの」「どのリソースに対して」「どんな操作を」「許可する(許可しない)」、といったことを記述する

ポリシータイプ

• アイデンティティベースのポリシー：IAMユーザー/IAMグループ/IAMロールに関連づけるポリシー

  • 管理ポリシー：IAMエンティティとは独立したポリシー、複数のエンティティにアタッチできる
    • AWS管理ポリシー：AWSが管理しているポリシー、変更不可
    • カスタマー管理ポリシー：ユーザーが作成したポリシー、AWS管理ポリシーで要件を満たせない場合に使用
  • インラインポリシー：単一のIAMユーザ/IAMグループ/IAMロールに直接埋め込む、非推奨

• リソースベースのポリシー：AWSサービスに関連づけるポリシー、単一リソースに関連づいておりインラインポリシーに似ている

ポリシードキュメント

ポリシードキュメントについては以下記事を参考にしました。
https://dev.classmethod.jp/articles/aws-iam-policy/

ポリシードキュメントの主な要素

• Version：ポリシー言語のバージョン、"2012-10-17"が現行バージョン
• Statement：以下要素を含むステートメントブロック
• Effect："Allow"または"Deny"、ステートメントの許可/拒否を指定
• Principal：リソースベースのポリシーにのみ使用、リソースにアクセスするプリンシパルを指定(ARN形式)
• Action：各AWSサービスでサポートされているアクションを指定
• Resource：Actionの対象となるリソースを指定（ARN形式）
• Condition：ポリシーを実行する条件を指定

アイデンティティベースのポリシー

IAMユーザー/グループ/ロールに関連づけるポリシー
例として、以下がAWS管理ポリシーAmazonS3ReadOnlyAccessの内容

AmazonS3ReadOnlyAccess

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:Get*",
        "s3:List*"
      ],
      "Resource": "*"
    }
  ]
}

アイデンティティベースのポリシーではPrincipal（誰が）は指定しない。
記述するまでもなく、このポリシーを関連づけたIAMユーザー/グループ/ロールがPrincipalになるため。
「このポリシーを関連づけたIAMユーザー/グループ/ロール」が「S3」の「全てのリソース」に対して「Get、List」することを「許可する」といった内容になる。

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

AWSリソース（操作を行われるモノ）に関連づけるポリシー
このAWSリソースを誰（Principal）が操作するかを指定する必要がある。
以下、リソースベースのポリシーの例

{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Allow",
    "Principal": {"AWS": "arn:aws:iam::777788889999:user/bob"},
    "Action": [
      "s3:PutObject",
      "s3:PutObjectAcl"
    ],
    "Resource": "arn:aws:s3:::example-bucket/*"
  }
}

「AWSアカウント：777788889999のIAMユーザー：bob」 が 「example-bucket S3バケット配下」に「操作：PutObject、PutObjectAcl」を「許可する」といった内容になる。

IAMロールとポリシーの関係性

どちらもIAMアイデンティティやAWSリソースにアクセス許可を与えるもの
ポリシーはロールに内容されているもの
以下、ポリシー（AmazonS3ReadOnlyAccess、AWSLambdaFullAccess）をロールにアタッチし、
そのロールをEC2にアタッチした場合の図

最小権限を付与する

最小権限からスタートして必要に応じて権限を増やしていく

アクセス権の決定ロジック（同一アカウントの場合）

複数のポリシーが適応された場合のアクセス権の決定ロジック

• アイデンティティベースのポリシー
  　　管理ポリシーとインラインポリシーが設定されている場合、いずれかのポリシーで許可されていれば有効な権限となる（OR）
• アクセス許可の境界
  　　IAMに付与できるアクセス許可の境界範囲内で、アイデンティティベースのポリシーで許可されているものが有効な権限となる（AND）
• リソースベースポリシー
  　　リソースベースポリシーで指定されているPrincipal、もしくはアイデンティティベースポリシーでリソースアクセスを許可しているPrincipalが有効な権限（OR）

アクセス権の決定ロジック（クロスアカウントの場合）

同一アカウントの場合との違いは、リソースベースポリシーへのアクセス許可判定がAND条件であること
他アカウントのリソースアクセスを許可しても、リソース側の許可がないとアクセスできない

IAMグループ

IAMユーザーの集合で、ポリシー管理を間単にするもの
IAMグループに関連付けたポリシーは、所属するIAMユーザーに継承される
IAMグループはアイデンティティ（Principal）ではない