Réponse succincte
Une plateforme IRM de protection de la vie privée nécessite un système d'autorisation qui va au-delà de la simple distinction entre „ administrateur “ et „ utilisateur “. Il est notamment indispensable de disposer de droits basés sur les rôles, liés aux objets, multi-clients et dépendants du statut. Les utilisateurs ne devraient pouvoir accéder qu’aux informations et fonctions dont ils ont besoin pour accomplir leur tâche respective. Cela s’applique notamment aux activités de traitement, aux risques, aux prestataires de services, aux incidents, aux analyses d’impact relatives à la protection des données, aux cas d’utilisation de l’IA, aux mesures et aux autorisations.
Il convient en outre de prendre en compte les autorisations temporaires, les processus d'administration réglementés, la journalisation traçable, les contrôles réguliers des droits d'accès et une connexion fiable au système de gestion des identités et des accès.
Les logiciels de protection des données contiennent des informations sensibles sur l'entreprise
Les logiciels de protection des données servent généralement à Documentation et la gestion des activités de traitement, des mesures techniques et organisationnelles, des sous-traitants, des demandes des personnes concernées, des incidents liés à la protection des données, des analyses d'impact relatives à la protection des données, des délais de conservation et des justificatifs correspondants.
Une plateforme Privacy-IRM ne contient toutefois pas uniquement des données administratives. Elle traite régulièrement des informations sensibles relatives aux structures d'une entreprise en matière de protection des données, de gestion des risques et de gouvernance.
La plateforme permet d'identifier quels systèmes données à caractère personnel identifier quels prestataires sont impliqués et quels sont les risques, les failles ou les mesures en cours. À cela s'ajoutent, le cas échéant, des informations sur les incidents, les réclamations, les points peu clairs Bases juridiques, les transferts internationaux de données et les décisions internes. Dans le cadre des processus de gouvernance de l'IA, des informations supplémentaires peuvent être fournies concernant les cas d'utilisation de l'IA, les sources de données, les modèles, les fournisseurs, les catégories de risque, les conditions d'autorisation, la surveillance, le contrôle humain et les répercussions possibles sur Personnes concernées être inclus.
Dans ce contexte, la plateforme Privacy-IRM elle-même doit également être considérée comme un système méritant d'être protégé. Si les droits d'accès sont définis de manière trop large, certaines personnes peuvent consulter des informations qui ne sont pas nécessaires à l'accomplissement de leur mission spécifique. Les rôles et les droits ne relèvent donc pas uniquement de la gestion des utilisateurs, mais constituent un élément essentiel de l'architecture de sécurité et de gouvernance d'une telle plateforme.
Les logiciels de protection des données peuvent eux-mêmes constituer un risque pour la protection des données et la sécurité
Un système de gestion de la protection des données a pour but d'aider les entreprises à identifier, évaluer et maîtriser les risques. Dans le même temps, ce système peut lui-même être source de risques si les autorisations sont accordées de manière trop large, de façon permanente ou sans contrôle suffisant.
Un service peut, par exemple, avoir besoin d'accéder aux activités de traitement dont il est responsable. Cela ne signifie toutefois pas automatiquement que toutes les activités de traitement des autres services de l'entreprise doivent également être consultables. Un fichier local Coordinateur de la protection des données peut, le cas échéant, avoir besoin d'accéder aux informations relatives à la société qui lui est attribuée ou au site concerné, mais pas nécessairement aux incidents confidentiels concernant d'autres sociétés.
Il en va de même pour les autres fonctions. Le service juridique a notamment besoin d’informations relatives aux contrats et à la responsabilité. Le service de sécurité informatique a besoin de données techniques. La direction a régulièrement besoin d’informations synthétiques sur les risques et les décisions. Un délégué à la protection des données externe doit avoir accès aux dossiers pertinents pour son activité, sans que cela n’implique automatiquement un accès illimité à l’ensemble des contenus documentés dans le système.
Le site RGPD exige, en matière de sécurité, que Traitement approprié mesures techniques et organisationnelles, garantissant un niveau de protection adapté au risque. Il convient notamment de tenir compte Confidentialité, Intégrité, Disponibilité ainsi que la résilience des systèmes et les risques de divulgation ou d'accès non autorisés.
Ces exigences ne s'appliquent pas uniquement aux systèmes répertoriés dans le registre des activités de traitement. Elles doivent également être prises en compte dans le système permettant de gérer les activités de traitement, les risques, les incidents et les mesures.
Le principe du privilège minimal dans les opérations liées à la protection de la vie privée
Le principe du « moindre privilège » prévoit de limiter les droits d'accès au strict nécessaire pour l'accomplissement d'une tâche spécifique. Le NIST décrit ainsi le « moindre privilège » comme un principe de sécurité selon lequel les droits d'accès sont limités au minimum nécessaire à l'accomplissement de la tâche concernée.
Pour les opérations liées à la protection de la vie privée, cela signifie que les rôles ne doivent pas se voir attribuer des droits étendus uniquement dans un souci de simplification.
Il convient de vérifier si un département a besoin de droits d'accès étendus, tout comme il faut se demander si un Coordinateur de la protection des données doit disposer de droits d'écriture à l'échelle de l'organisation ou que le service juridique devrait, par défaut, avoir accès à toutes les opérations. En fonction du domaine de responsabilité concerné, des droits d'accès plus étendus peuvent s'avérer nécessaires. Ceux-ci ne doivent toutefois pas être définis par défaut sans examen préalable.
Le principe du « privilège minimal » ne doit pas compliquer inutilement l'exécution des tâches. Ce qui importe avant tout, c'est de déterminer quelles informations et quelles actions un poste a réellement besoin pour pouvoir accomplir les tâches qui lui sont confiées.
Un modèle de rôle ne suffit généralement pas à lui seul
De nombreux systèmes reposent sur un modèle de rôles. Cependant, la simple existence de rôles ne permet pas encore de se faire une idée précise du degré de différenciation avec lequel les accès peuvent effectivement être contrôlés.
Un modèle qui se contente de distinguer les rôles d'administrateur, de gestionnaire, d'utilisateur et d'utilisateur en lecture seule ne devrait généralement pas suffire pour les processus complexes de gestion des droits d'accès (IRM) liés à la confidentialité. Le rôle à lui seul ne permet notamment pas de déterminer à quel objet se rapporte une autorisation, à quel mandant elle s'applique, quel est le statut d'une opération et quelle action concrète est autorisée.
Un utilisateur peut, par exemple, être à la fois responsable d'une activité de traitement et réviseur d'une mesure. Dans une autre entreprise, cette même personne peut n'avoir qu'un accès en lecture seule. Une autorisation supplémentaire peut être nécessaire à titre temporaire pour un incident de protection des données spécifique. Dans le cadre d’un processus de validation, un utilisateur peut être autorisé à ajouter des commentaires sans pouvoir décider lui-même de la validation. Un auditeur peut consulter des justificatifs sans être autorisé à les modifier.
De telles configurations doivent être prises en compte régulièrement, en particulier au sein des grandes organisations. Une plateforme Privacy-IRM nécessite donc, outre la définition des rôles, une architecture des droits qui relie entre elles les différentes dimensions d'accès.
Droits par rôle, objet, mandant, statut et action
Une logique d'autorisation robuste doit prendre en compte plusieurs dimensions.
Il convient tout d'abord d'examiner le rôle de l'utilisateur. Il peut s'agir, par exemple, d'un responsable de service, d'un délégué à la protection des données, d'un responsable de la vérification juridique, d'un responsable de la sécurité informatique, d'un cadre, d'un auditeur, d'un consultant externe ou d'un administrateur.
Par ailleurs, c’est l’objet concerné qui est déterminant. Une requête peut par exemple porter sur une activité de traitement, un prestataire de services, un système, une mesure, un incident, une demande d’une personne concernée, une Analyse d'impact relative à la protection des données, se rapportant à un cas d'utilisation de l'IA, à un risque ou à un rapport.
Il convient également de tenir compte du contexte organisationnel. Un objet peut être rattaché à une société, un site, une unité opérationnelle, un projet ou une équipe. En fonction de la structure organisationnelle, plusieurs de ces niveaux peuvent être pertinents simultanément.
Le statut de la tâche peut également influencer les actions autorisées. Il convient notamment de distinguer les statuts suivants : brouillon, vérification, renvoi, validation, remontée, clôture ou archivage.
Enfin, il convient de déterminer quelles actions le rôle concerné est autorisé à effectuer. Il s'agit notamment de la lecture, de la modification, de l'ajout de commentaires, de la vérification, de la validation, du rejet, de la remontée, de l'exportation, de la suppression ou de l'attribution de droits.
Ce n'est qu'à partir de l'interaction de ces dimensions qu'il est possible d'élaborer un système d'autorisations qui reflète de manière adéquate le processus de gouvernance concerné.
Un responsable de service peut, par exemple, modifier une activité de traitement au sein de son entreprise tant qu'elle est encore au stade de projet. Une fois le document soumis pour examen, il peut s’avérer nécessaire de limiter les modifications. Il doit rester possible de poser des questions et d’apporter des compléments d’information, tandis que la validation proprement dite reste du ressort du réviseur ou du validateur compétent. Une fois le processus terminé, il convient également de définir la procédure à suivre pour apporter des modifications à une version déjà validée.
La matrice des autorisations comme base de contrôle
Lors du choix d'une plateforme Privacy-IRM, il ne faut donc pas se contenter de demander si le système prend en charge les rôles. Il est plus pertinent de se demander si les rôles peuvent être gérés en fonction des actions, des objets, des clients, des statuts et des autorisations.
Une matrice d'autorisations simplifiée peut, par exemple, être structurée comme suit :
Un tel tableau ne constitue pas un modèle d'autorisation universel. Il montre toutefois que les rôles ne doivent pas être considérés isolément, mais en relation avec les objets, les actions, les statuts et les entités organisationnelles.
Les droits liés au statut garantissent le bon déroulement du processus
Les droits liés au statut constituent un autre aspect important. Au cours de son cycle de vie, une opération voit son statut technique et organisationnel évoluer. Cela peut donc entraîner une modification des personnes autorisées à effectuer certaines actions.
Une opération de traitement au stade du projet doit être traitée différemment d'une opération de traitement déjà validée. Il en va de même pour un cas d'utilisation de l'IA en cours de saisie par rapport à un cas d'utilisation déjà mis en production et soumis à des conditions de validation, pour une mesure à l'état de projet par rapport à une mesure critique en retard, ou pour un incident de protection des données en cours d'évaluation initiale par rapport à un incident clôturé avec une décision de signalement documentée.
Le dispositif d'autorisation doit donc notamment définir qui est autorisé à modifier un projet, quelles sont les possibilités de modification après soumission et dans quelles conditions une évaluation déjà validée peut être modifiée ou rouverte. Il convient également de déterminer qui peut révoquer des validations, clôturer des dossiers ayant fait l’objet d’une escalade ou marquer des mesures comme étant terminées.
En l'absence de règles appropriées, les utilisateurs peuvent modifier l'état du processus, involontairement ou délibérément, alors que la phase de processus concernée ne le prévoit pas. Dans ce cas, la seule mise en place a posteriori d'un système d'enregistrement ne remplace pas une Contrôle d’accès aux données.
Des accès spécifiques aux objets plutôt que des accès complets généraux
Les systèmes Privacy-IRM doivent généralement offrir la possibilité de restreindre l'accès à des objets spécifiques.
Si, par exemple, un service doit mettre à jour une opération de traitement spécifique, cela ne signifie pas pour autant que toutes les opérations de traitement de l'entreprise doivent être accessibles. Un auditeur externe peut être amené à vérifier certains justificatifs sans pour autant avoir besoin d'accéder à l'ensemble des risques, des incidents et des demandes des personnes concernées. Il en va de même pour un interlocuteur local qui, dans le cadre d'une Analyse d'impact relative à la protection des données y participe.
Une plateforme devrait donc permettre d'envoyer des invitations d'accès ciblées. On pourrait par exemple envisager d'autoriser une personne uniquement à modifier une activité de traitement spécifique, à commenter une mesure donnée, à consulter certains justificatifs ou à participer à un cas d'utilisation concret de l'IA.
Cela permet de faciliter la collaboration sans pour autant devoir accorder des droits d'accès étendus au système.
Autorisations temporaires
De nombreux accès ne sont nécessaires que pour une durée limitée. C'est le cas, par exemple, des auditeurs, des consultants externes, des collaborateurs des services spécialisés dans le cadre d'une demande d'une personne concernée, du service juridique lors de l'examen d'un contrat spécifique ou du service de sécurité informatique lors de l'évaluation d'un système. En cas d'incident lié à la protection des données, une équipe chargée de la gestion des incidents peut également avoir besoin d'un accès supplémentaire à titre temporaire.
Ces autorisations ne devraient pas être automatiquement maintenues de manière permanente.
Il devrait donc être possible d'associer une date d'expiration aux droits temporaires. Il convient en outre d'examiner s'il est possible de prévoir une justification, un enregistrement et un retrait automatique à l'issue d'une procédure ou à l'expiration d'un délai.
Dans la pratique, un risque lié aux autorisations peut notamment survenir lorsqu'un accès initialement justifié n'est pas révoqué une fois que la raison qui le justifiait a disparu.
Accès guidés par domaine de spécialité
La gestion de la protection des données nécessite régulièrement la participation des services opérationnels. Ceux-ci doivent fournir des informations, mettre à jour les activités de traitement, mettre en œuvre des mesures, répondre aux questions et accompagner les processus de validation.
Une plateforme IRM dédiée à la protection de la vie privée ne devrait donc pas s'adresser exclusivement aux experts en protection des données. Dans le même temps, il convient d'éviter que les services opérationnels ne se voient attribuer des informations, des champs ou des droits qui ne sont pas nécessaires à l'accomplissement de leurs missions.
Un système de droits adapté permet de canaliser de manière ciblée les accès au sein des services. Les utilisateurs voient ainsi les dossiers qui leur sont attribués et les informations dont le traitement leur incombe. Les demandes de précisions, les tâches, les possibilités de modification, les informations sur le statut et les délais peuvent être mis à disposition dans ce cadre, sans qu'un accès complet à l'ensemble du dispositif de protection des données soit nécessaire.
Cela peut contribuer à la fois à la sécurité des accès et à la facilité d'utilisation du système. L'essentiel est de permettre la collaboration sur l'objet concerné sans accorder d'autorisations allant au-delà de ce qui est nécessaire.
Distinguer les rôles administratifs
Les droits d'administrateur doivent faire l'objet d'une attention particulière en raison de leur portée souvent très étendue.
Dans certains systèmes, l'administration technique et l'accès complet aux données métier sont associés. Les personnes habilitées à créer des utilisateurs ou à configurer des champs peuvent ainsi, le cas échéant, avoir également accès à des contenus métier tels que les incidents liés à la protection des données ou les activités de traitement.
Un tel couplage n'est pas indispensable. Une plateforme IRM de protection de la vie privée devrait plutôt pouvoir prendre en charge différentes tâches administratives.
Les administrateurs techniques n'ont pas nécessairement besoin d'un accès complet aux fonctionnalités. Les administrateurs fonctionnels ne doivent pas forcément pouvoir modifier l'ensemble des configurations du système. Les administrateurs de sécurité peuvent avoir besoin d'autorisations différentes de celles des administrateurs chargés de la protection des données. De même, les accès du fournisseur à des fins d'assistance doivent être limités en termes de contenu et de durée, et faire l'objet d'un journalisation traçable.
Dans les grandes organisations en particulier, une telle séparation peut contribuer à limiter les accès privilégiés au strict nécessaire et à faciliter leur contrôle.
L'intégration IAM en tant que composante du modèle opérationnel
L'intégration à un système de gestion des identités et des accès (IAM) n'est pas seulement une fonctionnalité pratique pour une plateforme Privacy-IRM. Elle revêt une importance capitale pour la gestion à long terme des utilisateurs et des autorisations.
Si la gestion des rôles et des utilisateurs s'effectue exclusivement de manière manuelle au sein du logiciel de protection des données, des divergences peuvent apparaître entre la structure organisationnelle réelle et les droits d'accès enregistrés. Les collaborateurs changent de fonction, des personnes externes quittent des projets, des sociétés ou des équipes sont restructurées et des utilisateurs quittent l'entreprise.
Si ces modifications ne sont pas répercutées dans la plateforme Privacy-IRM, des autorisations qui ne sont plus nécessaires peuvent subsister.
Selon l'organisation, cela concerne donc notamment Connexion unique, la prise en charge des groupes et des rôles, l'attribution et la suppression automatisées des droits d'accès, la prise en charge des utilisateurs externes, les contrôles réguliers des droits d'accès ainsi que la journalisation des accès privilégiés.
La connexion technique ne suffit toutefois pas à elle seule. Le modèle de rôles sous-jacent doit également être correctement défini. Sinon, des groupes IAM mal configurés ne feront que entraîner le transfert automatique d'autorisations trop étendues vers un autre système.
Les groupes IAM, les rôles de plateforme et les rôles de gouvernance doivent donc être harmonisés entre eux.
Contrôles réguliers des droits
Un système d'autorisations doit être contrôlé et adapté tout au long de son exploitation. Les rôles évoluent, les projets s'achèvent, les responsabilités changent et les intervenants externes n'ont plus besoin d'accès une fois leur mission terminée.
Une plateforme IRM de protection de la vie privée devrait donc permettre de vérifier régulièrement les autorisations.
À cet égard, il convient notamment de se demander quels utilisateurs ont accès aux incidents critiques, qui dispose de droits d'exportation, qui est habilité à accorder des autorisations d'accès et quelles personnes possèdent des droits d'administration. Il faut également tenir compte des droits temporaires, des comptes d'utilisateurs inactifs, des comptes externes toujours actifs et des rôles éventuellement trop larges.
Une plateforme peut faciliter ces contrôles en fournissant les rapports, les processus de contrôle et les justificatifs correspondants. La vérification régulière des droits d'accès fait ainsi partie intégrante des opérations de protection des données et de gouvernance.
Exigences particulières en matière de droits d'exportation
Lors de la conception d'un système d'autorisations, il convient de prendre en compte, outre les droits de lecture et de modification, les droits d'exportation en particulier.
Une exportation permet de extraire des informations sensibles de l'environnement contrôlé de la plateforme. Les rôles, les règles de statut et les restrictions d'accès en vigueur au sein de la plateforme ne s'appliquent alors plus nécessairement de la même manière aux données exportées.
Les droits d'exportation devraient donc faire l'objet d'une réglementation distincte. Un droit de lecture ne doit pas nécessairement inclure un droit d'exportation. De même, il peut s'avérer nécessaire de limiter les exportations à certains ensembles de données, mandants ou sociétés. Dans le cas de données particulièrement sensibles, un enregistrement dans un journal ou des processus d'autorisation supplémentaires peuvent être envisagés.
Selon les objectifs visés, le niveau de détail des informations requises peut varier. La direction peut avoir besoin d'une vue d'ensemble synthétique, tandis que les audits peuvent nécessiter des justificatifs plus détaillés. Les services opérationnels, quant à eux, n'ont généralement besoin que d'un aperçu limité.
Lors de la configuration des droits d'accès, il convient donc non seulement de vérifier qui est autorisé à consulter les informations au sein du système, mais aussi qui peut les exporter hors du système.
Autorisations dans AI Governance
Les processus de gouvernance de l'IA permettent d'imposer des exigences supplémentaires en matière de Contrôle d’accès aux données résultent.
Un cas d'utilisation de l'IA peut contenir des informations sur les modèles, les fournisseurs, les sources de données, les risques, les domaines d'application, les groupes d'utilisateurs, la supervision humaine, les conditions d'autorisation et le suivi. Toutes ces informations ne sont pas nécessairement requises pour chaque rôle.
Un service peut, par exemple, traiter son propre cas d'utilisation. Le service de sécurité informatique peut, le cas échéant, avoir besoin d'accéder à des informations techniques, tandis que le service juridique peut avoir besoin d'accéder aux informations relatives aux prestataires et aux contrats, et le Protection des données sur les informations à caractère personnel ainsi que sur les risques liés à Personnes concernées. La direction, en revanche, peut avoir besoin notamment d'informations sur l'état d'avancement et les risques.
Lorsque des fonctionnalités d'IA sont directement intégrées à une plateforme de gouvernance, le modèle d'autorisation doit également s'appliquer à ces fonctionnalités. Un agent d'IA ne devrait pouvoir accéder qu'aux informations et effectuer que les actions autorisées pour le rôle de l'utilisateur concerné et dans le contexte spécifique du processus.
L'utilisation d'un agent IA ne doit donc pas permettre de contourner les restrictions existantes en matière de rôles, d'objets ou de statuts. De même, dans le cas de résumés générés ou d'actions préparées, il convient de tenir compte des informations que le rôle demandeur est effectivement autorisé à consulter et à traiter.
Interaction entre la capacité à gérer plusieurs clients et le modèle de rôles
capacité à prendre en charge plusieurs clients et le contrôle des autorisations doivent être considérés conjointement. Alors que la structure des mandants sépare les entités organisationnelles les unes des autres, le modèle de rôles détermine quels accès sont autorisés au sein de ces entités et, le cas échéant, entre elles.
Un siège social peut, par exemple, avoir besoin d'un reporting global, tandis que les différentes sociétés gèrent leurs opérations de manière autonome. Une unité opérationnelle peut avoir besoin d’informations concernant plusieurs filiales, tandis qu’un site ne nécessite que des mesures locales. Les équipes de projet, quant à elles, peuvent se voir accorder l’accès à des cas d’utilisation spécifiques de l’IA. Un délégué à la protection des données du groupe peut quant à lui avoir besoin d’une vue d’ensemble axée sur les risques.
Une séparation stricte des clients peut donc s'avérer tout aussi insuffisante qu'un modèle de rôles trop large, qui supprime de fait les limites organisationnelles existantes.
Pour les grandes organisations, il convient donc de coordonner les mandants, les objets, les rôles, les autorisations et les fonctions de reporting.
Stratégie d'autorisation dans Ailance
Une plateforme IRM de protection de la vie privée devrait notamment prendre en charge les fonctionnalités suivantes :
| Exigence | Signification |
|---|---|
| basé sur les rôles Contrôle d’accès aux données | Les rôles reflètent les tâches typiques et limitent les droits généraux. |
| Droits liés aux objets | Les accès peuvent être limités à des opérations de traitement, des risques, des mesures ou des incidents spécifiques. |
| Références aux clients et aux sociétés | Les sociétés, les pays ou les entités organisationnelles peuvent être gérés et analysés séparément. |
| Droits liés au statut | La conception, la vérification, la validation, la remontée et la clôture peuvent être associées à différents niveaux d'autorisation. |
| Droits liés à des actions | Les opérations de lecture, modification, vérification, validation, escalade, exportation et suppression sont gérées séparément. |
| Autorisations temporaires | Projet, Audit- ou les droits d'accès accordés à titre exceptionnel peuvent être accordés pour une durée limitée, puis retirés. |
| Restrictions relatives aux champs ou aux domaines | Les informations particulièrement sensibles peuvent bénéficier d'une protection supplémentaire. |
| Délégation et suppléance | Il est possible de créer des délégations sans accorder de droits étendus de manière permanente. |
| Séparation des rôles d'administrateur | L'administration technique et l'accès complet aux fonctionnalités peuvent être dissociés. |
| Intégration IAM/SSO | Les utilisateurs, les groupes et les rôles peuvent être associés à l'identité de l'entreprise. |
| Vérification des droits et renouvellement de la certification | Les droits d'accès peuvent être vérifiés et consignés régulièrement. |
| Audit Trajectoire des autorisations | Les modifications apportées aux rôles, aux droits et aux accès restent traçables. |
| Contrôle des exportations | Les exportations de données peuvent faire l'objet de règles spécifiques, être consignées et limitées. |
| Autorisations pour les agents IA | Les fonctionnalités d'IA restent liées au rôle, au contexte et au processus. |
L'étendue de ces exigences découle de la nature des informations traitées au sein d'une plateforme Privacy-IRM. Ce système contient généralement des informations essentielles relatives aux processus de protection des données, de gestion des risques et de gouvernance d'une entreprise et doit donc être protégé en conséquence.
Stratégie d'autorisation dans Ailance
Ailance est conçue comme une plateforme dédiée aux processus de gouvernance. Le modèle de droits doit donc être adapté aux objets et processus de gouvernance gérés au sein de la plateforme.
Une activité de traitement, un risque, un prestataire de services, un système, un cas d'utilisation de l'IA ou une mesure ne constituent pas simplement des ensembles de données isolés. Ils sont liés à des rôles, des statuts, des responsabilités, des validations et des justificatifs.
Il s'ensuit que les droits d'accès doivent eux aussi être définis en fonction des objets et des processus.
Pour un accès concret, il convient donc notamment de déterminer le rôle d'un utilisateur, le mandant dans lequel il opère, l'objet concerné par l'action, le statut de cet objet et l'action concrète à effectuer. Par ailleurs, il peut être pertinent de vérifier si les autorisations requises ont été accordées, si l’accès a été accordé de manière permanente ou temporaire, et si des informations sensibles doivent être exportées.
La journalisation ou la remontée de certaines actions peut également faire partie intégrante de ce système de contrôle.
C'est en cela qu'un système d'autorisations de gouvernance se distingue d'une simple gestion des utilisateurs, qui se contente essentiellement de vérifier si un utilisateur est connecté et affecté à un rôle général donné.
Vérification pratique des autorisations existantes
Les entreprises devraient vérifier régulièrement si les rôles et les autorisations existants correspondent toujours aux besoins réels liés aux missions. Le rôle qui dispose actuellement des droits les plus étendus peut notamment servir de point de départ.
À cet égard, il conviendrait notamment d'examiner les questions suivantes :
- Est-il réellement nécessaire d'avoir accès à tous les mandants ?
- L'accès à tous les objets est-il nécessaire pour la tâche en question ?
- Faut-il également des droits de modification en plus des droits de lecture ?
- Faut-il exporter les données en question ?
- À quand remonte la dernière vérification des autorisations attribuées ?
Si ces questions ne trouvent pas de réponse satisfaisante, cela n'affecte pas seulement la gestion des utilisateurs. Cela peut également indiquer la nécessité de réexaminer la sécurité et la gouvernance du système de gestion de la protection des données.
Conclusion
Dans une plateforme Privacy-IRM, les rôles et les droits constituent un élément essentiel de l'architecture du système et de la gouvernance.
La plateforme traite régulièrement des informations sensibles concernant les activités de traitement, les systèmes, les données, les risques, les prestataires de services, les incidents, Personnes concernées, les décisions et les justificatifs. En conséquence, l'accès à ces informations doit également être limité de manière appropriée et contrôlé de façon traçable.
Il convient notamment de tenir compte du principe du « moindre privilège », des autorisations liées aux objets, des contrôles d'accès par mandant, des droits liés au statut et aux actions, des accès temporaires, des autorisations d'exportation distinctes, de la séparation des rôles administratifs ainsi que d'une intégration aux structures IAM existantes.
L'essentiel est que les utilisateurs disposent des informations et des fonctionnalités dont ils ont besoin pour accomplir leur tâche respective, sans qu'aucun accès supplémentaire ne leur soit accordé de manière permanente ou forfaitaire. Un système d’autorisations robuste est donc une condition préalable pour qu’une plateforme Privacy-IRM puisse soutenir de manière adéquate les processus de protection des données et de gouvernance d’une entreprise.
Questions et réponses
Quels sont les rôles et les droits nécessaires à une plateforme IRM dédiée à la protection de la vie privée ?
Une plateforme IRM de protection de la vie privée nécessite des droits basés sur les rôles, liés aux objets, multi-clients, dépendants du statut et liés aux actions. À cela s'ajoutent notamment les accès temporaires, les exportations contrôlées, la séparation des rôles administratifs, l'intégration IAM, Audit Trails et vérifications régulières des droits d'accès.
Pourquoi les logiciels de protection des données peuvent-ils eux-mêmes constituer un risque pour la protection des données ?
Les logiciels de protection des données contiennent généralement des informations sensibles concernant les activités de traitement, les systèmes, les prestataires de services, les risques, les incidents, les mesures prises et les décisions. Si les droits d'accès sont définis de manière trop large, cela peut entraîner des risques en matière de confidentialité et de sécurité.
Que signifie le principe du « droit d'accès minimal » dans le cadre des opérations de protection de la vie privée ?
Le principe du « privilège minimal » signifie que les utilisateurs ne disposent que des informations et des actions dont ils ont besoin pour accomplir leur tâche spécifique. Les droits requis peuvent donc varier, par exemple, selon qu’il s’agit des services opérationnels, des réviseurs, des délégués à la protection des données, du service juridique, du service de sécurité informatique, de la direction ou des consultants externes.
Pourquoi des rôles simples comme « Admin » et « Utilisateur » ne suffisent-ils pas ?
Les processus IRM liés à la confidentialité nécessitent souvent une gestion plus nuancée. Outre le rôle, il convient notamment de prendre en compte l'objet concerné, le mandant, le statut d'une opération et l'action autorisée.
Que sont les droits liés aux objets ?
Les droits liés à des objets limitent l'accès à des activités de traitement, des risques, des mesures, des incidents, des prestataires de services ou des cas d'utilisation de l'IA spécifiques. Cela permet une collaboration ciblée sans accorder un accès complet à l'ensemble du système.
Pourquoi les autorisations temporaires sont-elles importantes ?
De nombreux accès ne sont nécessaires que pour des projets, des audits, des incidents ou des contrôles ponctuels. Une limitation dans le temps empêche que les autorisations initialement nécessaires ne subsistent indéfiniment une fois leur objectif atteint.
Quel est le rôle de l'intégration IAM ?
Une connexion IAM relie les utilisateurs, les groupes et les rôles de la plateforme Privacy-IRM au système existant de gestion des identités et des accès de l'entreprise. Cela permet notamment de gérer de manière plus fiable les changements de rôle, les départs, ainsi que l'attribution et la suppression des droits d'accès.
Pourquoi faut-il accorder une attention particulière aux droits d'exportation ?
Une exportation entraîne le transfert de données hors de l'environnement contrôlé de la plateforme. C'est pourquoi les droits d'exportation doivent être attribués séparément, limités et consignés. Pour les données sensibles, des autorisations supplémentaires peuvent être envisagées.
Quel est le lien entre la capacité multi-clients et les autorisations ?
capacité à prendre en charge plusieurs clients reflète la séparation organisationnelle des unités. Le système d'autorisations définit qui est habilité, au sein de ces unités ou au-delà, à consulter, modifier, vérifier, valider ou établir des rapports. Ces deux niveaux doivent être coordonnés entre eux.
Que signifie une autorisation liée au statut ?
Dans le cas d'une autorisation liée au statut, l'action autorisée dépend de l'état actuel d'une opération. Un brouillon peut donc être soumis à des droits de modification différents de ceux applicables à une opération validée, transmise à un niveau supérieur ou clôturée.
Que signifie « autorisation » pour les agents IA ?
Un agent IA ne devrait pouvoir accéder qu'aux informations et effectuer que les actions autorisées en fonction du rôle de l'utilisateur concerné, de l'objet, de l'état du processus et du contexte de gouvernance. Les fonctions d'IA ne doivent pas contourner les limites d'autorisation existantes.
Quels rôles peuvent disposer de droits particulièrement étendus ?
Selon le système et l'organisation, les administrateurs, les coordinateurs locaux, les responsables de projet ou encore les utilisateurs avancés dont le rôle s'est développé au fil du temps peuvent notamment disposer de droits étendus. Il convient de vérifier régulièrement si ces droits sont toujours justifiés. Nécessité doit être vérifié.
German 
English 
Italian 
French