Referenzarchitektur: Fusionen und Akquisitionen

Übersicht

CompanyA ist ein Lebensmittelhersteller in den nördlichen Ebenen der Vereinigten Staaten. Um weiter zu wachsen und zu neuen Arten von Lebensmitteln zu expandieren, plant CompanyA , zusätzliche Lebensmittelhersteller in verschiedenen Klimazonen zu akquirieren. Im Rahmen des Akquisitionsprozesses benötigt CompanyA eine wiederholbare Strategie, um erworbene Unternehmenssysteme in eine einzige, einheitliche Erfahrung zu integrieren.

Die Integration in mehrere unabhängige Organisationen bringt viele technische Herausforderungen mit sich. Die Herausforderungen konzentrierten sich hauptsächlich darauf, externen Benutzern (CompanyA-Benutzern) den Zugriff auf private Ressourcen (CompanyB-Anwendungen) zu gewähren, die von separaten, unabhängigen Identitätsanbietern autorisiert wurden.

CompanyA entschied sich, Citrix Workspace als Eckpfeiler für ihre Fusions- und Übernahmestrategie zu nutzen. Sie wollen dieselbe Strategie für den Erwerb von CompanyC, CompanyD und CompanyE verwenden.

Erfolgskriterien

Als Teil der Akquisitionsstrategie benötigt CompanyA eine Lösung, die Benutzern schnell und sicher den Zugriff auf CompanyA- und CompanyB-Ressourcen ermöglicht. Um erfolgreich zu sein, hat CompanyA eine Liste von Erfolgskriterien definiert, die die Grundlage für das übergeordnete Design bilden.

Benutzererfahrung

Der erste Aspekt einer Lösung für Fusionen und Übernahmen besteht darin, die Bedürfnisse der Benutzer zu erfüllen. CompanyA identifizierte die folgenden benutzerbezogenen Kriterien für ein erfolgreiches Design.

Sicherheit

Der zweite Aspekt einer Lösung für Fusionen und Übernahmen besteht darin, die Sicherheitsanforderungen zu erfüllen. CompanyA identifizierte die folgenden sicherheitsrelevanten Kriterien für ein erfolgreiches Design.

Konzeptarchitektur

Basierend auf ihren definierten Anforderungen schuf CompanyA die folgende hochrangige, konzeptionelle Architektur für ihre Akquisitionsstrategie. Die konzeptionelle Architektur erfüllt nicht nur alle Anforderungen, sondern gibt CompanyA die Grundlage, die sie benötigen, um auf zusätzliche Anwendungsfälle zu erweitern, wie in der Zukunft identifiziert.

Das Architektur-Framework ist in mehrere Layer unterteilt. Der Rahmen bietet eine Grundlage für das Verständnis der technischen Architektur für das Szenario der Fusionen und Übernahmen. Alle Ebenen fließen zusammen, um eine vollständige End-to-End-Lösung zu schaffen.

Im Überblick:

Benutzerebene: Die Benutzerebene beschreibt die Endbenutzerumgebung und Endgeräte, die zur Verbindung mit Ressourcen verwendet werden.

• Unabhängig vom Gerät greifen Benutzer auf Ressourcen von der Workspace-App zu, was zu einer Erfahrung führt, die für jeden Formfaktor und jede Geräteplattform identisch ist.

Zugriffsebene: Die Zugriffsebene beschreibt Details dazu, wie sich Benutzer bei ihrem Workspace und sekundären Ressourcen authentifizieren.

• Benutzer authentifizieren sich weiterhin mit ihrer primären Identität vor dem Erwerb.
• Benutzer verwenden weiterhin ihre Mehrfachfaktor-Authentifizierungslösung vor der Akquisition. Wenn das Unternehmen derzeit keine Multifaktor-Authentifizierung verwendet, bietet CompanyA telefonbasierte TOTP-Token an, die Push-basierte Authentifizierung unterstützen.

