Criação de uma solução Serverless para pedido de reembolso médico compatível com HIPAA utilizando Amazon SNS, Amazon SQS e AWS KMS

Esse blog foi escrito por Daniel Abib, arquiteto de soluções sênior da AWS e Rodrigo Peres, arquiteto de soluções da AWS.

A segurança deve ter a mais alta prioridade para qualquer aplicativo comercial. Isso também inclui proteger a infraestrutura de mensagens usada por esses aplicativos. Para aprimorar sua proteção contra possíveis violações de dados, proteger a infraestrutura de mensagens é crucial para empresas de todos os tamanhos. Neste contexto, nenhuma camada de segurança da arquitetura de uma aplicação deve ser negligenciada. Para aprimorar a proteção conta violação de dados, por exemplo, garantir a segurança na infraestrutura de mensagens e nas integrações externas e internas do aplicativo é fundamental. A AWS fornece um conjunto completo de serviços de integração para garantir a troca de mensagens de maneira segura, como o Amazon Simple Notification Service (SNS) e o Amazon Simple Queue Service (SQS), bem como o Key Management Service (KMS) para gerenciar chaves de criptografia.

Este blog analisa como esses serviços podem ser combinados para criar uma solução de mensagens segura e escalável, com foco especial nos recursos de criptografia e conformidade oferecidos pelo AWS KMS.

Amazon SNS e Amazon SQS: Serviços de Integração e Mensageria

O Amazon SNS e o Amazon SQS são os principais serviços de mensagens Serverless da AWS, essenciais para criar arquiteturas modernas, desacopladas e escaláveis.

O Amazon SNS, um serviço de publicação/assinatura totalmente gerenciado, foi projetado para facilitar a comunicação baseada em mensagens entre diferentes partes de um aplicativo ou entre diferentes aplicativos, garantindo escalabilidade dinâmica e recursos robustos de filtragem de mensagens.

O Amazon SQS complementa fornecendo um serviço de filas altamente confiável para mensagens entre componentes de software, simplificando o gerenciamento de mensagens e permitindo tarefas de processamento assíncrono. Juntos, esses serviços fortalecem a capacidade de resposta e a confiabilidade dos aplicativos na extensa infraestrutura de nuvem da AWS.

O Amazon SQS e o Amazon SNS geralmente são utilizados em conjunto dentro de um padrão de encadeamento de tópicos e filas. Essa combinação poderosa permite uma arquitetura de mensagens altamente escalável e flexível, na qual o Amazon SNS atua como roteador de mensagens, transmitindo mensagens para vários assinantes , entre os quais podem ser utilizadas filas do Amazon SQS que, por sua vez, fazem o papel de um buffer de mensagens. Esse padrão permite a comunicação assíncrona e a dissociação de microsserviços, tornando-o a escolha ideal para criar sistemas robustos. Os arquitetos e desenvolvedores podem planejar sistemas que não sejam apenas resilientes e escaláveis, mas também capazes de lidar com fluxos de trabalho complexos e altos volumes de dados.

AWS KMS: a espinha dorsal das mensagens seguras

O AWS Key Management Service (KMS) é um serviço totalmente gerenciado que simplifica a geração e gestão de chaves criptográficas. Com ele, as empresas se beneficiam do controle centralizado sobre suas chaves, permitindo aplicar controles de acesso granulares e rigorosos. Além disso, a integração nativa do KMS com diversos serviços da AWS permite que elas enderecem facilmente seus requisitos de criptografia de dados em todos os seus ambientes da AWS.

Embora o Amazon SQS e o Amazon SNS já ofereçam criptografia em trânsito por padrão, podemos adicionar outra camada de segurança à aplicação utilizando o AWS KMS na criptografia das mensagens também em repouso, o que garante que informações confidenciais permaneçam protegidas contra acesso não autorizado. A integração entre o AWS KMS, o Amazon SQS e o Amazon SNS fortalece a segurança dos dados nos aplicativos construídos na AWS, mantendo a integridade e a confidencialidade dos sistemas de mensagens e notificações, cruciais para criar aplicativos resilientes e seguros na nuvem.

Integrando SNS, SQS e KMS para mensagens seguras

Por padrão, tanto o Amazon SNS quanto o Amazon SQS oferecem suporte à criptografia em repouso, também chamada server-side encryption (SSE) ou criptografia do lado do servidor. Isto garante que as mensagens sejam cifradas assim que o serviço as receba e assim permaneçam até que sejam entregues ou excluídas da fila ou tópico. Ao criar uma nova fila ou tópico, você deve especificar a chave do AWS KMS a ser usada para criptografia, conforme ilustrado, respectivamente, nas Figuras 1 e 2.

Figura 1: Configurando a criptografia com o AWS KMS na fila do Amazon SQS usando o console da AWS

Figura 2 : Como configurar a criptografia com o AWS KMS no Tópico do Amazon SNS usando o console da AWS

Ao habilitar a criptografia em repouso, você deve selecionar a chave KMS que será utilizada pelo serviço para cifrar as mensagens. Esta chave pode ser gerenciada pelo serviço AWS ou pelo cliente, a chamada customer master key (CMK) ou chave mestra de cliente. A principal diferença entre elas é o nível de controle e de responsabilidade do cliente.  As chaves gerenciadas por serviços AWS removem do cliente a necessidade de gestão, mas reduzem o nível de controle. Enquanto que utilizando uma chave CMK, o cliente possui maior flexibilidade no controle de acesso às operações da chave. Este controle é alcançado através de uma política de chave, onde o cliente especifica quais usuários e funções do IAM podem realizar operações criptográficas com a chave e quais usuários podem realizar atividades de gestão sobre a chave. Note que este controle permite uma granularidade em que usuários do time de segurança, por exemplo, com permissões de gestão das chaves, não tenham acesso à execução de operações criptográficas e consequentemente não tenham acesso às informações criptografadas.

Além da criptografia em repouso, a AWS recomenda que todas as mensagens sejam criptografadas em trânsito usando endpoints HTTPS para o Amazon SNS e o Amazon SQS. No entanto, a escolha do protocolo de comunicação depende, em última análise, do cliente que utiliza o serviço. O uso de HTTPS protege seus dados à medida que eles se movem entre seu aplicativo e os serviços da AWS, fornecendo uma camada adicional de segurança para todo o seu aplicativo.

Adicionalmemente, é importante controlar quem pode acessar seus tópicos do Amazon SNS e suas filas do Amazon SQS. O AWS Identity and Access Management (IAM) permite que você defina políticas de recursos que especificam quem pode enviar mensagens para uma fila   ou publicar em um tópico, conforme mostrado nas Figuras 3 e 4, respectivamente. Você também pode definir quem pode se inscrever em tópicos ou receber mensagens de filas.

Figura 3: Configurando a política de acesso para filas do Amazon SQS usando o console da AWS

Figura 4: Configurando a política de acesso para tópicos do Amazon SNS usando o console da AWS

Segurança e conformidade para Amazon SQS e Amazon SNS

A AWS fornece um ambiente de núvem pública seguro que está em conformidade com vários padrões, incluindo HIPAA, PCI DSS e GDPR, que se aplicam a serviços como Amazon SNS e Amazon SQS.

Para conformidade com a HIPAA, a AWS permite que as entidades cobertas e seus parceiros comerciais processem, mantenham e armazenem informações de saúde protegidas (PHI) com segurança. A AWS alinha seu programa de gerenciamento de riscos da HIPAA com o FedRAMP e o NIST 800-53, que são padrões de segurança mais elevados que se baseiam na regra de segurança da HIPAA. Os clientes que lidam com PHI podem utilizar os serviços da AWS qualificados pela HIPAA listados no Adendo de Associado Comercial da AWS (BAA).

Com relação ao PCI DSS, os serviços da AWS que estão em conformidade podem ser usados para armazenar, processar ou transmitir dados do titular do cartão, com a AWS fornecendo uma infraestrutura que suporta esses serviços. Os clientes são responsáveis por gerenciar sua certificação de conformidade com o PCI DSS. A AWS fornece recursos como o AWS Artifact para que os clientes baixem relatórios de conformidade e o resumo de responsabilidades do PCI DSS da AWS para entender responsabilidades de controle específicas. A conformidade da AWS com o PCI DSS é validada por um terceiro externo independente, garantindo que seu programa de gerenciamento de segurança seja abrangente e siga as principais práticas do setor.

