Häufig gestellte Fragen

Nein, DS verfügt nicht über solche Funktionen. Es sollte beachtet werden, dass DS eine Datenbanksicherheitslösung und keine WAF (Web Application Firewall) ist. DataSunrise schützt Datenbanken, nicht die darauf laufenden Anwendungen.

Das Einzige, was als eine Art virtuelles Patchen verwendet werden kann, ist die SQL-Injection-Präventions-Sicherheitsregel, da ein SQL-Injection-Angriff in der Regel auf der Anwendungsebene durch das Ausnutzen schlechter Anwendungsdesigns durchgeführt wird, die es einem Angreifer ermöglichen, schädliche SQL-Befehle zusammen mit nicht parametrisierten oder nicht maskierten Anfrageparametern zu senden.

Nein, der VA Scanner von DataSunrise kann nur zu Berichterstellungszwecken verwendet werden und führt keine Patches als Teil der VA Scanner-Geschäftslogik durch.

Für eine ausgewählte Reihe von DBMS-Engines und Versionen kann DataSunrise jedoch eine Liste von Maßnahmen bereitstellen, die von CIS und STIG-Sicherheitsbenchmarks durchgeführt werden müssen, um das DBMS zu härten.

DataSunrise kann nur Schwachstellen und Fehlkonfigurationen finden und deren Behebung vorschlagen, die durch SQL-Schnittstellenbefehle diagnostiziert und behoben werden können.

DataSunrise verfügt nicht mehr über Komponenten, die im HA (aktiv/passiv oder aktiv-aktiv) arbeiten.

Lastenausgleich oder Failover sollten mittels Drittanbieter-Lösungen (kommerziell oder Open-Source) konfiguriert werden:

• Keepalived (Aktiv/Passiv Failover) auf Linux

• HAProxy (Aktiv/Aktiv L4/L7 Load Balancer)

Die unten aufgeführten Lösungen sind kommerziell, wir können sie nicht empfehlen, aber sie sollten erwähnt werden:

• Citrix

• Kemp

• F5

• Jeder andere (z.B. CISCO) Hardware-Load-Balancer

Die Konfiguration von DS im vollwertigen HA-Modus liegt außerhalb des Zuständigkeitsbereichs des DS-Support-Teams und sollte von den Kunden selbst basierend auf deren eigenen Entscheidungen durchgeführt werden.

Standardmäßig bietet DataSunrise die folgenden HA-Techniken:

• Mehrere DS-Knoten können an einer einzigen Konfigurationsdatenbank arbeiten, wodurch die Notwendigkeit beseitigt wird, jeden Knoten einzeln zu konfigurieren (die Einstellungen werden aus einem gemeinsamen Wörterbuch übernommen)

• Wenn die Hauptverbindung zum Wörterbuch verloren geht, verwenden Sie ein Systemwörterbuch-Backup als Reservekonfigurationsdatenbank. DS überprüft regelmäßig, ob die Wörterbuchverbindung wiederhergestellt ist und schaltet zurück, wenn sie verfügbar ist.

• Wenn eine Audit-Speicherdatenbank nicht verfügbar wird, kann DataSunrise die auditierten Daten in lokal gespeicherten, flachen Dateien schreiben und sie an die Audit-Speicherdatenbank übermitteln, sobald DS feststellt, dass die Konnektivität wiederhergestellt ist.

Nein, wir haben keine Empfehlungen zur zusätzlichen Härtung der Anwendung (Proxy-Endpunkte/Verwaltungskonsole).

In der Regel hängen diese von den Anforderungen ab, die die jeweilige Umgebung/Kunde für die an seinem Standort bereitgestellten Anwendungen hat.

DataSunrise bietet eine Vielzahl zusätzlicher Parameter zur Härtung/Optimierung der Leistung. Diese sind völlig optional und sollten individuell für jeden Fall besprochen und konfiguriert werden.

Nichtsdestotrotz wurden die Standardwerte für die Mehrheit der Parameter in DataSunrise so konfiguriert, dass sie für die meisten Fälle optimal sind.

In Bezug auf die Prozessarchitektur besteht eine DataSunrise-Instanz aus einem Single AppBackendService (oder Backend, kurz BE) und null bis vielen AppFirewallCore (oder kurz Core) Prozessen.

Das Backend ist eine Einheit, die die Konfiguration von DS verwaltet und verschiedene Dienstaufgaben durchführt (Berichte erstellen, Metadaten aktualisieren, SMTP-Alarme senden, Daten entdecken usw.)

Core verarbeitet den von Proxy/Sniffer/Trailing/Agent (TBA) empfangenen Datenverkehr und führt Auditing/Maskierung/Blocking durch.

Der RAM-Verbrauch eines Cores wird durch das Volumen der Metadaten (Tabellen und deren Spaltendetails, Ansichten, Pakete (Oracle), Prozeduren, Funktionen, Synonyme) der Ziel-Datenbank bestimmt, für die dieser Proxy/Sniffer/Trailing/Agent konfiguriert ist: Die Metadaten werden im Cache geladen.

