SQL Server-Datenbank gegen clevere Admins sichern?

Question

Ich möchte Ereignisse in einer Tabelle gespeichert, die Beziehungen zu anderen hat. Ereignisse werden über den Windows-Dienst eingefügt, der eine Verbindung zur Hardware herstellt und von der Hardware liest.

In der Ereignistabelle sind PK, Datum und Uhrzeit und 3 verschiedene Werte.

Das Problem ist, dass sich jeder Admin anmelden und Daten in diese Tabelle einfügen/aktualisieren/löschen kann, z. mit SQL Management Studio. Ich erstelle Trigger, um das Update und das Löschen zu verhindern. Wenn also der Admin keine Trigger kennt, kann er die Daten nicht ändern, aber wenn er den Trigger kennt, kann er den Trigger einfach deaktivieren und tun, was er will.

Also nach langem Nachdenken habe ich eine Idee, neue Spalte (Feld) zu Tabelle hinzufügen und so etwas wie Prüfsumme in diesem Feld speichern, diese Prüfsumme wird basierend auf anderen Werten berechnet. Diese Prüfsumme wird in insert/update-Anweisungen generiert. Wenn jemand etwas manuell einfügt/aktualisiert, werde ich es wissen, denn wenn ich Daten mit Prüfsumme überprüfe, wird es Mismatches geben.

Meine Frage ist, wenn Sie ähnliche Problem haben, wie lösen Sie es? Welchen Algorithmus für Prüfsummen verwenden? Wie kann ich gegen eine Löschanweisung schützen (ich weiß über leere Zahlen in PK, aber es ist nicht genug)?

Ich bin mit SQL Server 2005.

Answer 1

Alles, was Sie auf Serverebene tun, kann der Administrator rückgängig machen. Das ist die Definition seiner Rolle und es gibt nichts, was Sie tun können, um es zu verhindern.

In SQL 2008 können Sie die Überwachung des genannten SQL-Servers mit X-Ereignissen anfordern, siehe http://msdn.microsoft.com/en-us/library/cc280386.aspx. Dies ist eine CC-konforme Lösung, die manipulationssicher ist. Das bedeutet, dass der Administrator das Audit stoppen und seine boshaften Aktionen ausführen kann, aber das Stoppen des Audits wird aufgezeichnet.

In SQL 2005 wird für die empfohlene Überwachungslösung die profiler infrastructure verwendet. Dies kann manipulationssicher gemacht werden, wenn es korrekt eingesetzt wird. Sie würden Datenänderungen mit Triggern und Einschränkungen verhindern und DDL-Änderungen prüfen. Wenn der Administrator die Trigger ändert, ist dies in der Prüfung sichtbar. Wenn der Administrator die Prüfung beendet, ist dies auch in der Prüfung sichtbar.

Planen Sie dies als einmalige Aktion gegen einen Rogue-Administrator oder als Funktion, die Ihrem Produkt hinzugefügt werden soll? Die Verwendung von digitalen Signaturen zum Signieren aller Anwendungsdaten kann in App-Zyklen sehr kostspielig sein. Sie müssen auch ein sicheres Schema entwerfen, um zu zeigen, dass Datensätze nicht gelöscht wurden, einschließlich der letzten Datensätze (dh keine einfache Lücke in einer Identitätsspalte). Z.B. Sie könnten über BINARY_CHECKSUM(*) berechnen, das Ergebnis in der App unterschreiben und den signierten Wert für jede Tabelle nach jedem Update speichern. Needles zu sagen, dies wird Ihre Anwendung verlangsamen, da Sie im Grunde jede Operation serialisieren. Für einzelne Zeilen Cheksums/Hashes müssten Sie die gesamte Signatur in Ihrer App berechnen, und das würde möglicherweise Werte erfordern, die Ihre App noch nicht hat (dh der Identitätsspaltenwert ist Ihrem Einsatz als zugewiesen). Und wie weit willst du gehen? Ein einfacher Hash kann gebrochen werden, wenn der Administrator Ihre App in die Hand nimmt und überwacht, was Sie in welcher Reihenfolge hashen (dies ist trivial). Er kann dann den gleichen Hash berechnen. Ein HMAC erfordert, dass Sie ein Geheimnis in der Anwendung speichern, das im Grunde gegen einen entschlossenen Hacker unmöglich ist. Diese Bedenken mögen übertrieben erscheinen, aber wenn es sich um eine Anwendung handelt, die Sie zum Beispiel verkaufen, dann ist alles, was Sie brauchen, ein Hacker, um Ihre Hash-Sequenz oder hmac Geheimnis zu brechen. Google wird sicherstellen, dass alle anderen irgendwann davon erfahren.

Mein Punkt ist, dass Sie auf dem Hügel vor einer verlustreichen Schlacht sind, wenn Sie versuchen, die Admin über Technologie zu verhindern. Die Admin ist eine Person, die Sie vertrauen und wenn dies in Ihrem Fall gebrochen ist, ist das Problem Vertrauen, nicht die Technologie.

Answer 2

Sicherheit durch Unklarheit ist eine schlechte Idee. Wenn es eine Formel gibt, um eine Prüfsumme zu berechnen, kann es jemand manuell tun.

Wenn Sie Ihren DB-Administratoren nicht vertrauen können, haben Sie größere Probleme.

Answer 3

Es könnte effektiver sein, zu versuchen, Berechtigungen für die Tabelle zu sperren. Mit der Prüfsumme scheint es, als ob ein böswilliger Benutzer sie fälschen könnte oder Daten einfügen könnte, die gültig zu sein scheinen.