Ressourcenebene: Die Ressourcenebene autorisiert bestimmte SaaS, Web- und virtuelle Ressourcen für definierte Benutzer und Gruppen und die mit der Ressource verbundenen Sicherheitsrichtlinien.

• Unabhängig vom Ursprungsunternehmen eines Benutzers muss dem Benutzer der nahtlose Zugriff auf alle autorisierten Ressourcen gewährt werden, die von anderen Unternehmen gehostet werden.
• Um Daten besser schützen zu können, benötigt CompanyA Richtlinien, die das Drucken, Herunterladen und Kopieren/Einfügen von Inhalten von der verwalteten Ressource zum und vom Endpunkt deaktivieren. CompanyA erfordert auch die Einschränkung von Screen-Scraping, Anwendungen und Keylogging-Malware.
• Aufgrund der Unbekannten des Sicherheitsstatus des Endpunkt-Sicherheitsstatus benötigt CompanyA VPN-losen Zugriff auf Ressourcen unter Verwendung isolierter Browser oder virtualisierter Sitzungen.

Steuerungsebene: Die Steuerungsebene definiert, wie sich die zugrunde liegende Lösung basierend auf den zugrunde liegenden Aktivitäten des Benutzers anpasst.

• Mit den Richtlinien zum Schutz der Benutzer und Unternehmensdaten bestehen nach wie vor Risiken. CompanyA verwendet den Security Analytics-Dienst, um gefährdete Benutzer oder Insiderbedrohungen zu identifizieren und automatisch Maßnahmen zur Aufrechterhaltung einer sicheren Umgebung zu ergreifen.
• Die Plattform zur Vereinheitlichung der Multi-Directory-Authentifizierung muss vor externen Bedrohungen und Angriffen geschützt sein. CompanyA ermöglicht es der integrierten Web App Firewall und Bot Management, den Authentifizierungspunkt in der Umgebung zu schützen.

Hosting-Ebene: Die Hosting-Ebene beschreibt, wie Komponenten auf Hardware bereitgestellt werden, unabhängig davon, ob es sich um eine on-premises, eine Cloud oder eine Hybrid Cloud handelt.

• Citrix Workspace muss in der Lage sein, über eine einzige Workspace-Site auf den Identitätsanbieter jedes Unternehmens zuzugreifen, unabhängig davon, ob es sich um eine on-premises Active Directory-Domäne oder ein Cloud-basiertes Angebot von Okta handelt.

Die folgenden Abschnitte enthalten detailliertere Details zu spezifischen Designentscheidungen für die Referenzarchitektur der Fusionen und Übernahmen von CompanyA .

Zugriffsebene

Authentifizierung

Eine der Herausforderungen, die CompanyA bei früheren Akquisitionen erlebt hat, war die Integration von Identitätsanbietern. Das Zusammenführen von Identitätsanbietern kann viel Zeit in Anspruch nehmen. Mit der neuen Strategie verwendet CompanyA einen Citrix Application Delivery Controller, um alle Authentifizierungsanfragen zu bearbeiten.

Der Authentifizierungsprozess arbeitet, indem der Application Delivery Controller das Unternehmen des Benutzers bewertet und dann die richtige Authentifizierungsanforderung anwendet. Da CompanyA auf Okta für die primäre Authentifizierung standardisiert hat, wird die Anfrage an Okta weitergeleitet. Sobald Okta die Benutzerauthentifizierung abgeschlossen hat, antwortet Okta dem Application Delivery Controller mit einem Token, das die erfolgreiche Authentifizierung identifiziert.

Aber nicht jedes Unternehmen, das CompanyA erwirbt, nutzt Okta. Wenn der Application Delivery Controller identifiziert, dass der Benutzer von CompanyB stammt, wird der Benutzer stattdessen nach seinem Active Directory-Benutzernamen und Kennwort gefragt. Diese Anmeldedaten werden gegen die Active Directory-Domäne von CompanyB validiert. Wenn CompanyB bereits eine Multifaktor-Authentifizierungslösung integriert hat, verwenden Benutzer weiterhin ihre registrierten Token.

