Organigramme du processus de demande d'accès aux données (demande de révocation)
Organigramme du processus de demande d'accès aux données : indiquez l'objectif, lisez la classification de l'ensemble de données, laissez le propriétaire des données décider, effectuez les vérifications des données personnelles, accordez…
Qu'est-ce que le processus organigramme du processus de demande d'accès aux données (demande de révocation) ?
Les demandes de données sont généralement traitées comme s'il s'agissait de demandes de logiciels. Un ticket arrive demandant l'accès à l'entrepôt, celui qui détient les informations d'identification l'accorde, et quelqu'un qui avait besoin d'une table pour répondre à une question finit par pouvoir lire tous les schémas du cluster, y compris ceux contenant les salaires, les identifiants des patients ou les numéros de carte. Trois habitudes causent la plupart des dégâts. L'approbateur est choisi par celui qui peut techniquement accorder l'accès plutôt que par celui qui est responsable des données. La requête nomme un système au lieu d'un objectif, il n'y a donc rien pour tester le moindre privilège. Et la subvention n'a pas de date de fin, elle survit donc au projet, puis au changement d'équipe et parfois à l'emploi. L'accès aux données est également le seul type d'accès où une réponse plus petite est presque toujours disponible (une colonne masquée, un filtre au niveau des lignes, un tableau pré-agrégé) et où personne ne la propose, car l'offrir prend plus de temps que d'accorder la table brute. Le résultat est un domaine dans lequel personne ne peut dire qui peut lire quoi, et aucune demande individuelle n’a jamais été déraisonnable.
Ce graphique concerne les ensembles de données, pas les comptes. Si quelqu'un déjà en poste a besoin d'une candidature supplémentaire et que la question est de savoir qui l'approuve et qui la provisionne, il s'agit du processus général de demande d'accès chez /fr/templates/organigramme-processus-demande-acces, et la version pilotée par un événement de rejoint ou de déménagement dans le système RH est chez /fr/templates/organigramme-du-processus-de-demande-d-acces-des-employes-menuisier-et-demenageur. La création, la modification et la désactivation de l'identité elle-même (le compte, le groupe d'annuaire, la licence) font partie du processus de provisionnement des utilisateurs chez /fr/templates/organigramme-du-processus-de-provisionnement-des-utilisateurs-rejoindre-deplacer-quitter ; tout ici suppose que le demandeur possède déjà un compte fonctionnel et demande uniquement ce que ce compte peut lire. Il ne s'agit pas non plus d'une demande extérieure à l'organisation : un individu demandant une copie de ses propres données personnelles déclenche une obligation légale avec sa propre horloge, ses propres contrôles d'identité et ses propres motifs de refus, et qui est tirée chez /fr/templates/organigramme-de-demande-de-personne-concernee-rgpd-dsar-de-la-reception-a-la-cloture. Et si les données sont déjà arrivées quelque part où elles n’auraient pas dû, ce n’est absolument pas le bon tableau : le confinement, le test de risque pour les individus et la décision de notification dans les 72 heures sont chez /fr/templates/organigramme-du-processus-de-reponse-aux-violations-de-donnees-horloge-rgpd-de-72-heures. Ce qui reste ici est restreint et spécifique : une personne interne, un ensemble de données nommé, un objectif déclaré et un propriétaire qui décide.
Les décisions que la plupart des procédures écrites d’accès aux données laissent à l’habitude sont ici explicitement tirées. « Catalogue avec un propriétaire nommé ? » est placé avant toute évaluation, car un ensemble de données sans propriétaire ne peut être approuvé par personne, et la position honnête dans la plupart des organisations est que la première requête adressée à une table est ce qui la classe finalement ; la branche No revient en boucle via le catalogage plutôt que de transmettre le message à celui qui a construit le pipeline. « De quel accès le but a-t-il besoin ? » est une branche à trois voies plutôt qu'un oui ou un non, donc l'itinéraire masqué ou agrégé existe sur le diagramme et doit être exclu au lieu de ne jamais être mentionné. Et le processus ne s'arrête pas à la subvention : « Recertifié avant la date d'expiration ? fait de l'expiration la valeur par défaut et du renouvellement l'exception, ce qui est à l'opposé de la façon dont la plupart des accès sont réellement détenus, tandis que « Rôle ou objectif modifié ? » donne au propriétaire une deuxième raison de révocation sans attendre une date de révision. La voie d'urgence est tracée pour la même raison : un ingénieur confronté à un incident de production accédera aux données d'une manière ou d'une autre, donc « Approbation rétrospective donnée ? place la ratification et la révocation derrière un accès sécurisé plutôt que de prétendre que cela n’a pas eu lieu.
Ce que couvre cet organigramme
Dans ce modèle
- Cinq couloirs (demandeur, gestionnaire des données, propriétaire des données, bureau de la confidentialité et équipe de la plateforme de données) répartis en cinq phases : demande, classification, évaluation du propriétaire, approvisionnement, et examen et révocation.
- Une demande qui doit être motivée : « Soumettre une demande dans le but déclaré » est la seule voie d'accès ordinaire, tandis qu'un « Accès en cas d'urgence ? » La branche envoie les cas d'incidents de production directement à « Accorder l'accès aux bris de vitres enregistrés » plutôt que de les laisser se produire hors du diagramme. Cette subvention fait alors l'objet d'une « approbation rétrospective donnée ? » et se termine par un « accès d'urgence révoqué et intensifié » si personne ne la ratifie.
- « Catalogue avec un propriétaire nommé ? » dans la voie Gestionnaire de données, dont la branche No exécute « Classifiez-le et nommez un propriétaire de données » et revient à la recherche dans le catalogue, de sorte qu'un ensemble de données sans propriétaire ne peut pas être approuvé par défaut.
- C'est le propriétaire des données qui décide plutôt que l'informatique : « Évaluer la finalité et le moindre privilège », puis « La finalité justifie l'accès ? dont la branche Non se termine par "Demande refusée avec motifs enregistrés", et "**Données personnelles** concernées ?" l'acheminement vers la voie du bureau de confidentialité.
- Une branche des données personnelles avec de vrais pouvoirs : « Enregistrer la base légale et minimiser les champs », puis une triple « Le contrôle de la confidentialité autorise l'utilisation ? » qui autorise la demande, la refuse contre la même fin de rejet, ou l'envoie via « Remplir la DPIA et définir les conditions » et revient pour une deuxième réponse une fois que le risque résiduel est connu.
- Un triple « De quel accès l'objectif a-t-il besoin ? » : données brutes restreintes masquées ou agrégées (qui ajoute « Signer l'accord d'utilisation des données ») ou données internes brutes, toutes convergeant vers « Accorder l'accès avec une date d'expiration », la journalisation des requêtes et une entrée de registre. « Le rôle ou le but a changé ? et "Recertifié avant la date d'expiration ?" puis revenez à une nouvelle subvention ou à "Accès révoqué et registre mis à jour".
Quand utiliser ce modèle
- Vous rédigez la section d'accès d'une politique de gouvernance ou de gestion des données pour un entrepôt, un lac ou une couche de reporting, et vous avez besoin d'une page montrant que le propriétaire des données décide plutôt que l'équipe détenant les informations d'identification.
- Vos analystes disposent d'un accès accordé pour des projets terminés il y a deux ans, et vous souhaitez que l'expiration et la recertification soient intégrées au processus au lieu d'être considérées comme un nettoyage annuel dont personne n'apprécie.
- Vous configurez le workflow des demandes dans un catalogue de données ou un outil de gouvernance des accès et souhaitez que le chemin d'approbation et les seuils de classification soient convenus avant leur encodage.
- Les ingénieurs disposent d'un accès sécurisé aux données de production que personne ne vérifie par la suite, et vous avez besoin que les étapes de ratification et de révocation soient tracées de manière à ce que les propriétaires des données et le personnel d'astreinte puissent les voir.
- Votre équipe chargée de la protection de la vie privée et celle de votre plateforme de données ne sont toujours pas d’accord sur la question de savoir qui décide des données personnelles, et vous souhaitez que la base légale, la minimisation et les étapes DPIA soient placées à l’intérieur du flux plutôt que boulonnées à la fin de celui-ci.
Comment cela fonctionne
Renommez les voies en votre propre organisation
Remplacez le demandeur, l'intendant des données, le propriétaire des données, le bureau de la confidentialité et l'équipe de la plateforme de données par les rôles que vous avez réellement. Gardez le propriétaire des données séparé de l'équipe de la plateforme, même si la même personne effectue les deux tâches aujourd'hui, car leur fusion est ce qui produit un processus dans lequel le concédant est également l'approbateur. Si vous n'avez pas de bureau de confidentialité, nommez la personne qui en porte la responsabilité plutôt que de supprimer la voie, et si la gestion est informelle, indiquez-y le responsable du domaine et dites-le par écrit.
Écrivez votre système de classification dans le tableau
« Lire les règles de classification et de traitement » reste inerte jusqu'à ce que les niveaux existent. Nommez-les (publics, internes, confidentiels, restreints ou tout ce que votre système utilise) et à côté de chacun, notez ce qu'il autorise : requête sur place uniquement, extraction autorisée, masquage obligatoire, accord signé requis. Indiquez ensuite quel niveau déclenche la branche de contrat d'utilisation et quel niveau ne peut jamais quitter l'environnement d'analyse. Sans ce tableau, chaque demande est argumentée à partir des premiers principes et les réponses dérivent selon l'approbateur.
Faire en sorte que la déclaration d'objectif fasse un vrai travail
Définissez le minimum qu'une demande doit dire : la question à laquelle on répond, les tables et les colonnes nécessaires, quels enregistrements sont concernés, combien de temps l'accès est souhaité et où tout extrait sera stocké. "Pour analyse" doit être renvoyé plutôt qu'approuvé. Il s'agit du contrôle le moins cher du marché, car un objectif correctement rédigé rend l'évaluation du moindre privilège, la décision de masquage et la date d'expiration presque mécaniques, tandis qu'un objectif vague rend les trois arbitraires.
Définir des périodes d'expiration par défaut par classification
Attachez une valeur par défaut à « Accorder l'accès avec une date d'expiration » pour chaque niveau : quelque chose comme la fenêtre d'incident pour les bris de glace, quatre-vingt-dix jours pour les données restreintes, six ou douze mois pour les données internes et la date de fin du projet s'il en existe une. Laissez les demandeurs demander des délais plus courts et faites de tout ce qui est plus long que la valeur par défaut une décision explicite du propriétaire. L’expiration est le contrôle qui survit aux réorganisations, aux migrations d’outils et au fait que tout le monde oublie que le processus existe.
Convenez de l'itinéraire d'urgence avant d'en avoir besoin
Décidez qui peut invoquer l'accès bris de glace, ce qu'il accorde, à partir de quel compte il s'exécute, comment la session est enregistrée et qui est alerté au moment de l'octroi. Fixez ensuite le délai de ratification (un petit nombre de jours ouvrables) et, plus important encore, décidez de ce qui se passera lorsque personne ne ratifiera. La révocation automatique dans les délais est la seule version qui tient, car une file d'attente d'approbation rétrospective sans conséquence devient un retard permanent en un trimestre.
Parcourez-le, puis publiez une version
Apportez le graphique terminé à un propriétaire de données, à un analyste qui demande souvent l'accès, à l'ingénieur de plate-forme qui exécute les subventions et à toute personne qui gère la confidentialité, et testez-le par rapport à trois demandes réelles du dernier trimestre, dont une qui a été refusée et une qui a traversé le verre brisé. Corrigez le diagramme en fonction de ce qui s'est réellement passé plutôt que de ce que dit la politique. Publiez ensuite cette révision, conservez les précédentes et associez-la à la politique de gouvernance des données afin que les lecteurs sachent quelle version ils consultent.
Questions fréquentes
Quelles sont les étapes d’un processus de demande d’accès aux données ?
Soumettre une demande indiquant le but plutôt que le système ; localiser le jeu de données dans le catalogue et lire ses règles de classification et de traitement ; confirmez qu'il a un propriétaire nommé et classez-le en premier si ce n'est pas le cas ; demander à ce propriétaire d'évaluer l'objectif par rapport au moindre privilège et de décider ; lorsque les données personnelles sont concernées, enregistrer la base légale, minimiser les champs et les soumettre à un examen de confidentialité ou à une DPIA ; offrir une vue masquée ou agrégée avant l'accès brut ; ajouter un accord d'utilisation signé pour les données restreintes ; accorder l'accès avec une date d'expiration ; activer la journalisation des requêtes ; enregistrer le droit dans le registre d'accès ; puis soit le recertifier avant son expiration, soit le révoquer immédiatement si le rôle ou l'objectif de la personne change. Les étapes qui manquent le plus souvent en pratique sont l'alternative masquée, la date d'expiration et le déclencheur de révocation en cas de changement de rôle.
Qui doit approuver l’accès à un ensemble de données : le service informatique ou le propriétaire des données ?
Le propriétaire des données, c'est-à-dire la personne responsable dans le domaine d'activité décrit par les données, et non l'équipe qui exploite la plateforme sur laquelle elles se trouvent. Le jugement qui est porté est de savoir si cet objectif justifie ces données, et seule quelqu'un qui comprend ce que signifient les enregistrements peut le faire. L'équipe de la plateforme exécute la subvention, fixe l'expiration et active la journalisation ; il ne devrait pas non plus décider qui a le droit de lire les dossiers de paie, les dossiers des patients ou des clients. L'approbation d'un supérieur hiérarchique mérite d'être ajoutée comme première porte, car elle confirme que la demande fait partie du travail de la personne, mais elle ne remplace pas la décision du propriétaire. Lorsqu'un ensemble de données n'a véritablement pas de propriétaire, il s'agit d'une découverte en soi. C'est pourquoi ce graphique indique « Catalogue avec un propriétaire nommé ? » avant l’évaluation plutôt qu’après.
Combien de temps l’accès aux données doit-il durer avant leur expiration ?
Assez longtemps pour l'objectif déclaré et pas plus, avec la valeur par défaut définie par classification plutôt que négociée par demande. Un modèle viable est la durée de l'incident en cas d'accès par bris de glace, environ quatre-vingt-dix jours pour les données restreintes ou personnelles, six à douze mois pour les données internes ordinaires et la date de fin du projet lorsque la demande est liée à un projet. Le mécanisme compte plus que les chiffres : une date d’expiration fait de la suppression un acte par défaut et du renouvellement un acte délibéré, de sorte que l’accès se dégrade de lui-même lorsque le processus est négligé. Les accès sans expiration s'accumulent à la place. Lorsque vous demandez à un propriétaire de se recertifier, envoyez le décompte de la requête avec la demande : un droit que personne n'a utilisé depuis six mois est supprimé sans argument, tandis qu'une liste de noms sans données d'utilisation jointes est presque toujours approuvée en gros.
Quand une demande d’accès aux données nécessite-t-elle une DPIA ?
En vertu du RGPD du Royaume-Uni et de l'UE, une évaluation d'impact sur la protection des données est requise lorsque le traitement est susceptible d'entraîner un risque élevé pour les personnes, et elle est attendue en particulier pour le traitement à grande échelle de données de catégorie spéciale, la surveillance systématique et les décisions automatisées ayant des effets juridiques ou d'importance similaire. Les autorités de contrôle publient leurs propres listes d'opérations qui en nécessitent toujours une. Pour une demande d’analyse interne, les déclencheurs honnêtes sont généralement l’échelle de la population concernée, si les données appartiennent à une catégorie spéciale ou à des données criminelles, si les individus s’attendraient raisonnablement à cette utilisation et si les résultats alimentent une décision les concernant. En pratique, deux choses sont utiles : filtrer chaque demande de données personnelles plutôt que d’attendre que quelqu’un soulève une préoccupation, et traiter le résultat comme des conditions d’octroi (les colonnes masquées, la durée de conservation, l’interdiction de réidentification) plutôt que comme un document archivé et oublié.
En quoi est-ce différent d’un processus général de demande d’accès ?
Le processus général de demande d'accès chez /fr/templates/organigramme-processus-demande-acces couvre les systèmes et les applications : quelqu'un a besoin d'un rôle dans un système d'entreprise, un supérieur hiérarchique et un propriétaire du système l'approuvent, une séparation des tâches est vérifiée et le service informatique le provisionne. Cette page couvre les ensembles de données et trois choses changent en conséquence. L'approbateur est le propriétaire des données plutôt que le propriétaire du système, car la question porte sur la signification des enregistrements plutôt que sur la fonction d'une application. Une étape de classification se situe au milieu, car la réponse dépend du contenu du tableau. Et il existe une alternative masquée ou agrégée, qui n'a pas d'équivalent en termes d'accès aux applications : vous ne pouvez pas accorder à quelqu'un soixante pour cent d'un module financier, mais vous pouvez lui accorder une vue sans les identifiants. Si vous concevez un formulaire de centre de services pour l'accès aux applications, commencez par le processus général ; si vous décidez qui peut interroger l'entrepôt, commencez ici.