Configuração do OCSP¶

Este tópico fornece uma visão geral do OCSP e do seu uso no Snowflake, e informações para ajudar a diagnosticar problemas do OCSP.

Neste tópico:

Visão geral¶

O Snowflake usa o protocolo de status de certificados online (OCSP) para proporcionar segurança máxima ao determinar se um certificado está revogado quando os clientes do Snowflake tentam se conectar a um ponto de extremidade via HTTPS.

O Snowflake usa o OCSP para avaliar cada certificado da cadeia de confiança, até o certificado intermediário que a autoridade de certificação raiz (CA) emite. Garantir que os certificados não estão revogados ajuda o Snowflake a estabelecer conexões seguras com atores de confiança durante o processo de verificação de identidade.

Dependendo da versão do seu cliente ou driver e da configuração descrita nesta página, é possível desativar o OCSP e ajustar a ação que ocorre quando o OCSP determina que um certificado foi revogado.

Comportamento falha-abre ou falha-fecha¶

Atualmente, os usuários podem escolher entre dois comportamentos em termos de como os clientes ou drivers do Snowflake vão responder durante um evento OCSP.

Falha-abre
Falha-fecha

Falha-abre¶

Po padrão, o Snowflake oferece suporte à abordagem falha-abre em termos de avaliação da resposta OCSP CA. A abordagem falha-abre tem as seguintes características:

Uma resposta indicando um certificado revogado resulta em uma falha na conexão.

Uma resposta com qualquer outro erro ou status de certificado permite que a conexão ocorra, mas denota a mensagem nos logs no nível WARNING com os detalhes relevantes no formato JSON.

Os usuários podem monitorar os logs do driver ou do conector específico para determinar a freqüência de logs de eventos falha-abre.

Esses logs de eventos podem ser combinados com a página de status do Snowflake para determinar o melhor curso de ação, tal como restringir temporariamente o acesso do cliente ou mudar para o comportamento falha-fecha.

Atualmente, a abordagem padrão falha-abre se aplica às seguintes versões do cliente e do driver.

Cliente/Driver	Versão
SnowSQL	v1.1.79 ou posterior
Conector Python	v1.8.0 ou posterior
Driver JDBC	v3.8.0 ou posterior
Driver ODBC	v2.19.0 ou posterior
SQL Alchemy	Atualize o conector Python para a v1.8.0 ou posterior
Spark	v2.4.14 ou posterior se usar o Maven ou o SBT para criar o aplicativo Spark. . JDBC v3.8.0 ou posterior se anexar arquivos JAR ao cluster do Spark. . Solicite o Databricks para atualizar seu conector Spark se usar o conector Spark interno do Databricks.
Go Driver	v1.2.0 ou posterior
Node.js	v1.2.0 ou posterior

Nota

O Snowflake não oferece suporte à verificação OCSP para o driver .NET. Em vez disso, o .NET utiliza sua própria estrutura para verificar a validade do certificado HTTPS.

Falha-fecha¶

O comportamento falha-fecha é mais restritivo para interpretar a resposta OCSP da CA. Se o cliente ou o driver não receber uma resposta OCSP válida da CA por qualquer motivo, há falha na conexão.

Como esse comportamento não é padrão com base nas versões listadas na seção falha-abre, o falha-fecha deve ser configurado manualmente em cada driver ou conector.

Para preservar o comportamento falha-fecha, defina o parâmetro ocsp_fail_open correspondente como false.

Cliente/Driver	Configuração
SnowSQL	`snowsql -o ocsp_fail_open=false`
Conector Python	Para obter mais detalhes, consulte Escolha do modo falha-abre ou falha-fecha na documentação do conector Python.
Driver JDBC	Para obter mais detalhes, consulte Escolha do modo falha-abre ou falha-fecha na documentação do driver JDBC.
Driver ODBC	Escolha uma das seguintes opções: . Defina o parâmetro de conexão como `OCSP_FAIL_OPEN=false` . Use a variável de ambiente $SIMBAINI para localizar o arquivo correspondente. Em seguida, defina `OCSPFailOpen=false`
SQL Alchemy	Consulte as configurações do driver JDBC
Spark	O conector Spark não tem um parâmetro `ocsp_fail_open`. . O falha-fecha só pode ser preservado com o Spark se o driver JDBC for utilizado.
Go Driver	Escolha uma das seguintes opções: . - Defina o parâmetro de conexão `OCSPFailOpen` em Config como `ocspFailOpenTrue` ou `ocspFailOpenFalse`, por exemplo: . `import ( ... sf "github.com/snowflakedb/gosnowflake ... ")` . `config: &Config{ Account: "xy12345", ..., OCSPFailOpen: sf.ocspFailOpenFalse, ... }` . - Defina o parâmetro de conexão `ocspFailOpen` na cadeia de conexão como `true` ou `false`, por exemplo, . `user:pass@account/db/s?ocspFailOpen=false`. . Observe as diferenças entre maiúsculas e minúsculas. . Para obter mais informações sobre os parâmetros de conexão do Go, consulte a GoDoc documentação gosnowflake.
Node.js	Defina o parâmetro global `ocspFailOpen=false`. Para obter mais detalhes, consulte Referência de opções do Node.js.