http://www.databasejournal.com/features/mssql/article.php/2246271/Managing-Users-Permissions-on-SQL-Server.htm

Answer 4

Letztlich auch wenn Administratoren Rechte haben nicht löschen, können sie sich Zugang geben, die Änderung vorzunehmen, um nicht Löschungen verweigern, löschen Sie die Zeile und dann die Berechtigung wiederherstellen und dann ihren Zugang widerrufen Erlaubnis zu machen Änderungen.

Wenn Sie das auditieren, dann feuern Sie sie, wenn sie sich selbst Zugang gewähren.

Soweit eine effektive manipulationssichere Prüfsumme, ist es möglich, öffentliche/private Schlüssel Unterzeichnung zu verwenden. Dies bedeutet, dass wenn die Signatur mit der Nachricht übereinstimmt, niemand außer dem, der den Datensatz erstellt hat, den Datensatz erstellt oder geändert hat. Jeder kann den Datensatz mit seinem eigenen Schlüssel ändern und unterschreiben, aber nicht als jemand anderen.

Answer 5

ich nur Protect sensitive information from the DBA in SQL Server 2008

Answer 6

zeigen werde Wenn Sie Menschen betroffen sind, die Daten zu modifizieren, sollten Sie auch besorgt über sie die Prüfsumme ändern.

Können Sie bestimmte Berechtigungen für diese Datenbank nicht einfach mit einem Kennwort schützen?

Answer 7

Die Idee einer Prüfsumme, die von der Anwendung berechnet wird, ist eine gute Idee. Ich würde vorschlagen, dass Sie Message Authentication Codes oder MACs für eine sicherere Methode suchen.

Kurz gesagt, einige MAC-Algorithmen (HMAC) verwenden eine Hash-Funktion und enthalten einen geheimen Schlüssel als Teil der Hash-Eingabe.Selbst wenn der Administrator die verwendete Hash-Funktion kennt, kann er den Hash also nicht reproduzieren, da er nicht alle Eingaben kennt.

Auch in Ihrem Fall sollte eine laufende Nummer Teil der Hash-Eingabe sein, um das Löschen ganzer Einträge zu verhindern.

Idealerweise sollten Sie eine starke kryptographische Hash-Funktion aus der SHA-2-Familie verwenden. MD5 hat bekannte Sicherheitslücken und ähnliche Probleme werden in SHA-1 vermutet.

Answer 8

Da Administratoren Berechtigungen haben, alles auf Ihrem SQL-Server zu tun, empfehle ich eine temper-evidente Auditing-Lösung. In diesem Szenario wird alles, was in einer Datenbank oder einer SQL Server-Instanz passiert, erfasst und in einem Repository für unvorhergesehene Ereignisse gespeichert. Für den Fall, jemand, der die Privilegien (wie Administratoren) hat ändert oder löscht geprüften Daten aus dem Repository, wird es

ApexSQL Comply ist eine solche Lösung gemeldet werden, und es hat sind eine eingebaute Integritätsprüfung Option Es gibt mehrere anti-Manipulation Maßnahmen, die unterschiedliche Integritätsprüfungen ermöglichen und Manipulationen erkennen, selbst wenn sie von einer vertrauenswürdigen Partei ausgeführt werden. Um die Datenintegrität sicherzustellen, verwendet die Lösung Hashwerte.Ein Hash-Wert ist ein numerischer Wert, der mit einem spezifischen Algorithmus erstellt wurde, der ihn eindeutig identifiziert.

Jede Tabelle in der zentralen Repository-Datenbank enthält die Spalten RowVersion und RowHash. Die RowVersion enthält den Zeilenzeitstempel - das letzte Mal, an dem die Zeile geändert wurde. Die RowHash-Spalte enthält den eindeutigen Zeilenbezeichner für die Zeile, die mit den Werten anderer Tabellenspalten berechnet wurde

Wenn der ursprüngliche Datensatz im Überwachungsrepository geändert wird, aktualisiert ApexSQL Comply automatisch den RowVersion-Wert, um den Zeitpunkt der letzten Änderung widerzuspiegeln. Um die Datenintegrität zu überprüfen, berechnet ApexSQL Comply den RowHash-Wert für die Zeile basierend auf den vorhandenen Zeilenwerten. Die bei der Datenintegritätsüberprüfung verwendeten Werte werden jetzt aktualisiert, und der neu berechnete RowHash-Wert unterscheidet sich daher von dem RowHash-Wert, der in der zentralen Repository-Datenbank gespeichert ist. Dies wird als mutmaßliche Manipulation gemeldet.

Um die Manipulation zu verbergen, müsste ich einen neuen Wert für RowHash berechnen und aktualisieren. Dies ist nicht einfach, da die für die Berechnung verwendete Formel komplex und nicht offengelegt ist. Aber das ist nicht alles. Der RowHash-Wert wird mithilfe des RowHash-Werts aus der vorherigen Zeile berechnet. Um die Manipulation zu verdecken, müsste ich die RowHas-Werte in allen folgenden Zeilen neu berechnen und ändern

Für einige Tabellen in der ApexSQL Comply zentralen Repository-Datenbank werden die RowHash-Werte basierend auf den Zeilen in anderen Tabellen berechnet decken Spuren in einer Tabelle Manipulation, würden die Server-Betreiber müssen die Datensätze in mehreren zentralen Repository-Datenbanktabellen Diese Lösung modifizieren, ist nicht fälschungssicher, sondern macht auf jeden Fall abdeckt Vergütungs Tracks ziemlich schwierig

Haftungsausschluss: ich arbeite für ApexSQL als Support-Techniker