Häufig gestellte Fragen

Nein, DS verfügt nicht über derartige Fähigkeiten. Es ist zu beachten, dass DS eine Datenbanksicherheitslösung ist und keine WAF (Web Application Firewall). DataSunrise schützt Datenbanken, nicht die auf diesen laufenden Anwendungen.

Das Einzige, was als eine Art virtuelles Patchen verwendet werden könnte, ist die SQL Injection Prevention Security Rule, da ein SQL-Injection-Angriff normalerweise in der Anwendungsebene durchgeführt wird, indem ein Angreifer ein schlechtes Anwendungsdesign ausnutzt, das es ihm ermöglicht, bösartige SQL-Befehle zusammen mit nicht parametrisierten oder nicht maskierten Anfrageparametern zu senden.

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

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

DataSunrise ist nur in der Lage, Schwachstellen und Fehlkonfigurationen zu finden und deren Behebung vorzuschlagen, sofern diese mittels SQL-Schnittstellenbefehlen diagnostiziert und behoben werden können.

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

Load Balancing oder Failover sollte mithilfe von Drittanbieterlösungen (kommerziell oder Open-Source) konfiguriert werden:

• Keepalived (Aktiv/Passiv HA-Failover) unter Linux

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

Die nachfolgend genannten 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-Supportteams und sollte von den Kunden selbst basierend auf deren eigenen Entscheidungen vorgenommen werden.

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

• Mehrere DS-Knoten können mit einer einzigen Konfigurationsdatenbank arbeiten, wodurch die Notwendigkeit entfällt, jeden Knoten einzeln zu konfigurieren (die Einstellungen werden aus einem gemeinsamen Dictionary übernommen)

• Falls die Hauptverbindung zum Dictionary verloren geht, wird ein System Dictionary Backup als Reservekonfigurationsdatenbank verwendet. DS prüft in regelmäßigen Abständen, ob die Dictionary-Verbindung wiederhergestellt wurde, und schaltet zurück, sobald sie verfügbar ist.

• Wenn eine Audit Storage-Datenbank nicht verfügbar wird, ist DataSunrise in der Lage, auditierte Daten in lokal gespeicherten Flat Files zu schreiben und diese an die Audit Storage-Datenbank weiterzuleiten, sobald DS feststellt, dass die Konnektivität wiederhergestellt ist.

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

In der Regel hängen diese von den Anforderungen der jeweiligen Umgebung bzw. des Kunden ab, in der die Anwendungen bereitgestellt werden.

DataSunrise bietet eine große Auswahl zusätzlicher Parameter zur Härtung bzw. zur Leistungsoptimierung. Diese sind vollständig 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 in den meisten Fällen optimal sind.

Hinsichtlich der Prozessarchitektur besteht eine DataSunrise-Instanz aus einem einzelnen AppBackendService (oder kurz Backend, BE) und aus null bis vielen AppFirewallCore (oder kurz Core) Prozessen.

Der Backend ist eine Entität, die die Konfiguration von DS verwaltet und verschiedene Hilfsaufgaben ausführt (Erstellen von Berichten, Aktualisierung von Metadaten, Versenden von SMTP-Warnungen, Durchführen von Data Discovery usw.).

Der Core verarbeitet den von Proxy/Sniffer/Trailing/Agent empfangenen Traffic und führt Auditing/Maskierung/Blocking durch.

Der vom Core verbrauchte Arbeitsspeicher wird durch das Volumen der Metadaten (Tabellen und ihre Spalteninformationen, Views, Pakete (Oracle), Prozeduren, Funktionen, Synonyme) der Ziel-Datenbank bestimmt, für die dieser Proxy/Sniffer/Trailing/Agent konfiguriert ist: Die Metadaten werden in den Cache geladen.

Darüber hinaus cached der Core von DataSunrise auch SQL-Abfragen, die im durchlaufenden Traffic erkannt werden, um die Verarbeitungsgeschwindigkeit zu erhöhen.

