セキュリティ戦略を定義する

セキュリティ組織にとっての最終目標が、クラウド サービスの導入によって変わることはありませんが、それらの目標がどのように達成されるかは変化します。 それでもセキュリティ チームは、攻撃からのビジネス リスクを低減することに集中し、すべての情報システムとデータに機密性、整合性、および可用性を組み込むために働く必要があります。

セキュリティ戦略を最新化する

組織は時間と共にクラウドを採用して運用するため、セキュリティ チームは戦略、アーキテクチャ、テクノロジを最新化する必要があります。 当初は変更の規模や数に圧倒されるように思えますが、セキュリティ プログラムの最新化を行えば、セキュリティ チームは、従来のアプローチに付随するつらい負担の一部を低減することができます。 組織は一時的に従来の戦略やツールを使用して運用することもできますが、このアプローチでは、クラウドと脅威の環境における変化のペースに耐えることが困難です。

• セキュリティ チームのセキュリティに関する考え方が (ビジネスを実現するのと同時に IT チームやビジネス チームと協力してリスクを軽減するのではなく)、回答が常に "いいえ" で始まる従来の "非干渉型" である場合、セキュリティ チームがクラウド導入の意思決定から外される可能性が高くなります。
• セキュリティ チームは、すべての防御と監視について、従来のオンプレミス ツールのみを使用し、もっぱらネットワーク境界のみによる対策に固執している場合、クラウドの攻撃を検出して防御するのが難しい時間を過ごすことになります。

クラウド規模での監視と保護

クラウド規模での防御は、重大な変換の取り組みであり、クラウドとモバイルの資産を監視し、保護することに役立てるため、クラウド ネイティブの検出と自動化の機能を利用し、ID 境界を導入することが求められます。

• Microsoft ID プラットフォームは、最新の認証および認可メカニズムをアプリケーションに組み込むのに役立ちます。
• Microsoft Sentinel は、組織全体でクラウドネイティブのセキュリティ分析と脅威インテリジェンスを提供し、脅威インテリジェンスの大規模なリポジトリと、クラウドのほぼ無制限の処理およびストレージ機能を利用する強化された脅威検出を可能にします。

セキュリティ チームが、セキュリティの最新化、つまり戦略の最も重要な側面の迅速な最新化、継続した段階的な改善、前進に向けて、アジャイル アプローチを採用することをお勧めします。

クラウドのセキュリティとクラウドからのセキュリティ

組織がクラウド サービスを採用するときには、セキュリティ チームが 2 つの主要目標に向けて作業をすることになります。

• クラウドのセキュリティ (クラウド リソースのセキュリティ保護): セキュリティをクラウド サービスの計画と運用に統合し、それらの中核的セキュリティ保証がすべてのリソースにわたって、一貫して適用されるようにする必要があります。
• クラウドからのセキュリティ (クラウドを使用したセキュリティの変革): セキュリティ チームは、クラウド テクノロジを使用してセキュリティ ツールとプロセス、特にネイティブに統合されるセキュリティ ツールを最新化する方法について、計画と検討をすぐに開始する必要があります。 クラウドでホストされるセキュリティ ツールが増えており、オンプレミス環境では実行が困難または不可能な機能が提供されています。

ソフトウェア定義データセンターのセキュリティ保護

多くの組織は、クラウド リソースを別の "仮想データセンター" として扱うことから始めます。これは、クラウドのセキュリティの効果的な出発点です。 クラウドからのセキュリティを使用して組織を最新化するときには、ほとんどの組織が、この思考モデルを迅速に脱しつつあることに気づきます。 ソフトウェア定義のデータセンターをセキュリティで保護することで、オンプレミス モデルで提供できるものを超えた機能が実現します。 クラウドでホストされるセキュリティ ツールには、次の機能が用意されています。

• セキュリティ機能の迅速な有効化とスケーリング。
• 非常に効果的な資産インベントリとセキュリティ構成の検疫に関する検出。

Microsoft Defender for Cloud のデプロイにより、組織のセキュリティ体制と制御の継続的な評価が有効になります。 クラウド リソースのセキュリティ体制が強化され、統合された Microsoft Defender プランにより、Defender for Cloud は Azure、ハイブリッド、その他のクラウド プラットフォームで実行されているワークロードを保護します。 Microsoft Defender for Cloud の詳細をご確認ください。

適切なレベルのセキュリティ上の摩擦

セキュリティによって、プロセスの速度を低下させる摩擦が自然に作り出されます。これは、DevOps や IT のプロセスにおいて健全な要素とそうでない要素を識別するために欠くことができません。

