Architecture de référence : Fusions et acquisitions

Vue d’ensemble

L’entreprise A est un fabricant d’aliments situé dans les plaines septentrionales des États-Unis. Afin de poursuivre sa croissance et de s’étendre à de nouveaux types d’aliments, la société a l’intention d’acquérir d’autres fabricants d’aliments dans différents climats. Dans le cadre du processus d’acquisition, l’entreprise A a besoin d’une stratégie reproductible pour intégrer les systèmes d’entreprise acquis dans une expérience unique et unifiée.

L’intégration au sein de plusieurs organisations indépendantes pose de nombreux défis techniques. Les défis portaient principalement sur l’octroi d’un accès à des utilisateurs externes (utilisateurs de l’entreprise A) à des ressources privées (applications de l’entreprise B) autorisées par des fournisseurs d’identité distincts et indépendants.

La société a décidé d’utiliser Citrix Workspace comme pierre angulaire de sa stratégie de fusion et d’acquisition. Ils cherchent à utiliser la même stratégie pour acquérir l’entreprise C, l’entreprise D et l’entreprise E.

Critères de réussite

Dans le cadre de la stratégie d’acquisition, l’entreprise A a besoin d’une solution qui permet aux utilisateurs d’accéder rapidement et en toute sécurité aux ressources de l’entreprise A et de l’entreprise B. Pour réussir, l’entreprise a défini une liste de critères de réussite qui constitue la base de la conception globale.

Expérience utilisateur

Le premier aspect d’une solution de fusions-acquisitions est de répondre aux besoins de l’utilisateur. L’entreprise A a identifié les critères suivants liés à l’utilisateur pour une conception réussie.

Sécurité

Le deuxième aspect d’une solution de fusions et acquisitions est de répondre aux besoins de sécurité. L’entreprise A a identifié les critères de sécurité suivants pour une conception réussie.

Architecture conceptuelle

Sur la base de leurs exigences définies, l’entreprise A a créé l’architecture conceptuelle de haut niveau suivante pour sa stratégie d’acquisition. L’architecture conceptuelle répond non seulement à toutes les exigences, mais elle donne à l’entreprise les bases dont elle a besoin pour s’étendre à d’autres cas d’utilisation identifiés à l’avenir.

Le cadre d’architecture est divisé en plusieurs couches. Le cadre fournit une base pour comprendre l’architecture technique du scénario des fusions et acquisitions. Toutes les couches s’unissent pour créer une solution complète de bout en bout.

À un haut niveau :

Couche utilisateur : La couche utilisateur décrit l’environnement de l’utilisateur final et les périphériques de point de terminaison utilisés pour se connecter aux ressources.

• Quel que soit l’appareil, les utilisateurs accèdent aux ressources de l’application Workspace, ce qui permet d’obtenir une expérience identique sur tous les facteurs de forme et toutes les plateformes de périphériques.

Couche d’accès : la couche d’accès décrit en détail comment les utilisateurs s’authentifient auprès de leur espace de travail et de leurs ressources secondaires.

• Les utilisateurs continuent de s’authentifier avec leur identité principale avant l’acquisition.
• Les utilisateurs continuent d’utiliser leur solution d’authentification multifactorielle pré-acquisition. Si l’entreprise n’utilise pas actuellement l’authentification multifactorielle, l’entreprise A fournit des jetons TOTP basés sur téléphone qui prennent en charge l’authentification basée sur le push.

Couche de ressources : la couche de ressources autorise des ressources SaaS, Web et virtuelles spécifiques pour des utilisateurs et des groupes définis, ainsi que les stratégies de sécurité associées à la ressource.

• Quelle que soit la société d’origine d’un utilisateur, l’utilisateur doit avoir un accès transparent à toute ressource autorisée hébergée par d’autres sociétés.
• Pour mieux protéger les données, la société a besoin de stratégies qui désactivent la possibilité d’imprimer, de télécharger et de copier/coller du contenu de la ressource gérée vers et à partir du point de terminaison. La société a également besoin de restreindre le grattage d’écran \ capture des applications et les logiciels malveillants de journalisation de touches.
• En raison de la nature inconnue de l’état de sécurité des terminaux, la société a besoin d’un accès sans VPN aux ressources avec l’utilisation de navigateurs isolés ou de sessions virtualisées.

Couche de contrôle : la couche de contrôle définit la manière dont la solution sous-jacente s’adapte en fonction des activités sous-jacentes de l’utilisateur.

