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

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

はじめに

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

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

• AWSリソースに対する意図しない変更が報告された、至急だれがいつ何を実行したか追跡したい
  • AWS CloudTrail Lakeを使用し、CloudTrailが記録したアクティビティに対しSQLクエリを実行することで、インシデント調査を行う
  • リソースへの変更が適切なセキュリティグループやIAMユーザー/IAMロールによって加えられているか確認し、疑わしい変更を追跡

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

• CloudWatchエージェントのログデータがAmazon CloudWatch Logsへ送信されない
  • CloudWatchエージェントが開始されない場合、設定に問題がある可能性あり
    • 設定情報はconfiguration-validation.logファイルにログ記録される
      • Linux: /opt/aws/amazon-cloudwatch-agent/logs/configuration-validation.log
      • Windows: $Env:ProgramData\Amazon\AmazonCloudWatchAgent\Logs\configuration-validation.log
  • CloudWatchエージェントが実行されているか、CloudWatchエージェントのクエリで確認
    • AWS Systems ManagerのRun Commandを使用し、リモートで実行可能
      • コマンドドキュメントリストで、AmazonCloudWatch-ManageAgentの横のボタンをクリック
      • Actionリストで、statusを選択
      • エージェントが実行されている場合、"status":"running"と出力される
    • コマンドラインを使用する場合、チェックできるのはローカルサーバーのみ
      • Linux: sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -m ec2 -a status
      • Windows: & $Env:ProgramFiles\Amazon\AmazonCloudWatchAgent\amazon-cloudwatch-agent-ctl.ps1 -m ec2 -a status
  • CloudWatchエージェントが起動ぜず、EC2リージョンに関するエラーが発生する場合
    • CloudWatchエージェントにEC2エンドポイントへのアクセス権が付与されていない可能性あり
  • CloudWatchエージェントの設定更新後、CloudWatchコンソールに新しいメトリクスやログが表示されない場合
    • 次回エージェント起動時、fetch-configオプションを使用
      • sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a fetch-config -s -m ec2 -c file:configuration-file-path
  • CloudWatchエージェントのログを確認し、エラーメッセージなどのトラブルシューティング情報が含まれていないか確認
    • Linux: /opt/aws/amazon-cloudwatch-agent/logs/amazon-cloudwatch-agent.log
    • Windows: $Env:ProgramData\Amazon\AmazonCloudWatchAgent\Logs\amazon-cloudwatch-agent.log

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

• 従業員が自宅からまたは移動中でも、AWSリソースにアクセスできるようにしたい
  • AWS Client VPNを使用し、すべての従業員が所在位置に関係なく安全で高可用性のVPNアクセスが可能
  • AWS Client VPNは、OpenVPNベースのクライアントを使用し、どこからでもAWSまたはオンプレミスのネットワークに安全にアクセスできるマネージドサービス
  • AWS Client VPN以前のソリューション
    • セルフマネージド型のクライアントベースのVPNソリューション
      • データセンターのハードウェアVPNアプライアンス
      • または、EC2にデプロイしたソフトウェアベースのVPNアプライアンス
    • 課題: 費用、セキュリティ、メンテナンスコスト、VPN高負荷、低可用性など
  • AWS Client VPNの機能
    • 安全な接続
      • OpenVPNクライアントを使用し、あらゆる場所から安全な TLS接続を提供
    • マネージド型サービス
      • AWSマネージドサービスであるため、サードパーティー製のリモートアクセスVPNソリューションをデプロイ/管理不要
    • 高可用性と高伸縮性
      • AWSリソースとオンプレミスリソースに接続しているユーザー数に自動的に対応
    • 認証
      • Active Directoryを使用したクライアント認証、フェデレーション認証、および証明書ベースの認証をサポート
    • きめ細かな制御
      • ネットワークベースのアクセスルールを定義することで、カスタムセキュリティ管理を実装できる
        • Active Directoryグループによる詳細な設定
        • セキュリティグループを使用したアクセス制御
    • 使いやすさ
      • 単一VPNトンネルを使用し、AWSリソースとオンプレミスリソースにアクセスできる
    • 管理性
      • クライアントの接続試行に関する詳細な接続ログ
      • アクティブなクライアント接続管理可能
    • 高度な統合
      • AWS Directory ServiceやVPCなど既存AWSサービスと統合

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

