GuardDuty — 防犯カメラの正しい使い方

防犯カメラと警備員の違い

こんにちは。今日のテーマはGuardDutyなんですが、最初に大事な誤解を解いておきたいんですね。

GuardDutyって何か。って聞かれてね、多くの人が「AWSが悪意のある活動を止めてくれるサービス」だと思ってるんですよ。ここが最大の落とし穴です。

想像してください。ビルの防犯カメラとビルの警備員の違いを。防犯カメラは何が起きてるかを見張ってる。「あ、不審な人物がロビーにいるな」って記録して、通知する。でも、カメラは手を動かさない。

警備員は「不審な人物がいる。止めろ」って指示が来たら、その人を止める。実際に物理的に動く。

GuardDutyは防犯カメラです。警備員ではありません。つまり、GuardDutyが検出した脅威に対して、実際の防御アクションは自分たちが用意しなくてはいけない。これが試験でよく狙われるポイントです。

GuardDutyは「検出」エンジン。防御ではなく、通知です。ここを理解できてない人が、本番環境で「え、GuardDutyは攻撃を止めないの」って失望するんですよ。

では、このカメラは何を見てるのか。ここからが重要です。

三つの目（3つのデータソース）

GuardDutyが持ってるデータソースを、僕は「三つの目」って呼んでるんですよ。それぞれ違う視点でAWSを監視してます。

目その一：CloudTrail（API呼び出しの目）

CloudTrailはね、誰が何をしたか を見てるんです。すべてのAPI呼び出しのログを拾ってきて、その中から異常なパターンを検出する。

例えば、こんなケース。IAMユーザーが「突然フィリピンから管理コンソールにログイン」。不正アクセスの兆候。KMSキーを大量に削除しようとした。ランサムウェア活動の可能性。侵害されたアクセスキーで異常なAPIが呼ばれてる。認証情報漏洩。

CloudTrailの視点は「誰かが何をしようとしたか」なんですね。

目その二：VPC Flow Logs（ネットワークトラフィックの目）

こちらはね、ネットワーク通信の流れ を見てます。どのEC2インスタンスが、どこに向かって通信してるか。特に検出するのは、既知の暗号通貨マイニングプールへの通信。不正な採掘活動。C&Cサーバー、つまりCommand & Control との通信。ボットネット感染。異常な出力ポートでのSSH試行。スキャン活動。

ここでの重要な比喩が「通信の相手が悪人名簿に載ってるかどうか」ということです。GuardDutyは、世界中の脅威インテリジェンスと照合して「あ、この相手は過去に悪さしてた」って判断するわけです。これ、すごい仕組みなんですよ。

目その三：DNS ログ（ドメイン問い合わせの目）

最後の目がDNS。EC2がどんなドメインに問い合わせしてるか見てます。なぜこれが重要か。マルウェアは大抵、C&Cサーバーと通信するのにドメイン名を使うんですね。そしてそのドメイン名は、セキュリティベンダーが「あ、これは悪いドメインだな」って既に認識してるケースが多い。

例えば、ビットコイン採掘プールのドメイン。mining.badpool.com みたいなやつ。DGA、つまりDomain Generation Algorithm で自動生成された怪しいドメイン。既知のマルウェアC&Cドメイン。

これら三つの目が常に働いてる。CloudTrailで「何をしたか」、VPC Flow Logsで「誰と通信したか」、DNSで「どのドメイン名に関心があるか」。複合的に見ることで、初めて「あ、これはマルウェア感染してるな」って判断ができる。

さらに広がる「見張りの視野」

ただし、三つの目だけじゃ足りないんですね。AWSはさらに細かく、いろんな層で監視できるようにしたんです。

S3の異常検出。S3のアクセスパターンを見て「あ、今日はいつもと違う動きをしてるな」ってやつです。例えば、ListBucket と GetObject を何千回も実行。ランサムウェアがデータを盗み出す前に何があるか調査してる。権限のないアカウントから大量のアクセス。アクセスキーが盗まれた。

EKS、つまりKubernetesの脅威検出。コンテナの世界も見てます。管理者権限、つまりprivileged でPodを起動してる。悪さを企ててる可能性。異常な数のPodが生成されてる。CronJobで不正なコンテナを大量起動。

