Logic Apps 用の Azure セキュリティ ベースライン

このセキュリティ ベースラインにより、Azure セキュリティ ベンチマーク バージョン 1.0 のガイダンスが Azure Logic Apps に適用されます。 Azure セキュリティ ベンチマークには、Azure 上のクラウド ソリューションをセキュリティで保護する方法に関する推奨事項がまとめてあります。 内容は、Azure Logic Apps に適用される Azure セキュリティ ベンチマークと関連ガイダンスで定義されているセキュリティ コントロールによってグループ化されています。

このセキュリティ ベースラインとその推奨事項は、Microsoft Defender for Cloud を使用して監視できます。 Azure Policy定義は、Microsoft Defender for Cloud ダッシュボードの [規制コンプライアンス] セクションに一覧表示されます。

セクションに関連するAzure Policy定義がある場合は、Azure セキュリティ ベンチマークのコントロールと推奨事項への準拠を測定するために、このベースラインに一覧表示されます。 一部の推奨事項では、特定のセキュリティ シナリオを有効にするために有料の Microsoft Defender プランが必要になる場合があります。

Note

Azure Logic Apps に適用されないコントロール、または Microsoft が責任を持つものは、除外されています。 Azure Logic Apps を完全に Azure セキュリティ ベンチマークにマップする方法については、完全な Azure Logic Apps セキュリティ ベースライン マッピング ファイルを参照してください。

ネットワークのセキュリティ

詳細については、Azure セキュリティ ベンチマークの「ネットワークのセキュリティ」を参照してください。

1.1:仮想ネットワーク内の Azure リソースを保護する

ガイダンス:"グローバルな" マルチテナント Logic Apps サービスで実行されるコネクタは、Microsoft によってデプロイおよび管理されます。 これらのコネクタでは、Office 365、Azure Blob Storage、SQL Server、Dynamics、Salesforce、SharePoint など、クラウド サービスとオンプレミス システムの一方または両方にアクセスするためのトリガーとアクションが提供されます。 ネットワーク セキュリティ グループまたは Azure Firewall で関連リソースへのアクセスを許可する規則を指定するときに、AzureConnectors サービス タグを使用できます。

Azure 仮想ネットワーク内のリソースに直接アクセスする必要があるロジック アプリの場合は、専用のリソースでロジック アプリをビルド、デプロイ、実行できる統合サービス環境 (ISE) を作成できます。 一部の Azure 仮想ネットワークでは、プライベート エンドポイント (Azure Private Link) を使用して、Azure でホストされている Azure Storage、Azure Cosmos DB、Azure SQL Database、パートナー サービス、カスタマー サービスなどの Azure PaaS サービスへのアクセスが提供されます。 ロジック アプリでプライベート エンドポイントを使用する仮想ネットワークにアクセスする必要がある場合は、ISE の内部でそれらのロジック アプリを作成、デプロイ、実行する必要があります。

ISE を作成するときに、内部アクセス エンドポイントと外部アクセス エンドポイントのどちらを使用するかを選択できます。 この選択により、ISE 内のロジック アプリ上で要求または Webhook トリガーが仮想ネットワークの外からの呼び出しを受信できるかどうかが決まります。 内部および外部アクセス エンドポイントは、実行の入力と出力を含むロジック アプリの実行履歴を仮想ネットワークの内部または外部から表示できるかどうかにも影響します。

お使いの ISE に関連するすべての Virtual Network サブネット デプロイに、アプリケーションの信頼されたポートとソースに固有のネットワーク アクセス制御が適用されたネットワーク セキュリティ グループがあることを確認してください。 ISE でロジック アプリをデプロイする場合は、Private Link を使用します。 Azure Private Link を使用すると、お使いの仮想ネットワーク内のプライベート エンドポイント経由で、Azure PaaS サービスと Azure でホストされている顧客所有のサービスまたはパートナー サービスにアクセスできます。 または、特定のユース ケースがある場合は、Azure Firewall を実装することでこの要件を満たすことができます。 セキュリティ規則を設定する際の複雑さを軽減するには、特定の Azure サービスの IP アドレス プレフィックスのグループを表すサービス タグを使用します。

責任: 共有

1.2:仮想ネットワーク、サブネット、ネットワーク インターフェイスの構成とトラフィックを監視してログに記録する

ガイダンス:外部アクセス ポイントを使用する統合サービス環境 (ISE) でロジック アプリを実行する場合は、ネットワーク セキュリティ グループ (NSG) を使用して、データ流出のリスクを軽減することができます。 NSG フロー ログを有効にし、トラフィック監査のためにログを Azure Storage アカウントに送信します。 また、NSG フロー ログを Log Analytics ワークスペースに送信し、Traffic Analytics を使用して Azure クラウド内のトラフィック フローに関する分析情報を提供することもできます。 Traffic Analytics のいくつかの利点として、ネットワーク アクティビティを視覚化してホット スポットを特定したり、セキュリティの脅威を識別したり、トラフィック フロー パターンを把握したり、ネットワークの誤った構成の正確な場所を特定したりする機能が挙げられます。

責任: Customer

1.4:既知の悪意のある IP アドレスとの通信を拒否する

ガイダンス: 着信した呼び出しや要求を受け取る要求ベースのトリガー (Request トリガーや Webhook トリガーなど) がロジック アプリで使用されている場合、承認されたクライアントだけがそのロジック アプリを呼び出すことができるように、アクセスを制限できます。

統合サービス環境 (ISE) でロジック アプリを実行している場合は、自分の ISE に関連付けられている仮想ネットワークで DDoS Protection 標準を有効にして、DDoS 攻撃から保護してください。 Microsoft Defender for Cloud の統合された脅威インテリジェンスを使用して、既知の悪意のある、または未使用のインターネット IP アドレスとの通信を拒否します。

有効化され、悪意のあるネットワーク トラフィックに対して "アラートおよび拒否" するように構成された脅威インテリジェンスとともに、組織の各ネットワーク境界に Azure Firewall をデプロイします。

Microsoft Defender for Cloud のジャスト インタイム ネットワーク アクセスを使用して、NSG を構成し、限られた期間、承認された IP アドレスへのエンドポイントの公開を制限します。

Microsoft Defender for Cloud のアダプティブ ネットワーク強化を使用して、実際のトラフィックと脅威インテリジェンスに基づいてポートとソース IP を制限する NSG 構成を推奨します。

責任: Customer

1.5:ネットワーク パケットを記録する

