Fermer

décembre 28, 2018

Sécurité Oracle Fusion SaaS avec Oracle Analytics Cloud


La question souvent posée est la suivante: pouvons-nous utiliser la même sécurité que celle que nous avons déjà dans Oracle Fusion SaaS (y compris les utilisateurs, les tâches, les rôles et les règles de sécurité) pour sécuriser les données dans Oracle Analytics Cloud (OAC – un PaaS Oracle) ? La réponse est oui. Pour mieux comprendre comment cela est possible, continuez à lire. Ce blog suit mes 2 précédents articles sur Intégration de données Oracle SaaS dans OAC et Création de la réplication de données OAC à partir d'Oracle SaaS . Alors que les publications précédentes décrivaient comment charger des données SaaS dans OAC, ce blog explique comment faire en sorte que OAC hérite de la sécurité d'Oracle Fusion SaaS et évite ainsi la tâche fastidieuse de maintenance manuelle des configurations de sécurité à plusieurs endroits.

Avant d'entrer dans les détails, Il est important de faire la distinction entre la sécurisation des données Oracle SaaS transférées directement vers OAC via une connexion de jeu de données et les données Oracle SaaS répliquées dans un entrepôt de données OAC, via l'une des techniques de copie des données (synchronisation des données, réplication des données, etc.). Flux de données ou autres moyens ETL)

1. Connexion d'un ensemble de données OAC avec Oracle SaaS : Cette approche exploite l'adaptateur de connexion d'application OAC Oracle. Il permet l'authentification avec un utilisateur administrateur partagé ou avec un identifiant d'utilisateur final. En choisissant de faire en sorte que les utilisateurs finaux se connectent avec leurs propres informations d'identification Oracle Fusion App, leurs rôles de sécurité et leurs stratégies de données sont automatiquement appliqués à tous les rapports qu'ils établissent avec l'application Fusion. Par conséquent, avec une connexion à un ensemble de données, aucune configuration supplémentaire n'est nécessaire pour hériter de la sécurité de Fusion App dans OAC, puisqu'elle se déclenche une fois que l'utilisateur final se connecte avec ses informations d'identification Fusion.

2. Connexion entre magasin de données CAO : Cette approche interroge un réplica des données de l'application Fusion qui a été copié dans un entrepôt de données. En conséquence, les données répliquées nécessitent que les contrôles de sécurité des objets et des données soient définis dans le CAO. Heureusement, bien que cela nécessite une configuration manuelle unique, il repose sur les attributions de rôle de sécurité et les stratégies de données configurées dans l’application Fusion source.

Le reste de cet article de blog développe le second type de connexion et explique comment faire en sorte que le CAO hérite de la sécurité de Fusion App par rapport à un entrepôt de données.

Je vais commencer mon explication en décrivant le fonctionnement de l'authentification, puis nous expliquerons comment configurer l'autorisation à la fois pour la sécurité des objets et pour la sécurité des données.

Authentification :

  • Authentification OAC : Selon la configuration de votre instance OAC, vous utiliserez peut-être le serveur Weblogic intégré OAC en tant que fournisseur d'identité ou Oracle Identity Cloud Service (IDCS). La fondation IDCS est quelque chose que vous avez déjà dans votre abonnement CAO (si vous avez des crédits universels), et vous êtes fortement encouragé à commencer à l’utiliser, si vous ne l’avez pas déjà fait. Vous devrez utiliser IDCS en tant que fournisseur d’identité pour le CAO pour établir une authentification unique (SSO) avec votre application Fusion. IDCS est l'endroit où les utilisateurs, les rôles et les attributions de rôles sont définis. En outre, IDCS sert de fournisseur d'identité commun à plusieurs services Oracle Cloud, ainsi qu'à des systèmes Cloud et sur site non Oracle qu'il peut être nécessaire d'intégrer pour la fédération d'utilisateurs et la connexion unique. Pour les besoins de ce blog, l’idée principale est de permettre à IDCS d’hériter des utilisateurs, des rôles et des attributions de rôles de votre application Fusion pour pouvoir les partager avec le CAO.
  • Authentification de l’application Fusion : Idéalement, IDCS est configuré en tant que Fournisseur d'identité pour l'application Oracle Fusion. Cependant, il est fort possible que ce ne soit pas le cas. De nombreux abonnés de Fusion Cloud App n’avaient pas d’IDCS au moment où ils configuraient leurs applications Oracle SaaS. Par conséquent, ils ont fini par utiliser le fournisseur d'identité Fusion App intégré pour gérer les comptes d'utilisateur Fusion. Si cela semble familier, il n'y a pas besoin de s'inquiéter. Ci-dessous, je vais expliquer comment l'héritage des configurations de sécurité de Fusion Apps vers OAC est possible dans les deux scénarios:

