MongoDB Queryable Encryption: le query di prefisso, suffisso e sottostringa sono ora GA

La scorsa settimana, abbiamo annunciato la disponibilità generale del supporto per le query di prefisso, suffisso e sottostringa in Queryable Encryption di MongoDB. Queste funzionalità estendono Queryable Encryption oltre le query di uguaglianza e di intervallo e sono ora completamente supportate per i carichi di lavoro di produzione.

MongoDB Queryable Encryption è una tecnologia di crittografia in uso innovativa, la prima nel settore, sviluppata dal MongoDB Cryptography Research Group. Consente ai clienti di crittografare i dati applicativi sensibili, di memorizzarli in modo sicuro in formato crittografato su MongoDB e di eseguire query complesse direttamente sui dati crittografati senza decrittografarli. Il database non vede mai i dati in chiaro.

Le organizzazioni possono ora eseguire ricerche testuali flessibili, che corrispondono a nomi parziali, parole o identificatori, sui dati crittografati in produzione, mantenendo le informazioni sottostanti protette dalla progettazione, in base a garanzie di sicurezza chiaramente definite. Ciò significa una maggiore protezione dei dati, una conformità più semplice e nessuna necessità di soluzioni alternative come gli indici di ricerca esterni. Il tutto con modifiche minime al codice e nessuna nuova infrastruttura.

Con il supporto per le query di prefisso, suffisso e sottostringa ora generalmente disponibile in Queryable Encryption, MongoDB consente alle organizzazioni di proteggere i dati sensibili durante tutto il loro ciclo di vita: inattivi, in transito e in uso. Di conseguenza, i team possono creare applicazioni sicure e che preservano la privacy senza compromettere la funzionalità. Queryable Encryption è disponibile senza costi aggiuntivi in MongoDB Atlas, MongoDB Enterprise Advanced e MongoDB Community Edition.

La sfida: i dati sono protetti solo finché non è necessario utilizzarli

La maggior parte delle organizzazioni archivia dati sensibili: informazioni di identificazione personale (PII) come nomi e numeri di previdenza sociale, o informazioni sanitarie protette (PHI) come cartelle cliniche. Mantenere tali dati al sicuro mentre sono in archivio o si spostano attraverso una rete è una pratica consolidata. La crittografia dei dati inattivi e in transito è oggi una pratica standard.

Eseguire query su tali dati è un altro paio di maniche. La crittografia tradizionale rende i dati illeggibili, il che significa che un database non può cercarli senza prima decrittografarli. Si consideri un fornitore di assistenza sanitaria che deve trovare tutti i pazienti con una diagnosi contenente la parola "edema"; senza decrittografare le cartelle cliniche, il database non può cercare tale termine.

Per risolvere questo problema, molte organizzazioni lasciano i campi sensibili non crittografati o creano indice di ricerca esterni per consentire le query di cui le loro applicazioni hanno bisogno. Entrambi gli approcci aggiungono costi generali operativi. Entrambi aumentano inoltre il rischio di accesso non autorizzato, proprio nel momento in cui i dati sensibili sono maggiormente esposti.

Questo diventa più difficile a causa della pressione normativa. Standard come l'Health Insurance Portability and Accountability Act (HIPAA), lo Standard di sicurezza dei dati del settore delle carte di pagamento (PCI-DSS) e il Regolamento generale sulla protezione dei dati (GDPR) prevedono sempre più spesso che le organizzazioni dimostrino che i dati sensibili rimangono protetti in ogni fase, non solo inattivi e in transito. Fornire protezione mentre i dati sono attivamente in uso è l'aspetto che la maggior parte degli approcci di crittografia non riesce a risolvere.

Per proteggere appieno i dati sensibili e rispettare i requisiti di conformità, le organizzazioni hanno bisogno di un modo per eseguire ricerche sui dati crittografati senza decrittografarli, senza sacrificare le prestazioni o aggiungere nuove infrastrutture.

Protezione dei dati a esposizione zero

MongoDB Queryable Encryption è stato creato per colmare questa lacuna. Mantiene i dati sensibili crittografati mentre vengono ricercati attivamente, l'unica fase che altri metodi di crittografia non possono raggiungere.

Con Queryable Encryption, i campi sensibili non vengono mai archiviati, trasmessi, elaborati o restituiti in testo normale, nemmeno sul server del database stesso. Le query vengono eseguite su dati crittografati. Non c'è decrittografia e non c'è nessuna finestra in cui i dati sono esposti.

Questo è possibile perché Queryable Encryption si basa su uno schema di crittografia strutturato che mantiene i dati crittografati durante l'elaborazione delle query sul server in ogni momento. Lo schema è interamente open source e verificabile in modo indipendente, non una dichiarazione del fornitore di tipo black-box. Si tratta di un approccio unico nel settore: nessun'altra tecnologia di database offre oggi questo livello di crittografia durante l'uso e non dipende da hardware specializzato come gli enclave sicuri.

Le organizzazioni si affidano già a Queryable Encryption per proteggere alcuni dei loro dati più sensibili. Le forze di sicurezza interne francesi (ANFSI) vi si affidano per proteggere i documenti riservati, supportati da una revisione di sicurezza governativa.

Per i team che gestiscono dati PII, PHI o altri dati regolamentati, ciò significa un posto in meno in cui le informazioni sensibili possono essere esposte, anche da parte di persone interne con accesso diretto al database.

Ricerca più espressiva, integrata

