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

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

はじめに

今回も引き続き、「こんな時どうする」集の作成です。

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

• CloudFrontが配信するコンテンツへの不正アクセスが報告された、コンテンツへのアクセスを制御するためリクエストにヘッダーを挿入してからオリジンに転送したい
  • AWS Lambdaの拡張機能Lambda@Edgeを使用し、エッジでリクエストにヘッダー挿入可能
    • Lambda@Edgeは、CloudFrontの配信コンテンツに対しカスタマイズ関数を実行するコンピューティングサービス
    • 米国東部(バージニア北部)リージョンでNode.jsまたはPython関数を作成し、ビューワーに近いAWSロケーションで実行できる
    • サーバーをプロビジョニング/管理する必要ない
    • 自動スケーリングし、オリジンサーバーの代わりにビューワー最寄りのAWSロケーションでリクエストを処理することで、レイテンシーが大幅に軽減され、ユーザーエクスペリエンスが向上
  • CloudFrontディストリビューションをLambda@Edge関数に関連付けることで、CloudFrontエッジロケーションでリクエストとレスポンスがインターセプトされる
  • Lambda関数がトリガーされるCloudFrontイベント
    • CloudFrontがビューワーからリクエストを受信したとき(ビューワーリクエスト)
    • CloudFrontがリクエストをオリジンに転送する前(オリジンリクエスト)
    • CloudFrontがオリジンからレスポンスを受信したとき(オリジンレスポンス)
    • CloudFrontがビューワーにレスポンスを返す前(ビューワーレスポンス)
  • Lambda@Edgeの用途
    • 関数でヘッダーまたは認証トークンを検査し、CloudFrontがリクエストをオリジンに転送する前に、コンテンツへのアクセスを制御するヘッダーを挿入できる
    • Cookieを検査しURLを書き換え、A/Bテスト用に異なるバージョンのサイトをユーザーに表示できる
    • CloudFrontは、デバイスに関する情報が含まれているUser-Agentヘッダーを確認し、ビューワーが使用しているデバイスに基づいて、異なるオブジェクトをビューワーに返せる
      • デバイスの画面サイズに基づいて異なるイメージを返す
      • Refererヘッダーの値を考慮する関数を作成し、最も低い解像度のイメージをボットに返せる
    • Cookieを確認し、その内容に応じて、Lambda関数にてリクエストを変更し異なる結果を返せる
    • Lambda関数は、CloudFrontのビューワーリクエストイベントまたはオリジンリクエストイベントの発生時にHTTPレスポンスを生成できる
    • Lambda関数は、外部リソースのネットワーク呼び出しを実行し、ユーザー認証情報を確認したり、追加のコンテンツを取得してレスポンスをカスタマイズできる

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

• Amazon GuardDutyで、EC2インスタンスのDNSログを監視したい
  • EC2インスタンスでAWS DNSリゾルバーを使用している場合(デフォルト設定)、GuardDutyは内部のAWS DNSリゾルバーを介して、リクエストと応答に関するDNSログにアクセスし処理できる
  • OpenDNSやGoogleDNSなど別のDNSリゾルバー、または独自のDNSリゾルバーを使用する場合、GuardDutyはそのデータソースのデータにアクセスできない
  • GuardDutyを有効にすると、独立データストリームからDNSログの分析がすぐに開始される
    • このデータストリームは、Route 53リゾルバークエリログ記録機能を通じて提供されるデータとは別もの
      • Route 53リゾルバークエリログ記録機能の設定は、GuardDutyの解析には影響しない

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

• 複数のブランチオフィス間で、安全簡単なリモート通信を実現したい
  • 複数AWS Site-to-Site VPN接続がある場合、AWS VPN CloudHubを使用し、安全なSite-to-Site通信を提供できる
    • リモートサイトを有効にし、VPCとの通信のみならず、サイト間の相互通信が可能
  • VPN CloudHubは、VPCの有無にかかわらず使用できるシンプルなハブアンドスポークモデルで動作
    • 複数のブランチオフィスと既存のインターネット接続があり、リモートオフィス間でプライマリ接続またはバックアップ接続を実現可
  • サイト間でIPアドレス範囲の重複は許可されない
  • VPN CloudHubアーキテクチャと構成要素
    
    ※ 引用元: https://docs.aws.amazon.com/ja_jp/vpn/latest/s2svpn/VPN_CloudHub.html
    • 単一の仮想プライベートゲートウェイを作成
    • ゲートウェイのパブリックIPアドレスを持つ複数のカスタマーゲートウェイを作成
      • カスタマーゲートウェイの一意のボーダーゲートウェイプロトコル(BGP)自律システム番号(ASN)を使用する必要あり
    • 各カスタマーゲートウェイから仮想プライベートゲートウェイに動的ルーティングされるSite-to-Site VPN接続を作成
    • 仮想プライベートゲートウェイにサイト固有のプレフィックス(10.0.0.0/24、10.0.1.0/24など)をアドバタイズするように、カスタマーゲートウェイデバイスを設定
      • これらのルーティングアドバタイズメントが受信され、各BGPピアに再アドバタイズされることで、サイト間でのデータの送受信か可能になる
      • この設定は、Site-to-Site VPN接続のVPN設定ファイルでネットワークステートメントを用いて行う
    • サブネットルートテーブルのルートを設定し、VPCのインスタンスがサイトと通信できるようにする
      • ルートテーブルに集約ルート(10.0.0.0/16など)を設定できる
        • カスタマーゲートウェイデバイスと仮想プライベートゲートウェイ間より具体的なプレフィックスを使用
  • 仮想プライベートゲートウェイへAWS Direct Connectにて接続するサイトをAWS VPN CloudHubに含めることも可能
    • 例えば、本社でVPCへのAWS Direct Connect接続を確立しながら、ブランチオフィスでVPCへのSite-to-Site VPN接続を使用できる
    • ブランチオフィス間で、AWS VPN CloudHubを使用し、相互にデータ送受信したり、本社とデータ送受信できる

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

