Amazon GuardDutyについて調べたのでメモしておきます。
非常に簡単に脅威検知が可能になるため、有効化必須のサービスといっても良いと思います。
東京リージョンでも利用可能です。
よくまとまったスライドがあるので一読すると概要が掴めると思います。
目次です。
GuardDutyとは
料金
Amazon GuardDuty の料金表 – アマゾン ウェブ サービス (AWS)
- AWS CloudTrail イベントの数量 (1,000,000 イベントあたり) と分析された VPC フローログと DNS ログデータの量 (GB あたり) に基づいています。
- 以下、Tokyoの例になります。
GuardDutyのセットアップ
Amazon GuardDuty でサポートされるリージョン - Amazon GuardDuty
- コンソールから「GuardDutyの有効化」を実施するだけです。
- リージョンサービスのため、各リージョンで有効化を実施する必要があります。
無料トライアル
- 30日間の無料トライアルがあります。リージョンごとに30日間無料サービスが提供されます。
IAMロールの自動作成
- GuardDutyを有効化すると「AWSServiceRoleForAmazonGuardDuty」というIAMロールが作成されます。
- 作成されたIAMロールはIAMからもGuardDutyからも編集は不可能になります。
- AWSアカウントに対して1つ作成され、リージョンごとにGuardDutyを作成した場合は同じIAMロールを使用することになります。
# アクセス権限(AmazonGuardDutyServiceRolePolicy)
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:DescribeInstances",
"ec2:DescribeImages"
],
"Resource": "*"
}
]
}# 信頼関係
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "guardduty.amazonaws.com"
},
"Action": [
"sts:AssumeRole"
]
}
]
}
各種データソース
- GuardDuty では AWS CloudTrail、VPC フローログ、DNS クエリログのデータソースを分析し結果を生成します。
- ただし、AWS CloudTrail、VPC フローログ、DNS クエリログのイベントやログは提供しないので、AWS CloudTrailやVPCフローログのセットアップが別途必要になります。
- VPCフローログが有効でなくてもGuardDutyの結果は生成されます。
※AWS CloudTrailを有効にする必要があるかは不明であるが、全リージョンで有効にしておくことが無難だと思われる。要確認。
※DNS クエリログはEC2インスタンス上から実行されたクエリログが解析対象のため、有効化は不要と思われる。要確認。
Amazon CloudWatch Events
- GuardDutyのユーザインターフェースはCloudWatchをサポートしていませんので、CloudWatch側から設定する必要があります。
- CloudWatchもリージョンサービスなので、リージョンごとに設定が必要になります。
- イベントタイプにはGuardDuty Findingのみ用意されています。結果の生成をトリガーに通知が送信されます。
ex) ターゲットにSNSトピックを指定することで結果の生成をトリガーにメール通知を行うことができます。
信頼できるIPリストと脅威リスト
停止または無効化
Amazon GuardDuty の停止または無効化 - Amazon GuardDuty
- GuardDuty停止
- AWS 環境のセキュリティは監視されなくなり、新しい結果は生成されません。
- 既存の結果は変更されず、GuardDuty の停止によって影響を受けることはありません。GuardDuty は後で再び有効にすることができます。
- GuardDuty無効
- 既存の結果と GuardDuty の設定は失われ、復旧できなくなります。
- 既存の結果を保存する場合は、GuardDuty を無効にする前にそれらをエクスポートする必要があります。
GuardDutyの結果
- 最近の結果から結果タイプや重要度の一覧を確認できます。
- 以下の結果タイプをサポートしています。
- Amazon GuardDuty の結果タイプ - Amazon GuardDuty
- BackDoor: AWSリソースが攻撃を受けていることを検出
- Behavior: ベースラインとは異なるアクティビティやアクティビティパターンを検出
- Crypto Currency: ビットコインやイーサリアムなどの暗号通過に関連付けられたソフトウェアを検出
- Pentest: 既知のペンテストツールで生成されたアクティビティと類似するアクティビティを検出
- Recon: AWS環境の脆弱性を探そうとしているアクティビティを検出
- Stealth: 攻撃アクションや形跡を隠そうとするアクティビティを検出
- Trojan: トロイの木馬プログラムが攻撃に使用されていることを検知
- Unauthorized Access: 不審なアクティビティまたアクティビティパターンの検出
- 以下に結果タイプの詳細なリストが記載されています。
- 結果タイプの説明横の四角いボタンから詳細なリストへリンクすることができます。
検出されたセキュリティ問題の修復
- 「EC2インスタンスの修正」が必要な場合
- Amazon GuardDuty によって検出されたセキュリティ問題の修復 - Amazon GuardDuty
- 不正なアクティビティの特定停止
- インスタンスの削除
- サポートケースにリクエスト(プレミアムサポートパッケージの受信者限定)
- 「AWS認証情報の修正」が必要な場合
- Amazon GuardDuty によって検出されたセキュリティ問題の修復 - Amazon GuardDuty
- 認証情報の所有者を識別
- 正当な使用か確認
- 不正に利用されていた場合は以下の対応を行います
- Resolve Issues with Potentially-Compromised AWS Accounts
- ルートアカウントとIAMユーザのパスワードを変更する
- AWS IDとアクセスキーを削除またはローテションする
- 不要なリソースを削除する
- AWSサポートセンターから受け取った通知に応答する
検証方法
- 「全般」「結果サンプルの生成」ボタンから、サンプルを生成することができます。
- [例]と書かれた32件のFindingsが作成されました。
- CloudWatch Eventsも送信されるので通知先の動作確認を行うことができます。
※手軽に結果を生成させる方法がわかっていません。要確認。
エクスポート
- JSON形式でエクスポートすることが可能です。
[
{
"schemaVersion": "2.0",
"accountId": "xxxxxxxxxxxxxxxxxxxxxxxx",
"region": "ap-northeast-1",
"partition": "aws",
"id": "yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy",
"arn": "arn:aws:guardduty:ap-northeast-1:xxxxxxxxxxxxxxxxxxxxxxxx:detector/xxxxxxxxxxxxxxxxxxxxxxxx/finding/yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy",
"type": "CryptoCurrency:EC2/BitcoinTool.B!DNS",
"resource": {
"resourceType": "Instance",
"instanceDetails": {
"iamInstanceProfile": null,
"imageId": null,
"instanceId": "i-99999999",
"instanceState": null,
"instanceType": null,
"launchTime": null,
"networkInterfaces": null,
"availabilityZone": null,
"platform": null,
"productCodes": null,
"tags": null
}
},
"service": {
"serviceName": "guardduty",
"detectorId": "zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz",
"action": {
"actionType": "DNS_REQUEST",
"dnsRequestAction": {
"domain": "example.com",
"protocol": "TCP",
"blocked": false
}
},
"resourceRole": "TARGET",
"additionalInfo": {
"sample": true
},
"eventFirstSeen": "2017-12-27T02:21:34Z",
"eventLastSeen": "2017-12-27T02:21:34Z",
"archived": false,
"count": 1
},
"severity": 5,
"createdAt": "2017-12-27T02:21:34.592Z",
"updatedAt": "2017-12-27T02:21:34.592Z",
"title": "Bitcoin-related domain name queried by EC2 instance i-99999999.",
"description": "EC2 instance i-99999999 is querying a domain name that is associated with Bitcoin-related activity."
}
]
AWS アカウントの管理(マルチアカウント)
- メンバーアカウントで検知した結果をマスターアカウントのGuardDutyで表示および管理することが可能になります。
※メンバーアカウントでも料金が発生するかは要確認。
※マスターアカウントでは、メンバーアカウントの料金も重複して発生するか要確認。
アカウント
- マスターアカウント
- 自分のアカウントおよびすべてのメンバーアカウントの GuardDuty を設定し、さらに GuardDuty の結果を表示および管理できます。GuardDuty に最大 100 のメンバーアカウントを登録できます。
- メンバーアカウント
- 自分のアカウントの GuardDuty を設定し、さらに GuardDuty の結果を表示および管理できます。メンバーアカウントのユーザーは、他のメンバーアカウントの結果を表示または管理することはできません。
※AWS アカウントを同時に GuardDuty のマスターアカウントとメンバーアカウントにすることはできません。
マルチアカウントでの信頼できるIPリスト、脅威リスト
- マスターアカウントで設定した信頼できるIPリスト、脅威リストはメンバーアカウントには反映されません
招待方法
Amazon GuardDuty での AWS アカウントの管理 - Amazon GuardDuty
- ステップ 1 - アカウントを追加する
- ステップ 2: アカウントを招待する
- ステップ 3 - 招待を受け入れる
- メンバーアカウント側で「招待を承諾する」ボタンを押します。
- 事前に有効化していた場合でも、招待を承諾することで各種設定やログが消えることはありません。
- メンバーアカウント側ではアーカイブを実施することができません。
※招待を受け入れた後もメンバーアカウント側で自由に抜けることが可能です。抜けた後はアーカイブを実施することが可能になります。
最後に
組織を超えてAmazon GuardDutyの中央管理を行いたかったので、まとめてみました。
既にメンバーアカウント側でGuardDutyを有効化している場合も検知結果や設定はそのまま、マスターアカウント側で管理することが可能だったので展開自体はしやすいと感じました。
ただし、費用に関してはメンバーアカウント側でも発生して、マスターアカウント側ではメンバーアカウント側の費用も重複して発生しそうなのでコスト的にはデメリットとなるかもしれません。
また、メンバーアカウント側でアーカイブ機能に制限があり、いったんメンバーから離脱しないとメンバーアカウント側では検知されたイベントを消すことができないこともデメリットとなるかもしれません。
マルチアカウントにして、マスターアカウント側で管理することのメリットを明確にしないと、メンバーアカウントのメリットはわかりづらいというのが現時点での感想です。
ex) 社内のCSIRTと連携してインシデントレスポンスを迅速に行う。など
