Connector-Endpunktfilterung (Vorschauversion)

[Dieser Artikel ist Teil der Dokumentation zur Vorabversion und kann geändert werden.]

Mit der Connector-Endpunktfilterung können Administratoren steuern, mit welchen spezifischen Endpunkten sich Entwickler beim Erstellen von Apps, Flows oder Chatbots verbinden können. Sie ist in einer Datenrichtlinie konfiguriert und steht ausschließlich für die folgenden Connectors zur Verfügung:

• HTTP
• HTTP mit Microsoft Entra ID (AD)
• HTTP-Webhook
• SQL Server (einschließlich der Verwendung des SQL Server-Connectors für den Zugriff auf Azure Synapse Data Warehouse)
• Azure Blob Storage
• SMTP
• Browserautomatisierung
• Benutzeroberflächenautomatisierung

Wenn ein Hersteller seine App, den Fluss oder den Chatbot mit einem blockierten Endpunkt verbindet, wird eine Fehlermeldung der Datenrichtlinie angezeigt.

Hinzufügen von Endpunktfilterregeln zu Ihren Datenrichtlinien

Die Spalte konfigurierbarer Endpunkt im Bereich "Vorgefertigte Konnektoren" in "Datenrichtlinien" gibt an, ob die Endpunktfilterfunktion für den Konnektor unterstützt wird.

Wenn der Wert der konfigurierbaren Endpunkt Spalte Yes ist, können Sie diese Funktion verwenden, indem Sie mit der rechten Maustaste klicken und dann Konnektor konfigurieren>Konnektor-Endpunkte auswählen.

Dadurch wird ein seitliches Panel geöffnet, in dem Sie eine geordnete Liste von URL-Mustern zum Zulassen oder Ablehnen angeben. Die letzte Zeile in der Liste ist eine Regel für das Wildcardzeichen (*), die für alle Endpunkte in diesem Connector gilt. Standardmäßig ist das * Muster als "Zulassen" für neue Datenrichtlinien eingerichtet, Sie können es jedoch als "Zulassen" oder "Verweigern" markieren.

Neue Regeln hinzufügen

Sie können neue Regeln hinzufügen, indem Sie Endpunkt hinzufügen auswählen. Neue Regeln werden am Ende der Musterliste als vorletzte Regel hinzugefügt. Dies liegt daran, dass * der letzte Eintrag in der Liste ist. Sie können die Reihenfolge der Muster jedoch aktualisieren, indem Sie die Dropdownliste Reihenfolge verwenden oder die Optionen Nach oben oder Nach unten auswählen.

Nachdem Sie ein Muster hinzugefügt haben, können Sie es bearbeiten oder löschen, indem Sie eine bestimmte Zeile und dann "Löschen" auswählen.

Nachdem Sie die Filterregeln für den Connectorendpunkt und die Datenrichtlinie gespeichert haben, in der sie definiert sind, werden sie sofort für die zielbezogenen Umgebungen erzwungen. Die folgende Abbildung zeigt ein Beispiel, in dem ein Hersteller versucht, seinen Cloudfluss mit einem HTTP-Endpunkt zu verbinden, der nicht zulässig ist.

Bekannte Einschränkungen

• Die Endpunktfilterungsregeln werden nicht für Umgebungsvariablen, benutzerdefinierte Eingaben und dynamisch gebundene Endpunkte während der Laufzeit durchgesetzt. Nur statische Endpunkte, die beim Erstellen einer App, eines Flusses oder eines Chatbots während der Entwurfszeit bekannt und ausgewählt sind, werden erzwungen. Dies bedeutet, dass Filterregeln für Connectorendpunkte für SQL Server und Azure Blob Storage nicht erzwungen werden, wenn die Verbindungen mit Microsoft Entra ID authentifiziert werden. In den folgenden beiden Screenshots erstellt ein Hersteller einen Cloudfluss, der sql Server und die Datenbank innerhalb von Variablen definiert, und verwendet diese Variablen dann als Eingabe für die Verbindungsdefinition. Daher werden die Endpunktfilterregeln nicht ausgewertet, und der Cloudfluss wird erfolgreich ausgeführt.

  

  

