x

Typiquement, le sujet d'une règle est un groupe. Il est possible d'appliquer une règle à un seul utilisateur, mais ceci n'est généralement pas recommandé, car gérer les règles sur utilisateur individuel peut considérablement augmenter la charge de travail. Il est plus facile de modifier les règles qui s'appliquent à l'utilisateur un ajoutant ou en supprimer suppriment en retirant l'utilisateur d'un groupe, sans avoir à changer les règles elles-mêmes. Cette rubrique suppose que votre stratégie de sécurité sera basée sur les groupes, mais vous pouvez toujours affiner une stratégie en ajoutant des règles au niveau des utilisateurs individuels, si nécessaire.

Les modèles de domaine définissent quatre rôles (utilisateur basique, utilisateur avancé, et administrateur de groupe), qui sont implémentés en tant que sous-groupe placé sous un groupe pour le domaine. Les capacités des utilisateurs dans le groupe Utilisateur Basique sont déterminées par les règles associées au rôle Utilisateur Basique, alors que les capacités des utilisateurs dans le groupe Utilisateurs Avancé sont à la fois déterminées par les règles associées au rôle Utilisateur Basique et par les règles associées au rôle Utilisateur Avancé. Les capacités d'un utilisateur avancé incluent celles que possèdent les utilisateurs basiques, et les capacités d'un développeur incluent celles que possèdent les utilisateurs avancés, comme le montre le diagramme suivant. Les administrateurs de groupe ne sont pas autorisés à exécuter les rapports ou à visualiser la sortie de bibliothèque de façon à ce que leurs permissions ne chevauchent pas celles des utilisateurs dans d'autres sous-groupes.

L'imbrication des rôles simplifie la conception de stratégie. Un utilisateur n'a besoin d'appartenir qu'à un seul de ces groupes pour obtenir toutes les capacités de ce type d'utilisateur. Un utilisateur peut aussi être ajouté aux groupes Groupe Administrateur et à l'un des autres groupes, s'il s'avère nécessaire qu'un individu obtienne cet ensemble de capacités. Les règles peuvent être appliqués à un groupe parent pour permettre à tous ces utilisateurs de partager leur contenu, ou de permettre aux administrateurs de groupe de contrôler ces parents et ses sous-groupes.

Alternativement, vous pouvez partitionner les capacités utilisateur en plusieurs rôles distincts sans superposer les privilèges. Bien que ce modèle permette la plus grande flexibilité, il est aussi plus difficile à administrer dans la mesure où les capacités de chaque utilisateur sont un composite de plusieurs rôles et de plusieurs règles.

De plus, vous pourrez avoir besoin de groupes d'infrastructures pour l'organisation des utilisateurs nécessitant un accès à toutes les ressources du système. Par exemple, un groupe administrateur, ou un groupe contrôle du changement prenant les décisions concernant l'export de ressources sur l'ensemble du référentiel sans pour autant exécuter ou supprimer des ressources.

Pour plus d'informations sur les groupes, consultez Gestion des utilisateurs et des groupes.

x

Les rôles sont utilisés pour regrouper un jeu de privilèges souvent affectés en commun. Une règle de sécurité va alors permettre ou refuser le rôle pour une ressource, comme le montre l'image suivante.

Après avoir déterminé l'organisation des utilisateurs en groupes, vous pouvez concevoir les rôles qui s'avéreront utiles pour ces groupes. S'il existe un seul groupe par type d'utilisateur, comme c'est le cas dans les modèles de domaine, la méthode la plus simple est de créer un rôle par type l'utilisateur. Vous pouvez alors créer des règles qui accordent ou refusent chaque rôle à son groupe respectif pour une ressource particulière.

