Laden...

Henne-Ei-Problem in Bezug auf Sicherheitsfunktionen

Erstellt von Mr. Bart Simpson vor 6 Jahren Letzter Beitrag vor 6 Jahren 2.273 Views
Mr. Bart Simpson Themenstarter:in
502 Beiträge seit 2004
vor 6 Jahren
Henne-Ei-Problem in Bezug auf Sicherheitsfunktionen

Hallo zusammen,

ich konzipiere gerade (mit Kollegen) an einem größeren Softwareprojekt, welches Basis-Infrastrukturdienste für weitere Software zur Verfügung stellen soll (ich sprech mal bildlich: Eine Art Betriebsystem für andere Software).
D.h. es soll einzelne "Module" geben (Stichwort: Microservices), die für sich genommen funktionieren können und im Zusammenspiel miteinander Ihre Stärken ausspielen - diese sollen aber auch und vor allem genutzt werden von Software die "weiter oben" läuft.
"Unter" den Modulen soll es einen Layer geben, der sich -vereinfach gesagt- um die Verwaltung eben jener Module kümmert. So soll dort z.B. ein ggf. nötiger Dienst gestartet werden oder auch eine Art "Health Checking" für die Module laufen (Um beim Bild von oben zu bleiben: Der Kernel des Betriebssystems). Grundidee ist es dabei, den unteren Layer so schlank wie möglich und damit einfach und performant zu halten.

So weit so schön (und einfach)... :evil:
Nun soll es unter anderem ein Modul geben, welches eine zentrale Benutzer- und Rechteverwaltung erlaubt (Authentifizierung und Authorisierung). Damit sollen weitere Programme in die Lage versetzt werden, diese für sie nötige Funktionalität an eine zentrale Stelle zu delegieren. Auf den ersten Blick sofort etwas was man im Layer für die Module ansiedeln möchte, da es sich augenscheinlich ja um ein solches handelt.
Doch dann gibt es leider Anforderungen an den untersten Layer (im Bild: der Kernel), die ebenfalls irgendwie einer Rechteprüfung unterliegen müssen. (Beispielsweise: Wer darf die Konfiguration für z.B. das Startverhalten von Modulen ändern)

Nun stellt sich die Frage: Welche Softwarekomponente führt die dafür nötigen Prüfungen durch? 🤔 *Das selbe Modul wie oben? Damit bringt man aber eine (eigentlich unnötige und auch unerwünschte) Abhängigkeit des untersten Layers von einer darüber liegenden Schicht ins Spiel... *Eine (Kernel-) eigene Implementierung der Rechteprüfung? Damit wird a) u.U. Code gedoppelt und vor allem b) die Idee der zentralen Benutzerverwaltung ad absurdum geführt

Sieht jemand noch weitere Alternativen? Hat jemand gute Vor- / Ratschläge für die Lösung des Problems? Ich wäre für jedewede Information dankbar und freue mich auch über eifrige Diskussionen - denn damit bekommt man immer einen anderen Blickwinkel, der einem auch mal die Augen öffnen kann. Betriebsblindheit ist schließlich eine Berufskrankheit für Softwareentwickler... 😉

Bart Simpson

Praxis ist wenn alles funktioniert und keiner weiss warum.
Theorie ist wenn man alles weiss, aber nichts funktioniert.

Bei uns wird Theorie und Praxis vereint: Nichts funktioniert und keiner weiss warum...

3.170 Beiträge seit 2006
vor 6 Jahren

Hallo,

Doch dann gibt es leider Anforderungen an den untersten Layer (im Bild: der Kernel), die ebenfalls irgendwie einer Rechteprüfung unterliegen müssen.

Damit besteht also in jedem Fall eine Abhängigkeit zwischen Kernel und Rechteprüfung. Da kommst Du nicht drum herum.
Das Problem lässt sich also eingrenzen auf 2 Fälle:

  1. Die Logik wird direkt in dem Kernel Layer implementiert.
  2. Die Logik wird in einem abgesetzten Dienst/Modul implementiert, der sowohl vom Kernel als auch Anwendungen verwendet werden kann.

