Einführung

Inductive Automation ist stolz darauf, die Lizenzierung von gehosteten und mandantenfähigen Anwendungen (Multi Tenancy) ohne zusätzliche Kosten für den Lizenznehmer zu ermöglichen, wenn die Ignition Cloud Edition verwendet wirdx. Das Hosting ermöglicht eine flexible gemeinsame Nutzung von Ressourcen und „Pay as you go“-Dienstleistungsmodelle. Multi-Tenancy kann die breite Bereitstellung von kundenspezifischen Ignition-Anwendungen als Service ermöglichen. Dieser Wandel ermöglicht neue Rollen von Dienstanbietern, von denen die gesamte Ignition-Gemeinschaft profitieren kann. Diese Modelle sind jedoch mit Risiken für die Beteiligten verbunden.

Als universelles Software-Design-Tool ermöglicht Ignition eine Vielzahl von Anwendungen, die von Benutzern erstellt werden. Diese reichen von Werkzeugen für den Informationsaustausch mit geringem Risiko bis hin zu Systemen mit hohem Risiko, die eine Schnittstelle zu kritischen Infrastrukturen in regulierten Bereichen bilden. Ignition-Systeme teilen das Risiko in Bezug auf Sicherheit, Vertraulichkeit, Integrität und Verfügbarkeit der grösseren Prozessumgebung einschliesslich der angeschlossenen Systeme.

Konfiguration, Architektur und betriebliche Anforderungen sind je nach Anwendung sehr unterschiedlich. Ein pauschaler Ansatz für das Risikomanagement nach dem Motto „Einheitsgrösse für alle“ ist für Ignition-Anwendungen niemals angemessen. Die gemeinsame Nutzung von Ressourcen erhöht naturgemäss das Risiko in den Bereichen Sicherheit, Datenschutz und Leistung.

Zweck

Dieser Leitfaden soll die Beteiligten über die Eigenheiten und Risiken im Zusammenhang mit gehosteten oder mandantenfähigen Ignition-Anwendungen informieren. Dieser Leitfaden ist eine Ergänzung und kein Ersatz für projektspezifische Qualitätssicherung und Sicherheitspraktiken auf der Grundlage von Fachwissen.

Begriffserklärungen

Ignition-Anwendung. Eine benutzerdefinierte, auf Ignition basierende Laufzeitanwendung. Der Zugriff kann zum Nutzen Dritter freigegeben werden. Dies bezieht sich häufig auf ein Ignition Perspective-Projekt, das in einem modernen Webbrowser läuft.

Privilegierter Ignition-Zugriff (Privileged Access). Privilegierter Zugriff innerhalb eines Ignition-Systems umfasst „Application Design“ (Designer-Rolle) oder „Ignition Configuration“ (Gateway Config-Rolle). Der privilegierte Zugriff ist auf einen einzigen Endbenutzer und bestimmte vertrauenswürdige Parteien auf Basis der einzelnen Lizenzen beschränkt.

Endbenutzer (EU). Eine Organisation, die Ignition-Anwendungen verwendet. EUs sind oft die Lizenznehmer von Ignition. EUs können einen privilegierten Ignition-Zugang haben, müssen es aber nicht. Mehrere Organisationen, die in einer Geschäftsbeziehung stehen, können auf der Grundlage gemeinsamen Vertrauens als ein einziger EU gelten.

Single-Tenant. Ein Architekturmuster, bei dem jeder EU ein dediziertes Ignition Gateway zugewiesen wird. Das Design und die Konfiguration der Ignition-Anwendung ist auf diesen einen EU beschränkt, kann aber gemeinsam genutzt oder delegiert werden. Eine Single-Tenant-Architektur kann von dem EU verwaltet oder gehostet werden. Der EU ist häufig der Lizenznehmer.

Multi-Tenant. Ein Architekturmuster, bei dem die Nutzung der Ignition-Anwendung mehreren Endbenutzern auf einem Ignition-Gateway gewährt wird. Der privilegierte Zugriff ist jedoch auf einen einzigen Lizenznehmer und vertrauenswürdige Partner beschränkt. Der privilegierte Zugang zu Ignition für mehrere Mandanten ist eine schlechte Sicherheitspraxis und wird durch die Lizenzvereinbarung verboten.