Versões herdadas de clientes e drivers¶

Se a versão do seu cliente ou do seu driver for mais antiga do que a listada na seção falha-abre, o comportamento falha-abre não é uma opção. Portanto, o comportamento falha-fecha será o padrão.

As implantações do Snowflake usando versões herdadas de clientes e drivers têm três opções em relação ao OCSP:

Atualizar o cliente ou driver para a versão mais recente (melhor opção).
Continuar usando o comportamento falha-fecha.
Desativar o monitoramento do OCSP (ou seja, modo inseguro) como descrito neste artigo da base de conhecimento (na Comunidade Snowflake).

Práticas recomendadas¶

Para reduzir os riscos, o Snowflake recomenda as seguintes práticas para manter a segurança das comunicações.

Use a conectividade privada ao serviço Snowflake e bloqueie o acesso público ao Snowflake.
Permitir que os drivers dos clientes sejam executados apenas em desktops e servidores gerenciados.
Enviar os logs do driver do cliente para um sistema de gerenciamento ou fazer o upload para o Snowflake. Monitorar as conexões feitas sem a verificação OCSP.

Nota

Suporte à conectividade privada ao serviço Snowflake requer Business Critical (ou superior). Para se informar sobre a possibilidade de upgrade, entre em contato com o suporte Snowflake.

Site da CA e hosts respondentes OCSP usados pelo Snowflake (por plataforma de nuvem e região)¶

O Snowflake usa os seguintes hosts para verificações OCSP. Observe que os hosts podem diferir por região para uma dada plataforma de nuvem.

Importante

Estes são exemplos dos hosts mais comumente utilizados. Para cada região (ou conta individual), o Snowflake pode usar um certificado emitido por uma CA diferente, o que resulta em hosts e URLs diferentes. Por exemplo:

Para a maioria das contas no Oeste dos US (no AWS), o Snowflake usa atualmente certificados assinados pela Digicert da Network Solutions.
Para outras regiões (no AWS), o Snowflake utiliza principalmente certificados da CA da Amazon.

Além disso, o Snowflake pode mudar os certificados conforme eles expiram ou requerem aprimoramento, o que resultará em hosts e URLs diferentes.

Para obter uma lista completa de hosts e URLs para sua conta, entre em contato com o suporte Snowflake.

Snowflake no AWS¶

Host	Oeste dos US	Outras regiões	Notas
`ocsp.snowflakecomputing.com:80`	✔	✔	Servidor de cache de resposta OCSP do Snowflake. Observe que o nome do host é diferente se o AWS PrivateLink estiver habilitado.
`*.amazontrust.com:80`	✔	✔
`*.digicert.com:80`	✔	✔
`*.netsolssl.com:80`	✔
`*.ss2.us:80`	✔	✔
`*.usertrust.com:80`	✔

Snowflake no Microsoft Azure¶

Host	East US 2	Notas
`ocsp.snowflakecomputing.com:80`	✔	Servidor de cache de resposta OCSP do Snowflake. Observe que o nome do host é diferente se o Azure Private Link estiver habilitado.
`*.digicert.com:80`	✔
`*.msocsp.com:80`	✔

Snowflake na Google Cloud Platform¶

Host	us-central1	Notas
`ocsp.snowflakecomputing.com:80`	✔	Servidor de cache de resposta OCSP do Snowflake.
`ocsp.digicert.com:80`	✔
`ocsp.pki.goog:80`	✔

As verificações de certificação OCSP requerem a porta 80¶

Todas as comunicações com o Snowflake acontecem pela porta 443. No entanto, as verificações de certificação OCSP são transmitidas pela porta 80. Se sua estação de trabalho estiver protegida por um firewall, certifique-se de que o administrador de rede da sua organização tenha aberto o firewall para o tráfego nas portas 443 e 80.

Os drivers JDBC e ODBC não usam mais a CRL¶

A CRL (lista de revogação de certificado) especifica os certificados que foram explicitamente revogados por determinada CA. As versões mais antigas dos drivers JDBC e ODBC usavam a CRL ou o OCSP para verificar os certificados TLS. A partir das versões a seguir, os drivers passaram a usar apenas o OCSP para todas as verificações:

JDBC 3.5.0 (ou superior).
ODBC 2.15.0 (ou superior)