BestandenExperience CloudDatabeveiliging

Bestanden en guest/Experience Cloud-gebruikers: blootstellingsrisico's

Hoe bestanden zichtbaar worden voor guest- en Experience Cloud-gebruikers in Salesforce: Visibility-veld, sharing per record en de misconfiguraties die data lekken.

AgentForceAccess 3 min leestijd
Een bestand binnen een ring die de org-grens markeert, met stralen die naar externe guest-gebruikers en een wereldbol schijnen

Bestandstoegang is intern al lastig genoeg. Voeg er Experience Cloud- (community-) en guest-gebruikers aan toe en het wordt in beide richtingen scherper: de bestanden die je externe gebruikers wel wilt laten zien, verschijnen soms niet, en de bestanden die je niet wilt tonen, lekken soms naar het publiek. Beide komen neer op dezelfde kleine set instellingen. Zo krijg je ze goed.

Externe gebruikers gebruiken hetzelfde model, met één extra poort

Community- en guest-gebruikers zien bestanden via hetzelfde ContentDocumentLink-model als iedereen. Maar er is een extra poort die interne gebruikers zelden tegenkomen: het Visibility-veld van de link.

VisibilityWie het insluit
AllUsersInterne én externe/community-gebruikers
InternalUsersAlleen interne gebruikers
SharedUsersAlleen gebruikers met wie expliciet is gedeeld

Om een aan een record gekoppeld bestand te zien moeten voor een Experience Cloud-gebruiker twee dingen tegelijk waar zijn: ze hebben toegang tot het record, én de Visibility van de bestandslink sluit externe gebruikers in (doorgaans AllUsers).

Daarom is “de community-gebruiker ziet het record wel maar het bestand niet” zo’n veelvoorkomend ticket: de recordtoegang is in orde, maar Visibility staat op InternalUsers.

Faalmodus 1: bestanden die zouden moeten verschijnen, doen dat niet

De onschuldige variant. Een community-gebruiker kan een case openen, maar de bijlagen ontbreken. De oplossing is bijna altijd de Visibility op de ContentDocumentLink van het bestand, plus ervoor zorgen dat bestanden die in de community worden geüpload de juiste zichtbaarheid erven. Controleer de link, niet de record-sharing.

Faalmodus 2: bestanden die niet zouden moeten verschijnen, doen dat wel

De gevaarlijke variant, en de reden dat dit onderwerp er voor de beveiliging toe doet.

Guest-gebruikers zijn niet geauthenticeerd. Het zijn anonieme bezoekers van je openbare site. Dus alles wat de configuratie van een guest-gebruiker blootstelt, is feitelijk beschikbaar voor het hele internet:

  • Een openbare link (geen login, by design) op een gevoelig bestand.
  • Bestanden die gekoppeld zijn aan records die het guest-gebruikersprofiel kan bereiken, met AllUsers-zichtbaarheid.
  • Te ruime sharing sets / sharing rules die het guest- of externe publiek meer records toekennen dan bedoeld, en daarmee meer bestanden.

Te ruime guest-toegang behoort tot de meest gerapporteerde kwesties rond datablootstelling in Salesforce. De bestanden liften mee met de records die je per ongeluk hebt blootgesteld.

De twee poorten die je samen moet auditen

Omdat externe bestandstoegang afhangt van recordtoegang ÉN bestands-Visibility, moet je beide als een paar controleren:

  1. Welke records kunnen guest- en externe gebruikers bereiken? (Sharing-model van de community, sharing sets, sharing rules.)
  2. Wat is de Visibility van de bestanden die aan die records gekoppeld zijn?
  3. Eventuele openbare links op gevoelige bestanden?

De beoogde eindtoestand: precies de bestanden die je wilde publiceren zijn bereikbaar voor het externe publiek, en niets anders. Daar komen is dezelfde kernvraag als de rest van het recordtoegangsmodel, alleen met het meest risicovolle publiek dat er bestaat.

Weten wat het publiek werkelijk kan bereiken

De combinatie — externe recordtoegang maal bestands-Visibility plus eventuele openbare links — is precies wat guest-gebruikersblootstelling moeilijk in te schatten en lastig handmatig te verifiëren maakt. AgentForceAccess beoordeelt het op dezelfde manier als interne toegang: vraag wat een guest- of community-gebruiker kan zien, en het traceert de records die ze bereiken en de bestanden die die records blootstellen, zodat “lekt er iets naar het publiek” een vraag wordt die je daadwerkelijk kunt beantwoorden.

Veelgestelde vragen

Waarom kan mijn community-gebruiker een bestand op een toegankelijk record niet zien?

Meestal staat de Visibility van de ContentDocumentLink op InternalUsers, wat externe gebruikers uitsluit ook al is de recordtoegang in orde. Om het bestand aan community-gebruikers te tonen is doorgaans Visibility = AllUsers nodig. Recordtoegang alleen volstaat niet als Visibility het publiek uitsluit.

Wat is het risico met guest-gebruikers en bestanden?

Guest-gebruikers zijn niet-geauthenticeerde bezoekers. Elk bestand dat hun sharing-configuratie of een openbare link blootstelt, is feitelijk beschikbaar voor het hele internet. Te ruime guest-toegang, of een vergeten openbare link, is een van de meest voorkomende bevindingen rond datablootstelling in Salesforce.

Hoe verhoudt bestandszichtbaarheid zich tot record-sharing in een community?

Het zijn twee aparte poorten. De gebruiker heeft toegang tot het record nodig (via het sharing-model van de community, sharing sets of sharing rules) EN de Visibility van de bestandslink moet externe gebruikers insluiten. Beide moeten op één lijn liggen, en daarom is bestandstoegang in communities een veelvoorkomend support- en beveiligingsonderwerp.

Wat moet ik controleren voordat ik bestanden in een community blootstel?

Bevestig welke records guest- en externe gebruikers kunnen bereiken en controleer vervolgens de Visibility van de bestanden die aan die records gekoppeld zijn. Audit alle openbare links. Het doel is dat precies de bedoelde bestanden, en geen andere, bereikbaar zijn voor het externe publiek.

Bekijk het op je eigen org

AgentForceAccess legt in normale taal uit waarom een gebruiker een record of bestand kan zien — over elk Salesforce share-mechanisme heen.

Vraag vroege toegang aan