イノベーションのセキュリティ

イノベーションは、デジタル時代における組織の推進力であり、有効にする必要も保護する必要もあります。 イノベーションのセキュリティにより、サイバー攻撃からイノベーションのプロセスとデータが保護されます。 デジタル時代のイノベーションは、DevOps または DevSecOps メソッドを使用したアプリケーション開発という形式をとり、リリース間隔が数か月から数年かかる可能性のある従来のウォーターフォール型の出荷スケジュールを待つことなく迅速にイノベーションを進めます。

新しい機能とアプリケーションの開発には、次の 3 種類の異なる要件を満たす必要があります。

• ビジネス開発 (Dev): アプリケーションでは、急速に変化することの多いビジネスおよびユーザーのニーズが満たされる必要があります。
• セキュリティ (Sec): アプリケーションは、急速に進化する攻撃者からの攻撃に対する回復力に優れ、イノベーションをセキュリティ防御に活用する必要があります。
• IT 運用 (Ops): アプリケーションは信頼性が高く、効率的に実行される必要があります。

これら 3 つの要件を融合して共有カルチャを作り上げることは非常に重要ですが、多くの場合は困難です。 このような変更を進めるために、開発、IT、およびセキュリティの各チームのリーダーが連携する必要があります。 詳細については、「リーダーの義務: カルチャの融合」を参照してください。

セキュリティで保護された迅速なイノベーションを実現するための DevSecOps メソッドの詳細については、次のビデオをご覧ください。

DevSecOps とは

テクノロジ イノベーションは多くの場合、開発と操作を組み合わせて DevOps プロセスにする、迅速でリーンかつアジャイルな開発方法のコンテキストで開発されます。 このプロセスにセキュリティを統合することが、イノベーション プロセス、組織の成長、組織内の既存の資産に対するリスクを軽減するために不可欠であるということがわかっています。 プロセスにセキュリティを統合すると、DevSecOps プロセスが作成されます。

セキュリティ バイ デザインおよびシフト レフト

組織で DevOps およびその他の迅速なイノベーション手法を採用するときには、セキュリティが、組織とその開発プロセスのタペストリー全体を織りなす糸となる必要があります。 プロセスへのセキュリティの統合が遅れると、高額になり、修正が難しくなります。

タイムラインでセキュリティをシフト レフトして、サービスと製品の構想、設計、実装、および運用にセキュリティを統合します。 開発チームが DevOps に移行し、クラウド テクノロジを採用するときには、その変化にセキュリティが含まれている必要があります。

ウォーターフォール モデルでは、セキュリティは従来、開発が完了した後の品質ゲートでした。

DevOps では、運用チームを含めるように従来の開発モデル (人、プロセス、テクノロジ) が拡張されました。 この変更により、開発チームと運用チームを分離することによって生じていた摩擦が軽減されました。 同様に、DevSecOps によって、個別または異なるセキュリティ チームの摩擦を軽減するように DevOps が拡張されます。

DevSecOps は、着想から、構想、アーキテクチャ デザイン、反復的なアプリケーション開発、運用に至る DevOps のライフサイクルの全ステージにセキュリティを統合したものです。 各チームは、イノベーションの速度、信頼性、セキュリティの回復力の目標に向かって足並みをそろえる必要があります。 各チームは、互いのニーズを相互に理解し、相互に尊重しながら、原因が何であっても最も重要な問題から取り組みます。

クラウド導入フレームワークの編成手法を使用すれば、組織内の DevSecOps 構造についてさらに詳しく理解できます。 詳細については、「アプリケーションのセキュリティと DevSecOps の機能」を参照してください。

DevSecOps を選択する理由

DevOps はアジリティをもたらし、DevSecOps はセキュアなアジリティをもたらします。

世界中のほぼすべての組織で、イノベーションを通じて競争力を高めるためにソフトウェア開発に頼っています。 DevOps プロセスをセキュリティで保護することが、組織の成功にとって重要になります。 攻撃者は、このカスタム アプリケーションへのシフトに注目しており、攻撃時にカスタム アプリケーションを攻撃することが増えています。 これらの新しいアプリケーションは、多くの場合、まだ商品として市場に出ていない貴重な新しいアイデアを含む価値の高い知的財産の豊富なソースになります。

このイノベーションの保護には、開発プロセスと、アプリケーションをホストするインフラストラクチャの両方で、セキュリティの潜在的な弱点に組織で対処することが必要になります。 この方法は、クラウドとオンプレミスの両方に適用されます。

攻撃者は、以下における脆弱性を悪用する可能性があります。

