Risiko orgweiter Consent

Viele Administratoren sind sich bei der Consent-Abfrage nicht sicher, ob sie alles richtig machen Wir wollen keine Lücken im Sicherheitskonzept haben. Daher habe ich hier mich besonders der Vergabe von Zugriffsrechten bei Graph und anderen Apps mit OAUTH2 / Modern Authentication gewidmet.

Anmeldung 1x1

(Fast) alle Zugriff auf Dienste in der Cloud erfolgen authentifiziert. Eine Anmeldung mit "Benutzername + Kennwort" sind heute bei Cloud-Diensten eher nicht mehr üblich. OAUTH2 / Modern Authentication ist gefordert und die Anmeldung hat sich im Laufe der Zeit geändert. Siehe dazu auch Authentifizierung im Wandel der Zeit.

Mit OAUTH/Modern-Auth gibt es aber mehrere Varianten. Es ist daher wichtig, dass Sie als Administrator die unterschiedlichen Zugriffsrechte auf Schnittstellen und Daten kennen. Denken Sie erst einmal daran, wie sie auf eine Mail in einem Postfach zugreifen wollen. Hier haben wir alle Möglichkeiten an einem Ort:

  • Zugriff als Postfachbesitzer mit Username/Kennwort, z.B: per EWS/IMAP/POP
    Diese Anmeldung gibt es theoretisch noch aber ist per Default nicht mehr erlaubt und sollten Sie nie mehr nutzen. Angeblich beruhten 90% alle missbräuchlichen Zugriffe auf diesem Verfahren, da MFA/Conditional Access nicht möglich ist.
  • Zugriff als Postfachbesitzer mit einer App (Delegated)
    Das ist der reguläre Zugriff von z.B. Outlook auf das eigene Postfach und wird auch als "Delegated Access" bezeichnet
  • Als anderer User mit einer App (Delegated + Stellvertreter Rechte)
    Als Postfachbesitzer können Sie einem anderen Benutzer durchaus "Vollzugriff" oder Stellvertreter-Rechte auf ihr Postfach einräumen. Der andere Benutzer meldet sich aber auch mit seiner App und seinen Anmeldedaten an. Auch das ist ein "Delegated Access" und nutzen alle, die z.B. auf eine "Shared Mailbox" zugreifen.
  • Als Dienstkonto mit einer App (Impersonated + Stellvertreter Rechte)
    Eine Sonderform des Zugriffs als Dienstkonto kennen die Exchange OnPremises Administratoren in Verbindung mit EWS und Impersonation. Das Dienstkonto kann so handeln, als wenn es der Benutzer selbst wäre. Das ist eine sehr weitreichende und damit auch gefährliche Berechtigung, wenn sie nicht korrekt vergeben und limitiert wird. Dies funktioniert auch in Exchange Online, solange EWS noch angeboten wird
  • Als App/Service Principal  (App Permission)
    In der Cloud versuchen wir aber solche "Dienstkonten" zu vermeiden, die wie Benutzerkonten aussehen. Hier nutzen wir besser "Service Principals", die Berechtigungen auf Daten von Benutzern oder Management-APIs bekommen. Das ist dann der Zugriff als App über entsprechende APIs wie Microsoft Graph.

Für den Zugriff auf Management APIs sollten sie nur in Ausnahmefällen ein reguläres Benutzerkonto nutzen und nur diesem die Berechtigungen geben.

Die Sache mit dem Consent

Seit dem Wechsel von einer Anmeldung mit Benutzername/Kennwort zu "Modern Auth" (Siehe Authentifizierung im Wandel der Zeit und OAUTH2 / Modern Authentication) können Administratoren beim Einsatz von Conditional Access sehr viel mehr die Zugriffe der Benutzer steuern. Neben gültigen Anmeldedaten kann ich den Zugriff auf Applikationen beschränken. Bei Microsoft 365 sind einige Apps wie Word, Excel, PowerPoint, Outlook etc. schon voreingestellt. Wenn ich aber eine eigene App oder ein Skripte nutzen möchte, muss ich dazu erst eine App Registration anlegen und die benötigten Rechte konfigurieren. Für Microsoft Graph habe ich den Prozess auf Graph Berechtigungen beschrieben.

