Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

Usar mTLS de front-end com o Secure Web Proxy

É possível configurar o mTLS de front-end no Secure Web Proxy para melhorar a segurança das cargas de trabalho, como agentes de IA. O Secure Web Proxy usa o mTLS de front-end para verificar as identidades do cliente por meio de certificados.

Essa integração permite usar identidades de cliente validadas em políticas de autorização do Secure Web Proxy para aplicar o controle de acesso granular ao tráfego de saída.

Como funciona

As etapas a seguir explicam como o Secure Web Proxy usa o mTLS de front-end para proteger o tráfego de saída:

Conexão de proxy explícita: é possível configurar o cliente para usar o Secure Web Proxy como proxy explícito. O cliente inicia uma solicitação HTTPS CONNECT para o front-end do Secure Web Proxy, em vez de se conectar diretamente à Internet.
Handshake de TLS mútuo: durante a configuração da conexão, o Secure Web Proxy e o cliente realizam um handshake de mTLS no front-end do proxy. O proxy usa um recurso TrustConfig configurado para validar o certificado do cliente, enquanto o cliente valida o certificado do servidor do proxy.
Extração de identidade: após um handshake bem-sucedido, o Secure Web Proxy extrai atributos de identidade exclusivos, como URI_SAN, diretamente do certificado do cliente validado.
Autorização baseada em identidade: o Secure Web Proxy avalia a solicitação de saída em relação às políticas de autorização configuradas. Para determinar se a solicitação está autorizada, o proxy usa a identidade do cliente, que foi verificada criptograficamente durante o handshake de mTLS.
Tráfego de saída seguro: depois de autorizado e se houver uma regra correspondente para um destino externo, o Secure Web Proxy atenderá à solicitação para o destino.

Principais benefícios

A configuração do mTLS de front-end no Secure Web Proxy oferece os seguintes benefícios operacionais e de segurança:

Segurança aprimorada: alcance o acesso de confiança zero exigindo a autenticação mTLS de front-end para todo o tráfego de saída. Isso garante que apenas cargas de trabalho com uma identidade verificada possam estabelecer uma conexão com o proxy para acessar serviços externos.
Configuração simplificada da carga de trabalho: use o modo de roteamento de proxy explícito para o Secure Web Proxy para aproveitar a capacidade do proxy de interceptar e autenticar solicitações.
Controle granular: aplique políticas detalhadas e com reconhecimento de identidade para determinar a quais serviços externos cada carga de trabalho específica pode acessar.

Exemplo de caso de uso: validar a identidade das cargas de trabalho

Em setores regulamentados e com muita conformidade, como o bancário, verificar o local da rede de uma solicitação não é suficiente para evitar o acesso não autorizado a dados. Ao configurar o mTLS de front-end no Secure Web Proxy, as organizações podem migrar para um modelo de identidade criptograficamente verificado. Isso garante que cada carga de trabalho, seja uma instância de máquina virtual (VM) ou um agente de IA, precise comprovar sua identidade específica usando um certificado confiável.

Essa abordagem permite que os administradores apliquem barreiras de proteção baseadas em identidade que protegem caminhos de saída sensíveis. Por exemplo, um banco pode garantir que apenas uma carga de trabalho de processamento de pagamentos autenticada específica possa acessar um gateway financeiro externo.

Configurar a autenticação mTLS de front-end para o Secure Web Proxy

Esta seção descreve as etapas para configurar a autenticação mTLS de front-end para a instância do Secure Web Proxy.

Antes de começar

Consulte a página Gerenciar configurações de confiança.
Instale o Google Cloud CLI
Ative as APIs necessárias
Peça ao administrador do Identity and Access Management para conceder a você os seguintes papéis:
- Proprietário do Certificate Manager role (roles/certificatemanager.owner)
- Administrador de rede do Compute role (roles/compute.networkAdmin)
- Papel de Administrador de segurança do Compute (roles/compute.securityAdmin)
- Administrador de segurança de rede papel (roles/networksecurity.admin)
É necessário ter uma instância do Secure Web Proxy implantada no modo de roteamento de proxy explícito.

