Séparation de domaine dans GRC : Gestion de la politique et de la conformité

  • Rversion finale: Australia
  • Mis à jour 12 mars 2026
  • 6 minutes de lecture
  • 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.

    Avantages d’avoir des tables séparées par domaine dans Gestion de la politique et de la conformité

    Séparation de domaine est particulièrement adapté aux clients qui :
    • Nécessité d’appliquer une ségrégation absolue des données entre les entités d’entreprise (séparation des données).
    • Personnalisez les définitions de processus business et les interfaces utilisateur pour chaque domaine (administration déléguée).
    • Gérez certains processus globaux et rapports globaux en une seule instance.
    Ces utilisateurs peuvent choisir d’étendre ou de réduire le champ d’application de domaine pour afficher ou masquer les données d’autres domaines.
    Remarque :
    Les utilisateurs ont toujours accès aux données des domaines qui leur ont été explicitement accordés par la visibilité de domaine.

    Comment GRC gère Séparation de domaine

    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 enregistrements qui peuvent être générés automatiquement. Pour les enregistrements générés automatiquement (et pour tout enregistrement GRC généré manuellement), le domaine de l’enregistrement est le même que le domaine de l’utilisateur responsable de la création ou de la génération des enregistrements.
    • 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, supposons que vous ayez les domaines suivants :
      * Global
                        * Top
                            * Domain A
                            * Domain B
    • Si vous avez un risque ou un contrôle que vous souhaitez faire évaluer par les utilisateurs dans les 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 pourrez pas recréer le risque ou le contrôle dans le domaine A en raison de l’indexation.
    • Si vous avez un risque ou 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 à des 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’attribuer 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 attribuer d’objectifs de contrôle et d’énoncés de risque dans un domaine supérieur à des attestations et des évaluations dans un domaine inférieur. Sinon, le questionnaire d’attestation ou 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 des 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.

    Lorsqu’il examine un contrôle à partir 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 système sépare uniquement les tables de plateforme et d’application de base de référence par domaine, le cas échéant.

    Avertissement :
    ServiceNow ne recommande pas les tables de plateforme de séparation de domaine (toutes les tables portant le préfixe sys_, telles que les tables Entrée de dictionnaire [sys_dictionary] et Remplacement d’entrée de dictionnaire [sys_dictionary_override] ), car cela peut produire des résultats inattendus.

    Dans ce cas d’utilisation, les scripts clients, les règles métier, les workflows, les processus, etc., peuvent être séparés par domaine.

    Bien que le comportement proposé avec Séparation de domaine fournisse une prise en charge de la mutualisation, celle-ci est toujours contenue dans une seule instance. Cela signifie que certaines propriétés globales, certaines données globales et certains processus globaux sont partagés entre tous les domaines. Par exemple, l’option « Se souvenir de moi » du système sur la page de connexion est globale et ne peut pas être spécifiée par domaine.

    Si vous avez besoin d’une séparation complète et totale de toutes les propriétés système et que vous n’avez pas besoin de rapports ou de processus globaux, des instances distinctes sont la meilleure option.

    Allocation de valeurs de domaine aux Gestion de la politique et de la conformité objets

    Les enregistrements qui sont générés automatiquement via des travaux planifiés ou des scripts en arrière-plan sont séparés par domaine en fonction de leur objet parent ou de leur domaine utilisateur pour tous les objets Policy and Compliance. De même, les contrôles, les risques ou les évaluations des risques qui sont générés automatiquement en fonction des entités doivent également être séparés par domaine.

    Les changements suivants sont apportés au processus d’affectation de domaine pour gérer la ségrégation des données par les fournisseurs de services gérés liés aux Gestion de la politique et de la conformité tables :
    Gestion de la politique et de la conformité Objets Source de domaine
    Politique Domaine d'utilisateur
    Campagne de confirmation Domaine de politique
    Politique à Objectif du contrôle Domaine de politique
    Document de référence Domaine d'utilisateur
    Contenu source d'autorité Domaine du document
    Objectif de contrôle Domaine d'utilisateur
    Objectif du contrôle à Citation Domaine de citation
    Exception de politique Domaine d'utilisateur
    Approbations de l'exception de politique Domaine d’exception de politique
    Enregistrements connexes à l'exception de politique Domaine d’exception de politique
    Confirmation Domaine de l’article de la base de connaissances
    Catégorie de politique Domaine d'utilisateur
    Registre d'intégration des exceptions de politique Domaine d'utilisateur
    Mappage de la cote de risque de l'exception de politique Domaine d'utilisateur
    Statut de conformité aux politiques/réglementations Domaine du document
    Liste de choix des motifs Domaine d'utilisateur
    Choix des motifs Domaine du registre d’intégration des exceptions de politique
    Document de référence pour la taxonomie Domaine du document de référence
    Citation pour la taxonomie Domaine de citation
    Contrôle Domaine de l’entité
    Statut de la conformité d'entité Domaine de l’entité
    Contrôle à entité Domaine.Contrôle.Entité
    Objectif du contrôle associé à l'élément Domaine de l’objectif du contrôle
    Objectif du contrôle à Type d'entité Domaine du type d’entité
    Politique à Type d'entité Domaine du type d’entité
    Modèle d'article Domaine d'utilisateur
    Registre de sources de données de conformité Domaine d'utilisateur