Corte accidental da produción, claves de API filtradas ou infraestrutura de nube eliminada¶

Todos os enxeñeiros de software, administradores de sistemas e traballadores técnicos remotos afrontan finalmente o momento estremecedor en que un comando destinado a localhost ou staging executa contra production: un non indexado DELETE sen a WHERE cláusula, a DROP TABLE ou terraform destroy, a git push --force que sobrescribe a rama principal ou unha confirmación pública que contén claves secretas de AWS ou Stripe en directo. O que separa un pequeno inconveniente de 15 minutos dunha catástrofe de datos que remata a súa carreira é deter as mans inmediatamente, conxelar o tráfico de escritura antes de que se sobrescriban os bloques de almacenamento e executar o protocolo de recuperación correcto.

Fai isto agora¶

1. Conxela as túas mans e NON executes comandos de "corrección" apresurados, reinicies o servidor de base de datos ou peches a xanela do teu terminal. O teu búfer de desprazamento de terminal actual, o historial de shell e o local .git/logs reflog contén as marcas de tempo exactas das transaccións, os hash SHA de commit e os ID de recursos necesarios para revertir o dano. Copia primeiro o teu terminal de desprazamento completo nun ficheiro de texto seguro.
2. Declare un incidente de gravidade-1 (SEV-1) na canle Slack/Teams de incidentes do teu equipo nun prazo de 2 minutos. Nunca pases 45 minutos intentando reparar en segredo unha base de datos de produción dañada só mentres os clientes están a producir 500 erros e os traballos automatizados en segundo plano están a corromper as táboas restantes. Póñase inmediatamente en contacto co administrador de base de datos (DBA) ou o enxeñeiro de fiabilidade do sitio (SRE) de garda.
3. Se filtraches unha clave API, .env ficheiro ou segredo de nube nun repositorio público de GitHub, REVOQUE a chave no panel de control do provedor PRIMEIRO (antes de tentar reescribir o historial de Git). As redes de bots automatizadas raspan a API pública de GitHub Firehose e executan as chaves AWS, OpenAI, Stripe e GCP roubadas nun prazo de 3 a 15 segundos dos teus segundos. git push. Eliminar o ficheiro nunha segunda confirmación ou forzar a forza non detén a un atacante que xa clonou a chave.
4. Se correches un accidente DELETE, UPDATE, ou DROP nunha base de datos de produción, corte o tráfico de ESCRITURA da aplicación inmediatamente. Pon a aplicación web en modo de mantemento ou revogue os permisos de escritura do usuario da aplicación para que as novas transaccións entrantes non sobrescriban as tuplas mortas sen aspirar nin dificulten a recuperación puntual (PITR).
5. Nunca corres VACUUM, OPTIMIZE TABLE, ou git gc --prune=now despois dunha eliminación accidental. Tanto as bases de datos relacionais (PostgreSQL MVCC, MySQL InnoDB) como Git manteñen as filas eliminadas e as confirmacións orfas intactas no disco ata que un pase de recollida de lixo/baleiro recupera fisicamente as páxinas.
6. ** Se a terraform destroy ou o script de eliminación da nube aínda está en execución no teu terminal, preme Ctrl + C UNHA VEZ (non dúas veces) ou elimina o token de sesión IAM.** Premendo Ctrl + C unha vez desencadea unha descarga de estado elegante polo que Terraform garda o parcial .tfstate do que aínda existe; presionando Ctrl + C forza dúas veces un aborto impropio que pode corromper ou perder o ficheiro do teu estado local.

Fluxo de traballo de triaxe de emerxencia: caída da base de datos, forza de git ou filtración secreta¶

Siga esta árbore de decisións para encamiñar os seus primeiros 5 minutos de contención técnica.