Logisch wäre so ein abgesetzter Dienst aber trotzdem irgendwie Teil der Kernel-Schicht, eben aufgrund der Abhängigkeit. Es ist nur eine Frage der Betrachtungsweise.

Damit wird a) u.U. Code gedoppelt und vor allem b) die Idee der zentralen Benutzerverwaltung ad absurdum geführt

Das verstehe ich aber nicht so ganz. Vor allem b). Viel zentraler als Dein Kernel Layer kann es doch gar nicht mehr werden??

Vielleicht wäre es eine Alternative - auch um Code Dup zu vermeiden, den Teil der Auth-Logik, der vom Kernel benötigt wird, auch dort zu implementieren. Dann hast Du zusätzlich ein Modul, das erweiterte Logik für die Applikationen bereitstellt, und für die bereits im Kernel implementiertwe Logik als Proxy fungiert.

Und wenn ich mir das jetzt selbst durchlese, ist man damit wieder in gewisser Weise beim oben genannten Fall 2 eines abgesetzten Dienstes/Moduls, von dem der Kernel dann eben abhängt.

Also sozusagen eine Zwischenschicht zwischen Kernel und Modulen, von dem der Kernel abhängt. Die Anwendungen greifen dann aber nicht direkt darauf zu, sondern über ein Modul in der Modulschicht, das für bereits implementierte Logik als Proxy fungiert.

Ich hoffe ich habe Dich jetzt nicht komplett falsch verstanden. Aber vielleicht ist das mal ein Anfang für:

und freue mich auch über eifrige Diskussionen

Gruß, MarsStein

Non quia difficilia sunt, non audemus, sed quia non audemus, difficilia sunt! - Seneca

16.807 Beiträge seit 2008
vor 6 Jahren

Leider muss ich Dich da enttäuschen: es gibt da keine pauschale Antwort. 😃

zB. für HealthCheck und Co nimmt man in vielen Fällen die Service Registry (bzw. die "Registrar Instanz") im Rahmen einer Service Discovery Umgebung.
Verzichtet ihr auf die Registry, dann habt ihr in diesem Fall auch keine HealthCheck Komponente. Dann muss das anders gelöst werden.

Beim Thema Rechtemanagement sieht es so aus, dass Deine zentrale Einheit der Benutzerverwaltung für die Authentifizierung zuständig ist; was sie nicht machen kann ist die Autorisierung.
Jeder Service muss in sich eine Logik haben um zu prüfen, ob der Service das tun darf, was der User will.
Eine zentrale Stelle wäre hier falsch.

Es wäre aber die Frage, wo die Informationen liegen, damit der Service prüfen kann, ob der Benutzer autorisiert ist.
Das kann an einer zentralen Stelle sein (ich bin ein Gegner von sowas) oder der Service muss das selbst halten (befürworte ich wegen weniger Dependency und mehr Flexibilität des Gesamtsystems).

Was man in so einem System dann auch nicht vergessen darf, ist das Logging.
Dazu gehört: Application Logs (Trace, Diagnostics, Auditing..), Activity Logs, Correlations und dann darauf basierend zB. Log Analytics und Log Monitor (und wenn es dann Fancy wird oder eher gesagt werden soll: noch die Log-Anbindung an Machine Learning um aus verschiedenen Töpfen wiederkehrende Probleme zu erkennen 😉

P
1.090 Beiträge seit 2011
vor 6 Jahren

Grundlegend kann man sich mal schon vorhandene Lösungen für Rechte/Lizenz Verwaltung anschauen.

ASP.NET Core-Sicherheit (Übersicht)

Hier kannst du einen einstieg finden.

Bei uns ist es so gelöst, das die Verwaltung von Rechten (BL) und die Prüfung von Rechten (vereinfacht DAL) getrennt sind. Auch sind Lizenz und Rechte getrennt.

Wir haben für beides ein Interface was wir mit DI Injizieren.

Grundlegend Probieren wir in den Layern so „hoch“ wie möglich zu prüfen ob die Rechte/Lizenz vorhanden ist. Was natürlich einmal die UI ist, hier werden je nach Lizenz/Recht nur die Funktionen angezeigt die der User auch hat. Da es sich um eine Web Anwendung handelt, wird bei dem Controller (Web Api) auch noch mal geprüft ob der User die Lizenz/Recht hat (Das ist bei Web Anwendungen wirklich wichtig). Im BL werden je nach Lizenz auch noch Sonderfunktionen ausgeführt. Hier findet dann auch noch mal eine Lizenzprüfung statt. Da wir aber für die Prüfung ein Interface des „DALs“ verwenden ist, das kein Problem.

Sollte man mal gelesen haben:

Clean Code Developer
Entwurfsmuster
Anti-Pattern

Mr. Bart Simpson Themenstarter:in
502 Beiträge seit 2004
vor 6 Jahren

Hi,

schon mal vielen Dank für die Antworten. Die jeweiligen Tendenzen zeigen mir jetzt schon, dass ich nicht komplett falsch liege mit meinen Ansichten 😁
Ich versuch mal auf die für mich wesentlichen Punkte einzugehen:

Das verstehe ich aber nicht so ganz. Vor allem b). Viel zentraler als Dein Kernel Layer kann es doch gar nicht mehr werden??

