Web アプリケーションと API のセキュリティに関する新たなルール

実際のところ、ほとんどの Web アプリケーションや API のセキュリティツールは、現在とは全く異なる時代に合わせて設計されています。すなわち、開発者とセキュリティ担当者が協力し合い、統合されたワークフローを使用してセキュアなソフトウェアをリリースする前の時代です。アプリケーションがグローバルに分散され、API ベースになる前の時代で、エンジニアがコマンドを入力すれば、瞬時にグローバルにアップデートできる前の時代です。しかし、Fastly の CEO である Joshua Bixby が繰り返し言うように、「攻撃者も開発者」なのです。そして、攻撃者はレガシーソリューションの制限に悩まされることがありません。彼らは最新のツールやワークフローを使ってこれまで以上に俊敏に新たな脅威を構築し、進化させています。セキュリティに対するアプローチを変えなければならないことは明白です。そこでこの記事では、最新のアプリケーションの構築プロセスを考慮した、Web アプリケーションと API のセキュリティに関する新たなルールをご紹介します。

ルール1 : 特定の脅威ではなく、攻撃の目的に対応できるツールを使用する

セキュリティチームは長い間、特定の脅威に焦点を当ててきました。彼らが新しいツールを評価する際、「このツールは X から保護できるか ?」ということに注目しがちです。この場合、脅威 X は Stuxnet や SolarWinds ハッキングのように、ニュースになるような大きな被害をもたらしている脅威です。このような形で評価が行われる場合、特定の脅威のシグネチャやセキュリティ侵害インジケーター (IoC) を探すツールが採用されます。IoC には、既知の攻撃者の IP アドレスや、マルウェアが狙う特定のリクエスト URL にマッチする正規表現などが含まれます。

しかし、シグネチャベースのツールは正当なトラフィックと悪意のあるトラフィックを区別したり、増え続ける脅威に対応するのが苦手です。それはなぜでしょうか ? 最近のレポートによると、毎日35万種類以上の新しいマルウェアの亜種が作成されていることが報告されています。

このモデルではうまく対応できないのは明白です。実際、セキュリティ侵害を防ぐことができないウイルス対策ソフトや、SQL インジェクションやクロスサイトスクリプティングのみを検出する従来の WAF、リクエストするブラウザのユーザーエージェントのみをチェックするボット対策ツールなど、このタイプのモデルを採用したセキュリティソリューションが軒並み失敗するのを目の当たりにしてきました。

Web アプリケーションと API のセキュリティに関する新たなルールでは、よりインテリジェントなモデルへのシフトが求められています。新たなモデルは、セキュリティツールチェーンに十分な信頼性をもたらし、正当なリクエストをブロックしたり悪意のあるリクエストを通過させたりする心配がなく、貴重なトラフィックを安心して処理できるシステムでなければなりません。

それを実現するためには、セキュリティ技術に新たなことを求める必要があります。まず、セキュリティ担当者はトラフィックのシグネチャだけでなく、その目的や動作を調べるツールを求めなければなりません。つまり、リクエストの速さ、時間帯、ユーザーのログインステータスなどの要素を考慮する必要があるということです。

次に、運用チームはモニタリングモードだけでなくブロックモードでも運用できるツールを求めなければなりません。誤検知を恐れてモニタリングモードでしか実行できないツールでは、壊れたシステムを強化するだけです。チームが脅威に対応できるようになるまでにすでにシステムがダメージを受けてしまうからです。街角で犯罪があったときに「信号無視だ！」とか「空き巣だ！」と叫ぶだけで他に何もせず、ただ警察が来るのを待っているスーパーヒーローを想像してみてください。セキュリティチームや運用チームは、アラートの洪水の中で溺れかけています。彼らは脅威を検知してそれに対応することが常に求められています (これを実現する可視化とコントロールについては後述します)。しかし、ここでチームに必要なのは、侵入後に問題を診断するツールではなく、脅威の発生と同時に確実にそれをブロックできるツールの基盤です。

最後に、ツールはセキュリティチームや運用チームに負担をかけずに、常に最新の脅威に対応できるものでなければなりません。最先端のクラウドおよび SaaS ソリューションを使用することで、セキュリティチームは常に脅威の一歩先を進み続けてプロアクティブにプロダクトのアップデートを提供できるようになります。パッチを当てる必要がなくなり、最新の脅威への心配に取りつかれることもなくなります。

ルール2 : ユーザビリティのないセキュリティツールは使えません

