クラウドネイティブアプリケーションのセキュリティ組織アーキテクチャの簡単な分析

デジタル変革は無視できない力です。あらゆる業種において、企業はテクノロジー企業になることを目指しており、その実現方法をますます差別化しています。

クラウドと DevOps はこの変革に大きな役割を果たしており、ソフトウェアの開発と運用の方法に革命をもたらしました。ソフトウェアの作成はかつてないほど容易になり、更新もかつてないほど頻繁になり、イノベーションが顧客のニーズにこれほど迅速に適応することもなくなりました。

このような変化に直面して、セキュリティは適応する以外に選択肢はありません。企業はさらなるスピードを目指して努力し続けなければなりませんし、これからも努力し続けるでしょう。そして、独立したチームがこれを達成する唯一の方法です。アプリケーションを保護する方法は、独立した開発チームの日常業務の一部になるように変更する必要があります。セキュリティ チームは、まずこれらのチームのセキュリティ確保を支援することに重点を置く必要があります。セキュリティは開発の優先事項である必要があります。

セキュリティ業界は DevOps の取り組みの一部ではありません。セキュリティ プロセスは、進行中のプロセスに組み込まれるのではなく、進行中のプロセスを制御する傾向があります。セキュリティ プロセスでは次の機能を実現できないことに注意してください。

独立した開発チームを支援する

セキュリティ機能は別のチームが所有しており、開発チームにはセキュリティに関する決定を下す権限がなく、ツールは主にビルダーではなく監査人向けに設計されていました。

継続的な運用とメンテナンス

安全プロセスは依然として、安全性監査や結果レビューなどの手動ゲートに大きく依存しており、進行中のプロセスの速度を低下させています。

セキュリティ対策がスピードと独立性を求めるビジネス上のインセンティブに反するのであれば、良い結果にはならない可能性が高い。開発チームは、ビジネス成果に悪影響を与える速度低下と、重大なリスクをもたらすセキュリティ制御の回避のどちらかを選択する必要があります。どちらも長期的には実行可能な選択肢ではないため、企業は DevOps の現実に合わせてセキュリティ慣行を変更する必要があります。

DevOps により、開発重視のセキュリティ方法論の必要性が高まり、デジタル トランスフォーメーションの時代においては、クラウドとクラウド ネイティブ アプリケーションの進化も見られました。クラウド ネイティブ アプリケーションは、以前のものよりも範囲が広く、基盤となるスタックのより多くの要素を包含するようになっています。

アプリケーションの範囲がこのように変更されると、アプリケーション セキュリティの範囲も変更する必要があります。この記事では、クラウド ネイティブ アプリケーション セキュリティ (CNAS) と呼ばれる、アプリケーション セキュリティの新しい拡張された範囲について説明します。

CNAS を導入するには、アプリケーションとインフラストラクチャを保護する方法に大幅な変更が必要になります。移行のプロセスは、組織ごとに、また同じ組織内の異なる部門でも、それぞれ異なる形で経験される旅です。

正しい道を選ぶのはあなた次第ですが、正しい道を選ぶためのパターンとベストプラクティスが現れ始めています。この記事では、現状を打破することを検討できるいくつかの領域と、それを実行する方法を提案します。

セキュリティ組織の再考

組織は多くの場合、責任分野に基づいて分割されます。アプリケーション セキュリティの問題としてインフラストラクチャの一部を保護することを考える場合は、セキュリティ組織の構造を再考してください。具体的には、アプリケーション セキュリティ チームの責任範囲を変更するかどうかを検討します。

さらに、セキュリティ プラクティスが開発者中心になり、開発者の支援に重点が置かれるようになると、このアプリケーション セキュリティ チームに対する要件も変化します。さらなる共感力、プロジェクト管理力、そしてエンジニアリング能力が必要です。建設者を増やし、破壊者を減らす必要があります。

セキュリティ部門の組織構造を評価する際に役立つように、アプリケーション セキュリティ分野でよく見られる 3 つのチーム範囲 (コア アプリケーション セキュリティ、セキュリティ エンジニアリング、新しい製品セキュリティ) を紹介します。これらは、完璧なモデルを採用するのではなく、組織をどのように構築するかについての参照ポイントとして機能する必要があります。

コアアプリケーションセキュリティチーム

まずは現状から始め、アプリケーション セキュリティ チームの範囲を同じままにしておきましょう。これはデフォルトの状態であるため、ほとんどの組織では、少なくとも出発点としてこのチーム スコープを使用します。

