Gemini data-classificatie in Google Drive: labels automatisch toepassen
Gemini past in Google Drive automatisch classificatielabels toe op basis van jouw instructies. Open beta sinds augustus 2026, z...
Sinds 14 september 2026 kun je in de Google Workspace admin console publieksgerichte deelregels en datacondities combineren in een enkele regel. Met die unified data protection rules stel je sharing boundaries in: harde grenzen aan met wie bestanden in Google Drive gedeeld mogen worden. Je kiest daarbij uit drie modi, van alles blokkeren tot een allowlist of een denylist. In dit artikel lees je wat de regels doen, hoe je ze instelt en waar je op moet letten bij de uitrol.
Wat sharing boundaries zijn en waarom je ze wilt
Sharing boundaries zijn de grenzen die bepalen met wie gebruikers binnen jouw organisatie bestanden mogen delen. Zonder zulke grenzen kan iedere medewerker in theorie een document openzetten voor iedereen met de link, naar een persoonlijk Gmail-adres sturen of een externe leverancier toegang geven tot een map vol klantgegevens. Dat is precies het moment waarop data-exfiltratie plaatsvindt: niet altijd kwaadwillig, vaak per ongeluk, maar het effect is hetzelfde.
Tot nu toe moest je zo'n grens opbouwen uit losse onderdelen. Je stelde iets in op het niveau van delen buiten de organisatie, en daarnaast werkte je met DLP-regels en classificatielabels om gevoelige inhoud te beschermen. Die twee werelden stonden naast elkaar. Sinds 14 september 2026 komen ze samen in een enkele regel, binnen de unified data protection rules. Je combineert dan een publieksgerichte voorwaarde, wie mag dit wel of niet zien, met een dataconditie, om welk soort inhoud het gaat. Een regel kan bijvoorbeeld zeggen: delen buiten de organisatie is toegestaan, behalve wanneer het bestand een classificatielabel voor vertrouwelijk draagt.
De drie modi: blokkeren, allowlist en denylist
De kracht zit in de drie modi waarin je een sharing boundary kunt zetten. Je kiest de modus die past bij hoe streng je organisatie wil zijn, en je kunt per regel verfijnen.
| Modus | Wat het doet | Wanneer geschikt |
|---|---|---|
| Alle externe sharing blokkeren | Voorkomt dat bestanden die aan de inhoudscriteria voldoen buiten de organisatie worden gedeeld | Volledig gesloten willen werken |
| Allowlist | Blokkeert alle interne en externe sharing, behalve met de toegestane organisatie-eenheden, groepen of domeinen | Standaard dicht, gericht open |
| Denylist | Blokkeert sharing met specifieke interne organisatie-eenheden, groepen of externe partijen; de rest mag | Soepel blijven delen, specifiek blokkeren |
De eerste modus blokkeert alle externe sharing. Niemand deelt nog iets met een partij buiten je organisatie. Dit is de strengste stand aan de buitenkant en werkt goed voor organisaties die volledig gesloten willen werken, bijvoorbeeld bij zeer gevoelige dossiers of in een tijdelijk crisisscenario.
De tweede modus blokkeert alle interne en externe sharing behalve een allowlist. Sharing staat standaard dicht, maar je maakt gerichte uitzonderingen. Je kunt specifieke organisatie-eenheden, specifieke groepen of specifieke externe domeinen op de allowlist zetten. Zo mag de afdeling Inkoop wel delen met het domein van een vaste leverancier, terwijl de rest van de organisatie dicht blijft. Dit is in de praktijk de modus die de meeste organisaties willen: standaard dicht, gericht open.
De derde modus werkt met een denylist. Hier blokkeer je specifieke interne organisatie-eenheden, groepen of externe partijen, terwijl al het overige delen is toegestaan. Je kunt bijvoorbeeld een leverancier blokkeren waarmee je net een samenwerking hebt beëindigd, of een interne groep die met gevoelige persoonsgegevens werkt volledig afschermen, terwijl de rest van de organisatie normaal blijft samenwerken.
Het verschil tussen allowlist en denylist is een keuze in risicohouding. Een allowlist is veiliger, omdat je expliciet toestemming geeft en de standaard dicht is. Een denylist is soepeler en grijpt alleen in waar nodig. Kies de strengste variant die je werkprocessen nog toelaten.
Sharing boundaries instellen in de admin console
De instelling vind je in de admin console bij de data protection rules. Je kiest daar de app Google Drive en vervolgens de optie om sharing te blokkeren. Binnen die regel stel je de modus in en bepaal je welke organisatie-eenheden, groepen of domeinen wel of niet mogen delen.
De logische opbouw is als volgt. Eerst bepaal je de scope: geldt de regel voor de hele organisatie of alleen voor een specifieke organisatie-eenheid of groep. Daarna kies je de modus: alles blokkeren, allowlist of denylist. Vervolgens voeg je de uitzonderingen toe, de interne organisatie-eenheden, groepen of externe domeinen die je wel of juist niet wilt toestaan. Tot slot koppel je zo nodig een dataconditie, bijvoorbeeld een classificatielabel of een DLP-conditie, zodat de regel alleen geldt voor inhoud met een bepaald gevoeligheidsniveau.
Wat de regels sterk maakt, is dat je ze kunt stapelen. Je kunt een brede regel neerzetten die extern delen beperkt, en daarbovenop een fijnmazige regel die voor vertrouwelijke bestanden nog strenger is. Omdat publieksgerichte regels en datacondities nu in een en dezelfde regel samenkomen, houd je het overzicht. Je hoeft niet meer te reconstrueren welke losse instellingen samen welk effect hebben.
Voor wie is het beschikbaar
De unified data protection rules met sharing boundaries zijn beschikbaar voor Enterprise Standard en Plus, Education Standard en Plus, Enterprise Essentials, en Frontline Standard en Plus. Werk je in een kleinere licentie, dan kun je deze specifieke combinatie niet gebruiken, maar de onderliggende deelinstellingen blijven uiteraard wel bestaan.
Waarom dit helpt tegen data-exfiltratie
Data-exfiltratie klinkt als iets voor grote concerns, maar het begint klein. Een medewerker die een export deelt met een privé-adres, een projectgroep die een map openzet voor een externe partij die later afhaakt, een leverancier die toegang houdt na het einde van een contract. Sharing boundaries pakken dat patroon bij de bron aan: niet door achteraf te zoeken wat er is weggegaan, maar door vooraf te bepalen wat er weg mag.
Dat sluit aan op een zero trust-gedachte. Je vertrouwt niet standaard dat elke gebruiker de juiste afweging maakt op het moment dat hij op delen klikt, maar je legt de grens centraal vast. De gebruiker merkt daar meestal weinig van, zolang zijn normale werk maar binnen de regel past. Alleen de uitzondering, het delen met een partij die niet is toegestaan, wordt geblokkeerd.
Het mooie is dat je dit kunt combineren met andere beschermingslagen. Denk aan context-aware access, dat toegang afhankelijk maakt van identiteit, locatie, apparaatstatus en IP, en aan client-side encryption voor de gevoeligste bestanden. Samen vormen die lagen een verdediging in de diepte: zelfs als een grens ergens niet dicht is, vangt een andere laag het op.
Zo pak je de uitrol aan
Begin niet met de strengste stand voor de hele organisatie. Dat levert onnodig veel supportvragen op en ondermijnt het draagvlak. Werk in stappen.
Breng eerst in kaart met wie nu wordt gedeeld. Kijk welke externe domeinen en groepen veel voorkomen. Dat zijn de partijen die je waarschijnlijk op een allowlist wilt, of bewust niet.
Kies daarna een pilotgroep. Een afdeling die met gevoelige gegevens werkt en tegelijk openstaat voor feedback is ideaal. Zet daar de strengere modus aan en meet wat er gebeurt.
Communiceer vervolgens vooraf. Leg medewerkers uit wat er verandert, waarom, en hoe ze een uitzondering aanvragen. Een grens zonder uitleg voelt als een blokkade, met uitleg voelt het als bescherming.
Breid daarna uit naar de rest. Zet de allowlist of denylist organisatiebreed aan zodra de pilot stabiel loopt, en combineer de regel met classificatielabels voor de gevoeligste bestanden.
Monitor tot slot en stel bij. Bekijk welke blokkades optreden en of die kloppen. Een grens is geen eenmalige instelling, maar iets dat je met de organisatie mee laat groeien.
Een concreet scenario: de vertrouwelijke map
Stel dat een organisatie een map heeft met vertrouwelijke klantdossiers. Medewerkers mogen intern samenwerken, maar de inhoud mag het bedrijf niet verlaten. Met een denylist-regel op de betrokken groep, gekoppeld aan een classificatielabel voor vertrouwelijk, wordt delen buiten de organisatie geblokkeerd zodra een dossier dat label draagt. De rest van de organisatie blijft gewoon samenwerken.
Die combinatie is de kern van de unified regels: je kijkt niet alleen naar wie deelt, maar ook naar wat wordt gedeeld. Een regel die alleen op publiek stuurt, zou te grof zijn en te veel normale samenwerking blokkeren. Een regel die alleen op inhoud stuurt, laat de vraag open met wie iets mag worden gedeeld. Door beide te combineren, krijg je een grens die precies past bij de gevoeligheid van de inhoud.
Uitzonderingen beheren zonder de grens te verliezen
Elke organisatie heeft uitzonderingen nodig. Een vaste accountant, een samenwerkingspartner of een moederbedrijf moet bereikbaar blijven. De kunst is om die uitzonderingen expliciet te maken in plaats van de hele grens open te zetten.
Gebruik daarvoor de allowlist-modus: standaard dicht, gericht open voor specifieke organisatie-eenheden, groepen of domeinen. Leg vast wie een uitzondering mag aanvragen en wie die goedkeurt. En herzie de lijst periodiek, want samenwerkingen veranderen. Zo blijft de allowlist een levend instrument en geen vergeten lijst.
Conclusie
Sharing boundaries met unified data protection rules geven je als beheerder een centrale knop om te bepalen met wie je organisatie deelt. Sinds 14 september 2026 combineer je daarvoor publieksgerichte deelregels en datacondities in een enkele regel, met drie modi van volledig blokkeren tot allowlist en denylist. Begin klein, communiceer helder en breid uit zodra de pilot loopt.
Wil je hulp bij het opzetten van sharing boundaries of het combineren met DLP en classificatielabels? Neem contact op of bekijk onze Google Workspace-diensten en cybersecurity-diensten. Meer lezen over de bredere aanpak vind je in ons artikel security checklist 2026 en in het artikel over zero trust met context-aware access.