Ihr Power-Pages-Portal absichern: Ein tiefer Einblick in Tabellenberechtigungen und Bereiche

Von Mirko Peters · 2026-08-11

Willkommen zurück im Podcast-Blog! Wenn Sie kundenorientierte Webanwendungen auf der Microsoft Power Platform entwickeln, darf Sicherheit kein nachträglicher Gedanke sein. Power Pages ist…

Automatisch mit KI aus dem Originalbeitrag übersetzt. Englisches Original lesen

Willkommen zurück im Podcast-Blog! Wenn Sie kundenorientierte Webanwendungen auf der Microsoft Power Platform entwickeln, darf Sicherheit kein nachträglicher Gedanke sein. Power Pages ist ein hervorragendes Werkzeug, um leistungsfähige externe Portale zu veröffentlichen, die direkt mit Dataverse verbunden sind. Doch mit großer Macht kommt große Verantwortung, und zwar konkret die Verantwortung, dafür zu sorgen, dass sensible Daten Ihrer Organisation nicht versehentlich an die Öffentlichkeit gelangen oder organisatorische Grenzen überschreiten.

In diesem Beitrag gehen wir ausführlich auf die grundlegenden Sicherheitskonzepte der Architektur ein, die wir in unserer letzten Folge besprochen haben. Falls Sie sie noch nicht gehört haben, sehen Sie sich unbedingt die Folge Build Customer Portals with Power Pages and Dataverse an. Sie enthält eine vollständige Anleitung zur Einrichtung Ihrer Umgebung, zur Verwaltung externer Identitäten und zur Bereitstellung Ihrer ersten Portallösung.

Tauchen wir tief in die Mechanik der Power-Pages-Sicherheit ein, beginnend mit der Planung Ihrer Datengrenzen und der Verwaltung von Tabellenberechtigungen.

Einführung in die Sicherheit von Power Pages

Wenn Sie eine Power-Pages-Website erstellen, bietet die Plattform eine flexible, hochgradig anpassbare Oberfläche. Darunter verbirgt sich jedoch eine direkte Verbindung zu Ihrer Microsoft-Dataverse-Umgebung. Wenn Sicherheitskonfigurationen fehlerhaft verwaltet werden, könnte jeder einzelne Datensatz Ihrer Datenbank über einen ungesicherten Endpunkt oder eine schlecht eingegrenzte Listenansicht offengelegt werden.

Die Sicherheit in Power Pages beruht auf einer mehrschichtigen Verteidigungsstrategie. Auf der äußeren Ebene stehen Authentifizierungsmechanismen, etwa Azure AD B2C, lokale Konten oder externe Identitätsanbieter, die sicherstellen, dass sich Benutzer ausweisen. Auf der inneren Ebene stehen Webrollen und Dataverse-Tabellenberechtigungen. Diese Berechtigungen legen genau fest, was authentifizierte Identitäten sehen, erstellen, aktualisieren oder löschen dürfen. Genau darauf kommt es an: Ob Sie ein sicheres Unternehmensportal betreiben oder einen massiven Datenschutzvorfall riskieren, entscheidet sich hier.

Datengrenzen und Tabellenberechtigungen planen

Bevor Sie in Power Pages Studio auch nur eine Schaltfläche anklicken, sollten Sie zum Whiteboard greifen und Ihre Datengrenzen sorgfältig festlegen. Dies sind wohl die wichtigsten 15 Minuten im gesamten Lebenszyklus Ihres Portalprojekts.

Beginnen Sie damit, eine vollständige Übersicht aller Dataverse-Tabellen zu erstellen, die Sie externen Benutzern zugänglich machen möchten. Legen Sie für jede Tabelle die absolut notwendigen CRUD-Aktionen fest. Benötigt ein Kunde wirklich die Möglichkeit, eine Rechnung zu löschen, oder reichen Lese- und Anfügerechte? Sobald Sie die Aktionen definiert haben, bestimmen Sie den Datensatzbereich für jede Tabelle:

• Kontakt-Bereich: Der Benutzer kann nur mit Datensätzen arbeiten, die direkt seinem eigenen Kontaktdatensatz zugeordnet sind.
• Konto-Bereich: Der Benutzer kann mit Datensätzen arbeiten, die dem gesamten Unternehmen bzw. dem Konto zugeordnet sind.
• Globaler Bereich: Der Benutzer kann alle Datensätze der gesamten Tabelle sehen (typischerweise für öffentliche Artikel der Wissensdatenbank oder Metadaten reserviert).

Wenn Sie diese Grenzen frühzeitig festlegen, schaffen Sie eine Grundlage nach dem Prinzip der minimalen Berechtigungen, noch bevor in Ihrer Entwicklungsumgebung irgendeine Konfiguration entsteht.

Kontakt- und Konto-Bereiche im Vergleich

Einer der häufigsten Stolpersteine für Entwickler, die neu bei Power Pages sind, ist das Verständnis der Unterschiede zwischen Kontakt- und Konto-Bereichen. Die Wahl des falschen Bereichs kann entweder die Benutzererfahrung vollständig beeinträchtigen, weil relevante Unternehmensdaten ausgeblendet werden, oder vertrauliche Daten versehentlich für unbefugte Personen freigeben.

Der Kontakt-Bereich ist für individuelle Portale im Stil von Endkundenangeboten konzipiert. Wenn sich ein Benutzer anmeldet und ein Supportticket einreicht, stellt eine Berechtigung mit Kontakt-Bereich sicher, dass er nur Fälle einsehen kann, bei denen er ausdrücklich als primärer Kontakt oder Ersteller eingetragen ist. Meldet sich ein anderer Benutzer aus genau demselben Unternehmen an, sieht er die persönlichen Supporttickets seines Kollegen nicht.

Der Account Scope ist dagegen für B2B-Portalarchitekturen gedacht. In einem B2B-Szenario soll ein Account Manager oder ein zentraler Einkäufer alle Fälle, Bestellungen und Rechnungen einsehen, die dem übergeordneten Unternehmenskonto zugeordnet sind. Wenn Sie einer Tabellenberechtigung einen Account-Scope zuweisen, ermittelt das Portal den übergeordneten Account, der mit dem Kontaktdatensatz des angemeldeten Benutzers verknüpft ist, und zeigt anschließend alle untergeordneten Datensätze dieser Organisation an. Diese Beziehung in Dataverse korrekt abzubilden, ist für den Erfolg im B2B-Umfeld entscheidend.

Webrollen definieren und die Falle „Authenticated Users“ vermeiden

Webrollen verbinden Ihre authentifizierten Benutzer mit Ihren Dataverse-Tabellenberechtigungen. Power Pages enthält standardmäßig eine Rolle namens „Authenticated Users“. Hier tappen viele Administratoren in eine gefährliche Sicherheitsfalle.

Standardmäßig wird jeder Benutzer, der sich erfolgreich am Portal anmeldet, automatisch der Rolle „Authenticated Users“ zugeordnet. Wenn Sie dieser Standardrolle weitreichende Tabellenberechtigungen oder, noch schlimmer, Berechtigungen mit globalem Scope zuweisen, erbt jede Person, die sich auf Ihrer Website registriert, diese weitreichenden Rechte sofort. Das ist ein gravierendes Sicherheits-Antipattern.

Erstellen Sie stattdessen eigene, granulare Webrollen, die auf Ihre konkreten Benutzertypen zugeschnitten sind. Zum Beispiel:

• CustomerUser: Ist einem Contact-Scope für operative Tabellen wie Fälle und Bestellungen zugeordnet, sodass Benutzer ihre eigenen Interaktionen nachverfolgen können.
• AccountManager: Ist einem Account-Scope zugeordnet, wodurch ausgewählte Führungskräfte einer Organisation Einblick in unternehmensweite Ressourcen erhalten.
• KnowledgeBaseViewer: Ist global zugeordnet, aber strikt auf reine Leseaktionen für öffentlich zugängliche Support-Artikel beschränkt.

