Você já viveu aquele momento de gelar quando percebe que apagou dados importantes do banco sem querer ou derrubou o ambiente de produção no lugar do de desenvolvimento? E, para coroar o pesadelo, descobre que os backups não estavam ativados? É um cenário familiar demais para muita gente. Na DoiT, recebemos quase toda semana tickets de clientes com histórias assim. Neste post, você vai aprender a evitar que isso aconteça de novo!
Vamos começar entendendo as Organizational Policies.
Organizational Policies
Como o nome sugere, as Organizational Policies são ferramentas que ajudam administradores a gerenciar e controlar o comportamento dos recursos dentro da organização e dos projetos no GCP. São regras definidas no nível da organização, da pasta ou do projeto que determinam quais ações podem ou não ser executadas sobre os recursos nesses níveis. Essas políticas ajudam a aplicar diretrizes de segurança, compliance e operação. E, no nosso cenário, podem ser usadas para tornar os backups do CloudSQL obrigatórios!
Como fazer isso? Infelizmente, a documentação e os guias do GCP não ajudam muito, e os exemplos ou não funcionam ou ficam confusos para quem ainda não conhece a Common Expression Language. Eu só descobri por acaso, ajudando um cliente a resolver esse problema. Vamos ao passo a passo. Vamos usar Custom Constraints para bloquear a criação ou modificação de qualquer banco CloudSQL que não tenha o point-in-time recovery (PITR) habilitado. PITR é uma técnica de recuperação que permite restaurar o banco para um momento específico no tempo, normalmente antes de uma perda ou corrupção de dados.
Passo a passo
Passo 1: criar a Custom Constraint
Nossa primeira tarefa é criar uma constraint que negue qualquer tentativa de criar ou modificar um banco CloudSQL sem PITR habilitado. Atenção: se você tentar modificar um banco CloudSQL existente sem PITR habilitado, a modificação será bloqueada, a menos que você habilite o PITR junto!:
- Acesse o console de Organizational Policies
Vá até o Google Cloud Console e selecione sua organização
2. Crie uma Custom Constraint
- Clique em CUSTOM CONSTRAINT
- Informe um nome e uma descrição para a constraint. Isso facilita identificá-la e entendê-la depois.
- Em Enforcement Type, selecione `sqladmin.googleapis.com/instance`.
- Escolha aplicar a constraint nas ações de Create e Update.
- Clique no ícone de lápis ao lado de [define condition] para inserir a condição.
3. Defina a condição
- Informe a seguinte condição para exigir backups com PITR:
resource.settings.backupConfiguration.pointInTimeRecoveryEnabled == false
- Defina a Action como `deny`.
Passo 2: aplicar a constraint
Depois de criada a custom constraint, o próximo passo é aplicá-la na sua organização:
1. Abra a constraint:
Se ainda não estiver nela, vá até a constraint que você criou no console de Organizational Policies.
2. Manage Policy:
- Clique em MANAGE POLICY no topo da página da constraint.
- Selecione Override parent's policy caso já exista uma política.
- Defina a regra de aplicação como On.
- Deve ficar assim:
Se você quiser que apenas alguns dos seus bancos Cloud SQL tenham a exigência de PITR, pode usar Conditions para filtrar quais recursos entram no escopo.
- Clique em ADD CONDITION.
- Informe os critérios de filtro, como a Tag, e escolha o Value path desejado:
Para evitar problemas com recursos existentes (lembre-se da observação anterior sobre não ser possível modificar bancos CloudSQL existentes sem adicionar PITR), recomendo testar a política antes:
- Clique em Test Policy e aguarde a validação ser concluída.
- Acesse a página SIMULATION HISTORY para conferir se o resultado bate com o esperado.
- Estando tudo certo, volte para a custom constraint e selecione MANAGE POLICY.
- Se as alterações não tiverem sido aplicadas, configure a política como antes (veja acima). Clique em SET POLICY e aceite os avisos que aparecerem.
Passo 3: verificar a aplicação da política
Testar e verificar se a política está funcionando como esperado é essencial. Siga estes passos para confirmar a aplicação:
- Teste a política:
A tentativa de criar ou atualizar uma instância do Cloud SQL sem habilitar o point-in-time recovery deve ser negada pela Organizational Policy.
- Execute o comando a seguir:
gcloud sql instances create test-instance --region=us-central1 --no-backup
- Você deve receber um erro informando que o point-in-time recovery precisa estar habilitado.
2. Crie uma instância Cloud SQL em conformidade:
Agora, crie uma instância Cloud SQL com point-in-time recovery habilitado para garantir que ela atenda à política.
- Execute o comando a seguir:
gcloud sql instances create compliant-instance — region=us-central1 — backup-start-time=23:00 — enable-point-in-time-recovery
Esse comando deve ser permitido.
Seguindo esses passos, você criou e aplicou com sucesso uma custom constraint nas políticas da sua organização para garantir que todas as instâncias Cloud SQL tenham backups com point-in-time recovery. Isso não só está alinhado às boas práticas de proteção de dados, como também garante compliance em todos os recursos de nuvem da sua organização. E poupa uma baita dor de cabeça quando alguém apagar dados críticos. De novo.
Calma, não entre em pânico!
Se você perdeu dados, saiba que não está sozinho. A DoiT International está aqui para ajudar a recuperar dados e apoiar na aplicação de backups no Cloud SQL para que isso não aconteça de novo. Com mais de 180 especialistas sêniores em nuvem dedicados a criar soluções sob medida, nosso time está pronto para conduzir esse processo com tranquilidade e otimizar sua infraestrutura para garantir compliance e atender às demandas futuras com eficiência.
Fale com a gente hoje mesmo para garantir que suas políticas de backup do Cloud SQL sejam gerenciadas de ponta a ponta e sem dor de cabeça. Estamos aqui para ajudar você a tomar decisões embasadas e implementar as melhores soluções para as suas necessidades. Além do Cloud SQL, podemos revisar todas as suas políticas em AWS, GCP e Azure para garantir compliance e segurança ponta a ponta.
Nossos especialistas estão prontos para oferecer orientação estratégica e expertise técnica em cada etapa. Vamos conversar sobre o que faz mais sentido para a sua empresa nesta fase de aplicação de políticas, garantindo que sua infraestrutura de nuvem seja robusta, em compliance e otimizada para o sucesso.