Violazione della riservatezza e dell'integrità nella sicurezza del database

1) If we consider knowing the availability of data is a type of confidentiality disclosure?

Sì, conoscere la disponibilità dei dati è un tipo di violazione della riservatezza. Esempio è un messaggio di errore che rivela se esiste o meno un nome utente nel database.

2) What is the referential integrity problem in database security?

Affinché gli elementi del database siano costantemente sincronizzati, più tabelle che separano i dati relativi a un singolo attributo devono essere collegate correttamente. In altre parole, non dovrebbe esistere alcun set di dati non autorizzati.

Supponiamo di avere un'applicazione con due tabelle di database user_credentials & user_activity .

user_credentials ha colonne user_name e user_passwd . user_activity ha user_name & user_lastlogintime .

L'integrità referenziale è la proprietà con cui entrambe le tabelle hanno esattamente tutti gli stessi valori nel campo user_name . Ciò garantisce coerenza nell'accesso o nella rimozione degli elementi della tabella.

3) Can confidentiality violation lead to integrity violation?

È possibile. Ma entrambi devono essere considerati separatamente. Si consideri uno scenario in cui viene utilizzato un algoritmo di hash rotto con una collisione nota. La conoscenza dell'algoritmo rotto può essere utilizzata per bypassare i controlli di integrità. Ma dal punto di vista della sicurezza delle informazioni, la violazione dell'integrità avviene a causa dell'uso di un algoritmo rotto, sebbene sia il risultato di un compromesso sulla riservatezza.

"L'integrità referenziale può rivelare la disponibilità di dati nel database e portare a violazioni riservate"

È possibile. In un semplice esempio, un tentativo di cancellare un record del cliente può fallire se c'è un ordine o un record di pagamento appartenente al cliente. Tuttavia questo funziona solo se ci sono circostanze in cui è consentita la cancellazione. Spesso gli elementi di dati non vengono mai "cancellati" (rimossi) ma semplicemente contrassegnati come "cancellati", "archiviati" o "inattivi".

Nella direzione opposta, l'inserimento di un record di pagamento può essere rifiutato se il cliente non esiste. Ma se gli identificatori sono arbitrari, l'aggressore spesso non è in grado di provare questo senza conoscere già l'identificatore del cliente. Più probabilmente saranno in grado di fare stime sul numero di dipendenti, clienti, fatture ecc. Nel sistema.

I vincoli di unicità comportano maggiori probabilità di perdita di informazioni (ad es. la carta di credito, il numero di telefono o l'indirizzo e-mail sono già presenti nel sistema).