RDSの不正アクセス検知
スー選択肢
- Amazon GuardDutyの活用
- AWS CloudTrailの利用
- セキュリティグループとネットワークACLの設定 -> これもやるだろう or やっているところはちゃんとやてそう。
- データベース監査ログの有効化 -> これもやるだろう or やっているところはちゃんとやてそう。
3,4はやっているところが多いと思うが、1,2については知らなかったのでもうちょい追ってみる。
Amazon GuardDuty
Amazon GuardDutyは、AWS環境全体を継続的に監視し、悪意のある活動や不正な行動を検出する脅威検知サービスです。特にRDSに対しては、異常なログイン試行や既知の悪意のあるIPアドレスからのアクセスを検出する「RDS保護」機能を提供しています。
AWS CloudTrail
AWS CloudTrailは、AWSアカウント内のAPIコールを記録し、監査やコンプライアンスの目的で使用されます。CloudTrailのログを分析することで、RDSへの不審なアクセスや操作を検出できます。例えば、CloudWatchと連携させて特定の異常な操作をリアルタイムで検知し、アラートを設定することが可能です。
セキュリティグループとネットワークACLの設定
RDSインスタンスへのアクセスを制限するために、セキュリティグループやネットワークACLを適切に設定し、許可されたIPアドレスやポートからのみアクセスできるようにします。これにより、不正アクセスのリスクを低減できます。
データベース監査ログの有効化
RDSの一部のエンジン（例: MySQL、PostgreSQL）では、監査ログ機能を提供しています。これを有効化することで、データベース内の操作履歴を記録し、不正なクエリやアクセスを検出できます。
-> これって検出したものをどうやって人間が認識できるように通知するんだ・・・？
スーQ. GuardDutyとCloudTrailはどのような役割分けとして認識すれば良い？
GuardDutyとCloudTrailの役割分け
GuardDutyとCloudTrailはAWSのセキュリティにおいて補完的な役割
それぞれの役割を理解することで、より効果的なセキュリティ対策を講じることができる
1. GuardDutyの役割
-
目的: 脅威検知
GuardDutyは、AWS環境全体を対象とし、悪意のある行動やセキュリティ侵害の兆候を検出します。具体的には以下を行います：- 不正アクセスや異常な動作の検知
- 既知の悪意あるIPアドレスやドメインからの通信の検出
- RDS、S3、IAMなどAWSサービスへの不正な操作を検出
- 高度な機械学習や脅威インテリジェンスを活用した継続的監視
-
使い所:
- リアルタイムで異常なアクティビティを検出したい場合
- AWSサービスを横断した潜在的な脅威を把握したい場合
- 自動化されたアラートで迅速に対応したい場合
2. CloudTrailの役割
-
目的: 操作履歴の監査・分析
CloudTrailは、AWSリソースで発生するすべてのAPIコール（マネジメントコンソール、CLI、SDKからの操作を含む）を記録します。具体的には以下を行います：- 誰が（ユーザーまたはロール）、いつ、どのリソースに対して何を行ったかを追跡
- 過去の操作ログを保存し、セキュリティインシデント発生時の根本原因分析に利用
- コンプライアンスや監査のための詳細な操作履歴の提供
-
使い所:
- 具体的なユーザーやIPアドレスが特定リソースに対して何をしたかを調査したい場合
- 長期間の操作履歴を保存して、将来のセキュリティ監査やトラブルシューティングに備えたい場合
違いと補完関係
| 項目 | GuardDuty | CloudTrail |
|---|---|---|
| 目的 | 異常や脅威の検出 | 操作履歴の監査と分析 |
| 監視対象 | ネットワーク通信、AWSリソース全体の動作 | AWSリソースでのAPIコール |
| リアルタイム性 | リアルタイムでの脅威検出 | 基本は非リアルタイム（ログ取得後の分析が前提） |
| 主な用途 | アラート・脅威の通知、自動応答 | 監査、トラブルシューティング、根本原因分析 |
| 対象者 | セキュリティチーム（自動検出・対応） | 開発者や運用チーム（具体的な操作ログの追跡） |
具体的な使い分け例
-
GuardDutyで脅威を検出 → CloudTrailで詳細を調査
- GuardDutyが「既知の悪意のあるIPアドレスからRDSへの接続」を検知した場合、CloudTrailログを確認し、誰がどのAPIコールを発行したかを詳細に調査。
-
CloudTrailで異常な操作を発見 → GuardDutyで関連脅威を監視
- CloudTrailで特定のIAMユーザーが通常より多くのAPIコールを発行していることに気づいた場合、GuardDutyでそのユーザーの関連する脅威をモニタリング。
まとめ
- GuardDutyはリアルタイム検知と異常検知の自動化に強い。
- CloudTrailは操作履歴の可視化と調査分析に特化。
両方を組み合わせることで、AWS環境のセキュリティを効果的に強化する。
スーセキュリティチームがない場合のGuardDutyとCloudTrail活用方法
セキュリティチームがない場合でも、アプリケーションチームが効率的にセキュリティ対応を行うには、自動化や適切なアラート設計が重要。また、利用料金を抑えつつ効果を高めるには以下の手順が有効。
1. GuardDutyの活用
-
自動的に脅威を検知し、コストを抑える設定
-
必要最低限のサービス範囲に限定
RDSやEC2など特に脅威が懸念されるAWSリソースにフォーカスしてGuardDutyを有効化する。
S3やIAMなどの対象を広げるのは脅威の優先度に応じて判断する。 -
自動アクションの設定
GuardDutyで検出された脅威に対して、AWS Lambdaを利用し自動的に特定の対応（例: セキュリティグループの制限）を行う仕組みを構築する。
Lambdaはイベント駆動で動作するためコスト効率が良い。
-
必要最低限のサービス範囲に限定
-
アラート通知
GuardDutyで検知された重要な脅威をAmazon SNSを通じて通知する。メールやSlack通知を活用し、迅速に気付ける環境を整える。 -
コスト
GuardDutyの料金はスキャン対象リソースの使用量に基づく。小規模環境では低コストであり、約$1/百万イベントが目安である。
2. CloudTrailの利用
-
コストを抑える設定
-
ログの保存先をS3に指定し、ライフサイクル管理を設定
必要な操作履歴を最小限保持し、古いデータは削除またはGlacier（低コストストレージ）に移動する。 -
リアルタイム分析をAWS CloudWatchに限定
CloudTrailのすべてのログをリアルタイムで監視するとコストが増加するため、特定のイベント（例: IAM操作やRDSへのアクセス）に限定して分析する。
-
ログの保存先をS3に指定し、ライフサイクル管理を設定
-
アラート通知
CloudWatchアラームを設定し、不審な操作（例: 未許可IPからのアクセス）が発生した際に通知する。 -
コスト
CloudTrailは管理イベントの前月ログが無料（5GBまで）であり、大規模運用をしない場合、ランニングコストはほぼゼロである。
3. AWS ConfigとConfig Rules
-
設定の自動監査
AWS Configを利用して、セキュリティルールに基づいたリソース設定を自動監査する。
例: RDSが常に暗号化されているか、IAMポリシーが過剰権限を持たないかを監査。 -
違反のアクション
自動的に修正ルールを適用可能であり、設定ミスの影響を最小化できる。 -
コスト
管理するリソース数によるが、単一リージョンで数十リソース規模であれば月数ドル程度に抑えられる。
4. AWS Security Hubの導入
-
脅威の集中管理
Security Hubを利用することで、GuardDutyやConfigのセキュリティフィンドを1つのダッシュボードで管理可能。
重要度ごとに脅威を分類し、アクション優先度を決める指針となる。 -
コスト
Security Hubの利用料金は少量のフィンド数に対して低コストであり、利用状況に応じてスケーリング可能。
5. コスト効果と選択肢の比較
| サービス | 用途 | 予想コスト（月） | 備考 |
|---|---|---|---|
| GuardDuty | 脅威検知とアラート | 数ドル～数十ドル | リソース規模に応じて変動。RDS Protectionが特に今回は良さそう |
| CloudTrail | 操作履歴の監査と調査 | 無料（5GBまで） | 大規模でなければ低コスト運用が可能 |
| AWS Config | リソース設定の自動監査 | 5～10ドル | 管理リソース数に応じて増加 |
| Security Hub | セキュリティ情報の集中管理 | 数ドル～数十ドル | フィンド数が少なければ安価 |
| Amazon SNS | 通知機能の統合 | 数ドル | メールやSlack通知を簡単に利用 |
スーリンクまとめ