Aber es gibt auch ein einen Wege, die erforderlichen Rechte bei der ersten Anmeldung anzufordern. Die Applikation verbindet sich mit dem Authentifizierungsdienst und liefert mit, welche Rechte Sie gerne hätte. Wenn es die entsprechende Definition nicht gibt, öffnet sich ein Fenster mit der Anzeige der Rechte, der App und bittet um Zustimmung.

Je nach Konfiguration des Tenants (Siehe Checkliste Tenant Einrichtung) kann das ein Benutzer für seine Daten machen. Wenn der angemeldete Benutzer auch administrative Rechte hat, dann kann im gleichen Dialog auch die Berechtigung für den gesamten Tenant gegeben werden. Sie können ja einfach mal auf https://draw.io surfen und ein Diagramm auf ihrem OneDrive speichern.

Damit die App, also das JavaScript im Browser, mit ihren Berechtigungen auf ihre OneDrive-Dateien zugreifen kann, muss die App die "delegate"-Permission bekommen. Wenn der Administrator diese Funktion beschränkt hat, dann sehen sieh einen Fehler. Wenn der Admin der App die Rechte schon generell gewährt hat, dann kommt gar keine Abfrage. Nur wenn die App unter ihrem Namen noch keine Rechte hat und der Freigabe durch den Benutzer nicht unterbunden ist, dann können Sie als Anwender selbst zustimmen. Sollten Sie auch noch Admin über den Tenant sein, dann sehen Sie noch die Checkbox "Zustimmen im Namen ihrer Organisation".

Ich bin ein Freund davon, dass die Eintragung eines Consent durch einen Administrator im Tenant erfolgt. Es ist wie die Installation und Freischaltung einer Applikation zu sehen. Bisher durften Anwender ja in der Regel auch nicht selbst Software auf ihrem PC installieren. Im AzureAD können Sie dann gleich Conditional Access-Regeln anpassen und vielleicht einen Verzeichnisabgleich zur Benutzerverwaltung zur App einrichten.

Wenn Sie sich aber den Dialog anschauen, dann gebe ich als Benutze der App nur die Rechte auf "meine" Daten. Wenn ich als Administrator hier zustimme, dann geben ich jedem Benutzer die Möglichkeit, die App mit den eigenen seinen Zugriffsrechten zu nutzen und auf seine Daten zuzugreifen.

Diese Konfiguration gewährt der App also nicht das Recht, auf alle Daten aller Benutzer zuzugreifen, sondern nur einen "Delegated"-Zugriff.

Aber auch das ist im Grund schon ein Risiko, wie ich auf Phishing mit Consent-Anforderung schon beschrieben habe.

Nehmen Sie einfach mit, dass Sie beim "Consent" für Berechtigungen genau hinschauen, welche Berechtigungen sie tatsächlich welchen Programmen und Personen zuweisen.

App-Permission und Service Principal

Solange jede Lösung ihre eigene App mitbringt, können Sie die Berechtigungen pro App individuell gewähren. Knifflig wird, es wenn Tools und Skripte z.B. die gleichen PowerShell-Module verwenden, die sich immer mit der gleichen AppID bzw. dem gleichen Service Principal gegenüber dem Service ausweisen. Lassen Sie mich ein Beispiel machen.

Wenn Sie z.B. ein Skript bauen, welches Rechte zum Auslesen von AuditLogs anfordert, dann ist dies per Microsoft Graph PowerShell schnell erledigt.

# Verbinden mit Graph zu einem bestimmten Tenant.
PS C:\> Connect-MgGraph `
   -Scopes AuditLog.Read.All,Directory.Read.All `
   -TenantId msxfaqdev.onmicrosoft.com 

# Kontrolle des Tenant
PS C:\> (Get-MgOrganization).verifieddomains