• 健全な摩擦: 練習での負荷が筋肉を強くするのと同様に、適切なレベルのセキュリティ上の摩擦を組み込んで、適時に批判的思考を強制することで、システムやアプリケーションが強化されます。 これは一般的に、攻撃者がアプリケーションまたはシステムの侵害を試みる可能性がある理由と方法について設計時に熟考し (脅威モデリングと呼ばれます)、攻撃者がソフトウェア コード、構成、または運用の実務において悪用できる潜在的脆弱性を調査して特定し、理想的には修正するという形を取ります。
• 健全でない摩擦: 保護するよりも多くの価値を妨げます。 これは多くの場合、ツールによって生成されるセキュリティ バグの誤検知 (誤ったアラームなどの) 率が高いときや、セキュリティの問題を検出したり修正したりする労力が、攻撃の潜在的影響を大幅に上回っているときに発生します。

単独での責任と統合された責任

機密性、整合性、および可用性の保証を提供するには、セキュリティ専門家が専用のセキュリティ機能を運用し、組織内の他のチームと緊密に連携する必要があります。

• 他にないセキュリティ機能: セキュリティ チームは、組織の他の場所では見つからない、独立した機能を実行します。セキュリティ操作や、(仮想マシン、コンテナーなどの) 脆弱性管理を始めとした機能です。
• 他の機能へのセキュリティの統合: セキュリティ チームは、組織内でビジネス イニシアチブの推進、リスクの評価、アプリケーションの設計や開発、IT システムの運用を行う他のチームや役目に対して、領域の専門家としての役割も果たします。 セキュリティ チームはこれらのチームに、攻撃者、攻撃の方法と傾向、未承認のアクセスを許す可能性がある脆弱性、および軽減策の手順や回避策の選択肢と、それらの潜在的な利点や落とし穴に関する専門知識とコンテキストを用いて助言します。 このセキュリティの機能は、1 つの結果を支えるために大小多くの場所に織り込まれる品質上の職務の機能に似ています。

クラウドにおけるすばやい変化のペースと、ビジネスの変革に遅れずについてゆきながらこれらの責任を果たすには、セキュリティ チームが、ツール、テクノロジ、およびプロセスを最新化することが必要です。

変革、マインドセット、期待

多くの組織は、組織内で同時に行われる、一連の複数の変革を管理しています。 これらの社内変革は、通常、モバイルとクラウドのテクノロジに対する顧客の新しい好みを満たすために、ほぼすべての外部市場が変化していることが理由で開始されます。 組織は多くの場合、新しいスタートアップ企業の競争上の脅威と、市場を崩壊させる可能性のある従来の競合他社のデジタル変革に直面します。

社内の変革プロセスには、一般に、以下が含まれています。

• 新しい機会をつかみ、デジタル ネイティブのスタートアップ企業に対して競争力を維持するための、ビジネスのデジタル変革。
• クラウド サービス、最新化した開発の実務、および関連する変更によってイニシアチブを支援するための、IT 組織のテクノロジ変革。
• クラウドに適応するのと同時に、ますます高度になる脅威の環境に対処するための、セキュリティの変革。

社内の争いが高くつく場合がある

変更によってストレスと争いが生じて、意思決定が急停止されることがあります。 これが特に該当するのは、セキュリティ リスクのアカウンタビリティを、ビジネス成果とその他のリスクの種類すべてについて責任がある資産の所有者 (経営者) ではなく、領域の専門家 (セキュリティ チーム) が誤って負わされているようなセキュリティ状態です。 このように誤って負わされるアカウンタビリティは、多くの場合、すべての利害関係者がセキュリティについて誤った見方をするために発生します。企業スパイや従来からのその他の犯罪行為のように、動的で継続的なリスクではなく、解決すべき技術的または絶対的問題として見なすのです。

変革のこの時期には、重要なプロジェクトとインセンティブ チームの両方が、セキュリティ リスクの軽減を無視するように狂わされることがある争いを軽減するために、すべてのチームのリーダーが積極的に作業する必要があります。 共倒れになるチーム間の争いが発生すると、以下の結果が生じる可能性があります。

• 回避可能なセキュリティ インシデントや攻撃によるビジネス上の損害の増加などの、セキュリティ リスクの増加 (特に、チームがセキュリティ部門に苛立ち、通常のプロセスをバイパスする場合や、旧式になったセキュリティ手法が攻撃者によって簡単にバイパスされる場合)。
• ビジネス プロセスが市場のニーズを満たすのに十分な速度で有効にされていない、または更新されていない場合などの、ビジネスやミッションに対する悪影響 (多くはセキュリティ プロセスが重要なビジネス イニシアチブを停滞させている場合)。

