Patronen voor gegevensbescherming
Lees meer over Goed Architectuurde Trust → Gegevensbescherming en Privacy
Patronen
| Waar te zoeken | Hoe goed eruitziet |
|---|---|
| Gegevensclassificatieschema | ✅ Classificatieschema gedocumenteerd met niveaus (Openbaar, Intern, Vertrouwelijk, Beperkt) ✅ Bedrijfsvoorbeelden voor elk classificatieniveau ✅ Classificatieschema afgestemd op wettelijke verplichtingen (HIPAA, PCI DSS, AVG) ✅ Gegevensmodelleurs getraind om classificatie consistent toe te passen tijdens het ontwerp ✅ Nieuwe velden die zijn geclassificeerd als onderdeel van het gegevensmodelleringsproces, niet met terugwerkende kracht |
| Classificatie op veldniveau | ✅ Classificatie toegepast op veldniveau, niet alleen objectniveau ✅ Velden binnen één object kunnen verschillende classificaties hebben ✅ Beveiliging op veldniveau weerspiegelt classificatieverschillen ✅ Niet-geclassificeerde gegevens vallen terug op het hoogste geschikte beschermingsniveau ✅ Classificatie drives bescherming controles (encryptie, toegang, opslag) |
| Aangepaste objecten en velden | ✅ Alle aangepaste objecten hebben gedocumenteerde gegevensclassificatie ✅ Gevoelige velden (salaris, SSN, PHI, betalingsgegevens) geclassificeerd als Vertrouwelijk of Beperkt ✅ Openbare velden (bedrijfsnaam, website) gedocumenteerd als Openbaar ✅ Classificatiemetagegevens vastgelegd in veldbeschrijvingen ✅ Classificatie beoordeeld tijdens code beoordelingen en ARB |
| Standaardobjecten | ✅ Standaardobjectvelden geëvalueerd op basis van classificatieschema ✅ Shield Platform Encryption ingeschakeld voor standaardvelden met beperkingen ✅ Beveiliging op veldniveau toegepast op vertrouwelijke standaardvelden ✅ Rapporten en lijstweergaven gefilterd om blootstelling van gevoelige standaardvelden te voorkomen |
| Integratiegegevens | ✅ Gegevens stromen door integraties geclassificeerd vóór implementatie ✅ Extern systeem gegevensgevoeligheid geëvalueerd en gedocumenteerd ✅ Integratie-eindpunten die op certificaten gebaseerde auth. met beperkt gegevensgebruik afhandelen ✅ Gegevensclassificatie behouden over systeemgrenzen |
| Nalevingstoewijzing | ✅ HIPAA PHI-velden geïdentificeerd en gemarkeerd Beperkt ✅ PCI-kaarthoudergegevens worden waar mogelijk vermeden in Salesforce—getokeniseerd via betalingsgateway voor bereikvermindering; waar deze moeten worden opgeslagen, gebruikt u Versleutelde aangepaste velden onder PCI DSS-besturingselementen ✅ AVG-persoonsgegevens geïdentificeerd en onderworpen aan privacycontroles ✅ SOX financiële gegevens geclassificeerd en onderworpen aan scheiding van taken |
Anti-patronen
| Waar te zoeken | Hoe slecht eruitziet |
|---|---|
| Uniforme bescherming | ⚠️ Dezelfde bescherming toegepast op alle velden, ongeacht de gevoeligheid ⚠️ Gegevens van lage waarde overbeschermd (verspilling van resources) terwijl gegevens van hoge waarde onderbeschermd zijn ⚠️ Bedrijfsgegevens die hetzelfde worden behandeld als PHI- of betaalkaartgegevens ⚠️ Elk veld versleuteld “voor de zekerheid” zonder classificatie rechtvaardiging |
| Classificatie met terugwerkende kracht | ⚠️ Gegevens geclassificeerd na implementatie naar productie ⚠️ Gevoelige gegevens ontdekt door nalevingsaudits in plaats van ontwerpbeoordelingen ⚠️ Gegevens alleen geclassificeerd na beveiligingsincidenten ⚠️ “We zoeken later de classificatie uit” is de standaard tijdens de ontwikkeling |
| Classificatie op alleen objectniveau | ⚠️ Hele objecten uniform geclassificeerd wanneer velden verschillende gevoeligheid hebben ⚠️ Toegang op objectniveau verleend zonder beveiliging op veldniveau voor gevoelige velden ⚠️ Alle velden voor account- of contactpersoonsobjecten waarvan wordt aangenomen dat ze dezelfde classificatie hebben ⚠️ Objectmachtigingen die worden gebruikt als enige toegangscontrole voor objecten met gemengde gevoeligheid |
| Tribale Knowledge | ⚠️ Classificatie ongedocumenteerd, alleen bestaande in de Knowledge van belangrijke mensen ⚠️ Ontwikkelaars vertrouwden erop om “gewoon weten” welke velden gevoelig zijn ⚠️ Geen geschreven classificatieschema toegankelijk voor alle gegevensmodelleurs ⚠️ Nieuwe teamleden onboarded zonder classificatie training |
Patronen
| Waar te zoeken | Hoe goed eruitziet |
|---|---|
| Encryptie in ruste | ✅ Alle gegevens versleuteld op infrastructuurniveau via Hyperforce ✅ Shield Platform Encryption ingeschakeld voor beperkte gegevens ✅ Encryptieschema (probabilistisch, deterministisch, hoofdlettergevoelig deterministisch) geselecteerd op basis van query en uniciteitsvereisten ✅ Encryptie trade-offs geëvalueerd tijdens het ontwerp van het gegevensmodel |
| Shield Platform Encryption strategie | ✅ Probabilistische encryptie gebruikt voor de meeste velden met beperkingen (ondersteunt alle querybewerkingen) ✅ Deterministische encryptie gebruikt voor velden die exacte-match WHERE clausules of uniciteit vereisen ✅ Hoofdlettergevoelig deterministisch gebruikt waar hoofdletteronderscheid belangrijk is voor bedrijfslogica ✅ Versleutelde veldwerking getest vóór productie-implementatie ✅ Formuleveld verwijzingen naar versleutelde velden correct afgehandeld (verplaatst naar Apex indien nodig) |
| Sleutelbeheer | ✅ Sleutelrotatieprocedures gedocumenteerd en geautomatiseerd ✅ Belangrijkste vernietigingsscenario’s getest tijdens hersteloefeningen bij rampen ✅ Door de klant beheerde sleutels (BYOK) geëvalueerd voor naleving die expliciete sleutelcontrole vereisen ✅ Belangrijke intrekkingsprocedures gedocumenteerd ✅ Encryptiesleutellevenscyclus beheerd volgens nalevingsvereisten |
| Encryptie onderweg | ✅ TLS 1.2 of hoger vereist voor alle integraties ✅ Op certificaten gebaseerde wederzijdse authenticatie voor integraties die gegevens verwerken ✅ HSTS-headers geconfigureerd voor Experience Cloud-sites om downgrade van het protocol te voorkomen ✅ TLS-certificaatverval gecontroleerd en geautomatiseerde verlenging geconfigureerd ✅ Zwakke versleutelingen en protocollen uitgeschakeld |
| Code en configuratie | ✅ Inloggegevens nooit ingebed in code, configuratiebestanden of versiebeheer ✅ Benoemde inloggegevens en externe inloggegevens die worden gebruikt om authenticatie centraal te beheren ✅ Credential rotatie mogelijkheden ingebouwd in de architectuur ✅ Benoemde inloggegevens abstracte authenticatie van code, waardoor updates zonder codewijzigingen mogelijk zijn |
| AppExchange pakketten | ✅ Pakket beveiligingsvereisten geëvalueerd vóór de installatie ✅ Versleutelde velden die alleen toegankelijk zijn voor pakketten wanneer dit zakelijk verantwoord is ✅ Pakketgegevenstoegangspatronen bewaakt via Event Monitoring ✅ Pakketten die toegang vereisen tot Beperkte gegevens onderworpen aan uitgebreide beoordeling |
Anti-patronen
| Waar te zoeken | Hoe slecht eruitziet |
|---|---|
| Encryptie zonder evaluatie | ⚠️ Probabilistische encryptie ingeschakeld voor alle velden zonder testen ⚠️ Kritieke rapporten die in de productie zijn mislukt omdat versleutelde velden niet kunnen worden geaggregeerd ⚠️ Encryptie ingeschakeld voor formuleveldbronnen zonder inzicht in gevolgen ⚠️ Velden die worden gebruikt in SOQL LIKE-query’s die zijn versleuteld zonder over te schakelen op deterministische encryptie |
| Ingebedde inloggegevens | ⚠️ Inloggegevens ingebed in code, aangepaste instellingen of versiebeheer ⚠️ API sleutels, wachtwoorden en certificaten hardcoded in Apex klassen ⚠️ Inloggegevens die zijn toegewezen aan bronregelingsrepository’s ⚠️ Gegevens die zijn opgeslagen in aangepaste metagegevens of aangepaste instellingen zonder encryptie |
| Zwakke of verouderde protocollen | ⚠️ TLS 1.0 of 1.1 geaccepteerd (verouderd en kwetsbaar) ⚠️ Gebruikersnaam-wachtwoord OAuth-stroom toegestaan wanneer JWT-bearer beschikbaar is ⚠️ Certificaten met eigen ondertekening geaccepteerd in productie-integraties ⚠️ Certificaatvalidatie uitgeschakeld “om integratie te laten werken” |
| Geen sleutelbeheer | ⚠️ Shield Platform Encryption ingeschakeld zonder sleutelrotatieprocedures ⚠️ Geen gedocumenteerde sleutelvernietigingsscenario’s ⚠️ Standaardsleutels die worden gebruikt zonder door de klant beheerde sleutels te evalueren op naleving ⚠️ Sleutelrotatie- en intrekkingsprocedures nooit getest |
| Over-encryptie | ⚠️ Openbare of interne classificatiegegevens versleuteld, kosten toevoegen zonder voordeel ⚠️ Shield Platform Encryption ingeschakeld op elk veld, waardoor onnodige complexiteit ontstaat ⚠️ BYOK gebruikt wanneer naleving dit niet vereist (voegt operationele overhead toe) ⚠️ Encryptie verplicht wanneer gegevensclassificatie dit niet rechtvaardigt |
Patronen
| Waar te zoeken | Hoe goed eruitziet |
|---|---|
| Sandboxstrategie | ✅ Beperkte gegevens komen nooit in ontwikkel- of testomgevingen ✅ Gedeeltelijk kopiëren van sandbox sluit Beperkte objecten en velden uit ✅ Sandboxsjablonen definiëren welke objecten en velden moeten worden opgenomen op omgevingstype ✅ Data Mask geconfigureerd voor sandboxen die productie-achtige gegevens vereisen |
| Data Mask regels | ✅ Data Mask regels verhullen gevoelige velden met behoud van gegevenskenmerken ✅ Patronen onderhouden verwijzingsintegriteit (dezelfde invoer produceert dezelfde gemaskerde uitvoer) ✅ E-mailadressen gemaskeerd, maar blijven geldig formaat voor testen ✅ Telefoonnummers gemaskeerd, maar blijven geldig formaat ✅ Datums verschoven consistent onderhouden van relatieve relaties ✅ Numerieke velden gerandomiseerd binnen realistische bereiken |
| Synthetische gegevens | ✅ Ontwikkelomgevingen gebruiken synthetische gegevensgeneratie ✅ Synthetische gegevens hebben realistische kenmerken die effectief testen mogelijk maken ✅ Geen productiegegevens ooit vereist voor ontwikkeling ✅ Testgegevens genereren geautomatiseerd in ontwikkelingspijplijnen |
| Niet-productieomgevingen | ✅ Productiegegevens nooit gekopieerd naar persoonlijke ontwikkelaarsorganisaties ✅ Screen captures en demo’s gebruiken gemaskerde of synthetische gegevens ✅ Trainingsomgevingen gebruiken synthetische gegevens of zwaar gemaskeerde productiegegevens ✅ Contractant en leverancier toegang tot niet-productiegegevens beperkt tot Business Use Only classificatie |
Anti-patronen
| Waar te zoeken | Hoe slecht eruitziet |
|---|---|
| Productiegegevens in sandboxen | ⚠️ Volledige sandboxen vernieuwd met niet-gemaskeerde productiegegevens voor ontwikkeling ⚠️ Beperkte gegevens gekopieerd naar ontwikkelaarssandboxen voor het gemak ⚠️ Ontwikkelaars verleend brede toegang tot productie-gegevens sandboxen ⚠️ Sandboxen vernieuwd met gevoelige gegevens “omdat testen gemakkelijker is met echte gegevens” |
| Geen synthetische gegevens | ⚠️ Productiegegevens die uitsluitend voor alle tests worden gebruikt ⚠️ Geen synthetische gegevensgeneratie voor ontwikkelomgevingen ⚠️ “We hebben echte gegevens nodig” aangenomen zonder synthetische alternatieven te evalueren ⚠️ Handmatige testgegevens die worden gemaakt wanneer genereren kan worden geautomatiseerd |
Patronen
| Waar te zoeken | Hoe goed eruitziet |
|---|---|
| Gegevensminimalisering | ✅ Alleen gegevens die nodig zijn voor vermelde zakelijke doeleinden verzameld ✅ Elke veld toevoeging betwist met “welke architectonische beslissing vereist deze gegevens?” ✅ Gegevens die niet langer het doel van verzameling dienen, verwijderd ✅ Optionele velden duidelijk gemarkeerd en niet verplicht zonder zakelijke rechtvaardiging ✅ Historische gegevensbewaring afgestemd op de juridische basis, niet “houd alles voor altijd” |
| Doelbeperking | ✅ Machtigingensets beperken gegevenstoegang op basis van functiedoel ✅ Marketinggebruikers hebben geen toegang tot details van ondersteuningscases zonder gedocumenteerde rechtvaardiging ✅ Verkoopgebruikers hebben geen toegang tot klantenservicehistories, tenzij de taak dit vereist ✅ Cross-functionele toegang tot gegevens vereist expliciete goedkeuring en bewaking ✅ Doel van gegevenstoegang gedocumenteerd in beschrijvingen van machtigingensets |
| Instemmingsbeheer | ✅ Toestemming vastgelegd op individueel niveau voor marketing, analyses, optionele verwerking ✅ Instemming is fijnmazig (doelspecifiek), niet binaire deken instemming ✅ Werkstromen voor het intrekken van instemming worden doorgevoerd in geïntegreerde systemen ✅ Instemming beslissingen bijgehouden met tijdstempel, versie en mechanisme ✅ Consent UI legt duidelijk uit waar de gebruiker toestemming voor geeft |
| Rechten van betrokkene | ✅ Werkstromen voor toegangsverzoeken leveren gegevenskopieën binnen de deadline die de regelgeving voor uw implementatie stelt ✅ Rechtzettingswerkstromen corrigeren onnauwkeurigheden met controletraject ✅ Wiswerkstromen verwijderen gegevens waar wettelijk toegestaan (met inachtneming van bewaarverplichtingen) ✅ Overdraagbaarheidswerkstromen exporteren gegevens in machineleesbare indeling ✅ Rechtenwerkstromen van betrokkenen regelmatig getest om tijdlijnen te valideren ✅ Werkstroomautomatisering zorgt ervoor dat de wettelijke tijdlijnen consistent worden gehaald |
| Privacycontroles | ✅ Privacycontroles die technisch worden afgedwongen, niet alleen via beleid ✅ Regels voor delen implementeren doelbeperking ✅ Beveiliging op veldniveau beschermt gevoelige kenmerken ✅ Controletrajecten leggen privacyrelevante events vast ✅ Privacy controles gevalideerd in CI / CD-pijplijnen |
Anti-patronen
| Waar te zoeken | Hoe slecht eruitziet |
|---|---|
| Alles verzamelen | ⚠️ “Verzamel alle mogelijke gegevens, we kunnen het ooit nodig hebben” benadering ⚠️ Velden toegevoegd zonder gedocumenteerd bedrijfsdoel ⚠️ Gegevens voor onbepaalde tijd bewaard zonder rechtvaardiging voor bewaren ⚠️ Optionele gegevens die worden verzameld door velden verplicht te maken |
| Instemming voor deken | ⚠️ Enkelvoudige instemming met voorwaarden voor alle doeleinden ⚠️ Marketinginstemming gecombineerd met servicelevering in één selectievakje ⚠️ Instemming gemaakt alles-of-niets wanneer doeleinden scheidbaar zijn ⚠️ Instemming begraven in 20-pagina termen en voorwaarden |
| Beleid zonder afdwinging | ⚠️ Privacybeleid beschrijft ideale praktijken die niet technisch worden afgedwongen ⚠️ Gebruikerstraining die wordt gebruikt om ongepaste toegang tot gegevens te voorkomen ⚠️ Privacybeginselen gedocumenteerd zonder technische controles te implementeren ⚠️ Naleving van beleid aangenomen zonder bewaking en validatie |
| Handmatige verzoeken van betrokkenen | ⚠️ GDPR / CCPA verzoeken verwerkt via handmatige IT-tickets duurt maanden ⚠️ Geen gedocumenteerde procedures voor toegang, rectificatie, verwijdering, overdraagbaarheid ⚠️ Het venster voor aanvraagvoltooiing dat de regelgeving voor uw implementatie instelt, wordt gemist ⚠️ Verzoek om werkstromen die tijdens controles worden gevonden, niet te laten bestaan |
| Overmatig delen van gegevens | ⚠️ Brede toegang tot gegevens verleend over afdelingen zonder rechtvaardiging van het doel ⚠️ Marketing toegestane toegang tot ondersteuningscasedetails ⚠️ Verkoop toegestaan toegang tot klantenservice histories zonder gedocumenteerde noodzaak ⚠️ Openbaar lezen/schrijven OWD gebruikt voor objecten met persoonsgegevens |
Patronen
| Waar te zoeken | Hoe goed eruitziet |
|---|---|
| Regionale implementatie Hyperforce | ✅ Organisatie geleverd in Hyperforce regio die voldoet aan vereisten voor gegevensverblijf ✅ Gegevensopslag en -verwerking plaatsvinden binnen de vereiste geografische grenzen ✅ Regionale vereisten gedocumenteerd en gevalideerd vóór levering ✅ Multi-regio vereisten aangepakt via multi-organisatie architectuur waar nodig |
| Toewijzing van gegevensstromen | ✅ Document met gegevensstroomkaarten waar gegevens vandaan komen, worden doorgevoerd en zich bevinden ✅ Grensoverschrijdende gegevensoverdrachten geïdentificeerd en geëvalueerd op basis van regelgeving ✅ Standaard contractuele clausules of bindende bedrijfsregels voor internationale overdrachten ✅ Gegevenstransitpaden geëvalueerd voor naleving van residentie, niet alleen opslaglocatie |
| Bereik van gegevensverblijf | ✅ Gegevensopslag locatie (welke Hyperforce regio) ✅ Locatie van gegevensverwerking (rekenregio’s) ✅ Back-up opslaglocatie ✅ Logboek en audit trail opslag locatie ✅ Integratie transitpaden geëvalueerd voor grensoverschrijdende gegevensverkeer |
| Architectuur voor meerdere organisaties | ✅ Architectuur voor meerdere organisaties gebruikt wanneer niet kan worden voldaan aan wettelijke vereisten binnen één organisatie ✅ Elke organisatie geleverd in de juiste regio voor haar gegevens ✅ Integratiepatronen respecteren beperkingen voor gegevensverblijf ✅ Operationele complexiteit trade-offs gedocumenteerd in ADRs |
| Nalevingsvalidatie | ✅ Gegevensverblijfsvereisten gedocumenteerd per jurisdictie ✅ Hyperforce regio selectie gevalideerd op basis van vereisten vóór levering ✅ Periodieke audits bevestigen dat gegevens binnen de vereiste grenzen blijven ✅ Wijzigingen in residentieregelgeving activeren architectuurbeoordeling |
Anti-patronen
| Waar te zoeken | Hoe slecht eruitziet |
|---|---|
| Toezicht op ingezetenschap | ⚠️ Schendingen van gegevensverblijf ontdekt tijdens nalevingscontroles ⚠️ Organisaties die worden geleverd zonder regionale vereisten te evalueren ⚠️ “Cloud is cloud” aangenomen zonder rekening te houden met regelgeving voor gegevenslocatie ⚠️ Rechtsgebieden toegevoegd zonder verblijfsverplichtingen te beoordelen |
| Transit negeert residentie | ⚠️ Alleen opslaglocatie in aanmerking genomen terwijl transitpaden worden genegeerd ⚠️ Gegevens gerouteerd door regio’s buiten nalevingsgrenzen ⚠️ Integratie middleware gebruikt in niet-conforme regio’s ⚠️ Back-ups opgeslagen in andere regio’s dan primaire gegevens |
| Onnodige multi-organisatie | ⚠️ Architectuur voor meerdere organisaties gebruikt wanneer één organisatie met Hyperforce regio’s voldoende is ⚠️ Operationele complexiteit, licentiekosten en integratieoverhead vermenigvuldigd zonder noodzaak van regelgeving ⚠️ Multi-organisatie geïmplementeerd “voor de zekerheid” zonder een specifieke nalevingsvereiste ⚠️ Standaard multi-organisatie gebruikt wanneer gegevensclassificatie en toegangscontroles voldoende zijn |