Capabilities                      IsDefault IsInitial Name                           Type
------------                      --------- --------- ----                           ----
Email, OfficeCommunicationsOnline False     True      msxfaqdev.onmicrosoft.com      Managed
None                              True      False     msxfaq.net                     Managed
None                              False     False     msxfaqdev.mail.onmicrosoft.com Managed
None                              False     False     msxfaqdev.de                   Managed

Natürlich wird nach der Anmeldung auch hier ein Consent erwartet:

Der Zugriff über Graph ist für Administratoren nicht ungewöhnlich und das MGGraph-Modul ist nicht einmal verifiziert. Auch das angeforderte Recht "Überwachungsprotokolldateien lesen" können sie erwarten, weil sie ihr PowerShell-Script genau dazu entwickelt haben. Aber was hat es mit der Checkbox "Zustimmung im Namen ihrer Organisation" zu tun? Wenn Sie diese aktivieren und als Administrator bestätigen, dann tragen Sie die Rechte für die Organisation ein, d.h. jeder Anwender kann nun ebenfalls bei Nutzung der MGGraph-Powershell sich als Anwender anmelden und die Berechtigung anfordern. Da sehen sie auch im Azure Portal:

Wenn wir uns die Graph-Session anschauen, dann sehen Sie, dass der aktuelle Benutzer die "Delegated"-Berechtigung zum Zugriff auf AuditLog.Read.All u.a. hat.

PS C:\> Get-MgContext

ClientId               : 14d82eec-204b-4c2f-b7e8-296a70dab67e
TenantId               : 604d9047-44e5-443a-ad8f-98abe5748b0a
Scopes                 : {AuditLog.Read.All, Directory.Read.All, openid, profile…}
AuthType               : Delegated
TokenCredentialType    : InteractiveBrowser
CertificateThumbprint  :
CertificateSubjectName :
Account                : Clouduser1@msxfaqdev.onmicrosoft.com
AppName                : Microsoft Graph Command Line Tools
ContextScope           : CurrentUser
Certificate            :
PSHostVersion          : 7.3.8
ManagedIdentityId      :
ClientSecret           :
Environment            : Global

Entsprechend kann ich nun per Graph Power die AuditLogs lesen.

PS C:\Program Files\PowerShell\7> Get-MgAuditLogSignIn -Top 1 | fl

AppDisplayName                   : Microsoft Graph Command Line Tools
AppId                            : 14d82eec-204b-4c2f-b7e8-296a70dab67e
AppliedConditionalAccessPolicies : {}
ClientAppUsed                    : Mobile Apps and Desktop clients
ConditionalAccessStatus          : notApplied
CorrelationId                    : d6ba1f8c-3906-4818-93e0-d507ed994b70
CreatedDateTime                  : 19.10.2023 11:53:13
DeviceDetail                     : Microsoft.Graph.PowerShell.Models.MicrosoftGraphDeviceDetail
IPAddress                        : 2a00:6020:4e92:e200:4403:3b15:ac43:4e9d
Id                               : 4e77a804-c51c-40a4-b5ae-440ee4495800
IsInteractive                    : True
Location                         : Microsoft.Graph.PowerShell.Models.MicrosoftGraphSignInLocation
ResourceDisplayName              : Microsoft Graph
ResourceId                       : 00000003-0000-0000-c000-000000000000
RiskDetail                       : none
RiskEventTypes                   : {}
RiskEventTypesV2                 : {}
RiskLevelAggregated              : none
RiskLevelDuringSignIn            : none
RiskState                        : none
Status                           : Microsoft.Graph.PowerShell.Models.MicrosoftGraphSignInStatus
UserDisplayName                  : Frank Carius DEV2
UserId                           : 7263485b-b2b1-46d5-9eec-22831be5dce2
UserPrincipalName                : adminfc2@msxfaqdev.onmicrosoft.com
AdditionalProperties             : {}

Soweit ist das nicht überraschend und sogar erwünscht.

Berechtigungen akkumulieren sich

