Apps beveiligen met App-beheer voor voorwaardelijke toegang van Microsoft Defender for Cloud Apps

Notitie

  • De naam van Microsoft Cloud App Security is gewijzigd. Het heet nu Microsoft Defender for Cloud Apps. In de komende weken werken we de schermafbeeldingen en instructies hier en op gerelateerde pagina's bij. Zie deze aankondiging voor meer informatie over de wijziging. Zie het Microsoft Ignite Security-blog voor meer informatie over de recente hernoeming van Microsoft-beveiligingsservices.

  • Microsoft Defender for Cloud Apps maakt nu deel uit van Microsoft 365 Defender. Met de Microsoft 365 Defender-portal kunnen beveiligingsbeheerders hun beveiligingstaken op één locatie uitvoeren. Dit vereenvoudigt werkstromen en voegt de functionaliteit van de andere Microsoft 365 Defender-services toe. Microsoft 365 Defender is de thuisbasis voor het bewaken en beheren van beveiliging in uw Microsoft-identiteiten, gegevens, apparaten, apps en infrastructuur. Zie Microsoft Defender for Cloud Apps in Microsoft 365 Defender voor meer informatie over deze wijzigingen.

Op de huidige werkplek is het vaak niet genoeg om na het feit te weten wat er in uw cloudomgeving gebeurt. U wilt inbreuken en lekken in realtime stoppen, voordat werknemers opzettelijk of onbedoeld uw gegevens en uw organisatie in gevaar brengen. Het is belangrijk om gebruikers in uw organisatie in staat te stellen optimaal gebruik te maken van de services en hulpprogramma's die voor hen beschikbaar zijn in cloud-apps en hun eigen apparaten te laten werken. Tegelijkertijd hebt u hulpprogramma's nodig om uw organisatie in realtime te beschermen tegen gegevenslekken en gegevensdiefstal. Microsoft Defender for Cloud Apps integreert met elke id-provider (IdP) om deze mogelijkheden te leveren met toegangs- en sessiebeheer. Als u Azure Active Directory (Azure AD) als uw IdP gebruikt, zijn deze besturingselementen geïntegreerd en gestroomlijnd voor een eenvoudigere en meer op maat gemaakte implementatie die is gebouwd op het hulpprogramma voor voorwaardelijke toegang van Azure AD.

Notitie

  • Naast een geldige Defender for Cloud Apps-licentie hebt u ook een Azure Active Directory P1-licentie of de licentie nodig die is vereist voor uw IdP-oplossing om Defender for Cloud Apps-app-beheer voor voorwaardelijke toegang te gebruiken.

Uitleg

App Control voor voorwaardelijke toegang maakt gebruik van een reverse proxy-architectuur en kan worden geïntegreerd met uw IdP. Wanneer u integreert met Azure AD voorwaardelijke toegang, kunt u apps configureren voor gebruik met app-beheer voor voorwaardelijke toegang met slechts een paar klikken, zodat u eenvoudig en selectief toegangs- en sessiebeheer kunt afdwingen op de apps van uw organisatie op basis van elke voorwaarde in voorwaardelijke toegang. De voorwaarden bepalen wie (gebruiker of groep gebruikers) en op welke (welke cloud-apps) en waar (welke locaties en netwerken) beleid voor voorwaardelijke toegang wordt toegepast. Nadat u de voorwaarden hebt vastgesteld, kunt u gebruikers routeren naar Defender for Cloud Apps, waar u gegevens kunt beveiligen met App Control voor voorwaardelijke toegang door toegangs- en sessiebesturingselementen toe te passen.