flowchart TD
    A["Emerxencia Enxeñaría de Produción"] --> B{"Que fallo acaba de ocorrer?"}
    B -->|"DROP/DELETE/UPDATE de SQL accidental en Prod"| C["Deter as escrituras de aplicacións/Modo de mantemento; NON execute o baleiro"]
    B -->|"Clave API / .env / Chave privada filtrada en Git"| D["Revoga e xira o segredo no panel de control da nube en 60 segundos"]
    B -->|"git push accidental --force / rama eliminada"| E["Executar git reflog localmente; Copiar SHA do último compromiso correcto"]
    B -->|"Destrución accidental da terraform/Eliminado S3 ou VM"| F["Mata a sesión IAM ou preme Ctrl+C unha vez; Conservar .tfstate"]
    C --> G["Gravar a marca de tempo UTC exacta; Activar Cloud PITR Clone ou Binlog Flashback"]
    D --> H["Auditar rexistros de acceso / CloudTrail para spin-ups non autorizados; Scrub Repo con git-filter-repo"]
    E --> I["Consulta eventos de GitHub / Reflog e restaurar rama con git push --force-with-lease"]
    F --> J["Comprobe S3 Versioning Eliminar marcadores, EBS Snapshots ou Cloud Recycle Bin"]

Parte 1: Base de datos de producións accidentais DROP, TRUNCATE, ou DELETE sen WHERE¶

Cando unha consulta SQL destrutiva chega a unha base de datos de produción en directo, o mecanismo de recuperación exacto depende do seu motor de base de datos (PostgreSQL, MySQL/MariaDB, SQL Server, MongoDB ou DynamoDB) e de se a declaración era un DML (DELETE / UPDATE) ou DDL (DROP TABLE / TRUNCATE) operación.

Paso 1: rexistra a marca de tempo UTC exacta ata o segundo¶

Antes de tocar calquera consola de copia de seguridade, anote a hora UTC actual (date -u no terminal Linux/macOS ou SELECT NOW(); dentro do indicador SQL) e estima o segundo exacto xusto * antes de que * comezase a executarse a túa consulta destrutiva. Point-In-Time Recovery (PITR) funciona reproduciendo o rexistro de escritura anticipada da base de datos (WAL en PostgreSQL) ou rexistro binario (binlog en MySQL) ata T_minus_1_second xusto antes de que chegase a túa mala consulta.

Paso 2: Detén os traballos en segundo plano e as escrituras de aplicacións (Protexe as tuplas MVCC)¶

En PostgreSQL, en execución DELETE FROM users; ou UPDATE orders SET status = 'cancelled'; non borra un só byte de datos do ficheiro de táboa no disco inmediatamente. Dado que PostgreSQL usa Control de simultaneidade de varias versións (MVCC), a DELETE simplemente establece o xmax encabezado de ID de transacción en cada tupla de fila para marcalo como invisible para futuras consultas, deixando os datos de fila completos intactos dentro do base/ montón ata que apareza autovacuum para marcar o espazo reutilizable.

• Se estás nunha máquina virtual PostgreSQL ou autoaloxada e non tes unha copia de seguridade recente: Conéctate inmediatamente como superuser e desactive o baleiro automático nesa mesa (ALTER TABLE table_name SET (autovacuum_enabled = false);), ou detén o servizo PostgreSQL e fai unha instantánea do sistema de ficheiros a nivel de bloque (LVM / EBS instantánea) do /var/lib/postgresql/data directorio. Extensións forenses PostgreSQL especializadas (pg_dirtyread) pode ler e recuperar o 100 por cento das filas eliminadas ou actualizadas previamente directamente fóra da táboa de acumulación sen aspirar en minutos.

Matriz de recuperación de bases de datos por motor e plataforma na nube¶

Parte 2: claves API filtradas, .env segredos ou claves privadas comprometidas con Git¶

Se accidentalmente cometeches un .env arquivo, an id_rsa Chave SSH, un ficheiro JSON da conta de servizo de Firebase/GCP, unha chave secreta de Stripe (sk_live_...), ou un AWS AKIA... clave de acceso a Git, siga esta secuencia exacta de dúas fases: Fase A (Mata a chave na nube) primeiro e Fase B (Limpiar o repositorio de Git) segundo.