ガイダンス:外部アクセス ポイントを使用する統合サービス環境 (ISE) でロジック アプリを実行する場合は、ネットワーク セキュリティ グループ (NSG) を使用して、データ流出のリスクを軽減することができます。 NSG フロー ログを有効にし、トラフィック監査のためにログを Azure Storage アカウントに送信します。 また、NSG フロー ログを Log Analytics ワークスペースに送信し、Traffic Analytics を使用して Azure クラウド内のトラフィック フローに関する分析情報を提供することもできます。 Traffic Analytics のいくつかの利点として、ネットワーク アクティビティを視覚化してホット スポットを特定したり、セキュリティの脅威を識別したり、トラフィック フロー パターンを把握したり、ネットワークの誤った構成の正確な場所を特定したりする機能が挙げられます。

追加の保護を施し、ネットワーク トラフィックに関する情報を提供するには、アクセス ログを参照してください。アクセス ログは、各 Application Gateway インスタンスでこれを有効にした場合にのみ生成されます。 このログを使用して Application Gateway のアクセス パターンを表示し、重要な情報を分析できます。 これには、呼び出し元の IP、要求された URL、応答の待機時間、リターン コード、入出力バイトが含まれます。

それ以外の場合は、マーケットプレースのサードパーティ製ソリューションを利用して、この要件を満たすことができます。

責任: Customer

1.6:ネットワーク ベースの侵入検出または侵入防止システム (IDS または IPS) をデプロイする

ガイダンス: ペイロード検査能力を備えた IDS または IPS 機能をサポートする Azure Marketplace からのプランを選択します。 ペイロード検査に基づく侵入検出または侵入防止が要件でない場合は、脅威インテリジェンスを備えた Azure Firewall を使用できます。 Azure Firewall の脅威インテリジェンス ベースのフィルター処理では、既知の悪意のある IP アドレスおよびドメインとの間のトラフィックを警告処理して拒否できます。 この IP アドレスとドメインのソースは、Microsoft の脅威インテリジェンス フィードです。

悪意のあるトラフィックを検出および拒否できるように、組織の各ネットワーク境界に任意のファイアウォール ソリューションをデプロイします。

責任: Customer

1.7:Web アプリケーションへのトラフィックを管理する

ガイダンス: 統合サービス環境 (ISE) でロジック アプリを実行している場合は、Azure Application Gateway をデプロイします。

責任: Customer

1.8:ネットワーク セキュリティ規則の複雑さと管理オーバーヘッドを最小限に抑える

ガイダンス: Azure Logic Apps インスタンスへのアクセスが必要なリソースについては、仮想ネットワーク サービス タグを使用して、ネットワーク セキュリティ グループまたは Azure Firewall に対するネットワーク アクセス制御を定義します。 セキュリティ規則を作成するときは、特定の IP アドレスの代わりにサービス タグを使うことができます。 規則の適切なソースまたは宛先フィールドにサービス タグ名 (LogicApps、LogicAppsManagement など) を指定することにより、対応するサービスのトラフィックを許可または拒否できます。 サービス タグに含まれるアドレス プレフィックスの管理は Microsoft が行い、アドレスが変化するとサービス タグは自動的に更新されます。

責任: Customer

1.9:ネットワーク デバイスの標準的なセキュリティ構成を維持する

ガイダンス: Azure Policy を使用して、対象の Azure Logic Apps インスタンスに関連するネットワーク リソースの標準的なセキュリティ構成を定義して実装します。 Azure Logic Apps インスタンスのネットワーク構成を監査または適用するためのカスタム ポリシーを作成するには、"Microsoft.Logic" と "Microsoft.Network" の名前空間で Azure Policy エイリアスを使用します。 次のように、組み込みのポリシー定義を使用することもできます。

  • Logic Apps で診断ログを有効にする必要がある

  • DDoS Protection Standard を有効にする必要がある

また、Azure Blueprints を使用して、Azure Resource Manager テンプレート、Azure ロールベースのアクセス制御 (Azure RBAC)、ポリシーなどの主要な環境成果物を単一のブループリント定義にパッケージ化することによって大規模な Azure デプロイを簡略化することもできます。 ブループリントを新しいサブスクリプションと環境に簡単に適用し、バージョン管理によって制御と管理を微調整します。

責任: Customer

1.10:トラフィック構成規則を文書化する

ガイダンス: 個々の NSG 規則については、[説明] フィールドを使用して、ネットワークとの間のトラフィックを許可する規則のビジネス ニーズや期間 (など) を指定します。

すべてのリソースが確実にタグ付きで作成され、既存のタグ付けされていないリソースがユーザーに通知されるようにするには、タグ付けに関連したいずれかの組み込みの Azure Policy 定義 ("タグとその値が必要" など) を使用します。

Azure PowerShell または Azure CLI を使用して、タグに基づいてリソースを検索したり、リソースに対するアクションを実行したりすることもできます。

責任: Customer

1.11:自動化ツールを使用してネットワーク リソース構成を監視し、変更を検出する

ガイダンス:Azure アクティビティ ログを使用して、ネットワーク リソース構成を監視し、対象の Azure Logic Apps インスタンスに関連するネットワーク リソースの変更を検出します。 重要なネットワーク リソースへの変更が発生するとトリガーされる Azure Monitor 内のアラートを作成します。

責任: Customer

ログ記録と監視

詳細については、Azure セキュリティ ベンチマークの「ログ記録と監視」を参照してください。

2.2:セキュリティ ログの一元管理を構成する

ガイダンス: 実行時にロジック アプリに関するより豊富なデバッグ情報を取得するには、Azure Monitor ログを設定して使用し、トリガー イベント、実行イベント、アクション イベントなどのランタイム データやイベントに関する情報を Log Analytics ワークスペースに記録して格納します。 Azure Monitor を使用すると、クラウド環境とオンプレミス環境を監視して、可用性とパフォーマンスをより簡単に維持することができます。 Azure Monitor ログを使用することで、この情報を収集して確認するのに役立つログ クエリを作成できます。 さらに、Azure Storage や Azure Event Hubs などの他の Azure サービスでこの診断データを使用することもできます。

または、Microsoft Sentinel またはサード パーティの SIEM に対してデータを有効にしてオンボードすることもできます。

責任: Customer

2.3:Azure リソースの監査ログ記録を有効にする

