はじめに
本事件について簡単に
また参考までに
AWSの脆弱な仕組みが突かれて起きた問題、というわけではないようだが
IAM の設定やベストプラクティスの理解、一体どこでどのように管理対応するのが良いのか出来すぎる事による複雑性
AWSを利用する上では必ずついてまわるめ出来ること、できそうな事を考えておく
GuardDuty
一番簡単で効果的な不正トラフィックの監視を行ってくれるサービス料金
CloudTrail イベント分析 – GuardDuty は、CloudTrail イベント を継続的に分析し、AWS のアカウントとインフラストラクチャのすべてのアクセスと動作をモニタリングします。CloudTrail 分析は、毎月 1,000,000 件のイベントごとに課金され、プロ評価されます。
VPC フローログと DNS ログの分析 – GuardDuty は、VPC フローログおよび DNS のリクエストと応答を継続的に分析し、AWS のアカウントとワークロードで悪意のある動作、不正な動作、または予期しない動作を識別します。フローログと DNS ログの分析は、1 か月あたりのギガバイト (GB) 単位で課金されます。フローログと DNS ログの分析には、段階的な従量制割引が適用されます。
通信量とイベント数の従量課金、通信量ではなく通信ログの量なので注意
規模によるがこそこの金額がかかりそう
GuardDutyの利用
サービス画面で有効可を行うだけ
有効になると EC2 に直接通信するようなサービスやポートがあった場合通知してくれる
ただ遡及して検知はしないため、利用する場合はなるべく早くから有効化しておいてほうがいい
AWS Config
AWS上の設定変更、ステータス変更、コンプライアンス対応状況を監視、通知してくれる料金
利用するConfigのルール数と監査する対象数と検知数での従量課金となる
2019年8月に金額計算式の改定が行われ、複雑になっているが従来より安くなっている（らしい）
追加で S3 料金も発生する
Configの利用
Configのログを出力するバケットとロールを作成
ルールの指定
Configのルールは作成時点で52ルールある
AWS Config マネージドルールのリスト
マニュアルを見ながら必要なものだけを指定し、状況を見て必要なら追加するようにしたほうが良さそう
とりあえず以下のルールを指定してみる
- s3-bucket-policy-grantee-check
- restricted-ssh
- elb-acm-certificate-required
- iam-root-access-key-check
- cloudtrail-enabled
- eip-attached
- guardduty-enabled-centralized
- s3-bucket-public-write-prohibited
- s3-bucket-public-read-prohibited
- acm-certificate-expiration-check
- ec2-volume-inuse-check
- rds-instance-public-access-check
- ebs-optimized-instance
ルールを指定し Config の設定を完了すると完了
初回の解析時は結構時間がかかる
解析が終わると問題があった場合、どこに問題があったか教えてくれる
IAM のベストプラクティス
今読んでも理解しきれないけど、よく読んでおく
マネージドコンソールへのログインを監視
CloudTrail + CloudWatch を利用して AWS マネージドコンソールにログインしたら通知するようにするCloudTrail 証跡の作成
しておく
CloudWatch イベントの作成
AWSの認証イベントは us-east-1 で記録されるため、CloudWatch Event、SNS も同リージョンに設定する必要がある
設定後、ログインするとメール通知がくる
あとは Lambda 使ってもいいし
CloudWatch Logs で監視する
これはリージョンの縛りはない
CloudTrailの証跡から CloudWatch Logs にログを連携設定し
下記を参考にメトリクスフィルタを作成しアラームを設定する
CloudTrail イベント用の CloudWatch アラームの作成: 追加の例
メトリクスフィルタを工夫すればログイン失敗情報、API認証失敗などを通知することも出来る