貴重なチーム メンバーがセキュリティで保護されず不安定のままになる可能性がある、移り変わる環境を進む助けとなるように、チーム内およびチーム間の関係の正常性を常に把握しておくことが非常に重要です。 これらのマインドセットに関する忍耐、共感、教育と、将来の明るい可能性を持つことが、チームがこの期間をより適切に乗り切り、組織にとって適切なセキュリティ上の結果を促進する助けとなります。

リーダーは、以下のように明確で事前対応型の手順を採用することで、文化的変化の推進を支援できます。

• チームに期待されるふるまいを公的にモデル化します。
• 適応するための自身の苦労を明らかにすることを含め、変更の課題について透明性を保ちます。
• セキュリティの最新化と統合の緊急性と重要性をチームに定期的に伝達します。

サイバーセキュリティの回復力

従来のセキュリティ戦略の多くは、攻撃の防止にのみ重点を置いてきました。これは、最新の脅威には十分でないアプローチです。 セキュリティ チームは、戦略が、この範囲の先を進んでいて、回復力を高めるために迅速な攻撃の検出、対応、回復を実現するものでもあることを確認する必要があります。 組織は、攻撃者が一部のリソースを侵害することを前提にして ("侵害の想定" とも呼ばれます)、(攻撃の防止を試みるだけの一般的な既定のアプローチではなく) 攻撃防止と攻撃管理の間で リソースと技術的設計のバランスが取れているようにする必要があります。

多くの組織は近年、攻撃の量や洗練度が着実に高まってきた状況を管理してきたため、既にこの取り組みを進めています。 この取り組みは、多くの場合、最初の主要なインシデントから始まります。これは、ユーザーが以前抱いていた、傷つけられない、安全であるといった感覚を失う感情的な出来事です。 この出来事は、人生を失うことと同じではありませんが、否定で始まり、最終的には受け入れで終わる同様の感情を引き起こす場合があります。 この「失敗」 を前提にすることは、最初は受け入れるのが難しい人たちもいる可能性がありますが、適切に確立された「フェールセーフ」の工学原理によく対応しており、この前提によって、チームは成功のより適切な定義である「回復力」に焦点を合わせることができます。

NIST サイバーセキュリティ フレームワークの機能は、回復力に関する戦略において、ID、保護、検出、対応、復旧の補完的な活動の間で投資のバランスを取る方法について、有益なガイドとして役立ちます。

サイバー セキュリティの回復力とサイバーセキュリティ制御の最終的な目標の詳細については、「組織のリスクを低く抑えたままにする方法」で説明しています。

クラウドによってセキュリティがどのように変化しているか

セキュリティのためにクラウドに移行することは、単純なテクノロジの変更ではなく、メインフレームからデスクトップやエンタープライズ サーバーに移行することに似た、テクノロジにおける世代交代です。 この変化を乗り切るのに成功するには、セキュリティ チームが期待することやマインドセットに根源的な変化が必要です。 適切なマインドセットや期待することを取り入れると、組織内の争いが軽減され、セキュリティ チームの有効性が向上します。

これらはどのセキュリティ最新化計画にも含まれている可能性がありますが、クラウドでの変化のペースは速いため、それらを導入することは緊急の優先事項となります。

• 共有される目標を持つパートナーシップ。 意思決定のペースが速く、プロセスが絶え間なく進化するこの時代に、セキュリティ部門はもはや、環境への変更を承認または拒否することに対して "非干渉型" のアプローチを採用できなくなっています。 セキュリティ チームは、ビジネス チームおよび IT チームと緊密なパートナーとなり、生産性、信頼性、およびセキュリティに関連して共有される目標を確立し、それらのパートナーと共同で作業してそれらの目標を達成する必要があります。

  このパートナーシップは、"シフト レフト" の最終的な形式です。これは、セキュリティ問題の修正を、より容易で効果的なものとするために、プロセスのより早期にセキュリティを統合するという原理です。 このためには、すべての関係者 (セキュリティ、ビジネス、IT) による文化的変化が必要で、それぞれが、自身の文化について他のグループに教えるのと同時に、他のグループの文化と規範を学習する必要があります。

  セキュリティ チームは以下のことを行う必要があります。

  • ビジネスと IT の目標のほか、それぞれが重要な理由と、変換時にそれらを達成することに関してどう考えているかについて学習します。
  • ビジネスに関するそれらの目標とリスクのコンテキストにおいてセキュリティが重要である理由、セキュリティ目標を達成するために他のチームが実行できること、およびそれを実行する必要がある方法を共有します。

  容易な作業ではありませんが、組織とその資産を持続可能な方法でセキュリティ保護するためには欠かせません。 このパートナーシップは、おそらく健全な妥協に至ることになります。この場合、当初達成されるのは最小限のセキュリティ、ビジネス、および信頼性のみですが、長期にわたって着実かつ段階的に改善される可能性があります。

