IBM Cloud Docs
相互 TLS の使用

相互 TLS の使用

相互 Transport Layer Security (mTLS) 認証により、トラフィックはクライアントとサーバー間の双方向でセキュアかつ信頼できるものになります。 エンタープライズプランのお客様のみご利用いただけます。

mTLS が構成されている場合、アクセスは、対応するクライアント証明書を持つ要求にのみ付与されます。 リクエストがアプリケーションに到達すると、 CIS、クライアント証明書のリクエストで応答する。 クライアントが証明書を提示できない場合、要求は続行できません。 その他の場合、鍵交換が続行されます。

*の図mTLS握手
の図

相互 TLS の構成

Mutual TLS ( mTLS ) は、セキュリティ強化のため、証明書ベースのクライアント認証を提供する。 mTLS は、デフォルトでは有効になっておらず、ドメインごとに事前の承認が必要である。 mTLS, を設定するには、以下の手順に従う：

  1. 認可を要請する。 IBM Cloud アカウントの mTLS 有効化をリクエストする サポート ケースを作成 します。

    mTLS を有効にすると、無効にすることはできない。

  2. 有効にする mTLS:

    1. CIS、 「セキュリティ」をクリックし、 「相互TLS」 タブを選択する。
    2. **「Enable」**をクリックします。

  3. ルート証明書をアップロードする：

    1. 相互TLS ページのルート証明書テーブルで、 Addをクリックして新しいルート証明書を定義する。

    2. 証明書の内容を証明書の内容フィールドに貼り付ける。 ルート CA 証明書の名前を指定し、この証明書を使用するエンドポイントの完全修飾ドメイン名 （FQDN）を 1 つ以上追加する。

      これらのFQDNは、 mTLS アプリケーションポリシーによって保護されるリソースによって使用されるホスト名である。 ルート認証局は、保護されたアプリケーションで使用される FQDN と関連付ける必要があります。

    3. 保存 をクリックします。

      中間証明書を使用する場合は、証明書チェーン全体をアップロードする。

  4. mTLS アクセスポリシーを作成する：

    1. 相互TLS ページの MTLSアクセスポリシー 表で、［ 作成 ］をクリックしてアクセスアプリケーションを作成します。

    2. アップロードされたルート証明書に関連付けられた FQDN のいずれかに一致するホスト名を選択または入力し、「 Create 」をクリックします。

      アプリケーション・ポリシーは、 non_identity の決定を使用し、有効なクライアント証明書と一致するルールを含むように事前に設定されている。

  5. API でクライアント証明書の転送を有効にする：

    検証されたクライアント証明書をオリジン・サーバに転送するには（ロギング、監査、またはバックエンド認証に役立つ）、転送を有効にする必要があります。

    クライアント証明書は、各 mTLS 接続の最初のリクエストでのみ転送される。

    クライアント証明書の転送を有効にするAPI curlの例については、 Update access certificates settings APIを参照してください。

    オリジンサーバーに送信されるクライアント証明書ヘッダー：

    • Cf-Client-Cert-Der-Base64: Base64-encoded クライアント証明書のDERバージョン
    • Cf-Client-Cert-Sha256 SHA-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>'

  6. 認証されていないリクエストをブロックするWAFカスタムルールを作成する：

    特にログインパスやAPIなどの機密性の高いエンドポイントのセキュリティを向上させるには、有効なクライアント証明書を提示しないリクエストをブロックするWAFルールを作成する。

    1. CIS、 Security セクションに戻り、 Custom rules タブを選択する。

    2. 「作成」 をクリックします。

    3. WAFカスタムルールの作成］サイドパネルで、［ 式エディタの使用 ］をクリックします。

    4. 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)

    5. アクションを ブロックに設定する。

    6. 「作成」 をクリックします。

    このルールは、クライアント証明書が正常に検証された場合にのみ、認証アクセスを許可する。 mTLS、または無効な証明書を使用したリクエストはブロックされる。

mTLS アクセスのテスト

以下の例では、 curlを使用して、クライアント証明書を使用するリクエストと使用しないリクエストを行い、 mTLS 認証をテストしています。

  1. クライアント証明書なしでサイトへのアクセスを試みる。

    この例では、 mTLS を強制するサイトへのアクセスをテストするために curl を使用する例を示す。 URL この例でのターゲットは https://auth.example.com。

    curl -sv https://auth.example.com

    クライアント証明書が提供されないので、リクエストは 403 Forbidden。

  2. クライアント証明書と秘密鍵をリクエストに追加する：

    curl -sv https://auth.example.com --cert example.pem --key key.pem

    クライアントが適切に認証されている場合、応答は mTLS の認証に成功したことを示す CF_Authorization Set-Cookie ヘッダーを含む。

相互 TLS の検証

このアクセス・ポリシーを有効にする場合、以下のワークフローを使用してクライアント証明書を検証する：

起点へのすべての要求は、有効なクライアント証明書について評価されます。

  1. クライアントは Hello。
  2. アクセス・アプリケーションは Hello で応答し、クライアント証明書を要求する。
  3. クライアントは、検証のために証明書を送信する。
  4. クライアント証明書は、設定されたルート認証局に対して認証される。
  5. 証明書チェーンを使用する場合、システムは期限切れの証明書もチェックし、チェーン全体を検証する。
  6. クライアント証明書が信頼される場合、リクエストとそれ以降のリクエストの続行を許可する、署名されたJSON Webトークン(JWT)がクライアントのために生成される。
  7. クライアントが有効な証明書を提示しない場合、サーバーは 403 Forbidden。

APIを使用してアクセス証明書を取得するには、 アクセス証明書の一覧を 参照してください。