• AWSアカウント管理者が担当していたIAMユーザー作成業務を、ユーザーAに委任したい
  • アクセス許可の境界を使用し、他のユーザーへ責任を委任できる
  • 例: IAMユーザーの作成業務を以下の制限付きでユーザーAに委任
    • IAMを使って管理ユーザー、グループ、グループロール、ポリシーを作成できない
    • S3バケットへのアクセスは拒否される
    • EC2インスタンスインスタンスBにアクセスできない
    • アクセス許可の境界ポリシーを削除できない
  • 委任に必要なアカウント管理者のタスク
    • 管理ポリシー1を作成し、AWSアカウントの新しいIAMユーザーに対するアクセス許可の境界を定義
      • 管理者は、新しいユーザーのアクセス許可の上限を決める必要あり
        • 複数AWSサービスへのフルアクセスをユーザーに許可する
        • 新しいユーザーがAWSサービスへのアクションは、ユーザーにアタッチされているアクセス許可ポリシーによってのみ制限される
        • IAMコンソールで制限されている、自己管理アクセスを許可する
          • ユーザーはコンソールにサインインした後、パスワードを変更できるが、初期パスワードは設定できない
          • これを許可するには、*LoginProfileアクションを追加
    • 管理ポリシー2を作成し、アクセス許可の境界としてユーザーAに割り当てる
      • ユーザーAへのアクセス許可の上限を定義、ただし、管理ポリシー1を使用してアクセス許可の境界を設定することを条件とする
    • 管理ポリシー3を作成し、アクセス許可ポリシーとしてユーザーAにアタッチ
      • ユーザーAにIAMユーザーを作成する権限を付与するが、管理ポリシー2のアクセス許可の境界を条件とする
      • "iam:PermissionsBoundary":"arn:aws:iam::アカウントID:policy/管理ポリシー2"
    • ユーザーAに新しい責任と制限を伝える

分野5: データ保護

• AWS KMSカスタマー管理キーをS3でのみ使用できるように制限したい
  • AWS KMSのポリシー条件として、kms:ViaService条件キーを使用し、指定AWSサービスからのリクエストに制限
  • 1つのkms:ViaService条件キーに1つ以上のサービスを指定でき、KMSキーリソースオペレーションをオペレーションとして指定
    • KMSキーリソースオペレーションを識別するには、アクションとリソースの表で、オペレーションのResources列のKMSキー値を探す
  • ポリシー例: IAMユーザーに代わって、リクエストがEC2またはRDSから送信された場合のみ、カスタマー管理キーを指定されたアクションで使用できるように許可する
    • "Effect": "Allow"
    • "Principal": {"AWS":"arn:aws:iam::アカウントID:user/ユーザー"}
    • "Action": [
      • "kms:Encrypt",
      • "kms:Decrypt",
      • "kms:ReEncrypt*",
      • "kms:GenerateDataKey*",
      • "kms:CreateGrant",
      • "kms:ListGrants",
      • "kms:DescribeKey"]
    • "Resource": "*"
    • "Condition": {"StringEquals": {"kms:ViaService": ["s3.us-west-2.amazonaws.com"]
  • kms:ViaService条件キーを使用する場合、サービスがAWSアカウントのプリンシパルに代わりリクエストを発行
    • プリンシパルの代わりにサービスがカスタマー管理キーを使用できるようにするため、プリンシパルは統合されたサービスに以下アクセス許可を付与する必要あり
      • KMSキーを使用するアクセス許可
      • AWS KMSと統合されたサービスを使用するアクセス権限
  • すべてのAWS管理キーは、キーポリシーでkms:ViaService条件キーを使用し、KMSキーを作成したサービスからリクエストされた場合のみ、KMSキーの使用を許可できる
    • AWS管理キーのキーポリシーは、GetKeyPolicyオペレーションを使用し表示
  • kms:ViaService条件キーはIAMポリシーとキーポリシーのステートメントで有効
    • 指定サービスは、AWS KMSと統合され、かつkms:ViaService条件キーをサポートする必要あり

おわりに

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

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