Sicherheit in Power Pages basiert auf Ebenen. Das Verständnis dieses hierarchischen Modells ist entscheidend für die Implementierung sicherer Kundenportale. Dieser Guide erklärt, wie Administratoren, Custom Roles, authentifizierte Benutzer, anonyme Besucher und System-Komponenten zusammenarbeiten – von der Authentifizierung bis zur Feldebene.
Fünf Ebenen greifen dabei ineinander: anonyme Besucher, authentifizierte Benutzer, benutzerdefinierte Rollen, die Administrator-Rolle und die System-Komponenten (Web API, Forms, Lists, Liquid Templates). Wer versteht, wie diese Ebenen zusammenspielen, kann Berechtigungen gezielt statt pauschal vergeben.
Wichtigste Erkenntnisse
- Administrator ist nur ein Name: keine automatischen Privilegien, alle Zugriffe erfordern explizite Table Permissions
- Mehrere Rollen, kumulative Berechtigungen: Benutzer können mehrere Rollen haben, Berechtigungen addieren sich
- Die Rolle „Authenticated Users" ist automatisch: Sie kann nicht entfernt werden und gilt für ALLE eingeloggten Benutzer
- Bevorzugen Sie spezifische Scopes: Contact oder Account Scope statt Global, wo immer möglich
- System-Komponenten respektieren Berechtigungen: Web API, Forms und Lists halten sich an Table Permissions
Das hierarchische Zugriffskontrollmodell auf einen Blick
Stellen Sie sich die Sicherheitsarchitektur als Gebäude mit fünf Stockwerken vor. Jede Ebene hat eine eigene Farbe, eine eigene Zielgruppe und eigene Spielregeln:
Die Sicherheitsebenen im Detail
1. Administrator Web Role
Kernkonzept
- Nur ein Web-Role-Name – keine besonderen Privilegien
- Alle Datenzugriffe erfordern explizite Table Permissions
- Gleiche Regeln wie für jede Custom Role
- Verwenden Sie spezifische Scopes (Contact/Account) statt Global
Was Sie tun können
- Portal-Einstellungen und Konfiguration verwalten
- Web Roles zu Benutzern zuweisen
- Seiten und Inhalte verwalten
- Table Permissions konfigurieren (falls gewährt)
Zugriffstypen (Table Permissions)
- Global: alle Datensätze in der Tabelle
- Contact: mit dem Benutzer verbundene Datensätze
- Account: mit dem Konto des Benutzers verbundene Datensätze
- Self: nur der eigene Contact-Datensatz des Benutzers
Best Practices: Vermeiden Sie Global Scope wo möglich, verwenden Sie Contact oder Account Scope für die meisten Szenarien, folgen Sie dem Prinzip der geringsten Rechte und planen Sie regelmäßige Berechtigungsaudits ein.
2. Custom Web Roles
So funktioniert es
- Erstellen Sie Rollen für spezifische Benutzergruppen
- Weisen Sie Rollen Table und Page Permissions zu
- Benutzer können mehrere Rollen haben (kumulativer Zugriff)
- Konfiguration über die Portal Management App
Häufige Beispiele
- Partner: Zugriff auf Daten ihrer Kunden
- Kunde: B2B-Zugriff auf Account-Ebene
- Support-Agent: Case-Management-Rechte
- Abteilungsleiter: Team-Datenzugriff
Berechtigungs-Scopes
- Account Scope: perfekt für B2B-Szenarien
- Contact Scope: zugehörige Datensätze des Benutzers
- Parent Scope: hierarchische Beziehungen
- Child Permissions: Zugriff auf verbundene Tabellen
Konfiguration
- Security Workspace im Design Studio (modern)
- Oder Power Pages Management App (Dataverse)
- Table Permissions mit spezifischen Scopes hinzufügen
- Benutzer manuell oder via Power Automate zuweisen
3. Authentifizierte Benutzer
Wichtig: implizite Rolle
- ⚠️ Automatisch ALLEN eingeloggten Benutzern zugewiesen
- ⚠️ Kann nicht von Benutzern entfernt werden
- ⚠️ Nur EINE pro Website
- ⚠️ Seien Sie vorsichtig mit Berechtigungen an dieser Stelle
So funktioniert es
- Benutzer werden durch Dataverse Contacts repräsentiert
- Können zusätzliche Custom Roles haben
- Berechtigungen sind kumulativ über alle Rollen
- Verwaltet über die Portal Management App
Typisches Setup
- Contact Scope: eigene Datensätze des Benutzers
- Self Scope: nur der eigene Contact-Datensatz
- Lesezugriff: Referenzdaten (Produkte etc.)
- Erstellen: Cases, Leads, Support-Anfragen
Authentifizierungsmethoden
- Microsoft Entra ID (für interne Benutzer)
- Microsoft Entra External ID (für externe Kunden und Partner)
- SAML 2.0, OpenID Connect
- Lokale Authentifizierung (Benutzername/Passwort)
- Azure AD B2C
- Social Provider (Google, LinkedIn, etc.)
4. Anonyme Benutzer
Anonymous-Users-Rolle
- Spezielle Rolle für nicht-authentifizierte Besucher
- Nur EINE pro Website
- Respektiert Table Permissions (aber nicht Page Permissions)
- Zugriff auf öffentliche Inhalte und Formulare
Website-Sichtbarkeit
- Standard: nur intern (Microsoft Entra Auth)
- Go-Live: Umschalten auf „Public"
- Schützt teilweise entwickelte Websites
- Verhindert versehentliche Datenlecks
Worauf sie zugreifen können
- Öffentliche Seiten (Homepage, Marketing)
- Knowledge-Base-Artikel (falls konfiguriert)
- Kontaktformulare
- Login- und Registrierungsseiten
Datenzugriff
- Kann Table Permissions haben (über die Anonymous-Rolle)
- Daten über Formulare übermitteln
- Gefilterte Listen anzeigen (falls konfiguriert)
- Kein direkter Dataverse-API-Zugriff
5. System-Komponenten
Portals Web API
- CRUD-Operationen auf Dataverse-Tabellen
- Verfügbar unter
/_api/-Endpunkten - Muss pro Tabelle aktiviert werden (Site Settings)
- Erfordert Power Pages 9.3.3.x oder neuer
Sicherheits-Fakten
- ✅ Web API respektiert Table Permissions
- ✅ Verwendet Portal-Session-Authentifizierung
- ✅ Erfordert CSRF-Token für alle Aufrufe
- ✅ Column Permissions für Field-Level Security
Site Settings (erforderlich)
Weitere Komponenten
- Forms & Lists: respektieren Table Permissions
- Liquid Templates: Zugriff auf das {{ user }}-Objekt
- JavaScript: client-seitige Code-Ausführung
- FetchXML: Dataverse-Daten abfragen
Einschränkungen
- Nicht für Drittanbieter-Integration konzipiert
- Konfigurationstabellen nicht unterstützt
- Actions und Functions nicht verfügbar
- Server-seitiges Caching für Performance
Sicherheits-Best-Practices
✅ Empfohlen
- Contact oder Account Scope für B2B-Szenarien verwenden
- Das Prinzip der geringsten Rechte anwenden
- Column Permissions für Sicherheit auf Feldebene aktivieren
- MFA für sensible Bereiche konfigurieren
- Regelmäßige Sicherheitsaudits der Rollenzuweisungen
- Dataverse Auditing für Compliance aktivieren
❌ Zu vermeiden
- Global Scope, es sei denn absolut notwendig
- Weitreichende Berechtigungen für die Rolle „Authenticated Users"
- Sicherheitslogik nur client-seitig in JavaScript implementieren
- Web API ohne ordentliche Table Permissions aktivieren
- Authentifizierungsanbieter ohne klare Strategie mischen
Implementierungsleitfaden
Ein praktischer Schritt-für-Schritt-Ansatz zur Implementierung sicherer Power-Pages-Portale:
📋 Setup-Checkliste
-
1. Planen Sie Ihre Rollen:
Ordnen Sie Geschäftsrollen (Partner, Kunde, Intern) den Web Roles zu
-
2. Definieren Sie Table Permissions:
Bestimmen Sie, auf welche Tabellen jede Rolle zugreifen muss und mit welchem Scope
-
3. Konfigurieren Sie die Authentifizierung:
Richten Sie Entra ID (intern) und Entra External ID (extern) ein
-
4. Implementieren Sie Row-Level Security:
Verwenden Sie Contact oder Account Scope, damit Benutzer nur ihre Daten sehen
-
5. Aktivieren Sie Field-Level Security:
Konfigurieren Sie Column Permissions für sensible Felder
-
6. Testen Sie gründlich:
Überprüfen Sie Berechtigungen mit Testbenutzern in jeder Rolle
-
7. Aktivieren Sie Auditing:
Schalten Sie Dataverse Auditing für Compliance-Tracking ein
Fazit
Die Power-Pages-Sicherheitsarchitektur bietet Zugriffskontrolle auf Enterprise-Niveau, ohne dass tiefes Sicherheits-Know-how erforderlich ist. Wer das hierarchische Modell versteht und die Best Practices befolgt, kann sichere Kundenportale erstellen, die sensible Daten schützen und gleichzeitig exzellente Benutzererfahrungen bieten.
Und wenn Ihr Portal bereits live ist und Sie wissen wollen, ob die Konfiguration wirklich so dasteht, wie sie hier beschrieben ist: Genau das prüft mein Security-Audit zum Festpreis, strikt lesend und mit risikopriorisiertem Bericht.
