Etablierung einer Umgebungsstrategie

  • Artikel

Power Platform Umgebungen sind Container, die von Administratoren zur Verwaltung von Apps, Flows, Verbindungen und anderen Ressourcen zusammen mit Berechtigungen verwendet werden können, um Mitgliedern der Organisation die Nutzung der Ressourcen zu ermöglichen. Dieser Artikel führt Sie durch wichtige Details über Umgebungen in Microsoft Power Platform und erörtert empfohlene Wege, wie Sie von einer proaktiven Verwaltung dieser Umgebungen profitieren können. Weitere Informationen: Überblick über Microsoft Power Platform Umgebungen

Die Entwicklung einer Umgebungsstrategie bedeutet, Umgebungen und andere Ebenen der Datensicherheit so zu konfigurieren, dass die produktive Entwicklung in Ihrer Organisation unterstützt und gleichzeitig Ressourcen gesichert und organisiert werden. Eine Strategie zur Verwaltung der Bereitstellung und des Zugriffs auf Umgebungen und zur Kontrolle der darin enthaltenen Ressourcen ist wichtig:

  • Daten und Zugriff sichern
  • Verstehen, wie die Standardumgebung richtig verwendet wird
  • Die richtige Anzahl von Umgebungen verwalten, um Ausbreitung zu vermeiden und Kapazität zu sparen
  • Application Lifecycle Management (ALM) vereinfachen
  • Ressourcen in logischen Partitionen organisieren
  • Unterstützung von Operationen (und Helpdesk) bei der Identifizierung von Apps, die sich in Produktion befinden, indem diese in speziellen Umgebungen bereitgestellt werden.
  • Stellen Sie sicher, dass die Daten in akzeptablen geografischen Regionen gespeichert und übertragen werden (aus Gründen der Leistung und Einhaltung von Vorschriften).
  • Gewährleistung der Isolierung von Anwendungen, die entwickelt werden.

Umgebungen verstehen

Bevor wir anfangen, wollen wir uns einige wichtige Fakten zu Umgebung und Sicherheit ansehen:

  • Umgebungen sind an einen geografischen Standort gebunden, der zum Zeitpunkt der Erstellung der Umgebung konfiguriert wird.
  • Umgebungen können verwendet werden, um verschiedene Zielgruppen anzusprechen oder für verschiedene Zwecke wie Entwicklung, Test und Produktion.
  • Richtlinien zur Verhinderung von Datenverlust (DLP) können auf einzelne Umgebungen oder den Mandant angewendet werden.
  • Jeder Mandant hat eine Standardumgebung.
  • Nicht-Standard-Umgebungen können von lizenzierten Power Apps-, Power Automate- und Dynamics 365-Benutzern erstellt werden. Die Erstellung kann über eine Mandant Einstellung auf globale und Service-Admins beschränkt werden.
  • Nicht standardmäßige Umgebungen bieten mehr Kontrolle bei Berechtigungen.
  • Eine Umgebung kann eine oder keine Microsoft Dataverse Instanzen haben.
  • Zu den Umgebungen gehören vordefinierte Sicherheitsrollen, die allgemeine Benutzeraufgaben widerspiegeln, wobei die Zugriffsebenen so definiert sind, dass sie dem Ziel bewährter Verfahren entsprechen, den Zugriff auf die minimale Menge an Geschäftsdaten zu ermöglichen, die für die Nutzung der Apps erforderlich ist.
  • Das Standardumgebungs-Routing ist ein Premium-Governance-Feature. Dieses Feature, das es Power Platform-Administrierenden ermöglicht, ihre neuen Entwickelnden automatisch in ihre eigenen, persönlichen Entwicklerumgebungen zu leiten, wenn sie make.powerapps.com das erste Mal besuchen.

Umgebungsarten

Bevor Sie mit der Entwicklung einer Umgebungsstrategie beginnen, stellen Sie sicher, dass Sie die verschiedenen Arten von Umgebungen verstehen.

