残念なことに、従来のアプリケーション開発では、ITセキュリティはしばしば開発プロジェクトの終わる時点で検討される傾向にあります。それはセキュリティ上の問題だけでなく、IT管理又は経営上の問題でもあります。開発プロジェクトの最後にアプリケーションを変更するには遅すぎ、非常にコストがかかるためです。

アプリケーションのサイバー・セキュリティに対する最善のアプローチは、アプリケーションの全ライフサイクルにおいてセキュリティをカバーすることです。テストや運用などを含めて、アプリケーション開発の初期段階からセキュリティを適用するという「Shift Left」と「DevSecOps」の考え方が特に現代のサイバーセキュリティ対策として不可欠です。

これらの流行語は、セキュリティをアプリケーション開発とサイバーセキュリティ分野での運用においても便利で、マインドセットの変更(考え方の変更)が不可欠であるという考えを伝えるのにも非常に役立つ概念です。

全員がセキュリティの専門家になるべき？

Webアプリケーションのセキュリティを向上させるには、ITセキュリティを特に従来からネットワークの運用やインフラ部門などに任せている日本においてはパラダイムシフトが必要です。開発側は、自らのWebアプリケーションのセキュリティにも責任を負うべきだとよく聞こえてきます。それはもちろん正しい考え方です。しかし、個々の開発者に全ての責任を帰するだけでは十分ではありません。それは良いWebアプリケーション・セキュリティの実現が実際に難しいためです：

アプリケーション・セキュリティの世界は非常に広くて一部は複雑過ぎるため、正しく実装するにはITセキュリティ専門レベルのノウハウが必要です。
但し、すべてのアプリケーション開発者、テスターまたはエンジニアを素早くITセキュリティ専門家にすることは不可能であり、効率的ではありません。
アプリケーション・セキュリティは、さまざまなデザインかつ多重なレイヤーでいくつかの方法において実装できます。
異なるアプリケーション開発プロジェクトは、同じセキュリティ要件を異なる知識を元に解釈をし、異なる言語フレームワークと異なるレイヤーかつ異なる方法で実装するため、結果的に企業全体のセキュリティレベルが異なることになってしまいます。
アプリケーションの中には、他のアプリケーションとの依存関係のためにリリースサイクルが長いものがあり、スピーディーに変更することはできません。
インフラストラクチャ部門又は運用部門は、アプリケーションセキュリティの責任を負うことを望まず、そのようなセキュリティ機能を実装しないか、またはそれらを厳密に提供しません。
アプリケーション開発者やビジネスオーナーは、セキュリティが既にインフラストラクチャの中でカバーされていると思い込んでしまいがちです。それはよくある誤解です。

これらの問題を解決するためには賢い対策が必要です。それはDevSecOpsの考え方で、誰がどのレイヤーで何のセキュリティを実装するのかを明確にすることを意味します。DevSecOpsは、開発の全ライフサイクルにセキュリティを組み込む方法を考えたものなのです。

DevSecOpsはテクノロジーではありませんが、テクノロジーはDevSecOpsの目標をより効率的に達成するサポートができます。リバース・プロキシ型WAFの例でこれを以下に示したいと思います。

どのくらいの「DevSecOps」？どのくらいの「シフトレフト」ですか？

「DevSecOps」は、セキュリティを開発ライフサイクルと運用ライフサイクルにどのように本格的に組み込むかという考え方です。しかしながら、「DevSecOps」としてどのぐらいの要素は含まれ、数えられるべきであるかという議論はオープンです。概念のセマンティクスを考慮すれば、「SecDevOps」と「DevOpsSec」という組み合わせにも意味がありますが、これらはまだ使用さ
れておらず、その意味を表現するためより良い言葉があります。

このような議論では少なくとも3つの段階を区別する必要があります：

コードを開始する前のセキュリティプロセス（セキュリティ設計）
コーディング中のセキュリティプロセス（セキュリティ強化）
コーディング後のセキュリティプロセス（リリース後のセキュリティパッチの適用）

「リリース後のセキュリティ」というのは、ライフサイクルで遅すぎ「DevOpsSec」のような言葉と似ています。主に、リリース後に問題が見つかった場合になんとかのセキュリティ対策になります。アプリケーション診断及びペンテストを使ってこのような脆弱性を積極的に探しているのは、開発ライフサイクルの後ろはなく、なるべくコーディング中に行うべきです。

