Adicionando suporte mTLS a Implantações de API
Descubra como usar uma política de solicitação para adicionar suporte a mTLS a implantações de API com o Gateway de API.
Os gateways de API criados com o serviço API Gateway são protegidos por meio da criptografia e verificação TLS. Um gateway de API apresenta um certificado de servidor para um cliente de API durante um handshake TLS, permitindo que o cliente de API valide a autenticidade do gateway de API. O processo do cliente de API que autentica o gateway de API é conhecido como TLS unidirecional.
Em muitas situações, você só deseja permitir que clientes de API autenticados acessem uma API. Nessas situações, você deseja que o gateway de API valide a autenticidade de um cliente de API, verificando o certificado TLS apresentado pelo cliente de API. O processo do gateway de API que autentica o cliente de API é conhecido como mTLS (TLS mútuo).
Com mTLS, o gateway de API e o cliente de API trocam e verificam certificados durante o handshake de TLS. O gateway de API verifica o certificado TLS apresentado pelo cliente de API usando certificados raiz da Autoridade de Certificação (CA) personalizados e pacotes de CA personalizados de certificados raiz e intermediários. As CAs personalizadas e os pacotes de CAs são armazenados no armazenamento confiável do gateway de API, juntamente com um pacote de CAs padrão que contém certificados de CAs públicas conhecidas. Observe que, em um handshake mTLS, o gateway de API só usa CAs personalizadas e pacotes de CA personalizados para verificar certificados de cliente de API. O gateway de API não usa o bundle de CAs padrão para verificar certificados de cliente de API. Portanto, se você quiser que um gateway de API suporte mTLS, adicione CAs e pacotes de CA personalizados ao armazenamento confiável do gateway de API (consulte Personalizando Armazenamentos Confiáveis para Verificação de Certificado TLS).
Para controle extra, você também pode especificar que os certificados apresentados por clientes de API a um gateway de API devem conter valores específicos nos campos Endereço de E-mail, URL ou Nome de Domínio do certificado. Se você especificar valores para esses campos ao configurar o mTLS para um gateway de API, o gateway de API rejeitará solicitações de clientes de API que apresentem certificados que não os contenham. Se você não especificar valores para esses campos ao configurar o mTLS, o gateway de API aceitará todas as solicitações dos clientes de API, desde que o certificado seja válido. Você pode especificar até 10 valores para cada implantação de API por padrão (você pode alterar esse limite interno).
Após um handshake mTLS bem-sucedido entre o gateway de API e um cliente de API, uma versão codificada por Base64 do certificado apresentado pelo cliente de API é salva na tabela de contexto request.cert
como uma variável de contexto chamada request.cert[client_base64]
. Ao definir uma implantação de API, você pode fazer referência ao certificado usando o formato ${request.cert[client_base64]}
(consulte Adicionando Variáveis de Contexto a Políticas e Definições de Backend HTTP). Observe que, se um cliente de API apresentar um certificado TLS com tamanho superior a 8 KB (depois de codificado em Base64), o certificado não será salvo como variável de contexto.
Você usa uma política de solicitação na especificação de implantação de API para adicionar suporte mTLS a uma API (consulte Adicionando Políticas de Solicitação e Políticas de Resposta a Especificações de Implantação de API). A política de solicitação mTLS se aplica globalmente a todas as rotas em uma especificação de implantação de API.
- Se um cliente de API apresentar um certificado TLS a um gateway de API e a implantação de API não estiver ativada para mTLS, o gateway de API simplesmente ignorará o certificado TLS apresentado. A variável de contexto
request.cert[client_base64]
não está definida nesta situação. - Se um gateway de API não puder validar o certificado TLS apresentado por um cliente de API, o gateway de API rejeitará a solicitação com um código de resposta de status de erro HTTP 401.
- Se um gateway de API usar um pacote de CAs personalizado para validar o certificado TLS apresentado por um cliente de API, não será possível percorrer mais de três certificados de CAs em nenhum ponto da cadeia de certificados durante a validação. Em outras palavras, para ser válido, um certificado de CA na cadeia deve ser assinado diretamente por uma CA personalizada presente no armazenamento confiável do gateway de API ou estar a não mais que dois certificados intermediários de um certificado que tenha sido assinado por essa CA personalizada. Entre em contato conosco se quiser permitir mais certificados intermediários.
Você pode adicionar uma política de solicitação mTLS a uma especificação de implantação de API:
- usando a Console
- editando um arquivo JSON
Usando a Console para Adicionar Políticas de Solicitação mTLS
Para adicionar uma política de solicitação mTLS a uma especificação de implantação de API usando a Console:
-
Crie ou atualize uma implantação de API usando a Console. Selecione a opção Totalmente Nova e insira os detalhes na página Informações Básicas.
Para obter mais informações, consulte Implantando uma API em um Gateway de API por meio da Criação de uma Implantação de API e Atualizando um Gateway de API.
-
Na seção Políticas de Solicitação de API da página Informações Básicas, em TLS Mútuo, selecione a opção Ativar mTLs e especifique opcionalmente:
- Nome Alternativo do Assunto (SAN) / Nome Comum: Valores que devem aparecer em um ou mais dos seguintes campos do certificado apresentado pelo cliente de API para que o gateway de API aceite solicitações do cliente:
- Endereço de E-mail
- URL
- Nome do Domínio
Por exemplo,
example.com
. Você pode especificar até 10 valores por padrão (você pode alterar esse limite interno). A validação não faz distinção entre maiúsculas e minúsculas.Você pode incluir um curinga asterisco (*) no início e/ou no final de cada valor para representar zero, um ou mais caracteres. Não é possível incluir um curinga de asterisco no meio do valor. Por exemplo:
*.example.com
corresponde aserver.example.com
server.example.*
corresponde aserver.example.com
*.example.*
corresponde aserver.example.com
server.*.com
não corresponde aserver.example.com
porque o curinga não pode estar no meio do valor
Se você especificar valores ao configurar mTLS para uma implantação de API, o gateway de API rejeitará solicitações de clientes de API que apresentem certificados que não os contenham. Se você não especificar valores ao configurar mTLS, o gateway de API aceitará todas as solicitações de clientes de API que fornecem o certificado será válido.
- Nome Alternativo do Assunto (SAN) / Nome Comum: Valores que devem aparecer em um ou mais dos seguintes campos do certificado apresentado pelo cliente de API para que o gateway de API aceite solicitações do cliente:
- Selecione Revisar para revisar os detalhes informados para a implantação de API.
- Selecione Criar ou Salvar Alterações para criar ou atualizar a implantação de API.
- (Opcional) Confirme se a API foi implantada com êxito, chamando-a (consulte Chamando uma API Implantada em um Gateway de API).
Editando um Arquivo JSON para Adicionar Políticas de Solicitação mTLS
Para adicionar uma política de solicitação mTLS a uma especificação de implantação de API em um arquivo JSON:
-
Usando seu editor JSON preferido, edite a especificação de implantação de API existente à qual você deseja adicionar suporte mTLS ou crie uma nova especificação de implantação de API (consulte Criando uma Especificação de Implantação de API).
Por exemplo, a seguinte especificação básica de implantação de API define uma função simples sem servidor Hello World no OCI Functions como um único back-end:
{ "routes": [ { "path": "/hello", "methods": ["GET"], "backend": { "type": "ORACLE_FUNCTIONS_BACKEND", "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq" } } ] }
-
Para especificar uma política de solicitação mTLS que se aplique globalmente a todas as rotas em uma implantação de API:
-
Insira uma seção
requestPolicies
antes da seçãoroutes
, se ainda não existir uma. Por exemplo:{ "requestPolicies": {}, "routes": [ { "path": "/hello", "methods": ["GET"], "backend": { "type": "ORACLE_FUNCTIONS_BACKEND", "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq" } } ] }
-
Adicione a seguinte política
mutualTLS
à nova seçãorequestPolicies
para aplicar globalmente a todas as rotas em uma implantação de API:{ "requestPolicies": { "mutualTls":{ "isVerifiedCertificateRequired": true|false, "allowedSans": [<list-of-values>] } }, "routes": [ { "path": "/hello", "methods": ["GET"], "backend": { "type": "ORACLE_FUNCTIONS_BACKEND", "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq" } } ] }
em que:
"isVerifiedCertificateRequired": true|false
, étrue
oufalse
, indicando se o mTLS está ativado para a implantação de API. Se não for especificado, o valor padrão seráfalse
."allowedSans": [<list-of-values>]
é uma lista opcional de valores separados por vírgulas que deve aparecer em um ou mais dos seguintes campos do certificado apresentado pelo cliente de API para que o gateway de API aceite solicitações do cliente:- Endereço de E-mail
- URL
- Nome do Domínio
Por exemplo,
example.com
. Você pode especificar até 10 valores por padrão (você pode alterar esse limite interno). A validação não faz distinção entre maiúsculas e minúsculas.Você pode incluir um curinga asterisco (*) no início e/ou no final de cada valor para representar zero, um ou mais caracteres. Não é possível incluir um curinga de asterisco no meio do valor. Por exemplo:
*.example.com
corresponde aserver.example.com
server.example.*
corresponde aserver.example.com
*.example.*
corresponde aserver.example.com
server.*.com
não corresponde aserver.example.com
porque o curinga não pode estar no meio do valor
Se você especificar valores ao configurar mTLS para uma implantação de API, o gateway de API rejeitará solicitações de clientes de API que apresentem certificados que não os contenham. Se você não especificar valores ao configurar mTLS, o gateway de API aceitará todas as solicitações de clientes de API que fornecem o certificado será válido.
Por exemplo:
{ "requestPolicies": { "mutualTls":{ "isVerifiedCertificateRequired": true, "allowedSans": [ "example.com", "example.co.uk" ] } }, "routes": [ { "path": "/hello", "methods": ["GET"], "backend": { "type": "ORACLE_FUNCTIONS_BACKEND", "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq" } } ] }
-
- Salve o arquivo JSON que contém a especificação de implantação de API.
-
Use a especificação de implantação de API ao criar ou atualizar uma implantação de API das seguintes formas:
- especificando o arquivo JSON na Console quando você selecionar a opção Carregar uma API existente
- especificando o arquivo JSON em uma solicitação à API REST do serviço API Gateway
Para obter mais informações, consulte Implantando uma API em um Gateway de API por meio da Criação de uma Implantação de API e Atualizando um Gateway de API.
- (Opcional) Confirme se a API foi implantada com êxito, chamando-a (consulte Chamando uma API Implantada em um Gateway de API).