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

##### [前回] [AWS公式資料で挑むSCS認定(38)-こんな時どうする(全分野その15)](https://qiita.com/mingchun_zhao/items/7b7ded45cfcbd91bfedd)

## はじめに

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

## 分野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%削減できる
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2523098/821eda2f-1d64-0eac-f6a8-882eeb40034c.png)
※ 引用元: 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)](https://qiita.com/mingchun_zhao/items/2a58a411f1b022c75c5c)