コア アプリケーション セキュリティ チームは、カスタム アプリケーション コードとビジネス ロジック、および使用中のオープン ソース ライブラリを保護する役割を担っています。通常、カスタム コードの脆弱性を見つけるための静的、動的、インタラクティブなアプリケーション セキュリティ テスト (SAST、DAST、IAST) や、脆弱なオープン ソース ライブラリを見つけるためのソフトウェア構成分析 (SCA) ツールなど、従来のアプリケーション セキュリティ テスト (AST) スイートがあります。さらに、これらのチームはセキュリティ教育やトレーニングを開発することが多く、脆弱性管理やバグ報奨金プログラムに取り組むこともあります。場合によっては、RASP または WAF ツールを使用してランタイム アプリケーション保護機能を実装することもあります。

コア アプリケーション セキュリティ チームのメンバーは、通常、セキュア コーディングの専門家であり、アプリケーション操作のレビューとセキュア コード監査の経験を持っている必要があります。開発者と協力するには、開発者に対する優れた共感力が必要であり、そのためにはある程度の理解やコード関連の能力が必要ですが、完全なソフトウェア開発の認定資格は必要ありません。

コア アプリケーション セキュリティ チームを維持する主な利点は、業界における長期的な地位です。チーム内のさまざまな分野で経験のある専門家を採用しやすくなります。ツールに関しては、ツールとプラクティスが十分に文書化されている領域です。組織構造の観点から見ると、ほとんどの業界では、アプリケーション セキュリティ チームはコア アプリケーション セキュリティ チームと類似していると考えられます。

コア アプリケーション セキュリティ チームの任務は現状維持ですが、その方法論は開発者にとってより使いやすいものになることがよくあります。アプリケーション セキュリティ チームは、多くの場合、チーム内の個人に複数の開発チームのパートナーとして責任を割り当て、より優れたコラボレーションを促進します。アプリケーション セキュリティの分野には、規模の拡大と開発チーム内へのセキュリティ専門知識の浸透を支援するセキュリティ チャンピオン プログラムを実行している同業者が数多く存在します。範囲はほぼ同じですが、コア アプリケーション セキュリティ チームの内部プラクティスは従来のプラクティスと同じである必要はありません。

セキュリティエンジニアリング/セキュリティプラットフォームチーム

セキュリティ ガバナンス プロセスのステップを自動化することは、最新の開発環境では重要です。高速 CI/CD パイプラインには手動レビューの余地がなく、代わりに自動化されたパイプライン テストが必要です。さらに、開発者はセキュリティの専門家ではなく、セキュリティに費やす時間も少ないため、セキュリティの専門知識が組み込まれ、セキュリティに関する決定を軽減または促進できるツールが必要です。

セキュリティ ツールの構築と運用は簡単ではありません。特に、さまざまな開発チームで要件が大きく異なる大規模な組織では、なおさらです。自動化を促進するために、一部の組織では、セキュリティ強化を目標に、内部ツールの構築と外部ツールの統合に重点を置いた専用のセキュリティ エンジニアリング チームを立ち上げています。

セキュリティ エンジニアリング チームは、セキュリティに少し重点を置いたソフトウェア エンジニアで構成されており、完全な DevOps エンジニアリング チームと同様に機能します。通常、彼らは構築したサービスを構築、展開、運用し、他のエンジニアリング チームと同じ方法論を使用してアジャイル プロセスを実行し、製品バックログを管理します。

ワークロードが独自のチームを必要とするほど大きくない場合は、同じアクティビティをコア アプリケーション セキュリティ チーム内に組み込むこともできます。ただし、「セキュリティ エンジニアリング」という名前のチームの職務内容はかなり一貫しているのに対し、「セキュリティ エンジニア」という肩書きを持つ個人 (ますます一般的になっています) の責任は多岐にわたります。中には、上で説明したようにソフトウェア エンジニアもいますが、タイトルの「エンジニア」の部分がセキュリティ分野を指す人もいます。

セキュリティ エンジニアリング チームは、自動化を大幅に向上させる優れた方法であり、運用指向のプラットフォーム チームやサイト信頼性エンジニア (SRE) チームと並行して機能する優れたチームです。実際、プラットフォームチームの範囲が、こうしたセキュリティツールの構築と運用にまで拡大しているケースも少なくありません。これは、ソフトウェア エンジニアをセキュリティ チームに参加させる優れた方法でもあり、人材不足に対処し、セキュリティ チーム内で開発者の共感を高めるのに役立ちます。

製品セキュリティチーム/クラウドネイティブアプリケーションセキュリティチーム

セキュリティ チーム モデルの最新メンバーは、製品セキュリティ チームです。これらのチームの範囲ははるかに広く、アプリケーション コード自体だけでなく、製品に関連するすべてのものが含まれます。最も注目すべきは、2 つの重要な新機能により、CNAS の全範囲がカバーされ、製品自体にセキュリティ機能が組み込まれるようになったことです。