Entwickeln einer Strategie

Hier ist ein Ansatzpunkt, den Sie für Ihre Umgebungstrategie in Betracht ziehen sollten.

  • Weisen Sie Ihren Admins die Rolle Microsoft Power Platform Service Admin oder Dynamics 365 Service Admin zu.
    Diese Rollen bieten Administratorzugriff auf Power Apps-Canvas-Apps, Flows, Modellgesteuerte Apps, Umgebungen, benutzerdefinierte Connectors, Verbindungen, Gateways, Power Apps-Portale, AI Builder-Modelle und alle Dataverse-Instanzen. Diese Rolle sollte Administratoren zugewiesen werden, die keinen globalen Zugriff des Mandant-Administrators benötigen und sich der Verwaltung von Microsoft Power Platform widmen.

  • Beschränken der Erstellung neuer Produktionsumgebungen auf Admins
    Einschränken der Umgebungserstellung ist vorteilhaft, um die Kontrolle im Allgemeinen aufrechtzuerhalten: sowohl zur Vermeidung von nicht abgerechnetem Kapazitätsverbrauch als auch zur Reduzierung der Anzahl der zu verwaltenden Umgebungen. Wenn Benutzer Umgebungen von der zentralen IT-Abteilung anfordern müssen, ist es einfacher zu sehen, woran die Benutzer arbeiten, wenn Admins als Gatekeeper fungieren.

  • Behandeln Sie die Standardumgebung als eine Benutzer- und Teamproduktivitätsumgebung für Ihre Unternehmensgruppen.
    Es wird empfohlen, die Umgebung durch das Admin-Center umzubenennen, damit der Zweck dieser Umgebung selbsterklärend ist. Machen Sie deutlich, dass Default für Benutzer- und Teamproduktivitätsszenarien verwendet wird, nicht aber für geschäfts- oder unternehmenskritische Apps. Diese Umgebung kann nicht deaktiviert oder gelöscht werden, da sie die Integration mit Produkten wie SharePoint und Projekt ermöglicht. Wir empfehlen einen stufigen Ansatz für Umgebungen mit Benutzer- und Teamproduktivität.

  • Einrichten eines Prozesses zur Beantragung des Zugangs zu oder Erstellung von Umgebungen.
    Da die Erstellung von Umgebungen gesperrt und standardmäßig für Apps zur Integration von Erstanbietern reserviert ist, sollten Sie Ihrer Organisation klarmachen, dass ein geeignetes Entwicklungsprojekt durch die Anforderung einer neuen dedizierten Umgebung gestartet werden sollte, in der Entwickler und Admins eindeutig ihre Absichten und Unterstützung mitteilen. Der nächste Abschnitt enthält weitere Einzelheiten über die automatisierte Erstellung von Umgebungen, die nur eine Möglichkeit zur Implementierung eines einfachen formalen Antragsprozesses darstellt.

  • Dev/Test-/Produktionsumgebungen für bestimmte Geschäftsgruppen oder Anwendungen.
    Durch inszenierte Umgebungen wird sichergestellt, dass Änderungen während der Entwicklung die Benutzer in der Produktion nicht stören und Daten nicht beschädigt werden. Wenn die Ressourcen begrenzt sind, konzentrieren Sie dieses Muster für auftragskritische und wichtige Apps oder auf Geschäftseinheiten, die den größten Bedarf an eigenem Platz haben.

  • Einzelplatz-Umgebungen für den Nachweis von Konzepten und Schulungs-Workshops.
    Zur Veranstaltung von Workshops, Hackathons und internen Schulungsveranstaltungen wie App-in-a-Day oder Flow-in-a-Day erstellen Sie eine neue, separate Umgebung für das Ereignis, damit alle organisiert sind. Bitten Sie die Benutzer, die benötigten Ressourcen kurzfristig nach dem Ereignis zu sparen und die Umgebung zu säubern oder für andere Ereignisse zurückzusetzen. Verwenden Sie Testumgebungen, die keine Kapazität für diese Art von Aktivitäten verbrauchen.

  • Einrichtung von Richtlinien zur Verhinderung von Datenverlust (DLP) auf Mandanten- und Umgebungsebene
    Richtlinien zur Verhinderung von Datenverlust (Verhinderung von Datenverlust, DLP) dienen als Leitplanken, um zu verhindern, dass Benutzer unbeabsichtigt Organisationsdaten preisgeben, und um die Informationssicherheit im Mandant zu schützen. Ein wesentlicher Teil der Rolle des Power Platform-Admins wird darin bestehen, DLP-Richtlinien auf Mandanten- und Umgebungsebene einzurichten und aufrechtzuerhalten.