• Power Apps, die vor dem 1. Oktober 2020 veröffentlicht wurden, müssen für Konnektor-Aktionen und Endpunktregeln neu veröffentlicht werden, um Datenrichtlinien durchzusetzen. Mit dem folgenden Skript können Administratoren und Entscheidungsträger Apps identifizieren, die erneut veröffentlicht werden müssen, um diese neuen Regeln für die präzise Kontrolle der Datenrichtlinie einzuhalten:

  Add-PowerAppsAccount
  
  $GranularDLPDate = Get-Date -Date "2020-10-01 00:00:00Z"
  
  ForEach ($app in Get-AdminPowerApp){
  
      $versionAsDate = [datetime]::Parse($app.LastModifiedTime)
  
      $olderApp = $versionAsDate -lt $GranularDLPDate
  
      $wasBackfilled = $app.Internal.properties.executionRestrictions -ne $null -and $app.Internal.properties.executionRestrictions.dataLossPreventionEvaluationResult -ne $null -and ![string]::IsNullOrEmpty($app.Internal.properties.executionRestrictions.dataLossPreventionEvaluationResult.lastAdvancedBackfillDate) 
  
      If($($olderApp -and !$wasBackfilled)){
          Write-Host "App must be republished to comply with granular data policy: " $app.AppName " "  $app.Internal.properties.displayName " " $app.Internal.properties.owner.email
      } 
      Else{ 
          Write-Host "App is already Granular data policy compliant: " $app.AppName 
      }
  }
  

Endpunkt-Eingabeformate und Beispiele

Jeder Connector definiert einen Endpunkt anders, und einige Endpunkte können in mehreren Formaten vorliegen. Daher müssen Sie Endpunkte in allen möglichen Formaten eingeben, um Entwickler daran zu hindern, sie beim Erstellen von Apps und Flows zu verwenden. Administratoren können den vollständigen Endpunktnamen eingeben oder musterabgleich mit dem Wildcardzeichen (*) verwenden, um eine Endpunktfilterregel zu erstellen. Diese Regeln werden in eine sortierte Liste von Endpunktmustern eingegeben und dargestellt, was bedeutet, dass sie in aufsteigender Reihenfolge nach Zahl ausgewertet werden. Die letzte Regel für einen bestimmten Konnektor lautet immer * Zulassen oder * Ablehnen. „Zulassen“ ist die Standardeinstellung, die in „Ablehnen“ geändert werden kann.

Die folgende Anleitung beschreibt, wie Sie Connector-Endpunkte eingeben, während Sie Regeln erstellen, um sie zuzulassen oder abzulehnen.

SQL Server

Sql Server-Verbindungsendpunkte im <Server_name, database_name> Format auflisten. Einige Dinge, die Sie beachten sollten:

• Hersteller können den Servernamen in verschiedenen Formaten eingeben. Um einen Endpunkt zu adressieren, geben Sie ihn in allen möglichen Formaten ein. Lokale Instanzen können beispielsweise im Format <machine_name\named_instance, database_name> oder <IP address, custom port, database_name> vorliegen. In diesem Fall müssen Sie für einen Endpunkt in beiden Formaten Regeln für das Zulassen oder Blockieren anwenden. Zum Beispiel:

  • WS12875676\Servername1,MktingDB blockieren
  • 11.22.33.444,1401,MktingDB blockieren

• Keine spezielle Logik behandelt relative Adressen wie localhost. Wenn Sie daher *localhost* blockieren, können Ersteller keine Endpunkte verwenden, indem sie localhost als Teil des SQL Server-Endpunkts verwenden. Es wird sie jedoch nicht daran hindern, mithilfe der absoluten Adresse auf den Endpunkt zuzugreifen, es sei denn, die absolute Adresse wurde vom Administrator ebenfalls gesperrt.

Hier sind einige Beispiele:

• Nur Azure SQL Server-Instanzen zulassen:

  1. *.database.windows.net* zulassen
  2. * ablehnen

• Nur einen bestimmten IP-Bereich zulassen: (Die nicht zulässigen IP-Adressen können weiterhin vom Hersteller im <machine_name\named_instance> Format eingegeben werden.)

  1. 11.22.33* zulassen
  2. * ablehnen

Dataverse

Dataverse-Endpunkte werden durch die Organisations-ID dargestellt, z. B. 00aa00aa-bb11-cc22-dd33-44ee4ee4e4ee. Beachten Sie, dass sich derzeit nur der reguläre Dataverse-Konnektor im Geltungsbereich der Endpunktfilterung befindet. Dynamische Dataverse-Konnektoren und aktuelle Dataverse-Konnektoren befinden sich nicht im Geltungsbereich. Auch die lokale Instanz von Dataverse (auch als aktuelle Umgebung bezeichnet) kann niemals für die Verwendung in einer Umgebung blockiert werden. Dies bedeutet, dass Die Entscheidungsträger immer innerhalb einer bestimmten Umgebung auf die aktuelle Dataverse-Umgebung zugreifen können.