Hosting. Ein Modell zur Bereitstellung von Ignition-Diensten oder Rechenressourcen für EUs. Hosting wird oft mit Cloud-Diensten, gemeinsam genutzten Ressourcen und einem Modell der gemeinsamen Verantwortung in Verbindung gebracht. Gehostete Modelle können für jedes Ignition-Gateway eine Single- oder Multi-Tenancy vorsehen.

Ignition-Dienstanbieter (Host). Ein Akteur, der eine auf Ignition basierende Infrastruktur zum Nutzen anderer Parteien verwaltet. Er stützt sich häufig auf Cloud-Service-Provider, muss dies aber nicht. Hosts können auch andere Dienste wie Anwendungsanpassung, Validierung, Dokumentation, Einhaltung von Vorschriften oder technische Fähigkeiten anbieten.

Ignition Management Modell. Das Modell beschreibt die Verwaltung von Ignition-Systemen. Die Referenzoptionen sind: vom Kunden verwaltet, gehostet und mandantenfähig gehostet.

Das vom Kunden verwaltete Modell ähnelt am ehesten einem lokalen oder „traditionellen“ IT-Modell, obwohl es auch Cloud Computing umfassen kann.

Beim gehosteten Modell verwaltet ein Host die auf Ignition basierende Infrastruktur zum Nutzen anderer Parteien.

Die Mandantenfähigkeit bietet die Möglichkeit, dass mehrere EUs auf gemeinsame Ignition-Anwendungen zugreifen, und schränkt den privilegierten Zugang von Natur aus ein.

Modell der geteilten Verantwortung. Die Beteiligten tragen die Verantwortung für verschiedene Aspekte in einer gehosteten oder mandantenfähigen Umgebung gemeinsam. Cloud-Service-Anbieter bieten dazu Referenzleitfäden.

 

 

Rollen und Verantwortlichkeiten

Enduser

Der Enduser (EU) ist dafür verantwortlich, zu bestimmen, was für seine Branche, seine Anwendung und seine Risikobereitschaft angemessen ist. Dazu gehört in der Regel die Due-Diligence-Prüfung, die das Unternehmen bei jedem SaaS/PaaS/IAAS-Angebot durchführen würde. Aufgrund des industriellen Charakters von Ignition umfasst dies häufig EU-Stakeholder aus den Bereichen Betriebstechnologie (OT) und Informationstechnologie (IT). Die typische Geschäftsbeziehung mit EUs und Inductive Automation (IA) ist die des EU als Lizenznehmer von Ignition, was einen Software-Supportvertrag beinhalten kann. IA empfiehlt die Konsultation von Fachexperten, wie z.B. qualifizierten Systemintegratoren mit entsprechendem Fachwissen. Siehe die Normenreihe ISA/IEC 62443-2-x unter der Rolle „Asset Owner“ für allgemein anerkannte Best Practices für EUs.

Systemintegrator

Systemintegratoren (SI) bieten den EUs oft Dienstleistungen in den Bereichen Entwurf, Implementierung und Support an, die oft über den Anwendungsbereich von Ignition hinausgehen. Dies ist eine optionale Rolle für Ignition-Anwendungen. Zwischen SIs und EUs können Geschäftsbeziehungen bestehen, die oft dazu führen, dass SIs einen privilegierten Zugang zu Ignition erhalten. Inductive Automation unterhält ein Integrator-Programm, welches Vergünstigungen und Software-Support für SIs beinhaltet und den Kontakt für EUs erleichtert. Inductive Automation ist nicht an Projekten oder Anwendungen beteiligt, die zwischen EUs und SIs stattfinden. Siehe die Normenreihe ISA/IEC 62443-3-x für Integrationsempfehlungen.

Inductive Automation

Die Rolle von Inductive Automation (IA) ist die Bereitstellung der Ignition-Software. Dazu gehören regelmässige Software-Updates, Dokumentation, Schulungen und technischer Support. Weitere Informationen über den Softwareentwicklungszyklus (SDLC) von IA, der nach den Normen ISASecure und IEC 62443-4-1 zertifiziert ist, finden Sie im Security and Trust portal. IA bietet keine Hosting-Dienste an und hat keinen Zugang zu Daten, Netzen oder Systemen der EU. A bietet Dokumentation, Softwareunterstützung und Schulungen an und fördert die Zusammenarbeit zwischen der Ignition-Gemeinschaft.

Ignition-Dienstanbieter

