Administrar recursos

Las autoridades certificadoras (AC) creadas a través de Certificate Authority Service dependen de dos tipos de recursos secundarios:

• Una versión de clave de Cloud Key Management Service, que se usa para firmar certificados y las listas de revocación de certificados (CRL) que emite la AC. Para obtener más información sobre las versiones de claves, consulta Versiones de claves.
• Un bucket de Cloud Storage, que se usa para alojar un certificado de la AC y cualquier CRL que publique la AC, si esta configuración está habilitada Para obtener más información sobre los buckets de Cloud Storage, consulta Buckets.

Ambos recursos deben existir para cada AC y no se pueden cambiar después de crearla.

Modelos de administración

El servicio de CA admite dos modelos de administración del ciclo de vida para estos recursos:

• Google-managed
• Administrada por el cliente

La clave de Cloud KMS y el bucket de Cloud Storage no es necesario que usen el mismo modelo de administración. Por ejemplo, la clave de Cloud KMS puede ser administrada por Google, y el bucket de Cloud Storage puede ser administrado por el cliente, o viceversa.

Google-managed

El servicio de AC crea y configura automáticamente los recursos según este modelo cuando se crea la AC y borra los recursos cuando se borra la AC. No se te factura por estos recursos por separado.

De forma predeterminada, las AC nuevas usan claves de Cloud KMS y buckets de Cloud Storage administrados por Google. Puedes elegir un algoritmo de clave específico para la clave de Cloud KMS administrada por Google cuando creas una AC. Las claves de Cloud KMS administradas por Google no se vuelven a usar en las AC.

Para obtener información sobre cómo crear una AC raíz, consulta Crea una AC raíz. Para obtener información sobre cómo crear una AC subordinada, consulta Crea una AC subordinada. Para obtener orientación sobre cómo elegir un algoritmo de clave, consulta Cómo elegir un algoritmo de clave.

Administrada por el cliente

Puedes crear recursos administrados por el cliente solo para las AC en el nivel empresarial. Debes crear y configurar los recursos administrados por el cliente antes de crear la AC. Además, debes borrar estos recursos en un momento adecuado después de que se destruya la AC. Se les factura directamente a los usuarios por estos recursos.

El servicio de AC considera el proyecto como el límite de seguridad para las claves de Cloud KMS administradas por el cliente. Por ejemplo, supongamos que una usuaria llamada Alice usa una clave de Cloud KMS administrada por el cliente para crear una AC en el proyecto test. Luego, otro usuario, Roberto, puede usar la misma clave de Cloud KMS para crear otra AC en el mismo proyecto. Si bien Alice necesita tener acceso de administrador a la clave para crear la primera AC, Bob no necesita ningún acceso a esa clave porque Alice ya habilitó el uso de la clave por parte del servicio de AC en el proyecto test.

Ventajas de crear recursos administrados por el cliente

Una ventaja de este modelo es que los llamadores tienen control directo sobre esos recursos. Los emisores pueden actualizar directamente atributos, como la administración de acceso, para que se ajusten a sus requisitos organizativos.

Para crear una AC con recursos administrados por el cliente, el emisor debe tener acceso administrativo a esos recursos para otorgar el acceso adecuado al servicio de AC. Para obtener más información, consulta Agente de servicio de CA Service.

Ubicación de las claves de Cloud KMS

Debes crear claves de Cloud KMS administradas por el cliente en la misma ubicación que la de los recursos de tu servicio de AC. Para obtener la lista completa de ubicaciones del servicio de AC, consulta Ubicaciones. Para obtener la lista de ubicaciones en las que se pueden crear recursos de Cloud KMS, consulta Ubicaciones de Cloud KMS.

Ubicación de los buckets de Cloud Storage

Debes crear buckets de Cloud Storage administrados por el cliente en aproximadamente la misma ubicación que los recursos de tu servicio de CA. No puedes crear el bucket de Cloud Storage fuera del continente en el que creaste los recursos del servicio de AC.

