Hoe je een Salesforce-org veilig houdt terwijl je team groeit

Kort antwoord: Salesforce-orgs worden bijna nooit onveilig doordat iemand ze aanviel. Ze worden onveilig doordat rechten sneller opstapelen dan iemand ze weghaalt, en doordat integratiegebruikers veel meer toegang krijgen dan de integratie nodig heeft. Beide problemen zijn stil, beide groeien mee met het personeelsbestand, en beide los je op met ontwerpkeuzes in plaats van met securityproducten.

Wat tast Salesforce-security echt aan als een team groeit?

Twee mechanismen, en geen van beide ziet er op de dag zelf uit als een inbraak.

• Rechtenwildgroei. Toegang wordt verleend als een reeks uitzonderingen. Iemand heeft vrijdag een rapport nodig, krijgt een permission set, en houdt die drie jaar. Vermenigvuldig dat met elke aanname, elk project en elke vertrekker wiens toegang nooit is ingenomen.
• Te ruim bevoegde integratiegebruikers. De middleware moet naar twee objecten schrijven en krijgt een System Administrator-profiel, omdat dat de snelste manier is om de sync werkend te krijgen.

Beide zijn per definitie optellend. Niets in het platform haalt uit zichzelf toegang weg. Die asymmetrie, makkelijk te geven en niemands taak om in te trekken, is het hele verhaal van hoe een goed ontworpen org binnen twee jaar een auditprobleem wordt.

Waarom ontstaat rechtenwildgroei zelfs in gedisciplineerde teams?

Omdat de snelle weg en de juiste weg verschillende kanten op wijzen:

• Klonen is makkelijker dan modelleren. Een profiel klonen kost een minuut en een fatsoenlijke permission set group bouwen kost een middag, dus orgs eindigen met tientallen bijna identieke profielen die niemand durft samen te voegen.
• Tijdelijke toegang heeft geen einddatum. Salesforce neemt het niet voor je terug, en er is geen ticket dat iemand eraan herinnert.
• Niemand is eigenaar van intrekken. Bij toekenningen hoort een aanvrager. Bij intrekkingen hoort niemand, en daarom worden toegangsreviews wel ingepland en stilletjes overgeslagen.
• Gevoelige rechten verstoppen zich in de optelsom. Twee onschuldige permission sets kunnen samen iets mogelijk maken dat geen van beide bedoelde.

Welk rechtenmodel overleeft groei?

Het model dat schaalt is saai en goed gedocumenteerd. Wat telt is dat je eraan begint voordat je 200 gebruikers hebt, niet erna.

1. Minimaal basisprofiel. Geef het profiel alleen wat elke gebruiker met dat licentietype nodig heeft. Geen objecttoegang die bij een functie hoort.
2. Permission sets voor capaciteiten, niet voor personen. Een permission set beschrijft een taak, dus de naam hoort de persoon te overleven die hem als eerste nodig had.
3. Permission set groups voor rollen, met muting waar een groep net iets te veel geeft. Dit is het mechanisme waarmee je een rol samenstelt zonder alweer een profiel te klonen.
4. Automatiseer toewijzing met User Access Policies, zodat instromers en doorstromers toegang krijgen op basis van criteria en niet uit het geheugen.
5. Houd de gevaarlijke rechten op een benoemde lijst. Modify All Data, View All Data, API Enabled, export en Manage Users verdienen een eigenaar en een schriftelijke onderbouwing per houder. Is die lijst langer dan je directie, dan heb je je eerste project gevonden.

De uitleg over least privilege van Salesforce Ben is een goede aanvulling als je de klikdetails wilt. De ontwerpkeuze hierboven moet van jou komen.

Waarom zijn integratiegebruikers de grootste blinde vlek?

Omdat ze onzichtbaar zijn in elk gesprek over security. Ze volgen geen onboarding, verlaten het bedrijf nooit, en niemand beoordeelt ze als een project eindigt. Ondertussen hebben ze meestal bredere datatoegang dan welke mens in de org dan ook, en authenticeren ze zonder MFA-prompt.

Vier regels die standhouden naarmate het aantal integraties groeit:

• Een integratiegebruiker per integratie. Gedeelde integratiegebruikers maken het onmogelijk te zeggen wie een record schreef, en onmogelijk om een systeem in te trekken zonder een ander te breken.
• Gebruik waar mogelijk de API-only integratielicentie. Salesforce geeft vijf gratis Salesforce Integration-licenties op Enterprise-, Unlimited- en Performance-edities, volledig zonder UI-toegang, wat een hele klasse misbruik wegneemt.
• Scope op objecten en velden, niet op profielen. Schrijf op wat de integratie mag aanraken en dwing dat af met een permission set die alleen voor die integratie is gebouwd.
• Beperk op IP en monitor het volume. Het gedrag van een integratiegebruiker is voorspelbaar, waardoor afwijkingen erin ongewoon veelzeggend zijn vergeleken met menselijk gedrag.

Welke controles overleven schaal echt?

Dit zijn de controles die blijven werken als het team verdubbelt, geordend naar hoeveel ze terugbetalen:

1. Deploy rechten via de pipeline, niet met de hand in productie. Staan toegangswijzigingen in versiebeheer, dan heeft elke toekenning een auteur, een review en een datum. Deze ene controle maakt de volgende vier mogelijk.
2. Houd een terugkerende toegangsreview met een benoemde eigenaar en een vaste agenda: de lijst gevaarlijke rechten, integratiegebruikers, en iedereen wiens rol vorig kwartaal veranderde.
3. Spreek een vervalconventie af voor uitzonderingstoegang, desnoods afgedwongen met een agenda-herinnering. Toegang zonder einddatum is permanente toegang.
4. Volg Health Check en Setup Audit Trail als trend, niet als screenshot vlak voor een audit.
5. Neem rechten mee in code review. Een diff van een profiel of permission set verdient dezelfde aandacht als Apex, want hij kan sneller meer schade aanrichten.

Hoe weet je of het werkt?

Kies cijfers die omlaag moeten. Tel de houders van elk gevaarlijk recht. Tel rechten die buiten een permission set group zijn verleend. Tel integratiegebruikers met UI-toegang. Tel profielen. Dalen die vier niet per kwartaal, dan drijft je beveiligingspositie af, ook al is er nog niets misgegaan.

FAQ

Zijn profielen in Salesforce afgeschaft?

Nee, en je hebt er nog steeds een per gebruiker nodig. De praktische lijn is: houd profielen minimaal en druk alles rolspecifieks uit in permission sets en permission set groups.

Hoe vaak moet je toegang reviewen?

Per kwartaal voor gevaarlijke rechten en integratiegebruikers, en direct bij elke rolwijziging of uitdiensttreding. Een jaarlijkse review is een auditoefening, geen controle.

Hebben integratiegebruikers MFA nodig?

API-only integratiegebruikers authenticeren systeem naar systeem, dus de zinvolle controles zijn IP-restricties, afgebakende rechten en monitoring, niet een MFA-prompt die geen mens ooit ziet.

Is dit een probleem van securitytooling?

Tools helpen je de wildgroei zien. Ze bepalen niet wie toegang hoort te hebben. De beslissingen zijn architectureel, en daarom hoort de oplossing in je deliveryproces en niet in een aankoop.

Wij bouwen op Salesforce als gecertificeerd SI, ISV en PDO, en hebben packages door de AppExchange security review geloodst in zorg, logistiek en maakindustrie, dus het rechtenmodel is iets dat wij ontwerpen in plaats van erven. Groeide jouw org sneller dan het toegangsmodel? Neem contact op.