Criar os certificados raiz e intermediários

Esta seção mostra como usar OpenSSL para gerar um certificado de autoridade certificadora raiz (a âncora de confiança) e um certificado de CA intermediário opcional. O Secure Web Proxy usa esses certificados para verificar os certificados de cliente que as cargas de trabalho apresentam durante o processo de handshake de mTLS de front-end. Esse processo manual é destinado a ambientes de teste e desenvolvimento para fornecer a âncora de confiança que o Secure Web Proxy precisa para verificar os certificados do cliente.

Um certificado raiz reside na parte de cima da cadeia de certificados, enquanto um certificado intermediário atua como uma ponte na cadeia de confiança de volta à raiz. O certificado intermediário é assinado criptograficamente pelo certificado raiz. Quando o Secure Web Proxy recebe um certificado de cliente, ele valida a identidade estabelecendo uma cadeia de confiança do certificado do cliente de volta à âncora de confiança configurada.

Use os comandos a seguir para criar os certificados raiz e intermediários. Embora o certificado intermediário seja opcional, essa configuração o usa para assinar o certificado do cliente para mostrar uma hierarquia de certificados de várias camadas.

Crie um arquivo de configuração OpenSSL.

cat > example.cnf << EOF
[req]
distinguished_name = empty_distinguished_name

[empty_distinguished_name]
# Kept empty to allow setting via -subj command-line argument.

[ca_exts]
basicConstraints=critical,CA:TRUE
keyUsage=keyCertSign
extendedKeyUsage=clientAuth
EOF

Crie um certificado raiz X.509 autoassinado (root.cert) e uma chave privada (root.key).

openssl req -x509 \
    -new -sha256 -newkey rsa:2048 -nodes \
    -days 3650 -subj '/CN=root' \
    -config example.cnf \
    -extensions ca_exts \
    -keyout root.key -out root.cert

Crie a solicitação de assinatura de certificado (int.req) para o certificado intermediário.

openssl req -new \
    -sha256 -newkey rsa:2048 -nodes \
    -subj '/CN=int' \
    -config example.cnf \
    -extensions ca_exts \
    -keyout int.key -out int.req

Assine a solicitação de assinatura de certificado (CSR, na sigla em inglês) para criar o certificado intermediário X.509 (int.cert).

openssl x509 -req \
    -CAkey root.key -CA root.cert \
    -set_serial 1 \
    -days 3650 \
    -extfile example.cnf \
    -extensions ca_exts \
    -in int.req -out int.cert

Criar um certificado de cliente para teste

Crie um certificado de folha e uma chave privada para a carga de trabalho do cliente de teste. Durante o processo de handshake de mTLS com a instância do Secure Web Proxy, o cliente fornece esse certificado de folha para comprovar a identidade.

O exemplo a seguir usa o OpenSSL para gerar uma chave de cliente e uma CSR e, em seguida, assina a CSR com a chave de AC intermediária que você criou na seção Criar os certificados raiz e intermediários.

Execute o seguinte OpenSSL comando para gerar uma chave privada RSA chamada client.key:
```
openssl genpkey -algorithm RSA -out client.key
```

Crie um arquivo de configuração chamado client.cnf que especifica um nome DNS para o nome alternativo do assunto (SAN, na sigla em inglês). Isso ajuda a garantir que o certificado seja compatível com os requisitos de segurança modernos.

cat > client.cnf << EOF
[req]
distinguished_name = req_distinguished_name
req_extensions = v3_req
prompt = no

[req_distinguished_name]
CN = my-client.example.com

[v3_req]
keyUsage = critical, digitalSignature, keyEncipherment
extendedKeyUsage = clientAuth
subjectAltName = @alt_names

[alt_names]
DNS.1 = my-client.example.com

EOF

É possível modificar os valores CN e DNS.1 conforme necessário para testes.

