次の方法で共有

サービス ファブリック REST 要求の認証

  • [アーティクル]

Service Fabric クラスターは、X.509 証明書、Kerberos、または X.509 証明書と Kerberos の組み合わせを使用してセキュリティで保護できます。 この記事では、次の内容について説明します。

  • HttpGatewayEndpoints (REST エンドポイント) が特定のセキュリティ ソリューションに準拠するようにクラスター マニフェストを編集する方法。

  • 各ソリューション (X.509、Kerberos、または X.509 と Kerberos の組み合わせ) で利用できるように REST 呼び出しを変更する方法。

X.509 セキュリティを使用した HTTP ゲートウェイ

Azure とオンプレミスでは、Service Fabric の REST エンドポイントでは、次の X.509 証明書を使用できます。

  1. クライアントの認証と承認: Service Fabric は、証明書に応じて、ユーザーアクセス権、管理者アクセス権、または REST クライアントへのアクセス権を付与するように構成できます。

  2. Service Fabric ノードの認証: REST クライアントは、正しい Service Fabric ノードの 1 つと通信していることを確認できます。

  3. メッセージ (REST 要求および応答) の暗号化。

注意

ユーザー アクセス権を持つクライアントのみが、読み取り要求 (https://localhost:19007/Nodes?api-version=6.0 など) のアクセス許可を持っています。 管理者アクセス権を持つクライアントは、読み取り要求と書き込み要求 (書き込み要求の例は https://localhost:19007/Nodes/<NodeName>/$/Deactivate?api-version=6.0) のアクセス許可を持っています。

クラスター マニフェストの変更

このセクションでは、X.509 証明書を使用するように構成されたクラスター マニフェストが用意できている前提で説明します。 詳細については、「 X.509 証明書を使用したクラスターのセキュリティ保護」を参照してください。

クライアントの認証と承認 (ユーザーと管理) と Service Fabric ノードの認証をサポートするようにクラスターを構成するには、クラスター マニフェストで次のパラメーターを設定する必要があります。

  • ノードの種類ごとのサーバー証明書とクライアント証明書のサムプリント

    • <ClientCertificate X509FindValue="…" />

    • <ServerCertificate X509FindValue="…" />

  • Security セクション

    • <Parameter Name="ClientRoleEnabled" Value="true" />

    • <Parameter Name="ServerAuthCredentialType" Value="X509" />

    • ClientAuthAllowedCommonNames パラメーター

    • AdminAllowedCommonNames パラメーター

    • ServerAuthAllowedCommonNames パラメーター

X.509 で既にセキュリティ保護されているクラスター マニフェストで HttpGateway を有効にするには (つまり、クラスターとクライアント/サーバーのセキュリティが既に有効になっています)、次の変更のみが必要です。

  • すべての HttpGatewayEndpoint 要素の Protocol を "https" に設定します。 たとえば、 <HttpGatewayEndpoint Port="19017" Protocol="https"/>

  • HttpGateway セクションで HttpGateway を有効にします。 たとえば、 <パラメーター名="IsEnabled" Value="true"/>

REST API と X.509 を使用する方法

X.509 で保護された HTTPS 要求の場合、関連するクライアント証明書 (一般名は ClientAuthAllowedCommonNames または AdminAllowedCommonNames で指定します) とサーバー証明書のサムプリントを作成します。

X.509 で保護された HTTP エンドポイントの場合、REST API は変わりません。 REST 呼び出しの URL、HTTP ヘッダー、要求、応答本文は変更されません。

Kerberos (または NTLM) セキュリティを使用した HTTP ゲートウェイ

オンプレミスの Service Fabric クラスターでは、Kerberos と NTLM を使用して、ユーザーおよび管理者のクライアントの認証と承認、およびサーバーの認証 (Service Fabric ノード) を行うことができます。 ただし、メッセージの暗号化に Kerberos または NTLM は使用できません。

注意

Kerberos を使用する場合は、HTTPS を使用して、クラスター マニフェストに確実にサーバー証明書が含まれるようにすることをお勧めします。

Kerberos セキュリティを使用する場合は、HTTPS も使用することを強くお勧めします。 つまり、クラスターには X.509 サーバー証明書が必要があります。 クラスターに X.509 証明書があることで、通信の暗号化にサーバー証明書が使用されます。

クライアントに X.509 証明書ではなく Kerberos 認証を使用する主な利点は、Kerberos によってクライアント証明書管理が簡易になることです。

Service Fabric を使用すると、Kerberos ではなく NTLM 経由でクライアントを認証できます。 Microsoft では、NTLM の使用を推奨していません。 詳細については、「 実装者のセキュリティに関する考慮事項」を参照してください。

可能な限り、NTLM ではなく Kerberos を使用してください。

クラスター マニフェストの変更

このセクションでは、クライアント認証に Kerberos を使用し、サーバー認証と暗号化には X.509 証明書を使用するようにクラスター マニフェストを構成している前提で説明します。 詳細については、「Windows セキュリティを使用してクラスターをセキュリティで保護する」を参照してください。

REST API と Kerberos を使用する方法

REST API を使用して Kerberos 対応クラスターと通信する場合、REST API は変わりません。 REST 呼び出しの URL、HTTP ヘッダー、要求、応答本文は変更されません。

ただし、標準の Kerberos および NTLM HTTP 認証プロセスに従う必要があります。

以下の点に注意してください。

  • ほとんどの HTTP クライアントは、このプロセスに自動的に従います。

  • サーバーが Kerberos/NTLM で保護されていることが判明している場合は、次のプロセスで手順 3 から開始できます。 これで、ネットワーク ホップが 1 回減ります。

Kerberos 認証プロセスを使用した REST

REST を使用した Kerberos 認証プロセスのシーケンスの例を次に示します。

  1. HTTP ヘッダーを追加せずに REST API を呼び出します。

    GET http://localhost:19007/Nodes?api-version=6.0 HTTP/1.1  
User-Agent: Fiddler  
Host: localhost:19007

  2. Kerberos を使用して、クラスターから 401 Unauthorized 応答を返し、www-authenticate ヘッダーを "Negotiate" に設定します。

    HTTP/1.1 401 Unauthorized  
Server: Microsoft-HTTPAPI/2.0  
WWW-Authenticate: Negotiate  
Date: Thu, 09 Jan 2014 08:20:55 GMT  
Content-Length: 0

  3. これで、クライアントがトークンを取得するには、サービスの SPN を使用して AD (フェデレーションまたは相互) に接続する必要があるようになりました。

    サービスの SPN は、接続されている Service Fabric ノードの HTTP\FQDN です。

  4. AD によって返されるトークンは、"ネゴシエート <トークン>" の形式で承認ヘッダーで使用する必要があります

    GET http://localhost:19007/Nodes?api-version=6.0 HTTP/1.1  
User-Agent: Fiddler  
Host: localhost:19007  
Authorization: Negotiate YH8GBisG<…>CSqGSIb3EgECAgYKKwYBBAGCNwICHqI/BD1OVE<…>RNT05E

  5. そのトークンはサーバーで認証され、クライアントに操作を実行する権限がある場合は、要求の実行が開始されます。

    HTTP/1.1 200 OK  
Content-Type: application/json; charset=utf-8  
Server: Microsoft-HTTPAPI/2.0  
Date: Thu, 09 Jan 2014 08:38:43 GMT  
Content-Length: 1457  

[{"Name":"Node4","IpAddressOrFQDN":"localhost","Type":"NodeType04","CodeVersion":"2.0.283.0","ConfigVersion":"1.0","NodeStatus":1,"NodeUpTimeInSeconds":"4335",NodeDownTimeInSeconds":"0","HealthState":1,"IsSeedNode":false,"UpgradeDomain":"MYUD1","FaultDomain":"fd:\/RACK2","Id":{"Id":"b5bd41bc26a079f4df3791b2b5d42e5"}},{"Name":"Node1","IpAddressOrFQDN":"localhost","Type":"NodeType01","CodeVersion":"2.0.283.0","ConfigVersion":"1.0","NodeStatus":1,"NodeUpTimeInSeconds":"4335",NodeDownTimeInSeconds":"0","HealthState":1,"IsSeedNode":true,"UpgradeDomain":"MYUD1","FaultDomain":"fd:\/RACK1","Id":{"Id":"10152272d1e44a94356a41d96dc9b466"}},{"Name":"Node2","IpAddressOrFQDN":"localhost","Type":"NodeType02","CodeVersion":"2.0.283.0","ConfigVersion":"1.0","NodeStatus":1,"NodeUpTimeInSeconds":"4335",NodeDownTimeInSeconds":"0","HealthState":1,"IsSeedNode":true,"UpgradeDomain":"MYUD2","FaultDomain":"fd:\/RACK2","Id":{"Id":"15091e9851978afe10f2f3ab37c1d2f0"}},{"Name":"Node5","IpAddressOrFQDN":"localhost","Type":"NodeType05","CodeVersion":"2.0.283.0","ConfigVersion":"1.0","NodeStatus":1,"NodeUpTimeInSeconds":"4335",NodeDownTimeInSeconds":"0","HealthState":1,"IsSeedNode":false,"UpgradeDomain":"MYUD2","FaultDomain":"fd:\/RACK1","Id":{"Id":"6e48b9c722325a66f805e2890bb7dd30"}},{"Name":"Node3","IpAddressOrFQDN":"localhost","Type":"NodeType03","CodeVersion":"2.0.283.0","ConfigVersion":"1.0","NodeStatus":1,"NodeUpTimeInSeconds":"4335",NodeDownTimeInSeconds":"0","HealthState":1,"IsSeedNode":true,"UpgradeDomain":"MYUD3","FaultDomain":"fd:\/RACK1","Id":{"Id":"880f1f5072c2c4805e9cb15ec710d083"}}]