Entfernen Sie unnötige Standardzugriffe konsequent und stellen Sie sicher, dass Benutzern ausdrücklich zweckgebundene Rollen zugewiesen werden, die sich an ihrer organisatorischen Beziehung orientieren.

Feldbasierte Sichtbarkeit absichern und personenbezogene Daten schützen

Die Steuerung des Zeilenzugriffs über Tabellen-Scopes ist nur die halbe Miete. Sie müssen außerdem genau prüfen, welche Daten innerhalb einzelner Zeilen und Listen sichtbar sind. Die Offenlegung personenbezogener Daten (PII) wie Telefonnummern, Privatadressen, Finanzdaten oder interne Mitarbeiternotizen kann zu schweren Compliance-Verstößen führen, etwa gegen die DSGVO oder den CCPA.

Wenn Sie in Power Pages Listen und einfache Formulare erstellen, bereinigen Sie Ihre Ansichten unbedingt von sensiblen Spalten. Nur weil ein Feld im Frontend-Formular ausgeblendet ist, heißt das nicht, dass es sich nicht über die zugrunde liegenden Web-APIs einsehen oder abrufen lässt, wenn die Berechtigungen zu weit gefasst sind. Verwenden Sie gesonderte, gehärtete Ansichten, etwa eine eigens dafür vorgesehene „PublicView“, die ausschließlich sichere, bereinigte Spalten enthält. Wenn bestimmte Spalten in der Tabelle verbleiben müssen, sollten Sie Spaltensicherheit in Dataverse implementieren, um den Zugriff auf Datenbankebene vollständig zu beschränken.

Penetrationstests für Ihre Portalberechtigungen durchführen

Gehen Sie nie einfach davon aus, dass Ihr Sicherheitsmodell funktioniert. Sie müssen es nachweisen. Bevor Sie eine Portallösung in eine Test- oder Produktionsumgebung übernehmen, sollten Sie Ihre Tabellenberechtigungen und Ihre Routing-Logik gründlichen Penetrationstests unterziehen.

Richten Sie Testbenutzerkonten für jede definierte Webrolle ein. Melden Sie sich als gewöhnlicher CustomerUser an und versuchen Sie, Daten eines anderen Kontakts oder Accounts aufzurufen. Testen Sie Manipulationen der URL und von GUIDs, indem Sie in der Adressleiste des Browsers Datensatz-IDs austauschen, um zu prüfen, ob der Server unautorisierte Anfragen korrekt blockiert. Prüfen Sie außerdem die Diagnose- und Auditprotokolle Ihres Portals, um sicherzustellen, dass versuchte Rechteausweitungen mit einer 403-Forbidden-Antwort beantwortet werden.

Fazit und Best Practices

Ein Power Pages-Portal abzusichern erfordert durchdachte Planung, die konsequente Einhaltung des Least-Privilege-Prinzips und ein fundiertes Verständnis von Dataverse-Tabellenberechtigungen und Scopes. Wenn Sie sich von gefährlichen Standardeinstellungen wie der Rolle „Authenticated Users“ lösen, den Tabellenzugriff gezielt auf Contact- oder Account-Ebene begrenzen und die feldbasierte Sichtbarkeit absichern, können Sie ein Kundenportal aufbauen, das sowohl leistungsstark als auch besonders sicher ist.

Um dieses Thema noch tiefer zu erkunden und eine vollständige End-to-End-Anleitung zu erhalten, die von der Einrichtung externer Identitäten über den Entwurf Ihrer Lösungsarchitektur bis zur Vorbereitung auf den Go-live reicht, hören Sie sich unbedingt unsere begleitende Podcast-Episode an: Build Customer Portals with Power Pages and Dataverse. Vielen Dank fürs Lesen, und bleiben Sie dran für weitere Expertentipps zur Beherrschung der Microsoft Power Platform!