Berechtigungskonzept in der modernen Cloud Umgebung

[StefanWe 14]

Hallo,

 

mich würde gerne einmal interessieren, bzw. Diskutieren, wie ihr das Berechtigungskonzept in der modernen Cloud Umgebung seht.

 

ich für meinen Fall habe in der klassischen On Prem Welt stark auf das AGDLP Prinzip bzw. Plus U Gruppen gesetzt. D.h. Egal welche Anwendung wurde ans AD angebunden und Berechtigungen innerhalb dieser an Gruppen im AD vergeben. Jedenfalls wo es möglich war. 
 

Mit Entra Id in einer Hybriden Welt ist dies zum Teil für Cloud Anwendungen, welche mittels Saml/oauth angebunden werden möglich. Man könnte nun im AD Gruppen anlegen und diese synchronisieren oder matchen lassen. Je Nachdem was die Cloud Anwendung unterstützt. 
 

Alternativ könnte man Benutzer aber auch individuell der Anwendung zuweisen und Berechtigungen innerhalb der Anwendung direkt an die Benutzer vergeben. Oder Benutzer innerhalb der Anwendung in die Anwendungsgruppen packen.

 

Bei letzterem ist eine Delegation der Berechtigungen auch an Fachabteilungen möglich. Sie können so Leute innerhalb ihrer Projekte berechtigen. 
 

Wie seht ihr das?

[NorbertFe 2.027]

Am Ende kommt "Es kommt darauf an" raus.

1. Wenn du es mit SAML/Oauth steuern kannst und es dir die Arbeit leichter macht, dann tu das.

2. Wenn die Anwendung das nicht unterstützt, dann nimm das was geht und dir die Arbeit möglich macht. ;)

 

Da man ggf. beide Varianten gleichzeitig im Einsatz hat, siehst du schon, auf was das hinausläuft. Und ob ich Berechtigungen an Fachabteilungen weiterdelegieren möchte, da hab ich so meine Bedenken. Grundsätzlich klingt das toll, aber muss dann auch kontrolliert und nachgeführt werden. Ansonsten kommt da meist nur "Krempel" bei raus.

 

Bye

Norbert

[v-rtc 88]

vor 5 Minuten schrieb NorbertFe:

Am Ende kommt "Es kommt darauf an" raus.

1. Wenn du es mit SAML/Oauth steuern kannst und es dir die Arbeit leichter macht, dann tu das.

2. Wenn die Anwendung das nicht unterstützt, dann nimm das was geht und dir die Arbeit möglich macht. ;)

 

Da man ggf. beide Varianten gleichzeitig im Einsatz hat, siehst du schon, auf was das hinausläuft. Und ob ich Berechtigungen an Fachabteilungen weiterdelegieren möchte, da hab ich so meine Bedenken. Grundsätzlich klingt das toll, aber muss dann auch kontrolliert und nachgeführt werden. Ansonsten kommt da meist nur "Krempel" bei raus.

 

Bye

Norbert

Das mit den Fachabteilungen funktioniert prima in einem regulierten Unternehmen… oder man arbeitet mit Ihnen Rollenmodelle aus… dann klappt das auch. Ansonsten ja wirds schwierig… 

[NorbertFe 2.027]

vor 35 Minuten schrieb v-rtc:

Das mit den Fachabteilungen funktioniert prima in einem regulierten Unternehmen… oder man arbeitet mit Ihnen Rollenmodelle aus… dann klappt das auch.

Und wieviele sind dir da in Praxis schon begegnet? Ich kenne nur sehr wenige und selbst da gibts immer wieder Stolpersteine, wenn neue Verfahren/Systeme kommen.

[v-rtc 88]

vor 23 Minuten schrieb NorbertFe:

Und wieviele sind dir da in Praxis schon begegnet? Ich kenne nur sehr wenige und selbst da gibts immer wieder Stolpersteine, wenn neue Verfahren/Systeme kommen.

Bei den 2-3 wo ich war funktionierte es … lerne aber dazu… hoffe das bleibt kein Einzelfall

[StefanWe 14]

Die meisten Cloud Applikationen sind doch idr. auch eher kleine Tools die die Fachabteilung unbedingt haben möchte. Das Große ERP, CRM, sonstwas Tool wird dann ja schon eher Unternehmensweit ausgerollt und sollte dann durch die IT gesteuert / berechtigt werden.

 

Aber gerade bei diesen kleinen Tools finde ich die Berechtigungsvergabe innerhalb der Applikation ganz praktisch. Und damit eben auch auf das AGDLP Prinzip zu verzichten.

 

Ähnliches gilt ja auch, wenn man Cloud Tools mit externen Partnern zusammen nutzt. Hier bietet es sich doch an, direkt den Firmenaccount des jeweiligen in der Applikation zu berechtigen, anstatt demjenigen erst einen AD Account zu erstellen, im schlimmsten Fall noch ein Postfach, damit er die Onboardingbestätigungsmail akzeptieren kann.

 

Bin mal auf weitere Meinungen gespannt.

[daabm 1.348]

Am 5.6.2024 um 09:58 schrieb NorbertFe:

Und wieviele sind dir da in Praxis schon begegnet?

Hier...

[NorbertFe 2.027]

Du bist die absolute Ausnahme und außerdem eben nicht der „normale“ Kunde. :p ja es gibt einige wir euch, aber auch dann seid ihr eben nicht der Normalfall.

[falkebo 21]

Das eingesetzte Verfahren sollte davon abhängig gemacht werden:
a) Wer verantwortet/verwaltet die Applikation

b) Was sind die Anforderungen hinsichtlich der Berechtigungen

 

Grundsätzlich ist ein zentrales Berechtigungsmanagement sinnvoll und sollte immer vorhanden sein,
ansonsten ist z.B. ein Least Privilege Prinzip gar nicht wirklich anwendbar.

 

 

 

Am 5.6.2024 um 12:41 schrieb StefanWe:

Ähnliches gilt ja auch, wenn man Cloud Tools mit externen Partnern zusammen nutzt. Hier bietet es sich doch an, direkt den Firmenaccount des jeweiligen in der Applikation zu berechtigen, anstatt demjenigen erst einen AD Account zu erstellen, im schlimmsten Fall noch ein Postfach, damit er die Onboardingbestätigungsmail akzeptieren kann.

 

Sehe ich nicht so. Jede Applikation sollte - wie auch immer - an einen zentralen Identity Provider angebunden werden.
Um externe dafür zu berechtigen, würdest du im idealen Fall einfach einen Gast Benutzer in Entra ID für den externen anlegen und diesen entsprechend für die Applikation berechtigen.

Vorteile:

• Der externe Benutzer nutzt einfach den Identity Provider seiner eigenen Organisation weiter
• Eure Zugriffssteuerung (z.B. mit Conditional Access) stellt trotzdem sicher, dass die Identität für den Zugriff auf die Applikation eure Company Anforderungen erfüllt (MFA, etc.)

Welche Berechtigungen er dann innerhalb der Applikation erhält, darüber kann man im Zweifell streiten.
Wenn die Applikation in der Verantwortung der Fachabteilung liegt, dann kann dies entweder innerhalb von Entra ID delegiert werden (Berechtigung erteilen um Gruppenmitgliedschaften zu verwalten) oder aber innerhalb der Applikation, liegt dann nicht mehr in der Verantwortung der IT.

 

So oder so muss der Zugriff jedoch über den zentralen Identity Provider erfolgen, alles andere führt dazu, dass ihr keine Chance mehr habt eure Daten zu schützen.