ガイダンス: 実行時にロジック アプリに関するより豊富なデバッグ情報を取得するには、Azure Monitor ログを設定して使用し、トリガー イベント、実行イベント、アクション イベントなどのランタイム データやイベントに関する情報を Log Analytics ワークスペースに記録して格納します。 Azure Monitor を使用すると、クラウド環境とオンプレミス環境を監視して、可用性とパフォーマンスをより簡単に維持することができます。 Azure Monitor ログを使用することで、この情報を収集して確認するのに役立つログ クエリを作成できます。 さらに、Azure Storage や Azure Event Hubs などの他の Azure サービスでこの診断データを使用することもできます。

または、Microsoft Sentinel またはサード パーティの SIEM に対してデータを有効にしてオンボードすることもできます。

責任: Customer

Microsoft Defender for Cloud による監視: Azure セキュリティ ベンチマークは Microsoft Defender for Cloud の既定のポリシー イニシアチブであり、Microsoft Defender for Cloud の推奨事項の基礎となります。 このコントロールに関連する Azure Policy 定義は、Microsoft Defender for Cloud によって自動的に有効になります。 このコントロールに関連するアラートでは、関連するサービスのために Microsoft Defender プランが必要になる場合があります。

Azure Policy 組み込み定義 - Microsoft.Logic:

名前
(Azure portal)
説明 効果 Version
(GitHub)
Logic Apps のリソース ログを有効にする必要がある リソース ログが有効になっていることを監査します。 これにより、セキュリティ インシデントが発生した場合やお使いのネットワークが侵害された場合に、調査目的で使用するアクティビティ証跡を再作成できます AuditIfNotExists、Disabled 5.0.0

2.5:セキュリティ ログのストレージ保持を構成する

ガイダンス:ロジック アプリを作成して実行すると、ロジック アプリの実行状態、実行の履歴、トリガー履歴、およびパフォーマンスを確認できます。 リアルタイムでのイベントの監視と高度なデバッグを行うには、Azure Monitor ログを使用してロジック アプリの診断ログを設定します。 この Azure サービスを使用すると、クラウド環境とオンプレミス環境を監視して、可用性とパフォーマンスをより簡単に維持することができます。 これにより、トリガー イベント、実行イベント、アクション イベントなどのイベントを検索して表示できます。 この情報を Azure Monitor ログに格納することで、この情報の検索と分析に役立つログ クエリを作成できます。 この診断データは、Azure Storage や Azure Event Hubs などの他の Azure サービスで使用することもできます。

Azure Monitor で、組織のコンプライアンス規則に従って、Azure Logic Apps インスタンスに関連付けられているログの保持期間を設定します。

責任: Customer

2.6:ログを監視して確認する

ガイダンス: ロジック アプリのログを設定するには、ロジック アプリを作成するときに Log Analytics を有効にするか、既存のロジック アプリの Log Analytics ワークスペースに Logic Apps 管理ソリューションをインストールします。 このソリューションでは、ロジック アプリの実行に関する集約情報が提供され、状態、実行時間、再送信の状態、関連付け ID などの特定の詳細情報が含まれています。 次に、この情報に対してログの記録とクエリの作成を有効にするために、Azure Monitor ログを設定します。

また、Azure アクティビティ ログの診断設定を有効にし、Log Analytics ワークスペースにログを送信することもできます。 Log Analytics でクエリを実行して、用語の検索、傾向の特定、パターンの分析を行い、Azure Logic Apps 用に収集された可能性があるアクティビティ ログ データに基づいて、多くの他の分析情報を提供します。

または、Microsoft Sentinel またはサード パーティの SIEM に対してデータを有効にしてオンボードすることもできます。

責任: Customer

2.7:異常なアクティビティについてのアラートを有効にする

ガイダンス: Log Analytics と共に Microsoft Defender for Cloud を使用し、セキュリティ ログやイベントで検出される異常なアクティビティに対する監視と警告を行います。

または、Microsoft Sentinel に対してデータを有効にしてオンボードすることもできます。

責任: Customer

ID およびアクセス制御

詳細については、Azure セキュリティ ベンチマークの「ID およびアクセス制御」を参照してください。

3.1: 管理アカウントのインベントリを維持する

ガイダンス: Azure Active Directory (Azure AD) には、明示的に割り当てる必要があるためにクエリ可能である組み込みロールがあります。 Azure AD PowerShell モジュールを使用してアドホック クエリを実行し、管理グループのメンバーであるアカウントを検出します。

サインインすることなく他の Azure AD によって保護される他のリソースに容易にアクセスして ID の認証を行うため、ロジック アプリは、資格情報やシークレットではなくマネージド ID (以前はマネージド サービス ID (MSI) と呼ばれていました) を使用できます。 この ID は、ユーザーの代わりに Azure で管理されます。ユーザーがシークレットを提供したりローテーションしたりする必要がないため、資格情報の保護に役立ちます。

ロジック アプリのすべての要求エンドポイントは、エンドポイントの URL に Shared Access Signature (SAS) を含みます。 要求ベースのトリガーのエンドポイント URL を他のパーティと共有する場合は、特定のキーを使用する有効期限付きのコールバック URL を生成できます。 そうすることで、キーをシームレスに交換したり、ロジック アプリのトリガーに対するアクセスを特定の期間に基づいて制限したりできます。

責任: Customer

3.2: 既定のパスワードを変更する (該当する場合)

ガイダンス: Azure Active Directory (Azure AD) および Azure Logic Apps には、既定のパスワードという概念はありません。

基本認証を使用している場合は、ユーザー名とパスワードを指定する必要があります。 これらの資格情報を作成するときは、認証用に強力なパスワードを構成してください。

コードとしてのインフラストラクチャを使用している場合は、パスワードをコードに格納せずに、Azure Key Vault を使用して資格情報の格納と取得を行います。

責任: Customer

3.3: 専用管理者アカウントを使用する

ガイダンス: 専用管理者アカウントの使用に関する標準的な操作手順を作成します。 Microsoft Defender for Cloud の ID およびアクセス管理を使用して、管理アカウントの数を監視します。

さらに、専用管理者アカウントを追跡できるように、Microsoft Defender for Cloud または組み込みの Azure ポリシーの次のような推奨事項を使用することもできます。

  • 複数の所有者がサブスクリプションに割り当てられている必要がある
  • 所有者としてのアクセス許可を持つ非推奨のアカウントをサブスクリプションから削除する必要がある
  • 所有者アクセス許可を持つ外部アカウントをサブスクリプションから削除する必要がある

詳細については、次のリファレンスを参照してください。

責任: Customer

3.4: Azure Active Directory シングル サインオン (SSO) を使用する

