Schützen von Apps mit der App-Steuerung für bedingten Zugriff von Microsoft Defender for Cloud Apps

Hinweis

  • Wir haben Microsoft Cloud App Security umbenannt. Es wird jetzt als Microsoft Defender for Cloud Apps bezeichnet. In den kommenden Wochen werden wir die Screenshots und Anweisungen hier und auf verwandten Seiten aktualisieren. Weitere Informationen zur Änderung finden Sie in dieser Ankündigung. Weitere Informationen zur aktuellen Umbenennung von Microsoft-Sicherheitsdiensten finden Sie im Microsoft Ignite Security-Blog.

  • Microsoft Defender for Cloud Apps ist jetzt Teil Microsoft 365 Defender. Das Microsoft 365 Defender Portal ermöglicht Sicherheitsadministratoren, ihre Sicherheitsaufgaben an einem Ort auszuführen. Dadurch werden Workflows vereinfacht und die Funktionalität der anderen Microsoft 365 Defender Dienste hinzugefügt. Microsoft 365 Defender ist das Zuhause für die Überwachung und Verwaltung der Sicherheit in Ihren Microsoft-Identitäten, Daten, Geräten, Apps und Infrastruktur. Weitere Informationen zu diesen Änderungen finden Sie unter Microsoft Defender for Cloud Apps in Microsoft 365 Defender.

Am heutigen Arbeitsplatz ist es oft nicht genug, um zu wissen, was in Ihrer Cloudumgebung nach der Tatsache passiert. Sie sollten Sicherheitsverletzungen und Lecks in Echtzeit beheben, damit Ihre Daten und Ihre Organisation nicht durch Mitarbeiter (mit Absicht oder versehentlich) in Gefahr gebracht werden. Es ist wichtig, Benutzern in Ihrer Organisation die Möglichkeit zu ermöglichen, die Dienste und Tools in Cloud-Apps optimal zu nutzen und ihnen die Möglichkeit zu geben, ihre eigenen Geräte zur Arbeit zu bringen. Gleichzeitig benötigen Sie Tools zum Echtzeitschutz Ihrer Organisation vor Datenlecks und Datendiebstahl. Microsoft Defender for Cloud Apps in jeden Identitätsanbieter (IdP) integriert, um diese Funktionen mit Zugriffs- und Sitzungssteuerelementen bereitzustellen. Wenn Sie Azure Active Directory (Azure AD) als IdP verwenden, werden diese Steuerelemente für eine einfachere und maßgeschneiderte Bereitstellung optimiert, die auf dem Tool für bedingten Zugriff von Azure AD basiert.

Hinweis

  • Zusätzlich zu einer gültigen Defender for Cloud Apps-Lizenz, um Defender for Cloud Apps Conditional Access App Control zu verwenden, benötigen Sie auch eine Azure Active Directory P1-Lizenz oder die von Ihrer IdP-Lösung erforderliche Lizenz.

Funktionsweise

Die App-Steuerung für bedingten Zugriff verwendet eine Reverseproxyarchitektur und ist in Ihr IdP integriert. Wenn Sie den bedingten Zugriff in Azure AD integrieren, können Sie Apps so konfigurieren, dass sie mit der App-Steuerung für bedingten Zugriff mit nur wenigen Klicks arbeiten, sodass Sie Zugriffs- und Sitzungssteuerelemente auf Der Grundlage jeder Bedingung im bedingten Zugriff ganz einfach und selektiv erzwingen können. Die Bedingungen definieren , wer (Benutzer oder Gruppe von Benutzern) und welche (welche Cloud-Apps) und wo (welche Speicherorte und Netzwerke) eine Richtlinie für bedingten Zugriff angewendet wird. Nachdem Sie die Bedingungen festgelegt haben, können Sie Benutzer an Defender für Cloud-Apps weiterleiten, wo Sie Daten mit der App-Steuerung für bedingten Zugriff schützen können, indem Sie Zugriffs- und Sitzungssteuerelemente anwenden.

