Como criar um bucket do Amazon S3 seguro (AWS)

Muito já se falou sobre a segurança do Amazon S3 na Amazon Web Services (AWS) em notícias e publicações técnicas, e boa parte desse conteúdo simplifica demais o assunto e tem pouca utilidade prática. O Amazon S3 é um serviço de nuvem incrivelmente simples de usar, mas proteger adequadamente seus recursos no S3 está longe de ser simples — como muitas organizações já descobriram. 

Nesta publicação (e nas duas sessões da nossa Cloud Security Masterclass dedicadas ao Amazon S3), apresento uma abordagem prática para entender a segurança do S3. Você poderá avaliar como proteger seus casos de uso específicos do S3 e criar um bucket seguro que atenda às suas necessidades. 

Se você se basear apenas no que lê na imprensa, pode acabar achando que a única medida necessária para garantir a segurança do seu bucket do S3 é ativar o Block Public Access. Acertar essa configuração é importante (e a AWS tomou as medidas necessárias para avisar você se ela estiver incorreta), mas isso também pode gerar uma falsa sensação de segurança se for a única coisa que você fizer. 

As camadas de segurança do Amazon S3

O Amazon S3 tem várias camadas de segurança, e algumas são mais importantes do que outras. 

• Pontos de controle de acesso (ACLs)

• Políticas de gerenciamento de identidade e acesso (IAM) 

• Políticas de bucket

• Block Public Access

• Pontos de acesso

• Criptografia

Entre esses recursos, as políticas de IAM, a criptografia e as políticas de bucket são os mais importantes para entender, pelo menos no começo. Mas, antes de entrar nos detalhes desses tipos de política, é essencial ter um modelo mental de políticas e de como elas se relacionam com ações e recursos na AWS. Vamos deixar as ACLs de lado, pois são um legado histórico que a AWS recomenda não usar na maioria dos casos. 

Políticas de IAM

Na AWS, existem entidades principais (Principals), ações (Actions) e recursos (Resources). Há, é claro, outros tipos de entidade na AWS, mas esses são os que você precisa entender ao projetar buckets do S3 seguros. 

• Entidades principais (Principals) são agentes, tanto humanos quanto máquinas. São as entidades que fazem chamadas a ações e recursos, usando credenciais para isso. 

• Ações (Actions) são os endpoints de API que usamos para executar operações na nuvem. Cada serviço da AWS tem um conjunto de ações, como ListBuckets ou GetObject no S3.

• Recursos (Resources) são instâncias e objetos específicos de um serviço da AWS, como um bucket ou objeto do S3, ou uma instância do EC2. 

Para que uma entidade principal execute uma ação em um recurso (como listar o conteúdo de um bucket do S3), é preciso haver políticas que concedam as permissões necessárias em todas as etapas. Uma negação em qualquer etapa impede a execução da ação no recurso. A política padrão da AWS para todas as ações e recursos, para todas as entidades principais, é: Deny.

Vamos ilustrar. 

Você vê aquela linha vertical entre as entidades principais e as ações, e outra entre as ações e os recursos? Vamos chamá-las de “barreiras de negação”. Ao criar um bucket do S3 seguro, nosso trabalho é abrir brechas nessas linhas somente para as ações necessárias à entidade principal e apenas nos recursos apropriados. 

Para entidades principais da AWS, como usuários e recursos da AWS (por exemplo, uma instância do EC2 associada a uma função do IAM), podemos usar o IAM para permitir acesso a ações e recursos. Veja um exemplo de política de IAM que permite um grupo de ações em todos os buckets do S3 da conta:

1{
2    "Version": "2012-10-17",
3    "Statement": [
4        {
5            "Sid": "VisualEditor0",
6            "Effect": "Allow",
7            "Action": [
8                "s3:GetObjectAcl",
9                "s3:GetObject",
10                "s3:GetObjectTagging"
11            ],
12            "Resource": "*"
13        }
14    ]
15}

Observe que a política tem seções para ações e recursos, assim como no nosso diagrama. Repare que abrimos uma brecha na barreira de negação entre as entidades principais e as ações para as três operações Get definidas na política, e isso se aplica a todos os buckets do S3 nos recursos. 

Neste e em muitos outros casos, a seção de recursos é “*”, ou seja, todos os recursos associados àquela ação. Isso costuma ser uma boa ideia, pois podemos usar políticas de bucket e outros meios para restringir os recursos permitidos quando todas as políticas forem avaliadas. 

Ao decidir onde declarar detalhes como nomes de recursos, é importante evitar criar políticas de IAM em excesso, pois gerenciá-las passa a ser uma fonte de custos e riscos. Por isso, em geral, não é recomendável incluir identificadores de recursos específicos em uma política de IAM, já que isso levaria a várias cópias da política. A seguir, vamos usar políticas de bucket do S3 para limitar o acesso aos recursos na camada do bucket. Assim, quando essa política for atribuída a um usuário ou processo, ela não dará acesso a todos os buckets do S3.

Recomendamos usar políticas gerenciadas pela AWS sempre que fizer sentido, pois já há mais de 700 delas na sua conta, mantidas pela própria AWS. Mesmo que você não encontre uma que se encaixe perfeitamente no seu objetivo, vale usá-las como exemplos para criar políticas de IAM bem elaboradas.

Políticas de bucket

