Mit der Server- und Workload Protection API können Sie gemeinsame Regelsets und globale Regeln erstellen. Sie können einen
Regelset-Typ oder eine Kombination verwenden. Weitere Informationen finden Sie unter
Gemeinsames Regelset erstellen und Globale Regeln hinzufügen.
Local ruleset: Regeln, die als Teil des Software-Inventars eines Computers hinzugefügt werden oder
im Wartungsmodus sind, werden nur auf dem geschützten Computer gespeichert und sind
in Server- und Workload Protection nicht sichtbar. Zulassen- oder Sperren-Regeln, die Sie in Server- und Workload Protection konfigurieren, werden an den Agenten gesendet und an beiden Orten gespeichert. Da
Agenten ihre Inventarinformationen nicht an Server- und Workload Protection übertragen, bieten lokale Regelsets eine bessere Leistung als geteilte Regelsets.
Um festzustellen, ob Software neu ist oder sich geändert hat, vergleicht Version 10
des Agenten die Datei mit dem SHA-256-Hash, der Dateigröße, dem Pfad und dem Dateiname
der ursprünglich installierten Software (sie haben ein "dateibasiertes" lokales Regelwerk).
Version 11+ des Agenten vergleicht nur den SHA-256-Hash und die Dateigröße der Datei
(sie haben ein "hash-basiertes" lokales Regelwerk). Da die von Version 11+ Agenten
erstellten Regeln nur den eindeutigen Hash und die Dateigröße vergleichen, wird eine
Regel weiterhin angewendet, selbst wenn die Softwaredatei umbenannt oder verschoben
wird. Dadurch reduziert die Verwendung von Version 11+ Agenten die Anzahl der Softwareänderungen,
mit denen Sie sich befassen müssen. Version 10 Agenten verwenden weiterhin ein dateibasiertes
lokales Regelwerk, bis sie auf Version 11+ aktualisiert werden. Bei der Aktualisierung
wird ihr lokales Regelwerk in ein hash-basiertes Regelwerk umgewandelt.
Hinweis
Wenn es mehrere dateibasierte Regeln für denselben Hash-Wert gibt, werden sie zu einer
hashbasierten Regel zusammengefasst. Wenn die zusammengefassten Regeln miteinander
in Konflikt stehen (eine Regel sperrt die Datei und eine andere erlaubt sie), wird
die neue hashbasierte Regel eine "Erlauben"-Regel sein.
Shared ruleset: Synchronisiert alle seine Regeldaten sowohl auf Agenten als auch auf Manager (und
auch auf Relays, falls aktiviert). Dies erhöht die Nutzung von Netzwerk- und Speicherplatz.
Es kann jedoch einfacher sein, wenn Sie die Regeln aus dem anfänglichen Inventarscan
oder dem Wartungsmodus überprüfen müssen, oder wenn Sie eine Serverfarm mit vielen
Computern verwalten, die identisch sein sollten. Zum Beispiel, wenn Sie einen Serverpool
mit identischen LAMP-Webservern haben oder wenn es sich um virtuelle Maschinen (VMs)
handelt, die Teil einer Auto-Scaling-Gruppe sind, können gemeinsame Regelsets nützlich
sein. Es kann auch die Arbeitsbelastung des Administrators reduzieren.
Warnung
Verwenden Sie kein gemeinsames Regelwerk, wenn Sie Block unrecognized software until it is explicitly allowed aktiviert haben und wenn Computer nur ähnlich (aber nicht identisch) sind. Es wird
alle Software auf anderen Computern sperren, die nicht im Regelwerk des ersten Computers
enthalten ist. Wenn diese kritische Dateien umfassen, könnte dies das Betriebssystem
beschädigen. Sollte dies passieren, müssen Sie möglicherweise neu installieren, auf
ein Backup zurückgreifen oder den Wiederherstellungsmodus des Betriebssystems verwenden.
Wenn Sie ein neues gemeinsames Regelset erstellen, kann es nur hashbasierte Regeln
enthalten (Regeln, die nur den Hash und die Größe einer Datei vergleichen). Wenn Sie
ein gemeinsames Regelset mit einer früheren Version von Server- und Workload Protection erstellt haben, enthält es dateibasierte Regeln (Regeln, die den Namen, Pfad, die
Größe und den Hash einer Datei vergleichen). Ältere gemeinsame Regelsets werden weiterhin
dateibasierte Regeln verwenden, bis alle Agenten, die das gemeinsame Regelset verwenden,
auf die Agentenversion 11+ aktualisiert sind. Dann wird das gemeinsame Regelset in
hashbasierte Regeln umgewandelt.
Warnung
Erstellen Sie kein neues gemeinsames Regelwerk, bis alle Agenten auf Version 11.0+
aktualisiert wurden. Neue gemeinsame Regelwerke sind hashbasiert und nicht kompatibel
mit Agentenversion 10.3 oder früher, die nur dateibasierte Regelwerke unterstützt.
Tipp
Wenn es mehrere dateibasierte Regeln für denselben Hash-Wert gibt, werden sie zu einer
hashbasierten Regel zusammengefasst. Wenn die zusammengefassten Regeln miteinander
in Konflikt stehen (eine Regel sperrt die Datei und eine andere erlaubt sie), wird
die neue hashbasierte Regel eine "Erlauben"-Regel sein.
Global rules: Wie gemeinsame Regelsets werden globale Regeln von Server- und Workload Protection (und auch von Relays, falls aktiviert) an Agenten verteilt. Dies erhöht die Nutzung
von Netzwerk- und Speicherplatz. Da sie jedoch global sind, müssen Sie keine Zeit
damit verbringen, sie in jeder Richtlinie auszuwählen. Globale Regeln sind nicht Teil
der Regelsets, die Sie in Server- und Workload Protection sehen können. Globale Regeln können nur Sperrregeln enthalten, keine Erlaubnisregeln.
Globale Regeln erfordern einen Agenten der Version 10.2+. Server- und Workload Protection wird die globalen Regeln nicht an ältere Agenten senden. Globale Regeln haben Vorrang
vor allen anderen Application Control-Regeln und werden auf allen Computern durchgesetzt,
auf denen Application Control aktiviert ist. Die Regeln in den globalen Regeln basieren
auf dem MD5-, SHA-1- oder SHA-256-Hash einer Datei. Da der Hash einer Softwaredatei
einzigartig ist, können Sie spezifische Software überall sperren — unabhängig von
Dateipfad, Richtlinie oder Computergruppe und unabhängig davon, ob Application Control
die Software zuvor erkannt hat.
Hinweis
In einer Multi-Tenant-Bereitstellung hat jeder Mandant separate globale Regeln. Um
Software für alle Mandanten zu sperren, erstellen Sie die gleichen globalen Regeln
für jeden Mandanten.
Sie können die API verwenden, um gemeinsame Erlauben- oder Sperren-Regeln zu erstellen
und das Regelwerk auf andere Computer anzuwenden. Dies kann nützlich sein, wenn Sie
viele identische Computer haben (wie zum Beispiel eine Lastverteilte Webserver-Farm).
Shared rulesets should be applied only to computers with the exact same inventory.
Navigieren Sie zu Computer or Policy editor → Application Control.
Stellen Sie im Abschnitt Regeln sicher, dass Inherit settings nicht ausgewählt ist, und wählen Sie dann Use a shared ruleset aus. Geben Sie an, welche gemeinsamen Regeln verwendet werden sollen.
Hinweis
Diese Einstellungen sind verborgen, bis Sie die API verwenden, um mindestens ein gemeinsames
Regelwerk zu erstellen. Wenn Sie keine gemeinsamen Regelwerke erstellt haben oder
die Standardeinstellungen beibehalten, wird jeder Computer seine eigenen Zulassungs-
und Sperrregeln lokal behalten. Änderungen an lokalen Regeln wirken sich nicht auf
andere Computer aus.
Klicken Sie auf Save.
Das nächste Mal, wenn der Agent auf dem Computer eine Verbindung mit Server- und Workload Protection herstellt, wendet der Agent diese Regeln an.
Wenn Sie eine Fehlermeldung sehen, die besagt, dass das Hochladen des Regelwerks nicht
erfolgreich war, überprüfen Sie, ob Netzwerkgeräte zwischen dem Agenten und Server- und Workload Protection oder dem Relay die Kommunikation über den Heartbeat-Port oder die Relay-Portnummern zulassen.
Von gemeinsamen zu computerspezifischen Erlauben- und Sperren-Regeln wechseln
Wenn der Computer derzeit gemeinsame Erlauben- oder Sperren-Regeln verwendet, die
über die API erstellt wurden, können Sie ihn so ändern, dass er lokale Regeln verwendet.
Application Control durchsucht das Dateisystem nach allen derzeit installierten Software
und erstellt ein anfängliches Regelwerk dafür, ähnlich wie beim ersten Aktivieren
von Application Control.
Warnung
Bevor Sie beginnen, vergewissern Sie sich, dass nur gute Software installiert ist.
Das Neufestlegen des Regelwerks wird alle derzeit installierte Software zulassen,
auch wenn sie unsicher oder Malware ist. Wenn Sie sich nicht sicher sind, was installiert
ist, ist der sicherste Ansatz, eine Neuinstallation durchzuführen und dann Application
Control zu aktivieren.
Die folgenden Schritte konfigurieren den Agenten eines Computers zur Verwendung eines
lokalen Regelwerks. Wenn Sie möchten, dass alle Computer lokale Regeln verwenden,
bearbeiten Sie stattdessen die Einstellung im Richtlinien-Tab.
Prozedur
Navigieren Sie zu Computer editor → Application Control.
Im Abschnitt Regelwerk deaktivieren Sie Inherit settings (falls erforderlich) und wählen Sie dann Use local ruleset initially based on installed software aus.
Bereitstellen von Application Control gemeinsamen Regelsets über Relays
Jedes Mal, wenn Sie ein Application Control-Regelset erstellen oder ändern, muss es
auf alle Computer verteilt werden, die es verwenden. Geteilte Regelsets sind größer
als lokale Regelsets. Geteilte Regelsets werden auch häufig auf viele Server angewendet.
Wenn sie alle das Regelset gleichzeitig direkt von Server- und Workload Protection herunterladen würden, könnte eine hohe Auslastung zu einer langsameren Leistung führen.
Globale Regelsets erfordern die gleichen Überlegungen.
Die Schritte variieren je nachdem, ob Sie eine Multi-Tenant-Bereitstellung haben oder
nicht.
Einzelmandantenbereitstellungen
Navigieren Sie zu Administration → System Settings → Erweitert und wählen Sie dann Serve Application Control rulesets from relays aus.
Multi-Tenant-Bereitstellungen
Der primäre Mandant (t0) kann nicht auf die Konfigurationen anderer Mandanten (tN)
zugreifen, daher haben t0-Relays keine tN Application Control-Regelsätze. Andere Mandanten
(Tn) müssen ihre eigene Relay-Gruppe erstellen und dann Serve Application Control rulesets from relays auswählen.
Überlegungen bei der Verwendung von Relais mit gemeinsamen Regelsets
Bevor Sie Relays verwenden, vergewissern Sie sich, dass sie mit Ihrer Bereitstellung
kompatibel sind. Wenn der Agent derzeit keine zuvor heruntergeladene Regelgruppe in
Kraft hat, und if it doesn't receive new Application Control rules, then the computer won't be protected
by Application Control. Wenn der Download des Application Control-Regelsatzes fehlschlägt, wird ein Ereignis
für das Scheitern des Regelsatz-Downloads in der Server- und Workload Protection-Konsole und auf dem Agenten protokolliert.
Wenn Sie einen Proxy verwenden, um Agenten mit einem Manager zu verbinden, müssen
Sie ein Relay verwenden.
Hinweis
In Version 10.0 und früheren Versionen des Agenten hatten Agenten keine Unterstützung
für Verbindungen über einen Proxy zu Relays. Wenn ein Regelwerk-Download aufgrund
eines Proxys fehlschlägt und Ihre Agenten einen Proxy benötigen, um auf das Relay
oder Server- und Workload Protection zuzugreifen, müssen Sie entweder:
