Niveau d'accès aux droits Crm rls autorisé. RLS – flexibilité et réglage fin des restrictions d’accès aux données. Application conjointe de plusieurs restrictions d'accès au niveau de l'enregistrement

25.08.2020

À partir de la plate-forme 8.0 du système 1C Enterprise, il est possible de restreindre les droits d'accès des utilisateurs au niveau de l'enregistrement. A cet effet, le mécanisme RLS (Record Level Security) est utilisé. Un tel « réglage fin » peut être utile pour restreindre l’accès par organisation, client, gamme de produits, etc.

RLS est la capacité d'un développeur à définir des conditions sur les tables de base de données pour certains utilisateurs (groupes d'utilisateurs) et à les empêcher de voir des éléments inutiles. La condition est de type booléen. Si la condition est vraie, l'accès est accordé, sinon l'accès est refusé.

RLS est utilisé simultanément avec la définition des droits d'accès normaux. Par conséquent, avant de commencer à configurer RLS, vous devez attribuer des droits réguliers aux objets de configuration.

RLS est utilisé pour les types de droits d'accès suivants :
*En lisant
* Ajout
* Changement
* Suppression

Comment configurer RLS

Regardons un exemple simple de la façon de le configurer. Les captures d'écran ont été prises sur la version 1C Enterprise 8.2 (8.2.9.356). La syntaxe des modèles de texte de contrainte est décrite dans la documentation de la version 8.2 dans le livre « Guide du développeur. Partie 1 », nous ne nous y attarderons donc pas.

La première étape consiste donc à définir des modèles de contraintes pour chaque rôle existant.

Après cela, sur la base des modèles spécifiés, des restrictions sont définies sur les objets nécessaires. Pour modifier le texte d'une condition, vous pouvez utiliser le concepteur de restrictions d'accès aux données.

Pour modifier plusieurs rôles, il est pratique de gérer via la fenêtre « Tous les rôles ».

Vous pouvez utiliser la fenêtre Toutes les restrictions d'accès pour copier les conditions vers d'autres rôles. Les modèles ne peuvent être copiés que manuellement vers d'autres rôles.

C'est ça. Vous pouvez vérifier le résultat.

Inconvénients de l’utilisation de RLS :
1. L'utilisation d'un mécanisme de restriction d'accès au niveau de l'enregistrement entraîne une augmentation implicite du nombre de tables participant à la requête, ce qui peut entraîner des erreurs dans le mode client-serveur de la base de données.
2. Il peut s'avérer difficile, voire impossible, d'implémenter une logique d'application complexe pour le contrôle d'écriture. Dans de tels cas, il est préférable d'utiliser des conditions dans la procédure OnWrite().
3. La rédaction d'une condition (requête) nécessite certaines qualifications de la part du développeur.
4. Des difficultés supplémentaires peuvent être créées par l'incapacité de déboguer une condition (requête).

Dans les configurations typiques, les droits au niveau de l'enregistrement peuvent être définis de manière interactive pour les objets suivants : organisations, contreparties, articles, entrepôts, divisions, individus, candidatures et autres.

Il ne faut pas oublier que les restrictions des droits d'accès au niveau de l'enregistrement sont un mécanisme plutôt gourmand en ressources et que plus vous définissez des restrictions complexes, plus le programme fonctionnera lentement, en particulier avec une grande base de données.
Alexandre Melkostupov

Informations extraites du site

Paramétrage des accès au niveau des entrées de l'annuaire.

Ce paramètre a été inclus dans la configuration il n'y a pas si longtemps, je pense personnellement que le paramètre est très utile.

Ce paramètre est nécessaire pour ceux qui ont besoin de restreindre l'accès au répertoire par les éléments de ce répertoire. Par exemple, un responsable doit voir uniquement les clients, ainsi que les rapports et les journaux de documents, uniquement pour les contreparties auxquelles il est autorisé à accéder, et un comptable doit avoir un accès complet à tous les éléments de l'annuaire, par exemple « Contreparties. »

Je propose de considérer un exemple en utilisant l'exemple de la configuration du démarreur progressif.

A ce stade, il est nécessaire de définir un ensemble de groupes d'utilisateurs.

Administrateurs ;

Directeurs commerciaux ;

Responsables des achats ;

Dans un deuxième temps, les groupes d'accès au répertoire sont déterminés.

Acheteurs ;

Fournisseurs ;

