Die Power Platform und die IT-Compliance - Teil 1

Zugegeben, die Power Platform wird stetig weiterentwickelt und an einigen Stellen ist sie noch in der Findungsphase – positiv ausgedrückt. Trotzdem nutzen viele Unternehmen (Teil-)Bereiche dieses Ökosystems. Warum? Meine persönliche Antwort: Weil sie wirklich hilfreich ist und Spaß macht. Eine objektivere Antwort: Wegen bereits vorhandener Lizenzen im Rahmen von Office-E3/E5-Abonnements, einem starken Schwenk in das SaaS-Angebot von Microsoft durch z. B. Microsoft Teams und dem Willen der "Fachbereiche" eigene Lösungen zu schaffen.

Eins der Probleme aus meiner Sicht? An vielen Stellen besticht die Power Platform durch ihre Einfachheit und das Gefühl, dass man einfach mal loslegen kann. Doch dadurch rennt man zwangsläufig in Probleme mit dem Change Management, dem User Access Management, dem Monitoring und weiteren Aspekten. Eine Governance, die das regelt ist also Pflicht.

Disclaimer: Denglisch/Übersetzungs-Verwirrung

Eine kleine Warnung meinerseits: An vielen Stellen werde ich auf englische Wörter zurückgreifen. Dadurch entsteht ein manchmal schlechter zu lesendes Denglisch. Warum ich das mache? Aufgrund der Microsoft-Dokumentation und meiner Arbeitsweise. Die Dokumentation steht zwar auch auf Deutsch zur Verfügung, jedoch ist diese maschinell übersetzt.

Dadurch sind einige Sätze in der Dokumentation sinnentstellt. Einfache Lösung: Ich nutze nahezu ausschließlich die englische Dokumentation und die Power Platform auf Englisch. Dazu habe ich meinen Browser Microsoft Edge auf Englisch eingestellt.

Es ergibt sich dadurch auch ein weiterer Vorteil: Die weitere Literatur, wie Whitepaper, tolle Blog- oder Foreneinträge, ist meist nur auf Englisch vorhanden. Die Übersetzungsleistung entfällt ebenfalls, wenn man auf Englisch arbeitet.

Was ist die Power Platform?

Microsoft bündelt die "Power" Produkte und vereinheitlicht diese zu einem ganzheitlichen Produkt:

• Power BI – interaktive Berichte und Datenanalysen (Stichwort „Self-Service Business Intelligence”)

• Power Apps – kleine Apps im Browser „ohne Programmierung” entwickeln (Stichwort „Low-Code-Development” und „Citizen Developer”)

• Power Automate – Aufgaben durch Workflows (das Produkt hieß früher schlicht „Flow”) in der Cloud oder mit der Desktop-Variante in Windows automatisieren (Stichwort „Robotic Process Automation”)

• Power Virtual Agents – einfache Gespräche für Mitarbeiter:innen oder Kund:innen automatisieren (Stichwort „Chatbots”)

Anstoß für diesen Blog-Beitrag und die daraus entstehende Reihe war übrigens ein Blog-Beitrag und Whitepaper von Microsoft rund um das Thema „Enterprise Deployment for RPA and more in Power Automate”. Ich möchte aber nicht so spezifisch auf ein gesondertes Thema, wie „Power Automate” eingehen, sondern die ganzheitliche Umsetzung der IT-Compliance betrachten.

Welches „Soll” müssen wir anlegen?

Wie immer ist diese Frage individuell für das Unternehmen zu beantworten, abhängig von den gesetzlichen und regulatorischen Anforderungen sowie dem Risikoappetit. Ich mache es mir für diese Reihe allerdings einfach: Ich möchte die Power Platform aus Sicht der Anforderungen an Individuelle Datenverarbeitungen (IDV) für regulierte Unternehmen, wie Banken, Versicherungen oder Kapitelverwaltungsgesellschaften betrachten. Ausgangspunkt bildet für mich die aktuelle Fassung der Bankenaufsichtlichen Anforderungen an die IT (oder kurz BAIT). Für Robotic Process Automation habe ich das an dieser Stelle schon einmal gemacht. Jetzt soll es also um die ganze Power Platform gehen.

Aus den Anforderungen möchte ich folgende Themen ableiten und besprechen:

• Identifizierung der IDV in der Power Platform (inkl. Schutzbedarfsfeststellung)

