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

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

## はじめに

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

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

- ユーザー認証情報を悪用した不正アクセスが報告された、至急セキュリティインシデント調査を行い、侵害による影響確認と対策を実施したい
    - AWS CloudTrail Lakeを使用し、CloudTrailで記録されたAWSサービスのアクティビティをクエリし、インシデント調査を行う
    - ※ AWS CloudTrail Lakeの機能
        - ユーザーアクティビティと影響を受けるリソースをクエリおよび分析し、悪意のあるユーザーの特定やアクセス許可のベースライン化など対処
        - SQLで使い慣れた複数属性のクエリエクスペリエンスを提供し、複数の同時クエリをスケジュールおよび処理できる
        - CloudTrailログを他の場所に移動/取り込む必要がないため、データ信頼性を維持、ログのスロットリング(流量制御)も対処不要
        - 大量の構造化ログを処理するように最適化されているため、ほぼリアルタイムのレイテンシーが提供される
    - ※ CloudTrail Lakeで調査可能なイベントカテゴリ
        - CloudTrailによって収集された任意のイベントカテゴリに対しCloudTrail Lakeを有効にできる
        - イベントカテゴリ
            - `CreateBucket`や`TerminateInstances`などコントロールプレーンアクティビティをキャプチャする管理イベント
            - `GetObject`や`PutObject`などデータプレーンアクティビティをキャプチャするデータイベント
    - ※ CloudTrail Lakeの開始時間とデータ保持期間
        - 機能を有効にした後、ほぼすぐ発生するアクティビティのクエリを開始できる
        - 最大7年間のイベント保持期間を選択でき、いつでもそのデータをクエリできる、個別の証跡サブスクリプションは必要ない

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

- 使用しているSalesforceのSaaSサービスに対し、セキュリティ監視を行いたい
    - Amazon EventBridgeを使用し、SaleseForceのイベントを取得/管理
        - ※ Amazon EventBridgeはサーバーレスイベントバスサービスで、「ユーザー独自のアプリケーション、サードパーティーSaaSプラットフォーム、AWSサービス」に接続しイベントを受信でき、リアルタイムデータのストリームを配信できる
            - 取得したイベントデータをAWS Lambdaなどのターゲットにルーティングし、すべてのデータソースにリアルタイムで反応する疎結合かつ分散型のイベント駆動型アプリケーションアーキテクチャを構築可能
        - EventBridgeは、Amazon CloudWatch Eventsと同じCloudWatch Events APIを使用する
            - 既存のCloudWatch Eventsユーザーは、新しいEventBridgeコンソールとCloudWatch Eventsコンソールで、バス、ルール、およびイベントにアクセスできる

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

- CIDRブロックが重複する3つのVPCで相互にファイル共有を行いたい
    - 以下の場合、VPCピア接続設定はサポートされない
        - 重複するCIDRブロック
        - 推移的なピアリング接続
            - `VPC A`と`VPC B`間、`VPC A`と`VPC C`の間、にVPCピアリング接続が設定されていても、`VPC A`経由で`VPC B`から`VPC C`へパケットを直接ルーティングすることはできない
        - 「ゲートウェイまたはプライベート接続」経由のエッジツーエッジルーティングが既に存在する場合
            - 社内ネットワークに対するVPN接続またはAWS Direct Connect接続
            - インターネットゲートウェイ経由のインターネット接続
            - NATデバイス経由のプライベートサブネットのインターネット接続
            - AWSサービスへのゲートウェイVPC エンドポイント(S3へのエンドポイントなど)
            - (IPv6)ClassicLink接続
                - EC2-Classicインスタンス(IPv6未サポート)と別VPCのインスタンス間で、IPv6通信用のVPCピアリング接続はできない(IPv4通信用は接続可能)
    - AWS Transit Gatewayを使用し、「VPC、AWSアカウント、オンプレミスネットワーク」を単一のゲートウェイに簡単に接続できる
        - 中央ハブを介してネットワークが簡素化され、複雑なピア接続関係がなくなる
        - クラウドルーターとして利用できる(新しい接続はそれぞれ1回だけ行われる)
        - インターネットを介さずリージョン間ピア接続でき、データを自動的に暗号化し転送できる
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2523098/d5b83ac5-5355-0587-f887-edad9fcf6ce5.png)
※ 引用元: [AWSホワイトペーパーAmazon Virtual Private Cloud Connectivity Options](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/aws-vpc-connectivity-options.pdf)


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

