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

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

はじめに

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

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

• EC2インスタンスに不正侵入が報告された、実行中のすべてのプロセスを確認したい
  • AWS Systems Manager(旧SSM)のFleet Manager機能を使用し、コンソールベースでインスタンスのプロセスを確認
  • ※ Fleet Managerは、IT管理者によるリモートサーバー管理作業の合理化とスケールを支援
    • インスタンス上のプロセスに対し、表示/管理/リソース消費量評価/開始/停止、など操作可能
    • ファイルシステムの探索、ログ管理、パフォーマンスカウンター、ユーザー管理など一般的な管理者タスクを実行
    • サーバーにリモート接続することなく、AWSとオンプレミスの両方から、実行されているインスタンスを管理できる

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

• CloudTrailから取得されたAWSアカウントのアクティビティをAmazon SNS通知したい
  • CloudTrailをCloudWatch Logsと統合し、CloudWatch LogsのAmazon SNS通知機能を使用
  • ※ CloudTrailとCloudWatch Logsの統合を有効にする方法
    • IAMロールを作成し、CloudWatch Logsログストリームにイベントを配信権限を付与
    • CloudTrailコンソールでCloudWatch LogsロググループとIAMロールを指定
      • AWS SDKまたはAWS CLIを使用して統合を有効にすることも可能
    • これで統合が有効になり、CloudTrailの取得イベントが指定されたCloudWatch LogsロググループのCloudWatch Logsログストリームに送られる

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

• VPCとS3バケット間の通信をAWSネットワーク内に制限したい(インターネットを介さず)

  • S3接続用にVPCエンドポイントを作成し、Amazon S3 DNS名を使ってS3リソースにアクセス
    
    ※ 引用元: https://docs.aws.amazon.com/ja_jp/vpc/latest/privatelink/vpce-gateway.html

  • ※ エンドポイントポリシー

    • デフォルトで、VPC内の任意のユーザーまたはサービスから、任意のAWSアカウントの認証情報による、S3リソースへのアクセスを許可
      • VPCが関連付けられているアカウントとは別のAWSアカウントのS3リソースも含まれる

  • ※ エンドポイントを介したS3へのアクセスを許可/拒否する際、IAMポリシーまたはバケットポリシーでaws:SourceIp条件は使用できない

    • 理由は、VPC CIDRブロックは重複または同じになる場合があり、VPC IPv4 CIDR範囲(プライベートIPv4アドレス範囲)からのアクセスは許可されていない
    • アクセス制御方法
      • ルートテーブルを使用し、エンドポイント経由でS3リソースにアクセスできるインスタンスを制御
      • バケットポリシーの場合、特定エンドポイントまたは特定VPCへのアクセスを制限できる

  • ※ エンドポイントはクロスリージョンのリクエストをサポートしない

    • 必ずバケットと同じリージョンでエンドポイントを作成する必要あり
      • バケットの場所はS3コンソールまたはget-bucket-locationコマンドを使用
    • AWS CLIを使用しS3へリクエストを行う場合、デフォルトリージョンをバケットと同じリージョンに設定するか、リクエストで--regionパラメータを使用

• 同じAWSアカウントに存在し、CIDRブロックが重複しない、3つのVPCで相互にファイル共有を行いたい

  • フルメッシュ設定で3つのVPCをピアリング接続
    • VPC間で制限なしで相互にリソースを共有する必要がある場合、フルメッシュ設定を使用できる
    • 各VPCのルートテーブルは、該当するVPCピアリング接続を指し、接続先VPCのCIDRブロック全体にアクセス
  • 設定例
    • VPC AはVPCピアリング接続pcx-aaaabbbbによりVPC Bにピアリング接続
    • VPC AはVPCピアリング接続pcx-aaaaccccによりVPC Cにピアリング接続
    • VPC BはVPCピアリング接続pcx-bbbbccccによりVPC Cにピアリング接続
      
      ※ 引用元: https://docs.aws.amazon.com/ja_jp/vpc/latest/peering/peering-configurations-full-access.html#three-vpcs-full-access

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