• Avec les stratégies en place pour protéger les utilisateurs et les données de l’entreprise, il y a encore des risques. L’entreprise A utilise le service Security Analytics pour identifier les utilisateurs compromis ou les menaces internes et prendre automatiquement des mesures pour maintenir un environnement sécurisé.
• La plate-forme qui unifie l’authentification multi-annuaire doit être protégée contre les menaces et les attaques externes. L’entreprise A permet au Web App Firewall et à la gestion des bots intégrés de protéger le point d’authentification dans l’environnement.

Couche d’hébergement : La couche d’hébergement détaille la façon dont les composants sont déployés sur le matériel, que ce soit sur site, dans le cloud ou dans un cloud hybride.

• Citrix Workspace doit pouvoir accéder au fournisseur d’identité de chaque société, qu’il s’agisse d’un domaine Active Directory local ou d’une offre basée sur le cloud à partir d’Okta, via un seul site Workspace.

Les sections suivantes fournissent plus de détails sur les décisions de conception spécifiques pour l’architecture de référence de la stratégie de fusion et d’acquisition de l’entreprise.

Couche d’accès

Authentification

L’un des défis rencontrés par l’entreprise lors des acquisitions précédentes était de savoir comment intégrer les fournisseurs d’identité. Le processus de fusion des fournisseurs d’identité peut prendre beaucoup de temps. Avec la nouvelle stratégie, l’entreprise A utilise un Citrix Application Delivery Controller pour traiter toutes les demandes d’authentification.

Le processus d’authentification fonctionne par l’Application Delivery Controller qui évalue la société de l’utilisateur, puis applique la demande d’authentification correcte. Comme l’entreprise A a standardisé sur Okta pour l’authentification primaire, la demande est transmise à Okta. Une fois que Okta a terminé l’authentification de l’utilisateur, Okta répond à Application Delivery Controller avec un jeton identifiant l’authentification réussie.

Mais toutes les entreprises acquises par l’entreprise n’utilisent pas Okta. Au lieu de cela, si Application Delivery Controller identifie que l’utilisateur ptovient de l’entreprise B, il est demandé à l’utilisateur de fournir son nom d’utilisateur et son mot de passe Active Directory. Ces informations d’identification sont validées par rapport au domaine Active Directory de l’entreprise B. Si CompanyB a déjà intégré une solution d’authentification multifactorielle, les utilisateurs continuent à utiliser leurs jetons enregistrés.

Étant donné que l’authentification forte est une première étape cruciale pour la sécurité, l’entreprise A souhaite disposer d’une solution prête pour les organisations qui n’utilisent pas actuellement l’authentification multifacteur. Dans ce cas, une fois que l’utilisateur s’est authentifié auprès du domaine Active Directory de sa société, Application Delivery Controller utilise le moteur de mot de passe unique basé sur le temps natif pour fournir une authentification multifacteur pour l’utilisateur. Une fois enregistré sur l’appareil de l’utilisateur, l’utilisateur peut entrer le code manuellement ou utiliser le service de notification push. Les notifications Push exigent simplement que l’utilisateur sélectionne « Oui » à partir de son appareil mobile enregistré pour effectuer l’authentification multifacteur.

Stratégie nFactor

Pour l’authentification principale, Citrix Application Delivery Controller joue un rôle critique. Pour prendre les décisions d’authentification, Application Delivery Controller utilise une stratégie NFactor.

Pour traiter correctement les demandes d’authentification, la stratégie nFactor doit savoir à quelle société l’utilisateur appartient. Une fois l’identificateur d’entreprise correct sélectionné, nFactor transmet la demande à la branche correcte de la stratégie d’authentification.

Une fois la stratégie nFactor définie, l’entreprise peut continuer à l’étendre pour y intégrer d’autres organisations qu’elle acquiert à l’avenir. La stratégie nFactor permet à Company de créer des flux supplémentaires en utilisant des normes d’authentification qui incluent LDAP, RADIUS, SAML, certificats clients, OAuth OpenID Connect, Kerberos et plus encore. Le moteur de stratégie nFactor offre à l’entreprise la flexibilité nécessaire pour continuer à intégrer d’autres acquisitions sans refonte.

Accès réseau zéro confiance

Pour fournir un accès aux ressources internes telles que les applications Web privées, les applications virtuelles et les bureaux virtuels, CompanyA prévoit d’utiliser le service Secure Private Access et Citrix DaaS. Ces deux services utilisent une solution d’accès réseau zéro confiance, qui est une alternative plus sécurisée aux VPN traditionnels.