Was ich meinte war im Prinzip: Es gibt a) das schon erwähnte Modul zur Benutzerverwaltung und evtl. b) zusätzlich in gewisser Weise die selbe Funktionalität irgendwie nochmal im Kernel - aber eben "nur" für die Nutzung von dort aus. Und damit ergäbe sich eine gewisse funktionale Doppelung (was ich ja auch selbst kritisiert habe).
Die Idee mit dem Proxy klingt erst mal ganz net - aber dann muss man auch kucken, dass es nicht den Proxy um des Proxy's Willen gibt. Denn dann könnte u.U. auch direkt von "extern" mit der Funktionaliät im Kernel kommuniziert werden.
Ich weiss nicht so recht, ob dann nicht wieder Dein vorgeschlagener Punkt 2. der bessere wäre.

Aber vielleicht ist das mal ein Anfang für:

und freue mich auch über eifrige Diskussionen

Läuft! 😁

zB. für HealthCheck und Co nimmt man in vielen Fällen die Service Registry

Das ist auch genau unser Plan 😁 Ich hab nur das in gewisser Weise falsche oder zumindest suboptimale Beispiel HealthCheck gewählt, weil's so schön plakativ ist und damit auch jemand der sich noch nicht konkret mit der Thematik beschäftigt hat auch eine Vorstellung vom "Plan" bekommen kann... Verzeih also die bewusste Irreführung. 😉

Der Punkt, dass die zentrale Stelle keine Autorisierung machen kann/soll ist an sich ein valides Argument. Würdest Du den Standpunkt auch weiterhin vertreten, wenn ich folgende "Erweiterung" einbaue?*Das zentrale Module ist zuständig für die Authentifizierung (ähnlich wie Du das schreibst, von daher sag ich mal: -> Check!) *Die Nutzenden (externen, "drüberliegenden") Programme bekommen zusätzlich Zugriff auf eine Api, mit der sie an zentraler Stelle auch Informationen/Daten zur Autorisierung ablegen/verwalten können.

Hintergrund davon ist: Es kann/wird mehrere Programme geben, die sich eben jene (letztendlich) "administrative Konfiguration" (sprich: Wer darf was) teilen.

Was man in so einem System dann auch nicht vergessen darf, ist das Logging.

Den konkreten Punkt haben wir schon explizit auf dem Schirm. Ich bin aber sehr dankbar, wenn noch irgendwelche anderen Punkte/Anmerkungen kommen - einfach um nichts zu übersehen...

Bei uns ist es so gelöst, das die Verwaltung von Rechten (BL) und die Prüfung von Rechten (vereinfacht DAL) getrennt sind.

Das wollen wir grundsätzlich auch tun. Allerdings ist es "von außen betrachtet" dann doch wieder in einem Modul verortet - wenn auch u.U. über eine weitere/andere API zu erreichen.

U.a. weil unser Projekt in .net Core entwickelt werden soll, haben wir uns die dort vorhandenen Mechanismen / Lösungen schon genauer angekuckt und planen auch einiges von den Konzepten und Ideen bei uns einfließen zu lassen. Für unseren speziellen Anwendungsfall können wir aber aller Wahrscheinlichkeit nach nicht oder nicht vollständig darauf zurückgreifen... Da ist aber noch alles "im Fluss"...