クラウドネイティブアプリケーションのセキュリティを完全にカバー

CNAS の範囲を含める拡張は、特定のインフラストラクチャ リスクをアプリケーション セキュリティとして再考することの自然な結果です。現在、コンテナや IaC などのテクノロジーは、同じ開発者が同じプラクティスとツールを使用してカスタム コードを作成することによって推進されています。この変更をサポートするには、AppSec チームがこれらのエンジニアをサポートしてこれを正常に実行できるようにする必要があります。このより広い範囲を扱うチームは、多くの場合、自らを製品セキュリティ チームと呼びます。

CNAS の範囲が拡大されたということは、製品セキュリティ チームがソフトウェア開発ライフサイクルのより広い部分にわたって作業することを意味します。これには、本番環境の展開や運用への関与が拡大することが含まれており、より運用に重点を置いたクラウド セキュリティ チームとの重複につながります。実際には、クラウド ネイティブ開発とは、クラウド セキュリティが開発チームと運用チームの両方の影響を受け、製品セキュリティ チームが前者を担当することを意味します。

多くのコア アプリケーション セキュリティ チームは、チーム名やミッションを正式に変更せずに、CNAS の全範囲をカバーするように拡張していることに注意してください。コンテナ イメージの脆弱性をスキャンし、IaC ファイルを監査するためのソリューションを選択して実装することは、ますますアプリケーション セキュリティ チームの領域になっています。製品セキュリティ チームがこの完全な範囲を把握していると想定しても問題ありませんが、このような名前の変更は厳密には必要ではなく、多くのアプリケーション セキュリティ チームはこのような宣言を行わずに進化してきました。

製品の安全機能

CNAS とは関係ありませんが、それでも注目すべき点は、製品セキュリティ チームの関与が、セキュリティのよりユーザー向けの部分、つまりセキュリティ機能に及んでいることです。ユーザーがセキュリティの重要性を認識するようになるにつれて、多くの製品が専用のセキュリティ機能を組み込み、それを通じて差別化を図ろうとするようになります。どのセキュリティ機能が有益かを判断するには、開発チームにはなくてもセキュリティ チームにはあるレベルのセキュリティに関する理解が必要です。製品セキュリティ チームはここで明確な役割を担うことが多く、これまで以上に製品の全機能と価値提案を所有する製品マネージャー (PM) と連携します。

この責任は、アプリケーション チームとセキュリティ チームの関係において重要な役割を果たします。セキュリティ制御はリスクを軽減する手段ですが、このリスク軽減をセキュリティ機能として提供できるということは、収益の増加にもつながることを意味します。収益の増加は両チームのもう一つの共通目標であり、リスクの削減よりも明白であったため、成功を祝いやすくなりました。

製品安全の進化

製品安全は新しい名称と範囲であり、まだ定義中です。範囲が広いため、通常は、前述の他のチームを含む親タイトルまたは大規模なチームになります。クラウド ネイティブ組織の中には、製品セキュリティが最高セキュリティ責任者 (CSO) の主な権限となっている組織もありますが、リーダーを最高製品セキュリティ責任者 (CSO) に任命し始めている組織もあります。

Atlassian の最高情報セキュリティ責任者 (CISO) である Adrian Ludwig 氏は、次のように述べています。「製品セキュリティの目標は、製品のセキュリティ体制を改善し、顧客のセキュリティに対する期待を開発チームに社内で伝えることです。」 Twilio、Deliveroo、Snyk などの他の企業もこの称号を使用しており、これが CNAS を指す正しい方法であると私は信じています。

DevSecOps チームについてはどうですか?

DevSecOps チームの名前を挙げなかったことにお気づきかもしれませんが、それは偶然ではありません。 DevOps と同様に、DevSecOps はチームではありません。これは、セキュリティをコア開発および運用作業に組み込むことを目指す運動です。私の意見では、それはチームタイトルであってはならない。

しかし、DevOps チームと同様に、DevSecOps チームも存在し、そのタスクはまったく異なります。場合によっては、実質的には運用と実行時のセキュリティに重点を置いたクラウド セキュリティ チームとなることもあります。また、セキュリティ エンジニアリング チームと同様の責任を持ち、プラットフォームのような役割を担う場合もあります。タイトルは特定の責任を意味するものではないため、DevSecOps チームの職務の範囲は実際に定義できるものではありません。

しかし、これらすべてのチームに共通しているのは、前向きな考え方を持っていることです。 DevSecOps はセキュリティの実施方法を変えることであり、DevSecOps チームは、その範囲に関係なく、常に自らを変革エージェントと見なしています。彼らは自動化とクラウドを採用し、監査よりもエンジニアリングされたセキュリティ ソリューションを優先し、開発チームと運用チームが自らを保護できるように取り組んでいます。