Daher gibt es eine Regel, die besagt:

1. 00aa00aa-bb11-cc22-dd33-44ee44ee44ee zulassen
2. * ablehnen

eigentlich Folgendes:

1. Dataverse current environment zulassen
2. 00aa00aa-bb11-cc22-dd33-44ee44ee44ee zulassen
3. * ablehnen

Das Zulassen von Dataverse current environment ist immer implizit die erste Regel in der Dataverse-Endpunktfilterliste für jede beliebige Umgebung.

Azure Blob Storage

Azure Blob Storage-Endpunkte verwenden den Namen des Azure-Speicherkontos.

SMTP

SMTP-Endpunkte werden im Format <SMTP server address, port number> dargestellt.

Hier ist ein Beispielszenario:

1. smtp.gmail.com,587 ablehnen
2. * zulassen

HTTP mit Microsoft Entra ID, HTTP-Webhook und HTTP-Connectors

HTTP-Connectorendpunkte verwenden ein URL-Muster. Die Aktion Webressource abrufen des HTTP mit Microsoft Entra-Connectors liegt außerhalb des Geltungsbereichs.

Ein Beispiel für ein Szenario:

Erlauben Sie nur den Zugriff auf die Azure-Abonnementseite innerhalb von https://management.azure.com/.

1. https://management.azure.com/subscriptions* zulassen
2. https://management.azure.com/* ablehnen
3. * ablehnen

Browserautomatisierung

Mit diesem Feature können Sie die Webseiten steuern, auf die ein Desktopfluss in Power Automate für Desktop zugreift. Die Endpunkte werden entweder im URL-Format oder im Webseitennamenformat dargestellt, und Sie können Platzhalter für den Abgleich dynamischer URLs oder Seitennamen verwenden. Die Überprüfung erfolgt während der Aktionen "Webbrowser starten" oder "Zur Webseite wechseln", bevor ein Desktopablauf mit Browserinteraktionen fortfährt.

Hier ist ein Beispielszenario:

Erlauben Sie den Zugriff auf alle Webseiten mit Ausnahme der URL https://www.microsoft.com/ und aller URLs oder Webseiten, die die Zeichenfolge powerplatform enthalten.

1. https://www.microsoft.com/ ablehnen
2. *powerplatform* ablehnen
3. * zulassen

Benutzeroberflächenautomatisierung

Mit diesem Feature können Sie definieren, mit welchen Anwendungen und Bildschirmen ein Desktopablauf in Power Automate für Desktop interagieren kann. Endpunkte werden mithilfe des Prozessnamens der Anwendung angegeben. Wenn der Prozessname "ApplicationFrameHost", "Java" oder "Javaw" lautet und eine Universelle Windows-Plattform (UWP) oder Java-Anwendung angibt, in der mehrere Instanzen denselben Namen aufweisen können, verwendet Power Automate für Desktop sowohl den Prozessnamen als auch den Anzeigenamen des Fensters, um das Ziel genau zu identifizieren. Platzhalter werden zur flexiblen Anpassung unterstützt.

Die Überprüfung erfolgt für jede Aktion innerhalb der Benutzeroberflächenautomatisierungsgruppe. Es überprüft das Process-Attribut (angegeben durch die Zahl 1 im Bild) oder das Name-Attribut (angegeben durch die Zahl 2 im Bild) im Selektor des Zielbildschirms (wie vom Pfeil in der Abbildung dargestellt). In der Regel wird das übergeordnete Element der zugehörigen UI-Elemente verwendet, um zu bestimmen, ob die Interaktion zulässig ist.

Endpunktfilterregeln gelten nicht für Variablen oder dynamisch gebundene Endpunkte. Wenn ein Ausdruck etwas anderes als eine Literalzeichenfolge enthält, wird die Filterung umgangen , was möglicherweise den Zugriff auf eingeschränkte Connectorargumente zulässt. Das Standardrichtlinienverhalten ist, dass alle Endpunktfilterrichtlinien eine Kernregel enthalten (Allow * oder Deny *), wobei standardmäßig Allow * (Allow All) gilt.

