Implementar controles de conformidade para dados confidenciais

Concluído

Implementar controles de conformidade após a migração do banco de dados é importante para garantir que seus dados permaneçam seguros e em conformidade com os regulamentos relevantes. A migração para um novo ambiente, como o SQL do Azure, apresenta novos recursos e recursos de segurança.

Explorar auditoria de servidor e banco de dados

A auditoria SQL do Azure rastreia eventos de banco de dados, registrando-os em um log de auditoria armazenado em sua conta de Armazenamento do Microsoft Azure, no espaço de trabalho do Log Analytics ou nos Hubs de Eventos. Além disso, facilita a manutenção da conformidade regulatória, a análise de padrões de atividade e a detecção de desvios que podem indicar violações de segurança.

Você pode definir políticas no nível do servidor e no nível do banco de dados. As políticas de servidor abrangem automaticamente bancos de dados novos e existentes no Azure.

  • Habilitar a auditoria de servidor dispara a auditoria para o banco de dados, independentemente de suas configurações de auditoria individuais.
  • Você pode habilitar a auditoria no nível do banco de dados, permitindo que as políticas de servidor e banco de dados coexistam simultaneamente.
  • A auditoria em réplicas somente leitura é habilitada automaticamente.

É melhor não habilitar a auditoria de servidor e a auditoria de banco de dados juntas, exceto nos cenários a seguir.

  • Você precisa de uma conta de armazenamento distinta, um período de retenção ou um workspace do Log Analytics para um banco de dados específico.

  • Uma auditoria é necessária para um banco de dados específico com tipos de eventos exclusivos ou categorias distintas das outras no servidor.

Em todos os outros casos, recomendamos que você habilite apenas a auditoria no nível do servidor e mantenha a auditoria no nível do banco de dados desabilitada para todos os bancos de dados.

A política de auditoria padrão para Banco de Dados SQL inclui o seguinte conjunto de grupos de ações:

Grupo de ações Definição
BATCH_COMPLETED_GROUP Faz a auditoria de todas as consultas e os procedimentos armazenados executados no banco de dados.
SUCCESSFUL_DATABASE_AUTHENTICATION_GROUP Isso indica que uma entidade de segurança consegue fazer logon no banco de dados.
SUCCESSFUL_DATABASE_AUTHENTICATION_GROUP Isso indica que uma entidade de segurança não consegue fazer logon no banco de dados.

Para habilitar a auditoria de todos os bancos de dados em um servidor SQL do Azure, selecione Auditoria na seção Segurança da folha principal do servidor.

Screenshot of auditing option in the Security section of a SQL server.

A página Auditoria permite que você defina o destino do log de auditoria e também escolha se deseja acompanhar as operações do engenheiro de suporte da Microsoft no mesmo destino de log que a Auditoria do SQL do Azure ou selecionar uma diferente.

Screenshot of the Auditing page of a SQL server.

Você pode examinar os logs de auditoria das operações de Suporte da Microsoft em seu workspace do Log Analytics executando a seguinte consulta:

AzureDiagnostics
| where Category == "DevOpsOperationsAudit"

Importante

Os serviços de auditoria do Banco de Dados SQL do Azure e da Instância Gerenciada de SQL do Azure foram ajustados para obter a disponibilidade e o desempenho ideais. No entanto, vale a pena observar que, sob condições de atividade excepcionalmente alta ou congestionamento de rede significativo, determinados eventos auditados podem não ser registrados.

Auditar rótulos confidenciais

Quando combinado com a classificação de dados, você também pode monitorar o acesso a dados confidenciais. A Auditoria do SQL do Azure foi aprimorada para incluir um novo campo no log de auditoria, chamado data_sensitivity_information.

Ao registrar os rótulos de confidencialidade dos dados retornados por uma consulta, esse campo fornecerá uma maneira mais fácil de controlar o acesso a colunas classificadas.

Screenshot of the Information Protection page from Azure portal.

A auditoria consiste em acompanhar e registrar eventos que ocorrem no mecanismo de banco de dados. A auditoria do SQL do Azure simplifica as etapas de configuração necessárias para habilitá-la, facilitando o controle das atividades do banco de dados para o Banco de Dados SQL e a Instância Gerenciada de SQL.

Mascaramento de dados dinâmicos

A Máscara Dinâmica de Dados funciona ofuscando os dados para limitar sua exposição. Ela permite que os usuários que não precisam de acesso a informações confidenciais vejam a coluna, mas não os dados reais. A Máscara Dinâmica de Dados funciona na camada de apresentação, e os dados não mascarados permanecem visíveis para usuários altamente privilegiados.

