AWS公式資料で挑むSCS認定(22)-こんな時どうする(分野4:ID及びアクセス管理)
[前回] AWS公式資料で挑むSCS認定(21)-こんな時どうする(分野3:インフラストラクチャのセキュリティ)
はじめに
引き続き「こんな時どうする」集、
今回は「分野4: ID及びアクセス管理」です。
「分野4: ID及びアクセス管理」基本知識のおさらい
AWS APIエンドポイント
- AWSへのすべての操作は必ずAPIアクセスポイントを経由(APIインタフェース)
- 目的はアクセスポイント数を制限し、モニタリングするため
- APIリクエストの認証/認可は、IAMで行う
- APIリクエストのログ記録は、AWS CloudTrailで行う
- 認証状況、アクセスしたリソース情報など
AWS APIの保護
- APIリクエストに対し、署名を使ってチェック
- ID有効性確認
- 有効なアクセスキーを持つ正しいユーザからか
- 中間者攻撃などによる改ざん
- 転送中に改ざんされていないかハッシュ値を使ってチェック
- ※ 中間者攻撃とは、二者間の通信に第三者が割り込み、盗聴・介入を行う攻撃手法
- リプレイ攻撃を防止
- リクエストに付与されたタイムスタンプを使用
- ※ リプレイ攻撃とは、ログイン時に送受信される認証データを盗聴し、その認証データを用いて不正アクセスを行う攻撃手法
- 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
を割り当てる
- ロールタイプは[別のAWSアカウント]、
-
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
を呼び出す
- アプリケーションでロールARN
- AWS Management Consoleからアクセスする場合
-
-
特定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バケットにアクセス
- カスタムIDブローカーを作成。その機能は、
- ※ LDAP認証情報を使用して直接IAMへのログインは不可
- パターン1: S3バケットへのアクセス権を持つIAMロールを使用する場合
-
ID管理に、既存のオンプレミス
Microsoft Active Directory
を継続使用したい- AD Connectorを使用
おわりに
「こんな時どうする」集の「分野4: ID及びアクセス管理」パートでした。
次回は「分野5: データ保護」の「こんな時どうする」です。
お楽しみに。
[次回] AWS公式資料で挑むSCS認定(23)-こんな時どうする(分野5:データ保護)
Author And Source
この問題について(AWS公式資料で挑むSCS認定(22)-こんな時どうする(分野4:ID及びアクセス管理)), 我々は、より多くの情報をここで見つけました https://qiita.com/mingchun_zhao/items/2c9d60dc58a58749f807著者帰属:元の著者の情報は、元のURLに含まれています。著作権は原作者に属する。
Content is automatically searched and collected through network algorithms . If there is a violation . Please contact us . We will adjust (correct author information ,or delete content ) as soon as possible .