DataSunrise sponsorise AWS re:Invent 2024 à Las Vegas, veuillez nous rendre visite au stand n°2158 de DataSunrise

Oracle's native RBAC

Maîtriser le RBAC natif d’Oracle : Un guide complet – Partie 2

RBAC natif d'Oracle - Partie 2 Avancé

4. Concepts avancés du RBAC natif d’Oracle

La mise en œuvre du RBAC d’Oracle offre des fonctionnalités avancées qui fournissent une flexibilité et une granularité supplémentaires dans la gestion du contrôle d’accès. Explorons certains de ces concepts avancés.

4.1 Hiérarchies de rôles

Les hiérarchies de rôles vous permettent d’établir des relations parent-enfant entre les rôles. Un rôle enfant dispose des mêmes privilèges que son rôle parent. Le rôle enfant reçoit également tous les privilèges supplémentaires qui lui sont spécifiquement accordés. Cela permet de créer une structure hiérarchique des rôles, simplifiant ainsi la gestion des politiques de contrôle d’accès complexes.

Pour créer une hiérarchie de rôles dans Oracle, vous utilisez l’instruction GRANT pour accorder un rôle à un autre rôle. Par exemple:

-- Créer un rôle parent nommé "manager"
CREATE ROLE manager;
-- Accorder des privilèges au rôle "manager"
GRANT SELECT, INSERT, UPDATE ON employees TO manager;
-- Créer un rôle enfant nommé "sales_manager"
CREATE ROLE sales_manager;
-- Accorder le rôle "manager" au rôle "sales_manager"
GRANT manager TO sales_manager;
-- Accorder des privilèges supplémentaires spécifiques au rôle "sales_manager"
GRANT SELECT ON sales TO sales_manager;

Dans cet exemple, nous créons un rôle parent nommé “manager” et lui accordons des privilèges sur la table “employees”. Nous créons ensuite un rôle enfant nommé “sales_manager” et lui accordons le rôle “manager”. Le gestionnaire des ventes possède tous les mêmes privilèges qu’un gestionnaire, plus des privilèges supplémentaires liés aux ventes.

Les hiérarchies de rôles simplifient la gestion des privilèges en définissant des privilèges de base au niveau supérieur et en les personnalisant aux niveaux inférieurs. Cela réduit la redondance et facilite la maintenance et la mise à jour des politiques de contrôle d’accès.

4.2 Rôles d’application sécurisés

Habituellement, ces conditions dépendent de l’exécution réussie d’un package ou d’une fonction PL/SQL.

Pour créer un rôle d’application sécurisé dans Oracle, utilisez l’instruction CREATE ROLE avec la clause IDENTIFIED USING. Ce package ou cette fonction spécifie quel rôle doit être activé. Par exemple:

-- Créer un package PL/SQL pour vérifier les conditions
CREATE OR REPLACE PACKAGE security_pkg IS
FUNCTION check_access RETURN BOOLEAN;
END security_pkg;
/
-- Créer un rôle d'application sécurisé
CREATE ROLE secure_role IDENTIFIED USING security_pkg.check_access;
-- Accorder des privilèges au rôle d'application sécurisé
GRANT SELECT ON sensitive_data TO secure_role;

Dans cet exemple, nous créons un package PL/SQL nommé “security_pkg” contenant une fonction “check_access”. Cette fonction détermine si le rôle d’application sécurisé doit être activé. Elle prend en compte des facteurs tels que l’adresse IP de l’utilisateur, l’heure actuelle et les règles spécifiques de l’application.

Ensuite, nous créons un rôle sécurisé appelé “secure_role” en utilisant la clause IDENTIFIED USING et la spécification “security_pkg.check_access”. Le rôle n’est activé que lorsque la fonction “check_access” renvoie TRUE.

Nous accordons un accès spécial au rôle d’application sécurisé, de sorte que les utilisateurs disposant du rôle et remplissant les conditions requises peuvent consulter les données sensibles.

Les rôles d’application sécurisés renforcent les mesures de sécurité globales en activant les rôles uniquement lorsque certaines conditions sont remplies, ajoutant ainsi une sécurité supplémentaire. Cela empêche l’accès non autorisé et ajoute une couche de contrôle supplémentaire au-delà des méthodes de contrôle d’accès basées sur les rôles traditionnelles.

4.3 Contrôle d’accès finement défini

Le contrôle d’accès finement défini dans le RBAC natif d’Oracle permet de décider qui peut accéder aux données en fonction de conditions ou d’attributs spécifiques détaillés. Cela signifie que vous pouvez contrôler l’accès aux données à un niveau extrêmement granulaire.