Lambda関数の監視。サーバーレス環境でも見張ってます。Lambda関数がC&Cサーバーと通信。無視できない。Torネットワーク経由でLambdaが呼ばれてる。強い匂いがする。

RDSのログイン異常。データベースへのアクセスパターンも見てる。普段と違うブルートフォース試行とか、ね。

EBSマルウェアスキャン。これはちょっと特殊で、オンデマンドで EC2のボリュームをスキャンして、既知のマルウェアが入ってないか調べるやつです。

GuardDutyは見張りの範囲を、クラウド全体に広げている。その目の広さが、脅威検出の精度を上げてるんです。

具体的な脅威シナリオ

では、実際にGuardDutyが何を検出するのか、具体的に見てみましょう。

シナリオ1：暗号通貨マイニング感染

ある日、開発チームのEC2インスタンスがね、突然、リソースを大量に消費し始めた。実は、そのインスタンスには古いバージョンのアプリケーションが乗ってて、その脆弱性を突いて、攻撃者がマイニングスクリプトを挿入してた。

GuardDutyはどう検出するか。1番目、DNS ログ。mining.pool.xyz へのドメイン問い合わせ。2番目、VPC Flow Logs。既知のビットコインマイニングプール IP への通信。3番目、CloudTrail。誰も指示してない EC2 インスタンスが CloudWatch Logs に異常なパターンを出力。

Finding型は「CryptoCurrency:EC2/BitcoinTool.B!DNS」。重大度は「中」、つまり5から7くらい。お金が盗まれてるわけではないけど、計算資源は盗まれてますね。

シナリオ2：認証情報漏洩による不正アクセス

営業担当者のノートパソコンがマルウェアに感染して、IAMアクセスキーが盗まれた。攻撃者はそのキーを使ってAWSに侵入して、データベースのバックアップをダウンロードしようとしてる。

GuardDutyはどう検出するか。1番目、CloudTrail。営業担当者のキーが、いつもと違う IP から使われてる。2番目、CloudTrail。フィリピン、つまり営業拠点ではないところから管理コンソールログイン試行。3番目、S3 アクセス異常。バックアップバケットに対して、異常な GetObject 呼び出し。

Finding型は「UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration」。重大度は「高」、つまり7から8.5。認証情報が外部に漏れて、実際に使われてるのは深刻です。

シナリオ3：ランサムウェア前の偵察活動

攻撃グループが、まずはターゲットを偵察してる段階。やることは、S3 バケットを列挙したい。ListBucket 大量実行。データの量や位置を把握したい。メタデータをスキャン。どのリソースが重要か探る。CloudTrail の API 呼び出しパターンを見る。

GuardDutyはどう検出するか。1番目、S3 アノマリ検出。いつもと違う ListBucket の頻度。2番目、CloudTrail。権限昇格を狙った API コール。AssumeRole 呼び出し。3番目、IAM ユーザー異常。通常時と違うコンソールアクセスパターン。

Finding型は「Recon:S3/BucketEnumeration.Intentional」。重大度は「中から高」、つまり6から7。まだ実害は出てないけど、非常に危険な兆候。

ここ、試験でよく出ますね。「GuardDutyが検出する脅威の段階」を理解することが、合否を分ける。

検出後の戦い

さて、ここが試験でも実務でも最重要なポイントです。GuardDutyが検出した。では、誰が防御するのか。答え、自分たちです。GuardDutyは「見張り」。見張りが「侵入者がいます」って通知するのが仕事。その後の「警備を強化する」「侵入者を追い出す」「ドアを施錠する」は、自分たちが用意しなくちゃいけない。

自動修復パイプラインの構図

GuardDuty Finding、つまりファインディングが出て、EventBridge がそれをキャッチして、Lambda が自動修復アクション実行して、実際の防御が動く。

具体例を見てみましょう。暗号通貨マイニング検出時。1番目、GuardDuty が Finding を生成。2番目、EventBridge が「あ、Crypto Finding だ」って検知。3番目、Lambda が起動して、該当 EC2 インスタンスの SecurityGroup を「隔離用」に変更。4番目、インスタンスは世界と通信できなくなる。マイニングも止まる。5番目、セキュリティチームに SNS で通知。人間が調査・復旧。

