Nota
O acesso a esta página requer autorização. Podes tentar iniciar sessão ou mudar de diretório.
O acesso a esta página requer autorização. Podes tentar mudar de diretório.
Aplica-se a: SQL Server 2019 (15.x) e versões posteriores no Windows
Azure SQL Database
Este artigo descreve como identificar e resolver problemas comuns que pode encontrar ao executar instruções Transact-SQL (TSQL) usando o Always Encrypted com enclaves seguros.
Para informações sobre como executar consultas usando enclaves seguros, veja Executar Transact-SQL instruções usando enclaves seguros.
Erros de ligação à base de dados
Para executar instruções usando um enclave seguro, é necessário ativar o Always Encrypted, especificar um protocolo de atestação e, se aplicável, um URL de atestação para a ligação à base de dados, conforme explicado em Pré-requisitos para executar instruções usando enclaves seguros. No entanto, a sua ligação falhará se especificar um protocolo de atestado, mas a sua base de dados Azure SQL ou a sua instância SQL Server de destino não suportarem enclaves seguros, ou estiverem configuradas incorretamente.
- Se estiveres a usar Azure SQL Database com enclaves Intel SGX, verifica se a tua base de dados usa a configuração de hardware da série DC . Para mais informações, consulte Ativar enclaves Intel SGX para a sua base de dados Azure SQL.
- Se estiveres a usar Azure SQL Database com enclaves VBS, verifica se a propriedade preferredEnclaveType está definida como VBS. Para mais informações, consulte Ativar VBS Enclaves para a sua base de dados Azure SQL.
- Se estiveres a usar SQL Server 2019 (15.x) ou posterior, verifica se o Secure Enclave está corretamente configurado para a tua instância. Para mais informações, consulte Configurar o enclave seguro no SQL Server.
Erros de atestação ao utilizar o Microsoft Azure Attestation
Observação
Esta secção aplica-se apenas a Azure SQL Database com enclaves Intel SGX.
Antes de um driver cliente submeter uma instrução T-SQL ao servidor lógico Azure SQL para execução, o driver desencadeia o seguinte fluxo de trabalho de atestação enclave usando o Microsoft Azure Attestation.
- O driver cliente passa a URL de atestado, especificada na ligação à base de dados, ao servidor lógico Azure SQL.
- O servidor lógico Azure SQL recolhe as evidências sobre o enclave, o seu ambiente de alojamento e o código a correr dentro do enclave. O servidor envia então um pedido de atestação ao fornecedor de atestado, referenciado na URL de atestado.
- O fornecedor de atestação valida as evidências contra a política configurada e emite um token de atestação para o servidor lógico Azure SQL. O fornecedor de atestação assina o token de atestação com a sua chave privada.
- O servidor lógico Azure SQL envia o token de atestação para o driver cliente.
- O cliente contacta o fornecedor de atestação na URL de atestação especificada para recuperar a sua chave pública e verifica a assinatura no token de atestado.
Erros podem ocorrer em várias etapas do fluxo de trabalho acima devido a configurações erradas. Aqui estão os erros comuns de atestado, as suas causas profundas e os passos recomendados para a resolução de problemas:
- O seu servidor lógico Azure SQL não consegue ligar-se ao fornecedor de atestação no Azure Attestation (passo 2 do fluxo de trabalho acima), especificado na URL de atestado. As causas prováveis incluem:
- O URL de atestação está incorreto ou incompleto. Para mais informações, consulte Determinar a URL de atestação para a sua política de atestação.
- O fornecedor de atestação foi apagado acidentalmente.
- O firewall foi configurado para o fornecedor de atestado, mas não permite o acesso aos serviços Microsoft.
- Um erro intermitente na rede faz com que o fornecedor de atestação fique indisponível.
- O seu servidor lógico Azure SQL não está autorizado a enviar pedidos de atestação ao fornecedor de atestado. Certifique-se de que o administrador do seu fornecedor de atestação adicionou o servidor de base de dados ao papel de Leitor de Atestado.
- A validação da política de atestação falha (no passo 3 do fluxo de trabalho acima).
- Uma política de atestação incorreta é a causa raiz provável. Certifica-te de que estás a usar a política recomendada pela Microsoft. Para obter mais informações, veja Criar e configurar um fornecedor de atestado.
- A validação da política também pode falhar devido a uma violação de segurança que comprometa o enclave do lado do servidor.
- A sua aplicação cliente não consegue ligar-se ao fornecedor de atestação e recuperar a chave pública de assinatura (no passo 5). As causas prováveis incluem:
- A configuração dos firewalls entre a sua aplicação e o fornecedor de atestação pode bloquear as ligações. Para diagnosticar a ligação bloqueada, verifique se consegue ligar-se ao endpoint OpenId do seu fornecedor de atestado. Por exemplo, use um navegador web a partir da máquina que hospeda a sua aplicação para ver se consegue ligar-se ao endpoint OpenID. Para mais informações, consulte Configuração de Metadados - Obtenha.
Erros de atestação ao utilizar o Serviço Host Guardian
Observação
Esta secção aplica-se apenas ao SQL Server 2019 (15.x) e posteriores.
Antes de um driver cliente submeter uma instrução T-SQL ao SQL Server para execução, o driver desencadeia o seguinte fluxo de trabalho de atestação do enclave usando o Host Guardian Service (HGS).
- O driver do cliente chama o SQL Server para iniciar a atestado.
- O SQL Server recolhe as evidências sobre o seu enclave, o seu ambiente de alojamento e o código a correr dentro do enclave. O SQL Server solicita um certificado de saúde à instância HGS, onde a máquina que aloja o SQL Server estava registada. Para mais informações, consulte Registar o computador com o Serviço Host Guardian.
- O HGS valida as evidências e emite o certificado de saúde para o SQL Server. A HGS assina o certificado de saúde com a sua chave privada.
- O SQL Server envia o certificado de saúde para o controlador cliente.
- O driver cliente contacta o HGS na URL de atestado, especificada para a ligação à base de dados, para recuperar a chave pública do HGS. O condutor cliente verifica a assinatura no certificado de saúde.
Podem ocorrer erros em várias etapas do fluxo de trabalho acima devido a configurações incorretas. Aqui estão alguns erros comuns de atestado, as suas causas principais e os passos recomendados para a resolução de problemas:
- O SQL Server não consegue ligar-se ao HGS (passo 2 do fluxo de trabalho acima), devido a um erro intermitente de rede. Para resolver o problema da ligação, o administrador do computador SQL Server deve verificar se o computador consegue ligar-se à máquina HGS.
- A validação no passo 3 falha. Para resolver o problema da validação:
- O administrador do computador do SQL Server deve trabalhar com o administrador da aplicação cliente para verificar se o computador SQL Server está registado com a mesma instância HGS que a instância referenciada na URL de atestação do lado do cliente.
- O administrador do computador do SQL Server deve confirmar que o computador SQL Server pode atestar com sucesso, seguindo as instruções do Passo 5: Confirme que o host pode atestar com sucesso.
- A sua aplicação cliente não consegue ligar-se ao HGS e recuperar a sua chave pública de assinatura (no passo 5). A causa provável é:
- A configuração de um dos firewalls entre a sua aplicação e o fornecedor de atestação pode bloquear as ligações. Verifica se a máquina que hospeda a tua aplicação consegue ligar-se à máquina HGS.
Erros de encriptação no local
Esta secção apresenta os erros comuns que pode encontrar durante o uso de ALTER TABLE/ALTER COLUMN em encriptação em local, além dos erros de atestação descritos nas secções anteriores. Para obter mais informações, consulte Configurar a criptografia de coluna no local usando Always Encrypted com enclaves seguros.
- A chave de encriptação das colunas que está a usar para encriptar, desencriptar ou voltar a encriptar dados não é uma chave compatível com enclave. Para mais informações sobre os pré-requisitos para encriptação no local, veja Pré-requisitos. Para informações sobre como provisionar chaves habilitadas pelo enclave, consulte Provisionar chaves habilitadas pelo enclave.
- Não ativaste o Always Encrypted nem os cálculos enclave para a ligação à base de dados. Veja Pré-requisitos para executar instruções usando enclaves seguros.
- A sua
ALTER TABLE/ALTER COLUMNinstrução desencadeia uma operação criptográfica e altera o tipo de dados da coluna ou define uma colação com uma página de códigos diferente da página de código de colação atual. Não é permitido combinar operações criptográficas com alterações no tipo de dados ou na página de colação. Para resolver o problema, use instruções separadas; uma instrução para alterar o tipo de dados ou a página de código de colação e outra para encriptação no local.
Erros ao executar consultas DML confidenciais usando enclaves seguros
Esta secção lista erros comuns que pode encontrar ao executar consultas DML confidenciais usando enclaves seguros (para além dos erros de atestação descritos nas secções anteriores).
- A chave de encriptação da coluna configurada para a coluna que está a consultar não é uma chave habilitada pelo enclave.
- Não ativaste o Always Encrypted nem os cálculos enclave para a ligação à base de dados. Para mais informações, consulte Pré-requisitos para executar instruções usando enclaves seguros.
- A coluna que estás a consultar usa encriptação determinística. Consultas DML confidenciais usando enclaves seguros não são suportadas com encriptação determinística. Para mais informações sobre como alterar o tipo de encriptação para randomizado, veja Permitir Sempre Encriptado com enclaves seguros para colunas encriptadas existentes.
- A coluna de string que estás a consultar utiliza uma colação que não é do tipo BIN2 nem do tipo UTF-8. Muda a colação para BIN2 ou UTF-8. Para mais informações, consulte instruções DML usando enclaves seguros.
- A sua consulta desencadeia uma operação não suportada. Para a lista de operações suportadas dentro dos enclaves, veja instruções DML usando enclaves seguros.