Da eine starke Authentifizierung ein wichtiger erster Schritt zur Sicherheit ist, möchte CompanyA eine Lösung für Unternehmen haben, die derzeit keine Multifaktor-Authentifizierung verwenden. In diesem Fall verwendet der Application Delivery Controller die native zeitbasierte Einmalkennwort-Engine, nachdem sich der Benutzer bei der Active Directory-Domäne seines Unternehmens authentifiziert hat, um dem Benutzer eine multifaktorische Authentifizierung bereitzustellen. Nach der Registrierung auf dem Gerät des Benutzers kann der Benutzer den Code entweder manuell eingeben oder den Push-Benachrichtigungsdienst verwenden. Bei Push-Benachrichtigungen muss der Benutzer lediglich “Ja” von seinem registrierten Mobilgerät auswählen, um die Multifaktor-Authentifizierung zu erfüllen.

nFactor-Richtlinie

Für die primäre Authentifizierung spielt der Citrix Application Delivery Controller eine entscheidende Rolle. Um die Authentifizierungsentscheidungen zu treffen, verwendet der Application Delivery Controller eine nFactor-Richtlinie.

Um Authentifizierungsanfragen ordnungsgemäß zu verarbeiten, muss die nFactor-Richtlinie wissen, zu welchem Unternehmen der Benutzer gehört. Sobald die richtige Unternehmenskennung ausgewählt ist, leitet nFactor die Anfrage an den richtigen Zweig der Authentifizierungsrichtlinie weiter.

Sobald die nFactor-Richtlinie definiert ist, kann CompanyA sie weiter ausbauen, um weitere Organisationen zu integrieren, die sie in Zukunft erwirbt. Die nFactor-Richtlinie ermöglicht es CompanyA, zusätzliche Flows unter Verwendung von Authentifizierungsstandards zu erstellen, die LDAP, RADIUS, SAML, Client-Zertifikate, OAuth OpenID Connect, Kerberos und mehr umfassen. Die nFactor Policy Engine bietet CompanyA die Flexibilität, zusätzliche Akquisitionen ohne Neugestaltung weiter zu integrieren.

Zero Trust Netzwerkzugriff

Um Zugriff auf interne Ressourcen wie private Web-Apps, virtuelle Apps und virtuelle Desktops zu ermöglichen, plant CompanyA die Verwendung des Secure Private Access-Dienstes und Citrix DaaS. Diese beiden Dienste verwenden eine Null-Vertrauens-Netzwerkzugriffslösung, die eine sicherere Alternative zu herkömmlichen VPNs darstellt.

Der Secure Private Access-Dienst und Citrix DaaS verwenden die ausgehenden Kontrollkanalverbindungen, die von den Cloud Connectors und Connector-Appliances eingerichtet wurden. Diese Verbindungen ermöglichen es dem Benutzer, remote auf interne Ressourcen zuzugreifen. Diese Verbindungen sind jedoch

• Eingeschränkt, so dass nur die definierte Ressource zugänglich ist
• Basierend auf der primären, gesicherten Identität des Benutzers
• Nur für bestimmte Protokolle, die Netzwerk-Traversal verbieten

Ressourcenebene

Föderierte Authentifizierungsdienste

Benutzer authentifizieren sich bei Citrix Workspace mit einer primären Identität. Die primäre Identität basiert auf dem Identitätsanbieter ihres Unternehmens. Eine der Herausforderungen bei Fusionen und Übernahmen ist der Zugang zu sekundären Ressourcen, die auf einer sekundären Identität basieren. Zum Beispiel ermöglicht CompanyA bestimmten Benutzern von CompanyB und CompanyC den Zugriff auf virtuelle Windows-Anwendungen. Um auf eine virtuelle Windows-Anwendung zugreifen zu können, muss der Benutzer über ein Benutzerkonto (sekundäre Identität) in der Domäne verfügen, die die virtuelle Ressource enthält. Das Konto eines CompanyB-Benutzers (primäre Identität) wird sich nicht bei einer CompanyA-Ressource (sekundäre Identität) authentifizieren. Um Anmeldeinformationen zwischen einer primären und sekundären Identität zu übersetzen und Single Sign-On für virtuelle Windows-Anwendungen bereitzustellen, verwendet CompanyA den Federated Authentication Service in Citrix Cloud.

