AWS公式資料で挑むSCS認定(30)-こんな時どうする(全分野その7)

[前回] AWS公式資料で挑むSCS認定(29)-こんな時どうする(全分野その6)

はじめに

「こんな時どうする」自作により、理解が徐々に深まるきがします。
この調子で続けます。

分野1: インシデント対応

• Amazon CloudFrontオリジンのS3バケットに保存したプライベートコンテンツへ、S3 URL経由で疑わしいアクセスが発生した

  • S3バケットのオリジンアクセスアイデンティティ(OAI)を設定し、Amazon S3 URLからファイルへの直接アクセスを禁止、署名付きCloudFront URLを使用したアクセスのみ許可
  • 設定手順
    • OAIと呼ばれる特別なCloudFrontユーザーを作成し、CloudFrontディストリビューションに関連付ける
    • バケット内のファイルの読み取りアクセス許可をオリジンアクセスアイデンティティに付与
    • 他のすべてのユーザーから、Amazon S3 URLを使用してファイルを読み取るアクセス許可を削除
  • ※ 署名付きURLを使用するためにこの手順を実行する必要はないが推奨される

• Amazon CloudFrontカスタムオリジンのプライベートコンテンツへ、HTTP経由で疑わしいアクセスが発生した

  • プライベートHTTPサーバー(カスタムオリジン)のカスタムヘッダーを設定し、ファイルへのアクセスを制限
    • CloudFrontは標準のHTTP(または HTTPS)リクエストを使用し、カスタムオリジンからファイルを取得
    • カスタムヘッダーを使用しコンテンツへのアクセスを制限することで、ファイルへの直接アクセスを禁止し、署名付きCloudFront URLを使用したアクセスのみ許可
  • 設定手順
    • CloudFrontを設定し、オリジンのカスタムヘッダーがオリジンに転送されるようにする
    • ディストリビューションでビューワープロトコルポリシーを設定し、ビューワーからCloudFrontへアクセス時HTTPS使用が要求されるようにする
    • ディストリビューションでオリジンプロトコルポリシーを設定し、CloudFrontがリクエストをオリジンに転送する際、ビューワーと同じプロトコルを使用するように要求
    • カスタムオリジンでアプリケーションを更新し、CloudFrontで設定したカスタムヘッダーを含むリクエストのみ受け入れるようにする
  • ※ ビューワープロトコルポリシーとオリジンプロトコルポリシーの組み合わせにより、カスタムヘッダーが転送中に暗号化される
    • ただし、CloudFrontがオリジンに転送するカスタムヘッダーを定期的にローテーションすることを推奨
  • ※ 署名付きURLを使用するためにこの手順を実行する必要はないが推奨される

分野2: ログとモニタリング(監視)

• Amazon CloudWatch Logsへの呼び出しをすべて記録したい
  • CloudWatch Logsと統合されたAWS CloudTrailを使って、CloudWatchコンソールからの呼び出しと、CloudWatch Logs API オペレーションへのコード呼び出しなど、すべてのアクションを記録
  • CloudTrailで収集された情報を使用し、CloudWatch Logsに対するリクエスト、リクエスト元のIPアドレス、リクエスト送信者、リクエスト日時などの詳細を確認できる
  • CloudTrailの証跡を作成し、CloudWatch Logsからの収集イベントをAmazon S3バケットへ継続的に配信可能
    • 証跡未設定の場合でも、CloudTrailコンソールの[Event history(イベント履歴)]で最新のイベントを確認できる

分野3: インフラストラクチャのセキュリティ

• 企業のActive Directoryユーザーがシングルサインオン(SSO)を使用し、AWS Management Consoleにアクセスできるようにしたい

  • 企業ネットワークとAWSリージョンの間にAWS Direct Connect接続を作成
    • ※ AWS Direct Connectは、AWSへの専用ネットワーク接続サービス
      • 標準イーサネット光ファイバケーブルを介して、企業ネットワークをAWS Direct Connectロケーションに接続
      • ネットワークトラフィックは転送中にAWSグローバルネットワークに残り、公開インターネットにアクセスしない
  • Active Directoryの外部IDプロバイダー(IdP)とIAMサービス間の信頼関係を確立する
    • フェデレーティッドユーザーがAWSにアクセスできるように、AWS Management ConsoleとSAML 2.0フェデレーションを行うためのIAMロールを作成
    • IAMロールを使用し、コンソールでタスクを実行するユーザーアクセス権限を付与

