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

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

はじめに

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

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

• 不審なIPアドレスからの、特定クエリ文字列が含まれたリクエストをブロックしたい
  • AWS WAFのWeb ACLでトラフィック情報のログ記録を有効に設定し、事前定義ルールによりリクエストをブロック
  • AWS WAFはWebアプリケーションファイアウォールで、ウェブリクエストを許可/ブロック/監視(カウント)するルールを設定し、ウェブアプリケーションを攻撃から保護
    • ルール条件にはIPアドレス、HTTPヘッダー、HTTP本文、URI文字列、SQLインジェクション、クロスサイトスクリプトが含まれる
  • AWS WAFがウェブサイトやアプリケーションを保護する方法
    • Amazon CloudFrontと統合
      • AWS外のカスタムオリジンにホストされたウェブサイトも保護可
    • Application Load Balancer(ALB)と統合
  • Web ACLのロギング設定
    • ログフィルタリングを設定し、保持/ドロップするウェブリクエストを指定
      • ルールアクションとWebリクエストラベルでフィルタリング可能
    • ログレコードから機微な情報が含まれたフィールドをXXXのようにマスキング可能
  • Web ACLログ保存先
    • 保存先として設定されたAmazon Kinesis Data Firehoseにログ送信
      • AWS WAFは、Kinesis Data FirehoseのHTTPSエンドポイントを介しストレージにログ送信
  • ログ記録に必要なアクセス許可
    • iam:CreateServiceLinkedRole
    • firehose:ListDeliveryStreams
    • wafv2:PutLoggingConfiguration

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

• AWS CloudTrailの大量ログからAPI操作の傾向を分析したい
  • Amazon Athenaを使用し、CloudTrailログに基づきアクティビティを分析する
  • AWS CloudTrailは、AWSアカウントのAWS APIコールとイベントを記録するサービス
    • ログにコンソールを含めたAWSサービスに対し発行されたAPIコールの詳細が記載される
    • CloudTrailは暗号化されたログファイルを、Amazon S3に保存
  • Athenaクエリを使用し、CloudTrailログに基づきアクティビティ傾向を識別、属性(ソースIPアドレスやユーザーなど)でカテゴライズ
    • Athenaは、ログファイルのLOCATIONを指定し、Amazon S3のログファイルを直接クエリできる
      • 方法1: CloudTrailコンソールからCloudTrailログファイルのテーブルを作成
      • 方法2: AthenaコンソールでCloudTrailログファイルのテーブルを手動で作成

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

• ALB(Application Load Balancer)のターゲットのEC2インスタンスを保護したい
  • ALBでAWS WAFを使用し、インターネットに公開されているロードバランサーおよび内部ロードバランサーを保護できる
  • ALBは、OSIモデルの第7層のアプリケーションレイヤーで機能
  • ALBは、クライアントからの単一通信先
    • 受信トラフィックを複数AZの複数ターゲットに分散し、アプリケーション可用性向上
  • ALBのリスナー
    • ALBに1つ以上のリスナーを設置可
    • 指定プロトコルとポートを使用したクライアントからの接続リクエストを、事前定義ルールによりチェック
  • ALBのターゲットグループ
    • 指定されたプロトコルとポート番号を使用し、1つ以上の登録済みターゲットにリクエストをルーティング
      • デフォルトのルーティングアルゴリズムはラウンドロビン
    • 1つのターゲットを複数のターゲットグループに登録可
  • ALB作成時、指定可能なサブネットタイプ
    • AZ(アベイラビリティーゾーン)
      • 少なくとも2つのAZのサブネットを選択する必要あり
      • それぞれのサブネットは、異なるAZに属する必要あり
      • ロードバランサーのAZサブネットごとにCIDRブロックを最低でも/27ビットマスクにする
      • 各サブネットにつき最低8個空きIPアドレスを用意
    • ローカルゾーン
      • ロードバランサーでAWS WAFを使用できない
      • Lambda関数をターゲットとして使用できない
    • Outpost
      • オンプレミスのデータセンターにOutpostをインストール/設定要
      • OutpostとAWSリージョンの間に信頼できるネットワーク接続が必要
      • ロードバランサーノードのOutpostに2つのインスタンスが必要

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