Mit der App-Steuerung für bedingten Zugriff können Benutzerzugriffe auf Apps und Sitzungen auf der Grundlage von Zugriffs- und Sitzungsrichtlinien in Echtzeit überwacht und gesteuert werden. Zugriffs- und Sitzungsrichtlinien werden im Cloud App Security-Portal verwendet, um Filter weiter zu verfeinern und Aktionen festzulegen, die für einen Benutzer ausgeführt werden sollen. Mithilfe von Zugriffs- und Sitzungsrichtlinien können Sie die folgenden Aktionen ausführen:

  • Verhindern Sie die Datenexfiltration: Sie können das Herunterladen, Ausschneiden, Kopieren und Drucken vertraulicher Dokumente auf nicht verwalteten Geräten blockieren.

  • Authentifizierungskontext erfordern: Sie können Azure AD-Richtlinien für bedingten Zugriff erneut bewerten, wenn eine vertrauliche Aktion in der Sitzung auftritt. Benötigen Sie beispielsweise die mehrstufige Authentifizierung zum Herunterladen einer streng vertraulichen Datei.

  • Schützen Sie den Download: Anstatt den Download vertraulicher Dokumente zu blockieren, können Sie Dokumente beim Integrieren mit Microsoft Purview Information Protection beschriftet und verschlüsselt sein. Diese Aktion stellt sicher, dass Dokumente in potenziell riskanten Sitzungen geschützt sind und der Benutzerzugriff eingeschränkt wird.

  • Verhindern Sie das Hochladen von nicht gekennzeichneten Dateien: Bevor eine vertrauliche Datei hochgeladen, verteilt und von anderen verwendet wird, ist es wichtig, sicherzustellen, dass die vertrauliche Datei die Bezeichnung hat, die durch die Richtlinie Ihrer Organisation definiert ist. Sie können sicherstellen, dass unbezeichnete Dateien mit vertraulichen Inhalten erst hochgeladen werden, wenn der Benutzer den Inhalt klassifiziert hat.

  • Blockieren sie potenzielle Schadsoftware: Sie können Ihre Umgebung vor Schadsoftware schützen, indem Sie den Upload potenziell schädlicher Dateien blockieren. Jede Datei, die hochgeladen oder heruntergeladen wird, kann anhand von Microsoft Threat Intelligence gescannt und sofort blockiert werden.

  • Überwachen von Benutzersitzungen für Compliance: Riskante Benutzer werden überwacht, wenn sie sich bei Apps anmelden und ihre Aktionen innerhalb der Sitzung protokolliert werden. Sie können das Benutzerverhalten untersuchen und analysieren, um zu verstehen, wo und unter welchen Bedingungen Sitzungsrichtlinien in Zukunft angewendet werden sollen.

  • Blockieren des Zugriffs: Sie können den Zugriff für bestimmte Apps und Benutzer je nach verschiedenen Risikofaktoren präzise blockieren. Sie können sie z. B. blockieren, wenn sie Clientzertifikate als eine Form der Geräteverwaltung verwenden.

  • Blockieren von benutzerdefinierten Aktivitäten: Einige Apps haben eindeutige Szenarien, die Risiken tragen, z. B. das Senden von Nachrichten mit vertraulichen Inhalten in Apps wie Microsoft Teams oder Slack. In diesen Szenarien können Sie Nachrichten auf vertrauliche Inhalte überprüfen und in Echtzeit blockieren.

Funktionsweise der Sitzungssteuerung

Durch Erstellen einer Sitzungsrichtlinie mit Conditional Access App Control können Sie Benutzersitzungen durch Weiterleiten des Benutzers über einen Reverseproxy statt direkt an die App steuern. Anschließend durchlaufen Benutzeranfragen und -antworten Defender für Cloud-Apps statt direkt an die App.

Wenn eine Sitzung durch Proxy geschützt ist, werden alle relevanten URLs und Cookies durch Defender for Cloud Apps ersetzt. Wenn die App z. B. eine Seite mit Links zurückgibt, deren Domänen enden myapp.com, wird die Domäne des Links mit etwa wie *.mcas.msfolgt suffixiert:

URL der App Ersetzte URL
myapp.com myapp.com.mcas.ms

Diese Methode erfordert keine Installation von Elementen auf dem Gerät, die es ideal machen, wenn Sitzungen von nicht verwalteten Geräten oder Partnerbenutzern überwacht oder gesteuert werden.

