テクノロジーの発展が続く中、Webサービスを構成する要素は次第に変化を遂げてきました。本ブログではDX実現のために考慮が必要となるWebサービスにおけるセキュリティ課題について、「Webサービスの構成要素」と「攻撃手法」の両面から検証した結果を前編・後編に分けて解説します。
本記事ではまず前編として、Webサービスを構成する一般的な要素を対象に、それぞれにおけるセキュリティ課題をまとめていきます。次回の記事では後編として、攻撃者による「攻撃手法」の観点からセキュリティ課題を検証していきます。
公開WEBシステムを取り巻くトレンドと変遷
先述の通り、Webサービスを取り巻く環境はこれまで止まることなく変化を遂げてきました。DXの実現には「変化への対応速度」が大きなカギとなり、ビジネスの成否を決定付けるものであると筆者は考えます。アジャイルやDevOpsといった開発手法を採用することで高頻度リリースを目指し、クラウドを活用することでシステム環境の即時立ち上げを実現します。また、コンテナ技術やマイクロサービスアーキテクチャを取り入れることで、開発効率を大きく向上させる取り組みも活発化しております。
Webサービスを取り巻く環境を考えていく上で、Webサービスを構成する要素を「開発手法」、「インフラストラクチャ」、「サーバ形態」、「アプリケーションアーキテクチャ」の4つに分解しました。本記事ではこの4つの観点に着目し、それぞれの特徴と課題について取り上げていきたいと思います。
『開発手法』
変化が加速する中、開発プロセスにセキュリティを組み込むことが必然となる
従来、特に日本におけるシステム開発現場ではウォーターフォール型開発手法が採用され続けてきました。しかし前の工程には遡らないことを前提とした手法であるため、仕様の変更には大きな労力が必要であること、実際にシステムの使い勝手を確かめることができるのは全工程の終盤となり、ユーザの意見を反映しにくいといった課題がありました。
このようなデメリットを補う形で、アジャイル型開発手法の採用が進みました。一つの機能を短期間で開発する短いサイクルを回すことで、必要な機能から優先順位をつけて開発することができ、変化に柔軟に対応することが可能となります。また、DevOpsと呼ばれる開発手法を用いることで開発チーム、運用チームといった組織の壁を取っ払い、同じ目的を持った少人数の１つのチームとして活動することで、さらなるスピード感のある開発へと繋がっています。
このように各チームが協調し高速リリースを実現させていく中、セキュリティがその妨げになってはいけません。サービスの価値を高めるためにもスピード感のある機能追加を行っていきたいところですが、開発プロセスの「後」であるリリースの段階になって初めてセキュリティ検査を行うようでは、結局見つかった脆弱性の修正に大きく手戻りが発生してしまいます。
そこで、開発プロセスの「中」にセキュリティを組み込むことが重要となり、DevSecOpsという開発手法が誕生しました。DevSecOpsはDevOpsにセキュリティの人員・文化・技術・プロセスを組み込むことで、可能な限り手戻りのロスを減らします。さらに自動化技術を活用することで、高速な開発速度を維持した状態でセキュリティコントロールを行います。
もちろん良い事ばかりではありません。開発部門・セキュリティ部門の異なる文化を融合させるうえで発生する摩擦に対しお互いの理解を深めるチームビルディングを行う、自動化の代償として低下する品質に対し大きなアーキテクチャ変更のタイミングでしっかりとしたセキュリティ検査を計画する、など様々な工夫が必要となるでしょう。
DevSecOpsに関する詳しい解説は以下の記事を参考にして下さい。
「デジタル時代の開発サイクル「DevSecOps」｜迅速な開発とセキュリティの融合」
『インフラストラクチャ』
情報資産はクラウドへ、クラウドサービス設定値の適切な管理が求められる
クラウドの活用により、システム環境の即時立ち上げとメンテナンスに必要な時間は大きく削減され、エンジニアはよりアプリケーションの開発業務に集中できるようになりました。しかし、これまで社内領域に保管されていた情報はインターネット上の社外領域に保管されることとなり、常に外部からの脅威に晒されることで、より被害に繋がりやすい状態となっています。
現にクラウド上の大規模データを無認証の状態で露呈することによる情報漏えい事案は毎週のように報告されており、中には数千万、数億件規模の個人情報を漏えいさせてしまった事例も少なくありません。
クラウドサービスによってアクセス権の設定方法やデフォルト設定が違うことから単純に設定が難しいという問題もありますが、クラウドサービス上でシステムを構築する場合、そこには「クラウドサービス事業者が負う責任」と「ユーザが負う責任」が必ず存在し、この責任範囲が曖昧で分かりにくいことが、このような事故の誘発を高めている一因であると考えます。
このようにクラウドサービスの設定値を適切に管理することは重要なことですが、クラウドサービスは機能のアップデートも頻繁に行われ、全ての設定値を正しく管理することは非常に困難と言えるでしょう。
そのため、CSPM(Cloud Security Posture Management)といったクラウド設定値の一元管理を行うことができるソリューションを活用することが効果的です。CSPMに関する詳しい解説は以下の記事を参考にして下さい。
「CSPMとは？クラウドの設定ミス防止ソリューション｜選定で失敗しない３つのポイント」
『サーバ形態 コンテナ』
コンテナ特有の脅威を認識し、ビルドパイプライン全体を俯瞰した対策を行う
開発スピードの向上と本番環境の安定を目的として、コンテナを採用する企業が増えています。コンテナのメリットは数多くありますが、中でも可搬性の高さは開発スピードを向上させる特徴の一つとして上げられます。
コンテナにはアプリケーション本体に加え、特定バージョンの言語ランタイムや必要なライブラリ、関連設定ファイルなどが含まれます。このような依存関係を一纏めに組み込むことでアプリケーションの一貫性が保証され、例えば開発環境と本番環境での動作に差異が生じません。環境要因によるトラブルに悩まされることもなくなり、開発者は新機能の開発に集中することが可能となります。
そんなコンテナは複数の要素から成り立っており、それぞれに潜むリスクを正しく理解しておく必要があります。例えばインターネットに公開されているコンテナイメージはデフォルトの状態で脆弱であったり、汚染されていたりするケースが少なくありません。
Kenna Security社の調査によると、Docker Hubの利用率上位1000のコンテナイメージの内、20％のコンテナにおいて脆弱な設定がされていたとのことでした。またPrevasio社の調査によると、Docker Hubに公開されている400万のコンテナイメージの半数において悪用可能な脆弱性が見つかり、その多くは暗号通貨のマイニングに関するものであったと報告されています。他にも、オーケストレーションツールにおいて適切な認証や権限設定が行えておらず、配下のコンテナを乗っ取られてしまうといった危険性も考えられます。
「NIST SP800-190 Application Container Security Guide」ではコンテナ技術を構成するコアコンポーネントとして、「イメージ」、「レジストリ」、「オーケストレータ」、「コンテナ」、「ホストOS」の５つが述べられています。先程の例ですと、「イメージ」においては「皆が使っているイメージだから安心」と盲信せずに、コンテナに特化したイメージの脆弱性スキャンを行うといった対策が上げられます。
また、「オーケストレータ」においては必要性に応じた権限のみを付与すること、そして機微性のレベルに応じたグループ化を行うことが推奨対策として上げられます。Build、Ship、Runの各フェーズにおいてそれぞれ適切なセキュリティ機能を組み込み、ビルドパイプライン全体を俯瞰したセキュリティ対策が必要です。
『サーバ形態 サーバレス』
従来の対策に頼らず、アーキテクチャを理解した対策が求められる
サーバレスの普及も広がりつつあります。開発チームはサーバや仮想化環境などソフトウェアの実行環境を用意することなく、必要な時に必要な分だけクラウド事業者が提供しているサーバレスサービス上でソフトウェアを実行します。冗長化やスケーリングといった可用性に関する観点もクラウドサービス事業者側が責任を負いますので、開発者にとってはシステムに関する余分な心配事から開放されます。メンテナンスの必要がなくなることで、開発者はよりビジネスロジックへの注力が可能です。
一方、サーバレスで構築されたシステムのセキュリティ対策はどう変わるのでしょうか？従来のセキュリティ対策は、主にネットワークにIDS/IPS、WAF等のセキュリティ対策ソリューションを導入することが基本でした。また、サーバ内に改ざん検知やEPPといったエージェント型ソリューションを導入されるケースも多いかと思われます。しかし、サーバレスアーキテクチャにおいてはネットワークやサーバはユーザの管理下にはありませんので、これらの対策に頼り切ることは難しいと言えます。
また、サーバレスはイベント駆動型アーキテクチャとの相性が良く、様々な入力値をトリガーにシステムを起動させるケースが多いですが、入力値によってはWAFでの対策が難しいことを理解しておく必要があります。基本的にWAFはHTTP通信を検査対象としておりますので、それ以外の通信プロトコルには対応しておりません。
人が介在可能な入力値は決して信用してはならず、入力値の検証やサニタイズ処理を行う仕組みが必要となります。さらに同じ理由でほとんどのセキュリティ診断ツールはHTTP以外のプロトコルには対応しておりませんので、何をもってリリース可と判定するかといった基準についても、再考が必要となります。
つまり従来のセキュリティ対策をそのままにサーバレスへと移行することは非常に難しく、サーバレスアーキテクチャの特性を踏まえた上で、それぞれに必要となる対策を講じる必要があります。
『アプリケーションアーキテクチャ』
開発チームに一任せず、システム全体の統合的なセキュリティ管理を実施する
マイクロサービスアーキテクチャの活用も進んでいます。マイクロサービスはモノリシックなアプリケーションを小さな単位で自律サービスとして動作させ、相互に連携させることでサービスを提供するアーキテクチャです。一般的に、先程ご説明しましたコンテナやサーバレスを元に構成されています。
この小さなサービス単位で独立したチームとして開発を行うことで、サービス毎に得意な言語で開発を進めることができるなど、それぞれのチームの特色を活かし、より迅速で効率的な開発が可能となります。また、新機能のリリースにおいてもサービス全体を止める必要がなく、サービス単位の変更が行える点も大きな特徴です。
一方、マイクロサービス特有のセキュリティリスクも存在します。マイクロサービスアーキテクチャでは、多数の異なるサービス間の通信を確立させるために様々なネットワーク接続やAPIが使用されるため、モノリシックアプリケーションと比較すると攻撃対象領域(Attack Surface)が広くなる傾向にあると言われています。
また、各マイクロサービスはコンテナとして動作させることが一般的であり、一つの同じ基盤に多数のマイクロサービスが実装されています。サービス提供基盤そのものが侵害されることで 、結果として被害に遭う危険性も指摘されています。
開発チーム毎に自由な開発を行うことができるのはマイクロサービスの大きなメリットではありますが、システム全体としては統合されたセキュリティコントロールが必須となります。サービス間でセキュリティ対策に差を出さないためには、開発プロセスへ強制的にセキュリティ対策を組み込むことが有効的です。つまり、DevSecOpsの考え方がここでも重要となります。
これまで述べてきた「コンテナ」、「サーバレス」、「マイクロサービス」は、パブリッククラウドサービス上で実装されるケースがほとんどかと思われます。このような環境下におけるワークロードを統括的に守るセキュリティソリューションとして、「CWPP (Cloud Workload Protection Platform)」が注目されています。CWPPを含む、パブリッククラウドの包括的なセキュリティ対策に関する詳しい解説は以下の記事を参考にして下さい。
パブリッククラウドの包括的なセキュリティに向けて｜CSPM, CWPP, CNAPPs
おわりに
今回はDX実現のために考慮が必要となるWebサービスにおけるセキュリティ課題について、「Webサービスの構成要素」の観点からそれぞれまとめてみました。次回の記事では攻撃者の視点に立ち、「攻撃手段」のトレンドとそのセキュリティ課題について考えてみたいと思います。
関連記事：Webサービス概観｜DX実現のためのセキュリティ課題（後編）