• 開発プロセス: 攻撃者は、通信の暗号化が脆弱または未使用であるなど、アプリケーションの設計プロセスでの弱点を見つける可能性があります。 また、攻撃者は、コードで入力が検証されなかったり、SQL インジェクションのような一般的な攻撃を許してしまったりするなどの、設計の実装での弱点を見つける可能性があります。 さらに、攻撃者は、コードにバック ドアを埋め込んで、後から戻ってお客様の環境やお客様の顧客の環境を悪用できるようにする可能性があります。
• IT インフラストラクチャ: 攻撃者は、標準的な攻撃を使用して、開発プロセスがホストされているエンドポイントおよびインフラストラクチャ要素を侵害できます。 攻撃者は、盗んだ資格情報やマルウェアを使用して、環境の他の部分から開発インフラストラクチャにアクセスするマルチステージ攻撃を実行する可能性もあります。 さらに、ソフトウェア サプライ チェーン攻撃のリスクがあるため、次の両方にとってセキュリティをプロセスに統合することが重要になります。
• 組織の保護: ソース コード サプライ チェーンにおける悪意のあるコードと脆弱性から保護します
• 顧客の保護: 評判の低下、責任、または組織に対するその他のビジネス上の悪影響を招く可能性がある、アプリケーションおよびシステムにおけるあらゆるセキュリティ上の問題から保護します

DevSecOps の推移

ほとんどの組織で、どのワークロードまたはアプリケーションに対する DevOps または DevSecOps も、実際には 2 段階のプロセスであると認識しており、このプロセスでは、最初にアイデアが安全な領域で温められ、その後、運用環境に公開され、繰り返し継続的に更新されます。

次の図は、この種のイノベーション ファクトリ アプローチのライフサイクルを示しています。

セキュリティで保護されたイノベーションは、以下の両方のフェーズに対する統合アプローチです。

• アイデア培養。ここでは、最初のアイデアが作成され、検証され、初期の運用環境で使用できるように準備されます。 このフェーズは、新しいアイデアで開始し、最初の運用リリースが、以下についての実用最小限の製品 (MVP) の基準を満たしたときに終了します。
  • 開発: 機能は最小限のビジネス要件を満たしています
  • セキュリティ: 機能は、運用環境での使用に関する規制コンプライアンス、セキュリティ、安全性の要件を満たしています
  • 運用: 機能は、運用システムであるための最小限の品質、パフォーマンス、サポート性の要件を満たしています
• DevOps: このフェーズは、継続的なイノベーションと改善を可能にするアプリケーションまたはワークロードの持続的で反復的な開発プロセスです

リーダーの義務: カルチャの融合

これら 3 つの要件を満たすには、これら 3 つのカルチャを結び付け、すべてのチーム メンバーが、すべての種類の要件を尊重し、共通の目標を目指して協力できるようにすることが必要になります。

これらのカルチャと目標を統合して真の DevSecOps アプローチにすることは困難な場合がありますが、投資する価値はあります。 多くの組織では、独立して作業している開発、IT 運用、セキュリティの各チーム間でのハイ レベルの異常な摩擦を経験しており、このとき次の問題が発生します。

• 価値提供の遅れとアジリティの低下
• 品質とパフォーマンスの問題
• セキュリティの問題

少々問題が生じても、新しい開発では普通のことで想定内のことですが、チーム間で衝突が起きると、多くの場合、このような問題の数と重大度が大幅に増大します。 この衝突は、多くの場合、1 つまたは 2 つのチームが政治的な優位性を持ち、他のチームの要件を繰り返しオーバーライドするために起こります。 時間が経つとともに、無視された問題の規模と重大度が増大します。 未解決のままにしておくと、この変化は DevOps によって悪化する可能性があります。ビジネス ニーズや顧客の好みの急速な変化に対応するために意思決定の速度が速まるためです。

これらの問題を解決するには、リーダーがサポートしている開発、セキュリティ、運用の要件を尊重する共有カルチャを作成する必要があります。 この方法を採ると、チームは、より適切に協力できるようになり、セキュリティを改善しているか、運用上の安定性を高めているか、重要なビジネス機能を追加しているかにかかわらず、どのスプリントでも最も緊急度の高い問題を解決できるようになります。

リーダーの手法

これらの重要な手法は、リーダーが共有カルチャを構築するときに役立ちます。

1. すべての議論に勝つ勝者はいない: リーダーは、ビジネスに悪影響を及ぼす不均衡を招くことがあるあらゆる決定の優位に立つ単一の考え方は存在しないことを確認する必要があります。

2. 完璧ではなく継続的な改善を期待する: リーダーは、継続的な改善と継続的な学習の期待感を生む必要があります。 成功する DevSecOps プログラムの作成は一晩では行われません。 これは、漸進的な進行を伴う継続的な取り組みになります。