「シフト・レフト」という概念は、セキュリティの考慮を開発ポロセスの後ろから左に移動して、開発プロセスの効率的なところに入れるために意味のある表現です。「DevSecOps」はそれを表現するための別の用語です。しかし、「DevOps」というバズワードもあります。この意味で使用されている場合は、開発側と運用側の間に何らかの制限が生じる危険性があります。理想的には、要件と設計段階も含める必要があります。そのために「Security by Design」を別の概念として用いられています。

リリース後に製品の基本設計やアーキテクチャーの変更に当たる場合、極めて困難な作業であるために、こういうセキュリティ懸念をできるだけ左にシフトすることは理想的に違いありません。「SecDevOps」という単語になりますが、それは受け入れられる用語ではなく、セマンティクスで迷う恐れがありますので代わりに、「セキュリティによる設計」つまり「Security by Design」を言うだけでよいでしょう。「Security by Design」と「DevSecOps」の区別は、誤解を防ぐために役立つ概念でしょう。

定義がどんなものであれ、「シフト・レフト」がどれだけ可能であるかは現場のニーズに応じて定義するべきです。これは、IT管理とITの戦略の問題でもあるため、経営陣のトップの呼びかけです。「DevSecOps」ベースのテクノロジとサービスは、セキュリティと品質目標をより効率的に達成するプロジェクトをサポートできます。

実例：WAFと「リバースプロキシ」で「Shift Left」と「DevSecOps」をサポート

リバース・プロキシはWebアプリケーション・セキュリティとWebアプリケーション・デリバリーにおいて戦略的な要素です。Airlock WAFのようなリバース・プロキシ・ソリューションをセキュリティ・フレームワークとして使用することで、効率性の良い優れたセキュリティ標準が直接使用できるようになります。

大切なステップは、これらのセキュリティ標準をDevSecOpsの段階上でどんなステークホルダーがどのように使用するのかを明確にすることです：

開発者は、複雑なセキュリティ機能を開発する必要はありません。Airlockのセキュリティ標準（中央認証とSSO、アクセス制御、セキュアなセッション処理、セキュアなクッキー処理、URL暗号化、フォーム保護、ブラウザ・フィンガープリンティングなど）を再使用するだけです。
開発者は、再使用できないアプリケーション専用のセキュリティ部分（データレイヤーのアクセス制御、アプリケーションのビジネスフローとトランザクションの保護、アプリケーションのAPIの保護、例外処理など）に特化して開発するだけです。
運用の方では、新たに発見された脆弱性を一元的に修正するためのAirlock WAF仮想パッチを使用してアプリケーション部門にサービスとして提供します。また、セキュリティ・レベルを関連する全てのアプリケーションに対して一元的に再調整します。
インフラストラクチャ側では、DMZのセキュリティとアプリケーション・デリバリー（SSLオフロードと認証処理、ロードバランシング、フェイルオーバーと高可用性、ネットワーク分離、URLリダイレクトとコンテンツ書き換えなど）のためのセキュア・リバース・プロキシとしてAirlock WAFの機能を使用し、アプリケーション部門にサービスとして提供します。

Airlockを使用したDevSecOpsは、WebアプリケーションとセキュアなWebアプリケーション開発のため、一貫したセキュリティ・インフラストラクチャをもたらします。このようなフレームワーク再使用戦略は、オンプレミス又はクラウド上で実装できます。

事業体のエンタープライズ・セキュリティ・アーキテクチャへ

それだけではありません。Airlockのようなリバース・プロキシを中心したアプローチでは、一つ一つのWebアプリケーションのセキュリティを向上させるだけではなく、エンタープライズ・セキュリティ・アーキテクチャの思想を元にしたITガバナンスにも影響をもたらす力があります。それは事業体のWebアプリケーション戦略又はビジネスの観点からも非常に意味があることです。

標準化されたセキュリティ・フレームワークがあると、実装が難しいセキュリティ技術が開発者と運用者に提供され、更に再使用において事業体の全アプリケーションが同じセキュリティ・レベルを維持できるよう、サイバー・セキュリティと効率性を結びつけることが可能となります。