Saiba como o AWS Foundational Technical Review (FTR) ajuda você a tratar e proteger dados em suas aplicações SaaS

A maioria das soluções de software como serviço (SaaS) que passam pela lente do AWS Foundational Technical Review (FTR) tem em comum ingestão, gerenciamento e armazenamento de dados confidenciais.

Os dados confidenciais consistem principalmente em informações de identificação pessoal (PII) e informações de saúde protegidas (PHI). Trabalhar com dados confidenciais em soluções SaaS exige que você pense em como os dados do cliente serão transmitidos, armazenados e processados sem prejudicar a segurança, capacidade de gerenciamento e desempenho de sua solução SaaS.

O FTR é uma revisão baseada no AWS Well-Architected Framework e permite que a Infomach como parceiro da AWS identifique e corrija riscos em suas soluções.

O FTR quando operado por arquitetos cloud qualificados simplifica a gestão e proteção de dados confidenciais em suas soluções SaaS, contribuindo no atendimento dos requisitos relacionados a PII ou PHI.

Dados confidenciais em soluções SaaS

Os dados confidenciais, incluindo PII e PHI, têm amplas definições específicas de país e região. Portanto, a definição de PII e PHI deve ser contextualizada e considerar os países de operação e a base de usuários do parceiro.

Para os propósitos desta postagem, podemos definir PII como “informações que podem ser usadas para distinguir ou rastrear a identidade de um indivíduo, como nome, CPF, registros biométricos, isoladamente ou quando combinadas com outras informações pessoais ou de identificação que está vinculado ou vinculável a um indivíduo específico, como data e local de nascimento e nome de solteira da mãe”.

Podemos então definir PHI como “informações de saúde identificáveis individualmente” de acordo com o NIST.

No contexto de uma solução SaaS sendo revisada através do AWS FTR, observamos que as PII estão relacionadas principalmente a credenciais de login e dados pessoais coletados pela solução.

Para soluções SaaS, os requisitos de PHI se aplicam se eles coletam ou gerenciam informações pessoais relacionadas à saúde, mesmo quando a solução pode ou não estar operando no domínio da saúde, juntamente com os requisitos regulatórios da região, como HIPAA nos Estados Unidos.

Se houver uso de autenticação baseada em aplicativo, bancos de dados como Amazon Relational Database Service (Amazon RDS), Amazon Aurora ou banco de dados autogerenciado no Amazon Elastic Compute Cloud (Amazon EC2) serão usados para armazenar PII. Serviços de armazenamento como Amazon Simple Storage Service (Amazon S3), Amazon Elastic File System (Amazon EFS) e Amazon Elastic Block Store (Amazon EBS) também são usados para armazenar PII.

Já o PHI pode ser encontrado nos serviços citados, dependendo do aplicativo, dados e região de atuação. Os parceiros também devem considerar os dados que podem ter um impacto direto em seus clientes, além dos dados PHI ou PII identificados diretamente. Por exemplo, em um aplicativo SaaS, se os metadados do sistema relacionados a uma determinada exibição de formulário por um determinado usuário forem comprometidos, isso poderá revelar o volume de vendas de um determinado produto para esse usuário específico.

Classificação de dados

Como começar a abordar os riscos relacionados a dados confidenciais é uma pergunta comum, e é aí que o requisito FTR de classificação de dados fornece orientações. Os parceiros da AWS devem ter um sistema de classificação de dados para identificar dados confidenciais em sua solução.

O artefato de classificação de dados geralmente se manifesta na forma de um sistema de classificação de dados relacionado ao aplicativo em que os dados que não são de conhecimento público comum (PII e PHI) são identificados e documentados. Por exemplo, o documento pode indicar que, com relação ao aplicativo SaaS, uma tabela específica do Amazon RDS (MySQL) possui credenciais de usuário que são PII e classificadas como “Sensíveis”. Um bucket do Amazon S3 também pode armazenar imagens contendo informações do usuário que são novamente PII e classificadas como “Confidenciais”, enquanto outro bucket do S3 armazena imagens genéricas que não possuem PII ou PHI e, portanto, são classificadas como “Públicas”.

O sistema de classificação de dados deve atuar como um mapa para classificação de dados, proteção de dados (em repouso e em trânsito) e estratégias de mitigação de ameaças se houver vazamento de dados. Por exemplo, o Center for Internet Security (CIS) Critical Security Controls Version 8 recomenda que as empresas usem rótulos, como Sensível, Confidencial e Público, e classifiquem seus dados de acordo com esses rótulos. Da mesma forma, o governo dos EUA usa um esquema de classificação de três níveis, ou seja, Confidencial, Secreto e Ultrassecreto para informações de segurança nacional, conforme descrito na Ordem Executiva 13526.

O Amazon Comprehend também tem a capacidade de detectar entidades PII em documentos de texto em inglês. Por exemplo, Comprehend pode analisar tíquetes de suporte e artigos de conhecimento para detectar entidades PII e redigir o texto antes de indexar os documentos em uma solução de pesquisa.

Protegendo dados em repouso

Analisamos a classificação de dados manipulados por um aplicativo e a identificação de PII e PHI. Agora, vamos explorar como proteger esses dados.

Um requisito na seção Dados confidenciais do FTR é criptografar todos os dados confidenciais em repouso. Isso garante que seus dados estejam protegidos em repouso e ajuda a lidar com vulnerabilidades relacionadas a vazamentos de dados. Com base no sistema de classificação de dados mencionado acima, todos os armazenamentos de dados onde PII ou PHI são armazenados devem ser criptografados.

Vejamos como podemos abordar a criptografia para alguns serviços da AWS comumente usados que lidam com dados confidenciais. Se a criptografia estiver habilitada no Amazon EBS, o serviço funcionará com o AWS Key Management Service (AWS KMS) para habilitar a criptografia nos volumes. A criptografia no lado do servidor Amazon S3 (SSE-S3) criptografa objetos S3 em repouso e também usa o AWS KMS para gerenciamento de chaves.

Para Amazon RDS e outras ofertas de banco de dados da AWS, as opções integradas do AWS KMS podem ser usadas para criptografar o banco de dados. Dependendo do serviço específico da AWS, lembre-se dos tipos de instância disponíveis, classes e limitações correspondentes ao habilitar a criptografia. Com a maioria de nossos serviços, os parceiros da AWS têm a opção de usar uma chave gerenciada pela AWS, que é a chave de criptografia padrão no AWS KMS, ou criar sua própria chave KMS. É altamente recomendável que os parceiros alternem essas chaves de criptografia regularmente.

Também recomendamos que os parceiros usem o Amazon Cognito em vez de criar seus próprios sistemas de autenticação e autorização baseados em aplicativos. O Amazon Cognito permite que os parceiros adicionem cadastro de usuário, login e controle de acesso a aplicativos móveis e da Web de forma rápida e fácil. Além disso, o Cognito criptografa as credenciais do usuário por padrão.

Protegendo Dados em Trânsito

Vamos explorar como proteger os dados durante o trânsito. Outro requisito na seção Dados confidenciais para FTR é usar apenas protocolos de rede com criptografia ao transmitir dados confidenciais fora de sua nuvem privada virtual (VPC). Esse requisito se traduz no uso de comunicação baseada em https ou SSL/TLS durante a comunicação fora da VPC.

Para soluções na AWS que precisam encerrar o TLS, a AWS oferece várias opções, incluindo serviços de balanceamento de carga (Elastic Load Balancer, Network Load Balancer e Application Load Balancer), Amazon CloudFront e Amazon API Gateway. O processo de geração, distribuição e rotação de certificados digitais usados para criptografia SSL/TLS pode ser simplificado usando o AWS Certificate Manager.

Usando serviços como AWS KMS, AWS CloudHSM e AWS Certificate Manager, os parceiros podem implementar uma estratégia abrangente de criptografia de dados em repouso e dados em trânsito em todo o ecossistema da AWS.

PHI e HIPAA

Se a solução SaaS tiver clientes nos EUA e lidar com PHI, os parceiros também precisarão ter um Adendo de associado comercial (BAA) em vigor com a AWS para cada conta da AWS que contenha PHI. Os parceiros também devem usar os serviços da AWS qualificados pela HIPAA para processar e armazenar PHI.

Mais detalhes podem ser encontrados na página da Web de conformidade HIPAA da AWS. Ao abordar o acima, os parceiros da AWS atenderão aos requisitos da seção Informações de saúde protegidas do FTR.

Recomendações Gerais

Outra recomendação é habilitar o registro abrangente em toda a sua solução, onde as PII e as PHI são armazenadas e processadas. Esses logs também devem ser enviados para uma conta de auditoria dedicada ou solução de log para permitir rastreabilidade e auditabilidade em caso de violação de dados. Isso, no entanto, não é um requisito para o FTR.