Met App Control voor voorwaardelijke toegang kunnen gebruikers-app-toegang en -sessies in realtime worden bewaakt en beheerd op basis van toegangs- en sessiebeleid. Toegangs- en sessiebeleid wordt gebruikt in de Defender for Cloud Apps-portal om filters verder te verfijnen en acties in te stellen die voor een gebruiker moeten worden uitgevoerd. Met het toegangs- en sessiebeleid kunt u het volgende doen:

  • Gegevensexfiltratie voorkomen: u kunt het downloaden, knippen, kopiëren en afdrukken van gevoelige documenten op bijvoorbeeld niet-beheerde apparaten blokkeren.

  • Verificatiecontext vereisen: u kunt Azure AD beleid voor voorwaardelijke toegang opnieuw beoordelen wanneer er een gevoelige actie plaatsvindt in de sessie. Vereisen bijvoorbeeld meervoudige verificatie bij het downloaden van een zeer vertrouwelijk bestand.

  • Beveiligen bij downloaden: in plaats van het downloaden van gevoelige documenten te blokkeren, kunt u vereisen dat documenten worden gelabeld en versleuteld wanneer u integreert met Microsoft Purview Informatiebeveiliging. Deze actie zorgt ervoor dat het document is beveiligd en dat gebruikerstoegang wordt beperkt in een mogelijk riskante sessie.

  • Uploaden van niet-gelabelde bestanden voorkomen: voordat een gevoelig bestand wordt geüpload, gedistribueerd en gebruikt door anderen, is het belangrijk om ervoor te zorgen dat het gevoelige bestand het label heeft dat is gedefinieerd door het beleid van uw organisatie. U kunt ervoor zorgen dat niet-gelabelde bestanden met gevoelige inhoud niet kunnen worden geüpload totdat de gebruiker de inhoud classificeert.

  • Mogelijke malware blokkeren: u kunt uw omgeving beschermen tegen malware door het uploaden van mogelijk schadelijke bestanden te blokkeren. Elk bestand dat wordt geüpload of gedownload, kan worden gescand op bedreigingsinformatie van Microsoft en onmiddellijk geblokkeerd.

  • Gebruikerssessies controleren op naleving: Riskante gebruikers worden bewaakt wanneer ze zich aanmelden bij apps en hun acties worden vastgelegd vanuit de sessie. U kunt gebruikersgedrag onderzoeken en analyseren om te begrijpen waar en onder welke omstandigheden sessiebeleid in de toekomst moet worden toegepast.

  • Toegang blokkeren: u kunt de toegang voor specifieke apps en gebruikers gedetailleerd blokkeren, afhankelijk van verschillende risicofactoren. U kunt ze bijvoorbeeld blokkeren als ze clientcertificaten gebruiken als vorm van apparaatbeheer.

  • Aangepaste activiteiten blokkeren: sommige apps hebben unieke scenario's die risico lopen, bijvoorbeeld het verzenden van berichten met gevoelige inhoud in apps zoals Microsoft Teams of Slack. In dit soort scenario's kunt u berichten scannen op gevoelige inhoud en deze in realtime blokkeren.

Hoe sessiebeheer werkt

Als u een sessiebeleid maakt met App Control voor voorwaardelijke toegang, kunt u gebruikerssessies beheren door de gebruiker om te leiden via een omgekeerde proxy in plaats van rechtstreeks naar de app. Vanaf dat jaar gaan gebruikersaanvragen en -antwoorden via Defender voor Cloud Apps in plaats van rechtstreeks naar de app.

Wanneer een sessie wordt beveiligd door proxy, worden alle relevante URL's en cookies vervangen door Defender for Cloud Apps. Als de app bijvoorbeeld een pagina retourneert met koppelingen waarvan de domeinen eindigen myapp.com, wordt het domein van de koppeling als volgt met iets als *.mcas.msvolgt geretourneerd:

App-URL Vervangen URL
myapp.com myapp.com.mcas.ms

Voor deze methode hoeft u niets op het apparaat te installeren, waardoor het ideaal is bij het bewaken of beheren van sessies van onbeheerde apparaten of partnergebruikers.