• セキュリティは、1 つの問題ではなく継続的なリスクです。 犯罪を "解決する" ことはできません。 セキュリティの中核となっているのは、自然の出来事ではなく、人による悪意のある行為にたまたま焦点を合わせたリスク管理の規範にすぎません。 すべてのリスクと同様に、セキュリティは、解決策によって解決できる 1 つの問題ではありません。これは、否定的なイベント、すなわち攻撃による損害が起きる可能性と影響の組み合わせです。 これと最も共通点が多いのは、従来の企業スパイや犯罪活動であり、組織が直面するのは、組織への攻撃を成功させることが経済的誘因となっている、動機を持つ人間の攻撃者です。

• 生産性またはセキュリティのいずれかで成功を収めるには、両方が必要になります。 組織は、現在の "イノベーションを遂げるか無関係になるか" の環境において、セキュリティと生産性の両方に注力する必要があります。 組織が生産的ではなく、新しいイノベーションを推進していない場合、市場での競争力を失う可能性があります。それが、経済的な弱体化や最終的な破産を引き起こします。 組織がセキュリティで保護されておらず、攻撃者に対する資産の制御を失った場合、市場での競争力を失う可能性があります。それが、経済的な弱体化や最終的な破産を引き起こします。

• 何者も完璧ではありません。 クラウドの導入において完璧な組織はありません。Microsoft でさえも同様です。 Microsoft の IT チームとセキュリティ チームは、プログラムを適切に構造化する方法の検討や、従来のソフトウェアのサポートと最先端のイノベーションのサポートのバランスを取ることなど、お客様がしているのと同じ多くの課題に取り組んでいます。また、クラウド サービスに含まれるテクノロジ ギャップにさえ取り組んでいます。 これらのチームは、クラウドをより適切に運用してセキュリティで保護する方法を学習しているので、IT 紹介サイトで、このようなドキュメントで学んだ教訓を他者と積極的に共有しています。同時に、オファリングを改善するために、エンジニアリング チームやサードパーティ ベンダーに継続的にフィードバックを提供しています。

  Microsoft では、経験に基づいて、完璧さではなく、継続的に学習と改善を行うことにチームの基準を保つことをお勧めします。

• 変革における機会。 デジタル面の変革は、セキュリティ向上のための積極的機会であると考えることが重要です。 この変革の潜在的なマイナス面やリスクに気づくのは簡単ですが、セキュリティの役割を定義し直し、意思決定が行われる席を獲得するという大きな機会を逃すことも簡単です。 ビジネスとの連携によって、セキュリティ資金が増加する結果となり、セキュリティ分野で繰り返される無駄な労力を削減し、セキュリティ分野の作業をより楽しいものにできます。これは、組織のミッションにより深く結び付けられるためです。

共同責任モデルの採用

クラウドで IT サービスをホストすると、クラウド プロバイダーと顧客テナントとの間で、ワークロードに対する運用上とセキュリティ上の責任が分割され、共同責任による事実上のパートナーシップが形成されます。 すべてのセキュリティ チームは、新しい環境にプロセス、ツール、スキル セットを適合させるために、この共有責任モデルについて調査し、理解する必要があります。 これは、セキュリティ体制の中に、セキュリティ リスクやリソースの無駄になるギャップや重複が意図せず作られることを避ける助けとなります。

この図は、事実上のパートナーシップにあるクラウド ベンダーとクラウド顧客組織との間で、セキュリティに関する責任がどのように配分されるかを示しています。

異なるモデルのクラウド サービスが存在するため、各ワークロードに対する責任は、ワークロードがホストされているのが、サービスとしてのソフトウェア (SaaS) 上であるか、サービスとしてのプラットフォーム (PaaS) 上であるか、サービスとしてのインフラストラクチャ (IaaS) 上であるか、オンプレミスのデータセンター内であるかによって異なります。

セキュリティ イニシアチブの構築

この図は、クラウド用のセキュリティ戦略とセキュリティ プログラムの目標を調整するために、ほとんどのセキュリティ プログラムで従う必要のある 3 つの主なセキュリティ イニシアチブを示しています。

クラウドで回復性があるセキュリティ体制を構築するには、いくつかの並列する補完的アプローチが必要です。

