AWS公式資料で挑むSCS認定(22)-こんな時どうする(分野4:ID及びアクセス管理)

##### [前回] [AWS公式資料で挑むSCS認定(21)-こんな時どうする(分野3:インフラストラクチャのセキュリティ)](https://qiita.com/mingchun_zhao/items/1eb8ca9bd126fd36d705)

## はじめに

引き続き「こんな時どうする」集、
今回は「分野4: ID及びアクセス管理」です。

## 「分野4: ID及びアクセス管理」基本知識のおさらい

### AWS APIエンドポイント

- AWSへのすべての操作は必ずAPIアクセスポイントを経由(APIインタフェース)
    - 目的はアクセスポイント数を制限し、モニタリングするため
- APIリクエストの認証/認可は、IAMで行う
- APIリクエストのログ記録は、AWS CloudTrailで行う
    - 認証状況、アクセスしたリソース情報など

#### AWS APIの保護

- APIリクエストに対し、署名を使ってチェック
    - ID有効性確認
        - 有効なアクセスキーを持つ正しいユーザからか
    - 中間者攻撃などによる改ざん
        - 転送中に改ざんされていないかハッシュ値を使ってチェック
        - ※ 中間者攻撃とは、二者間の通信に第三者が割り込み、盗聴・介入を行う攻撃手法
    - リプレイ攻撃を防止
        - リクエストに付与されたタイムスタンプを使用
        - ※ リプレイ攻撃とは、ログイン時に送受信される認証データを盗聴し、その認証データを用いて不正アクセスを行う攻撃手法

### 認証

#### 認証方法

- パスワード
- アクセスキー
- 多要素認証(MFA)
- 一時認証トークン
    - 有効期限付きのアクセスキーID/シークレットアクセスキー/セキュリティトークンで構成
    - AWS Security Token Service(AWS STS)により動的生成
    - IAMロールによる権限委任で使用される

### 認可

#### アクセス許可

- アクセス許可の優先順位
    - ①明示的拒否
    - ②明示的許可
    - ③暗黙的拒否
    
#### アクセスポリシー

##### ポリシーの種類
- IDベースポリシー(IAMポリシー)
    - AWS管理ポリシー
    - カスタマー管理ポリシー
    - インラインポリシー
- リソースベースポリシー
    - インラインポリシーのみ
        - Amazon S3 バケットポリシー
        - IAMロールの信頼ポリシー
            - IAMロールの権限移譲を行うためのポリシー
- AWS IAMアクセス許可の境界
    - IAMユーザーとロールの範囲を限定し、権限の昇格を防ぐ
- AWS Organizationsサービスコントロールポリシー (SCP)
    - 組織のアクセス許可の管理に使用できる組織ポリシーの一種
- アクセスコントロールポリシー (ACL)
    - リソースへのアクセス可否設定リスト。例:
        - Amazon S3のバケットのACL
        - Amazon VPCのサブネットのACL
- セッションポリシー
    - AWS CLI、AWS APIを使用して、ロールまたはフェデレーティッドユーザーを引き受ける場合に高度なセッションポリシーを渡す
    - IDベースポリシーでセッションに付与するアクセス許可を制限するのみ、新しいアクセス許可を付与はしない

##### ポリシー条件の評価
- 複数条件を指定した場合
    - 論理 AND 演算で評価
- 単一条件を指定した場合
    - 複数キー
        - 論理 AND 演算で評価
    - 1つのキーに複数の値
        - 論理 OR 演算で評価

#### ポリシーのセキュリティ

- IAMエンティティには、必要最小限のアクセス権限のみ付与
- ユーザアカウントよりは、まずロールとフェデレーションを使用
- インラインポリシーよりは、まずカスタマーポリシーを使用
- Notprincipalエレメントなどで、ポリシーサイズを削減

### AWS Directory Service

- Simple AD
    - 小規模環境で使用するフルマネージドディレクトリサービス
    - AWS上に独立した新規ディレクトリ(ドメイン)を作成
    - パワーユーザーをサポートしない
        - パワーユーザーとは、IAMユーザーやグループの管理を除き、全てのAWSサービスにフルアクセスできるユーザー
- AD Connector
    - 既存のディレクトリサービスへの接続
    - 接続先は、オンプレミスまたは VPC 上のドメインを指定
    - 多要素認証(MFA)をサポート
- AWS Managed Microsoft AD
    - 大量ディレクトリをサポートするフルマネージドディレクトリサービス
    - AWS上にMicrosoft ADが存在する
    - 既存ディレクトリ(ドメイン)との信頼関係をサポート
- Amazon Cognito
    - ユーザープールを使用し、ユーザーディレクトリを作成・維持
    - モバイルまたはウェブアプリケーションにサインアップとサインインを追加
    - SaaSアプリケーションの認証で使用

### AWSアカウントのルートユーザを保護