Par exemple, les modèles de domaine créent une règle qui affecte le rôle DomainBasicUser au groupe BasicUser sur le dossier domaine et ses enfants. Le groupe AdvancedUser est associé au rôle DomainAdvancedUser sur le dossier de domaine et ses enfants. Vous pouvez concevoir des règles similaires pour accorder aux sous-groupes personnalisés que vous créez l'accès approprié au portail de domaine, ou encore à une page de domaine sur un portail partager. Pour assurer l'accès développeur au serveur de rapports, vous pouvez créer une règle accordant le rôle DomainDeveloper aux groupes développeurs sur le serveur de rapports dans l'arborescence de ressources.

Un rôle peut être utilisé dans plusieurs règles, par exemple dans le cas où vous souhaitez accorder des privilèges à un groupe sur différents types de ressources. Si vous souhaitez accorder des privilèges développeurs sur un dossier, un portail, et un nœud serveur de rapports, vous pouvez créer un rôle qui collectera tous les privilèges nécessaires, puis créer une règle séparée qui s'appliquera au rôle pour chaque ressource concernée. WebFOCUS ignore les privilèges ne s'appliquant pas à un sous-système donné. Vous pouvez aussi créer un rôle séparé pour les développeurs sur chaque ressource qui ne collecte que les privilèges liés au sous-système IBFS associé. Vous pourriez créer un rôle pour développeurs qui spécifie le dossier, un rôle spécifiant le portail, et un rôle spécifiant le nom serveur de rapports. Cependant, un rôle unique est plus facile à maintenir.

Remarque : les rôles qui incluent les privilèges de session ne devraient pas être utilisés dans des règles qui sont spécifiées dans les branches inférieures du sous-système WFC. Par défaut, WebFOCUS ne vérifie pas les privilèges de session en dessous d'une certaine profondeur, à fin de limiter les demandes d'accès aux ressources système. La profondeur de recherche peut être changée par un administrateur système, mais cela n'est pas recommandé.

Pour plus d'informations sur la modification de la profondeur de recherche, consultez Paramètres de sécurité. Pour plus d'informations sur les rôles, consultez Gestion de rôles.

x

Le système sera d'autant plus facile à comprendre et à maintenir que si un minimum de règles lui est affecté. Le nombre de règles comprises dans votre stratégie de sécurité dépend de plusieurs facteurs, par exemple quels sous-systèmes doivent être exposés aux utilisateurs, combien de rôles différents votre organisation nécessite, et combien de domaines sont présents dans votre organisation. Vous pouvez réduire le nombre de règles dans notre système en les appliquant au plus haut niveau possible dans la hiérarchie IBFS. En général, ceci correspond à accorder des privilèges au plus haut niveau possible, puis à les refuser à des niveaux inférieurs autant que nécessaire.

Par exemple, considérez un scénario simple dans lequel tous les intervenants d'une installation ont accès à toutes les ressources et les utilisateurs n'ont besoin que de deux choses : développer les rapports ou les exécuter. Vous pouvez implémenter cela très simplement en utilisant deux groupes et deux règles. Ces deux groupes sont le groupe Développeur rapport et le groupe Lanceur rapport. Les deux règles sont placées sur le nœud racine IBFS, et s'appliquent donc à tous les dossiers de contenu, aux portails, et aux ressources du serveur de rapports. Une règle affecte le rôle développeur rapport au groupe développeur rapport sur le dossier racine IBFS et tous ses enfants, tandis que l'autre règle affecte le rôle lanceur rapport au groupe lanceur rapport dans le même champ d'application. Avec une seule règle supplémentaire, vous pouvez masquer le nœud serveur de rapports au groupe lanceur rapport en refusant le rôle liste à ce groupe et sur ce nœud.

Il arrive souvent que des groupes différents aient besoin d'accéder à des ressources différentes. La stratégie de sécurité fournie par les modèles de domaine prend en charge besoin. Dans chaque domaine, les groupes obtiennent un accès à leurs propres ressources, et aucun groupe n'est associé aux règles situées au-dessus des dossiers de domaine et des portails. Des règles spécialisées peuvent être appliques pour ajuster la stratégie à fin de prendre en charge ses besoins supplémentaires, par exemple masquer des dossiers spécifiques ou des pages de portail.