• 信頼するが検証する: クラウド プロバイダーによって実行される責任については、組織は "信頼するが検証する" アプローチを取る必要があります。 組織は、クラウド プロバイダーのセキュリティ実施状況と、クラウド プロバイダーが提供するセキュリティ制御を評価し、組織のセキュリティ ニーズをクラウド プロバイダーが満たしていることを確認する必要があります。

• インフラストラクチャとアプリケーションのセキュリティの最新化: 組織の制御下にある技術的要素については、クラウド内のリソースをセキュリティで保護するための対象範囲のギャップを最小限に抑えるため、最新化するセキュリティ ツールおよび関連付けられたスキルセットに優先度を付けます。 これは、2 つの異なる補完的取り組みで構成されます。

  • インフラストラクチャのセキュリティ: 組織では、クラウドを使用して、オペレーティング システム、ネットワーク、コンテナー インフラストラクチャなどの多くのアプリケーションによって使用される共通コンポーネントを、保護および監視するためのアプローチを最新化する必要があります。 これらのクラウド機能には、多くの場合、IaaS 環境とオンプレミス環境の両方にわたってインフラストラクチャ コンポーネントを管理することが含まれます。 このインフラストラクチャは、アプリケーションと、その上で実行されるデータの依存関係となっていて、それが多くの場合、重要なビジネス プロセスを可能にして、重要なビジネス データを格納するため、この戦略を最適化することが重要です。

  • アプリケーションのセキュリティ: 組織は、組織によって、または組織のために開発された独自のアプリケーションとテクノロジを、セキュリティで保護する方法を最新化する必要もあります。 この分野は、DevOps アジャイル プロセスの導入、オープンソース コンポーネントの使用の増加、アプリケーション コンポーネントの置き換えやアプリケーションの相互接続を目的としたクラウド API とクラウド サービスの導入によって急速に変化しています。

    これらのアプリケーションは重要なビジネス プロセスを実現し、重要なビジネス データを格納することが多いため、この権限を得ることが非常に重要です。

  • 最新の境界: 組織は、すべてのワークロードにわたってデータを保護するために、包括的なアプローチを備える必要があります。また、組織は一貫性があり、一元的に管理される ID 制御による最新の境界を確立し、データ、デバイス、アカウントを保護する必要があります。 これは、CISO ワークショップのモジュール 3 で詳細に説明されているゼロ トラスト戦略に大きく影響されています。

セキュリティと信頼

セキュリティ分野で "信頼" という用語を使用すると、混乱を招く場合があります。 このドキュメントでは、この概念の有益な用途を示す 2 つの方法で、それについて言及します。

• ゼロ トラストは、企業やイントラネットのネットワークは悪意のあるもの ("ゼロ トラスト" に値する) と想定し、それに応じてセキュリティを設計するという、セキュリティに対する戦略的アプローチを表す一般的な業界用語です。
• 信頼するが検証するは、関心事が異なっている可能性があっても、共通の目標に向けて共同作業を行う 2 つの異なる組織の本質を捉えた表現です。 これは、組織向け商用クラウド プロバイダーとパートナーになる初期段階における、微妙な関係の多くの面を簡潔に捉えています。

クラウド プロバイダーとその実施方法およびプロセスは、契約上および規制上の要件を満たすために説明責任を負っている場合があり、信頼を得ることも失うこともあります。 ネットワークは、攻撃者によって使用される場合に結果に直面することができない、無生物の接続です (道路や車に、それらを使用している犯罪者についての責任を負わせることができないこととよく似ています)。

クラウドによってセキュリティの関係と責任はどのように変化するか

以前に、デスクトップ コンピューティングやエンタープライズ サーバー コンピューティングなどの新世代のテクノロジに移行したときと同様に、クラウド コンピューティングへの移行は、長期に確立された関係、役割、責任、およびスキル セットを崩壊させつつあります。 過去数十年間にわたって慣れてきたジョブの説明は、今ではクラウド機能を含むようになった企業にはすっきりと対応していません。 業界が全体として、新しいモデルの標準化に取り組んでいるため、組織では、こうした変化の期間中のあいまいさに伴う不確実性を管理するのに役立つよう、できるだけ明確さを高めることに集中する必要があります。

セキュリティ チームは、ビジネスと、サポートするテクノロジにおけるこれらの変化に加えて、より適切に脅威アクターに適応するための社内の最新化の取り組みにも影響を受けます。 攻撃者は、組織の人間、プロセス、テクノロジの弱点を悪用するために、活発に進化して最も容易に利用できる弱点を絶えず探しており、セキュリティでは、これらの視点に対処するための機能とスキルを開発する必要があります。

