BLOG

DevSecOpsがボット管理に取り組むべき6つの理由

Jim Downey サムネール
Jim Downey
Published July 21, 2022

このデジタル競争の時代では、すべての企業がテクノロジ企業であり、この時代のイノベーションは金融から食料品や輸送に至る産業を混乱に陥れてきました。現代のテクノロジ企業として成功するためには、競合他社よりも迅速なイノベーションが必要です。迅速なイノベーションには、DevOpsが必要です。DevOpsは、開発者とIT運用部門のコラボレーションであり、ソフトウェア デリバリにリーン原則を適用することにより製品リリースのペースを飛躍的に向上させる火付け役となりました。DevOpsの約束にもかかわらず、ボット攻撃やセキュリティに関するその他の懸念は、適切に対処されないと、組織がメリットを享受できなくなる可能性があります。幸い、DevOpsからDevSecOpsが生まれました。これは、ハイペースのDevOpsの世界で、セキュリティに関する懸念、特にボット管理を引き受ける上で好位置にあります。

DevOps文化の中で、DevSecOpsは継続的統合/継続的開発(CI/CD)パイプラインにセキュリティを組み込む責任を持ち、開発者に対するセキュリティ バグに関する迅速なフィードバックを保証し、テクノロジのバリュー ストリームへのセキュリティの統合を継続的に改善します。

リーン生産方式を基盤とするDevOpsは、再作業のコストが大きい下流での障害を削減するために品質に関する考慮をバリュー ストリームの早期に行うことを強調しています。検査を行って欠陥を検出するよりも、品質を製品設計に組み込む方が効果的です。セキュリティは品質の重要な要素であるため、DevSecOpsでもセキュリティのシフト レフトを行い、ワークストリームの早期にギャップへの対応が計画されるようにしています。静的分析セキュリティ テスト、動的分析セキュリティ テスト、および脆弱性スキャンなどのツールの実行が早いほど、開発者はフィードバックを早く得ることができるとともに、バグも早期に修正できます。

要件収集、設計、およびコーディングでセキュリティにより多く対応するほど、効果的なセキュリティ管理が実現します。これらは安全なコーディングおよびソフトウェア開発ライフサイクル(SDLC)の基本概念ですが、セキュリティへの対応が遅れると、迅速に導入できなかったり、セキュリティ リスクにつながったりするため、DevOps環境ではこれらのプラクティスがさらに重要になります。

現代企業の安全確保におけるDevSecOpsの重要な役割を考えると、ボット管理はこの部門の責務に含める必要があります。ボット管理はセキュリティに不可欠であり、DevSecOpsの使命の中核を成すだけでなく、DevSecOpsは、組織を悪質なボットから保護する上で理想的な位置にあります。ここで約束どおり、DevSecOpsがボット管理に取り組む必要がある6つの理由を示します。

1)ボット対策はセキュリティとデータ プライバシーに不可欠

ボットとは、アプリケーションやAPIへのHTTP要求の送信を自動化するスクリプトを指します。犯罪者はボットを使用して、以下のようなさまざまな種類の攻撃でWebやモバイル アプリケーションを攻撃します。

  • クレデンシャル スタッフィング:攻撃者はログインに対して盗んだ資格情報を試し、アカウントを乗っ取ります。
  • 偽のアカウント作成:犯罪者は偽のアカウントを作成し、ソーシャル メディアを使った感化やマネー ロンダリングなどの不正行為を働きます(Twitterの偽アカウントの問題に関するF5の分析を参照)。
  • カーディング:犯罪者は盗んだクレジット カード データを有効にします。
  • カード クラッキング:犯罪者はさまざまな値を使用して、盗んだ支払いカード データのセキュリティ コードや欠落している発効日/有効期限を特定します。
  • ギフト カードの残高やロイヤルティ ポイントの窃盗:犯罪者は、ユーザーがこれらの残高を頻繁にチェックしないことに付け込み、ギフト カードの残高ロイヤルティ ポイントを盗みます。
  • 購入/再販:不法なブローカーは、期間限定オファーの商品を購入し、それより高い価格で再販します。
  • 在庫の買い占め:ボットが商品やサービスを予約するものの、購入を完了せず、在庫がないように見せかけ、正当な購入を阻止します。
  • スクレイピング:スクレイピング ボットは、アプリケーションからデータを抽出し、競走上の不利とサイト パフォーマンスの低下をもたらします。

