ネットワーク コントローラーをセキュリティで保護する
適用対象: Azure Stack HCI、バージョン 23H2 および 22H2。Windows Server 2022、Windows Server 2019、Windows Server 2016
この記事では、 ネットワーク コントローラー と他のソフトウェアとデバイス間のすべての通信のセキュリティを構成する方法について説明します。
セキュリティで保護できる通信パスには、管理プレーンでの Northbound 通信、クラスター内のネットワーク コントローラー仮想マシン (VM) 間のクラスター通信、データ プレーンでの Southbound 通信が含まれます。
Northbound 通信。 ネットワーク コントローラーは、管理プレーン上で、Windows PowerShell や System Center Virtual Machine Manager (SCVMM) などの SDN 対応管理ソフトウェアと通信します。 これらの管理ツールを使用すると、ネットワーク ポリシーを定義して、ネットワークの目標状態を作成できます。これに対して実際のネットワーク構成を比較し、実際の構成を目標状態と同等にすることができます。
ネットワーク コントローラー クラスター通信。 3 つ以上の VM をネットワーク コントローラー クラスター ノードとして構成すると、これらのノードは相互に通信します。 この通信は、ノード間でのデータの同期とレプリケーション、またはネットワーク コントローラー サービス間の特定の通信に関係する場合があります。
Southbound 通信。 ネットワーク コントローラーは、データ プレーン上で、SDN インフラストラクチャ、およびソフトウェア ロード バランサー、ゲートウェイ、ホスト マシンなどのその他のデバイスと通信します。 ネットワークコントローラーを使用して、これらの Southbound デバイスを構成および管理し、ネットワークに関して構成した目標状態を維持することができます。
Northbound 通信
ネットワーク コントローラーでは、Northbound 通信の認証、承認、暗号化がサポートされます。 以降のセクションでは、これらのセキュリティ設定の構成方法について説明します。
認証
ネットワーク コントローラーの Northbound 通信の認証を構成するときに、ネットワーク コントローラー クラスター ノードと管理クライアントが通信相手のデバイスの ID を確認できるようにします。
ネットワーク コントローラーでは、管理クライアントとネットワーク コントローラー ノードの間で次の 3 つの認証モードがサポートされます。
注意
System Center Virtual Machine Managerを使用してネットワーク コントローラーを展開する場合は、Kerberos モードのみがサポートされます。
Kerberos です。 管理クライアントとすべてのネットワーク コントローラー クラスター ノードの両方を Active Directory ドメインに参加させる場合は、Kerberos 認証を使用します。 Active Directory ドメインには、認証に使用されるドメイン アカウントが必要です。
X509。 Active Directory ドメインに参加していない管理クライアントの証明書ベースの認証には、X509 を使用します。 すべてのネットワーク コントローラー クラスター ノードと管理クライアントに証明書を登録する必要があります。 また、すべてのノードと管理クライアントは、お互いの証明書を信頼する必要があります。
なし。 テスト環境でのテスト目的には [なし] を使用します。そのため、運用環境で使用することはお勧めしません。 このモードを選択すると、ノードと管理クライアントの間で認証は実行されません。
Northbound 通信の認証モードは、ClientAuthentication パラメーターを指定した Windows PowerShell コマンド Install-NetworkController を使用して構成できます。
承認
ネットワーク コントローラーの Northbound 通信の承認を構成するときに、ネットワーク コントローラー クラスター ノードと管理クライアントが、通信相手のデバイスが信頼されていることと、通信に参加するアクセス許可があることを確認できるようにします。
ネットワーク コントローラーでサポートされている各認証モードには、次の承認方法を使用します。
Kerberos です。 Kerberos 認証方法を使用する場合は、Active Directory にセキュリティ グループを作成し、承認されたユーザーとコンピューターをグループに追加することで、ネットワーク コントローラーとの通信を承認されたユーザーとコンピューターを定義します。 Install-NetworkController Windows PowerShell コマンドの ClientSecurityGroup パラメーターを使用して、承認にセキュリティ グループを使用するようにネットワーク コントローラーを構成できます。 ネットワーク コントローラーをインストールした後、-ClientSecurityGroupパラメーターを指定した Set-NetworkController コマンドを使用して、セキュリティ グループを変更できます。 SCVMM を使用する場合は、展開時に、パラメーターとしてセキュリティ グループを指定する必要があります。
X509。 X509 認証方法を使用している場合、ネットワーク コントローラーは、証明書の拇印がネットワーク コントローラーに認識されている管理クライアントからの要求のみを受け入れます。 これらのサムプリントは、Install-NetworkController Windows PowerShell コマンドの ClientCertificateThumbprint パラメーターを使用して構成できます。 Set-NetworkController コマンドを使用すると、他のクライアントのサムプリントをいつでも追加できます。
なし。 このモードを選択すると、ノードと管理クライアントの間で認証は実行されません。 テスト環境でのテスト目的には [なし] を使用します。そのため、運用環境で使用することはお勧めしません。
暗号化
Northbound 通信では、Secure Sockets Layer (SSL) を使用して、管理クライアントとネットワーク コントローラー ノードの間に暗号化チャネルを作成します。 Northbound 通信の SSL 暗号化には、次の要件があります。
すべてのネットワーク コントローラー ノードには、拡張キー使用法 (EKU) 拡張機能でのサーバー認証とクライアント認証の目的を含む同じ証明書が必要です。
管理クライアントがネットワーク コントローラーと通信するために使用する URI は、証明書のサブジェクト名である必要があります。 証明書のサブジェクト名には、完全修飾ドメイン名 (FQDN) またはネットワーク コントローラー REST エンドポイントの IP アドレスが含まれている必要があります。
ネットワーク コントローラー ノードが異なるサブネット上にある場合、証明書のサブジェクト名は、Install-NetworkController Windows PowerShell コマンドの RestName パラメーターに使用される値と同じである必要があります。
すべての管理クライアントは、SSL 証明書を信頼する必要があります。
SSL 証明書の登録と構成
SSL 証明書は、ネットワーク コントローラー ノードに手動で登録する必要があります。
証明書を登録した後、Install-NetworkController Windows PowerShell コマンドの -ServerCertificate パラメーターで証明書を使用するようにネットワーク コントローラーを構成できます。 ネットワーク コントローラーを既にインストールしている場合は、Set-NetworkController コマンドを使用していつでも構成を更新できます。
注意
SCVMM を使用している場合は、証明書をライブラリ リソースとして追加する必要があります。 詳細については、「VMM ファブリックで SDN ネットワーク コントローラーを設定する」を参照してください。
ネットワーク コントローラー クラスター通信
ネットワーク コントローラーでは、ネットワーク コントローラー ノード間の通信の認証、承認、暗号化がサポートされます。 通信は、Windows Communication Foundation (WCF) と TCP を経由します。
このモードは、Install-NetworkControllerCluster Windows PowerShell コマンドの ClusterAuthentication パラメーターを使用して構成できます。
詳細については、「Install-NetworkControllerCluster」を参照してください。
認証
ネットワーク コントローラー クラスター通信の認証を構成するときに、ネットワーク コントローラー クラスター ノードが通信している他のノードの ID を確認できるようにします。
ネットワーク コントローラーでは、ネットワーク コントローラー ノードの間で次の 3 つの認証モードがサポートされます。
注意
SCVMM を使用してネットワーク コントローラーを展開する場合は、Kerberos モードのみがサポートされます。
Kerberos です。 すべてのネットワーク コントローラー クラスター ノードが、認証に使用されるドメイン アカウントを持つ Active Directory ドメインに参加している場合、Kerberos 認証を使用できます。
X509。 X509 は、証明書ベースの認証です。 ネットワーク コントローラー クラスター ノードが Active Directory ドメインに参加していない場合、X509 認証を使用できます。 X509 を使用するには、証明書をネットワーク コントローラー クラスター ノードに登録する必要があり、すべてのノードは証明書を信頼する必要があります。 さらに、各ノードに登録される証明書のサブジェクト名は、ノードの DNS 名と同じである必要があります。
なし。 このモードを選択すると、ネットワーク コントローラー ノード間で認証は実行されません。 このモードはテスト目的でのみ提供され、運用環境での使用には推奨されません。
承認
ネットワーク コントローラー クラスター通信の承認を構成する場合、ネットワーク コントローラー クラスター ノードが通信相手のノードが信頼され、通信に参加するアクセス許可を持っていることを確認できるようにします。
ネットワーク コントローラーでサポートされている各認証モードには、次の承認方法を使用します。
Kerberos です。 ネットワーク コントローラー ノードでは、他のネットワーク コントローラーのコンピューター アカウントからの通信要求のみが受け入れられます。 これらのアカウントは、ネットワーク コントローラーを展開するときに、New-NetworkControllerNodeObject Windows PowerShell コマンドの Name パラメーターを使用して構成できます。
X509。 ネットワーク コントローラー ノードでは、他のネットワーク コントローラーのコンピューター アカウントからの通信要求のみが受け入れられます。 これらのアカウントは、ネットワーク コントローラーを展開するときに、New-NetworkControllerNodeObject Windows PowerShell コマンドの Name パラメーターを使用して構成できます。
なし。 このモードを選択すると、ネットワーク コントローラー ノード間で承認は実行されません。 このモードはテスト目的でのみ提供され、運用環境での使用には推奨されません。
暗号化
ネットワーク コントローラー ノード間の通信は、WCF トランスポート レベルの暗号化を使用して暗号化されます。 この形式の暗号化は、認証と承認の方法が Kerberos または X509 証明書のいずれかである場合に使用されます。 詳細については、次の各トピックを参照してください。
Southbound 通信
Southbound 通信の場合、ネットワーク コントローラーはさまざまな種類のデバイスと対話します。 これらの対話では異なるプロトコルが使用されます。 このため、デバイスとの通信にネットワーク コントローラーで使用されるデバイスとプロトコルの種類に応じて、認証、承認、暗号化に関するさまざまな要件があります。
次の表では、ネットワーク コントローラーとさまざまな Southbound デバイスとの対話に関する情報を提供します。
| Southbound デバイスおよびサービス | Protocol | 使用される認証 |
|---|---|---|
| ソフトウェア ロード バランサー | WCF (MUX)、TCP (ホスト) | 証明書 |
| ファイアウォール | OVSDB | 証明書 |
| Gateway | WinRM | Kerberos、証明書 |
| 仮想ネットワーク | OVSDB、WCF | 証明書 |
| ユーザー定義のルーティング | OVSDB | 証明書 |
次のセクションでは、これらの各プロトコルの通信メカニズムについて説明します。
認証
Southbound 通信では、次のプロトコルと認証方法が使用されます。
WCF/TCP/OVSDB。 これらのプロトコルでは、認証は、X509 証明書を使用して実行されます。 ネットワーク コントローラーとピア ソフトウェア負荷分散 (SLB) マルチプレクサー (MUX) またはホスト マシンは、相互認証のために相互に証明書を提示します。 各証明書は、リモート ピアによって信頼される必要があります。
Southbound 認証では、Northbound クライアントとの通信を暗号化するように構成されているものと同じ SSL 証明書を使用できます。 また、SLB MUX とホスト デバイスで証明書を構成する必要があります。 証明書のサブジェクト名は、デバイスの DNS 名と同じである必要があります。
WinRM。 このプロトコルの場合、認証は、Kerberos (ドメイン参加済みマシンの場合) と証明書 (ドメインに参加していないマシンの場合) を使用して実行されます。
承認
Southbound 通信では、次のプロトコルと承認方法が使用されます。
WCF/TCP。 これらのプロトコルの場合、承認は、ピア エンティティのサブジェクト名に基づきます。 ネットワーク コントローラーでは、ピア デバイスの DNS 名が格納され、それを承認に使用されます。 この DNS 名は、証明書のデバイスのサブジェクト名と一致している必要があります。 同様に、ネットワーク コントローラーは、ピア デバイスに格納されているネットワーク コントローラーの DNS 名と一致している必要があります。
WinRM。 Kerberos を使用する場合、WinRM クライアント アカウントは、Active Directory の事前定義されたグループ、またはサーバー上のローカル管理者グループに存在する必要があります。 証明書を使用する場合、サーバーでサブジェクト名または発行者を使用して承認された証明書がクライアントによってサーバーに提示され、サーバーでは、マップされたユーザー アカウントを使用して認証が実行されます。
OVSDB。 承認は、ピア エンティティのサブジェクト名に基づいています。 ネットワーク コントローラーは、ピア デバイスの DNS 名を格納し、承認に使用します。 この DNS 名は、証明書のデバイスのサブジェクト名と一致している必要があります。
暗号化
Southbound 通信の場合、次の暗号化方法がプロトコルに使用されます。
WCF/TCP/OVSDB。 これらのプロトコルでは、暗号化は、クライアントまたはサーバーに登録されている証明書を使用して実行されます。
WinRM。 WinRM トラフィックは、既定では、Kerberos セキュリティ サポート プロバイダー (SSP) を使用して暗号化されます。 WinRM サーバーで、追加の暗号化 (SSL 形式) を構成できます。