Partager cet article
Nous suivre sur Linkedin
Bienvenue dans le monde de SAP Datasphere, où les données ne sont pas seulement des informations – elles sont l’élément vital des entreprises modernes. Dans ce contexte, il est primordial de préserver le caractère sacré des données, et c’est là que les gardiens silencieux, les « Data Access Controls » (DAC), entrent en jeu.
Introduction.
Les Data Access Controls de SAP Datasphere permettent de gérer les droits d’accès des utilisateurs. Ils garantissent que vos informations restent sûres et correctes. Comme de plus en plus de données sont créées et circulent, il est de la plus haute importance d’avoir des règles strictes pour protéger les informations sensibles des personnes qui ne devraient pas les voir. Dans ce blog, nous expliquerons pourquoi ces contrôles sont importants, comment ils sont utiles et pourquoi ils sont essentiels pour garantir la sécurité de vos données.
Pour explorer une gamme variée de scénarios, une version « allégée » du modèle de données décrit dans le blog SAP intitulé « SAP Datasphere Analytic Model Series – Data Model Introduction » est utilisée. L’ensemble de données mentionné et partagé dans le blog SAP est classé ici. Il permet de tester et d’analyser l’efficacité de différents scénarios dans différents contextes. Examinons les scénarios et découvrons les différents résultats qu’ils ont produits.
Modèle de données.
Comme indiqué ci-dessus, les fichiers suivants ont été importés afin de disposer d’un échantillon de données et d’un exemple de vue.
Les tables ayant été importées avec succès, une vue a été créée dans SAP Datasphere avec ces tableaux afin d’explorer divers scénarios d’accès aux données. Veuillez noter que cette vue sert principalement à tester des scénarios d’accès aux données et qu’elle peut ne pas être implémentée de la manière la plus optimale du point de vue de l’entreprise.
Vue 1 : Vue principale créée dans SAP Datasphere comprenant certains tableaux de l’article
Passons en revue les scénarios et observons comment SAP Datasphere réagit.
Scénario 1
Dans le scénario initial, l’utilisateur se voit accorder l’accès à des organisations de vente spécifiques exclusivement. Il s’agit d’un scénario de base qui vous permet de vous familiariser avec les accès aux données dans SAP Datasphere. Le tableau suivant dans SAP Datasphere montre l’autorisation d’accès d’un utilisateur aux organisations de vente 463, 949 et 765.
Tableau 1 Users_Salesorg : Nom d’utilisateur et organisation de vente
La capture d’écran suivante (DAC 1) montre l’écran d’action sur les données où nous pouvons ajouter la « Permissions Entity » qui est dans ce cas l’organisation de vente.
DAC 1 : La Permission Entity est Users_salesorg et la Identifier Column est le nom d’utilisateur.
Une fois que nous avons ajouté ce DAC à notre vue principale (voir la première vue 1), l’utilisateur n’est autorisé à voir que les données spécifiques aux organisations de vente autorisées. Le tableau suivant montre les résultats de l’accès aux données et, comme nous pouvons le voir, seules les organisations de vente concernées sont représentées.
Résultat 1 : Tableau des résultats de la vue principale après l’ajout du DAC 1 en tant que règle de droit d’accès.
Comme indiqué précédemment, l’exemple précédent a servi de point de départ. Nous allons maintenant nous pencher sur des scénarios plus détaillés.
Scénario 2
Dans ce scénario, nous supposons que l’utilisateur a accès à deux organisations de vente différentes et à la catégorie de produit 3.
Tableau 2 : Nom d’utilisateur, organisation de vente et catégorie de produit
Le résultat est conforme aux attentes : l’utilisateur ne peut voir que les données relatives aux organisations de vente 463 et 949 et à la catégorie de produits 3. Toutes les autres données ne sont pas accessibles.
Résultat 2 : Tableau des résultats de la vue principale après l’ajout du tableau 2 mentionné ci-dessus en tant que règle de droit d’accès.
Scénario 3
Dans le scénario suivant, j’ai testé s’il était possible d’ajouter des rôles d’utilisateur dans SAP Datasphere, car les rôles d’utilisateur sont un aspect essentiel de tout système ou plateforme impliquant plusieurs utilisateurs.
Au lieu d’attribuer individuellement des autorisations à chaque utilisateur, les administrateurs peuvent attribuer des rôles comprenant un ensemble d’autorisations prédéfinies. Cela simplifie le processus d’octroi ou de révocation de l’accès, car les administrateurs n’ont qu’à gérer les rôles plutôt que les autorisations individuelles des utilisateurs. Par conséquent, les droits d’accès correspondants sont automatiquement étendus à tous les utilisateurs affectés aux mêmes rôles.
Pour gérer efficacement les rôles d’utilisateur, j’ai créé un tableau des rôles d’utilisateur. Dans ce tableau, j’ai ajouté les rôles d’utilisateur UR1 et UR2, ainsi que l’organisation de vente et la catégorie de produit.
Tableau 3 : Rôle de l’utilisateur, organisation de vente et catégorie de produit
Tableau 4 : Utilisateur et rôle d’utilisateur
Pour fusionner le tableau des rôles d’utilisateur avec le tableau des utilisateurs, je les ai réunis dans une vue.
Vue 2 : Rôles d’utilisateur et liste d’utilisateurs jointe
Le tableau des résultats montre les valeurs correctes qui me sont accessibles avec le rôle d’utilisateur UR1, ce qui montre que les rôles d’utilisateur dans SAP Datasphere sont possibles et faciles à gérer.
Résultat 3 : Tableau des résultats des rôles d’utilisateur après l’ajout de la vue mentionnée ci-dessus en tant que règle de droit d’accès.
Scénario 4
Poursuivant notre exploration, j’ai procédé à une évaluation de l’interaction entre deux DAC lorsqu’ils sont tous deux appliqués à la même vue. Le système donnera-t-il la priorité au premier DAC ou le DAC le plus récent l’emportera-t-il sur le précédent ? Ainsi, deux DAC sont intégrés simultanément dans une même vue, ce qui permet de comprendre comment ils s’influencent l’un l’autre.
Dans le tableau 5, vous pouvez observer le tableau initial dans lequel j’ai implémenté une restriction, autorisant l’utilisateur à accéder uniquement à l’organisation commerciale 949. J’ai intégré ce tableau dans un DAC et je l’ai appelé « SalesOrg DAC ».
Tableau 5 : Nom d’utilisateur et organisation de vente
Pour le deuxième DAC, j’ai utilisé le DAC de rôle d’utilisateur mentionné plus haut, que j’ai appelé » User Role DAC « .
Vue 3 : Vue du rôle de l’utilisateur utilisée comme deuxième restriction des droits d’accès
J’ai d’abord ajouté le « SalesOrg DAC » dans la vue principale, puis j’ai ajouté le « UserRole DAC ». Lorsque j’ai vérifié les données comme dans le résultat 4, aucune donnée n’apparaissait. J’ai également essayé l’ordre inverse, en commençant par le « UserRole DAC » et en ajoutant ensuite le « SalesOrg DAC », mais il n’y avait toujours pas de données, comme le montre le résultat 5. Cela confirme que l’accès aux données fonctionne correctement selon le processus prévu puisqu’un DAC ne doit pas remplacer l’autre.
Résultat 4 : Pas de données disponibles
Résultat 5 : Pas de données disponibles
Scénario 5
Dans ce scénario, je veux tester ce qui se passe si j’utilise des caractères génériques tels que « * », » « , « null ». En implémentant des caractères génériques pour l’accès aux données, nous testerons si les utilisateurs sont en mesure de voir et d’accéder à toutes les données du système. Cette approche permet d’évaluer l’efficacité des contrôles d’accès aux données et d’identifier les éventuelles lacunes ou vulnérabilités des mesures de sécurité.
Toutefois, il est important de noter qu’accorder un accès illimité à toutes les données peut ne pas être approprié ou recommandé dans la plupart des scénarios. Il est généralement conseillé de définir des filtres et des restrictions spécifiques en fonction des rôles d’utilisateur, des exigences organisationnelles et de la sensibilité des données, afin de garantir une gouvernance et une sécurité adéquates des données.
Voyons ce qui se passe si nous plaçons le tableau d’accès aux données avec le caractère générique au-dessus de la vue précédente.
Tableau 6 : Tableau de caractères génériques avec le nom d’utilisateur, l’organisation de vente et la catégorie de produit
Comme le montre le résultat 6, aucun des caractères génériques mentionnés ci-dessus ne fonctionne avec le DAC de caractères génériques. L’utilisation de caractères génériques peut parfois conduire à des résultats involontaires ou inexacts, et ils peuvent ne pas fournir la précision requise pour des requêtes spécifiques. Le fait que les caractères génériques ne fonctionnent pas dans SAP Datasphere peut être considéré comme un avantage. Cette limitation encourage les utilisateurs à adopter des méthodes de recherche plus précises et contrôlées, ce qui favorise l’obtention de résultats précis et fiables dans leurs processus d’analyse de données.
Résultat 6 : Numéro non valide : Erreur SQL
Conclusion
L’exploration des contrôles d’accès aux données dans SAP Datasphere a mis en évidence le rôle critique qu’ils jouent pour assurer la sécurité, l’intégrité et l’accès contrôlé aux données sensibles. Grâce à une série de scénarios impliquant différents scénarios d’accès et modèles de données, nous avons acquis des connaissances précieuses sur les capacités de ces contrôles.
Dans l’ensemble, les scénarios ont montré l’efficacité et la flexibilité des contrôles d’accès aux données dans SAP Datasphere. En tirant parti de ces contrôles, les organisations peuvent garantir la sécurité des données, respecter les règles de conformité et faciliter une collaboration efficace entre les utilisateurs disposant de différents niveaux d’accès.