• 企業のActive Directoryユーザーが、簡単にAWS Management Consoleにアクセスできるようにしたい

  • AWS Directory Connectorを使用
    • ※ AD Connectorは、ディレクトリリクエストをオンプレミスのMicrosoft Active Directoryへリダイレクトするディレクトリゲートウェイ
    • AD Connectorは、既存のオンプレミスのアクティブディレクトリをAWSに簡単に接続
  • ディレクトリユーザーに対し、AD認証情報によるAWS Management Consoleへのアクセスを有効にする
    • AWSサービスおよびリソースにアクセスできるように、IAMロールをディレクトリメンバーに割り当てることで、アクセス権を付与
    • ディレクトリメンバーへコンソールアクセスを付与する前に、ディレクトリにアクセスURLを割り当てる必要あり
  • ※ AD ConnectorはAD推移的信頼をサポートしない
    • AD ConnectorとオンプレミスのADドメインは1対1の関係
    • 認証対象のADフォレスト内の子ドメインを含む各オンプレミスドメインごとに、一意のAD Connectorを作成する必要あり

• 企業の各拠点から、AWS Direct Connectを使用しAWSリソースにアクセスする。拠点間で簡単にデータ送信を行いたい

  • AWS Direct Connectにリンクされている各拠点間で、SiteLinkを使用し最短パスでデータ送信できる

分野4: アイデンティティ(ID)及びアクセス管理

• AWSアカウントAのS3バケットへ、別のAWSアカウントBから安全にアクセスできるようにしたい
  • AWSリソースへのアクセス権を第三者に付与(委任)する方法として、
    • 外部IDをIAMロールの信頼ポリシーに指定することで、ロールを引き受けられるユーザーを指定できる
  • 設定手順
    • アカウントBで、一意の外部IDを作成しAWSアカウント番号と一緒にアカウントAに提供
    • アカウントAで、S3バケットへのアクセス権をアカウントBに付与するIAMロールを作成
    • IAMロールの信頼ポリシーで、アカウントBがIAMロールを引き受けることができるように設定
      • Principal要素にアカウントBのアカウント番号を指定
        • "Principal": {"AWS": "アカウントBのAWS Account ID"}
      • Condition要素で、ExternalIdコンテキストキーを使って、アカウントBの一意の外部IDと一致するかチェック
      • "Condition": {"StringEquals": {"sts:ExternalId": "アカウントBの外部ID"}}
    • IAMロールのアクセス許可ポリシーで、アカウントBにS3バケットへのアクセス許可を付与
    • IAMロールのAmazonリソースネーム(ARN)をアカウントBに提供
    • アカウントBはS3バケットにアクセスするため、AWS sts:AssumeRole APIを下記パラメータを指定し呼び出す
      • 引き受けるIAMロールのARN
      • 外部IDに対応するExternalIdパラメータ
    • リクエスト元がアカウントBで、ロールARNと外部IDが正しい場合、リクエストが成功し、一時的なセキュリティ認証情報が提供される
    • アカウントBはその認証情報を使用し、アカウントAのIAMロールが許可しているS3バケットにアクセスできる
  • ※ 外部IDを使用する理由
    • 外部IDにより、アカウント所有者が特定環境においてのみロールを引き受けることができるように制限可能
    • 外部IDの最も重要な機能は、「混乱した代理」問題の防止と対処
      • IAMロール名が他のアカウントやユーザにより推測された場合、リソースにアクセスできてしまう
      • 代理アクセスによる正しいアクセスか否か分からず混乱が生じる

分野5: データ保護

• Amazon CloudFrontキャッシュ内のプライベートコンテンツを保護したい
  • 署名付きURLまたは署名付きCookieを使用するように設定
  • 署名付きURLまたは署名付きCookieの署名について
    • 使用されるキー
      • ClouFrontキーペアのプライベートキーを使用し、一部がハッシュ化され、署名が行われる
    • 使用されるアルゴリズム
      • RSA-SHA1を使用(CloudFrontでは他のアルゴリズムを使用できない)
  • 設定方法
    • 署名付きURLまたは署名付きCookieの使用が要求されるようにCloudFrontを設定
    • 署名付きURLを作成し認証されたユーザーに配信する、または認証されたユーザーの署名付きCookieを設定するSet-Cookieヘッダーを送信するようなアプリケーションを開発
    • 署名付きURLまたは署名付きCookieを作成時に、次の制限を指定可能
      • 最終日時、この日時以降URLが無効に
      • (オプション)URLが有効になる日時
      • (オプション)コンテンツへのアクセスに使用可能なIPアドレスまたはアドレス範囲

おわりに

「こんな時どうする」の追記でした。
次回も続きます、お楽しみに。

[次回] AWS公式資料で挑むSCS認定(31)-こんな時どうする(全分野その8)