En règle générale, les listes de groupes décrites ci-dessus sont discutées avec la direction et ensuite seulement entrées dans le programme.

Il est maintenant nécessaire de décrire les réglages réels qui doivent être effectués dans 1C.

Activons "Accès restreint au niveau de l'enregistrement". Service - gestion des utilisateurs et des accès - Paramètres d'accès au niveau de l'enregistrement. Voir fig. 1.

Le formulaire de traitement « Accès aux paramètres au niveau de l'enregistrement » s'ouvrira, voir Fig. 2.

Sur ce formulaire, vous devez effectivement activer la restriction, dont le drapeau « Restreindre l'accès au niveau de l'enregistrement par type d'objet » est responsable et sélectionner les répertoires pour lesquels la restriction s'appliquera. Cet article traite uniquement du répertoire « Contreparties ».

Ensuite, nous aurons besoin des groupes d'utilisateurs et d'entrepreneurs définis au début de l'article.

Les groupes d'entrepreneurs sont saisis dans le répertoire « Groupes d'utilisateurs », voir Fig. 3.

Le formulaire de l'élément de répertoire « Groupes d'utilisateurs » s'ouvrira, voir Fig. 4.

Sur le côté gauche de la fenêtre l'objet d'accès est indiqué (pour nous ce sont des « contreparties »), à droite se trouvent les utilisateurs qui sont membres du groupe, dans cet exemple ce sont des « Administrateurs ».

Pour chaque groupe d'utilisateurs que vous définissez, vous devez compléter ce paramétrage ; il ne doit plus rester un seul utilisateur qui ne soit pas membre du groupe.

Dans la troisième étape, vous devez saisir les « groupes d'accès aux contreparties » ; le répertoire « Groupes d'accès aux contreparties » s'en charge. Voir fig. 5.

Pour notre exemple, ce sont : Acheteurs, Fournisseurs, Autres. Voir Fig. 6.

A ce stade, vous devez attribuer un groupe d'accès à chaque élément du répertoire « contreparties ». Voir Fig. 7.

Le groupe d'accès pour la contrepartie est attribué dans l'onglet « autre ». J'utilise généralement un traitement standard auxiliaire pour attribuer des données à des groupes. « Traitement groupé des répertoires et des documents », il permet de définir massivement le groupe souhaité pour ce détail.

Cette étape est l’étape culminante. A ce stade, l'accès des « groupes d'utilisateurs » aux « groupes d'accès des contreparties » est configuré ; ceci est configuré à l'aide du traitement « Définition des droits d'accès au niveau de l'enregistrement », voir Fig. 8.

La relation entre les groupes d'utilisateurs et les groupes d'accès des contreparties est mise en évidence en rouge. Pour les groupes « Responsables des achats » et « Responsables des ventes », les relations sont configurées exactement de la même manière, seuls les objets d'accès sont précisés comme ceux auxquels ils doivent avoir accès, par exemple uniquement « Fournisseurs » ou uniquement « Acheteurs ». Les drapeaux, par exemple « Visibilité dans la liste » sont les droits de « l'Objet d'accès ». D'après le nom, je pense que la fonctionnalité de ces droits est claire.

Après les manipulations mentionnées ci-dessus, vous devriez avoir un accès limité au répertoire « Contreparties ».

Les autres répertoires sont configurés de la même manière.

Important:

L'accès limité ne s'applique pas au rôle « Pleins droits » ;

L'ensemble des rôles utilisateur doit contenir le rôle « Utilisateur » ;

Si vous disposez de vos propres rôles, alors vous devez insérer des modèles et des restrictions dans votre rôle comme dans le rôle « Utilisateur » par rapport au répertoire « Contreparties » (voir le code dans le rôle Utilisateur en cliquant sur le répertoire des contreparties).

La plate-forme 1C:Enterprise 8 dispose d'un mécanisme intégré pour restreindre l'accès aux données au niveau de l'enregistrement. Vous pouvez lire des informations générales à ce sujet ici. En bref, RLS vous permettra de restreindre l'accès aux données en fonction de certaines conditions sur les valeurs des champs. Par exemple, vous pouvez restreindre l'accès des utilisateurs aux documents en fonction de la valeur de l'attribut « Organisation ». Certains utilisateurs travailleront avec des documents pour l'organisation « Société de gestion », et d'autres avec l'organisation « Usine laitière ». A titre d'exemple.

Préparation