Execute o comando de solicitação do OpenSSL usando a chave privada e o arquivo de configuração criados para gerar um arquivo client.req.
```
openssl req -new -key client.key -out client.req -config client.cnf
```
Use o comando x509 do OpenSSL para assinar a solicitação usando o certificado intermediário (int.cert) e a chave (int.key). Defina um período de validade, como 365 dias, e verifique se as extensões do arquivo de configuração foram aplicadas ao arquivo client.cert gerado.
```
openssl x509 -req -in client.req -CA int.cert -CAkey int.key \
  -set_serial 02 -days 365 -out client.cert \
  -extfile client.cnf -extensions v3_req
```
Esse processo cria o arquivo client.cert. Registre o valor usado no SAN DNS (por exemplo, my-client.example.com) como a identidade do cliente. É possível usar esse valor para identificar a carga de trabalho ao criar as políticas de autorização do Secure Web Proxy.

Formatar os certificados

Formate os certificados raiz e intermediários em variáveis de ambiente a serem usadas no arquivo trust_config.yaml.

  export ROOT_CERT=$(cat root.cert | sed 's/^[ ]*//g' | tr '\n' $ | sed 's/\$/\\n/g')
  export INTERMEDIATE_CERT=$(cat int.cert | sed 's/^[ ]*//g' | tr '\n' $ | sed 's/\$/\\n/g')

Criar um recurso de configuração de confiança

Uma configuração de confiança representa sua infraestrutura de chave pública (ICP) no Certificate Manager. A configuração de confiança indica à instância do Secure Web Proxy quais certificados de autoridade de certificação (AC) confiar ao verificar os certificados de cliente apresentados durante um handshake de mTLS de front-end.

Esse recurso de configuração de confiança de amostra contém um repositório de confiança com um único repositório de confiança com uma âncora de confiança (AC raiz) e uma AC intermediária. Ele usa o conteúdo do certificado das variáveis de ambiente criadas em a seção anterior Formatar os certificados.

Crie um arquivo trust_config.yaml.

cat << EOF > trust_config.yaml
trustStores:
  TRUST_CONFIG_NAME:
    trustAnchors:
      - pemCertificate: |
        -----BEGIN CERTIFICATE-----
        <certificate content>
        -----END CERTIFICATE-----
    intermediateCAs:
      - pemCertificate: |
        -----BEGIN CERTIFICATE-----
        <certificate content>
        -----END CERTIFICATE-----

EOF

Substitua TRUST_CONFIG_NAME pelo nome do recurso de configuração de confiança.

Importe o arquivo trust config.yaml usando o gcloud certificate-manager trust-configs import comando.
```
gcloud certificate-manager trust-configs import TRUST_CONFIG_NAME\
  --source=trust_config.yaml \
  --location=LOCATION
```
Substitua:
- TRUST_CONFIG_NAME: nome do recurso de configuração de confiança
- LOCATION: região em que o recurso de configuração de confiança está armazenado

Criar um recurso `ServerTlsPolicy`

Um recurso ServerTlsPolicy, também conhecido como recurso de autenticação do cliente, define como o Secure Web Proxy valida os certificados do cliente. Ele permite especificar o modo TLS do lado do servidor e o recurso de configuração de confiança para verificação de certificado.

O atributo clientValidationMode determina como a conexão é processada quando um cliente fornece um certificado inválido ou nenhum certificado. Para mais informações, consulte Modos de validação de cliente mTLS de front-end.

Os valores do atributo clientValidationMode são os seguintes:

REJECT_INVALID: o Secure Web Proxy permite apenas as conexões de clientes que apresentam um certificado válido assinado por uma AC na configuração de confiança. Conexões com certificados inválidos ou ausentes são rejeitadas.
ALLOW_INVALID_OR_MISSING_CLIENT_CERT: o Secure Web Proxy permite a solicitação de conexão mesmo que o certificado do cliente seja inválido, não possa ser validado na configuração de confiança ou esteja ausente.