ボット攻撃の包括的な分類については、OWASP Automated Threat Handbook(OWASPによる自動化された脅威のハンドブック)またはKyle Robertsによるこちらの要約を参照してください。

すべてのボット攻撃のうち、クレデンシャル スタッフィングは特に有害です。Global Privacy Assembly(GPA)は、クレデンシャル スタッフィングをデータ プライバシーに対するグローバルな脅威であると宣言しています。130を超えるデータ保護およびプライバシー規制当局と執行機関を代表するGPAは、ボット管理はデータ プライバシーに必要な対策であり、オンラインでビジネスを行うすべてのB-to-C企業に必須であると主張しています。

DevSecOpsが組織とその顧客の安全確保の使命を果たすためには、悪質なボットの問題を解決することが重要です。

2)ボットはDevOpsが利用するテレメトリを破壊する

DevOpsハンドブックによると、テレメトリは複雑なシステム(大きすぎて複雑に絡み合っているために、すべての部分がどのように組み合わさっているかを1人の人では理解できないシステム)で問題を予測、診断、解決するために不可欠です。DevOpsが成功するために、テレメトリは、1つのレイヤの問題をスタック全体で追跡し、根本原因を迅速に特定できるように、ビジネス指標、機能使用率、ネットワーク パフォーマンス、インフラストラクチャ ロードなどを含む複数のレイヤに対応している必要があります。

ボットはテレメトリを大きく歪めます。F5 Distributed Cloud Bot Defenseをご利用の多くのお客様は、ユーザー アカウントのほとんどが偽のアカウントであり、ボットがログイン トラフィックの95%以上を占めていたことを検出しました。場合によっては、組織のインフラストラクチャの大部分は、スクレイピング ボットにサービスを提供するだけでした。

人間とボットを区別できなければ、テレメトリは無意味になります。機能が失敗しているのは、実際のユーザーが原因ですか?それともボットが原因ですか?ログイン成功率が重要なのはなぜですか?特定のアプリケーション パスへのトラフィックが急増した原因は何ですか?ボットは、そのノイズによって信号を書き消してしまいます。

DevOpsが成功するためには、意味のあるテレメトリが必要です。そして、テレメトリを意味のあるものにするには、ボットを検出する能力が必要です。DevSecOpsは、ボット管理に関与し、DevOpsに不可欠なデータの整合性を保証することでDevOpsの成功に大きく貢献することができます。

3)ボット対策はコード セキュリティでも、開発だけの課題でもない

ベスト プラクティスのコーディングや脆弱性テストによって開発者が対処できる従来の脆弱性とは異なり、ボット攻撃は、ログイン、パスワードを忘れた場合、製品のチェックアウト、製品の価格情報など、アプリケーションで公開しなければならない正当な機能を主な標的としています(F5のDan Woodsは、Pirate Radioでのインタビューでこれらを「内在する脆弱性」と呼んでいます)。ボット対策はアプリケーション セキュリティに不可欠ですが、安全なコーディングとは関係なく、開発者が単独で解決することはできません。ボット対策は、開発者とInfoSecの間、まさにDevSecOpsの領域に位置します。

犯罪組織には、検出機能をバイパスするボットを開発する十分な動機があるため、悪質なボットからの保護は思いのほか困難です。CAPTCHAはもはや機能しません。MLやヒューマン クリック ファームを使用したCAPTCHA解決サービスにより、CAPTCHAは迅速かつ安価に解決されます(Dan Woodの「ヒューマンCAPTCHAソルバーの話」を参照)。ボットはJavaScriptを実行して、作業証明の条件を満たし、実際の人間の行動を模倣し、微妙なランダムネスを取り入れ、プロキシ ネットワークを悪用して、数百万件の有効なレジデンシャルIPアドレスを使用してオリジンを偽装します。また、犯罪者は検出されてから数時間以内にボットを改良します。ボットのこの高度化と急速な進化は、WAFルールの手動更新によりボットを阻止する時代はとっくの昔に過ぎ去ったことを意味します。

開発担当者にこのレベルの努力を強制しても、機能を完成させることはできないでしょう。WAFルールを更新するためにこれを運用チームに押し付けると、そのリソースが使い尽されてしまいます。ボット管理ソリューションをテクノロジのバリュー ストリームに統合するには、組織ではDevSecOpsの関与が必要になります。

