[前回] AWS公式資料で挑むSCS認定(26)-こんな時どうする(全分野その3)
はじめに
「こんな時どうする」数が増えていくにつれ、弱い部分も見えてきました、
公式資料を読み返し、問題点をクリアにしていく過程が楽しくなりました。
分野1: インシデント対応
-
アクセスキーを悪用した不正アクセスが報告された、IAMアクセス許可が変更されていないか確認したい
- AWS Configサービスを使用、AWSリソースの設定を評価、監査、審査できる
- AWSリソースの設定が継続的にモニタリングおよび記録され、設定の評価が自動的に実行される
-
DDoS攻撃によりネットワークやシステムに遅延が発生した
- 攻撃対象領域を削減する
- 目標
- 必要なインターネットエントリポイントの数を減らす
- インターネットエントリポイントを分離し攻撃の効果を最小化
- 管理トラフィックからエンドユーザートラフィックを分離
- 必要なインターネットエントリポイントを難読化し、信頼できないエンドユーザーがアクセスできなくする
- 対策
- VPCを使用し、AWS内に独自の論理的に分離された仮想ネットワーク領域を定義
- 使用しないポート、プロトコルを無効にする
- 目標
- スケールして攻撃を吸収できるようにする
- 目標
- 攻撃をより広い領域に分散させ、影響範囲を最小化
- 攻撃者が攻撃をスケールアップするためさらにリソースを消費
- DDoS攻撃を分析し、対策するまで時間を稼ぐ
- その他障害シナリオに対し、冗長性のセキュリティレイヤーが追加される
- 対策
- アプリケーションに対して適切なEC2インスタンスタイプを選択
- Elastic Load BalancingやAuto Scaling といったサービスで自動スケール
- Amazon CloudFrontやAmazon Route 53などに組み込まれた固有のスケールを使用
- Application Load BalancerとAuto Scalingグループで自動スケールし、アプリケーション層のトラフィック増を吸収
- 目標
- 公開されたリソースを保護する
- 目標
- サービズ中断できないエントリポイントへのアクセスを制限し、保護
- 悪意のあるトラフィックがアプリケーションに到達しないようにする
- 対策
- Amazon CloudFront
- Amazon Route 53
- AWS WAF(ウェブアプリケーションファイアウォール)
- AWS Well-Architectedフレームワークを使用
- 目標
- 通常時の動作について学習する
- 目標
- アプリケーションやインフラストラクチャが攻撃を受けたときに検知できる
- アプリケーションの正常なトラフィックレベルやパターンを理解し、異常検知のベンチマークとして使用
- 対策
- Amazon CloudWatchを使用し、AWSで実行中のインフラストラクチャとアプリケーションをモニタリング
- Amazon CloudFrontレポートを使用
- Amazon Route 53のヘルスチェック
- 目標
- 攻撃に対する計画を作成する
- 目標
- 攻撃される前に対応を計画することで、インシデント発生時に素早く対応できる
- 対策
- アーキテクチャを検証し、インフラストラクチャにおいて有効な手法を選択
- 弾力性を高めるためのコストを評価、防御の目標を理解
- 攻撃が発生したときの連絡先を明確にする
- 必要なAWSサポートレベルを考慮
- 目標
- 攻撃対象領域を削減する
分野2: ログとモニタリング(監視)
-
EC2インスタンスのシステムログをCloudWatch Logsに配信したい
- CloudWatchエージェントを使用
- CloudWatchエージェントのインストール手順(IAMロール使用例、IAMユーザーも使用可)
- IAMロールを作成し、以下アクションを許可するポリシーをアタッチ
- "logs:CreateLogGroup"
- "logs:CreateLogStream"
- "logs:PutLogEvents"
- "logs:DescribeLogStreams"
- EC2インスタンスに上記IAMロールをアタッチ
- EC2インスタンスにCloudWatchエージェントをインストール
- CloudWatchエージェント設定ファイルで、収集するメトリクスを指定
- IAMロールを作成し、以下アクションを許可するポリシーをアタッチ
-
機密レベルが異なる複数アプリケーションログに対し、それぞれアクセス制御したい
- Amazon CloudWatch Logsを使用し、機密レベルに応じてロググループを作成
- IAMポリシーを使用し、ロググループ別アクセス制御を行う
- ロググループを各アプリケーションに適用
分野3: インフラストラクチャのセキュリティ
-
VPCプライベートサブネット内のアプリケーションサーバーとMySQLサーバー間でHTTPS通信のみ許可したい
- MySQLセキュリティグループのインバウンドルールに、アプリケーションサーバーセキュリティグループからMySQLポートへのアクセスのみ許可
- ※ セキュリティグループはステートフルのため、インバウンドルールのみでOK
-
VPCとAWS KMS間の通信をAWSネットワーク内に制限したい(インターネットを介さず)
- VPCプライベートエンドポイントをAWS KMS用に作成し、AWS KMSに直接接続
- VPCエンドポイントのプライベートDNS名を有効にし、下記標準KMS DNSホスト名がVPCエンドポイントに名前解決できるように
https://kms.<region>.amazonaws.com
- KMSへのリクエストをVPCエンドポイントに制限するため、KMSキーポリシーで
aws:sourceVpceまたはaws:sourceVpc条件キーを使用- ※ リクエストがVPCエンドポイントから送信される場合、
aws:sourceIP条件キーは無効
- ※ リクエストがVPCエンドポイントから送信される場合、
分野4: アイデンティティ(ID)及びアクセス管理
- 特定IPアドレスからS3バケット及びすべてのオブジェクトへアクセス制限したい
- バケットポリシーのResourceセクションに、バケットとバケット両方指定
... ...
"Effect": "Deny",
"Resource": [
"arn:aws:s3:::MY-TEST-BUCKET",
"arn:aws:s3:::MY-TEST-BUCKET/*"
],
"Condition": {
"NotIpAddress": {
"aws:SourceIp": "xxx.xxx.xxx.xxx/xx"
}
}
- SAML2.0互換IDプロバイダー(IdP)を使用し、Amazon API Gateway経由でAPIにアクセスしたい
- Amazon Cognitoで、ユーザープールにSAML2.0互換IDプロバイダーを設定
- Amazon CognitoがSAMLアサーションを受信時、SAML属性をユーザープール属性にマッピングできるように
-
属性マッピングタブでSAML2.0互換IdPの属性をAmazon Cognitoユーザープール属性にマッピング
-
- SAML2.0互換IdPをセットアップし、SAML2.0互換IdPからSAMLアサーションを受信できるように
- Amazon Cognitoユーザープールを証明書利用者として追加
- 署名証明書を追加
- Amazon API GatewayがAmazon Cognitoから渡される認証情報を認識できるように
- Amazon API Gatewayで、Amazon Cognitoユーザープールをオーソライザーとして指定
- ※ デベロッパーガイドから引用:
- Amazon API Gatewayは、ユーザープール認証からのトークンを検証し、これらのトークンを Lambda 関数などのリソースに付与できる
分野5: データ保護
- 使用しなくなったKMSキーをコスト削減のため30日後に削除したい
- キーの削除をスケジュールするためのアクセス許可
kms:ScheduleKeyDeletionを追加 -
Schedule key deletionで、キーの削除をスケジュールする -
Waiting period(in days)で、待機期間(日数)を30日に指定 -
Schedule deletionを選択 - KMSキーのステータスが
Pending deletion(削除保留中)に変わる - ※ 注意: KMSキーを削除すると復元できない、そのKMSキーで暗号化されたデータも復号できなくなる
- 不明な場合は削除ではなく、KMSキーを無効化
- キーの削除をスケジュールするためのアクセス許可
おわりに
「こんな時どうする」の追記でした。
次回も続きます、お楽しみに。