では、認証情報漏洩のケース。1番目、GuardDuty が Finding を生成。2番目、EventBridge が「あ、Unauthorized Access だ」って検知。3番目、Lambda が起動して、該当 IAM ユーザーのアクセスキーをすべて無効化。4番目、攻撃者は使えるキーがなくなる。5番目、SNS で通知。実ユーザーが「あ、自分のキー盗まれた」って気づく。

防御は自動化できる。だから設計が大事。試験では「GuardDuty だけでは攻撃は止まらない」「EventBridge と Lambda を組み合わせて初めて防御になる」ってのが狙われます。

複数アカウント管理の現実

では、現実的な話をしましょう。企業のAWS環境ってね、大体は複数アカウントで運営されてます。開発環境、ステージング、本番環境が別アカウント。あるいは、部門ごとに異なるアカウント。

そうなると、GuardDutyをどう管理するのか。アカウントAでDetector、つまりディテクターが動いて、アカウントBでも Detector が動いて、アカウントCでも。バラバラだと、セキュリティチームが狂いますね。

AWS はここで「Organizations 統合」っていう仕組みを用意したんです。Management Account、つまり親アカウントで Organizations を管理して、その下で Delegated Admin Account、つまり委任管理者アカウント、これはセキュリティ専任のアカウントですね、が、他のアカウント A、B、C の Finding を管理できるわけです。

つまり、セキュリティ専任アカウントが、全アカウントの GuardDuty Finding を一元管理できるってわけです。

メリットは、セキュリティチームが 1 ヶ所で全社の脅威を見守れる。自動修復ロジック、つまりLambda をセキュリティアカウントに集約できる。新規アカウント作成時に自動的に Detector が有効化される。

やり方は、Management Account で「セキュリティアカウントを委任管理者として登録」して、セキュリティアカウント側で「うん、管理します」って許可。完了。

試験では「マルチアカウント環境で GuardDuty をどう管理するか」ってよく聞かれます。答えは「Organizations 統合で委任管理者を指定」。覚えておいてください。

よくある間違い

試験でも実務でも、こんな誤解をしてる人が多いんですね。

誤解1：「GuardDuty が攻撃を止めてくれる」

違います。GuardDuty は検出。防御は自分たちの仕事。WAF があればリクエストを遮断できるし、SecurityGroup があれば通信を遮断できます。でも GuardDuty 単独では何も止まりません。

誤解2：「全リージョンで自動的に有効化される」

違います。各リージョンで明示的に有効化する必要があります。東京リージョンで有効化しても、大阪リージョンでは何も見張ってません。試験では「シドニーで API 権限昇格があったのに検出されなかった」みたいな引っ掛け問題がよくあります。答えは「シドニーリージョンで GuardDuty Detector が作成されていない」。ここ、本当に出ます。

誤解3：「CloudTrail を有効化していれば十分」

違います。CloudTrail は GuardDuty の一部のデータソースに過ぎません。CloudTrail だけでは VPC Flow Logs や DNS ログの異常は検出できません。GuardDuty 自体を有効化する必要があります。

誤解4：「すべての脅威を検出できる」

違います。GuardDuty が見てない層の脅威は検出できません。例えば、アプリケーションレベルの脆弱性。SQLインジェクションは見てません。ホスト内部のマルウェアも、EBS ボリュームスキャンを明示的に実行しないと見えません。

誤解5：「Finding を出したら、すぐに対応しなくてもいい」

違います。Finding は「今、脅威が存在する可能性がある」という信号。確実に対応する仕組みを作っておかないと、検出されても意味がありません。EventBridge と Lambda で自動化するか、最低でも SNS で即座に通知する仕組みが必須。

GuardDuty は「信号」。信号に応答する仕組みを、自分で用意する。ここを忘れずに。

他のサービスとの役割分担

最後に、GuardDuty の「周辺」を見ておきましょう。セキュリティサービスの総合戦です。

Security Hub との関係