Hinweis

  • Unsere Technologie verwendet erstklassige patentierte Heuristiken, um Aktivitäten zu identifizieren und zu steuern, die vom Benutzer in der Ziel-App ausgeführt werden. Unsere Heuristiken sind so konzipiert, dass die Sicherheit mit der Benutzerfreundlichkeit optimiert und ausgeglichen wird. In einigen seltenen Szenarien, wenn Aktivitäten auf der Serverseite blockiert werden, rendert die App unbrauchbar, sichern wir diese Aktivitäten nur auf der clientseitigen Seite, wodurch sie potenziell anfällig für die Ausbeutung durch böswillige Insider sind.
  • Defender für Cloud Apps nutzt Azure Data Centers weltweit, um eine optimierte Leistung über geolocation bereitzustellen. Das bedeutet, dass die Sitzung eines Benutzers je nach Datenverkehrsmustern und Standort außerhalb einer bestimmten Region gehostet werden kann. Zum Schutz Ihrer Privatsphäre werden keine Sitzungsdaten in diesen Rechenzentren gespeichert.
  • Unsere Proxyserver speichern keine Ruhedaten. Beim Zwischenspeichern von Inhalten folgen wir den Anforderungen in RFC 7234 (HTTP-Zwischenspeicherung) und nur öffentliche Inhalte zwischenspeichern.

Identifizieren von verwalteten Geräten

App-Steuerung für bedingten Zugriff ermöglicht es Ihnen, Richtlinien zu erstellen, die berücksichtigen, ob ein Gerät verwaltet wird oder nicht. Um den Zustand eines Geräts zu identifizieren, können Sie Zugriffs- und Sitzungsrichtlinien konfigurieren, um Folgendes zu überprüfen:

  • Microsoft Intune Kompatible Geräte [nur für Azure AD verfügbar]
  • Azure AD Hybrid-beigetretene Geräte [nur verfügbar mit Azure AD]
  • Vorhandensein von Clientzertifikaten in einer vertrauenswürdigen Kette

Intune kompatiblen und hybriden Azure AD-verbundenen Geräten

Der bedingte Azure AD-Zugriff ermöglicht Intune kompatiblen und hybriden Azure AD-verbundenen Geräteinformationen, die direkt an Defender for Cloud Apps übergeben werden. Danach kann eine Zugriffs- oder Sitzungsrichtlinie entwickelt werden, die den Gerätezustand als Filter verwendet. Weitere Informationen finden Sie in der Einführung in die Geräteverwaltung in Azure Active Directory.

Hinweis

Einige Browser erfordern möglicherweise zusätzliche Konfigurationen, z. B. die Installation einer Erweiterung. Weitere Informationen finden Sie unter Unterstützung des Browsers für bedingten Zugriff.

Mit einem Clientzertifikat authentifizierte Geräte

Der Mechanismus zur Geräteidentifizierung kann die Authentifizierung von relevanten Geräten anfordern, die Clientzertifikate verwenden. Sie können entweder bereits vorhandene Clientzertifikate verwenden, die bereits für Ihre Organisation bereitgestellt wurden, oder neue Clientzertifikate für verwaltete Geräte bereitstellen. Stellen Sie sicher, dass das Clientzertifikat im Benutzerspeicher und nicht im Computerspeicher installiert ist. Sie können diese Zertifikate nutzen, um Zertifikat- und Sitzungsrichtlinien festzulegen.

SSL-Clientzertifikate werden über eine Vertrauenskette überprüft. Sie können eine X.509-Stamm- oder Zwischenzertifizierungsstelle hochladen, die im PEM-Zertifikatformat formatiert ist. Diese Zertifikate müssen den öffentlichen Schlüssel der Zertifizierungsstelle enthalten, der dann zum Signieren der Clientzertifikate verwendet wird, die während einer Sitzung angezeigt werden.

Sobald das Zertifikat hochgeladen wurde und eine relevante Richtlinie konfiguriert ist, fordert der Defender for Cloud Apps-Endpunkt den Browser an, die SSL-Clientzertifikate darzustellen, wenn eine entsprechende Sitzung die App-Steuerung für bedingten Zugriff durchläuft. Der Browser dient den SSL-Clientzertifikaten, die mit einem privaten Schlüssel installiert sind. Diese Kombination aus Zertifikat und privatem Schlüssel erfolgt mithilfe des PKCS #12-Dateiformats, in der Regel .p12 oder PFX.

Wenn eine Clientzertifikatüberprüfung ausgeführt wird, sucht Defender für Cloud Apps nach den folgenden Bedingungen:

  1. Das ausgewählte Clientzertifikat ist gültig und befindet sich unter der richtigen Stamm- oder Zwischenzertifizierungsstelle.
  2. Das Zertifikat wird nicht widerrufen (wenn die CRL aktiviert ist).

