Webサービスを公開するにあたり、サイバー攻撃対策を避けて通ることはできません。本ブログではDX実現のために考慮が必要となるWebサービスにおけるセキュリティ課題について、「Webサービスの構成要素」と「攻撃手法」の両面から検証した結果を前編・後編に分けて解説します。
前編ではWebサービスを構成する一般的な要素を対象に、それぞれにおけるセキュリティ課題をまとめました。後編では、攻撃者による「攻撃手法」のトレンドを取り上げ、これまでの対策では対応が難しい攻撃に対し、どのような対策を取るべきかをまとめていきます。
Webサービスを標的とする攻撃手法のトレンドと対策
Webサービスを標的とするこれまでの対策では対応が難しい攻撃手法
先述の通り、Webサービスを公開するにあたり攻撃者の存在を無視することはできません。Webサービスは常に多くの脅威に晒されており、攻撃者は様々な攻撃手法を用いてシステムを侵害し、対価を得ようとします。
Webサービスを標的とした攻撃・侵害事例は以前から多くあり、対策手法もたくさん提案されてきました。例えば「非公開システムに対する不正アクセス」という脅威があります。この脅威に対してはNetwork Firewallを用いることで、公開しているシステム以外への通信をブロックすることで対策を行うことが可能です。
また、「OSやプロダクトの脆弱性を突くような攻撃」に対してはIPSや次世代Firewallを活用することで対策し、「Webアプリケーションの脆弱性を突くような攻撃」に対してはWAFを用いることでこれらの攻撃からサービスを保護してきました。脅威を通信レイヤー毎に分割し、それぞれの対策を得意とするソリューションを個々に用意することで、多層防御の観点からWebサービスを守ります。
しかし、これらの攻撃は「自社管理下のリソースに対し、明らかに通常のユーザの挙動とは異なる動き」が発生しているという点では分かりやすいものでした。近年猛威を奮っている攻撃手法のトレンドとして、「通常のユーザが対象サービスにて取りうる行動の範囲内」で悪事を働くケースが増えています。この一連の行動はシステムの脆弱性を突くような攻撃ではないため、上記のようなソリューションでは防ぐことが難しいとされています。
また、自社管理下にないサードパーティリソースが侵害されることで、間接的にサービスが侵害されるようなケースも大きな問題となっています。今回の記事では上記のような、これまでの対策では対応が難しいとされる3つの攻撃手法とその対策について、それぞれまとめたいと思います。
企画・設計段階からセキュリティを確保し、サービス仕様の脆弱性を防ぐ
数年前よりFintechサービスや自社ポイントを用いた販促キャンペーンなど、サービス利用者のみならず、攻撃者にとっても金銭的魅力のあるサービスが多く展開されています。そしてご存知の通り、第三者によるポイント使用や不正出金といった被害は後を絶ちません。
Webサービスを取り巻く脅威は大きく分類すると二つに分けられます。一つはインフラやサーバ、Webアプリケーションといったシステムの脆弱性を突くような攻撃です。これらは顧客情報の窃取やサービスの妨害などを目的としていますが、セキュリティ診断を行うことで脆弱性を検出することができ、セキュリティソリューションを活用することでシステムを保護することが一般的な対策として広く普及しています。
もう一つはWebサービス仕様の欠陥を突くような攻撃です。主にサービス間連携の不備を悪用することで、他人のクレジットカード情報や銀行口座情報を攻撃者自身の決済サービスに紐付けるといった事案が世間を賑わせましたが、金銭または同様に価値のあるモノの獲得を目的とした攻撃が相次いでいます。
DXによりこれまで経験したことのないビジネスモデルに挑戦すること、サービス間連携の多経路化、そしてビジネスモデルの複雑化によりこのような仕様の欠陥が生まれやすい状況になっていると考えます。
このようなサービス仕様の欠陥を防ぐためには、サービスの企画・設計段階から対策機能が検討される必要があります。この時点で要件に含まれない機能が、システムの設計、実装範囲に含まれることはありません。要件定義などの上流工程でセキュリティ要件をしっかりと検討し、サービスへ組み込むことが必要です。
この考えを「セキュリティ・バイ・デザイン」と言います。早い段階で手を打つことができれば、サービスリリースの直前にサービス仕様の穴を発見しリリースが延期される、といったリスクも回避することができます。結果として、シフトレフトへと繋がります。
では、どのようにセキュリティ要件を検討すれば良いでしょうか。想定されるセキュリティリスクを洗い出すためには従来型のシステムセキュリティの視点に止まらず、詐欺や不正、迷惑行為といった悪用に繋がるユースケースに加え、プライバシーリスクやコンプライアンスリスク、レピュテーションなど多面的な分析を行う必要があります。
例えばクーポンを配布するユースケースを設定した場合、そのクーポンが無限に取得されてしまう脅威シナリオを想定することができます。また、ユーザから取得した情報を他社へ販売するビジネスモデルにはプライバシー上のリスクが伴いますし、取り扱う情報によってはコンプライアンスリスク、ひいてはレピュテーションの低下に繋がる恐れもあります。
上記の例は過去実際に発生した事案を元に作成しました。セキュリティリスクの分析を行う際は類似サービスの被害事例が大きなインプットとなります。そのため、類似サービスや同業他社への攻撃事例・脅威動向など、常にナレッジを蓄積することも重要なポイントです。過去の攻撃事例を参考にし、他社サービスとの差分となる自社独自仕様箇所をベースに脅威シナリオを作成し、必要となるセキュリティ要件・対策機能を定めていきます。
セキュリティ・バイ・デザインに関する詳しい解説は以下の記事を参考にして下さい。
「多様化するFinTechに不可欠な 「セキュア・バイ・デザイン」｜上流工程がセキュリティー品質確保の鍵を握る」
また、セキュリティリスクの分析に関する詳しい解説は以下の記事を参考にして下さい。
ユーザを取り巻く様々な情報を分析し、不正ログイン/アカウント使用を防ぐ
ダークウェブ上の闇市場には、あるサイトが侵害を受けることで流出したIDとパスワードの組み合わせリストが大量に販売されています。攻撃者はこのリストを活用し膨大なログイン試行を行うことで、流出したIDとパスワードの組み合わせを他サイトでも流用しているユーザを見つけ出し、不正ログインを試みます。
このような大量のログイン試行を行う場合、攻撃者は一般的にボットと呼ばれる自動プログラムを用いたアクセスを行います。ただしこれらのアクセスは非常に機械的なものであるため、例えば単位時間あたりの同一送信元IPアドレスからのアクセス数で制御を行ったり、ユーザエージェントによる識別を行ったりするような対策が行われてきました。
しかし攻撃ツール側も進化を続けており、近年の高度化したボットには単純なルールベースでの対策は通用しません。単位時間あたりのアクセス数による検出を避けるため、少量のアクセスを長い時間をかけて行うLow＆Slowアクセスが行われます。
また、ユーザエージェントの偽装はもちろんのこと、JavaScriptの処理を理解した応答を自動で行ったり、なかにはCAPTCHA認証を突破したりするようなボットも現れています。そのため、単一的なルールを用いた対策を行うのではなく、防御側も人かボットかの判断を行うためにより多くの情報を参照する必要があります。具体的にはアクセス元の環境情報やネットワーク情報、そして振る舞いの情報など複数の要素を判断基準に組み込むことが有効とされています。
一方、ボットによる大量のアクセス試行を行わず、直接人が実在のユーザになりすまして不正アクセスを行うケースも増えてきました。この場合攻撃者はフィッシングなどを用い、直接そのサービスの認証情報をユーザより窃取します。Webサービス側から見ると、正規のアカウント情報を用いた非常に人間らしい挙動をするユーザがアクセスをしてきているため、このアクセスをボットと判定することはできません。
このような不正アクセスの対策としては二要素認証があります。しかし、特にECサイトを運営する事業者の目線とすると、ユーザはこの追加の認証を非常に手間と感じ、結果として商品をカートに加えたものの追加認証のタイミングで購入することなくサイトを離れてしまう、いわゆる「カゴ落ち」へと繋がるリスクを問題視しています。セキュリティ機能を強化したいがカスタマーエクスペリエンスを損ないたくないという、両者ともに譲ることができないジレンマを抱えるのです。
こうしたカゴ落ちリスクを減らしつつ不正なユーザを検出する方法として、ユーザの行動特性を元にしたリスク分析を行う手法が注目を集めています。ユーザの過去の取引情報や購入履歴、ページ遷移の傾向や滞在時間など、ありとあらゆるパラメータを活用し、ユーザの行動特性を学習・蓄積します。過去の行動特性から明らかに傾向が異なるユーザについてはその時点で即座にアカウントを停止し、不正アクセスの可能性が想定されるユーザのみに絞って追加認証を設けることで、通常のユーザの利便性を損なわずに効率的なセキュリティ強化を行うことが可能となります。
自社コントロールが及ばない脅威についても、対策可能な仕組みを整える
Webサービスを新たに構築する際、そのリソース全てを自社にて開発することはもはやありません。世の中には多くのAPIサービスやライブラリが溢れており、開発者はそれらを組み合わせることでより迅速に、より使い勝手のよいサービスを安定して作り上げることが可能になりました。
しかし近年、これらサードパーティリソースが侵害されることによって間接的に自社サービスが被害を受けてしまうケースが増加しています。例えば上記の図の通り、Webサービス内に広告を掲載するために、サードパーティの広告配信サービスを活用するサイトを想定します。攻撃者はこの広告配信サービスを侵害することで、広告配信に使用されるJavaScriptを改ざんし、そこに悪意のあるコードを混入させます。
一般ユーザが対象のWebサービスにアクセスをすると、この改ざんされたJavaScriptがブラウザのバックエンドで実行され、例えば決済時に入力したクレジットカード番号などが秘密裏に攻撃者の元へ送り届けられます。この通信はユーザが使用するブラウザと攻撃者が用意したサーバとの直接的なやり取りになりますので、Webサービス事業者がいくらWAF等のネットワークセキュリティ対策を行ったとしても通信はその経路を通らず、被害を検出することはできません。
このような攻撃に気づくためにはどのような対策を行えば良いのでしょうか。まずはWebサービスが利用しているサードパーティリソースを含む全リソースを適切に把握しておく必要があります。それぞれの外部リソースの被害情報が公開された際に、自身のWebサービスに影響がないかをすぐに確認できる体制を整えておく必要があります。
また、スクリプトの実行制御や振る舞い検知など、継続的なランタイム監視を行えると非常に強力な対策となります。これらの対策は、実ユーザのブラウザ上の挙動を直接監視・制御します。コンテンツセキュリティポリシー(CSP)と呼ばれるHTTPレスポンスヘッダーを活用することでスクリプトの接続先を制限する対策が一般的ではありますが、ホワイトリスト型の管理を行う必要がありますので、Webサービスの機能の拡充に併せて適宜更新する運用が発生します。
最近ではこのようなリソース状況の可視化や監視を行うソリューションも多く登場しておりますので、運用負荷を軽減させたい場合には是非活用をご検討下さい。
おわりに
本記事では前編・後編を通しまして、Webサービスの構成要素、Webサービスを狙う攻撃手法の双方の観点からDX実現のために考慮が必要となるセキュリティ課題の概観を見てきました。お客様に安全に利用して頂けるWebサービスを提供するために、自身のWebサービスを構成する要素にはどのようなセキュリティ課題があるのか、そしてどのような攻撃手法を警戒しなくてはならないのかを認識し、それぞれの課題に応じた適切な対策をご検討下さい。
NRIセキュアでは、Webサービスのリスク評価から脆弱性診断、各種ソリューションの導入支援やマネージドサービスまで幅広く提供しております。Webサービスを運営されるにあたりセキュリティ周りに課題を感じることがございましたら、是非当社までご相談下さい。
関連記事：Webサービス概観｜DX実現のためのセキュリティ課題（前編）