Security Hub は「統合ダッシュボード」です。GuardDuty の Finding も、Inspector の脆弱性検出も、Config のコンプライアンス違反も、すべて一ヶ所に集約される。

やることは、Security Hub を有効化して、GuardDuty が Finding を生成して、Security Hub に自動的に反映。セキュリティチームが一元ビューで全脅威を監視。GuardDuty だけ見ててもダメ。Security Hub で全体像を把握する。

Detective との関係

Detective は「詳細な脅威分析」です。GuardDuty が「あ、インスタンスのクレデンシャルが流出した」って言ったら、Detective は「その IP はどこから来てるのか」「その間に他のリソースにアクセスしてないか」「データは盗まれてないか」って、グラフで可視化してくれる。

GuardDutyは「脅威がある」。Detectiveは「脅威の詳細な経路をビジュアル化」。

Inspector との関係

Inspector は「脆弱性検出」です。GuardDuty ではありません。GuardDutyは「外部から不正アクセスの兆候がある」。Inspectorは「このインスタンスに CVE-2024-12345 が存在する」。別の視点から脅威を見てます。

EventBridge + Lambda との関係

ここまで何度も出てきた相棒ですね。GuardDutyは「検出」。EventBridgeは「Finding をキャッチして振り分け」。Lambdaは「実際の修復アクション」。この三つが揃うと、初めて「自動化された防御」になります。

GuardDuty は点。他のサービスと組み合わせて線、面になる。

試験対策まとめ

では、SCS-C03 の試験出題パターンを、実体験に基づいて話しておきます。

必ず出る問題パターン

パターン1が「GuardDuty の役割は何か」。選択肢Aが「悪意のある通信を遮断する」。これはバツ。WAF や SecurityGroup。選択肢Bが「検出して通知する」。マル。選択肢Cが「脆弱性をスキャンする」。バツ。これは Inspector。

パターン2が「複数リージョンでの GuardDuty 有効化」。「シドニーでクレデンシャル流出が疑われるが検出されなかった。原因は」。「シドニーリージョンで GuardDuty Detector が作成されていない」。

パターン3が「マルチアカウント管理」。「複数アカウントの Finding を一元管理するには」。「Organizations で委任管理者を指定」。

パターン4が「自動修復パイプライン設計」。「高重大度の Finding 検出時に、自動的にリソースを隔離するには」。「EventBridge で Finding をキャッチして、Lambda で SecurityGroup 変更」。

パターン5が「Finding タイプの判別」。「マイニング活動が疑われる Finding は」。「CryptoCurrency:EC2/BitcoinTool」。「認証情報流出が疑われる Finding は」。「UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration」。ここ、よく引っ掛け問題になります。「Trojan」と「CryptoCurrency」の Finding 名を混同させるような問題が出ます。実務で何度か見た Finding 名を暗記しとくといいですね。

「できない」を聞く問題

試験はね、「何ができるか」と同じくらい「何ができないか」を聞いてきます。GuardDuty で SQLインジェクションを検出できるか。バツ。アプリレベル。GuardDuty でランサムウェアの侵入前段階を検出できるか。マル。CloudTrail で権限昇格試行など。GuardDuty 単独で攻撃を防げるか。バツ。自動修復パイプラインが必須。

SCS-C03 は「できる」「できない」の境界線を正確に見分けることが合否を分ける。ここを理解することが、試験合格への近道です。

最後に

これから先、AWSセキュリティの実務をやるなら、ここだけは肝に銘じておいてください。GuardDuty に期待しすぎるな。

GuardDuty は「見張り」です。見張りの報告を受けて、実際に何をするのかは、あなたたちが設計する。検出だけして「よし、セキュリティ対策は万全だ」と思ったら、最初から何も防げてません。

自動修復パイプラインがあるか。SNS 通知は動いてるか。Detective で詳細分析できる体制があるか。セキュリティチームの教育は十分か。すべてが揃って、初めて「GuardDuty を使ったセキュリティ対策」が完成します。

では、みなさんの試験合格と、実務での活躍を祈ります。これまでの4つの講義で、AWSセキュリティの基本、つまりIAM、KMS、CloudTrail、GuardDutyの全体像が理解できたと思います。次は実際の設計や運用で、この知識を活かしていってください。