Hinweis

Die meisten hauptbrowser unterstützen die Durchführung einer Clientzertifikatüberprüfung. Mobile und Desktop-Apps nutzen jedoch häufig integrierte Browser, die diese Überprüfung nicht unterstützen und sich daher auf die Authentifizierung für diese Apps auswirken.

So konfigurieren Sie eine Richtlinie zum Nutzen der Geräteverwaltung über Clientzertifikate:

  1. Wählen Sie in Defender für Cloud-Apps in der Menüleiste das Symbol "Einstellungen"-Einstellungen aus. und wählen Sie "Einstellungen" aus.

  2. Wählen Sie die Registerkarte "Geräteidentifikation " aus.

  3. Laden Sie beliebig viele Stamm- oder Zwischenzertifikate hoch.

    Tipp

    Um zu testen, wie dies funktioniert, können Sie unser Beispiel-Stammzertifizierungsstelle- und Clientzertifikat wie folgt verwenden:

    1. Laden Sie das Beispielstammzertifikat und das Clientzertifikat herunter.
    2. Laden Sie die Stammzertifizierungsstelle in Defender für Cloud-Apps hoch.
    3. Installieren Sie das Clientzertifikat (password=Microsoft) auf den relevanten Geräten.

Nachdem die Zertifikate hochgeladen wurden, können Sie Zugriffs- und Sitzungsrichtlinien basierend auf Gerätetag und gültigem Clientzertifikat erstellen.

Unterstützte Apps und Clients

Sitzungs- und Zugriffssteuerelemente können auf alle interaktiven Einmaligen Anmeldungen angewendet werden, indem Sie das SAML 2.0-Authentifizierungsprotokoll verwenden oder wenn Sie Azure AD verwenden, auch das Open ID Connect-Authentifizierungsprotokoll. Wenn Ihre Apps mit Azure AD konfiguriert sind, können Sie diese Steuerelemente auch auf Apps anwenden, die lokal mit dem Azure AD-App-Proxy konfiguriert sind. Darüber hinaus können Zugriffssteuerelemente auf native Mobile- und Desktopclient-Apps angewendet werden.

Defender für Cloud Apps identifiziert Apps mithilfe von Informationen, die im Cloud App-Katalog verfügbar sind. Einige Organisationen und Benutzer passen Apps an, indem Sie Plugins hinzufügen. Damit die Sitzungssteuerelemente jedoch ordnungsgemäß mit diesen Plugins funktionieren, müssen die zugeordneten benutzerdefinierten Domänen der jeweiligen App im Katalog hinzugefügt werden.

Hinweis

Für die Authenticator-App wird neben anderen Anmeldeflüssen für die native Client-App auch ein nicht interaktiver Anmeldefluss verwendet, und sie kann nicht mit Zugriffssteuerungen genutzt werden.

Zugriffssteuerung

Viele Organisationen, die Sitzungssteuerelemente für Cloud-Apps verwenden, um In-Sitzungsaktivitäten zu steuern, wenden Auch Zugriffssteuerelemente an, um dieselbe Gruppe von nativen mobilen und Desktopclient-Apps zu blockieren, wodurch umfassende Sicherheit für die Apps bereitgestellt wird.

Sie können den Zugriff auf native Mobile- und Desktopclient-Apps mit Zugriffsrichtlinien blockieren, indem Sie den Client-App-Filter auf Mobile und Desktop festlegen. Einige native Client-Apps können einzeln erkannt werden, während andere, die Teil einer Suite von Apps sind, nur als ihre App auf oberster Ebene identifiziert werden können. Beispielsweise können Apps wie SharePoint Online nur erkannt werden, indem eine Zugriffsrichtlinie erstellt wird, die auf Office 365 Apps angewendet wird.

Hinweis

Es sei denn, der Client-App-Filter wird speziell auf Mobile und Desktop festgelegt, die resultierende Zugriffsrichtlinie gilt nur für Browsersitzungen. Der Grund dafür besteht darin, die versehentliche Proxy-Benutzersitzungen zu verhindern, was möglicherweise ein Durchprodukt für die Verwendung dieses Filters sein kann. Während die meisten wichtigsten Browser die Ausführung einer Clientzertifikatüberprüfung unterstützen, verwenden einige mobile und Desktop-Apps integrierte Browser, die diese Überprüfung möglicherweise nicht unterstützen. Daher kann die Verwendung dieses Filters die Authentifizierung für diese Apps beeinflussen.