Grundlegend Probieren wir in den Layern so „hoch“ wie möglich zu prüfen ob die Rechte/Lizenz vorhanden ist.

Das favorisiere ich im Prinzip auch. Allerdings gilt natürlich auch die Prämisse "never trust user input" und es darf natürlich nicht durch eine solche Verlagerung der Prüfung dazu kommen, dass angedachte Absicherungen/Kontrollen ausgehebelt oder umgangen werden können.
Um bei meinem Bild mit dem Betriebssystem zu bleiben: Wenn Dir die UI der Systemsteuerung nicht erlaubte eine kritische Stelle umzukonfigurieren, dann solltest Du das auch nicht können, wenn Du direkt versuchst, z.B. die Registry zu editieren.

Bart Simpson

Praxis ist wenn alles funktioniert und keiner weiss warum.
Theorie ist wenn man alles weiss, aber nichts funktioniert.

Bei uns wird Theorie und Praxis vereint: Nichts funktioniert und keiner weiss warum...

P
1.090 Beiträge seit 2011
vor 6 Jahren

Grundlegend Probieren wir in den Layern so „hoch“ wie möglich zu prüfen ob die Rechte/Lizenz vorhanden ist.

Das favorisiere ich im Prinzip auch. Allerdings gilt natürlich auch die Prämisse "never trust user input" und es darf natürlich nicht durch eine solche Verlagerung der Prüfung dazu kommen, dass angedachte Absicherungen/Kontrollen ausgehebelt oder umgangen werden können.
Um bei meinem Bild mit dem Betriebssystem zu bleiben: Wenn Dir die UI der Systemsteuerung nicht erlaubte eine kritische Stelle umzukonfigurieren, dann solltest Du das auch nicht können, wenn Du direkt versuchst, z.B. die Registry zu editieren.

Bart Simpson

Hab ich ja geschrieben, das es ein muss ist, die Sachen im Controller noch mal zu prüfen.

Ich hab ehrlich gesagt noch nicht genau Verstand wo dein Problem liegt. So das du die Standard Mechanismen nicht verwenden kannst.

Für mich klingt es fast so als ob der User Administrativen zugriff auf die Server hat. Wenn dem so ist, hast du eh keine Chance bei jemanden der weiß was er macht.

Sollte man mal gelesen haben:

Clean Code Developer
Entwurfsmuster
Anti-Pattern

16.807 Beiträge seit 2008
vor 6 Jahren

Der Punkt, dass die zentrale Stelle keine Autorisierung machen kann/soll ist an sich ein valides Argument. Würdest Du den Standpunkt auch weiterhin vertreten, wenn ich folgende "Erweiterung" einbaue?
Das zentrale Module ist zuständig für die Authentifizierung (ähnlich wie Du das schreibst, von daher sag ich mal: -> Check!)

Die Nutzenden (externen, "drüberliegenden") Programme bekommen zusätzlich Zugriff auf eine Api, mit der sie an zentraler Stelle auch Informationen/Daten zur Autorisierung ablegen/verwalten können.

Ja - natürlich.
Und als Zwischenschicht verwendest Du ein API Management Tool (gibts in Azure schon, oder Tyk.io oder API Umrella als unabhängige Lösungen).

Und je nach Umgebung trennen wir noch folgendes (wobei mein Fokus auch Industrie 4.0, Factories, Cloud und Co ist; weiß nicht inwiefern ihr da eine ähnliche Anforderung an die Umgebung habt):

* Wir haben externe und interne Services
* Plattform-Fremde Elemente dürfen nur mit den externen Services sprechen; nie mit internen
* Externe Services sind quasi nur Proxies, die sicherstellen, dass kein ungültiger Zugriff auf die internen Services weitergereicht werden; sie dienen nur als Schutzschicht.
* Externe Services können - bei Bedarf - je nach Umgebung individuell(er) angepasst werden
* Wir trennen strikt internen von externem Zugriff
* Wir können damit unterschiedliche Rechtemanagement-Implementierungen für interne und externe Zugriffe fahren
* Die externen Services
* Wir können im externen API Management andere Policies hinterlegen als im internen
* Kommunikation kann durch REST oder AMQP erfolgen