Le service Secure Private Access et Citrix DaaS utilisent les connexions du canal de contrôle sortant établies par les connecteurs cloud et les appliances de connecteur. Ces connexions permettent à l’utilisateur d’accéder à distance aux ressources internes. Cependant, ces connexions sont

• Portée limitée de sorte que seule la ressource définie soit accessible
• Basé sur l’identité principale et sécurisée de l’utilisateur
• Seulement pour les protocoles spécifiques, qui interdisent la traversée réseau

Couche de ressources

Services d’authentification fédérée

Les utilisateurs s’authentifient auprès de Citrix Workspace avec une identité principale. L’identité principale est basée sur le fournisseur d’identité de leur entreprise. L’un des défis liés aux fusions et acquisitions est l’accès à des ressources secondaires fondées sur une identité secondaire. Par exemple, l’entreprise A permet à certains utilisateurs de l’entreprise B et de l’entreprise C d’accéder aux applications Windows virtuelles. Pour accéder à une application Windows virtuelle, l’utilisateur doit disposer d’un compte d’utilisateur (identité secondaire) dans le domaine contenant la ressource virtuelle. Le compte d’un utilisateur de l’entreprise B (identité principale) ne s’authentifiera pas auprès d’une ressource de l’entreprise A (identité secondaire). Pour traduire les informations d’identification entre une identité principale et secondaire et fournir une authentification unique aux applications Windows virtuelles, l’entreprise A utilise le service d’authentification fédérée dans Citrix Cloud.

Le dossier technique de Workspace Single Sign-On contient des informations supplémentaires relatives au service d’authentification fédérée.

Stratégies de sécurité des ressources

La société veut limiter le risque de perte de données due à une menace d’initié. Dans les différents types d’applications, l’entreprise A intègre de nombreuses restrictions pour empêcher les utilisateurs de copier, télécharger ou imprimer des données.

En tant que stratégie de base, la société a défini ce qui suit (avec la possibilité d’assouplir les stratégies selon les besoins en fonction de l’utilisateur et de l’application).

La fiche technique des stratégies de protection des applications contient des informations supplémentaires concernant les stratégies de prévention de l’enregistrement au clavier et des captures d’écran

Couche de contrôle

Web App Firewall

Lorsque les utilisateurs s’authentifient auprès de Citrix Workspace, ils accèdent à un formulaire d’authentification personnalisé prenant en charge la stratégie de fusions et d’acquisitions. Le formulaire d’authentification, hébergé sur Citrix Application Delivery Controller, est une page Web publique qui doit être protégée contre les robots et les attaques. Pour mieux protéger l’application Web publique, l’entreprise A utilise les composants Bot Management et Web App Firewall de la solution Citrix Application Delivery Controller.

La première ligne de défense est la gestion des bots. Les robots peuvent facilement planter ou ralentir une application Web publique en inondant le service de demandes frauduleuses. Le composant de gestion des robots de l’Application Delivery Controller est capable de détecter une requête de robot et de l’empêcher d’inondrer le système.

La deuxième ligne de défense est le Web App Firewall. Avec le Web App Firewall, le moteur de stratégie qui gère les informations d’identification soumises est protégé contre les attaques. Ces types d’attaques sont généralement le dépassement de tampon, l’injection SQL et le script intersite. Web App Firewall détecte et empêche ces attaques d’avoir un impact sur le moteur de politique d’authentification.

Analyses de sécurité

L’entreprise A doit identifier et arrêter les menaces internes qui pèsent sur l’environnement avant que l’impact ne soit trop important.

Pour protéger l’environnement, l’entreprise A utilise Citrix Security Analytics pour identifier les menaces initiées, les utilisateurs compromis et les terminaux compromis. Dans de nombreux cas, un seul cas de menace ne justifie pas une action drastique, mais une série de menaces peut indiquer une atteinte à la sécurité.

L’entreprise A a développé les stratégies de sécurité initiales suivantes :

Le document Indicateurs de risque utilisateur Citrix contient des informations supplémentaires concernant les différents indicateurs de risque fournis à Citrix Security Analytics.

La page Stratégies et actions Citrix contient des informations sur les étapes de résolution que Citrix Security Analytics peut effectuer.

Sources

Pour faciliter la planification d’une stratégie de fusion et d’acquisition, nous aimerions vous fournir des diagrammes sources que vous pouvez adapter.