Cloudflare導入による、全プロダクトへの高度なセキュリティ機能の展開と運用効率化
Sansan株式会社 / Takeshi Matsuda
チームリーダー / セキュリティエンジニア / 従業員規模: 1,001〜5,000名 / エンジニア組織: 301名〜500名
利用プラン | ツールの利用規模 | ツールの利用開始時期 | 事業形態 |
---|---|---|---|
Cloudflare Enterprise Service | 101名〜300名 | 2023年6月 | B to B |
アーキテクチャ
![アーキテクチャ図](https://cdn.findy-tools.io/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsibWVzc2FnZSI6IkJBaHBBbU1CIiwiZXhwIjpudWxsLCJwdXIiOiJibG9iX2lkIn19--61831a160aa8ec94864b62200602fa08d70bf7be/cloudflare_sansan.jpg?disposition=inline)
導入の背景・解決したかった問題
導入背景
導入前の状況・課題
Cloudflareの導入前は事業の規模によって利用する対策製品が異なり、それぞれで個別最適化された運用が定義されていました。そのため、事業によって使用している製品が異なり、ナレッジの共有が難しく、運用のサイロ化が発生していました。
また、各プロダクトでWebアプリケーションに対するセキュリティ対策製品や対応レベルが統一化されておらず、個別最適化によってセキュリティ運用の各工程にオーバーヘッドが生じるようになり、可視性や実効性が低下する恐れがありました。
目指していた状態
- 全プロダクトへWebアプリケーションに対する高度な攻撃を可視化及び対応できる機能を適用し、費用対効果を最大化し全プロダクトへ同水準のセキュリティ機能を展開
- インフラメンバーのセキュリティ運用コストを最小化しエンジニア全員が利活用しやすい状態
比較検討したサービス
- Akamai Kona Site Defender
- Fastly Next-Gen WAF
- Imperva Incapsula
比較した軸
- 現在よりも高度な攻撃を可視化及び対応できる機能
- 上記を活用しやすいプラットフォームを有していること
- Webアプリケーションのセキュリティ対策において費用対効果を最大化できること
選定理由
プラットフォームが洗練されており使いやすく、Cloudflare に関するナレッジも豊富に揃っていることから、エンジニア全体の運用コストを最小化できると感じたため。
導入の成果
全プロダクトで統制の取れた高水準のセキュリティ運用を展開・適用できるようになりました。ただ、Cloudflare の権限管理に柔軟性がなく、エンジニア全員が利活用しやすい状態には至っていないため、柔軟性の高い RBAC 機能の追加をリクエストしています。
Bot Management や DDoS Protection を活用し、最新の攻撃を含む可視性の向上と対応が可能になると共に、Cloudflare Workers や CDN を適用することでプロダクト全体の品質向上にも寄与できていることから、費用対効果を高く維持できています。
導入時の苦労・悩み
全社のWebアプリケーション対策に対する現状を整理し、基準含めた正確な必要ゾーン数・トラフィック量・リクエスト数を試算するのに苦労しましたが、SIEM に格納されていたデータ等を活用し全体の費用感を算出することができました。
導入に向けた社内への説明
上長・チームへの説明
現在の運用を続けていると近い将来課題が顕在化し、組織を標的とする大きな侵害への対応が難しくなると説明しました。加えて、このタイミングで Cloudflare に変更することによって Bot 対策や DDoS 対策等を柔軟に適用でき費用対効果を最大化できると説明しました。
社内・チームへの展開
セキュリティエンジニア・インフラエンジニア・PdM 含む全ての視点での課題を明確し、それらを Cloudflare がどのように解決するかを丁寧に説明し、当社のPremise である「セキュリティと利便性を両立させる」という一つの大きな目標に一致団結させるように推進しました。
活用方法
全社的にほぼ毎日、開発・検知状況確認やポリシー類見直しなど
よく使う機能
Cloudflare WAF
アカウントレベルとゾーンレベルでそれぞれ分かれており、最適化された運用フローを策定し、ぞれぞれで必要なポリシーを適用し攻撃の遮断や最新の攻撃傾向の可視化を行っている。特に Attack likelihood/Bot likelihood/Rate limit analysis は調査時に絶大な効力を発揮している。Cloudflare Workers
現在のところ主にメンテナンスページの表示に活用しており、サーバレスで切り替え手順も容易にしているCloudflare CDN
一部のプロダクトで先行適用しており、全体のパフォーマンス向上とオリジンへのリクエスト数削減に活用している
ツールの良い点
- プラットフォーム全体の作りがシンプルで使いやすく、最小の学習コストで誰でもすぐに扱える
- ゾーン数やトラフィック量、リクエスト数に応じた課金体系により契約範囲内であればプロダクトの規模に関わらず気軽に Cloudflare を適用し、セキュリティ対策レベルや対応品質を一定基準に引き上げ、共通化できる
- WAF の機能に留まらず、DDoS Protection や Bot Management、CDN、Workers などサービス運用品質改善にあると便利な機能が手軽に利用できすぐに展開できる
ツールの課題点
- アカウントごとにきめ細かい RBAC ができないため、権限が足りずにエラーになる等権限管理には大きな不満を感じている
- チューニング時の Exception Rule だけがルールセット化できないことにより、ルールが乱立化し、MSSP との協業運用において見通しやすさが低下している
- Logpush で SIEM に Firewall ログに Bot や WAF Attack Score が連携できないなどの制約があり、ログ量の多い HTTP リクエストログをもとに分析しなければならない
- OWASP ルールセットの有効化と無効化や、Exception Rule による Skip 動作に柔軟性が無く Block と Log を両立できない場合がある
その他
Cloudflareを使っている中で失敗したエピソード
Cloudflare Aegis を適用する際に最大同時接続数が公開されていない仕様に到達してしまい、一部のサービスに一定時間の品質低下を引き起こしてしまった。このような複雑な課題については解決に時間を要したり、サポート側に要因特定に必要なログが不足している等で対応に苦労したが、現在は徐々に改善されつつある。
ツールを検討されている方へ
マルチIaaS環境やオンプレでWAFを展開している等、現在の運用と将来性に課題を持っている場合は、Free や Business プラン、トライアルで費用対効果を試算してみると良いかと思います。
Sansan株式会社 / Takeshi Matsuda
チームリーダー / セキュリティエンジニア / 従業員規模: 1,001〜5,000名 / エンジニア組織: 301名〜500名
よく見られているレビュー
Sansan株式会社 / Takeshi Matsuda
チームリーダー / セキュリティエンジニア / 従業員規模: 1,001〜5,000名 / エンジニア組織: 301名〜500名
レビューしているツール
目次
- アーキテクチャ
- 導入の背景・解決したかった問題
- 活用方法