

中嶋悟
名前:中嶋 悟(なかじま さとる) ニックネーム:サトルン 年齢:28歳 性別:男性 職業:会社員(IT系メーカー・マーケティング部門) 通勤場所:東京都千代田区・本社オフィス 通勤時間:片道約45分(電車+徒歩) 居住地:東京都杉並区・阿佐ヶ谷の1LDKマンション 出身地:神奈川県横浜市 身長:175cm 血液型:A型 誕生日:1997年5月12日 趣味:比較記事を書くこと、カメラ散歩、ガジェット収集、カフェ巡り、映画鑑賞(特に洋画)、料理(最近はスパイスカレー作りにハマり中) 性格:分析好き・好奇心旺盛・マイペース・几帳面だけど時々おおざっぱ・物事をとことん調べたくなるタイプ 1日(平日)のタイムスケジュール 6:30 起床。まずはコーヒーを淹れながらニュースとSNSチェック 7:00 朝食(自作のオートミールorトースト)、ブログの下書きや記事ネタ整理 8:00 出勤準備 8:30 電車で通勤(この間にポッドキャストやオーディオブックでインプット) 9:15 出社。午前は資料作成やメール返信 12:00 ランチはオフィス近くの定食屋かカフェ 13:00 午後は会議やマーケティング企画立案、データ分析 18:00 退社 19:00 帰宅途中にスーパー寄って買い物 19:30 夕食&YouTubeやNetflixでリラックスタイム 21:00 ブログ執筆や写真編集、次の記事の構成作成 23:00 読書(比較記事のネタ探しも兼ねる) 23:45 就寝準備 24:00 就寝
GuardDutyとWAFの基本的な違い
GuardDutyとWAFは、セキュリティ対策の中でよく出てくる言葉ですが、それぞれの役割ははっきりと異なります。GuardDutyは「脅威を検知するサービス」であり、あなたのクラウド環境を絶えず監視して不審な挙動を見つけ出します。一方、WAFは「防御を実行するサービス」であり、ウェブアプリケーションに対する悪意あるリクエストを遮断します。つまりGuardDutyは“気づく人”、WAFは“門番”のようなイメージです。これらは同時に使うことで、侵入の初期段階でのブロックと、侵入後の検知・対応を両立させることができます。
実務ではこの2つを組み合わせ、攻撃の“入口を閉じる”と同時に“後から攻撃を探し出す”運用が基本形になります。
このような背景を理解することは、クラウドのセキュリティ戦略を設計する上でとても重要です。
GuardDutyとは何か
GuardDutyは AWS が提供する脅威検知サービスで、主に VPC フローログ、CloudTrail の管理イベント・データイベント、DNS クエリなどのログを自動的に分析します。エージェントを導入する必要はなく、AWS アカウントとリージョン単位で有効化するだけで機能します。機械学習と最新の脅威情報を組み合わせ、通常とは異なる挙動や潜在的な悪意の活動を検知します。検知結果は「ファインディング」としてダッシュボードに表示され、Security Hub など他のセキュリティサービスと統合して自動化ワークフローを設定することも可能です。検出の例としては、未知の IP からの不審な API 呼び出し、インスタンスの異常な挙動、データアクセスのパターンの変化などが挙げられます。実装時のポイントは、全アカウント・全リージョンでの有効化、適切な権限設定、そして検出結果をどう運用につなげるかという点です。警告を受け取るだけでなく、検知情報を自動化された対応に結びつけることが重要です。
WAFとは何か
WAFは Web Application Firewall の略で、ウェブアプリケーションに向かう HTTP/HTTPS のリクエストを検査し、SQLインジェクション(SQLi)やクロスサイトスクリプティング(XSS)などの一般的なウェブ攻撃をブロックします。WAF は前段の門番として機能し、悪意のあるリクエストをサーバーに到達させない状態を作ります。AWS では AWS WAF というマネージドサービスがあり、ルールの作成・管理を比較的簡単に行えます。ルールには「SQLi対策」「XSS対策」「地理的制限」などがあり、また「レート制限」ルールで短時間の過剰リクエストを抑制することも可能です。実運用では、CloudFront や ALB/API Gateway と組み合わせて使用し、HTTP ヘッダやクエリ文字列、IP アドレスなどを基にポリシーを細かく設定します。センシティブなデータを扱う場合には、検査ログを S3/CloudWatch に保存して監査可能性を高め、誤検知を減らすためのチューニングも重要です。導入時はまず基本的なルールセットを適用し、徐々に自社のリスクプロファイルに合わせてカスタムルールを追加するのが良いでしょう。
実務での使い分けと注意点
この二つのツールは、同じセキュリティの輪の中で補完的に動作します。実務での基本的な使い分けは、入口防御(WAF)と侵入検知(GuardDuty)を別々の層で実装することです。ウェブアプリの攻撃を未然にブロックしたい場合は WAF を前に置き、内部ネットワークの挙動を監視して未知のアクティビティを検知したい場合は GuardDuty を有効化します。運用のポイントとしては、まず GuardDuty を有効化して組織内の脅威の“パターン”を把握することです。次に WAF のルールを作成して、実際のリクエストを遮断する基盤を整えます。両者を Security Hub や Lambda を組み合わせて自動化することで、脅威が検知されたときの対応を迅速化できます。コスト面では GuardDuty は検出件数に応じた課金、WAF はルール数とリクエスト数に応じた課金になるため、利用規模に合わせて最適化が必要です。設定の際には false positives(誤検知)を減らすための検証ステップを組み込み、影響範囲を限定した段階的ロールアウトを心がけましょう。
今日は友だちとカフェで、GuardDutyとWAFの違いについて話していた。最初は“同じセキュリティの仲間”みたいに思えたけれど、話を深掘りすると役割がぜんぜん違うことに気づく。GuardDutyはクラウド環境の“監視員”で、怪しい挙動を教えてくれる。WAFはウェブの門番で、悪いリクエストを邪魔してくれる。二つを同時に使えば、入口を守りつつ内部で起きた未知の動きも拾い上げられる。自分たちのアプリを守るための基本的な考え方として、まずGuardDutyを有効にして脅威の傾向を把握し、次にWAFで具体的な防御ルールを作ると良い、という結論に落ち着いた。