[前回] AWS公式資料で挑むSCS認定(27)-こんな時どうする(全分野その4)
はじめに
「こんな時どうする」佳境入りましたが、
予防接種3回目も頭痛や熱出るんですね。
分野1: インシデント対応
- AWS Configによりコンプライアンス違反が通知された、すぐEC2インスタンスを終了させたい
- CloudWatch Eventsを使用し、AWS Lambda関数をスケジュールする
- Lambda関数を使って、EC2インスタンスを終了させる
- ※ イベント管理は、CloudWatch EventsよりAmazon EventBridge がより多くの機能を提供
分野2: ログとモニタリング(監視)
-
EC2インスタンスにアタッチされたEBSボリュームが暗号化されているか監視したい
- AWS Configのルール識別子
ENCRYPTED_VOLUMES
を使用し監視 - 暗号化にKMSキーID(kmsIdパラメータ)を指定した場合、アタッチ状態のEBSボリュームが、指定KMSキーで暗号化されているか確認できる
- AWS Configのルール識別子
-
EC2インスタンスが特定AMIから起動したか監視したい
- AWS Configのルール識別子:
APPROVED_AMIS_BY_ID
を使用し監視 - 承認済みAMI IDリストを指定し、実行中インスタンスで使用されているAMIがリストに存在しない場合、
NON_COMPLIANT
非準拠と判定される
- AWS Configのルール識別子:
分野3: インフラストラクチャのセキュリティ
-
EC2インスタンスからAmazon RDS for MySQLのポート番号3306を経由した接続のみ許可したい
- 方法1: NACLの場合、アウトバウンドルールでポート3306を許可、インバウンドルールで一時ポートを許可
- インバウンド/アウトバウンド両方にルール設定が必要(ステートレス)
- 方法2: SGの場合、アウトバウンドルールでポート3306を許可
- アウトバウンドルールのみでOK(ステートフル)
- 方法1: NACLの場合、アウトバウンドルールでポート3306を許可、インバウンドルールで一時ポートを許可
-
EC2インスタンスのパッケージを更新したい、SSHを介したEC2へのアクセスは許可されていない
- AWS Systems Managerの自動化機能
Run Commond
を使用し、リモートからコマンドを実行 - ※ AWS Systems Managerは、AWSリソースの運用実体を把握し、大規模AWSリソースへのアクションを安全に実行できる管理ツール
- 設定方法
- EC2インスタンスでのアクション実行権限をSystems Managerに付与するため
- IAMロールを作成し、
AmazonEC2RoleforSSM
ポリシーを割り当てる
- IAMロールを作成し、
- Systems ManagerでEC2インスタンスを管理するため
-
EnablesEC2ToAccessSystemsManagerRole
ロールを使用しEC2インスタンスを作成
-
- EC2インスタンスのSystems Managerエージェントを更新
- Systems Managerの
Run Command
を用いてリモートシェルスクリプトを実行 - 作業終わったら費用削減のため、Systems ManagerとEC2関連リソースを終了
- EC2インスタンスでのアクション実行権限をSystems Managerに付与するため
- AWS Systems Managerの自動化機能
-
異なるVPCに配置されたEC2インスタンス間で、プライベートな通信を行いたい(インターネット介さず)
- VPCピアリング接続を使用すると、複数VPCのインスタンスが同じネットワーク内に存在しているかのように相互通信可能
- 設定方法
- 各VPC内でルーティングテーブルを構成し、相互にルーティング可能にする
- VPC内セキュリティグループに別VPC内セキュリティグループからのリクエストを受け付けるようにルール追加
- ※ VPCピアリング接続は、以下のVPC間で作成可能
- 同じAWSアカウントのVPC間
- 別のAWSアカウントのVPCとの間
- 別のAWSリージョンのVPCとの間
分野4: アイデンティティ(ID)及びアクセス管理
- AWS
アカウントA
のS3バケットやオブジェクトへのクロスアカウントアクセス許可を、別のAWSアカウントB
に付与したい-
アカウントA
の管理者ユーザーが、「特定バケット操作のためクロスアカウントアクセス許可が付与された」バケットポリシーを、アカウントB
にアタッチ -
アカウントB
の管理者ユーザーは、自動的にアカウントA
から受け取ったアクセス許可を継承し、アクセス許可を委任するユーザーポリシーをアカウントB
の他のユーザにアタッチ -
アカウントB
のユーザーは、アカウントA
が所有するバケットのオブジェクトにアクセスできる - ※ S3ユーザーガイド から引用
-
- AWS
アカウントA
のバケットに対し、「オブジェクトをアップロードするアクセス許可」を付与された別のAWSアカウントB
から、S3バケットにオブジェクトがアップロードされた。バケット所有者であるアカウントA
からオブジェクトへのアクセスを許可したい- デフォルトで、別のAWS
アカウントB
がオブジェクトをS3バケットにアップロードすると、アカウントB
(オブジェクトライター)がオブジェクト所有者となる - オブジェクト所有者は、オブジェクトACLを介して
アカウントA
の他のユーザーにそのオブジェクトへのアクセスを許可できる - ※ Amazon S3のアクセスコントロールリスト(ACL)とは
- 各バケットとオブジェクトに、ACLがサブリソースとしてアタッチされるので、ACLを用いた個別アクセス制御が可能
- ※ オブジェクトを個別にアクセス制御する必要がある状況を除き、ACLを無効にすることが推奨される
- ※ オブジェクトの所有権を使用し、ACLを無効にすることで
- バケット所有者として、バケット内のすべてのオブジェクトを自動的に所有でき、ACL以外のポリシーにアクセス制御を委ねることができる
- 別のAWSアカウントによってアップロードされたオブジェクトを含むバケットを簡単に維持できる
- バケット所有者は、ACL以外のポリシーを使用しオブジェクトへのアクセスを制御できる
- デフォルトで、別のAWS
分野5: データ保護
- EC2インスタンスで使用するシークレットを、API経由で安全に操作したい
- AWS Systems Managerパラメータストアを使用し、Secure Stringパラメータを作成し、シークレットを保管
- ※ Secure Stringパラメータとは、平文テキストのパラメータ名と暗号化されたパラメータ値を持つパラメータ
- ※ パラメータストアは、AWS KMSを使用してSecure Stringパラメータのパラメータ値を暗号化および復号
- パラメータストアがシークレットを作成/変更時、AWS KMSキーを使用し、Secure Stringパラメータのパラメーター値を暗号化
- シークレットにアクセス時、KMSキーを使用しパラメータ値を復号
- ※ KMSキーは、カスタマー管理キーまたはAWS管理キーを指定可能
- EC2インスタンスからAPI経由でシークレットにアクセスする手順
- IAMロールを作成、アクセス許可は、
- AWS KMSキーを使用するアクセス許可を追加
- Systems Managerパラメータを読み取るアクセス許可を追加
- EC2インスタンスにIAMロールをアタッチ
- IAMロールを作成、アクセス許可は、
- AWS Systems Managerパラメータストアを使用し、Secure Stringパラメータを作成し、シークレットを保管
おわりに
「こんな時どうする」の追記でした。
次回も続きます、お楽しみに。