Workload-Sicherheitsagenten bereitstellen
Änderungen vorschlagen
PDFs
Workload Security Agents überwachen die Benutzeraktivitäten und erkennen potenzielle Sicherheitsbedrohungen in Ihrer Speicherinfrastruktur. In diesem Leitfaden werden die Installation eines Agents, das Öffnen der erforderlichen Netzwerkports, die Verwaltung des Pausierens/Fortsetzens und Anheftens/Entfernens sowie die Überprüfung des Agents nach der Bereitstellung behandelt. Vor Beginn sollte sichergestellt werden, dass der Agent-Host die Anforderungen in Workload Security Agent Requirements erfüllt.
Bevor Sie beginnen
-
Es ist sicherzustellen, dass der Agent-Host die System-, Paket- und Netzwerkanforderungen gemäß den Workload Security Agent Requirements erfüllt (4 CPU-Kerne, 16 GB RAM, /opt/netapp mit mindestens 35 GB freiem Speicherplatz, unterstützte Linux-Distribution, unzip / zip / sshpass, statische IP, NTP).
-
Für die Installation, das Ausführen von Skripten und die Deinstallation sind sudo-Berechtigungen erforderlich.
-
Während der Installation werden ein lokaler Benutzer cssys und eine lokale Gruppe cssys auf dem Rechner erstellt. Falls die Richtlinie die Erstellung eines lokalen Benutzers nicht zulässt und stattdessen Active Directory erfordert, ist vor der Installation ein Benutzer mit dem Benutzernamen cssys in Active Directory zu erstellen.
-
Ein Agent unterstützt maximal 50 Datensammler (alle Typen zusammen, zum Beispiel Active Directory, LDAP und ONTAP SVM Sammler), mit einer Obergrenze von etwa 20.000 Ereignissen pro Sekunde. Die Kapazität sollte mit dem Event Rate Checker geplant werden, bevor viele Sammler auf einem Agent eingesetzt werden.
-
Falls der Agent einen Proxy für den Zugriff auf SaaS verwendet, sollten Proxy-Host, Port und Zugangsdaten bereitliegen. Der Proxy wird während der Installation in Schritt 4 festgelegt.
Schritte zur Installation eines Agenten
-
Melden Sie sich als Administrator oder Kontobesitzer bei Ihrer Workload Security-Umgebung an.
-
Wählen Sie Collectors > Agents > +Agent. Das System zeigt die Seite „Add an Agent“ an.
-
Im Bereich „Agent Server Requirements“ auf „Linux Versions Supported (i)“ und „Minimum Server Requirements (i)“ klicken, um zu bestätigen, dass das Host-Betriebssystem unterstützt wird und korrekt dimensioniert ist.
-
Wenn Ihr Netzwerk einen Proxyserver verwendet, Optional: Proxy-Server-Einstellungen > Anweisungen anzeigen erweitern und auf Proxy-Server-Einstellungen kopieren klicken. Auf dem Agent-Host den kopierten Befehl in einem Terminal ausführen, wobei USER, PASSWORD, PROXY_SERVER und PORT durch eigene Werte zu ersetzen sind.
export https_proxy='USER:PASSWORD@PROXY_SERVER:PORT'
Derselbe Terminal wie für den Installationscode sollte für diesen Befehl verwendet werden, damit der Installer die Proxy-Einstellung übernimmt.
-
Auf „Copy Installer Snippet“ klicken. Der Ausschnitt enthält einen eindeutigen Schlüssel, der 2 Stunden lang und nur für einen Agent gültig ist, daher sollte er umgehend ausgeführt und nicht für einen zweiten Agent wiederverwendet werden. Zur vorherigen Ansicht auf „Reveal Installer Snippet“ klicken.
-
Auf dem Agent-Host ein Terminal öffnen, den Installationsbefehl einfügen und ausführen. Ein bevorzugt leeres Arbeitsverzeichnis, dessen Eigentümer Sie sind (zum Beispiel mkdir cloudsecure && cd cloudsecure), verwenden, damit chmod während der Installation nicht bei Dateien fehlschlägt, die anderen Benutzern gehören.
-
Nach erfolgreicher Installation gibt das Installationsprogramm eine Erfolgsmeldung aus und der Agentendienst wird gestartet. Im Browser kann mit „Setup abschließen“ das Hinzufügen des Agenten beendet werden. Bei erfolgreicher Installation wird „Neuer Agent erkannt“ angezeigt.
Nach Abschluss
-
Bestätigen, dass der Agent unter Workload Security > Collectors > Agents als verbunden angezeigt wird.
-
Die FPolicy/EMS-Callback-Ports auf dem Agent-Host müssen geöffnet sein (siehe Netzwerkkonfiguration unten).
-
Für jede Domäne, deren Benutzer auf überwachte SVMs zugreifen, sollte ein User Directory Collector (Active Directory oder LDAP) konfiguriert werden, idealerweise vor oder zusammen mit dem ersten ONTAP SVM Collector. Ohne diese Konfiguration zeigt Activity Forensics möglicherweise SIDs anstelle von Benutzernamen an. Test Connection ist für User Directory Collector nicht verfügbar.
-
Ein oder mehrere ONTAP SVM Data Collectors konfigurieren. Bevorzugt werden die Cluster Management-IP und der SVM-Name mit den Cluster-Anmeldedaten verwendet, und vor dem Speichern sollte Test Connection ausgeführt werden, damit Netzwerk- und RBAC-Prüfungen erfolgreich sind.
-
Innerhalb der Agentenkapazität bleiben: höchstens 50 Sammler pro Agent; den Event Rate Checker zur Dimensionierung für die maximale Ereignisrate verwenden.
Den Proxy nach der Installation ändern
Wenn sich der Proxy nach der Installation des Agenten ändert, muss die Agentenkonfiguration aktualisiert und der Dienst neu gestartet werden.
-
Zum Konfigurationsverzeichnis wechseln: cd /opt/netapp/cloudsecure/conf
-
Die Datei agent.properties bearbeiten und AGENT_PROXY_HOST, AGENT_PROXY_PORT sowie falls erforderlich AGENT_PROXY_USER und AGENT_PROXY_PASSWORD festlegen.
-
Agent neu starten: sudo systemctl restart cloudsecure-agent.service
Befindet sich der Agent hinter einer SSL-Inspektion (zum Beispiel Zscaler), sollte die SSL-Inspektion für *.cloudinsights.netapp.com und den regionalen agentlogin Host deaktiviert werden. Workload Security funktioniert nicht korrekt, wenn Zwischenzertifikate die SaaS-Endpunkte neu signieren.
Netzwerkkonfiguration
Die TCP-Ports, die ONTAP zum Senden von FPolicy- und EMS-Ereignissen an den Agenten verwendet, müssen geöffnet werden. Es ist nicht erforderlich, den gesamten Bereich von 35000 bis 55000 zu öffnen. Die Reservierung für Collector auf diesem Agenten sollte entsprechend dimensioniert werden: Jede SVM verwendet bis zu 4 Ports (2 pro aktiviertem Protokoll, NFS und CIFS/SMB). Für einen vollständig ausgelasteten Agenten (50 Collector) sollten etwa 200 Ports im Bereich von 35000 bis 55000 reserviert werden. Die Reservierung kann bei Bedarf erhöht werden.
Öffnen Sie den Bereich zum Agent-Host, einschließlich aller lokalen Firewalls. Es sollte außerdem sichergestellt sein, dass SVM-Daten-LIFs den Agent für FPolicy-Ereignisse erreichen können und (wenn EMS-basierte Funktionen wie ARP verwendet werden) dass die Cluster-Management-IP den Agent auf denselben reservierten Ports erreichen kann. Die vollständigen Tabellen für In-Network- und Cloud-Egress finden sich unter Workload Security Agent Requirements.
Beispiel: firewalld (permanent)
sudo firewall-cmd --permanent --zone=public --add-port=35000-55000/tcp
sudo firewall-cmd --reload
Regel verifizieren:
Auf Systemen, die firewalld verwenden (z. B. RHEL / CentOS 8+):
sudo firewall-cmd --zone=public --list-ports | grep 35000
Beispielausgabe: 35000-55000/tcp
Auf Systemen, die iptables verwenden (zum Beispiel ältere RHEL / CentOS 7.x):
sudo iptables-save | grep 35000
Beispielausgabe:
-A IN_public_allow -p tcp -m tcp --dport 35000:55000 -m conntrack -ctstate NEW,UNTRACKED -j ACCEPT
Die Verbindungsprüfung (auf der ONTAP SVM Collector-Seite) überprüft nur eine Teilmenge der Ports in diesem Bereich. Der vollständige reservierte Portsatz muss auf dem Agenten offen bleiben.
Überprüfung nach der Installation
Nach erfolgreicher Installation sind auf dem Agent-Host und in der Benutzeroberfläche folgende Punkte zu bestätigen:
-
UI-Status: Collectors > Agents zeigt den Agent als Verbunden an (nicht NICHT_VERBUNDEN).
-
Dienst: sudo systemctl status cloudsecure-agent.service meldet aktiv (running).
-
Benutzer: id cssys und groups cssys erfolgreich (lokaler cssys-Benutzer/-Gruppe existiert oder das AD cssys-Konto ist verfügbar).
-
Disk-Pfad: /opt/netapp befindet sich auf einer lokalen Festplatte, auf die cssys zugreifen kann (kein NFS-Mount, den der lokale Benutzer nicht verwenden kann).
-
Ports: Der reservierte Bereich 35000–55000 ist für eingehende Verbindungen zum Agent geöffnet (firewall-cmd oder iptables-Prüfung siehe oben).
-
SaaS-Pfad: Ausgehender TCP 443 zu den Endpunkten *.cloudinsights.netapp.com und agentlogin Ihrer Region ist erfolgreich (keine SSL-Inspektionsumschreibung).
Falls der Agent nicht startet, bevor Anwendungsprotokolle vorhanden sind, sollte journalctl -u cloudsecure-agent.service geprüft werden, da frühe Bootstrap-Fehler im Dienstjournal und nicht in agent.log protokolliert werden.
Control Agent-Aktualisierungen: Anheften und Aufheben der Anheftung
Workload Security aktualisiert Agents standardmäßig automatisch. Durch das Anheften eines Agents werden diese automatischen Updates angehalten, sodass der Agent und die von ihm gehosteten Collector ihre aktuelle Version beibehalten.
Hinweis: Anheften und Aufheben der Anheftung beziehen sich auf einen Agenten und sind nur über die API verfügbar. Anhalten und Fortsetzen sind Steuerelemente des Datensammlers, sie beziehen sich nicht auf einen Agenten, und sie können entweder über die Benutzeroberfläche oder die API ausgeführt werden. Siehe Konfigurieren des ONTAP SVM Data Collector. _
| Kontrolle | Wie es ausgeführt wird | Was es bewirkt |
|---|---|---|
Anheften |
Nur cloudsecure_config.agents-API. In der Benutzeroberfläche nicht verfügbar. |
Automatische Updates werden pausiert. Der Agent und die von ihm gehosteten Collector bleiben bei ihrer aktuellen Version. |
Lösen |
Nur cloudsecure_config.agents-API. In der Benutzeroberfläche nicht verfügbar. |
Automatische Updates werden fortgesetzt. Der Agent ruft die neueste verfügbare Version ab und aktualisiert sich selbst sowie seine Collector. |
Ein fixierter Agent kehrt zu automatischen Updates zurück, wenn eine der folgenden Bedingungen erfüllt ist:
-
Sie lösen die Fixierung des Agent.
-
30 Tage sind vergangen. Das 30-Tage-Zeitfenster beginnt am Tag der letzten Agentenaktualisierung, nicht an dem Tag, an dem der Agent angeheftet wird.
In beiden Fällen aktualisiert der Agent sich beim nächsten Workload Security-Refresh, nachdem die Bedingung erfüllt ist. Bis zu fünf Minuten können vergehen, bis eine Anheftungs- oder Aufhebungsanforderung wirksam wird.
Um einen Agenten anzuheften oder die Anheftung aufzuheben, werden die cloudsecure_config.agents APIs verwendet. Die aktuellen Agentenversionen sind unter Workload Security > Collectors > Agents einsehbar.
Agentenversionen, die auf der Registerkarte „Agenten“ angezeigt werden.
Einen Agent nach dem anderen anheften und lösen
Das Anheften und Aufheben der Anheftung wird auch auf Mandantenebene unterstützt. Wenn die Anheftung auf Mandantenebene aufgehoben wird, werden alle Agenten im Mandanten automatisch und sofort aktualisiert.
Stattdessen die Anheftung und das Aufheben der Anheftung auf Agentenebene verwenden. Die Steuerung auf Agentenebene ist feiner abgestuft: Nur der Agent, dessen Anheftung aufgehoben wird, erhält das Upgrade, sodass die Auswirkungen einer neuen Version auf diesen Agenten und die von ihm gehosteten Collector beschränkt sind.
| Umfang | Anheften | Lösen |
|---|---|---|
Alle Agenten im Mandanten |
POST /v1/cloudsecure/agents/configuration |
DELETE /v1/cloudsecure/agents/configuration |
Ein einzelner Agent (empfohlen) |
POST /v1/cloudsecure/agents/ {agentId}/Konfiguration |
DELETE /v1/cloudsecure/agents/ {agentId}/Konfiguration |
Vorgeschlagene Vorgehensweise
-
Die Agenten, die in ihrer aktuellen Version beibehalten werden sollen, anheften.
-
Einen Agenten lösen und das Upgrade durchführen lassen.
-
Bestätigt wird, dass der Agent wieder den Status „Verbunden“ hat und seine Collector wieder den Status „Wird ausgeführt“ haben.
-
Die verbleibenden Agents werden schrittweise gelöst, sodass ein unerwartetes Problem nur einen Teil Ihrer Umgebung betrifft.
Bewährte Vorgehensweisen für Agents
Diese Vorgehensweisen gelten für den Agenten. Vorgehensweisen für Datensammler, einschließlich wann ein Datensammler pausiert werden sollte, sind unter Konfigurieren des ONTAP SVM Data Collector zu finden.
-
Mit „Anheften“ und „Anheften aufheben“ lässt sich steuern, wann ein Agent aktualisiert wird. Für die Steuerung von Aktualisierungen ist es nicht erforderlich, die Collector anzuhalten.
-
Das Anheften und Aufheben der Anheftung erfolgt auf Agentenebene statt auf Mieterebene, sodass ein Upgrade jeweils nur einen Agenten und dessen Collector betrifft.
-
Planen Sie nicht, einen angehefteten Agenten dauerhaft zu behalten. Ein angehefteter Agent wird 30 Tage nach seiner letzten Aktualisierung automatisch aktualisiert.
-
Innerhalb der Agent-Kapazität bleiben: höchstens 50 Collector pro Agent (alle Typen zusammen), mit einer Obergrenze von 20.000 Ereignissen pro Sekunde. Ungefähr 10 Collector passen zu 4 CPU-Kernen und 16 GB RAM; ungefähr 20 Collector passen zu 4 CPU-Kernen und 32 GB RAM.
-
Den Agent für die maximale Ereignisrate mit dem Event Rate Checker dimensionieren, bevor Collector hinzugefügt werden, und einen Collector zu einem anderen Agent migrieren, anstatt einen Agent zu überlasten.
-
Collector auf mehrere Agents verteilen, damit die Wartung eines Agents die Überwachung jeder SVM nicht unterbricht.
-
Dem Agent-Host wird eine statische IP-Adresse zugewiesen, und seine Uhr bleibt mithilfe von NTP mit ONTAP synchronisiert.
-
Die reservierten FPolicy Callback-Ports müssen zum Agenten hin offen bleiben, auch in der Host-Firewall (siehe Netzwerkkonfiguration).
Fehlerbehebung
Bei Installations- und Verbindungsfehlern des Agenten (nicht unterstütztes Betriebssystem, fehlendes unzip/zip, cssys-Berechtigungsprobleme, NOT_CONNECTED, Proxy-Änderungen, Symptom-Collector-Fehler) siehe Troubleshooting the ONTAP SVM Data Collector — Agent install and health section und Workload Security Agent Requirements.
Zum Sammeln eines Diagnosepakets für den Support (als Root ausführen):
sudo /opt/netapp/cloudsecure/agent/bin/cloudsecure-agent-symptom-collector.sh -o /tmp
cloudsecure-agent-symptoms.zip (oder die in /tmp erstellte zip-Datei) zusammen mit Ihrer Data Infrastructure Insights Seriennummer an den Fall anhängen. Vor dem Ausführen des Symptom Collectors muss das zip-Paket auf dem Agent Host installiert sein.