Para conformidade com o GDPR, a AWS oferece recursos e serviços que ajudam os clientes a se alinharem aos requisitos da regulamentação. Isso inclui a adesão aos padrões de segurança de TI e o fornecimento de vários recursos e ferramentas de conformidade, como o AWS Artifact, os guias de início rápido de segurança e conformidade e o AWS Security Hub.

Ao usar o Amazon SNS e o Amazon SQS, é importante que os clientes entendam sua parte do Modelo de Responsabilidade Compartilhada, que delineia as obrigações de segurança e conformidade da AWS e de seus clientes. Embora a AWS garanta que a infraestrutura e os serviços estejam em conformidade, os clientes devem gerenciar seus próprios dados e aplicativos para manter a conformidade em seus casos de uso.

Exemplo de cenário de caso de negócios

Vamos usar um exemplo de uma arquitetura Serverless projetada para processar pedidos de reembolsos médicos de forma compatível com a Lei de Portabilidade e Responsabilidade de Seguros de Saúde (HIPAA). O processo é orquestrado usando os serviços da AWS, garantindo que os dados confidenciais do paciente sejam tratados com as medidas de segurança necessárias.

Figura 5: Visão geral do processo hipotético de solicitação de reembolo médico

O fluxo de trabalho começa com a coleta de dados de solicitações de vários pacientes, enviados por requisição a APIs e tratados pelo Amazon API Gateway. Esses dados são então processados pelas funções do AWS Lambda, serviço de computação Serverless da AWS orientado a eventos. O conjunto de funções do AWS Lambda executa verificações e validações nos dados da solicitação para garantir que estejam completos e formatados adequadamente.

Após o processamento inicial de recebimento dos dados, a primeira etapa comercial é verificar se os dados estão completos e se o plano do seguro médico do paciente cobre o total de serviços médicos solicitados. Em seguida, as solicitações de reembolso são passadas para um serviço de detecção de fraudes, representado por outras funções do AWS Lambda responsáveis por analisar os pedidos em busca de padrões que possam indicar atividade fraudulenta. Nesta fase do processo de negócio podem ser utilizados modelos de aprendizado de máquina (ML) e algoritmos de detecção de anomalias. Em casos suspeitos, o sistema pode sinalizar os casos que exijam uma investigação mais aprofundada por um time com processos manuais.

Uma vez superadas as fases de validação de cobertura e anti-fraude, a solicitação passa para o estágio de processamento do pagamento do reembolso, onde a legitimidade da solicitação se traduz em transações financeiras. Em nosso exemplo, esse estágio também é gerenciado por funções do AWS Lambda, que se integram aos sistemas financeiros para executar a transação de pagamento.

Nesse cenário hipotético, o estágio final do fluxo de trabalho é o gerenciamento da relação médica, onde são enviados comunicados aos profissionais de saúde. Isso pode envolver a atualização de registros médicos, envio de atualizações de cobertura, novidades sobre o relacionamento com a empresa, o envio de notificações sobre a parceira ou sobre os atendimentos, e a garantia de que todas as partes tenham as informações necessárias sobre a solicitação de forma segura e protegida pela confidencialidade médica.

Durante todo o processo, a auditoria e o gerenciamento de contas (controladoria) são componentes indispensáveis e podem ser executados em paralelo com o processo comercial principal. É provável que cada ação e decisão no fluxo de trabalho seja registrada para garantir a rastreabilidade e a responsabilidade de cada time ou sistema do processo principal. Isso não apenas fornece uma trilha de auditoria clara para fins de conformidade, mas também ajuda na identificação de problemas e na melhoria do processo ao longo do tempo.

Saindo do processo de negócio e entrando em detalhes de segurança, ao usar o Amazon SQS e o Amazon SNS, os clientes da AWS podem e devem aplicar a criptografia em repouso e em trânsito, bem como garantir que o API Gateway e todas as funções do AWS Lambda sejam criptografadas. Isso significa implementar a criptografia do lado do servidor (SSE) para mensagens nas filas do Amazon SQS usando chaves do AWS KMS e, da mesma forma, para tópicos do Amazon SNS.