Autorisation : Il existe 2 niveaux d'autorisations différents qui doivent être configurés: sécurité au niveau des objets et sécurité au niveau des données.

  1. Sécurité au niveau des objets : définit les objets du catalogue (tableaux de bord, rapports, projets de visualisation des données, etc.), ainsi que les domaines et les modèles de données auxquels un utilisateur CAO a accès, et avec quel type d'autorisation en lecture seule ou modifiable). Pour sécuriser de manière transparente les objets OAC en fonction de la sécurité de Fusion App, nous identifions d’abord les rôles Fusion App que nous souhaitons utiliser pour configurer les autorisations d’objet OAC. Par exemple, si l'application Fusion est HCM, vous pouvez hériter des rôles de spécialiste des ressources humaines, d'analyste des ressources humaines et de gestionnaire de la paie. Les utilisateurs qui ont ces rôles dans Fusion auront automatiquement accès aux objets correspondants dans OAC. Une telle configuration permet de gagner beaucoup de temps du point de vue de la maintenance du point de vue de la maintenance. Faire en sorte que le CAO hérite des rôles de Fusion App et que les attributions de rôles reposent sur le fait que IDCS doit servir de pont entre les applications Fusion et le CAO. Cette intégration est légèrement différente selon que vous utilisez IDCS ou Fusion App en tant que fournisseur d'identité pour Fusion App. Voici comment les choses fonctionnent dans ces deux scénarios:
    • Scénario 1 : IDCS est un fournisseur d'identité pour le CAO uniquement lorsque Fusion App utilise son fournisseur d'identification intégré pour la gestion des utilisateurs. Dans ce scénario, IDCS est configuré pour agir en tant que fournisseur de services pour l'application Fusion (en d'autres termes, Fusion App est le fournisseur d'identité pour IDCS.) Les mots de passe continuent à être stockés et conservés dans l'application Fusion. Les utilisateurs, les rôles et les attributions d'utilisateur à utilisateur seront tous définis dans l'application Fusion, puis synchronisés sur IDCS. Les nouvelles créations, mises à jour et inactivation des utilisateurs de Fusion App sont automatiquement transférées dans IDCS et OAC. Cette synchronisation automatique des applications Fusion vers IDCS s'effectue par le biais de tâches Oracle Enterprise Scheduler (ESS). Plus de détails sur la configuration des synchronisations sont disponibles dans ce document oracle .
    • Scénario 2 : IDCS en tant que fournisseur d'identité pour OAC et Fusion App. Dans ce cas, les comptes d'utilisateur et leurs mots de passe sont stockés et gérés dans IDCS. Les utilisateurs peuvent être définis dans IDCS ou dans l’application Fusion et synchronisés avec l’autre côté. Toutefois, les rôles et attributions de rôles sont toujours définis dans l’application Fusion, comme d’habitude, et synchronisés avec IDCS comme dans le scénario 1. En résumé, qu’il s’agisse du premier ou du second scénario, les administrateurs de Fusion App continuent de maintenir la sécurité de la même manière. faire avant d'activer le CAO. Ils ne nécessitent pas de frais généraux du point de vue de la maintenance en cours.
  2. Sécurité au niveau des données : C'est ce qui indique au CAO quel utilisateur a accès à quels sous-ensembles de données. Par exemple, limitez l'accès aux informations en fonction de la position, de la hiérarchie de superviseur ou d'une liste de paie HCM. Comme pour la sécurisation des objets du CAO, il est vivement recommandé d'associer la sécurité au niveau des données du CAO aux stratégies de sécurité des données de l'application Fusion. Investissez suffisamment de temps pour réaliser une configuration unique et évitez les tracas de la maintenance double et compliquée. Vous devez d'abord identifier les objets de sécurité des données à sécuriser en dehors de l'application Fusion (par exemple, par emplacement ou par unité commerciale). Fusion Data Roles associe le travail d’un utilisateur aux données auxquelles il accède (par exemple, un spécialiste des ressources humaines au niveau national). Les rôles de données sont définis dans les profils de sécurité de Fusion App. Nous devons donc créer un système IDCS et, en conséquence, le CAO, hériter des rôles de données Fusion et appliquer des filtres de sécurité sur ces rôles dans le modèle de données du CAO. Pour configurer la sécurité des données dans le CAO, nous devons connaître les objets de visualisation publics (PVO) de Fusion qui fournissent les identificateurs d'objet de données de sécurité autorisés par l'utilisateur (tels que la liste des services auxquels un utilisateur connecté a accès). Une fois la source Fusion identifiée, nous définissons ensuite les variables de session OAC pour interroger les PVO Fusion App. Lors de l'application initiale de filtres de sécurité sur les rôles de données hérités dans l'OAC, nous reproduisons les stratégies de sécurité définies dans l'App Fusion. Notez que la sécurisation des rôles d'application du CAO en appliquant des filtres de sécurité au niveau des données aux domaines du CAO peut être effectuée dans le Thell Data Modeler du CAO ou dans l'outil d'administration du référentiel client du CAO. Pour une sécurité plus complexe au niveau des données dans plusieurs rôles d'application, Client Admin Too offre une meilleure façon de définir ces filtres.

En conclusion, l'intégration d'Oracle Fusion SaaS Security dans OAC est un élément essentiel d'une implémentation réussie d'Oracle Analytics. Effectuer une intégration de sécurité complète avec le SaaS qui couvre les différentes couches, y compris les utilisateurs, les objets et les données, est crucial. Le succès de la mise en œuvre dépend de la sécurité des données de l'entreprise et de la possibilité d'éviter les coûts de maintenance qui auraient été nécessaires sans une solution de sécurité bien planifiée et intégrée pour Oracle SaaS et PaaS.




Source link