• Wenn "* zulassen" verwendet wird: Dynamische Werte werden nicht gefiltert. Jeder dynamische Ausdruck umgeht die Endpunktfilterung, auch wenn bestimmte Anwendungen eingeschränkt sind.
• Wenn Deny * verwendet wird: Alle dynamischen Werte werden standardmäßig blockiert, wodurch eine strengere Erzwingung sichergestellt wird.

Hier ist ein Beispielszenario. Um den Zugriff auf alle Anwendungen und Bildschirme zu ermöglichen, mit Ausnahme derJenigen, bei denen das Attribut "Process " oder "Name " entweder genau "Rechner " ist oder die Zeichenfolge "Java" enthält, würden Sie die folgenden Regeln konfigurieren:

1. Calculator ablehnen
2. *Java* ablehnen
3. * zulassen

PowerShell-Unterstützung für Endpunktfilterung

Endpunktfilterung für eine Richtlinie konfigurieren

Das Objekt, das Endpunktfilterregeln für eine Richtlinie enthält, wird als Connectorkonfigurationen bezeichnet.

Das Connector-Konfigurationsobjekt hat die folgende Struktur:

$ConnectorConfigurations = @{ 
  connectorActionConfigurations = @() # used for connector action rules
  endpointConfigurations = @( # array – one entry per 
    @{  
      connectorId # string
      endpointRules = @( # array – one entry per rule 
        @{ 
          order # number 
          endpoint # string
          behavior # supported values: Allow/Deny
        }
      ) 
    }
  ) 
}

Notizen

• Die letzte Regel für jeden Connector muss immer auf die URL * angewendet werden, um sicherzustellen, dass alle URLs von den Regeln abgedeckt werden.
• Die Reihenfolge-Eigenschaft der Regeln für jeden Verbinder muss die Zahlen 1 bis N verwenden, wobei N die Anzahl der Regeln für diesen Verbinder ist.

Vorhandene Connectorkonfigurationen für eine Datenrichtlinie abrufen

Get-PowerAppDlpPolicyConnectorConfigurations 

Erstellen von Connectorkonfigurationen für eine Datenrichtlinie

New-PowerAppDlpPolicyConnectorConfigurations

Aktualisieren von Konnektorkonfigurationen für eine Datenrichtlinie

Set-PowerAppDlpPolicyConnectorConfigurations

Beispiel

Ziel:

Für den SQL Server-Connector:

• Datenbank "testdatabase" des Servers "myservername.database.windows.net" ablehnen.
• Alle anderen Datenbanken des Servers "myservername.database.windows.net" zulassen
• Alle anderen Server ablehnen

Für den SMTP-Connector:

• Gmail zulassen (Serveradresse: smtp.gmail.com, Port: 587)
• Alle anderen Adressen ablehnen

Für den HTTP-Connector:

• Endpunkte https://mywebsite.com/allowedPath1 und https://mywebsite.com/allowedPath2 zulassen
• Alle anderen URLs ablehnen

$ConnectorConfigurations = @{ 
  endpointConfigurations = @(
    @{  
      connectorId = "/providers/Microsoft.PowerApps/apis/shared_sql" 
      endpointRules = @(
        @{ 
          order = 1 
          endpoint = "myservername.database.windows.net,testdatabase" 
          behavior = "Deny"
        }, 
        @{ 
          order = 2 
          endpoint = "myservername.database.windows.net,*" 
          behavior = "Allow"
        }, 
        @{ 
          order = 3
          endpoint = "*" 
          behavior = "Deny"
        } 
      ) 
    }, 
    @{  
      connectorId = "/providers/Microsoft.PowerApps/apis/shared_smtp" 
      endpointRules = @(
        @{ 
          order = 1 
          endpoint = "smtp.gmail.com,587" 
          behavior = "Allow"
        }, 
        @{ 
          order = 2 
          endpoint = "*" 
          behavior = "Deny"
        } 
      ) 
    },
    @{  
      connectorId = "http" 
      endpointRules = @(
        @{ 
          order = 1 
          endpoint = "https://mywebsite.com/allowedPath1" 
          behavior = "Allow"
        }, 
        @{ 
          order = 2
          endpoint = "https://mywebsite.com/allowedPath2" 
          behavior = "Allow"
        }, 
        @{ 
          order = 3
          endpoint = "*" 
          behavior = "Deny"
        } 
      ) 
    } 
  ) 
}
New-PowerAppDlpPolicyConnectorConfigurations -TenantId $TenantId -PolicyName $PolicyName -NewDlpPolicyConnectorConfigurations $ConnectorConfigurations