このセクションでは、クラウドへの移行過程で頻繁に変化する主な関係について説明します。これには、リスクを最小限に抑え、改善の機会を活かすことについて学んだ教訓も含まれています。

• セキュリティとビジネス関係者との間: セキュリティ リーダーは、組織でリスクの軽減を可能にするために、ますますビジネス リーダーと連携する必要が生じてきます。 セキュリティ リーダーは、セキュリティ領域の専門家 (SME) としてビジネス上の意思決定を支援する必要があり、これらのビジネス リーダーにとって信頼できるアドバイザーに成長するよう努力する必要があります。 この関係は、ビジネス リーダーがビジネス上の意思決定をするときにセキュリティ リスクが確実に考慮されるようにする助けになります。また、ビジネス上の優先事項のセキュリティについて情報を提供し、セキュリティ投資が、他の投資と共に適切に優先度付けされるようにする助けになります。

• セキュリティ リーダーとチーム メンバーとの間: セキュリティ リーダーは、ビジネス リーダーからのこうした分析情報をチームに持ち帰り、チームでの投資優先度の指針とする必要があります。

  セキュリティ リーダーは、従来の "非干渉型" の関係ではなく、ビジネス リーダーとチームが連携する気風を育むことで、セキュリティと生産性の両方の目標を妨げる敵対的な動きを回避できます。

  セキュリティ リーダーは、生産性とセキュリティのトレードオフについて日々の意思決定をどのように管理するか、チームに明確に示そうと努める必要があります。これは、チームの多くのメンバーにとって新しいことの可能性があるためです。

• アプリケーション チームとインフラストラクチャ チーム (およびクラウド プロバイダー) との間: IT およびセキュリティ業界には、イノベーションの速度と開発者の生産性の向上を目的とした複数の傾向があるため、この関係は大きく変化しているところです。

  以前の規範や組織の機能は崩壊してきましたが、新しい規範と機能はまだ新たに登場しつつある状況なので、あいまいさを受け入れ、現在の考え方に遅れずについてゆき、組織に対して何がよく機能するかを成功するまで試すことが推奨されます。 この領域で様子見のアプローチを採用すると、組織は競争上大きく不利な立場に立たされる可能性があるため、これはお勧めしません。

  これらの傾向は、アプリケーションとインフラストラクチャの役割や関係に関する従来の規範に課題を突き付けています。

  • DevOps によって融合する規範: 理想的な状態では、これにより、両方の領域の専門知識のセットを組み合わせて迅速にイノベーションを行い、更新をリリースし、問題 (セキュリティやその他) を解決する、高度な機能を備えた単一チームが効果的に形成されます。 この理想的な状態を達成するのには一定の時間がかかり、その最中の責任はあいまいなままであるものの、組織では既にこの協調型アプローチによる迅速なリリースの恩恵をいくつか受けています。 これらの文化を学び、セキュリティに関する学習を共有し、セキュリティで保護された信頼できるアプリケーションを迅速にリリースするという共通の目標に向けて仕事をする助けとなるよう、このサイクルにセキュリティを統合することが推奨されます。

  

  • 共通のインフラストラクチャ コンポーネントになるコンテナー化: アプリケーションは、Docker、Kubernetes、それらに類似したテクノロジなどのテクノロジによって、ますますホストされ、調整されるようになってきています。 これらのテクノロジでは、基礎となるオペレーティング システムのセットアップと構成の多くの要素を抽象化することで、開発とリリースが簡略化されます。

  

  コンテナーは、開発チームによって管理されるアプリケーション開発テクノロジとして始まりましたが、ますますインフラストラクチャ チームに移行しつつある共通インフラストラクチャ コンポーネントに変化しています。 この移行は、多くの組織でまだ進行中ですが、現在の課題の多くがネットワーク、ストレージ、容量管理などの従来のインフラストラクチャ スキル セットを使用して最適に解決される、自然で肯定的な方向です。

  インフラストラクチャ チームと、それをサポートするセキュリティ チーム メンバーには、このテクノロジを管理、監視、およびセキュリティで保護するのに役立つトレーニング、プロセス、およびツールを提供する必要があります。

  • サーバーレスとクラウド アプリケーション サービス: 現在業界で最も際立っている傾向の 1 つは、アプリケーションのビルドや更新するために必要な時間と開発作業の量を削減することです。

    

    開発者も、以下のためにクラウド サービスをますます使用するようになりつつあります。

    • 仮想マシン (VM) やサーバーでアプリケーションをホストするのではなく、コードを実行します。
    • 独自のコンポーネントを開発するのではなく、アプリケーション機能を提供します。 これが、共通の機能には既存のクラウド サービスを使用するサーバーレス モデルにつながってきました。 クラウド サービス (とそれらのイノベーションのペース) の数と多様性も、それらのサービスの使用を評価して承認するセキュリティ チームの能力を超えました。セキュリティ チームに残された選択肢は、開発者がどのサービスでも使用できるようにするか、開発チームが未承認のサービスを使用することを防ごうと試みるか、より良い方法を見つけようと試みるかです。
    • コード不要アプリケーションと Power Apps: もう 1 つの新たな傾向は、Microsoft Power Apps などのコード不要テクノロジの使用です。 このテクノロジを使用すると、コーディング スキルを持たない人が、ビジネス成果を達成するアプリケーションを作成できるようになります。 このように摩擦が弱く高価値の可能性があるため、この傾向の人気が急速に高まる可能性があり、セキュリティの専門家は、その影響をすばやく理解することが賢明でしょう。 セキュリティの取り組みは、人がアプリケーション内でミスをする可能性がある領域に焦点を絞る必要があります。つまり、アプリケーション コンポーネント、相互作用/関係、およびロールのアクセス許可をモデル化する、脅威を介したアプリケーションと資産のアクセス許可の設計です。

