Détecter la falsification des bases de données, est-ce possible ?

Question

Auditeur de longue date, appelant pour la première fois.

Disons que vous avez une table de base de données qui est responsable de l'enregistrement de l'activité des utilisateurs. L'intégrité de ce journal est importante, vous voulez donc être en mesure de détecter si quelqu'un a modifié des données de la table. Pour rendre les choses encore plus intéressantes, considérez également le fait que votre système peut être exploité par un administrateur SQL maléfique qui a le contrôle total de ce système maléfique. aïe...

Comment allez-vous protéger vos données ?

Comment détecter si quelqu'un a manipulé vos données ?

Vous avez des outils illimités à votre disposition. (par exemple, le hachage, le cryptage, etc.)

Answer 1

Si vous devez vraiment détecter une falsification, ajoutez un champ de somme de contrôle à la table. La somme de contrôle de chaque nouvelle ligne doit inclure la somme de contrôle de la ligne précédente. Ensuite, pour vérifier le contenu, parcourez l'ensemble de données en calculant la somme de contrôle à mesure que vous avancez. Si la somme de contrôle calculée ne correspond pas à la valeur du tableau, cela signifie qu'une valeur a été falsifiée.

-Mike

Answer 2

Si l'"administrateur maléfique" n'a pas accès à l'application qui alimente la base de données, une colonne supplémentaire sur chaque table constituée d'un signature cryptographique pour le reste des colonnes fera l'affaire. La condition "aucun accès" est nécessaire pour qu'ils ne puissent pas extraire votre clé privée et signer leurs fausses données.

Edit : Ah, comme les commentateurs le font remarquer, je n'ai pas envisagé que l'administrateur supprime simplement une ligne. Pour cela, vous aurez besoin d'une ligne supplémentaire avec un nombre de lignes signé cryptographiquement que vous mettez à jour à chaque fois (ou un hash signé du reste du contenu de la table, ou le dernier temps d'accès, ou tout autre indicateur que vous choisissez).

Answer 3

Si vous voulez vraiment être en sécurité, utilisez - Write once Read Many Media pour cette table.

Answer 4

Créez une table fantôme qui hachera chaque fichier avec une clé/sel que seuls vous et l'application connaissez. Si vous voulez vérifier si des données ont été falsifiées, remontez la table de l'utilisateur et comparez-la à la table fantôme.

Answer 5

Il suffit de tenir un journal papier avec vos identifiants de transaction et de garder l'imprimante dans une pièce avec une seule clé. Travaillez avec des systèmes financiers, et vous verrez que beaucoup d'entre eux s'appuient encore sur leurs sauvegardes papier. Il est pratiquement impossible de "pirater" un journal papier de manière intraçable... C'est pourquoi les gens continuent à faire pression pour que les machines à voter soient enregistrées sur papier.

Beaucoup de gens disent, "Ajoute juste une autre base de données" et bien que j'ai effectivement pratique ce genre d'enregistrement moi-même, je n'y crois pas. Un initié malveillant pourrait neutraliser cette protection d'une douzaine de façons.

Tout ce que nous faisons ici est d'essayer de trouver un moyen de rendre évident que quelque chose s'est passé. Vous allez perdre vos journaux. Vous ne pourrez pas leur faire confiance : si je tombais sur un système doté d'un système de journalisation infaillible, je le remplirais de données inutiles ou je l'effacerais complètement. Ne tombez pas dans une mentalité de ligne Maginot.

Mais si vous préparez assez de pour qu'il y ait trop d'échecs, vous pouvez limiter le sabotage à une source interne. Vous devez enregistrer autour de la base de données, vous devez conserver des journaux système détaillés, vous devez surveiller le trafic IP, placer une caméra dans la salle des serveurs, laisser un enregistreur de frappe sur la console, etc, etc. Même les meilleurs d'entre eux se trompent un jour ou l'autre, et si vous avez suffisamment de pièges à souris, vous pouvez les attraper par accident.