ハーフリング、ドラゴン、そして DDoS 攻撃
今日のアプリケーションにおける非常に一般的な制約は予算です。 セキュリティ予算は確かに増加しているかもしれないが、ハッキングに費用がかかりすぎるという戦略的アプローチに見合った割合ではない。
このアプローチは、次のように述べるハーフリング-ドラゴンの原則に似ています。
ハーフリングと気難しいドラゴンと一緒にいる場合は、ドラゴンを追い抜く必要はなく、ハーフリングを追い抜くだけでよいことを覚えておいてください。
自分の環境を攻撃するのにコストがかかりすぎるようにして、ドラゴンがその貪欲な目を競争相手であるハーフリングに向けるように仕向けるというアイデアです。
さて、倫理的な議論に踏み込むことなく言えば、環境をハッキングするにはコストがかかりすぎるようにするという考えは、悪いものではありません。
問題は、それがあなたにとっても高額すぎることを意味することが多いということです。 なぜなら、一般的に言えば、そのような戦略を実行するためのアドバイスには、大量のソリューションを購入し、それらを中世のガントレットのように投げ込み、新しい障壁を設置して、攻撃者が本当に欲しいもの、つまりデータに到達するためにそれを実行させる必要があるからです。 これにより、攻撃者は検出を回避するために攻撃を拡散させようとする際に、時間、労力、そして最終的にはお金を費やすことになり、攻撃者にとってコストが高くなります。 これは攻撃者だけでなく、企業にとってもコストがかかります。 各ソリューションは管理、更新、監視され、最終的には拡張される必要があるため、ソリューション (設備投資) だけでなく運用面 (運用コスト) も考慮する必要があります。
裏返しでもあります。 攻撃者が欲しがっているのはあなたのデータですが、私たちはデータから最も遠い地点、つまりネットワークの境界から防御と保護を構築する傾向があります。
では、実装コストが高すぎないようにしながら、顧客が望むものを手に入れるためのコストを高くするにはどうすればよいでしょうか?
これには万能の解決策はありませんが、攻撃コストを上げながらコストを抑える方法はいくつかあります。
1. プラットフォームを活用する
プラットフォームは、共通の環境を共有するという考えに基づいています。 仮想化とコンテナ化によってコンピューティング リソースの効率が向上するのと同じように、コストも削減されます。 たとえば、ADC はモジュールで拡張して、セキュリティを含むさまざまな配信機能をサポートできます。 多くの組織では、WAF やその他のセキュリティ関連機能の導入をサポートできる可能性のある負荷分散による可用性を確保するために、すでに ADC を使用しています。 総合的なソリューションとして、適切な ADC は、ポイント ソリューションとしての個々の機能の合計よりも、総コストがはるかに低くなります。
ロードバランサー自体の機能も調査する価値があります。 基本的な負荷分散とは異なり、ADC は通常、攻撃をより困難にするために使用できる、セキュリティに関連する多数のノブとレバーを提供します。 SYN フラッド検出、Cookie 暗号化、URL 難読化、IP/ポート フィルタリングは、多くの場合、負荷分散サービスの一部として利用できます。 アプリに近い部分の保護を強化すると、攻撃者がアクセスするのが難しくなります。
2. 運用化
一部の人にとっては残念なことであり、他の人にとっては喜ばしいことですが、アプリケーションのセキュリティ保護と拡張に必要なすべてを単独で提供できる「神の箱」はまだ存在しません。 複数のソリューションが必要になります (重要なのは、使用するプラットフォームの数を最小限に抑えることです。上記を参照)。つまり、複数のコンソール、管理パラダイム、そしておそらく人員が必要になります。 これらすべてがあなたの予算を吹き飛ばすでしょう。
自動化とオーケストレーションを可能にする運用化により、導入する必要のあるソリューションのコストを抑えることができます。 自動スケーリングなどの機能によって、（おそらく）すでに持っているリソースを活用してスケールアップし、攻撃者に同様の対応を強いることにより、防御コストを抑えながら攻撃コストを増加させることができます。
運用化（DevOps、SDN、SDDC、SDx、プライベート クラウドなど）では、人為的エラーやプロセスの欠如といった高リスクの原因にも対処します。 後者の場合、存在しないプロセス (ちなみに、これはオーケストレーションです) を自動化することはできません。 もし持っていないなら、ぜひ持ってください。 これにより、アプリを本番環境に移行する際に、アプリのセキュリティを確保し、拡張するために必要な手順が確実に実行されるようになります。 前者の人為的ミスは、セキュリティにうっかり穴を開けてしまい、悪意のある人物が直接、またはボリューム型 DDoS 攻撃の隙をついて侵入する可能性があるため、大きなリスクとなります。
3. スケールとしてのクラウド
自動スケーリングができなくなったり、帯域幅が圧迫されたりした場合は、常にクラウドを利用できます。 クラウドをスケールとして利用する（クラウド バーストとも言う）ことは、攻撃コストを上げながら効率的に防御できるようにする優れたオプションです。 攻撃中（または攻撃が最初に開始されたとき）に DDoS スクラビングと保護をクラウドに切り替えると、ビジネスへのローカルな影響（生産性と利益の尺度）を即座に軽減できるため、実際には防御コストが削減されます。 （ほぼ）無限の規模と大量の帯域幅を備えたクラウドに攻撃を吸収させれば、長期的にはコストは大幅に削減されますが、攻撃者にとってはそうではありません。
4. 内側から外側まで安全
前述のように、攻撃者は一般的にあなたのデータを欲しがります。 それは、あなたのデータ == 怪しげなオープン市場ではお金だからです。 したがって、境界の保護と同じくらい（できればそれ以上に）データの保護に重点を置いてください。 つまり、攻撃者が攻撃から価値を引き出す（データを取得する）のに非常に高いコストがかかるように、あらゆるトリックやテクニックを使用することを意味します。 そのためには、常に注意を払い、アプリに入力されるものだけでなく、出力されるものも保護する必要があります。 それがリクエストとレスポンスの保護です。
現在 WAF を導入している 2016 年のアプリケーション配信の現状に関する調査回答者の大多数 (67%) は、アプリケーション層 (リクエスト レスポンス) 攻撃に対する組織の耐性に自信を持っていました。 これらは、SQLi や XSS などの機能だけでなく、WebSocket セキュリティやセッション ハイジャック防止機能、そして攻撃者がデータを取得するのに多大なコストがかかることを保証するその他の豊富な機能です。
実際、3 つの攻撃対象領域 (クライアント、リクエスト、レスポンス) すべてにわたって一貫性のある保護が提供されると、アプリケーション層攻撃に耐えられるという信頼性が高まります。 これは「エッジ」機能ではなく、アプリ中心の機能です。 ネットワークのエッジよりもアプリに近い位置に配置され、ネットワーク攻撃を阻止することではなく、実際にデータを抜き取る攻撃を阻止することが目的です。 それは攻撃者が求めている価値であり、攻撃者が諦めて他の場所に行くほど高価にする必要がある価値です。
セキュリティを安くする方法はありません。 まったくないんです。 しかし、コストを抑えて、アプリのセキュリティを確保するために破産することなく、攻撃者にとってのコストをあなたよりも高くする方法があります。 そして、もしあなたがそれをうまく行い、あなたの防御が攻撃者に自身のリソース（とお金）をあまりにも多く消費させることを強いるなら、ドラゴンは半分にされるのを待つには疲れすぎている（お金がない）かもしれません。 そして、ハーフリングは自らの防御を有利に進めるチャンスを得ることになります。