Vous pouvez spécifier exactement qui a le droit de consulter ou de modifier certaines données. Le FGAC vous permet de restreindre l’accès en fonction de critères ou d’attributs spécifiques. Oracle propose des outils tels que VPD et OLS pour un contrôle précis de l’accès aux bases de données.

Le VPD vous permet d’ajouter des règles de sécurité aux requêtes SQL pour une table ou une vue. Ces politiques peuvent imposer une sécurité au niveau des lignes en fonction des attributs de l’utilisateur ou du contexte de l’application. Par exemple:

-- Créer une fonction de politique VPD
CREATE OR REPLACE FUNCTION policy_func (
schema_var IN VARCHAR2,
table_var IN VARCHAR2
)
RETURN VARCHAR2
IS
BEGIN
RETURN 'department_id = SYS_CONTEXT(''USERENV'', ''DEPARTMENT_ID'')';
END;
/
-- Appliquer la politique VPD à une table
BEGIN
DBMS_RLS.ADD_POLICY (
object_schema => 'HR',
object_name => 'EMPLOYEES',
policy_name => 'EMP_POLICY',
function_schema => 'HR',
policy_function => 'POLICY_FUNC',
statement_types => 'SELECT,UPDATE,DELETE',
update_check => TRUE
);
END;
/

Dans cet exemple, nous créons une fonction de politique VPD nommée “policy_func”. Cette fonction génère une règle basée sur l’identifiant de département de l’utilisateur. La fonction renvoie une condition qui garantit que les utilisateurs ne peuvent accéder qu’aux enregistrements appartenant à leur propre département.

Ensuite, nous utilisons la politique VPD sur la table “EMPLOYEES” avec la procédure DBMS_RLS.ADD_POLICY. Nous spécifions la fonction de politique et les types d’instructions auxquels elle s’applique.

La politique VPD permet aux utilisateurs d’accéder et de modifier les enregistrements correspondant à leur identifiant de département. Cela donne un contrôle précis sur l’accès au niveau des lignes.

Oracle Label Security (OLS) est une autre fonctionnalité qui permet un contrôle d’accès finement défini basé sur les étiquettes de classification des données. OLS vous permet d’étiqueter les lignes de données et de contrôler l’accès en fonction des étiquettes des utilisateurs. Cela est particulièrement utile dans les environnements contenant des données sensibles nécessitant une confidentialité stricte et une ségrégation des données.

Le contrôle d’accès finement défini améliore le RBAC en ajoutant des niveaux supplémentaires de sécurité. Il vous permet de faire respecter des règles d’accès en fonction d’attributs ou de conditions de données spécifiques.

Contrôle d’accès basé sur les attributs (ABAC)

L’ABAC est une façon de contrôler l’accès en considérant les attributs des utilisateurs, les attributs des ressources et l’environnement pour déterminer les autorisations d’accès. L’ABAC offre une approche plus dynamique et flexible par rapport au RBAC traditionnel.

Dans l’ABAC, les politiques de contrôle d’accès sont définies en fonction des attributs plutôt que des rôles. Les attributs sont des caractéristiques qui peuvent inclure des détails sur l’utilisateur, des détails sur les ressources et des détails environnementaux.

Les détails de l’utilisateur peuvent inclure le titre du poste ou le département. Les détails des ressources peuvent inclure la classification des données ou le niveau de sensibilité. Les détails environnementaux peuvent inclure l’heure de la journée ou l’emplacement.

Oracle prend en charge l’ABAC par le biais de diverses fonctionnalités et technologies, telles que Oracle Entitlements Server (OES) et Oracle Access Manager (OAM). Ces solutions vous permettent de définir des politiques basées sur les attributs et de les appliquer à différentes applications et ressources.

Voici un exemple de mise en œuvre de l’ABAC à l’aide d’Oracle Entitlements Server:

-- Définir les attributs des utilisateurs
CREATE ATTRIBUTE USER_ATTRIBUTES.JOB_TITLE VARCHAR(255);
CREATE ATTRIBUTE USER_ATTRIBUTES.DEPARTMENT VARCHAR(255);
CREATE ATTRIBUTE USER_ATTRIBUTES.SECURITY_CLEARANCE VARCHAR(255);
-- Définir les attributs des ressources
CREATE ATTRIBUTE RESOURCE_ATTRIBUTES.CLASSIFICATION VARCHAR(255);
CREATE ATTRIBUTE RESOURCE_ATTRIBUTES.SENSITIVITY_LEVEL VARCHAR(255);
-- Définir une politique ABAC
CREATE POLICY ACCESS_POLICY
GRANT VIEW ON RESOURCE
WHERE RESOURCE_ATTRIBUTES.CLASSIFICATION = 'CONFIDENTIAL'
AND USER_ATTRIBUTES.SECURITY_CLEARANCE >= 'SECRET'
AND USER_ATTRIBUTES.DEPARTMENT = 'FINANCE';

Dans cet exemple, nous parlons des titres de poste des utilisateurs et des départements, ainsi que des classifications et des niveaux de sensibilité des ressources.

Nous avons une politique appelée “ACCESS_POLICY”. Cette politique permet uniquement aux utilisateurs ayant une habilitation de sécurité ‘SECRET’ et appartenant au département ‘FINANCE’ de consulter les ressources ‘CONFIDENTIELLES’.

Les politiques ABAC peuvent être plus complexes et inclure plusieurs attributs et conditions. Le moteur d’évaluation des politiques examine les détails de l’utilisateur, des ressources et de l’environnement pour déterminer si l’accès doit être accordé.

L’ABAC complète le RBAC en offrant une approche plus fine et plus dynamique du contrôle d’accès. Il permet des décisions de contrôle d’accès plus flexibles et contextuelles basées sur une combinaison d’attributs.

Listes de contrôle d’accès (ACL)

Les listes de contrôle d’accès (ACL) sont un autre mécanisme de contrôle d’accès aux ressources. Les ACL sont utilisées pour spécifier les autorisations pour des utilisateurs ou des groupes individuels sur des objets ou des ressources spécifiques.

Dans Oracle, les ACL sont souvent utilisées pour gérer l’accès aux ressources de réseau externe tels que les services Web ou les bases de données distantes. Oracle propose un mécanisme ACL intégré via le package DBMS_NETWORK_ACL_ADMIN.

Voici un exemple de création d’une ACL et d’octroi d’autorisations à l’aide du package DBMS_NETWORK_ACL_ADMIN:

-- Créer une ACL
BEGIN
DBMS_NETWORK_ACL_ADMIN.CREATE_ACL (
acl => 'my_acl.xml',
description => 'ACL pour accéder à un service Web externe',
principal => 'HR_USER',
is_grant => TRUE,
privilege => 'connect'
);
END;
/ -- Attribuer l'ACL à un hôte réseau BEGIN
DBMS_NETWORK_ACL_ADMIN.ASSIGN_ACL (
acl => 'my_acl.xml',
host => 'www.example.com',
lower_port => 80,
upper_port => 80
);
END;
/

Dans cet exemple, nous créons une ACL nommée “my_acl.xml” en utilisant la procédure DBMS_NETWORK_ACL_ADMIN.CREATE_ACL. Nous spécifions le principal (utilisateur ou rôle) auquel s’applique l’ACL, dans ce cas, ‘HR_USER’. Nous définissons également l’autorisation sur ‘connect’, ce qui permet au principal d’établir une connexion avec la ressource externe.

Ensuite, nous attribuons l’ACL à un hôte réseau spécifique en utilisant la procédure DBMS_NETWORK_ACL_ADMIN.ASSIGN_ACL. Nous spécifions le nom de l’ACL, le nom ou l’adresse IP de l’hôte et la plage de ports à laquelle l’ACL s’applique.

Avec cette ACL en place, ‘HR_USER’ pourra se connecter à l’hôte réseau spécifié sur la plage de ports désignée.

Les ACL aident à contrôler l’accès aux ressources externes de manière détaillée, travaillant en parallèle avec les mécanismes de contrôle d’accès internes de la base de données. Elles sont utiles pour gérer les ressources réseau et s’assurer que seuls les utilisateurs ou les applications autorisés peuvent les utiliser.

Cela conclut la Partie 2. Dans la dernière Partie 3, nous explorerons les Rôles en détail.

Vous cherchez des solutions de sécurité de base de données professionnelles ? Rejoignez-nous en ligne pour une séance de démonstration complète sur la gestion des utilisateurs et des rôles dans DataSunrise, offrant des solutions avancées pour les bases de données Oracle. Découvrez comment rationaliser le contrôle d’accès et améliorer la sécurité avec notre plateforme intuitive.

Suivant

Maîtriser le RBAC natif d’Oracle : Un guide complet – Partie 3

Maîtriser le RBAC natif d’Oracle : Un guide complet – Partie 3

En savoir plus

Besoin de l'aide de notre équipe de support ?

Nos experts seront ravis de répondre à vos questions.

Informations générales :
[email protected]
Service clientèle et support technique :
support.datasunrise.com
Demandes de partenariat et d'alliance :
[email protected]