No Amazon API Gateway, devemos habilitar endpoints HTTPS para comunicações web seguras e configurar nas funções do AWS Lambda com criptografia para manter uma postura de segurança robusta. Ao aderir a esses padrões de criptografia, podemos reforçar a segurança e a conformidade de nosso aplicativo, protegendo dados confidenciais e aderindo às melhores práticas de proteção de dados.

Figura 6: Visão geral do processo com criptografia fim-a-fim em descanso e em trânsito

Nesse fluxo de trabalho seguro, o AWS Identity and Access Management (IAM) desempenha um papel fundamental na proteção dos dados à medida que eles passam por vários estágios, já que todos os serviços envolvidos devem ter permissão explícita para interagir entre si e nenhum outro serviço deve ter  acesso aos dados em trânsito ou em repouso. É importante observar que, devido às políticas rigorosas do IAM, usuários, contas, serviços e funções estão proibidos de acessar os dados no Amazon SQS e no Amazon SNS sem que uma política explicitamente definida conceda esse acesso. Essa camada adicional de segurança garante que somente entidades autorizadas possam lidar com os dados, reforçando a proteção de informações confidenciais em todo o processo de solicitação de reembolso.

No diagrama abaixo, qualquer aplicativo como Marketing, RH ou qualquer outro da empresa que não pode acessar dados nas filas ou nos tópicos sem uma política explícita do IAM vai ter acesso aos dados.

Figura 7: Políticas do AWS IAM negando acesso da aplicação de Markeging as mensagens armazenadas no Amazon SQS

Mas e quanto ao caso de uso da HIPAA?

Ao usar o Amazon SQS e o Amazon SNS em uma solução compatível com a HIPAA, é essencial aplicar a criptografia para PHI em repouso e em trânsito. Os auditores de conformidade exigem que os clientes criptografem as PHI de acordo com as orientações do HHS (U.S. Department of Health and Human Services). Para fazer isso, podemos usar o AWS Key Management Service (KMS) para gerenciamento e criptografia de chaves ou usar recursos nativos dos serviços da AWS.

Os clientes têm flexibilidade na forma como atendem a esses requisitos de criptografia e podem usar recursos de criptografia nativos de serviços qualificados pela HIPAA ou outros métodos consistentes com as diretrizes do HHS. É importante revisar regularmente o site do HHS para verificar se há atualizações sobre esses requisitos. Para obter informações mais detalhadas, você pode consultar a documentação da AWS sobre criptografia e proteção de PHI na AWS.

Primeira abordagem: usando serviços nativos

Ao utilizar os serviços da AWS para lidar com dados de mensagens, especialmente ao lidar com informações confidenciais, como PHI, de acordo com a HIPAA, é possível usar os recursos nativos para proteção de dados no Amazon SNS (link), no Amazon CloudWatch logs (link) ou até mesmo no Amazon CloudFront (link).

O cliente da AWS tem a responsabilidade de configurar esses serviços corretamente para manter a conformidade com os regulamentos de saúde necessários. Para uma compreensão aprofundada, você deve consultar a documentação da AWS sobre criptografia e proteção de PHI.

Confira esta postagem no blog da AWS para entender em detalhes como a proteção de dados do Amazon SNS pode ajudar os clientes em cenários de conformidade.

Um possível desafio de usar a proteção de dados de mensagens do Amazon SNS é que, embora a criptografia proteja a privacidade e a segurança de todos ou de parte dos dados no processo de solicitação de reembolso, ela também pode tornar os dados inutilizáveis (desidentificação ou embaralhamento das informações) para outras etapas de processamento automatizado. Isso significa que, depois que os dados são ofuscados para fins de segurança, os sistemas que realizam tarefas como processamento de pagamentos ou gerenciamento de relações médicas podem não conseguir acessar ou interpretar as informações criptografadas sem os mecanismos de descriptografia adequados, o que pode aumentar a complexidade do fluxo de trabalho.