ガイダンス: Azure アプリの登録 (サービス プリンシパル) を使用して、API 呼び出しを介して Recovery Services コンテナーと対話するために使用できるトークンを取得します。

多くのコネクタでは、対象のロジック アプリでトリガーやアクションを使用する前に、最初に対象のサービスまたはシステムへの接続を作成し、認証資格情報またはその他の構成の詳細を指定する必要があります。 たとえば、ユーザーに代わってデータにアクセスしたり、投稿したりするために Twitter アカウントへの接続を承認する必要があります。

Azure Active Directory (Azure AD) OAuth を使用するコネクタの場合、接続の作成は、Office 365、Salesforce、GitHub などのサービスへのサインインを意味し、そこでアクセス トークンが暗号化され、Azure シークレット ストアに安全に保存されます。 FTP や SQL などのその他のコネクタでは、サーバーのアドレス、ユーザー名、およびパスワードなどの構成の詳細を含む接続が必要です。 これらの接続構成の詳細も暗号化され、安全に保存されます。

責任: Customer

3.5: すべての Azure Active Directory ベースのアクセスに多要素認証を使用する

ガイダンス: Azure Active Directory (Azure AD) 多要素認証を有効にし、Microsoft Defender for Cloud の ID およびアクセス管理の推奨事項に従います。

責任: Customer

3.6: セキュリティで保護された Azure マネージド ワークステーションを管理タスクに使用する

ガイダンス:多要素認証が構成された特権アクセス ワークステーション (PAW) を使用して Azure リソースにログインし、そのリソースを構成します。

責任: Customer

3.7: 管理者アカウントからの疑わしいアクティビティに関するログとアラート

ガイダンス: Azure Active Directory (Azure AD) Privileged Identity Management (PIM) を使用して、環境内で疑わしいアクティビティまたは安全ではないアクティビティが発生したときにログとアラートを生成します。

また、Azure AD のリスク検出を使用して、危険なユーザーの行動に関するアラートとレポートを表示します。

責任: Customer

3.8:承認された場所からのみ Azure リソースを管理する

ガイダンス: 条件付きアクセスのネームド ロケーションを使用して、IP アドレスの範囲、国、またはリージョンの特定の論理グループからのみ Azure portal へのアクセスを許可します。

さらに、ロジック アプリのすべての要求エンドポイントは、エンドポイントの URL に Shared Access Signature (SAS) を含みます。 特定の IP アドレスからの要求のみを受け入れるようにロジック アプリを制限できます。

責任: Customer

3.9: Azure Active Directory を使用する

ガイダンス: Azure Logic Apps インスタンスの主要な認証および認可システムとして Azure Active Directory (Azure AD) を使用します。 Azure AD でデータを保護するには、保存データと転送中のデータに強力な暗号化を使用します。 また、Azure AD では、ユーザーの資格情報がソルト化およびハッシュされ、安全に格納されます。

Logic Apps でサポートされている場合は、資格情報やシークレットではなくマネージド ID を使用して、Azure AD によって保護されている他のリソースに簡単にアクセスし、サインインすることなく ID の認証を行います。 この ID は、ユーザーの代わりに Azure で管理されます。ユーザーがシークレットを提供したりローテーションしたりする必要がないため、資格情報の保護に役立ちます。

Azure Logic Apps では、システム割り当てとユーザー割り当ての両方のマネージド ID がサポートされます。 ロジック アプリでは、システムによって割り当てられた ID または単一のユーザー割り当て ID のいずれかを使用できます。これは、ロジック アプリのグループ全体で共有できますが、両方を共有することはできません。 現在、特定の組み込みトリガーおよびアクションでのみマネージド ID がサポートされ、以下のようなマネージド コネクタや接続はサポートされません。

  • HTTP
  • Azure Functions
  • Azure API Management
  • Azure App Service

詳細については、次のリファレンスを参照してください。

責任: Customer

3.10: ユーザー アクセスを定期的に確認して調整する

ガイダンス: Azure Active Directory (Azure AD) では、古いアカウントの検出に役立つログが提供されます。 また、Azure ID アクセス レビューを使用して、グループ メンバーシップ、エンタープライズ アプリケーションへのアクセス、およびロールの割り当てを効率的に管理します。 ユーザー アクセスを定期的にレビューし、適切なユーザーのみが継続的なアクセス権を持っていることを確認できます。

責任: Customer

3.11: 非アクティブ化された資格情報へのアクセスの試行を監視する

ガイダンス: Azure Logic Apps インスタンスの主要な認証および認可システムとして Azure Active Directory (Azure AD) を使用します。 Azure AD でデータを保護するには、保存データと転送中のデータに強力な暗号化を使用します。 また、Azure AD では、ユーザーの資格情報がソルト化およびハッシュされ、安全に格納されます。

Azure AD サインイン アクティビティ、監査、リスク イベント ログのソースにアクセスできるため、Microsoft Sentinel またはサードパーティの SIEM と統合することができます。

このプロセスを効率化するには、Azure AD ユーザー アカウントの診断設定を作成し、監査ログとサインイン ログを Log Analytics ワークスペースに送信します。 Log Analytics 内で必要なログ アラートを構成できます。

責任: Customer

3.12: アカウント サインイン動作の偏差に関するアラートを生成する

ガイダンス: Azure Active Directory (Azure AD) のリスクおよび ID Protectoin 機能を使用して、ユーザー ID に関連して検出された疑わしいアクションに対する自動応答を構成します。 Microsoft Sentinel にデータを取り込んで、さらに詳しく調査することもできます。

責任: Customer

データ保護

詳細については、Azure セキュリティ ベンチマークの「データ保護」を参照してください。

4.1: 機密情報のインベントリを維持する

ガイダンス: 機密情報を格納または処理する Azure リソースを追跡しやすくするには、タグを使用します。

責任: Customer

4.2:機密情報を格納または処理するシステムを分離する

ガイダンス: "グローバルな" マルチテナント Logic Apps サービスで実行されるコネクタは、Microsoft によってデプロイおよび管理されます。 これらのコネクタでは、Office 365、Azure Blob Storage、SQL Server、Dynamics、Salesforce、SharePoint など、クラウド サービスとオンプレミス システムの一方または両方にアクセスするためのトリガーとアクションが提供されます。

