開発重視のクラウドネイティブアプリケーションセキュリティモデルへの適応

CNAS を導入するには、アプリケーションとインフラストラクチャを保護する方法に大幅な変更が必要になります。変革は、組織ごとに、また同じ組織内の異なる部門ごとに異なる道のりです。

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

ツールの再考

組織の変更に加えて、CNAS と Development First ではツールキットの再評価も必要です。この新しい視点を踏まえて、テクノロジー ソリューションに求める最も重要な機能と、ツールをバンドルする方法について再考する必要があります。

ツールを再評価する方法は多数ありますが、開発ツールの採用、プラットフォームの範囲、ガバナンスのアプローチという 3 つの主要領域に重点を置くことをお勧めします。

開発者ツール Calibre

開発者が日常業務にセキュリティを組み込めるようにすることが目標であれば、その目標に合わせて最適化されたツールを開発者に提供する必要があります。監査人向けに設計されたソリューションを購入し、開発者にそれを使用することを要求した場合、成功する可能性は低くなります。

当然のことながら、開発者は開発者が使い慣れているツールを使用することに慣れています。これらのツールは、優れた開発者ツールとは何かというテーマに関して独自のベスト プラクティスを開発してきた業界全体を表しています。開発者が採用するセキュリティ ソリューションを選択するには、開発者ツールのベスト プラクティスに照らしてこれらのツールを評価し、そのパフォーマンスを理解する必要があります。

優れた開発者ツールに共通する特徴は次のとおりです。

セルフサービス導入の成功

成功している開発ツールのほぼすべてには、簡単なオンボーディング、直感的なワークフロー、優れたドキュメントなど、優れたセルフサービス機能が備わっています。これは開発者がツールを使用する方法であり、ベンダーは営業担当者が押し付けることなく、自社のツールが開発者にとって関連性のあるものであることを確認する必要があります。開発者にツールを売り込む営業担当者になりたいのでなければ、開発者のセルフサービス導入の実績が豊富なツールを探してください。

ワークフローへのシームレスな統合

ほとんどの場合、開発ツールは開発者に別のツールを開くことを要求するのではなく、開発者と対話することがよくあります。これらは IDE、Git、開発パイプラインにエレガントに統合され、適切なタイミングで価値を提供します。統合は単なる技術的なフックではありません。ワークフローとベストプラクティスに適合する必要があり、そうでない場合は採用が拒否されます。

豊富なAPIと自動化対応

開始するには独自の統合が必要ですが、開発ツールもスイスアーミーナイフでなければなりません。ツールを各パイプラインに適応させ、コミュニティがその上に構築できるようにするには、豊富な API と自動化に適したクライアント (CLI/ソフトウェア開発キット [SDK]) が必須です。ツール上で構築できない場合、それは優れた開発ツールとは言えません。

オープンソースとコミュニティの採用

開発者は、ツールの信頼性を検証するために他の開発者を頼りにしており、オープンソースの採​​用は、その最良の指標です。オープンソース プロジェクトがセキュリティ ツールを統合したり、セキュリティ ツール上に構築したりするのを見ることは、開発者コミュニティにとって大きな評価となります。セキュリティ ツールを検討するときは、オープン ソースでの採用状況を確認し、独自の結論を導き出してください。

これらは、開発ツールに関する数多くのベスト プラクティスのほんの一部です。開発優先のセキュリティに関する具体的なセキュリティ推奨事項について詳しく知りたい場合は、以下をお読みください。また、ツールを評価するときは、実際のアプリケーション開発者を関与させて、ツールが周囲の環境にどの程度適合するかについての現実的な洞察を得るようにしてください (下の図を参照)。

開発者に優しいセキュリティツールの例

プラットフォーム範囲

現在主流の AST プラットフォームは、主にカスタム コードと、おそらくアプリケーションで使用されるオープン ソース ライブラリに重点を置いています。ツール スイートは主に SAST、DAST、IAST で構成されており、最近 SCA が追加されました。クラウド ネイティブ アプリケーションのより広範な範囲を採用するにつれて、プラットフォームを構成するものを再考する必要があります。

まず、単一のプラットフォームに統合することでメリットが得られるツールについて考えてみましょう。それらは以下の部分に分けられます。

共有ユーザー: 異なる主要ユーザー向けに異なるツールが設計されている場合、いずれにしても別々に使用されるため、それらを単一のプラットフォームの一部にする必要はほとんどありません。

共有ワークフロー: 複数のツールが同様の方法で使用され、ユーザーのワークフローの同様のポイントに統合される場合、複数の個別のツールを使用する代わりにそれらを組み合わせることで、統合時間だけでなくユーザーの時間と労力も節約できます。

