Domande Frequenti
Ottieni risposte alle domande più frequenti
DataSunrise ha capacità di patching virtuale per le applicazioni che protegge?
No, DataSunrise non ha tali capacità. Si noti che DataSunrise è una soluzione di Sicurezza nel Database e non un WAF (Web Application Firewall). DataSunrise protegge i database, non le applicazioni che girano sopra i database.
L’unica cosa che può essere utilizzata come una sorta di patching virtuale è la SQL Injection Prevention Security Rule poiché l’attacco SQL injection viene solitamente eseguito a livello dell’applicazione sfruttando un design applicativo scadente che consente a un malintenzionato di inviare comandi SQL dannosi insieme a parametri di richiesta non parametrizzati o non protetti.
Il Scanner per la Valutazione delle Vulnerabilità (VA) di DataSunrise esegue patching reale o virtuale delle vulnerabilità trovate?
No, il Scanner VA di DataSunrise può essere utilizzato solo a scopo di reportistica e non esegue alcun patching come parte della logica operativa del Scanner VA.
Tuttavia, per la gamma selezionata di motori e versioni DBMS, DataSunrise può fornire una lista di azioni da eseguire per rafforzare il DBMS dagli standard di sicurezza CIS e STIG.
DataSunrise è in grado solo di trovare e suggerire la correzione delle vulnerabilità e delle configurazioni errate diagnosticate e correggibili tramite comandi dell’interfaccia SQL.
DataSunrise ha un failover o un Load Balancer nativo o integrato per la modalità di Alta Disponibilità? Cosa offre DS come HA out-of-the-box?
DataSunrise non ha più componenti per lavorare in modalità HA (attivo/passivo o attivo/attivo).
Il bilanciamento del carico o il failover devono essere configurati utilizzando soluzioni di terze parti (commerciali o open-source):
Keepalived (Active/Passive HA failover) su Linux
HAProxy (Active/Active L4/L7 Load Balancer)
Le soluzioni menzionate qui sotto sono commerciali, non possiamo raccomandarle ma dovrebbero essere citate:
Citrix
Kemp
F5
Altre soluzioni hardware per il bilanciamento del carico (es. CISCO)
La configurazione di DataSunrise in modalità HA completa esula dalle competenze del team di supporto di DataSunrise e deve essere eseguita dai clienti stessi basandosi sulle proprie decisioni.
Per impostazione predefinita, DataSunrise offre le seguenti tecniche HA:
Più nodi DataSunrise possono lavorare su un singolo database di configurazione mitigando la necessità di configurare ogni nodo separatamente (le impostazioni vengono prese da un Dictionary condiviso)
Nel caso in cui la connessione al Dictionary principale venga persa, utilizzare un System Dictionary Backup come database di configurazione di riserva. DataSunrise controlla periodicamente se la connessione al Dictionary è stata ripristinata e ritorna alla connessione principale quando è disponibile.
Se un database di Storage di Audit diventa indisponibile, DataSunrise è in grado di scrivere i dati di audit in file flat memorizzati localmente e di trasferirli al database di Storage di Audit non appena DataSunrise scopre che la connettività è stata ripristinata.
Esistono delle best practice per l’indurimento delle applicazioni DataSunrise? Management Console o Proxies?
No, non abbiamo raccomandazioni per l’indurimento aggiuntivo dell’applicazione (Proxy Endpoints/Management console).
Di solito, queste dipendono dai requisiti specifici dell’ambiente del cliente per le applicazioni implementate sul proprio sito.
DataSunrise offre una vasta gamma di Parametri Aggiuntivi per l’ottimizzazione delle prestazioni/l’indurimento. Questi sono totalmente opzionali e devono essere configurati caso per caso.
Ciononostante, i valori predefiniti per la maggior parte dei parametri in DataSunrise sono stati configurati per essere ottimali nella maggior parte dei casi.
Cosa comporta il consumo di memoria core?
In termini di architettura dei processi, un’istanza di DataSunrise consiste di un singolo AppBackendService (o Backend, BE in breve) e da zero a molti processi AppFirewallCore (o Core in breve).
Il Backend è un’entità che gestisce la configurazione di DataSunrise e esegue diverse attività di utilità (generazione di report, aggiornamento dei metadati, invio di alert SMTP, esecuzione di Data Discovery, ecc.)
Il Core elabora il traffico ricevuto da Proxy/Sniffer/Trailing/Agent (TBA) e si occupa di Audit/Mascheramento/Blocco.
La RAM consumata da un Core è determinata dal volume dei metadati (tabelle e dettagli delle loro colonne, viste, pacchetti (Oracle), procedure, funzioni, sinonimi) del Database di Destinazione per cui questo Proxy/Sniffer/Trailing/Agent è configurato: i metadati vengono caricati nella cache.
Oltre a ciò, il Core di DataSunrise memorizza anche le query SQL riconosciute nel traffico in transito per accelerare la velocità di elaborazione.
Il consumo di memoria del Core aumenta anche se il server di Audit DB non è in grado di gestire gli eventi in tempo: DataSunrise manda eventi elaborati allo Storage di Audit tramite una coda interna. L’elaborazione avviene quasi immediatamente, tuttavia se il server di Audit DB non è in grado di elaborare gli eventi tempestivamente, gli eventi possono accumularsi dal lato del server DataSunrise e causare un aumento del consumo di RAM che diminuisce quando gli eventi vengono inviati allo Storage di Audit.
Infine, una parte della memoria è riservata per i buffer del parser di protocollo e per ogni connessione proxy.
Poi, DataSunrise segnala il consumo di Memoria Virtuale.
La memoria virtuale non corrisponde 1:1 o a qualsiasi altro rapporto con la Memoria Fisica (RAM).
Questo significa che un alto consumo di Memoria Virtuale non può causare il crash dell’host di DataSunrise a causa della bassa memoria.
DataSunrise usa la Memoria Virtuale per monitorare l’allocazione della Memoria Virtuale per gli oggetti runtime che DataSunrise genera durante l’operazione. Usiamo questa metrica per monitorare l’operazione del servizio DataSunrise su un host e nel caso in cui il consumo di memoria superi una soglia interna i processi possono essere riavviati automaticamente.
Fare riferimento ai parametri aggiuntivi MaxCoreMemoryForTerminate o MaxBackendMemoryForTerminate per la soglia ultima (in unità di Memoria Virtuale) il cui superamento forza automaticamente la terminazione del processo Core o Backend di DataSunrise.
Pertanto, i picchi di memoria sono normali specialmente quando si utilizzano specifiche hardware medie.
È più importante che, se il consumo di memoria diminuisce nel tempo, non vi sia nulla di cui preoccuparsi.
Tuttavia, se il consumo di memoria virtuale rimane alto dopo un periodo di attività intensa, potrebbero esserci perdite di memoria o altri aspetti da esaminare.
In tal caso, è importante condividere i file di log dall’ambiente problematico utilizzando il pulsante Scarica Tutto.
Può fare questo in Impostazioni di Sistema -> Log & Tracciamento -> Scheda Log -> Per ogni Server disponibile dalla lista a tendina dei Server “Scarica Tutto”.
NB: questo genera un archivio di file di log (ZIP) da scaricare sulla tua workstation, quindi potrebbe essere necessario abilitare i pop-up per questa operazione.
Se possibile, si consiglia di condividere i modi per riprodurre il problema del consumo di memoria persistente. Se ci sono Regole configurate, è importante fornire gli screenshot delle impostazioni delle tue Regole. La migliore opzione è utilizzare l’opzione di backup del Dictionary in Impostazioni di Sistema -> Generale. Nota che un file di backup può essere grande.
Quali sono i requisiti di sistema per il DataSunrise Database Security Suite?
DataSunrise può essere eseguito su qualsiasi hardware di uso comune. Nessun requisito hardware speciale. Se DataSunrise deve essere utilizzato in produzione, suggeriamo specifiche come le seguenti:
CPU: 8 core
RAM: 8-16GB sono sufficienti
Nessun requisito di storage speciale
Spazio su disco disponibile: 100 GB per l’audit dei dati
Sistema operativo: Linux 64-bit (Red Hat Enterprise Linux 7+, Debian 10+, Ubuntu 18.04 LTS+, Amazon Linux 2) o Windows Server 64-bit 2019+
DataSunrise può essere abbinato ai load balancer?
DataSunrise supporta i load balancer. Ad esempio, supportiamo il Classic Load Balancer di AWS. Puoi anche utilizzare un determinato load balancer durante il deployment di DataSunrise on-premises in una configurazione HA. DataSunrise supporta diversi tipi di load balancer. Ad esempio, DataSunrise supporta le applicazioni basate su AWS essendo completamente integrato con AWS Classic Load Balancer. Inoltre, DataSunrise può essere configurato per utilizzare un determinato load balancer come HAProxy, ecc. Nota: DataSunrise supporta i load balancer solo quando è in modalità HA.