Classificação de dados e Amazon Macie

A sua organização tem 3.200 buckets do S3. Alguém do compliance faz uma pergunta razoável: quais deles guardam dado pessoal de cliente? A resposta honesta, na maioria das contas, é que ninguém sabe.

Essa lacuna não é só um problema de auditoria. Todo controle que você poderia aplicar tem um custo. Criptografar com uma chave gerenciada pelo cliente, ligar data events do CloudTrail no nível do objeto, restringir compartilhamento entre contas, prender o dado a Regions aprovadas: aplique tudo isso em todo lugar e a fatura e o atrito ficam insuportáveis. Não aplique nada e um bucket acaba estragando a semana da empresa.

Classificação de dados é como você escapa dessa armadilha. A skill 4.2.1 do exame pede que você implemente e imponha um esquema de classificação, e são 2 trabalhos diferentes. Implementar é definir níveis e rotular o dado. Impor é fazer o rótulo mudar de verdade o que a AWS permite.

Um nível é um conjunto de regras de tratamento, não um adesivo

Um esquema de classificação é um número pequeno de níveis, cada um preso a uma linha de base de controles. Um formato comum se parece com isto:

Os nomes dos níveis importam menos que a segunda e a terceira coluna. Um rótulo sem regras de tratamento presas a ele é decoração. Uma regra de tratamento sem rótulo em que se prender não tem onde ser aplicada.

Aqui é onde os times erram de forma previsível. É tentador classificar tudo no nível mais alto, na teoria de que proteção demais nunca faz mal. A AWS diz o contrário sem rodeio: a classificação excessiva gera despesa injustificada com controles caros, atrapalha a operação do negócio e desvia atenção dos datasets que realmente precisam dela. Órgãos como ISO e NIST recomendam esquemas em níveis exatamente por isso e desaconselham práticas que tratam todo dado por igual. Se o seu esquema coloca 90% do estate no nível mais alto, o esquema falhou mesmo com todo dataset "protegido".

Os 5 passos, e onde os serviços AWS se encaixam

A AWS descreve classificação como um processo repetível, não como um projeto de uma vez só. Cada passo tem um serviço que o carrega:

1. Estabeleça um catálogo de dados. Inventarie os tipos de dado que você guarda, como são usados e quais caem sob alguma regulação. O AWS Glue Data Catalog guarda e compartilha esse metadado, com rastreio de mudança de schema.
2. Avalie criticidade para o negócio e impacto. Para cada tipo de dado, o que acontece com o negócio se ele vazar, for alterado ou for perdido? Este é o passo que decide o nível, e ele não é um passo técnico.
3. Rotule a informação. Prenda o nível aos recursos de verdade. Na AWS isso é tagging, e é o assunto da próxima seção.
4. Trate os ativos conforme o nível. Os controles daquela terceira coluna viram políticas, chaves e configurações reais.
5. Monitore continuamente. Verifique se os rótulos ainda batem com a realidade e se o tratamento continua aplicado. É aqui que vivem o Macie e o AWS Config.

Os passos 3 e 5 são o par que a maioria dos esquemas erra. Rotular é uma declaração feita por quem criou o recurso. Monitorar é a verificação dessa declaração contra os bytes efetivamente armazenados. Um esquema com rotulagem e sem verificação é um esquema construído sobre esperança.

Tags são a alavanca que o esquema segura

Na AWS o rótulo prático é uma tag, e uma única chave de tag usada de forma consistente vale mais que uma taxonomia elaborada que ninguém aplica. Algo como DataClassification com os valores public, internal, confidential e restricted.

A razão para padronizar em uma chave só é que a tag vira condição de política. Uma bucket policy pode exigir uma tag de principal correspondente:

{
  "Sid": "RestrictedDataNeedsMatchingClearance",
  "Effect": "Deny",
  "Principal": "*",
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::example-data-lake/*",
  "Condition": {
    "StringNotEquals": {
      "aws:PrincipalTag/DataClearance": "restricted"
    }
  }
}

A mesma ideia funciona em uma key policy do KMS, então a chave do nível confidencial só pode ser usada por principals que carreguem a tag de clearance correspondente. Isso é controle de acesso baseado em atributos aplicado a um esquema de classificação, e é a diferença entre um rótulo e um controle.

Dois mecanismos mantêm as tags honestas:

• Prevenção. Um SCP com uma condição aws:RequestTag pode negar a criação de recurso quando a tag de classificação estiver ausente, nos serviços que aceitam tagging no momento da criação. Isso impede que recurso sem tag apareça.
• Detecção. A regra gerenciada do AWS Config required-tags sinaliza recursos sem a tag, e ela pode carregar uma ação de remediação automática. Isso pega tudo que a prevenção deixou passar.

Nenhum dos 2 consegue dizer se a tag está correta. Um bucket marcado como internal que silenciosamente acumula números de passaporte passa nas 2 checagens. É esse ponto cego específico que o Macie existe para fechar.

O Macie começa por um inventário, não por uma varredura

Habilite o Amazon Macie em uma conta e a primeira coisa que ele faz é gerar e manter um inventário dos seus buckets de uso geral do S3, depois avaliar e monitorar esses buckets quanto a segurança e controle de acesso. Nenhum conteúdo de objeto foi lido ainda. Este estágio é metadado: configurações de acesso público, configurações de criptografia, compartilhamento, replicação, contagem de objetos, e quanto do bucket o Macie conseguiria analisar se fosse pedido.

Quando as configurações de um bucket mudam de um jeito que reduz a segurança ou a privacidade dele, o Macie escreve um policy finding:

Uma propriedade dos policy findings pega as pessoas o tempo todo, então vale nomear antes que ela morda: o Macie gera um policy finding apenas se a mudança acontecer depois de você habilitar o Macie para a conta. Um bucket cujas configurações de block public access já estavam desativadas quando você ligou o Macie, e que continuou assim, não produz finding nenhum. O Macie observa mudanças, ele não audita uma linha de base. Para enxergar o estado preexistente você lê o inventário de buckets e a quebra de acesso público dele, e é por isso que o inventário é um recurso de primeira classe e não um efeito colateral.

Policy findings ficam guardados por 90 dias. Se um policy finding se repete, o Macie atualiza o finding existente e incrementa a contagem de ocorrências em vez de criar um novo.

Duas formas de olhar dentro dos objetos

Ler o conteúdo dos objetos é uma atividade separada e cobrada, e o Macie te dá 2 métodos com trabalhos genuinamente diferentes.

Automated sensitive data discovery é a opção de amplitude. O Macie avalia continuamente o seu inventário de buckets, usa amostragem para escolher objetos representativos e os analisa, em um ciclo por dia. Por padrão ele cobre todo bucket de uso geral do S3, e para um administrador do Macie isso inclui buckets de contas membro. Você estreita o escopo excluindo buckets, o que vale a pena para buckets que só guardam log. Por padrão ele usa o conjunto de managed data identifiers que a AWS recomenda para descoberta automatizada, e você pode trocar por identificadores gerenciados específicos, pelos seus próprios identificadores custom, ou pelos 2. A saída é sensitive data findings, sensitivity scores por bucket e um heat map interativo do estate.

Sensitive data discovery jobs são a opção de profundidade. Você define os buckets, a profundidade de amostragem e critérios derivados de propriedades dos objetos, e roda o job uma vez para uma avaliação sob demanda ou em agendamento recorrente.

A fronteira de custo vale decorar porque ela molda a resposta de questões de cenário. Quando você habilita o Macie pela primeira vez, a conta entra em um free trial de 30 dias que cobre a avaliação de buckets e, dependendo das configurações da conta, o automated sensitive data discovery. Discovery jobs não estão incluídos no free trial. Se uma questão fala de um time que habilitou o Macie, não viu cobrança nenhuma e depois tomou uma fatura surpresa, um discovery job é o culpado de sempre.

O que o Macie procura, e o que ele ignora

Três componentes decidem a superfície de detecção:

• Managed data identifiers são os critérios prontos da AWS, usando machine learning e casamento de padrões. Eles cobrem uma lista grande e crescente de tipos de dado sensível para muitos países e regiões: vários tipos de PII, informação financeira e dados de credenciais.
• Custom data identifiers são seus. Uma expressão regular que define um padrão de texto, opcionalmente refinada com sequências de caracteres e uma regra de proximidade. É assim que você detecta identificadores proprietários, codinomes internos ou um formato de número de conta feito em casa.
• Allow lists definem texto e padrões de texto que o Macie deve ignorar. O uso canônico são os telefones públicos da sua própria organização e os nomes dos representantes públicos dela, ou dados de teste que disparam detectores de PII em toda execução.

Allow lists são o botão de ajuste que as pessoas esquecem que existe. Se um tipo de finding dispara repetidamente sobre dado que é público de propósito, a correção é uma allow list, não camadas de regras de supressão em cima de um detector barulhento.

Quando o Macie acha alguma coisa, ele escreve um sensitive data finding nomeando a categoria:

Diferente dos policy findings, todo sensitive data finding é tratado como novo e único, mesmo para o mesmo objeto entre execuções. Eles também ficam guardados por 90 dias, e esse é um teto de retenção para planejar em volta: se a evidência precisa durar mais de 90 dias, exporte pelo EventBridge ou pelo Security Hub CSPM para um armazenamento que é seu.

O Macie em uma organização

O Macie se integra ao AWS Organizations, e as regras são específicas o bastante para virar material de prova.

A conta de gerenciamento do Organizations designa um administrador delegado do Macie, e só a conta de gerenciamento pode criar, mudar ou remover essa designação. Uma organização tem exatamente um administrador do Macie, e uma conta não pode ser administradora e membro ao mesmo tempo.

Depois vem a propriedade que derruba montagens multi-Region: o Macie é um serviço regional, mas o AWS Organizations é global. A designação do administrador é por Region. Se a conta de gerenciamento designa um administrador em us-east-1, aquele administrador consegue gerenciar contas membro só em us-east-1. Cobrir 4 Regions significa entrar em cada uma e designar o administrador 4 vezes. A conta designada precisa ser a mesma em toda Region, mas a designação em si é repetida.

Mais 3 regras para carregar:

• Um administrador do Macie pode estar associado a no máximo 10.000 contas membro em cada Region.
• O administrador não consegue habilitar o Macie para a conta de gerenciamento do Organizations. Se você quer a conta de gerenciamento como membro, alguém dentro dela precisa habilitar o Macie ali primeiro.
• Uma conta membro não consegue se desassociar. Só o administrador pode removê-la, e a remoção deixa o Macie habilitado na conta como conta standalone, em vez de desligá-lo.

Fechando o ciclo do finding até o controle

Um finding sobre o qual ninguém age é uma versão mais lenta de não estar olhando. O Macie publica findings no Amazon EventBridge como eventos, o que os roteia para alvos como funções Lambda e tópicos SNS para processamento quase em tempo real. Você também pode configurar o Macie para publicar findings no AWS Security Hub CSPM, que os agrega junto com findings do GuardDuty, do Inspector e do resto, com suporte a agregação entre Regions para uma Region só.

O padrão de imposição que satisfaz a skill 4.2.1 se parece com isto de ponta a ponta:

1. O automated discovery do Macie acha SensitiveData:S3Object/Financial em um bucket marcado com DataClassification=internal.
2. O finding chega ao EventBridge, casado por uma regra que filtra por tipo de finding e severidade.
3. Um alvo Lambda re-etiqueta o bucket para confidential e abre um chamado nomeando o dono a partir da tag de owner do bucket.
4. Como a bucket policy e a key policy do KMS já estão amarradas a DataClassification, as regras de tratamento do nível entram em vigor no instante em que a tag muda.

O passo 4 é o ponto inteiro. Se a tag não está ligada a nada, a automação só renomeou um problema.

Dicas para a prova

• A skill 4.2.1 diz implementar e impor. Uma resposta que só detecta e reporta é incompleta quando outra opção liga o rótulo a uma permissão.
• Classificação excessiva é resposta errada, não resposta cautelosa. Fique atento a opções propondo o controle mais estrito para todo dado.
• O Macie analisa buckets de uso geral do Amazon S3. Se a questão envolve conteúdo em RDS, EBS ou DynamoDB, o Macie não é a resposta.
• Policy findings só disparam para mudanças feitas depois de o Macie ser habilitado. Fraquezas preexistentes aparecem no inventário de buckets, não como findings.
• Automated sensitive data discovery = amplo, contínuo, amostrado, todos os buckets por padrão, incluído no free trial de 30 dias. Discovery job = direcionado, sob demanda ou agendado, profundidade que você configura, fora do free trial.
• Custom data identifier = uma regex para algo que a AWS não conhece. Allow list = texto a ignorar. Eles apontam em direções opostas.
• As 2 categorias de finding ficam guardadas por 90 dias. Policy findings atualizam no lugar quando se repetem; sensitive data findings são sempre novos.
• O Macie é regional. A designação de administrador delegado, as associações de membros e a quota de 10.000 membros são todas por Region, e só a conta de gerenciamento do Organizations pode designar o administrador.
• Findings chegam à automação pelo EventBridge, e chegam a uma visão consolidada de postura pelo Security Hub CSPM.

O que carregar daqui: classificação é o que torna todo controle posterior deste tópico financiável. Criptografia, key policies, escopo de certificado e rotação de segredo ficam todos mais baratos e mais afiados quando se aplicam ao subconjunto certo em vez de a tudo. A próxima lição pega a regra de tratamento do nível confidencial ao pé da letra e a constrói com KMS.