• 開発者とオープンソース コンポーネント作成者: 開発者も、独自のコンポーネントを開発するのではなく、オープンソースのコンポーネントとライブラリを使用することによって効率を高めています。 これによって効率を通して価値がもたらされますが、外部への依存関係と、それらのコンポーネントの適切な保守と修正を行うための要件が作成されることで、セキュリティ リスクも生じます。 開発者は事実上、これらのコンポーネントを使用するときにセキュリティのリスクやその他のバグを想定しているので、開発するコードと同じ基準で、それらを軽減する計画が存在するようにする必要があります。

• アプリケーションとデータとの間: データのセキュリティとアプリケーションとの境界線は、ところどころあいまいになってきていて、新しい規制では、データ/プライバシー チームとセキュリティ チームとの間により緊密な連携が求められるようになっています。

  • 機械学習のアルゴリズム: 機械学習のアルゴリズムは、データを処理して結果を生成するように設計されているという点で、アプリケーションに似ています。 主な違いは次のとおりです。

    • 高価値の機械学習: 機械学習には、多くの場合、競争上の大きなメリットがあって、機密の知的財産かつトレード シークレットであると考えられることがよくあります。

    • 秘密度のインプリント: 監視される機械学習は、データセットを使用してチューニングされます。その際、アルゴリズムではデータセットの特性がインプリントとして出力されます。 このため、チューニングされたアルゴリズムは、そのトレーニングに使用されたデータセットのために機密であると見なされる可能性があります。 たとえば、軍の秘密基地のデータセットを使用して、地図で軍の秘密基地を見つける機械学習アルゴリズムをトレーニングすると、それが機密資産になります。

    Note

    すべての例が明確なわけではないため、データ サイエンス チーム、ビジネス上の利害関係者、セキュリティ チーム、プライバシー チームなどの適切な利害関係者と一緒にチームを編成することが重要です。 これらのチームが、イノベーションと責任の共通目標を達成する責任を負う必要があります。 セキュリティ保護されていない構成になっているデータのコピーを保存する方法と場所、アルゴリズムの分類方法、もしあれば組織の懸念事項など、一般的な問題に対処する必要があります。

    Microsoft は、自社独自のチームとお客様のガイドとなる信頼のおける AI の原則を公開してきました。

    • データの所有権とプライバシー: GDPR のような規制により、データの問題とアプリケーションの可視性が向上してきました。 アプリケーション チームは、銀行や金融機関による財務データの追跡に匹敵するレベルで、機密データの制御、保護、追跡を行うことができるようになりました。 データ所有者とアプリケーション チームは、データ アプリケーションで何が格納され、どのような制御が必要とされているかについて、豊富な知識を身に付ける必要があります。