• 別のAWSアカウントから、自分のAWSアカウントのS3バケットにアップロードされたオブジェクトにアクセスできない
  • 背景知識
    • デフォルトのオブジェクト所有権を持つ既存S3バケットで、オブジェクト所有者はオブジェクトをバケットにアップロードした別のAWSアカウントになる
      • これら既存バケットで、オブジェクト所有者がオブジェクトにアクセス許可を明確に付与しないかぎり、バケット所有者はオブジェクトにアクセスできない
    • S3 Object Ownership設定を使用し、バケット所有者は自分のバケットにアップロードされたオブジェクトの所有権を管理できる
      • デフォルトで、新しく作成されたすべてのS3バケットで、bucket owner enforced設定が有効になる
        • バケット所有者はバケット内のすべてのオブジェクトのオブジェクト所有者になる
      • バケットとそのオブジェクトのACLはすべて無効になる
      • バケット所有者には、下記設定が推奨される
        • IAMおよびバケットポリシーを介してアクセス許可を管理する
        • 新規/既存のバケットにbucket owner enforced設定を使用
  • 解決方法
    • バケットACLを無効にできる場合、バケットのオブジェクト所有権を取得するコマンド
      • aws s3api put-bucket-ownership-controls --bucket my-bucket --ownership-controls 'Rules=[{ObjectOwnership=BucketOwnerEnforced}]'
    • バケットACLを無効にできない場合、オブジェクト所有者は以下いずれかの方法を用いて、オブジェクトACLでバケット所有者にフルコントロールを付与
      • putまたはcopy操作
        • aws s3api put-object --bucket my_BUCKET --key dir-1/my_images.tar.bz2 --body my_images.tar.bz2 --acl bucket-owner-full-control
      • 単一のオブジェクトのコピーオペレーション
        • aws s3api copy-object --bucket my_BUCKET --key source_DOC-EXAMPLE-BUCKET/myobject --acl bucket-owner-full-control
          -または、 aws s3 cp s3://source_BUCKET/myobject s3://destination_BUCKET/ --acl bucket-owner-full-control
      • 複数オブジェクトのコピーオペレーション
        • aws s3 cp s3://source_BUCKET/ s3://destination_BUCKET/ --acl bucket-owner-full-control --recursive
      • オブジェクトがバケットに追加された後
        • aws s3api put-object-acl --bucket destination_DOC-EXAMPLE-BUCKET --key keyname --acl bucket-owner-full-control
    • バケットポリシーを使用し、別のアカウントによってバケットにアップロードされたすべてのオブジェクトACLをbucket-owner-full-controlに設定するように強制できる
      • オブジェクト所有者に対し、バケット所有者へフルコントロールを付与することを要求できる

分野5: データ保護

• 4KBを超えるデータを暗号化したい
  • エンベロープ暗号化を使用する必要あり
    • AWS KMSに直接送信し暗号化できるデータは最大4KB
  • エンベロープ暗号化のパフォーマンスメリット
    • エンベロープ暗号化でネットワーク転送が必要なのは、ちいさなデータキーのみでネットワーク負荷が低い
      • AWS KMSで直接データを暗号化する場合、データそのものをネットワーク経由で送信する必要あり
    • データキーは、暗号化を行うAWSサービスまたはローカルアプリケーションで使用される
      • データブロック全体をAWS KMSに送信しないため、ネットワークレイテンシーが発生しない
  • AWS KMSと統合されたAWSサービスおよびクライアント側のツールキットは、エンベロープ暗号化を使用しデータ保護
    • AWS KMSがAWSサービスまたはローカルアプリケーションで暗号化するため使用されるデータキーを生成
    • データキー自体は、KMSのカスタマー管理キーで暗号化され、AWS KMSによるデータキーの保持や管理は行われない
    • AWSサービスでデータが暗号化され、暗号化されたデータキーのコピーは、暗号化されたデータと一緒に保存される
    • データ復号する場合、KMSキーを使用しデータキーを復号するようAWS KMSにリクエスト
    • リクエストしているユーザーが、KMSキーの復号権限を付与されている場合、AWSサービスはAWS KMSから復号されたデータキーを受信
    • AWSサービスでデータ復号され、プレーンテキストで返される
    • ※ KMSキーの使用リクエストは、すべてAWS CloudTrailに記録される

おわりに

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

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