AWS公式資料で挑むSCS認定(26)-こんな時どうする(全分野その3)
[前回] AWS公式資料で挑むSCS認定(25)-こんな時どうする(全分野その2)
はじめに
早速、今回も「こんな時どうする」の追記です。
精査はしていますが、過去と似たような項目を取り上げる可能性あります、悪しからず。
分野1: インシデント対応
- EC2インスタンスで使用されていないポートが攻撃された、稼働中システムを止めずにすぐ対処したい
- セキュリティグループのインバウンドルールから問題のポート番号を削除
分野2: ログとモニタリング(監視)
-
S3バケットのアクセスログに「認証失敗」「HTTP Referer情報」を含め記録したい
- S3サーバーアクセスログを使用し、S3リクエストをログ記録
-
S3バケットのアクセスログに「IAM/ユーザー特定情報」「クロスアカウントログ」を含め記録したい、かつログファイルを暗号化したい
- AWS CloudTrailを使用し、S3のAPIコールをログ記録
-
Amazon GuardDutyによる監視で、特定EC2インスタンスから頻繁に誤検知(false positive)の通知発生するため、監視対象から除外したい
- 信頼できるIPリストに、問題EC2インスタンスのIPアドレスを追加し、Amazon GuardDutyに適用
- ※ 信頼できるIPリストのアップロード数は各リージョンのAWSアカウントにつき1つのみ
- ※ Amazon GuardDutyとは
- セキュリティの観点から脅威リスクを検知するマネージドサービス
- 分析のソースに下記を利用、メタデータの連続ストリームを分析
- VPC Flow Logs
- AWS CloudTrail Event Logs
- DNS Logs
- 統合脅威インテリジェンスを使用し脅威を認識
分野3: インフラストラクチャのセキュリティ
- VPC内複数コンテナ間で相互TLS認証による通信を行いたい
- ACMプライベートCA(証明機関)を使用し、下位CAを作成
- ACM(AWS Certificate Manager)を使ってプライベート証明書を作成、すべてのコンテナに適用する
- ※ ACMプライベートCAとは、プライベート証明書のライフサイクルを簡単かつ安全に管理するマネージドサービス
- 自社プライベートCAを先行投資やメンテナンスコストをかけず運用でき、可用性の高いプライベートCAを得られる
分野4: アイデンティティ(ID)及びアクセス管理
-
AWSアカウントを保護したい
- AWSアカウントのルートユーザーまたはIAMユーザーに対しMFA(多要素認証)を有効に
-
EC2 Linuxインスタンスにログインしたい
- キーペアによる認証でログイン
- キーペアには、プライベートキーとパブリックキーが含まれる
- パブリックキーは、EC2インスタンス内に保管
- プライベートキーは、ユーザー自身が保管
-
セキュリティ監査の実施タイミングが不明
- 定期的監査
- 従業員が退職するなど組織変更があった場合
- 1つ以上のAWSサービスを使用しなくなった場合(不要になったアクセス許可を削除するため重要)
- AWSアカウントでソフトウェアの追加/削除があった場合(EC2インスタンスのアプリケーション、AWS OpsWorksスタック、AWS CloudFormationテンプレートなど)
- 権限のない人がアカウントにアクセスした疑いがある場合
分野5: データ保護
- S3バケットのオブジェクトに対し、KMSキーを用いたサーバー側暗号化(SSE-KMS)を強制するポリシーを作成したい
- ポリシーで下記Statementを定義
{
... ...
"Effect": "Deny",
"Action": "s3:PutObject",
"Condition": {
"StringNotEquals":{
"s3:x-amz-server-side-encryption":"aws:kms"
}
}
}
- S3バケットのオブジェクトに対し、S3バケットキーを用いたサーバー側暗号化(SSE-S3)を強制するポリシーを作成したい
- ポリシーで下記2つのStatementを定義
{
... ...
"Effect": "Deny",
"Action": "s3:PutObject",
"Condition": {
"StringNotEquals": {
"s3:x-amz-server-side-encryption": "AES256"
}
}
},
{
... ...
"Effect": "Deny",
"Action": "s3:PutObject",
"Condition": {
"Null": {
"s3:x-amz-server-side-encryption": "true"
}
}
}
- 独自のキーマテリアルをインポートしているKMSキー(カスタマー管理キー)を毎年更新したい
- 新しいKMSキーを作成し
- 新しいキーマテリアルをインポート
- 既存のKMSキーのエイリアスを新しいKMSキーにマッピング
- ※ KMSキー(カスタマー管理キー)の種類とローテーション
- カスタマー管理の対称KMSキー
- キーマテリアルをAWS KMSで生成
- 1年ごとの自動更新を設定可
- キーマテリアルをAWS CloudHSMクラスターで生成(KMSカスタムキーストア機能を使用)
- 自動更新不可、要手動更新
- 独自のキーマテリアルをインポート
- 自動更新不可、要手動更新
- キーマテリアルをAWS KMSで生成
- カスタマー管理の非対称KMSキー
- キーマテリアルはAWS KMS HSMでのみ生成可能
- 自動更新不可
- キーマテリアルはAWS KMS HSMでのみ生成可能
- カスタマー管理の対称KMSキー
おわりに
「こんな時どうする」の追記でした。
次回も続きます、お楽しみに。
Author And Source
この問題について(AWS公式資料で挑むSCS認定(26)-こんな時どうする(全分野その3)), 我々は、より多くの情報をここで見つけました https://qiita.com/mingchun_zhao/items/feaf1d3d5bff8d0dd954著者帰属:元の著者の情報は、元のURLに含まれています。著作権は原作者に属する。
Content is automatically searched and collected through network algorithms . If there is a violation . Please contact us . We will adjust (correct author information ,or delete content ) as soon as possible .