Azure 仮想ネットワーク内のリソースに直接アクセスする必要があるロジック アプリの場合は、専用のリソースでロジック アプリをビルド、デプロイ、実行できる統合サービス環境 (ISE) を作成できます。 一部の Azure 仮想ネットワークでは、プライベート エンドポイント (Azure Private Link) を使用して、Azure でホストされている Azure Storage、Azure Cosmos DB、Azure SQL Database、パートナー サービス、カスタマー サービスなどの Azure PaaS サービスへのアクセスが提供されます。 ロジック アプリでプライベート エンドポイントを使用する仮想ネットワークにアクセスする必要がある場合は、ISE の内部でそれらのロジック アプリを作成、デプロイ、実行する必要があります。

ISE を作成するときに、内部アクセス エンドポイントと外部アクセス エンドポイントのどちらを使用するかを選択できます。 この選択により、ISE 内のロジック アプリ上で要求または Webhook トリガーが仮想ネットワークの外からの呼び出しを受信できるかどうかが決まります。

さらに、環境の種類やデータの機密度レベルなど、個々のセキュリティ ドメイン用の個別のサブスクリプションと管理グループを使用して分離を実装します。 アプリケーションやエンタープライズ環境で必要とされる Azure リソースへのアクセス レベルを制限できます。 Azure のロールベースのアクセス制御 (Azure RBAC) を使用して、Azure リソースへのアクセスを制御できます。

責任: Customer

4.3:機密情報の承認されていない転送を監視してブロックする

ガイダンス:現時点では使用できません。Azure Logic Apps では、データの識別、分類、損失防止機能はまだ使用できません。

機密情報の承認されていない転送を監視して、情報セキュリティ担当者にアラートを送信すると同時に、そのような転送をブロックする、Azure Marketplace からのサードパーティ ソリューションをネットワーク境界で利用します。

Microsoft では、Azure Logic Apps 用の基になるインフラストラクチャを管理し、顧客データの損失や漏洩を防ぐための厳格な管理を実施してきました。

責任: 共有

4.4:転送中のすべての機密情報を暗号化する

ガイダンス:転送中のすべての機密情報を暗号化します。 Azure Logic Apps では、ロジック アプリが実行されている間、すべてのデータが転送中 (トランスポート層セキュリティ (TLS) を使用) と保存時に暗号化されます。 ロジック アプリの実行履歴を表示するときは、Logic Apps によってアクセスの認証が行われた後、各実行の要求と応答に対する入力および出力へのリンクが提供されます。 ただし、パスワード、シークレット、キーなどの秘匿性の高い情報を処理するアクションについては、他のユーザーがそのデータを表示したり利用したりできないようにします。 たとえば、ロジック アプリが HTTP アクションの認証時に使用するシークレットを Azure Key Vault から取得する場合、そのシークレットが見えないようにする必要があります。

Request トリガーでは、受信要求に対してトランスポート層セキュリティ (TLS) 1.2 のみがサポートされます。 対象の Azure リソースに接続しているすべてのクライアントが TLS 1.2 以上をネゴシエートできることを確認します。 HTTP コネクタを使用する送信呼び出しでは、トランスポート層セキュリティ (TLS) 1.0、1.1、および 1.2 がサポートされます。

該当する場合、保存時と転送時の暗号化に関する Microsoft Defender for Cloud の推奨事項に従います。

責任: 共有

4.5:アクティブ検出ツールを使用して機密データを特定する

ガイダンス: Azure Logic Apps では、多くのトリガーとアクションに、ロジック アプリの実行履歴からデータを隠すことで入力と出力のどちらかまたは両方をセキュリティで保護するために有効にできる設定があります。

Microsoft では、Azure Logic Apps 用の基になるインフラストラクチャを管理し、顧客データの損失や漏洩を防ぐための厳格な管理を実施してきました。

責任: 共有

4.6:Azure RBAC を使用してリソースへのアクセスを制御する

ガイダンス: ロジック アプリの管理、編集、表示など、特定のタスクの実行を特定のユーザーまたはグループのみに許可することができます。 それらのアクセス許可を制御するには、カスタマイズされたロールまたは組み込みロールを Azure サブスクリプションのメンバーに割り当てることができるように、Azure のロールベースのアクセス制御 (Azure RBAC) を使用します。

  • ロジック アプリの共同作成者: ロジック アプリを管理できますが、アクセス権を変更することはできません。
  • ロジック アプリのオペレーター: ロジック アプリの読み取り、有効化、無効化ができますが、編集または更新はできません。

他のユーザーがお客様のロジック アプリを変更したり削除したりしないようにするには、Azure のリソース ロックを使用できます。 この機能を使用すると、他のユーザーは運用リソースを変更または削除できなくなります。

責任: Customer

4.8:機密情報を保存時に暗号化する

ガイダンス: Azure Logic Apps は Azure Storage を利用して、データを格納し、自動的に保存データを暗号化します。 この暗号化によってデータが保護され、組織のセキュリティとコンプライアンスの要件を満たすことができます。 既定では、Azure Storage は Microsoft マネージド キーを使用してデータを暗号化します。

対象のロジック アプリをホストするための統合サービス環境 (ISE) を作成し、Azure Storage で使用される暗号化キーをより詳細に制御したい場合は、Azure Key Vault を使用して、独自のキーを設定、使用、管理することができます。 この機能は "Bring Your Own Key" (BYOK) とも呼ばれ、キーは "カスタマー マネージド キー" と呼ばれます。

責任: Customer

4.9:重要な Azure リソースへの変更に関するログとアラート

ガイダンス: Azure Logic Apps およびその他の重要なリソースまたは関連リソースへの変更がいつ発生したかに関するアラートを作成するには、Azure Monitor と Azure アクティビティ ログを使用します。

責任: Customer

インベントリと資産の管理

詳細については、Azure セキュリティ ベンチマークの「インベントリと資産の管理」を参照してください。

6.1:自動化された資産検出ソリューションを使用する

ガイダンス:Azure Resource Graph を使用して、サブスクリプション内のすべてのリソース (コンピューティング、ストレージ、ネットワーク、ポート、プロトコルなど) のクエリまたは検出を行います。 テナントで適切な (読み取り) アクセス許可を確認し、サブスクリプション内のリソースだけでなく、すべての Azure サブスクリプションを列挙します。

従来の Azure リソースは Resource Graph で検出できますが、今後は Azure Resource Manager リソースを作成して使用することを強くお勧めします。

責任: Customer

6.2:資産メタデータを保持する

ガイダンス:メタデータを提供する Azure リソースにタグを適用すると、それらのリソースが各分類に論理的に整理されます。

責任: Customer

