Microsoft 365 がアーキテクチャの検証を実行する方法について参照します
安全なシステム アーキテクチャは、それらのために設計されているセキュリティと回復力のレベルを提供するために実装され、正しく運用される必要があります。 Microsoft 365 のアーキテクチャは、定期的かつ自動的に、クラウドベースのツールを使用して検証され、Microsoft のセキュリティ原則との整合性を確認し、分離と回復の機能を継続的にテストしています。 アーキテクチャの検証には、主に 2 つの形式を使用しています。
- アーキテクチャと構成の評価: サービス アーキテクチャについての約束 (たとえば、特定のネットワークが正しくセグメント化されているか、またはコンピューターが必要なパッチを最新の状態にしているかなど) が守られているかどうか、また逆行していないかどうかを検証します。
- 侵入後の検証: 運用環境で監視システムや応答システムが期待通りに動作するかどうかを確認するために、Microsoft のインフラストラクチャに対する攻撃を直接シミュレートします。
どちらの形式の検証でも分析やレポートによる結果が出て、エラーを迅速に特定し、修復することができます。 検証に使用するツールは継続的に実行され、サービス全体を対象とするもの、または完全性が確保できない場合の代表サンプルを対象とするように構成されています。 Microsoft の監視や応答システムと同様に、検証システムもサービス全体を視野に入れています。 たとえば、Microsoft の攻撃シミュレーション ツールは、クラウドベースのコマンド システムとコントロール システムを使用してアクションを調整することで、サービス インフラストラクチャ全体をインテリジェントに移動するように設計されています。
侵害想定のメンタリティの一環として、攻撃によるダメージを最小限に抑えるために、サービス アーキテクチャを設計しています。 ネットワークの分離は、その好例です。 ただし、ネットワークの分離は時間の経過とともに劣化する可能性があります。 Microsoft のアーキテクチャ検証は、サービスの現在の状態が適切な状態と異なっているインスタンスを自動的に識別します。 たとえば、以前は使用されていなかったポートをリッスンする新しいサービスが導入された場合、新しいサービスの侵害によってサービスのセクション全体が横方向の移動のリスクにさらされる場合があります。 アーキテクチャ検証は、セキュリティに対する姿勢を低下させる可能性のあるアーキテクチャの変更を検出し、確認と緩和を目的としてこれらの変更にフラグを立てるのに役立ちます。
アーキテクチャ検証の目標は、サービス インフラストラクチャのセキュリティ機能が期待通りに機能することを保証することです。 セキュリティ コントロールの実装だけでは不十分です。 このような理由から、Microsoft のシステムや顧客を保護するために、システムは定期的に制御を検証しています。