A Máscara Dinâmica de Dados oferece a vantagem de exigir modificação mínima em seu aplicativo ou banco de dados. Você pode configurá-la convenientemente por meio do portal do Azure ou usando T-SQL.

Screenshot of the dynamic data masking T-SQL commands.

As colunas PhoneNumber e EmailAddress estão ocultas do usuário DDMDemo, que só tem permissão SELECT na tabela. O usuário tem permissão para ver os últimos quatro dígitos do número de telefone, pois ele é mascarado com uma função parcial que substitui todos os últimos quatro dígitos da coluna. Este mascaramento é considerado uma função personalizada. Além do T-SQL, se você estiver usando o Banco de Dados SQL do Azure, poderá criar regras de mascaramento dinâmico no portal do Azure.

Screenshot of how to add masking rule in Azure portal.

Para adicionar uma regra de mascaramento, navegue até seu banco de dados no portal do Azure e selecione Máscara Dinâmica de Dados na seção Segurança da folha principal do seu banco de dados.

A Máscara Dinâmica de Dados dá suporte aos seguintes padrões de mascaramento que podem ser usados:

Função de mascaramento Definição Exemplo de T-SQL
Default Mascara os dados na coluna sem expor nenhuma parte dos valores para o usuário. O usuário verá XXXX para valores de cadeia de caracteres, 0 para números e 01.01.1900 para valores de data. ALTER TABLE [Customer] ALTER COLUMN Address ADD MASKED WITH (FUNCTION = 'default()')
Cartão de crédito Mascara todos, exceto os quatro últimos caracteres, permitindo que os usuários vejam os quatro dígitos finais. Esse mascaramento pode ser útil para agentes de atendimento ao cliente que precisam ver os últimos quatro dígitos de um número de cartão de crédito, mas que não precisam ver o número inteiro. Os dados são mostrados no formato habitual de um número de cartão de crédito XXXX-XXXX-XXXX-1234. ALTER TABLE [Customer] ALTER COLUMN Address ADD MASKED WITH (FUNCTION = 'partial(0,"XXXX-XXXX-XXXX-",4)')
Email Somente a primeira letra e o sufixo de domínio à direita não são mascarados; por exemplo, "aXXX@XXXXXXX.com" ALTER TABLE [Customer] ALTER COLUMN Email ADD MASKED WITH (FUNCTION = 'email()')
Número Esse formato de mascaramento deve ser usado em colunas numéricas. Ela mostra um número aleatório como o valor mascarado em vez do valor real. Com cada consulta, um número diferente é exibido. ALTER TABLE [Customer] ALTER COLUMN [Month] ADD MASKED WITH (FUNCTION = 'random(1, 12)')
Cadeia de caracteres personalizada Com essa opção, o texto é mascarado com qualquer valor e pode exibir um número personalizado de caracteres em qualquer extremidade do valor mascarado. Se o comprimento do valor que está sendo mascarado for igual ou inferior ao número de caracteres especificado pela máscara para ser exibido, somente os caracteres mascarados serão exibidos. ALTER TABLE [Customer] ALTER COLUMN [PhoneNumber] ADD MASKED WITH (FUNCTION = 'partial(1,"XXXXXXX",0)')

Para permitir que os usuários recuperem dados desmascarados das colunas para as quais o mascaramento está definido, você precisará conceder a permissão UNMASK explicitamente.

Observação

É possível identificar dados mascarados usando inferência com base nos resultados. Se você estiver usando o mascaramento de dados, também deverá limitar a capacidade do usuário de executar consultas locais.

Por esse motivo, recomendamos combinar o mascaramento de dados dinâmicos com outros recursos de segurança, como auditoria, criptografia e segurança em nível de linha para aprimorar a proteção de dados confidenciais.

Caso de uso

O mascaramento de dados é uma solução simples e leve, e é ideal para muitos cenários, incluindo:

  • Mascarar dados de usuários de aplicativos que não têm acesso direto ao banco de dados.

  • Restrição de informações privadas para um grupo de usuários.

  • Fornecer dados mascarados para fornecedores externos, nos quais você precisa proteger informações confidenciais, preservando ainda as relações entre os itens nos dados.

  • Exportar uma cópia do seu banco de dados de produção para um ambiente inferior para fins de desenvolvimento, usando um usuário sem permissão UNMASK. Os dados exportados estão em um formato mascarado.

Importe e exporte dados

Copiar dados de uma coluna mascarada para outra tabela usando SELECT INTO ou INSERT INTO resulta em dados mascarados na tabela de destino.

Quando um usuário sem o privilégio UNMASK executar a Importação e Exportação do SQL Server, o arquivo de dados exportado contém dados mascarados e o banco de dados importado conterá dados mascarados inativamente.