Por ejemplo, si tu AC está en us-west1, puedes crear los buckets de Cloud Storage en cualquier región de EE.UU., como us-west1 o us-east1, la región doble NAM4 y la multirregión US.

Para obtener la lista de ubicaciones en las que se pueden crear recursos de Cloud Storage, consulta Ubicaciones de Cloud Storage.

Acceso a los recursos administrados

Cualquier persona que tenga la URL del certificado de la AC alojado en un bucket de Cloud Storage o cualquier CRL que haya publicado la AC puede acceder a estos recursos de forma predeterminada. Para evitar el acceso público a tu certificado de AC y CRL, agrega el proyecto que contiene el grupo de AC a un perímetro de Controles del servicio de VPC.

Cuando agregas el proyecto que contiene el grupo de AC a un perímetro de Controles del servicio de VPC, el bucket de Cloud Storage administrado por Google se une al perímetro. El perímetro de los Controles del servicio de VPC garantiza que no se pueda acceder al bucket de Cloud Storage desde fuera de las redes aprobadas.

Los clientes dentro del perímetro de la red aún pueden acceder a las CRL y a los certificados de AC sin autenticación. Las solicitudes de acceso desde fuera de la red aprobada fallan.

URLs basadas en HTTP para certificados de AC y CRL

Los certificados de la AC y las CRL están disponibles en las URLs basadas en HTTP por los siguientes motivos:

• Los clientes no deben confiar en un certificado de AC que se publica en un bucket de Cloud Storage tal como está. Los certificados de AC forman parte de una cadena de certificados, que comienza con el certificado de la AC raíz. Cada certificado de la cadena de certificados está firmado por el certificado de la AC que está más arriba en la cadena para preservar la integridad del certificado. Por lo tanto, no hay ninguna ventaja adicional de usar el protocolo HTTPS.

• Algunos clientes rechazan las URLs basadas en HTTPS mientras validan los certificados.

Habilita la publicación de certificados de AC y CRL para las AC en un grupo de AC

El servicio de AC habilita la publicación de certificados de AC y CRL en buckets de Cloud Storage de forma predeterminada cuando creas un grupo de AC nuevo. Si inhabilitaste la publicación de certificados de AC y CRL mientras creabas el grupo de AC y quieres habilitarlos ahora, puedes seguir las instrucciones de esta sección.

Para habilitar la publicación de certificados de AC y la publicación de CRL para todas las AC en un grupo de AC, haz lo siguiente:

gcloud privateca pools update POOL_ID --publish-crl --publish-ca-cert

Para obtener más información sobre cómo habilitar la publicación de CRL para revocar certificados, consulta Cómo revocar certificados.

Inhabilita la publicación de certificados de AC y CRL para las AC en un grupo de AC

Para inhabilitar la publicación de certificados de AC o la publicación de CRL para todas las AC de un grupo de AC, haz lo siguiente:

gcloud privateca pools update POOL_ID --no-publish-crl --no-publish-ca-cert

Inhabilitar los puntos de distribución no borra el bucket de Cloud Storage ni sus permisos, ni quita los certificados de AC ni las CRL que ya se encuentran alojados allí. Sin embargo, esto significa que las CRL futuras ya no se publicarán en el bucket de Cloud Storage, y los certificados futuros no tendrán las extensiones AIA y CDP.

Actualiza el formato de codificación de los certificados de la AC y las CRL publicadas

Para actualizar el formato de codificación de los certificados de AC y las CRL publicadas, haz lo siguiente:

gcloud privateca pools update POOL_ID --publishing-encoding-format=PUBLISHING_ENCODING_FORMAT

Para obtener más información sobre el comando gcloud privateca pools update, consulta Actualización de grupos de privateca de gcloud.

¿Qué sigue?

• Obtén más información para crear grupos de AC.
• Obtén más información para crear una AC raíz.
• Obtén más información para crear una AC subordinada.
• Obtén información para crear una AC subordinada a partir de una AC externa.