(Denkt euch im Bild die 2 hinzu; war wohl n Tippfehler und bin zu faul es nochmal zu zeichnen) 😃

16.807 Beiträge seit 2008
vor 6 Jahren

Eigentlich prüft der Controller/die Action in ASP.NET gar nichts.

Die Authorize-Middleware von ASP.NET Core prüft (Authentication) und die Business Logik prüft (Authorization).
Die Beispiele in der Dokumentation von Microsoft sind (oft zu) einfach gehalten.

Was dort direkt in der Action beispielhaft passiert, gehört eigentlich in einen Service (BL).
Deswegen dort auch das exemplarische Beispiel auf den authNService.

Ich hab aber das grundlegende Problem verstanden; dass ist i.d.R. immer der erste Diskussionspunkt in einer Plattformplanung.
Es hat ja schließlich auch nichts mit Standardmitteln sondern viel eher mit einem Architekturthema zutun; vor allem nicht, wenn hier verschiedene Zugriffsquellen existieren.

Mr. Bart Simpson Themenstarter:in
502 Beiträge seit 2004
vor 6 Jahren

Ja - natürlich.
Und als Zwischenschicht verwendest Du ein API Management Tool (gibts in Azure schon, oder Tyk.io oder API Umrella als unabhängige Lösungen).

Und je nach Umgebung trennen wir noch folgendes (wobei mein Fokus auch Industrie 4.0, Factories, Cloud und Co ist; weiß nicht inwiefern ihr da eine ähnliche Anforderung an die Umgebung habt)

Je länger ich über Dein Modell nachdenke, desto plausibler erscheint es mir - auch im Kontext unserer konkreten Anforderungen. 8)
Wobei ich allerdings noch nicht sicher bin, ob es wirklich zwei so strikte Management-Layer geben wird oder sollte. Aber das ist noch "im Fluss" (Hintergrund: Es gibt hier ein paar Aspekte, die ich in einem Forum nicht breittreten darf...)

Aber ich möchte mich auf jedenfall schon mal bei allen Antwortgebern bedanken! Allein die Tatsache mal was mit der Brille von jemand anderem zu sehen hat mir viel geholfen - und sei es z.T. auch "nur" die Tatsache, dass andere Leute auf die selben Lösungsansätze kommen.
Weitere Anregungen sind natürlich immer gern gesehen! 😁

Bart Simpson

P.S. @Abt: Ich bewege mich exakt in dem von Dir genannten Umfeld - wobei ich aber bei vielen (zumindest aktuell) nicht "Industrie 4.0" hinschreiben würde, sondern eher 0.9 beta 2 :evil:

Praxis ist wenn alles funktioniert und keiner weiss warum.
Theorie ist wenn man alles weiss, aber nichts funktioniert.

Bei uns wird Theorie und Praxis vereint: Nichts funktioniert und keiner weiss warum...

16.807 Beiträge seit 2008
vor 6 Jahren

Diese Separierung hier ist nur ein Teil "meiner" Gesamtarchitektur für Industrie 4.0 / Connected Factory.

Ich hab quasi eine Referenzarchitektur entwickelt, die auf Smart/Connected-Factory mit Offline-Fähigkeit und Cloud-Anbindung konzipiert ist und wir auch so erfolgreich umsetzen und auch schon produktiv haben; mit der Betracht, dass das Ganze (zB der Shopfloor, die Produktionslinie...) auch ohne Cloud funktionieren muss und zB. auch Dinge wie Whitelabeling beachtet.

Ich selbst war mal bei der Grundentwicklung einer Cloud-Plattform für Industrien beteiligt; bin dann aber gegangen nachdem das Konzept von Oben so einfach gegen die Wand fahren musste. Und das Feedback, das ich nun in der Beratung für Maschinenbaukunden habe ist genau das: die wollen sich nicht von Anbietern (Siemens, Bosch, SAP, Adamos und viele kleinere...) abhängig machen.
Aufgrund der Erfahrung ist quasi meine Referenzarchitektur entstanden.

Das große Bild schaut also deutlich größer und komplexer aus; will ich hier aber ehrlich gesagt auch nicht preis geben.