Der Core-Speicherverbrauch steigt auch, wenn die Spezifikationen des Audit-DB-Servers nicht in der Lage sind, Ereignisse rechtzeitig zu verarbeiten: DataSunrise sendet verarbeitete Ereignisse über eine interne Warteschlange an den Audit Storage. Die Verarbeitung erfolgt nahezu sofort; falls der Audit-DB-Server die Ereignisse nicht rechtzeitig verarbeiten kann, können sich die Ereignisse am DS-Server anhäufen und den RAM-Verbrauch erhöhen, was wieder abnimmt, sobald die Ereignisse an den Audit Storage übermittelt werden.

Abschließend wird etwas Speicher für Protokollparser-Puffer und für jede Proxy-Verbindung reserviert.

Anschließend berichtet DataSunrise über den Verbrauch des virtuellen Speichers.

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

Das bedeutet, dass ein hoher Verbrauch an virtuellem Speicher nicht dazu führen kann, dass der DS-Host aufgrund von Speichermangel abstürzt.

DataSunrise verwendet den virtuellen Speicher, um die Zuweisung des virtuellen Speichers für die zur Laufzeit gestarteten Objekte zu überwachen. Wir nutzen diesen Wert, um den Betrieb des DataSunrise-Dienstes auf einem Host zu überwachen, und falls der Speicherverbrauch einen internen Schwellenwert überschreitet, können die Prozesse automatisch neu gestartet werden.

Bitte beachten Sie den Additional Parameter MaxCoreMemoryForTerminate oder MaxBackendMemoryForTerminate für den endgültigen Schwellenwert (in Einheiten virtuellen Speichers), dessen Überschreiten den DS Core- oder Backend-Prozess automatisch beendet.

Daher sind Speicherspitzen in Ordnung, besonders wenn Sie durchschnittliche Hardware-Spezifikationen verwenden.

Am wichtigsten ist, dass, wenn der Speicherverbrauch im Laufe der Zeit wieder abnimmt, kein Anlass zur Sorge besteht.

Falls der virtuelle Speicherverbrauch jedoch nach einer intensiven Aktivitätsphase hoch bleibt, könnten Speicherlecks oder andere Aspekte vorliegen, die untersucht werden sollten.

In diesem Fall ist es wichtig, die Logdateien der betroffenen Umgebung mithilfe des Download All-Buttons zu übermitteln.

Dies können Sie unter System Settings -> Logging & Logs -> Logs Tab -> Für jeden Server in der Drop-down-Liste Servers* mittels “Download All” tun.

NB: Dies führt dazu, dass ein Logdateiarchiv (ZIP) auf Ihren Arbeitsplatz heruntergeladen wird; daher müssen Sie möglicherweise Pop-ups für diesen Vorgang zulassen.

Wenn möglich, wird empfohlen, Wege zur Reproduktion des Problems des anhaltend hohen Speicherverbrauchs aufzuzeigen. Falls Regeln konfiguriert sind, ist es wichtig, Screenshots der Einstellungen Ihrer Regeln bereitzustellen. Die beste Option ist es, die Dictionary-Backup-Option unter System Settings -> General zu verwenden. Beachten Sie, dass eine Backup-Datei groß sein kann.

DataSunrise kann auf jeder handelsüblichen Hardware betrieben werden. Es werden keine speziellen Hardwareanforderungen gestellt. Wenn DataSunrise in der Produktion eingesetzt wird, empfehlen wir etwa folgende Spezifikationen:

• CPU: 8 Kerne

• RAM: 8-16GB sind ausreichend

• Keine speziellen Speicheranforderungen

• Verfügbarer Festplattenspeicher: 100 GB für die 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 DataSunrise vor Ort in einer HA-Konfiguration eingesetzt wird. DataSunrise unterstützt verschiedene Arten von Load Balancern. So unterstützt DataSunrise beispielsweise 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 verwendet wird, etc. Hinweis: DataSunrise unterstützt Load Balancer nur im HA-Modus.