Sitzungssteuerelemente

Während Die Sitzungssteuerelemente für die Arbeit mit jedem Beliebigen Browser auf allen wichtigen Plattformen auf jedem Betriebssystem erstellt werden, unterstützen wir Microsoft Edge (neueste), Google Chrome (neueste), Mozilla Firefox (neueste) oder Apple Safari (neueste). Der Zugriff auf mobile und Desktop-Apps kann auch blockiert oder zulässig sein.

Hinweis

  • Defender für Cloud Apps verwendet Transport Layer Security (TLS)-Protokolle 1.2+ zum Bereitstellen von best-in-Class-Verschlüsselung. Native Client-Apps und Browser, die TLS 1.2+ nicht unterstützen, sind nicht zugänglich, wenn sie mit dem Sitzungssteuerelement konfiguriert sind. SaaS-Apps, die TLS 1.1 oder niedriger verwenden, werden jedoch im Browser als TLS 1.2+ angezeigt, wenn sie mit Defender für Cloud Apps konfiguriert sind.
  • Um Sitzungssteuerelemente auf portal.office.com anzuwenden, müssen Sie Microsoft 365 Admin Center onboarden. Weitere Informationen zum Onboarding von Apps finden Sie unter Onboarding und Bereitstellen von App-Steuerelement für bedingten Zugriff für jede App.

Vorinstallierte Apps

Jede Web-App, die mithilfe der zuvor erwähnten Authentifizierungsprotokolle konfiguriert ist, kann integriert werden, um mit Zugriffs- und Sitzungssteuerelementen zu arbeiten. Darüber hinaus sind die folgenden Apps bereits mit Zugriffs- und Sitzungssteuerelementen für Azure Access Directory integriert.

Hinweis

Es ist erforderlich, Ihre gewünschten Anwendungen an Zugriffs- und Sitzungssteuerelemente zu weiterleiten und eine erste Anmeldung durchzuführen.

  • AWS
  • Feld
  • Concur
  • CornerStone OnDemand
  • DocuSign
  • Dropbox
  • egnyte
  • GitHub
  • Google Workspace
  • HighQ
  • JIRA/Confluence
  • LinkedIn Learning
  • Microsoft Azure DevOps (Visual Studio Team Services)
  • Microsoft Azure-Portal
  • Microsoft Dynamics 365 CRM
  • Microsoft Exchange Online
  • Microsoft OneDrive for Business
  • Microsoft Power BI
  • Microsoft SharePoint Online
  • Microsoft Teams
  • Microsoft Yammer
  • Salesforce
  • Slack
  • Tableau
  • Workday
  • Workiva
  • Workplace from Meta

Wenn Sie an einer speziellen App interessiert sind, die vorab integriert ist, senden Sie uns Details zu der App. Stellen Sie sicher, dass Sie den Anwendungsfall senden, den Sie für das Onboarding interessieren.