6.3:承認されていない Azure リソースを削除する

ガイダンス: Azure リソースを整理および追跡するには、必要に応じて、タグ付け、管理グループ、個別のサブスクリプションを使用します。 定期的にインベントリを調整し、承認されていないリソースがサブスクリプションから適切なタイミングで削除されるようにします。

さらに、Azure Policy を使用し、次の組み込みのポリシー定義を使用して、顧客のサブスクリプション内に作成できるリソースの種類を制限します。

  • 許可されないリソースの種類
  • 許可されるリソースの種類

詳細については、次のリファレンスを参照してください。

責任: Customer

6.4:承認された Azure リソースのインベントリを定義および管理する

ガイダンス:組織のニーズに応じて、承認された Azure リソース (コネクタなど) とコンピューティング リソース用に承認されたソフトウェアのインベントリを作成します。

注:Google のデータおよびプライバシー ポリシーにより、Gmail コネクタは Google によって承認されたサービスでのみ使用できます。 この状況は進展しており、将来的に他の Google コネクタに影響を与える可能性があります。

責任: Customer

6.5:承認されていない Azure リソースを監視する

ガイダンス: Azure Policy を使用して、サブスクリプションで作成できるリソースの種類に制限を設けます。

Azure Resource Graph を使用して、サブスクリプション内のリソースのクエリまたは検出を行います。 環境に存在するすべての Azure リソースが承認されていることを確認します。

責任: Customer

6.9:承認された Azure サービスのみを使用する

ガイダンス: 次の組み込みのポリシー定義を使用して、顧客のサブスクリプション内に作成できるリソースの種類に制限を適用するには、Azure Policy を使用します。

  • 許可されないリソースの種類
  • 許可されるリソースの種類

詳細については、次のリファレンスを参照してください。

責任: Customer

6.10:承認されたソフトウェア タイトルのインベントリを管理する

ガイダンス: 適用できません。この推奨事項は、コンピューティング リソースを対象にしています。

責任: Customer

6.11:Azure Resource Manager を操作するユーザーの機能を制限する

ガイダンス: Azure 条件付きアクセスを使用して Azure Resource Manager とやりとりするユーザーの機能を制限するには、"Microsoft Azure 管理" アプリに対して [アクセスのブロック] を構成します。

責任: Customer

6.12:コンピューティング リソース内でスクリプトを実行するユーザーの機能を制限する

ガイダンス: 適用できません。この推奨事項は、コンピューティング リソースを対象にしています。

責任: Customer

6.13:リスクの高いアプリケーションを物理的または論理的に分離する

ガイダンス: 業務に必要であっても、組織のリスクが高くなる可能性がある対象のロジック アプリに関連するリソースは、独自の仮想マシンや仮想ネットワーク内に隔離し、Azure Firewall またはネットワーク セキュリティ グループで十分に保護する必要があります。

業務に必要であっても、組織のリスクが高くなる可能性があるロジック アプリは、特定のアクセス許可と Azure RBAC 境界を持つ個別のリソース グループを使用して、可能な限り分離する必要があります。

責任: Customer

セキュリティで保護された構成

詳細については、Azure セキュリティ ベンチマークの「セキュリティで保護された構成」を参照してください。

7.1:すべての Azure リソースに対してセキュリティで保護された構成を確立する

ガイダンス: Azure Policy を使用して、Azure Logic Apps インスタンスの標準のセキュリティ構成を定義および実装します。 対象の Logic Apps インスタンスの構成を監査または適用するためのカスタム ポリシーを作成するには、"Microsoft.Logic" 名前空間で Azure Policy エイリアスを使用します。 たとえば、アクセスを制限するリソースへの接続を他のユーザーが作成または使用できないようにすることができます。

さらに、Azure Resource Manager には、テンプレートを JavaScript Object Notation (JSON) でエクスポートする機能があります。構成が組織のセキュリティ要件を満たしているか超えていることを確認するためにはこれを確認する必要があります。

また、セキュリティで保護されたパラメーターを使用して、機密データやシークレットを保護します。

責任: Customer

7.2:セキュリティで保護されたオペレーティング システムの構成を確立する

ガイダンス: 適用できません。このガイドラインは、コンピューティング リソースを対象にしています。

責任: Customer

7.3:セキュリティで保護された Azure リソースの構成を維持する

ガイダンス:Azure リソース全体にセキュリティで保護された設定を適用するには、Azure Policy の [deny] と [deploy if not exist] を使用します。

Azure Policy を使用して、Azure Logic Apps インスタンスの標準のセキュリティ構成を定義および実装します。 対象の Logic Apps インスタンスの構成を監査または適用するためのカスタム ポリシーを作成するには、"Microsoft.Logic" 名前空間で Azure Policy エイリアスを使用します。 たとえば、アクセスを制限するリソースへの接続を他のユーザーが作成または使用できないようにすることができます。

さらに、Azure Resource Manager には、テンプレートを JavaScript Object Notation (JSON) でエクスポートする機能があります。構成が組織のセキュリティ要件を満たしているか超えていることを確認するためにはこれを確認する必要があります。

また、難読化を使用して実行履歴のデータをセキュリティで保護していることを確認します。

責任: Customer

7.4:セキュリティで保護されたオペレーティング システムの構成を維持する

ガイダンス: 適用できません。このガイドラインは、コンピューティング リソースを対象にしています。

責任: 共有

7.5:Azure リソースの構成を安全に格納する

ガイダンス: カスタムの Azure Policy 定義を使用する場合は、Azure DevOps または Azure Repos を使用して、コードを安全に格納して管理します。

さらに、Azure Resource Manager には、テンプレートを JavaScript Object Notation (JSON) でエクスポートする機能があります。構成が組織のセキュリティ要件を満たしているか超えていることを確認するためにはこれを確認する必要があります。

責任: Customer

7.6:カスタム オペレーティング システム イメージを安全に格納する

ガイダンス: 適用できません。このガイドラインは、コンピューティング リソースを対象にしています。

責任: Customer

7.7:Azure リソース用の構成管理ツールをデプロイする

ガイダンス: 組み込みの Azure Policy 定義と "Microsoft.Logic" 名前空間の Azure Policy エイリアスを使用して、システム構成のアラート、監査、適用を行うカスタム ポリシーを作成します。 ご利用の Azure リソースのネットワーク構成を監査または適用するには、Azure Policy エイリアスを使用してカスタム ポリシーを作成します。 さらに、ポリシー例外を管理するためのプロセスとパイプラインを作成します。