最近の SaaS ベースのツールは、直感的で誰にでも分かりやすい Web エクスペリエンスを提供するものが増えているため、ほとんどのテクノロジーツールでは使いやすさが重要視されていますが、セキュリティソリューションはこの点で大きく遅れをとっています。従来のツールはルールの強制とコントロールを目的に設計されており、実際に操作されることは考慮されていませんでした。しかし、今日のチームはツールを操作することを望み、統合、観察、アクションの実行が可能なツールを必要としているのです。

運用者にとってユーザーインターフェースは防御の最前線ですが、残念なことに、真っ先にユーザビリティがないがしろにされる場所でもあります。従来の UI は動作が遅く、使い勝手が悪いことがよくあります。また多くの場合、同じプロバイダーのソリューションを使用していても、システムを管理するのに複数のユーザーインターフェースにログインする必要があります。貧弱な UI は、ツール間でのポリシーと適用状況のギャップ、緊急の脅威に対する対応の遅れや連携不足、セキュリティエコシステム全体に対する一貫性のある可視性の不足 (最悪の場合、可視性の完全な欠如) など、多くのリスクを生み出します。

セキュリティソリューションは、ソリューション全体のコントロールと可視化を実現する、直感的で使いやすい単一のインターフェイスを備えている必要があります。また、システムの状態を一目で把握できる完全な可視性が得られるよう、すべてをカバーする可観測性も備えていなければなりません。重要なのは、これらのソリューションは、セキュリティチームと他のチームの両方が使用できるものでなければならないということです。なぜなら、運用とエンジニアリングチーム全体でより多くの人が脅威との戦い参加することが可能になるからです。

次に、最新のツールは最新のアプリケーションデザインにマッチしなければなりません。多くの場合、ツールセットは単にパッケージ化され、プロバイダーによって販売されていますが、実際には技術的な統合を行うことができません。私の友人はこれを「請求書による統合」と呼んでいます。たとえシステムが、ソリューションをナビゲートするためにタブを切り替えなければならないだけだとしても、攻撃を受けている間、貴重な数秒と統合された可視性を失うことになります。このアプローチでは、技術的なギャップや可視性のギャップが生じるため、全体的なセキュリティ対策の効果が弱くなります。プロバイダーは、デフォルトで自動化と統合を提供するべきです。これらを行うには、完全に API 制御可能であることが前提です。すべてのセキュリティソリューションには、システムの全機能を公開する、使いやすい API が必要です。ソリューションは、相互に統合できるだけではなく、Jira、PagerDuty、Slack、Splunk などのツールを含む、レスポンスツールチェーン全体と簡単に統合できるものでなければなりません。また、チームが使用するセキュリティモニタリングや可観測性システムのデータを公開する、リアルタイムのログと統計も提供できる必要があります。すべてのソリューションを統合することで、攻撃者の真の意図をはるかに容易に特定することが可能になります。

ルール3 : リアルタイムの攻撃にはリアルタイムの対応が必要

マルウェアは、ソフトウェアシステムです。ソフトウェアシステムは開発者によって構築されます。つまり、攻撃者は開発者なのです。このことを認識すると、従来のセキュリティモデルが脅威のスピードに追い付けない理由を容易に理解できます。アジャイルな攻撃者は高度な DevOps ワークフローを採用して新しい手法を迅速に試行、調整、デプロイしています。1回の攻撃の間に何百回もこれらを行っている場合があります。攻撃者と同じスピードで対応できない場合、アプリケーションを保護することは不可能です。誤解のないように言うと、対応の速さは頭の回転の速さによって制限されているのではありません。対応の速さは、使用しているセキュリティソリューションのスピードに依存します。これを「可視化のスピード」と「コントロールのスピード」に分けて考えてみましょう。

可視化のスピード

攻撃を発見するのに数分から数時間かかるようではすでに手遅れです。攻撃者は攻撃を試み、それが失敗すればまた別の試みを行います。これらは全て数分の間に起こります。セキュリティソリューションがデータを自分自身や SIEM、モニタリングシステムに中継できるようになるまでに、すでにシステムはダメージを受けています。そこで、リアルタイムの可視化 (秒単位での測定) が得られると、自動ワークフローと手動ワークフローの両方で効果的に脅威に対応できるようになります。これにより、システムはリアルタイムでロジックを適用して脅威を審査し、運用チームは人間の介入が必要なアラートに迅速に対応することができます。いずれの場合も、可視化とコントロールが密接に連携している必要があります。

コントロールのスピード

担当者やシステムが脅威を察知したら、対応や修復のスピードが重要になります。よりインテリジェントなインテントベースの (攻撃者の目的に基づく) 対策を行うには、複数の種類のデータを使用して判断する必要があります。インテントベースのシステムは、自己学習と自己修復の機能を備えたシステムです。このタイプのシステムは常にパターンと動作を分析して新たな脅威や進化する脅威を予測します。そのため、リアルタイムでトラフィックを確認して解析できるだけでなく、変化する脅威に対応する新しいルールをデプロイできることもこれらのシステムには不可欠です。