Abgestufter Ansatz für Umgebungen mit Team- und Benutzerproduktivität

Um Integrationen zu unterstützen, die Anzahl der benötigten Umgebungen zu reduzieren und das Onboarding zu beschleunigen, empfehlen wir, mehrere gemeinsam genutzte Umgebungen zu erstellen, die von Einzelpersonen und Teams genutzt werden können.

Standardumgebung

Jeder in Ihrem Mandant hat die Berechtigung, Apps und Flows hier zu erstellen. Es gibt derzeit keine Möglichkeit, die Zuweisung der Environment Maker-Rolle in dieser Umgebung zu blockieren. Dies ist auch die Umgebung, die für First-Party-Integrationen verwendet wird, wie das Erstellen einer App aus einer SharePoint-Liste. Erfahren Sie mehr: Die Standard-Umgebung

Um das Datenrisiko zu reduzieren, sollten die in Ihren Apps und Flows verwendeten Konnektorentypen auf eine weniger freizügige DLP-Richtlinie (Verhinderung von Datenverlust) beschränkt werden. Diese Richtlinie sollte allgemeine Anwendungsfälle der Produktivität von Einzelpersonen und kleinen Teams abdecken, wie z.B. die Arbeit mit SharePoint-Daten, das Senden von E-Mails und einen Genehmigungs-Workflow.

Umgebung für Power-User

Während die Standardumgebung viele Anwendungsfälle abdeckt, haben einige Poweruser weitergehende Anforderungen an ihre Apps und Flows, wie die Integration mit Microsoft Teams, Microsoft Entra ID oder Azure DevOps.

Zu diesem Zweck empfehlen wir, eine Umgebung für Power-User zu erstellen. Bei dieser freigegebenen Umgebung sollten eher erlaubendere DLP-Richtlinien verwenden und Administratoren sollten die Erstellerliste für diese Umgebung steuern.

Einige Überlegungen für die Umgebung von Power-Usern:

  • Prüfen Sie die verfügbaren Konnektoren in dieser Umgebung, um sicherzustellen, dass sie für Ihre Benutzer geeignet sind.
  • Dokumentieren Sie den Zweck und die verfügbaren Konnektoren in dieser Umgebung klar und deutlich, z.B. auf einer SharePoint-Site oder einem Wiki.
  • Erstellen Sie einen automatisierten Prozess, mit dem Maker Zugriff auf die Umgebung für Power-User beantragen können, z.B. mit Microsoft Forms, einer SharePoint-Site oder einer App. Falls erforderlich, könnte dieser Prozess die Genehmigung durch den Vorgesetzten oder die IT-Abteilung beinhalten.

Benutzerdefinierte Umgebungen

Während die gemeinsam genutzten Umgebungen viele Anwendungsfälle abdecken, könnten Teams und Projekte von einer benutzerdefinierten Umgebung zur Unterstützung ihrer geschäftsbereichsspezifischen Anwendungsfälle oder Anwendungs-Lebenszyklus-Management-Szenarien profitieren.

