DevOpsという概念を定義する試みが多数ありますが、こちらでは新たな定義を追加するつもりはありません。ある程度、解釈に問題があっても、新しいアイデァを立てることや、新しいソリューションを配置させる際にDevOpsは共通言語として重要な役割を持つ概念です。更に、DevOpsにITセキュリティを入れる要地のある概念です。
ですが、DevOpsはアジャイルのプロジェクトに開発とテストの自動化をもたらすことだけに限りません。デリバリサイクルの時間短縮、システム変更のハードルを低くしたIT開発のサービスレベルの強化や開発コストの削減などという目標はビジネス側のスポンサーにとっても意味のある内容です。このために、バズワード化にしたDevOpsという概念が万が一将来に名前変更されても、中身の成功した内容は残るでしょう。
具体的には、数多く行われる開発とテストのプロセスが究極的に自動化されることによって改善します。更に、従来から問題視されているサイロ化してしまった各開発チームと各運用チームの間の組織的な壁がなくなり、IT現場の効率性が向上します。ITの開発現場で大きなマインドセットチェンジをもたらしていくために、従来の伝統的な組織の秩序を改善することが期待されています。
DevOpsにセキュリティを追加
ITセキュリティをDevOpsに追加するにあたって、多数の使い道があります。しかし、行き当りばったりならないために、DevSecOpsのような努力が必要不可欠です。DevSecOpsの目標は開発中とリリース後の製品に対して継続的にセキュリティ強化(継続ハードニング)を実現させるということです。
継続的なセキュリティハードニングが行われていないICT製品の開発現場ではセキュリティ効率の面でも悪く、積極的なサイバーセキュリティ対策を実現できません。しかし、セキュリティには複雑な部分が多いので、開発者の継続的なハードニングの作業をサポートする必要があります。そのために適切なベンダーソリューション(SAST、DAST、コードレビューやセキュリティテストなど)をDevOpsのパイプラインに追加することでハードニング作業の効率性をアップさせることができます。
ソリューションの機能能力、実装のコンテキストと組織のニーズにより、特定のベンダーソリューションがあるDevOpsのパイプラインに追加されます。一度限りの努力ではなく、現場のエンジニアが継続的に新しいマインドセットを行うことで開発と運用のプロセスが改善されます。
更に、ウエブアプリケーションファイアウォール(WAF)というアプリケーションセキュリティソリューションをDevOpsの開発現場で活躍させることにもメリットがあります。開発者にWAFの継続的なハードニングの機能を提供すると、DevSecOps用のWAFとなります。
DevOpsパイプラインの一部としてDevSecOps WAFについて説明する前に、まず従来のコンベンショナルWAFを見てみましょう。
コンベンショナルWAFのシナリオ
コンベンショナルWAFというのは現在でよく使用されている普通のWAFを使用するためのシナリオです。
コンベンショナルWAFのシナリオは以下の通りです:
- 本番環境のみに実装されています。
- 常にインフラ及びネットワークのチームによって運用されています。
- ネットワークのインフラのように見なされ、ハードウエアまたはCDNのサービスパッケージの一部として提供されています。
- 運用側およびインフラのオーナーはアプリケーションレイヤーの課題や問題に責任感が薄く、アプリケーションの邪魔にならないように”透明性のある”サービスとしての提供が多く見られています。
- “透明性のある”WAFが使用されることによって、WAFの優れているアプリケーションセキュリティレイヤーの機能は使用されず、しばしば矛盾する状況となります。
- WAFはアプリケーションの開発環境やテスト環境などでは実装されていないために、開発者が直接使用できません。
- WAFは高価なICT製品として販売され、アプリケーションの開発チームの多くの開発環境やテスト環境に実装することは経済的な面に困難になります。
- 開発者は、WAF製品をセキュリティアーキテクチャの一部として戦略的な可能性を研究開発対象にすることはできません。
- WAFはアプリケーション層なのか?インフラ層なのか?どっちに属すのか?捉えにくい正体なので、評判は良くないです。
- コンプライアンス上の理由から、WAFを使用する場合がよくあります。だが、WAFの機能を実際に使用できる条件は少なく、WAFの設定を最小限に抑えた運用がよく見られます。
- リリース後のアプリケーションの脆弱性を迅速に修正することができない場合、WAF上でプリケーションの脆弱性を仮想パッチのように使用するのが魅力的なWAFの使用方法です。
- 絶えずに増加するルールとシグネチャの数の影響でWAFの管理が難しくなってきています。
残念ながら、これは現場でよく見られるWAFの状況です。
理論的にWAFはアプリケーション層のことであり、アプリケーションの特定のセキュリティニーズのために特定の機能を提供するべきですが、IT組織の開発側vs.運用側のサイロ的な考え方のために、可能ができる限りの優れた機能が使用されていません。
WAFはアプリケーションセキュリティレイヤーで動作するはずですが、このレイヤーをうまくカーバーできないネットワークセキュリティやインフラストラクチャの運用チームによって提供されています。
アプリケーションレイヤーのセキュリティはかなり広く、複雑な世界です。そのため、異なるチーム間において懸念事項があります。それは操作上のリスクが他の領域に移行するため、危険なツールとして認識されてしまうことです。このような組織的な壁は、WAFソリューションの可能性を限定させてしまいます。
DevSecOps WAFのシナリオ
上記のコンベンショナルWAFの使用欠点と新しいDevOpsのコンテキストを考慮すると、DevSecOpsのための新しいWAFを使用するシナリオが出てきます。それは、基本的に、ICT製品の開発現場でもWAFの他の高度なセキュリティ機能を効率的に使用してもらうということです。
セキュリティの効率アップが目標です。そのなかで、ICT製品のアプリケーションが開発でき、さらにテストしている開発者がWAFの機能を直接使用できるようになることで、サイロ化したDevとOpsの組織の壁を打ち破る結果となります。
DevSecOpのWAFの使用要件のシナリオは次の通りです:
- 同じWAFのビルドがすべてのIT開発環境、ITテスト環境、本番環境で実装されています。
- 開発者はWAFのセキュリティ機能を外部のセキュリティフレームワークのように使用し、アプリケーションのセキュリティを強化します。WAFの高度なセキュリティ機能を利用するとアプリケーションでの開発は必要なくなり、効率性が向上します。
- 組織の予算が限られているので、開発者の間に普及し、利用してもらうために、開発・テスト用のWAF製品が低価格でなければなりません。
- DevOpsの自動化したパイプライン内でWAFを展開するために、使いやすくセットアップも容易でなければなりません。
- WAFの機能の使用は、アプリケーションの開発者の視点から使いやすいものでなければなりません。
- さまざまな所有者とステークホルダーがいますので、各設定と各ルールを別途でサポート、管理する必要があります。企業レベルのセキュリティ設定とアプリケーション固有のセキュリティ設定を個別に管理する必要もあります。
- 開発現場であるステージングプロセスをサポートする必要があります。
- 設定やルールなどの管理において、他のアプリケーションやエンタープライズ全体のセキュリティ設定を妨げることなく、きめ細かいレベルで容易にインポートおよびエクスポートする機能が必要です。
- ソフトウェアアプライアンス、仮想イメージ、または(クラウド)サービスとして提供されています。
このような点のほとんどは技術的なものではなく、多くのWAF製品で実現できます。しかし、実際にDevOpsパイプラインに具体的なプロセスやテクノロジーでの実装をより容易にするために、製品自体による特定のサポート機能が必要になる場合があります。
ビジネス戦略でも貢献:エンタープライズセキュリティアーキテクチャの一部としてのWAFの役割
セキュアリバースプロキシとしてのWAFは戦略的な存在でもあります。シナリオとしては、下流にあるすべてのWebアプリケーションへのアクセスを制御し、中心的なセキュリティゲートウェイのような役割を果たして事業体の全アプリケーションのセキュリティレベルを保護するというものです。
エンタプライズレベルでセキュリティゲートウエイとして再利用されると極めて戦略的な姿になります。コストの削減、相互運用性と統合機能の実現、単純なルールと署名のアプローチをはるかに超える高度なセキュリティ機能を活躍させることが可能になります。さらには、エンタープライズ全体の認証サービス、アクセス制御、およびIAM統合機能を包括的に提供するための戦略的な役割を担います。
こうしたエンタープライズセキュリティアーキテクチャの一部になれば、アプリケーション毎の継続的なハードニングよりはるかに優れたセキュリティへの貢献を期待できます。
特定のアプリケーションプロジェクトのソリューションアーキテクトは、その機能と可能性を認識し、アプリケーション開発プロジェクトでそのエンタプライズアーキテクチャーの機能の活躍を設計することが期待されています。このように、WAFは、アプリケーションプロジェクトの開発者がコードの作業を始める前に、「Security by Design」の段階でもセキュリティの品質に貢献することができます。
ディパオロ・ロベルト (Author: Roberto Di Paolo)
Version 1 2018/06/27, last update 2018/07/06 ©ACROSEC Inc., All Rights Reserved