Nous implémenterons l'exemple dans la configuration démo de SCP 1.3. Créons un utilisateur "Storekeeper" et ajoutons-lui le rôle du même nom "Storekeeper".

Passons maintenant directement à la configuration des droits d'accès au niveau de l'enregistrement. Passons à l'interface "Administration des utilisateurs". Dans le menu principal, sélectionnez « Accès au niveau de l'enregistrement -> Options ». Ici, cochez la case à côté de « Restreindre l'accès au niveau de l'enregistrement par type d'objet » et sélectionnez « Organisations » dans la liste des objets.

Ainsi, nous avons activé l'utilisation de RLS. Vous devez maintenant le configurer.

Le contrôle d’accès au niveau de l’enregistrement n’est pas configuré séparément pour chaque utilisateur ou profil d’autorisation. RLS est configuré pour les groupes d'utilisateurs. Ajoutons un nouveau groupe d'utilisateurs, appelons-le "Storekeepers".

La composition du groupe sur le côté droit du formulaire affiche une liste des utilisateurs appartenant à ce groupe. Ajoutons l'utilisateur que nous avons créé précédemment à la liste. A gauche se trouve un tableau des restrictions d'accès. Lors de la configuration de RLS, nous avons choisi que l'accès soit limité uniquement par les organisations, nous ne voyons donc qu'un seul type d'objet d'accès. Cliquez sur le bouton "Accéder aux paramètres". Le processus de définition des droits d'accès pour le groupe actuel s'ouvrira.

Ajoutons l'organisation « IPE « Entrepreneur » à la liste des objets d'accès du groupe. Le type de succession des droits restera inchangé. Nous définirons le droit à l'objet d'accès en lecture et en écriture. Cliquez sur "OK", les paramètres sont prêts. Nous venons de configurer RLS au niveau de l'organisation.

Ce que voit l'utilisateur

Lançons le programme sous l'utilisateur précédemment créé et ouvrons le répertoire "Organisations". Voici à quoi ressemblera la liste pour notre utilisateur et pour un utilisateur disposant de tous les droits :

Comme nous pouvons le constater, l'utilisateur magasinier ne voit qu'une seule organisation pour laquelle nous avons accordé un accès en lecture. Il en va de même pour les documents, par exemple la réception de biens et de services.

Ainsi, l'utilisateur non seulement ne verra pas les organisations pour lesquelles l'accès n'est pas défini pour lui, mais ne pourra pas non plus lire/écrire les documents et autres objets de la base d'informations pour lesquels les droits sont définis dans le rôle « Organisation ». attribut.

Nous avons examiné l'exemple le plus simple de configuration de RLS. Dans le prochain article nous parlerons de l'implémentation du mécanisme RLS dans la configuration "Manufacturing Enterprise Management" version 1.3.