Ignition-Service-Provider (Hosts) bieten eine Vielzahl von Ignition-bezogenen Leistungen an, von der Infrastruktur bis zu Anwendungsdiensten. Sie können Systeme extern zertifizieren und damit verbundene Dienste wie Dokumentation, Validierung, technische Fähigkeiten und automatische Konfiguration anbieten. Die Hosts nutzen oft separate Dienstleister wie Cloud Service Provider (CSP) für die Infrastruktur, Anbieter von Cybersicherheitsdiensten oder auch Drittanbieterfunktionen wie Sprachbenachrichtigung, Identity Providers oder Datenarchivierung. Es liegt in der Verantwortung des Hosts, ihre Anforderungen auf Grundlage ihres Angebots zu bestimmen und sicherzustellen, dass ihre Kunden sich innerhalb akzeptabler Grenzen bewegen. Diese Beziehung besteht zwischen der EU und dem Host. Inductive Automation ist nicht an den auf Ignition basierenden Diensten beteiligt.

Stakeholder-Rollendiagramme

Diese Diagramme bieten einen konzeptionellen Rahmen für Anwendungen des Ignition-Modells der geteilten Verantwortung. Die Stakeholder-Modelle sind konzeptionell in die Kategorien „vom Kunden verwaltet“, „gehostet“ und „mandantenfähig gehostet“ unterteilt. Andere Arrangements sind möglich, wobei die Details zwischen den Beteiligten vereinbart werden. Fiktive Rollen sind farblich kodiert. Schwarzer Text kennzeichnet Rollen und Verantwortlichkeiten. Blauer Text kennzeichnet eine optionale Rolle, die oft eine Designentscheidung hervorhebt. Roter Text weist auf eine Funktion hin, die nicht zulässig ist.

Modell der geteilten Verantwortung

Abbildung 1 zeigt mögliche Rollen und Verantwortlichkeiten zwischen den Beteiligten von gehosteten oder mandantenfähigen Ignition-basierten Systemen im Kontext traditioneller SaaS/PaaS/IaaS (XaaS)-Modelle. Die Rolle von Inductive Automation besteht darin, Ignition-Software für die Nutzung durch den Kunden bereitzustellen. Inductive Automation bietet keine XaaS-Dienste an und hat keinen Zugriff auf Kundendaten, Netzwerke oder Systeme.

Modell der geteilten Verantwortung – Beispiel-Rollen

Abbildung 2 soll fiktive Rollen und Verantwortlichkeiten im Zusammenhang mit Stakeholder-Modellen vermitteln. Fett gedruckter Text kennzeichnet Schlüsselrollen. Blauer Text hebt Verantwortlichkeiten mit Benennungsoptionen hervor. Der Begriff „Eigentümer der Infrastruktur“ bezieht sich auf die aufgelisteten Zuständigkeiten, nicht unbedingt auf das physische Eigentum.

Ignition Management Modell Ressourcenansicht

Die Abbildungen 3 und 4 sollen die Verwendung von gemeinsam genutzten bzw. dedizierten Ressourcen verdeutlichen. Aus der Sicht von Ignition stellt die Beibehaltung eines dedizierten Gateways pro EU (Abbildung 3) eine Einzelmiete (Single-Tenant) dar, selbst wenn es gehostet wird. Abbildung 4 zeigt mehrere EUs, die auf gemeinsame Ignition-Anwendungen über dasselbe Gateway zugreifen, was eine Mehrfachnutzung von Ignition-Anwendungen darstellt. Die gemeinsame Nutzung von Ressourcen durch die EUs birgt ein höheres Risiko als die Zuweisung von Ressourcen für jede EU. Ignition-Architekturen in Abbildung 3 sind tendenziell risikoärmer als Ignition-Architekturen in Abbildung 4.

Risikofaktoren

Gehostete und mandantenfähige Anwendungen bringen von Natur aus zusätzliche Risikofaktoren mit sich. Es ist wichtig, die Risikofaktoren bei der Planung einer gehosteten oder mandantenfähigen Anwendung zu verwalten und klar zu kommunizieren.

Anwendungsanpassung und -vielfalt auf einem gemeinsamen Gateway

