Adicione políticas de emissão de certificados

A adição de políticas de emissão de certificados no serviço de AC envolve a definição de regras e restrições que regem os tipos de certificados emitidos por uma autoridade de certificação (AC). Para saber mais acerca das políticas de emissão de certificados, consulte o artigo Acerca das políticas de emissão de certificados.

Uma política de emissão de certificados permite-lhe especificar o requerente e os nomes alternativos do requerente (SANs) que podem ser incluídos nos certificados emitidos. Pode especificar a política de emissão de certificados ao criar um conjunto de ACs ou pode atualizar um conjunto de ACs existente para adicionar uma política de emissão.

Para mais informações, consulte o artigo Vista geral dos modelos e das políticas de emissão.

Antes de começar

• Certifique-se de que tem a função do IAM de gestor de operações do serviço de AC (roles/privateca.caManager) ou administrador do serviço de AC (roles/privateca.admin). Para ver informações sobre como conceder um IAM a um principal, consulte o artigo Conceda uma única função.

• Crie um conjunto de ACs.

Pode adicionar uma política de emissão de certificados a um conjunto de ACs durante a criação de um conjunto de ACs ou quando atualiza um conjunto de ACs existente.

Use um dos seguintes métodos:

Restrições suportadas

O serviço de AC suporta as seguintes restrições de política de emissão. Pode combinar as seguintes restrições conforme necessário para criar uma política de emissão de certificados personalizada.

Restrinja ou force valores X.509 permitidos

Um conjunto de ACs pode restringir os valores X.509 permitidos em pedidos de certificados através da configuração do campo passthrough_extensions.

Um conjunto de ACs também pode especificar explicitamente valores X.509 a serem adicionados a todos os respetivos certificados emitidos, substituindo quaisquer valores pedidos, através do campo baseline_values.

Os valores de baseline_values de um conjunto de CA permitem especificar as seguintes propriedades:

• Utilização da chave
• Opções de CA
• Servidores OCSP da AIA
• Extensões X.509 adicionais

Também pode usar estas opções em conjunto.

Se atualizar qualquer parte do campo baseline_values, a atualização substitui o conjunto completo de valores no campo baseline_values.

• Exemplo: restrinja uma AC para emitir apenas certificados de entidade final com valores X.509 para TLS mútuo (mTLS).

  policy.yaml

  baselineValues:
    caOptions:
      isCa: false
    keyUsage:
      baseKeyUsage:
        digitalSignature: true
        keyEncipherment: true
      extendedKeyUsage:
         clientAuth: true
         serverAuth: true
  

• Exemplo: restrinja uma AC para emitir apenas certificados de assinatura de código de entidade final com um URL OCSP AIA de base.

  policy.yaml

  baselineValues:
    caOptions:
      isCa: false
    keyUsage:
      baseKeyUsage:
        digitalSignature: true
      extendedKeyUsage:
        codeSigning: true
    aiaOcspServers:
      -   "http://foo.bar/revocation"
    additionalExtensions:
    -   objectId:
          objectIdPath:
            -   1
            -   2
            -   3
        critical: false
        value: "base64 encoded extension value"
  

Para mais informações acerca do perfil do certificado para mTLS de entidade, consulte o artigo mTLS de entidade.

Restrinja os campos de identidade permitidos

Para restringir a identidade dos certificados emitidos através de um conjunto de ACs, pode adicionar uma expressão da [Linguagem de expressão comum (CEL)][4]{: .external} ao campo identity_constraints da política de emissão. As expressões CEL permitem restrições arbitrárias sobre o nome do domínio do assunto (incluindo o nome comum) e os SANs de um certificado.

Para mais informações sobre a utilização de uma expressão CEL para restringir o assunto e os SANs, consulte o artigo Usar o IEC.

• Exemplo Permitir que a AC emita apenas certificados que correspondam a um assunto especificado.

  policy.yaml

  identityConstraints:
    allowSubjectPassthrough: true
    allowSubjectAltNamesPassthrough: false
    celExpression:
      expression: 'subject.organization == "Example LLC" && subject.country_code in ["US", "UK"]'
  

  O campo celExpression é opcional. Use uma expressão do Idioma de expressão comum (IEC) para validar o assunto e o SAN X.509 resolvidos antes de um certificado ser assinado. Para mais informações sobre a utilização de expressões CEL, consulte o artigo Usar o IEC.

• Exemplo: permita apenas SANs com DNS Names como us.google.org ou que terminem em .google.com.

  policy.yaml

  identityConstraints:
    allowSubjectPassthrough: false
    allowSubjectAltNamesPassthrough: true
    celExpression:
      expression: 'subject_alt_names.all(san, san.type == DNS && (san.value == "us.google.org" || san.value.endsWith(".google.com")) )'
  

