Approcci di sicurezza nella modellazione dei dati. Parte 3

Questa è la terza della nostra serie in più parti sull'applicazione di approcci alla sicurezza delle informazioni alla modellazione dei dati. La serie utilizza un semplice modello di dati, qualcosa per gestire i club sociali e i gruppi di interesse, per fornire il contenuto che cerchiamo di proteggere. Successivamente tratteremo la modellazione per l'autorizzazione e la gestione degli utenti, nonché altre parti di un'implementazione sicura del database.

Nelle situazioni sociali, è comune "leggere tra le righe", deducendo le ipotesi e le affermazioni non dette in una conversazione. Lo stesso si verifica nella creazione di software e nella memorizzazione dei dati in un database. Le fatture vengono enumerate con l'ID cliente incorporato e quante entità di dati utilizzano una data e ora come parte della chiave? È difficile immaginare di documentare o strutturare tutto a fondo senza qualche tipo di omissione. Ma nella nostra ultima puntata, abbiamo svolto esattamente quell'esercizio. Siamo stati in grado di attribuire sensibilità a diverse parti del database del nostro social club. Ma per quantificare e gestire tale sensibilità, dobbiamo aumentare la struttura del nostro modello di dati in modo da rendere chiari i dati sensibili e le relative relazioni.

Colmare le lacune del modello di dati

La modellazione dei dati per la sicurezza richiede diverse varietà distinte di modifiche alla struttura. Stiamo esplorando questi a nostra volta, utilizzando un (molto!) semplice modello di dati di social club come base per questa serie. Man mano che procedevamo, abbiamo migliorato il modello con più dati. Nell'ultima puntata, abbiamo analizzato il modello per attribuire la sensibilità ai dati dove l'abbiamo trovato. Questa analisi anche ha rivelato che c'erano punti in cui il modello di dati indicava collegamenti che non erano stati effettivamente acquisiti in modo esplicito nelle colonne e nelle relazioni chiave. Il modellatore dovrebbe aspettarselo in un'analisi di sicurezza. Andando avanti da queste scoperte, renderemo queste relazioni il più concrete e chiare possibile costruendo le tabelle e le connessioni tra di esse. Questo ci consentirà di allegare attributi di sicurezza più avanti.

Costruire le relazioni di dati nel club

Tutte le relazioni nei dati, così come le stesse entità di dati, devono avere una rappresentazione per attribuirvi valore o sensibilità. A tale scopo potrebbero essere necessarie nuove colonne, nuove chiavi, nuovi riferimenti e persino nuove tabelle. Quando abbiamo analizzato le tabelle e le loro relazioni nel nostro ultimo post, abbiamo isolato due tabelle principali con dati ad alta sensibilità:

• Person
• Photo

Inoltre, ne avevamo quattro contenenti dati moderatamente sensibili:

• Member
• Club
• Office
• Club_Office

Questi aspetti della sensibilità sono in parte intrinseci a ciascuna tabella, ma le relazioni non esplicite portano gran parte della sensibilità. Per allegarlo, iniziamo a registrare le relazioni e diamo loro una struttura per contenere la sensibilità.

Relazioni incorporate nelle foto

Photo contiene molte relazioni incorporate che dobbiamo acquisire. Principalmente, siamo interessati al rapporto con Person . Per catturare la relazione Persona-Foto, aggiungo il Photo_Content tabella:

Ci sono molti aspetti diversi per cui una Person potrebbe riguardare una Photo . Ho deciso di aggiungere una nuova tabella, Photo_Content_Role , per caratterizzare il rapporto di una Foto con una Persona. Invece di avere tabelle separate per ogni tipo di relazione, utilizziamo una singola tabella di connessione e la tabella Photo_Content_Role. Questa tabella è un elenco di riferimento con relazioni standard come quelle che abbiamo già notato. Ecco la nostra serie iniziale di dati per Photo_Content_Role :

