Einführung in Sicherheitsprinzipien im Kontext von Datenbanksystemen
Von Andreas Wolter
Vorwort
Während sich viele von uns in „sozialer Distanz“ üben und viel Zeit zu Hause verbringen, finde ich endlich die Zeit, einige der Themen mit der Öffentlichkeit zu teilen, an denen ich seit meinem Einstieg bei Microsoft Ende 2018 gearbeitet habe.
In den letzten Jahren und immer häufiger eine der Fragen in Sachen Sicherheit der SQL Engine On-Prem sowie der SQL Azure Datenbank die aufkamen, bezog sich auf Lösungsmöglichkeiten, um die „Separation of Duties“ zu erreichen. Das ist eine gute Sache, denn es bestärkt mich in meiner Ansicht, dass Separation of Duties in der IT und speziell bei Cloud-basierten Systemen immer wichtiger wird.
Auf der anderen Seite haben wir festgestellt, dass es in der technischen Community noch kein breites Verständnis dafür gibt, was Separation of Duties (aka SoD) wirklich bedeutet und wie es heute umgesetzt werden kann. Ich habe den Eindruck, dass das Verständnis oft vage und manchmal sogar widersprüchlich ist, je nachdem, wen man fragt. Es könnte daher hilfreich sein, etwas Kontext und eine Anleitung dazu zu liefern, was SoD wirklich ist und wie es sich zu anderen Sicherheitsprinzipien verhält, auf die allgemein Bezug genommen wird und die sich in den letzten Jahrzehnten in der IT etabliert haben.
Wenn Sie nicht bereits ein Experte für IT-Sicherheit sind, hoffe ich, dass Sie diese Serie nützlich finden werden.
Einleitung: Motivation
Sicherheitsprinzipien in der Informationstechnologie oder Cybersecurity (auf physische Sicherheit gehe ich in diesem Artikel nicht ein) existieren als Richtlinien, um Design- und Entscheidungsprozesse in der Architektur, der Implementierung und reaktive Verfahren bei Vorfällen zu unterstützen. Der Zweck ist es, durch die Verwendung allgemeiner, bewährter Muster Systeme von vornherein mit Hinblick auf Sicherheit zu entwerfen und in der Lage zu sein, die Sicherheit eines Systems effektiv zu bewerten.
Von vornherein sichere Systeme zu entwickeln, kann eine teure Aufgabe sein, aber im Laufe der Jahre haben wir alle Sicherheitsvorfälle gesehen, die Millionen kosten und Unternehmen oder sogar Banken in den Ruin treiben können. (siehe z. B. https://www.ibm.com/ae-en/security/data-breach )
Ein wichtiger Hinweis: Die bloße Einhaltung dieser Sicherheitsprinzipien bietet keine Garantie, erfolgreiche Angriffe zu verhindern. Manche Angreifer investieren viel Zeit, um sich immer wieder neue Methoden auszudenken und Angriffsvektoren auszunutzen, an die Sie vorher vielleicht nicht gedacht haben.
Aber das Befolgen dieser Sicherheitsprinzipien hilft, die folgenden Ziele zu erreichen:
- Verringerung des Aktionsradius eines Angriffs
- d.h. Angreifer können aufgrund der Abschottung möglicherweise nicht auf alle ins Ziel genommenen Dienste zugreifen oder können nicht alle Berechtigungen erreichen, um Zugriff auf alle Dokumente zu erhalten
- Erhöhung der Zeit für einen erfolgreichen Angriff
- Dies steht im Zusammenhang mit Punkt 1, da es schwieriger wird, ausreichenden Zugriff zu erhalten.
- Erhöhung der Chancen auf frühzeitige Erkennung (!!)
- Mehr Kontrollen und Audits bedeuten in der Regel mehr Chancen, Alarme oder Fehler auf dem Weg auszulösen
- Verbesserung der forensischen Möglichkeiten nach der Entdeckung
- Bessere Audit-Trails ermöglichen erfolgreichere Ermittlungen
Sicherheit an erster Stelle
Daher rate ich dringend dazu, von vornherein die richtigen Sicherheitskontrollen zu implementieren. Und das nicht nur, weil es unter IT-Architekten allgemein bekannt ist, dass es teurer ist, laufende Systeme zu ändern, als dafür zu sorgen, dass Sicherheit von vornherein eine tragende Säule in der Architektur ist.
Um noch einen Schritt weiter zu gehen: Sicherheit sollte DIE ERSTE Säule sein, die implementiert wird. Was ich damit meine, ist, dass idealerweise nichts in Betrieb genommen wird, bevor nicht alle Sicherheitsmaßnahmen implementiert sind. Andernfalls ist es leicht möglich, absichtlich oder unabsichtlich Hintertüren oder andere Sicherheitslücken in die Basis einzubauen, die unentdeckt bleiben. Die allererste Maßnahme sollte daher sein, ein Auditing einzurichten. Wir werden in einem späteren Artikel mehr über Auditing sprechen.
Inhalt
Diese Artikelserie wird einen Überblick über die am häufigsten zitierten Sicherheitsprinzipien und -konzepte geben, die oft verwendet werden, wenn von Separation of Duties die Rede ist – oder sogar mit ihr vermischt werden – und kurz ihre Bedeutung und ihren Zusammenhang klären. Erwarten Sie eine Menge Schlüsselwörter (aber keine Buzzwords, versprochen).
Principle of Least Privilege (POLP) Need to know
Delegation of Privileges Separation of Privileges
Audit Trail Separation of Duties
– Diese Artikel werden in den nächsten Wochen nach und nach veröffentlicht und die Links werden dann ebenfalls nach und nach aktualisiert.
Ein weiteres Prinzip, das Sie bei der Konzeption von Sicherheit im Auge behalten sollten: „KISS“ – Keep it simple, stupid
Wie bereits in meinem Artikel aus dem Jahr 2017 (Separation of Duties (SoD) und rollenbasierte Sicherheitskonzeption in SQL Server) erwähnt, ist es absolut wichtig, die User Experience so einfach wie möglich zu halten. Alles, was „zu viel“ Aufwand bedeutet (und das können auch einfach „zu viele Klicks“ sein), wird dazu führen, dass die Benutzer versuchen werden, Wege herum zu finden. Und das werden sie auch.
Beispiel
Ein häufiges Beispiel dafür ist das gemeinsame Admin-Konto. Anstatt ein erhöht privilegiertes Konto pro Person zu haben, teilen sich die Entwickler ein gemeinsames privilegiertes Konto, vor allem in kleinen Firmen. Das macht unter anderem Auditing fast nutzlos, da niemand wirklich sagen kann, wer was gemacht hat.
Hinweis
Separation of concerns (SoC)
Im Laufe der Zeit habe ich gehört, dass dieser Term verwendet wird, wenn eigentlich „Separation of Duties“ gemeint war. SoC ist KEIN Sicherheitsprinzip, sondern ein grundlegendes Designprinzip der Programmierung, das zu modularer (oder „funktionaler“) Programmierung führt. Hoffentlich klärt das diese häufige Verwechslung auf.
Wikipedia-Artikel: https://en.wikipedia.org/wiki/Separation_of_concerns
Lasst mich wissen, ob Sie diese Serie hilfreich finden und was Sie in Zukunft noch hören wollen.
Andreas
Besonderen Dank an
Raul Garcia, ehemaliger SQL Security PM und „Ehrenmitglied auf Lebenszeit“ 🙂 – dein Wissen in Sachen Security und SQL Security speziell hat mir geholfen, nichts Wichtiges zu übersehen und einen gewissen Qualitätsmaßstab einzuhalten 😉
Steven Gott, einer unserer ranghöchsten Security Engineers, für deine kritischen Standpunkte, die mir helfen, nach vorne zu schauen, obwohl ich weiß, dass ich unmöglich alles erwähnen kann.
Ralf Dietrich vom Sarpedon Quality Lab® Deutschland für unzählige Stunden Brainstorming über sichere Architekturen, auch wenn wir nun in unterschiedlichen Zeitzonen sind.