優先順位の共有: 異なるツールからのアクション項目を互いに優先する必要がある場合、バックログを共有すると効率と結果が向上します。

価値の増大: 最後に、ツール共有プラットフォームの最も強力な推進力は、各ツールを一緒に使用すると価値が高まることです。この標準により、SAST や SCA などのテクノロジが単一のプラットフォームに適合する理由が自然に説明されます。どちらも同じ開発者ユーザーにサービスを提供しており、同じ場所でスキャンを実行してユーザーとやり取りし、開発者が優先する必要のあるセキュリティ脆弱性のバックログを共有しています。高度な SCA ソリューションでは、SAST テクノロジーにより、カスタム コードがライブラリ内の脆弱なコードを呼び出しているかどうかを示すことで価値が付加され、精度が向上します。

SAST と SCA の同じプラットフォームにコンテナと IaC セキュリティを追加する場合も、同じロジックが適用されます。

共有ユーザー: コンテナーと IaC は、SAST や SCA と同様に開発者によって保護されるようになり、開発者は学習と関与に時間を要する複数の異なる製品を持つことを好みません。

共有ワークフロー: コンテナと IaC を保護するには、SAST や SCA と同様に、IDE、Git、ビルド統合など、ライフサイクル全体にわたる統合が必要です。

共通の優先事項: 同じ開発者が、コンテナや IaC の脆弱性、またはコードやライブラリの脆弱性の修正に時間を費やしています。これらはすべて、アプリケーションのセキュリティ保護のバックログの一部です。

価値乗数: これらのコンポーネントを保護する方法はいくつかあります。コンテナをスキャンするには、内部のアプリケーションを調査する必要があり、インフラストラクチャ構成を理解することでコードとライブラリの脆弱性を優先順位付けするのに役立ち、コンポーネント間のフローを理解することで問題を軽減するのに役立ちます。これはまさに脆弱性をトリアージするときに行うことです。

このロジックは、CNAS の範囲が拡大しても有効であり、CNAS ツールをプラットフォームとして考えることをお勧めします。簡単な経験則としては、Git リポジトリ内のあらゆるものは、その周囲のファイルと関連しており、同じ開発ワークフローに従う可能性が高いということです。したがって、CNAS プラットフォームは、リポジトリ内のすべて (クラウド ネイティブ アプリケーション全体) を保護するのに役立ちます。

DAST と IAST は、このようなプラットフォームに参加するには少々厄介です。これらはアプリケーションの保護を扱いますが、多くの場合、異なるワークフローが必要になります。実行に時間がかかるため、ビルド パイプラインや IDE スキャンに組み込むのは困難です。私の意見では、これは論理的な問題というよりも技術的な問題であり、IAST および DAST ソリューションがよりパイプラインに適したものに進化すれば解決されると思われます。

ガバナンスとエンパワーメントのアプローチ

セキュリティに対して開発優先のアプローチを採用するには、異なるタイプのコラボレーションが必要です。私たちが必要としているのは、ブロードキャストやトップダウンのタスクの実施に重点を置いたツールではなく、安全なアプリケーションを共同で構築するのに役立つツールです。

これは当たり前のように聞こえるかもしれませんが、実際には多くのセキュリティ ツールの動作とは大きく異なります。これが何を意味するのか、具体的な例をいくつか見てみましょう。

まず、開発者はビジネスニーズとセキュリティリスクのバランスをとる必要があります。つまり、たとえば、発見された脆弱性を修正せずに、そのまま本番環境に展開するという決定を下すことができるようになります。これは一部の人にとっては恐ろしい提案ですが、独立したチームを実現する唯一の方法です。脆弱性を無視する場合は、依然として (監査可能な) 理由が必要であり、一部の制約は強化される必要があります (通常はコンプライアンス上の理由により)。ただし、デフォルトの位置としては、決定は開発者に任せる必要があります。

第二に、開発者はセキュリティリスクを管理できる必要があり、そのためにはプロジェクト内のすべての脆弱性を可視化する必要があります。これには、脆弱性のリストだけでなく、悪用可能性や資産マッピングなど、優先順位付けに必要なすべての情報も含める必要があります。この情報について透明性を保つことは、ある程度のリスクを伴う可能性がありますが、セキュリティを強化する唯一の方法です。開発者に権限を与えるには、開発者を信頼してこの機密データを提供する必要があります。

3 番目に、セキュリティ チームは、成果よりもセキュリティ制御の追跡と採用の促進に投資する必要があります。開発チームは脆弱性のバックログを管理する必要がありますが、セキュリティ チームは開発チームがこれを成功させるのを支援する必要があります。開発優先のセキュリティ ガバナンスとは、修正すべき脆弱性を強調するのではなく、どのような制御が実施されているか、その出力がどのように処理されているかを追跡し、開発チームと協力してそれらの統計を改善することを意味します。

