O blog da AWS
Implementando as melhores práticas do AWS Well-Architected para o Amazon SQS — Parte 2
- Implementando as melhores práticas do AWS Well-Architected para o Amazon SQS — Parte 1: Excelência operacional
- Implementando as melhores práticas do AWS Well-Architected para o Amazon SQS — Parte 3: eficiência de desempenho, otimização de custos e sustentabilidade
Pilar de segurança
O pilar de segurança inclui a capacidade de proteger dados, sistemas e ativos e de aproveitar as tecnologias de nuvem para melhorar sua segurança. Esse pilar recomenda a implementação de práticas que influenciem a segurança. Usando essas melhores práticas, você pode proteger os dados enquanto estão em trânsito (à medida que viajam de e para o SQS) e em repouso (enquanto estão armazenados em disco no SQS), ou controlar quem pode fazer o quê com o SQS.
Prática recomendada: sempre configurar a criptografia do lado do servidor
Se seu aplicativo tiver um requisito de conformidade, como HIPAA, GDPR ou PCI-DSS, exigindo criptografia em repouso, se você quiser melhorar a segurança dos dados para se proteger contra acesso não autorizado ou se estiver apenas procurando um gerenciamento simplificado de chaves para as mensagens enviadas para a fila do SQS, você pode aproveitar a criptografia do lado do servidor (SSE) para proteger a privacidade e a integridade dos dados armazenados no SQS.
O SQS e o AWS Key Management Service (KMS) oferecem duas opções para configurar a criptografia do lado do servidor. As chaves de criptografia gerenciadas por SQS (SSE-SQS) fornecem criptografia automática de mensagens armazenadas em filas SQS usando chaves gerenciadas pela AWS. Esse recurso é ativado por padrão quando você cria uma fila. Se você optar por usar suas próprias chaves do AWS KMS para criptografar e descriptografar mensagens armazenadas no SQS, poderá usar o recurso SSE-KMS.
O SSE-KMS fornece maior controle e flexibilidade sobre as chaves de criptografia, enquanto o SSE-SQS simplifica o processo gerenciando as chaves de criptografia para você. Ambas as opções ajudam você a proteger dados confidenciais e cumprir os requisitos normativos ao criptografar dados em repouso nas filas do SQS. Observe que o SSE-SQS criptografa somente o corpo da mensagem e não os atributos da mensagem.
No exemplo de gerenciamento de inventário apresentado na parte 1, uma função do AWS Lambda responsável pelo processamento de CSV envia mensagens de entrada para uma fila do SQS quando um arquivo de atualizações de inventário é colocado no bucket do Amazon Simple Storage Service (Amazon S3). O SQS criptografa essas mensagens na fila usando o SQS-SSE. Quando um Lambda de processamento de backend consulta mensagens da fila, a mensagem criptografada é descriptografada e a função insere atualizações de inventário no Amazon DynamoDB.
O seguinte código usando o AWS Could Development Kit (AWS CDK) define o SSE-SQS como o tipo de chave de criptografia padrão. No entanto, o código CDK da AWS a seguir mostra como criptografar a fila com o SSE-KMS.
Prática recomendada: implemente o acesso com menor privilégios usando a política de acesso
Para proteger seus recursos na AWS, implementar o acesso com menos privilégios é fundamental. Isso significa conceder aos usuários e serviços o nível mínimo de acesso necessário para realizar suas tarefas. O acesso com menos privilégios fornece melhor segurança, permite que você atenda aos seus requisitos de conformidade e oferece responsabilidade por meio de uma trilha de auditoria clara de quem acessou quais recursos e quando.
Ao implementar o acesso com menos privilégios usando políticas de acesso, você pode ajudar a reduzir o risco de violações de segurança e garantir que seus recursos sejam acessados somente por usuários e serviços autorizados. As políticas de gerenciamento de identidade e acesso (IAM) da AWS se aplicam a usuários, grupos e funções, enquanto as políticas baseadas em recursos se aplicam aos recursos da AWS, como filas do SQS. Para implementar o acesso com menos privilégios, é essencial começar definindo quais ações são necessárias para que cada usuário ou serviço execute suas tarefas.
No exemplo de gerenciamento de inventário, a função Lambda de processamento de CSV não executa nenhuma outra tarefa além de analisar o arquivo de atualizações de inventário e enviar os registros de inventário para a fila SQS para processamento adicional. Para garantir que a função tenha as permissões para enviar mensagens para a fila SQS, conceda à fila SQS acesso à função do IAM que a função Lambda assume. Ao conceder à fila SQS acesso à função IAM da função Lambda, você estabelece um canal de comunicação seguro e controlado. A função Lambda só pode interagir com a fila SQS e não tem acesso ou permissões desnecessárias que possam comprometer a segurança do sistema.
Prática recomendada: permita somente conexões criptografadas por HTTPS usando aws:SecureTransport
É essencial ter um método seguro e confiável para transferir dados entre os serviços da AWS e ambientes locais ou outros sistemas externos. Com o HTTPS, um invasor baseado em rede não pode espionar o tráfego da rede nem manipulá-lo usando um ataque como o man-in-the-middle.
Com o SQS, você pode optar por permitir somente conexões criptografadas por HTTPS usando a chave de condição aws:SecureTransport na política de filas. Com essa condição em vigor, todas as solicitações feitas por HTTP não seguro recebem um erro 400 InvalidSecurity do SQS.
No exemplo de gerenciamento de inventário, a função Lambda de processamento de CSV envia atualizações de inventário para a fila SQS. Para garantir a transferência segura de dados, a função Lambda usa o endpoint HTTPS fornecido pelo SQS. Isso garante que a comunicação entre a função Lambda e a fila SQS permaneça criptografada e resistente a possíveis ameaças à segurança.
Prática recomendada: use controles de acesso baseados em atributos (ABAC)
Alguns casos de uso exigem controle de acesso granular. Por exemplo, autorizar um usuário com base nas funções, ambiente, departamento ou localização do usuário. Além disso, a autorização dinâmica é necessária com base na alteração dos atributos do usuário. Nesse caso, você precisa de um mecanismo de controle de acesso baseado nos atributos do usuário.
Os controles de acesso baseados em atributos (ABAC) são uma estratégia de autorização que define permissões com base em tags anexadas a usuários e recursos da AWS. Com o ABAC, você pode usar tags para configurar as permissões e políticas de acesso do IAM para suas filas. Portanto, o ABAC permite que você escale seu gerenciamento de permissões com facilidade. Você pode criar uma única política de permissão no IAM usando tags criadas para cada função comercial e não precisar mais atualizar a política ao adicionar novos recursos.
O ABAC para filas SQS permite dois casos de uso principais:
- Controle de acesso baseado em tags: use tags para controlar o acesso às suas filas do SQS, incluindo chamadas de API do plano de controle e do plano de dados.
- Tag-on-Create: aplique tags no momento da criação de uma fila SQS e negue a criação de recursos SQS sem tags.
Pilar de confiabilidade
O Pilar de Confiabilidade engloba a capacidade de uma carga de trabalho de executar a função pretendida de forma correta e consistente, quando esperado. Ao aproveitar as melhores práticas descritas neste pilar, você pode aprimorar a maneira de gerenciar mensagens no SQS.
Prática recomendada: configurar filas de mensagens não processadas (dead-letter queues)
Em um sistema distribuído, quando as mensagens fluem entre subsistemas, existe a possibilidade de que algumas mensagens não sejam processadas imediatamente. Isso pode ocorrer porque a mensagem está corrompida ou o processamento posterior está temporariamente indisponível. Em tais situações, não é ideal que a mensagem incorreta bloqueie outras mensagens na fila.
As filas Dead Letter (DLQs) no SQS podem melhorar a confiabilidade do seu aplicativo fornecendo uma camada adicional de tolerância a falhas, simplificando a depuração, fornecendo um mecanismo de repetição e separando as mensagens problemáticas da fila principal. Ao incorporar DLQs em sua arquitetura de aplicativos, você pode criar um sistema mais robusto e confiável que pode lidar com erros e manter altos níveis de desempenho e disponibilidade.
No exemplo de gerenciamento de inventário, um DLQ desempenha um papel vital ao adicionar resiliência às mensagens e evitar situações em que uma única mensagem incorreta bloqueia o processamento de outras mensagens. Se a função Lambda de backend falhar após várias tentativas, a mensagem de atualização do inventário será redirecionada para a DLQ. Ao inspecionar essas mensagens não consumidas, você pode solucioná-las e redirecioná-las para a fila principal ou para um destino personalizado usando o recurso de redrive DLQ. Você também pode automatizar o redrive usando um conjunto de APIs programaticamente. Isso garante atualizações precisas do inventário e evita a perda de dados.
O seguinte trecho de código do AWS CDK mostra como criar uma DLQ para a fila de origem e configura uma política de DLQ para permitir somente mensagens da fila SQS de origem. É recomendável não definir o valor max_receive_count como 1, especialmente ao usar uma função Lambda como consumidor, para evitar o acúmulo de muitas mensagens na DLQ.
Prática recomendada: processe as mensagens em tempo hábil configurando o tempo limite de visibilidade correto
Definir o tempo limite de visibilidade adequado é crucial para o processamento eficiente de mensagens no SQS. O tempo limite de visibilidade é o período durante o qual o SQS impede que outros consumidores recebam e processem uma mensagem após ela ter sido retirada da fila.
Para determinar o tempo limite de visibilidade ideal para seu aplicativo, considere seu caso de uso específico. Se seu aplicativo normalmente processa mensagens em alguns segundos, defina o tempo limite de visibilidade para alguns minutos. Isso garante que vários consumidores não processem a mensagem simultaneamente. Se seu aplicativo precisar de mais tempo para processar mensagens, considere dividi-las em unidades menores ou agrupá-las em lotes para melhorar o desempenho.
Se uma mensagem falhar no processamento e for retornada à fila, ela não estará disponível para processamento novamente até que o tempo limite de visibilidade tenha decorrido. Aumentar o tempo limite de visibilidade aumentará a latência geral do seu aplicativo. Portanto, é importante equilibrar a compensação entre reduzir a probabilidade de duplicação de mensagens e manter um aplicativo responsivo.
No exemplo de gerenciamento de inventário, definir o tempo limite de visibilidade correto ajuda o aplicativo a falhar rapidamente e a melhorar os tempos de processamento de mensagens. Como a função Lambda normalmente processa mensagens em milissegundos, um tempo limite de visibilidade de 30 segundos é definido no seguinte trecho de código do AWS CDK.
É recomendável manter o tempo limite de visibilidade da fila SQS em pelo menos seis vezes o tempo limite da função Lambda, mais o valor de MaximumBatchingWindowInseconds. Isso permite que a função Lambda repita as mensagens se a invocação falhar.
Conclusão
Esta postagem do blog explora as melhores práticas para SQS usando o pilar de segurança e o pilar de confiabilidade do AWS Well-Architected Framework. Discutimos várias práticas recomendadas e considerações para garantir a segurança do SQS. Seguindo essas melhores práticas, você pode criar um sistema de mensagens robusto e seguro usando o SQS. Também destacamos a tolerância a falhas e o processamento de uma mensagem em tempo hábil como aspectos importantes da criação de aplicativos confiáveis usando o SQS.
A próxima parte desta série de postagens no blog se concentra no pilar da eficiência de desempenho, no pilar da otimização de custos e no pilar da sustentabilidade do AWS Well-Architected Framework e explora as melhores práticas para o SQS.
Para obter mais recursos de aprendizado sem servidor, visite Serverless Land.
Este artigo foi traduzido do Blog da AWS em Inglês.
Sobre o autor
Chetan Makvana
Hardik Vasa
Tradutor
Daniel Abib é Enterprise Solution Architect 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.