3. 共通の利益と一意の個々の価値の両方を歓迎する: チームが共通の結果に向けて努力し、各個人が他の個人では提供できないものを提供するようにします。 すべての要件の種類は、同じビジネス価値の作成と保護に関するものです。 開発チームは、新しい価値を作ろうとしますが、運用チームとセキュリティ チームは、別のリスク シナリオに対してその価値を保護し維持しようとします。 組織全体のすべてのレベルにおけるリーダーは、この共通性と、当面の成功と長期の成功の両方にとってすべての種類の要件を満たすことがどれだけ重要かを伝える必要があります。

4. 共有された理解を形成する: チームの全員は、次の点に関する基礎知識を持っている必要があります。

   • ビジネスの緊急度: チームは、問題となっている収益を明確に把握する必要があります。 このビューには、現在の収益 (サービスがオフラインの場合) と、アプリケーションおよび機能の提供の遅れに影響される可能性のある将来の収益が含まれます。 これは、リーダーの関係者からのシグナルに直接基づきます。
   • 可能性のあるリスクと脅威: 存在する場合は脅威インテリジェンス チームの入力に基づいて、チームは、アプリケーション ポートフォリオが直面する可能性のある脅威の意識を確立する必要があります。
   • 可用性の要件: チームは、必要なアップタイム、アプリケーションの予想されるライフタイム、トラブルシューティングなどの運用上の要件と、サービスがオンラインのときの適用などのメンテナンスの要件に関する共有意識を持つ必要があります。

5. 望ましい振る舞いを示してモデル化する: リーダーは、チームに求める振る舞いを公的にモデル化する必要があります。 謙虚さを示す、学習に集中する、他の原則を尊重する、などです。 別の例としては、開発マネージャーはセキュリティおよび高品質のアプリケーションの価値を議論するとか、セキュリティ マネージャーは急速なイノベーションおよびアプリケーション パフォーマンスの価値を議論するというものになります。

6. セキュリティ上の摩擦のレベルを監視する: セキュリティは必然的に摩擦を生み出し、これがプロセスの速度を低下させます。 セキュリティによって生じる摩擦のレベルと種類をリーダーが監視することが重要になります。

   • 健全な摩擦: 練習が筋肉を強くするのと同様に、適切なレベルのセキュリティ上の摩擦を DevOps プロセスに組み込んで、適時に批判的思考を強制することで、アプリケーションが強化されます。 チームが学習し、その学習内容を使用してセキュリティを強化する場合 (たとえば攻撃者がアプリケーションの侵害を試みる可能性のある理由と方法について考慮したり、重要なセキュリティ バグを検出して修正したりするなどの場合)、チームは順調に進んでいます。
   • 健全でない摩擦: 保護したときよりも多くの価値を妨害する摩擦に注意します。 これは多くの場合、ツールで生成されたセキュリティ バグの擬陽性の割合や誤検知が高い場合、または何かを修正するセキュリティ上の作業によって、攻撃の潜在的な影響を上回る影響が生じた場合に起こります。

7. セキュリティを予算計画に統合する: セキュリティ予算が、セキュリティへの他の投資に比例して割り当てられるようにします。 これは、標準的にイベント予算に物理的なセキュリティが含まれているコンサートなどの物理的なイベントに似ています。 一部の組織では、セキュリティのベスト プラクティスを一貫して適用できるように、一般的なルールとして、セキュリティに総コストの 10% を割り当てます。

8. 共有目標を確立する: アプリケーション ワークロードのパフォーマンスおよび成功のメトリックに、開発、セキュリティ、運用の目標が反映されるようにします。

Note

理想的には、組織全体か、特定のプロジェクトまたはアプリケーションかにかかわらず、これらのチームは共同でこれらの共有目標を作成して同意を最大化する必要があります。

DevSecOps MVP を識別する

アイデアから運用への移行中に、要件の種類ごとに、機能が最小要件または実用最小限の製品 (MVP) を満たすようにすることが重要です。

• 開発者 (dev) は、ユーザー、顧客、ビジネス リーダーの期待を満たす機能の迅速な提供を求めるビジネス ニーズの表現に重点を置きます。 機能が組織の成功に役立つようにするための最小要件を識別します。
• セキュリティ (sec) は、コンプライアンスの義務を満たし、組織のリソースから継続的に不正利益を得ようとする攻撃者から防御することに重点を置きます。 規制コンプライアンス要件を満たし、セキュリティ体制を維持し、セキュリティ運用で迅速にアクティブな攻撃を検出して応答するための最小要件を識別します。
• 運用 (ops) は、パフォーマンス、品質、効率性に重点を置き、ワークロードが長期にわたって価値を提供し続けられるようにします。 近い将来に大規模なアーキテクチャまたは設計の変更を必要とせずにワークロードを実行およびサポートできるようにするための最小要件を識別します。

