L’essentiel
1. Chiffrement et protection des données à caractère personnel
1.1 Le chiffrement constitue une mesure essentielle pour rendre les données à caractère personnel incompréhensibles à toute personne non autorisée. Les recommandations issues du document « PIA, les bases de connaissances – Édition février 2018 » insistent sur l’usage d’algorithmes publics réputés forts, de certificats d’authentification et d’outils certifiés ou qualifiés par l’ANSSI, en cohérence avec les exigences du Référentiel Général de Sécurité (RGS). L’objectif est de garantir la confidentialité, mais aussi la disponibilité et l’intégrité des éléments permettant de récupérer les secrets (mots de passe administrateurs, supports de recouvrement, etc.).
1.2 La première étape consiste à déterminer précisément ce qui doit être chiffré : disque dur entier, partition, conteneur, fichiers spécifiques, données d’une base de données ou encore un canal de communication. Ce choix dépend de la forme de stockage, des risques identifiés et des performances attendues. Le type de chiffrement – symétrique ou asymétrique – doit être sélectionné en fonction du contexte et des menaces, en privilégiant des solutions conformes au RGS et bénéficiant d’une preuve de sécurité.
1.3 Les bonnes pratiques générales recommandent de recourir à des dispositifs de protection des clés privées, à des modules de chiffrement et de déchiffrement certifiés, ainsi qu’à des mécanismes de gestion des secrets robustes. Il est également nécessaire de mettre en place des mesures pour garantir la disponibilité, l’intégrité et la confidentialité des éléments de recouvrement (par exemple les CD de recouvrement ou les mots de passe d’administration), afin de ne pas créer de nouveaux points de vulnérabilité.
2. Spécificités du chiffrement symétrique
2.1 Dans le cas du chiffrement symétrique, chaque clé ne doit être utilisée que pour un seul usage afin de limiter les risques de compromission et de corrélation entre différents traitements. Les mécanismes doivent être reconnus par les organisations compétentes et conformes au RGS. L’algorithme AES est explicitement recommandé, avec une taille de bloc d’au moins 128 bits et un mode opératoire de chiffrement non déterministe, tel qu’un mécanisme CBC avec vecteur d’initialisation aléatoire.
2.2 La longueur des clés cryptographiques doit être adaptée à la durée d’utilisation prévue (par exemple au moins 128 bits pour une confidentialité assurée jusqu’en 2020) et exclure les clés faibles. La gestion des clés doit être formalisée par une procédure écrite, décrivant la génération, la distribution, le stockage, la rotation et la révocation des clés, afin d’assurer une traçabilité et une maîtrise complète du cycle de vie cryptographique.
3. Spécificités du chiffrement asymétrique (clé publique)
3.1 Pour le chiffrement asymétrique, chaque bi-clé (clé publique / clé privée) doit également être réservée à un seul usage. Les mécanismes doivent disposer d’une preuve de sécurité et être conformes au RGS, par exemple RSAES-OAEP, avec des longueurs de clés adaptées à la durée de confidentialité recherchée. La génération des clés doit respecter les prescriptions du RGS, idéalement via un prestataire de service de certification électronique (PSCE) référencé.
3.2 La vérification des certificats électroniques est un point critique : il convient de contrôler l’indication d’usage, la validité, l’absence de révocation et la chaîne de certification à tous les niveaux. La sécurité de la génération et de l’utilisation des clés doit être proportionnée à leur position dans la hiérarchie des clés : stockage protégé pour les clés utilisateurs (droits d’accès restrictifs, mot de passe, carte à puce), mesures renforcées pour les clés racines (stockage en coffre-fort, partage de secrets entre plusieurs détenteurs, etc.).
3.3 La gestion des clés doit être formalisée dans une politique de certification détaillant les responsabilités, les mécanismes d’identification et d’authentification, les exigences opérationnelles sur le cycle de vie des certificats, les mesures de sécurité techniques et non techniques, les profils de certificats, les listes de révocation et les modalités d’audit de conformité.
4. Chiffrement de matériels, bases de données, partitions et fichiers
4.1 Le chiffrement de matériels vise à rendre les données inintelligibles en cas de récupération d’un poste de travail, d’un serveur ou d’un support amovible. Il peut être mis en œuvre au niveau matériel (surface du disque dur) ou au niveau du système d’exploitation (partition ou conteneur). Les recommandations citent l’usage de disques durs chiffrables avec technologie SED, ou de logiciels comme dm-crypt sous Linux, FileVault sous MacOS ou VeraCrypt sous Windows. Il est conseillé de privilégier les dispositifs ne stockant pas les clés sur le matériel à chiffrer, sauf si un stockage sécurisé (par exemple une puce TPM) est mis en œuvre.
4.2 Pour le chiffrement de bases de données, l’objectif est de réduire les risques liés au vol de serveur, à un accès physique illégitime ou à un accès direct aux données par un administrateur. Selon les risques, il est possible de chiffrer l’espace de stockage (niveau matériel, système d’exploitation ou base de données) ou la donnée elle-même via l’application, afin de garantir la confidentialité vis-à-vis des administrateurs. Le chiffrement par la base de données permet, dans des équipes cloisonnées, de réserver l’accès aux seuls administrateurs de base de données, sans exposition aux administrateurs système.
4.3 Le chiffrement de partitions ou de conteneurs répond aux risques de récupération de matériel, d’accès physique illégitime ou d’accès direct aux données par un administrateur. Il s’effectue au niveau du système d’exploitation (partition, répertoire, fichier) ou via un logiciel spécialisé de conteneur chiffré. Les recommandations mentionnent des outils comme VeraCrypt ou Zed! pour ce type de protection.
4.4 Le chiffrement de fichiers isolés vise à protéger des fichiers stockés ou des pièces jointes à des courriers électroniques. Les solutions citées incluent ZoneCentral, des logiciels utilisant la librairie Security BOX Crypto 6.0, AxCrypt ou Gnu Privacy Guard (GPG). À défaut, un outil de compression avec chiffrement par mot de passe, tel que 7-Zip (chiffrement AES), ou une solution matérielle comme une carte Bull Trustway PCI cryptographic card, peuvent être utilisés.
5. Chiffrement des courriers électroniques et des canaux de communication
5.1 Le chiffrement de courriers électroniques a pour objectif de rendre les messages inintelligibles en cas d’interception. Il est recommandé de chiffrer les messages à l’aide de logiciels tels que Gnu Privacy Guard (GPG), en s’assurant de la bonne gestion des clés et certificats associés.
5.2 Le chiffrement d’un canal de communication permet de protéger les flux de données contre l’interception. Il s’agit de chiffrer le canal entre un serveur authentifié et un client distant, en utilisant un certificat d’authentification de serveur conforme au RGS et le protocole TLS (anciennement SSL) dans ses dernières versions. Il est recommandé d’exiger un mot de passe pour l’usage de la clé privée et de protéger son accès par des droits très restrictifs. Des alternatives ou compléments incluent SSH pour la mise en place de tunnels sécurisés (VPN) ou des solutions de chiffrement IP (VPN-IPSec).
6. Cloisonnement des données dans le système d’information
6.1 Le cloisonnement des données vise à réduire la possibilité de corréler des données à caractère personnel et de provoquer une violation globale. Il s’agit d’identifier les données propres à chaque métier, de les séparer logiquement et de limiter les accès. Les bonnes pratiques recommandent d’identifier les seules données utiles à chaque processus métier et de prévoir un accès des personnes aux seules données nécessaires. Par exemple, un service de statistiques n’a pas besoin d’accéder aux noms et prénoms.
6.2 La séparation logique des données utiles à chaque processus repose sur des droits d’accès différenciés selon les métiers (gestion de la paie, des congés, de l’avancement de carrière, etc.) et, le cas échéant, sur des environnements informatiques dédiés pour les systèmes traitant des données les plus sensibles. Des vérifications régulières doivent s’assurer que les données restent correctement cloisonnées et qu’aucun destinataire ou interconnexion non autorisé n’a été ajouté.
7. Contrôle d’accès physique aux locaux et équipements
7.1 Le contrôle d’accès physique a pour objectif de limiter les risques d’accès non autorisé aux données à caractère personnel par la présence physique dans les locaux. Il repose sur la distinction de zones selon les risques : zone ouverte au public (accueil, salle d’attente, réunion), zone réservée au service (bureaux où sont traitées les données) et zone de sécurité (serveurs, stations d’administration, éléments actifs du réseau, équipements d’alimentation et de distribution d’énergie, équipements réseau et de téléphonie).
7.2 Une liste des personnes autorisées (visiteurs, employés, habilités, stagiaires, prestataires) doit être tenue à jour pour chaque zone, avec un réexamen régulier des droits d’accès, notamment pour les zones de sécurité. Les moyens d’authentification des collaborateurs doivent être proportionnels aux risques : simple reconnaissance à l’accueil pour les risques faibles, portillons, badges de proximité avec photographie ou numéro d’identification personnel pour les zones réservées ou de sécurité.
7.3 Les visiteurs (personnes en réunion, prestataires externes, auditeurs) doivent être authentifiés selon le niveau de risque : absence d’authentification pour les risques faibles, mais accueil dans une plage horaire prédéfinie, vérification de la pièce d’identité et remise d’un badge spécifique limité à la durée de la visite pour les risques élevés. Les actions à entreprendre en cas d’échec d’authentification (refus d’accès, alerte de la sécurité) doivent être définies.
7.4 La conservation de traces d’accès, après information des personnes concernées, est recommandée : enregistrement de l’identité, de la date et de l’heure d’entrée et de sortie, tenue d’un journal des accès sur une période limitée (par exemple trois mois). Les visiteurs doivent être accompagnés en dehors des zones d’accueil par une personne de l’organisme. Les zones les plus sensibles doivent être protégées par des portes verrouillées, digicodes, vidéophones, renouvellement régulier des codes, signalétique claire, sécurisation des ouvrants (barreaux, portes renforcées).
7.5 Des dispositifs d’alerte en cas d’effraction (détection d’ouverture, détection d’effraction, remontée centralisée des alertes, vidéosurveillance des zones sensibles) complètent le dispositif. Il est également recommandé de prévoir des moyens de ralentir les personnes ayant pénétré dans une zone interdite et des moyens d’intervention permettant un délai d’action inférieur au temps nécessaire pour quitter la zone.
8. Contrôle d’intégrité des données
8.1 Le contrôle d’intégrité vise à être alerté en cas de modification non désirée ou de disparition de données à caractère personnel. Les moyens incluent les fonctions de hachage, les codes d’authentification de message (MAC), la signature électronique et les mécanismes de prévention des injections SQL ou de scripts. Il convient d’identifier les données dont l’intégrité doit être contrôlée et de choisir un moyen adapté au contexte, aux risques et à la robustesse attendue.
8.2 Les fonctions de hachage permettent de générer une empreinte (hash) pour traiter les risques liés aux erreurs ; les MAC traitent les risques d’erreurs et de modification par toute personne ignorant la clé ; la signature électronique traite les risques d’erreurs et de modification par toute personne autre que le signataire. Le moment d’application de la fonction et celui du contrôle doivent être définis selon le processus métier (par exemple empreinte à la saisie et à l’affichage, avec alerte en cas de divergence et restauration à partir des sauvegardes).
8.3 Lorsque les données sont envoyées dans une base de données, des mesures d’analyse doivent prévenir les attaques par injection SQL ou de scripts : empêcher la saisie de caractères spéciaux ou de commandes SQL, filtrer ou encoder les données avant enregistrement, limiter le volume de données saisissables.
9. Fonctions de hachage, MAC et signature électronique
9.1 Pour les fonctions de hachage, il est recommandé d’utiliser des mécanismes conformes au RGS, tels que SHA-256, pour calculer une empreinte des données. Cette empreinte peut être transmise par un canal différent ou après signature électronique pour vérifier l’intégrité lors de la réception (par exemple par courrier électronique), ou stockée de manière sécurisée pour des contrôles ultérieurs (sauvegardes, archivage, stockage).
9.2 Pour les codes d’authentification de message, les mécanismes doivent être reconnus et disposer d’une preuve de sécurité. Le RGS recommande par exemple le CBC-MAC « retail » utilisant l’algorithme AES avec deux clés distinctes (une pour la chaîne CBC, une pour le surchiffrement « retail »).
9.3 La signature électronique impose de n’employer chaque bi-clé que pour un seul usage et de recourir à des algorithmes publics réputés forts. Les outils de création et de vérification de signature doivent être certifiés ou qualifiés par l’ANSSI au niveau de robustesse attendu. Les mécanismes recommandés incluent RSA-SSA-PSS ou ECDSA avec les courbes P-256, P-384, P-521, B-283, B-409 ou B-571. Les clés doivent être générées conformément au RGS, idéalement via un prestataire de certification électronique référencé pour un usage de signature.
9.4 Des mécanismes de vérification des certificats électroniques doivent être mis en place (contrôle de l’usage, de la validité, de la non-révocation et de la chaîne de certification). La sécurité de la génération et de l’utilisation des clés doit être cohérente avec leur niveau dans la hiérarchie, et la gestion des clés doit être formalisée dans une politique de certification détaillée. Dans le cas d’une carte à puce comme dispositif de création de signature, l’usage d’un lecteur avec PIN-pad intégré est recommandé pour saisir le code d’activation sans qu’il transite par l’ordinateur ou la borne publique.
10. Contrôle des accès logiques et gestion des privilèges
10.1 Le contrôle des accès logiques vise à limiter les risques d’accès non autorisé aux données à caractère personnel par voie électronique. Il repose sur la gestion des profils utilisateurs, les mécanismes d’authentification, la politique de mots de passe et la journalisation. Les profils doivent être gérés en séparant les tâches et domaines de responsabilité, de préférence de manière centralisée, en appliquant les principes du besoin d’en connaître et du moindre privilège.
10.2 Chaque personne ayant un accès légitime (employés, contractants, tiers) doit disposer d’un identifiant unique. L’usage d’identifiants génériques ou partagés ne doit être toléré qu’exceptionnellement, avec validation hiérarchique et mise en place de moyens de traçabilité (fiche de présence, main courante des actions). L’accès aux outils et interfaces d’administration doit être limité aux personnes habilitées, et l’utilisation des comptes à privilèges élevés (notamment les comptes « administrateurs ») doit être restreinte aux opérations qui le nécessitent.
10.3 Les comptes administrateurs doivent être individuels, avec un mot de passe propre, et réservés aux tâches d’administration. Les administrateurs doivent utiliser un compte à droits limités pour les activités exposées (messagerie, navigation Internet). Les informations liées à l’utilisation des privilèges doivent être journalisées, et une revue annuelle des privilèges doit permettre de supprimer les comptes non utilisés et de réaligner les droits sur les fonctions réelles. Les droits des personnes quittant l’organisme ou changeant de poste doivent être retirés ou ajustés sans délai, avec une date d’expiration pour les comptes temporaires.
11. Authentification et gestion des authentifiants
11.1 L’authentification des personnes souhaitant accéder aux données doit être adaptée au contexte, au niveau de risque et à la robustesse attendue. Pour des risques faibles, un mot de passe peut suffire ; pour des risques plus élevés, une authentification forte est nécessaire (boîtier OTP, envoi partiel de mot de passe par SMS, carte avec code PIN, certificat électronique, etc.). Les mots de passe ne doivent jamais apparaître en clair dans les programmes, fichiers, scripts, journaux ou à l’écran lors de la saisie.
11.2 Les actions à entreprendre en cas d’échec d’authentification doivent être définies (blocage du compte après un certain nombre d’échecs, augmentation du temps d’attente entre tentatives). Les accès logiques doivent être journalisés. L’authentification par identifiant et mot de passe doit être limitée au contrôle d’accès au poste de travail, tandis que le poste lui-même doit être authentifié auprès des systèmes distants via des mécanismes cryptographiques.
11.3 Une politique de mots de passe doit être adoptée, mise en œuvre et contrôlée automatiquement lorsque possible, et les utilisateurs doivent y être sensibilisés. Les mots de passe doivent comporter au moins huit caractères, inclure au minimum trois types de caractères (majuscules, minuscules, chiffres, caractères spéciaux), être renouvelés en cas de doute de compromission et, éventuellement, périodiquement. Il est déconseillé de réutiliser les cinq derniers mots de passe, d’utiliser le même mot de passe pour des accès différents ou de choisir des mots de passe liés à la personne (nom, date de naissance).
11.4 Une politique spécifique doit s’appliquer aux mots de passe des administrateurs, en conformité avec la Délibération n° 2017-012 du 19 janvier 2017. Les logiciels doivent être configurés pour ne jamais retenir ces mots de passe, et un nombre maximal de tentatives doit déclencher une alerte et un blocage. Les mots de passe par défaut des applications ou systèmes doivent être modifiés immédiatement après installation. Chaque compte utilisateur doit être créé avec un mot de passe initial aléatoire unique, transmis de manière sécurisée (canaux séparés, « case à gratter ») et à changer dès la première connexion.
11.5 Les informations d’authentification (mots de passe, clés privées, certificats) doivent être stockées de manière à n’être accessibles qu’aux utilisateurs autorisés, avec des droits d’accès minimaux et, si nécessaire, un chiffrement des fichiers contenant les mots de passe. Les authentifiants d’administration doivent être placés sous séquestre dans un coffre ou une armoire fermée à clé et tenus à jour. En cas de départ d’un administrateur, ses comptes individuels doivent être désactivés et les mots de passe d’administration qu’il connaissait doivent être changés.
11.6 Lorsque de nombreux mots de passe ou secrets doivent être gérés, des solutions d’authentification centralisée, de mots de passe à usage unique ou de coffres-forts sécurisés sont recommandées (mot de passe maître robuste, stockage sécurisé, masquage, résistance aux attaques, fermeture automatique). Des moyens mnémotechniques peuvent aider à créer des mots de passe complexes (premières lettres d’une phrase, majuscules sur les noms, ponctuation, chiffres pour les nombres). Une vigilance particulière est requise pour supprimer toute donnée d’authentification biométrique dans les dispositifs de contrôle d’accès.
12. Durées de conservation et archivage
12.1 La gestion des durées de conservation vise à respecter les articles 6 et 36 de la loi informatique et libertés et l’article 5.1(e) du RGPD, en s’assurant que les données à caractère personnel ne sont pas conservées plus longtemps que nécessaire. Pour chaque catégorie de données, des durées limitées et adaptées à la finalité du traitement et aux contraintes légales doivent être définies, en distinguant les données courantes, les données archivées (accès restreint), les traces fonctionnelles et les journaux techniques (logs).
12.2 Le traitement doit permettre de détecter la fin de la durée de conservation, par exemple via un mécanisme automatique basé sur la date de création ou de dernier usage, et d’afficher la date à laquelle la donnée doit être supprimée. Il doit également permettre de supprimer effectivement les données en fin de durée, avec un moyen approprié aux risques pour les libertés et la vie privée. La suppression ne doit pas se limiter à un effacement logique laissant la donnée lisible dans la base.
12.3 Une bonne pratique consiste à définir une durée de conservation intermédiaire : la donnée reste accessible à tous pendant une période donnée, puis uniquement à une liste restreinte de personnes (par exemple un service contentieux). Une fois la durée atteinte, et sous réserve d’un éventuel archivage intermédiaire, les données doivent être supprimées sans délai, y compris les traces et journaux techniques. Une fonctionnalité automatisée d’archivage/effacement est recommandée, avec éventuellement la possibilité de prolonger la durée lorsque le contexte le permet, la suppression restant la règle par défaut.
12.4 De manière générale, la finalité des traitements ne justifie pas la conservation de données en prévision d’actions de police ou de justice au-delà de ce que prévoient la loi informatique et libertés et le RGPD, même si certains secteurs imposent des durées spécifiques (opérateurs de télécommunication, passagers de vols aériens, etc.). La réduction de la quantité de données traitées et disponibles, via l’archivage et la purge, permet de limiter les impacts en cas de vol ou de diffusion accidentelle de la base.
13. Éloignement des sources de risques
13.1 L’éloignement des sources de risques vise à éviter que des sources humaines ou non humaines portent atteinte aux données à caractère personnel. Les bonnes pratiques recommandent de placer les produits dangereux (inflammables, combustibles, corrosifs, explosifs, aérosols, humides, etc.) dans des lieux de stockage appropriés et éloignés des zones où sont traitées les données, et d’éviter les zones géographiques dangereuses (zones inondables, proximité d’aéroports, zones d’industries chimiques, zones sismiques ou volcaniques).
13.2 Le stockage des données dans un État étranger ne doit être envisagé que si des garanties assurent un niveau de protection suffisant : transfert vers un pays reconnu comme « adéquat » par la Commission européenne (par exemple Canada, Suisse, Argentine, territoires de Guernesey, Jersey, Isle of Man), signature de clauses contractuelles types approuvées par la Commission, adoption de Binding Corporate Rules (BCR) au sein d’un groupe, adhésion au Privacy Shield pour certains transferts vers les États-Unis (dans le cadre juridique applicable), ou invocation d’une des exceptions prévues par l’article 69 de la loi informatique et libertés. Dans tous les cas, le responsable de traitement demeure responsable de la sécurité des données et doit s’assurer du niveau de sécurité du stockage.
14. Exercice des droits de limitation du traitement et d’opposition
14.1 L’exercice des droits de limitation du traitement et d’opposition doit être conforme à l’article 38 de la loi informatique et libertés et aux articles 18 et 21 du RGPD. Il s’agit de garantir aux personnes la possibilité de s’opposer à l’utilisation de leurs données, de demander le « gel » du traitement le temps d’en vérifier la légitimité, et de vérifier que le traitement ne relève pas d’une exception (obligation légale, motifs légitimes et impérieux, droits en justice, intérêt public).
14.2 Les moyens pratiques permettant l’exercice du droit d’opposition doivent être définis, accessibles rapidement (délai maximal de deux mois), dans une forme similaire à celle du traitement (voie postale et/ou électronique), sans démarches dissuasives ni frais pour les personnes concernées. Il convient de s’assurer que le droit d’opposition pourra toujours s’exercer, en prévoyant des solutions de secours si les moyens principaux deviennent inopérants.
14.3 L’intéressé doit être mis en mesure d’exprimer son choix avant la validation définitive de ses réponses, conformément à l’article 96 du décret informatique et libertés. Les demandes sur place doivent permettre de vérifier l’identité des demandeurs et des personnes mandatées. Les demandes par voie postale doivent être signées, accompagnées de la photocopie d’un titre d’identité (non conservée sauf nécessité de preuve) et préciser l’adresse de réponse. Les demandes électroniques doivent être transmises via un canal chiffré, accompagnées d’un titre d’identité numérisé (noir et blanc, faible définition, fichier chiffré), et ne pas être conservées au-delà du besoin de preuve.
14.4 Le motif légitime des personnes exerçant leur droit d’opposition doit être apprécié, sauf pour la prospection ou certains traitements de recherche en santé où l’opposition est discrétionnaire. Tous les destinataires du traitement doivent être informés des oppositions exercées, conformément à l’article 97 du décret informatique et libertés. Le droit à la limitation permet, en complément, d’exiger le gel du traitement à titre conservatoire.
14.5 Pour les traitements par téléphone, un mécanisme doit permettre de signifier l’opposition (par exemple en appuyant sur une touche). Pour les formulaires électroniques, des cases à décocher (opt-out) ou des mécanismes de suppression de compte doivent être prévus. Pour les courriers électroniques, l’expéditeur doit être clairement identifié, le contenu en rapport avec l’objet, et une opposition doit être possible en répondant au message ou via un lien dédié, sans nécessiter d’authentification pour la désinscription.
14.6 Pour les objets connectés et applications mobiles, des paramètres « Vie privée » doivent être proposés, accessibles dès le premier démarrage et à tout moment via un menu spécifique. L’utilisateur doit pouvoir s’opposer à la collecte de données particulières, être prévenu lorsque l’application fonctionne en arrière-plan, lorsque le micro « écoute » ou lorsque la localisation est collectée, et pouvoir s’y opposer. Les utilisateurs mineurs doivent être pris en compte (dispositif de contrôle parental, exclusion des moins de 13 ans de tout profilage automatisé). Toute collecte doit cesser effectivement si le consentement est retiré. Pour les recherches sur des prélèvements biologiques identifiants (ADN), les personnes concernées par un traitement ultérieur différent doivent pouvoir s’y opposer sans motif légitime.
15. Exercice des droits de rectification et d’effacement
15.1 Les droits de rectification et d’effacement doivent respecter l’article 40 de la loi informatique et libertés et les articles 16, 17 et 19 du RGPD. Ils garantissent aux personnes la possibilité de rectifier, compléter, mettre à jour, verrouiller ou supprimer leurs données, sous réserve des exceptions (sûreté de l’État, défense, sécurité publique, liberté d’expression et d’information, obligation légale, intérêt public, santé publique, recherche scientifique ou historique, statistiques, droits en justice).
15.2 Les moyens pratiques d’exercice du droit de rectification doivent être définis, avec un traitement rapide (moins de deux mois), dans une forme similaire à celle du traitement, sans frais ni démarches dissuasives. Il convient de s’assurer que les droits de rectification et d’effacement pourront toujours s’exercer, en prévoyant des solutions de secours si les mécanismes principaux deviennent indisponibles.
15.3 L’identité des demandeurs doit être vérifiée : signature et photocopie de titre d’identité pour les demandes postales (non conservée sauf besoin de preuve), titre d’identité numérisé pour les demandes électroniques (canal chiffré, noir et blanc, faible définition, fichier chiffré), vérification sur place pour les demandes physiques, y compris pour les mandataires ou héritiers. La véracité des rectifications demandées doit être contrôlée, et l’effacement effectif des données à supprimer doit être garanti.
15.4 Une confirmation doit être fournie aux demandeurs, et les destinataires ayant reçu les données doivent être informés des rectifications ou effacements. À la suite d’une demande d’effacement, l’utilisateur doit être informé des données qui seraient néanmoins conservées (contraintes techniques, obligations légales). Le droit à l’oubli pour les mineurs impose qu’un internaute de moins de 18 ans au moment de la publication ou de la création d’un compte en ligne puisse demander l’effacement, dans les meilleurs délais et sans autre motif, des données le concernant, sous réserve des exceptions prévues par le droit applicable.
PIA, les bases de connaissances – extraits sur chiffrement, contrôle d’intégrité, accès logiques et durées de conservation (Édition février 2018)
Type d’acte, par exemple : décret, arrêté, loi, ordonnance, délibération, recommandation, circulaire, instruction, avis, décision, communiqué, rapport, question ministérielle, réponse ministérielle, autre
Guide
Autorité / organisme : Reprendre l’autorité, le ministère, l’institution, l’organisme, l’autorité administrative indépendante ou autorité ayant rendu ce texte officiel
CNIL
Date du texte sous la forme jour mois année, exemple de sortie : 14 avril 2026
1 février 2018
Numéro exact du texte sauf si non indiqué
Délibération n° 2017-012 du 19 janvier 2017
Variantes exactes de recherche :
PIA bases de connaissances chiffrement intégrité accès logiques durées de conservation
Délibération n° 2017-012 du 19 janvier 2017
délibération 2017-012
délibération n 2017-012
délibération N° 2017-012
délibération n° 2017-012 du 19 janvier 2017
Résumé :
Ces extraits du guide « PIA, les bases de connaissances » détaillent les bonnes pratiques de chiffrement (symétrique, asymétrique, de matériels, bases de données, partitions, fichiers, canaux), de contrôle d’intégrité (hachage, MAC, signature électronique), de contrôle des accès logiques (gestion des privilèges, authentification, politique de mots de passe) et de définition de durées de conservation limitées, en conformité avec la loi Informatique et Libertés, le RGPD et le référentiel général de sécurité. Ils précisent les objectifs, les mesures recommandées et les références normatives associées.
RGPD & protection des données
Approfondir ce sujet :