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

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

## はじめに

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

## 分野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リソースにアクセス
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2523098/084efa2f-b4b2-0847-179e-d5a6e08c494d.png)
※ 引用元: 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にピアリング接続
        ![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2523098/0fd7244c-439d-0e59-5821-bd98f4b83f9b.png)
        ※ 引用元: 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)](https://qiita.com/mingchun_zhao/items/e6de42ff0bb4b25cdd48)