Verdict-as-a-Service

Komponenten

Erläuterungen zu den einzelnen Komponenten

1 = Verdict-as-a-Service SDK

Vorbereitete SDKs erleichtern Ihnen die Implementierung in Ihre Anwendung.
Sie finden in den SDKs (je nach Programmiersprache) bis zu 4 verschiedene Funktionen:

forFile = Datei überprüfen
forUrl = URL überprüfen
forStream = Streams überprüfen
forSha256 = Ausschließlich Sha256 überprüfen

Je nach Funktion verläuft der Informationsaustausch der Komponenten untereinander leicht abgewandelt.

2 = Identity-Provider

Mini-Identity-Provider ist ein OpenID Connect kompatibler Authentifizierungsanbieter. Er wird für einfache Szenarien mit nur einem Benutzer verwendet. Es ist möglich an dieser Stelle Ihren Authentifizierungsanbieter zu verwenden.

3 = Gateway

Das Gateway fungiert als Schnittstelle für sämtliche Anfragen, einschließlich der Authentifizierung. Es generiert die Antworten unter Zuhilfenahme unserer Backing Services.

4 = Redis

Dieser Cache beinhaltet frühere Überprüfungen und dient als Grundlage für eine erneute Prüfung. Bei Vorhandensein eines Zwischenergebnisses in der Cache-Datei ist ein weiteres Scannen der Datei nicht notwendig.

5 = GdScan

Die Hauptkomponente für das Scannen von Dateien unter Verwendung mehrerer Engines.

6 = CloudHashLookUp

CloudHashLookUp ist ein Backend-System, welches ausschließlich in unserer Cloud gehostet werden kann. Anhand des Hashwertes wird ermittelt, was über diese Datei bereits bekannt ist, ohne das die Datei übermittelt werden muss. Dadurch können schadhafte Dateien mit weniger Verzögerung identifiziert werden. In der Verdict-as-a-Service Cloud-Lösung erfolgt diese Abfrage immer, bei On-Premise Lösungen kann diese Abfrage optional ausgeführt werden.

Erklärung des Schema-Diagramms

Das Schema-Diagramm veranschaulicht das Zusammenwirken der Verdict-as-a-Service Komponenten im Falle einer Dateiüberprüfung (forFile). Alle anderen Funktionen weichen leicht

Funktion forFile
1. Das in der Software integrierte SDK (1) fordert beim Identity Provider (2) ein Authentifizierungs-Token an und übermittelt dieses Token zusammen mit der SHA256-Summe der Datei an das Gateway (3).
2. Das Gateway (3) überprüft die Authentifizierung und prüft im Redis (4), ob diese Datei bereits durch Verdict-as-a-Service gescannt wurde. Im Falle einer positiven Übereinstimmung wird das Resultat umgehend an das SDK (1) zurückgegeben.
3. Andernfalls wird die SHA256-Summe an CloudHashLookup (6) übermittelt. Sofern dort bereits Informationen zu dieser Datei vorliegen, erfolgt eine unmittelbare Rückgabe des Resultats an das SDK (1).
4. Ist anhand der SHA256-Summe nichts über diese Datei bekannt, fordert das Gateway (3) die Übermittlung der vollständigen Datei an und lässt sie durch den Scanner (5) laufen. Das Ergebnis wird an das SDK (1) zurückgegeben.
Funktion ForURL
- Der Ablauf ist wie bei der Funktion forFile. Es wird durch das SDK jedoch eine URL übermittelt. Dadurch entfällt die Abfrage der SHA256-Summe. Die Dateien, die unter der angegebenen URL erreicht werden, werden durch das Gateway (3) heruntergeladen und durch die Scanner überprüft.
Funktion forStream
- Der Ablauf entspricht der Funktion forFile.

Funktion forSha256

Der Ablauf entspricht der Funktion forFile, jedoch entfällt das Hochladen der Datei, auch wenn die Abfrage des CloudHashBackups keine Informationen geliefert hat. Diese Funktion kann bei On-Premise Nutzung von Verdict-as-a-Service nur verwendet werden, wenn die Abfrage des CloudHashBackups nicht deaktiviert wurde.