Bekannte Einschränkungen

  • Proxy kann mit eingebetteten Sitzungstoken umgehen werden
    Es ist möglich, den Proxy in Fällen zu umgehen, in denen die Anwendung selbst das Token in die Links einbetten. Ein Endbenutzer kann den Link kopieren und direkt auf die Ressource zugreifen.

  • Kopieren/Ausschneiden von Richtlinien können mithilfe von Entwicklertools umgehen werden.
    Es ist möglich, die definierte Kopie/Ausschneiden-Richtlinie mithilfe der Browserentwicklertools zu umgehen. In einer Richtlinie, die die Kopie von Inhalten aus Microsoft Word verhindert, ist es möglich, den Inhalt mithilfe von Entwicklertools anzuzeigen, den Inhalt dort zu kopieren und dann den Proxy zu umgehen.

  • Proxy kann durch eine Parameteränderung umgehen werden.
    Es ist möglich, die definierte Sitzungsrichtlinie durch Ändern von Parametern zu umgehen. Beispielsweise ist es möglich, die URL-Parameter zu ändern und den Dienst auf eine Weise zu führen, die den Proxy umgehen und einen Download einer vertraulichen Datei ermöglicht.

  • Einschränkung des Browser-Plug-Ins
    Unsere aktuelle App-Steuerungssitzungseinschränkungslösung unterstützt keine nativen Anwendungen, da es einige Änderungen des zugrunde liegenden Anwendungscodes erfordert. Browsererweiterungen, ähnlich wie systemeigene Apps, sind auf dem Browser vorinstalliert und ermöglichen es uns daher nicht, ihren Code nach Bedarf zu ändern und zu unterbrechen, wenn ihre Token über unsere Proxylösung umgeleitet werden. Als Administrator können Sie das Standardsystemverhalten definieren, wenn eine Richtlinie nicht erzwungen werden kann und zwischen dem Zulassen des Zugriffs oder vollständigen Blockierens der Richtlinie wählen kann.

  • Kontextverlust
    In den folgenden Anwendungen haben wir Szenarien gefunden, in denen die Navigation zu einem Link möglicherweise zu einem Verlust des vollständigen Pfads des Links führen kann und der Benutzer in der Regel auf der Startseite der App landet.

    • ArcGIS
    • GitHub
    • Microsoft Dynamics 365 CRM
    • Microsoft Power Automate
    • Microsoft Power Apps
    • Microsoft Power BI
    • Microsoft Yammer
    • Workplace from Meta
  • Sitzungsrichtlinien sind für Dateien bis zu 50 MB größe gültig.
    Dateien mit einer Größe von bis zu 50 MB unterliegen Sitzungsrichtlinien. Ein Administrator kann beispielsweise eine der folgenden Sitzungsrichtlinien definieren:

    • Überwachen von Dateidownloads für OneDrive-App
    • Blockieren des Dateiuploads
    • Herunterladen blockieren\Hochladen von Schadsoftwaredateien

    Eine Datei von bis zu 50 MB wird basierend auf den Sitzungsrichtlinien in diesem Fall behandelt. Für eine größere Datei bestimmen Mandanteneinstellungen ( > Einstellungen für das Standardverhalten für den bedingten Zugriff auf die App-Steuerung > ), ob die Datei zulässig oder blockiert wird, unabhängig von den übereinstimmenden Richtlinien.

  • Prüfrichtlinien für den Informationsschutz sind für Dateien bis zu 30 MB in Größe und 1 Millionen Zeichen gültig.
    Wenn eine Sitzungsrichtlinie zum Blockieren von Dateiuploads oder Downloads basierend auf der Informationsschutzinhaltsprüfung angewendet wird, wird die Überprüfung auf Dateien ausgeführt, die kleiner als 30 MB und kleiner als 1 Millionen Zeichen sind. Ein Administrator kann beispielsweise eine der folgenden Sitzungsrichtlinien definieren:

    • Blockieren des Dateiuploads für Dateien mit social Security Number (SSN)
    • Schützen des Dateidownloads für Dateien mit PHI (Geschützte Integritätsinformationen)
    • Blockieren des Dateidownloads für die Vertraulichkeitsbezeichnung "sehr vertraulich"

    In solchen Fällen werden Dateien, die größer als 30 MB oder 1 Millionen Zeichen sind, nicht gescannt und gemäß der Richtlinieneinstellung von Always die ausgewählte Aktion angewendet, auch wenn die Daten nicht gescannt werden können. Hier sind einige Beispiele:

    • eine TXT-Datei, 1 MB Größe und 1 Millionen Zeichen: wird gescannt.
    • eine TXT-Datei, 2 MB Größe und 2 Millionen Zeichen: Wird nicht gescannt.
    • eine Word-Datei aus Bildern und Text, 4 MB Größe und 400 K-Zeichen: wird gescannt.
    • eine Word-Datei aus Bildern und Text, 4 MB Größe und 2 Millionen Zeichen: wird nicht gescannt.
    • eine Word-Datei aus Bildern und Text, 40 MB Größe und 400 K-Zeichen: wird nicht gescannt.

    Hinweis

    Clientseitige Uploads und Downloads sind standardmäßig auf 5 MB beschränkt. Es ist möglich, die Größe auf bis zu 30 MB festzulegen. Es ist wichtig zu beachten, dass sich dies auf die Latenz des Endbenutzers auswirken kann.

Nächste Schritte

Anweisungen zum Onboarding Ihrer Apps finden Sie unter dem entsprechenden Dokument unten:

Wenn Probleme auftreten, helfen wir Ihnen gerne weiter. Öffnen Sie ein Supportticket, um Hilfe oder Support für Ihr Produktproblem anzufordern.