Die zunehmende Anpassung von Ignition-Anwendungen erhöht das Gesamtrisiko für alle Benutzer eines gemeinsam genutzten Gateways mit mandantenfähigen Anwendungen. Endbenutzer, die zu ähnlichen Zwecken auf dieselbe Anwendung zugreifen, haben in der Regel ein gleiches Risikoprofile. Das Hosten verschiedener Arten von Anwendungen auf demselben Ignition-Gateway erhöht das Risiko für EUs mit mehreren Mandanten. Eine ordnungsgemässe Trennung der Gateways nach EU, Anwendungstyp oder Risikoprofil verringert das Gesamtrisiko.

Unterscheidung der Risikotoleranz

Die Beteiligten können aufgrund der Praktiken anderer Beteiligter einem unerwünschten Risiko ausgesetzt sein. Dies kann allein auf unterschiedliche Anforderungen zurückzuführen sein und wird durch schlechte Praktiken noch verschärft.

Bei Modellen der geteilten Verantwortung sind klare Erwartungen und Regeln zwischen den Beteiligten erforderlich. Betrachten wir ein fiktives Beispiel mit Systemen mit „geringer“, „mittlerer“ und „hoher“ Auswirkung:

• Host bietet ein in der Ignition Cloud Edition gehostetes System, das für „mittlere Auswirkungen“ angemessen gesichert ist.
• EU1 verbindet ein sensibles, gut gesichertes System mit „hoher Auswirkung“ mit dem Host
• Das System von EU2 hat „geringe Auswirkungen“. EU2 hat das Risiko akzeptiert, welches mit ihren mangelnden Sicherheitskontrollen und schwachen Praktiken wie unkontrollierter Verbindungen zu Drittanbietern verbunden ist. Seine Risikoprofile sind darauf ausgerichtet.
• Es liegt auf der Hand, dass die Verbindung von EU2 zum Host ein Problem für EU1 darstellt. Aus der Sicht von EU1 sind unbekannte Drittanbieterverbindungen indirekt mit ihrem System verbunden, und der Hosting-Dienst schützt gemeinsame Verbindungspunkte nur unzureichend.

Die Trennung von Ignition-basierten Umgebungen nach Auswirkungen, Anforderungen, Risikobereitschaft oder Anwendungstyp kann helfen, das Gesamtrisiko zu steuern. Eine klare Kommunikation der beabsichtigten Nutzung und der Erwartungen ist wichtig für ein gemeinsames Verständnis bei allen Beteiligten.

Privilegierter Zugriff

Der privilegierte Zugriff auf Ignition wird als Ignition Designer- oder Gateway-Konfigurationsrolle bezeichnet. Jeder privilegierte Ignition-Zugriff gewährt von vornherein volle Fähigkeiten für das gesamte Ignition Gateway.

Die Ignition-Lizenzierung erlaubt keinen privilegierten Zugriff von mehreren EUs auf dasselbe Ignition-Gateway. Der privilegierte Ignition-Zugriff sollte im vornherein als eine einzige Sicherheitsrolle betrachtet werden, die auf der Ebene des jeweiligen Gateways verwaltet wird. Privilegierter Zugriff kann einer vertrauenswürdigen Partei von einer EU wie einem Systemintegrator, Partner oder Host gewährt werden. Achten Sie besonders auf EUs, die möglicherweise Wettbewerber auf demselben Gateway sind. Privilegierter Zugriff auf niedrigerer Ebene, wie z. B. Berechtigungen auf Root-Ebene des Betriebssystems, sollte mit dem gleichen Verständnis angegangen werden.

Datenverwaltung

Datenvertraulichkeit, -integrität und -verfügbarkeit sind für die Endnutzer oft wichtige Aspekte. Berücksichtigen Sie die Klassifizierung der Daten. Überlegen Sie, wie die Daten gespeichert und verwaltet werden. Die Vermischung von EU-Daten in gemeinsamen Datenbanken oder Diensten stellt ein zusätzliches Risiko für die Beteiligten dar. Berücksichtigen Sie den gesamten Lebenszyklus der Daten, einschliesslich Planung, Backups, Zugriff, Verwaltung und Löschung.

Netzwerkverbindungen am Standort des Endbenutzers

Remote-Verbindungen und Netzwerkverbindungen von Drittanbietern zu Endbenutzern (oder dem Host) stellen eine Risikoquelle für alle verbundenen Parteien dar. Dazu gehören permanente, temporäre und vom Benutzer initiierte Verbindungen. Nicht vertrauenswürdige Verbindungen sind besonders problematisch, wenn die Risikoebenen oder die Informationskategorisierung zwischen den verbundenen Parteien stark variieren. Betrachten Sie die Verbindungen aus der Perspektive der einzelnen Beteiligten. Es ist üblich, dass der Host seine Erwartungen formuliert und gegenüber jeder EU den Nachweis der Vertrauenswürdigkeit erbringt. Dies geschieht häufig in Form von Dokumentation, Zertifizierungen durch Dritte, Fragebögen und Audits.

