O Stellar Engine foi projetado com etapas em camadas para implementar o isolamento de dependências, a contenção de segurança e implantações repetíveis. O repositório é dividido em quatro etapas sequenciais, e cada uma delas é responsável por um domínio específico da página de destino.
Etapa 0: inicialização
A etapa de inicialização inicializa a infraestrutura viável mínima necessária para gerenciar o processo de implantação, atuando como a raiz de confiança do pipeline de IaC.
Essa etapa usa o princípio de privilégio mínimo para a conta de serviço do implantador inicial e a separação estrita da hierarquia administrativa.
O objetivo dessa etapa é criar o seguinte:
- Base administrativa
- Gerenciamento de estado remoto
- Perímetro de segurança inicial
Os seguintes recursos são criados:
- Conexões principais da conta de faturamento e alertas de orçamento
- Projeto de IaC administrativo dedicado para hospedar contas de serviço de implantação
- Buckets do Cloud Storage bloqueados para o estado remoto do Terraform com o controle de versões de objetos ativado
- Coletores de registros de auditoria globais integrados a um bucket central do Cloud Logging
- Configuração de contatos essenciais para garantir que as notificações de segurança, técnicas e de faturamento sejam encaminhadas apenas para domínios de agências autorizadas
Etapa 1: gerenciamento de recursos
O objetivo dessa etapa é definir as pastas, os projetos e os papéis personalizados do Identity and Access Management necessários para estruturas regulatórias específicas.
Essa etapa usa o princípio da segregação de funções em diferentes domínios administrativos e o isolamento estrito de recursos.
Os seguintes recursos são criados:
- Hierarquia de pastas alinhada à conformidade (por exemplo,
Prod,Non-Prod,Security, eShared) - Projetos de locatários dedicados isolados por ambiente e função
- Vinculações de papéis do IAM granulares e papéis personalizados para aplicar o privilégio mínimo
Etapa 2: rede
A etapa de rede provisiona os caminhos de comunicação, os controles de segurança de limites e a conectividade híbrida. O Stellar Engine oferece suporte a vários módulos de rede, incluindo o FedRAMP High e o IL5 NGFW.
O objetivo dessa etapa é estabelecer padrões de conectividade segura, filtragem de pacotes e controles de entrada ou saída.
Essa etapa se concentra na proteção de limites estrita, na inspeção de tráfego centralizada e na filtragem de pacotes profundos. Depois de executar essa etapa, integre uma solução SIEM para monitorar os recursos. Segmente o SIEM em um projeto separado Google Cloud e em uma VPC separada de onde ele está coletando dados.
Os seguintes recursos são criados:
- Topologia de VPC compartilhada hub-e-spoke ou arquiteturas do Network Connectivity Center que minimizam a exposição pública
- Conexões de peering de VPC, Cloud VPN ou interconexão dedicada para cargas de trabalho híbridas
- Roteamento de VPC padrão ou encadeamento de serviços avançado usando firewalls de próxima geração (NGFW) da série VM do Palo Alto (necessário para enclaves DoD IL5) em uma VPC de inspeção especializada
Etapa 3: segurança e auditoria
A etapa de segurança e auditoria aplica imposições de criptografia, bloqueios finais e responsabilidade de serviço.
O objetivo dessa etapa é melhorar a proteção de dados, a rastreabilidade de auditoria e a soberania criptográfica.
Essa etapa se concentra na soberania em repouso, na soberania em uso e no isolamento criptográfico estrito de dados.
Os seguintes recursos são criados:
- Chaves e keystores do Cloud Key Management Service (Cloud KMS) para atender aos requisitos de chaves de criptografia gerenciadas pelo cliente (CMEK) para todos os serviços de armazenamento
- Scripts de bloqueio de segurança e restrições do serviço de política da organização aplicados às contas de serviço usadas durante a implantação
- Tópicos de mensagens inativas e alertas para ingestão registro de auditoria com falha
Princípios de implantação
A tabela a seguir descreve os princípios que o Stellar Engine usa para o processo de implantação.
| Princípio | Descrição |
|---|---|
| Isolamento de estado |
Os arquivos de estado do Terraform são estritamente segregados por etapa. Por exemplo, um bug ou corrupção de estado na etapa 2 não pode acessar ou corromper o estado principal ou as credenciais das etapas 0 ou 1. |
| Fixação de versão do módulo |
Os blueprints referenciam dependências modulares usando tags do Git fixadas ou hashes de confirmação. A fixação ajuda a garantir que as mudanças upstream no registro do módulo não sejam introduzidas automaticamente em ambientes de destino sem revisão explícita. |
| Contenção de impacto |
As atualizações são executadas localmente nos diretórios de etapas. A contenção de impacto ajuda a garantir que uma mudança de código nas regras de firewall na etapa 2 não afete as chaves do Cloud KMS na etapa 3. |
| Contenção de falhas |
Os buckets de estado do Cloud Storage são configurados com o controle de versões de objetos ativado. Se uma mudança de código ruim ou uma edição de estado manual corromper o arquivo de estado, ele poderá ser restaurado imediatamente para uma versão anterior. |