DoD ゼロ トラスト戦略とロードマップは、国防総省の各部署と国防産業基盤 (DIB) パートナーによる、ゼロ トラストの原則に基づく新しいサイバーセキュリティ フレームワークを導入するための大まかな道筋を示しています。 ゼロ トラストは、従来の境界や信頼の前提を排除し、セキュリティ、ユーザー エクスペリエンス、ミッション パフォーマンスを強化する、より効率的なアーキテクチャを実現します。
このガイドには、DoD ゼロ トラスト機能遂行ロードマップでの、152 種のゼロ トラスト アクティビティに関する推奨事項が記載されています。 各セクションは、DoD ゼロ トラスト モデルの 7 つの柱に対応します。
ガイドの各セクションに移動するには次のリンクを使用してください。
3 アプリケーションとワークロード
このセクションには、アプリケーションとワークロードの柱に含まれる DoD ゼロ トラスト アクティビティに関する Microsoft のガイダンスと推奨事項があります。 詳細については、「ゼロ トラストによるアプリケーションのセキュリティ保護」を参照してください。
Note
このセクションの推奨事項は、ドラフトの「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 フェデレーション サービス (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 に登録されたデバイスによって検出されます。 これは、テナントのソフトウェア インベントリです。 企業のデバイスでは、アプリまたは管理対象アプリはこのレポートに対して収集されません。 - 検出されたアプリ Azure DevOps 安全なパッケージ管理のために、このサービスを使用します。 開発者は、1 か所でコードを共有し、パッケージを管理します。 - Azure Artifacts - Azure GitHub リポジトリ |
3.2 セキュリティで保護されたソフトウェア開発と統合
GitHub Advanced Security (GHAS) や GitHub Actions などの GitHub 機能は、ゼロ トラスト ソフトウェアの開発とデプロイの実施方法を確立するのに役立ちます。 GitHub Enterprise Cloud は Microsoft Entra ID と統合され、Azure AD Identity Governance を使用してエンタイトルメントを管理し、条件付きアクセス ポリシーを使用してアクセスをセキュリティで保護します。
開発者は、Microsoft 認証ライブラリ (MSAL) を使用して、アプリケーションを Microsoft Entra ID と統合できます。 詳細については、「ゼロ トラスト用にユーザーを認証する」を参照してください。
| 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 と Azure DevOps に対して GitHub Advanced Security を使用して、コードと開発プロセスのセキュリティを強化します。 - Advanced Security - Advanced Security for Azure DevOps Microsoft Entra SSO とプロビジョニング Microsoft Entra ID を使用して Git ツールのシングル サインオン (SSO) を構成します。 - GitHub Enterprise Cloud - Organization との SSO 統合 - GitHub Enterprise Server との SSO 統合 - 組織を Microsoft Entra ID に接続する Azure およびその他のクラウド向けの DevSecOps の詳細については、DoD の最高情報責任者 (CIO) ライブラリを参照してください。 |
Target 3.2.2 DevSecOps ソフトウェア ファクトリの構築 パート 2DoD 組織は、承認された CI/CD パイプラインを使用して、ほとんどの新しいアプリケーションを開発します。 除外して従来の方法で開発できるようにするには、標準化された承認プロセスに従います。 DevSecOps プロセスは、すべての新しいアプリケーションの開発と、既存のアプリケーションの更新にも使用されます。 継続的な検証機能が CI/CD パイプラインと DevSecOps プロセスに統合され、既存のアプリケーションと統合されます。 結果: - アプリケーションの開発が CI/CD パイプラインに移行されます - 継続的な検証プロセス/テクノロジが実装され、使用されます - アプリケーションの開発が DevSecOps プロセスとテクノロジに移行されます |
GitHub Advanced Security GitHub Advanced Security を使用してコードの依存関係と脆弱性をスキャンします。 コードの品質を評価する定期的なビルドを構成します。 - Advanced Security - CodeQL コード スキャン - サプライ チェーンをセキュリティで保護する Azure 内の Bicep infrastructure-as-code (IaC) を Azure Resource Manager (ARM) テンプレートおよび Bicep テンプレートと組み合わせて使用して、クラウド インフラストラクチャをプロビジョニングします。 - Bicep Microsoft Defender for Cloud アプリケーション ワークロードがあるサブスクリプションの Defender for Cloud によるワークロード保護を有効にします。 - クラウド ワークロードを保護する Microsoft Defender for DevOps Defender for DevOps を使用して、Azure DevOps (ADO) と GitHub のパイプラインのセキュリティとアラートをモニターします。 - Defender for DevOps |
Target 3.2.3 アプリケーション セキュリティの自動化とコード修復 パート 1アプリケーション セキュリティに対する標準化されたアプローチ (コード修復を含む) が、DoD エンタープライズ全体にわたって実装されます。 このアクティビティのパート 1 には、API または同様の呼び出しを利用するアプリケーションとセキュリティで保護された API ゲートウェイの統合が含まれています。 コード レビューは系統的アプローチで実施され、コンテナーとそのインフラストラクチャに対する標準化された保護機能が設置されます。 さらに、サービスとしてのプラットフォームなどのインフラストラクチャをサードパーティが管理するサーバーレス機能が、適切なサーバーレス セキュリティ モニター機能と応答機能を利用します。 コード レビュー、コンテナー、サーバーレスのセキュリティ機能が、必要に応じて CI/CD または DevSecOps プロセスに統合されます。 結果: - セキュリティで保護された API ゲートウェイが運用可能になり、API 呼び出しの大半がゲートウェイを通過します - アプリケーション セキュリティ機能 (コード レビュー、コンテナー、サーバーレス セキュリティなど) が CI/CD と DevSecOps の一部として実装されます |
Azure Application Gateway Azure Application Gateway と Web アプリケーション ファイアウォールを使用して、パブリックにアクセスできる Web アプリケーションと API を配置します。 - Web アプリケーション ファイアウォール Microsoft Entra ID アプリケーション Microsoft Entra ID は、Web アプリケーションと API アクセスの承認ゲートウェイです。 Microsoft Entra を使用して登録されたアプリケーションに対して API を公開します。 Azure App Service および Azure Functions で、組み込みの認証と承認 (Easy Auth) を使用します。 Microsoft Entra ID を認識しない API については、Azure API Management の OAuth 承認を使用します。 - Web API を公開するためのアプリを構成する - Azure App Service と Azure Functions での認証と承認 - API に対する認証と承認 GitHub Advanced Security GitHub と Azure DevOps に対して GitHub Advanced Security を使用します。 3.2.1 の Microsoft ガイダンスを参照してください。 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 コードのスキャン - サプライ チェーンをセキュリティで保護する Windows Defender のアプリケーション制御 Windows Defender のアプリケーション制御を使用して、信頼されていないコードがマネージド エンドポイントで実行されないようにします。 - アプリケーション制御とアプリ ロッカー - プラットフォーム コードの整合性 |
Target 3.3.2 脆弱性の管理プログラム パート 1DoD エンタープライズは、組織と連携して脆弱性の管理プログラムを確立および管理します。 このプログラムには、すべての組織によって合意されたポリシーと標準が含まれます。 開発されたプログラムには、DoD アプリケーション/サービスに基づくパブリック脆弱性の追跡と管理が最低でも含まれています。 組織は主要な利害関係者とともに脆弱性の管理チームを設立し、そこでエンタープライズ ポリシーと標準に従って脆弱性が議論および管理されます。 結果: - 適切な利害関係者メンバーシップの脆弱性の管理チームが設置されます - 脆弱性の管理ポリシーとプロセスが設置され、利害関係者から合意されます - 脆弱性のパブリック ソースが追跡に利用されます |
脅威と脆弱性の管理 VM の機能により、資産の可視性とインテリジェントな評価が可能になります。 TVM には、エンドポイントとサーバー用の組み込みの修復ツールがあります。 脆弱性の管理プログラムで TVM を使用します。 - Microsoft Defender TVM Microsoft クラウド セキュリティ ベンチマーク Microsoft オンライン サービスによる脆弱性の管理の実施方法を確認します。 - TVM の概要 - 態勢と脆弱性の管理 |
Target 3.3.3 脆弱性の管理プログラム パート 2パブリックとプライベートの両方からアクセス可能な DoD で維持/運用されるサービスの脆弱性の漏えいを管理するために、DoD エンタープライズ レベルでプロセスが確立されます。 DoD 組織が脆弱性の管理プログラムを拡張して、DIB、CERT などの閉じた脆弱性リポジトリを追跡および管理します。 結果: - 制御された脆弱性のソース (DIB、CERT など) が追跡に利用されます - 脆弱性の管理プログラムに、マネージド サービスの外部/公的開示を受け入れるプロセスがあります |
脅威と脆弱性の管理 Microsoft Defender TVM の弱点ページを使用して、組織のデバイスとサーバーで検出された脆弱性を識別し、優先順位を付けます。 - 組織内の脆弱性 TVM の脆弱なデバイスのレポートを使用して修復アクティビティを追跡します。 - 脆弱なデバイスのレポート |
Target 3.3.4 継続的な検証DoD 組織は、アプリケーション開発に継続的な検証アプローチを実装します。このアプローチでは、並列デプロイが実施され、承認された環境レベル (ユーザー受け入れテスト、運用など) と統合されます。 CI/CD プロセスに継続的な検証を統合できないアプリケーションが識別され、必要に応じて系統的アプローチを使用した除外機能が提供されます。 結果: - 更新されたアプリケーションがライブ環境または運用環境、あるいはその両方にデプロイされます - 廃止と移行のマークが付けられたアプリケーションは使用が停止されます - 継続的な検証ツールが実装され、CI/CD パイプライン内のコードに適用されます - 継続的な検証を必要とするコードが識別され、検証基準が確立されます |
Azure Chaos Studio Azure Chaos Studio を使ってワークロードを検証します。 - 継続的な検証 GitHub Advanced Security DoD Enterprise DevSecOps リファレンス デザインの脆弱性の管理に GitHub の機能とアクションを使います。 3.2.1 の Microsoft ガイダンスを参照してください。 |
3.4 リソースの承認と統合
条件付きアクセスは、Microsoft Entra ID のゼロ トラスト ポリシー エンジンです。 Microsoft Entra ID を使用してアプリケーション ワークロードを接続します。 Azure AD Identity Governance を使用してエンタイトルメントを管理し、条件付きアクセス ポリシーを使用してサインインをセキュリティで保護します。 ポリシーは、デバイスの正常性、セッションの詳細、リスクなどのセキュリティ属性を使用して、アダプティブ アクセスの決定を行います。 Microsoft Entra ID、Azure Resource Manager、および CI/CD パイプラインは、Azure でのリソースのデプロイを承認します。
| DoD アクティビティの説明と結果 | Microsoft ガイダンスと推奨事項 |
|---|---|
Target 3.4.1 リソース承認 パート 1DoD エンタープライズは、組織でのリソース承認アプローチ (ソフトウェア定義境界など) を標準化します。 最低でも、リソース承認ゲートウェイが ID およびデバイスと統合されます。 組織は、承認されたリソース承認ゲートウェイをデプロイし、外部と接続するアプリケーション/サービスを有効にします。 移行するその他のアプリケーションと移行できないアプリケーションは、除外または使用停止対象であると識別されます。 結果: - 外部と接続するアプリケーションに対して、リソース承認ゲートウェイが設置されます - リソース承認ポリシーが ID およびデバイスと統合されます - 変換標準に関するエンタープライズ全体のガイダンスが関係者に伝達されます |
Microsoft Entra ID Microsoft Entra は、アプリケーション リソースの承認ゲートウェイです。 SSO 用の最新およびレガシのアプリケーションを Microsoft Entra と統合します。 ユーザーのページで、Microsoft ガイダンス 1.2.4 を参照してください。 Azure AD Identity Governance アプリケーションへのアクセスに Azure AD Identity Governance アプリ ロールを使用します。 静的メンバーシップ、動的 Microsoft Entra セキュリティ グループ、またはエンタイトルメント管理アクセス パッケージを使用して、ユーザーをアプリ ロールに割り当てます。 - アプリにアプリ ロールを追加し、トークンで受け取ります - ロールベースのアクセス制御 条件付きアクセス 条件付きアクセス ポリシーを使用して、アプリケーション アクセスを動的に承認、制御、またはブロックします。 ユーザーのページの Microsoft ガイダンス 1.8.3 と、デバイスのページの 2.1.4 を参照してください。 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 ワークロード ID ワークロード ID フェデレーションを使用して、ユーザー割り当てマネージド ID を構成するか、アプリ登録を使用して外部 ID プロバイダー (IdP) のトークンを信頼します。 GitHub Actions ワークフローのフェデレーション ワークロード ID を使用します。 - ワークロード ID フェデレーション Azure API Management Azure API Management を使用して、Azure 上と Azure 外でホストされているサービスを API として管理、承認、公開します。 - Azure API Management |
Target 3.4.3.SDC リソース承認 パート 1DoD エンタープライズが、業界のベスト プラクティスに従う、コード ベースのコンピューティング管理 (つまり、ソフトウェア定義コンピューティング) に対して標準化されたアプローチを提供します。 承認されたコード ライブラリとパッケージのセットを使用して、リスクベースのアプローチを使用するベースラインが作成されます。 DoD 組織が、承認されたコード/バイナリ アクティビティと連携して、このアプローチをサポートできるアプリケーションとサポートできないアプリケーションを確実に識別します。 最新のソフトウェア ベースの構成と管理のアプローチをサポートできるアプリケーションが識別され、移行が開始されます。 ソフトウェア ベースの構成と管理のアプローチに従うことができないアプリケーションが識別されて、系統的アプローチを使用して除外が許可されます。 結果: - 承認されたバイナリ/コードを使用するように更新できないアプリケーションには廃止のマークが付けられ、移行計画が作成されます - 承認されたバイナリとコードがないと識別されたアプリケーションが、承認されたバイナリ/コードを使用するように更新されます - 変換標準に関するエンタープライズ全体のガイダンスが関係者に伝達されます |
安全な開発 セキュリティ開発ライフサイクルと公開されたベスト プラクティスに従って、Azure アプリケーションを設計、開発、デプロイします。 - 安全な開発 - コードとしてのインフラストラクチャ - コードとしての Azure Policy ワークフロー Microsoft Entra ID アプリケーションの認証と承認に Microsoft 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 のアプリ コンテナ化ツールを使用して、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 アプリケーション Microsoft Entra ID を使用して最新のアプリケーションと API を承認します。 Microsoft Entra アプリケーション プロキシと Azure Arc 対応サーバーをデプロイして、Microsoft Entra ID をレガシ認証プロトコルに拡張します。 3.1.1 と 3.2.3 の Microsoft ガイダンスを参照してください。 条件付きアクセス Microsoft Entra は、リソース承認のためのセキュリティで保護されたゲートウェイです。 条件付きアクセスは承認エンジンです。 ユーザー、アプリケーション、ユーザー、環境条件 (デバイスのコンプライアンス状態を含む) を使用して、詳細な承認のポリシーを構成します。 - 条件付きアクセス - 条件付きアクセスの設計 - 準拠デバイスを必須にする 動的なセキュリティ グループ ユーザー属性に基づいて動的なセキュリティ グループを作成します。 動的グループを使用して、ユーザー属性に基づいて静的属性承認の条件付きアクセス ポリシーのスコープを設定します。 - グループの動的メンバーシップ - ユーザー、グループ、およびワークロード ID Microsoft Purview の機密情報の種類 完全データ一致 (EDM) を使用して機密情報の種類を定義します。 Microsoft Purview Information Protection および Purview データ損失防止 (DLP) ポリシーで機密情報の種類を使います。 - 機密情報の種類に基づくデータ一致 - 機密情報の検出と保護 Azure AD Identity Governance アプリ ロールを使ったアプリケーションへのアクセスに Azure AD Identity Governance を使います。 静的メンバーシップ、動的セキュリティ グループ、またはエンタイトルメント管理アクセス パッケージを使って、アプリ ロールにユーザーを割り当てます。 - アプリ ロールを追加してトークンで受け取る - ロールベースのアクセス制御 |
Advanced 3.4.6.リソース承認の属性のエンリッチ パート 2拡張識別属性が、リソース承認のテクノロジおよびポリシーと統合されます。 信頼度スコアリングが属性全体に導入されて、承認についてより高度な意思決定方法を自動的に作成します。 結果: - 承認ポリシーが、承認の意思決定に信頼レベルを組み込みます - 属性の信頼レベルが定義されます |
Microsoft Entra ID Protection 条件付きアクセス ポリシー セットで、サインイン リスクと Microsoft Entra ID Protection からのユーザー シグナルを使います。 リスクを含む認証コンテキストを構成して、環境の詳細とリスク レベルに基づいて信頼レベルを確立します。 - Microsoft Entra ID リスク - ポリシー テンプレート: サインイン リスク MFA - 認証コンテキストの例 ユーザーに関するページの Microsoft ガイダンス 1.3.3 を参照してください。 カスタム セキュリティ属性 Microsoft Entra ID ユーザーのカスタム セキュリティ属性を管理し、割り当てます。 動的な属性ベースのアクセス制御 (ABAC) にロールの割り当て条件を使います。 - カスタム セキュリティ属性 |
Advanced 3.4.7.REST API マイクロセグメントDoD エンタープライズで承認された API ゲートウェイを使うと、アプリケーション呼び出しがマイクロセグメント化され、特定の宛先 (マイクロサービスなど) に対して認証され、承認されたアクセスのみが許可されるようになります。 可能なときは、API マイクロセグメント化コンソールが統合されて、ソフトウェア定義境界コントローラーまたはソフトウェア定義ネットワーク コンソール、あるいはその両方などの他のマイクロセグメント化コンソールを認識するようになります。 結果: - 承認されたエンタープライズ API が適切にマイクロセグメント化されます |
Azure のネットワークと接続 イングレス フローとエグレス フローにまたがるネットワーク トラフィックを分離し、フィルターに掛け、制御します。 使用可能なネットワーク境界でローカライズされたネットワーク制御を使って、多層防御の原則を適用します。 Azure Well-Architected Framework に従います。 - ネットワークと接続に関する推奨事項 - セグメント化戦略の推奨事項 API の設計 マイクロサービスの API を設計するための推奨プラクティスに従います。 Microsoft Entra ID を使って API を保護および承認します。 - マイクロサービス 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 エンタープライズ 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) を組み込みます。 3.3.2 の Microsoft ガイダンスを参照してください。 Azure DevOps と Microsoft Sentinel Sentinel と Azure DevOps との統合とデプロイ操作を自動化します。 - Sentinel と Azure DevOps の統合 Microsoft Defender XDR と Sentinel Microsoft Defender XDR および Defender for Cloud を Sentinel と統合します。 - ゼロ トラストのための Sentinel と Defender XDR |
次のステップ
DoD ゼロ トラスト戦略用に Microsoft クラウド サービスを構成します。