責任: Customer

7.8:オペレーティング システム用の構成管理ツールをデプロイする

ガイダンス: 適用できません。このガイドラインは、コンピューティング リソースを対象にしています。

責任: Customer

7.9:Azure リソースの自動構成監視を実装する

ガイダンス: 組み込みの Azure Policy 定義と "Microsoft.Logic" 名前空間の Azure Policy エイリアスを使用して、システム構成のアラート、監査、適用を行うカスタム ポリシーを作成します。 Azure リソースの構成を自動的に適用するには、Azure Policy の [audit]、[deny]、[deploy if not exist] を使用します。

責任: Customer

7.10:オペレーティング システムの自動構成監視を実装する

ガイダンス: 適用できません。このガイドラインは、コンピューティング リソースを対象にしています。

責任: Customer

7.11:Azure シークレットを安全に管理する

ガイダンス: 難読化を使用して、ロジック アプリの実行履歴の入力と出力をセキュリティで保護します。 デプロイ先が複数の異なる環境にまたがる場合、環境に応じて変わる値は、ロジック アプリのワークフロー定義内でパラメーター化することを検討してください。 そのようにすると、Azure Resource Manager テンプレートを使用してロジック アプリをデプロイすることでデータのハードコーディングを避け、セキュリティで保護されたパラメーターを定義することで機密データを保護し、パラメーター ファイルを使用することでテンプレートのパラメーターで個別の入力としてそのデータを渡すことができます。 Key Vault を使用して機密データを格納し、デプロイ時に Key Vault からそれらの値を取得する、セキュリティで保護されたテンプレート パラメーターを使用できます。 その後、パラメーター ファイルの中で、キー コンテナーとシークレットを参照することができます。

対象のロジック アプリをホストするための統合サービス環境 (ISE) を作成し、Azure Storage で使用される暗号化キーをより詳細に制御したい場合は、Azure Key Vault を使用して、独自のキーを設定、使用、管理することができます。 この機能は "Bring Your Own Key" (BYOK) とも呼ばれ、キーは "カスタマー マネージド キー" と呼ばれます。

責任: Customer

7.12:ID を安全かつ自動的に管理する

ガイダンス: サインインすることなく他の Azure Active Directory (Azure AD) によって保護される他のリソースに容易にアクセスして ID の認証を行うため、ロジック アプリは、資格情報やシークレットではなくマネージド ID (以前はマネージド サービス ID (MSI) と呼ばれていました) を使用できます。 この ID は、ユーザーの代わりに Azure で管理されます。ユーザーがシークレットを提供したりローテーションしたりする必要がないため、資格情報の保護に役立ちます。

現在、特定の組み込みトリガーおよびアクションでのみマネージド ID がサポートされ、以下のようなマネージド コネクタや接続はサポートされません。

  • HTTP
  • Azure Functions
  • Azure API Management
  • Azure App Service

詳細については、次のリファレンスを参照してください。

責任: Customer

7.13:意図しない資格情報の公開を排除する

ガイダンス: 難読化を使用して、ロジック アプリの実行履歴の入力と出力をセキュリティで保護します。 デプロイ先が複数の異なる環境にまたがる場合、環境に応じて変わる値は、ロジック アプリのワークフロー定義内でパラメーター化することを検討してください。 そのようにすると、Azure Resource Manager テンプレートを使用してロジック アプリをデプロイすることでデータのハードコーディングを避け、セキュリティで保護されたパラメーターを定義することで機密データを保護し、パラメーター ファイルを使用することでテンプレートのパラメーターで個別の入力としてそのデータを渡すことができます。 Key Vault を使用して機密データを格納し、デプロイ時に Key Vault からそれらの値を取得する、セキュリティで保護されたテンプレート パラメーターを使用できます。 その後、パラメーター ファイルの中で、キー コンテナーとシークレットを参照することができます。

また、コード内で資格情報を特定する資格情報スキャナーを実装することもできます。 また、資格情報スキャナーを使うと、検出された資格情報を、Azure Key Vault などのより安全な場所に移動しやすくなります。

責任: Customer

マルウェアからの防御

詳細については、Azure セキュリティ ベンチマークの「マルウェアからの防御」を参照してください。

8.1:一元管理されたマルウェア対策ソフトウェアを使用する

ガイダンス: 適用できません。この推奨事項は、コンピューティング リソースを対象にしています。 Microsoft のマルウェア対策は、Azure サービス (Azure Logic Apps など) をサポートしている基になるホストで有効になっていますが、顧客のコンテンツに対しては実行されません。

責任: Customer

8.2:非コンピューティング Azure リソースにアップロードするファイルを事前にスキャンする

ガイダンス: Microsoft Anti-malware は、Azure サービス (Azure Backup など) をサポートしている基になるホストで有効になっていますが、ユーザーのコンテンツに対しては実行されません。

App Service、Data Lake Storage、Blob Storage などの非コンピューティング Azure リソースにアップロードされようとしているファイルはすべて、事前にスキャンしてください。

Microsoft Defender for Cloud のデータ サービス向け脅威検出を使用して、ストレージ アカウントにアップロードされたマルウェアを検出します。

責任: Customer

手順 8.3:マルウェア対策ソフトウェアと署名が確実に更新されるようにする

ガイダンス: 適用できません。このガイドラインは、コンピューティング リソースを対象にしています。

責任: Customer

データの復旧

詳細については、Azure セキュリティ ベンチマークの「データの復旧」を参照してください。

9.1:定期的な自動バックアップを保証する

ガイダンス: ディザスター リカバリー (DR) ソリューションを適切に実装して、データを保護し、重要なビジネス機能をサポートするリソースをすばやく復元し、業務を継続して事業継続性 (BC) を保つことができるようにします。

このディザスター リカバリー戦略では、Azure Logic Apps も利用可能な別の場所にあるスタンバイまたはバックアップ ロジック アプリにフェールオーバーするようにプライマリ ロジック アプリを設定することに重点を置いています。 こうすることで、プライマリに損失、中断、または障害が発生した場合、セカンダリは作業を引き継ぐことができます。 この戦略では、セカンダリ ロジック アプリと依存リソースがすでに別の場所に展開され、準備ができている必要があります。

さらに、ロジック アプリの基になるワークフロー定義を Azure Resource Manager テンプレートに拡張する必要があります。 このテンプレートでは、ロジック アプリをプロビジョニングおよびデプロイするためのインフラストラクチャ、リソース、パラメーター、およびその他の情報を定義します。