Einige Überlegungen für benutzerdefinierte Umgebungen:

  • Arbeiten Sie mit den Projektteams oder Geschäftsbereichen zusammen, um festzustellen, ob sie dedizierte Entwicklungs-, Test- und Produktionsumgebungen benötigen oder ob eine dedizierte Entwicklungsumgebung und gemeinsam genutzte Test- und Produktionsumgebungen für ihren Anwendungsfall besser geeignet sind.
  • Berücksichtigen Sie dedizierte Umgebungen für kritische Projekte und Arbeitslasten. Entwickler haben Environment Maker-Zugriff in der Entwicklungsumgebung, aber nur Benutzerzugriff in den Test- und Produktionsumgebungen. Endbenutzer haben nur Zugriff auf die Produktionslösung, so dass niemand die Produktionsanwendungen ändern kann.
  • Ziehen Sie Freigabe Test- und Produktionsumgebungen für wichtige, aber mittelkomplexe Apps in Betracht. Einzelne Projekte und Geschäftseinheiten haben ihre eigene Entwicklungsumgebung zum Schutz von Daten, aber die Lösungen werden in gemeinsamen Test- und Produktionsumgebungen bereitgestellt. Entwickler sind Endbenutzer in der Testumgebung, und Endbenutzer haben in der Produktionsumgebung nur grundlegenden Zugriff auf Lösungen und Daten.
  • Arbeiten Sie mit dem Geschäftsbereich zusammen, um festzulegen, welche Konnektoren erforderlich sind, und erstellen Sie eine Richtlinie für Ausnahmen.
  • Legen Sie gemeinsam mit dem Geschäftsbereich fest, wer in dieser Umgebung ein Maker und wer der Umgebungsadministrator sein wird.
  • Jede Umgebung verbraucht 1 GB an Datenkapazität, daher sollten benutzerdefinierte Umgebungen mit Bedacht verwaltet werden.

Zusätzlich zu den obigen Empfehlungen wird die Festlegung Ihrer Umgebungsstrategie auch Ihre DLP-Strategie formen und lenken.

  • Jeder ist ein Maker. Kommunizieren Sie mit allen, dass Standard nicht für die Entwicklung von kritischen Apps geeignet ist.
  • Nur ein Benutzer hat Zugriff. Entwickler Umgebungen sind für alle anderen Benutzer außer dem Benutzer, der den Community-Plan abonniert hat, vollständig gesperrt. Anwendungen können bei Bedarf aus der Umgebung entfernt werden.
  • Genehmigte Benutzer haben Zugriff. Gemeinsam genutzt Umgebungen für Benutzer- und Teamproduktivitätsszenarien mit einer Liste genehmigter Maker.
  • Dedizierte Umgebungen Umgebungen für kritische Projekte und Arbeitslasten. Entwickler haben in der Entwicklungsumgebung Zugriff auf die Maker-Umgebung, in der Test- und Produktionsumgebung jedoch nur Benutzerzugriff. Endbenutzer haben nur Zugriff auf die Produktionslösung, so dass niemand die Produktionsanwendungen ändern kann.
  • Gemeinsam genutzt Test- und Produktionsumgebungen für wichtige, aber mittelkomplexe Apps. Einzelne Projekte und Geschäftseinheiten haben ihre eigene Entwicklungsumgebung zum Schutz von Daten, aber die Lösungen werden in gemeinsamen Test- und Produktionsumgebungen bereitgestellt. Entwickler sind Endbenutzer in der Testumgebung, und Endbenutzer haben in der Produktionsumgebung nur grundlegenden Zugriff auf Lösungen und Daten.

Zusätzliche Empfehlungen zur Verwaltung von Umgebungen