No fluxo de trabalho hipotético em que estamos trabalhando neste blog, ofuscar dados de PHI para cumprir os padrões de privacidade pode levar a complicações posteriores. Se a carga útil encaminhada para os estágios subsequentes não tiver visível devido aos dados obscurecidos, acessar e utilizar as informações necessárias posteriormente no processo pode se tornar um desafio. Isso exige um equilíbrio entre proteger a PHI e garantir que os dados permaneçam funcionais nas etapas de processamento subsequentes.

Segunda abordagem — Trazendo o AWS KMS para o jogo

Uma abordagem refinada para gerenciar, proteger e estar totalmente em conformidade com a HIPAA nesse processo de solicitação de reembolso envolve o uso de serviços de mensageria da AWS em conjunto com o AWS Key Management Service (KMS) para criptografia, bem como outros mecanismos de criptografia (criptografia em trânsito e em repouso, conforme definido anteriormente). Ao criar chaves públicas distintas no AWS KMS e permitir que cada aplicativo de negócio (cobertuda de plano de saúde, anti-fraude, pagamento e relacionamento médico) acesse a chave apropriada, a solução pode criptografar e descriptografar diferentes segmentos da carga útil quando necessário.

No início do fluxo, podemos ter uma função do AWS Lambda criptografando cada parte dos dados usando chaves de criptografia diferentes. Em cada estágio da solicitação de reembolso, uma função específica do AWS Lambda processa o segmento de dados relevante e esses AWS Lambdas terão acesso específico às chaves que permitem a descriptografia dos dados que lhes são permitidos. Por exemplo, a função Lambda responsável por lidar com os detalhes do paciente teria acesso à chave KMS correspondente para descriptografar essas informações. Da mesma forma, outras funções do AWS Lambda utilizariam suas respectivas chaves para acessar e processar dados de despesas e custos médicos.

Figura 7: Uso de chaves do AWS KMS para criptografar cada grupo de informações contidas no pedido de reembolso médico

O uso de chaves de criptografia separadas para diferentes tipos de dados tem vários benefícios. Ele aprimora a postura de segurança ao garantir que cada função do AWS Lambda só possa descriptografar informações às quais esteja explicitamente autorizada a acessar. Isso minimiza o risco de acesso não autorizado a dados confidenciais e permite que as informações fluam de ponta a ponta. Além disso, ele se alinha ao princípio do menor privilégio, reduzindo a superfície de ataque e o impacto de possíveis violações de segurança.

Ao segregar o acesso dessa maneira, o sistema também facilita uma abordagem modular da lógica de negócios, permitindo atualizações e manutenção mais diretas para cada componente funcional do processo de reembolso.

A incorporação do AWS CloudTrail e outras ferramentas de observabilidade da AWS nessa arquitetura fornece uma trilha de auditoria abrangente. Ele permite monitorar quais aplicativos ou serviços estão usando cada chave de criptografia, oferecendo visibilidade e rastreabilidade aprimoradas para auditorias de segurança e monitoramento de conformidade.

Melhores práticas para mensagens seguras

Para proteger mensagens na AWS, seguir um conjunto de melhores práticas é essencial. Primeiro, modifique a criptografia padrão oferecida pelos serviços Amazon SQS e Amazon SNS para usar a criptografia SSE. O Amazon SQS oferece como padrão a criptografia usando o AWS KMS e, para os clientes do Amazon SNS, é necessário alternar essa configuração de segurança.

Em segundo lugar, configurar a política e os procedimentos de rotação das chaves do AWS KMS aumentam significativamente a segurança ao atualizar o material da chave, que pode ser arquivado automática ou manualmente para reduzir o risco de comprometimento da chave. A aplicação de políticas do IAM para o Amazon SNS e o Amazon SQS também é essencial, pois garante que somente usuários autorizados possam publicar, assinar ou processar mensagens, mantendo um ambiente de controle de acesso seguro.

