[前回] AWS公式資料で挑むSCS認定(51)-こんな時どうする(全分野その28)
はじめに
本日のSCS認定試験、おかげさまで無事合格できました。
ゴールは「AWSの魔法使いになること」で、資格獲得ではない、
と自分に言い聞かせながらも、
試験終了時表示された合格おめでとうには感慨深いものがありました。
試験について、3点情報共有です
- 公式資料の基本知識をしっかり理解できていれば合格ラインに到達可能
- アクセス許可ポリシーの問題が厄介でした(が、これも公式資料の範疇)
例えば、本連載で過去取り上げた内容 - 試験開始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エンドポイントを設定
- HTTPSでカスタムドメインを使用するには、
-
- オリジンアクセスアイデンティティ(OAI)を使用し、CloudFrontにより配信されるS3バケットコンテンツに、ユーザーが直接アクセスできないようにする
分野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フィールドを含むフローログを作成
- トラフィックがセカンダリプライベートIPv4アドレスに送信されても、フローログのdstaddrフィールドにはプライマリプライベートIPv4アドレスが表示される
- ネットワークインターフェイスが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のネットワークインターフェイスの間のトラフィック
- Amazon DNSサーバーに接続したときにインスタンスによって生成されるトラフィック
- EC2-Classicプラットフォームにあるネットワークインターフェイスのフローログを有効にすることはできない
- フローログを削除してから、必要な設定を使って新しくフローログを作成する必要あり
分野3: インフラストラクチャのセキュリティ
- 大量のVPCにまたがるアプリケーションを、ルートテーブルを更新する手間なく、構築/デプロイしたい
- AWS Transit Gatewayを中心的なハブとして使用
- AWS Transit Gatewayのユースケース
- 集中型ルーターとして使用
- すべてのVPC、AWS Direct Connect、およびAWS Site-to-Site VPNの接続に対し、集中型ルーターとして設定できる
- 共有サービスを使用する分離されたVPC構成で、独立したルーターとして使用
- ルートとアタッチメントが変わる可能性がある場合、複数トランジットゲートウェイより高い柔軟性を提供
- ピア接続
- 一元的な発信ルーティング
- アプライアンスVPC
- 集中型ルーターとして使用
- 構成例
※ 引用元: 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
- 最初のエントリ
- 各VPCに、2つのエントリを持つルートテーブル
- トランジットゲートウェイルートテーブル
- 2つのルートテーブル
- VPC用
- VPN接続および共有サービスVPC用
送信先 ターゲット ルートタイプ 10.99.99.0/24 VPN接続のアタッチメント 伝播済み 10.4.0.0/16 VPC Dのアタッチメント 伝播済み
- 2つのルートテーブル
- 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
- 次のVPC CIDRが含まれる
- VPC A、VPC B、VPC C、およびVPC Dのルートテーブル
分野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キーポリシーはアカウントまたはそのユーザーに対し、明示的な許可ステートメントを含める必要あり
- キーポリシーで、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:*許可を付与できるようになる
- AWSアカウントのIAMユーザーまたはロールに対し、IAMポリシーを用いて、 キーポリシーで委譲された
- プログラムで作成されたKMSキーのデフォルトキーポリシーの全文である
- キーを制御する許可をアカウントプリンシパル(ルートユーザーを含む削除できないアカウント管理者)に付与するもう一つの利点
- キーが管理不能になるリスクが軽減される
- たとえば、KMSキーへのアクセスを1人のユーザーだけに付与するキーポリシーを作成した場合
- そのユーザーを削除すると、キーが管理不能になる
- KMSキーへのアクセスを取り戻すためには、AWSサポートに連絡しなければならない
- たとえば、KMSキーへのアクセスを1人のユーザーだけに付与するキーポリシーを作成した場合
- IAMのベストプラクティスは、緊急時を除き、アカウントルートユーザーで操作することは推奨されていない
- ただし、KMSキーへのアクセス権を持つ他のすべてのユーザーおよびロールを削除した場合、アカウントルートユーザーで操作する必要あり
- キーが管理不能になるリスクが軽減される
- KMSキーを付与するAWSアカウントに、KMSキーへのフルアクセスを付与
- KSMキーのアクセス制御可能なポリシー
分野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)を証明書に追加できる
- SSL/TLSツールを使用し署名証明書リクエスト(CSR)を作成し、CAからCSR署名を取得し証明書を発行し、ACMにこの証明書をインポートする
- ロードバランサーとクライアント間で、SSL/TLSセッションによるトラフィック暗号化が可能
おわりに
ブログ書きながらのSCS認定試験準備、やがて幕を閉じます。
拙い文章読んでいただき誠にありがとうございます。