責任: Customer

9.2: システムの完全バックアップを実行し、すべてのカスタマー マネージド キーをバックアップする

ガイダンス: ディザスター リカバリー (DR) ソリューションを適切に実装して、データを保護し、重要なビジネス機能をサポートするリソースをすばやく復元し、業務を継続して事業継続性 (BC) を保つことができるようにします。

このディザスター リカバリー戦略では、Azure Logic Apps も利用可能な別の場所にあるスタンバイまたはバックアップ ロジック アプリにフェールオーバーするようにプライマリ ロジック アプリを設定することに重点を置いています。 こうすることで、プライマリに損失、中断、または障害が発生した場合、セカンダリは作業を引き継ぐことができます。 この戦略では、セカンダリ ロジック アプリと依存リソースがすでに別の場所に展開され、準備ができている必要があります。

さらに、ロジック アプリの基になるワークフロー定義を Azure Resource Manager テンプレートに拡張する必要があります。 このテンプレートでは、ロジック アプリをプロビジョニングおよびデプロイするためのインフラストラクチャ、リソース、パラメーター、およびその他の情報を定義します。

ロジック アプリのすべての要求エンドポイントは、エンドポイントの URL に Shared Access Signature (SAS) を含みます。 シークレットを格納するために Azure Key Vault を使用している場合は、必ずキーと URL の定期的な自動バックアップを実行してください。

責任: Customer

9.3:カスタマー マネージド キーを含むすべてのバックアップを検証する

ガイダンス: 対象のディザスター リカバリー戦略では、Azure Logic Apps も利用可能な別の場所にあるスタンバイまたはバックアップ ロジック アプリにフェールオーバーするようにプライマリ ロジック アプリを設定することに重点を置く必要があります。 こうすることで、プライマリに損失、中断、または障害が発生した場合、セカンダリは作業を引き継ぐことができます。 この戦略では、セカンダリ ロジック アプリと依存リソースがすでに別の場所に展開され、準備ができている必要があります。

バックアップされたカスタマー マネージド キーの復元をテストします。 これは、統合サービス環境 (ISE) で実行されている Logic Apps にのみ適用されることに注意してください。

責任: Customer

9.4: バックアップとカスタマー マネージド キーの保護を保証する

ガイダンス: 対象のディザスター リカバリー戦略では、Azure Logic Apps も利用可能な別の場所にあるスタンバイまたはバックアップ ロジック アプリにフェールオーバーするようにプライマリ ロジック アプリを設定することに重点を置く必要があります。 こうすることで、プライマリに損失、中断、または障害が発生した場合、セカンダリは作業を引き継ぐことができます。 この戦略では、セカンダリ ロジック アプリと依存リソースがすでに別の場所に展開され、準備ができている必要があります。

バックアップされたカスタマー マネージド キーを保護します。 これは、統合サービス環境 (ISE) で実行されている Logic Apps にのみ適用されることに注意してください。

Key Vault で論理的な削除と消去保護を有効にして、偶発的または悪意のある削除からキーを保護します。

責任: Customer

インシデント対応

詳細については、Azure セキュリティ ベンチマークの「インシデント対応」を参照してください。

10.1:インシデント対応ガイドを作成する

ガイダンス: 組織のインシデント対応ガイドを作成します。 要員のすべてのロールを定義するインシデント対応計画が記述されていることと、検出からインシデント後のレビューまでのインシデント対応/管理のフェーズがあることを確認します。

責任: Customer

10.2:インシデントのスコアリングと優先順位付けの手順を作成する

ガイダンス: Microsoft Defender for Cloud によって各アラートに重大度が割り当てられるため、最初に調査する必要があるアラートの優先順位付けに役立ちます。 重要度は、アラートの発行に使用された検出内容またはメトリックに対する Microsoft Defender for Cloud の信頼度と、アラートの原因となったアクティビティの背後に悪意のある意図があったかどうかの信頼度レベルに基づいて決まります。

さらに、タグを使用してサブスクリプションを明確にマークし (運用、非運用など)、Azure リソース (特に、機密データを処理するもの) を明確に識別して分類するための命名システムを作成します。 インシデントが発生した Azure リソースと環境の重要度に基づいて、アラートの修復に優先順位を付けることは、お客様の責任です。

責任: Customer

10.3:セキュリティ対応手順のテスト

ガイダンス:ご利用のシステムのインシデント対応機能を定期的にテストする演習を実施することで、ご利用の Azure リソースの保護を支援できます。 弱点やギャップを特定し、必要に応じて計画を見直します。

責任: Customer

10.4:セキュリティ インシデントの連絡先の詳細を指定し、セキュリティ インシデントのアラート通知を構成します

ガイダンス:セキュリティ インシデントの連絡先情報は、Microsoft Security Response Center (MSRC) でユーザーのデータが違法または権限のないユーザーによってアクセスされたことが検出された場合に、Microsoft からの連絡先として使用されます。 事後にインシデントをレビューして、問題が解決されていることを確認します。

責任: Customer

10.5:インシデント対応システムにセキュリティ アラートを組み込む

ガイダンス: Microsoft Defender for Cloud のアラートと推奨事項を連続エクスポート機能を使用してエクスポートし、Azure リソースに対するリスクを特定できます。 連続エクスポートを使用すると、アラートと推奨事項を手動で、または継続した連続的な方法でエクスポートできます。 Microsoft Defender for Cloud データ コネクタを使用してアラートを Microsoft Sentinel にストリーミングできます。

責任: Customer

10.6:セキュリティ アラートへの対応を自動化する

ガイダンス: Azure リソースを保護するセキュリティ アラートやセキュリティに関する推奨事項に対して「Logic Apps」経由で応答を自動的にトリガーするには、Microsoft Defender for Cloud のワークフローの自動化機能を使用します。

責任: Customer

侵入テストとレッド チーム演習

詳細については、Azure セキュリティ ベンチマークの「侵入テストとレッド チーム演習」を参照してください。

11.1:Azure リソースの通常の侵入テストを実施し、セキュリティに関する重大な調査結果がすべて、確実に修復されるようにする

ガイダンス: お客様の侵入テストが Microsoft のポリシーに違反しないように、Microsoft の実施ルールに確実に従ってください。 Microsoft が管理しているクラウド インフラストラクチャ、サービス、アプリケーションに対する Red Teaming およびライブ サイト侵入テストに関する Microsoft の戦略と実施を活用してください。

責任: 共有

次のステップ