Os 5 erros de segurança em cloud que mais vemos por aí

Depois de mais de uma década mexendo com infraestrutura de cloud, a gente já viu de tudo. E quando o assunto é segurança, alguns erros aparecem com uma frequência que chega a dar arrepio.

Quer saber a parte mais frustrante? A maioria desses problemas é super fácil de resolver. Mas quando não são tratados, podem virar dor de cabeça gigante.

Vou te mostrar os 5 erros que mais encontramos por aí e como resolver cada um deles.

1. Buckets S3 abertos pro mundo todo

Esse aqui é campeão disparado. Bucket S3 configurado como público sem necessidade real.

A gente já chegou em cliente que tinha backup de banco de dados disponível na internet. Qualquer um podia baixar um dump completo com dados de cliente. Imagina a confusão.

O pior é que a AWS facilita demais criar bucket público. Basta marcar uma caixinha e pronto, tá tudo aberto.

Como resolver:

Primeiro, audita todos os buckets. Usa o comando da CLI pra listar as permissões:

aws s3api get-bucket-acl --bucket nome-do-bucket

Se não precisar de acesso público, bloqueia tudo:

aws s3api put-public-access-block --bucket nome-do-bucket --public-access-block-configuration "BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true"

E configura alertas no CloudTrail pra ser avisado quando alguém mexer nas permissões dos buckets.

2. Chaves de API hardcoded no código

Esse erro é clássico mas ainda acontece toda hora. Desenvolvedor coloca chave da AWS direto no código e sobe pro repositório.

Já vimos caso de startup que teve a conta da AWS hackeada em 2 horas depois de fazer push pra repositório público no GitHub. O atacante usou as chaves pra subir instâncias de mineração de crypto.

Como resolver:

Nunca, jamais, coloque chaves no código. Use sempre variáveis de ambiente ou serviços como AWS Secrets Manager.

Pro Terraform, configure assim:

resource "aws_secretsmanager_secret" "api_key" {
  name = "app/api-key"
}

resource "aws_secretsmanager_secret_version" "api_key" {
  secret_id     = aws_secretsmanager_secret.api_key.id
  secret_string = var.api_key
}

E instala ferramentas como git-secrets pra escanear o código antes do commit.

3. Security Groups liberais demais

Security Group com regra 0.0.0.0/0 na porta 22 ou 3389. Isso é pedir pra ser invadido.

A gente vê muito isso em ambiente de desenvolvimento que depois vira produção. Ninguém lembra de ajustar as regras.

Como resolver:

Audita todos os Security Groups. Procura por regras muito abertas:

aws ec2 describe-security-groups --query 'SecurityGroups[?IpPermissions[?IpRanges[?CidrIp==`0.0.0.0/0`]]]'

Pra SSH e RDP, usa bastion host ou VPN. Nunca libera direto da internet.

E automatiza isso no Terraform:

resource "aws_security_group" "web" {
  ingress {
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = ["10.0.0.0/8"]  # Só rede interna
  }
}

4. Não usar MFA pra contas administrativas

Conta root da AWS sem MFA é suicídio. Mesmo IAM users com permissões altas sem MFA já é arriscado demais.

Teve um caso que a gente acompanhou de empresa que perdeu controle da conta AWS porque um funcionário reutilizou senha que vazou em outro serviço. Se tivesse MFA, não teria dado problema.

Como resolver:

MFA obrigatório pra tudo que é crítico. Configura policy que força MFA:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "NotAction": [
        "iam:EnableMFADevice",
        "iam:GetUser",
        "iam:ListMFADevices"
      ],
      "Resource": "*",
      "Condition": {
        "BoolIfExists": {
          "aws:MultiFactorAuthPresent": "false"
        }
      }
    }
  ]
}

E usa ferramentas como aws-mfa pra facilitar o uso no dia a dia.

5. Logs desabilitados ou mal configurados

CloudTrail desabilitado é como dirigir de olhos fechados. Quando acontece alguma coisa, não tem como investigar.

A gente já atendeu cliente que teve instâncias comprometidas e não conseguia entender como aconteceu porque não tinha nenhum log configurado.

Como resolver:

CloudTrail habilitado sempre, com logs indo pra bucket S3 criptografado:

resource "aws_cloudtrail" "main" {
  name           = "main-trail"
  s3_bucket_name = aws_s3_bucket.trail.bucket
  
  event_selector {
    read_write_type                 = "All"
    include_management_events       = true
    data_resource {
      type   = "AWS::S3::Object"
      values = ["arn:aws:s3:::*/*"]
    }
  }
}

E integra com ferramentas como Grafana pra monitorar eventos suspeitos em tempo real.

A segurança é processo, não produto

Esses 5 erros são só a ponta do iceberg. Segurança em cloud não é coisa que você configura uma vez e esquece.

A gente recomenda revisão mensal das configurações de segurança. E automação sempre que possível. Terraform, scripts, alertas automáticos.

Humano erra. Automação não.

Se você tá reconhecendo algum desses problemas na sua infraestrutura, não se desespere. A maioria é questão de algumas horas pra resolver.

Mas resolve logo. Atacante não vai esperar você ter tempo livre pra arrumar a casa.