• Methodik des Testens (inkl. Change Management)

• Rezertifizierungsprozess der Berechtigungen

Wie lassen sich Entwicklung, Test & Produktion trennen?

Damit dieser Beitrag nicht nur theoretisch bleibt, werde ich abschließend auf ein essenzielles Element eingehen: Die verschiedenen Environments bzw. in der deutschen Übersetzung „Umgebungen” der Power Platform. Diese sind, wie der Name schon sagt, voneinander getrennte, logische Umgebungen. Dies betrifft die darunterliegende Datenbank (früher namentlich Common Data Service, heute Dataverse), die Zugriffsrechte, Administrationseinstellungen aber auch den Ort der Datenablage.

Einsehbar sind die Environments eines Tenants hier. Natürlich sind dafür entsprechende Berechtigungen von Nöten, beispielsweise die Rolle „global reader”. Was es übrigens mit den Berechtigungen in Azure Active Directory (AAD) oder Azure Role-Base Access Control (Azure RBAC) auf sich hat, habe ich hier beschrieben.

Die Environments sind auch der Grundstein für ein professionelles Change Management, inkl. Trennung von Entwickler:innen, Tester:innen und späteren Anwender:innen. Mit zusätzlichen Kniffen, die ich in einem weiteren Beitrag ansprechen möchte, lassen sich Freigaben und auch weitere Anforderungen, wie eine Schutzbedarfsfeststellung realisieren.

Im obenstehenden Screenshot ist ein Teil der bestehenden Environments in unserem Tenant zu sehen. Neben den möglichst sprechenden Namen und der Region, in der ein Environment betrieben wird, ist ein Aspekt sehr relevant: Der Typ des Environments.

Was hat es mit den Environment-Types auf sich?

In unserem Tenant sind fünf der sechs verschiedenen Typen von Environments in Verwendung – einzig der potenziell zu vernachlässigende Typ „Trial” fehlt bei uns. Auf die genauen Unterschiede wollen wir im Verlauf der Reihe eingehen, das default”-Environment schauen wir uns bereits jetzt an.

Für jeden Tenant exisiert automatisch ein „default”-Environment in der Power Platform. Dieses steht allen Benutzer:innen automatisch zur Verfügung, wenn sie über eine entsprechende Power-Apps-/Power-Automate-Lizenz verfügen. Dieses „default”-Environment ist auch Grund für meine oben getätigte Aussage, dass es zu Problemen beim Change Management und User Access Management kommen kann, wenn man die Power Platform ohne entsprechende Governance nutzt.

Warum? Jede:r Benutzer:in mit der entsprechenden Lizenz kann innerhalb dieses Environments eigene Flows (so heißen die Workflows in Power Automate) oder Apps erstellen. So können Endanwender schnell und unkompliziert ihre Anforderungen umsetzen, fernab von Programmierrichtlinien, Methodik des Testens, Schutzbedarfsfeststellung und Rezertifizierung. Im Grunde haben wir damit das IDV-Problem von Excel/Access nur auf eine neuere Technologie verlagert, ohne Nutzung der Vorteile der Plattform.

Was also mit dem default-Environment anstellen?

Seitens Microsoft gibt es im Whitepaper „Administering a low-code development platform - Power Apps and Power Automate Enterprise Deployment” verschiedene Empfehlungen zum Umgang mit dem „default”-Environment. Die wichtigste aus meiner Sicht: „The Default environment should not be used to host production solutions.”

Eine vorgeschlagene Maßnahme: Die Umbennung in einen Namen, wie „Personal Productivity”. Aus meiner Sicht ein sinnvoller Schritt, allerdings nur ein Schritt von vielen.

Fazit & Ausblick

Und damit wären wir beim Cliffhanger dieses Beitrags bzw. dem Ausblick: Der nächste Teil wird sich mit dem Center of Excellence befassen, welches beim Umgang mit dem „default”-Environment und auch den anderen Environments unterstützen kann.

Was aber ist das Fazit dieser kurzen Einführung? Es gibt vieles rund um die Power Platform zu entdecken, was bei der Umsetzung der IT-Compliance hilft. Manches, wie die Environments, ist direkt in der Platform eingebaut.

Anderes, dazu mehr im nächsten Teil, ist nicht direkt eingebaut, aber wichtiger Baustein, um zum Beispiel die Anforderungen der BAIT zu erfüllen.