DE102015112026A1

DE102015112026A1 - Auf geringste Rechte basierende Sicherheitsarchitektur für Fertigungssteuerungssoftware

Info

Publication number: DE102015112026A1
Application number: DE102015112026.7A
Authority: DE
Inventors: Lee Allen Neitzel; Dan Halver Ussing
Original assignee: Fisher Rosemount Systems Inc
Current assignee: Fisher Rosemount Systems Inc
Priority date: 2014-07-25
Filing date: 2015-07-23
Publication date: 2016-01-28
Also published as: JP2016031762A; CN105302092B; JP2023162405A; CN110109427A; GB201512424D0; GB2596194A; GB2596193A; GB202203760D0; JP2019215901A; GB2596190B; JP2021128785A; GB202105490D0; GB202105492D0; CN114237188A; JP6669448B2; CN114217589A; US20220198047A1; GB202105489D0; CN114185319A; GB2596192B

Abstract

Eine Sicherheitsarchitektur für Fertigungssteuerungssoftware, die Attacken der Zero-Day-Malware oder anderer Arten von Malware effektiver verhindert, implementiert bei der Ausführung der Applikationen und Dienste in einem Computergerät die Anwendung von „geringsten Rechten“. Die auf geringste Rechte basierende Architektur trennt „Dienst“-P rozesse von Desktopapplikationen, die im Auftrag von einem angemeldeten Benutzer ausgeführt werden, durch Partitionieren des allgemeinen Namensraums des Softwaresystems in Dienstnamensräume und Namensräume des angemeldeten Benutzers, indem Kommunikationen zwischen den Applikationen und Diensten in diesen unterschiedlichen Namensräumen mittels Interprozesskommunikationen genau gesteuert werden. Außerdem benutzt die Sicherheitsarchitektur benutzerdefinierte Konten, um sicherzustellen, dass jeder Dienstprozess die geringste Menge von Rechten aufweist, die für die Implementierung seiner Funktionen ungeachtet der Rechte, die mit der aufrufenden Applikation oder mit dem Benutzer assoziiert werden, benötigt werden.

Description

