Data Security Center:Varredura e identificação de dados

A varredura de dados afeta o desempenho do meu banco de dados?

O Data Security Center (DSC) utiliza varreduras completas, incrementais e agendadas para examinar seus bancos de dados. A varredura completa causa impacto mínimo no desempenho do banco de dados e não afeta as operações normais do seu negócio. A varredura incremental processa apenas os arquivos modificados e gera impacto insignificante no desempenho.

Quais tipos de ativos de dados o DSC suporta para varredura?

Quanto tempo leva para concluir uma varredura após a autorização de um ativo de dados?

Após a autorização de acesso a um ativo de dados pelo DSC, a varredura inicia em até 2 horas. A duração depende do volume de dados a analisar e pode se estender caso haja muitas tabelas (por exemplo, mais de 10.000) ou grande volume de arquivos no OSS (por exemplo, mais de 1 PB). Durante a varredura, o DSC exibe resultados parciais na página Overview do console do DSC. Para mais detalhes, consulte Visão geral do Data Security Center.

Como o DSC verifica ativos de dados não estruturados (OSS e SLS)?

O DSC analisa o conteúdo armazenado em ativos de dados não estruturados e identifica dados sensíveis com base nos resultados da varredura.

DSC: Quais são as regras de faturamento para varreduras de fontes de dados não estruturados (OSS e SLS)?

O DSC é um serviço baseado em assinatura. As varreduras de identificação de dados consomem as cotas de recursos adquiridas. As regras de dedução variam conforme a edição:

• Enterprise Edition: O faturamento baseia-se no volume de proteção de dados. A cota consumida é calculada assim: Tamanho dos buckets do OSS autorizados + (Tamanho dos projetos do SLS autorizados × 0,5). O valor resultante é deduzido da sua capacidade de proteção de armazenamento.

• Plano de Serviço de Valor Agregado: O recurso de varredura e identificação de dados não é suportado.

Para mais informações, consulte Faturamento.

Nova varredura de objetos do OSS

Se um objeto não sofreu modificações, o DSC não o verifica novamente. Caso um objeto seja alterado, o DSC executa automaticamente uma nova varredura dentro de 24 horas.

Se necessário, também é possível executar manualmente uma nova varredura de um ativo do OSS. Para mais detalhes, consulte Reexecutar uma tarefa de identificação.

Como o DSC verifica dados estruturados, como o MaxCompute?

O DSC analisa nomes de campos e seus respectivos valores em bancos de dados e tabelas para identificar dados sensíveis. Por exemplo, ao avaliar dados relacionados à idade, o DSC examina tanto o nome da coluna quanto seus valores, caso os valores isoladamente não sejam conclusivos.

• Varredura inicial: Após a autorização, o DSC executa uma varredura completa de todas as tabelas em todo o banco de dados ou projeto de dados.

• Varredura incremental: Quando uma nova tabela é adicionada a um banco de dados ou projeto de dados, o DSC verifica essa nova tabela. Se o esquema (colunas) de uma tabela existente for alterado, o DSC também reexamina a tabela afetada.

O DSC faz login no banco de dados para recuperar dados?

Com a devida autorização, o DSC acessa seu banco de dados e utiliza amostragem de dados para identificar informações sensíveis. O DSC não armazena nenhum dado proveniente dos seus projetos do MaxCompute ou bancos de dados.

Quais cenários acionam uma nova varredura?

O DSC aciona automaticamente uma nova varredura de um ativo de dados autorizado nas seguintes situações:

Varredura de dados criptografados

Sim, desde que os dados estejam criptografados por meio de criptografia transparente de dados (TDE).

Impacto no desempenho das varreduras do MongoDB

Uma varredura completa de coleções causa impacto mínimo no desempenho do banco de dados e geralmente não interrompe as operações normais do negócio.

Para reduzir ainda mais o impacto das varreduras de ativos no desempenho, aumente o intervalo entre varreduras ou agende-as para horários de baixa demanda, quando o tráfego do banco de dados for menor.

Varredura de arquivos compactados e documentos no OSS

Sim. É possível consultar a lista completa de tipos de dados do OSS suportados na aba File Type da página Identification Rules no console do Data Security Center.

O DSC suporta uma ampla variedade de categorias de arquivos, incluindo arquivos de texto (109 tipos, como .txt, .xml e .vcf), documentos de escritório (144 tipos), arquivos de imagem (86 tipos), documentos de design (10 tipos), arquivos de código (91 tipos), arquivos binários (23 tipos), arquivos de dados (25 tipos), arquivos de verificação de assinatura (18 tipos) e arquivos compactados (50 tipos, como .7z, .zip, .rar e .tar).

Exportação de resultados de identificação

Sim. Para obter instruções, consulte Visualizar e exportar resultados de identificação de dados sensíveis.

Resultados de varredura no nível de campo para MongoDB

Não. O ApsaraDB for MongoDB é um banco de dados orientado a documentos, cuja menor unidade de armazenamento é o documento. Portanto, não é possível restringir os resultados da varredura a um campo específico.

Detalhes nos resultados de consulta da API

Sim.

Identificação de dados sensíveis para Redis

Não. Atualmente, o DSC oferece apenas o recurso de verificação de linha de base para o ApsaraDB for Redis. Para mais informações, consulte Verificações de linha de base de segurança.

Seleção do modelo de identificação comum

Não é necessário configurar separadamente o modelo de identificação comum. Se uma tarefa de identificação utilizar um modelo integrado, o modelo comum será usado por padrão. Para mais detalhes, consulte Visualizar e configurar modelos de identificação e Verificar dados sensíveis usando uma tarefa de identificação.

Tarefas da edição gratuita em estado de espera

A cota gratuita para identificação de dados (5 GB de dados armazenados e 100 tabelas de banco de dados) foi esgotada. Consequentemente, a tarefa de identificação não pode ser executada e permanece em estado de espera. Para continuar utilizando o recurso de identificação de dados sensíveis, adquira um plano do Data Security Center. Para mais informações, consulte Adquirir o Data Security Center.

Tarefas de varredura completa relatadas como parciais

• Descrição do problema: Uma tarefa de varredura agendada está configurada para verificar todos os dados em uma instância de banco de dados, mas a coluna Last Scanned At indica que apenas alguns bancos de dados foram verificados.

  Na página Sensitive Data Identification, ao expandir uma instância MySQL que contém quatro bancos de dados, o horário em Last Scanned At difere para cada banco, sendo que alguns apresentam datas significativamente mais antigas que outros.

• Causa: Em uma tarefa de identificação periódica personalizada, a varredura inicial é completa e abrange o escopo configurado. No entanto, as varreduras subsequentes processam apenas dados incrementais dentro desse mesmo escopo.

• Solução: Caso precise atualize as regras de identificação ou execute uma varredura completa, reconfigure a tarefa de varredura personalizada.