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

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

はじめに

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

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

• Amazon CloudFrontが配信しているコンテンツへ、許可されていない国からの不正アクセス発生
  • 地域制限(地理的ブロック)を使用し、CloudFrontディストリビューション経由で配信しているコンテンツに対し、特定地域のユーザーによるアクセスを回避できる
    • 方法1: CloudFrontの地域制限機能を使用し、国レベルでアクセス制限
      • ディストリビューションに関連するすべてのファイルへのアクセスを制限
    • 方法2: サードパーティーの位置情報サービスを使用し、国レベルより詳細なレベルでアクセス制限
      • ディストリビューションに関連するファイルのサブセットへのアクセスを制限
  • CloudFrontの地域制限機能
    • 承認された国のリストに含まれている国のユーザーのみ、コンテンツへのアクセスを許可
    • ブロックリストにある国のユーザーは、コンテンツへのアクセスを禁止
  • CloudFrontは、サードパーティーのデータベースを使用し、ユーザーの場所を判別
    • IPアドレスと国とのマッピングの正確さは、リージョンによって異なるが、全体的に99.8%正確
  • CloudFrontがユーザーの場所を特定できない場合、ユーザーがリクエストしたコンテンツは提供される
  • 地域制限の仕組み
    • CloudFrontディストリビューションを更新し、コンテンツ配信権限を持つ国を許可リストに追加
    • 許可されていない国からコンテンツへリクエストがあった場合、DNSはそのリクエストを当該国のCloudFrontエッジロケーションにルーティング
    • エッジロケーションがユーザーのディストリビューションを検索
    • ユーザーがコンテンツダウンロードを許可されていないと判断された場合、HTTPステータスコード403(Forbidden)をユーザーに返す
  • オプション
    • ユーザーにカスタムエラーメッセージを返すように、CloudFrontを設定できる
    • リクエストされたファイルに関するエラーレスポンスをキャッシュ可能で、保持時間の長さを指定できる(デフォルトは10秒)
  • 地域制限はディストリビューション全体に適用される
    • コンテンツのある部分に特定制限を適用したい場合、別のCloudFrontディストリビューションを作成するか、サードパーティーの位置情報サービスを使用する必要あり
  • CloudFrontで拒否されたリクエストを特定したい
    • CloudFrontの標準ログ(アクセスログ)を有効にし、sc-status(HTTPステータスコード)の値が403であるログエントリを検索
    • 標準ログだけでは、ユーザーの場所に基づき拒否されたか否かの理由までは判別できない
      • Digital ElementやMaxMindなどサードパーティーの位置情報サービスを利用している場合、アクセスログのc-ip(クライアント IP)列にあるIPアドレスに基づいてリクエストの場所を識別できる

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

• GuardDutyを一時的に無効にしたい
  • GuardDutyコンソールを使用し、GuardDutyを停止または無効化できる
    • サービスの停止中は、GuardDuty対し課金されない
  • GuardDutyを無効または停止する前に、すべてのリージョンのすべてのディテクターからすべてのオプションのデータソースを無効にする必要あり
  • GuardDutyを無効または停止するには、すべてのメンバーアカウントの関連付けを解除または削除する必要あり
  • GuardDutyを停止すると、AWS環境のセキュリティはモニタリングされなくなり、新しい検出結果は生成されない
    • ただし、既存の検出結果は変更されず、GuardDutyの停止によって影響を受けない、再度有効にできる
  • GuardDutyを無効にすると、既存の検出結果とGuardDutyの設定は失われ、復旧できなくなる
    • 既存の検出結果を保存する場合は、GuardDutyを無効にする前にエクスポートする必要あり

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

• リモートのネットワークからVPCに安全に接続したい
  • AWS VPN(Virtual Private Network)を使用し、VPCをリモートネットワークに接続可能
  • 下記VPN接続オプションを使用すると、VPCをリモートネットワークおよびユーザーに接続できる
    • AWS Site-to-Site VPN
      • VPCとリモートネットワーク間で、IPsecおよびVPN接続を作成できる
      • Site-to-Site VPN接続のAWS側は、仮想プライベートゲートウェイまたはトランジットゲートウェイ
        • 自動フェイルオーバーのため、2つのVPNエンドポイント(トンネル)が提供される
      • Site-to-Site VPN接続のリモート側は、カスタマーゲートウェイデバイス
    • AWS Client VPN
      • AWSリソースまたはオンプレミスネットワークに安全にアクセスできる、クライアントベースのマネージドVPNサービス
      • ユーザーが接続時に安全なTLS VPNセッションを確立できるエンドポイントあり
      • クライアントはOpenVPNベースのVPNクライアントを使用し、どこからでもAWSまたはオンプレミスのリソースにアクセスできる
    • AWS VPN CloudHub
      • リモートネットワークが複数ある(複数支社など)場合、仮想プライベートゲートウェイを通じて複数のAWS Site-to-Site VPN接続を作成することで、ネットワーク間で通信できる
    • サードパーティー製ソフトウェア
      • VPNアプライアンス
        • サードパーティー製ソフトウェアのVPNアプライアンスを実行するEC2インスタンスを使用し、リモートネットワークへのVPN接続を作成できる
        • AWSは、サードパーティー製ソフトウェアVPNアプライアンスを提供および維持しない
          • ただし、AWS Marketplaceでパートナーやオープンソースコミュニティが提供する様々な製品を選択できる
    • AWS Direct Connect
      • リモートネットワークからVPCへの専用プライベート接続を作成できる
      • この接続をAWS Site-to-Site VPN接続と組み合わせると、IPsecで暗号化された接続を作成できる

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