Notitie

  • Onze technologie maakt gebruik van best-in-class gepatenteerde heuristieken om activiteiten te identificeren en te beheren die door de gebruiker in de doel-app worden uitgevoerd. Onze heuristieken zijn ontworpen om de beveiliging te optimaliseren en te balanceren met bruikbaarheid. In sommige zeldzame scenario's, wanneer het blokkeren van activiteiten aan de serverzijde de app onbruikbaar maakt, beveiligen we deze activiteiten alleen aan de clientzijde, waardoor ze mogelijk vatbaar zijn voor misbruik door kwaadwillende insiders.
  • Defender for Cloud Apps maakt gebruik van Azure-datacenters over de hele wereld om geoptimaliseerde prestaties te bieden via geolocatie. Dit betekent dat de sessie van een gebruiker kan worden gehost buiten een bepaalde regio, afhankelijk van verkeerspatronen en hun locatie. Om uw privacy te beschermen, worden er echter geen sessiegegevens opgeslagen in deze datacenters.
  • Onze proxyservers slaan geen data-at-rest op. Bij het opslaan van inhoud in cache volgen we de vereisten die zijn vastgelegd in RFC 7234 (HTTP-caching) en alleen openbare inhoud in de cache.

Identificatie van beheerde apparaten

Met App-beheer voor voorwaardelijke toegang kunt u beleid maken dat er rekening mee houdt of een apparaat wordt beheerd of niet. Als u de status van een apparaat wilt identificeren, kunt u toegangs- en sessiebeleid configureren om te controleren op:

  • Microsoft Intune compatibele apparaten [alleen beschikbaar met Azure AD]
  • Hybride Azure AD-gekoppelde apparaten [alleen beschikbaar met Azure AD]
  • Aanwezigheid van clientcertificaten in een vertrouwde keten

Intune compatibele en hybride Azure AD gekoppelde apparaten

met Azure AD voorwaardelijke toegang kunnen Intune compatibele en hybride Azure AD gekoppelde apparaatgegevens rechtstreeks worden doorgegeven aan Defender for Cloud Apps. Van daaruit kan een toegangsbeleid of een sessiebeleid worden ontwikkeld dat de apparaatstatus als filter gebruikt. Zie de inleiding tot apparaatbeheer in Azure Active Directory voor meer informatie.

Notitie

Voor sommige browsers is mogelijk aanvullende configuratie vereist, zoals het installeren van een extensie. Zie de ondersteuning van de browser voor voorwaardelijke toegang voor meer informatie.

Geverifieerde apparaten met clientcertificaten

Het apparaatidentificatiemechanisme kan verificatie aanvragen bij relevante apparaten met behulp van clientcertificaten. U kunt bestaande clientcertificaten gebruiken die al in uw organisatie zijn geïmplementeerd of nieuwe clientcertificaten implementeren op beheerde apparaten. Zorg ervoor dat het clientcertificaat is geïnstalleerd in het gebruikersarchief en niet in het computerarchief. Vervolgens gebruikt u de aanwezigheid van deze certificaten om toegangs- en sessiebeleid in te stellen.

SSL-clientcertificaten worden geverifieerd via een vertrouwensketen. U kunt een X.509-basis- of tussenliggende certificeringsinstantie (CA) uploaden die zijn opgemaakt in de PEM-certificaatindeling. Deze certificaten moeten de openbare sleutel van de CA bevatten, die vervolgens wordt gebruikt om de clientcertificaten te ondertekenen die tijdens een sessie worden gepresenteerd.

Zodra het certificaat is geüpload en een relevant beleid is geconfigureerd, vraagt het Defender for Cloud Apps-eindpunt de browser om de SSL-clientcertificaten te presenteren wanneer een toepasselijke sessie het app-beheer voor voorwaardelijke toegang doorkruist. De browser dient de SSL-clientcertificaten die zijn geïnstalleerd met een persoonlijke sleutel. Deze combinatie van certificaat en persoonlijke sleutel wordt gedaan met behulp van de PKCS #12-bestandsindeling, meestal .p12 of .pfx.

Wanneer een controle van een clientcertificaat wordt uitgevoerd, controleert Defender for Cloud Apps op de volgende voorwaarden:

  1. Het geselecteerde clientcertificaat is geldig en bevindt zich onder de juiste basis- of tussenliggende CA.
  2. Het certificaat wordt niet ingetrokken (als CRL is ingeschakeld).