これらは、ガバナンス ツールと手法を評価する際に考慮すべきほんの一例です。重要なのは、プラットフォームの考え方を受け入れることです。その目的は、セキュリティの脆弱性を追跡することではなく、開発チームが安全なソフトウェアを正常に構築できるように支援することです。

優先順位の再考

最後に、CNAS はアプリケーション セキュリティの優先順位を再考する必要があります。開発者がクラウドネイティブ アプリケーション全体を保護する必要がある場合、どの側面に最も重点を置くべきでしょうか?

歴史的に、IT セキュリティ制御はアプリケーション セキュリティ制御よりも大きな予算を占め、CISO の注目を集めてきました。この不均衡には歴史的な理由があるかもしれませんが、最終的には、組織のリスクを軽減するために資金を最も効果的に使用する方法に関する CISO の見解を表しています。

言い換えれば、CISO は、パッチが適用されていないサーバーやインフラストラクチャの構成ミスによる侵害のリスクは、コード内のカスタム脆弱性によるリスクよりも大きいと考えています。この見解を裏付けるには、歴史的な不規則性とその原因を示す相当量のデータが必要です。さらに、理解しやすいです。攻撃者にとっては、アプリケーションをリバース エンジニアリングして侵入するためのカスタムの欠陥を見つけるよりも、既知のエクスプロイトを大規模に実行して、開いているドアを探す方がはるかに簡単です。

クラウドはこの方程式を簡略化しません。実際、それはそれを強化します。クラウドを導入するということは、より多くのインフラストラクチャとサーバーを使用することを意味します。これらのインフラストラクチャとサーバーは、より一般にアクセスしやすく、管理にあまり精通しておらず、成熟度の低いツールを備えたチーム (開発者) によって定義される傾向があります。

ただし、以前は IT セキュリティ予算とアプリケーション セキュリティ予算のバランスが取れていましたが、現在はすべてがアプリケーション セキュリティの領域にあります。クラウドネイティブ アプリケーションを構築する場合、同じ開発者がカスタム コードを保護し、オープン ソースの使用における脆弱性を管理し、サーバーとインフラストラクチャの耐障害性を高める必要があります。同じアプリケーション セキュリティ チームが、同じ予算を割り当てて、これを支援する必要があります。

それでは、最初の質問に戻りましょう。貴重な開発者の時間と限られた CNAS 予算をどのように割り当てたいですか?

開発者自身のデバイスとアプリケーションのセキュリティ予算を捨て、カスタム コードの保護に開発者の注意を集中させます。アプリケーション セキュリティの成熟度モデル、業界のベスト プラクティス、チーム メンバーの個人的な経験はすべて、開発者が保護する必要のあったものの大半がカスタム コードであったクラウド以前の世界に根ざしています。 SAST や DAST などのツールの購入は、新しいアプリケーション セキュリティ リーダーのリストで最初に挙げられることが多く、異論を唱えられることはほとんどありません。

しかし、CNAS の範囲を考えると、これが時間とお金の最も有効な使い方なのでしょうか?既知の脆弱性や誤った構成による侵害のリスクは、たとえ開発者が構成したとしても、カスタム コードの欠陥によるリスクよりも高くなります。同意するのであれば、開発者やアプリケーション セキュリティ チームに、カスタム コードに取り組む前に、まずこれらのレイヤーのセキュリティ保護に重点を置くように指示すべきではないでしょうか。

これは答えるのが簡単な質問ではありません。優先順位は組織によって異なるため、何を優先すべきかを私が知っているとは思いません。ただし、CNAS の範囲が広いことを考慮すると、社内でこの会話を行って優先順位を再考することを強くお勧めします。

結論は

アプリケーション セキュリティへのアプローチ方法を変更することは、単なる思考訓練以上のものです。これは、人々のキャリア、予算の割り当て、組織を安全に保つための最善の方法の再評価など、下流に非常に現実的な影響を及ぼします。過去にどのように物事を行ったかという筋肉の記憶をある程度振り払い、解決策を選択する際に基本原理に戻らないようにする必要があり、貴重な時間とエネルギーを消費します。

幸いなことに、すべてを一度に行う必要はありません。この記事で概説する変更は相互に関連していますが、自分のペースで適用できます。自分に最も関連のある変更を選択するか、より重要と思われる他の変更を選択して継続することをお勧めします。セキュリティ機能をクラウド ネイティブの現実に徐々に適応させていきます。

この記事は、https://go.snyk.io/rs/677-THP-415/images/CNAS_OReilly.pdfから翻訳されています。転載する場合は、元のアドレスを明記してください。