Nun ist es aber so, dass über die Zeit verschiedene Administratoren oder auch Benutzer mit der MGGraph-PowerShell arbeiten. Jeder braucht vielleicht noch ein paar weitere Berechtigungen und über weitere Consent-Abfragen und deren Zustimmung bekommt die "App MGGraph" immer mehr Berechtigungen zugestanden. Da diese Berechtigungen auch noch Tenant-weit zugewiesen werden könnten, stehen sie grundsätzlich auch jedem Anwender erst einmal zur Verfügung. Es sind aber alles "Delegated"-Permissions, d.h. der Benutzer muss sich immer noch selbst anmelden.

Missbrauch als User?

Die Frage ist nun, ob es auch einem normalen Anwender ausreicht, wenn er mittels MGGRAPH sich zum Tenant verbindet und auch das Recht "AuditLog.Read.All" anfordert. Ich habe mir dann einen neuen Cloud Only Benutzer genommen, der keinerlei administrativen Rollen hat und auch hier die Befehle wiederholt. Eine "Consent-Rückfrage" kam natürlich nicht, da der Administrator diesen schon für den Tenant eingetragen hat.

PS C:\> Connect-MgGraph `
            -Scopes AuditLog.Read.All,Directory.Read.All `
            -TenantId msxfaqdev.onmicrosoft.com

PS C:\> Get-MgContext

ClientId               : 14d82eec-204b-4c2f-b7e8-296a70dab67e
TenantId               : 604d9047-44e5-443a-ad8f-98abe5748b0a
Scopes                 : {AuditLog.Read.All, Directory.Read.All, openid, profile…}
AuthType               : Delegated
TokenCredentialType    : InteractiveBrowser
CertificateThumbprint  :
CertificateSubjectName :
Account                : user1@msxfaqdev.onmicrosoft.com
AppName                : Microsoft Graph Command Line Tools
ContextScope           : CurrentUser
Certificate            :
PSHostVersion          : 7.3.8
ManagedIdentityId      :
ClientSecret           :
Environment            : Global

Wer nun aber denkt, dass ich allein mit einem gültigen SAML-Token mit der Berechtigung "AuditLog.Read.All" auch an die interessanten Protokolle kommen würde, irrt.

PS C:\> Get-MgAuditLogSignIn -Top 1
Get-MgAuditLogSignIn_List: User is not in the allowed roles

Status: 403 (Forbidden)
ErrorCode: Authentication_RequestFromUnsupportedUserRole
Date: 2023-10-19T12:37:24

Headers:
Transfer-Encoding             : chunked
Vary                          : Accept-Encoding
Strict-Transport-Security     : max-age=31536000
request-id                    : 14d3d132-f49b-4269-8757-96a8f3a7c707
client-request-id             : a11a651d-1f2e-47f0-aa58-0afce77048e3
x-ms-ags-diagnostic           : {"ServerInfo":{"DataCenter":"Germany West Central","Slice":"E","Ring":"5","ScaleUnit":"002","RoleInstance":"FR3PEPF00000167"}}
Date                          : Thu, 19 Oct 2023 12:37:24 GMT

Der Benutzer hat hier zwar die Möglichkeit sich mit graph.microsoft.com zu verbinden und er kann sogar ein Token mit der gewünschten Berechtigung anfordern. Allerdings prüft das Backend dann immer noch, ob der Anwender in den entsprechenden Rolegroup ist. Das ist er hier nicht und daher bekommt er auch den Fehler "Authentication_RequestFromUnsupportedUserRole"

Wo ist das Problem?

Es gibt keine echte Lücker aber wer auf Sicherheit bedacht ist. verfolgt eine mehrstufige Strategie und dazu gehören:

  • Wer
    Also das Konto, sei es ein Benutzer oder eine App, der den Zugriff versucht
  • Womit
    Mit welchem Client. Das ist bei Benutzern hilfreich, die nur mit Outlook ihr Postfach lesen dürfen aber nicht mit Thunderbird. Oder Administratoren die nur mit einer besonderen Provisioning-App aber nicht per Graph oder PowerShell arbeiten würden.
  • Worüber
    Damit meine ich die Schnittstelle, z.B. Graph, EWS, IMAP o.ä.
  • Wodurch
    Das Backend kann die Identität und deren Mitgliedschaft in Berechtigungsgruppen und Rollengruppen prüfen

