---
title: "31/08/2023 Suppression accidentelle d'enregistrements DNS - INC0086487"
canonical: "https://wiki.patientsknowbest.com/space/REL/4937121873/31%2F08%2F2023%20Suppression%20accidentelle%20d'enregistrements%20DNS%20-%20INC0086487"
format: markdown
---
| **Incident ouvert** | 31/08/2023 14:00 |
| --- | --- |
| **Incident clos** |  |

| ## <span style="color: #ffffff">Environnements touchés</span> |
| --- |

- [ ] Candidat à la libération (RC)
- [x] Bac à sable
- [x] Production britannique
- [x] Production de l'UE
- [x] Production EDU

| ## <span style="color: #ffffff">Références</span> |
| --- |

- **Référence PKB :** **<span style="color: #ff5630">FD144767</span>**
- **Numéro de référence de l'incident du pont de service : ****<span style="color: #ff5630">INC0086487</span>**

| ## <span style="color: #ffffff">Description du problème </span> |
| --- |

La suppression accidentelle des enregistrements DNS a rendu les environnements de production inaccessibles pour la plupart des clients.

| ## <span style="color: #ffffff">Impact</span> |
| --- |

Tous les services PKB accessibles via un nom de domaine ont été inaccessibles pendant 2 h 15. Certains clients utilisant des fournisseurs DNS ne respectant pas les TTL n'ont pas pu accéder à PKB pendant plus de 24 h.

| ## <span style="color: #ffffff">Chronologie et activité de résolution</span> |
| --- |

- 13h50 - Les enregistrements DNS sont supprimés en raison de l'exécution d'un script délétère sur un projet incorrect
- 13h55 - Le problème est identifié et le processus de restauration est lancé
- 13h57 - Restauration des archives terminée
- 14:43 - Une tentative est faite pour accélérer la propagation des enregistrements DNS (à ce stade, on pense toujours que la réplication se produit, car plusieurs serveurs DNS à travers le monde récupèrent à nouveau les enregistrements)
- 14:46
  - J'ai remarqué que lors de la recréation de zones dans Cloud DNS, Google Cloud a sélectionné des serveurs de noms différents de ceux connus du registraire, et a donc effectué des mises à jour du côté du registraire.
- 15:10 Nous soupçonnions que la propagation lente ou inexistante des enregistrements pouvait être causée par une mauvaise configuration DNSSEC
- 16h00 - Enregistrements DS corrigés pour correspondre à ce que le registraire publiait, caches vidés chez Cloudflare, Google, OpenDNS, la propagation a commencé immédiatement

| ## <span style="color: #ffffff">Enquêtes sur les causes profondes </span> |
| --- |

1. Un ingénieur infrastructure effectuait une tâche mineure consistant à modifier des entrées DNS. Le travail a été effectué, mais la console est restée ouverte. Peu après, l'ingénieur a effectué une autre opération impliquant la suppression de ressources cloud dans un environnement de test. La suppression a été effectuée dans la mauvaise console (celle laissée ouverte précédemment), entraînant la suppression des ressources DNS. Pourquoi a-t-il été possible de supprimer des composants d'infrastructure sans vérifications supplémentaires ?
  1. L'ingénieur a utilisé un indicateur appelé « auto-approbation », qui a forcé l'omission de la vérification préalable à la suppression.
  2. L'ingénieur avait accordé des droits d'accès excessifs à des infrastructures critiques
  3. Les infrastructures critiques ne bénéficiaient pas d’une protection explicite contre la suppression/modification
  4. L'infrastructure critique n'était pas gérée selon le processus normal d'utilisation d'une infrastructure sous forme de code (IaC) contrôlée par version.
2. Il a fallu deux heures pour rétablir le service en raison d'une mauvaise configuration DNSSEC. Pourquoi PKB n'a-t-il pas pu corriger cette erreur plus tôt ?
  1. Pas assez de documentation interne et d'expertise pour restaurer manuellement DNSSEC à partir de zéro
  2. La configuration DNS n'est pas entièrement contrôlée par le code car le registraire n'offre pas un bon support pour l'automatisation

| ## <span style="color: #ffffff">Activités de suivi et mesures d'atténuation</span> |
| --- |

Mesures d'atténuation pour les RCA :

1. Prévention des suppressions accidentelles et des modifications erronées des infrastructures critiques : nous mettrons en place une série de contrôles. Chacun de ces contrôles permettrait probablement d'éviter que cet accident ne se reproduise, mais nous en attendons des effets bénéfiques à plus grande échelle.
  1. Nous mettrons en place des contrôles qui rendront l’« approbation automatique » inutile.
  2. 
    1. Aucun utilisateur ingénieur (personas) ne disposera d'un accès permanent en écriture à l'infrastructure de production. Nous allons nous appuyer sur des comptes de service (SA) disposant d'autorisations d'accès spécifiques à certaines tâches. Les ingénieurs devront élever leurs autorisations en se faisant passer pour des SA disposant d'autorisations d'accès spécifiques et restreintes lors de l'exécution des travaux d'infrastructure.
    2. Dans les cas extrêmes où les ingénieurs eux-mêmes ont besoin d'autorisations élevées, nous les accorderons temporairement (en spécifiant un horodatage d'expiration) à l'aide de l'IaC
  3. Nous activerons la protection contre la suppression pour toutes les infrastructures critiques
  4. Nous investirons davantage pour faire passer le reste du système vers l'IaC
2. La configuration DNS sera documentée et automatisée.
  1. La documentation de configuration DNSSEC sera documentée.
  2. Nous passerons à un registraire de domaine qui permet une configuration DNS automatisée afin que l'ensemble de l'infrastructure DNS puisse être capturé dans IaC