Arquitetura na Nuvem: Como a Infraestrutura como Código Garante Segurança, Padronização e Escalabilidade
Imagine que você possa criar qualquer coisas usando as mesmas peças de lego. Pessoas diferentes criariam os mesmos objetos da mesma maneira sem um manual definindo como usar as peças e qual o formato final?
Na nuvem temos um problema parecido, temos vários serviços que podem ser usados de diversas maneiras, em alguns casos temos mais de uma opção de serviços diferentes que poderiam ser combinados para satisfazer a mesma arquitetura.
Entretanto, cada serviço tem as suas características e um conjunto de boas práticas de uso para garantir o uso eficiente e seguro.
Sobre segurança, algumas previsões do Gartner:
"Até 2026, 60% das organizações verão a prevenção de configurações incorretas na nuvem como uma prioridade de segurança, em comparação com 25% em 2021."
"99% das falhas de segurança na nuvem serão culpa do cliente."
Bom, para garantir o bom uso, muitos de vocês já ouviram falar do Cloud Well Architecture, todos os Cloud Service Providers tem um guia de fereência:
Não é só a quantidade de clouds que você usa
Não é só a quantidade de clouds que você usa, mas também quais serviços que você vai utilizar e como você vai utilizar.
Abaixo vemos as opções de Container Services para AWS, Azure GCP, IBM Cloud, OCI, Alibaba e Huawei respectivamente:
Arquitetura de Referência
O primeiro passo é definir quais serviços você vai usar, quais os cenários de uso, exemplos de uso, atendimento a escopos regulatórios, proteção de dados, monitoração, impacto de custos, e documentando através da criação de uma arquitetura de referência, voltada para o uso interno. Diferindo das documentações dos CSPs que são voltadas ao uso geral.
Uma vez definido o serviço que vai ser utilizado, como você garante que ele será utilizado dentro do padrão (dentro das boas práticas do CSP e dentro dos seus próprios padrões que vão envolver itens adicionais como:
Usando a infraestrutura como código...
Infraestrutura como Código (IaC) é uma prática de engenharia de software e DevOps que permite gerenciar e provisionar infraestrutura de TI através de arquivos de definição legíveis por máquina, em vez de processos manuais ou interfaces gráficas. Essencialmente, é a aplicação de princípios de desenvolvimento de software à infraestrutura tecnológica.
É importante que ao definir como os serviços devem ser utilizados, que isso seja feito através do uso de infraestrutura como código para que a adoção do uso do serviço seja feita de forma automatizada deste o inicío, desta forma:
Infraestrutura como código?
Seguindo o fluxo do nosso artigo anterior, vamos falar sobre Arquitetura em Nuvem e o que o IAC tem a ver com isso.
Criando um bucket S3 na AWS
Adotando Boas Práticas de Segurança
Se copiarmos o código base do terraform: https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/s3_bucket
resource "aws_s3_bucket" "example" {
bucket = "my-tf-test-bucket"
tags = {
Name = "My bucket"
Environment = "Dev"
}
}
A análise do tfsec revela uma verdade incômoda: mesmo ao criar um recurso básico como um bucket S3, seguir o 'protocolo next-next-finish' pode introduzir vulnerabilidades críticas. Embora os Provedores de Serviço em Nuvem (CSPs) se esforcem para oferecer configurações iniciais seguras, eles não podem prever todas as suas necessidades ou custos adicionais, deixando lacunas que podem ser exploradas.
É aqui que a IaC se torna sua primeira linha de defesa. Para garantir que seu bucket S3 (e, por extensão, toda a sua infraestrutura) seja verdadeiramente seguro, é imperativo que seu código de infraestrutura contemple:
Bloqueio Explícito de Acesso Público: Definir ACLs que proíbam categoricamente o acesso público, evitando exposições acidentais de dados sensíveis.
Criptografia com KMS: Implementar criptografia de ponta a ponta, preferencialmente utilizando chaves gerenciadas por um Key Management Service (KMS). Isso adiciona uma camada vital de controle, garantindo que o acesso aos dados dependa não apenas do acesso ao bucket, mas também da chave de criptografia utilizada no armazenamento dos dados no bucket.
Log de Acessos Detalhado: Configurar um bucket dedicado para receber logs de acesso. Essa trilha de auditoria é indispensável para monitorar atividades suspeitas e investigar incidentes de segurança.
Versionamento de Objetos Ativado: Habilitar o versionamento para proteger seus dados contra exclusões acidentais ou maliciosas, permitindo a recuperação de versões anteriores.
Itens como estes poderiam passar despercebidos quando estamos preocupados em provisionar o serviço. Mas analisando com cuidado vemos que não são apenas 'boas práticas'; são requisitos de segurança que, quando codificados via IaC, garantem que cada novo recurso seja provisionado com a segurança embutida, desde o primeiro dia."
Exemplo da saída do tfsec: (para este artigo estou usando o tfsec, mas o checkov é uma ferramenta bem interessante e cheia de recursos para quem quiser se aprofundar)
Result #1 HIGH No public access block so not blocking public acls
Result #2 HIGH No public access block so not blocking public policies
Result #3 HIGH Bucket does not have encryption enabled
Result #4 HIGH No public access block so not ignoring public acls
Result #6 HIGH No public access block so not restricting public buckets
Result #7 HIGH Bucket does not encrypt data with a customer managed key.
Result #8 MEDIUM Bucket does not have logging enabled
Result #9 MEDIUM Bucket does not have versioning enabled
Result #10 LOW Bucket does not have a corresponding public access block.
results
──────────────────────────────────────────
passed 1
ignored 0
critical 0
high 6
medium 2
low 1
1 passed, 9 potential problem(s) detected.
Veja que muitos destes itens já estariam definidos na arquitetura de referência, mas ainda que não estivessem, seria possível verificar se as boas práticas foram aplicadas.
Fazendo o enforce de configurações
Uma fez endereçada as boas práticas no código, todos os buckets serão criados com o mesmo padrão, importante dizer, que tudo aquilo que não é negociável, pode estar definido sem o uso de variável para que o usuário possa manipular, por exemplo, você pode pré-definir que o versionamento de objetos sempre estará ativo, ou que o tipo de criptografia deve sempre ser implantado via KMS.
Criando um bucket S3: Meus padrões
Importante definir no seu IaC, padrões de uso que vão simplificar o gerenciamento e o FinOps, definindo o esquema de nomenclatura de objetos e as tags (fundamentais para o finOps).
Padronizando Nomenclatura
resource "aws_s3_bucket" "main" {
bucket = join("-", ["s3", var.tag_app, var.tag_app_role, replace(var.region, "-", ""), var.tag_environment, local.unique_id])
tags = {
Name = join("-", ["s3", var.tag_app, var.tag_app_role, replace(var.region, "-", ""), var.tag_environment, local.unique_id])
# Functional
App = var.tag_app
AppRole = var.tag_app_role
Env = var.tag_environment
}
}
Desta forma teremos um nome padronizado, seguindo a regra:
<service>-<app_name>-<region>-<environment>-<unique_id>
"s3-website-cdn-useast1-dev-7b4aa579-1480-0f98-a371-acf26900cd51"
Padronização as Tags
E você pode também definir um escopo de valores para as variáveis, padronizando os metadados que iremos usar, abaixo defini alguns tags mínimas, mas pode ser incluídas tags de centro de custo, criticidade do ambiente, escopo regulatório - como referência: https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/azure-best-practices/resource-tagging
variable "tag_app_role" {
description = "Functional: Application Role Tag"
type = string
default = "cdn"
validation {
# regex(...) fails if it cannot find a match
condition = can(regex("^(cdn|web|data)$", var.tag_app_role))
error_message = "The env tag value must be a valid classification, it must be one of these values \"cdn|web|data\"."
}
}
variable "tag_environment" {
description = "Functional: Environment Tag"
type = string
default = "dev"
validation {
# regex(...) fails if it cannot find a match
condition = can(regex("^(dev|qas|prd)$", var.tag_environment))
error_message = "The env tag value must be a valid classification, it must be one of these values \"dev|qas|prd\"."
}
}
Assim teremos:
Escalando o ambiente de forma padronizada
A adoção da Infraestrutura como Código (IaC - infrastructure as code) é uma parte fundamental da estratégia de provisionamento de infraestrutura em nuvem.
Ela viabiliza que seja possível escalar o uso de infraestrutura em nuvem sem abrir mão da velocidade e padronização. Os códigos são facilmente reutilizáveis, versionados e modularizados para serem consumidos por vários projetos.
Tempo de Desenvolvimento que Retorna com o Aumento de Segurança
No início você tem um trabalho de criar os códigos como módulos, mas no final você ganha muita velocidade e padronização, além de poder ajudar as diversas equipes que vão criar seus componentes de infraestrutura sem ter que se preocupar com os pontos chave de adoção das configurações desejadas pelas definições de arquitetura.
Garantindo que seja possível minimizar o backlog do que poderá ser gerado através de plataformas de CSPM (Cloud Security Posture Management), focamos aqui no terraform para infraestrutura em nuvem, mas o mesmo se aplicaria para outros tipos de códigos de infraestrutura como:
Referências:
Gartner: https://www.gartner.com/en/documents/4540599 e https://www.gartner.com/smarterwithgartner/is-the-cloud-secure
Driving Growth Through Digital Transformation | IT Executive | Expert in ERP, CRM, Data & E-Commerce Strategy
1 mExcelente artigo, admiro a sua habilidade em explicar temas abrangentes de forma tão didática e simples de assimilar. Abs!
Ask me about Cloud and Application Security | Latam Security Sales Engineer
2 mAcho que esse seria um ótimo tópico Raphael Bottino para um ep do A culpa é Sec 🙃 top Seu Ari?
Cyber Security || Threat Intel || Security Analysis & Response || Telemetry Based Threat Hunting || Security Incident Conduction || Environment Analysis || SOC || MSS || Forensics
2 mGenial, grande Ari!!!!