[前回] AWS公式資料で挑むSCS認定(44)-こんな時どうする(全分野その21)
はじめに
今回も引き続き、「こんな時どうする」集の作成です。
分野1: インシデント対応
- 外部から侵害を受けたEC2 Windowsインスタンスに対し、メモリダンプを採取しフォレンジック調査を行いたい
- EC2Rescue for Windows Serverを使用し、メモリダンプを収集
- EC2Rescue for Windows Serverは、潜在的な問題の診断とトラブルシューティングを行うためのツール
- ログファイルを収集し問題を解決
- 問題がありそうな部分をプロアクティブに検索
- 他のインスタンスからAmazon EBSルートボリュームを調べることも可能
- 2種類のモジュール
- データ収集モジュール
- さまざまなソースからデータを収集
- データ分析モジュール
- 収集されたデータを、一連の定義済みルールと照らし合わせて解析、問題を識別、解決方法を提案
- データ収集モジュール
- EC2Rescue for Windows Serverツールは、Windows Server 2008 R2以降を実行するEC2インスタンスのみ実行可能
分野2: ログとモニタリング(監視)
- AWS CloudTrailの証跡からログを受け取るS3バケットのログファイルプレフィックスを追加/変更/削除しようとすると、
There is a problem with the bucket policyエラーが表示される- バケットポリシーで古いプレフィックスを使用しているため、証跡がログをバケットに配信できない可能性あり
- 対処方法
- S3コンソールを使用し、バケットポリシーのログファイルプレフィックスを更新
- プレフィックスを変更するバケットを選択し、
Propertiesを選択 -
Permissionsを選択し、Edit Bucket Policyを選択 - バケットポリシーで、
s3:PutObjectアクションの下で、Resourceエントリを編集 - 必要に応じてログファイルプレフィックスを追加/変更/削除
"Action": "s3:PutObject""Resource":"arn:aws:s3:::myBucket/prefix/AWSLogs/myAccountID/*"
- プレフィックスを変更するバケットを選択し、
- CloudTrailコンソールを使用し、証跡のバケットに同じプレフィックスを指定
- 証跡を選択し
-
Storage locationの場合、バケットの設定を編集 -
S3 bucketの場合、変更するプレフィックスを持つバケットを選択 -
Log file prefixの場合、バケットポリシーに入力したプレフィックスに一致するようにプレフィックスを更新
-
- 証跡を選択し
- S3コンソールを使用し、バケットポリシーのログファイルプレフィックスを更新
分野3: インフラストラクチャのセキュリティ
- VPC内のAWSリソースがインターネット経由でトラフィックを送受信できるようにしたい
- 以下の条件を満たすように対応
- インターネットゲートウェイがVPCに接続されている
- パブリックサブネットに関連付けられたルートテーブル(カスタムルートテーブルを含む)に、インターネットゲートウェイへのルートがある
- VPCに関連付けられたセキュリティグループが、インターネットとの間で送受信されるトラフィックのフローを許可
- VPC内のインスタンスに、パブリックIPアドレスまたは接続済みのEIP(Elastic IPアドレス)のいずれかがある
- 以下の条件を満たすように対応
分野4: アイデンティティ(ID)及びアクセス管理
- Amazon EC2 Auto Scalingのインスタンスで、
同じAWSアカウントのカスタマー管理キーにより暗号化されたAmazon EBSを使用したい- 暗号化されたEBSを使用するため、AWS KMSキーポリシーの設定が必要
- Amazon EC2 Auto Scalingは、事前定義された
サービスにリンクされたロールを用いて、ユーザーに代わって他のAWSサービスへの呼び出し許可を設定 - Amazon EC2 Auto Scalingインスタンス起動時、EBSの暗号化に使用可能なAWS KMSキー
- AWS管理キー
- EBSによって作成、所有、管理される暗号化キー
- 新しいアカウント作成時のデフォルト暗号化キー
- EC2 Auto Scalingの
サービスにリンクされたロールには、既にAWS管理キーへのアクセス権限が含まれるため、追加承認不要
- カスタマー管理型キー
- ユーザーが作成、所有、管理するカスタム暗号化キー
- 対称キーである必要あり、Amazon EBSは非対称カスタマー管理キーをサポートしない
- 設定タイミング
- 暗号化されたスナップショット作成時
- 暗号化されたボリュームを指定する起動テンプレートを作成時
- デフォルトで暗号化を有効にするとき
- EC2 Auto Scalingの
サービスにリンクされたロールに、カスタマー管理キーへのアクセス権限は含まれていない、キーポリシー設定が必要
- AWS管理キー
- EBS暗号化指定時、EC2 Auto Scalingインスタンス起動に必要なキーポリシーの設定方法
- Amazon EC2 Auto ScalingでCMK(カスタマー管理キー)のキーポリシーを使用するため、2つのポリシーステートメントが必要
- ステートメント1で、Principal要素に指定されたIAMアイデンティティに、カスタマー管理キーを直接操作できるようにアクセス許可
"Effect": "Allow""Principal": {"AWS": ["arn:aws:iam::123456789012:role/aws-service-role/autoscaling.amazonaws.com/AWSServiceRoleForAutoScaling"]}-
"Action": ["kms:Encrypt","kms:Decrypt","kms:ReEncrypt*","kms:GenerateDataKey*","kms:DescribeKey"]
- ステートメント2で、Principal要素に指定されたIAMアイデンティティに、独自のアクセス許可のサブセットをAWS KMSまたはプリンシパルと統合された別のAWSサービスに委任するための許可を指定
- これにより、委任対象サービスはユーザーに代わって、KMSキーを使用し暗号化されたリソースを作成できるようになる
"Effect": "Allow""Principal": {"AWS": ["arn:aws:iam::アカウントID:role/aws-service-role/autoscaling.amazonaws.com/AWSServiceRoleForAutoScaling"]}"Action": ["kms:CreateGrant"]"Resource": "*""Condition": {"Bool": {"kms:GrantIsForAWSResource": true}}
- ステートメント1で、Principal要素に指定されたIAMアイデンティティに、カスタマー管理キーを直接操作できるようにアクセス許可
- ※ 注意: キーポリシーに新しいポリシーステートメントを追加する際、既存のステートメントは変更しない
- Amazon EC2 Auto ScalingでCMK(カスタマー管理キー)のキーポリシーを使用するため、2つのポリシーステートメントが必要
分野5: データ保護
- ALBがウェブリクエストをターゲットグループのEC2インスタンスへルーティングする際の通信を暗号化し保護したい
- ALBのターゲットグループがHTTPSプロトコルを使用するように指定し、転送データを暗号化
- ALBはデフォルトで、ターゲットグループ作成時に指定したプロトコルとポート番号を使用し、リクエストをターゲットにルーティングする
- ターゲットグループへターゲット登録時、トラフィックのルーティングに使用されるポートを上書きすることも可能
- ターゲットグループでサポートされるプロトコルとポート
- プロトコル: HTTP、HTTPS
- ポート: 1 - 65535
- ターゲットグループがHTTPSプロトコルを使用して設定されているか、HTTPSヘルスチェックを使用する場合
- ターゲットへのTLS接続に
ELBSecurityPolicy-2016-08ポリシーのセキュリティ設定が使用される - ロードバランサーは、ターゲットにインストールする証明書を使用し、ターゲットとのTLS接続を確立
- ロードバランサーはこれらの証明書を検証しないため、自己署名証明書または期限切れの証明書を使用できる
- ロードバランサーはVPC内にあるため、ロードバランサーとターゲット間のトラフィックはパケットレベルで認証される
- よって、ターゲットの証明書が有効でない場合でも、中間者攻撃やスプーフィングのリスクはない
- ターゲットへのTLS接続に
おわりに
「こんな時どうする」の追記でした。
次回も続きます、お楽しみに。