Guggat emol BlogGuggat emol Blog

• Azubi-Ecke
  • Handbuch für Fachinformatiker
• Das Projekt
• Fettweg
  • Gewichtsapplikation
• gentoo
  • Asus
  • Software
• Guggat emol
• IT
  • Design Pattern
  • Programmieren
• itil
• MOC
• Projektmanagement
• ubuntu
• Unterricht
  • Bücher
  • Businesscase
  • galerie
• 

• Es schrieb

  • Ute bei LibreOffice 4.0.x, Gentoo und Rechtschreibprüfung Deutsch
  • JanDavid bei Superbank macht Supergewinn
  • Dirk Deimeke bei Superbank macht Supergewinn

• Grad geschrieben

  • Angel dir einen Gesamtprojektleiter Teil 1
  • Die Projektorganisation
  • NEUE-WELT Hauptthemen

Tags

• Blogroll

  • gentoo
  • miradlo bloggt

« Kubuntu hat mir zu viele Fehler Service Capacity Management »

Security fummelt man am Besten gleich in die Architektur hinein

26. Juni 2009 Roland

Ich habe mal meinen Enterprise Architect “vorgeglüht” und mich an die grundlegende Architektur des Newssystems gemacht.
Da ich als Basispattern das Model View Controller Pattern verwende, und die einzelnen Aktionen nach dem CRUD (Create, Read, Update, Delete) Pattern aufgebaut sind, fing ich mit den Modellen an.
Es kommen eine ganze Menge Modelle zusammen, wenn wir das Newssystem schön und sauber gestalten wollen.

Mach dir zuerst über die Security Gedanken

Als ich so meine Architekturtapete pinselte, dachte ich logischerweise auch über die Zugriffsrechte der Anwender nach.
Es gibt, wie immer, verschiedene Vorgehensweisen und Möglichkeiten wie man seine Sicherheitsregeln in das System einbaut.
Hier sind ein paar Gedanken dazu.

Authorisierung in den Modellen

Man kann z.B. die Zugriffsrechte fest in den Modellen einschreiben.
Das bedeutet, das jeweilige Modell kontrolliert, ob der Anwender überhaupt diese Aktion durchführen darf.
Dazu können hart kodierte Regeln verwendet werden. Das bedeutet der Redakteur darf nur seine eigenen Artikel verändern, also prüfen wir ob der aktuell angemeldete Redakteur im Artikel eingetragen ist.

Vorteile

• Wir können die Regeln einmal festlegen und eintragen
• Die Sicherheit wird auf Modellebene gesteuert
  Ein versehentliches falsches Einfügen und Verändern sollte verhindert werden können.

Nachteile

• Die Regeln stehen hart kodiert im Modell drin
  Änderungen an den Sicherheitsregeln müssen in den Modellen vorgenommen werden. Das nachträgliche Anpassen für einen Kunden ist nicht möglich. Wenn aber ein Kunde will, dass der Systemadministrator auch Artikel bearbeiten kann, dann geht das nicht. Wenn das jedoch ein Kundenwunsch ist, finde ich es nicht richtig unser System schon von Anfang an so einzuschränken.
• Wenn ein zentrales Security System verwendet werden soll, dann können die Zugriffsregeln nicht von dort aus gesteuert werden. Das System ist in sich geschlossen und nicht erweiterbar.
• Duplizierung von Code und Verantwortlichkeiten auf verschiedenen Layern
  Falls die Regeln auch Auswirkungen auf die Views haben, wie Beispielsweise die Anzeige von Löschbuttons nur wenn du auch die notwendigen Rechte hast, dann muss man diese Regeln auch noch in der View implementieren.
• Seperation of Concern verletzt
  Das gefällt mir als Architekt natürlich gar nicht. Wieso soll sich eine View oder ein Modell um die Berechtigungen des Users im Detail kümmern? Das macht die Komponenten dick und fett und das kann kein guter Ansatz sein.

Oha! Das war noch nichts.
Gut, ich behaupte mal die meisten Systeme sind genau so, oder so ähnlich aufgebaut. Aber wenn es falsch ist, dann ist es auch falsch wenn es meistens so gemacht wird.
Also gut, ein weiterer Versuch:

Security Rules nur in den Controllern

Der Controller ist ja dafür da, die Abläufe im System zu steuern.
Da wäre es doch nur rechtens, wenn er sich auch um die Security kümmert.
Wenn unser lieber User jetzt eine Aktion ausführen will, die er nicht ausführen darf, dann hindert ihn der Controller daran.

Vorteile

• Die Zugriffsdefinition wird an einer Stelle gehalten
  Juchu! Klingt doch schon eher nach Seperation of Concerns gelle?. Wenn wir was ändern wollen, dann ändern wir den jeweiligen Controller. View und Modell kümmern sich um die Ansicht und die Speicherung.
• Flexibilität der Rechtevergabe deutlich erhöht
  Da wir nun eine zentrale Komponente haben, in der wir die Rechtevergabe steuern, sollte es deutlich leichter sein diese zu verändern.

Nachteile

• Auf Modellebene wird keine Zugriffssteuerung implementiert.
  Das ist ein ziemlich dicker Nachteil. Das Modell muß permanent und immer sich um die Richtigkeit der Daten kümmern. Wenn wir dem Modell jetzt diese Verantwortung entziehen, dann muss der Controller immer sauber programmiert sein. Damit entsteht eine Sicherheitslücke. Denn wer weiß? Vielleicht umgeht ein versierter Hacker unseren Controller?
• Zentrale Rechteverwaltung nicht möglich
  Da wir wieder unsere Rechteverwaltung im System behalten, können wir eine Verwaltung nicht in einer externen Komponente auslagern. Unser System bleibt dick und wenn wir es irgendwo integrieren wollen, bleibt dem Administrator nichts anderes übrig als verschiedene Administartionstools zu verwenden.

