リソースの管理
Certificate Authority Service により作成された認証局（CA）は、2 つのセカンダリ リソースタイプに依存します。
- Cloud Key Management Service の鍵バージョン。CA によって発行された証明書と証明書失効リスト（CRL）の署名に使用されます。鍵バージョンの詳細については、鍵バージョンをご覧ください。
- Cloud Storage バケット。CA 証明書および CA によって公開された CRL をホストするために使用されます（これらの設定が有効になっている場合）。Cloud Storage バケットの詳細については、バケットをご覧ください。
これらのリソースはいずれも、CA ごとに存在する必要があり、CA の作成後に変更することはできません。
管理モデル
CA Service は、これらのリソースに対して 2 つのライフサイクル管理モデルをサポートしています。
- Google が管理
- 顧客管理
Cloud KMS 鍵と Cloud Storage バケットは、同じ管理モデルを使用する必要はありません。たとえば、Cloud KMS 鍵を Google が管理し、Cloud Storage バケットをお客様が管理することも、その逆も可能です。
Google が管理
CA Service は、CA の作成時にこのモデルに従ってリソースを自動的に作成して構成し、CA の削除時にリソースを削除します。 これらのリソースに対して別途課金されることはありません。
デフォルトでは、新しい CA は Google が管理する Cloud KMS 鍵と Cloud Storage バケットを使用します。CA を作成するときに、Google が管理する Cloud KMS 鍵に特定の鍵アルゴリズムを選択できます。Google が管理する Cloud KMS 鍵は、CA 間で再利用されません。
ルート CA の作成の詳細については、ルート CA を作成するをご覧ください。 下位 CA の作成方法については、下位 CA を作成するをご覧ください。 鍵アルゴリズムの選択に関するガイダンスについては、鍵アルゴリズムを選択するをご覧ください。
顧客管理
お客様が管理するリソースは、Enterprise ティアの CA に対してのみ作成できます。CA を作成する前に、お客様が管理するリソースを作成して構成する必要があります。また、CA が破棄された後、適切なタイミングでこれらのリソースを削除する必要があります。ユーザーはこれらのリソースに対して直接課金されます。
CA Service は、プロジェクトを顧客管理の Cloud KMS 鍵のセキュリティ境界として扱います。たとえば、ユーザー Alice がお客様が管理する暗号鍵（Cloud KMS）鍵を使用してプロジェクト test に CA を作成したとします。その後、別のユーザー Bob が同じ Cloud KMS 鍵を使用して、同じプロジェクトに別の CA を作成できます。Alice は、最初の CA を作成するために、鍵に対する管理者権限が必要ですが、Alice がプロジェクト test で CA Service による鍵の使用をすでに有効にしているため、Bob はその鍵に対するアクセス権は必要ありません。
顧客管理のリソースを作成するメリット
このモデルのメリットの 1 つは、呼び出し元がこれらのリソースを直接制御できることです。呼び出し元は、組織の要件に合わせてアクセス管理などの属性を直接更新できます。
顧客管理のリソースを使用して CA を作成するには、CA Service に適切なアクセス権を付与するために、呼び出し元にそれらのリソースに対する管理者権限が必要です。詳細については、CA Service のサービス エージェントをご覧ください。
Cloud KMS 鍵のロケーション
顧客管理の Cloud KMS 鍵は、CA Service リソースと同じロケーションに作成する必要があります。CA Service のロケーションのリストについては、ロケーションをご覧ください。Cloud KMS リソースを作成できるロケーションのリストについては、Cloud KMS のロケーションをご覧ください。
Cloud Storage バケットのロケーション
顧客管理の Cloud Storage バケットは、CA Service リソースとほぼ同じロケーションに作成する必要があります。CA Service リソースを作成した大陸の外部に Cloud Storage バケットを作成することはできません。
たとえば、CA が us-west1 にある場合、us-west1 や us-east1 など、米国内の任意の単一リージョン、デュアルリージョン NAM4 およびマルチリージョン US に Cloud Storage バケットを作成できます。
Cloud Storage リソースを作成できるロケーションのリストについては、Cloud Storage のロケーションをご覧ください。
マネージド リソースへのアクセス
Cloud Storage バケットでホストされている CA 証明書の URL または CA によって公開された CRL のすべてのユーザーは、デフォルトでこれらのリソースにアクセスできます。 CA 証明書と CRL への一般公開を防ぐには、CA プールを含むプロジェクトを VPC Service Controls の境界に追加します。
CA プールを含むプロジェクトを VPC Service Controls 境界に追加すると、Google が管理する Cloud Storage バケットが境界に結合されます。VPC Service Controls の境界により、承認済みネットワークの外部から Cloud Storage バケットにアクセスできなくなります。
ネットワーク境界内のクライアントは、認証なしで CRL と CA 証明書にアクセスできます。承認済みネットワークの外部からのアクセス リクエストは失敗します。
CA 証明書と CRL の HTTP ベースの URL
CA 証明書と CRL は、次の理由から HTTP ベースの URL で使用できます。
Cloud Storage バケットで公開される CA 証明書は、クライアントによってそのまま信頼されているわけではありません。CA 証明書は、ルート CA の証明書で始まる証明書チェーンの一部です。証明書チェーンの各証明書は、証明書の整合性を維持するため、チェーンの上位にある CA 証明書によって署名されます。したがって、HTTPS プロトコルを使用するメリットはありません。
一部のクライアントは、証明書の検証中に HTTPS ベースの URL を拒否します。
CA プール内の CA の CA 証明書と CRL の公開を有効にする
CA Service は、新しい CA プールを作成するときに、Cloud Storage バケットへの CA 証明書と CRL の公開をデフォルトで有効にします。CA プールの作成時に CA 証明書と CRL の公開を無効にし、今すぐ有効にする場合は、このセクションの手順に従ってください。
CA プール内のすべての CA の CA 証明書の公開と CRL 公開を有効にするには、次の操作を行います。
Console
Google Cloud コンソールの [Certificate Authority Service] ページに移動します。
[CA プール マネージャー] タブで、編集する CA プールの名前をクリックします。
[CA プール] ページで、 [編集] をクリックします。
[許可される鍵アルゴリズムとサイズを構成する] で、[次へ] をクリックします。
[受け入れられる証明書リクエスト メソッドを構成する] で、[次へ] をクリックします。
[公開オプションを構成する] で、[このプール内の CA の Cloud Storage バケットに CA 証明書を公開する] の切り替えボタンをクリックします。
[このプール内の CA の Cloud Storage バケットに CRL を公開する] の切り替えボタンをクリックします。
gcloud
次のコマンドを実行します。
gcloud privateca pools update POOL_ID --publish-crl --publish-ca-cert
POOL_ID を、CA プールの名前に置き換えます。
--publish-ca-cert を有効にすると、CA Service は各 CA の CA 証明書を Cloud Storage バケットに書き込みます。このバケットのパスは CA リソースで指定されます。発行されたすべての証明書の AIA 拡張機能は、CA 証明書を含む Cloud Storage オブジェクトの URL を指します。発行されたすべての証明書の CRL 配布ポイント（CDP）拡張機能は、CRL を含む Cloud Storage オブジェクト URL を指します。
gcloud privateca pools update コマンドの詳細については、gcloud privateca pools update をご覧ください。
証明書の取り消しのために CRL 公開を有効にする方法の詳細ついては、証明書の取り消しをご覧ください。
CA プール内の CA の CA 証明書と CRL の公開を無効にする
CA プール内のすべての CA の CA 証明書の公開または CRL 公開を無効にするには、次の手順を行います。
Console
Google Cloud コンソールの [Certificate Authority Service] ページに移動します。
[CA プール マネージャー] タブで、編集する CA プールの名前をクリックします。
[CA プール] ページで、 [編集] をクリックします。
[許可される鍵アルゴリズムとサイズを構成する] で、[次へ] をクリックします。
[受け入れられる証明書リクエスト メソッドを構成する] で、[次へ] をクリックします。
[公開オプションを構成する] で、[このプール内の CA の Cloud Storage バケットに CA 証明書を公開する] の切り替えボタンをクリックします。
[このプール内の CA の Cloud Storage バケットに CRL を公開する] の切り替えボタンをクリックします。
gcloud
次のコマンドを実行します。
gcloud privateca pools update POOL_ID --no-publish-crl --no-publish-ca-cert
POOL_ID を、CA プールの名前に置き換えます。
ディストリビューション ポイントを無効にしても、Cloud Storage バケットやその権限は削除されません。また、そこにすでにホストされている CA 証明書や CRL も削除されません。ただし、将来の CRL は Cloud Storage バケットに公開されなくなり、将来の証明書には AIA および CDP 拡張機能が適用されなくなります。
公開された CA 証明書と CRL のエンコード形式を更新する
公開された CA 証明書と CRL のエンコード形式を更新するには、次の手順を行います。
Console
Google Cloud コンソールの [Certificate Authority Service] ページに移動します。
[CA プール マネージャー] タブで、編集する CA プールの名前をクリックします。
[CA プール] ページで、 [編集] をクリックします。
[許可される鍵アルゴリズムとサイズを構成する] で、[次へ] をクリックします。
[受け入れられる証明書リクエスト メソッドを構成する] で、[次へ] をクリックします。
[公開オプションを構成する] で [公開エンコード形式] のプルダウン メニューをクリックします。
公開エンコード形式を選択します。
gcloud
次のコマンドを実行します。
gcloud privateca pools update POOL_ID --publishing-encoding-format=PUBLISHING_ENCODING_FORMAT
以下を置き換えます。
- POOL_ID: CA プールの名前。
- PUBLISHING_ENCODING_FORMAT:
PEMまたはDER。
gcloud privateca pools update コマンドの詳細については、gcloud privateca pools update をご覧ください。
次のステップ
- CA プールを作成する方法を学習する。
- ルート CA を作成する方法を学習する。
- 下位 CA を作成する方法を学習する。
- 外部 CA から下位 CA を作成する方法を学習する。