1) Estado seguro e backends remotos

O estado do Terraform contém informações sensíveis sobre sua infraestrutura. Manter o estado local expõe dados e dificulta a colaboração. Adote backends remotos com locking para evitar condições de corrida e garanta criptografia em repouso. Ao usar S3 como backend, associe uma tabela DynamoDB para o locking, habilite criptografia em repouso (SSE) e aplique uma política de acesso adequada.

Boas práticas:
– utilize backends remotos em produção;
– habilite encryption no backend e, se possível, chaves KMS;
– habilite locking com DynamoDB;
– mantenha o estado separado por ambiente (prod, staging, dev).

terraform {
  required_version = ">= 1.5"

  backend "s3" {
    bucket         = "my-terraform-state-prod"
    key            = "infra/terraform.tfstate"
    region         = "us-east-1"
    encrypt        = true
    kms_key_id     = "arn:aws:kms:us-east-1:123456789012:key/abcd-1234-efgh-5678"
    dynamodb_table = "terraform-locks-prod"
  }
}

2) Controle de acesso e identidade

Princípio do menor privilégio é indispensável. Evite credenciais estáticas no código ou em tfvars. Prefira uso de provedores com credenciais dinâmicas (roles, assumed roles) e procure centralizar a gestão de identidade com políticas bem definidas. Valide quem pode aplicar alterações e quando.

Exemplo de configuração de provedor com role assumption (AWS):

provider "aws" {
  region = "us-east-1"

  assume_role {
    role_arn = "arn:aws:iam::123456789012:role/TerraformAdmin"
  }

  # opcional: use perfil temporário ou credenciais via ambiente
  # assume_role_session_name = "TerraformSession"
  # shared_credentials_file = "~/.aws/credentials"
}

Valide a identidade atual para auditoria com uma chamada simples:

data "aws_caller_identity" "current" {}
output "principal_arn" {
  value = data.aws_caller_identity.current.arn
}

3) Proteção de segredos e configuração

Segredos devem residir fora do código-fonte e do estado. Utilize mecanismos gerenciados (Secrets Manager, Vault, KMS) e marque variáveis e saídas como sensíveis quando possível. Evite imprimir credenciais em logs ou planos. Para dados que precisam chegar às aplicações, exponha apenas o necessário via mecanismos seguros.

Exemplo de variável sensível e uso seguro:

variable "db_password" {
  type      = string
  sensitive = true
}

resource "aws_db_instance" "app_db" {
  allocated_storage = 20
  engine            = "mysql"
  password          = var.db_password
  username          = "app_user"
}

Alternativas seguras para segredos:
– gerenciar segredos com AWS Secrets Manager, Vault ou SOPS;
– consultar segredos em tempo de aplicação sem armazená-los no estado;
– marcar outputs como sensíveis para evitar vazamento acidental.

4) Observabilidade, auditoria e controle de mudanças

Ter visibilidade completa de mudanças e eventos é essencial para segurança. Adote práticas de auditoria, versionamento de código e trilhas de alterações. Use planos imutáveis e guarde o histórico para revisão. Em ambientes de produção, acompanhe logs de provedor e mantenha um pipeline de revisão de mudanças com aprovação explícita.

Boas práticas recomendadas:
– gere planos de execução e guarde-os (terraform plan -out=tfplan) para auditoria;
– aplique mudanças apenas mediante aprovação humana;
– versionamento de código com tags e releases;
– configure logging e monitoramento no provedor de nuvem para ações de IAM e operações de estado.