Agora temos uma política de IAM que permite várias ações Get em todos os buckets do S3 da conta, mas provavelmente queremos restringir o acesso apenas aos buckets necessários para o aplicativo em que estamos trabalhando. Há várias maneiras de fazer isso, mas recomendamos definir uma política de bucket para todos os seus buckets do S3 como última linha de defesa. 

As políticas de bucket são políticas da AWS aplicadas a cada bucket individualmente e são uma ótima maneira de negar solicitações que as políticas de IAM talvez permitam. Neste exemplo, queremos que o bucket “foo” aceite apenas ações iniciadas por duas redes VPC específicas. Veja uma política diretamente do portal de suporte da AWS para isso.

1{
2  "Version": "2012-10-17",
3  "Id": "VPCe and SourceIP",
4  "Statement": [{
5    "Sid": "VPCe and SourceIP",
6    "Effect": "Deny",
7    "Principal": "*",
8    "Action": "s3:*",
9    "Resource": [
10      "arn:aws:s3:::awsexamplebucket",
11      "arn:aws:s3:::awsexamplebucket/*"
12    ],
13    "Condition": {
14      "StringNotEquals": {
15        "aws:sourceVpce": [
16          "vpce-1111111",
17          "vpce-2222222"
18        ]
19      },
20      "NotIpAddress": {
21        "aws:SourceIp": [
22          "11.11.11.11/32",
23          "22.22.22.22/32"
24        ]
25      }
26    }
27  }]
28}

Aqui, definimos Deny para todas as entidades principais e todas as ações do S3 no início da declaração. Em seguida, uma condição restringe a negação aos endpoints de VPC que não correspondem a dois identificadores VpcE e a dois blocos CIDR. Em outras palavras, apenas as entidades principais que passarem por esses endpoints de VPC e estiverem dentro desses blocos CIDR poderão executar ações do S3.

Quando combinamos esses elementos no diagrama, aplicando essa política ao bucket “foo” e políticas de bucket diferentes, com outros endpoints de VPC e blocos CIDR, temos:

Aqui, o usuário azul acessa pela VPC com o endpoint vpce-1111111, enquanto o usuário vermelho acessa pelo endpoint vpce-3333333. A política de bucket de “foo” nega o acesso ao usuário vermelho, embora ele use a mesma política de IAM que o usuário azul, pois está vindo de um endpoint de VPC não permitido.

Você pode pensar em todas essas políticas como parte de uma única avaliação, na qual qualquer Deny significa que a solicitação será negada. Assim, você pode decidir onde incluir declarações Allow e Deny com base no seu caso de uso e na sua arquitetura.

Block Public Access

Ouvimos com frequência que as pessoas acreditam estar protegidas contra violações de segurança no S3 ao ativar o recurso Block Public Access na AWS. É um ótimo recurso e você deve usá-lo quando for apropriado, mas seu alcance para bloquear acessos é bem diferente do que muita gente imagina. Não presuma que está tudo seguro só porque ele está ativado.

Na documentação da AWS, está escrito:

 “Para ser considerado não público, uma política de bucket deve conceder acesso somente a valores fixos (valores que não contêm um caractere curinga) de um ou mais dos seguintes tipos:

• Um conjunto de intervalos CIDR (Classless Inter-Domain Routing), usando aws:SourceIp. …”

O documento traz muito mais informações (e você deve lê-lo), mas só esse trecho já mostra que uma lista de blocos CIDR com acesso público não é considerada “pública” do ponto de vista do recurso. Blocos CIDR podem representar grandes partes da internet. Portanto, você pode ter um bucket “não público” exposto a milhões de endereços IP e achar que está tudo seguro. É sempre uma boa ideia usar a política de bucket mais restritiva possível para cada bucket do S3.

Uma observação sobre criptografia

Ao criptografar um bucket do S3, é importante usar chaves do KMS ou chaves gerenciadas pelo usuário. Esses métodos exigem que um invasor também tenha acesso a serviços ou dados adicionais para obter informações descriptografadas do seu bucket do S3. Se você apenas ativar a criptografia do lado do servidor na forma mais básica, terá somente criptografia em repouso no serviço S3. Qualquer entidade principal com permissões GetObject receberá o objeto descriptografado. 

Se houver uma exigência regulatória para criptografar todos os dados em repouso, isso atenderá ao requisito. Mas, do ponto de vista prático, essa medida tem pouco ou nenhum efeito na sua postura de segurança.

E tem mais...

Há mais recursos e camadas de segurança do S3 na AWS do que abordamos nesta publicação. Alguns deles são discutidos na nossa série Cloud Security Masterclass sobre segurança do S3. Se você guardar uma ideia desta publicação, esperamos que seja esta: para entender a segurança do S3, é preciso entender de verdade as políticas da AWS — e não basta confiar em exemplos prontos para dominar o assunto. 

ADENDO: Esqueci de mencionar que você deve ativar o registro de acesso, o registro em nível de objeto e o versionamento nos seus buckets do S3. Os registros de acesso e em nível de objeto permitem ver o que aconteceu no bucket, enquanto o versionamento permite restaurar versões anteriores dos objetos caso alguém obtenha acesso e modifique ou exclua objetos necessários.

Se quiser que abordemos tópicos mais avançados sobre segurança do S3, entre em contato. Vamos nos aprofundar neles!