Der Deep Security Agent kann die Kommunikation zu Server- und Workload Protection initiieren oder von Server- und Workload Protection kontaktiert werden, wenn das Computerobjekt auf den bidirektionalen Modus eingestellt
ist. Server- und Workload Protection behandelt alle Verbindungen zu Agents auf ähnliche Weise. Wenn der Agent nicht aktiviert
wurde, ist nur ein begrenzter Satz von Interaktionen möglich. Wenn der Agent aktiviert
wurde (entweder durch einen Administrator oder über die agenteninitiierte Aktivierungsfunktion),
ist der vollständige Satz von Interaktionen aktiviert. Server- und Workload Protection agiert in allen Fällen als HTTP-Client, unabhängig davon, ob es der Client beim Aufbau
der TCP-Verbindung war oder nicht. Agents können keine Daten anfordern oder selbst
Operationen initiieren. Server- und Workload Protection fordert Informationen wie Ereignisse und Status an, führt Operationen aus oder überträgt
Konfigurationen an den Agenten. Diese Sicherheitsdomäne ist streng kontrolliert, um
sicherzustellen, dass Agents keinen Zugriff auf Server- und Workload Protection oder den Computer haben, auf dem es läuft.
Sowohl der Agent als auch Server- und Workload Protection verwenden zwei verschiedene Sicherheitskontexte, um den sicheren Kanal für HTTP-Anfragen
zu etablieren:
- Vor der Aktivierung akzeptiert der Agent das Bootstrap-Zertifikat, um den SSL- oder TLS-Kanal zu bilden.
- Nach der Authentifizierung ist eine gegenseitige Authentifizierung erforderlich, um die Verbindung zu initiieren. Für die gegenseitige Authentifizierung wird das Server- und Workload Protection-Zertifikat an den Agenten gesendet und das Zertifikat des Agenten wird an Server- und Workload Protection gesendet. Der Agent überprüft, dass die Zertifikate von derselben Zertifizierungsstelle stammen (die Server- und Workload Protection ist), bevor privilegierter Zugriff gewährt wird.
Sobald der sichere Kanal eingerichtet ist, fungiert der Agent als Server für die HTTP-Kommunikation.
Er hat eingeschränkten Zugriff auf Server- und Workload Protection und kann nur auf Anfragen antworten. Der sichere Kanal bietet Authentifizierung,
Vertraulichkeit durch Verschlüsselung und Integrität. Die Verwendung von gegenseitiger
Authentifizierung schützt vor Man-in-the-Middle (MiTM)-Angriffen, bei denen der SSL-Kommunikationskanal
über eine bösartige Drittpartei geleitet wird. Innerhalb des Streams wird der innere
Inhalt mit GZIP verwendet und die Konfiguration wird weiter mit PKCS #7 verschlüsselt.
Es wird nicht empfohlen, die SSL/TLS-Entschlüsselung der Kommunikation zwischen Deep
Security-Produkten durchzuführen. Jedes Gerät oder Middleware sollte für TLS-Passthrough
konfiguriert werden. Wenn beispielsweise eine Firewall eine SSL-Inspektion durchführt,
entschlüsselt und verschlüsselt sie die Kommunikation erneut, wodurch das Zertifikat
im Prozess verändert wird. Diese Veränderung führt dazu, dass das Zertifikat von dem
ursprünglichen abweicht. Infolgedessen wird das veränderte Zertifikat als unautorisiert
angesehen, wenn die Kommunikation vom Deep Security Agent den Deep Security Manager
erreicht.