La huitième version de la plateforme 1C:Enterprise (aujourd'hui 8.3) comportait de nombreux changements par rapport aux « sept », parmi lesquels le mécanisme de restriction des droits d'accès au niveau de l'enregistrement était particulièrement remarquable. Malgré le fait qu'il soit théoriquement possible de s'en passer, en utilisant uniquement des rôles, RLS permet d'obtenir des paramètres d'accès plus fins. Mais pour faire fonctionner correctement ce mécanisme, vous devez clairement comprendre son essence et avoir une expérience suffisante en développement en 1C.

Qu’est-ce que le SJSR ?

L'essence de cette fonctionnalité est la capacité du développeur à empêcher un utilisateur ou un groupe d'utilisateurs spécifique d'accéder aux tables ou aux champs des tables de la base de données. En règle générale, les restrictions sont utilisées pour empêcher les utilisateurs de 1C de voir et de modifier des informations confidentielles et secrètes, par exemple en limitant les employés d'une entreprise inclus dans un groupe à consulter des documents uniquement pour leur organisation. De plus, le mécanisme de restriction des droits d'accès au niveau de l'enregistrement peut être utilisé pour supprimer les informations inutiles de l'interface.

Pour pouvoir écrire des requêtes pour les restrictions RLS, vous devez créer un rôle ou en prendre un existant. La configuration de RLS dans 1C 8.3 peut être utilisée pour les actions utilisateur suivantes :

Ajout;
En lisant;
Supprimer;
Changement.

Outre les possibilités de personnalisation des accès les plus larges, RLS présente également des inconvénients :

Exigences de qualification du développeur, puisque la demande devra être rédigée dans un langage intégré, en tenant compte des règles de syntaxe ;
Manque de capacité à déboguer rapidement les conditions ;
Possibilités limitées de description de la logique : des conditions trop complexes devront encore être écrites dans des modules de documents et d'ouvrages de référence ;
Dans la version client-serveur de la base de données, une croissance implicite des tables incluses dans la requête est possible. De plus, il est très difficile de suivre ce processus ;
Besoins en ressources. Les restrictions RLS consomment beaucoup d'énergie sur la machine client et le serveur ;
Peu de documentation est disponible gratuitement.

Un autre problème qui peut survenir après la configuration de 1C RLS peut être celui des rapports. Le fait est que les développeurs prévoient d'éventuelles restrictions RLS et créent des rapports de manière à afficher uniquement les données autorisées. Si les utilisateurs ont configuré différentes restrictions RLS, les données du rapport pour les mêmes paramètres peuvent être différentes. Cela peut soulever des questions, vous devez donc prendre en compte ces situations lors de la conception de rapports ou de l'écriture de requêtes dans RLS.

Créer une contrainte RLS

Afin d'ajouter une restriction RLS, vous devez rechercher le rôle souhaité et l'ouvrir en double-cliquant.

La fenêtre qui s'ouvre contient 2 onglets : « Droits » et « Modèles de restrictions ». Pour imposer certaines restrictions sur une action spécifique, vous devez la sélectionner et cliquer sur le plus vert en bas à droite. Une ligne apparaîtra dans laquelle nous pouvons définir les restrictions 1C RLS dans le langage intégré à 1C.

Si vous connaissez la syntaxe 1C (comme le bout de votre main), alors vous pouvez écrire directement dans le champ « Restriction d'accès ». Les développeurs 1C ont fourni la possibilité d'ouvrir un constructeur de requêtes, ce qui aidera et suggérera quelles restrictions peuvent être apportées. Pour l'ouvrir, vous devez cliquer sur le bouton à trois points (Sélectionner) ou F4 et une fenêtre avec le bouton « Query Designer... » apparaîtra.

Dans la fenêtre qui apparaît, vous pouvez configurer des restrictions non seulement pour ce répertoire, mais également pour d'autres objets système. Pour ce faire, vous devez les ajouter dans l'onglet « Tables et champs ». Nous enregistrons les restrictions sur les champs du répertoire « Nomenclature » et cliquons sur « OK ». Attention aux noms des variables : les paramètres RLS sont définis au début de la session utilisateur et doivent être contenus dans l'objet métadonnées.

Dans l'onglet « Modèles de contraintes », vous spécifiez les requêtes nécessaires lors de la copie des mêmes paramètres RLS dans 1C 8.3. Après avoir ajouté votre modèle, vous pouvez utiliser son nom dans les paramètres des droits d'accès.

Il est également possible d'ajouter simultanément des restrictions à plusieurs rôles. Pour ce faire, dans l'arborescence de configuration, vous devez faire un clic droit sur la section « Rôles » et sélectionner « Tous les rôles ».

En conclusion, je voudrais souligner que cet article s'adresse aux développeurs consultants 1C et peut aider principalement ceux qui ont déjà une expérience en développement sur 1C:Enterprise. Malgré son apparente simplicité, la connaissance de la sémantique et la compréhension de la structure des processus commerciaux de sa propre entreprise ou de l’organisation d’un client pour la répartition correcte des droits nécessitent un certain niveau de connaissances et d’expérience.

Dans le système 1C Enterprise 8, nous continuerons aujourd'hui à étudier le mécanisme des droits et à approfondir le mécanisme RLS (restriction des droits au niveau de l'enregistrement).

Ci-dessous, nous examinerons les avantages et les inconvénients de cette méthode et examinerons la configuration de RLS dans 1C Enterprise 8.3 à l'aide d'un exemple.

1C RLS (Record Level Security) ou restriction des droits au niveau de l'enregistrement- ce sont des droits d'utilisateur dans le système 1C, qui permettent de séparer les droits des utilisateurs dans le contexte de données évoluant dynamiquement.

Le type le plus courant de paramètre 1C RLS consiste à limiter la visibilité de l'utilisateur par organisation ou client (l'utilisateur ne voit que « ses » données).

Le principal avantage est la présence d'un mécanisme ; le mécanisme est assez complexe et intéressant. Vous permet de différencier très finement les droits des utilisateurs - les utilisateurs peuvent même ne pas être conscients de l'existence d'autres données dans le système.

