APRENDER. PRATICAR. EVOLUIR.Separar proteção, visibilidade e recuperação
Num arquivo fictício de relatórios de fundos, o nome de um ficheiro deixou de devolver conteúdo. A equipa conclui que Object Lock falhou. Antes de aceitar essa conclusão, distingue o nome lógico, as versões e o marcador atual. O bloqueio protege uma versão; não impede necessariamente um novo conteúdo com o mesmo nome ou um delete marker. Desenha o histórico v1, v2 e marcador m3. Decide qual versão contém o relatório validado e quem pode lê-la. A recuperação deve manter rastreabilidade, evitando apagar versões por tentativa e erro. A disponibilização por CloudFront continua a exigir controlos de acesso adequados; retenção não autentica os leitores. A aula de cache aprofunda essa fronteira. Para uma origem S3 normal, configura OAC com assinatura de pedidos e uma bucket policy que autoriza o serviço CloudFront apenas para a distribuição prevista, através de AWS:SourceArn. O endpoint de website S3 tem tratamento diferente e não aceita OAC. Se o problema for apenas o delete marker, recupera a versão validada ou remove o marcador adequado com autorização; não apagues o histórico para tornar o nome novamente legível.
Decidir retenção com critérios verificáveis
Nesta oficina usamos retenção fixa e legal hold, não retenção variável por evento. Um documento tem retain-until no dia 20 e um legal hold ativo; chegar ao dia 21 não resolve ambos os controlos. Regista cada condição separadamente. Em governance, uma exceção exige a autorização específica e a indicação de bypass no pedido, além das permissões da operação. Em compliance, não planeies encurtar a retenção para cumprir uma urgência operacional. O gestor deve confirmar classificação e prazo com os responsáveis, ensaiar a configuração em dados descartáveis e documentar a decisão. O termo compliance no produto não demonstra, por si, cumprimento de todas as obrigações de uma organização. Durante a retenção em compliance, a versão não pode ser eliminada por utilizadores, incluindo root.
Manter a recuperação possível durante o ciclo das chaves
FINOPS propõe retirar uma chave porque a aplicação já escreve com outra. No inventário, inclui relatórios antigos, snapshots e cópias conservadas para recuperação. A rotação de material numa chave não é uma migração de todos os dados para uma nova chave. No cenário, o alias atual aponta para B, mas o arquivo ainda depende de A. Exige evidência de recuperação desse arquivo antes de aprovar a retirada. Uma chave em PendingDeletion não está disponível para novas operações criptográficas KMS, embora caches possam esconder parte do impacto. Define responsável, dependências e critérios de interrupção. Object Lock conserva versões, mas não assegura a disponibilidade da chave necessária para as ler.
Rodar segredos e observar os consumidores
Um serviço fictício de reconciliação usa um segredo para criar ligações à base de dados. Depois de uma rotação, workers antigos continuam com ligações abertas, mas novos workers falham ao autenticar. O estado da tarefa de rotação não substitui a observação do consumidor. Compara o destino atualizado, a versão obtida pelo cliente e o comportamento da cache, sem incluir palavras-passe nos logs. A operação de rotação deve tratar o segredo e o sistema que valida a credencial. Prepara uma verificação com ligação nova e uma estratégia aprovada para recuperar o serviço se houver incompatibilidade. A equipa de suporte precisa de saber onde observar a falha e como distinguir conectividade de autenticação. Usa Secrets Manager para gerir o segredo e testa a renovação de credenciais no consumidor.
Recolher a evidência de acesso necessária
Uma revisão pergunta quem leu relatórios de uma carteira num intervalo concreto. O trail recolhe apenas alterações administrativas; o resultado vazio para GetObject não prova ausência de leitura. Traduz o requisito em operações, recursos e intervalo, e compara-o com os seletores efetivamente ativos. Eventos de dados podem ter custos e volume relevantes; escolhe o âmbito necessário e confirma uma leitura controlada no ensaio autorizado. Um seletor apenas de escrita não responde à pergunta sobre leitores. Documenta a lacuna histórica quando a recolha só começa depois do incidente. Preserva a distinção entre nenhum evento encontrado e nenhuma operação realizada. O dossier deve indicar a cobertura conhecida e os limites da conclusão. Configura eventos de dados CloudTrail para as operações de leitura exigidas no bucket.
Aceitar o serviço recuperado
Uma alteração lógica às 14:10 corrompe um conjunto; a equipa escolhe um ponto anterior e prepara uma nova instância. O plano deve preservar a origem enquanto identifica operações válidas posteriores a reconciliar. A existência da instância não comprova parâmetros, acessos, desempenho ou resultado funcional. Na oficina, desenha uma sequência com seleção do ponto, restauro isolado, validação, reconciliação, transição controlada e observação. Reserva quinze minutos para identificar dependências e vinte para rever critérios de aceitação com o RUN. Para AWS Backup, distingue estado do restauro do resultado de validação. Entrega uma decisão justificada e um plano de limpeza dos recursos de ensaio. Este exercício é documental: nenhum restauro AWS foi executado nesta aula. No RDS point-in-time recovery, o restauro cria outra instância; planeia a validação e o cutover para o novo endpoint.
Um relatório continua guardado numa versão protegida, mas o nome atual tem um delete marker e a chave necessária está indisponível. São dois problemas distintos: visibilidade e capacidade de decifrar.
Armadilhas comuns
Confundir versão retida com ficheiro visível; retirar chaves só porque o alias mudou; usar ligações antigas para validar rotação; aceitar COMPLETED como prova de recuperação funcional.
Tópicos relacionados: Identidade, confiança e permissões · Bases relacionais, ligações e recuperação · CloudFront: cache, privacidade e origem · Objetos: retenção, replicação e recuperação
Demonstra que os dados necessários continuam legíveis, que os acessos são observáveis e que o serviço recuperado cumpre critérios explícitos.
Referência: RDS point-in-time restore · SAA-C03