• Amazon S3にサイズが100MBを超えるオブジェクトを安全にアップロードしたい
  • マルチパートアップロードを使用し、単一のオブジェクトをパートのセットとしてアップロード
    • 各パートは、オブジェクトデータの連続する部分で、任意の順序で個別にアップロードできる
    • いずれかのパート送信が失敗しても、他のパートに影響を与えず再送できる
  • ※ マルチパートアップロードの利点
    • スループットの向上
      • パートを並列にアップロードすることで、スループットを向上させることができる
    • ネットワーク問題から迅速に回復
      • パートサイズが小さいほど、ネットワークエラーにより失敗したアップロードを再開する際の影響を最小限に抑えられる
    • オブジェクトアップロードの一時停止と再開
      • オブジェクトの複数のパートを徐々にアップロードできる
      • 終了期限はないが、明示的に完了または停止する必要あり
    • オブジェクトの最終的なサイズが不明な状態でアップロードを開始可能
      • オブジェクト作成中でもアップロード開始できる
  • マルチパートアップロードAPIとアクセス許可
    • マルチパートアップロードの作成
      • オブジェクトへのs3:PutObjectアクション許可
    • マルチパートアップロードの開始
      • オブジェクトへのs3:PutObjectアクション許可
    • パートのアップロード(コピー)
      • ターゲットオブジェクトへのs3:PutObjectアクション許可
      • ソースオブジェクトへのs3:GetObjectアクション許可
    • マルチパートアップロードを完了
      • オブジェクトへのs3:PutObjectアクション許可
    • マルチパートアップロードの中止
      • s3:AbortMultipartUploadアクション許可
      • デフォルトでは、バケット所有者とマルチパートアップロードの開始者に、IAMとバケットポリシーの一部として、アクションの実行が許可される
      • 開始者がIAMユーザーである場合、そのユーザーのAWSアカウントもマルチパートアップロードを停止できる
      • VPCエンドポイントポリシーでは、マルチパートアップロードの開始者は、s3:AbortMultipartUploadアクション許可を自動的に付与されない
    • マルチパートアップロードに含まれるパートをリスト
      • s3:ListMultipartUploadPartsアクション許可
    • バケットに対し進行中のマルチパートアップロードをリスト
      • バケットへのs3:ListBucketMultipartUploadsアクション許可
  • AWS KMS暗号化/復号関連のアクセス許可
    • KMSキーを使用し暗号化を伴うマルチパートアップロードを実行するには
      • キーのkms:Decryptおよびkms:GenerateDataKey*アクション許可
    • IAMユーザー/IAMロールがKMSキーと同じAWSアカウントにある場合
      • キーポリシーで許可付与が必要
    • IAMユーザー/IAMロールがKMSキーと異なるアカウントに属している場合
      • キーポリシーと「IAMユーザー/IAMロール」の両方に許可付与が必要

分野5: データ保護

• S3バケットに対し、AWS KMS(SSE−KMS)を用いたサーバー側暗号化を行っているが、KMSへのリクエストコストを削減したい

  • SSE−KMSでバケットレベルのS3バケットキーを使用し、S3からKMSへのリクエストトラフィックを減らすことにより、KMSへのリクエストコストを最大99%削減できる
    
    ※ 引用元: https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/userguide/bucket-key.html

  • SSE−KMSのS3バケットキーのメカニズム

    • SSE−KMSで暗号化された数百万、数十億のオブジェクトにアクセスするワークロードは、KMSに大量のリクエストを生成する
    • S3バケットキーなしでSSE−KMSを使用しデータを保護する場合、S3はすべてのオブジェクトに対し異なるKMSデータキーを使用する
      • すべてのKMS暗号化対象オブジェクトに対しリクエストが行われるたびにKMSが呼び出される
    • SSE−KMSのS3バケットキーを使用するようにバケットを設定すると
      • KMSによりバケットレベルのS3バケットキーが生成される
      • S3バケットキーは、バケットに追加される新しいオブジェクトの一意データキー作成に使用される
      • S3バケットキーは、S3内で期間限定で使用されるため、S3 からKMSへリクエストを行い、暗号化操作を完了する必要性が軽減される
      • 結果として、S3からKMSへのトラフィックが減少し、少ないコストでKMS暗号化されたS3オブジェクトにアクセスできるようになる

おわりに

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

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