Hm… Schon mal nicht schlecht, bis auf die Nachteile.
Mir gefällt diese Implementation jedoch schon viel besser als die Erste Variante.
Vielleicht gibts da noch was anderes?

Rechteverwaltung in eigene Komponenten auslagern und über Interface ansteuern

Das klingt schön kompliziert und gefällt deshalb dem Architekt
Quatsch, das ist gar nicht kompliziert, hilft uns jedoch die Komplexität zu senken und später ein anderes Rechtesystem mitzuverwenden.
Wir erstellen, z.B. mit einem Singleton oder Factory Pattern, ein eigenständiges Sicherheitsregelwerk. Dieses Regelwerk wird für die Standalone Lösung des Newssystems verwendet.
Die Authorisierung wird über ein Interface angesprochen.
Dieses Interface bietet mindestens eine Funktion.
Und die nennen wir z.B. isActionAllowed(actionID, component).
Wir übergeben dieser Methode die Aktion die zur Zeit aufgerufen wurde und die Komponente auf die diese Aktion angewendet wird.
Die Methode liefert true zurück, wenn der Anwender diese Aktion durchführen darf. Und, rate mal, false falls er es nicht darf.
Unglaublich digital!
Jetzt können wir in jedem Modell und in jedem Controller oder View nach belieben Regeln festlegen und im zentralen Authorisierungssystem implementieren.

Vorteile

• Zentrale Verwaltung aller Rechte möglich
  Vorbei sind die Probleme, dass wir Rechte nicht zentral verwalten können. Je nach Strategie können wir eine Whitelist oder eine Blacklist implementieren. Will heißen, dass wir z.B. nur true zurückliefern, wenn die Komponente und Aktion bekannt und erlaubt ist. Oder wir liefern true zurück wenn wir keinen Plan haben was da aufgerufen wurde. Dann überprüfen wir nur, was wir auch schon kennen.
• Auf Modellebene kann Rechteverwaltung realisiert werden.
  Wenn wir mindestens alle Modelle in der Rechteverwaltung aufnehmen, ist eine Rechtesteuerung auf Modellebne möglich.
• Größte Flexibilität bei der Rechtevergabe
  Klar, wir können hier die wildesten Rechtesteuerungen erfinden. Aber Vorsicht! Es ist nicht cool man wenn man damit jedem Anwender alle Rechte gibt.
• Einfaches Testen
  Da die Security in einem eigenen System zusammengefasst ist, können wir für jede Aktion von CRUD und jeder Komponente einen true und false Testfall generieren. Wir können dann sehr sicher sein, dass z.B. die Modelle nur speichern wenn sie auch wirklich speichern dürfen.

Nachteile

Was? So eine coole Lösung und Nachteile?
Leider ja…

• Modelle haben keine direkte Kontrolle über Authorisierung
  Dieser Nachteil ist der gleiche wie wenn wir die Rechtevergabe dem Controller übergeben. Der Entwickler und Administrator unserer Rechtesystems muss wissen was er tut. Das Modell unterstützt ihn hierbei nicht.
• Externe Rechtevergabe kann Sicherheitslücken verursachen
  Klar, wenn wir unsere Security “outsourcen” dann verlieren wir innerhalb des Systems die Kontrolle darüber. Aber mal ehrlich: Wir bauen hier ein Newssystem, im schlimmsten Fall wird mal eine schlechte Nachricht geschrieben oder gelöscht…

Wozu hat sich jetzt der (graue) Star Architekt entschlossen?

Ratet mal!
Ich bin ein faules Tier und möchte die Flexibilität so hoch wie möglich halten.
Also werde ich in die Architektur die dritte Variante einbauen.
Wie bitte? Faul und dann so ein System?
Genau deshalb. Wenn wir nur eine Komponente verwalten müssen, mit der wir die Authorisierung durchführen, sparen wir uns über die Zeit eine menge Arbeit.
Wenn die einzelnen Methoden einfacher aufgebaut sind, können wir sie schneller uns sicherer testen.
Dann kann ich ruhig schlafen und habe das gute Gefühl keine vollständige Standalone Lösung entwickelt zu haben.

Hätten wir diese Lösung auch noch später einbauen können?

Ja, das hätten wir gekonnt. Doch wir wären permanent über den User und seine Berechtigungen gestolpert. Im schlimmsten Fall hätten wir die einzelnen Berechtigungen schon irgendwie in den Controller, oder noch schlimmer, nur in die Views eingebaut.
In den Views wäre besonders schlimm, da das erste was ein böser Bube umgehen kann die View ist. Ein Roboter braucht keine View…

Der Beitrag wurde am Freitag, den 26. Juni 2009 um 11:10 Uhr veröffentlicht und wurde unter Programmieren abgelegt.
Kurzlink: http://www.baldenhofer.eu/blog/?p=1641

Dir gefiel der Artikel? Dann abonniere doch den RSS Feed

Du kannst die Kommentare zu diesem Eintrag durch den RSS 2.0 Feed verfolgen. Du kannst einen Kommentar schreiben, oder einen Trackback auf deiner Seite einrichten.

Eine Reaktion zu “Security fummelt man am Besten gleich in die Architektur hinein”

1. Security Komponenten Klassendiagramm  Guggat emol Blog sagt:

   30. Juni 2009 um 08:49

   [...] im ersten Sprint umgesetzt werden sollen Auf der Suche nach einem Tool um Anforderungen zu erfassen Security fummelt man am Besten gleich in die Architektur hinein Security Komponenten Klassendiagramm [...]

zum Seitenanfang