Basierend auf erfolgreichen Erfahrungen mit Kundeneinsätzen finden Sie hier eine Liste mit zusätzlichen Empfehlungen, die die Verwaltung von Umgebungen erleichtern können.

  • Benutzen Sie ein Service-Konto, um Produktionslösungen bereitzustellen: Erstellen Sie ein Service-Konto, das die zentrale IT-Abteilung für die Bereitstellung von Test- und Produktionsumgebungen bereitstellt. Dies ist aus vielen Gründen vorteilhaft:

    • Ermöglicht allen IT-Mitgliedern die Verwaltung von Admin-Ressourcen (z.B. Test- und Produktionsumgebungen).
    • Nur das Dienstkonto verfügt über Admin-Berechtigungen in der Umgebung.
    • Alle anderen Benutzer haben Endbenutzer-Berechtigungen und können keine neuen Ressourcen erstellen - dies ist wichtig, denn wenn Benutzer Zugriff auf eine Datenverbindung erhalten, können sie neue Schnittstelle zur Interaktion mit den Daten erstellen, die nicht vom Entwickler beabsichtigt war.
    • Die IT-Abteilung kennt produktionsreife Anwendungen, die sich in der Bereitstellung befinden, da sie an der Implementierung beteiligt sind.
    • Service-Konten benötigen die Berechtigung Microsoft Power Platform oder Dynamics 365 Service-Admin in PIM. Weisen Sie je nach Bedarf zusätzliche Lizenzen zu, je nachdem, welche Konnektoren im Antragsprozess verwendet werden müssen (wenn z.B. Dataverse und Outlook verwendet werden, weisen Sie Premium Power Apps und Office Enterprise zu).
    • Wenn die Details für eine Anwendung angezeigt werden, wird das Dienstkonto als Ersteller und nicht als Maker angezeigt. Dadurch wissen Endbenutzer besser, an wen sie sich bei Anwendungsproblemen wenden können.

    Überlegen Sie, ob die Risiken eines Dienstkontos für Sie wichtig sind. Einige Organisationen sind mit einem Dienstkonto nicht zufrieden, weil z.B. eine gemeinsam genutzte Ressource mit Admin-Berechtigungen nicht bis zu einer einzelnen Person zurückverfolgt werden kann. Dies ist gültig, kann aber durch Schritte wie die Durchsetzung von standortbasiertem bedingten Zugriff, die Rückverfolgung der Audit-Protokolle zu einer IP oder umfangreichere Methoden wie die Aufrechterhaltung einer Arbeitsstation mit sicherem Zugriff, die während der Nutzung eine Benutzeridentifizierung erfordert, und die Einschränkung des Zugriffs auf das Servicekonto für dieses Gerät abgeschwächt werden.

  • Reduzieren der Anzahl der gemeinsam genutzten Entwicklungsumgebungen

    Sie verfügen über separate Umgebungen für die separate Projektentwicklung, insbesondere beim Umgang mit sicheren Daten. Umgebungen sind Container für Ressourcen wie z.B. Datenverbindungen, und in Entwicklungsumgebungen können mehrere Personen mit Zugriff auf Environment-Maker arbeiten. Wenn Maker Zugriff auf eine gemeinsame Datenverbindung haben und Apps und Flows erstellen können, besteht die Gefahr, dass jemand eine neue Schnittstelle zum Lesen, Aktualisieren und Löschen von Daten erstellt, auf die er möglicherweise Zugriff erhalten hat. Dies ist besonders wichtig für die Standardumgebung - Sie sollten immer über wichtige Datenverbindungen, benutzerdefinierte Konnektoren und andere Vermögenswerte verfügen, die zu ihrem Schutz in isolierten Umgebungen gesichert werden müssen.

  • Ressourcen mit Microsoft Entra Sicherheitsgruppen teilen

    Sicherheitsgruppen können verwendet werden, um den Zugriff auf Power Apps, Flows, Dataverse Sicherheitsrollen und andere Office 365 Dienste wie SharePoint Online zu verwalten. Dadurch entfällt der Aufwand für den Admin, den Zugriff auf einzelne Endbenutzer für jede Komponente zu aktualisieren (insbesondere, wenn mehrere beteiligt sind) - die Besitzer von Apps können dies auf der Ebene der Sicherheitsgruppe ohne IT ändern (es sei denn, die IT schränkt den Zugriff auf die Verwaltung der Sicherheitsgruppe ein).

  • Automatische Erstellung von Umgebungen

    Die Admin-Konnektoren (Microsoft Power Platform for Admins) ermöglichen es, einen Genehmigungs-Flow zu erstellen, in dem Benutzer Umgebungen anfordern, wenn die IT die Erstellung der Umgebung auf Admins beschränkt hat. Die zentrale IT-Abteilung kann einen Antrag prüfen und die Schaffung der Umgebung genehmigen oder ablehnen, ohne dafür verantwortlich zu sein, manuell zum Admin-Center zu gehen und die Umgebung für den Benutzer zu erstellen, sondern nur die Antragsdetails, die geschäftliche Rechtfertigung, die DLP-Anforderungen und die Frage, ob genügend Kapazität verfügbar ist, überprüfen.

  • Vorübergehende Entwicklungsumgebungen erstellen

    Wie bereits erwähnt, wird empfohlen, Entwicklungsumgebungen so weit wie möglich zu trennen und insbesondere die gleichzeitige Entwicklung von Apps für kritische Lösungen in der Standardumgebung zu vermeiden. Wenn Umgebungen zu Entwicklungszwecken erstellt werden, setzen Sie eine Frist, wie lange die Umgebung den Entwicklern zur Verfügung stehen soll, und verfügen Sie über einen Prozess, um sie zu sichern und zu entfernen.

  • Weniger ist besser

    Obwohl es wichtig ist, sicherzustellen, dass die Ressourcen zwischen Projekten und Geschäftsbereichen, die Umgebungen verwenden, angemessen aufgeteilt werden, ist es dennoch wichtig, ein gutes Gleichgewicht zwischen Sicherheit und Machbarkeit zu finden. Die Verwaltung gemeinsam genutzter Test- und Produktionsumgebungen ist eine gute Möglichkeit, eine größere Anzahl von wichtigen Lösungen zu ermöglichen und gleichzeitig die Kapazität zu erhalten und bewährte Verfahren zu befolgen. Dadurch bleiben eingeschränkte Berechtigungen erhalten, da für Test und Produktion eingeschränkte Umgebungsberechtigungen gelten und daher die Endbenutzer die Anwendungen nicht ändern können.

  • Bereitstellung von Umgebungen mit Dataverse Instanzen in der entsprechenden Region

    In Unternehmen, in denen Mitarbeiter in mehreren Ländern/Regionen arbeiten, kann es einige Überlegungen zur Einhaltung der Vorschriften geben, wenn Daten gespeichert und zwischen Ländern/Regionen versandt werden. Wenn die Umgebung eine Dataverse-Instanz hat, werden die Daten physisch in der Region gespeichert. Prüfen Sie die Liste der unterstützten Umgebungen.

Faktoren, die die Bereitstellung beeinflussen

Einige Faktoren beeinflussen, wann welche Arten von Umgebungen bereitgestellt werden sollten:

  • Definierte Ebenen der Anwendungsunterstützung

    Der Grad der Komplexität, die Wichtigkeit der App und die von der Anwendung betroffenen Benutzer (z.B. monatlich aktive Benutzer/Gesamtbenutzer in einer Organisation) sind wichtige Maßstäbe für die Bereitstellung von Umgebungen zur Unterstützung aller Szenarien.

    Verschiedene Arten von Anwendungen sollten in verschiedenen Umgebungen getrennt werden, je nachdem, wie kritisch jede einzelne ist.

       
    Kritische Apps Missionskritische Szenarien und/oder hochkomplexe und/oder org-weite Nutzung. Support im Besitz der IT-Abteilung. Robuster ALM-Prozess (dev/test/prod). Längerer Entwicklungszyklus, oft mehr als 3 Monate bis zum minimal realisierbaren Produkt.
    Wichtige Apps Wichtig, aber nicht kritisch und/oder von mittlerer Komplexität und/oder auf Geschäftseinheiten zugeschnitten. Support im Besitz des Besitzers oder der Geschäftseinheit von Apps, gesegnet durch die IT-Abteilung. ALM-anwendende Umgebungen werden empfohlen, sind aber möglicherweise nicht notwendig. Die Entwicklung dauert in der Regel weniger als drei Monate bis zum minimal realisierbaren Produkt.
    Produktivitäts-Apps Produktivitäts-App, die kein hohes Maß an Governance erfordert. Unterstützung durch App-Entwickler. In der Regel ist eine Verwaltung des Anwendungs-Lebenszyklus nicht erforderlich. Weniger als zwei Wochen bis zum minimal realisierbaren Produkt.

  • Kapazität

    Jede Umgebung (außer Test- und Entwicklerumgebungen) verbraucht 1 GB für die anfängliche Bereitstellung. Dies kann eine Einschränkung für Bereitstellungsumgebungen darstellen, wenn Ihre Organisation nicht für Premium-Lizenzen der Stufe Power Apps oder Dynamics 365 bezahlt, und es sich außerdem um eine gemeinsam genutzte Kapazität handelt, die vom Mandant an diejenigen vergeben werden muss, die sie benötigen.

    Kapazität einsparen durch:

    • Verwaltung gemeinsam genutzter Test- und Produktionsumgebungen. Im Gegensatz zu gemeinsam genutzten Entwicklungsumgebungen sollten Berechtigungen in Test- und Produktionsumgebungen auf den Zugriff von Endbenutzern zu Testzwecken beschränkt sein.
    • Automatisieren Sie die Bereinigung von temporären Entwicklungsumgebungen und fördern Sie die Verwendung von Testumgebungen für Tests oder Proof-of-Concept-Arbeiten.

  • Beteiligung von Admins

    Es ist nicht immer möglich, die zentrale IT an jedem Entwicklungsprojekt im gesamten Mandant zu beteiligen, insbesondere wenn das IT-Team kleiner ist oder ein größeres Unternehmen zu verwalten ist.

    Reduzieren Sie den Aufwand für den Admin durch:

    • Automatisierte Erstellung von Umgebungen, so dass der Mandant-Admin nur noch die Anfrage genehmigen muss.
    • Automatisieren der Bereinigung von Entwicklungsumgebungen mit temporären Umgebungen.