GEBIET DER TECHNIK
Diese Anmeldung betrifft allgemein Computersysteme in Fertigungsbetrieben und insbesondere ein Verfahren und eine Vorrichtung zur Sicherung des Betriebs von Softwareprozessen innerhalb Geräten, wie etwa Computer in einer Fertigungs- oder Fertigungsanlageumgebung.
BESCHREIBUNG DES STANDES DER TECHNIK
Prozessteuerungssysteme, wie verteilte oder skalierbare Prozessteuerungssysteme, die etwa bei Prozessen der Energiegewinnung, bei chemischen, erdölbezogenen oder bei anderen Prozessen verwendet werden, umfassen typischerweise einen oder mehrere Regler, die kommunikativ miteinander und über ein Prozesssteuerungsnetzwerk mit mindestens einem Host oder einer Arbeitsstation eines Betreibers verbunden sind, und über analoge, digitale oder kombinierte analoge und digitale Datenleitungen mit einem oder mehreren Feldgeräten verbunden sind. Die Feldgeräte, die zum Beispiel Ventile, Ventilstellungsregler, Schalter oder Transmitter (z.B. Temperatur-, Druck oder Fließratensensoren) sein können, erfüllen Funktionen innerhalb des Prozesses oder der Anlage, wie etwa Öffnen und Schließen von Ventilen, Ein- und Abschalten von Geräten und Messen von Prozessparametern. Der Regler empfängt Signale, die Prozess- und Anlagemessungen anzeigen, die von den Feldgeräten stammen und/oder andere Informationen, die die Feldgeräte betreffen, benutzt diese Informationen, um ein Steuerbedienungsprogramm zu implementieren und dann Steuersignale zu generieren, die über die Datenleitungen zur Steuerung des Betriebs des Prozesses oder der Anlagen an die Feldgeräte gesendet werden. Von den Feldgeräten und dem Regler stammende Informationen werden typischerweise einer oder mehreren Applikationen zur Verfügung gestellt, die von der Arbeitsstation eines Betreibers ausgeführt werden, damit der Betreiber in der Lage ist, gewünschte Funktionen in Hinblick auf den Prozess oder die Anlage durchzuführen, wie etwa den aktuellen Status der Anlage zu sehen oder den Betrieb der Anlage zu modifizieren etc..
Die Prozessregler, die typischerweise innerhalb des Umfeldes der Prozessanlage angebracht sind, empfangen Signale, die Prozessmessungen oder Prozessvariablen anzeigen, die von den Feldgeräten stammen oder mit ihnen und/oder anderen Informationen über die Feldgeräte assoziiert sind und führen unter Verwendung dieser Informationen Reglerapplikationen aus. Die Reglerapplikationen implementieren beispielsweise unterschiedliche Steuermodule, die Entscheidungen hinsichtlich der Prozessteuerung treffen, auf den empfangenen Informationen basierende Steuersignale generieren und mit den in den Feldgeräten, wie etwa HART^® und FOUNDATION^®-Feldbusgeräten, befindlichen Steuermodulen oder -blöcken koordinieren. Die Steuermodule in den Prozessreglern senden die Steuersignale über die Kommunikationsleitungen oder andere Signalleitungen an die Feldgeräte, um dadurch den Prozessbetrieb zu steuern.
Von den Feldgeräten und den Prozessreglern stammende Informationen werden typischerweise einem oder mehreren anderen Hardwaregeräten über das Prozessteuerungsnetzwerk zur Verfügung gestellt, wie etwa Arbeitsstationen, Wartungsstationen, Servern, PCs, Handheld-Geräten, Datenarchivierungen, Berichtgeneratoren, zentralisierten Datenbanken etc.. Mit den über das Netzwerk übertragenen Informationen kann ein Betreiber oder ein Wartungsmechaniker gewünschte Funktionen hinsichtlich des Prozesses durchführen und/oder den Betrieb der Anlage ansehen. Beispielsweise kann ein Betreiber mit Hilfe der Informationen die Einstellungen des Steuerbedienungsprogramms ändern, den Betrieb der Steuermodule innerhalb der Prozessregler oder kommunikationsfähigen Feldgeräte modifizieren, das aktuelle Prozessstadium oder den Status eines bestimmten Gerätes innerhalb des Prozessanlage ansehen, von Feldgeräten und Prozessreglern stammende Alarmsignale ansehen, den Prozessbetrieb für die Ausbildung des Personals oder für das Testen der Prozessteuerungssoftware simulieren, Probleme oder Ausfälle hinsichtlich der Hardware innerhalb der Prozessanlage diagnostizieren und so weiter.
Die Feldgeräte kommunizieren mit anderen Geräten gewöhnlich über das Prozessteuerungsnetzwerk, was beispielsweise ein Ethernet konfiguriertes LAN-Netzwerk sein kann. Das Netzwerk überträgt die Prozessparameter, Netzwerkinformationen und andere Prozesssteuerdaten über verschiedene Netzwerkgeräte an vielfältige Einheiten im Prozessteuerungssystem. Zu den typischen Netzwerkgeräten gehören Netzwerkkarten, Switches, Router, Server, Firewalls, Regler und Arbeitsstationen. Die Netzwerkgeräte ermöglichen normalerweise den Datenfluss über das Netzwerk, indem sie dessen Routing, Frame-Rate, Timeout und andere Netzwerkparameter steuern, sie verändern dabei aber nicht die Prozessdaten. Wenn das Prozessteuerungsnetzwerk an Größe und Komplexität gewinnt, erhöht sich entsprechend die Anzahl und die Art der Netzwerkgeräte. Aufgrund des Anwachsens des Systems und des Netzwerkes, erweisen sich die Sicherheit und das Management von solchen komplexen Systemen als zunehmend schwieriger. Beispielsweise kann jedes Netzwerkgerät einen oder mehrere Kommunikationsports umfassen, die einen Access Point oder Port zur physikalischen Verbindung der Prozessteuerungssystemkomponenten und anderer Netzwerkgeräte untereinander durch das Netzwerk bieten. Einige dieser Ports oder Verbindungen können jedoch auch zum Anschluss der Steuergeräte an öffentlich zugängliche Netzwerke wie etwa das Internet oder zum Anschluss tragbarer Speichergeräte an die Steuersystemgeräte verwendet werden. Ein offener Port an dem Gerät kann daher ein Access Point für eine Netzwerkerweiterung werden, indem andere Geräte hinzugefügt werden oder einer Einheit, schädlich oder nicht, Zugriff auf das Netzwerk gewährt wird und damit unerwünschter und potentiell schädlicher Netzwerkverkehr eingeleitet wird oder Malware (wie zum Beispiel schädliche Programme, Programme zum Ausspähen oder Sammeln von Daten, und andere unerwünschte und potentiell schädliche Programme) eingeführt wird, die schwerwiegende Probleme innerhalb des Anlagesteuersystems hervorrufen kann. Eine wirksame Überwachung oder Steuerung des Zugriffs auf alle Ports an Geräten innerhalb eines Netzwerkes, das Kommunikationen über ein komplexes Prozessteuerungssystem steuert, wird mit Zunahme der Netzwerkgeräte und damit assoziierten Access Points zunehmend unmöglicher.
Ebenso werden in einem typischen industriellen Steuerungssystem die Arbeitsstationen/Server strategisch zwischen dem Anlagenetzwerk und den eingebetteten Geräten verteilt, die Steuerungs- und Datenabschlussfunktionen ausführen (z.B. Regler, SPS, RTUs) und ein wichtiges Ziel hinsichtlich Sicherheit für diese Arbeitsstationen und Server besteht darin, zu verhindern, dass Malware in das Steuerungssystem eindringen und die eingebetteten Geräte nachteilig beeinflussen kann und auch dass Malware die in der Anlagendatenbank gespeicherte Konfigurationsdaten und historischen Daten ändern kann. Obwohl eine Reihe von Sicherheitsfunktionen, wie etwa „Antivirus-Software“ und „White Listing” für dieses Ziel eingesetzt werden können, sind diese Sicherheitsfunktionen im Allgemeinen jedoch nicht ausreichend. Beispielsweise bietet Antivirus-Software keinen Schutz gegen „Zero-Day”-Viren und White Listing verhindert nur die Ausführung von nicht berechtigten Applikationen. Des Weiteren sind einige dieser Funktionen derart aggressiv, dass sie in einem Prozessteuerungssystem nicht einsatzfähig sind, weil die Sicherheitsfunktionen das Potential aufweisen, die Handlungen von Anlagebetreibern zu behindern.
Im Allgemeinen wird Malware, wie etwa bei einer vernichtenden Zero-Day-Attacke, typischerweise durch ein bestimmtes Gerät über ein externes Speichergerät (wie etwa ein entfernbarer USB-Stick) oder über Kommunikationsverbindungen durch einen Betrieb einer Applikation oder eines Dienstes, die/der Zugriffsrecht oder -berechtigung für diese Speichergeräte, Netzwerkports oder direkten Datenverbindungen hat, in das Steuerungssystem eingeführt. (Im Sinne dieses Patents umfassen Kommunikationsverbindungen Verbindungen, die über eine Kommunikationsnetzwerkverbindung oder eine direkte Datenverbindung wie etwa ein Modem zustande kommen.) Danach ist die Malware in der Lage, sich auf andere Geräte (z.B. über Kommunikations- oder tragbare Speichergeräte) zu verbreiten und/oder im Gerät unter Verwendung der Sicherheitsrechte der Applikationen oder Dienste, die von der Malware infiziert wurden, ausgeführt zu werden. Des Weiteren kann die Malware örtlich bestehen bleiben, um nach einem Neustart wieder ausgeführt werden zu können. Bei einigen Fällen kann die Malware die Rechte eines Hosts z.B. einer infizierten Applikation oder eines Dienstes unter Verwendung der Rechte des Kontos, unter welchem die Applikation oder der Dienst ausgeführt werden, sprunghaft erweitern und die Malware kann dadurch in der Lage sein, Aktionen oder Transaktionen innerhalb des Prozessteuerungsgeräts oder -systems durchzuführen, die vorrangige Rechte erfordern und sind daher im Allgemeinen noch schädlicher für den Betrieb des Steuerungssystems. Jedenfalls stellen Zero-Day-Attacken, die eine bereits ausgeführte Applikation infizieren, ein starkes Problem bei Prozessteuerungssystemen dar und es gibt keine effektive Verfahrensweise, um diese Art von Attacken zu verhindern. Diese Attacken können schwerwiegende, zerstörerische und sogar tödliche Konsequenzen in einer Prozessanlage mit sich führen, wenn diese Attacken den laufenden Betrieb des Anlagesteuerungssystems stören.
KURZDARSTELLUNG DER OFFENBARUNG
Ein Prozessteuerungssystem verwendet eine neue Zusammenstellung von Sicherheitsfunktionen oder eine Software-Sicherheitsarchitektur, die Attacken der Zero-Day-Malware oder anderer Arten von Malware effektiver verhindert. Im Allgemeinen implementiert die neue Sicherheitsfunktion oder Sicherheitsarchitektur bei der Ausführung von Applikationen und Diensten in einem bestimmten Steuerungssystemgerät, wie etwa Arbeitsstationen, Server, Datenbanken, Regler, Feldgeräte etc., die Anwendung, die hier als „geringste Rechte” bezeichnet wird, um damit den Einfluss von Malware zu verringern, die eine Arbeitsstation, einen Server oder andere Geräte infizieren kann. Der Begriff „Recht“ umfasst hier sowohl Betriebssystemrechte als auch Zugriffsberechtigungen. Beispielsweise kann einem Benutzer das Recht gewährt werden, sich rechnerfern anzumelden oder einen anderen Benutzer (oder Recht) zu imitieren und auch ein Zugriff gewährt werden, bestimmte Dateien zu lesen/schreiben/auszuführen (Berechtigungen).
Im allgemeinen trennt die auf geringste Rechte basierende Sicherheitsfunktion oder Sicherheitsarchitektur „Dienstprozesse” von Desktopapplikationen, die im Auftrag von einem angemeldeten Benutzer (örtlich oder rechnerfern) laufen, durch beispielsweise Partitionieren des allgemeinen Namensraums des Geräts (z.B. Regler, Arbeitsstation, Server etc.) in einen Dienstnamensraum und, soweit vorhanden, in Namensräume des angemeldeten Benutzers, (z.B. wie etwa Desktopapplikationen). Die Architektur steuert dann genau Kommunikationen zwischen den Prozessen (z.B. die Applikationen und die Dienste) in diesen unterschiedlichen Namensräumen unter Verwendung von Interprozesskommunikationen (und nicht gemeinsam genutzten Speichern), um einen infizierten Dienst oder infizierte Applikation daran zu hindern, direkt andere Applikationen oder Dienste zu infizieren oder zu korrumpieren. Insbesondere benutzt die neue Sicherheitsarchitektur diese Partitionierung des Namensraums, um eine Desktopapplikation daran zu hindern, direkt auf Objekte in dem Dienstnamensraum zuzugreifen und umgekehrt.
Ferner schränkt die neue Sicherheitsarchitektur die Diensten und Desktopapplikationen gewährten Rechte ein, und zwar auf eine Weise, dass dadurch die Fähigkeit eines infizierten Dienstes oder einer infizierten Applikation beschränkt wird, andere Dienste oder Applikationen zu infizieren oder zu korrumpieren. Im Allgemeinen beschränkt die Sicherheitsarchitektur die Betriebssystemrechte von einem Dienst oder einer Applikation oder anderen Prozess auf eine spezifische Untermenge von Rechten, die dem Konto gewährt werden, unter welchem der Dienst oder Applikationen oder andere Prozesse ausgeführt oder hervorgebracht werden, beschränkt die Rechte von Applikationen, die im Auftrag von angemeldeten Benutzern ausgeführt werden, auf eine spezifische Untermenge von mit dem Benutzer assoziierten Rechten und verhindert eine Erweiterung der Ausfüllungsrechte über eine Desktopapplikation (die unter dem angemeldeten Benutzer ausgeführt wird). Bei einem Fall setzt das Softwaresicherheitssystem eine Beschränkung durch, dass jeglicher Zugriff auf einen Kommunikationsport oder externen Medienport (z.B. für ein entfernbares Speichergerät, das über einen externen Medienport wie ein USB-Port verbunden ist) über einen Dienst mit beschränkten Rechten (und niemals durch eine Desktopapplikation) auszuführen ist, wobei die beschränkten Rechte des Dienstes den Dienst daran hindern, auf einen lokalen Speicher (z.B. Festplatte) zu schreiben, über den anderen von dem Kommunikationsport oder externen Medienport zu kommunizieren, oder mit Administratorrechten zu agieren. Auf diese Weise wird die Infizierung ungefährlich, im Fall, dass ein Dienst infiziert ist, da die Infizierung sich nicht auf einer lokalen Festplatte oder einem anderen Speicher abspeichern kann, keine Verwaltungsfunktionen ausführen kann, auf den Desktop nicht zugreifen kann, über ein Kommunikationsnetzwerk nicht verbreitet werden kann, falls es über einen externen Medienport von einem entfernbaren Speichergerät eingeführt wurde, und über einen externen Medienport nicht auf einem entfernbaren Speichergerät abgespeichert werden kann oder zu einer weiteren Kommunikationsverbindung verbreitet werden kann, falls sie über einen Kommunikationsport von einer Kommunikationsverbindung eingeführt wurde.
Daher verwendet die neue Sicherheitsarchitektur Zugriffssteuerungen, die durchsetzen, welche Benutzerkonten und welche Prozesse (Dienst oder Desktop) berechtigt sind, durch Aufforderungen an das Betriebssystem und seine Subsysteme auf feststellbare Objekte zuzugreifen und umfasst einen Mechanismus, der Prozesse mit geringeren Rechten daran hindert, einen Code bei Prozessen mit höherwertigen Rechten einzuspeisen. Zu diesem Zweck weist die Sicherheitsarchitektur Konten, die allgemein „Gruppen“ genannt werden, auf oder nutzt diese, damit Benutzerkonten und Dienstkonten zu einer Übernahme von anderen Gruppenkonten gehören können.
Die Kombination von einer oder mehreren Sicherheitsfunktion führt zu einer besser gesicherten Softwareumgebung innerhalb eines Prozessteuerungssystems oder einer Prozessanlage, die hinsichtlich Virusattacken wie etwa Zero-Day-Virusattacken und von anderer Malware weniger anfällig sind, da durch diese Sicherheitsfunktionen, allein oder in Kombination, es für Malware schwierig, wenn nicht unmöglich wird, in das System durch den Betrieb einer Desktopapplikation, die auf eine Netzwerkverbindung oder eine entfernbare/tragbare Speicherverbindung (wie ein USB-Port) zugreift, eingeführt zu werden. Diese Sicherheitsfunktionen beschränken auch die Fähigkeit der Malware, über ein Netzwerk oder externes Gerät auf ein internes Datenspeichergerät gebracht zu werden, die Rechte von Diensten für den Zugriff auf Geräte, Speichermedien oder Prozesse, die von der Applikation, die den Dienst anfordert, nicht benötigt werden, sprunghaft zu erweitern etc..
Unter Verwendung dieser Funktionen partitioniert (isoliert) die neue Sicherheitsarchitektur die Dienste und Desktopapplikationen, die in den Arbeitsstationen des Systems für Prozesssteuerung und Automatisierung und in den Servern laufen, um ihr Profil oder Oberfläche für Malwareattacken zu reduzieren. Falls ein Dienst oder ein von einem Dienst hervorgebrachter Prozess infiziert wird, wird dieser außerdem nicht die Rechte haben, etwas zu bearbeiten, das er nicht bereits bearbeitet, und nicht die Berechtigungen haben, auf Ressourcen zuzugreifen, die er nicht direkt benötigt. Des Weiteren ist eine Desktopapplikation, wenn sie infiziert wird, nicht in der Lage, auf privilegierte Funktionen des Betriebssystems direkt zuzugreifen, und kann auch nicht direkt auf das Netzwerk oder eine entfernbare Speichereinheit schreiben, die über einen externen Medienport verbunden sind. Die Desktopapplikation muss daher Aktionen anfordern, die von Diensten und von ihnen hervorgebrachten Prozessen für sie durchzuführen sind, die derart entwickelt sind, um eine zusätzliche Ebene der Zugriffssteuerung auf privilegierte Funktionen und Ressourcen zu bieten und zu bestätigen.
KURZBESCHREIBUNG DER ABBILDUNGEN
1 zeigt ein beispielhaftes Blockdiagramm einer Prozessanlage mit einem verteilten Prozesssteuerungssystem und Prozessautomatisierungsnetzwerk einschließlich einer oder mehrerer Bediener- und Verwaltungsarbeitsstationen, Server, Regler, Feldgeräte und anderer Netzwerkgeräte, die zur Implementierung der hier beschriebenen auf geringste Rechte basierenden Sicherheitsarchitektur für Software konfiguriert sind.
2 zeigt ein beispielhaftes Blockdiagramm einer/s Arbeitsstation/Servers/Reglers innerhalb einer Prozesssteuerungsanlage, wobei verschiedene Namensraum- und Sicherheitsbeschränkungen gezeigt werden, die hinsichtlich Applikationen, Diensten und anderer in der Prozesssteuerungssoftwarearchitektur ausgeführter Prozesse zur Implementierung von fortgeschrittenen Sicherheitsfunktionen implementiert sind.
3 zeigt eine Diagramm von Konten, einschließlich Gruppenkonten und benutzerdefinierten Konten, die Mengen von mit den verschiedenen Applikationen und Diensten assoziierten Rechten gemäß der hier beschriebenen auf geringste Rechte basierenden Sicherheitsarchitektur für Software definieren.
4 zeigt ein beispielhaftes Architekturdiagramm, das die Software- und Hardwarekomponenten von einer der Arbeitsstationen des Systems in 2 abbildet und die Kommunikationsverbindungen zwischen verschiedenen Diensten und Applikationen, die die Konten von 3 benutzen, abbildet.
BESCHREIBUNG
1 zeigt eine schematische Darstellung eines Prozessteuerungssystems oder Prozessautomatisierungssystems 100, das beispielsweise in einer Prozessanlage angeordnet ist, in welcher verschiedene Computergeräte verschiedenen Softwaresicherheitsfunktionen zur Verbesserung der Softwaresicherheit und Unterstützung der Verwaltung und Wartung von Computern/Netzwerk unterworfen werden können. Das Prozessteuerungssystem 100 umfasst insbesondere ein oder mehrere Prozessregler 110 und ein oder mehrere Prozessanlagendatenbanken 112 (wie etwa Datenarchivierungen), die kommunikativ über ein Kommunikationsnetzwerk zur Prozesssteuerung 130 mit einer oder mehreren Datenbanken (Hosts) oder Computern 120–122 (welche jede Art von PCs, Arbeitstationen, Server etc. sein können) verbunden sind. Die Regler 110 und die Datenbanken 112 können über eine oder mehrere Netzwerkkarten 132 mit dem Kommunikationsnetzwerk oder Bus 130 (beispielsweise ein Ethernet-Kommunikationsnetzwerk) verbunden sein. Weiter können die Regler 110 über I/O-Karten 142 mit in der Prozessanlage oder im Steuersystem befindlichen Feldgeräten 140, 143 und 154 verbunden sein. Die Datenbanken 112 können eine oder mehrere Datenarchivierungen umfassen, die jegliche Art von gewünschten Datensammlungseinheiten oder Speichergeräte von jeglicher Speicherart und gewünschter oder bekannter Software, Hardware, Firmware zur Speicherung von Daten aufweisen können. Des Weiteren können die Datenbanken 112 ein Teil von einer oder mehreren Arbeitstationen oder Server 120–122 sein oder davon getrennt bestehen. Die Regler 110, wie beispielsweise die von Fisher Rosemount Systems, Inc. angebotenen DeltaV^TM-Regler, sind durch eine oder mehrere Netzwerkkarten oder -geräte 132 über beispielsweise die Ethernet-Verbindung 130 oder über jegliches gewünschtes Kommunikationsnetzwerk kommunikativ mit den Hosts 120–122 verbunden. Die Netzwerkgeräte 132 können eine Netzwerkkarte, einen Switch, einen Router, eine Firewall oder ein anderes Gerät oder mehrere davon umfassen, die die Datenübertragung über das Netzwerk 130 ohne Änderung der zugrunde liegenden Daten ermöglichen.
Wie in 1 dargestellt, ist ein Server 122 mit verschiedenen Netzwerkgeräten verbunden, welche sich in irgendeinem Bereich eines Kommunikations- oder Prozesssteuerungsnetzwerks und innerhalb eines Bereichs einer Prozessanlage befinden können und jeglichen Teil der hier beschriebenen Sicherheitsfunktion umfassen kann. Bei diesem Beispiel ist das Kommunikationsnetzwerk 130 typischerweise ein geschlossenes lokales Netz (LAN), an das nur die im Steuerungssystem involvierten Geräte angeschlossen sind und mittels festverdrahteter oder drahtloser Technologie implementiert werden können. Des Weiteren sind die Regler 110 kommunikativ mit den Feldgeräten 140 unter Verwendung jeglicher Hardware und Software, die beispielsweise mit standardmäßigen 4–20 mA-Gerätprotokollen, Ethernet-Protokollen und/oder jeglichem intelligenten Kommunikationsprotokoll wie etwa das FOUNDATION^® Feldbus-Protokoll (Feldbus), das HART^®-Protokoll, das WirelessHART^®-Protokoll, das Profibus-Protokoll, das CAN-Protokoll etc. assoziiert sind, verbunden.
Die Feldgeräte 140, 143 und 154 können alle Arten von Geräten sein, wie etwa Sensoren, Ventile, Transmitter, Stellungsregler etc., wobei die I/O-Karten 142 jegliche I/O-Geräte sein können, die jeglichem gewünschten Kommunikations- oder Steuerungsprotokoll entsprechen. Bei der in 1 dargestellten Ausführungsform sind die Feldgeräte 140 HART- oder 4–20 mA-Geräte, die über standardmäßige HART- oder analoge 4–20 mA-Leitungen 141 mit einem Modem oder einer I/O-Karte 142 kommunizieren, während die Feldgeräte 143 intelligente Geräte, wie etwa FOUNDATION^®-Feldbus-Feldgeräte sind, die über einen digitalen Bus 145 oder I/O-Netzwerk mit einer der I/O-Karten 142 unter Verwendung von Feldbus-Protokollkommunikationen kommunizieren. Die Feldgeräte 140 und 143 können natürlich jeglichem Standard oder Protokoll entsprechen, wobei auch in der Zukunft entwickelte Standards und Protokolle eingeschlossen werden. Die Feldgeräte 140 und 143 können darüber hinaus drahtlos mit den Reglern 110 über jegliches drahtlose Kommunikationsprotokoll, wie das WirelessHART^®-Protokoll, verbunden sein.
Außerdem können ein oder mehrere Feldgeräte 154 über ein Spezialnetzwerkgerät wie etwa ein Gateway 153 mit einem digitalen Bus 145 verbunden sein. Beispielsweise können die Feldgeräte 154 nur HART-Befehle verstehen und das I/O-Netzwerk 145 kann das PROFIBUS-Protokoll implementieren. Hierzu kann das Gateway 153 eine bidirektionale PROFIBUS/HART-Konvertierung bereitstellen.
Die Regler 110, die ein oder mehrere in der Anlage verteilte Regler mit einem oder mehreren integrierten Prozessoren sein können, implementieren oder überwachen eine oder mehrere Programme der Prozesssteuerung. Zu den Programmen können eine oder mehrere Steuerungsschleifen gehören, die in den Reglern 110 gespeichert sind oder mit diesen assoziiert sind. Die Regler 110 kommunizieren auch durch das Netzwerk 130 und damit assoziierte Netzwerkgeräte 132 mit den Geräten 140, 143 und 154 und mit den Hosts und Servern 120–122, sowie mit der Datenarchivierung und anderen Datenbanken 112, um einen Prozess in gewünschter Art zu steuern. Es sei darauf hingewiesen, dass jegliche Steuerbedienungsprogramme und hier beschriebene Elemente Teile aufweisen können, die von unterschiedlichen Reglern oder anderen gewünschten Geräten implementiert oder ausgeführt werden können. Ebenso können die Steuerbedienungsprogramme und hier beschriebenen Elemente, die im Prozesssteuerungssystem 100 implementiert werden sollen, jeglicher Art sein, wie etwa Software, Firmware, Hardware etc. Zum Zwecke dieser Erörterung kann ein Prozesssteuerungselement einen Teil oder einen Abschnitt eines Prozesssteuerungssystems darstellen, der auf einem computerlesbaren Medium gespeichert ist, wie beispielsweise ein Bedienungsprogramm, ein Datenblock oder ein Modul. Steuerbedienungsprogramme, die Module oder jeglicher Teil einer Steuerungsprozedur wie etwa ein Unterprogramm, Teile eines Unterprogramms (wie Codezeilen) etc. sein können, können in jeglichem Softwareformat implementiert werden, wie etwa unter Verwendung von Leiterlogik, Ablaufsprachen, Funktionsbausteinsprachen, objektorientierte Programmierung oder von jeglicher anderer Programmiersprache oder jeglichem anderen Entwicklungsmuster einer Software. Steuerbedienungsprogramme können ebenfalls in beispielsweise ein oder mehrere EPROMs, EEPROMs, anwendungsspezifische integrierte Schaltungen (ASICs) oder jegliche andere Hardware- oder Firmwareelemente fest kodiert werden. Die Steuerbedienungsprogramme können ferner mit jeglicher Erstellungshilfe, einschließlich grafischer Erstellungshilfen oder jeder anderen Art von Software-, Hardware-, Firmwareprogrammierhilfe oder Erstellungshilfe entwickelt werden. Daher können die Regler 110 derart konfiguriert werden, eine Steuerstrategie oder Steuerbedienungsprogramme in jeder gewünschten Form zu implementieren.
Ferner ist ein weiteres Kommunikationsnetzwerk 160, wie in 1 dargestellt wird, mit dem Server 122 und den Arbeitsstationen 120 und 121 verbunden, damit der Server des Prozessteuerungssystems 122 und die Arbeitsstationen 120 und 121 mit der Informatik der Anlage, mit betrieblichen Informationssystemen und anderen Netzwerksystemen innerhalb der Anlage verbunden werden können.
Im Allgemeinen implementieren die Arbeitsstationen und Server 120–122 sowie die anderen innerhalb des Netzwerks von 1 befindlichen Geräte das, was hier als auf geringste Rechte basierende Sicherheitsarchitektur bezeichnet wird, die (1) die Dienste und anderen Prozesse auf niedriger Ebene, die in verschiedenen Computern von 1, wie etwa Arbeitsstationen, Server, Datenbanken, Regler etc. ausgeführt werden, von den Desktopapplikationen isoliert oder abtrennt, und zwar auf verschiedene Weisen, und die (2) die Rechte der Dienste und Desktopapplikationen nur auf solche beschränkt, die diese Prozesse zur Implementierung ihrer Funktionalitäten benötigen. Diese auf geringste Rechte basierende Sicherheitsarchitektur unterstützt die Prävention, dass Malware importiert und innerhalb der Geräte der Prozesssteuerung instanziiert und ausgeführt werden kann. Im Allgemeinen können Desktopapplikationen und die Dienste oder anderen Prozesse innerhalb eines Computers isoliert werden, indem der allgemeine Namensraum jedes Computers des Prozesssteuerungssystems in ein oder mehrere Dienstnamensräume und in ein oder mehrere Benutzernamensräume (Desktopapplikationen) partitioniert wird. Diese Partitionierung verhindert, dass Desktopapplikationen direkt auf Objekte (z.B. Mutexe), die in dem Namensraum definiert sind, der von den Diensten benutzt wird, zugreifen können und dass Dienste direkt auf Objekte (z.B. in der Desktopumgebung), die für die von den Desktopapplikationen benutzten Desktopnamensräume definiert sind, zugreifen können. Stattdessen müssen alle Kommunikationen zwischen den verschiedenen Desktopapplikationen und Diensten, die vom Betriebssystem implementiert sind, über bekannte und zuverlässige Interprozesskommunikationen (IPCs) kommunizieren, die eine zuverlässige auf einem Nachrichtensystem basierende Kommunikationsstruktur bieten, die Kommunikationen zu Geräten/Arbeitsstationen/Server, in denen die Kommunikation implementiert ist, beschränkt und daher die Fähigkeit einer Applikation oder eines Dienstes, den Betrieb von anderen Applikationen oder Diensten (z.B. den Speicherplatz) zu stören, zu infizieren oder zu beeinträchtigen, verhindert oder reduziert. Auf diese Weise kann über eine Desktopapplikation eingeführte Malware nicht einfach zu einem Dienst oder anderem Prozess mit niedrigem Niveau importiert werden und umgekehrt.
Die hier beschriebene auf geringste Rechte basierende Sicherheitsarchitektur beschränkt/begrenzt außerdem die Einführung und Verbreitung von Malware innerhalb des Systems durch Beschränken der jedem Dienst oder jeder Desktopapplikation gewährten Rechte auf eine spezifische Untermenge von Rechten, wie etwa eine Untermenge von Rechten, die einem angemeldeten Benutzerkonto gewährt werden, bei welchem der Dienst oder die Applikation ausgeführt oder aufgerufen wird. Beispielsweise wird bei Diensten, die normalerweise auf einem Administratorkonto laufen und typischerweise alle Rechte des Administrators haben, die neue abgesicherte Softwarearchitektur einige oder alle Dienste nur mit den spezifischen Rechten ausführen oder abrufen, die der Dienst für die Erfüllung der Funktion, die er zu erfüllen hat, benötigt und nicht mit allen Administratorrechten. Ferner werden Dienste mit Zugriff entweder auf ein Kommunikationsnetzwerk (über einen Kommunikationsnetzwerkport) oder auf einen entfernbaren Datenspeicher über einen entfernbaren Speicherport (z.B. einen USB-Port) auf einem Konto mit sehr beschränkten Rechten ausgeführt, wobei diese Dienste keine Administratorrechte haben, keine Rechte für das Speichern oder Schreiben auf eine Festplatte (d.h. lokalen Speicher) haben und weder über den Kommunikationsnetzwerkport noch über den entfernbaren Speicherport direkt kommunizieren können. Diese Funktion unterbindet oder reduziert zumindest die Fähigkeit von Malware, einen Dienst zu benutzen, der von einem Benutzer mit erweiterten Rechten abgerufen wird, und Zugriff auf Geräte und Funktionalitäten zu haben, die vom Dienst selbst nicht benötigt werden, und dadurch wird die Fähigkeit von Malware, andere Geräte zu infizieren oder Befehle oder Dienste mit erweiterten Rechten auszuführen einfach aufgrund des angemeldeten Benutzerkontos, vom welchen der Dienst ausgeführt oder aufgerufen wird, beschränkt.
Die Sicherheitsfunktionen können ebenfalls Rechte für Applikationen, wie von angemeldeten Benutzern gestartete Desktopapplikationen, automatisch beschränken, um eine Erweiterung der Rechte zu verhindern. Bei manchen Fällen verhindert die Sicherheitsarchitektur, dass jede erdenkliche Desktopapplikation eine Erweiterung der Rechte erhalten kann, so dass eine an einen Benutzer gestellte Anfrage für eine Erweiterung der Rechte ein Anzeichen dafür ist, dass diese Applikation infiziert wurde. Allgemein erfordert eine Erweiterung der Rechte für eine Desktopapplikation (die vom angemeldeten Benutzerkonto ausgeführt wird) heutzutage typischerweise eine Genehmigung eines berechtigten Benutzers, um einen Arbeitsablauf, der eine Erweiterung der Rechte erfordert, durchführen zu können. Neuartige Betriebssysteme setzen diese Funktion typischerweise derart durch, indem sie von angemeldeten Benutzern einschließlich Administratoren gestarteten Applikationen nur standardmäßige Benutzerrechte (keine erweiterten Rechte oder Administratorrechte) gewähren und verlangen, dass eine Erweiterung der Rechte ausdrücklich von einem Benutzer genehmigt wird. Die neue Architektur könnte eine Erweiterung der Rechte von Desktopapplikation in jedem Fall verhindern, wodurch ein weiteres Sicherheitsniveau bereit gestellt wird, das die Fähigkeit von Malware beschränkt, automatisch Rechte im System zu erweitern und mithilfe dieser Erweiterung der Rechte zusätzliche Prozesse oder Geräte zu infizieren.
Ebenfalls kann die hier beschriebene Architektur auch Zugriffssteuerungen benutzen, die auferlegen, welche Benutzerkonten oder Prozesse (Dienst oder Desktop) berechtigt sind, durch Anforderungen an das Betriebssystem oder an dessen Subsysteme (z.B. Dateien, Mutexe, Vorgänge) auf feststellbare Objekte zugreifen zu können; sie kann ferner Mechanismen anwenden, um Prozesse mit geringeren Rechten daran zu hindern, Code bei Prozessen mit höherwertigen Rechten einzuspeisen, und kann auf Gruppen basierte Konten, die allgemein „Gruppen“ genannt werden, benutzen, um eine Übernahme von Rechten/Berechtigungen zu erlauben. Beispielsweise kann Benutzer A zur Gruppe B gehören, die wiederum zu Gruppe C gehört. Benutzer A übernimmt daher Rechte und Berechtigungen von sowohl B als auch C. Obwohl diese Rechte gemeinsam genutzt oder auf dem angemeldeten Benutzerkonto tragbar sein können, werden diese Rechte nicht auf Dienste oder Prozesse verbreitet, die Nachrichten von Applikation erhalten, die unter diesen Konten ausgeführt werden, wodurch verhindert wird, dass Dienste oder Prozesse (wie solche, die vom Betriebssystem als Reaktion auf von diesen Applikationen erhaltene Nachrichten instanziiert wurden) erweiterte Rechte haben können. Allgemein werden Rechte für Dienste oder Prozesse, die vom Betriebssystem ausgeführt oder eingebracht werden, daher getrennt von den Rechten für angemeldete Benutzerkonten definiert, so dass die Dienste oder Prozesse (und in vielen Fällen die Applikationen), die auf einem Benutzerkonto mit erweiterten Rechten ausgeführt werden, auf eine Untermenge von Rechten, d.h. die geringsten Rechte, beschränkt werden, die für den beabsichtigen Arbeitsablauf des Dienstes oder der Applikation oder des Prozesses benötigt werden.
Bezugnehmend auf 2 werden die Sicherheitsfunktionen und die hier beschriebene abgesicherte Architektur in einem Server oder einer Arbeitsstation oder einem Regler implementiert, wie die in 1 dargestellten Geräte. Dabei ist selbstverständlich, dass das hier beschriebene Sicherheitskonzept auch bei anderen Arten von Computern oder Maschinen, wie etwa Arbeitsstationen, Datenbankservern etc. auf gleiche oder ähnliche Weise implementiert werden kann. Insbesondere zeigt 2 eine/n mit keinem, einem oder mehreren Netzwerken/Datenlinks 230 verbundene Arbeitsstation/Server/Regler 220, von denen eines beispielsweise das Netzwerk 130 von 1 sein kann. In diesem Fall ist der Server/die Arbeitsstation 220 weiterhin mit einer oder mehreren lokalen Datenspeichern 235 verbunden, die in 2 als intern oder direkt mit der/dem Arbeitsstation/Server/Regler 220 verbunden dargestellt sind. Des Weiteren können die/der Arbeitsstation/Server/Regler 220 eine Benutzerschnittstelle oder ein Anzeigegerät 237 umfassen oder damit verbunden sein und keinen, einen oder mehrere entfernbare Medienports 239 umfassen. Der/de entfernbare/n Medienport/s 239, durch den/die externe und entfernbare Speichergeräte mit dem Gerät 220 verbunden sein können, können jede Art von Speicherzugriffsport wie ein USB-Port, eine standardmäßige oder firmeneigene Verbindung zu einem CD- oder DVD-Laufwerk, eine externe Festplatte, ein USB-Stick oder einen Festspeicher, eine Magnetplatteneinheit etc. umfassen. Wie in 2 gezeigt wird, können Daten, Programme etc. der/dem Arbeitsstation/Server/Regler 220 über einen der Ports 239, über ein entfernbares und tragbares Speichergerät, wie ein USB-Stick 240, eine DVD oder CD 241 etc., bereitgestellt oder von der/dem Arbeitsstation/Server/Regler 220 exportiert werden.
Des weiteren umfasst die/der Arbeitsstation/Server/Regler 220 keinen, einen oder mehrere Kommunikationsports 245, wobei jeder mit einem/einer Kommunikationsnetzwerk/Datenlink/Kommunikationsschnittstelle verbunden ist, das/die beispielsweise ein fest verdrahtetes oder drahtloses Kommunikationsnetzwerk, wie etwa ein Ethernet-Netzwerk, ein WiFi-Netzwerk, an Internetprotokollnetzwerk, oder jede andere örtliche Computervernetzung oder Weitverkehrsnetz oder Datenlink sein kann.
Wie ferner in 2 gezeigt wird, ist die/der Arbeitsstation/Server/Regler 220 in zwei Arten von Namensräumen partitioniert, die einen Dienstnamensraum 250 und keinen, einen oder mehrere angemeldete Benutzernamensräume (in 2 als ein einzelnen angemeldeter Benutzernamensraum 252 veranschaulicht) umfassen. Natürlich kann es ein unterschiedlicher angemeldeter Benutzernamensraum (der hier auch Benutzernamensraum genannt wird) für jeden unterschiedlichen einen aus einer Vielzahl der bei der/dem Arbeitsstation/Server/Regler 220 angemeldeten Benutzer sein und einige Geräte, wie etwa Server, können keine angemeldete Benutzernamensräume aufweisen. Wie ferner in 2 gezeigt wird, besteht eine Menge von Desktopapplikationen 258 in dem Benutzernamensraum 252 und wird dort ausgeführt, wohingegen die Dienste 260 in dem Dienstnamensraum 250 bestehen und dort ausgeführt werden. Allgemein sind die Desktopapplikationen 258 Prozesse, die in einem Benutzernamensraum ausgeführt werden, wohingegen Dienstprozesse, die hier einfache Dienste genannt werden, Prozesse sind, die unabhängig vom angemeldeten Benutzer ausgeführt werden und von einem Betriebssystem (oder einem Agenten wie die Windows-Dienststeuerung) eingebracht und ausgeführt werden, und das typischerweise als Reaktion auf Konfigurationseinstellungen, auf Abrufe vom Betriebssystem oder auf an diese gerichtete Request-Nachrichten (z.B. eine COM/DCOM-Nachricht bei Windows). Abgelöste Prozesse sind unabhängige Prozesse, die im gleichen Namensraum wie der Prozess, der sie gestartet hat, (z.B. ein Dienstprozess oder ein Desktopapplikationsprozess) ausgeführt werden. Beispielsweise können abgelöste Prozesse in dem Dienstnamensraum gestartet werden und die Prozesse darstellen, die USB implementieren oder von einem anderen lokalem Datenspeichergerät lesen, oder die ein Kommunikationsnetzwerk in der hier beschriebenen Weise verknüpfen. Während Dienste 260 typischerweise automatisch gestartet werden, können diese Prozesse als Reaktion auf eine von einem Benutzerprozess oder anderem Dienst gesendete Request-Nachricht gestartet werden. Wie hier noch genauer beschrieben wird, werden die Dienste 260 immer unter einem festgelegten Konto ausgeführt, und zwar unabhängig von dem Benutzerkonto des Prozesses, der sie startet und unabhängig davon, wie sie gestartet werden, während abgelöste Prozesse unter dem Konto des Prozesses (z.B. ein Dienst oder eine Desktopapplikation), der sie startet, ausgeführt werden. Von besonderer Bedeutung ist, dass die Dienste 260 in 2 keinen, einen oder mehrere Dienstnamensraumprozesse mit Netzwerkzugriff 262 (über einen der Kommunikationsports 245), Dienstnamensraumprozesse mit Zugriff auf ein entfernbares Speichergerät 264 über einen externen Medienport 239 und andere Dienstnamensraumprozesse 266, die weder Zugriff auf tragbare oder lokale Speicher noch auf Kommunikationsnetzwerk haben, aufweisen. Ferner umfasst das lokale Datenspeichergerät oder Speicher 235 verschiedene Arten von Dateien oder Ordnern, einschließlich Dienstdateien oder -ordner 270, die von den Dienstnamensraumprozessen 260 erstellt oder benutzt werden, sowie Desktopdateien und -ordner 272, die von den angemeldeten Benutzernamensraumprozessen, die z.B. von den Desktopapplikationen 258 erstellt oder benutzt werden.
Aus 2 wird erkennbar, dass die Computerumgebung der/des Arbeitsstation/Servers/Reglers in mehrfache Unterräume mit unterschiedlichen Namensraumregeln, die mit getrennten Namensräumen für alle angemeldeten Benutzer (oder Benutzergruppen) assoziiert sind und Dienste (oder von Diensten hervorgebrachte abgelöste Prozesse) aufgeteilt ist, wobei diese Regeln durch das Betriebssystem und seine Konfigurationsdaten durchgesetzt werden. Das Partitionieren des Namensraums der allgemeinen Computerumgebung in Dienstnamensräume und angemeldete Benutzernamensräume (Desktopapplikation) verhindert, dass Desktopapplikationen direkt auf in Dienstnamensräumen definierte Objekte (z.B. Mutexe) zugreifen können und Dienstnamensraumprozesse direkt auf in angemeldeten Benutzernamensräumen (die von Desktopapplikationen benutzt werden) definierte Objekte (z.B. das Desktop) zugreifen können. Auf diese Weise müssen Dienst- und Desktopapplikationen miteinander und übereinander kommunizieren (das heißt, sie werden dazu gezwungen), um die in jedem der unterschiedlichen Namensräume geschaffenen Objekte zu erreichen. Diese Funktion verhindert, dass eine in einem Dienst oder einer Desktopapplikation von einer Umgebung befindliche Malware Objekte in den anderen Namensräumen benutzt oder erstellt, ohne dabei durch einen entsprechenden Dienst oder eine Applikation in den anderen Namensraum gehen zu müssen, der allgemein die Malware daran hindert, andere Dienste oder Applikationen zu korrumpieren. Diese Funktion beschränkt beispielsweise die Fähigkeit der Malware, Objekte in anderen Umgebungen zu erstellen oder zu infizieren, was wiederum die Fähigkeit der Malware beschränkt, sich im Steuerungssystem anzulegen und über beispielsweise das Kommunikationsnetzwerk 230 zu verbreiten.
Die oben beschriebene abgesicherte Softwarearchitektur funktioniert auf verschiedene Weisen, um die allgemeine Sicherheit der/des in der Anlage oder dem sonstigen industriellem Automatisierungssystem benutzten Arbeitsstation/Server/Regler 220 zu erhöhen. Dieser Sicherheitsmechanismus, der allgemein auf alle Computer oder Maschinen im Steuerungssystem, einschließlich Maschinen, die Prozesse/Applikationen ausführen, die von Dritten entwickelt wurden (sowie auch Prozesse/Applikationen, die von Verkäufern des Steuerungssystems entwickelt wurden) angewendet wird, ist derart aufgebaut, um eine Reihe von Regeln und Funktionen zu implementieren.
Einige der hier beschriebenen Regeln, die von der Konfiguration des Betriebssystems der/des Arbeitsstation/Servers/Reglers 220 erzwungen werden, treffen auf alle Prozesse zu, die erweiterte Rechte, Netzwerkzugriff und Schreibzugriff auf die lokale Festplatte erfordern oder Zugriff auf tragbare oder entfernbare Speichergeräte (z.B. USB-Stick, Smartphones, DVD oder CD-Laufwerke) haben. Diese Prozesse umfassen beispielsweise die Prozesse 262 und 264 von 2. Insbesondere werden diese Prozesse (1) als Dienste ausgeführt oder von Diensten hervorgebracht, (2) werden unter benutzerdefinierten Konten (nicht standardmäßigen) ausgeführt, die zu benutzerdefinierten Gruppen oder Rollen gehören, (3) erhalten Zugriff nur auf Ressourcen, die sie benötigen, (4) ihnen wird ausdrücklich der Zugang zu nicht benötigten Ressourcen verweigert, (5) erhalten nur Rechte, die sie zum Arbeitsablauf benötigen, (6) haben keine Nachahmungsrechte, womit ein Prozess, der unter einem anderen Konto ausgeführt wird, Konten zu diesem benutzerdefinierten Konto ändern kann und (7) haben keine Delegationsrechte, die einem anderen ausgeführten Prozess die Genehmigung geben, unter diesem benutzerdefinierten Konto ausgeführt zu werden. Des Weiteren haben diese Prozesse, falls sie Netzwerkzugriff oder Zugriff auf tragbare oder entfernbare Speichergeräte haben, keine erweiterten Rechte und können auch nicht auf lokale Speicherplatten (z.B. Festplatte) schreiben.
Ebenso kommunizieren diese Prozesse miteinander über zuverlässige Interprozesskommunikationen (z.B. WCF Named Pipes, COM etc.), mit der Ausnahme, dass solchen Prozessen, die Netzwerkzugriff erfordern, direktes Kommunizieren mit Prozessen, die Zugriff auf tragbare oder entfernbare Speichergeräte haben und umgekehrt, nicht gestattet wird. Diese Ausnahme, die in 2 durch die Linie 290 dargestellt wird, ist als Schutz gegen das Weiterleiten von Malware implementiert, die von einem tragbaren Speichergerät in das Kommunikationsnetzwerk eingelesen wurde und gegen das Speichern von vom Kommunikationsnetzwerk auf ein tragbares oder entfernbares Speichergerät empfangene Malware.
Des Weiteren hat keiner der Prozesse 260 (z.B. die Prozesse 262, 264, 266), wie in 2 durch die gestrichelte Linie 291 dargestellt wird, direkten Zugriff auf den Desktopnamensraum 252 oder Objekte im Desktopnamensraum 252. Dies führt dazu, dass diese Prozesse den Desktopapplikationen 258 nur über zuverlässige Interprozesskommunikationen 292 Dienste (und insbesondere erweiterte Dienste) bereitstellen, was durch die zwischen den Diensten 260 und den Desktopapplikationen 258 verlaufenden Linien in 2 dargestellt wird.
Alle Prozesse, die Netzwerkzugriff erfordern oder Zugriff auf ein tragbares oder entfernbares Speichergerät (z.B. die Prozesse 262 und 264 von 2) haben, werden unter einem Konto ausgeführt, das (1) keinen Zugriff für Eingabeanforderungen hat, (2) keinen Zugriff auf Programme hat, die die Sicherheitskonfiguration (Richtlinieneinstellung und Konten) der/des Arbeitsstation/Servers/Reglers 220 ändern können und (3) sie werden daran gehindert, auf das Dateisystem zu schreiben, was durch die gestrichelte Linie 294 in 2 dargestellt wird. Dies führt dazu, dass nur die Dienste 266, die keinen Netzwerkzugriff (z.B. über den Port 245) oder Zugriff auf tragbare oder entfernbare Speichergeräte (z.B. über den Port 239) haben, in der Lage sind, auf die in der Datenbank 235 befindlichen Datendateien 270 zu schreiben.
Es gibt ferner verschiedene Sicherheitsfunktionen, die in der Desktopumgebung 252 implementiert sind. Insbesondere werden alle Desktopapplikationen, die hier auch als interaktive Applikationen/Prozesse bezeichnet werden, ohne erweiterte Rechte ausgeführt und das ungeachtet dessen, welche Benutzerkonten oder angemeldete Konten benutzt werden, um diese Applikationen oder Prozesse zu starten oder aufzurufen. In dem Fall, dass ein Benutzer mit Administratorrechten eine Desktopapplikation startet, wird diese immer noch mit beschränkten Rechten hinsichtlich des Betriebssystems ausgeführt, die gleichbedeutend sind mit denen für einen standardmäßigen Benutzer und dies unabhängig von den Rechten des ausführenden Benutzers. Ferner sind die Desktopapplikationen 258, wie bereits erwähnt, nicht in der Lage, direkt auf das Kommunikationsnetzwerk 230 zuzugreifen und müssen anstatt dessen über eine Interprozesskommunikation mit einem Dienst 262 im Dienstnamensraum 250 kommunizieren, der Zugriff auf das Kommunikationsnetzwerk bereitstellt. Die Desktopapplikationen 258 sind ebenfalls nicht in der Lage, direkt auf die tragbaren Speichergeräte 240, 241 zuzugreifen und müssen daher (über eine Interprozesskommunikation) mit einem Dienst 264 kommunizieren, der Zugriff auf diese Geräte bereitstellt. Des Weiteren sind die Desktopapplikationen 258 nicht berechtigt, auf im Besitz des Systems befindliche Verzeichnisse und Dateien zuzugreifen oder solche, die im infizierten Zustand die Leistung/den Betrieb des Systems beeinträchtigen können. Desktopapplikationen 258 können daher, und wie durch die Linien 296 von 2 dargestellt, auf Desktopordner und -dateien 272 schreiben, jedoch nicht auf Dienstordner und -dateien 270. Außerdem sind die Desktopapplikationen 258 derart konzipiert, dass sie niemals erweiterte Rechte erforderlich machen und ihre Rechte können unabhängig von den Rechten des ausführenden Benutzers nicht erweitert werden. Desktopapplikationen 258 können außerdem niemals einen anderen Benutzer imitieren und müssen über zuverlässige Interprozesskommunikationen miteinander kommunizieren.
Außerdem werden alle Benutzeridentitäten zwischen Diensten und Prozessen 260 und Desktopapplikationen 258 über digital unterzeichnete Identitätsbehauptungen ausgetauscht, und derartige Identitätsbehauptungen folgen oder gehen mit der Kommunikation und durch verschiedene Prozesse und Netzwerkgeräte, damit Genehmigungen des Prozessteuerungssystems verifiziert werden können. Beispielsweise kann der Betreiber eines Prozessteuerungssystems (über eine Desktopapplikation) etwas anfordern, wie etwa einen Parameter (z.B. einen Sollwert) in ein Prozessteuerungsgerät wie einen Regler zu schreiben. Diese Anforderung kann es erforderlich machen, dass während des Sendens dieser Anforderung über ein Kommunikationsnetzwerk an das Prozessteuerungsgerät, das den Schreibbefehl implementieren soll, verschiedene Dienste aufgerufen oder hervorgebracht werden. Die Identitätsbehauptungen des Benutzers fließen zusammen mit der Anforderung durch verschiedene Prozesse, die für die Erstellung und Weiterleitung der Anforderung über verschiedene Maschinen im Netzwerk der Prozesssteuerung benutzt werden, so dass das Prozessteuerungsgerät, das die Änderung implementiert, bestätigen kann, dass die Anforderung von einem Benutzer stammt, der die angemessenen Berechtigungen für die Änderung hat und die Änderung überprüfen und nahe an dem Prozess anlagern, bei dem der Schreibbefehl ausgeführt wird. Diese Funktion stellt sicher, dass eine Person als Benutzer bei der Ausführung eines Arbeitsablaufs ohne Verwendung von Imitation und/oder Delegation exakt und richtig identifiziert wird. Diese Funktion macht es ferner möglich, dass Desktopapplikationen oder ein von einer Desktopapplikation gestarteter Prozess, wie etwa eine Prozesssteuerungsapplikation im Zusammenhang mit einem angemeldeten Benutzer gestartet und dann bei einem Schichtenwechsel weiter betrieben werden kann, ohne dass ein anderer Benutzer einen Neustart durchführen muss, weil Schichtenwechsel nicht erfordern, dass sich ein angemeldeter Benutzer abmelden muss. Der Betreiber einer neuen Schicht identifiziert sich anstatt dessen dem Prozessteuerungssystem, ohne sich dabei beim Betriebssystem anmelden zu müssen. Auf diese Weise werden alle Desktopapplikationen mit den Rechten des angemeldeten Benutzers ausgeführt, sodass es keine Rolle spielt, welcher Betreiber eine Desktopapplikation startet, solange sich die neuen Betreiber bei der Nutzung der Applikation identifizieren, damit die angemessene Identitätsbehauptung zusammen mit der Anforderung des Prozessablaufs laufen kann. Ohne diesen Mechanismus wäre der/die Dienst/Prozess/Applikation darüber hinaus nur in der Lage, den Benutzer mit dem Konto, unter welchem er/sie durchgeführt wird oder von dem er/sie abgerufen wird, zu identifizieren. Diese Funktion ist bei Steuersystemen auch deshalb wichtig, weil der aktuelle Benutzer eines Bedienungsplatzes nicht derselbe Benutzer sein kann, der sich angemeldet hat. Diese Beschränkung entfernt die Gefahr, dass eine gestohlene Benutzeridentität für die Anmeldung bei der Bestimmung von Betriebssystemrechten und Berechtigungen der Zugriffskontrolle bei der Bestimmung von Zugriffsberechtigungen für den Zugriff auf Ressourcen des Steuerungssystems (z.B. Parameter und Alarmsignale) benutzt wird.
Eine Methodik der Implementierung der oben beschriebenen Sicherheitsfunktionen in Bezug auf 2 besteht in einer restriktiveren Methodik bei der Definition der Rechte und Berechtigungen, die verschiedenen Applikationen und Diensten in einem standardmäßigen auf offener Betriebssystemstruktur basierenden Steuerungssystem gewährt werden. Insbesondere heutzutage werden Benutzerrechte und -berechtigungen typischerweise für jeden einzelnen Benutzer definiert, so dass einige Benutzer mehr Rechte und Berechtigungen haben als andere. Bei dieser Architektur werden den Applikationen (z.B. Desktopapplikationen und von ihnen gestartete Prozesse) allgemein die Rechte und Berechtigungen vom angemeldeten Benutzerkonto gewährt, unter welchem diese Applikationen oder Prozesse gestartet oder aufgerufen wurden. Andererseits werden vielen Diensten (z.B. Prozesse, die basierend auf Konfigurationseinstellungen oder als Reaktion auf von Applikationen gemachte Aufrufe oder von Benutzern erteilte Aufforderungen an das Betriebssystem, diese zu starten oder eingehende Nachrichten zu bearbeiten, hervorgebracht werden) die Rechte des Betriebssystemskontos, unter welchem sie zur Ausführung konfiguriert sind, gewährt. Das führt dazu, dass alle Rechte und Berechtigungen oder Dienste von den Konten in diesen Systemen gesteuert werden. Insbesondere werden Desktopapplikationen immer unter dem Konto des angemeldeten Benutzers ausgeführt, wohingegen Dienste und der Prozess immer unter dem Konto ausgeführt werden, das für sie konfiguriert ist, und von anderen Prozessen gestartete Prozesse werden immer mithilfe des Kontos gestartet, unter welchem der diese startende Prozess ausgeführt wird. Es ist daher oft der Fall, dass Dienste unter standardmäßigen Dienstkonten des Betriebssystems oder Benutzerkonten ausgeführt werden.
Im Gegenteil dazu definiert die gesicherte Architektur von 2 Rechte und Berechtigungen für Dienste getrennt von den Rechten und Berechtigungen, die für die angemeldeten Benutzerkonten definiert sind und erlaubt daher nicht, dass Dienste unter Nutzerkonten ausgeführt werden, die das interaktive Anmelderecht besitzen. Dienste werden daher immer unter spezifischen Dienstkonten ausgeführt, die kein interaktives Anmelderecht besitzen. Insbesondere kann die gesicherte Architektur von 2 benutzerdefinierte Dienstkonten definieren, auf die hier Bezug genommen wird und die unterschiedliche oder beschränkte Mengen von Rechten und Berechtigungen aufweisen, und jeder der Dienste 260 von 2 kann einem oder mehreren dieser benutzerdefinierten Dienstkonten zum Zweck der Gewährung der Rechte und Berechtigungen für diese Dienste zugeordnet werden. Jeder Dienst ist einem benutzerdefinierten Dienstkonto zugeordnet, das eine geringste Menge von Berechtigungen aufweist, die der Dienst benötigt. Dienste sollten nicht benutzerdefinierten Dienstkonten zugeordnet werden, die mehr Rechte besitzen als die für den Betrieb der Dienste erforderlichen Rechte. Um jedoch die Vermehrung von benutzerdefinierten Dienstkonten zu reduzieren, kann ein Dienst unter einem benutzerdefinierten Dienstkonto mit mehr als den benötigten Rechten ausgeführt werden, jedoch nur wenn es mit einer beschränkten Dienstmenge konfiguriert ist, die die vom benutzerdefinierten Konto übernommenen Rechte auf diejenigen reduziert, die der Dienst benötigt. In manchen Fällen, wie bei Diensten, die Zugriff auf die Kommunikationsports und die externen Medienports haben, können die Dienste dem Konto mit geringster Menge von Berechtigungen zugeordnet werden und mit einer weiteren Beschränkung, dass diese Dienste nicht auf einen lokalen Datenspeicher (Festplatte) schreiben können. Andererseits werden Desktopapplikationen mit den Rechten des ausführenden Benutzers ausgeführt, sollten aber stets mit beschränkten standardmäßigen Benutzerrechten gestartet werden und nur dann erweitert werden, wenn sie dies benötigen und dann nur mit Genehmigung des Benutzers. Falls der Benutzer die notwendigen Rechte nicht besitzt, sollte das Erfordernis bestehen, dass ein Benutzer mit entsprechenden Rechten diese Erweiterung genehmigt. Auf diese Weise können Dienste und Applikationen eine beschränkte Menge von Rechten haben, die die Fähigkeit von Malware, ein Steuerungssystem zu infizieren, das diese Architektur benutzt, beschränkt.
Allgemein können die benutzerdefinierten Dienstkonten (und die Rechte dieser Konten) definiert werden und dann Diensten zugeordnet werden, die die Rechte der benutzerdefinierten Konten weiter beschränken, so dass die Dienste nur die Rechte oder Berechtigungen erhalten, die sie zur Erfüllung der Aufgaben, für die sie entwickelt wurden, benötigen.
3 zeigt ein Blockdiagramm 300 einer beispielhaften wechselseitigen Beziehung oder Assoziation von Benutzerkonten 306, die Benutzeranmeldungs- und benutzerdefinierte Dienstkonten 310 erlauben, welche Konten für die Konfiguration oder Bereitstellung von Rechten und Berechtigungen des Betriebssystems für Dienste 312 und Desktopapplikationen 314 und andere Prozesse benutzt werden können, die getrennt von den mit dem Prozesssteuerungssystem verbundenen Rechten und Berechtigungen sind, die für angemeldete Benutzerkonten definiert sind.
Wie in 3 gezeigt wird, ist eine Menge von Benutzerkonten 306 definiert und, wie durch die gestrichelte Linie zwischen den Benutzerkonten 306 und den Gruppenkonten 302 verdeutlicht, kann jedes Benutzerkonto 306 zu einem oder mehreren der Gruppenkonten 302 gehören. Auf diese Weise übernimmt jedes Benutzerkonto 306 die Rechte und Berechtigungen des Betriebssystems von jeglichem Gruppenkonto 302, mit dem es assoziiert ist oder zu dem es gehört und gibt diese Rechte/Berechtigungen an Desktopapplikationen weiter, wenn diese von einem assoziierten angemeldeten Benutzer gestartet werden. Wie in 3 auch gezeigt wird, kann ein Benutzerkonto 306 zu mehrfachen Gruppenkonten 302 gehören und daher deren Rechte und Berechtigungen übernehmen, und diese können wiederum zu anderen Gruppenkonten 302 gehören und deren Rechte übernehmen. Es wird ebenfalls und wie auch in 3 gezeigt wird, eine Menge an benutzerdefinierten Dienstkonten 310 etabliert, die alle unterschiedliche Rechte und Berechtigungen des Betriebssystems (einschließlich Zugriffsberechtigungen) haben, um im Betriebssystem Aktionen vorzunehmen, wie etwa Kommunikationsrechte, Lese-/Schreibrechte, Zugriffsrechte etc.. Jedes benutzerdefinierte Dienstkonto 310 kann zu mehrfachen Gruppenkonten 302 gehören und daher deren Rechte und Berechtigungen übernehmen. Jeder von verschiedenen Diensten 312 und den von ihnen in einem Computer gestarteten Prozessen, ist einem (oder möglicherweise mehr als einem) der benutzerdefinierten Dienstkonten 310 zugeordnet und übernimmt die Rechte und Berechtigungen des Betriebssystems für das/die benutzerdefinierte Dienstkonten 310, zu denen diese Dienste 312 gehören. Allgemein werden die für jedes benutzerdefinierte Dienstkonto 310 bereit gestellten Rechte und Berechtigungen des Betriebssystems getrennt von den Benutzerkonten 306 definiert. Insbesondere sollten die Rechte und Berechtigungen der benutzerdefinierten Dienstkonten 310 spezifisch auf Dienste 312 und von ihnen gestartete Prozesse (z.B. abgelöste Prozesse, untergeordnete Prozesse) zugeschnitten (beschränkt) sein und sie sollten nur die für die Dienste 312 und von ihnen gestartete Prozesse benötigten Rechte und Berechtigungen des Betriebssystems erhalten, um die beabsichtigte Funktion durchzuführen, und keine weiteren, außer wenn der Dienst/Prozess derart konfiguriert ist, um ferner die vom benutzerdefinierten Dienstkonto übernommenen Rechte zu beschränken.
Unter Verwendung von Benutzerkonten 306 und benutzerdefinierten Dienstkonten 310, können die Prozesse des Dienstnamensraums 312 (d.h. der Betriebsnamensraum, in dem Dienste und von ihnen gestartete Prozesse ausgeführt werden) und die Prozesse des Desktopnamensraums 314 (d.h. der Betriebsnamensraum, in dem Desktopapplikationen und von ihnen gestartete Prozesse ausgeführt werden) mit unterschiedlichen benutzerdefinierten Konten 310 oder Benutzerkonten 306 assoziiert werden, damit die von einer Desktopapplikation aufgerufenen Dienste mit unterschiedlichen Rechten als jene, die die aufrufende Desktopapplikation besitzt, ausgeführt werden können. Die Terminologie „von einer Desktopapplikation aufgerufen” bezieht sich auf den Empfang einer Aufrufnachricht eines rechnerfernen Vorgangs bei einem Dienst, die von einer Desktopapplikation gesendet wurde.
Es kann ebenfalls und wie auch in 3 gezeigt wird, auf höherer Ebene eine Menge an Gruppenkonten 302 etabliert werden, um eine bestimmte Menge von unterschiedlichen Rechten und Berechtigungen des Betriebssystems (einschließlich Zugriffsberechtigungen) zu definieren. Gruppenkonten können mit keinem, einem oder mehreren benutzerdefinierten Dienstkonten oder Benutzerkonten in einem Computergerät oder in der/dem Prozesssteuerungsanlage oder -system als Ganzes (z.B. unter Verwendung von Active Directory) assoziiert werden. Jedes Gruppenkonto 302 kann eine bestimmte Menge von Rechten und Berechtigungen des Betriebssystems (einschließlich Zugriffsberechtigungen) umfassen, das von anderen Gruppenkonten, benutzerdefinierten Konten und/oder Benutzerkonten übernommen werden kann, die Mitglieder des Gruppenkontos 306 sind. Eine Übernahme wird erreicht, indem diese Konten zu Mitgliedern des Gruppenkontos gemacht werden. Daher können benutzerdefinierte Konten 312 und Benutzerkonten 306 der gleichen Gruppe 302 angehören und damit die gleichen Rechte und Berechtigungen des Betriebssystems übernehmen. Die Gruppenkonten 302 sind daher unterschiedlich zu den Funktionen, die typischerweise in Prozesssteuerungssystemen zur Definition von Rechten und Berechtigungen der Prozesssteuerung (im Gegensatz zu denen des Betriebssystems) verwendet werden. Prozesssteuerungsfunktionen (im Gegensatz zu Gruppen des Betriebssystems) umfassen meistens Gruppen von Individuen (Betreiber, Konfigurationsingenieure, Techniker etc.), die für bestimmte Bereiche oder Funktionen der Anlage verantwortlich sind. Während diese unterschiedlichen Funktionen unterschiedliche Rechte und Berechtigungen der Prozesssteuerung für diese Personen definieren können, führen die Personen, denen unterschiedliche Funktionen aufgetragen werden, diese meistens unter dem gleichen angemeldeten Benutzerkonto aus und besitzen die gleiche Menge von Rechten und Berechtigungen des Betriebssystems, aber unterschiedliche Rechte und Berechtigungen der Prozesssteuerung. Jedenfalls geht man davon aus, dass die Gruppenkonten 302 Rechte und Berechtigungen des Betriebssystems definieren, die von benutzerdefinierten Dienstkonten 312 übernommen werden können, die zur Ausführung der Prozesse des Dienstnamensraums und/oder der Benutzerkonten 306 und der Prozesse des Desktopnamensraums, die vom angemeldeten Benutzer gestartet werden, verwendet werden.
Daher verdeutlicht 3 eine Gruppierung verschiedener Dienste 312 und Applikationen 314 unter verschiedenen Konten 302, 306 und 310, die für die Zuordnung von Berechtigungen der Prozesssteuerung für die Dienste und Applikationen verwendet werden. Die in 3 gezeigten benutzerdefinierten Dienstkonten 310 werden nur für Dienstprozesse 312 und andere Prozesse im Dienstnamensraum verwendet und die Benutzerkonten 306 nur für Prozesse (z.B. Applikationen 314) im Desktopnamensraum. Im Allgemeinen starten alle Prozesse (z.B. Desktopapplikationen 314) im Desktopnamensraum mit den Rechten des „standardmäßigen Benutzerkontos“ 306A (das Konto mit geringsten Rechten), das keine Administratorrechte besitzt. Die benutzerdefinierten Konten 310 sind darüber hinaus nur mit den zusätzlichen Rechten definiert, die sie benötigen. Wie jedoch in 3 gezeigt, kann mehr als ein Dienst 312 unter dem gleichen benutzerdefinierten Dienstkonto 310 ausgeführt werden und manche der Rechte können ihm individuell verweigert werden, falls der Dienst 312 nicht alle Rechte des benutzerdefinierten Dienstkontos benötigt. Für Dienste, die Zugriff auf einen Kommunikationsport und oder externen Medienport (z.B. USB-Port) haben, werden diese jedoch unter einem benutzerdefinierten Benutzerkonto ohne erweiterte Rechte (z.B. Administratorrechte) ausgeführt und mit einer weiteren Beschränkung, dass diese Dienste nicht auf einen lokalen Datenspeicher (intern) oder eine Festplatte schreiben können. Unter lokalen und internen Datenspeichern versteht man vorliegend Datenspeicher, die auf eine relativ permanente Weise mit einem Computergerät verbunden sind und die nicht dazu bestimmt sind, von tragbarer oder schnell entfernbarer Art zu sein und daher nicht mit einem externen Medienzugriffsport verbunden sind. Lokale und interne Datenspeicher umfassen allgemein interne Festplatten oder interne Arbeitsspeicher (RAM).
Aus der obigen Erörterung geht hervor, das Betriebssystemrechte einschließlich Zugriffsberechtigungen einem Prozess (z.B. einem Dienst oder einer Desktopapplikation) gewährt werden und zwar vollkommen unabhängig von den Zugriffsteuerungen, die einen Benutzerzugriff auf Objekte des Prozesssteuerungssystems (z.B. Setpoints, Temperatur- und Druckmessungen sowie Alarmgrenzen) erlauben/verweigern. Zugriff auf Objekte des Prozesssteuerungssystems erfordert eine getrennte Benutzeridentität, die mit Anforderungen zu übertragen ist, damit Prozesssteuerungsgeräte Berechtigungen der Prozesssteuerung verifizieren können, weil das Betriebssystem, das Zugriffsberechtigungen und Betriebssystemrechte durchsetzt, keine Kenntnisse über Objekte des Prozesssteuerungssystems hat. Bekanntlich weisen Betriebssysteme allgemein eine separate Benutzerverwaltung (User Manager) auf, die definiert, auf was jeder Benutzer des Betriebssystems im Steuerungssystem zugreifen kann und die Benutzeridentitätsbehauptungen werden bereitgestellt, damit diese separate Benutzerverwaltung ordnungsgemäß betrieben wird.
Jedenfalls stehen bei Anwendung dieser Architektur die Rechte und Berechtigungen, die ein Benutzer für den Zugriff auf Prozesssteuerungsobjekte besitzt, um Aktionen innerhalb der Anlage durchzuführen etc. in keinem Bezug mit den Rechten und Berechtigungen der Dienste und Applikationen, die unter benutzerdefinierten Dienstkonten oder angemeldeten Benutzerkonten ausgeführt werden. Diese Funktion vermindert oder eliminiert die Fähigkeit eines infizierten Prozesses, die von einem benutzerdefinierten Dienstkonto oder von dem Benutzerkonto, unter dem der infizierte Prozess ausgeführt ist, übernommenen Rechte und Berechtigungen des Betriebssystems zu nutzen, um Zugriff auf Prozesssteuerungsobjekte zu haben oder deren Ausführung zu stören.
Wie weiter in 3 gezeigt wird, gewährt die Ausführungsmaschine 320 (z.B. die Ausführungsmaschine des Betriebssystems) des Computers, auf dem ein Prozess (z.B. ein Dienst oder eine Applikation oder von einem Dienst oder einer Applikation gestarteter Prozess) ausgeführt werden soll, Rechte für Dienste 312 oder Applikationen 314 oder von ihnen gestartete Prozesse gemäß den folgenden Regeln. Direkt vom angemeldeten Benutzer gestartete Prozesse erhalten eine standardmäßige Menge von mit dem standardmäßigen Benutzerkonto assoziierten Rechten und Berechtigungen, auch wenn der Benutzer erweiterte Rechte (d.h. Administratorrechte) besitzt. Vom Betriebssystem gestartete Dienste erhalten die Rechte und Berechtigungen des benutzerdefinierten Dienstkontos, zu dem sie gehören, die durch für den Dienst konfigurierte Beschränkungen reduziert wurden. Von einem Prozess gestartete Prozesse erhalten die aktuelle Menge an Rechten und Berechtigungen des startenden Prozesses. Mit dieser Organisation kann jeder Prozess (z.B. jede/r Dienst 312 oder Applikation 314 oder dadurch gestartete Prozess) mit der geringsten Menge von Rechten ausgeführt werden, die nötig sind, um die spezifische Funktionalität des Prozesses durchzuführen zu können. Diese Funktionalität beschränkt daher die Fähigkeit von Malware, die eine/n Dienst 312 oder Applikation 314 oder dadurch gestarteten Prozess infiziert hat, Aktionen durchführen zu können (z.B. Rechte und Berechtigungen des Betriebssystems zu erhalten), die der Dienst 312 oder die Applikation 314 für den normalen Betrieb nicht benötigt, was wiederum die Fähigkeit der Malware beschränkt, im Computer betrieben zu werden und sich über das Kommunikationsnetzwerk des Prozesssteuerungssystems auf andere Prozesssteuerungsgeräte oder andere Computer zu verbreiten. Ferner kann die Ausführungsmaschine 320 eine Erweiterung der Rechte für Desktopapplikationen 314 oder Dienste 312 verbieten oder verhindern, um Malware daran zu hindern, diese Konstruktion der Betriebssystemrechte vernichten zu können.
4 zeigt ein schematisches Diagramm eines Computersystems 400, das die hier beschriebenen Regeln und Konfigurationsfunktionen für die Erhöhung der Sicherheit eines Computergeräts oder Anlagenetzwerks implementieren kann, um die Verbreitung oder wahrscheinliche Infizierung durch Malware zu verhindern. Insbesondere, wie in 4 gezeigt, ist das Diagramm des Computers 400 in ein Hardwaresystem 402, das verschiedene Hardwarekomponenten (unterhalb einer durchgezogenen Linie 403) aufweist und ein Softwaresystem 404, das verschiedene Software-/Firmwarekomponenten (oberhalb der durchgezogenen Linie 403) aufweist, unterteilt. Es versteht sich, dass die Software/Firmwarekomponenten des Softwaresystems 404 in einem oder mehreren Computerprozessoren und Speichergeräten (nicht in 4 gezeigt) implementiert sind, die mit dem Computer oder Gerät 400 assoziiert sind.
Wie weiter in 4 gezeigt wird, kann das Hardwaresystem 402 ein oder mehrere Speichergeräte 405, wie Datenbanken, interne lokale Speicher, Festplatten, USB-Sticks, RAM, ROM etc. umfassen. Speichergeräte 405 können lokale Datenspeicher 235 und die Dateien 270 und 272 von 2 umfassen. Das Hardwaresystem 402 kann auch eine oder mehrere Netzwerkkarten oder Ports 406 umfassen, die das Softwaresystem 404 über Netzwerkports mit einem oder mehreren externen Kommunikationsnetzwerken verbinden können, wie etwa der Netzwerkport 245 von 2. Das Hardwaresystem 402 kann gleichermaßen ein oder mehrere Peripheriegeräte 407, wie eine Benutzerschnittstelle (z.B. die Benutzerschnittstelle 237 von 2), Drucker, Tastaturen, Mäuse, externe Speichergeräte (beispielsweise mit einem externen Speicherport 239 von 2 verbunden) etc. umfassen. Natürlich kann sich jedes/r andere Peripheriegerät oder Geräteport oder Verbindung in dem Hardwaresystem 402 befinden, das/der/die an Stelle oder zusätzlich zu den hier spezifisch beschriebenen sein können. Ferner kann das Hardwaresystem 402 einen oder mehrere Prozessoren 408 umfassen, auf welchen das Betriebssystem und die hier beschriebenen Prozesse ausgeführt werden.
Wie in 4 gezeigt wird, umfasst das Softwaresystem 404 eine Betriebssystemkomponente 410, Dienste oder andere Prozesse 414 und eine Menge von Konfigurationsinformationen oder -daten 416 (z.B. eine Windows-Registrierungsdatenbank etc.), die für die Konfiguration des Betriebs des Softwaresystems 404 in hier beschriebener Weise verwendet werden können. Bei diesem Fall sind Dienstprozesse 414, hier einfach Dienste 414 genannt, Prozesse, die unabhängig von angemeldeten Benutzern ausgeführt werden, und allgemein als Reaktion auf an die Betriebssystemkomponente 410 gesendete Anfragen, die von der Betriebssystemkomponente 410 an einen Dienstprozess 414 weitergeleitet werden, ausgeführt werden. Das bedeutet, dass die Dienste 414 allgemein vom Betriebssystem 410 oder einem Agenten des Betriebssystems 410 (z.B. die Windows-Dienststeuerung) hervorgebracht oder ausgeführt werden. Obwohl diese Prozesse typischerweise automatisch gestartet werden, können sie auch als Reaktion auf eine von einer Desktopapplikation gesendeten Anfrage gestartet werden. In beiden Fällen und wie oben ausgeführt, werden diese Dienste jedoch immer unter einem bestimmten benutzerdefinierten Dienstkonto ausgeführt, unabhängig davon, welcher Prozess die Dienste gestartet hat. Zusätzlich umfasst das Softwaresystem 404 von 4 verschiedene Desktopapplikationen 420. Man geht davon aus, dass die Applikationen typischerweise von verschiedenen angemeldeten Benutzer gestartet werden und unter diesen Benutzerkonten 425 (durch die gestrichelten Linien in 4 dargestellt) ausgeführt werden. Daher werden Applikationen im Gegensatz zu Diensten, die immer unter dem gleichen benutzerdefinierten Dienstkonto ausgeführt werden, unter unterschiedlichen Benutzerkonten (das aktuelle angemeldete Benutzerkonto) ausgeführt, wie oben erörtert wird. Die Applikationen 420 können natürlich die Desktopapplikationen 258 von 2 sein und die Benutzerkonten 425 können unterschiedliche Rechte und Berechtigungen haben, als das sonst der Fall ist oder die gleichen Rechte und Berechtigungen des Betriebssystems haben, wie die für einen standardmäßigen Benutzer definierten, die allgemein die geringste Menge an Rechten und Berechtigungen des Betriebssystems besitzen. Insbesondere können die Konfigurationsinformationen 416 Registrierungen und andere Konfigurationsinformationen umfassen, die die Konfiguration der Betriebssystemkomponente 410 definieren, um in oben beschriebener Weise betrieben zu werden, oder die oben beschriebene Rechte in Bezug auf 2 zu implementieren. Bei diesem Fall können die Konfigurationsinformationen 416 Konteninformationen definieren, die Rechte enthalten, Zugriffsteuerungslisten definieren, die ein Konto mit einer Betriebssystemressource assoziieren und Zugriffsberechtigungen für das Konto sowie Informationen definieren, mit denen übertragene Kontenrechte bei Laufzeit verringert werden. Beim letzteren Fall wird der Dienst/die Applikation mit der Menge von Kontenrechten ausgeführt, die reduziert wurden, wie es die Konfigurationsinformationen spezifiziert haben. Jedenfalls fügt diese Art von Konfigurationsinformationen den vom Konto übertragenen Rechten keine Rechte hinzu, sie reduziert vielmehr die Rechte. Die Konfigurationsinformationen können als Teil von Konfigurationsaktivitäten geschaffenen und/oder bereitgestellten sein, die vom Lieferanten des Steuerungssystems oder vom Konfigurationsingenieur bereitgestellt wurden, so dass die Konfigurationsinformationen bereits eingestellt sind, um zu spezifizieren, welche Rechte des Betriebssystems mit jedem der Dienste 414 und Applikationen 420 über Benutzerkonten, Gruppenkonten und benutzerdefinierten Dienstkonten assoziiert oder ihnen bereitgestellt werden (z.B. von ihnen benötigt werden). Ebenso können bestimmte Benutzer, wie etwa Administratoren, die Konfigurationsinformationen 416 ändern, um neue Konten hinzuzufügen, neue Rechte zu definieren etc. Außerdem können ähnliche Konfigurationsinformationen für die Desktopapplikationen geschaffen und von einem Konfigurationsingenieur während dem Konfigurationsprozess bereitgestellt werden oder von dem Lieferanten der Applikation (z.B. dritte Lieferanten der Desktopapplikation) stammen, oder können automatisch oder durch einen Administrator auf ein niedrigstes Niveau von Rechten eingestellt sein.
Wie in 4 gezeigt, nutzt die Betriebssystemkomponente 410 die Konfigurationsinformationen 416, um die Betriebssystemrechte und daher auch die Berechtigungen und Funktionsweisen von verschiedenen Applikationen 420 (die über APIs 412 oder direkt mit der Betriebssystemkomponente 410 kommunizieren können) und die Dienste 414 zu steuern, um die oben beschriebenen auf geringsten Rechten basierenden Sicherheitsfunktionen durchzusetzen. Daher verwendet die Betriebssystemkomponente 410 die Konfigurationsinformationen (allgemein werden die Kontenverwaltungsinformationen in einer Datenbank oder Datei gespeichert, wie etwa ein Active-Directory-Verzeichnis, eine Workgroup-Konfigurationsdatei, eine .exe-spezifische Konfigurationsdatei etc.) und die partitionierten Namensräume, um die Anforderung durchzusetzen, dass die Applikationen 420 miteinander nur über IPCs (mit Linie 430 von 4 angedeutet) kommunizieren, dass die Applikationen 420 nur über IPCs (mit Linie 431 von 4 angedeutet) mit den Diensten 414 kommunizieren und die Dienste 414 mit anderen Diensten 414 nur über IPCs (mit Linie 432 von 4 angedeutet) kommunizieren. Ebenso kann die Betriebssystemkomponente 410 (oder die Ausführung der Applikationen/Dienste auf die hier beschriebenen Weise) die Konfigurationsinformationen 416 dahingehend verwenden, um zu verhindern, dass bestimmte Dienst mit anderen Diensten kommunizieren (z.B. ein Dienst mit Netzwerkzugriff mit einem Dienst kommuniziert, der Zugriff auf externe Medien hat), um zu verhindern, dass die Applikationen 420 auf interne Speichergeräte (z.B. Dateien 270 von 2) gespeicherte Dienstdateien und -ordner schreiben oder dass Dienste auf Desktopordner (z.B. Dateien 272 von 2) schreiben oder auf den Desktop auf andere Weise zugreifen und um zu verhindern, dass Dienste mit Netzwerkzugriff oder Zugriff auf externe Medien auf Dienstdateien und -ordner (z.B. Dateien 270 von 2) schreiben. Dabei versteht sich, dass die Betriebssystemkomponente 410 diese Regeln auf eine Weise durchsetzt, bei der die Rechte und Berechtigungen des Betriebssystems für verschiedene Konten und die damit assoziierten Dienste und Applikationen in den Konfigurationsdateien des Konfigurationsmoduls 416 auf strikteste Weise steuert.
Es versteht sich, dass das Ziel dieser gesamten in den 2–4 illustrierten Konzipierung ist, die Dienste und Desktopapplikationen, die in den Arbeitsstationen des Systems für Prozesssteuerung und Automatisierung und in den Servern oder anderen Computergeräten von beispielsweise einem Prozesssteuerungsnetzwerk ausgeführt werden, zu partitionieren (isolieren), um damit eine Infizierung zu isolieren und zu verhindern, dass sie fortbesteht, so dass die Infizierung beim Neustart verschwindet, ihre Fähigkeit, sich zu verbreiten verringert wird, die von der Infizierung eingeführten Schäden zu verringern, indem nicht erlaubt wird, dass die Infizierung erweiterte Rechte erhält und durch Beschränken der Rechte der Dienste der Kommunikationsschnittstellen und externen Prozesse oder Prozesse von Benutzern von externen Medienports zu beschränken. Falls ein Dienst oder ein von einem Dienst hervorgebrachter Prozess infiziert wird, (1) erhält der infizierte Dienst oder Prozess gemäß den Regeln keine erweiterten Rechte, weil der Dienst oder Prozess unter beschränkten Rechten ausgeführt wird, (2) erhält der infizierte Dienst oder Prozess keine Berechtigungen, auf Ressourcen zuzugreifen, die er nicht direkt benötigt und (3) kann der infizierte Dienst oder Prozess durch Neustarts nicht fortbestehen. Insbesondere erhalten die Dienste, die Zugriff auf das Kommunikationsnetzwerk und externen Medienports (z.B. USB-Port) haben, Beschränkungen dahingehend, was sie tun können, und weil diese Dienste die einzigen Zugänge darstellen, durch welche Infizierungen auf eine Maschine gelangen können, betreffen diese Beschränkungen, was sie tun können (z.B. verhindern, dass diese Dienste auf lokale Speicher und Festplatten schreiben, erweiterte Rechte ausführen können, auf das Desktop direkt zugreifen, Infizierungen zwischen tragbaren oder externen Medien und Kommunikationsnetzwerke/Datenlinks verbreiten können etc.) und falls sie infiziert sind, wird verhindert, dass die Infizierung sich innerhalb des Computergeräts oder Netzwerks ausbreitet. Folglich wird die Infizierung automatisch unter Quarantäne gestellt und bei Neustart der Dienste wird die Infizierung gelöscht. Bei Diensten, die nur bei Zugriff auf diese (z.B. COM/DCOM-Diensten) ausgeführt werden, erhält der aufrufende Prozess eine reine Kopie des Dienstes bei jedem neuen Aufruf, wodurch die Infizierung im Dienst gelöscht wird.
Ebenso ist ein Desktopapplikation, falls sie infiziert wird, gemäß diesen Regeln nicht in der Lage, auf privilegierte Funktionen des Betriebssystems direkt zuzugreifen und auch nicht auf ein Netzwerk oder tragbares Speichergerät zu schreiben. Die Desktopapplikation müssen vielmehr (über IPCs) Aktionen anfordern, die für sie von Diensten und von ihnen hervorgebrachten Prozessen durchgeführt werden, die derart konzipiert sind, um eine zusätzliche Ebene der Zugriffssteuerung auf privilegierte Funktionen und Ressourcen zu bieten und zu bestätigen.
Das führt dazu, dass einige wichtige Vorteile der Architektur einen Schutz vor Prozessen mit Zugriff auf ein Netzwerk oder tragbares Speichergerät umfassen und falls diese Prozesse mit Malware infiziert werden, wird verhindert, dass sie Administratorrechte benutzen, um das System anzugreifen, dass sie Zugriff auf Ressourcen erhalten, die allgemein genutzten/standardmäßigen Konten verfügbar sind, dass sie auf Dateisysteme schreiben und Malware von einem tragbaren Speichergerät auf ein Netzwerk verbreiten und umgekehrt. Diese Architektur bietet einen Schutz dagegen, dass eine Desktopapplikation direkt Zugriff auf zuverlässige oder beschränkte Ressourcen erhält (z.B. lokale Dateien) oder erweiterte Rechte benutzt, und dadurch wird das System weniger anfällig für Malware, falls die Desktopapplikation mit Malware infiziert wird. Mit dieser Architektur können Prozesse des Steuerungssystems darüber hinaus unter Betriebssystemkonten ausgeführt werden, die nur die Rechte und Berechtigungen des Betriebssystems oder Dateisystems aufweisen, die sie benötigen während ihnen der Zugriff auf Ressourcen des Steuerungssystems mit Hilfe von Benutzeridentitätsbehauptungen gestattet wird.
Obwohl die Sicherheitstechniken hier in Verbindung mit auf Netzwerk basierenden Prozesssteuerungsgeräten und -systemen unter Verwendung von Feldbus und standardmäßigen 4–20 mA-Geräten beschrieben wird, kann sie auch mit jeglicher Art von Steuerungsgerät unter Verwendung von jeglichem/r Kommunikationsprotokoll oder Programmierumgebung der Prozesssteuerung oder mit anderer Art von Geräten, Funktionsblöcken oder Reglern implementiert werden. Weiter können die hier beschriebenen Sicherheitstechniken auf jeglicher Art von Computergerät, einschließlich Computergeräten, die keinen Teil eines Prozesssteuerungssystems darstellen, implementiert werden. Obwohl die Funktionen der hier beschriebenen Sicherheitsarchitekturen vorzugsweise in einer Software implementiert werden, können sie auch in Hardware, Firmware etc. implementiert werden und können von jeglichem anderen mit einem Computergerät assoziierten Prozessor ausgeführt werden. Die hier beschriebenen Verfahren können daher in einem standardmäßigen Mehrzweck-Hauptprozessor oder, falls gewünscht, in speziell entwickelter Hardware oder Firmware wie etwa ASICs implementiert werden. Falls sie in Software implementiert werden, kann die Software auf jedem computerlesbaren Speicher wie etwa Magnetplatten, Laserplatten, Bildplatten oder auf ein anderes Speichermedium, in ein RAM oder ROM eines Computers oder Prozessors etc. gespeichert werden. Ebenso kann diese Software an einen Benutzer oder an ein Prozesssteuerungssystem über jegliches bekannte oder gewünschte Übertragungsverfahren, beispielsweise auf einer computerlesbaren Diskette oder auf einem anderen transportierbaren Speichermechanismus, geliefert werden oder über einen Kommunikationskanal wie etwa ein Telefonnetz, das Internet etc. moduliert werden.
Obwohl die vorliegende Erfindung mit Bezugnahme auf spezifische Beispiele erörtert wurde, die nur zur Veranschaulichung dienen und die Erfindung keinesfalls beschränken sollen, wird der Fachwelt offensichtlich, dass Veränderungen, Zusätze oder Eliminierungen bei den offenbarten Ausführungsformen durchgeführt werden können, ohne dabei vom Schutzumfang oder Geist der Erfindung abzuweichen.

