Batch のセキュリティとコンプライアンスのベスト プラクティス
この記事では、Azure Batch を使用するときのセキュリティ強化に関するガイダンスとベスト プラクティスを提供します。
既定では、Azure Batch アカウントにはパブリック エンドポイントがあり、パブリックにアクセスできます。 Azure Batch プールが作成されると、Azure 仮想ネットワークの指定したサブネットにプールがプロビジョニングされます。 既定では、Batch プール内の仮想マシンには、Batch によって作成されるパブリック IP アドレスを使用してアクセスできます。 プール内の計算ノードは、複数インスタンスのタスクの実行などのために必要に応じて相互に通信できますが、プール内のノードがプール外の仮想マシンと通信することはできません。
より安全な Azure Batch デプロイの作成に役立つ多くの機能が用意されています。 ノードへのアクセスを制限し、インターネットからのノードの探索可能性を低く抑えるには、パブリック IP アドレスのないプールをプロビジョニングします。 計算ノードが他の仮想マシン、またはオンプレミス ネットワークと安全に通信できるようにするには、そのプールを Azure 仮想ネットワークのサブネット内にプロビジョニングします。 また、Azure Private Link を使用しているサービスで、仮想ネットワークからのプライベート アクセスを有効にすることができます。
一般的なセキュリティに関するベスト プラクティス
プールの構成
プールは、クラシックまたは簡略化の 2 つのノード通信モードのいずれかで構成することができます。 クラシックのノード通信モデルでは、Batch サービスによってコンピューティング ノードへの通信が開始され、コンピューティング ノードも Azure Storage との通信を必要とします。 簡略化されたノード通信モデルでは、コンピューティング ノードが Batch サービスとの通信を開始します。 必要な受信または送信接続のスコープが縮小され、ベースライン操作に Azure Storage の送信アクセスは必要ないため、簡略化されたノード通信モデルを使用することをお勧めします。 クラシック ノード通信モデルは、2026 年 3 月 31 日に廃止される予定です。
プールは、トラステッド起動 (Gen2 VM イメージおよび互換性のある VM サイズが必要) および、ホストでのセキュア ブート、vTPM、暗号化の有効化 (互換性のある VM サイズが必要) など、強化されたセキュリティ設定を使用して構成する必要もあります。
Batch アカウントの認証
Batch アカウント アクセスでは、共有キーと Microsoft Entra ID の 2 つの認証方法がサポートされています。
Batch アカウント認証には Microsoft Entra ID を使用することを強くお勧めします。 一部の Batch 機能では、この認証方法が必要になります。これには、ここで説明するセキュリティ関連の機能の多くが含まれます。 Batch アカウントのサービス API 認証メカニズムは、allowedAuthenticationModes プロパティを使用した Microsoft Entra ID のみに制限できます。 このプロパティが設定されている場合、共有キー認証を使用した API 呼び出しは拒否されます。
Batch アカウントのプール割り当てモード
Batch アカウントの作成時には、次の 2 つのプール割り当てモードを選択できます。
- Batch サービス: 既定のオプションでは、プール ノードの割り当てと管理に使用される、基になる Virtual Machine Scale Setのリソースが Batch 所有のサブスクリプションに作成され、Azure portal に直接表示されません。 表示されるのは、Batch のプールとノードだけです。
- ユーザー サブスクリプション: 基になる Virtual Machine Scale Set のリソースは、Batch アカウントと同じサブスクリプションに作成されます。 そのため、これらのリソースは、対応する Batch リソースに加えて、サブスクリプションに表示されます。
ユーザー サブスクリプション モードでは、プールの作成時に Batch VM などのリソースがサブスクリプションに直接作成されます。 Azure Reserved VM Instances を使用して Batch プールを作成する場合、Virtual Machine Scale Sets のリソースで Azure Policy を使用する場合、またはサブスクリプションのコア クォータを管理する場合は、ユーザー サブスクリプション モードが必要です (サブスクリプションのすべての Batch アカウントで共有されます)。 また、ユーザー サブスクリプション モードで Batch アカウントを作成するには、ご利用のサブスクリプションを Azure Batch に登録し、アカウントを Azure Key Vault に関連付ける必要があります。
ネットワーク エンドポイント アクセスを制限する
Batch ネットワーク エンドポイント
既定では、パブリック IP アドレスを持つエンドポイントが、Batch アカウント、Batch プール、プール ノードでの通信に使用されます。
Batch アカウントの API
Batch アカウントが作成されると、REST API を使用して、アカウントのほとんどの操作の呼び出しに使用されるパブリック エンドポイントが作成されます。 アカウント エンドポイントには、https://{account-name}.{region-id}.batch.azure.com の形式を使用するベース URL があります。 Batch アカウントへのアクセスは、HTTPS を使用して暗号化されているアカウント エンドポイントとの通信を使用してセキュリティで保護され、各要求は共有キーまたは Microsoft Entra 認証を使用して認証されます。
Azure Resource Manager
Batch アカウントに固有の操作に加えて、管理操作が 1 つの、および複数の Batch アカウントに適用されます。 これらの管理操作には Azure Resource Manager 経由でアクセスします。
Azure Resource Manager による Batch の管理操作は HTTPS を使用して暗号化され、各要求は Microsoft Entra 認証を使用して認証されます。
Batch プール計算ノード
Batch サービスは、プール内の各ノードで実行される Batch ノード エージェントと通信します。 たとえば、ノード エージェントに対するタスクの実行、タスクの停止、またはタスクのファイルの取得が、サービスによって指示されます。 ノード エージェントとの通信は、1 つまたは複数のロード バランサーによって有効にされます。その数は、プール内のノードの数によって異なります。 ロード バランサーから目的のノードに通信が転送されます。各ノードは一意のポート番号でアドレス指定されます。 既定では、ロード バランサーにはパブリック IP アドレスが関連付けられています。 RDP または SSH 経由でプール ノードにリモート アクセスすることもできます。詳細については、「Azure Batch プール内の計算ノードへのリモート アクセスを構成する」を参照してください。
Batch 計算ノード OS
Batch は、Linux オペレーティング システムと Windows オペレーティング システムの両方をサポートします。 Batch では、Linux OS ディストリビューションのサブセット用として配置されたノード エージェントを使用した Linux がサポートされます。 OS パブリッシャーによって提供される最新のパッチを使用してオペレーティング システムを最新の状態に保つことをお勧めします。
Batch プールの OS の自動アップグレードを有効にすることをお勧めします。これにより、基になる Azure インフラストラクチャでプール全体の更新を調整できます。 このオプションは、タスクの実行で中断を起こさずに構成できます。 OS の自動アップグレードでは、Batch でサポートされているすべてのオペレーティング システムがサポートされるわけではありません。 詳細については、「Virtual Machine Scale Sets の OS の自動アップグレードのサポート マトリックス」を参照してください。
Windows オペレーティング システムの場合は、Batch プールで OS の自動アップグレードを使用するときにプロパティ virtualMachineConfiguration.windowsConfiguration.enableAutomaticUpdates を有効にしていないことを確認してください。
イメージ エージェントとノード エージェントに対する Batch のサポートは通常、パブリッシャーのサポート タイムラインに合わせて段階的に廃止されます。 期限切れ (EOL) の日付が迫っている画像や、EOL の日付を過ぎた画像は使用しないようにすることをお勧めします。
プールに関連する EOL 日のビューを定期的に更新し、EOL 日になる前にワークロードを移行することは、お客様の責任となります。 指定されたノード エージェントでカスタム イメージを使用している場合は、カスタム イメージが派生されている、または連携しているイメージについて、Batch のサポート終了日を追跡できていることを確認してください。 batchSupportEndOfLife の日付が指定されていないイメージは、そのような日付がバッチ サービスによってまだ決定されていないことを示します。 日付がないことは、それぞれのイメージが無期限にサポートされることを示すわけではありません。 EOL の日付は、将来いつでも追加または更新される可能性があります。 EOL 日付は、ListSupportedImages API、PowerShell、または Azure CLI で確認することができます。
Windows OSトランスポート層セキュリティ (TLS)
Batch ノード エージェントは、SSL/TLS バージョンまたは暗号スイートの順序付けのオペレーティング システム レベルの既定値を変更しません。 Windows では、SSL/TLS のバージョンと暗号スイートの順序はオペレーティング システム レベルで制御されるため、Batch ノード エージェントは、各計算ノードで使用されるイメージによって設定された設定を採用します。 Batch ノード エージェントは、可能な限り最も安全な設定を利用しようとしますが、これはオペレーティング システム レベルの設定によって引き続き制限される可能性があります。 OS レベルの既定値を確認し、ワークフローと組織の要件に適した最もセキュアなモードに適切に設定することをお勧めします。 詳細については、暗号スイートの順序の適用に関しては「TLS の管理」、Schannel SSP の SSL/TLS バージョン管理に関しては「TLS レジストリ設定」を参照してください。 一部の設定の変更は、有効にするために再起動が必要があることに注意してください。 Batch 開始タスクを使用してこのような設定を適用する代わりに、最新のセキュリティの既定値を使用した新しいオペレーティング システムや、設定が変更されたカスタム イメージを使用することをお勧めします。
Batch エンドポイントへのアクセスの制限
特にソリューションによって仮想ネットワークが使用される場合に、さまざまな Batch エンドポイントへのアクセスを制限するために、いくつかの機能を使用できます。
プライベート エンドポイントを使用する
Azure Private Link を使用すると、お使いの仮想ネットワーク内のプライベート エンドポイント経由で、Azure PaaS サービスと Azure でホストされている顧客所有の、またはパートナーのサービスにアクセスできます。 Private Link を使用すると、仮想ネットワーク内から、またはピアリングされた任意の仮想ネットワークから、Batch アカウントへのアクセスを制限できます。 Private Link にマップされたリソースは、プライベート ピアリングを使用して、VPN または Azure ExpressRoute 経由でオンプレミスからアクセスすることもできます。
プライベート エンドポイントを使用するには、Batch アカウントを作成時に適切に構成する必要があります。パブリック ネットワーク アクセスの構成は無効にする必要があります。 作成されると、プライベート エンドポイントを作成し、Batch アカウントに関連付けることができます。 詳細については、「Azure Batch アカウントでプライベート エンドポイントを使用する」を参照してください。
仮想ネットワーク内にプールを作成する
Batch プール内の計算ノードは、複数インスタンスのタスクの実行などで、仮想ネットワーク (VNet) を必要とせずに相互に通信できます。 ただし、既定では、プール内のノードは、ライセンス サーバーやファイル サーバーのような、仮想ネットワーク上のプールの外部にあり、プライベート IP アドレスを持つ仮想マシンとは通信できません。
計算ノードが他の仮想マシンと、あるいはオンプレミス ネットワークと安全に通信できるようにするために、Azure VNet のサブネットにプールを構成できます。
プールにパブリック IP エンドポイントがある場合、サブネットでは、計算ノード上のタスクをスケジュールしたり、その他の操作を実行したりできるよう、Batch サービスからのインバウンド通信を許可する必要があります。また、ワークロードのニーズに応じて、Azure Storage などのリソースと通信するために、アウトバウンド通信を許可する必要があります。 仮想マシンの構成におけるプールの場合は、計算ノードにアタッチされたネットワーク インターフェイスのレベルで、Batch によりネットワーク セキュリティ グループ (NSG) が追加されます。 これらの NSG には、以下を有効にするための規則があります。
- Batch サービスの IP アドレスからの受信 TCP トラフィック
- リモート アクセス用の受信 TCP トラフィック
- 任意のポートでの仮想ネットワークに対する送信トラフィック (サブネット レベルの NSG 規則ごとに修正可能)
- 任意のポートでのインターネットに対する送信トラフィック (サブネット レベルの NSG 規則ごとに修正可能)
仮想ネットワークのサブネット レベルで NSG を指定する必要はありません。これは、Batch によってその独自の NSG が構成されるためです。 Batch の計算ノードがデプロイされているサブネットに関連付けられている NSG がある場合、またはカスタム NSG 規則を適用して既定の適用をオーバーライドする場合は、少なくとも受信および送信のセキュリティ規則を持つ NSG を構成して、プール ノードに対する Batch サービスの通信と、Azure Storage に対するプール ノードの通信を可能にする必要があります。
詳細については、「仮想ネットワーク内に Azure Batch プールを作成する」を参照してください。
静的パブリック IP アドレスを持つプールを作成する
既定では、プールに関連付けられているパブリック IP アドレスは動的です。これらはプールの作成時に作成され、プールのサイズを変更するときに IP アドレスを追加または削除することができます。 プール ノードで実行されているタスク アプリケーションが外部サービスにアクセスする必要がある場合は、それらのサービスへのアクセスを特定の IP に制限しなければならない場合があります。 この場合、動的 IP アドレスを管理することはできません。
プールを作成する前に、Batch アカウントと同じサブスクリプションで静的パブリック IP アドレスのリソースを作成できます。 これらのアドレスは、プールを作成するときに指定できます。
詳細については、「特定のパブリック IP アドレスの Azure Batch プールを作成する」を参照してください。
パブリック IP アドレスのないプールを作成する
既定では、Azure Batch 仮想マシン構成プール内のすべての計算ノードに、1 つまたは複数のパブリック IP アドレスが割り当てられます。 これらのエンドポイントは、タスクをスケジュールするため、および計算ノードとの通信 (インターネットへの送信アクセスなど) を行うために Batch サービスによって使用されます。
これらのノードへのアクセスを制限し、インターネットからのこれらのノードの探索可能性を低く抑えるには、パブリック IP アドレスのないプールをプロビジョニングできます。
詳細については、パブリック IP アドレスのないプールの作成に関する記事を参照してください。
プール ノードへのリモート アクセスを制限する
2024-07-01 より前の API バージョンで作成されたプールの場合、既定では、Batch により、ネットワーク接続を使用するノード ユーザーに対して、RDP または SSH を使用して Batch プール内の計算ノードに外部から接続することが許可されます。
リモート アクセスを制限するには、API バージョン 2024-07-01 以降を使用してプールを作成します。
2024-07-01 より前のバージョンの API によって作成されたプール内のノードに対するリモート アクセスを制限するには、次のいずれかの方法を使用します。
- アクセスを拒否するように PoolEndpointConfiguration を構成する。 適切なネットワーク セキュリティ グループ (NSG) がプールに関連付けられます。
- パブリック IP アドレスのないプールを作成する。 既定では、これらのプールに VNet の外部からアクセスすることはできません。
- NSG を VNet に関連付けて、RDP または SSH ポートへのアクセスを拒否する。
- ノードにユーザーを作成しない。 ノード ユーザーがいなければ、リモート アクセスはできません。
データを暗号化する
転送中のデータを暗号化する
Batch アカウント エンドポイント (または Azure Resource Manager 経由) へのすべての通信で、HTTPS を使用する必要があります。 Batch サービスに接続するときは、API で指定された Batch アカウント URL の https:// を使用する必要があります。
Batch サービスと通信するクライアントは、トランスポート層セキュリティ (TLS) 1.2 を使用するように構成する必要があります。
Batch の保存データを暗号化する
Batch API で指定される一部の情報 (アカウント証明書、ジョブとタスクのメタデータ、タスクのコマンド ラインなど) は、Batch サービスによって保存されるときに自動的に暗号化されます。 既定では、このデータは、各 Batch アカウントに固有の Azure Batch プラットフォーム マネージド キーを使用して暗号化されます。
カスタマー マネージド キーを使用して、このデータを暗号化することもできます。 キーの生成と格納には、Azure Key Vault を使用します。キー識別子は Batch アカウントに登録されています。
計算ノード ディスクを暗号化する
Batch の既定の計算ノードには、OS ディスクとローカル一時 SSD の 2 つのディスクがあります。 Batch によって管理されるファイルとディレクトリは、一時 SSD に配置されます。これは、タスク出力ファイルなどのファイルの既定の場所です。 Batch のタスク アプリケーションは、SSD または OS ディスク上の既定の場所を使用できます。
セキュリティを強化するために、次のいずれかの Azure ディスク暗号化機能を使用してこれらのディスクを暗号化します。
計算ノードからサービスに安全にアクセスする
Azure Key Vault を含め、マネージド ID をサポートする Azure サービスにアクセスするには、ユーザー割り当てマネージド ID に対して構成された適切なアクセス許可を持つプール マネージド ID を使用します。 Batch ノードで証明書をプロビジョニングする必要がある場合は、使用可能な Azure Key Vault VM 拡張機能とプール マネージド ID を使用して、Batch プールに証明書をインストールして管理してください。 Batch プールでマネージド ID を使用して Azure Key Vault から証明書をデプロイする方法の詳細については、「Batch プールで証明書の自動ローテーションを有効にする」を参照してください。
ガバナンスとコンプライアンス
コンプライアンス
世界中の規制されている業界や市場において、お客様が各自のコンプライアンスの義務を満たすことができるように、Azure は、コンプライアンス認証の大規模なポートフォリオを管理しています。
これらの認証は、独立したサードパーティの監査企業による正式な認証、証明、検証、認可、および評価の他に、Microsoft による契約の修正、自己評価、顧客向けのガイダンス ドキュメントを含むさまざまな種類の保証に基づいています。 コンプライアンス認証の包括的な概要に関する記事を参照して、どれがご利用の Batch ソリューションに関連するかをご確認ください。
Azure Policy
Azure Policy は、組織の標準を適用し、コンプライアンスを大規模に評価するのに役立ちます。 Azure Policy の一般的なユースケースには、リソースの整合性、規制コンプライアンス、セキュリティ、コスト、管理のガバナンスの実装が含まれています。
プール割り当てモードと、ポリシーを適用するリソースに応じて、次のいずれかの方法で Batch で Azure Policy を使用します。
- 直接 Microsoft.Batch/batchAccounts リソースを使用する。 Batch アカウントのプロパティのサブセットを使用できます。 たとえば、ご利用のポリシーに、有効な Batch アカウントのリージョン、許可されたプール割り当てモード、およびアカウントに対してパブリック ネットワークが有効かどうかを含めることができます。
- 間接的に Microsoft.Compute/virtualMachineScaleSets リソースを使用する。 ユーザー サブスクリプション プール割り当てモードによる Batch アカウントに、Batch アカウント サブスクリプションで作成された Virtual Machine Scale Sets のリソースに対するポリシーを設定できます。 たとえば、許可されている VM サイズです。各プール ノードで特定の拡張機能が実行されるようにすることもできます。
次のステップ
- 「Batch 用の Azure セキュリティ ベースライン」を確認します。
- Azure Batch のベスト プラクティスに関する記事で詳細を確認します。