- ルートユーザより、まずIAMユーザに最小権限を割り当て使用
- 強力なパスワードを
- MFAを有効に
- 特殊ケースを除き、ルートアクセスキーを作成しない

## 「分野4: ID及びアクセス管理」の「こんな時どうする」

- 同じAWSアカウントの複数IAMユーザに、S3バケットへのアクセスを許可したい
    - リソースベースポリシーを作成
    - 配列を使ってプリンシパルに複数対象ユーザを記述
```
"Principal" : { 
  "AWS": [ 
    "userA",
    "userB" 
  ]
}
``` 
- AWSアカウント`accountA`のS3バケットへ、別のAWSアカウント`accountB`のIAMユーザ`userB`からのアクセスを許可したい
    - `accountA`で、アクセスポリシー`policyA`作成
        - S3バケットの読み書きを許可するポリシー
    - `accountA`で、ロール`roleA`を作成
        - ロールタイプは[別のAWSアカウント]、`accountB`と信頼関係を確立
        - ロールのアクセス許可に`policyA`を割り当てる
    - `accountB`で、`userB`にロールの切り替えを許可するアクセス許可を追加
        - `roleA`に対する`AssumeRole`アクションを許可するインラインポリシー
    - `accountB`で、`userB`のロールを切り替え、S3バケットにアクセスする
        - AWS Management Consoleからアクセスする場合
            - [Switch Role] (スイッチロール) ページから
        - CLIからアクセスする場合
            - `aws sts assume-role --role-arn "arn:aws:iam::accountA:role/roleA" --role-session-name "userB-test"`
        - APIからアクセスする場合
            - アプリケーションでロールARN`arn:aws:iam::accountA:role/roleA`に対し`AssumeRole`を呼び出す

- 特定EC2インスタンスのみAPIリクエストを発行できるようにしたい
    - API実行権限が付与されたIAMロールを状況に応じて複数作成
    - EC2インスタンスにIAMロールをアタッチしアクセス許可を付与
    - ※ EC2に同時にロールを複数割り当てることはできない
    - ※ EC2インスタンスへのIAMロールアタッチは、EC2インスタンスプロファイルを介して行われる

- FacebookまたはGoogleアカウントを使用して、S3バケットに直接アクセスしたい
    - ウェブIDフェデレーション(OpenID Connect(OIDC)互換のIdP)とAmazon Cognitoを使用(アプリケーションにセキュリティ認証情報を埋め込まなくて済む)
    - ユーザーはFacebookまたはGoogleアカウントを使用しサインインし、シークレットIDトークンを受け取る
    - IDトークンをAmazon Cognitoに問い合わせCognitoトークンを取得
    - CognitoトークンをAWSの一時的セキュリティ認証情報に変換
    - 一時的セキュリティ認証情報を使って、S3バケットに直接アクセス
    - AWSリソースへのアクセス許可はマッピングされたIAMロールにより制御
    - ※ おまけ: 既存のアプリで認証実装済みで、Amazon Cognitoを使用しない場合
        - コードを記述し、ウェブIdPにサインインし、認証トークンを取得
        - AssumeRoleWithWebIdentity APIを呼び出し、認証トークンを一時的なAWSセキュリティ認証情報と交換

- オンプレミスのLDAP認証を使用して、S3バケットに直接アクセスしたい
    - パターン1: S3バケットへのアクセス権を持つIAMロールを使用する場合
        - LDAP認証を行い、ユーザーに紐付けられたIAMロール名を取得
        - AWS STSを呼び出し、そのIAMロールを引き受ける
        - 一時的認証情報を使用してS3バケットにアクセス
    - パターン2: S3バケットへのアクセス権を持つIAMフェデレーティッドユーザを使用する場合
        - カスタムIDブローカーを作成。その機能は、
            - LDAP認証を行い、AWS STSを呼び出し、IAMフェデレーティッドユーザーの認証情報を取得
        - カスタムIDブローカーを呼び出し、IAMフェデレーティッドユーザーの認証情報を取得 
        - 一時的認証情報を使用してS3バケットにアクセス
    - ※ LDAP認証情報を使用して直接IAMへのログインは不可

- ID管理に、既存のオンプレミス`Microsoft Active Directory`を継続使用したい
    - AD Connectorを使用

- CORS(Cross−Origin Resource Sharing)設定を行ったS3バケットにアクセスできない
    - バケットにCORS設定が行われているか確認
    - S3が受信したすべてのリクエストを取り込み、設定されたCORSルールと一致するか確認

## おわりに

「こんな時どうする」集の「分野4: ID及びアクセス管理」パートでした。
次回は「分野5: データ保護」の「こんな時どうする」です。
お楽しみに。

##### [次回] [AWS公式資料で挑むSCS認定(23)-こんな時どうする(分野5:データ保護)](https://qiita.com/mingchun_zhao/items/2eed867d1841d4591c09)