OT-Netzwerkarchitektur Netzwerksegmentierung

Die Ignition Cloud Edition ist nicht für den direkten Anschluss an Geräte oder cyber-physische Systeme vorgesehen. Aus diesem Grund enthält sie keine Gerätetreiber. Berücksichtigen Sie segmentierte Architekturen und eine angemessene Segmentierung, wenn Sie eine Verbindung zu Geräten, Diensten und Datenbanken herstellen. Mehrere Segmentierungsebenen sind vom Edge bis zur Cloud üblich. Branchenweit anerkannte Standards und Frameworks wie ISA/IEC 62443 bieten Best Practices für die Netzwerksegmentierung. Erwägen Sie, nur die Netzwerksegmente zu verbinden, die benötigt werden.

Netzwerksegmentierung für den Benutzerzugriff

Der breite Zugriff auf Ignition-Anwendungen durch Benutzer, insbesondere der privilegierte Zugriff und die Internet-Verbindung, schafft eine Angriffsfläche. Der Schutz oder die Minimierung dieser Angriffsfläche, z. B. durch einen sicheren Fernzugriff oder private Netze, kann zur Risikominderung beitragen. Cloud-Anbieter halten sich an branchenübliche Best Practices wie „gut konzipierte Frameworks“. Der Benutzerzugang sollte geschützt und von anderen Segmenten des Ignition-Netzes getrennt werden, wie z. B. Datenbanken, OT-Geräte und Unternehmens- oder Webdienste. EUs sollten in einem Multi-Tenant-Konstrukt voneinander getrennt werden.

 

 

Anhang A – Erste Schritte

Zusätzliche Überlegungen

Bei der Verwendung von Ignition als gehostetes oder mandantenfähiges System sind besondere Überlegungen erforderlich. Es liegt letztendlich in der Verantwortung des Endbenutzers und des Hosts, die Anforderungen für ihren Anwendungsfall zu bestimmen.

Es ist am besten, alle Beteiligten frühzeitig einzubeziehen und mit dem Ignition Security Hardening Guide zu beginnen. Cloud- und Multi-Tenant-Projekte erfordern oft zusätzliche Fähigkeiten und bergen Risiken. Hier sind einige zusätzliche Themen, die bei der Planung eines gehosteten oder mandantenfähigen Projekts berücksichtigt werden sollten.

Planung

• Welche Dienstleistungen sollen erbracht werden?
• Welches ist die vorgesehene Umgebung und Nutzung?
• Werden Service Level Agreements benötigt?
• Werden getrennte Umgebungen verwendet (z. B. Entwicklung, Test, Produktion)?
  • Siehe Best Practices für die Bereitstellung von Ignition 8
• Wie werden Anwendungsänderungen durchgeführt? Gibt es einen Workflow?
• Umfasst der Plan die Aktualisierung/Patching von Ignition-Servern?
• Umfasst der Plan auch Tests?
• Deckt der Plan die Datenaufbewahrung ab?
• Deckt der Plan Backups, Disaster Recovery und Business Continuity ab?
• Deckt der Plan die Stilllegung von Projekten ab?
• Wie funktioniert der Benutzerlebenszyklus, einschliesslich Vereinbarung, Abrechnung, Verbindung, Nutzung, Modifizierung, Skalierung und Stilllegung?
• Ist eine Multi-Faktor-Authentifizierung erforderlich?
• Was sind die EU-Audit-Anforderungen?
• Kann die vorgeschlagene Architektur von der vorhandenen IT oder OT unterstützt werden?
• Werden Sicherheitsdienstleister, Notfallhelfer oder andere Beteiligte benötigt?

Überwachung

• Erstellen Sie einen Plan für die Überwachung Ihrer Cloud-Umgebung
• Ist eine Sicherheitsüberwachung vorgesehen?
• Ist die Leistungsüberwachung abgedeckt?
• Wird dies von einem Cloud-Anbieter oder einem anderen Dienstleister übernommen? Was sind die internen Verantwortlichkeiten?

Architektur

