自動化と人工知能（AI）によるセキュリティ態勢の強化に費やした費用が、結果的にはるかに大きな節約になることを知ると、驚かれるかもしれません。 IBMセキュリティチームは、Cost of a Data Breach 2021 Reportの中で、セキュリティ侵害が発生した場合、自動化とAIを導入していない組織では、導入している組織と比較して、平均80％以上のコストがかかることを明らかにしています。（平均で671万ドル対290万ドルと、381万ドルもの差があります）セキュリティの自動化とAIを優先することで、組織はセキュリティ侵害をより迅速に特定し、封じ込めることができ、費用と時間の両方を節約することができます。
(出典: Cost of a Data Breach 2021 Report)
しかし、セキュリティをCI/CDパイプラインに統合する際には、ツールに過度の負荷をかけないようにすることが重要です。トラフィックを検査する回数が少なければ少ないほど、遅延が発生しにくくなります。ビジネスにおいては、技術的な複雑さは迅速性を損なうことになります。
F5 NGINXでは、シームレスな統合と、ソフトウェア開発のライフサイクルの中で、チームの「shift security left」を支援可能な、ユニークなセキュリティプラットフォームを提供しています。組織が「コードとしてのセキュリティ」をCI/CDパイプラインに統合すると、セキュリティの自動化とAIの活用が可能になり、IBMが説明したような莫大なコスト削減につながるのです。アプリケーションとAPI開発の各段階にセキュリティが組み込まれることで、設定ファイルとセキュリティポリシーファイルがコードとして利用でき、SecOpsチームはDevOpsがアプリを構築する際に使用する宣言型のセキュリティポリシーを作成および維持することが可能となります。これらの同じポリシーを新しいアプリに繰り返し適用することで、セキュリティをCI/CDパイプラインの自動化で利用することができます。
F5 NGINX App ProtectとF5 NGINX Plusがセキュリティ保護の自動化を支援するトラフィック処理の3つのフェーズについて、一歩進んだ説明をします。
- フェーズ1 – F5 NGINX App Protect DoSは、サービス妨害（DoS）攻撃を検知し、防御することができます。
- フェーズ2 – F5 NGINX App Protect WAFはOWASP Top 10攻撃と悪意のあるボットから保護します。
- フェーズ3 – F5 NGINX Plusは、ネイティブ機能とサードパーティのシングルサインオン（SSO）ソリューションとの統合により、アプリとAPIクライアントを認証し、認可要件を実行します。
これら3つのセキュリティソリューションは、特にパブリッククラウド環境において、2つの方法でコストを削減します。
- NGINX App Protect DoSはDoS攻撃によるトラフィックをフィルタリングし、さらにNGINX App Protect WAFはOWASP Top 10などの複数の攻撃形態を排除するので、アプリには正規のトラフィックのみが到達します。
- NGINX Plusの非常に効率的なイベントドリブン型の設計は、CPU消費を抑えながら1秒間に膨大な数のリクエストを処理できることを意味します。高効率のプラットフォームで正当なアプリケーショントラフィックのみを処理することにより、必要な計算リソースが大幅に減少し、時間とコストが節約され、ツールに負担をかけずに複数の攻撃形態に対する防御を確保することができます。
現在、F5 BIG-IP Advanced WAFを使用してデータセンターで実行されているアプリを保護している場合、NGINX App Protect DosとWAFを備えたKubernetes用のIngressコントローラとしてNGINX Plusを追加し、最新のアプリケーションを拡張して保護し、クラウドでKubernetesアプリをオーケストレーションできる総合ソリューションとして、簡単に利用することが可能です。F5の”security-as-code”アプローチを使用すると、宣言型APIまたはファイル内の宣言型JSON形式の定義を介して、インフラストラクチャとセキュリティポリシーのコントロールをコードとして定義でき、BIG-IP XMLファイルをJSONファイルに変換することも可能です。ポリシー（SecOpsが所有し維持する標準的な企業セキュリティ管理）はコードリポジトリに存在し、他のコードと同じように開発パイプラインに取り込まれ統合されることが可能です。このアプローチは、DevOpsとSecOpsが運用上のギャップを埋め、低コストと優れたセキュリティでアプリをより早く市場に投入するのに役立ちます。
F5では、WAFのポリシー構築とベースラインを開発プロセスに組み込み、アプリケーション開発パイプラインにおける”shifting security left”とアプリケーションデプロイメントの自動化の重要な一端を担っています。
BIG-IPとNGINXの可視化ツールは互いに補完し合い、DevOpsライフサイクルの自動化プロセスを早期に構築することを可能にします。BIG-IPでは、XMLファイルをNGINXで使用されるJSONファイルに変換し、一貫したセキュリティポリシーを維持することができます。NGINXにより、チームはすでに導入されているアプリを微調整しながら、最新のアプリセキュリティ自動化を実現し、将来の侵害とその潜在的な攻撃のコストを相殺することができます。
フェーズ1：NGINX App Protect DoSによるDoS攻撃への防御
トラフィック管理の安全性を確保するための最初のステップは、サービス妨害（DoS）攻撃を排除することです。初期の段階でこの攻撃を排除することが、最初に必要となる防御策です。
攻撃者が従来の大量の通信による攻撃から、HTTP や HTTPS のリクエストや API コールを使ってレイヤ 7 を攻撃するようになりつつあることは、以前にも述べたとおりです。これはなぜでしょうか。攻撃者は、最も阻害される可能性の低い経路を辿っています。インフラエンジニアは、レイヤー 3 とレイヤー 4 の攻撃に対する効果的な防御策を何年もかけて構築し、ブロックしやすく、攻撃が成功する可能性を低くしてきました。レイヤー7攻撃は、このような従来の防御策を回避することができます。
すべてのDoS攻撃がボリューム攻撃である訳ではありません。Slow POSTやSlowlorisのような「低速でゆっくりとした」手法でサーバーリソースを消費するように設計された攻撃は、正当なトラフィックの中に簡単に隠れることができます。また、gRPC のようなオープンソースの HTTP/2 リモートプロシージャコールフレームワークは、最新のアプリケーションに必要な速度と柔軟性を提供しますが、その特徴であるオープンな性質が、独自のプロトコルよりも DoS 攻撃に脆弱である可能性をはらんでいます。
従来のDoS対策とは異なり、NGINX App Protect DoSは、自動化されたユーザーとサイトの行動分析、プロアクティブなヘルスチェック、ノータッチ設定を活用することで、現在の攻撃を検出します。HTTP GET flood、HTTP POST flood、Slowloris、Slow read、Slow POSTなどの一般的な攻撃を阻止する低レイテンシーのソリューションです。
これらの攻撃と戦うために、SecOpsとDevOpsチームは、CI/CDワークフローに「コードとしてのセキュリティ」による自動化を統合する必要があります – これらは“shift left”の考え方の一部です。NGINX App Protect DoSが、これを可能にするのです。また、DoSの驚異に対する高度な防御により、近年の分散アプリケーションやAPIを保護し、軽量なソフトウェアパッケージ、継続的な脅威に対するフィードバックループ、RESTful API を活用したDevOpsが馴染みのある ツールを統合するこのモデルが、SecOps と DevOps で時折対立してしまう優先順位の調整に役立ちます。
NGINX App Protect DoSは、IBM Security reportが大幅なコスト削減のキーとして強調している機械学習（ML）技術を統合しています。クライアントの挙動とアプリケーションの健全性を分析して正常なトラフィック パターンをモデル化し、正確な通信の保護を提供する動的な統計モデルの作成による独自のアルゴリズムを利用し、動的にシグネチャを構成し攻撃を自動的に軽減します。また、軽減による効果を継続的に測定し、動作やアプリケーションの健全性の変化に適応します。これらの機能により、NGINX App Protect DoSは一見すると正規の通信となる攻撃者からのDoS攻撃のブロックを可能とすることができます。
フェーズ2：NGINX App Protect WAFはOWASP Top 10を保護
DoS 防御は、悪意のあるトラフィックがインフラに侵入するのを阻止しますが、攻撃はその網をもかいくぐって到達を試みます。そのため、完全な防御を実現するための次の段階として、Webアプリケーションファイアウォール（WAF）が必要となります。
軽量かつ高性能なNGINX App Protect WAFは、レスポンスの検査、HTTPプロトコル準拠の強化、回避技術の検出、Data Guardによるクレジットカード番号やその他の機密性の高い個人情報のマスク、許可されないメタキャラクタやファイルタイプ、不正なJSONやXML、機密性の高いパラメータのチェックなど、包括的にセキュリティを保護する機能を提供します。また、最新の OWASP Top 10に示された脅威 からも保護することが可能です。
-
A01:2021: アクセスコントロールの不備
A02:2021: 暗号化の失敗
A03:2021: インジェクション
A04:2021: 安全でない設計
A05:2021: セキュリティの誤設定
A06:2021: 脆弱・時代遅れのコンポーネント
A07:2021: 本人確認・認証の失敗
A08:2021: ソフトウェアとデータの不整合
A09:2021: セキュリティログと監視の失敗
A10:2021: サーバーサイドリクエストフォージェリ
A03:2021 インジェクションのようなOWASP Top10の驚異に示されるサイバー攻撃が依然として盛んなのは当然のことです。2021年7月、オープンソースのeコマースサイト「WooCommerce」は、同社のプラグインの多くがSQLインジェクションに対して脆弱であり、複数の攻撃が発生していることを発表しました。企業や顧客はオンラインを主として活動しているため、攻撃者がWebベースのアプリに注目するのは合理的です。多くの場合、Webアプリは複雑で、マイクロサービスで構成され、多くのAPIで接続する分散環境にまたがっており、攻撃者の対象となるエンドポイントの数が増えているのです。
また、近年の攻撃はこれらの変化に素早く適用します。ここで登場するのがAIであり、IBMがその重要性を指摘した理由でもあります。NGINX App Protect DoSと同様に、NGINX App Protect WAFの優れたMLシステムにより、Platform Ops、DevOps、SecOpsチームで攻撃の傾向やデータを簡単に共有することができます。新機能の1つであるAdaptive Violation Rating機能は、アプリケーションの挙動の変化を検出することで、MLをさらに活用することができます。このML機能により、NGINX App Protect WAFは、各アプリケーションについて予測した動作を常に評価します。この学習に基づいて、他の方法ではブロックされるクライアントリクエストを有効にし、アプリケーションの違反評価スコアを下げ、誤検知を大幅に減らすことで、管理コストを抑えながらより良いユーザーエクスペリエンスを提供します。
NGINX App Protect WAFはボット保護機能も備えています。現在、インターネットトラフィックの約50％はボットによるものです。NGINX App Protect WAFは、既知の悪意のあるトラフィックを前もって排除することで、Botシグネチャデータベースを使用してボットトラフィックを迅速にブロックすることができます。
CI/CDパイプラインの早い段階でセキュリティ層としてWAFを導入することで、セキュリティリスクを軽減することができます。NGINX App Protect WAFはCI/CDに対応しているため、アプリケーション開発プロセスの早い段階でセキュリティをコードとして組み込んで自動化することができます。早期のセキュリティ認識とチーム間の適切な連携により、納品リスクなどのボトルネックも解消されます。DoSとWAFの多段階防御は、複数の検査を実施でき、セキュリティチームはアプリケーションの使用状況を可視化し、アプリケーションチームはそれらがどのように維持されているかを把握することができます。
フェーズ3：NGINX PlusによるアプリとAPIクライアントの認証と認可
NGINX App Protect DoSとNGINX App Protect WAFが悪意のあるトラフィックを排除した後でも、クライアントが正当であり、要求しているリソースへのアクセスが許可されていることを確認する必要があります。そこでNGINX Plusが登場します。認証と認可を行い、リクエストを適切なサーバーにルーティングします。NGINX PlusをAPIゲートウェイとしてデプロイすることで、複数のAPIに1つの一貫したエントリーポイントを提供でき、スタックを簡素化することができます。
認証と認可はシングルサインオン（SSO）により自動化され、DevOpsチームが求める俊敏性を維持することも可能です。NGINX Plusは、OAuth 2.0プロトコルの上にあるIDレイヤーである OpenID Connect（OIDC）をサポートしています。NGINXのドキュメント、how to use OIDC to enable SSO for applications proxied by NGINX Plusで説明しています。
APIは元来オープンな性質を持つことから、攻撃のターゲットとなっています。Gartner Researchは年次報告書の中で、2022年中にAPIが最も一般的な攻撃の標的となり、企業のWebアプリケーションに無数のデータ侵害を引き起こすだろうと予測しています。我々が2022年の経験からも、組織全体においてAPIが攻撃対象となった事象が増加し続けていることを見ると、この予測は真実であると感じられます。
「F5 Labs が提供する API Authentication Incidents: 2020 Application Protection Report 」は、APIインシデントの一般的な理由を3つ挙げています。
APIエンドポイントでの認証がない
APIトラフィックに対する認証を実装した場合、アイデンティティが正当であると証明されたクライアントは、信頼されたIDプロバイダーからトークンを受け取ります。その後、クライアントは各HTTPリクエストでアクセストークンを提示します。リクエストがアプリケーションに渡される前に、NGINX Plusはトークンを検証し、トークンにエンコードされているIDやその他のデータ（グループメンバーなど）を抽出して、クライアントの認証と認可を保証します。トークンが検証され、クライアントがリソースへのアクセスを許可された場合、リクエストはアプリケーションサーバーに渡されます。この検証を行う方法はいくつかありますが、OpenID Connect (OAuth 2.0 プロトコルに基づく) は、API リクエストのサードパーティ認証を可能にする一般的な方法として知られています。
しかし、市場にある多くのAPIは認証による保護がなされていません。2021年、対話型フィットネスプラットフォームの PelotonがAPIを漏洩していたことが明らかになりました。あるセキュリティ研究者が、PelotonのAPIに認証されていないリクエストを行い、認証なしで簡単にユーザーデータを取得できることを発見したのです。Pelotonは重大な侵害を受ける前にコードを修正しましたが、この災難は、セキュリティに対するモノリシックなアプローチが、API構造に内在する多様性と、その結果として生じる防御の俊敏性の必要性を考慮していないことを浮き彫りにしています。
API認証の不備
APIはコンピュータ間を接続するために設計されているため、多くのDevOpsチームは人間がAPIエンドポイントと通信することはないと想定しています。F5 Labsのレポートにある例では、あるモバイルアプリで数十万ドルのクレジットを「獲得」するために、複数のAPIリクエストを連続して利用したという研究者が登場します。このアプリは、不正使用を防ぐためトークンを定期的に生成していましたが、それらに有効期限を設定しなかったため、何度も繰り返し使用することができる状態となっていました。
適切にAPI認証トークンを検証しないと、攻撃者はAPIの脆弱性を悪用することが可能となってしまいます。この種の脆弱性が研究者ではなく、悪質な行為者によって発見された場合、ビジネス全体が危険にさらされる可能性があります。
API認可の不備
正しく動作しないAPI認証は、当然ながらAPI認可の破綻につながります。F5 Labsのレポートでは、オペレーティングシステムのバグがあるために、APIへの悪意のあるHTTPリクエストが可能になり、悪質な業者が認証トークンに容易にアクセスできるようになった事件も紹介されています。攻撃者はこの認証トークンを手に入れた結果、管理者権限の奪取が可能となりました。
NGINXは、APIを保護し、APIクライアントを認証するためのいくつかのアプローチを提供しています。詳細については、IPアドレスベースのアクセス制御リスト（ACL）、デジタル証明書認証、およびHTTP Basic認証のドキュメントを参照してください。さらに、NGINX PlusはAPI認証用のJSONウェブトークン（JWT）の検証をネイティブでサポートしています。詳しくは、ブログ「Authenticating API Clients with JWT and NGINX Plus 」をご覧ください。
今すぐ始める
セキュリティの自動化により、セキュリティ対策はすべての人の責任となります。セキュリティの自動化を優先することで、より信頼性の高いアプリを構築し、リスクを軽減し、運用コストを削減し、リリース速度を加速させることができます。これは、マイクロサービス、アプリ、および API が、今日の競争に追いつくために十分なスケーラビリティと速度を備えたアジャイル・セキュリティを得られることを意味します。
この記事で紹介した3つのフェーズによるセキュリティ構造は、最適なフローも提供します。これは、DoS 攻撃によってトラフィックを検査する WAF を停滞させたり、悪意を持った攻撃者を認証および承認しようとして貴重なリソースを浪費したりしたくないためです。簡単に特定できる攻撃を早期に排除することで、時間と費用を節約し、アプリのパフォーマンスを加速させることができます。
NGINX PlusとNGINX App Protectをご自身で試す準備はできましたか？今すぐ 30日間の無料トライアルを開始するか、お客様のユースケースについてご相談ください。