OK, quindi questo è un bait-and-switch. Ho detto Photo_Content metterebbe in relazione persone alle foto, quindi perché c'è qualcosa su "oggetto raffigurato"? Logicamente, ci saranno foto in cui descriveremmo il contenuto senza identificare una Persona . Dovrei aggiungere un'altra tabella per questo, con un insieme separato di ruoli di contenuto? Ho deciso di no. Invece, aggiungerò una riga di persona nulla a Person tabella come dati seme e il contenuto non personale si riferisce a quella persona. (Sì, programmatori, è un po' più di lavoro. Prego.) La "persona nulla" avrà id zero (0).

Apprendimento chiave n. 1:

Riduci al minimo le tabelle con dati sensibili sovrapponendo strutture di relazioni simili in un'unica tabella.

Prevedo che potrebbero esserci ulteriori relazioni che verranno scoperte a valle. Ed è anche possibile che un social club abbia i propri ruoli da attribuire a una Persona in una Foto . Per questo motivo, ho utilizzato una chiave primaria surrogata "pura" per Photo_Content_Role e ha anche aggiunto una chiave esterna facoltativa a Club . Questo ci consentirà di supportare usi speciali da parte dei singoli club. Chiamo il campo "esclusivo" per indicare che non dovrebbe essere disponibile per altri club.

Apprendimento chiave n. 2:

Quando gli utenti finali potrebbero estendere un elenco integrato, assegna alla sua tabella una chiave surrogata pura per evitare collisioni di dati.

Photo_Content_Role.max_per_person può anche essere misterioso. Non puoi vederlo nel diagramma, ma Photo_Content_Role.id porta il suo vincolo unico senza max_per_person . In sostanza, la vera chiave primaria è solo id . Aggiungendo max_per_person a id nella chiave primaria, forzo ogni tabella di riferimento ad assorbire le informazioni con le quali può (dovrebbe!) imporre un vincolo di verifica della cardinalità. Ecco il vincolo di controllo in Photo_Content .

Apprendimento chiave n. 3:

Quando ogni riga di una tabella ha restrizioni individuali, le tabelle di riferimento devono aggiungere un nuovo vincolo univoco, estendendo una chiave naturale con i campi del vincolo. Chiedi alla tabella figlio di fare riferimento a quella chiave.

Diamo un'occhiata a Photo_Content . Questa è principalmente una relazione tra Photo e Person , con la relazione specificata dal ruolo contenuto allegato. Come ho notato prima, tuttavia, è qui che memorizziamo tutto informazioni descrittive sulla foto. Per soddisfare questo tipo di apertura, abbiamo il content_headline opzionale e content_detailed colonne. Questi saranno raramente necessari per un'associazione ordinaria tra una Persona e una Foto. Ma un titolo come "Bob Januskis riceve l'Annual Achievement Award" è facile da prevedere. Inoltre, se non è presente alcuna Persona:"Oggetto raffigurato", Persona 0 — dobbiamo richiedere qualcosa nel content_headline , come ad esempio "pendio nord-ovest del monte Ararat".

L'ultima relazione con le foto scomparse:gli album

Finora, non abbiamo aggiunto nulla che riguardi Photo s a Photo S. È una cosa importante per i social network e i servizi fotografici:Album S. E non li vorresti nella proverbiale scatola da scarpe, vero? Quindi colmiamo questa lacuna evidente, ma pensiamo anche a questo.

Album allega Photo s in un modo diverso rispetto alle altre relazioni che abbiamo trattato. Photo I messaggi possono essere associati allo stesso club, a una data simile, alle coordinate GPS nelle vicinanze, allo stesso fotografo e così via. Tuttavia, Album indica chiaramente che la Photo Le s fanno parte di un singolo argomento o storia. Pertanto, gli aspetti rilevanti per la sicurezza di una Photo può essere dedotto da un altro nell'Album . Inoltre, l'ordinamento può amplificare o diminuire tali inferenze. Quindi non pensare solo a Album come una collezione innocua. Photo s è tutt'altro.

Sebbene non innocuo dal punto di vista della sicurezza, Album è un'entità semplice con un puro Id chiave surrogata di proprietà di un Club (non una Person ). Album_Photo ci fornisce una serie di Photo s sequenziato da Photo_Order . Noterai che ho creato l'Album id e order la chiave primaria. La relazione è davvero tra la Photo e l'Album , quindi perché non renderle la chiave primaria? Perché casi strani che richiedono una Photo da ripetere in un Album sono certamente possibili. Quindi ho messo Photo_Order nella chiave primaria e, dopo aver riflettuto un po', ha deciso di aggiungere una chiave univoca alternativa con album e foto per evitare una Photo dalla ripetizione in un Album . Se basta piangere per ripetere una Photo in un Album sorge, una chiave univoca è più facile da rimuovere rispetto a una chiave primaria.

Apprendimento chiave n. 4:

Per la chiave primaria, seleziona una chiave candidata con il minor rischio di essere scartata in seguito.

Metadati delle foto

L'ultima informazione potenzialmente sensibile da aggiungere sono i metadati (di solito creati da qualsiasi dispositivo abbia scattato le foto). Questi dati non parte di una relazione, ma è intrinseca alla foto. La definizione principale delle informazioni che una fotocamera memorizza con una foto è EXIF, uno standard industriale giapponese (JEITA). EXIF è estensibile e può supportare decine o centinaia di campi, nessuno dei quali può essere richiesto dalle nostre immagini caricate. Questo stato non obbligatorio è dovuto al fatto che questi campi non sono comuni a tutti i formati di foto e possono essere cancellati prima del caricamento. Ho creato Photo con molti campi di uso comune, tra cui:

• camera_mfr
• modello_fotocamera
• versione_software_fotocamera
• risoluzione_immagine_x
• risoluzione_immagine_y
• unità_risoluzione_immagine
• tempo_di_esposizione_immagine
• camera_aperture_f
• GPSLatitude
• GPSLongitudine
• Altitudine GPS

I campi GPS sono, naturalmente, quelli che aggiungono la più alta sensibilità a una Photo .

Il nostro modello, con tutti i dati sensibili e di valore definiti

Con queste modifiche completiamo questa fase di protezione del database del club. Sono presenti tutti i collegamenti e i dati aggiuntivi necessari, come illustrato di seguito. Ho creato Photo informazioni rosse e Album turchese chiaro per trasmettere la mia idea di raggruppamenti logici. L'aumento degli elementi di dati è reale, ma molto ridotto al minimo.

Conclusione

Mettere qualsiasi modello di dati su una buona base di sicurezza richiede un'applicazione ordinata e sistematica dei principi di sicurezza e della pratica dei database relazionali. In questa puntata, abbiamo esaminato il modello di dati e compilato accuratamente la struttura mancante che era implicita, ma non espressa nello schema. Non potremmo assegnare valore o fornire protezione ai dati esistenti senza aggiungere i dati che li riempiono e li legano correttamente insieme. Con questo in atto, procederemo ad allegare gli elementi di valutazione e sensibilità dei dati che ci consentiranno di vedere chiaramente tutti i dati da una prospettiva di sicurezza completa. Ma questo è nel nostro prossimo articolo.