Notitie

De meeste belangrijke browsers ondersteunen het uitvoeren van een controle van een clientcertificaat. Mobiele en desktop-apps maken echter vaak gebruik van ingebouwde browsers die deze controle mogelijk niet ondersteunen en dus van invloed zijn op verificatie voor deze apps.

Een beleid configureren voor het gebruik van apparaatbeheer via clientcertificaten:

  1. Selecteer in Defender voor Cloud Apps in de menubalk het pictogram Instellingen tandwielinstellingen. en selecteer Instellingen.

  2. Selecteer het tabblad Apparaatidentificatie .

  3. Upload zoveel basis- of tussenliggende certificaten als u nodig hebt.

    Tip

    Als u wilt testen hoe dit werkt, kunt u als volgt onze voorbeeld-CA en het clientcertificaat gebruiken:

    1. Download de voorbeeld-CA en het clientcertificaat.
    2. Upload de basis-CA naar Defender for Cloud Apps.
    3. Installeer het clientcertificaat (wachtwoord=Microsoft) op de relevante apparaten.

Nadat de certificaten zijn geüpload, kunt u toegangs- en sessiebeleid maken op basis van apparaattag en geldig clientcertificaat.

Ondersteunde apps en clients

Sessie- en toegangsbeheer kan worden toegepast op interactieve eenmalige aanmelding, met behulp van het SAML 2.0-verificatieprotocol of, als u Azure AD gebruikt, ook het Open ID Connect-verificatieprotocol. Als uw apps zijn geconfigureerd met Azure AD, kunt u deze besturingselementen ook toepassen op apps die on-premises worden gehost met de Azure AD app-proxy. Daarnaast kunnen toegangsbeheer worden toegepast op systeemeigen mobiele en desktopclient-apps.

Defender for Cloud Apps identificeert apps met behulp van informatie die beschikbaar is in de cloud-app-catalogus. Sommige organisaties en gebruikers passen apps aan door invoegtoepassingen toe te voegen. Om sessiebesturingselementen correct te laten werken met deze invoegtoepassingen, moeten de gekoppelde aangepaste domeinen echter worden toegevoegd aan de respectieve app in de catalogus.

Notitie

De Verificator-app maakt, naast andere systeemeigen aanmeldingsstromen voor client-apps, gebruik van een niet-interactieve aanmeldingsstroom, en kan niet worden gebruikt met besturingselementen voor toegang.

Besturingselementen voor toegang

Veel organisaties die ervoor kiezen om sessiebesturingselementen te gebruiken voor cloud-apps om in-sessieactiviteiten te beheren, passen ook toegangsbeheer toe om dezelfde set systeemeigen mobiele en desktopclient-apps te blokkeren, waardoor uitgebreide beveiliging voor de apps wordt geboden.

U kunt de toegang tot systeemeigen mobiele en desktopclient-apps met toegangsbeleid blokkeren door het filter client-app in te stellen op Mobiel en desktop. Sommige systeemeigen client-apps kunnen afzonderlijk worden herkend, terwijl andere apps die deel uitmaken van een suite met apps, alleen kunnen worden geïdentificeerd als hun app op het hoogste niveau. Apps zoals SharePoint Online kunnen bijvoorbeeld alleen worden herkend door een toegangsbeleid te maken dat is toegepast op Office 365 apps.

Notitie

Tenzij het filter client-app specifiek is ingesteld op Mobiel en desktop, is het resulterende toegangsbeleid alleen van toepassing op browsersessies. De reden hiervoor is om onbedoeld proxy-gebruikerssessies te voorkomen. Dit kan een voorproduct zijn van het gebruik van dit filter. Hoewel de meeste belangrijke browsers ondersteuning bieden voor het uitvoeren van een clientcertificaatcontrole, gebruiken sommige mobiele en desktop-apps ingebouwde browsers die deze controle mogelijk niet ondersteunen. Daarom kan het gebruik van dit filter van invloed zijn op verificatie voor deze apps.