Abgesehen davon speichert DataSunrises Core auch SQL-Abfragen, die im fließenden Datenverkehr erkannt werden, im Cache, um die Verarbeitungsgeschwindigkeit zu erhöhen.

Der Kernspeicherverbrauch steigt auch, wenn die Audit-DB-Server-Spezifikation nicht in der Lage ist, Ereignisse rechtzeitig zu verarbeiten: DataSunrise sendet verarbeitete Ereignisse über eine interne Warteschlange an den Prüfspeicher. Die Verarbeitung erfolgt fast sofort, wenn jedoch die Audit-DB die Ereignisse nicht rechtzeitig verarbeiten kann, können sich die Ereignisse auf der DS-Serverseite ansammeln und zu einem erhöhten RAM-Verbrauch führen, der zurückgeht, sobald die Ereignisse an den Audit-Speicher gesendet werden.

Schließlich wird auch etwas Speicher für Protokollparser-Puffer und für jede Proxy-Verbindung reserviert.

Dann berichtet DataSunrise über den Verbrauch des virtuellen Speichers.

Der virtuelle Speicher entspricht nicht 1:1 oder in einem anderen Verhältnis zum physischen Speicher (RAM).

Dies bedeutet, dass ein hoher virtueller Speicherverbrauch nicht dazu führen kann, dass der DS-Host aufgrund von geringem Speicher abstürzt.

DataSunrise verwendet virtuellen Speicher, um die Zuweisung von virtuellem Speicher für die Laufzeitobjekte zu überwachen, die DS während des Betriebs erzeugt. Wir verwenden diese Metrik, um den Betrieb des DataSunrise-Dienstes auf einem Host zu überwachen und falls der Speicherverbrauch den internen Schwellenwert überschreitet, können die Prozesse automatisch neu gestartet werden.

Bitte beachten Sie die zusätzlichen Parameter MaxCoreMemoryForTerminate oder MaxBackendMemoryForTerminate für den endgültigen Schwellenwert (in Einheiten des virtuellen Speichers), dessen Überschreitung automatisch den DS-Core- oder Backend-Prozess beendet.

Speicherspitzen sind daher in Ordnung, insbesondere wenn Sie die durchschnittliche Hardware-Spezifikation verwenden.

Am wichtigsten ist, dass es nichts zu befürchten gibt, wenn der Speicherverbrauch im Laufe der Zeit zurückgeht.

Wenn jedoch der virtuelle Speicherverbrauch hoch bleibt, auch nach einer intensiven Aktivitätsperiode, könnten Speicherlecks oder andere Aspekte zur Untersuchung verantwortlich sein.

In diesem Fall ist es wichtig, die Protokolldateien aus der Problemumgebung über die Schaltfläche Alles herunterladen zu teilen.

Sie können dies in den Systemeinstellungen -> Protokollierung & Protokolle -> Protokoll-Tab -> Für jeden Server, der in der Dropdown-Liste der Server* verfügbar ist, “Alles herunterladen” tun.

NB: Dadurch wird eine Protokolldatei-Archiv (ZIP) auf Ihren Arbeitsstation heruntergeladen, daher müssen Sie möglicherweise Pop-ups für diesen Vorgang zulassen.

Falls möglich, wird empfohlen, Wege zur Reproduktion des Problems mit anhaltendem Speicherverbrauch zu teilen. Wenn Regeln konfiguriert sind, ist es wichtig, Screenshots Ihrer Regel-Einstellungen bereitzustellen. Die beste Option ist die Verwendung der Wörterbuch-Backup-Option in den Systemeinstellungen -> Allgemein. Beachten Sie, dass eine Sicherungsdatei groß sein kann.

DataSunrise kann auf jeder Standardhardware ausgeführt werden. Es sind keine speziellen Hardwareanforderungen erforderlich. Wenn DataSunrise in der Produktion verwendet werden soll, empfehlen wir Spezifikationen wie die folgenden:

• CPU: 8 Kerne

• RAM: 8-16 GB sind ausreichend

• Keine speziellen Speicheranforderungen

• Verfügbarer Speicherplatz: 100 GB für Daten-Audit

• Betriebssystem: 64-Bit Linux (Red Hat Enterprise Linux 7+, Debian 10+, Ubuntu 18.04 LTS+, Amazon Linux 2) oder 64-Bit Windows Server 2019+

DataSunrise unterstützt Load Balancer. Zum Beispiel unterstützen wir den Classic Load Balancer auf AWS. Sie können auch einen bestimmten Load Balancer verwenden, wenn Sie DataSunrise lokal in einer HA-Konfiguration bereitstellen. DataSunrise unterstützt verschiedene Arten von Load Balancern. Zum Beispiel unterstützt DataSunrise AWS-basierte Anwendungen, die vollständig in den AWS Classic Load Balancer integriert sind. Zusätzlich kann DataSunrise so konfiguriert werden, dass ein bestimmter Load Balancer wie HAProxy usw. verwendet wird. Hinweis: DataSunrise unterstützt Load Balancer nur im HA-Modus.