Power Pages Table Permissions erklärt

Table Permissions sind das Fundament der Datensicherheit in Microsoft Power Pages. Sie steuern, welche Dataverse-Datensätze Ihre Portal-Benutzer lesen, erstellen, aktualisieren oder löschen können. Ohne korrekte Table Permissions wird jeder Datenzugriff standardmäßig blockiert.

Dieses Cheat Sheet behandelt 15 bewährte Sicherheitsmuster, die praxisnahe Zugriffskontroll-Herausforderungen lösen. Egal ob Sie ein Kundenportal, Partnerportal oder Mitarbeiter-Self-Service-Portal entwickeln — diese Muster helfen Ihnen, sicheren und skalierbaren Datenzugriff umzusetzen.

Global Scope

Zugriff auf alle Datensätze unabhängig vom Besitzer. Sparsam einsetzen.

Contact Scope

Zugriff auf Datensätze, die mit dem Kontaktdatensatz des Benutzers verknüpft sind.

Account Scope

Zugriff auf Datensätze, die mit dem übergeordneten Konto des Benutzers verknüpft sind.

Self Scope

Zugriff ausschließlich auf den eigenen Kontaktdatensatz des Benutzers.

Parent Scope

Zugriff über eine übergeordnete Tabellenbeziehung erben.

Tino Rabe · Microsoft MVP für Power Pages

15 Power Pages Table Permission Muster

Sichern Sie Ihre Portaldaten effektiv.

1
🌍
Global Nur-Lesen
Alle authentifizierten Benutzer können alle Datensätze lesen. Kein Schreibzugriff.
BEISPIEL:
Access: Global
Privileges: Read
2
👤
Contact Scope CRUD
Benutzer können nur Datensätze erstellen/lesen/aktualisieren/löschen, die mit ihrem Kontakt verknüpft sind.
BEISPIEL:
Access: Contact
Privileges: Read, Write, Create, Delete
3
🏢
Account Scope Lesen
Benutzer sehen Datensätze, die mit ihrem Konto verknüpft sind (unternehmensweite Sichtbarkeit).
BEISPIEL:
Access: Account
Privileges: Read
4
🔒
Nur eigener Zugriff
Benutzer können nur ihren eigenen Kontaktdatensatz lesen/aktualisieren. Restriktivste Option.
BEISPIEL:
Access: Self
Privileges: Read, Write
5
🔗
Parent-Child-Beziehung
Zugriff auf untergeordnete Datensätze über die übergeordnete Table Permission. Sauberes und skalierbares Muster.
BEISPIEL:
Parent: Case (Contact)
Child: Note (via regardingobjectid)
6
👁️
Anonymer öffentlicher Zugriff
Nicht-authentifizierten Benutzern das Lesen öffentlicher Datensätze ermöglichen. Mit Vorsicht verwenden!
BEISPIEL:
Web Role: Anonymous
Access: Global, Read only
7
➕
Nur-Erstellen-Berechtigung
Benutzer können Datensätze erstellen, aber nicht zurücklesen. Nützlich für Einsendungen.
BEISPIEL:
Access: Global
Privileges: Create only
8
📎
Lesen + Anhängen-Muster
Benutzer können Datensätze lesen und zugehörige Datensätze anhängen (z. B. Notizen zu Cases hinzufügen).
BEISPIEL:
Privileges: Read, Append
Parent: Case → Child: Note
9
🎯
Mehrstufiger Parent Scope
Berechtigungen über 3+ Ebenen verketten (Contact → Case → Note → Attachment).
BEISPIEL:
Contact → Case
Case → Note → Attachment
10
🏛️
Konto-Hierarchiezugriff
Hierarchiesicherheit aktivieren, um Zugriff auf über-/untergeordnete Konten zu gewähren.
BEISPIEL:
Übergeordnete Konto-Berechtigungen
werden auf untergeordnete Konten übertragen
11
👥
Rollenbasierte Lesen/Schreiben-Trennung
Verschiedene Web-Rollen erhalten verschiedene Berechtigungen (Admins: CRUD, Benutzer: Lesen).
BEISPIEL:
Admin Role: Read, Write, Delete
User Role: Read only
12
🔗
AppendTo-Beziehung
Verknüpfung von Datensätzen mit übergeordneten Datensätzen ermöglichen (Gegenteil von Append).
BEISPIEL:
Privilege: AppendTo
Notiz mit vorhandenem Case verknüpfen
13
🚫
Kein-Löschen-Richtlinie
Lesen/Schreiben/Erstellen gewähren, aber nie Löschen. Datenintegrität wahren.
BEISPIEL:
Privileges: Read, Write, Create
(Löschen bewusst weggelassen)
14
🔓
Nur-Lesen für Anonyme, CRUD für Authentifizierte
Öffentliche Benutzer können browsen, angemeldete Benutzer können vollständig interagieren.
BEISPIEL:
Anonymous: Read
Authenticated: Read, Write, Create
15
⚠️
Workaround für polymorphe Lookups
Polymorphe Lookups werden nicht unterstützt. Separate Berechtigungen je Entitätstyp verwenden.
BEISPIEL:
Statt regardingobjectid
fallspezifische Lookups verwenden
⬇️ Als PDF herunterladen

Wann welches Table-Permission-Muster einsetzen

Die Wahl des richtigen Table-Permission-Musters hängt von Ihren Geschäftsanforderungen ab. Hier eine kurze Entscheidungshilfe:

Für Kundenportale

  • Contact Scope CRUD für kundenspezifische Datensätze (Cases, Bestellungen, Rechnungen)
  • Nur eigener Zugriff for profile management
  • Parent-Child-Beziehung for related records (case notes, order lines)

Für Partnerportale

  • Account Scope für unternehmensweite Sichtbarkeit
  • Konto-Hierarchiezugriff for multi-level partner structures
  • Rollenbasierte Trennung für Partner-Admins vs. normale Benutzer

Für öffentliche Websites

  • Anonymer öffentlicher Zugriff for knowledge articles, FAQs
  • Nur-Erstellen-Berechtigung for contact forms, lead capture
  • Nur-Lesen Anonym + CRUD Authentifiziert für Produktkataloge mit Nutzerbewertungen

Best Practices

  • Immer mit der restriktivsten Berechtigung starten und bei Bedarf erweitern
  • Parent-Child-Beziehungen statt Global Scope verwenden, wann immer möglich
  • Berechtigungen mit verschiedenen Benutzerkonten testen, bevor die Seite live geht
  • Die Berechtigungsstruktur für künftige Wartung dokumentieren
  • Web API Column Permissions für sensible Felder in Betracht ziehen

Benötigen Sie Hilfe bei der Implementierung von Table Permissions in Ihrem Power Pages-Projekt? Kostenlose Beratung buchen bei einem Microsoft MVP.

Microsoft Power Pages-Beratung von Tino Rabe, MVP