Besturingselementen voor sessie

Hoewel sessiebesturingselementen zijn gebouwd om te werken met elke browser op elk belangrijk platform op elk besturingssysteem, ondersteunen we Microsoft Edge (nieuwste), Google Chrome (nieuwste), Mozilla Firefox (nieuwste) of Apple Safari (nieuwste). Toegang tot mobiele en desktop-apps kan ook worden geblokkeerd of toegestaan.

Notitie

  • Defender for Cloud Apps maakt gebruik van TLS-protocollen (Transport Layer Security) 1.2+ om optimale versleuteling te bieden. Systeemeigen client-apps en -browsers die geen ondersteuning bieden voor TLS 1.2+, zijn niet toegankelijk wanneer deze zijn geconfigureerd met sessiebeheer. SaaS-apps die TLS 1.1 of lager gebruiken, worden echter weergegeven in de browser als TLS 1.2+ wanneer deze zijn geconfigureerd met Defender for Cloud Apps.
  • Als u sessiebesturingselementen wilt toepassen op portal.office.com, moet u Microsoft 365-beheercentrum onboarden. Zie App-beheer voor voorwaardelijke toegang onboarden en implementeren voor elke app voor meer informatie over onboarding-apps.

Vooraf onboarding-apps

Elke web-app die is geconfigureerd met behulp van de eerder genoemde verificatieprotocollen , kan worden onboarding uitgevoerd om te werken met toegangs- en sessiebesturingselementen. Daarnaast zijn de volgende apps al voorbereid met zowel toegangs- als sessiebesturingselementen voor Azure Access Directory.

Notitie

Het is vereist om uw gewenste toepassingen te routeren om toegang te krijgen tot sessiebeheer en om een eerste aanmelding uit te voeren.

  • AWS
  • Box
  • Concur
  • CornerStone op aanvraag
  • 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 voor Bedrijven
  • Microsoft Power BI
  • Microsoft SharePoint Online
  • Microsoft Teams
  • Microsoft Yammer
  • SalesForce
  • Slack
  • Tableau
  • Workday
  • Workiva
  • Workplace from Meta

Als u geïnteresseerd bent in een specifieke app die vooraf wordt voorbereid, stuurt u ons details over de app. Zorg ervoor dat u de use-case verzendt waarin u geïnteresseerd bent voor onboarding.