4)DevSecOpsは、効果的なボット対策に不可欠なアプリケーション ロジックを知っている

ボットからの保護は、純粋な開発部門のタスクでも、従来の運用の意味での純粋な運用部門のタスクでもありませんが、ボット対策の構成には、アプリケーション、その要件、設計、実装に関する詳しい知識が必要です。

上述のボット攻撃の種類のうち、あなたのアプリケーションに当てはまるのはどれですか?これらの各攻撃について、ポットが狙うのはどのパスまたはAPIですか?これらの各パスについて、信号収集を計測し、ボットと人間を区別するために必要なデータを収集できるのはどこですか?

Webのボット対策の構成において、F5では保護されたパスをエンドポイント、インストルメンテーションが必要なページをエントリ ポイントと呼んでいます。ログインを想像してください。1つのWebページがログイン フォームをホストします。これをエントリ ポイントと呼びます。このフォームは特定のパスに転記されます。これをエンドポイントと呼びます。もちろん、いつもこれほど単純なわけではありません。ログイン フォームは多数のページに存在する可能性があり、これらのフォームは別のパスに転記されることもあります。

モバイルでも同様のことが言えます。ボットからモバイル アプリケーションを保護するには、通常、テレメトリのインストルメンテーションのためにSDKの統合が必要です。このテレメトリを含める必要のあるネットワーク要求を判断するには、アプリケーションの知識が必要です。

構成にはこのアプリケーションの知識が必要であることを考えると、ボット管理はDevSecOpsに最適です。特に、要件および設計の段階でボット管理を考慮して、この手順をシフト レフトすることは理にかなっています。

5)DevOpsはインフラストラクチャを知っている

同様にボットからの保護には、ネットワーク インフラストラクチャについて理解する必要があります。通常、ボット対策は、ネットワーク(おそらくCDN)、ロード バランサー、APIゲートウェイ、イングレス コントローラ、またはアプリケーション プラットフォームのレイヤから呼び出されるAPIを介して提供されます。これらのレイヤの1つは、関連するトラフィックをボット管理APIに送り、要求が人間からのものかボットからのものかを判断するように構成されます。

開発部門および運用部門と協力するDevSecOpsチームは、(CI/CDパイプラインの一部として)完全自動化が可能で最適なパフォーマンスを提供できる方法で、これらのAPI呼び出しをどこに実装するかを判断するうえで広い観点を持ちます。

6)DevSecOpsはボット管理がCI/CDパイプラインのどこに配置するかを知っている

組織がテクノロジのバリュー ストリームを通して新しい機能をリリースするのに伴い、WAFなどの他のセキュリティ コンポーネントと同様に、ボット対策には構成の更新が必要になります。DevSecOpsチームは、CI/CDパイプラインのどの位置でこの自動化された構成の更新を実行する必要があるかを判断するのに最適な立場にあります。

ボット対策は、ボットとして検出される自動QAテストを妨害する可能性があるため、これは一見したよりも複雑です。ヘッダーまたはIPアドレスを介してテスト ツールの許可リストを作成したり、自動QAテストの完了後にのみボット対策を配備したりするなど、この問題を解決する方法は複数あります。

特に重要なのは、DevSecOpsは開発部門およびInfoSec部門と協力して、ボット対策が必要な場所を特定し、関連する機能がリリースされる際にそれが配備されるようにする方法を提供する必要があることです。

まとめ

消費者向けアプリケーションを提供する組織は、オンラインでの顧客の安全を確保し、そのデータ プライバシーや財務面のセキュリティを確保する必要があります。DevOpsによって可能になる迅速なイノベーションを通じて競争上の優位性を追求する組織では、セキュリティがリリースのペースに後れをとらないように、顧客の保護にDevSecOpsが必要です。DevSecOpsの責務の中でも、ボット管理は不可欠です。ボット攻撃は、顧客のセキュリティを深刻なリスクにさらします。DevSecOpsは、悪質なボットから防御する上で非常に重要なスキルを提供し、組織が迅速なイノベーションを安全に受け入れることができるように支援します。

ボット対策のROIに関する詳しい洞察については、Forrester Total Economic Impactレポートを参照してください。f5.com/bot-defenseでは、詳細を確認したり、F5のボット エキスパートとのチャットをスケジュールしたりできます。