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を使用

おわりに

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

[次回] AWS公式資料で挑むSCS認定(23)-こんな時どうする(分野5:データ保護)