Der Workspace Single Sign-On Tech Brief enthält zusätzliche Informationen zum Verbundauthentifizierungsdienst.

Richtlinien zur Ressourcensicherheit

CompanyA möchte das Risiko eines Datenverlusts aufgrund einer Insider-Bedrohung begrenzen. Innerhalb der verschiedenen Anwendungstypen beinhaltet CompanyA zahlreiche Einschränkungen, um zu verhindern, dass Benutzer Daten kopieren, herunterladen oder drucken.

Als Basisrichtlinie definierte CompanyA Folgendes (mit der Möglichkeit, Richtlinien je nach Benutzer und Anwendung nach Bedarf zu lockern).

Der Tech Brief zu den Richtlinien zum Schutz von Apps enthält zusätzliche Informationen zu den Richtlinien zur Keylogging- und Screenshot-Verhinderung.

Steuerungsebene

Web App Firewall

Wenn sich Benutzer bei Citrix Workspace authentifizieren, greifen sie auf ein benutzerdefiniertes Authentifizierungsformular zu, das die Strategie für Fusionen und Übernahmen unterstützt. Das auf dem Citrix Application Delivery Controller gehostete Authentifizierungsformular ist eine öffentliche Webseite, die vor Bots und Angriffen geschützt werden muss. Um die öffentliche Web-App besser zu schützen, verwendet CompanyA die Komponenten Bot Management und Web App Firewall der Citrix Application Delivery Controller-Lösung.

Die erste Verteidigungslinie ist Bot Management. Bots können eine öffentliche Web-App leicht abstürzen oder verlangsamen, indem sie den Dienst mit betrügerischen Anfragen überfordern. Die Bot-Management-Komponente des Application Delivery Controller ist in der Lage, eine Bot-Anfrage zu erkennen und zu verhindern, dass sie das System überfordert.

Die zweite Verteidigungslinie ist die Web App Firewall. Mit der Web App Firewall ist die Richtlinien-Engine, die die übermittelten Anmeldeinformationen verarbeitet, vor Angriffen geschützt. Diese Arten von Angriffen sind in der Regel Pufferüberlauf, SQL-Injection und Cross-Site Scripting. Die Web App Firewall erkennt und verweigert, dass sich diese Angriffe auf die Authentifizierungsrichtlinien-Engine auswirken.

Sicherheitsanalysen

CompanyA muss Insider-Bedrohungen für die Umwelt identifizieren und stoppen, bevor die Auswirkungen zu groß sind.

Um die Umwelt zu schützen, verwendet CompanyA Citrix Security Analytics, um Insiderbedrohungen, kompromittierte Benutzer und gefährdete Endpunkte zu identifizieren. In vielen Fällen rechtfertigt ein einzelner Fall einer Bedrohung keine drastischen Maßnahmen, aber eine Reihe von Bedrohungen kann auf eine Sicherheitsverletzung hinweisen.

CompanyA entwickelte die folgenden anfänglichen Sicherheitsrichtlinien:

Das Dokument Citrix Benutzerrisikoindikatoren enthält zusätzliche Informationen zu den verschiedenen Risikoindikatoren, die für Citrix Security Analytics bereitgestellt werden.

Die Seite Richtlinien und Aktionen von Citrix enthält Informationen zu den Standardisierungsschritten, die Citrix Security Analytics ausführen kann.

Quellen

Um Ihnen die Planung einer Fusions- und Übernahmestrategie zu erleichtern, möchten wir Ihnen Quelldiagramme zur Verfügung stellen, die Sie anpassen können.