ここで注目すべき点は、可視化とコントロールのスピードは、単一のデプロイや地域に限定できるものではないということです。分散型システムの普及 (マルチリージョンやマルチクラウドのデプロイや、保護が必要な作業の分散) により、物理的な場所や境界を越えてアクションを実行できるソリューションが必要とされています。検出と保護が1か所のみで行われることに限定すると、高速なセキュリティソリューションはいくつかあります。しかし、そのような運用方法はもう通用しません。今の時代、ソフトウェアや従業員が世界中に配置されているのは当たり前であり、セキュリティはそのような環境に対応していく必要があります。このルールの詳細については、オンデマンドのウェビナー「API-First Security for Real-Time Attack Response」をご参照ください。API に対応したセキュリティによっていかに迅速なインシデント対応が可能になるかをご覧いただけます。

ルール4 : 開発者、セキュリティ担当者、運用チームの全員がエンジニアとしての考え方を身に付ける

私たちは、サイロ化されたチームが個別に (苦しみながら) 作業してソフトウェアをリリースしていた時代から、セキュアな DevOps を目指す DevSecOps モデルを通じてセキュリティ、エンジニアリング、運用の各チームが統合されるまでの進化の道のりを共に見てきました。しかしまだ、ミッション達成の旗を掲げるにはほど遠い状況です。セキュリティチームやエンジニアリングチームのリーダーたちの多くが、チーム間の技術的・文化的な溝を埋めることで、より速く、より安全なアプリケーション開発サイクルを実現できると考えていますが、時代遅れの慣習やツールがいまだにその実現を阻んでいます。

その主な要因のひとつとして、DevSecOps が真の統合ではなく、形だけのパフォーマンスアートと化しているケースがあることが挙げられます。セキュリティオペレーターとその使用ツールをデプロイパイプラインの最後に追加しても、DevSecOps を実現できるわけでも、ソフトウェアのリリースが速くなるわけでもありません。真の DevSecOps では、セキュリティ検証と脆弱性スキャンは自動化されたテストおよびデプロイのフレームワークに直接組み込まれます。それによりセキュリティチームは、システム稼働の直前になって脆弱性のリストを提出し、それらの修正を求める門番役ではなく、開発チームに統合され、その一部として協働できるようになります。その結果、開発者は安全な開発プラクティスを用いてコードを記述できるようになります。また、自動化された CI/CD パイプラインでは機能面のテストだけでなく、一般的なセキュリティホールのテストも可能になります。そして、自動化されたシステムが何かを見落とした場合に備えて、セキュリティチームは詳細なセキュリティ監査を実施するスキルと権限を持っているのです。

真の DevSecOps を実現するためには、セキュリティ担当者、運用担当者、開発者の全員が、エンジニアの思考を身に付け、セキュアなソフトウェアをリリースすることに注力する必要があります。セキュリティ製品やセキュリティ機能を管理する手間を省き、セキュリティ担当者が運用者からエンジニアへとシフトできる環境を構築しましょう。それによりシステム全体の信頼性や安全性が高まるだけでなく、スタッフのキャリアパスもより充実したものになります。

優れたソフトウェアを作るには、優れたセキュリティが不可欠

Amazon が AWS を開始し、企業がクラウドへの移行を開始してから15年が経ちました。この間に、より速く、よりユーザー中心のアプリケーションを構築するために何百もの新しいフレームワーク、言語、サービス、ツールが登場しました (そして多くの企業がそれらを採用してきました)。私にとっては実に楽しい体験でした。ソフトウェアを迅速にリリースすることと安全にリリースことの間にある対立は依然として残っていますが、今日その原因を解決することが可能です。

このような対立を減らすには、現在のチームのニーズを満たすセキュリティソリューション、つまり、ソフトウェアの構築プロセスに、セキュリティを文化的・技術的に不可欠な要素として組み込んだセキュリティソリューションが必要です。ソフトウェアを迅速にリリースするだけでは不十分です。高品質なソフトウェアを安全にリリースしなければなりません。Fastly はその実現をサポートするため、今日説明したルールに沿って、Web アプリケーションと API を保護するセキュリティソリューションを構築することに注力していくつもりです。みんなで一緒にがんばっていきましょう。

もっと詳しく知りたい方は、eブック『Web アプリケーションと API セキュリティの新たなルール』をご参照ください。各ルールに対応したお客様のユースケースをご確認いただけます。