DoD Zero Trust戦略とロードマップでは、国防総省のコンポーネントと防衛産業基盤 (DIB) パートナーがZero Trust原則に基づいて新しいサイバーセキュリティ フレームワークを採用するための道筋が示されています。 Zero Trustは、従来の境界と信頼の前提を排除し、セキュリティ、ユーザー エクスペリエンス、ミッション パフォーマンスを強化する、より効率的なアーキテクチャを実現します。
このガイドには、DoD Zero Trust Capability Execution ロードマップの 152 Zero Trust アクティビティに関する推奨事項があります。 セクションは、DoD Zero Trust モデルの 7 つの柱に対応しています。
ガイドの各セクションに移動するには次のリンクを使用してください。
- Introduction
- User
- デバイス
- アプリケーションとワークロード
- データ
- Network
- 自動化とオーケストレーション
- 可視性と分析
3 アプリケーションとワークロード
このセクションには、アプリケーションとワークロードの柱における DoD Zero Trust アクティビティに関する Microsoft のガイダンスと推奨事項が記載されています。 詳細については、Zero Trust を用いたアプリケーションセキュリティについて参照してください。
注意
このセクションの推奨事項は、ドラフトの「DoD エンタープライズ DevSecOps 参照設計」に沿っています。
3.1 アプリケーション インベントリ
Microsoft Entra IDは、Microsoft 365やAzureだけでなく、アプリケーションとクラウド プラットフォームの ID プロバイダー (IdP) です。 Microsoft Entra IDには、統合アプリケーションの一覧を取得するための Web ポータルと RESTful API が含まれています。 Microsoft Defender XDRのコンポーネントであるMicrosoft Defender for Cloud Appsには、承認されていないアプリを検出、インベントリ、ブロックする機能があります。
| DoD アクティビティの説明と結果 | Microsoft ガイダンスと推奨事項 |
|---|---|
Target
3.1.1 アプリケーション/コードの識別DoD 組織は、承認されたアプリケーションとコード (ソース コード、ライブラリなど) のインベントリを作成します。 各組織は、少なくともインベントリ内のサポート可能性 (アクティブ、レガシなど) とホストされている場所 (クラウド、オンプレミス、ハイブリッドなど) を追跡します。 結果: - コンポーネントがアプリケーションを識別し、レガシ、仮想化されたオンプレミス、およびホストされているクラウドのいずれかに分類します |
Microsoft Entra ID Microsoft Entra管理センターを使用して、Microsoft Entra に登録されているアプリケーションの一覧をダウンロードします。 上部のリボンで、 を選択します。- 組織が Active Directory Federation Services (AD FS) を使用している場合は、Microsoft Entra Connect Health を展開します。 アプリケーション活動レポートを使用して、AD FS アプリケーションを発見してください。 - Connect Health を使用して AD FS を監視する - アプリケーション活動レポート Microsoft Defender 脆弱性管理 Defender 脆弱性管理でソフトウェアインベントリを使用し、組織のソフトウェアを確認します。 - ソフトウェアインベントリ Microsoft Defender for Cloud Apps Defender for Cloud Appsで Cloud Discovery を設定し、ユーザーがアクセスしたアプリケーションのスナップショットを取得します。 - Cloud Discovery のセットアップ - アプリを調査する Microsoft Intune で発見されたアプリ テナント内の Intune 登録デバイスによって検出された Intune でのアプリです。 これは、テナントのソフトウェア インベントリです。 企業のデバイスでは、アプリまたは管理されたアプリはこの報告書用に収集されません。 - Discovered apps Azure DevOps このサービスは、安全なパッケージ管理のために利用します。 開発者はコードを共有し、パッケージを 1 つの場所で管理します。 - Azure Artifacts - Azure GitHub リポジトリ |
3.2 セキュリティで保護されたソフトウェア開発と統合
GitHub Advanced Security (GHAS) や GitHub Actions などのGitHub機能は、Zero Trustソフトウェアの開発と展開のプラクティスを確立するのに役立ちます。 GitHub Enterprise Cloud は、Microsoft Entra IDと統合して、条件付きアクセス ポリシーを使用してMicrosoft Entra ID Governanceとセキュリティで保護されたアクセス権を管理します。
開発者は、Microsoft Authentication Libraries (MSAL) を使用して、アプリケーションをMicrosoft Entra IDと統合できます。 詳細については、「authenticate users for Zero Trust」を参照してください。
| DoD アクティビティの説明と結果 | Microsoft ガイダンスと推奨事項 |
|---|---|
Target
3.2.1 DevSecOps ソフトウェア ファクトリの構築 パート 1DoD エンタープライズは、最新の DevSecOps プロセスと CI/CD パイプラインの基盤になる標準を作成します。 この概念は、将来のアプリケーション セキュリティ要件を満たすことができる DoD 組織全体にわたって標準化されるテクノロジ スタックに適用されます。 エンタープライズ全体の脆弱性の管理プログラムが、脆弱性の管理プログラムのアクティビティに従う CI/CD パイプラインと統合されます。 結果: - DevSecOps用の開発されたデータ/サービス標準 - CI/CD パイプラインが完全に機能し、テストに合格します - 脆弱性の管理プログラムが正式に設置され、運用されます |
GitHub Actions GitHub Actions は、継続的インテグレーションと継続的デリバリー (CI/CD) を使用してデプロイメントパイプラインを自動化します。 - GitHub Actions GitHub Advanced Security GitHub Advanced Security は、GitHub と Azure DevOps のセキュリティを強化して、コードと開発プロセスの保護を向上させます。 - Azure DevOps のための高度なセキュリティ - Azure DevOps のための高度なセキュリティ Microsoft Entra SSO とプロビジョニング Microsoft Entra ID を使用して Git ツールのためのシングルサインオン (SSO) を構成します。 - GitHub Enterprise Cloud 組織との SSO 統合 - GitHub Enterprise Server との SSO 統合 - 組織を Microsoft Entra ID に接続する Azure その他のクラウドの DevSecOps の詳細については、DoD Chief Information Officer (CIO) ライブラリ を参照してください。 |
Target
3.2.2 DevSecOps ソフトウェア ファクトリの構築 パート 2DoD 組織は、承認された CI/CD パイプラインを使用して、ほとんどの新しいアプリケーションを開発します。 除外規定については、従来の方法で開発が許可されるように、標準化された承認プロセスに従う必要があります。 DevSecOps プロセスは、すべての新しいアプリケーションの開発と、既存のアプリケーションの更新にも使用されます。 継続的な検証機能が CI/CD パイプラインと DevSecOps プロセスに統合され、既存のアプリケーションと統合されます。 結果: - アプリケーションの開発が CI/CD パイプラインに移行されます - 継続的な検証プロセス/テクノロジが実装され、使用されます - アプリケーションの開発が DevSecOps プロセスとテクノロジに移行されます |
GitHub Advanced Security GitHub Advanced Security を使用してコードの依存関係と脆弱性をスキャンします。 コード品質を評価するため、定期的なビルドを構成します。 |
Target
3.2.3 アプリケーション セキュリティの自動化とコード修復 パート 1アプリケーション セキュリティに対する標準化されたアプローチ (コード修復を含む) が、DoD エンタープライズ全体にわたって実装されます。 このアクティビティのパート 1 には、API または同様の呼び出しを利用するアプリケーションとセキュリティで保護された API ゲートウェイの統合が含まれています。 コード レビューは系統的アプローチで実施され、コンテナーとそのインフラストラクチャに対する標準化された保護機能が設置されます。 さらに、サービスとしてのプラットフォームなどのインフラストラクチャをサードパーティが管理するサーバーレス機能が、適切なサーバーレス セキュリティ モニター機能と応答機能を利用します。 コード レビュー、コンテナー、サーバーレスのセキュリティ機能が、必要に応じて CI/CD または DevSecOps プロセスに統合されます。 結果: - セキュリティで保護された API ゲートウェイが運用可能になり、API 呼び出しの大半がゲートウェイを通過します - アプリケーション セキュリティ機能 (コード レビュー、コンテナー、サーバーレス セキュリティなど) が CI/CD と DevSecOps の一部として実装されます |
Azure Application Gateway Azure Application Gateway および Web Application Firewall を使用して、パブリックにアクセスできる Web アプリケーションと API を設置してください。 - Web Application Firewall Microsoft Entra ID アプリケーション Microsoft Entra ID は、Web アプリケーションと API へのアクセスを承認するゲートウェイです。 Microsoft Entraを使用して登録済みアプリケーションの API を公開します。 Azure App ServiceとAzure Functionsで組み込みの認証と承認 (Easy Auth) を使用します。 Microsoft Entra ID非対応 API の場合は、OAuth 認可を使用して Azure API 管理を行います。 - Web API を公開するためのアプリケーションの構成 - 認証を行い、Azure App Service および Azure Functions で承認します - API への認証と承認 GitHub Advanced Security GitHub および Azure DevOps のために GitHub Advanced Security を使用します。 Microsoft のガイダンスは 3.2.1 を参照してください。 Microsoft Defender for Cloud API ワークロードを持つ Azure サブスクリプションに対して、Defender for Cloud ワークロードの保護を有効にします。 3.2.2 の Microsoft ガイダンスを参照してください。 |
Advanced
3.2.4 アプリケーション セキュリティの自動化とコード修復 パート 2DoD 組織は、マイクロサービスなどのベスト プラクティスアプローチに従って、内部で開発および管理されたサービスを提供するアプローチを最新化します。 これらのアプローチにより、セキュリティの問題が検出されたときに、各マイクロサービスのコードをより迅速に変更できるため、より回復性と安全性の高いアーキテクチャが可能になります。 DoD エンタープライズ全体でセキュリティ修復アクティビティがさらに進み、必要に応じてコンテナーのランタイム セキュリティ機能、脆弱なライブラリの自動更新、およびリリース プロセス中の自動 CI/CD 承認が含められます。 結果: - セキュリティで保護された API ゲートウェイが運用可能になり、API 呼び出しの大半がゲートウェイを通過します - サービス指向アーキテクチャ (SOA) に従ってサービスが提供されます - セキュリティ修復アクティビティ (ランタイム セキュリティ、ライブラリの更新、リリース承認など) が完全に自動化されます |
アクティビティ 3.2.2 と 3.2.3 を完了します。 |
3.3 ソフトウェア リスク管理
GitHub Actions DevSecOps のソフトウェア開発ワークフローの自動化、カスタマイズ、実行に役立ちます。 GitHub Actionsを使用して、ソフトウェア部品表 (SBOM) を生成し、コードを分析し、サプライ チェーンと依存関係の脆弱性をスキャンします。 GitHub Actionsの詳細については、GitHub Actionsを参照してください。
| DoD アクティビティの説明と結果 | Microsoft ガイダンスと推奨事項 |
|---|---|
Target
3.3.1 承認されたバイナリ/コードDoD エンタープライズは、ベスト プラクティス アプローチを使って、承認されたバイナリとコードを系統的アプローチで管理します。 これらのアプローチには、サプライヤー調達のリスク管理、承認されたリポジトリの使用、部品表のサプライ チェーン リスク管理、業界標準の脆弱性の管理が含まれます。 結果: - 承認されたソースに対してサプライヤー調達のリスクが評価および識別されます - 開発チームが使用するためのリポジトリと更新チャネルが確立されます - アプリケーションがソース、サポート可能性、リスク態勢を識別するために、部品表が作成されます - DevSecOps で使用するために、業界標準 (DIB) と承認された脆弱性データベースがプルされます |
GitHub Actions DevSecOps プロセスを標準化して、継続的インテグレーションおよび継続的デリバリー (CI/CD) パイプラインを使用してソフトウェア部品表 (SBOM) を生成します。 - ソフトウェアの部品表を生成する GitHub Dependabot と CodeQL を使用して、セキュリティ チェックを自動化し、依存関係の脆弱性をスキャンします。 - CodeQL コード スキャン - 安全なサプライ チェーン WindowsDefender アプリケーション制御 信頼されていないコードがマネージド エンドポイントで実行されないようにするには、Windows Defender アプリケーション制御を使用します。 - アプリケーション制御 およびアプリ ロッカー - Platform コード整合性 |
Target
3.3.2 脆弱性の管理プログラム パート 1DoD エンタープライズは、組織と連携して脆弱性の管理プログラムを確立および管理します。 このプログラムには、すべての組織によって合意されたポリシーと標準が含まれます。 開発されたプログラムには、DoD アプリケーション/サービスに基づくパブリック脆弱性の追跡と管理が最低でも含まれています。 組織は主要な利害関係者とともに脆弱性の管理チームを設立し、そこでエンタープライズ ポリシーと標準に従って脆弱性が議論および管理されます。 結果: - 適切な利害関係者メンバーシップの脆弱性の管理チームが設置されます - 脆弱性の管理ポリシーとプロセスが設置され、利害関係者から合意されます - 脆弱性のパブリック ソースが追跡に利用されます |
脅威と脆弱性の管理 VM の機能により、資産の可視性とインテリジェントな評価が可能になります。 TVM には、エンドポイントとサーバー用の組み込みの修復ツールがあります。 TVM と脆弱性管理プログラムを使用します。- Microsoft Defender TVMMicrosoft クラウド セキュリティ ベンチマークでMicrosoft のオンラインサービスがどのように脆弱性管理を実施しているかを確認します。TVM の概要、体制、および脆弱性管理を見直します。 |
Target
3.3.3 脆弱性の管理プログラム パート 2パブリックとプライベートの両方からアクセス可能な DoD で維持/運用されるサービスの脆弱性の漏えいを管理するために、DoD エンタープライズ レベルでプロセスが確立されます。 DoD 組織が脆弱性の管理プログラムを拡張して、DIB、CERT などの閉じた脆弱性リポジトリを追跡および管理します。 結果: - 制御された脆弱性のソース (DIB、CERT など) が追跡に利用されます - 脆弱性の管理プログラムに、マネージド サービスの外部/公的開示を受け入れるプロセスがあります |
|
Target
3.3.4 継続的な検証DoD 組織は、アプリケーション開発に継続的な検証アプローチを実装します。このアプローチでは、並列デプロイが実施され、承認された環境レベル (ユーザー受け入れテスト、運用など) と統合されます。 CI/CD プロセスに継続的な検証を統合できないアプリケーションが識別され、必要に応じて系統的アプローチを使用した除外機能が提供されます。 結果: - 更新されたアプリケーションがライブ環境または運用環境、あるいはその両方にデプロイされます - 廃止と移行のマークが付けられたアプリケーションは使用が停止されます - 継続的な検証ツールが実装され、CI/CD パイプライン内のコードに適用されます - 継続的な検証を必要とするコードが識別され、検証基準が確立されます |
Azure Chaos Studio ワークロードを検証するためにAzure Chaos Studioを使用します。 - 継続的な検証 GitHub Advanced Security GitHubの機能とアクションを使用して、DoDエンタープライズのDevSecOpsリファレンスデザインで脆弱性管理を行います。 Microsoftのガイダンスは3.2.1を参照してください。 |
3.4 リソースの承認と統合
条件付きアクセスは、Microsoft Entra IDのZero Trust ポリシー エンジンです。 アプリケーション ワークロードをMicrosoft Entra IDに接続します。 Microsoft Entra ID Governanceを使用して、条件付きアクセス ポリシーを使用して権利を管理し、サインインをセキュリティで保護します。 ポリシーは、デバイスの正常性、セッションの詳細、リスクなどのセキュリティ属性を使用して、アダプティブ アクセスの決定を行います。 Microsoft Entra ID、Azure Resource Manager、および CI/CD パイプラインは、Azureでのリソースのデプロイを承認します。
| DoD アクティビティの説明と結果 | Microsoft ガイダンスと推奨事項 |
|---|---|
Target
3.4.1 リソース承認 パート 1DoD エンタープライズは、組織でのリソース承認アプローチ (ソフトウェア定義境界など) を標準化します。 最低でも、リソース承認ゲートウェイが ID およびデバイスと統合されます。 組織は、承認されたリソース承認ゲートウェイをデプロイし、外部と接続するアプリケーション/サービスを有効にします。 移行するその他のアプリケーションと移行できないアプリケーションは、除外または使用停止対象であると識別されます。 結果: - 外部と接続するアプリケーションに対して、リソース承認ゲートウェイが設置されます - リソース承認ポリシーが ID およびデバイスと統合されます - 変換標準に関するエンタープライズ全体のガイダンスが関係者に伝達されます |
Microsoft Entra ID Microsoft Entra は、アプリケーション リソースの承認ゲートウェイです。 最新およびレガシー アプリケーションを Microsoft Entra と統合して SSO を実現します。Microsoft のガイダンス 1.2.4 を にてご覧ください。Microsoft Entra ID Governance アプリロールを使用してアプリケーションへのアクセスを管理します。 ユーザーをアプリの役割に割り当てるために、静的メンバーシップ、動的Microsoft Entraセキュリティ グループ、またはエンタイトルメント管理アクセス パッケージを使用します。 - アプリロールをアプリに追加し、トークンで受け取る - ロールベースのアクセス制御 条件付きアクセス 条件付きアクセスポリシーを活用して、アプリケーション アクセスを動的に承認、制御、またはブロックできます。 Microsoft ガイダンス 1.8.3 の User および 2.1.4 の Device を参照してください。 Azure Application Gateway Application Gateway と Web Application Firewall を使用して、パブリックにアクセス可能な Web アプリケーションと API を有効にします。 Microsoft ガイダンス 3.2.3 を参照してください。 |
Target
3.4.2 リソース承認 パート 2リソース承認ゲートウェイは、使用可能なすべてのアプリケーション/サービスに使用されます。 ゲートウェイを利用できないアプリケーションは、使用停止になるか、リスク ベースの系統的アプローチを使用して除外されます。 自動化された意思決定のために、承認が CI/CD パイプラインとさらに統合されます。 結果: - リソース承認ゲートウェイが、すべてのアプリケーションで使用されます - 自動化機能のために、リソース承認が DevSecOps および CI/CD と統合されます |
Microsoft Entra Workload ID ワークロード ID フェデレーションを使用して、外部 ID プロバイダー (IdP) からのトークンを信頼するようにユーザー割り当てマネージド ID またはアプリ登録を構成します。 GitHub Actions ワークフローのフェデレーテッド ワークロード アイデンティティを使用します。 - Workload アイデンティティ フェデレーション Azure API Management Azure API Managementを使用して、Azure内外でホストされているサービスをAPIとして管理、承認、公開します。 - Azure API Management |
Target
3.4.3.SDC リソース承認 パート 1DoD エンタープライズが、業界のベスト プラクティスに従う、コード ベースのコンピューティング管理 (つまり、ソフトウェア定義コンピューティング) に対して標準化されたアプローチを提供します。 承認されたコード ライブラリとパッケージのセットを使用して、リスクベースのアプローチを使用するベースラインが作成されます。 DoD 組織が、承認されたコード/バイナリ アクティビティと連携して、このアプローチをサポートできるアプリケーションとサポートできないアプリケーションを確実に識別します。 最新のソフトウェア ベースの構成と管理のアプローチをサポートできるアプリケーションが識別され、移行が開始されます。 ソフトウェア ベースの構成と管理のアプローチに従うことができないアプリケーションが識別されて、系統的アプローチを使用して除外が許可されます。 結果: - 承認されたバイナリ/コードを使用するように更新できないアプリケーションには廃止のマークが付けられ、移行計画が作成されます - 承認されたバイナリとコードがないと識別されたアプリケーションが、承認されたバイナリ/コードを使用するように更新されます - 変換標準に関するエンタープライズ全体のガイダンスが関係者に伝達されます |
安全な開発 セキュリティ開発ライフサイクルと公開されたベストプラクティスに従って、Azureアプリケーションを設計、開発、およびデプロイします。 - 安全な開発 - コードとしてのインフラストラクチャ - Azure Policyとしてのワークフロー Microsoft Entra ID アプリケーション認証と承認にMicrosoft Entra IDプラットフォームを使用します。 - アプリと認証の移行 Azure Migrate Azure Kubernetes Service (AKS) および App Service コンテナーのような最新のアプリ プラットフォームに移行します。 - 最新のアプリ プラットフォームにワークロードを移行する - AKS へ移行するための ASP.NET アプリを評価します。 - Azure App Service へ移行するための ASP.NET アプリを評価します。 |
Target
3.4.4 SDC リソース承認 パート 2ソフトウェアベースの構成と管理をサポートするアプリケーションが、運用環境/ライブ環境に移行され、通常運用されます。 可能な場合、ソフトウェア ベースの構成と管理をサポートできないアプリケーションが使用停止になります。 結果: - 更新されたアプリケーションが、ライブ環境または運用環境、あるいはその両方にデプロイされます - 廃止と移行のマークが付けられたアプリケーションが使用停止になります |
Azure Migrate Azure Migrate: App Containerization ツールを使用して、ASP.NET アプリとJava Web アプリを管理および移行します。 最新化できないアプリケーションの使用を停止します。 - ASP.NET アプリのコンテナー化およびAKSへの移行 - ASP.NET アプリのコンテナー化およびAzure App Serviceへの移行 - Java Web アプリのコンテナー化およびAKSへの移行 - Java Web アプリのコンテナー化およびAzure App Serviceへの移行 |
Advanced
3.4.5 リソース承認の属性のエンリッチ パート 1ユーザーとエンティティ アクティビティのモニター、マイクロセグメント化サービス、DLP、データ権利管理 (DRM) などの、ソースの初期属性が、リソース承認テクノロジ スタックとポリシーに統合されます。 後で統合するその他の属性が識別され、計画されます。 承認の決定を許可するユーザー、非個人エンティティ (NPE)、およびデバイスの基本的なリスク態勢を作成するために、属性が使用されます。 結果: - ほとんどの API 呼び出しがセキュリティで保護された API ゲートウェイを通過します - リソース承認が分析エンジンからデータを受け取ります - 承認の決定を行うために識別された属性が承認ポリシーに組み込まれます - 最初のエンリッチメントに使用される属性が識別されます |
Microsoft Entra アプリケーション 最新のアプリケーションと API を承認するには、Microsoft Entra IDを使用します。 アプリケーション プロキシとAzure Arc対応サーバー Microsoft Entra展開して、レガシ認証プロトコルにMicrosoft Entra IDを拡張します。 3.1.1 および 3.2.3 の Microsoft ガイダンスを参照してください . Conditional Access Microsoft Entra は、リソース承認用のセキュリティで保護されたゲートウェイです。 条件付きアクセスは承認エンジンです。 ユーザー、アプリケーション、ユーザー、環境条件 (デバイスのコンプライアンス状態を含む) を使用して、詳細な承認のポリシーを構成します。 - 条件付きアクセス - 条件付きアクセスの設計 - 準拠デバイスを必須にする 動的なセキュリティ グループ ユーザー属性に基づいて動的なセキュリティ グループを作成します。 動的グループを使用して、ユーザー属性に基づいた静的属性承認の条件付きアクセス ポリシーのスコープを設定します。 - グループの動的メンバーシップ - ユーザー、グループ、ワークロード ID Microsoft Purview 機密情報の種類 完全一致データ (EDM) を使用して機密情報の種類を定義します。 Microsoft Purview Information Protection および Purview データ損失防止 (DLP) ポリシーで機密情報の種類を使用します。 - 機密情報の種類に基づくデータ照合 - 機密情報の検出と保護 Microsoft Entra ID Governance アプリ ロールを持つアプリケーションへのアクセスに Microsoft Entra ID Governance を使用します。 静的メンバーシップ、動的セキュリティ グループ、またはエンタイトルメント管理アクセス パッケージを使って、アプリ ロールにユーザーを割り当てます。 - アプリ ロールを追加してトークンで受け取る - ロールベースのアクセス制御 |
Advanced
3.4.6.リソース承認の属性のエンリッチ パート 2拡張識別属性が、リソース承認のテクノロジおよびポリシーと統合されます。 信頼度スコアリングが属性全体に導入されて、承認についてより高度な意思決定方法を自動的に作成します。 結果: - 承認ポリシーが、承認の意思決定に信頼レベルを組み込みます - 属性の信頼レベルが定義されます |
Microsoft Entra ID Protection 条件付きアクセス ポリシー セット内のMicrosoft Entra ID Protectionからのサインイン リスクとユーザーシグナルを使用します。 環境の詳細とリスク レベルに基づいて、信頼レベルを確立するためにリスクを含む認証コンテキストを構成します。 - Microsoft Entra ID リスク - ポリシー テンプレート: サインイン リスク MFA - 認証コンテキストの例 Microsoft ガイダンス 1.3.3 でUserを参照してください。 カスタム セキュリティ属性 カスタム セキュリティ属性を管理し、Microsoft Entra ID ユーザーに割り当てます。 動的な属性ベースのアクセス制御 (ABAC) にロールの割り当て条件を使います。 - カスタム セキュリティ属性 |
Advanced
3.4.7.REST API マイクロセグメントDoD エンタープライズで承認された API ゲートウェイを使うと、アプリケーション呼び出しがマイクロセグメント化され、特定の宛先 (マイクロサービスなど) に対して認証され、承認されたアクセスのみが許可されるようになります。 可能なときは、API マイクロセグメント化コンソールが統合されて、ソフトウェア定義境界コントローラーまたはソフトウェア定義ネットワーク コンソール、あるいはその両方などの他のマイクロセグメント化コンソールを認識するようになります。 結果: - 承認されたエンタープライズ API が適切にマイクロセグメント化されます |
Azureネットワークと接続 受信フローと出力フロー全体のネットワークトラフィックを分離、フィルター処理し、制御します。 使用可能なネットワーク境界でローカライズされたネットワーク制御を使って、多層防御の原則を適用します。 Azure Well-Architected Framework に従う - ネットワーキングと接続性に関する推奨事項 - セグメント化戦略の推奨事項 API 設計 推奨されるプラクティスに従って、マイクロサービス用の API を設計します。 APIを保護し、Microsoft Entra IDで認証します。 - マイクロサービスAPI - APIを保護する |
3.5 継続的な監視と継続的な承認
Microsoft Defender for Cloudセキュリティ標準では、規制基準に準拠するために Defender for Cloud が有効になっているスコープ内Azureサブスクリプション、アマゾン ウェブ サービス (AWS) アカウント、Google Cloud Platform (GCP) プロジェクトを継続的に評価します。
| DoD アクティビティの説明と結果 | Microsoft ガイダンスと推奨事項 |
|---|---|
Advanced
3.5.1 継続的運用承認 (cATO) パート 1DoD 組織は、環境内の自動化ソリューションを利用して、統制のモニターを標準化し、逸脱を識別する機能を提供します。 適切な場合は、モニターとテストが DevSecOps プロセスに統合されます。 結果: - 統制の派生が標準化され、自動化の準備が整います - 統制の検査が DevSecOps のプロセスおよびテクノロジと統合されます |
DoD 最高情報責任者 (CIO) ライブラリ モニターと検査を DevSecOps プロセスに統合します。 DoD Enterprise DevSecOps リファレンス デザインを参照してください - DoD CIO ライブラリ Microsoft Defender for Cloud Defender for Cloud を使って Azure および非 Azure のワークロードを保護してください。 規制コンプライアンスとAzure Policyイニシアチブを使用して、構成標準を使用してインフラストラクチャを継続的に評価します。 構成のドリフトを防止する。 - セキュリティ基準を割り当てる - マルチクラウド環境 Microsoft Sentinel GitHub および Azure DevOpsと共に Sentinel の統合とデプロイ操作を自動化する。 - Sentinel および Azure DevOps の統合 - リポジトリからカスタムコンテンツをデプロイする |
Advanced
3.5.2 継続的運用承認 (cATO) パート 2DoD 組織が、派生の管理、検査、モニターの各プロセスを完全に自動化します。 逸脱は、柱にまたがる既存の自動化インフラストラクチャを使って自動的に検査され、解決されます。 承認の状態をモニターするためにダッシュボードが使われ、分析が承認担当者と統合されます。</br> 結果: - 統制の検査が完全に自動化されます - 標準的な IR と SOC 操作との統合が自動化されます |
Microsoft Defender脅威と脆弱性の管理 脆弱性管理プログラムに脅威と脆弱性の管理 (TVM) を追加します。 <c0 /><c1 /><c2>3.3.2</c2> に記載されている Microsoft のガイダンスを参照してください。<c3 /><c4 /><c5>Azure DevOps と Microsoft Sentinel</c5><c6 />Azure DevOps を使用して Sentinel の統合およびデプロイの自動化を行います。<c7 /><c8 /><c9>Azure DevOps との Sentinel の統合</c9><c10 /><c11 /><c12>Microsoft Defender XDR および Sentinel</c12><c13 />Microsoft Defender XDR および Defender for Cloud を Sentinel と統合します。<c14 /><c15 /><c16>ゼロトラストのための Sentinel と Defender XDR</c16><c17 /><c18 /> |
次のステップ
DoD Zero Trust戦略用に Microsoft クラウド サービスを構成します。
- Introduction
- User
- デバイス
- アプリケーションとワークロード
- データ
- Network
- 自動化とオーケストレーション
- 可視性と分析