Observação: se você selecionar esse modo, a instância do Secure Web Proxy vai extrair o SPIFFE_ID e outros atributos de certificado se um certificado válido for fornecido. No entanto, se o certificado for inválido ou estiver ausente, esses atributos de identidade específicos não estarão disponíveis. Ainda é possível criar políticas de autorização com base na presença de um certificado ou na impressão digital dele.

Para criar um recurso ServerTlsPolicy, siga estas etapas:

Crie um arquivo server_tls_policy.yaml. Escolha uma das seguintes opções para clientValidationMode:
- Opção 1: ALLOW_INVALID_OR_MISSING_CLIENT_CERT
```
name: SERVER_TLS_POLICY_NAME
mtlsPolicy:
  clientValidationMode: ALLOW_INVALID_OR_MISSING_CLIENT_CERT
  clientValidationTrustConfig: projects/PROJECT_ID/locations/LOCATION/trustConfigs/TRUST_CONFIG_NAME
```
- Opção 2: REJECT_INVALID
```
name: SERVER_TLS_POLICY_NAME
mtlsPolicy:
  clientValidationMode: REJECT_INVALID
  clientValidationTrustConfig: projects/PROJECT_ID/locations/LOCATION/trustConfigs/TRUST_CONFIG_NAME
```
Substitua:
- SERVER_TLS_POLICY_NAME: nome do recurso ServerTlsPolicy
- PROJECT_ID: ID do Google Cloud projeto
- TRUST_CONFIG_NAME: nome do recurso de configuração de confiança
- LOCATION: região em que a instância do Secure Web Proxy está configurada
Importe o recurso ServerTlsPolicy usando o gcloud network-security server-tls-policies import comando.
```
gcloud network-security server-tls-policies import SERVER_TLS_POLICY_NAME\
  --source=server_tls_policy.yaml \
  --location=LOCATION
```
Substitua:
- SERVER_TLS_POLICY_NAME: nome do recurso ServerTlsPolicy
- LOCATION: região em que a instância do Secure Web Proxy está configurada
Opcional: para listar todos os recursos ServerTlsPolicies, use o gcloud network-security server-tls-policies list comando.
```
gcloud network-security server-tls-policies list \
  --location=LOCATION
```
Substitua LOCATION pela região em que a instância do Secure Web Proxy está configurada.

Associar o recurso `ServerTlsPolicy` à instância do Secure Web Proxy

Anexe o recurso ServerTlsPolicy ao arquivo gateway.yaml da instância do Secure Web Proxy.
```
echo "serverTlsPolicy:
//networksecurity.googleapis.com/projects/PROJECT_ID/locations/
LOCATION/serverTlsPolicies/SERVER_TLS_POLICY_NAME"
>> gateway.yaml
```
Substitua:
- PROJECT_ID: ID do Google Cloud projeto
- LOCATION: região em que a instância do Secure Web Proxy está configurada
Importe a configuração da instância do Secure Web Proxy do gateway.yaml arquivo usando o gcloud network-services gateways import comando.
```
gcloud network-services gateways import GATEWAY_NAME\
    --source=gateway.yaml \
    --location=LOCATION
```
Substitua:
- GATEWAY_NAME: nome da instância do Secure Web Proxy
- LOCATION: região em que a instância do Secure Web Proxy está configurada

Configurar políticas de autorização

Para mais informações, consulte Configurar políticas de autorização para o Secure Web Proxy.

Logging

Para mais informações, consulte Tratamento de erros e registro de mTLS de front-end.

Limitações

O Secure Web Proxy oferece suporte à configuração do mTLS de front-end apenas no modo de roteamento de proxy explícito.
Para criar uma regra de segurança baseada em mTLS de front-end, use políticas de autorização para o Secure Web Proxy. As regras da política de segurança do gateway não são aceitas.

Para mais informações, consulte Limitações do mTLS de front-end.

A seguir

Implantar o Secure Web Proxy como um serviço do Private Service Connect