Práticas recomendadas de segurança para o Amazon SNS

A AWS fornece muitos recursos de segurança para o Amazon SNS. Analise esses recursos de segurança no contexto de sua própria política de segurança.

nota

As orientações desses recursos de segurança se aplicam a casos de uso e implementações comuns. Recomendamos que você examine as melhores práticas no contexto do seu caso de uso, arquitetura e modelo de ameaças específicos.

Melhores práticas preventivas

Veja a seguir as práticas recomendadas de segurança preventiva para o Amazon SNS.

Verifique se os tópicos não estão acessíveis ao público geral

A menos que seja nitidamente necessário que qualquer pessoa na Internet possa ler ou escrever no tópico do Amazon SNS, você deve garantir que o tópico não seja acessível ao público (acessível por todo mundo ou por qualquer usuário autenticado da AWS).

• Evite criar políticas com o Principal definido como "".

• Evite usar um curinga (*). Em vez disso, nomeie um usuário ou usuários específicos.

Implemente o privilégio de acesso mínimo

Quando concede permissões, você decide quem as recebe, para quais tópicos as permissões se aplicam e as ações específicas de API que você deseja permitir para esses tópicos. A implementação do princípio de privilégio mínimo é importante para reduzir os riscos de segurança. Também ajuda a reduzir o efeito negativo de erros ou intenção maliciosa.

Siga o aviso de segurança padrão de concessão de privilégios mínimos. Ou seja, conceda apenas as permissões necessárias para executar uma tarefa específica. Você pode implementar o privilégio mínimo usando uma combinação de políticas de segurança pertencentes ao acesso do usuário.

O Amazon SNS usa o modelo publicador-assinante, exigindo três tipos de acesso à conta de usuário:

• Administradores: acesso para criar, modificar e excluir tópicos. Os administradores também controlam as políticas de tópicos.

• Editores: acesso ao envio de mensagens para tópicos.

• Assinantes: acesso à assinatura de tópicos.

Para obter mais informações, consulte as seções a seguir:

• Gerenciamento de identidade e acesso no Amazon SNS

• Permissões da API do Amazon SNS: referência de ações e recursos

Usar funções do IAM para aplicações e produtos da AWS que exigem acesso ao Amazon SNS

Para aplicações ou serviços da AWS, como o Amazon EC2, para obter acesso aos tópicos do Amazon SNS, é preciso usar credenciais válidas da AWS nas solicitações de API da AWS. Como essas credenciais não são alteradas automaticamente, você não deve armazenar credenciais da AWS diretamente no aplicativo ou na instância do EC2.

Use uma função do IAM para gerenciar credenciais temporárias para aplicações ou serviços que precisam acessar o Amazon SNS. Quando você usa um perfil, não é necessário distribuir credenciais de longo prazo (como um nome de usuário, uma senha e chaves de acesso) para uma instância do EC2 ou um serviço da AWS como o AWS Lambda. Em vez disso, a função fornece permissões temporárias que os aplicativos podem usar ao fazer chamadas para outros recursos da AWS.

Para obter mais informações, consulte IAM Roles (Funções do IAM) e Common Scenarios for Roles: Users, Applications, and Services (Cenários comuns para funções: usuários, aplicações e produtos) no Guia do usuário do IAM.

Implemente a criptografia no lado do servidor

Para atenuar problemas de vazamento de dados, utilize a criptografia em repouso para criptografar as mensagens usando uma chave armazenada em um local diferente do local de armazenamento das suas mensagens. A criptografia no lado do servidor (SSE) fornece criptografia dos dados em repouso. O Amazon SNS criptografa os dados no nível da mensagem ao armazená-los e descriptografa as mensagens para você, quando você as acessa. O SSE usa chaves gerenciadas pelo AWS Key Management Service. Quando você autentica sua solicitação e tem as permissões de acesso, não há diferença de acesso entre as filas criptografadas e não criptografadas.

Para obter mais informações, consulte Criptografia inativa e Gerenciamento de chaves.

Aplicar a criptografia de dados em trânsito

É possível, mas não recomendado, publicar mensagens que não estejam criptografadas durante o trânsito usando HTTP. No entanto, não é possível usar HTTP ao publicar em um tópico criptografado do SNS.

A AWS recomenda o uso de HTTPS em vez de HTTP. Ao usar HTTPS, as mensagens são criptografadas automaticamente durante o trânsito, mesmo que o tópico do SNS em si não esteja criptografado. Sem HTTPS, um invasor que venha pela rede pode bisbilhotar o tráfego de rede ou manipulá-lo usando um ataque, como man-in-the-middle.

Para impor somente conexões criptografadas por HTTPS, adicione a condição aws:SecureTransport à política do IAM anexada aos tópicos do SNS não criptografados. Isso força os editores de mensagens a usar HTTPS em vez de HTTP. Você pode usar o seguinte exemplo de política como um guia:

{
  "Id": "ExamplePolicy",
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowPublishThroughSSLOnly",
      "Action": "SNS:Publish",
      "Effect": "Deny",
      "Resource": [
        "arn:aws:sns:us-east-1:1234567890:test-topic"
      ],
      "Condition": {
        "Bool": {
          "aws:SecureTransport": "false"
        }
      },
      "Principal": "*"
    }
  ]
}

Considerar o uso de endpoints da VPC para acessar o Amazon SNS

Se você tiver tópicos com os quais é preciso interagir, mas que não devem de forma alguma ficar expostos à Internet, use VPC endpoints para limitar o acesso ao tópico apenas aos hosts dentro de uma VPC específica. Você pode usar políticas de tópico para controlar o acesso a tópicos de endpoints da Amazon VPC ou a VPCs específicas.

Os endpoints da VPC do Amazon SNS fornecem duas maneiras de controlar o acesso às suas mensagens:

• É possível controlar as solicitações, os usuários ou os grupos permitidos por um VPC endpoint específico.

• Você pode controlar quais VPCs ou VPC endpoints terão acesso ao tópico usando uma política de tópico.

Para obter mais informações, consulte Criar o endpoint e Criar uma política de endpoint da Amazon VPC para o Amazon SNS.

Certificar-se de que as assinaturas não estejam configuradas para entregar a endpoints http brutos

Evite configurar assinaturas para entregar a endpoints http brutos. Sempre tenha assinaturas entregando para um nome de domínio de endpoint. Por exemplo, uma assinatura configurada para entregar a um endpoint, http://1.2.3.4/my-path, deve ser alterada para http://my.domain.name/my-path.