このページでは、ウェブ アプリケーションに対する証明書ベースのアクセス(CBA)を有効にする方法について説明します。CBA を使用すると、信頼できるデバイスから Google Cloud で実行されるエンタープライズ ウェブ アプリケーションへのアクセスが保護されます。
概要
ウェブ アプリケーションに対する CBA は、BeyondCorp Enterprise コンテキストアウェア アクセス機能と Google Cloud ネットワーキングを使用して、相互 TLS(mTLS)によりアクセスを保護します。ウェブ アプリケーションに対して CBA を有効にするために連携する主要コンポーネントは次のとおりです。
- Access Context Manager: ウェブ アプリケーションへのアクセスを決定する際に証明書を必要とするアクセスレベルを作成できます。
- Identity-Aware Proxy(IAP): ウェブ アプリケーションへのユーザー アクセスを認証します。
- Google Cloud HTTPS ロードバランサ: ユーザーとウェブ アプリケーション間の相互認証(mTLS)を提供します。
- Chrome Enterprise ポリシー: Chrome ブラウザを使用する場合に、ユーザーとウェブ アプリケーション間の相互認証(mTLS)を提供します。
準備
次のコマンドを実行して、Google Cloud CLI の最新バージョンを利用できるか確認します。
gcloud components update
外部 HTTPS ロードバランサに mTLS を設定する
手順に沿って、HTTPS 外部ロードバランサを設定します。作成されたターゲット HTTPS プロキシの名前をメモします。この名前は後の手順で必要になります。
信頼構成を作成する
公開鍵基盤(PKI)の種類を表す信頼構成を作成します。
このタスクを完了するには、ターゲットの Google Cloud プロジェクトに対する certificatemanager.trustconfigs.create
権限が必要です。
信頼構成は、Google 発行の証明書(方法 1)、独自の証明書(方法 2)、Endpoint Verification による自己署名証明書(方法 3)を使用して作成できます。
方法 1
Google 発行の証明書を使用して、信頼構成を作成します。
- ルート CA を作成する手順を完了します。
PEM ファイルの内容を取得します。
gcloud privateca roots describe ROOT_CA_ID \ --pool=POOL_ID \ --location=CA_LOCATION \ --format='value(pemCaCertificates)'
次のように置き換えます。
- ROOT_CA_ID: ルート証明書 ID。
- POOL_ID: ルート証明書のプール ID。
- CA_LOCATION: CA のロケーション。
pemCaCertificates
フィールドで返されるルート証明書を取得します。この証明書はBEGIN CERTIFICATE
マーカーとEND CERTIFICATE
マーカーの間の文字列であり、両方のマーカーが含まれています。ルート証明書を PEM 形式でファイルに保存します。
信頼構成を作成します。
次の環境変数を設定します。
ROOT_PEM_FILE=TRUST_ANCHOR_PATH INT_PEM_FILE1=IM_CERT_PATH INT_PEM_FILE2=SECOND_IM_CERT_PATH
次のように置き換えます。
- TRUST_ANCHOR_PATH: PEM エンコードされたトラスト アンカーのパス。
- IM_CERT_PATH: PEM エンコードされた中間証明書のパス。
- SECOND_IM_CERT_PATH: 2 番目の PEM エンコードされた中間証明書のパス。
信頼構成 YAML ファイルの内容を準備します。
ROOT=$(cat ROOT_PEM_FILE | sed 's/^[ ]*//g' | tr '\n' $ | sed 's/\$/\\n/g') INT_1=$(cat INT_PEM_FILE1 | sed 's/^[ ]*//g' | tr '\n' $ | sed 's/\$/\\n/g') INT_2=$(cat INT_PEM_FILE2 | sed 's/^[ ]*//g' | tr '\n' $ | sed 's/\$/\\n/g')
信頼構成 YAML ファイルを作成します。
cat << EOF > trust_config.yaml name: "${TRUST_CONFIG_NAME?}" trustStores: - trustAnchors: - pemCertificate: "${ROOT?}" intermediateCas: - pemCertificate: "${INT_1?}" - pemCertificate: "${INT_2?}" EOF
この YAML ファイルは
TRUST_CONFIG_NAME
という名前の信頼構成を定義します。信頼構成には、ルート証明書と 2 つの中間証明書を備えた 1 つのトラストストアが含まれます。信頼構成を Google Cloud Certificate Manager にインポートします。
gcloud certificate-manager trust-configs import TRUST_CONFIG_NAME \ --project=GCP_PROJECT \ --source=${PWD?}/trust_config.yaml
次のように置き換えます。
- TRUST_CONFIG_NAME: 信頼構成の名前。
- GCP_PROJECT: Google Cloud プロジェクト ID。
ルートによって署名された中間 CA を使用してより複雑な構造をデプロイする場合は、中間 CA を intermediateCAs
として追加します。
方法 2
既存の証明書で独自の PKI デプロイを使用して、信頼構成を作成します。
このタイプの信頼構成は、ルート証明書を表す単一のトラスト アンカーを持つ基本的なトラストストアを前提としています。中間証明書は指定されません。
信頼構成を作成します。
次の環境変数を設定します。
ROOT_PEM_FILE=TRUST_ANCHOR_PATH INT_PEM_FILE1=IM_CERT_PATH INT_PEM_FILE2=SECOND_IM_CERT_PATH
次のように置き換えます。
- TRUST_ANCHOR_PATH: PEM エンコードされたトラスト アンカーのパス。
- IM_CERT_PATH: PEM エンコードされた中間証明書のパス。
- SECOND_IM_CERT_PATH: 2 番目の PEM エンコードされた中間証明書のパス。
信頼構成 YAML ファイルの内容を準備します。
ROOT=$(cat ROOT_PEM_FILE | sed 's/^[ ]*//g' | tr '\n' $ | sed 's/\$/\\n/g') INT_1=$(cat INT_PEM_FILE1 | sed 's/^[ ]*//g' | tr '\n' $ | sed 's/\$/\\n/g') INT_2=$(cat INT_PEM_FILE2 | sed 's/^[ ]*//g' | tr '\n' $ | sed 's/\$/\\n/g')
信頼構成 YAML ファイルを作成します。
cat << EOF > trust_config.yaml name: "${TRUST_CONFIG_NAME?}" trustStores: - trustAnchors: - pemCertificate: "${ROOT?}" intermediateCas: - pemCertificate: "${INT_1?}" - pemCertificate: "${INT_2?}" EOF
この YAML ファイルは
TRUST_CONFIG_NAME
という名前の信頼構成を定義します。信頼構成には、ルート証明書と 2 つの中間証明書を備えた 1 つのトラストストアが含まれます。信頼構成を Google Cloud Certificate Manager にインポートします。
gcloud certificate-manager trust-configs import TRUST_CONFIG_NAME \ --project=GCP_PROJECT \ --source=${PWD?}/trust_config.yaml
次のように置き換えます。
- TRUST_CONFIG_NAME: 信頼構成の名前。
- GCP_PROJECT: Google Cloud プロジェクト ID。
方法 3
Chrome ブラウザを使用していて、Endpoint Verification で自己署名証明書を使用する場合は、このセクションの手順を行ってください。
手順に沿って、組織用に Endpoint Verification をデプロイします。Endpoint Verification は、Google が発行した自己署名証明書を自動的にデバイスにデプロイします。これにより、信頼構成を作成する必要がなくなります。
TLS ポリシーを作成して外部ロードバランサで mTLS を有効にする
方法 3 を使用した場合は、このステップをスキップできます。
このタスクを行うには、次の権限が必要です。
- この
ServerTlsPolicy
用に作成した信頼構成に対するcertificatemanager.trustconfigs.use
- ターゲットの Google Cloud プロジェクトに対する
networksecurity.serverTlsPolicies.create
サーバー TLS ポリシー YAML ファイルを作成します。
cat << EOF > server_tls_policy.yaml name: "SERVER_TLS_POLICY_NAME" mtlsPolicy: clientValidationMode: ALLOW_INVALID_OR_MISSING_CLIENT_CERT clientValidationTrustConfig: projects/GCP_PROJECT/locations/global/trustConfigs/TRUST_CONFIG_NAME EOF
次のように置き換えます。
- SERVER_TLS_POLICY_NAME: サーバー TLS ポリシーの名前。
- GCP_PROJECT: Google Cloud プロジェクト ID。
- TRUST_CONFIG_NAME: 前の手順で作成した信頼構成。
clientValidationMode
のクライアント検証オプションについては、MTLS クライアント検証モードをご覧ください。サーバー TLS ポリシー YAML を Google Cloud プロジェクトにインポートします。
gcloud network-security server-tls-policies import ${SERVER_TLS_POLICY_NAME?} \ --project=GCP_PROJECT \ --source=${PWD?}/server_tls_policy.yaml \ --location=global
GCP_PROJECT は、Google Cloud プロジェクト ID に置き換えます。
作成した TLS ポリシーは変更できません。既存の TLS ポリシーを変更する場合は、既存の TLS ポリシーを削除して新しいポリシーを作成します。
ターゲット HTTPS ポリシーに TLS ポリシーを接続する
このタスクを完了するには、ターゲットの Google Cloud プロジェクトに対する compute.targetHttpsProxies.get
権限が必要です。
既存のターゲット HTTPS プロキシをローカル ファイルにエクスポートします。
gcloud compute target-https-proxies export TARGET_HTTPS_PROXY_NAME \ --project=GCP_PROJECT \ --global \ --destination=${PWD?}/xlb-mtls-target-proxy.yaml
次のように置き換えます。
- TARGET_HTTPS_PROXY_NAME: ターゲット HTTPS プロキシ。
- GCP_PROJECT: Google Cloud プロジェクト ID。
ターゲット HTTPS プロキシ構成に
ServerTlsPolicy
を追加します。このタスクを行うには、次の権限が必要です。
- ターゲット HTTPS プロキシ用に作成した
ServerTlsPolicy
に対するnetworksecurity.serverTlsPolicies.use
- ターゲットの Google Cloud プロジェクトに対する
compute.targetHttpsProxies.update
echo "serverTlsPolicy: //networksecurity.googleapis.com/projects/GCP_PROJECT/locations/global/serverTlsPolicies/SERVER_TLS_POLICY_NAME" >> xlb-mtls-target-proxy.yaml
次のように置き換えます。
- GCP_PROJECT: Google Cloud プロジェクト ID。
- SERVER_TLS_POLICY_NAME: サーバー TLS ポリシー。
- ターゲット HTTPS プロキシ用に作成した
ローカル ファイルから新しい構成をインポートして、ターゲット HTTPS プロキシを更新します。
gcloud compute target-https-proxies import TARGET_HTTPS_PROXY_NAME \ --project=GCP_PROJECT \ --global \ --source=${PWD?}/xlb-mtls-target-proxy.yaml
次のように置き換えます。
- TARGET_HTTPS_PROXY_NAME: ターゲット HTTPS プロキシ。
- GCP_PROJECT: Google Cloud プロジェクト ID。
証明書を必要とするアクセスレベルを作成する
コンソール
- 手順に沿って、カスタム アクセスレベルを作成します。
カスタム アクセスレベルに次の式を追加します。
信頼構成(方法 1 または方法 2)を作成した場合、次の式をカスタム アクセスレベルの [条件] フィールドに追加して、認証時に PKI 証明書バインディングを使用します。
certIsPkiAttested(origin, ["TLS_POLICY_FULL_RESOURCE_PATH1", "TLS_POLICY_FULL_RESOURCE_PATH2", …]) == true
ここで、TLS_POLICY_FULL_RESOURCE_PATH1 と TLS_POLICY_FULL_RESOURCE_PATH2 は、複数の信頼構成を表すパスです(
certificatemanager.googleapis.com/projects/GCP_PROJECT/locations/global/trustConfigs/TRUST_CONFIG_NAME
)。少なくとも 1 つの信頼構成パスを指定する必要があります。
次のように置き換えます。
- GCP_PROJECT: Google Cloud プロジェクト ID。
- TRUST_CONFIG_NAME: 信頼構成の名前。
Google 発行の自己署名証明書(方法 3)を使用した場合、次の式をカスタム アクセスレベルの [条件] フィールドに追加して、認証時に証明書バインディングを使用します。
certificateBindingState(origin, device) == CertificateBindingState.CERT_MATCHES_EXISTING_DEVICE
gcloud
信頼構成(方法 1 または方法 2)を作成した場合、次のコマンドを実行して、認証時に PKI 証明書バインディングを使用するカスタム アクセスレベルを作成します。
gcloud access-context-manager levels create ACCESS_LEVEL_NAME \
--title=TITLE \
--custom-level-spec=FILE \
--description=DESCRIPTION \
--policy=POLICY_NAME
次のように置き換えます。
- ACCESS_LEVEL_NAME: アクセスレベルの一意の名前。
- TITLE: 人が読める形式のタイトル。
FILE: 次の式を含む YAML ファイル。
certIsPkiAttested(origin, ["TLS_POLICY_FULL_RESOURCE_PATH1", "TLS_POLICY_FULL_RESOURCE_PATH2", …]) == true
ここで、TLS_POLICY_FULL_RESOURCE_PATH1 と TLS_POLICY_FULL_RESOURCE_PATH2 は、複数の信頼構成を表すパスです(
certificatemanager.googleapis.com/projects/GCP_PROJECT/locations/global/trustConfigs/TRUST_CONFIG_NAME
)。少なくとも 1 つの信頼構成パスを指定する必要があります。
次のように置き換えます。
- GCP_PROJECT: Google Cloud プロジェクト ID。
- TRUST_CONFIG_NAME: 信頼構成の名前。
DESCRIPTION: アクセスレベルの詳細な説明。
POLICY_NAME: 組織のアクセス ポリシー。
Endpoint Verification を活用した自己署名証明書(方法 3)を使用していることで信頼構成がない場合は、カスタム アクセスレベルに次の式を追加します。
certificateBindingState(origin, device) == CertificateBindingState.CERT_MATCHES_EXISTING_DEVICE
Identity-Aware Proxy(IAP)を使用して証明書ベースのアクセスを適用する
ウェブ アプリケーションに対する CBA アーキテクチャでは、IAP はプリンシパル ベースのポリシー適用を提供し、信頼できないデバイスからウェブ アプリケーションを保護します。
IAP を有効にして CBA ポリシーを構成するには、次の手順を行います。
- IAP を設定していない場合は、こちらの手順に沿って IAP を設定します。
- IAP に移動して、先ほど作成したアクセスレベルを接続します。
IAP に移動 - CBA で保護するリソースを選択し、[設定] をクリックします。
- [アクセスレベル] フィールドに、作成したアクセスレベルの名前を入力します。
Google Cloud CLI を使用して IAP で CBA ポリシーを構成するには、Google Cloud CLI のドキュメントをご覧ください。
証明書を自動的に選択するようにブラウザを構成する
アクセスを決定する際に、ブラウザが自動的に証明書を選択できるようにするには、お使いのブラウザに関する手順を完了します。
Google Chrome
mTLS handshake 中に Chrome が正しい証明書を使用するように、AutoSelectCertificateForURLs
Chrome ポリシーを構成します。
Chrome ブラウザ クラウド管理または Windows グループ ポリシーで Chrome ブラウザが管理されていることを確認します。
- Windows、macOS、Linux: 管理対象の Chrome プロファイルを設定する手順を実施します。
- Chrome: デバイスを企業に登録します。
AutoSelectCertificateForUrls
ポリシーを追加します。
詳細については、ポリシー スキーマのドキュメントをご覧ください。Endpoint Verification の証明書を使用するポリシー構成の例を次に示します。
{
"pattern":"https://[*.].mysite.com",
"Filter":{
"ISSUER":{
"CN":"Google Endpoint Verification"
}
}
}
Safari
ID 設定を構成します。
- キーチェーン アクセス アプリを開き、[すべてのアイテム] を選択します。
- 構成する証明書を選択します。
- [ファイル] > [新しい ID 設定] をクリックします。
- URL を入力して [追加] をクリックします。
これにより、キーチェーンに更新可能な新しい ID 設定エントリが作成されます。
Edge
Edge ドキュメントの手順に沿って、AutoSelectCertificateForUrls
Edge ポリシーを設定します。