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.

Hosts do site CA e respondente OCSP usados pelo Snowflake¶

Você pode chamar a função SYSTEM$ALLOWLIST ou SYSTEM$ALLOWLIST_PRIVATELINK em sua conta Snowflake para obter os hosts que o Snowflake usa para verificações OCSP. Os valores de host são exclusivos para a plataforma de nuvem e a região onde sua conta Snowflake existe. As razões para os diferentes valores de host são baseadas em CA que a plataforma de nuvem usa e quando os certificados são atualizados ou renovados.

Por exemplo:

SELECT t.VALUE:type::VARCHAR as type,
  t.VALUE:host::VARCHAR as host,
  t.VALUE:port as port
FROM TABLE(FLATTEN(input => PARSE_JSON(SYSTEM$ALLOWLIST_PRIVATELINK()))) AS t
WHERE type ILIKE ANY ('OCSP%');

Copy

+-----------------------+---------------------------------------------------------------+------+
| TYPE                  | HOST                                                          | PORT |
|-----------------------+---------------------------------------------------------------+------|
| OCSP_CACHE            | ocsp.account1234.us-west-2.privatelink.snowflakecomputing.com | 80   |
| OCSP_CACHE_REGIONLESS | ocsp.my_org-my_account.privatelink.snowflakecomputing.com     | 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)