Fino ad ora, Queryable Encryption ha supportato query di uguaglianza e di intervallo nella disponibilità generale. Ciò copriva le corrispondenze esatte e le ricerche numeriche limitate, ma le applicazioni hanno spesso bisogno di qualcosa di più flessibile: ricerche parziali di nomi, completamento automatico o filtraggio di parole parziali. Con le query di prefisso, suffisso e sottostringa ora generalmente disponibili, tale lacuna è colmata.

Ecco cosa è ora possibile fare direttamente sui campi crittografati:

• Le query di prefisso restituiscono i documenti in cui il valore di un campo inizia con una specifica sequenza di caratteri. Per esempio, trovare tutti i clienti il cui cognome inizia con "Mac".

• Le query di suffisso restituiscono i documenti in cui il valore di un campo termina con una sequenza specifica. Ad esempio, la corrispondenza delle ultime quattro cifre di un numero di previdenza sociale crittografato.

• Le query di sottostringa restituiscono documenti in cui una sequenza specifica appare ovunque nel campo. La ricerca per sottostringa copre campi brevi e strutturati fino a 50 caratteri, cercando termini da 2 a 6 caratteri. Ad esempio, cercando "eng" all'interno di un campo crittografato del titolo di lavoro, corrispondente sia a "Ingegnere" che a "Responsabile di ingegneria".

• Le query di intervallo (esistenti) restituiscono documenti in cui un valore di campo rientra in un limite superiore e inferiore specificato, come un intervallo di stipendio crittografato.

• Le query di uguaglianza (esistenti) restituiscono documenti in cui un valore di campo corrisponde esattamente, come uno specifico indirizzo email crittografato.

Questi tipi di query vengono eseguiti tramite il motore di query e i driver native di MongoDB, gli stessi utilizzati per ogni altro tipo di query. Non ci sono indice di ricerca esterni da creare, nessun middleware da mantenere e modifiche minime al codice dell'applicazione. I team ottengono una ricerca espressiva e con corrispondenza parziale su dati crittografati utilizzando la stessa architettura che già utilizzano.

Conformità che puoi provare, non solo dichiarare

Soddisfare requisiti come HIPAA, PCI-DSS e GDPR significa dimostrare che i dati sensibili sono protetti, non solo affermarlo. Questo è difficile quando i reclami relativi alla crittografia non possono essere verificati in modo indipendente, e ancora più difficile quando il reclamo non copre i dati mentre sono attivamente in uso.

Queryable Encryption offre ai team di conformità e gestione del rischio una risposta difendibile. Il suo schema di crittografia strutturato è interamente open source, quindi la crittografia sottostante può essere esaminata in modo indipendente anziché accettata sulla fiducia. E poiché protegge i dati attraverso l'elaborazione delle query, non solo a riposo e in transito, risolve una fase che la maggior parte dei programmi di conformità non può altrimenti gestire.

Con le query di prefisso, suffisso e sottostringa ora generalmente disponibili, quella stessa prova si estende a più casi d'uso: ricerca parziale di nomi ed email, filtro parziale di parole in campi di testo libero e corrispondenza parziale di ID. Il risultato è un minor numero di lacune di controllo e un minor numero di strumenti frammentati da conciliare, indipendentemente dal fatto che i carichi di lavoro siano eseguiti in locale, in un ambiente ibrido o su più cloud.

Cosa possono ora costruire i team

Con le query di prefisso, suffisso e sottostringa generalmente disponibili in Queryable Encryption, ecco alcuni esempi di ciò che le organizzazioni possono ora ottenere:

• Ricerca PII per conformità e usabilità: Regolamenti come GDPR e HIPAA impongono una rigorosa privacy delle informazioni personali. Con le query di prefisso, i team possono recuperare gli utenti per cognome o prefisso email mantenendo i dati sottostanti crittografati. Ciò rende la conformità più semplice senza sacrificare la funzionalità di ricerca.

• Filtro parziale delle parole sui campi strutturati: I campi strutturati come le diagnosi richiedono spesso una corrispondenza parziale. Con il supporto alle query delle sottostringhe, i team possono cercare un campo di condizioni di salute crittografato per un termine come "diabet," corrispondente sia a "diabete" che "diabetico."

• Convalida sicura dell'ID: I flussi di lavoro di identità si basano spesso su identificatori parziali, come le ultime quattro cifre di un numero di previdenza sociale, un numero di assicurazione nazionale o un numero Aadhaar. Le query di suffisso abilitano queste ricerche su campi crittografati senza rivelare i valori completi, riducendo il rischio di perdite di dati in ambienti regolamentati.

• Gestione dei casi per le agenzie pubbliche: i numeri dei casi e gli ID di riferimento nelle applicazioni del settore pubblico seguono spesso formati strutturati. Le query di prefisso consentono alle agenzie di recuperare i record utilizzando prefissi basati su regione o ufficio, come "NYC-" o "EUR-, " senza esporre metadati di casi sensibili.

Inizia a usare Queryable Encryption

Le query di prefisso, suffisso e sottostringa offrono ai team un nuovo livello di flessibilità nella ricerca di dati sensibili senza richiedere loro di scegliere tra sicurezza e funzionalità. Che l'obiettivo sia soddisfare i requisiti di conformità, ridurre la complessità dell'infrastruttura o semplicemente creare applicazioni migliori, queste funzionalità sono pronte per la produzione oggi.

Le query di prefisso, suffisso e sottostringa offrono ai team un nuovo livello di flessibilità nella ricerca di dati sensibili. Questi nuovi tipi di query aiutano a proteggere i dati sensibili dall'accesso non autorizzato e a soddisfare i requisiti di conformità, riducendo al contempo la complessità infrastrutturale e operativa.