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

認証

認証方法

• パスワード
• アクセスキー
• 多要素認証(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からアクセスする場合
      • アプリケーションでロールARNarn: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:データ保護)