Inconvénients du 1C 8 RLS

Parmi les lacunes, on peut noter une baisse notable des performances du système. Cela est dû au fait que la plateforme, lors de la construction d'une requête dans la base de données, complique toute demande du développeur avec des conditions supplémentaires.

Parmi les inconvénients figurent également la complexité de configuration de cette fonctionnalité et la difficulté de débogage. 1C a publié très peu d'informations sur la configuration et le fonctionnement de cette fonctionnalité. Il est assez difficile de trouver un spécialiste qui mettrait en place correctement le mécanisme.

Mise en place de restrictions de droits au niveau de l'enregistrement 1C RLS

Les autorisations au niveau de l'enregistrement (RLS) sont utilisées pour restreindre les types de droits suivants :

En lisant
Ajout
Changement
Suppression

Obtenez 267 leçons vidéo sur 1C gratuitement :

En externe, la configuration de RLS (droits au niveau de l'enregistrement) est similaire à la création d'un simple fichier . Un exemple de modèle pour restreindre l'accès à la visibilité des documents par client depuis l'entête du document :

##Si &Utilisez les restrictions de droits d'accès au niveau de l'enregistrement ##Alors

TableActuelle DE #TableActuelle AS TableActuelle
REJOINDRE À GAUCHE (SÉLECTIONNER DIVERS
Composition du groupe.Link Groupe d'utilisateurs AS
DEPUIS
Répertoire.Groupes d'utilisateurs.UsersGroups Composition du groupe AS
OÙ
GroupComposition.User = &CurrentUser) AS UserGroups
Logiciel (&Restrictions des droits d'accès au niveau de l'enregistrement)
OÙ (&UseRecordLevelPermissionRestrictions = FALSE
OU (PAS 1 V
(SÉLECTIONNEZ LE TOP 1
1 COMMENT SÉLECTIONNER
DEPUIS
Registre d'informations. Objectif des types d'objets d'accès AS Objectif des types d'objets d'accès.
OÙ
Objectif des types d'accès Objects.UserGroup = UserGroups.UserGroup
ET CHOIX
QUAND Objet des types d'objets d'accès Type d'objet d'accès = VALEUR (Énumération. Types d'objets d'accès. Contreparties)
Et CurrentTable.#Parameter(1) LINK Directory.Counterparties
ET NON CurrentTable.#Parameter(1) = VALUE(Directory.Accounts.EmptyLink)
ALORS CHOIX
QUAND 1 V
(SÉLECTIONNEZ LE TOP 1
1
DEPUIS
Annuaire.Contreparties AS Entrepreneurs INTERNE JOIN Informations Registre.Paramètres des droits d'accès utilisateur AS Paramètres des droits d'accès utilisateur
PAR
UserAccessRightSettings.AccessObject = Contreparties.AccessGroupToCounterparty
Et UserAccessRightSettings.AccessObjectType = VALUE(Enumeration.AccessObjectTypes.Counterparties)
ET (Paramètres des droits d'accès utilisateur. Utilisateur = Attribution des types d'objets d'accès. Groupe d'utilisateurs
OU UserAccessRightSettings.User = VALEUR (Directory.UserGroups.AllUsers))
Et UserAccessRightSettings.Record = TRUE
OÙ
Contreparties.Link = CurrentTable.#Parameter(1))
ALORS LA VÉRITÉ
AUTRE FAUX
FIN
AUTREMENT VRAI
FIN = FAUX))
ET NON UserGroups.UserGroup EST NULL)
##FinSi

Essentiellement, cette requête est ajoutée chaque fois que la table "#CurrentTable" est interrogée. D'où nous pouvons imaginer quelle charge supplémentaire supporte le mécanisme de restriction au niveau de l'enregistrement.

Comme vous pouvez le constater, la demande comporte des paramètres spéciaux, par exemple « & Utiliser les restrictions des droits d'accès au niveau de l'enregistrement ». Ces paramètres dans le radar sont sélectionnés à partir d'objets de métadonnées - " ". En règle générale, ils sont définis au début de la session utilisateur.

Constructeur de restrictions d'accès aux données

Pour la commodité du développeur, 1C 8.3 dispose d'un utilitaire spécial pour aider à configurer le radar - Data Access Restriction Designer. Elle est appelée depuis le champ « Restriction d'accès ». Cela ressemble à ceci :