Erstellen Sie einen Plan für die Übertragung von Daten in die Cloud

Wenn Sie Daten in die Cloud senden, sollten Sie Sicherheitsoptionen auf allen möglichen Ebenen berücksichtigen. Viele industrielle Kommunikationsprotokolle entsprechen nicht den grundlegenden modernen Sicherheitsstandards. Häufig sind externe Sicherheitskontrollen erforderlich. Es ist eine allgemein akzeptierte Best Practice, OT-Geräte mit einem lokalen Gateway zu verbinden, das eine sichere Verbindung unterstützt. Von dort aus können die Daten über eine Vielzahl von Methoden übertragen werden, die eine starke Verschlüsselung unterstützen: Ignitions Gateway-Netzwerk, OPC-UA, MQTT, REST-API-Endpunkte). Beachten Sie, dass einige Kunden Präferenzen (oder gesetzliche Anforderungen) haben, die geografische Gebiete oder bestimmte Netzwerke vorschreiben. Die allgemein anerkannte beste Praxis ist, die zugrunde liegende Netzwerktransportschicht unterhalb der Anwendungskommunikationsschicht zu sichern, wenn dies praktikabel ist.

Aufbau einer skalierbaren Architektur in der Cloud

Stellen Sie bei der Entwicklung einer Cloud Ignition-Architektur die folgenden Fragen:

• Wann planen Sie die Trennung von Frontend und Backend?
• Wann planen Sie, neue E/A-Server hinzuzufügen?
• Wann planen Sie neue Frontend-Server hinzuzufügen?
• Wie sieht Ihr Plan für Hochverfügbarkeit oder Redundanz aus?
• Haben Sie spezielle SLAs mit Ihren Kunden?

Kundenisolierung

Wenn mehrere Kunden ein einziges Gateway nutzen, ist es wichtig, die Projekte, Geräte und Daten der einzelnen Endbenutzer (EU) zu isolieren. Obwohl eine rollenbasierte Zugriffskontrolle (RBAC) möglich ist, ist oft eine vollständigere Segmentierung erforderlich.

• Erstellen Sie einen Plan für den Lebenszyklus von Kundendaten und Serviceinstanzen, einschliesslich: Erstellung, Änderung, Wartung und Löschung. Bevorzugen Sie die Automatisierung.

Fragen zur allgemeinen Segmentierung

• Wie werden die Daten segmentiert?
• Wie werden Tags segmentiert?
• Wie werden die Kunden voneinander isoliert?
• Verfügt jeder Kunde bei Verbindungen über MQTT/Sparkplug über eine Zugriffskontrollliste (ACL), die die Veröffentlichung von Daten und den Zugriff auf Abonnements enthält?
• Werden separate Identitätsanbieter (IdP) für die Authentifizierung und Autorisierung benötigt?
  • Die Identität kann zentral verwaltet oder für die EU-Verwaltung mit einem separaten IdP pro EU delegiert werden.
• Welche Kundenprojekte müssen getrennt werden?
• Welche Netzwerksegmentierung ist erforderlich?
  • Berücksichtigung von IEC 62443 „Zones und Conduits“, „Perdue-Model“ und Cloud-„Well-Architected-Frameworks“
• Welche externen Sicherheitskontrollen oder -dienste werden benötigt?
• Welche gemeinsamen Dienste werden benötigt? Sind separate Berechtigungsnachweise erforderlich?

Ideen zur Trennung von Kundenprojekten:

• Wenn Kundenprojekte vor anderen Endbenutzern verborgen werden sollen, können sie auf der Startseite ausgeblendet werden, indem in den Projekteigenschaften die Option „Auf der Startseite und in nativen Apps ausblenden“ ausgewählt wird. Den Endbenutzern müssen Links zu den Projekten zur Verfügung gestellt werden (Single Domain / direkte Projektlinks, Subdomains, separate Domains usw.)
• Getrennter Zugriff ausserhalb von Ignition mit externen Technologien wie Load Balancern
• Getrennte Tag-Provider
• Getrennte Alarmjournal-Profile
• Getrennte Audit-Logs
• Getrennte Benutzerquellen
• Getrennte Kundendaten auf Benutzerbasis (z.B. Datenbanken, Schemata, Tabellen). Minimieren Sie die Vermischung von Daten.

Quellenangabe: https://inductiveautomation.com/resources/article/hostedmultitenant-ignition-cloud-edition-guidance