O monitoramento desempenha um papel crucial na segurança, e é altamente recomendável aproveitar as vantagens do AWS CloudTrail para essa finalidade. O CloudTrail permite o rastreamento de atividades relacionadas aos tópicos do Amazon SNS, às filas do Amazon SQS e às chaves do AWS KMS, permitindo uma trilha de auditoria que é fundamental para identificar qualquer acesso ilegal ou alterações nas configurações.

Por fim, para informações especialmente confidenciais, aplicar a criptografia do lado do cliente antes de enviar mensagens adiciona uma camada mais robusta de segurança. Ao criptografar o conteúdo das mensagens com chaves pessoais antes de enviá-las para a AWS, a integridade e a confidencialidade dos dados são preservadas, estabelecendo uma estrutura segura de mensagens.

No contexto de um fluxo de trabalho de solicitação de reembolso de despesas médicas, o Amazon SNS pode automatizar a detecção de dados confidenciais nas mensagens. Essa automação garante que as solicitações contendo PHI sejam identificadas e tratadas com segurança, com opções para bloquear ou auditar essas mensagens de acordo com as políticas estabelecidas, mitigando assim o risco de violações de dados.

Em um contexto de assistência médica em que as funções do AWS Lambda processam informações confidenciais, os recursos de proteção de dados (link) do AWS CloudWatch Logs são fundamentais para a conformidade com a HIPAA. Ao restringir o AWS Lambda de registrar PHI, divulgações inadvertidas em arquivos de log são evitadas, mantendo a confidencialidade exigida pela HIPAA. Isso se alinha à Regra de Privacidade da HIPAA, que exige a proteção das PHI contra exposição injustificada.

Além disso, o AWS CloudWatch Logs permite controles de acesso e criptografia refinados, garantindo que os dados de log só sejam acessíveis por pessoal e sistemas autorizados. Isso não apenas apoia a conformidade com a regra de segurança da HIPAA, protegendo as PHI contra acesso não autorizado, mas também fornece uma trilha de auditoria segura, essencial para monitorar e revisar as atividades do sistema relacionadas ao tratamento de PHI.

Conclusão

A segurança deve ser o aspecto mais importante do trabalho em qualquer empresa, negócio e aplicativo. Proteger aplicativos que usam serviços de mensagens da AWS, como Amazon SNS e Amazon SQS, é uma tarefa fundamental no ambiente atual baseado em dados, onde a restrição de acesso à informações confidenciais é fundamental.

Este blog analisou a sinergia entre esses serviços, enfatizando a criptografia com o AWS KMS para garantir a confidencialidade dos dados. À medida que navegamos na estrutura segura de mensagens, exploramos como a infraestrutura robusta da AWS oferece suporte à conformidade com padrões rigorosos, como HIPAA, PCI DSS e GDPR.

No cenário hipotético de um processo de solicitação de reembolso compatível com a HIPAA, os serviços da AWS ajudam o cliente a garantir que a PHI seja meticulosamente protegida, desde a captura inicial de dados até o gerenciamento final do relacionamento médico. A abordagem de criptografia em camadas, juntamente com as rigorosas políticas de acesso do AWS IAM, garante que os dados sejam acessíveis somente a entidades autorizadas, mantendo a integridade do fluxo de trabalho de reembolso.

Para concluir, está claro que, embora a AWS forneça uma série de bases para mensagens seguras, a responsabilidade de configurar e gerenciar meticulosamente esses serviços e chaves de criptografia recai sobre as empresas que usam o serviço da AWS. O modelo de responsabilidade compartilhada da AWS destaca isso, atribuindo aos usuários a obrigação de proteger seus aplicativos dentro do ecossistema da AWS.

Biografia dos Autores

	Daniel Abib é arquiteto de soluções senior na AWS, com mais de 25 anos trabalhando com gerenciamento de projetos, arquiteturas de soluções escaláveis, desenvolvimento de sistemas e CI/CD, microsserviços, arquitetura Serverless & Containers e segurança. Ele trabalha apoiando clientes corporativos, ajudando-os em sua jornada para a nuvem. https://www.linkedin.com/in/danielabib/
	Rodrigo Peres é arquiteto de soluções na AWS, com mais de 20 anos de experiência trabalhando com arquitetura de soluções, desenvolvimento de sistemas e modernização de sistemas legados.