Security Engine

Insecure Direct Object Reference

Eine grosse Gefahrenquelle, welche von der Öffentlichkeit nicht (oder erst langsam, vgl. Sicherheitsmängel bei T-Com) wahrgenommen wird, steckt bei Online-Systemen in der Lösung selbst. Auf der Website von OWASP, dem bedeutenden Open Web Application Security Project, werden die 10 kritischsten Sicherheitslöcher von modernen Applikationen beschrieben.  Die Bedrohungsart A4 - Insecure Direct Object Reference - gehört bei unternehmenskritischen Systemen zu den gefährlichsten Sicherheitslöchern, weil sie für den Entwickler sehr schwierig zu identifizieren und für das Testing Team praktisch nicht zu finden sind. Aus eigener Erfahrung wissen wir, dass praktisch alle Lösungen von dieser Bedrohungsart betroffen sind, denn jede Form von Datenzugriffen durch einen angemeldeten Benutzer stellt eine Herausforderung an das Sicherheitssystem dar. Ohne Unterstützung muss der Entwickler bei jedem Datenzugriff die Berechtigung von Hand ausprogrammieren. Die Berechtigung ist meist von den Daten selber, der Rolle des Benutzers und eventuell noch weiteren Faktoren abhängig. Es wird sofort klar, dass bei hunderten von unterschiedlichen Datenzugriffen und mehr als einem Dutzend Rollen die Wahrscheinlichkeit von Fehlern beträchtlich ist. Noch schlimmer wird es, wenn man an die Code Wartung und die damit verbundenen Änderungen denkt.

 

Gefahren

Die Konsequenzen dieser Bedrohung können katastrophal sein: Daten können gestohlen, manipuliert oder gelöscht werden. Bis anhin konnten nur umfassende (also nicht bloss stichprobenartige) Source Code Reviews mit jedem neuen Release diese Bedrohungsart identifizieren. Hand auf's Herz - wann haben Sie das letzte Mal einen solchen Review durchgeführt?

 

SecurityEngine

Diese Gefahren haben uns dazu bewogen, eine Komponente zu entwickeln, welche als Framework-Lösung alle Datenzugriffe komplett transparent für den Entwickler schützt. Diese Komponente heisst SecurityEngine und ist der Motor für die applikatorische Sicherheit innerhalb eines Systems. Sie stellt sicher, dass der Zugriff auf Daten nur berechtigten Benutzern erlaubt wird. Die SecurityEngine ist für den Einsatz von Datenbanksystemen zur Speicherung von sensitiven Daten ausgerichtet. Das zugrunde liegende Konzept kann jedoch auch auf andere Datenmanagementsysteme wie z.B. LDAP, o.ä. übertragen werden.


Ein zentrales Element der SecurityEngine ist die Zugriffsregel, welche eine einzelne Zugriffsberechtigung definiert. Eine Regel wird immer für eine bestimmte Entität, die darauf auszuführenden Operationen (create, read, update, delete) und eine bestimmte Rolle (ev. auch Benutzer) festgelegt. Eine Entität bezieht sich hierbei meist auf eine Tabelle oder Sicht einer Datenbank. Eine Rolle bezeichnet eine Gruppe von Benutzern mit gleichen Zugriffsberechtigungen, was die Verwaltung der Berechtigungen enorm erleichtert, weil sie so nur für eine kleine Menge und unabhängig von den tatsächlich vorhandenen Benutzern geschehen kann.

Die SecurityEngine setzt sich aus den folgenden Teilen zusammen:

  • Konfiguration
  • Runtime
  • Reporting & Monitoring
Die Konfiguration beinhaltet alle definierten Regeln und bestimmt, wie auf diese zugegriffen werden kann. Der Runtime Teil stellt die Integration zu Netport dar, damit die Regeln während der Laufzeit schnell ausgewertet und eingesetzt werden können. Das Reporting & Monitoring erlaubt die Überwachung und den Überblick über alle aktiven Regeln.


Der folgende Abschnitt zeigt einige typische Regelbeispiele, welche sich durch die SecurityEngine definieren und sicherstellen lassen:

  • Ein Kunde hat nur auf diejenigen Konti Zugriff, welche ihm angehängt sind.
  • Ein Supportmitarbeiter darf auf Kundendaten nur lesend zugreifen.
  • Mitarbeiter der Filiale Genf dürfen nur Kunden mit Filialzuteilung „Genf“ bearbeiten.
  • Ein Vertragsverwalter hat nur während den Öffnungszeiten Datenzugriff.
  • Aufträge mit einer Gesamtsumme über 1'000'000 CHF müssen für die Ausführung gegenvisiert sein.
  • Standard Abonnenten erhalten Informationen mit einer Verzögerung von 15 Minuten.

Alle oben aufgeführten Beispiele können mittels SecurityEngine über eine Konfiguration realisiert werden und bedürfen keiner Sourcecode-Anpassung. Dies garantiert eine flexible Wartung, grosse Transparenz und höchste Sicherheit.