Un besoin fréquent le besoin pour des utilisateurs d'agir au niveau des contenus d'un conteneur, sans pour autant pouvoir modifier le conteneur lui-même. Par exemple, les développeurs ont besoin de créer et de supprimer des dossiers dans Ventes mais vraisemblablement, mais ne devraient pas supprimer le dossier Ventes lui-même. Vous pouvez répondre à ce besoin en refusant des privilèges spécifiques avec une règle qui sera utilisée uniquement sur le dossier. Les modèles de domaine fonctionnent de cette façon pour les développeurs de domaine et les administrateurs de groupe, de façon à ce qu'ils ne puissent pas supprimer les conteneurs qui définissent leurs limites de sécurité, en particulier les dossiers sur lesquels ils disposent d'un contrôle d'administration.

Pour plus d'informations sur les règles, consultez Gérer les règles.

x

WebFOCUS rend possible la délégation des responsabilités pour la plupart des fonctions d'administration, y compris :

• Création de groupes et d'utilisateurs.
• Affecter des utilisateurs à des groupes.
• Créer des règles de sécurité limitées, tel que refuser à des membres d'un groupe spécial d'accéder à un sous-dossiers.
• Gérer du contenu privé pour des utilisateurs.
• Réaffecter les propriétaires de ressources telles que les plannings et les rapports.

Les modèles de domaine fournissent deux exemples de la manière d'approcher la conception d'une stratégie d'administration de groupe. Dans le modèle Domaine Entreprise, les administrateurs de groupe peuvent voir tous les utilisateurs dans WebFOCUS au sein du centre de sécurité, et ajouter n'importe quel utilisateur pour les groupes dont ils assurent la gestion. Cependant, dans le modèle de domaine Locataire logiciel, les administrateurs de groupe ne peuvent voir et gérer que la souscription des utilisateurs dans leur propre groupe locataire. Cette différence de stratégie et implémenter simplement en modifiant la règle qui affecte le rôle DomainGroupAdminScope pour qu'elle s'applique au groupe EVERYONE ou au groupe locataire. De la même façon, une règle affectant le rôle Gérer Utilisateurs aux administrateurs de groupe d'entreprise sur leur groupe parent permet aux administrateurs de créer des utilisateurs.

Pour plus d'informations sur les groupes, consultez Gestion des utilisateurs et des groupes.

x

Il est recommandé d'utiliser des règles IBFS pour masquer ou exposer les nœuds de serveurs de rapports à la demande, mais d'utiliser les fonctions Rôles Serveur de rapports et Contrôle d'accès pour protéger des ressources spécifiques sur le serveur. Les règles appliquées au niveau des ressources de serveur de rapports en dessous du noeud n'affecteront pas le contenu présent dans d'autres parties de l'interface utilisateur WebFOCUS. Elles ne s'appliqueront qu'à la vue de l'arborescence ressource.. Les fonctions du contrôle d'accès au serveur de rapports fournissent une bien meilleure sécurité pour contrôler l'accès aux paramètres du moteur du serveur, par exemple l'utilisation de SQL ou de commandes système, et ce pour des dossiers applicatifs contenant des métadonnées et des données téléchargées.

x

La sécurité IBFS gouverne les ressources dans le référentiel WebFOCUS et certaines ressources externes, par exemple les nœuds du serveur de rapports. Cependant, l'accès aux lignes de données dans une base de données ou à des noms de champ dans les métadonnées WebFOCUS est gouverné par les fonctions de sécurité des données WebFOCUS (DBA). Vous pouvez utiliser ces fonctionnalités de sécurité des données en passant l'ID utilisateur WebFOCUS authentifié et les groupes utilisateur au serveur de rapports.

Pour plus d'informations sur l'échange d'informations entre le Client WebFOCUS et le Serveur de rapports WebFOCUS, consultez Détails sur le traitement central du Serveur de Rapports WebFOCUS.