• AWSアカウントAから別のAWSアカウントBにあるAmazon API GatewayのプライベートREST APIにアクセスしたい
  • インターフェースVPCエンドポイントを使用
  • 設定手順
    • アカウントAで、VPCにインターフェイスエンドポイントを作成
      • 考慮事項
        • 異なるAZ(アベイラビリティーゾーン)で複数サブネットを選択することで冗長性を高める
        • プライベートDNSを有効にすると、パブリックDNSまたはプライベートDNSを使用しプライベートREST APIに接続可能
          • 注意: インターフェイスVPCエンドポイントのプライベートDNSを有効にすると、VPCからAPI GatewayのパブリックAPIへはアクセスできなくなる
        • セキュリティグループは、次のいずれかからの「TCPポート443、インバウンドHTTPS」トラフィックを許可するルールが必要
          • VPCのIPアドレス範囲
          • VPCの別セキュリティグループ
    • インターフェイスエンドポイントのVPCエンドポイントIDを取得
      • プライベートREST APIの作成と設定の際に必要
      • 例: vpce-xxxxxxxxxxxxx
    • インターフェイスエンドポイントの公開DNS名を取得
      • 例: vpce-xxxxxxxxxxxxx-yyyyy.execute-api.region.vpce.amazonaws.com
    • アカウントBで、API GatewayのプライベートREST APIを作成
      • [エンドポイントタイプ] は[プライベート] に設定
      • VPCエンドポイントIDは、上述のインターフェイスエンドポイントIDを指定
      • インターフェイスエンドポイントをプライベートREST APIに関連付けると、API Gatewayは新しいAmazon Route 53エイリアスレコードを生成する、これをプライベートAPIのアクセスに使用
    • インターフェイスエンドポイントへAPI呼び出しを許可するため、プライベートREST APIのリソースポリシーを設定
      • [リソースポリシー]の例
        • ※注 vpce-xxxxxxxxの部分は、上述のインターフェイスエンドポイントID
        • Statement1
          • "Effect": "Deny"
          • "Principal": "*"
          • "Action": "execute-api:Invoke"
          • "Resource": "execute-api:/*/*/*"
          • "Condition": {"StringNotEquals": {"aws:sourceVpce":"vpce-xxxxxxxxx"}
        • Statement2
          • "Effect": "Allow"
          • "Principal": "*"
          • "Action": "execute-api:Invoke"
          • "Resource": "execute-api:/*/*/*"
    • プライベートREST APIのメソッドをセットアップ
      • / resourceノードの下のドロップダウンリストで、[指定なし]を選択
      • [/ - ANY - Setup]ペインの[統合タイプ]で、[モック]を選択
        • モック統合は到達したすべての要求に応答するもので、テストに役立つ
    • プライベートREST APIをデプロイ
      • [ステージエディター]ペインで、プライベートAPIの呼び出しURLと共に、メッセージ「プライベートDNSが有効となっている場合は、次のURLを使用してください:」の内容をメモ
    • アカウントAからプライベートREST APIを呼び出す
      • アカウントAで、インターフェイスエンドポイントと同じVPCでEC2インスタンス起動
      • EC2インスタンスのコマンドラインから、curlコマンドを使用し、アカウントBのプライベートREST APIを呼び出す。呼び出し方法:
        • プライベートDNS名を使用
        • Route 53エイリアスを使用
        • ホストヘッダー付きのパブリックDNS名を使用、
        • x-apigw-api-idヘッダーを含むパブリックDNS名を使用
    • コマンドの出力を確認
      • API Gatewayへの接続が成功すると200 OKレスポンスを返される

分野5: データ保護

• S3バケットファイルを誤って削除しないように保護したい
  • AWS S3で、ファイルの誤削除を防ぐバージョニング機能を有効に設定
    • バージョニングは、ファイルごとにバージョンIDを付与し、ファイルを上書き/削除するときに元のファイルを保持
    • ただし、バージョニングを有効にしても、バージョンIDを指定し削除されてしまう可能性あり
  • S3 MFA Delete機能でセキュリティ強化しデータ保護
    • S3 MFA Deleteは、バージョニング機能のオプション
      • バージョンIDを指定しないファイル操作(作成/変更/削除)は通常とおり、バージョンIDを指定した削除操作のみ、MFAデバイスによる認証を必須とする
      • バケット所有者は、以下の操作で追加の認証が必要
        • バケットのバージョニング状態を変更する
        • オブジェクトバージョンを完全に削除する

おわりに

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

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