• Exemplo: permitir apenas SANs com URIs https://google.com/webhp ou que comecem por spiffe://example-trust-domain-1/ns/namespace1/sa/.

  policy.yaml

  identityConstraints:
    allowSubjectPassthrough: false
    allowSubjectAltNamesPassthrough: true
    celExpression:
      expression: 'subject_alt_names.all(san, san.type == URI && (san.value == "https://google.com/webhp" || san.value.startsWith("spiffe://example-trust-domain-1/ns/namespace1/sa/")) )'
  

• Exemplo: permitir apenas SANs com endereços de email example@google.com ou que terminem com @google.org.

  policy.yaml

  identityConstraints:
    allowSubjectPassthrough: false
    allowSubjectAltNamesPassthrough: true
    celExpression:
      expression: 'subject_alt_names.all(san, san.type == EMAIL && (san.value == "example@google.com" || san.value.endsWith("@google.org")) )'
  

• Exemplo: permitir apenas SANs personalizadas com um OID específico e um valor personalizado.

  policy.yaml

  identityConstraints:
    allowSubjectPassthrough: false
    allowSubjectAltNamesPassthrough: true
    celExpression:
      expression: 'subject_alt_names.all(san, san.type == CUSTOM && san.oid == [1, 2, 3, 4] && san.value == "custom-data" )'
  

Restrinja a duração da data anterior dos certificados emitidos

Para definir um not_before_time anterior para certificados emitidos, use o campo backdate_duration. Quando configurados, os certificados deste conjunto de AC têm um not_before_time igual à hora de emissão menos a duração especificada. O not_after_time é ajustado para manter a duração do certificado pedida. O elemento backdate_duration tem de ser igual ou inferior a 48 horas.

Exemplo

Para retroceder a data dos certificados em 1 hora, use o seguinte ficheiro policy.yaml:

backdateDuration: 3600s

Restrinja a duração máxima dos certificados emitidos

Para restringir a duração total dos certificados emitidos, use o campo maximum_lifetime. Se a duração pedida de um certificado for superior à duração máxima, a duração do certificado é explicitamente truncada.

Exemplo

Para permitir uma duração máxima de 30 dias, use o seguinte ficheiro policy.yaml:

maximumLifetime: 2592000s

Restrinja os modos de emissão de certificados permitidos

Pode pedir um certificado através de um pedido de assinatura de certificado (CSR) ou de uma descrição inline dos valores pedidos. Algumas organizações podem preferir adicionar limitações à opção que pode ser usada porque o último método não requer um comprovativo de posse da chave privada associada. Pode definir estas limitações através do campo allowedIssuanceModes.

Para mais informações sobre como especificar as formas como os certificados podem ser pedidos a um conjunto de ACs, consulte IssuanceModes.

Para mais informações sobre como pedir certificados, consulte o artigo Crie um pedido de certificado.

• Exemplo: permitir apenas a emissão de CSRs.

allowedIssuanceModes:
  allowCsrBasedIssuance: True
  allowConfigBasedIssuance: False

Restrinja os algoritmos de chave pública do pedido de certificado

Para restringir o comprimento mínimo da chave e os algoritmos de chave pública que os certificados podem usar, pode usar o campo allowedKeyTypes no ficheiro YAML da política de emissão de certificados. Se este campo for especificado, a chave pública do pedido de certificado tem de corresponder a um dos tipos de chaves indicados no ficheiro YAML. Se este campo não for especificado, pode usar qualquer chave, com a exceção das chaves RSA cujo tamanho do módulo seja inferior a 2048 bits. Se quiser usar uma chave RSA com um tamanho do módulo inferior a 2048 bits, tem de a permitir explicitamente através da política de emissão de certificados.

Exemplo: permitir chaves RSA com um tamanho de módulo entre 3072 bits e 4096 bits (inclusive) ou chaves do algoritmo de assinatura digital de curvas elípticas (ECDSA) sobre a curva NIST P-256.

allowedKeyTypes:
-   rsa:
  minModulusSize: 3072
  maxModulusSize: 4096
-   ellipticCurve:
      signatureAlgorithm: ECDSA_P256

Pode escolher um dos seguintes algoritmos de assinatura de curva elíptica:

• EC_SIGNATURE_ALGORITHM_UNSPECIFIED - Pode ser usado qualquer algoritmo de assinatura.
• ECDSA_P256 - Assinatura digital de curva elíptica sobre a curva NIST P-256.
• ECDSA_P384 - Assinatura digital de curva elíptica sobre a curva NIST P-384.
• EDDSA_25519 - Algoritmo de assinatura digital de curva de Edwards sobre a curva 25519, conforme descrito no RFC 8410.

O que se segue?

• Saiba mais acerca dos perfis de certificados.
• Saiba como pedir certificados.
• Saiba como configurar políticas do IAM.
• Saiba como usar o Idioma de expressão comum (IEC).
• Saiba como gerir vários controlos de políticas.