• IDベースポリシーとリソースベースポリシー、両方適用されている場合、IAMユーザーのアクセス許可を判断したい
  • IDベースポリシーが、userAにアタッチされている
    • バケットの名前にprotectが含まれているS3バケットへのアクセスをuserAに拒否

  {
      "Version": "2012-10-17",
      "Statement": [
          {
              "Sid": "DenyS3protect",
              "Effect": "Deny",
              "Action": "s3:*",
              "Resource": "arn:aws:s3:::*protect*"
          }
      ]
  }
  

  • リソースベースポリシー(バケットポリシー)が、bucketBにアタッチされている
    • ユーザーuserAのみバケットbucketBへアクセス可

  {
      "Version": "2012-10-17",
      "Statement": [
          {
              "Effect": "Allow",
              "Principal": {
                  "AWS": "arn:aws:iam::123456789012:user/userA"
              },
              "Action": "s3:*",
              "Resource": [
                  "arn:aws:s3:::bucketB/*",
                  "arn:aws:s3:::bucketB"
              ]
          }
      ]
  }
  

  • 最終的にuserAのアクセス許可はいかが
    • 明示的拒否により、バケットmy-protect-bucketへのデータ保存は拒否される
    • 明示的許可により、バケットbucketBへのデータ保存は許可される(二つのポリシーで片方だけ許可されたらOK)
    • 暗黙的拒否により、バケットbucketCへのデータ保存は拒否される(明示的に許可されていないため)

分野5: データ保護

• クライアントからDynamoDBまで、エンドツーエンドのデータ保護を実現したい
  • DynamoDBサーバー側の保管時の暗号化
    • DynamoDBデフォルトの暗号化機能により、ディスクに書き込まれる際、すべてのテーブルが透過的に暗号化される
      • 保管時の暗号化を有効または無効にするオプションはない
    • テーブルへのアクセス時に復号される
    • サーバー側の暗号化により、データはHTTPS接続で転送時に暗号化される
      • DynamoDBエンドポイントで復号された後、DynamoDBに保管される前に再度暗号化される
    • DynamoDB暗号化クライアントとサーバー側暗号化を両方使用できる
      • 暗号化/署名された項目をDynamoDBに送信しても、DynamoDBは項目が保護されているとして認識しない
  • DynamoDB暗号化クライアント
    • DynamoDB暗号化クライアントを用いたクライアント側暗号化により、テーブルデータをDynamoDBに送信する前に暗号化
      • クライアント側の暗号化により、エンドツーエンドソースからDynamoDBストレージまで、転送時および保管時のデータを保護できる
    • DynamoDB暗号化クライアントは、暗号化されていないDynamoDBテーブルデータの暗号化はサポートしない
      • 新しい未入力データベースのみ実装可能
    • DynamoDBにデータ送信する前に、DynamoDBアプリケーションに暗号化機能を追加する必要あり
    • プライマリキー属性やテーブル名などのテーブル項目に署名可能
      • すべてまたは一部テーブル項目の署名により、属性の追加や削除、属性値のスワップなど、項目全体への不正変更を検出できる
    • 暗号化キーの生成および保護方法を選択し、キーを保護できる
      • ユーザーがキーを作成して管理する
      • または、AWS KMSまたはAWS CloudHSMなど暗号化サービスを使用
    • データの保護方法の決定
      • 暗号化マテリアルプロバイダー(CMP)を選択する
        • CMPが、一意キーが生成されるタイミングや、使用する暗号化アルゴリズムおよび署名アルゴリズムなど、使用する暗号化の方法を判断
      • または、独自のものを記述
  • AWS Encryption SDK
    • クライアント側暗号化ライブラリで、汎用データの暗号化および復号に使用
    • 任意タイプのデータを保護できるが、データベースレコードなど構造化データは操作できない
    • DynamoDB暗号化クライアントとは異なり、項目レベルの整合性チェックはできない
      • 属性に基づきプライマリキーの暗号化を回避するロジックはない
    • AWS Encryption SDKとDynamoDB暗号化クライアントとの互換性はない
      • 1つのライブラリで暗号化し、もう1つのライブラリで復号はできない
      • DynamoDBの保管データを暗号化する場合、DynamoDB暗号化クライアントがお勧め

おわりに

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

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