Bekende beperkingen

  • Proxy kan worden overgeslagen met behulp van een ingesloten sessietoken
    Het is mogelijk om de proxy te omzeilen in gevallen waarin de toepassing zelf het token insluit in de koppelingen. Een eindgebruiker kan de koppeling kopiëren en in dat geval rechtstreeks toegang krijgen tot de resource.

  • Beleid voor kopiëren/knippen kan worden overgeslagen met ontwikkelhulpprogramma's
    Het is mogelijk om het gedefinieerde beleid voor kopiëren/knippen te omzeilen met behulp van de hulpprogramma's voor browserontwikkelaars. In een beleid dat bijvoorbeeld voorkomt dat inhoud uit Microsoft Word wordt gekopieerd, is het mogelijk om de inhoud weer te geven met ontwikkelhulpprogramma's, de inhoud daar te kopiëren en vervolgens de proxy te omzeilen.

  • Proxy kan worden overgeslagen door een parameterwijziging
    Het is mogelijk om het gedefinieerde sessiebeleid te omzeilen door parameters te wijzigen. Het is bijvoorbeeld mogelijk om de URL-parameters te wijzigen en de service op een manier te misleiden die de proxy overslaan en het downloaden van een gevoelig bestand mogelijk maakt.

  • Beperking van browserinvoegtoepassing
    Onze huidige oplossing voor het afdwingen van sessiebeperkingen voor voorwaardelijke toegang biedt geen ondersteuning voor systeemeigen toepassingen, omdat hiervoor enige wijziging van de onderliggende toepassingscode is vereist. Browserextensies, vergelijkbaar met systeemeigen apps, zijn vooraf geïnstalleerd in de browser, zodat we hun code niet naar behoefte kunnen wijzigen en worden verbroken wanneer hun tokens worden omgeleid via onze proxyoplossing. Als beheerder kunt u het standaardsysteemgedrag definiëren wanneer een beleid niet kan worden afgedwongen en kunt kiezen tussen het toestaan van toegang of het volledig blokkeren ervan.

  • Contextverlies
    In de volgende toepassingen zijn scenario's opgetreden waarbij het navigeren naar een koppeling kan leiden tot verlies van het volledige pad van de koppeling en meestal de gebruiker op de startpagina van de app terechtkomt.

    • ArcGIS
    • GitHub
    • Microsoft Dynamics 365 CRM
    • Microsoft Power Automate
    • Microsoft Power Apps
    • Microsoft Power BI
    • Microsoft Yammer
    • Workplace from Meta
  • Sessiebeleid is geldig voor bestanden tot 50 MB groot
    Bestanden met een grootte van maximaal 50 MB zijn onderhevig aan sessiebeleid. Een beheerder kan bijvoorbeeld een van de volgende sessiebeleidsregels definiëren:

    • Bestandsdownloads voor OneDrive-app controleren
    • Uploaden van bestanden blokkeren
    • Downloaden/uploaden van malwarebestanden blokkeren

    Een bestand van maximaal 50 MB wordt verwerkt op basis van het sessiebeleid in dat geval. Voor een groter bestand bepalen tenantinstellingen (instellingen > voor app-beheer > voor voorwaardelijke toegang standaardgedrag) of het bestand is toegestaan of geblokkeerd, ongeacht het overeenkomende beleid.

  • Inspectiebeleid voor informatiebeveiliging is geldig voor bestanden van maximaal 30 MB en 1 miljoen tekens
    Wanneer een sessiebeleid voor het blokkeren van bestandsuploads of downloads op basis van inhoudsinspectie van informatiebeveiliging wordt toegepast, wordt inspectie uitgevoerd op bestanden die kleiner zijn dan 30 MB en kleiner zijn dan 1 miljoen tekens. Een beheerder kan bijvoorbeeld een van de volgende sessiebeleidsregels definiëren:

    • Bestandsupload blokkeren voor bestanden met SSN (Social Security Number)
    • Bestand downloaden beveiligen voor bestanden met PHI (Protected Health Information)
    • Bestandsdownload blokkeren voor met gevoeligheidslabel 'zeer gevoelig'

    In dergelijke gevallen worden bestanden die groter zijn dan 30 MB of 1 miljoen tekens niet gescand en worden ze behandeld volgens de beleidsinstelling Altijd de geselecteerde actie toepassen, zelfs als de gegevens niet kunnen worden gescand. Hier volgen enkele voorbeelden:

    • een TXT-bestand, een grootte van 1 MB en 1 miljoen tekens: wordt gescand
    • een TXT-bestand, een grootte van 2 MB en 2 miljoen tekens: wordt niet gescand
    • een Word-bestand dat bestaat uit afbeeldingen en tekst, 4 MB en 400 K tekens: wordt gescand
    • een Word-bestand dat bestaat uit afbeeldingen en tekst, 4 MB en 2 miljoen tekens: wordt niet gescand
    • een Word-bestand dat bestaat uit afbeeldingen en tekst, 40 MB en 400 K tekens: wordt niet gescand

    Notitie

    Uploads en downloads aan de clientzijde zijn standaard beperkt tot 5 MB. Het is mogelijk om de grootte in te stellen op maximaal 30 MB. Het is belangrijk te weten dat dit van invloed kan zijn op de latentie van eindgebruikers.

Volgende stappen

Zie het juiste document hieronder voor instructies over het onboarden van uw apps:

Als u problemen ondervindt, zijn we hier om u te helpen. Als u hulp of ondersteuning voor uw productprobleem wilt krijgen, opent u een ondersteuningsticket.