Une sortie de service est incomplète lorsque l'export existe mais personne ne peut l'expliquer ou le restaurer. Commencez par les questions du futur opérateur : quels domaines et expéditeurs sont approuvés, quelles dépendances sont actives, pourquoi existe-t-il des exceptions et quelles modifications ont été autorisées ? Une exportation doit conserver ces réponses sans transférer de secrets ou de données personnelles inutiles dans une archive incontrôlée.
Définir la limite d'exportation
Répertoriez les inventaires des domaines et des expéditeurs, la configuration DNS et des politiques, les valeurs générées spécifiques au fournisseur, les exemples et l'historique des rapports, les conventions d'analyse, les attributions d'utilisateurs et de rôles, les exceptions, les approbations et les journaux de modifications. Enregistrez la plage horaire, les écarts connus et le fuseau horaire d’exportation. Conservez les dictionnaires de données et les identifiants qui lient une ligne de rapport à son fichier d'origine. Une capture d’écran d’un graphique constitue un contexte utile mais ne remplace pas les preuves sous-jacentes.
La structure du rapport agrégé est spécifiée dans RFC 9990; les tableaux de bord peuvent ajouter leur propre attribution ou normalisation. Conservez suffisamment de contenu brut pour distinguer les champs standard de l’interprétation du fournisseur. Ne considérez pas une étiquette de fournisseur familière comme une preuve que l'entreprise a approuvé un compte d'envoi particulier.
Séparer la configuration des informations d'identification
Identifiez quels éléments d'exportation sont des métadonnées opérationnelles sûres et lesquels sont des informations d'identification. DKIM enregistrements DNS publics et sélecteur les noms ne sont pas des clés de signature privées. Si le déplacement de clés privées est à la fois pris en charge et autorisé, utilisez un processus de transfert de secret approuvé séparément ; ne les placez pas dans ce lot de preuves générales. Lorsqu'un fournisseur n'exporte pas de clés, planifiez de nouvelles identités de signature et une transition contrôlée plutôt que de promettre une restauration à partir d'une exportation de clé publique.
Appliquez des contrôles d’accès et de conservation aux données des rapports et aux journaux d’audit. Une migration n’est pas une raison pour tout garder pour toujours. Demandez au propriétaire approprié d'approuver ce qui est conservé, qui peut l'ouvrir et quand il doit être supprimé. Faites une liste des éléments indisponibles, y compris l'historique d'audit ou les données brutes que le plan actuel ne peut pas exporter, avant la date d'annulation.
Vérifier une exportation sous forme de données
Supposons qu'une exportation autorisée contienne un inventaire de l'expéditeur, un historique des modifications et un index du rapport. Un manifeste enregistre chaque nom de fichier, le nombre d'octets et le résumé SHA-256. Une lecture ultérieure correspondant à ces résumés fiables établit la cohérence des octets pour les fichiers répertoriés, sans que chaque ligne requise ait été exportée. Un fichier d'exception omis pourrait laisser tous les hachages répertoriés correspondant alors que l'archive est opérationnellement incomplète.
Il s'agit d'un exemple hypothétique d'intégrité et d'exhaustivité, et non d'une archive générée ou d'une vérification de hachage exécutée. Exigez à la fois une vérification du manifeste et un rapprochement avec un inventaire source daté. Une inadéquation nécessite une enquête plutôt qu’un remplacement automatique du résumé fiable.
Pour une sortie réelle, rapprochez le nombre de lignes exportées avec un inventaire source daté et des exclusions de documents. Ouvrez les fichiers à l'aide du workflow de remplacement. Confirmez que les valeurs temporelles, les noms de domaine, les identifiants uniques et les relations survivent. Testez une tâche de récupération : étant donné un ID d'exception, le nouvel opérateur peut-il trouver son propriétaire, son approbation, son expiration et son expéditeur concerné ? Enregistrez le résultat plutôt que de marquer un téléchargement zip comme succès.
Conserver l'archive utile après la fin de l'accès
NIST SP 800-34 Rév. 1 décrit la planification d'urgence, les tests et la maintenance. En appliquant ces directives générales ici, nommez un dépositaire des archives et testez l'accès sans dépendre du service de départ. Stockez le manifeste et une explication du processus d'exportation avec les données. Conservez une copie contrôlée de manière indépendante lorsque la politique de conservation approuvée le permet.
Avant la fermeture, obtenez l'approbation du propriétaire sur l'historique manquant, la surveillance des remplacements et toutes les dépendances qui ne peuvent pas être restaurées à partir de l'exportation. Conserver l’ancien compte uniquement pour un objectif et une durée définis et autorisés. Le dossier de sortie final doit indiquer ce qui a été exporté, ce qui a été vérifié, ce qui reste indisponible et qui a accepté l'écart. N’appelez pas une somme de contrôle vérifiée un test complet de reprise après sinistre.