チームが独自の経験や他の組織から一緒に学習すると、MVP の定義が時間の経過に伴い、さまざまなワークロードの種類に応じて変更する可能性があります。

ネイティブにセキュリティをプロセスに統合する

セキュリティ要件では、既存のプロセスやツールとのネイティブな統合に重点を置く必要があります。 次に例を示します。

• 脅威モデル化などの設計アクティビティを設計フェーズに統合する必要があります
• セキュリティ スキャン ツールは、Azure DevOps、GitHub、Jenkins などの継続的インテグレーションと継続的デリバリー (CI/CD) システムに統合する必要があります
• セキュリティの問題は、他のバグと同じバグ追跡システムおよびプロセス (たとえば、優先順位付けスキーム) を使用して報告する必要があります。

セキュリティをプロセスに統合する方法は、チームの学習とプロセスの成熟が進むに従い継続的に改善する必要があります。 セキュリティ レビューとリスク評価では、エンドツーエンドの開発プロセス、最終的な運用サービス、基になるインフラストラクチャに軽減策が統合されるようにする必要があります。

DevSecOps の詳細については、DevSecOps の技術制御に関するページを参照してください。

取り組みのナビゲートに関するヒント

変化では、取り組みにおいて漸次的にこの理想的な状態に向けて構築していくことが必要です。 多くの組織では、この取り組みでの複雑さと困難さを示す必要があります。 このセクションでは、組織が直面する共通のものをいくつか概説します。

• 教育とカルチャの変更が重要な初期の手順である:戦争に行くのは現有する軍隊とともにです。 多くの場合、現有しているチームが新しいスキルを開発し、新しいパースペクティブを採用して、DevSecOps モデルの他の部分を把握する必要があります。 この教育およびカルチャの変更では、個人が変更の価値を完全に理解し把握するために、時間、焦点、エグゼクティブ スポンサー、定期的なフォロー アップが必要になります。 カルチャやスキルの大幅な変更では、個々人の職業的同一性を利用することがあり、強烈な抵抗が発生する可能性があります。 各個人とその状況の変更の理由、内容、方法を理解し、表現することが重要です。
• 変更に時間がかかる: 進行の速度は、チームが新しい方法で物事を行ったときの影響に適応できるスピードに制限されます。 チームは変更の間、常に既存のジョブを実行する必要があります。 最も重要なものに慎重に優先順位を付け、この変更が行われるスピードについての予想を管理することが重要です。 最も重要で基本的な要素が先頭に置かれるクロール、ウォーク、ラン戦略に重点を置くと、組織に十分に役立ちます。
• 制限されたリソース: 組織が通常早い時期に直面する難題は、セキュリティとアプリケーション開発の両方で人材やスキルを見つけることです。 組織がより効果的に共同し始めると、セキュリティの考え方を持った開発者や、開発のバックグラウンドを持つセキュリティ専門家など、隠れた人材を見つける場合があります。
• アプリケーション、コード、インフラストラクチャの性質のシフト: アプリケーションの技術的な定義と構成は、サーバーレス、クラウド サービス、クラウド API、コードレス アプリケーション (Power Apps など) のようなテクノロジの導入により根本的に変更します。 このシフトにより、開発手法、アプリケーション セキュリティが変更され、さらには、開発者以外がアプリケーションを作成できるようになります。

Note

一部の実装では、運用とセキュリティの責務を Site Reliability Engineer (SRE) の役割にまとめています。

これらの責務を単一の役割にまとめるのは、一部の組織にとって理想的な最終状態である可能性がありますが、多くの場合、これは現在の企業の手法、カルチャ、ツール、スキル セットからの極端な変更になります。

SRE モデルを対象にしている場合でも、このガイダンスで概説した実践的なクイック ウィンと漸進的な進行を使用して、セキュリティを DevOps に組み込んで、確実に優れた投資収益率 (ROI) を実現し、当面のニーズを満たすようにすることから始めることをお勧めします。 これにより、運用担当者と開発担当者にセキュリティ上の責務が段階的に追加され、担当者は SRE の最終状態に近づきます (組織が後でこのモデルを採用する予定の場合)。

次のステップ

DevSecOps の詳細なガイダンスについては、DevSecOps の技術制御に関するページを参照してください。

GitHub の高度なセキュリティを継続的インテグレーションと継続的デリバリー (CI/CD) パイプラインに統合する方法については、GitHub の高度なセキュリティに関するページを参照してください。

Microsoft の IT 組織が DevSecOps を実装する方法の詳細とツールについては、セキュリティで保護された DevOps ツールキットに関するページを参照してください。