運用設計:
①CloudWatchをベースにEC2の死活監視やRoute53の外形監視を使ってアラートの設定をして異常を検知する
②使用しているサービスのメトリクスで何を見るのか、何をアラートトリガーにするか決めておく(障害定義)
③アプリ側のメトリクス取得やログの外部出力(S3、CloudWatch Logs)を行うこと
④検知後の一次切り分けや復旧フローを作成する
->結構重要!!
⑤実施にフローを流してみる
⑥可能な限り自動化できることを模索すること
バックアップ:
①EC2の場合、AMIから復旧かEBSスナップショットからの復旧をするのか?
②IPアドレスが変更した場合も考慮する
③自動バックアップサービス
- Amazon DLM
- AWS Backup
- Opswitch
復旧計画:
①AZ障害が起こった場合の冗長構成はできているか?
②リージョンレベルでも考慮されているか?
③CloudFormationで、テンプレ化しておくと復旧が楽。
④変更の反映に手間になりすぎない構成にするのがベスト。
アカウント:
①扱うAWS環境が多くなる場合には、環境ごとにAWSアカウント自体を分けたほうが良い
②システム毎に分けるか、ステージ毎(本番・検証・開発)で分けるなど
セキュリティ:
①IAMユーザは、MFAを使う
②コードを扱う端末は全てにgit-secretを導入
③最小権限を意識する
④AWS利用ユーザーの方に、IAMの扱いについて教育する
⑤AWS CloudTrail:ログイン履歴を記録
⑥AWS Config:AWSリソースベースの変更履歴を記録
⑦Amazon GurdDuty:不正な動きを検知・不正なログインやその他脅威を検知する。
S3:
S3のアクセス制御について
①IAMポリシー
②バケットポリシー
③ACL
④パブリックアクセスブロック
⑤IAMユーザ・ロールにアクセス権を与える時はResouceでバケットを最小限に限定する(EC2/Lambdaなど)
⑥パブリックアクセスブロックで外部からのアクセスを多重に防ぐ
①CloudWatchをベースにEC2の死活監視やRoute53の外形監視を使ってアラートの設定をして異常を検知する
②使用しているサービスのメトリクスで何を見るのか、何をアラートトリガーにするか決めておく(障害定義)
③アプリ側のメトリクス取得やログの外部出力(S3、CloudWatch Logs)を行うこと
④検知後の一次切り分けや復旧フローを作成する
->結構重要!!
⑤実施にフローを流してみる
⑥可能な限り自動化できることを模索すること
バックアップ:
①EC2の場合、AMIから復旧かEBSスナップショットからの復旧をするのか?
②IPアドレスが変更した場合も考慮する
③自動バックアップサービス
- Amazon DLM
- AWS Backup
- Opswitch
復旧計画:
①AZ障害が起こった場合の冗長構成はできているか?
②リージョンレベルでも考慮されているか?
③CloudFormationで、テンプレ化しておくと復旧が楽。
④変更の反映に手間になりすぎない構成にするのがベスト。
アカウント:
①扱うAWS環境が多くなる場合には、環境ごとにAWSアカウント自体を分けたほうが良い
②システム毎に分けるか、ステージ毎(本番・検証・開発)で分けるなど
セキュリティ:
①IAMユーザは、MFAを使う
②コードを扱う端末は全てにgit-secretを導入
③最小権限を意識する
④AWS利用ユーザーの方に、IAMの扱いについて教育する
⑤AWS CloudTrail:ログイン履歴を記録
⑥AWS Config:AWSリソースベースの変更履歴を記録
⑦Amazon GurdDuty:不正な動きを検知・不正なログインやその他脅威を検知する。
S3:
S3のアクセス制御について
①IAMポリシー
②バケットポリシー
③ACL
④パブリックアクセスブロック
⑤IAMユーザ・ロールにアクセス権を与える時はResouceでバケットを最小限に限定する(EC2/Lambdaなど)
⑥パブリックアクセスブロックで外部からのアクセスを多重に防ぐ
0 件のコメント:
コメントを投稿