Claims

Computergerät, umfassend einen Prozessor und ein Betriebssystem, das auf dem Prozessor gemäß Konfigurationsdaten ausgeführt wird, um Dienstprozesse zu implementieren, wobei die Konfigurationsdaten veranlassen, dass jeder der Dienstprozesse zu einem aus einer Vielzahl von benutzerdefinierten Dienstkonten zugeordnet wird, wobei jedes eine vorbestimmte Menge von damit assoziierten Betriebssystemrechten hat, wobei die vorbestimmte Menge von Betriebssystemrechten für jede der Vielzahl von Dienstkonten basierend auf Rechten definiert ist, die die Dienste, die mit dem benutzerdefinierten Dienstkonto assoziiert sind, benötigen und wobei benutzerdefinierte Dienstkonten keine interaktiven Anmelderechte aufweisen.
Computergerät nach Anspruch 1, wobei das Computergerät weiter einen oder mehrere Kommunikationsports und eine lokale Speichereinheit umfasst und wobei jeder der Dienstprozesse, die mit einem Kommunikationsport kommunizieren können, kein Recht hat, auf die lokale Speichereinheit zu schreiben.
Computergerät nach einem der vorhergehenden Ansprüche, insbesondere nach Anspruch 2, wobei das Computergerät weiter einen externen Medienport umfasst und wobei ein oder mehrere Dienstprozesse, die mit einem Kommunikationsport kommunizieren können, kein Recht haben, über einen externen Medienport mit einer entfernbaren Speichereinheit zu kommunizieren; und/oder wobei das Computergerät weiter einen externen Medienport umfasst und wobei ein oder mehrere Dienstprozesse, die mit einem Kommunikationsport kommunizieren können, kein Recht haben, direkt mit einem weiteren Dienstprozess zu kommunizieren, der ein Recht hat, über einen externen Medienport mit der entfernbaren Speichereinheit zu kommunizieren.
Computergerät nach einem der vorhergehenden Ansprüche, insbesondere nach Anspruch 3, wobei das Computergerät weiter einen externen Medienport und eine lokale Speichereinheit umfasst und wobei einer der Dienstprozesse, der über einen externen Medienport mit einer entfernbaren Speichereinheit kommunizieren kann, kein Recht hat, auf die lokale Speichereinheit zu schreiben.
Computergerät nach einem der vorhergehenden Ansprüche, insbesondere nach Anspruch 4, wobei das Computergerät weiter einen Kommunikationsport umfasst und wobei ein oder mehrere Dienstprozesse, die über einen externen Medienport mit einer entfernbaren Speichereinheit kommunizieren können, kein Recht haben, direkt mit einem weiteren Dienstprozess zu kommunizieren, der ein Recht hat, über den Kommunikationsport zu kommunizieren.
Computergerät nach einem der vorhergehenden Ansprüche, insbesondere nach Anspruch 1, weiter eine Desktopumgebung umfassend und wobei das Betriebssystem die Durchsetzung eines Dienstnamensraums ausführt, der separat von einem Desktopnamensraum ist und die Ausführung der Dienstprozesse in dem Dienstnamensraum und einer oder mehrerer Desktopapplikationen im Desktopnamensraum betreibt.
Computergerät nach einem der vorhergehenden Ansprüche, insbesondere nach Anspruch 6, wobei das Betriebssystem auf dem Prozessor gemäß Konfigurationsdaten ausgeführt wird, um Konfigurationsdaten zur Implementierung von Desktopprozessen zu implementieren, wobei die Konfigurationsdaten veranlassen, dass jeder der Desktopprozesse mit einem aus einer Vielzahl von Benutzerkonten assoziiert wird, die alle eine vorbestimmte Menge von mit ihnen assoziierten Betriebssystemrechten aufweisen, wobei die vorbestimmte Menge von Betriebssystemrechten für jede der Vielzahl von Benutzerkonten interaktive Anmelderechte umfasst.
Computergerät nach einem der vorhergehenden Ansprüche, insbesondere nach Anspruch 7, wobei die mit den standardmäßigen Benutzerkonten assoziierte Menge von Betriebssystemrechten keine erhöhten Betriebssystemrechte oder Administratorrechte umfasst; und/oder wobei die mit den Desktopapplikationen zugeordnete Menge von Betriebssystemrechten bei Start zu standardmäßigen Benutzerrechten beschränkt werden, auch wenn das Benutzerkonto, auf dem die Desktopapplikation gestartet wurde, erhöhte Betriebssystemrechte hat und wobei Prozesse, die von im Desktopnamensraum ausgeführten Prozessen gestartet wurden, die Rechte des startenden Prozesses übernehmen; und/oder wobei das Betriebssystem eine Regel durchsetzt, dass im Desktopnamensraum ausgeführte Prozesse nur mit ausdrücklicher Berechtigung eines genehmigten Benutzers, dessen Konto erweiterte Rechte hat, auf Betriebssystemrechte erhöht werden können.
Computergerät nach einem der vorhergehenden Ansprüche, insbesondere nach Anspruch 6, wobei das Betriebssystem eine Anforderung durchsetzt, dass alle im Dienstnamensraum ausgeführten Prozesse über Interprozesskommunikationen mit anderen im Dienstnamensraum ausgeführten Prozesse kommunizieren müssen; und/oder wobei das Computergerät weiter eine lokale Speichereinheit umfasst, die Dienstdateien oder Dienstordner speichert und wobei das Betriebssystem eine Regel durchsetzt, die verhindert, dass im Desktopnamensraum ausgeführte Prozesse auf Dienstdateien oder Dienstordner schreiben, die in der lokalen Speichereinheit gespeichert sind; und/oder ein Computergerät weiter einen Desktop mit einer Benutzerschnittstelle im Desktopnamensraum umfassend und wobei das Betriebssystem eine Regel durchsetzt, die verhindert, dass einer der Dienstprozesse direkt auf diesen Desktop zugreifen kann; und/oder wobei von Desktopapplikationen stammende Nachrichten Informationen der Benutzeridentität umfassen, die einen Benutzer einer Desktopapplikation identifizieren und wobei die Informationen der Benutzeridentität den Nachrichten durch mehrfache Prozesse einschließlich eines Dienstprozesses, der auf den Kommunikationsport zugreift, um über den Kommunikationslink eine Nachricht zu senden, bis zum endgültigen Bestimmungsort folgen.
Computer nach einem der vorhergehenden Ansprüche, insbesondere nach Anspruch 9, wobei die Informationen der Benutzeridentität die Betriebssystemrechte und/oder Zugriffsberechtigungen, die mit einem oder mehreren zur Weiterleitung der Nachrichten an einen Empfänger benutzten Prozessen assoziiert werden, nicht steuern und wobei die Informationen der Benutzeridentität die Zugriffsberechtigungen auf Prozesssteuerungsobjekte steuern.
Computergerät umfassend: einen Prozessor; einen Kommunikationsport; eine lokale Speichereinheit und ein Betriebssystem, das auf dem Prozessor gemäß Konfigurationsdaten ausgeführt wird, um Dienstprozesse zu implementieren, einschließlich eines Dienstprozesses, der mit dem Kommunikationsport kommunizieren kann, wobei der Dienstprozess, der mit dem Kommunikationsport kommunizieren kann, kein Recht hat, auf die lokale Speichereinheit zu schreiben.
Computergerät nach Anspruch 11, wobei das Computergerät weiter einen externen Medienport umfasst und wobei der eine der Dienstprozesse, der mit einem Kommunikationsport kommunizieren kann, kein Recht hat, über den externen Medienport mit einer entfernbaren Speichereinheit zu kommunizieren.
Computergerät nach einem der Ansprüche 11 oder 12, insbesondere nach Anspruch 11, wobei das Computergerät weiter einen externen Medienport umfasst und wobei der eine der Dienstprozesse, der mit einem Kommunikationsport kommunizieren kann, kein Recht hat, direkt mit einem weiteren Dienstprozess zu kommunizieren, der Rechte hat, über den externen Medienport mit einer entfernbaren Speichereinheit zu kommunizieren.
Computergerät nach einem der Ansprüche 11 bis 13, insbesondere nach Anspruch 13, wobei der weitere Dienstprozess, der über einen externen Medienport mit einer entfernbaren Speichereinheit kommunizieren kann, keine Rechte hat, auf die lokale Speichereinheit zu schreiben.
Computergerät nach einem der Ansprüche 11 bis 14, 43, insbesondere nach Anspruch 43, wobei das Betriebssystem eine Regel durchsetzt, die verhindert, dass die Desktopapplikationen auf Dienstdateien oder Dienstordner schreiben, die in einer lokalen Speichereinheit gespeichert sind.
Computergerät nach einem der Ansprüche 11 bis 15, 27, insbesondere nach Anspruch 27, wobei eine von einer Desktopapplikation stammende Nachricht Informationen der Benutzeridentität umfasst, die einen Benutzer der Desktopapplikation identifizieren und wobei die Informationen der Benutzeridentität der Nachricht durch den Dienstprozess, der auf den Kommunikationsport zugreift, um die Nachricht über den Kommunikationslink zu senden, folgen.
Computergerät nach einem der Ansprüche 11 bis 16, insbesondere nach Anspruch 11, weiter einen Desktop mit einer Benutzerschnittstelle umfassend und wobei das Betriebssystem eine Regel durchsetzt, die verhindert, dass einer der Dienstprozesse direkt auf den Desktop zugreifen kann.
Computergerät umfassend: einen Prozessor; einen externen Medienport; eine lokale Speichereinheit und ein Betriebssystem, das auf dem Prozessor gemäß Konfigurationsdaten ausgeführt wird, um Dienstprozesse zu implementieren, einschließlich eines Dienstprozesses, der über den externen Medienport mit einer entfernbaren Speichereinheit kommunizieren kann, wobei der Dienstprozess, der über den externen Medienport mit einer entfernbaren Speichereinheit kommunizieren kann, kein Recht hat auf die lokale Speichereinheit zu schreiben.
Computergerät nach einem der Ansprüche 11 und 18, wobei die lokale Speichereinheit Dateien oder Ordner von Dienstprozessen speichert.
Computergerät nach einem der Ansprüche 11, 18 bis 19, insbesondere nach Anspruch 11 und 19, wobei die lokale Speichereinheit weiter Dateien von Desktopapplikationen speichert.
Computergerät nach einem der Ansprüche 18 bis 20, insbesondere nach Anspruch 18, wobei das Computergerät weiter einen Kommunikationsport umfasst und wobei der eine der Dienstprozesse, der über den externen Medienport mit einem entfernbaren Speicher kommunizieren kann, kein Recht hat, direkt mit einem weiteren Dienstprozess zu kommunizieren, der Rechte hat, über den Kommunikationsport zu kommunizieren.
Computergerät nach einem der Ansprüche 1 bis 6, 11 bis 14, 27, 18 bis 21, insbesondere nach Anspruch 26 und 27, wobei das Betriebssystem eine Anforderung durchsetzt, dass die im Desktopnamensraum ausgeführten Prozesse über Interprozesskommunikationen mit im Dienstnamensraum ausgeführten Prozessen kommunizieren müssen.
Computergerät nach einem der Ansprüche 11 bis 14, 18 bis 22, insbesondere nach Anspruch 22, wobei Desktopapplikationen einer Menge von Betriebssystemrechten zugeordnet werden, die separat von einer Menge von einem Benutzerkonto zugeordneten Betriebssystemrechten gehalten wird, das die Desktopapplikationen startet und wobei die Menge von Betriebssystemrechten, die mit den Desktopapplikationen assoziiert sind, keine Administratorrechte des Betriebssystems umfassen.
Computergerät nach einem der Ansprüche 18 bis 23, insbesondere nach Anspruch 18, weiter einen Desktop mit einer Benutzerschnittstelle umfassend und wobei das Betriebssystem eine Regel durchsetzt, die verhindert, dass einer der Dienstprozesse direkt auf den Desktop zugreifen kann.
Computergerät umfassend: einen Prozessor; einen externen Medienport; einen Kommunikationsport und ein Betriebssystem, das auf dem Prozessor gemäß Konfigurationsdaten ausgeführt wird, um Dienstprozesse zu implementieren, einschließlich eines Dienstprozesses, der über einen externen Medienport mit einer entfernbaren Speichereinheit kommunizieren kann, wobei der Dienstprozess, der über den externen Medienport mit einer entfernbaren Speichereinheit kommunizieren kann, kein Recht hat, auf den Kommunikationsport zuzugreifen.
Computergerät nach Anspruch 25, wobei der Dienstprozess, der über den externen Medienport mit einer entfernbaren Speichereinheit kommunizieren kann, kein Recht hat, direkt auf einen anderen Dienst zuzugreifen, der mit dem Kommunikationsport kommunizieren kann.
Computergerät nach einem der Ansprüche 11 bis 14, 18 bis 21, 25 bis 26, insbesondere nach Anspruch 11, 18 und 25, weiter eine Desktopumgebung umfassend und wobei das Betriebssystem die Durchsetzung eines Dienstnamensraums ausführt, der von einem Desktopnamensraum unabhängig ist und die Ausführung der Dienstprozesse in dem Dienstnamensraum und einer oder mehrerer Desktopapplikationen im Desktopnamensraum betreibt.
Computergerät nach einem der Ansprüche 25 bis 27, insbesondere nach Anspruch 27, wobei das Betriebssystem eine Anforderung durchsetzt, dass die im Desktopnamensraum ausgeführten Prozesse über Interprozesskommunikationen mit im Dienstnamensraum ausgeführten Prozessen kommunizieren müssen.
Computergerät nach einem der Ansprüche 25 bis 28, insbesondere nach Anspruch 25, wobei das Betriebssystem eine Anforderung durchsetzt, dass Dienste über Interprozesskommunikationen mit anderen Diensten kommunizieren müssen.
Computergerät umfassend; einen Prozessor und ein Betriebssystem, das auf dem Prozessor gemäß Konfigurationsdaten ausgeführt wird, um Dienstprozesse und einen oder mehrere Desktopprozesse zu implementieren; wobei das Betriebssystem die Durchsetzung eines Dienstnamensraums ausführt, der separat zu einem Desktopnamensraum ist und die Ausführung der Dienstprozesse in einem Dienstnamensraum und einer oder mehrerer Desktopapplikationen im Desktopnamensraum betreibt, der vom Dienstnamensraums getrennt ist und wobei alle im Dienstnamensraum implementierten Prozesse über Interprozesskommunikationen mit im Desktopnamensraum laufenden Prozessen kommunizieren müssen.
Computergerät nach Anspruch 30, wobei der einen oder den mehreren Desktopapplikationen ein Menge von Betriebssystemrechten zugeordnet wird, die getrennt von einer Menge von mit einem Benutzerkonto assoziierten Betriebssystemrechten gehalten wird, das die Desktopapplikation startet.
Computergerät nach einem der Ansprüche 30 bis 31, insbesondere nach Anspruch 30, wobei der einen oder den mehreren Desktopapplikationen die gleiche Menge von Betriebssystemrechten zugeordnet wird, die von einer Menge von mit einem Benutzerkonto assoziierten Betriebssystemrechten gehalten wird, das die Desktopapplikation startet, unabhängig ist.
Computergerät nach einem der Ansprüche 30 bis 32, insbesondere nach Anspruch 32, wobei die Menge von Betriebssystemrechten, die den Desktopapplikationen zugeordnet sind, keine Administratorrechte des Betriebssystems umfasst.
Computergerät nach einem der Ansprüche 30 bis 33, insbesondere nach Anspruch 33, wobei die Menge von Betriebssystemrechten, die den Desktopapplikationen zugeordnet sind, Betriebssystemrechte umfasst, die mit einem allgemeinen Benutzer assoziiert sind.
Computergerät nach einem der Ansprüche 30 bis 34, insbesondere nach Anspruch 30, wobei von Desktopapplikationen stammende Nachrichten Informationen der Benutzeridentität umfassen, die einen Benutzer einer Desktopapplikation identifizieren und wobei die Informationen der Benutzeridentität Nachrichten durch mehrfache mit dem Senden der Nachrichten assoziierte Prozesse folgen.
Computergerät nach einem der Ansprüche 30 bis 35, insbesondere nach Anspruch 35, wobei die Informationen der Benutzeridentität die Betriebssystemrechte nicht steuern, die mit einem oder mehreren zur Weiterleitung der Nachricht an einen Empfänger benutzten Prozessen assoziiert werden.
Computergerät nach einem der Ansprüche 30 bis 36, insbesondere nach Anspruch 30, wobei das Computergerät weiter einen Kommunikationsport, eine lokale Speichereinheit und einen externen Medienport umfasst und wobei einer der Dienstprozesse, der über das Kommunikationsnetzwerkport kommunizieren kann, kein Recht hat, über den externen Medienport auf die lokale Speichereinheit zu schreiben oder mit einer entfernbaren Speichereinheit zu kommunizieren und wobei einer der Dienstprozesse, der über den externen Medienport mit einer entfernbaren Speichereinheit kommunizieren kann, kein Recht hat, auf die lokale Speichereinheit zu schreiben und kein Recht hat, mit dem Kommunikationsport zu kommunizieren und wobei der eine der Dienstprozesse, der mit dem Kommunikationsport kommunizieren kann, kein Recht hat, direkt mit dem einen der Dienstprozesse zu kommunizieren, der über den externen Medienport mit einer entfernbaren Speichereinheit kommunizieren kann.
Computergerät umfassend; einen Prozessor und ein Betriebssystem, das auf dem Prozessor gemäß Konfigurationsdaten ausgeführt wird, um Dienstprozesse und einen oder mehrere Desktopprozesse zu implementieren; wobei das Betriebssystem die Durchsetzung von Betriebssystemrechten für die Dienstprozesse basierend auf benutzerdefinierten Dienstkonten ausführt, zu welchem jeder Dienstprozess, ungeachtet des Prozesses, der den Dienstprozess aufruft, zugeordnet ist, wobei das Betriebssystem die Durchsetzung von Betriebssystemrechten für jede der einen oder mehreren Desktopapplikationen unter Verwendung einer standardmäßigen Menge von Betriebssystemrechten ausführt, die für die Desktopapplikationen definiert sind und für die Desktopapplikationen ungeachtet dessen, welche eine Menge von Benutzerkonten die Desktopapplikation aufruft, verwendet werden und wobei eine Sendedesktopapplikation eine Nachricht an einen Empfangsprozess derart sendet, dass die Nachricht eine Benutzeridentität umfasst, die einen Benutzer der Desktopapplikation identifiziert, wobei die Benutzeridentität mit der Nachricht fließt, während die Nachricht von jedem einer Anzahl an unterschiedlichen Dienstprozessen verarbeitet wird, während die Nachricht von der Sendedesktopapplikation an den Empfangsprozess übertragen wird.
Computergerät nach Anspruch 38, wobei die Informationen der Benutzeridentität den Nachrichten durch mehrfache Prozesse einschließlich eines Dienstprozesses, der auf den Kommunikationsport zugreift, um über einen Kommunikationslink eine Nachricht zu senden, bis zum endgültigen Bestimmungsort folgen.
Computergerät nach einem der Ansprüche 38 bis 39, insbesondere nach Anspruch 39, wobei die Informationen der Benutzeridentität die Betriebssystemrechte und/oder Zugriffsberechtigungen, die mit einem oder mehreren zur Weiterleitung der Nachricht an einen Empfänger benutzten Prozessen assoziiert werden, nicht steuern.
Computergerät nach einem der Ansprüche 38 bis 40, insbesondere nach Anspruch 40, wobei die Informationen der Benutzeridentität Zugriffsberechtigungen zu Prozesssteuerungsobjekten in einem Prozesssteuerungsnetzwerk steuern.
Computergerät nach einem der Ansprüche 38 bis 41, insbesondere nach Anspruch 38, wobei die standardmäßige Menge von Betriebssystemrechten, die für die Desktopapplikationen definiert ist, keine Administratorrechte des Betriebssystems umfassen.
Computergerät nach einem der Ansprüche 11 bis 14, 18 bis 23, 30 bis 34 und 38 bis 42, insbesondere nach Anspruch 23, 32 und 42, wobei das Betriebssystem eine Regel durchsetzt, dass Betriebssystemrechte für Desktopapplikationen nicht erweitert werden können.
Computergerät nach einem der Ansprüche 30 bis 34 und 38 bis 43, insbesondere nach Anspruch 30 und 38, wobei das Computergerät eine lokale Speichereinheit umfasst und wobei das Betriebssystem eine Regel durchsetzt, die verhindert, dass die Desktopapplikationen auf Dienstdateien oder Dienstordner schreiben, die in der lokalen Speichereinheit gespeichert sind.
Computergerät nach einem der Ansprüche 30 bis 34 und 38 bis 44, insbesondere nach Anspruch 30 und 38, weiter einen Desktop mit einer Benutzerschnittstelle umfassend und wobei das Betriebssystem eine Regel durchsetzt, die verhindert, dass einer der Dienstprozesse auf den Desktop zugreifen kann.
Computergerät nach einem der Ansprüche 38 bis 45, insbesondere nach Anspruch 38, wobei die Informationen der Benutzeridentität die Betriebssystemrechte, die mit einem oder mehreren zur Weiterleitung der Nachricht an den Empfängerprozess benutzten Prozessen assoziiert werden, nicht beeinflussen.
Computergerät nach einem der Ansprüche 30 bis 36 und 38 bis 46, insbesondere nach Anspruch 30 und 38, wobei das Computergerät weiter einen Kommunikationsport und eine lokale Speichereinheit umfasst und wobei der eine der Dienstprozesse, der mit einem Kommunikationsport kommunizieren kann, kein Recht hat, auf die lokale Speichereinheit zu schreiben.
Computergerät nach einem der Ansprüche 30 bis 36 und 38 bis 47, insbesondere nach Anspruch 30 und 38, wobei das Computergerät weiter einen externen Medienport umfasst und wobei der eine der Dienstprozesse, der mit dem Kommunikationsport kommunizieren kann, kein Recht hat, über den externen Medienport mit einer entfernbaren Speichereinheit zu kommunizieren.
Computergerät nach einem der Ansprüche 38 bis 48, insbesondere nach Anspruch 38, wobei das Computergerät weiter einen Kommunikationsport, eine lokale Speichereinheit und einen externen Medienport umfasst und wobei einer der Dienstprozesse, der über den Kommunikationsport kommunizieren kann, kein Recht hat, auf die lokale Speichereinheit zu schreiben und wobei einer der Dienstprozesse, der über den externen Medienport mit einer entfernbaren Speichereinheit kommunizieren kann, kein Recht hat, auf die lokale Speichereinheit zu schreiben und wobei einer der Dienstprozesse, der über den Kommunikationsport kommunizieren kann, kein Recht hat, direkt mit dem einen der Dienstprozesse zu kommunizieren, der über den externen Medienport mit einer entfernbaren Speichereinheit kommunizieren kann.
Computergerät nach einem der Ansprüche 38 bis 49, insbesondere nach Anspruch 38, wobei das Betriebssystem die Durchsetzung eines Dienstnamensraums ausführt, der separat von einem Desktopnamensraum ist und die Ausführung der Dienstprozesse in einem Dienstnamensraum und der einen oder mehreren Desktopapplikationen im Desktopnamensraum betreibt, der separat von dem Dienstnamensraum ist und wobei alle im Dienstnamensraum implementierten Prozesse über Interprozesskommunikationen mit Prozessen im Desktopnamensraum kommunizieren müssen.