• 組織とクラウド プロバイダーとの間: 組織はクラウドでワークロードをホストするので、これらのクラウド プロバイダーそれぞれと、ビジネス上の関係を結ぶことになります。 クラウド サービスの使用により、多くの場合、以下のようなビジネス価値がもたらされます。

  • 新機能の市場投入までの時間を短縮することで、デジタル変革イニシアチブがスピードアップされます。

  • チームの代わりにクラウド サービスによってより効率的に提供される低レベルの日常的タスクではなく、より価値が高い (ビジネス目標に合った) アクティビティに集中するためにチームを解放することで、IT とセキュリティ アクティビティの価値を高めます。

  • 信頼性と応答性の向上: ほとんどの最新クラウドでは、従来のオンプレミス データセンターと比較してアップタイムも高く、(COVID-19 のパンデミック中のように) 高速にスケールできることが示されています。また、落雷のような自然の出来事の後に回復機能が提供されます (多くのオンプレミスの同等のものなら、よりずっと長い間停止したままでしょう)。

    クラウドへのこの移行は有益であるものの、リスクがないわけではありません。 クラウド サービスを採用する組織は、次のような潜在的リスク領域を考慮に入れる必要があります。

  • 事業継続とディザスター リカバリー: クラウド プロバイダーには、顧客の組織がサービスを使用している間に生き残って繁栄する可能性が高いビジネス モデルがあり、経済的に健全ですか。 クラウド プロバイダーでは、プロバイダーが財務上またはその他の障害を経験している場合に、顧客にソースコードを提供したり、そのオープン ソース化を行ったりするなどして、顧客の事業継続が可能なように準備されていますか。

    Microsoft の財務上の正常性に関する詳細情報とドキュメントについては、Microsoft のインベスター リレーションズに関するページを参照してください。

  • セキュリティ: クラウド プロバイダーは、セキュリティに関する業界のベスト プラクティスに従っていますか。 独立した規制機関によって検証されていますか。

    • Microsoft Defender for Cloud Apps では、16,000 個を超えるクラウド アプリケーションの使用状況を検出できます。これらは 70 個を超えるリスク要因に基づいてランク付けとスコア付けが行われ、クラウドの利用状況、シャドウ IT、シャドウ IT が組織に与えるリスクを継続的に把握できます。
    • Microsoft Service Trust Portal では、規制コンプライアンスの認定、監査レポート、侵入テストなどをお客様に提供しています。 これらのドキュメントには、社内のセキュリティ実施状況に関する多くの詳細が含まれています (特に SOC 2 Type 2 レポートや FedRAMP Moderate のシステム セキュリティ計画)。 Microsoft Defender for Cloud では、セキュリティ ポリシーの管理が可能であり、定義済みの業界標準と規制標準に準拠するレベルを示すことができます。

  • ビジネス上の競合他社: そのクラウド プロバイダーは、業界において重要なビジネス上の競合他社ですか。 クラウド サービス契約やその他の手段で、悪意のある可能性のあるアクションからビジネスを保護するために十分な保護が用意されていますか。

    Microsoft がクラウドのお客様との競合を回避する方法に関する解説については、この記事を参照してください。

  • マルチクラウド: 多くの組織は、事実上または意図的に、マルチクラウド戦略を採用しています。 これは、1 つのサプライヤーへの依存を軽減したり、独自の最高水準の機能を利用したりするための意図的な目標である場合もありますが、開発者が優先したい、または使い慣れているクラウド サービスを選択したため、または組織が他のビジネスを買収したために起きる場合もあります。 その理由にかかわらず、この戦略によって、以下のような、管理する必要がある潜在的リスクとコストが生じる可能性があります。

    • 複数の依存関係からのダウンタイム: 複数のクラウドに依存するように設計されたシステムは、クラウド プロバイダーでの中断 (またはチームによるそれらの使用) によってビジネスの停止や中断が発生する可能性があるため、より多くのダウンタイム リスク発生源にさらされます。 このようにシステムの複雑さが増すと、チーム メンバーがより複雑なシステムを完全に理解する可能性も下がるため、中断イベントが起きる可能性も高くなります。
    • 交渉力: 大規模な組織では、組織の機能要求を優先させるために、クラウド プロバイダーにより大きな影響を与えることができるのは、単一クラウド戦略 (相互コミットメント/パートナーシップ) とマルチクラウド戦略 (ビジネスを移行する能力) のどちらであるかについても検討します。
    • メンテナンス オーバーヘッドの増加: IT とセキュリティ リソースには、既存のワークロードと、1 つのクラウド プラットフォームの変更に対応するための過度の負担が既にかかっています。 プラットフォームを追加するたびに、このオーバーヘッドがさらに増加し、チーム メンバーは、ビジネス イノベーションを加速させる技術プロセスの合理化や、テクノロジのより効率的な使用に関するビジネス グループとの協議など、より高い価値があるアクティビティから離されることになります。
    • スタッフ配置とトレーニング: 組織は多くの場合、複数のプラットフォームをサポートするために必要なスタッフ配置の要件や、速いペースでリリースされる新機能の知識と伝達力を維持するために必要なトレーニングについて考慮していません。