Séparation de domaine dans GRC
Il s’agit Gouvernance, risque et conformité d’une vue d’ensemble de Séparation de domaine et des applications. Séparation de domaine vous permet de séparer les données, les processus et les tâches administratives en groupes logiques appelés domaines. Vous pouvez contrôler plusieurs aspects de cette séparation, notamment les utilisateurs qui peuvent voir les données et y accéder.
Niveau de prise en charge : basique
- Logique métier : garantit que les données parviennent au bon domaine pour les cas d'utilisation du fournisseur de service de l'application.
- L'application prend en charge Séparation de domaine lors de l'exécution. Séparation de domaine inclut la séparation à partir de l'interface utilisateur, des clés de cache, du reporting, des déploiements et des agrégations.
- Le propriétaire de l'instance doit configurer l'application de sorte qu'elle fonctionne sur plusieurs locataires.
Exemple de cas d'utilisation : lorsqu'un fournisseur de service (SP) utilise la messagerie instantanée pour répondre au message d'un locataire-client, le client doit pouvoir afficher la réponse du SP.
Pour en savoir plus sur les niveaux de prise en charge, consultez la rubrique Prise en charge de Séparation de domaine par les applications.
Vue d’ensemble de Séparation de domaine
- Nécessité d’appliquer la ségrégation absolue des données entre les entités d’entreprise (séparation des données).
- personnalisent les définitions des processus business et les interfaces utilisateur pour chaque domaine (administration déléguée) ;
- conservent certains processus globaux et des générations de rapports globaux dans une seule instance.
Fonctionnement de Séparation de domaine dans GRC
- Bien que GRC prenne en charge la séparation des données, la séparation de la logique et du processus n’est pas entièrement prise en charge.
-
De nombreux types d’enregistrements dans GRC sont générés automatiquement par le biais des processus utilisateur. Les entités, les contrôles, les risques, les indicateurs et les tests de contrôle sont tous des champs qui peuvent être générés automatiquement. Pour les enregistrements qui sont générés automatiquement, le domaine de l’enregistrement est déterminé par l’itérateur de domaine configuré pour la tâche. Dans le cas contraire, il est défini par défaut sur le domaine (s’il est défini) ou sur le domaine global. Pour les enregistrements qui sont générés manuellement, le domaine est dérivé du domaine de l’utilisateur qui crée l’enregistrement.
La génération automatique doit être gardée à l’esprit lorsque vous travaillez dans une implémentation GRC séparée par domaine. Les utilisateurs doivent s’assurer qu’ils créent/génèrent des enregistrements au bon niveau de domaine afin qu’ils soient visibles par le bon ensemble d’utilisateurs.
Par exemple, imaginons que vous ayez des domaines sous la forme suivante :- Global
- HAUT
- Domaine A
- Domaine B
- Si vous disposez d’un risque ou d’un contrôle que vous souhaitez faire évaluer par les utilisateurs des domaines A et B, le risque ou le contrôle doit être généré ou créé manuellement au niveau global. Si le risque ou le contrôle est créé dans le domaine B, vous ne serez pas en mesure de recréer le risque ou le contrôle dans le domaine A en raison de l’indexation.
- Si vous disposez d’un risque ou d’un contrôle que vous souhaitez faire évaluer par les utilisateurs dans TOP et le domaine A, vous pouvez créer le risque ou le contrôle dans le domaine A.
À moins que les risques et les contrôles ne se trouvent dans le domaine global, les utilisateurs ne doivent pas affecter de risques ou de contrôles d’un domaine supérieur aux utilisateurs d’un domaine inférieur. Dans l’exemple ci-dessus, si vous avez un contrôle dans le domaine TOP, vous ne devez pas l’affecter pour attestation aux utilisateurs des domaines A ou B, car ces utilisateurs n’auraient pas accès au contrôle ; Par conséquent, le questionnaire d’attestation ou d’évaluation ne serait pas généré.
De même, les utilisateurs ne doivent pas affecter des objectifs de contrôle et des déclarations de risque dans un domaine supérieur aux attestations et évaluations d’un domaine inférieur. Sinon, l’attestation ou le questionnaire d’évaluation ne serait pas généré.
Cas d'utilisation
Les données GRC pour le service informatique peuvent être séparées des données GRC d’autres départements. Chaque domaine d’activité utilisant l’application GRC peut avoir des données distinctes qui ne peuvent pas être partagées avec d’autres départements. Par conséquent, chaque département peut avoir ses propres entités, politiques, contrôles, risques, etc.
Lors de l’examen d’un contrôle du domaine informatique, l’utilisateur peut choisir d’élargir le champ d’application de domaine pour afficher les valeurs du domaine financier ou de réduire le champ d’application de domaine pour afficher uniquement les contrôles qui correspondent au domaine informatique.
Par défaut, Séparation de domaine ajoute un champ de domaine aux tables Tâche [task]et Éléments de configuration [cmdb_ci] et à leurs extensions.
Vous pouvez étendre Séparation de domaine à toutes les nouvelles tables que vous créez en ajoutant un champ sys_domain à la définition de dictionnaire de la table. Par défaut, le domaine système uniquement sépare les tables de plateforme et d'application de base de référence, le cas échéant.
[sys_dictionary] et Remplacement d’entrée de dictionnaire [sys_dictionary_override] ), car elle peut produire des résultats inattendus.Dans ce cas d'utilisation, les scripts clients, les règles métiers, les workflows, les processus, etc. peuvent être séparés par domaine.
Bien que le comportement proposé avec Domain Separation fournisse une prise en charge partagée, le partage est toujours contenu dans une seule instance. Cela signifie que certaines données et propriétés globales et certains processus globaux sont partagés dans tous les domaines. Par exemple, l'option « Mémoriser mon nom » du système sur la page de connexion est globale et ne peut pas être spécifiée par domaine.
Si une séparation complète et totale de toutes les propriétés système est nécessaire et n'exige pas de génération de rapports globaux ou de processus globaux, la meilleure approche à adopter est l'utilisation d'instances distinctes.
Comment les valeurs de domaine sont-elles allouées aux objets GRC ?
Enregistrements qui sont générés automatiquement, le domaine de l’enregistrement est déterminé par l’itérateur de domaine configuré pour la tâche. Le tableau suivant montre comment les valeurs de domaine sont allouées aux différents objets GRC :
| Objets GRC | Source du domaine |
|---|---|
| Entité | Obtient la valeur de domaine à partir de Applies_to. |
| Entité à type d’entité | Obtient la valeur de domaine à partir du type d’entité. |
| Évaluation de l’élément | Obtient la valeur de domaine à partir de l’élément (risque ou contrôle). |
| Problème | Obtient la valeur de domaine à partir de l’élément (risque ou contrôle). |
| Entité à objet d’information | Obtient la valeur de domaine à partir de l’entité. |
| Indicateur | Obtient la valeur de domaine à partir du contrôle ou du risque. |
| Tâche d'indicateur | Obtient la valeur de domaine à partir de l’indicateur. |
| Données associées | Obtient la valeur de domaine à partir de l’indicateur. |
| Résultat de l'indicateur | Obtient la valeur de domaine à partir de l’indicateur. |