Kommunizieren der Umgebungsstrategie Ihrer Organisation den Makers

Richten Sie eine SharePoint-Site oder ein Wiki ein, das klar kommuniziert:

  • Der Zweck Ihrer Standardumgebung.
  • Der Zweck gemeinsam genutzter Team- und Benutzerproduktivitätsumgebungen ist, dass zusätzlich zu anderen gemeinsam genutzten Umgebungen auch Maker Zugang haben (z.B. Schulungsumgebungen) und wie der Zugriff auf diese Umgebungen beantragt werden kann.
  • Der Zweck von Testumgebungen und wie man sie beantragt.
  • Der Zweck von Entwicklerumgebungen und wie man sie erstellt
  • Der Prozess der Anforderung von benutzerdefinierten Umgebungen für bestimmte Geschäftseinheiten oder Projektzwecke.
  • Die Verantwortlichkeiten eines Erstellers
    • Halten Sie den Mandant sauber. Löschen Sie Ihre Umgebungen, Apps und Flows, wenn sie nicht mehr benötigt werden. Verwenden Sie beim Experimentieren Testumgebungen.
    • Weiser Austausch. Achten Sie auf die gemeinsame Nutzung Ihrer Umgebungen, Apps, Flows und gemeinsam genutzten Verbindungen.
    • Schutz von Organisationsdaten. Vermeiden Sie das Verschieben von Daten aus streng vertraulichen oder vertraulichen Datenquellen in nicht geschützte oder externe Speicher.

Kommunizieren Sie die Richtlinien Ihrer Organisation DLP-Richtlinien auch klar an die Maker.