**Cloudflareは、リクエストがそこを通り、通過後の負荷をアプリケーションが処理できるときに効果的にサイトを守ります。**1つの設定を有効にするだけでは、サーバーへの全経路は保護されません。
オンラインショップを考えます。攻撃者は商品画像に大量アクセスしたり、高コストの検索APIを連打したり、サーバーへ直接接続したりします。消費する資源が違うため、複数の層が必要です。
サイトの対応DNSレコードでプロキシを有効にします。訪問者はサイトを実際に動かすサーバーであるオリジンより先にCloudflareへ到達します。DNS-onlyのレコードは名前解決を行うだけで、HTTPトラフィックをこの保護経路へ通しません。
Browser -> Cloudflare -> Origin -> Database
これが土台です。Cloudflareのフィルターが役立つのは、そこへ到達する要求だけです。メインドメインだけでなく、APIを含むショップの全公開ホスト名を確認します。
攻撃者がオリジンに直接届くなら、フィルターを迂回できます。公開Webの着信を適切なCloudflareのIP範囲に制限し、その一覧を更新します。または、外向き接続を使い、公開Web着信ポートを不要にできるCloudflare Tunnelを検討します。
管理アクセスは別の保護経路にし、データベースはインターネットへ公開しません。Cloudflare経由の正常アクセスと、直接アクセスの拒否を両方試します。IPを隠すだけでは不十分です。オリジンの保護を参照してください。
マネージドDDoS保護と、契約プランで使える制御を確認します。適切なWAFルールも追加します。WAFはHTTP要求の不審なパターンを調べてから転送します。DDoS保護とWAFには重なる部分がありますが、異なる問題を扱います。通過した要求がすべてアプリにとって軽いことを保証するものではありません。
理由を説明できるルールから始め、影響したトラフィックを確認し、正規顧客を遮断する場合は対象を絞って調整します。遮断件数の多さ自体は成功指標ではありません。CloudflareのDDoS設定と調整も確認します。
キャッシュ済み画像の要求は、多数のDBレコードを調べる検索より、通常はオリジン負荷が小さくなります。通常の利用状況と背後のサービス容量に基づき、高コストのエンドポイントをレート制限します。
万能な安全閾値はありません。正規利用のピークを観察し、慎重に制限を入れ、バックエンド負荷の低下と誤って拒否した正規要求を両方測ります。
公開画像や静的ファイルをキャッシュし、反復する要求をオリジンに届かせず処理します。ショップでは、同じ商品画像を何度も配信する資源を減らせます。
個人のカートやアカウント画面は別のルールが必要です。他人のデータを返してはいけません。動的レスポンスをキャッシュする前に、キーとバイパス条件を確認します。キャッシュは反復作業を減らしますが、ログインや購入を自動的に過負荷から守るものではありません。
Under Attackモードは、障害時にブラウザ確認を追加できます。影響するブラウザ経路で適用を検討し、適切な時点で一時措置を解除します。機械クライアントや決済Webhookはブラウザ確認を完了できないことがあるため、適切な認証と対象を絞った制御が必要です。
最後に、オリジンの遅延、CPU、DB負荷、エラーを監視しながら、正規顧客が閲覧と購入を完了できるか確認します。直接のネットワーク攻撃でオリジン回線が飽和するなら、ホスティング事業者と上流の保護を調整します。目標は有用なサービスの継続であり、どんな攻撃でも停止しないという約束ではありません。
ジュニアからシニアまで、詳細な回答付きのIT面接質問ライブラリ。
寄付する