Datadog AAP に 攻撃を見張ってもらうという選択

1. Datadog AAP に 攻撃を⾒張ってもらうという選択 hiroshi tokudomi / 株式会社タイミー プラットフォームエンジニアリング Japan Datadog User Group Meetup#24@東京
2. ⾃⼰紹介 徳富 博 所属 タイミー プラットフォームエンジニアリングチーム チームでやっていること セキュリティ o11y 開発⽣産性向上 パフォーマンスチューニング コスト管理 信頼性向上 インフラ構築 Embedded SRE 2
3. 最近、サーバー攻撃のニュースをよく⾒ かけませんか？ 3
4. いつ攻撃が来るかわからない時代 ⽉ • ⽕ ⽔ ⽊ ⾦ ⼟ ⽇ SQL インジェクションやスキャナーによる探索など、本番環境へのアクセスは、曜⽇も時間も選ば ない 攻撃は、こちらの都合を待ってくれない 4
5. 攻撃対応、⼈の⼿に頼ってませんか？ 気づく アラートを⾒る → 調べる ログやトレースを確認 → ブロック WAF に IP を登録 → 解除 あとで⼿動で外す ⼟⽇や夜間はすぐに動けないうえ、⼿動で⼊れた IP はあとで外す⼿間もかかる 正直、疲弊してますよね…… 5
6. これがずっと続くと思うと 頭が痛い…… Datadog に⾒張ってもらえないだろうか？ 6
7. そこで⾒つけたのが Datadog AAP APM と同じトレーサーを⼊れるだけ datadog gem などをアプリに組み込むだけ AAP アプリの「中」で攻撃を検知‧防御 リクエストだけでなく、実際の処理まで⾒て判断 App and API Protection（旧 ASM） IP‧ユーザーを⼀定期間ブロック 期限が切れたら⾃動で解除 7
8. Datadog AAP は 2 段構え ① In-App WAF ② Detection Rules 1 リクエストごとに判定して遮断 検知結果を集計して、攻撃者を締め出す 通常の WAF ルール 1 リクエストのパターンで判定 RASP 実際の処理を⾒て判定 実体はアプリに⼊れたトレーサー （Ruby なら datadog gem） 今⽇の話 2 → 2 In-App WAF の検知を集計 IP‧ユーザーごとに数える しきい値を超えたら攻撃者と判定 例：同じ IP から何度も攻撃している 検知結果 3 アクション：Denylist に追加 今⽇の話 1 その IP を⼀定期間ブロック 1 件ずつ遮断する In-App WAF ＋ 繰り返す攻撃者を締め出す Detection Rules 8
9. 1 Detection Rules で IP ⾃動ブロック 2 RASP 9
10. 1 Detection Rules で IP ⾃動ブロック 2 RASP 10
11. 1. 攻撃者を Denylist に⼊れて⾃動ブロック 攻撃が 繰り返される → Detection Ruleで集計して 攻撃者と判定 → → Denylist に登録 期限が来たら ⾃動で解除 Denylist Denylist に⼊ると IP 203.0.113.5 → ユーザー user_12345 その IP‧ユーザーからの リクエストは全部ブロック ⽇々⼿でやっている IP ブロックを、Datadog が⾃動でやってくれる ※ ユーザー単位のブロックは、トレースにユーザー ID を付けていることが前提 11
12. Detection Rules にはいろいろなルールがある OWASP Top 10 系 ビジネスロジック系 カスタムルール • パスワードリスト攻撃 通常の WAF ルールの検知を集計 • 使い捨てメールでの登録 例：SQL injections attempts、スキャナー • 通常と異なる場所からログイン ⾃社のサービスに合わせ て、検知の条件を⾃分で作 れる attempts 系 exploited 系 RASP の検知を集計（→ 今⽇の話 2） 例：SQL injection exploited どのルールも、しきい値を超えたら⾃動ブロックにつなげられる 12
13. 1 Detection Rules で IP ⾃動ブロック 2 RASP 13
14. 2. RASP は「実際の処理」を⾒て⽌める RASP（Runtime Application Self-Protection）= In-App WAF の仕組みのひとつ リクエスト ' OR 1=1 -- → アプリの処理 SQL を組み⽴てる → RASP：SQL を実⾏する直前にチェック ⼊⼒のせいで SQL の構造が変わっていないか？ 変わる ＝ 攻撃が成⽴しそう 変わらない ＝ 攻撃は成⽴しない そのリクエストを検知‧ブロック そのまま実⾏（⽌めない） SQLi っぽい⽂字列かではなく、攻撃が成⽴しそうかで判断する SQL のほか、ファイルアクセス‧外部への通信‧コマンド実⾏の直前も⾒ている（SQLi / LFI / SSRF / コマンドインジェクション） ※ 対応範囲は⾔語ごとに異なる。Ruby（datadog gem v2.15.0〜）は SQLi（ActiveRecord）と SSRF のみ 14
15. 全体像 アプリの中（トレーサー）で判定 Datadog 上で、送られてきた検知結果を集計して判断 送信 → ① In-App WAF 通常の WAF ルール リクエストのパターンで判定（ブロック ∕検知） ② Detection Rules 系 → attempts 通常ルールの検知を集計 ③ Security Responses どのルールからでも ブロックにつなげられる 今⽇の話 2 RASP 系ルール 実際の処理で判定（ブロック∕検知） 今⽇の話 1 exploited 系 → RASP の検知を集計 Denylist に追加 → その IP‧ユーザーを⼀定期間ブロック ビジネスロジック系など 期限が来たら ログイン試⾏などを集計 ⾃動で解除 検知 → 集計して判定 → ⾃動ブロックまで、Datadog がやってくれる 15
16. 多層防御の「最後の防衛ライン」にぴったり AWS WAF ⼊⼝で明らかな攻撃を落とす Detection Rules RASP 繰り返し攻撃してくる IP‧ユーザーを締め出す 成⽴しかけた攻撃だけを⽌める ※ 弊社は AWS 環境のため AWS WAF を例にしています（ Cloudflare などほかの WAF でも考え方は同じ） 16
17. ほかにもできること（さらっと紹介） Endpoint Scanning API Inventory 攻撃者分析 外から叩いて公開‧認証を確認 OWASP API Top 10 でスコア化 認証の有無や、個⼈情報‧カー ド番号を扱っているかなどを⾃ 動で棚卸し 脅威インテリジェンスで怪しい IP かを判定。攻撃がどこまで届 いたかをトレースで追える 17
18. まとめ 1 攻撃元を期限付きで⾃動ブロック 2 IP でもユーザーでも⽌められ、期限が来たら⾃動 で解除 3 AWS WAF と重ねて多層防御 ⼊⼝は AWS WAF、攻撃者の締め出しは Detection Rules、最後の砦は RASP RASP で成⽴しかけた攻撃だけ⽌める ⾒た⽬ではなく実際の処理で判定できる 4 ほかにもいろいろできる API のスキャンや棚卸し、攻撃者の分析まで 定型的な対応を自動化し、人は状況の判断と継続的な改善に集中しよう 18