相互 TLS の使用
相互 Transport Layer Security (mTLS) 認証により、トラフィックはクライアントとサーバー間の双方向でセキュアかつ信頼できるものになります。 エンタープライズプランのお客様のみご利用いただけます。
mTLS が構成されている場合、アクセスは、対応するクライアント証明書を持つ要求にのみ付与されます。 リクエストがアプリケーションに到達すると、 CIS はクライアント証明書の要求を返します。 クライアントが証明書を提示できない場合、要求は続行できません。 その他の場合、鍵交換が続行されます。
相互 TLS の構成
Mutual TLS ( mTLS ) は、セキュリティ強化のため、証明書ベースのクライアント認証を提供する。 mTLS は、デフォルトでは有効になっておらず、ドメインごとに事前の承認が必要である。 mTLS, を設定するには、以下の手順に従ってください:
-
認可を要請する。 IBM Cloud アカウントの mTLS 有効化をリクエストする サポート ケースを作成 します。
mTLS を有効にすると、無効にすることはできません。
-
有効にする mTLS:
- CIS、 「セキュリティ」をクリックし、 「相互 TLS 」タブを選択する。
- **「Enable」**をクリックします。
-
ルート証明書をアップロードする:
-
相互 TLS 」ページの 「ルート証明書」 表で、「 追加 」をクリックして新しいルート証明書を定義する。
-
証明書の内容を証明書の内容フィールドに貼り付ける。 ルート CA 証明書の名前を指定し、この証明書を使用するエンドポイントの完全修飾ドメイン名 (FQDN)を 1 つ以上追加する。
これらのFQDNは、 mTLS アプリケーションポリシーによって保護されているリソースで使用されるホスト名です。 ルート認証局は、保護されたアプリケーションで使用される FQDN と関連付ける必要があります。
-
保存 をクリックします。
中間証明書を使用する場合は、証明書チェーン全体をアップロードする。
-
-
mTLS のアクセスポリシーを作成します:
-
Mutual TLS 」ページの MTLSアクセスポリシー 表で、「 Create 」をクリックしてアクセスアプリケーションを作成します。
-
アップロードされたルート証明書に関連付けられた FQDN のいずれかに一致するホスト名を選択または入力し、「 Create 」をクリックします。
アプリケーション・ポリシーは、
non_identityの決定を使用し、有効なクライアント証明書と一致するルールを含むように事前に設定されている。
-
-
API でクライアント証明書の転送を有効にする:
検証されたクライアント証明書をオリジン・サーバに転送するには(ロギング、監査、またはバックエンド認証に役立つ)、転送を有効にする必要があります。
クライアント証明書は、各 mTLS 接続の最初のリクエストでのみ転送される。
クライアント証明書の転送を有効にするAPI curlの例については、 Update access certificates settings APIを参照してください。
オリジンサーバーに送信されるクライアント証明書ヘッダー:
Cf-Client-Cert-Der-Base64Base64-encoded DER クライアント証明書のバージョンCf-Client-Cert-Sha256SHA-256 クライアント証明書のフィンガープリント
APIで転送ステータスを確認する:
curl -X GET https://api.cis.cloud.ibm.com/v1/crn:v1:bluemix:public:internet-svcs:global:a/<account-id>:<instance-id>::/zones/<zone-id>/access/certificates/settings \ -H 'X-Auth-User-Token: Bearer <IAM-TOKEN>' -
認証されていないリクエストをブロックするWAFカスタムルールを作成する:
特にログインパスやAPIなどの機密性の高いエンドポイントのセキュリティを向上させるには、有効なクライアント証明書を提示しないリクエストをブロックするWAFルールを作成する。
- CIS、 Security セクションに戻り、 Custom rules タブを選択する。
- 「作成」 をクリックします。
- WAFカスタムルールの作成]サイドパネルで、[ 式エディタの使用 ]をクリックします。
- Use Expression Builder フィールドに以下の条件を入力する(必要に応じて
hostnameとpathを更新する)。
(http.host eq "example.com" and http.request.uri.path eq "/authenticate" and not cf.tls_client_auth.cert_verified)- 「 アクション 」を「 ブロック 」に設定します。
- 「作成」 をクリックします。
このルールは、クライアント証明書が正常に検証された場合にのみ、認証アクセスを許可する。 mTLS のないリクエストや無効な証明書によるリクエストはブロックされる。
mTLS アクセスのテスト
以下の例では、 curlを使用して、クライアント証明書を使用するリクエストと使用しないリクエストを行い、 mTLS 認証をテストしています。
-
クライアント証明書なしでサイトへのアクセスを試みる。
この例では、 mTLS を強制するサイトへのアクセスをテストするために curl を使用する例を示す。 この例におけるターゲットの URL は、
https://auth.example.comです。curl -sv https://auth.example.comクライアント証明書が提供されないので、リクエストは
403 Forbidden。 -
クライアント証明書と秘密鍵をリクエストに追加する:
curl -sv https://auth.example.com --cert example.pem --key key.pemクライアントが適切に認証されている場合、応答は mTLS の認証に成功したことを示す
CF_Authorization Set-Cookieヘッダーを含む。
相互 TLS の検証
このアクセス・ポリシーを有効にする場合、以下のワークフローを使用してクライアント証明書を検証する:
起点へのすべての要求は、有効なクライアント証明書について評価されます。
- クライアントは
Hello。 - アクセス・アプリケーションは
Helloで応答し、クライアント証明書を要求する。 - クライアントは、検証のために証明書を送信する。
- クライアント証明書は、設定されたルート認証局に対して認証される。
- 証明書チェーンを使用する場合、システムは期限切れの証明書もチェックし、チェーン全体を検証する。
- クライアント証明書が信頼されている場合、そのクライアントに対して署名付きJSON Web Token(JWT)が生成され、そのリクエストおよびその後のリクエストが実行可能になります。
- クライアントが有効な証明書を提示しない場合、サーバーは
403 Forbidden。
APIを使用してアクセス証明書を取得するには、 アクセス証明書の一覧を 参照してください。