Fase A: contención inmediata de credenciais na nube durante 60 segundos (faga isto PRIMEIRO)¶

1. AWS (AKIA... ID clave de acceso + clave de acceso secreta)¶

Cando os bots rouban unha chave AWS de GitHub, o seu script automatizado chega á túa conta en 10 segundos para activar instancias de GPU EC2 de tamaño máximo (p4d.24xlarge / g5.48xlarge) nas máis de 30 rexións globais de AWS (incluídas as rexións de activación como Iacarta, Osaka e Oriente Medio) para minar criptomoedas ou crear un usuario IAM de porta traseira con AdministratorAccess antes de eliminar a clave orixinal.

1. Desactiva e elimina a chave de acceso filtrada inmediatamente:
   • Abra AWS Console -> IAM -> Usuarios -> [Usuario comprometido] -> Credenciais de seguranza -> Teclas de acceso -> Fai clic en Desactivar, despois en Eliminar (ou a través da CLI: aws iam update-access-key --access-key-id AKIAIOSFODNN7EXAMPLE --status Inactive --user-name MyUser).
2. Achega un explícito DenyAll política de neutralización temporal aws sts fichas de sesión:
   • Trampa crítica: mesmo despois de eliminar un AKIA... Chave de acceso IAM, se o atacante xa chamou sts:GetSessionToken ou sts:AssumeRole durante os primeiros 30 segundos, a súa temporalidade ASIA... o token de sesión segue sendo válido de 1 a 12 horas a menos que anexas unha política explícita de Denegar (como AWSCompromisedKeyQuarantineV2 ou unha política de denegar todo para os tokens emitidos antes da marca de tempo actual) ao usuario ou función.
3. Audit AWS CloudTrail para a persistencia da porta traseira:
   • Abre AWS CloudTrail -> Historial de eventos e filtra polo ID de clave de acceso ou Nome de usuario comprometido nas últimas 2 horas.
   • Consulta especificamente estas 5 chamadas de persistencia: CreateUser, CreateAccessKey, AttachUserPolicy, AssumeRole, e RunInstances. Comprobe AWS Cost Explorer e EC2 Global View en todas as rexións para finalizar calquera instancia fraudulenta e abra un Caso de asistencia técnica de AWS (Conta e facturación -> Conta comprometida) de inmediato. AWS renuncia habitualmente ás facturas informáticas fraudulentas cando informa dunha fuga de clave e finaliza as instancias de inmediato.

2. Raia (sk_live_...), OpenAI (sk-...), SendGrid, Twilio e Slack Tokens¶