Wenn nun viele Anwender einfach "MGGRAPH" nutzen, und diese App den Consent für die Anforderung von bestimmten Berechtigungen hat, dann könnte jeder Anwender auch diese Rechte anfordern. Das passiert natürlich nur, wenn ein Administrator die Rechte mit einem "AdminConsent" vergeben hat.

Kritisch wäre es, wenn eine Backend-Applikation einfach nur die SAML-Rechte als einziges Kriterium nutzt und nicht mehr zusätzlich den ebenfalls enthaltenen Benutzer und Gruppen mit auswertet.
Ich kann nicht ausschließen, dass alle Services mit Anmeldung

Wünschenswert wäre daher vielleicht doch die Delegierung der Berechtigungen pro App an jeden Benutzer, der diese App verwenden soll. Das kann, wenn vom Administrator erlaub, jeder Benutzer selbst anfordern. dann könnte sich der Benutzer natürlich auch all die Rechte anfordern, die ich gerade über die tenantweite Zuteilung als AdminConsent unterbinden will. Andererseits gibt es wohl kaum einen Administrator, der nun bei jedem Benutzer die Berechtigungen einträgt.

Das Problem beschränkt sich auf Code, der sich mit einer AppID aber unterschiedlichen Anwendern beim Delegated Login meldet.

Schön ist das aber doch nicht, wie schon Tony Redmond geschrieben hat:

In fact, it’s a lousy idea. Microsoft needs to come up with a better way of allowing administrators to run Graph SDK cmdlets interactively without creating a security problem
Quelle: https://practical365.com/connect-microsoft-graph-powershell-sdk/

Option: Nutzerkreis einschränken

Leider gibt es aber keine einfache Lösung, da die Rechte für eine App entweder global für den Tenant oder individuell pro Benutzer vergeben werden. Allerdings kann ich Nutzung einer App auf Benutzergruppen beschränken.

Hinweis: Damit blockiere ich nicht den Zugriff auf Graph generell sondern nur den Zugriff über die MGGraph-Module, die Anwender eher nicht nutzen.

Wir können einfach den kleinen Schieber unter Properties bei der App "Microsoft Graph Command Line Tools" aktivieren und pflegen dann links in "Users and Groups" den Kreis der berechtigten Personen kontrollieren. So kann ich sehr einfach den Zugriff auf Microsoft Graph über die "App Microsoft Graph Command Line Tools" auf Administratoren beschränken.

MGGraph und App-Permission

Das Problem ist nicht existent, wenn Sie MGGraph mit einer eigenen App-Registration verwenden, d.h. eine Applikation sich mit der PowerShell anmelden. Für die Automatisierung ist dies sowieso der bessere Weg, da dann auch Conditional Access oder MFA kein Problem darstellen. Der Administrator muss natürlich dazu eine entsprechende App im Tenant samt Client Secret (Kennwort oder Zertifikat) einrichten.

Ich bevorzuge hier Zertifikate. Es reicht ein "SelfSigned"-Zertifikat mit der gewünschten Laufzeit, welches auf dem ausführenden Computer oder im Azure Keyvault sicher hinterlegt wird. Kennworte im Code oder Konfigurationsdateien sind weniger sicher.

Die Verbindung starten Sie dann wie folgt:

Connect-MgGraph `
   -ClientId "<guid der App registration>" `
   -TenantId "<guid des Tenant>" `
   -CertificateThumbprint "<thumbprint des Zertifikats"

Die Berechtigungen für die App können Sie als Administrator dann komplett losgelöst von Benutzern oder "Admin Consent" eintragen. Hier gibt es auch keine Anmeldung als "Delegate Access".

Weitere Links