- 複数AWSアカウントに対し、API実行時MFAを強制したい
    - AWS Organizationsで、組織のアクセス許可管理用の組織ポリシー「サービスコントロールポリシー(SCP)」を使用
    - SCPは、組織のすべてのアカウントで使用可能な最大アクセス許可を一元的に制御し、アカウントが組織のアクセスコントロールガイドラインに従っているか確認できる
    - AWS Organizationsの二つの機能セットで、SCPを使用できるのは
        - 「すべての機能」を有効にした組織: 使用可
        - 「一括請求機能」を有効にした組織: 使用不可
    - ※ 注意: 組織アカウントのアクセス制御は、SCPだけでは不十分
        - SCPは、管理アカウントのIAMユーザーやIAMロールには影響を与えず、組織内のメンバーアカウントにのみ影響を与える
        - SCPは、アカウント管理者がIAMユーザー/IAMロールに委任するアクションに対し、ガードレールを定義するか制限を設定するのみ
        - アカウント管理者は、IDベースポリシーまたはリソースベースポリシーを「IAMユーザー/IAMロール/アカウントのリソース」に割り当てることで、アクセス許可を付与する必要あり
        - 最終的なアクセス許可は、SCPによって許可されるアクセスとIAM/リソースベースのポリシーによって許可されるアクセスのインターセクション
    - SCPを使用し、IAMユーザーまたはロールがアクション(例えばEC2インスタンス停止)を実行する際、多要素認証(MFA)を強制する設定例
        - `"Effect": "Deny"`
        - `"Action": "ec2:StopInstances"`
        - `"Resource": "*"`
        - `"Condition": {"BoolIfExists": {"aws:MultiFactorAuthPresent": false}}`

## 分野5: データ保護

- Amazon S3バケットで`MFA Delete`を有効に設定したい
    - バージョニングを行うS3バケットに対し`MFA Delete`を有効に設定することで、認証情報を悪用した不正アクセスに対処でき、セキュリティをさらに強化できる
        - 削除アクションを開始したユーザーに、MFAデバイスの物理的所有を証明するMFAコードを要求
        - 削除アクションに対するセキュリティレイヤーを追加することで、バケットの偶発的な削除を防ぐ
    - 以下のバケット操作で、MFA認証が強制され、2つ以上の認証形式の組み合わせが要求される
        - 特定のオブジェクトバージョンを削除
        - バケットのバージョニング状態を変更
    - 認証方法
        - AWSセキュリティ認証情報
            - AWSアカウントに関連付けられているEメールアドレス、AWSアカウントID、パスワード、シークレットアクセスキー
        - `有効なシリアル番号`、`[ ](スペース)`、`承認済み認証デバイスの6桁コード`、三つを連結した文字
            - 認証コードは、ハードウェアデバイスまたは仮想MFAデバイスを使用し生成
    - ※ 注意
        - `MFA Delete`を有効化できるのは、バケットを作成したAWSアカウントであるバケット所有者(ルートアカウント)のみ
        - バージョニングを有効化できるのは、バケット所有者(ルートアカウント)と、すべての承認済みIAMユーザー
    - ※ S3ライフサイクル設定で`MFA Delete`を使用することはできない
    - ※ AWS Management Consoleを使用して`MFA Delete`を有効にすることはできない
        - AWS CLIまたはAPIを使用する必要あり
    - ※ `MFA Delete`設定
        - バケットのバージョニング状態を保存するためのバージョニングサブリソースに保存される
        ```
        <VersioningConfiguration xmlns="http://s3.amazonaws.com/doc/2006-03-01/"> 
            <Status>VersioningState</Status>
            <MfaDelete>MfaDeleteState</MfaDelete>  
        </VersioningConfiguration>
        ```
    - AWS CLIを使用し、バケットのバージョニングと`MFA Delete`を有効にする方法
    ```
    aws s3api put-bucket-versioning --bucket バケット名 --versioning-configuration Status=Enabled,MFADelete=Enabled --mfa "SERIAL 認証コード"
	```

## おわりに

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

##### [次回] [AWS公式資料で挑むSCS認定(37)-こんな時どうする(全分野その14)](https://qiita.com/mingchun_zhao/items/861124e3b54d3862c83b)