• Stripe: vai a Desenvolvedores -> Teclas API -> Teclas estándar / Teclas restrinxidas -> Fai clic nos tres puntos (...) -> Tecla de rolo. Escolle "Expirar agora" (ou establece unha xanela de gracia de 1 hora só se estás implementando activamente a nova clave nas variables do teu contorno de produción neste momento).
• OpenAI/Anthropic: Vaia ao panel de chaves API e fai clic en Revogar/Eliminar inmediatamente para que os raspadores de proxy automatizados non poidan consumir miles de dólares de créditos de tokens LLM en minutos.
• Fichas de acceso persoal (PAT) de GitHub, fichas de gran fino e claves de implementación: Vaia a Configuración de GitHub -> Configuración do programador -> Fichas de acceso persoal e fai clic en Eliminar/Revogar no token filtrado e, a continuación, verifique o Rexistro de auditoría da túa organización (Settings -> Audit log) para repo.clone, repo.access, ou creación de webhook non autorizada durante a xanela de exposición.
• Cadenas de conexión de base de datos (DATABASE_URL / postgres:// / mongodb+srv://) e URL de Redis: Cambie o contrasinal do usuario da base de datos dentro do motor de base de datos (ALTER USER app_user WITH PASSWORD 'new_random_secret';), e despois terminar todas as conexións TCP activas actualmente abertas que pertencen ás antigas credenciais (SELECT pg_terminate_backend(pid) FROM pg_stat_activity WHERE usename = 'app_user' AND pid <> pg_backend_pid(); en PostgreSQL), porque cambiar un contrasinal de base de datos en PostgreSQL ou MySQL só bloquea novos inicios de sesión e deixa a conexión xa aberta dun atacante ata que se expulse.

Fase B: eliminando o segredo da historia de Git (git filter-repo & Desaloxo da caché de GitHub)¶

Unha vez que a chave filtrada estea morta e rotada na produción, limpa a cadea secreta do seu historial de commits de Git para que os escáneres de seguranza deixen de alertar:

1. ** Reescribe o historial do repositorio usando git filter-repo (ou BFG Repo-Cleaner):**
   • Tome un novo clon de espello espido do seu repositorio e elimine o ficheiro filtrado (por exemplo, .env) de cada compromiso histórico en todas as ramas e etiquetas:

     # 1. Remove a specific file (.env) from all commits in history:
     git filter-repo --invert-paths --path .env
     
     # OR 2. Replace a specific secret string with ***REMOVED*** everywhere:
     echo "sk_live_YOUR_SECRET_STRING==>***REMOVED***" > replacements.txt
     git filter-repo --replace-text replacements.txt
     

2. Forzar forzar o historial limpo e purgar as vistas de solicitude de extracción/commit de GitHub na caché:
   • Empuxe o historial limpo de volta á orixe (git push origin --force --all e git push origin --force --tags).
   • Paso importante de confirmación na memoria caché de GitHub: Mesmo despois de forzar un historial limpo, calquera que coñeza o antigo URL SHA de confirmación de 40 caracteres (github.com/org/repo/commit/abc1234...) aínda pode ver a antiga confirmación sen limpar na IU web de GitHub ata que GitHub execute a recollida de lixo no servidor. Póñase en contacto co Soporte de GitHub (ou use o portal de Asesoramento de Seguridade / Soporte do repositorio) co SHA de commit antigo exacto e pídalles que desaloxen o commit desreferenciado/colgante da caché web e execute git gc no repositorio remoto.

Parte 3: Desfacer un accidente git push --force, git reset --hard, ou rama eliminada¶

Se correches accidentalmente git push --force e eliminou os compromisos dos teus compañeiros main, ou correu git reset --hard HEAD-5 e perdeu un día completo de traballo local, non te asustes, porque Git case nunca elimina inmediatamente os obxectos comprometidos.

Por que os teus compromisos "perdidos" aínda están a salvo dentro .git/logs (O Reflog)¶

Sempre que crea unha confirmación, cambia de rama, rebase ou restablece, Git rexistra o anterior HEAD e punteiros SHA-1/SHA-256 de punta de rama dentro dun rexistro local chamado Rexistro de referencia (git reflog), e mantén os obxectos de confirmación orfos reais no disco durante polo menos de 14 a 90 días antes de que a recollida de lixo os elimine.

Receitas de recuperación de emerxencia Git paso a paso¶

Escenario 1: correches git push --force e sobreescribiu origin/main¶

1. Atopa o SHA de compromiso exacto origin/main apuntado á dereita antes do teu empuxe forzado:
   • Método A (comproba o teu reflog local de seguimento remoto): Executa este comando no terminal onde presionaches:

     git reflog show origin/main
     

     Verá unha saída como:

     a1b2c3d (HEAD -> main, origin/main) refs/remotes/origin/main@{0}: update by push
     9f8e7d6 refs/remotes/origin/main@{1}: fetch: fast-forward
     

     Aquí, 9f8e7d6 (origin/main@{1}) é o compromiso exacto origin/main estaba xusto antes de que a túa forza de forza o sobrescribise.
   • Método B (Pregúntalle a calquera compañeiro que non correse git pull aínda): Calquera compañeiro de traballo que buscou main hoxe aínda ten o historial de compromiso intacto no seu local origin/main rama.
   • Método C (consulta o rexistro de eventos da API REST de GitHub): Se o teu reflog local carece do estado remoto, consulta a API de eventos push de GitHub para ver o "before" SHA hash do evento forza-push:

     gh api /repos/OWNER/REPO/events --jq '.[] | select(.type=="PushEvent") | {actor: .actor.login, before: .payload.before, head: .payload.head, time: .created_at}'
     

2. Restaurar origin/main ao anterior compromiso SHA de forma segura:
   • Verifique que o commit parece correcto (git log -n 5 9f8e7d6), entón empurra ese SHA exacto de volta ao control remoto main rama usando --force-with-lease:

     git push --force-with-lease origin 9f8e7d6:refs/heads/main
     

Escenario 2: correches git reset --hard ou eliminou unha sucursal local antes de presionar¶

1. ** Corre git reflog no teu repositorio local:**

   git reflog --date=iso
   

2. ** Localiza o SHA de commit xusto antes do reset: entrada** (por exemplo, HEAD@{2}: commit: feat: add payment webhook), e crea unha nova rama de rescate apuntando directamente a ese SHA:

   git switch -c rescue-branch HEAD@{2}
   

3. E se perdeches un ficheiro non comprometido que ti git added (escenificado) e despois eliminado con git reset --hard?
   • No momento en que corres git add myfile.ts, Git comprime e escribe o contido completo dese ficheiro .git/objects/ como unha gota colgante, aínda que nunca correches git commit. Recupérao enumerando todos os blobs colgantes ordenados por tempo de modificación:

     git fsck --lost-found
     # Inspect the recovered blobs written into .git/lost-found/other/
     

Parte 4: Accidental terraform destroy ou almacenamento na nube eliminado (S3, EBS, máquinas virtuales)¶

Se unha canalización de infraestrutura como código (IaC) ou un comando manual da CLI comeza a derrubar os recursos da nube de produción:

1. Detén a execución con seguridade:
   • Se se executa localmente no teu terminal, preme Ctrl + C UNHA VEZ polo que Terraform remata a súa chamada á API actual e escribe o actualizado .tfstate arquivo limpa. Se se está a executar dentro de GitHub Actions, GitLab CI ou Terraform Cloud, fai clic en Cancelar Run e desactiva inmediatamente a función AWS/GCP IAM do corredor de CI na consola da nube para que fallen as eliminacións da API durante o voo. AccessDenied.
2. ** Fai unha copia de seguridade da corrente .tfstate arquivo inmediatamente:**
   • Descarga unha copia local do teu ficheiro de estado remoto (terraform state pull > emergency-backup.tfstate) e comprobe a versión do depósito de S3 no seu depósito de estado de Terraform para coller a versión de estado anterior de hai 10 minutos.
3. Consulta as redes de seguridade do provedor de nube "Soft-Delete" e da papeleira de reciclaxe:
   • Amazon S3 (con versión de cubo activada): Eliminación de ficheiros nun depósito de S3 con versión (aws s3 rm --recursive) non elimina un só obxecto; simplemente insire un Borrar marcador de cero byte enriba de cada obxecto. Eliminar os marcadores de eliminación (a través de operacións por lotes S3 ou un Python de 5 liñas boto3 script) para restaurar o 100 por cento dos seus ficheiros ao instante.
   • AWS EBS Volumes & RDS Snapshots (Papeleira de reciclaxe): Marque Papeleira de reciclaxe de AWS na consola, se está configurada, e marque as bóvedas de Copia de seguranza de AWS.
   • Google Cloud Platform (GCP) e Microsoft Azure: Os proxectos GCP eliminados e os grupos de recursos de Azure/Bóvedas de claves/Contas de almacenamento con Eliminación suave activada permanecen recuperables durante 7 a 30 días cun só clic de restauración na consola.

Como recuperar un Terraform roto .tfstate ficheiro de estado ou reimportar infraestrutura orfa¶

Cando a terraform apply ou accidental terraform destroy interrómpese durante o voo ou cando alguén elimina accidentalmente o ficheiro de estado remoto en S3/GCS, a súa infraestrutura de nube entra nun perigoso estado de división cerebral onde aínda existen algúns recursos en AWS/GCP mentres que outros faltan. .tfstate:

1. Recuperando un control remoto sobrescrito ou eliminado .tfstate Ficheiro de S3/GCS Versioning:
   • Nunca edite manualmente un JSON .tfstate ficheiro a man nun editor de texto a menos que todas as outras opcións fallasen, porque unha única non coincide "serial" ou "lineage" A cadea UUID impedirá que Terraform se aplique de novo.
   • Abre o teu depósito S3 (ou o depósito de Google Cloud Storage / a pestana Estados de Terraform Cloud Workspace) onde reside o backend remoto, fai clic na opción Mostrar versións na parte superior da consola S3 e busca o terraform.tfstate versión con marca de tempo xusto antes da mala execución, descárguea e repúxaa de forma segura como o novo estado actual:

     # Push a recovered historical state file back to the remote backend safely
     terraform state push recovered-pre-incident.tfstate
     

2. ** Romper un bloqueo de estado atascado (Error acquiring the state lock):**
   • Cando abortas un mal terraform destroy con Ctrl + C ou mata a un corredor de CI colgado, a táboa remota de DynamoDB ou o ficheiro de bloqueo GCS permanecen bloqueados polo ID do proceso morto.
   • Primeiro verifique no seu panel de control de CI e cos seus compañeiros de equipo que ningún outro proceso de Terraform aínda se está executando nese espazo de traballo e, a continuación, libere o bloqueo orfo usando o ID de bloqueo UUID impreso na mensaxe de erro:

     terraform force-unlock <LOCK_ID_UUID>
     

3. Reconstruíndo un ambiente parcialmente destruído sen recrear bases de datos supervivientes (terraform import):
   • Se a terraform destroy eliminou os seus equilibradores de carga de aplicacións sen estado (aws_lb) e os nodos de traballo ECS/EKS antes de detelos, é fácil de solucionar: simplemente executa terraform apply e Terraform recreará todas as redes sen estado e as capas de computación desde cero en 5 minutos mentres deixa intacta a súa base de datos RDS.
   • Se o teu ficheiro de estado perdeu a pista dunha base de datos con estado ou dun depósito S3 superviviente, utiliza un import {} bloque de configuración (Terraform 1.5+) ou terraform import aws_db_instance.prod_db my-rds-instance-id para vincular o recurso de nube existente de novo ao ficheiro de estado sen destruílo e executalo terraform plan para confirmar "0 to destroy" antes de aplicar.

Parte 5: Como comunicar unha interrupción ao teu xestor e levar a cabo unha autopsia sen culpa¶

Cando provocas un incidente de produción mentres traballas de forma remota, a túa reputación profesional defínese non polo propio erro, senón pola túa velocidade de transparencia, comunicación tranquila e corrección sistemática.

As 3 regras de ouro da comunicación de incidentes¶

1. Indique feitos, impacto e ETA sen ocultar, atrasar ou culpar: Informa do erro dentro dos 2 minutos posteriores ao descubrimento.
2. Separa "Mitigación" (Deter o sangrado) da "Corrección da causa raíz": En caso de emerxencia, o teu único obxectivo é restaurar o servizo (refacer a implementación incorrecta, fallar no clon da base de datos PITR ou desactivar a marca da función). Garda a refactorización de código profundo para mañá.
3. Publica actualizacións regulares dos latidos do corazón de 15 minutos na canle de incidentes para que os executivos e o servizo de atención ao cliente saiban que alguén ten o control.

Copiar e pegar o script de declaración de incidentes de Slack / Teams¶

[INCIDENTE SEV-1] Produción [Nome do servizo/base de datos] Impacto - Que pasou: At [HH:MM UTC], mentres se executa [brief technical action, e.g., a data migration script], un non intencionado [DELETE / config change / force-push] aplicouse á produción [database / service]. - Impacto actual do cliente: [e.g., Checkout API is returning 500 errors / User profile updates are paused]. - Mitigación inmediata en curso: 1. Escribe tráfico para [table/service] púxose en pausa para preservar a integridade dos datos. 2. Clonación de recuperación puntual (PITR). [HH:MM:SS UTC] (10 segundos antes do evento) está a funcionar actualmente [AWS RDS / GCP]. - Comandante do incidente: @[Your Name] (asistido por @[DBA/On-Call SRE]). - Próxima actualización: En 15 minutos ([HH:MM UTC]) ou tan pronto como o clon de recuperación estea en liña.

Lista de verificación de garantías de enxeñaría post-incidente (Para o teu Blameless Post-Mortem)¶

Cada erro humano na produción é en realidade unha brecha de deseño do sistema (se un único comando de terminal copiado e pegado pode deixar a produción sen unha barandilla, o sistema estaba esperando para fallar). Propón e implemente estas barandillas técnicas de formigón no seu documento post mortem ao día seguinte:

• ** Indicacións de produción de códigos de cores e prefixos (kube-ps1, psql .psqlrc):** Configure o seu cliente de shell e SQL para que calquera conexión a PRODUCTION mostra un vermello brillante [PROD-DB] e inicia cada sesión interactiva de PostgreSQL dentro de un BEGIN; bloque de transaccións por defecto (ou conxuntos SET default_transaction_read_only = on;).
• Activar safe-updates (--i-am-a-dummy) en clientes MySQL/MariaDB: Engadir safe-updates a [mysql] en -/.my.cnf polo que MySQL négase rotundamente a executalo UPDATE ou DELETE declaración que carece de a WHERE cláusula clave ou a LIMIT.
• Acende DeletionProtection = true en todas as bases de datos RDS de produción, depósitos S3 e recursos con estado de Terraform (lifecycle { prevent_destroy = true }).
• Activar as regras de protección de ramas de Git main / production: Desactivar Allow force pushes e Allow deletions en ramas protexidas en GitHub/GitLab polo que nin os administradores do repositorio non poden git push --force a main.
• Instale ganchos de exploración secreta previa á confirmación (gitleaks ou trufflehog) e GitHub Push Protection: Bloquear commits que conteñan AKIA, sk_live_, ou .env patróns antes localmente git commit incluso ten éxito.

Preguntas frecuentes¶

Seré despedido por soltar accidentalmente unha táboa de base de datos de produción ou causar unha interrupción do sitio?¶

Nas organizacións de enxeñería saudables que practican unha cultura de seguridade sen culpa (estándar nos equipos de tecnoloxía moderna, DevOps e SRE), os enxeñeiros non son despedidos por erros humanos honestos na produción, sempre que informen do incidente inmediatamente e axuden a restaurar o servizo. Os líderes de enxeñería recoñecen que se un desenvolvedor júnior ou senior tiña os permisos brutos e a falta de barandillas para soltar unha táboa de produción cun único comando sen revisar, a causa raíz é un fallo no control de acceso e ferramentas de implementación, non malicia. Na práctica, o enxeñeiro que acaba de experimentar esa interrupción de primeira man é agora a persoa máis segura do equipo con respecto a ese sistema. O único comportamento que leva constantemente á rescisión é tentar encubrir un evento de perda de datos, eliminar rexistros de auditoría ou mentir durante a investigación do incidente.

Por que non debería cambiar inmediatamente o meu tráfico de produción en directo á instancia de base de datos de recuperación puntual (PITR) recentemente restaurada?¶

Se só eliminou accidentalmente filas dunha única táboa (por exemplo, o `user_preferences` táboa) ás 14:00 UTC, e leva 20 minutos facer que un clon PITR restaurado ás 13:59:50 UTC, é posible que a súa base de datos de produción en directo seguise procesando miles de pedidos e pagos lexítimos de clientes novos no `orders` mesa entre as 14:00 e as 14:20 UTC. Se cambias cegamente todo o teu punto final de DNS de produción ao clon PITR das 13:59:50, eliminarás eses 20 minutos de pedidos de clientes novos. Pola contra, mantén en liña a base de datos principal (coas escrituras en pausa só na función rota) e exporta só as filas que faltan do clon PITR das 13:59:50 á táboa de produción en directo.

Se fago un repositorio público de GitHub privado dous minutos despois de presionar accidentalmente un .env ficheiro, aínda teño que xirar todas as claves da API?¶

Si, o 100 por cento desas chaves aínda deben ser revogadas e rotadas inmediatamente. Cada commit enviado a un repositorio público de GitHub emítese en tempo real a través da API pública de eventos de GitHub ("o Firehose") e indexada en segundos tanto por servizos de arquivo de seguridade lexítimos (como GHArchive) como por bots maliciosos de recollida de credenciais automatizadas que se executan 24 horas ao día, 7 días ao día en redes na nube. Cambiar a visibilidade do repositorio de Público a Privado dous minutos máis tarde non borra a copia que xa descargaron os scrapers automatizados.

Como fai git push --force-with-lease evitar cortes en comparación con git push --force?¶

Cando corres estándar `git push --force`, Git sobrescribe incondicionalmente a sucursal remota coa túa sucursal local, destruíndo silenciosamente calquera commit que un compañeiro de equipo empurra a esa rama mentres tanto. Cando usas `git push --force-with-lease` (e aínda mellor, `--force-if-includes`), Git comproba primeiro o servidor remoto para verificar que a punta da rama remota aínda coincide coa confirmación SHA exacta que obtivo a máquina local por última vez. Se un compañeiro de traballo ou unha canalización de CI enviou unha nova confirmación á rama remota desde a túa última recuperación, `--force-with-lease` aborta con seguridade cunha advertencia de "información obsoleta" en lugar de borrar o seu traballo.

Fontes comprobadas¶

• Instituto Nacional de Estándares e Tecnoloxía (NIST, Estados Unidos): NIST SP 800-61 Rev. 2 / Rev. 3 Computer Security Incident Handling Guide and Credential Compromise Containment.
• Amazon Web Services (AWS), Google Cloud Platform (GCP) e Documentación de Microsoft Azure (Estados Unidos): Arquitectura de RDS Automated Point-In-Time Recovery (PITR), Políticas de corentena de claves comprometidas de AWS IAM (AWSCompromisedKeyQuarantineV2), e S3 Versioning Delete-Marker Recovery.
• Grupo de desenvolvemento global de PostgreSQL e documentación de MySQL/Oracle (internacional): Logging de escritura anticipada de PostgreSQL (WAL), visibilidade de tuplas MVCC e recuperación de flashback de rexistro binario baseado en filas de MySQL.
• Documentación oficial de Git SCM e laboratorio de seguridade de GitHub (internacional): Git Reflog (git-reflog), Recuperación de obxectos colgantes (git-fsck), Reescritura da Historia (git-filter-repo), e Protección de inserción de dixitalización secreta.
• Asociación USENIX / SREcon e Google Site Reliability Engineering (SRE) Books (International): Managing Incidents, Emergency Rollback Triage, and Blameless Postmortem Culture.

Guías relacionadas¶

• Seguridade do traballo remoto de emerxencia e privacidade dos datos
• Estratexia 3-2-1 de copias de seguridade dos ordenadores e recuperación ante desastres
• Eliminación accidental de ficheiros e recuperación da unidade formateada
• Migración de crise de hospedaxe web e restauración de copias de seguridade
• Phishing e contas comprometidas
• Números de emerxencia