myCSharp.de - DIE C# und .NET Community
Willkommen auf myCSharp.de! Anmelden | kostenlos registrieren
 
 | Suche | FAQ

» Hauptmenü
myCSharp.de
» Startseite
» Forum
» FAQ
» Artikel
» C#-Snippets
» Jobbörse
» Suche
» Regeln
» Wie poste ich richtig?
» Forum-FAQ

Mitglieder
» Liste / Suche
» Wer ist wo online?

Ressourcen
» openbook: Visual C#
» openbook: OO
» Microsoft Docs

Team
» Kontakt
» Übersicht
» Wir über uns

» myCSharp.de Diskussionsforum
Du befindest Dich hier: Community-Index » Diskussionsforum » Entwicklung » Rund um die Programmierung » Henne-Ei-Problem in Bezug auf Sicherheitsfunktionen
Letzter Beitrag | Erster ungelesener Beitrag Druckvorschau | Thema zu Favoriten hinzufügen

Antwort erstellen
Zum Ende der Seite springen  

Henne-Ei-Problem in Bezug auf Sicherheitsfunktionen

 
Autor
Beitrag « Vorheriges Thema | Nächstes Thema »
Mr. Bart Simpson Mr. Bart Simpson ist männlich
myCSharp.de-Mitglied

avatar-3273.gif


Dabei seit: 13.03.2004
Beiträge: 501
Herkunft: Mittelfranken


Mr. Bart Simpson ist offline

Henne-Ei-Problem in Bezug auf Sicherheitsfunktionen

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

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)... Teufel
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? verwundert
  • 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... Augenzwinkern

Bart Simpson
20.12.2017 09:01 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
MarsStein MarsStein ist männlich
myCSharp.de-Poweruser/ Experte

avatar-3191.gif


Dabei seit: 27.06.2006
Beiträge: 3.117
Entwicklungsumgebung: VS 2013, MonoDevelop
Herkunft: Trier -> München


MarsStein ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

Hallo,

Zitat:
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.

Zitat:
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:

Zitat:
und freue mich auch über eifrige Diskussionen

Gruß, MarsStein
20.12.2017 10:25 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
Abt
myCSharp.de-Team

avatar-4119.png


Dabei seit: 20.07.2008
Beiträge: 12.902
Herkunft: Stuttgart/Stockholm


Abt ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

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 ;-)
20.12.2017 10:29 Beiträge des Benutzers | zu Buddylist hinzufügen
Palin Palin ist männlich
myCSharp.de-Mitglied

Dabei seit: 22.08.2011
Beiträge: 1.090
Entwicklungsumgebung: VB.net


Palin ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

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.
20.12.2017 11:05 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
Mr. Bart Simpson Mr. Bart Simpson ist männlich
myCSharp.de-Mitglied

avatar-3273.gif


Dabei seit: 13.03.2004
Beiträge: 501
Herkunft: Mittelfranken

Themenstarter Thema begonnen von Mr. Bart Simpson

Mr. Bart Simpson ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

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 großes Grinsen
Ich versuch mal auf die für mich wesentlichen Punkte einzugehen:

Zitat von MarsStein:
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.

Zitat von MarsStein:
Aber vielleicht ist das mal ein Anfang für:

Zitat:
und freue mich auch über eifrige Diskussionen

Läuft! großes Grinsen

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

Das ist auch genau unser Plan großes Grinsen 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. Augenzwinkern

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.

Zitat von Abt:
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...

Zitat von Palin:
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"...

Zitat von Palin:
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

Dieser Beitrag wurde 1 mal editiert, zum letzten Mal von Mr. Bart Simpson am 20.12.2017 11:22.

20.12.2017 11:22 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
Palin Palin ist männlich
myCSharp.de-Mitglied

Dabei seit: 22.08.2011
Beiträge: 1.090
Entwicklungsumgebung: VB.net


Palin ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

Zitat von Palin:
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[/quote]
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.
20.12.2017 11:34 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
Abt
myCSharp.de-Team

avatar-4119.png


Dabei seit: 20.07.2008
Beiträge: 12.902
Herkunft: Stuttgart/Stockholm


Abt ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

Zitat von Mr. Bart Simpson:
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) :-)

Abt hat dieses Bild (verkleinerte Version) angehängt:
Picture1.png
Volle Bildgröße

20.12.2017 11:44 Beiträge des Benutzers | zu Buddylist hinzufügen
Abt
myCSharp.de-Team

avatar-4119.png


Dabei seit: 20.07.2008
Beiträge: 12.902
Herkunft: Stuttgart/Stockholm


Abt ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

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.
20.12.2017 13:16 Beiträge des Benutzers | zu Buddylist hinzufügen
Mr. Bart Simpson Mr. Bart Simpson ist männlich
myCSharp.de-Mitglied

avatar-3273.gif


Dabei seit: 13.03.2004
Beiträge: 501
Herkunft: Mittelfranken

Themenstarter Thema begonnen von Mr. Bart Simpson

Mr. Bart Simpson ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

Zitat von Abt:
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. cool
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! großes Grinsen

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 Teufel
21.12.2017 11:52 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
Abt
myCSharp.de-Team

avatar-4119.png


Dabei seit: 20.07.2008
Beiträge: 12.902
Herkunft: Stuttgart/Stockholm


Abt ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

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.
22.12.2017 12:25 Beiträge des Benutzers | zu Buddylist hinzufügen
Baumstruktur | Brettstruktur       | Top 
myCSharp.de | Forum Der Startbeitrag ist älter als ein Jahr.
Der letzte Beitrag ist älter als ein Jahr.
Antwort erstellen


© Copyright 2003-2019 myCSharp.de-Team | Impressum | Datenschutz | Alle Rechte vorbehalten. | Dieses Portal verwendet zum korrekten Betrieb Cookies. 19.08.2019 17:00