AWS公式資料で挑むSCS認定(52(最終回))-こんな時どうする(全分野その29)

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

## はじめに

本日のSCS認定試験、おかげさまで無事合格できました。
ゴールは「AWSの魔法使いになること」で、資格獲得ではない、
と自分に言い聞かせながらも、
試験終了時表示された`合格おめでとう`には感慨深いものがありました。

## 試験について、3点情報共有です
- 公式資料の基本知識をしっかり理解できていれば合格ラインに到達可能
- アクセス許可ポリシーの問題が厄介でした(が、これも公式資料の範疇)
    例えば、本連載で過去取り上げた内容
    - [AWS Lambda関数のデータをAmazon CloudWatch Logsにロギングさせたい](https://qiita.com/mingchun_zhao/items/d4e6cf1651d52523fe65#%E5%88%86%E9%87%8E2-%E3%83%AD%E3%82%B0%E3%81%A8%E3%83%A2%E3%83%8B%E3%82%BF%E3%83%AA%E3%83%B3%E3%82%B0%E7%9B%A3%E8%A6%96)
    - [AWS KMSカスタマー管理キーをS3でのみ使用できるように制限したい](https://qiita.com/mingchun_zhao/items/d3bf57f54d0f2dbbf329#%E5%88%86%E9%87%8E5-%E3%83%87%E3%83%BC%E3%82%BF%E4%BF%9D%E8%AD%B7)
    - [AWS Lambdaで使用する環境変数を保護したい](https://qiita.com/mingchun_zhao/items/d8edf10fe216f0cd2480#%E5%88%86%E9%87%8E5-%E3%83%87%E3%83%BC%E3%82%BF%E4%BF%9D%E8%AD%B7)
- 試験開始30分前に必ずチェックインすること
    - システムテスト、身分証撮影、室内チェックなど
    - もろもろありバタバタする羽目に。。。

## 最終回となりますが、「こんな時どうする」集です

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

- S3にホストされた静的ウェブサイトをCloudFrontで公開しているが、不正アクセスが報告された
    - オリジンアクセスアイデンティティ(OAI)を使用し、CloudFrontにより配信されるS3バケットコンテンツに、ユーザーが直接アクセスできないようにする
        - OAIは、特別なCloudFrontユーザーで、ディストリビューションに関連付ける
        - S3に必要な設定
            - CloudFrontがOAIを使用しバケットにアクセスできるように、S3バケットのアクセス許可を設定
            - S3バケットへのダイレクトURLアクセスを拒否するように設定
    - S3でホストされている静的ウェブサイトを公開する際、CloudFrontディストリビューションのデプロイ方法
        - OAIによりアクセス制限されたオリジンとして、REST APIエンドポイントを使用
        - 匿名(パブリック)アクセスを許可し、ウェブサイトのエンドポイントをオリジンとして使用
        - アクセスがRefererヘッダーで制限されたオリジンとして、ウェブサイトのエンドポイントを使用
        - AWS CloudFormationを使用し、REST APIエンドポイントをオリジンとしてデプロイし、OAIとCloudFrontを指すカスタムドメインを用いてアクセスを制限
    - オリジンとしてS3エンドポイントタイプを使用し、CloudFrontディストリビューションを設定する手順
        - オリジンとしてREST APIエンドポイントを使用し、OAIを用いてアクセスを制限
        - S3コンソールを使ってバケットを作成し、ウェブサイトファイルをアップロード
            - バケットで静的ウェブサイトホスティングを有効にする必要はない
            - 静的ウェブサイトホスティング機能のウェブサイトエンドポイントではなく、バケットのREST APIエンドポイントを使用
        - CloudFrontウェブディストリビューションを作成
            - `Origin Domain`: 作成したバケットを選択
            - `S3バケットアクセス`: OAIを使用(バケットはCloudFrontのみアクセス可)
            - `Origin Access Identity`: 新しいOAIを作成
            - `バケットポリシー`: バケットポリシーを更新
            - ウェブサイトにはSSL(HTTPS)を使用
                - HTTPSでカスタムドメインを使用するには、`カスタムSSL証明書`を選択
                - カスタムドメインを使用していない場合でも、ディストリビューションの`cloudfront.net`ドメイン名でHTTPSを使用できる
                - ※ 重要: ディストリビューションに代替ドメイン名(CNAME)を入力した場合、CNAMEは選択したSSL証明書と一致する必要あり
                - ※ S3静的ウェブサイトエンドポイントを使用する場合、CloudFrontとS3間の接続はHTTP経由のみ
                    - HTTPSを使用するには、オリジンにS3 REST APIエンドポイントを設定

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

- VPCフローログのレコードにフィールドを追加したい
    - フローログを削除してから、必要な設定を使って新しくフローログを作成する必要あり
        - フローログ作成後に、下記のような設定変更やフローログレコード形式変更はできない
            - 異なるIAMロールをフローログに関連付けたり
            - フローログレコードのフィールドを追加または削除したり
    - フローログにおける、他の制限事項
        - EC2-Classicプラットフォームにあるネットワークインターフェイスのフローログを有効にすることはできない
            - ClassicLinkを使用し、VPCにリンクされたEC2-Classicインスタンスが含まれる
        - ピアVPCがアカウントにない限り、VPCとピアリング接続されたVPCのフローログを有効にすることはできない
        - ネットワークインターフェイスに複数IPv4アドレスがある場合
            - トラフィックがセカンダリプライベートIPv4アドレスに送信されても、フローログのdstaddrフィールドにはプライマリプライベートIPv4アドレスが表示される
                - 元の送信先IPアドレスをキャプチャするには、pkt-dstaddrフィールドを含むフローログを作成
            - ネットワークインターフェイスとの間でトラフィックが送受信される場合、フローログのsrcaddrフィールドとdstaddrフィールドには常にプライマリのプライベート IPv4アドレスが表示される
                - パケットの送信元または送信先をキャプチャするには、pkt-srcaddrフィールドとpkt-dstaddrフィールドを含むフローログを作成
        - ネットワークインターフェイスがNitroベースのインスタンスにアタッチされている場合、指定した最大集約間隔に関係なく、集約間隔は常に1分以下になる
        - フローログで、以下トラフィックの種類において、IPトラフィックはキャプチャされない
            - Amazon DNSサーバーに接続したときにインスタンスによって生成されるトラフィック
                - 独自のDNSサーバーを使用する場合は、そのDNSサーバーへのすべてのトラフィックが記録される
            - Amazon Windowsライセンスのアクティベーション用にWindowsインスタンスによって生成されたトラフィック
            - インスタンスメタデータ用に169.254.169.254との間を行き来するトラフィック
            - Amazon Time Sync Serviceの169.254.169.123との間でやり取りされるトラフィック
            - DHCPトラフィック
            - ミラートラフィック
            - デフォルトVPCルーターの予約済みIPアドレスへのトラフィック
            - エンドポイントのネットワークインターフェイスとNetwork Load Balancerのネットワークインターフェイスの間のトラフィック

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

- 大量のVPCにまたがるアプリケーションを、ルートテーブルを更新する手間なく、構築/デプロイしたい
    - AWS Transit Gatewayを中心的なハブとして使用
    - AWS Transit Gatewayのユースケース
        - 集中型ルーターとして使用
            - すべてのVPC、AWS Direct Connect、およびAWS Site-to-Site VPNの接続に対し、集中型ルーターとして設定できる
        - 共有サービスを使用する分離されたVPC構成で、独立したルーターとして使用
            - ルートとアタッチメントが変わる可能性がある場合、複数トランジットゲートウェイより高い柔軟性を提供
        - ピア接続
        - 一元的な発信ルーティング
        - アプライアンスVPC
    - 構成例
    ![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2523098/12fd2983-f73f-f682-0b2c-8b4acaf69593.png)
    ※ 引用元: https://docs.aws.amazon.com/ja_jp/vpc/latest/tgw/transit-gateway-isolated-shared.html
    - ルーティング
        - VPC A、VPC B、VPC C、およびVPC Dのルートテーブル
            - 各VPCに、2つのエントリを持つルートテーブル
                - 最初のエントリ
                    - VPCのローカルで、IPv4ルーティングのデフォルトエントリ
                    - このエントリによって、このVPC内のインスタンスが相互に通信可能
                - 2番目のエントリ
                    - 他のすべてのIPv4サブネットトラフィックをトランジットゲートウェイにルーティングする
                    ```
                    送信先         ターゲット
                    10.1.0.0/16    ローカル
                    0.0.0.0/0      tgw-id
                    ```
        - トランジットゲートウェイルートテーブル
            - 2つのルートテーブル
                - VPC用
                - VPN接続および共有サービスVPC用
                ```
                送信先         ターゲット              ルートタイプ
                10.99.99.0/24  VPN接続のアタッチメント  伝播済み
                10.4.0.0/16    VPC Dのアタッチメント    伝播済み
                ```
        - VPNアタッチメントおよび共有サービスVPC(VPC D)アタッチメントのルートテーブル
            - 各VPCアタッチメントを指すエントリにより、VPN接続および共有サービスVPCからその他VPCへの通信が可能
            ```
            送信先        ターゲット              ルートタイプ
            10.1.0.0/16   VPC Aのアタッチメント   伝播済み
            10.2.0.0/16   VPC Bのアタッチメント   伝播済み
            10.3.0.0/16   VPC Cのアタッチメント   伝播済み
            10.4.0.0/16   VPC D のアタッチメント  伝播済み
        - カスタマーゲートウェイのBGPテーブル
            - 次のVPC CIDRが含まれる
                - 10.1.0.0/16
                - 10.2.0.0/16
                - 10.3.0.0/16
                - 10.4.0.0/16

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

- IAMポリシーを使って、複数KMSキーへのアクセス制御を同時に行いたい
    - KSMキーのアクセス制御可能なポリシー
        - キーポリシー(必須)
        - Grant(権限)(任意)
        - VPCエンドポイントポリシー(任意)
        - IAMポリシー(任意)
    - IAMポリシーを使用し、KMSキーへのアクセスを制御するには
        - KMSキーのキーポリシーが、IAMポリシーを使用するアクセス許可をアカウント(root)に付与する必要あり
    - VPCエンドポイントを介しAWS KMSにアクセスする場合
        - VPCエンドポイントポリシーを使用し、AWS KMSリソースへのアクセスを制限可能
        - 特定AWSアカウントのプリンシパルのみ、カスタマー管理キーへアクセスできるように許可できる
    - IAMポリシーを使用し、AWS KMSオペレーションへのアクセスを制御する方法
        - IAMポリシーは、任意のAWS KMSオペレーションへのアクセスを制御できる
        - キーポリシーと異なり、IAMポリシーは同時に複数KMSキーへのアクセス制御、複数AWSサービスのオペレーションに対するアクセス制御が可能
        - IAMポリシーは、特定KMSキーを含まないため、キーポリシーで制御できないオペレーション(CreateKeyなど)へのアクセスを制御する場合便利
    - キーポリシーでAWSアカウントへのアクセスを許可し、IAMポリシーを有効にする方法
        - KMSキーを付与するAWSアカウントに、KMSキーへのフルアクセスを付与
            - リソースベースポリシーと異なり、KMSキーポリシーはアカウントまたはそのユーザーに対し、明示的な許可ステートメントを含める必要あり
                - これにより、アカウントはIAMポリシーを使用し、IAMユーザーとロールにKMSキーへのアクセスを許可できる
                - この許可がないと、キーへのアクセスを許可するIAMポリシーは無効となるが、キーへのアクセスを拒否するIAMポリシーは依然として有効
        - キーポリシーで、KMSキーへIAMアクセス許可を設定できるようにするステートメント
            - プログラムで作成されたKMSキーのデフォルトキーポリシーの全文である
                - AWS KMSコンソールで作成されたKMSキーの、デフォルトキーポリシーの最初ポリシーステートメントでもある
            ```
            {
              "Sid": "Enable IAM policies",
              "Effect": "Allow",
              "Principal": {
                "AWS": "arn:aws:iam::111122223333:root"
              },
              "Action": "kms:*",
              "Resource": "*"
            }
            ```
            - 対象AWSアカウントに、KMSキーに対するすべてのアクション`kms:*`を許可
            - プリンシパルとして、アカウントプリンシパル(AWSアカウントとその管理者)を指定した場合
                - AWSアカウントのIAMユーザーまたはロールに対し、IAMポリシーを用いて、 キーポリシーで委譲された`kms:*許可`を付与できるようになる
        - キーを制御する許可をアカウントプリンシパル(ルートユーザーを含む削除できないアカウント管理者)に付与するもう一つの利点
            - キーが管理不能になるリスクが軽減される
                - たとえば、KMSキーへのアクセスを1人のユーザーだけに付与するキーポリシーを作成した場合
                    - そのユーザーを削除すると、キーが管理不能になる
                    - KMSキーへのアクセスを取り戻すためには、AWSサポートに連絡しなければならない
            - IAMのベストプラクティスは、緊急時を除き、アカウントルートユーザーで操作することは推奨されていない
                - ただし、KMSキーへのアクセス権を持つ他のすべてのユーザーおよびロールを削除した場合、アカウントルートユーザーで操作する必要あり

## 分野5: データ保護

- ELB(Elastic Load Balancing)とクライアント間の通信を保護したい
    - ロードバランサーとクライアント間で、SSL/TLSセッションによるトラフィック暗号化が可能
        - ALB(Application Load Balancer)の場合、HTTPSリスナーを作成し、接続暗号化可能
    - ロードバランサーを作成するときにリスナーを定義し追加できる
        - リスナーとは接続リクエストをチェックするプロセス
    - ロードバランサーがHTTPSリスナーを使用するには、SSL/TLSサーバー証明書(X.509証明書)を少なくとも1つデプロイする必要あり
        - ロードバランサーはフロントエンド接続を終了しターゲットにリクエストを送信する前に、サーバー証明書を使用しクライアントからのリクエストを復号
            - 証明書とは、認証機関(CA)によって発行された識別用デジタル形式
            - 証明書には、認識用情報、有効期間、パブリックキー、シリアル番号と発行者のデジタル署名が含まれる
        - ロードバランサーで使用する証明書を作成するときに、ドメイン名を指定する必要あり
    - AWS Certificate Manager(ACM)を使用しロードバランサーの証明書を作成することが推奨される
        - ACMは、2048ビット/3072ビット/4096ビットのキー長のRSA証明書およびすべてのECDSA証明書をサポート
        - ACMはELBと統合し、ロードバランサーに証明書をデプロイできる
            - SSL/TLSツールを使用し署名証明書リクエスト(CSR)を作成し、CAからCSR署名を取得し証明書を発行し、ACMにこの証明書をインポートする
                - あるいはIAMに証明書をアップロードも可能
            - デフォルトの証明書
                - HTTPSリスナーを作成するには、厳密に1つの証明書を指定する必要あり(デフォルト証明書)
                - HTTPSリスナー作成後、デフォルト証明書を置き換えることができる
            - 証明書リスト内の追加証明書を指定する場合でも、デフォルトの証明書が使用されるケース
                - クライアントがホスト名を指定するためにServer Name Indication(SNI)プロトコルを使用せずに接続した場合
                - または証明書リストに一致する証明書がない場合
            - 追加証明書を指定せず単一のロードバランサーを介して複数の安全なアプリケーションをホストする必要がある場合
                - ワイルドカード証明書を使用する
                - または追加ドメインごとにサブジェクト代替名(SAN)を証明書に追加できる

## おわりに

ブログ書きながらのSCS認定試験準備、やがて幕を閉じます。
拙い文章読んでいただき誠にありがとうございます。