Vertrouwen

Bij Salesforce is Trust onze beste waarde. Het is de basis van elke architectonische beslissing op het platform. Voor architecten wordt Trust bereikt via een uniek partnerschap: Salesforce biedt een veilig, conform platform (de infrastructuur, metagegevens en tools om het uw eigen te maken), terwijl u veilige oplossingen ontwerpt die op die basis vertrouwen.

Dit partnerschap werkt via het Shared Responsibility Model, een raamwerk dat de beveiligingsverantwoordelijkheden duidelijk verdeelt:

• Salesforce is verantwoordelijk voor de beveiliging van het platform, inclusief infrastructuur-, patch- en nalevingscertificeringen.
• U bent verantwoordelijk voor de beveiliging op het platform, inclusief configuratie, toegangscontroles, aangepaste code en gegevensbeheer.

Deze divisie is essentieel omdat het architectonische verantwoording definieert. Salesforce werkt met een architectuur voor meerdere belanghebbenden waarin duizenden organisaties de infrastructuur delen. Het platform biedt sterke beveiliging op infrastructuurniveau. Uw architectonische beslissingen bepalen of uw specifieke oplossingen het vertrouwen van belanghebbenden verdienen.

Het model Gedeelde verantwoordelijkheid geeft u de leiding over het ontwerpen van veilige oplossingen, terwijl fysieke beveiliging, netwerkbescherming, platformpatching en infrastructuurencryptie voor u worden afgehandeld. Hierdoor kunt u zich richten op het ontwerpen van veilige oplossingen die zijn gebaseerd op die basis (bijvoorbeeld identiteits- en toegangsbeheer, gegevensbescherming, integratiebeveiliging, veilige ontwikkelingspraktijken, naleving van regelgeving en incidentresponsmogelijkheden).

Het negeren van Trust tijdens het ontwerp maakt technische schulden. Een ontbrekende encryptiestrategie wordt een kostbare retrofit wanneer regelgeving verandert. Een onbeheerde integratie wordt een kwetsbaarheid wanneer inloggegevens worden gecompromitteerd. Trust opbouwen vanaf het begin is consistent goedkoper dan het later opnieuw uitrusten.

Trust omvat vier architectonische dimensies die samenhangend samenwerken:

• Beveiligingselementen beschermen systemen en gegevens
• Identiteitsbeheer bepaalt toegang
• Privacypraktijken respecteren gebruikersorganisatie
• Nalevingskaders voldoen aan wettelijke verplichtingen

Architecten die voor alle vier dimensies ontwerpen, creëren oplossingen die Trust verdienen en behouden door transparantie, controle en veerkracht.

In het Agentic Era strekt Trust zich uit tot de vertrouwde context waarin agenten opereren. Vertrouwde context betekent dat agenten toegang hebben tot beheerde, geverifieerde gegevens met duidelijke identiteits- en machtigingsgrenzen, waardoor AI-systemen kunnen redeneren en handelen namens gebruikers, terwijl tegelijkertijd de beveiliging, controleerbaarheid en naleving behouden blijven. Het ontwerpen van vertrouwde context is essentieel voor de architectuur van Agentic Enterprise.

Deze pijler bepaalt de baseline van de platformbeveiliging waarvan elke Salesforce-oplossing afhankelijk is. De pijler Agentic Trust bouwt voort op die baseline om risico's aan te pakken die uniek zijn voor autonome agenten, inclusief prompt injection, action governance en de gegevens waartoe agenten toegang hebben tijdens redeneertijden. Het is belangrijk dat u eerst de baseline ontwerpt en vervolgens agentspecifieke besturingselementen in lagen aanbrengt met behulp van de richtlijnen van Agentic Trust.

Deze pijler sluit nauw aan bij andere kaderkwesties.

• Betrouwbaarheid is afhankelijk van infrastructuur die bestand is tegen aanvallen en herstelt van inbreuken.
• Operational Excellence vereist veilige implementatiepijplijnen en incidentresponsmogelijkheden.
• Eerlijkheid vereist een transparante, ethische omgang met gegevens en algoritmische beslissingen.

Samen vormen deze pijlers een uniforme, oplossingsgerichte aanpak die organisaties kunnen Trusten met hun meest gevoelige activiteiten.

In het Shared Responsibility Model moeten Salesforce en architecten hun respectieve verantwoordelijkheden vervullen om Trust te behouden. Laten we eens beter kijken naar wat elke kant moet beveiligen.

Salesforce is verantwoordelijk voor de beveiliging van het platform en de wereldwijde infrastructuur, waaronder:

• Toegangscontroles, bewaking en milieubescherming voor datacenters
• Voor Hyperforce handelt de onderliggende cloudleverancier (bijvoorbeeld AWS, Azure of Google Cloud, afhankelijk van het exemplaar) fysieke beveiliging van datacenters af via gedelegeerde verantwoordelijkheid. De Salesforce Infrastructuur en subprocessors-documentatie identificeert de aanbieder en subprocessors voor elke service.

• Besturingselementen voor beveiliging op netwerklagen, inclusief DDoS-bescherming en dreigingsdetectie
• Verkeersencryptie onderweg (TLS 1.2+) en in ruste (doorgaans AES-256)

• Kwetsbaarheidsrespons en implementatie van platformpatch via Salesforce (ga voor meer informatie over beveiligingsadviezen naar security.salesforce.com)
• Beheer van beveiliging van besturingssysteem en infrastructuur

• Certificaten en attesten: Salesforce onderhoudt SOC 1/2/3, ISO 27001/27017/27018, FedRAMP-autorisatie (bereikt tot Government Cloud Plus en MuleSoft Government Cloud, niet het commerciële platform voor meerdere belanghebbenden) en validatie van PCI DSS Level 1.
• Ondersteuning van regelgeving: Dit is van toepassing op services die in aanmerking komen voor HIPAA met Business Associate Agreements (BAA's) of nalevingsprogramma's van de AVG.
• Ga voor meer informatie naar Trust.salesforce.com en compliance.salesforce.com.

• Architectuur voor huurdersisolatie: Een gedeelde, metagegevensgestuurde kernel partitioneert de gegevens en metagegevens van elke organisatie op organisatie-ID, waardoor de ene organisatie de records van een andere organisatie niet kan bereiken, zelfs niet als ze beide op een gedeelde infrastructuur draaien. De kernel dwingt scheiding af voor elke query, niet via een configuratie die u moet onderhouden.
• Encryptie op infrastructuurniveau at rest en back-upinfrastructuur: Basisplatformlicenties omvatten Classic Encryption (AES-128 biedt alleen aangepaste tekstvelden). Shield Platform Encryption vereist een afzonderlijke licentie (met AES-256 kunt u uw eigen sleutel meenemen en standaard- en aangepaste velden, bestanden en bijlagen bieden).

Deze controles zorgen ervoor dat het platform veilig, betrouwbaar en conform blijft.

U bent verantwoordelijk voor het beveiligen van uw gegevens, configuraties en operationele processen.

• Identiteit en bundeling: Voor Single Sign-On (SSO) en multi-factorenauthenticatie (MFA) moet u de identiteit van de gebruiker verifiëren.
• Toegangsbeperking: Technisch gezien beperken IP-bereiken en inloguren de manier waarop en wanneer identiteiten verbinding maken.
• Beginsel van minste rechten (PoLP): Gebruik de PoLP om alleen toegang te verlenen voor rollen, profielen en machtigingensets die nodig zijn voor het uitvoeren van afzonderlijke taken.
• Levenscyclusbeheer: Oefen levenscyclusbeheer voor gebruikers en krijg toegang tot richtlijnen voor hercertificering.

• Gegevensclassificatie, maskeren en beveiliging op object-/veld-/recordniveau gebruiken
• CRUD-machtigingen en regels voor delen afdwingen
• Bezit, test en implementeer een beproefde strategie om de gegevens van uw organisatie te herstellen, zodat gegevensverlies of herstel van corruptie binnen uw controle blijft.

• Gebruik API-authenticatie (bijvoorbeeld OAuth 2.0 of JWT) en benoemde inloggegevens.
• Schakel speciale integratiegebruikers met PoLP-machtigingensets in zodat de toegang van elke integratie wordt beperkt en afzonderlijk kan worden gecontroleerd door menselijke gebruikers.
• Beveiligde eindpunten en externe systeemvalidatie.

• Gebruik Event Monitoring, controletrajecten en integratie van Security Information and Event Management (SIEM).
• Volg incidentresponsprocedures en beveiligingsbeoordelingen.

• Gebruik veilige aangepaste code (bijvoorbeeld Apex of Lightning) en invoervalidatie.
• Voer Apex in de gebruikersmodus uit zodat object-, veld- en deelmachtigingen in code worden afgedwongen.
• Volg injectiepreventie en veilige ontwikkelingspraktijken.

• Handhaaf de nalevingspositie van oplossingen.
• Volg het beleid voor privacy-/instemmingsbeheer en gegevensbewaring.

Sommige verantwoordelijkheden vereisen samenwerking:

• Respons op beveiligingsincidenten: Beide partijen nemen deel aan detectie- en reactieactiviteiten.
• Kwetsbaarheidsbeheer: Salesforce patcht het platform, architecten patchen aangepaste code.
• Beveiligingscontrole: Combineer door platforms gegenereerde beveiligingssignalen met een architectenanalyse.
• Nalevingscertificeringen: Salesforce certificeert het platform (bijvoorbeeld SOC, ISO en FedRAMP voor Government Cloud); architecten zijn eigenaar van wat erop is gebaseerd (aangepaste objecten, code, integraties en configuratie) binnen de gecertificeerde status om aan te tonen dat audits worden uitgevoerd.
• Identiteitsbundeling: Salesforce vertrouwt de definities die de architect-identiteitsleverancier uitgeeft; architecten blijven de aanbieder en de Trust relatie tussen de aanbieder en Salesforce beveiligen.
• Sleutelbeheer: Met behulp van Bring-your-own-Key-encryptie beheert Salesforce de encryptieservice terwijl architecten het sleutelmateriaal genereren, roteren en intrekken dat de gegevens beschermt.

Elk ontwerpprincipe, onderwerpsectie en controlelijstitem in dit document vertegenwoordigt uw verantwoordelijkheid als architect. Het model Gedeelde verantwoordelijkheid omlijst wat u moet ontwerpen en configureren om Trust op het Salesforce-platform te verkrijgen.

De grens strekt zich uit tot wettelijke verplichtingen. Salesforce onderhoudt de certificeringen en attesten van het platform en beveiligt de infrastructuur tegen inbreuken. Architecten zijn verantwoordelijk voor de verplichtingen die zijn verbonden aan uw gegevens en jurisdictie (bijvoorbeeld: welke wetgeving van toepassing is, hoe gegevens worden geclassificeerd, welke bewaar- en instemmingsregels van toepassing zijn, en hoe u inbreuken op de gegevens onder uw controle detecteert en meldt). Architecten moeten de specifieke cijfers achter die verplichtingen (zoals bewaartermijnen en termijnen voor kennisgevingen) vergelijken met de regelgeving voor uw implementatie, omdat deze per rechtsgebied kunnen verschillen en in de loop van de tijd kunnen veranderen.

Gebruik deze principes als leidraad voor uw architectonische beslissingen voor beveiliging op het platform.

• Nul Trust toepassen op alle lagen. Trust nooit op basis van netwerklocatie, gebruikersbekendheid of systeemherkomst. Controleer elk toegangsverzoek expliciet met authenticatie, autorisatie en encryptie op de gegevens-, toepassings-, integratie- en infrastructuurlagen. Architectuur voor meerdere belanghebbenden betekent dat u infrastructuur deelt met duizenden organisaties, waardoor het netwerk waarop uw oplossing wordt uitgevoerd, geen perimeter is die u als vertrouwd kunt beschouwen. Controleer elk verzoek op zijn eigen merites—identiteit, autorisatie en context—in plaats van erop te vertrouwen waar het vandaan komt.
• Standaard de minste rechten verlenen. Verleen het minimale toegangsniveau dat nodig is voor elke gebruiker, integratie en geautomatiseerd proces om het doel ervan te bereiken. Begin met de meest beperkende instellingen—Privé standaardinstellingen voor de hele organisatie (OWD's) en minimale machtigingen—en breid bewust uit op basis van gedocumenteerde bedrijfsvereisten. Gebruik het toegangsmodel met vier lagen (organisatie → object → veld → record) zodat elke laag de lagen erboven verder beperkt.
• Verdediging in diepte. Laag meerdere beveiligingsbesturingselementen zodat het mislukken van één besturingselement niet het hele systeem in gevaar brengt. Combineer preventieve besturingselementen (bijvoorbeeld CRUD/FLS-afdwinging en transactiebeveiligingsbeleid dat bewerkingen blokkeert), detectivebesturingselementen (bijvoorbeeld Event Monitoring) en responsieve besturingselementen (bijvoorbeeld stapsgewijze authenticatie en kennisgeving van transactiebeveiliging). Ontwerp elke laag alsof de aangrenzende lagen kunnen mislukken. Vergeet niet dat beveiliging op veldniveau gegevens beschermt, zelfs wanneer regels voor delen te tolerant zijn.
• Integreer beveiliging door ontwerp. Integreer bedreigingsmodellering, beveiligingsvereisten en validatie van besturingselementen in elke architectuurfase, vanaf het eerste concept tot en met de voortdurende evolutie. Voer het modelleren van spoofing, knoeierij, afwijzing, openbaarmaking van informatie, Denial of Service en Eleving of Privilege (STRIDE) uit voordat het samenstellen begint. Beveiliging bepaalt technologieselectie en ontwerpbeslissingen.
• Beveiliging inbedden in automatisering. Bouw beveiligingselementen in geautomatiseerde pijplijnen, configuratiesjablonen en platformstandaards in. Salesforce Code Analyzer in CI/CD signaleert kwetsbaarheden vóór implementatie. Configuratie-als-code dwingt beveiligingsbaselines af. Ingebedde beveiliging zorgt voor consistentie en maakt het mogelijk om de beveiliging mee te laten schalen met de complexiteit van oplossingen.
• Ontwerp voor privacy. Neem privacyprincipes op vanaf de eerste architectuurfase. Ontwerp voor gegevensminimalisering (alleen noodzakelijke gegevens verzamelen), doelbeperking (toegang beperken op functie), instemmingsbeheer (granulaire, doelspecifieke instemming afdwingen) en rechten van betrokkenen (toegang, rectificatie, verwijdering en overdraagbaarheid van werkstromen inschakelen voor voltooiing binnen wettelijke tijdlijnen).
• Ontwerp voor traceerbaarheid. Maak elke gevolgactie achteraf toewijsbaar en reconstrueerbaar, voordat u vertrouwt op het detecteren van anomalieën erin. Zorg ervoor dat wijzigingen in gegevens, machtigingen en configuratie worden vastgelegd in controletrajecten, veldhistorie en eventlogboeken, en bewaar die records in een manipulatiebestendige opslag. Traceerbaarheid is de randvoorwaarde voor detectie, forensisch onderzoek en verantwoording. Vergeet niet dat u niet kunt onderzoeken wat nooit is vastgelegd.
• Ontwerp voor incidentrespons. Ontwerp voor detecteerbaarheid via Event Monitoring en voor realtime interventie via transactiebeveiligingsbeleid. Schakel snelle reactie in via gedocumenteerde procedures en isolatiegrenzen. Ondersteun herstel via back-upmogelijkheden en forensisch behoud. Test responsen door middel van oefeningen op tafel en inbreuksimulaties.

Architecten zijn verantwoordelijk voor het beveiligen van oplossingen op het platform dat Salesforce biedt.

De werkbelastingen die interactie hebben met Salesforce, worden steeds vaker buiten het kernplatform uitgevoerd: integratieservices, aangepaste toepassingen en headless clients roepen vaak Salesforce-API's aan, vaak namens een gebruiker. Om dit patroon te versnellen maakt Salesforce de mogelijkheden van het platform zichtbaar als API's, tools en opdrachten (bijvoorbeeld Salesforce Headless 360). Ongeacht wie deze toepassingen exploiteert, de architect is eigenaar van de Trust grens waar ze Salesforce ontmoeten om te bepalen hoe ze authenticeren, welke identiteit en machtigingen ze dragen, welke geheimen ze hebben en welke gegevens de grens overschrijden.

De onderstaande principes zijn van toepassing op elk containerintegratieplatform (bijvoorbeeld MuleSoft CloudHub).

Wanneer een externe client wordt geauthenticeerd als een benoemde gebruiker, wordt het platformbeveiligingsmodel van Salesforce automatisch toegepast. Objectmachtigingen, beveiliging op veldniveau en regels voor delen worden precies zo afgedwongen als in de browser. Authenticatie per gebruiker heeft betrekking op elke aanroep naar de machtigingen van dat individu en behoudt het controletraject, wat betekent dat het intrekken van het token van een gebruiker onmiddellijk de mogelijkheid van de client verwijdert om namens die persoon op te treden. Geef hier de voorkeur aan boven een gedeelde serviceaccount waar het werk voor een specifieke gebruiker wordt uitgevoerd.

Ontwerp de grens defensief, want een client die tokens voor veel gebruikers vasthoudt, concentreert Trust en wordt een waardevolle proxy voor een aanvaller: één gestolen OAuth-token kan gegevens bereiken voor elke gebruiker die de client bedient. Dit is niet hypothetisch. Bij het Salesloft Drift-incident van 2025 stalen aanvallers OAuth-tokens en gebruikten ze deze om Salesforce-gegevens te bereiken binnen honderden organisaties.

• Gebruikersidentiteit propageren, niet samenvoegen. Gebruik authenticatie per gebruiker of OAuth 2.0-tokenuitwisseling om de identiteit van een gebruiker over te dragen tussen servicehops (zie Agentic Identity and Authentication), zodat compromissen worden beperkt tot de context van één gebruiker in plaats van alle.
• Behandel OAuth-clientinloggegevens en vernieuwingstokens als het primaire doel. Sla ze op in een opslagplaats voor beheerde geheimen, roteer ze regelmatig en onderhoud ontwerpen voor onmiddellijke intrekking. Controleer API-gebruik op de abnormale patronen die een proxyaanvaller signaleren.
• Minimaliseer het bereik aan beide zijden. Beperk de OAuth-bereiken (ECA) van de External Client App en de Salesforce-machtigingen van de integratiegebruiker tot het minimum dat de functie vereist, zodat een gecompromitteerde client niet kan draaien naar niet-gerelateerde gegevens.
• Bepaal de grens via Externe clientapps. ECA's definiëren hoe een externe toepassing authenticeert, welke stromen zijn toegestaan en welke bereiken van toepassing zijn—ontwerp nieuwe integraties op basis hiervan (zie Authenticatiearchitectuur).

Wees voorzichtig wanneer een client wordt uitgevoerd als agentgebruiker of integratiegebruiker: die identiteiten kunnen in een verhoogde context werken—vaak tegen externe systemen die de toegangscontroles van Salesforce niet respecteren—dus het gebruik van de machtigingen- en bewakingsdiscipline zoals hierboven beschreven, houdt die macht gebonden.

Wanneer integraties worden uitgevoerd op een platform in containers, wordt isolatie op containerniveau op zichzelf beschouwd als een beveiligingsregeling: elke toepassing wordt uitgevoerd in een speciale container zonder gedeelde run-time of geheugen tussen toepassingen.

Deze isolatie biedt:

• Tenant grensafdwinging: Gecompromitteerde toepassingen hebben geen toegang tot gegevens of resources van naburige toepassingen die dezelfde omgeving delen. Elke container heeft een geïsoleerd bestandssysteem en procesruimte. Dwing netwerkisolatie af door middel van firewall- en TLS-configuratie en beperk expliciet uitgaand verkeer in plaats van te vertrouwen op toegestane standaardinstellingen.
• Grondige verdediging: Containerisolatie voegt een beveiligingslaag toe die verder gaat dan de besturingselementen op toepassingsniveau. Zelfs als de toepassingscode kwetsbaarheden heeft, beperken containergrenzen de straal van de ontploffing.
• Segmentering naleving: Gereguleerde werkbelastingen (bijvoorbeeld PCI en HIPAA) kunnen worden geïsoleerd in speciale containers, waardoor vermenging met niet-conforme werkbelastingen wordt voorkomen.

Architecten die omgevingen voor meerdere toepassingen ontwerpen, moeten vertrouwen op containerisolatie om scheiding van taken en beveiligingsdomeinen af te dwingen. Integraties van financiële services die kaarthoudergegevens verwerken, moeten worden uitgevoerd in afzonderlijke containers van marketingintegraties, zelfs binnen dezelfde omgeving.

Het verkeer tussen containers moet worden versleuteld en wederzijdse TLS (mTLS) moet worden toegepast wanneer een regelgevingskader authenticatie aan beide zijden vereist:

Hoe het werkt:

• Configureer TLS-contexten om desgewenst wederzijdse TLS (mTLS) in te schakelen voor inkomende verbindingen.
• Gebruik SSL op platformniveau met client-certificaatauthenticatie om de communicatie tussen platformservices en replica's te beveiligen.
• Configureer TLS-contexten om mTLS in te schakelen wanneer vereist door regelgevingskaders.
• Beheer certificaten via de certificatenopslag van het platform zodat levenscyclus en intrekking gecentraliseerd blijven.
• Dwing netwerkisolatiegrenzen af die ongeoorloofd verkeer tussen containers voorkomen.

Het versleutelen van verkeer op de platformlaag biedt diepgaande verdediging voor gegevens-in-transit. Zelfs als de HTTPS op de toepassingslaag verkeerd is geconfigureerd, blijft het containerverkeer versleuteld.

Containers die verbinding maken met on-premises systemen via VPN moeten een architect zijn voor gegevensbescherming tijdens transport:

• Tunnelencryptie: Routeer al het verkeer tussen containers en on-premises systemen door versleutelde VPN-tunnels. Dit geldt ongeacht de TLS van de toepassingslaag. Diepgaande verdediging zorgt voor dubbele encryptie voor gevoelige gegevens.
• Afdwingen van netwerksegmentering: VPN-tunnelbeleidsvormen beperken welke on-premises netwerken containers kunnen bereiken. Gecompromitteerde containers kunnen niet draaien naar ongeautoriseerde interne systemen buiten VPN-toegestane netwerken.
• Nalevingsbewijs: VPN-encryptie is een van de geaccepteerde mechanismen voor het beschermen van gegevens-in-transit naar en van cloudomgevingen. Accountants die HIPAA-, PCI-DSS- of SOX- controles beoordelen, verwachten gedocumenteerde encryptie onderweg voor hybride integraties.

Architecten moeten VPN-beleidsvormen ontwerpen die netwerktoegang met de minste rechten afdwingen. Marketingintegratiecontainers mogen niet naar interne financiële systemen worden gerouteerd, zelfs niet als beide bereikbaar zijn via VPN.

Vanity domeinen (bijvoorbeeld aangepaste URL's voor integratie-API's) vereisen dat architecten TLS-certificaten beheren als Trust anchors:

Vanity-domeinen (bijvoorbeeld aangepaste URL's voor integratie-API's) vereisen dat architecten TLS-certificaten beheren als Trust Ankers.

• Certificaatlevenscyclusautomatisering: Implementeer geautomatiseerde certificaatverlenging en implementatie. Verlopen certificaten verstoren integration Trust; clients weigeren verbindingen met certificaatvalidatiefouten.
• Planning van intrekking van certificaten: Ontwerp roulatieprocedures voor certificaten voor beveiligingsincidenten. Gecompromitteerde privésleutels vereisen een snelle heruitgifte van certificaten en implementatie in alle regio's.
• Cipher suite-configuratie: Oudere TLS-configuraties (TLS 1.0/1.1 en zwakke versleutelingen) mislukken nalevingscontroles. Dwing TLS 1.2+ (minimumvereiste) af en stem certificaat- en clientconfiguraties af op het beveiligingsbeleid van de organisatie.
• Vastleggen van transparantie van certificaten: Moderne TLS-certificaten worden door certificeringsinstanties ingediend bij openbare CT-logboeken (Certificate Transparency). Elk CT-logboek retourneert een ondertekend certificaattijdstempel (SCT), een cryptografisch bewijs van vastleggen, dat de CA in het certificaat inbedt via een X.509v3-extensie. Architecten moeten CT-logboeken controleren op ongeoorloofde certificaatuitgifte voor hun domeinen, met behulp van services zoals crt.sh of geautomatiseerde waarschuwingen.

Wanbeheer van certificaten heeft rechtstreeks invloed op Trust:

• Verlopen certificaten: Veroorzaak authenticatiefouten die worden weergegeven als uitval. Bewaking moet het verzenden van waarschuwingen binnen 30+ dagen vóór het verlopen omvatten om verlengingswerkstromen te laten starten.
• Certificaten met eigen ondertekening: Verbreek Trust chains voor externe clients. Productie-integraties vereisen certificaten die zijn ondertekend door vertrouwde certificeringsinstanties.
• Wildcardcertificaatuitbreiding: Verwijst naar te brede jokertekencertificaten (bijvoorbeeld *.company.com) die een grote straal creëren als ze worden gecompromitteerd. Certificaten met een smal bereik hebben de voorkeur per integratiedomein.

Containerimplementatieregio's moeten voldoen aan de vereisten voor gegevensverblijf en naleving.

• Gegevensverblijfplaats van AVG: De AVG vereist adequate bescherming voor persoonsgegevens die de Europese Unie (EU) verlaten, maar niet de EU-implementatie als zodanig. Het implementeren van integraties in een EU-regio houdt containerberekening en gegevensverwerking binnen de wettelijke grenzen, wat de meest directe manier is om aan deze vereiste te voldoen. Overdrachten buiten de EU blijven toegestaan op grond van een adequaatheidsbesluit, standaardcontractbepalingen of bindende bedrijfsregels.
• Gegevenslokalisatiewetgeving: Landen met vereisten voor gegevenslokalisatie omvatten: Rusland (federale wet 152-FZ en verplichte opslag) en China (PIPL/CSL voor CIIO's), waarvoor mogelijk containerimplementatie in het land vereist is. De Indiase DP Act van 2023 gebruikt een zwarte-lijstbenadering die geen algemeen opslagmandaat voor het land oplegt. Gegevensoverdrachten zijn toegestaan naar elk land, tenzij specifiek beperkt door een kennisgeving van de overheid. Architecten moeten inzicht hebben in jurisdictiespecifieke regelgeving.
• Mechanismen voor grensoverschrijdende gegevensoverdracht: Wanneer een multiregionale implementatie vereist is, maar de gegevens grensoverschrijdend moeten zijn, moeten architecten VCA's, BHG's of andere juridische overdrachtsmechanismen implementeren.
• Uitlijning van nalevingscertificering: Containerimplementatieregio's moeten overeenkomen met Salesforce-nalevingscertificeringen. Door FedRAMP geautoriseerde werkbelastingen vereisen implementatie in de VS. Voor door HITRUST gecertificeerde integraties moet u controleren of de implementatieregio binnen een actief bereik van het HITRUST-attest valt.

Regionale implementatiebeslissingen zijn architectenverantwoordelijkheden die rechtstreeks van invloed zijn op naleving van regelgeving. Financiële teams kunnen implementatie voor alleen de VS verplicht stellen voor door SOX gecontroleerde integraties. Gezondheidszorgteams kunnen door HITRUST gecertificeerde regio's vereisen voor het verwerken van persoonlijke gezondheidsgegevens (PHI).

Containers vereisen toegang tot inloggegevens, API-sleutels en encryptiesleutels. Architecten moeten beheerprocessen voor geheimen ontwerpen die blootstelling voorkomen:

• Geen hardcoded geheimen: Bed nooit inloggegevens in toepassingscode of configuratiebestanden in die zijn geïmplementeerd in containers. Gebruik door platform beheerde secrets stores.
• Door platform beheerde geheime injectie: Los geheimen op tijdens run-time vanuit de beheerde store van het platform (in plaats van ze te bewaren in het bestandssysteem) en markeer configuratiewaarden met inloggegevens als beschermd, zodat ze niet zichtbaar worden in logboeken of op de console.
• Roulatie van geheimen: Ontwerp integraties om geroteerde geheimen elegant af te handelen. OAuth-tokenvernieuwingspatronen, API-sleutelrotatiewerkstromen en wijzigingen in databasewachtwoorden mogen geen herimplementatie van containers vereisen.
• Toegang tot geheimen met de minste rechten: Verleen containers alleen toegang tot de geheimen die nodig zijn voor hun functie. Marketingintegraties mogen geen toegang krijgen tot inloggegevens van financiële systemen, zelfs niet als ze dezelfde omgeving delen.

Geopenbaarde geheimen zijn veelvoorkomende integratiebeveiligingsincidenten. Architecten moeten geheimen ontwerpen die codebeoordelingen, logboeken, foutberichten en bewakingsdashboards kunnen overleven zonder inloggegevens te lekken.

Toepassingen aan de Salesforce-grens genereren auditevents die voldoen aan de vereisten voor het vastleggen van naleving:

• Vastleggen van verzoeken/reacties: Legt API-verzoeken, responsen en routeringsbeslissingen vast. Nalevingsteams gebruiken deze logboeken voor toegangsaudits om te bepalen wie op welk moment toegang heeft gekregen tot welke gegevens.
• Vastleggen van fouten en uitzonderingen: Legt beveiligingsevents (bijvoorbeeld authenticatiefouten, autorisatieweigeringen en ongeldige certificaten) vast in de logboeken van de container. SIEM-integratie maakt realtime beveiligingsbewaking mogelijk.
• Beleidsvormen voor logboekbewaring: Architecten moeten bewaarperioden configureren die voldoen aan wettelijke vereisten. Deze minimumwaarden worden vastgesteld door regelgeving, verschillen per raamwerk en veranderen in de loop van de tijd, waardoor ze moeten worden afgeleid van een goed onderhouden nalevingsbron die elk cijfer verifieert aan de hand van de regelgeving in plaats van hardcoding-waarden.
• Logboekencryptie en toegangscontroles: Auditlogboeken kunnen gevoelige metagegevens bevatten. Logboeken moeten in ruste worden versleuteld en alleen toegankelijk zijn voor bevoegd beveiligings-/nalevingspersoneel. Onvoldoende vastlegging voorkomt incidentonderzoek en mislukt nalevingscontroles. Architecten moeten een afweging maken tussen de omvang van het vastleggen (bijvoorbeeld gevolgen voor prestaties en opslagkosten) en de behoeften aan nalevings- en beveiligingsonderzoek.

Dreigingsmodellering moet onderdeel zijn van het ontwerpen van uw oplossingen, in plaats van een afzonderlijke stap ervoor of erna. Zodra u een kandidaat-ontwerp hebt om over te redeneren, moet u de potentiële bedreigingen ervan modelleren—en het model opnieuw bekijken naarmate het ontwerp zich ontwikkelt, zodat beveiliging de architectuur vormgeeft in plaats van er later op terug te keren. Hoewel Salesforce de beveiliging van de infrastructuur beheert (bijvoorbeeld netwerkbescherming, OS-harding en kwetsbaarheidsbeheer), moet u risico's op toepassingslagen identificeren in uw configuratie, integraties en aangepaste code. Pas het STRIDE-framework (spoofing, sabotage, afwijzing, openbaarmaking van informatie, Denial of Service, verhoging van privileges) toe op de Salesforce-specifieke bedreigingsvectoren die hieronder worden vermeld. Identificeer Trust grenzen waar gegevens systemen, netwerken of machtigingsniveaus overschrijden.

Pas het STRIDE-framework toe op deze Salesforce-specifieke overwegingen bij het modelleren van bedreigingen:

• Gegevensstromen voor meerdere organisaties creëren extra Trust grenzen die expliciete authenticatie en autorisatie vereisen bij elke kruising.
• Externe integraties maken gebruik van API's en middleware, waardoor mogelijk aanvalsvectoren worden geïntroduceerd die platformbeveiligingselementen omzeilen.
• Aangepaste Apex en Lightning componenten vereisen veilige coderingsanalyse voor injectie, XSS en afdwingen van toegangscontrole.
• Experience Cloud-sites breiden het aanvalsoppervlak uit naar niet-geauthenticeerde of licht geauthenticeerde gebruikers.
• Externe en ISV-code (bijvoorbeeld beheerde pakketten, AgentExchange-vermeldingen, verbonden apps, externe connectoren, JavaScript-bibliotheken aan clientzijde en de externe AI-services die uw agenten aanroepen) is een supply chain vector die uw Trust grens overschrijdt, tijdens de installatie of tijdens run-time.

Externe en ISV-code is onderdeel van uw Trust grens.

Beheerde pakketten of AgentExchange-vermeldingen worden binnen uw organisatie uitgevoerd met de machtigingen die u ze verleent, waardoor hun beveiligingsstatus uw beveiligingsstatus wordt op het moment dat u ze installeert. Salesforce Security Review controleert elk vermeld pakket voordat het AppExchange of AgentExchange bereikt; u bent eigenaar van alles na die poort:

• Het pakket beoordelen op basis van uw eigen gegevensclassificatie en risicopositie
• Het verlenen van de minste hoeveelheid rechten die de gedocumenteerde functionaliteit ervan vereist
• Actueel houden met de releases van de uitgever
• En de activiteit ervan bewaken via dezelfde Event Monitoring- en auditbesturingselementen die u toepast op uw eigen code.

Pas beveiligingselementen toe op elke laag van de oplossingsstapel. Houd er rekening mee dat compromissen van één laag niet het hele systeem zichtbaar mogen maken.

Ontwerp elke laag alsof de lagen erboven en eronder kunnen mislukken. Vergeet niet dat meerdere onafhankelijke besturingselementen veerkracht creëren.

Zero Trust elimineert impliciete Trust op basis van netwerkpositie of voorafgaande authenticatiestatus. Elk verzoek moet onafhankelijk worden geauthenticeerd en geautoriseerd.

Pas zero Trust toe op:

• Gebruikerstoegang via continue verificatie met MFA, sessiebeleid en voorwaardelijke toegang op basis van context (bijvoorbeeld IP, apparaat, tijd en gedrag)
• Integratieverbindingen door middel van OAuth-tokenvalidatie voor elke aanroep, op certificaten gebaseerde wederzijdse TLS en IP-whitelisting
• Intersysteemcommunicatie via expliciete authenticatie, wat ook geldt voor vertrouwde interne systemen
• Gegevenstoegang door middel van CRUD- en FLS-afdwinging voor elke query en bewerking, ongeacht de aanroepcontext

Voorraad beveiligingsactiva is een invoer voor beveiligingsontwerp: u kunt alleen een bedreigingsmodel maken, de minste rechten toepassen op en een aanvalsoppervlak bewaken dat u eerst hebt genummerd, waardoor het bijhouden van uw beveiligingsrelevante activa bij de ontwerpbeslissingen hoort die ervan afhankelijk zijn. Dit verschilt van het operationele configuratiebeheer dat Operational Excellence bestrijkt (bijvoorbeeld het versiebeheer van organisatie-instellingen en het detecteren van configuratieafwijkingen voor operationele stabiliteit). Met andere woorden, de zorg is hier beperkter: welke activa brengen beveiligingsrisico's met zich mee, en waarom?

Houd een actuele voorraad bij van alle beveiligingsrelevante activa, inclusief aangepaste objecten die gevoelige gegevens opslaan, externe systeemintegraties, openbare API's, bevoorrechte accounts, productietoegangsverleningen en geïnstalleerde pakketten met verhoogde machtigingen.

Uw voorraad van beveiligingsactiva moet het volgende omvatten:

• Aangepaste objecten en velden met vertrouwelijke of beperkte gegevens
• Integratie-eindpunten en authenticatiemechanismen
• Gebruikers met verhoogde machtigingen (bijvoorbeeld Alle gegevens wijzigen, Alle gegevens weergeven en Gebruikers beheren)
• API-only integratiegebruikers en hun machtigingenbereiken
• Externe clientapps (ECA) en hun OAuth-bereiken, samen met alle oudere verbonden apps die nog steeds aanwezig zijn in de organisatie
• Geïnstalleerde AgentExchange-pakketten en hun machtigingsverlening
• Experience Cloud-sites en hun modellen voor authenticatie en extern delen
• Aangepaste Apex klassen met verhoogde modi voor delen
• Let met name op oudere klassen: code die is gecompileerd in API-versie 66.0 of lager en die een verklaring voor delen weglaat, wordt standaard "zonder delen" (bijvoorbeeld systeemmodus, waarbij de recordtoegang van de huidige gebruiker wordt omzeild). Houd er rekening mee dat vanaf API-versie 67.0 (Summer '26) een weggelaten declaratie standaard "met delen" wordt en dat databasebewerkingen worden uitgevoerd in de gebruikersmodus. Bestaande klassen behouden echter de oude werking totdat ze opnieuw worden gecompileerd op v67.0 (of later)—dus niet-gedeclareerde klassen die zijn overgedragen vanuit eerdere versies, blijven stilzwijgend verhoogd.

Het is uw verantwoordelijkheid om identiteitselementen te ontwerpen en configureren die de minste rechten afdwingen.

Laten we eens beter kijken naar de manier waarop u besturingselementen op de juiste manier ontwerpt en configureert met behulp van de PoLP.

Salesforce dwingt toegangscontrole af via vier afzonderlijke lagen: organisatie, object, veld en record. U moet bewust oplossingen ontwerpen die alle vier de lagen benutten. Controle over kerntoegang is gebaseerd op toekenning, wat inhoudt dat toegang additief is en dat gebruikers deze toegang op elke laag moeten hebben om een record te bereiken. Er is geen algemene regel voor het toestaan van overschrijvingen weigeren in het kernplatform, dus u kunt niet vertrouwen op een gerichte weigering om toegang tot een brede subsidie die al is verleend, ongedaan te maken.

Het beperken van toelaatbare hogere lagen kost u niet, maar verhoogt wel de inspanning: het in een vroeg stadium uitbreiden van standaardinstellingen voor de hele organisatie of objectmachtigingen betekent vertrouwen op beveiliging op veldniveau en configuratie voor delen om toegang terug te vorderen die nooit had mogen worden verleend.

Beperkingsregels en machtigingen voor negeren zijn twee ingebouwde uitzonderingen die toegang aftrekken, maar die elk een beperkt bereik hebben—beperkingsregels voor filteren op recordniveau en negeren voor machtigingen die zijn verleend binnen een groep machtigingensets—geen gegeneraliseerde laag voor weigeren.

Stel OWD's in op Privé voor objecten die gevoelige gegevens bevatten. Het openen van OWD's voor Openbaar alleen-lezen—laat staan Openbaar lezen/schrijven—maakt records breed zichtbaar en tast uw vermogen aan om toegang later te beperken zonder potentieel significante herarchitectuur. De meest voorkomende Trust debt in volwassen organisaties komt voort uit tolerante OWD's die zijn ingesteld tijdens de initiële implementatie.

De recordlaag volgt een model voor toekennen/vervolgens beperken, vaak afgebeeld als een piramide voor delen: OWD's stellen de beperkende baseline en rollenhiërarchie, regels voor delen en handmatig delen open toegang naar boven in. Twee besturingselementen keren die stroom om om toegang weg te nemen in plaats van te verlenen, en beide zijn het waard om er bewust in te ontwerpen.

• Beperkingsregels filteren wat gebruikers kunnen zien binnen records waartoe ze al toegang hebben, waardoor gebruikers met brede objecttoegang nog steeds alleen de subset zien die een regel toestaat.
• Machtigingen voor negeren trekken specifieke machtigingen binnen een groep machtigingensets af, zodat u toegang kunt samenstellen vanuit herbruikbare groepen en vervolgens kunt verwijderen wat een bepaalde populatie niet zou moeten hebben.
• Kies deze regels wanneer alleen op subsidie gebaseerde lagen u zouden dwingen om te veel te bieden of om toegang te fragmenteren in vele smalle machtigingensets.

Dwing MFA (multi-factorenauthenticatie) af voor alle gebruikers die inloggen bij productieomgevingen via de gebruikersinterface, die Salesforce verplicht als platformvereiste. Deze vereiste geldt niet voor API-only toegang: integraties met behulp van JWT-bearer- of clientinloggegevensstromen zijn vrijgesteld, waardoor u die integraties in plaats daarvan moet beschermen met certificaatbeheer en IP-beperkingen. Breid MFA-vereisten uit naar bevoorrechte bewerkingen.

Voor SSO (Single Sign-On) hebben SAML 2.0- of OpenID Connect-protocollen de voorkeur. Sessiebeleid configureren om beveiliging en bruikbaarheid in evenwicht te brengen:

• Sessietime-out: Configureer sessietime-outs die zijn afgestemd op gebruikersmachtigingenniveaus (kortere time-outs voor accounts met hoge machtigingen verminderen de risico's van onbeheerde sessies).
• IP-beperkingen: Dwing beperkingen af voor administratieve profielen en integratiegebruikers.
• Inloguren: Beperk serviceaccounts tot verwachte operationele perioden.
• Apparaatactivering: Vertrouw op de native apparaatactivering van Salesforce (identiteitsverificatie voor inloggen vanaf niet-herkende apparaten) en voeg MFA- en IP-beperkingen toe voor accounts met hoge machtigingen. Native device Trust status wordt afgedwongen via een externe identiteitsleverancier.
• Sessie-IP-vergrendeling: Vergrendel sessies op het IP-adres waaruit ze afkomstig zijn, zodat een gestolen sessie-ID niet opnieuw kan worden afgespeeld vanaf een andere netwerklocatie. Dit verscherpt de beveiliging, maar voegt frictie toe voor mobiele gebruikers en kan geautomatiseerde integraties verstoren. Wanneer vergrendeling niet haalbaar is, dwingt u Strikte inlog-IP-bereiken af op profielniveau met "Inlog-IP-bereiken afdwingen voor elk verzoek" als compenserende controle.
• Sessies met grote zekerheid: Een sessiebeveiligingsniveau Grote zekerheid vereisen, via Sessiebeveiligingsniveaubeleid en Toegangsbeleid, voor gevoelige bewerkingen (zoals toegang tot rapporten of het beheren van IP-bereiken), zodat routinematig inloggen op zichzelf geen acties met grote impact kan opleveren. In Lightning Experience wordt het opvoeren van een standaardsessie naar Grote zekerheid door opnieuw om MFA te vragen, niet ondersteund. Bereik dit beleid dus als u weet dat gebruikers van standaardsessies worden geblokkeerd voor de gated bewerking, in plaats van te worden gevraagd om te verhogen.
• Sessiecookiebescherming: Vereist het kenmerk HttpOnly zodat scripts de sessie-ID-cookie niet kunnen lezen en sessies kunnen vergrendelen naar het domein waarin ze voor het eerst zijn gebruikt, om sessie-overname te voorkomen.
• Alleen API-toegang voor integratiegebruikers: Beperk integratie- en serviceaccounts tot authenticatie met alleen API met de machtiging API Only User, zodat ze niet kunnen inloggen via de gebruikersinterface. Wijs voor nieuwe builds het profiel Minimale toegang - API Only Integrations toe met de Salesforce Integration-gebruikerslicentie. Het oudere Salesforce API Only Systems Integration-profiel is niet beschikbaar in organisaties die vanaf Spring '24 worden geleverd, dus ontwerp nieuwe integraties op basis van het huidige profiel in plaats van het verouderde.

Selecteer voor API-authenticatie OAuth 2.0-stromen die geschikt zijn voor het integratiepatroon:

• JWT-bearerstroom: Gebruik dit voor server-naar-server integraties die worden uitgevoerd als een integratiegebruiker (op certificaten gebaseerd, voorkeur voor vertrouwde omgevingen).
• Webserverstroom (autorisatiecode, met PKCE): Gebruik dit voor webtoepassingen die gebruikersautorisatie vereisen, en voor server-naar-server-integraties die specifieke gebruikerscontext moeten behouden (vernieuwingstokens opslaan aan de serverzijde om herhaalde browseraanwijzingen te voorkomen).
• Maak stroom voor autorisatiecode opnieuw afspelen veilig: Dwing PKCE af zodat een onderschepte autorisatiecode niet kan worden ingewisseld door iemand anders dan de client die erom heeft verzocht, en roteer vernieuwingstokens—waarbij bij elk gebruik een nieuwe wordt uitgegeven en de vorige ongeldig wordt—zodat een gestolen vernieuwingstoken een beperkte geldigheidsperiode heeft. Hergebruik van een ingetrokken token duidt op een compromis.
• Stroom Headless identiteitsautorisatiecode- en inloggegevens (met PKCE): Gebruik dit voor echt headless clients zonder browser die moeten worden uitgevoerd in de context van een specifieke gebruiker. De op omleidingen gebaseerde webserverstroom gaat uit van een browser die deze clients niet hebben.
• Apparaatstroom (voor headless apparaten): Vanaf 28 augustus 2025 heeft Salesforce OAuth 2.0-apparaatstroom permanent geblokkeerd voor de standaard verbonden app voor Salesforce CLI. Gebruik in plaats daarvan de webserverstroom (sf-inlogweb van organisatie) of de JWT-bearerstroom (sf-inlog-jwt van organisatie) voor CLI- en CI/CD-tooling.

Gebruik de stroom Gebruikersnaam-wachtwoord niet. Salesforce heeft deze standaard geblokkeerd voor organisaties die zijn gemaakt in Summer '23 of later, en heeft intrekkingsplannen voor deze stroom gepubliceerd. Bestaande integraties die nog steeds afhankelijk zijn van de stroom Gebruikersnaam-wachtwoord, moeten nu worden gemigreerd naar de stroom JWT-bearer of de stroom Client Credentials, in plaats van de migratie te behandelen als een uitgestelde technische schuld.

Deze stromen worden geconfigureerd voor de appregistratie die uw integratie vertegenwoordigt. Met ingang van Spring '26 verplaatst Salesforce die registratie van Verbonden apps naar Externe clientapps (ECA): het maken van nieuwe Verbonden apps is standaard uitgeschakeld en ECA is de constructie waartegen nieuwe integraties moeten worden ontworpen. Bestaande verbonden apps blijven geïnstalleerd, maar zodra een organisatie is gemigreerd, verwerken ze authenticatie niet meer. Houd daarom rekening met de migratie bij het controleren van de manier waarop integraties worden geverifieerd, in plaats van Verbonden apps als het permanente model te behandelen.

Naast het kiezen van een authenticatiestroom maakt u afzonderlijke governance waarvoor apps verbinding mogen maken:

• Eén registratie per integratie: Registreer een speciale externe clientapp voor elke nieuwe integratie en een afzonderlijke verbonden app voor elke bestaande. Beperkt tot alleen de OAuth-bereiken die elke integratie vereist, in plaats van één brede registratie te delen voor vele, houdt een speciale registratie de toegang van elke integratie onafhankelijk controleerbaar en herroepbaar.
• Expliciet toegang vooraf autoriseren (aanbevolen): Stel het beleid Toegestane gebruikers van de app Externe client in op "Door beheerder goedgekeurde gebruikers zijn vooraf geautoriseerd", zodat een beheerder toegang verleent via profielen en machtigingensets in plaats van gebruikers zichzelf te laten autoriseren. Beheerders configureren dit rechtstreeks in Set-up en het is de aanbevolen controle van Salesforce om te bepalen wie verbinding kan maken.
• API-toegangscontrole (strenger, op goedgekeurde lijst gebaseerd): Voor strengere controles beperkt API Access Control (API-toegangscontrole) door de beheerder goedgekeurde gebruikers tot alleen op de goedgekeurde lijst geplaatste verbonden apps. Het inschakelen ervan vereist een verzoek aan de klantenondersteuning van Salesforce. Plan daarom die stap bij het ontwerpen ervan in plaats van deze te beschouwen als een selfservice-instelling.

Bed inloggegevens nooit in code, configuratiebestanden of versiebeheer in. Gebruik benoemde inloggegevens en externe inloggegevens om authenticatie centraal te beheren met rotatiemogelijkheden.

In tegenstelling tot traditionele gebruikersauthenticatie vereisen agenten afzonderlijke identiteitsmodellen en het juiste model is afhankelijk van het gegeven of de agent werknemers of externe gebruikers bedient. Identiteit correct ontwerpen is de basis van agentbeveiliging: het bepaalt tot welke gegevens de agent toegang heeft en tot welke acties de agent toegang heeft.

Laten we eens wat beter kijken naar interne en externe agenten.

• Medewerkersagenten (intern): Taken uitvoeren binnen de context van de ingelogde gebruiker. Ze nemen de licenties, machtigingensets, beveiliging op veldniveau en regels voor delen van die gebruiker over, waardoor er geen afzonderlijke agentidentiteit wordt geboden en het bestaande beveiligingsframework bepaalt wat de agent kan doen.
• Klantagenten (extern): Communiceer via openbare kanalen en voer ze uit als speciale Agentgebruikers, gespecialiseerde integratiegebruikers, niet als gastgebruikers op openbare sites. Als de agent wordt uitgevoerd als toegewijde integratiegebruikers, kan deze back-endacties uitvoeren en gegevens bereiken (wat niet kan door niet-geauthenticeerde gastprofielen), terwijl hij toch gebonden is aan expliciete machtigingen met de minste rechten. Wanneer u een klantagent maakt, levert u een nieuwe agentgebruiker met minimale toegang en verleent u alleen de specifieke machtigingen die de acties ervan vereisen.

Wanneer het werk van een agent meerdere services omvat, draagt u de identiteit van de gebruiker uit binnen elke servicehop in plaats van terug te vallen op een gedeelde of gastidentiteit. De Salesforce OAuth 2.0-tokenuitwisselingsstroom ondersteunt dit:

Een client presenteert het bestaande identiteitstoken van de gebruiker en een Apex tokenuitwisselingshandler wijst dit toe aan een Salesforce-gebruiker en geeft een Salesforce-toegangstoken uit, waardoor de context van de oorspronkelijke gebruiker het verzoek volgt in plaats van samen te vouwen naar een serviceaccount. Bewaak de activiteit van agenten via Event Monitoring en gebruik de gebruikersidentiteit van de agent om afwijkend gedrag te detecteren.

Het kiezen van het juiste model is afhankelijk van wie de verbinding initieert en in wiens context het werk moet worden uitgevoerd.

Veel voorkomende verbindingsscenario's worden als volgt toegewezen aan aanbevolen benaderingen:

Ontwerp rollenhiërarchieën rond gegevenstoegangsbehoeften (die gebruikers toegang nodig hebben tot records die eigendom zijn van anderen)—niet het diagram voor managementrapportage. Laat de diepte van de rollenhiërarchie echte gegevenstoegangsrelaties volgen in plaats van niveaus toe te voegen die geen extra toegang verlenen, aangezien elk niveau overhead voor delen-berekeningen toevoegt—een overweging die zwaarder weegt in organisaties met privé-OWD-instellingen en grote gegevensvolumes.

Machtigingensets en groepen machtigingensets reduceren de noodzaak van profielproliferatie door flexibele, additieve toegang te bieden. Verleen functionele toegang door middel van machtigingensets en groepen machtigingensets in plaats van profielen, die toegang additief en controleerbaar houden. Profielen blijven noodzakelijk: naast inloguren en IP-beperkingen bepalen ze de toewijzing van paginalay-outs, standaardinstellingen voor recordtypen en zichtbaarheid van apps. Behandel profielen als een duurzaam onderdeel van het toegangsmodel, in plaats van als een constructie die moet worden verwijderd.

Transactiebeveiligingsbeleidsvormen vormen geen onderdeel van de baseline, maar vormen een uitbreidingsmogelijkheid die het kernautorisatiemodel aanvult: de bovenstaande besturingselementen voor identiteit, rol, profiel, machtigingenset en delen zorgen al voor een eigen veilige autorisatiestatus en transactiebeveiliging voegt daar real-time contextuele evaluatie aan toe. Configureer beleidsvormen om afwijkend gedrag te detecteren en te blokkeren, inclusief bulkdownloads van gegevens die normale patronen overschrijden, logins vanuit onverwachte geografische gebieden en wijzigingen van machtigingen buiten wijzigingsvensters.

Beveiligingscontroles hebben nadelen voor de beschikbaarheid, die een architectonische verantwoordelijkheid zijn. Een te brede IP-beperking kan legitieme gebruikers uitsluiten tijdens een netwerkwijziging en een te agressief afgestemd transactiebeveiligingsbeleid kan geldige bedrijfsactiviteiten blokkeren. Beperk deze besturingselementen dus tot een reëel risico, schakel ze in de modus voor alleen monitoren in voordat u ze afdwingt en ontwerp een glazen traject voor wanneer een besturingselement mislukt.

Uw verantwoordelijkheid: Rollenhiërarchie ontwerpen, machtigingensets maken, transactiebeveiligingsbeleid configureren.

Traditionele op rollen gebaseerde toegangscontrole) verleent machtigingen op basis van de rol van een gebruiker. ABAC (op kenmerken gebaseerde toegangscontrole) neemt autorisatiebeslissingen op basis van kenmerken van de gegevens, de gebruiker en de context.

Voor de meeste vereisten drukt het kernmodel voor delen toegang volledig uit. Reik naar speciale ABAC wanneer toegang gegevensclassificatie moet volgen die niet kan worden uitgedrukt per record: Data 360 ABAC biedt dit door middel van tags en annotaties.

Data 360 ABAC werkt via:

• Op tags gebaseerde beleidsvormen die toegangsregels definiëren op basis van tags die worden toegepast op gegevensobjecten (bijv. Persoonlijk Identificeerbare Informatie (PII), Financiële tags, Gezondheidszorgtags en Vertrouwelijke tags).
• Annotaties worden toegepast op gegevensobjecten ter ondersteuning van op beleid gebaseerde autorisatiebeslissingen.
• Standaardbeleid "Alles toestaan" voor nieuwe en bestaande organisaties die expliciet moeten worden verwijderd om fijnmazig governancebeleid in te schakelen.

Het primaire architectonische gebruik ervan is het afdwingen van gegevensclassificatie. Zie Gegevensclassificatie onder Gegevensbescherming en privacy voor de manier waarop classificatielagen ABAC-afdwinging aansturen.

Dit niveau van fijnkorreligheid brengt operationele kosten met zich mee. Kerndelen beantwoordt de vraag "Wie kan deze record zien en waarom?" uit een kleine, inspecteerbare set regels (OWD's, rollenhiërarchie en regels voor delen), terwijl ABAC zijn antwoorden op evaluatietijd ontleent aan de combinatie van gegevenstags, gebruikerskenmerken en context, waardoor effectieve toegang moeilijker wordt om over te redeneren en om te controleren naarmate beleid en tags zich opstapelen.

Dwing controle af als ontwerpvereiste: pas tags consistent toe, houd de beleidsset klein en benoemd naar de classificatie die wordt afgedwongen, en behoud de mogelijkheid om te reconstrueren waarom een gebruiker een bepaalde record heeft bereikt. Reserveer ABAC voor door classificatie gestuurde cases die per record niet echt kunnen worden uitgedrukt, in plaats van het te behandelen als een algemene vervanging van het op eigendom gebaseerde model.

Identificeer en bescherm accounts met verhoogde machtigingen, inclusief systeembeheerders, integratiegebruikers en geautomatiseerde procesaccounts. Deze accounts zijn waardevolle doelen voor aanvallers.

Pas uitgebreide controles toe op kritieke impactaccounts.

• phishingbestendige MFA vereisen
• Inlog-IP-bereiken beperken tot bekende beheerlocaties
• Inlogwaarschuwingen en kennisgevingen over machtigingswijzigingen inschakelen
• Periodieke toegangsbeoordelingen uitvoeren met gedocumenteerde attesten voor accounts met hoge machtigingen, waarbij de frequentie wordt bepaald door organisatorische risicotolerantie en nalevingsvereisten
• Handhaaf glasbreukprocedures voor toegang tot noodgevallen en controle na gebruik

Voor integratie- en serviceaccounts:

• OAuth-stromen toepassen; nooit gebruikersnaam-wachtwoord-stromen
• IP-beperkingen afdwingen
• Rotatieschema's voor inloggegevens implementeren
• Bewaken op abnormale API-gebruikspatronen via Event Monitoring

Uw verantwoordelijkheid: Identificeer kritieke accounts, pas uitgebreide controles toe en voer driemaandelijkse beoordelingen uit.

Ontwerp geautomatiseerde processen om gebruikers te voorzien van de juiste initiële toegang, pas machtigingen aan naarmate rollen zich ontwikkelen en verwijder ze onmiddellijk wanneer toegang niet langer vereist is.

Implementeer een systeem voor identiteitsbeheer voor meerdere domeinen (SCIM) voor geautomatiseerde levering door identiteitsleveranciers. SAML of OpenID Connect Just-in-Time-leveringen zijn een alternatief dat een gebruiker maakt bij de eerste keer inloggen, maar geen gebruikers ontslaat. Met andere woorden, SCIM is de ruggengraat van de levenscyclus, geen keuze ertegen.

De identiteitslevenscyclus omvat:

• Levering: Maak accounts met baselinetoegang die overeenkomt met de functie, die wordt geactiveerd door events van het HR-systeem.
• Toegangsaanpassingen: Verleen extra machtigingen naarmate rollen worden uitgebreid en trek machtigingen in wanneer rollen veranderen.
• Periode hercertificering: Controleer en valideer toegang elk kwartaal.
• Niet-levering: Trek toegang onmiddellijk in wanneer het dienstverband eindigt of rollen Salesforce-toegang niet langer vereisen.

Implementeer toegangshercertificeringsprocessen wanneer managers de machtigingen van hun teams periodiek controleren en valideren. De beoordelingsfrequentie is gebaseerd op risico- en nalevingsvereisten.

Uw verantwoordelijkheid: SCIM implementeren, leveringswerkstromen ontwerpen, driemaandelijkse hercertificering uitvoeren.

Het scheiden van gegevens in meerdere organisaties wordt soms gezien als een beslissing over kosten of verblijf. Architectonisch gezien is het een beveiligingsafweging en behoren de governance-gevolgen tot uw toegangsontwerp.

Isolatie is het belangrijkste voordeel. Afzonderlijke organisaties bieden de sterkst mogelijke grens tussen gegevenssets. Er is geen collectief model voor delen en geen aftap van machtigingen voor meerdere belanghebbenden, maar er is een duidelijke regelgevingslijn voor jurisdicties die er een vereisen. Diezelfde grens versnippert het bestuur. Elke toegangscontrole die u slechts één maal binnen één organisatie hoeft te onderhouden (bijvoorbeeld ontwerp van machtigingensets, rollenhiërarchie, verharding van kritieke impact-accounts, baselines van toestandcontrole, Event Monitoring en SIEM-correlatie) wordt nu per organisatie vermenigvuldigd, wat betekent dat deze consistent moet blijven voor alle ervan. Drift tussen organisaties creëert een eigen aanvalsoppervlak, omdat een machtiging die in de ene organisatie wordt aangescherpt en in de andere wordt gemist, een inconsistentie veroorzaakt die aanvallers kunnen vinden en misbruiken. Integraties tussen organisaties voegen geauthenticeerde Trust grenzen toe die voorheen niet bestonden. Elke inter-organisatorische integratie is een verbinding die u moet beveiligen en bewaken.

Daarom is het belangrijk om het isolatievoordeel af te wegen tegen de governancevermenigvuldiger voordat een organisatie wordt gesplitst. Reserveer meerdere organisaties voor gevallen waarin echt niet binnen één organisatie kan worden voldaan aan een permanent lokalisatiemandaat of de contractuele isolatievereiste van een klant. Wanneer u deze implementeert, moet u de baselines van het toegangsmodel, de bewaking en de configuratie ontwerpen om vanaf het begin identiek te worden afgedwongen voor elke organisatie.

Uw verantwoordelijkheid: Beschouw een beslissing voor meerdere organisaties als een beveiligingsafweging, niet alleen als een kostenafweging. Wanneer meerdere organisaties vereist zijn, dwingt u toegangscontroles, bewaking en baselines van toestandcontrole consistent af voor elke organisatie en beveiligt u elke inter-organisatorische integratie als een Trust grens.

Het is uw verantwoordelijkheid om gegevens te classificeren, encryptie te configureren en privacycontroles te ontwerpen.

Laten we eens beter kijken naar de manier waarop u gegevens en privacy goed beschermt.

Voor een juiste classificatie van uw gegevens moet u uw gegevens kennen. De overkoepelende architectonische taak bestaat uit het begrijpen van uw bedrijfsdomein en het onderhouden van een gegevenswoordenlijst die catalogiseert welke gegevens u in bezit hebt, wat deze inhouden en waar gevoelige gegevens zich bevinden. U kunt alleen gegevens classificeren—of beschermen—die u als eerste hebt geïdentificeerd.

Stel een gegevensclassificatieschema op dat de juiste beschermingselementen aanstuurt. Een classificatielabel beschermt op zichzelf niets. Het is de invoer voor de besturingselementen die u toepast, dus elke classificatie die u toewijst, moet worden toegewezen aan een concrete beslissing over encryptie, toegang, bewaring of bewaking. Classificatiebeslissingen die worden genomen tijdens het modelleren van gegevens, hebben rechtstreeks invloed op encryptievereisten, toegangscontroles, bewaarbeleid en nalevingsverplichtingen.

Bij Salesforce gebruiken we een schema met vier lagen dat een raamwerk biedt dat u kunt aanpassen aan de wettelijke vereisten en bedrijfsbehoeften van uw organisatie. Veel bedrijven gebruiken soortgelijke modellen die zijn afgestemd op industrienormen (bijvoorbeeld ISO 27001 en NIST). Uw specifieke implementatie moet uw nalevingsverplichtingen (bijvoorbeeld HIPAA, PCI DSS, AVG en brancheregelgeving) en bedrijfscontext weerspiegelen.

Pas classificatie toe op veldniveau. Eén accountrecord kan openbare velden (bijvoorbeeld bedrijfsnamen), vertrouwelijke velden (bijvoorbeeld bedrijfsomzet) en velden met beperkingen (bijvoorbeeld burgerservicenummers) bevatten. Beveiliging op veldniveau moet deze verschillen weerspiegelen.

Classificatie kan worden afgedwongen door middel van op kenmerken gebaseerde toegangscontrole, die de tags leest die u toewijst en toegangsregels toepast. Dit is een door metagegevens gestuurde laag die een aanvulling vormt op regels voor delen.

Door ABAC uit te lijnen met uw classificatieschema kan het platform:

• Beperk toegang tot gegevens met de tag Beperkt of Vertrouwelijk vanuit de classificatie zelf, in plaats van vanuit een regel voor delen die per object wordt onderhouden.
• Pas de toegang aan naarmate de classificatie van een record verandert. Een record met een nieuwe tag Gereguleerd neemt striktere toegang over zonder handmatige regelwijziging.
• Combineer gegevenskenmerken (bijvoorbeeld classificatie en gevoeligheid) met gebruikerskenmerken (bijvoorbeeld afdeling en inklaring) en context (bijvoorbeeld tijd en locatie) in één autorisatiebeslissing.

Ontwerp ABAC-beleidsvormen dusdanig dat het classificeren van een veld als Beperkt de handeling is die de toegangscontroles ervan aanstuurt en de afdwinging verankerd houdt aan de classificatie, in plaats van regels voor delen afzonderlijk te onderhouden.

Uw verantwoordelijkheid: Definieer classificatieschema's, train gegevensmodelleurs, classificeer velden tijdens het ontwerp, configureer besturingselementen en stem ABAC-beleidsvormen af op de classificatielagen zodat tags de afdwinging stimuleren.

StartBegin met de informatie die het platform al biedt voor elke organisatie. Gegevens in ruste worden standaard versleuteld. Hyperforce past encryptie op volumeniveau toe die een volledig opslagvolume beschermt onder één sleutel waarvan Salesforce eigenaar is en die Salesforce beheert. Deze baseline is altijd ingeschakeld en transparant voor uw oplossing, maar werkt op het volumeniveau (niet per veld), dus de keuze voor wat er moet worden versleuteld en beheerd binnen de levenscyclus van de sleutel, ligt bij het platform, niet bij u.

Wanneer die baseline niet kan voldoen aan een nalevings-, contractuele of gegevensclassificatieverplichting, gebruikt u Shield Platform Encryption. Met name wanneer u een van de drie dingen nodig hebt die encryptie op volumeniveau niet biedt:

• Controle over de levenscyclus van de sleutel zodat u het sleutelmateriaal zelf kunt genereren, roteren en intrekken
• Selectiviteit over welke standaardvelden, aangepaste velden, bestanden en bijlagen in ruste worden versleuteld
• De mogelijkheid om gegevens ontoegankelijk te maken voor Salesforce.

Beperkte gegevens en gegevens die onder expliciete wettelijke sleutelbeheermandaten vallen (bijvoorbeeld HIPAA, PCI DSS en GDPR) zijn de gebruikelijke triggers. De baseline dekt al bescherming op infrastructuurniveau van al het andere.

Shield Platform Encryption versleutelt op veldniveau en biedt twee schema's die beveiliging ruilen voor opvraagbaarheid.

Probabilistische encryptie is een sterk, standaardschema, maar de velden die ermee zijn versleuteld, kunnen niet worden gebruikt in filtercriteria-, sorteer- of aggregatiefuncties (bijvoorbeeld MAX(), MIN() en COUNT_DISTINCT().

Deterministische encryptie maakt filteren van exacte overeenkomsten in rapporten, lijstweergaven en SOQL WHERE-clausules – hoofdlettergevoelig of hoofdletterongevoelig – mogelijk met verminderde sterkte, omdat dezelfde platte tekst altijd dezelfde versleutelde tekst produceert.

U wordt aangeraden om standaard te versleutelen met het probabilistische schema en deterministische encryptie te reserveren voor de specifieke velden die u moet filteren of sorteren. Evalueer deze nadelen tijdens het ontwerpen van gegevensmodellen, inclusief gevolgen voor verwijzingen naar formulevelden, rapportaggregatie en SOQL-bewerkingen.

Klantgestuurde sleutels zijn er in twee verschillende vormen:

• Met Bring Your Own Key (BYOK) kunt u sleutelmateriaal genereren buiten Salesforce—met behulp van uw eigen cryptobibliotheken, sleutelbeheersysteem voor de onderneming of hardwarebeveiligingsmodule—en dit aanleveren aan het platform.
• Alleen-cache sleutelservice bewaart uw gegevensencryptiesleutel in een sleutelservice die u beheert. Salesforce haalt het op verzoek op in plaats van het op te slaan.

Met beide formulieren kunt u sleutelmateriaal roteren en vernietigen volgens uw eigen planning. Het vernietigen van sleutelmateriaal maakt de gegevens die het heeft beschermd onherstelbaar, wat een krachtige, opzettelijke controle is in plaats van een routine. Het is ook belangrijk om uw sleutelrotatie- en intrekkingsprocedures te documenteren.

Alle integraties moeten TLS 1.2 of hoger gebruiken (het Salesforce-platform dwingt dit af), maar u moet op een certificaat gebaseerde wederzijdse authenticatie implementeren voor integraties die Beperkte gegevens afhandelen (met behulp van uw eigen configuratie).

Uw verantwoordelijkheid: Bepaal waar de baseline op volumeniveau van het platform voldoet en waar een nalevings-, contractuele of classificatieverplichting Shield Platform Encryption rechtvaardigt, selecteer vervolgens encryptieschema's, kies en bedien een door de klant beheerde sleutelstrategie en implementeer op certificaten gebaseerde auth. voor gevoelige integraties.

Bescherm gevoelige gegevens in niet-productieomgevingen met behulp van strategieën die voorkomen dat gegevens met beperkingen in sandboxen terechtkomen.

• Gedeeltelijk kopiëren van sandbox sluit Beperkte gegevens uit van sandboxvernieuwingen.
• Regels voor het maskeren van gegevens verwarren gevoelige veldwaarden in sandboxen door patronen te gebruiken die gegevenskenmerken behouden.
• Het genereren van synthetische gegevens is van toepassing op ontwikkelomgevingen die nooit productiegegevens vereisen.
• Sandboxsjablonen definiëren welke objecten en velden moeten worden opgenomen in elk sandboxtype.

Ontwerpen voor nalevingstests is een architectonische verantwoordelijkheid. Stel ontwikkel- en testcycli samen op basis van synthetische gegevens met realistische kenmerken, zodat teams kunnen valideren op basis van productieachtige omstandigheden terwijl gereguleerde gegevens binnen de productiegrens blijven.

Uw verantwoordelijkheid: Ontwerp sandboxstrategie, configureer Data Mask regels, genereer synthetische testgegevens.

Ontwerp oplossingen die de privacy van gebruikers respecteren via architectonische beslissingen.

• Gegevensminimalisering: Verzamel gegevens die alleen nodig zijn voor vermelde bedrijfsdoeleinden. Daag elke veldtoevoeging uit door te vragen: "Welke architectonische beslissing vereist deze gegevens?" Vergeet niet dat de veiligste gegevens de gegevens zijn die u nooit verzamelt.
• Doelbeperking: Ontwerp gegevenstoegangspatronen die doelbeperking technisch afdwingen. Gebruik machtigingensets en regels voor delen om toegang tot gegevens te beperken op basis van het doel van een functie. Marketinggebruikers moeten bijvoorbeeld geen toegang hebben tot details van ondersteuningscases, tenzij hun taak dit vereist.
• Instemmingsbeheer: Implementeer het bijhouden van instemming op individueel niveau voor marketing, analyses en optionele gegevensverwerking. Ontwerp werkstromen voor het intrekken van instemming, die worden verspreid over geïntegreerde systemen. Met andere woorden, instemming is fijnmazig en doelspecifiek.
• Rechten van betrokkene: Werkstromen samenstellen voor toegangsverzoeken (bijvoorbeeld het aanleveren van gegevenskopieën), rectificatie (bijvoorbeeld het corrigeren van onnauwkeurigheden), verwijdering (bijvoorbeeld het verwijderen van gegevens wanneer dit wettelijk is toegestaan) en overdraagbaarheid (bijvoorbeeld exporteren naar een machineleesbare indeling). Ontwerp deze werkstromen voor voltooiing binnen de reactiedeadline die elk regelgevend raamwerk oplegt. Deze deadlines variëren per rechtsgebied en worden periodiek gewijzigd. Het is dus belangrijk om de SLA van de werkstroom te parametriseren vanuit een onderhouden nalevingsbron en elk venster te controleren op basis van de regelgeving (in plaats van één waarde hard te coderen).

Uw verantwoordelijkheid: Ontwerp gegevensmodellen met een minimum aan aandacht, configureer toegang op doel, implementeer instemmingswerkstromen en stel automatisering van de rechten van betrokkenen samen.

Gegevensverblijf is een architectonische beslissing die u neemt vóór levering, niet een instelling die u achteraf aan-/uitschakelt. Hyperforce biedt regionale implementatie—maar een regio bestaat alleen waar Salesforce er een exploiteert—en de residentie van een organisatie is vastgelegd bij levering. Het is uw verantwoordelijkheid om vast te stellen waar elke gegevenscategorie zich moet bevinden, te controleren of er een geschikte regio beschikbaar is en de mechanismen voor gegevensoverdracht te ontwerpen die legitiem grenzen overschrijden.

In plaats van standaard te kiezen voor opslag in het land, is het belangrijk om uw verblijfsverplichtingen te classificeren voordat u begint.:

• Verplichte lokalisatie. Een kleine set jurisdicties vereist dat bepaalde gegevens binnen de nationale grenzen blijven (soms geldt dit alleen voor gereguleerde sectoren). Wanneer Salesforce niet actief is in een regio binnen het land, kan native opslag op zichzelf niet voldoen aan het mandaat. Daarom hebt u een overlay voor gegevensverblijf of een afzonderlijke organisatie voor die gegevens nodig. Aangezien deze lijst kan veranderen, is het belangrijk om het specifieke mandaat te bevestigen ten opzichte van de regelgeving.
• Op verantwoording gebaseerde raamwerken. De meeste regimes leggen geen lokalisatiemandaat op. Ze worden bevredigd door een regionale hub met een geschikt mechanisme voor grensoverschrijdende overdracht. In deze gevallen wordt de beslissing gebaseerd op welke regio de latentie minimaliseert en naleving vereenvoudigt.

Wanneer gegevens een grens overschrijden, gaat het om bewustwording vóór configuratie. Met andere woorden, u moet weten welke overdrachten plaatsvinden en op welke juridische basis, en vervolgens de toegang dusdanig ontwerpen dat de gegevens van begin tot eind worden beheerd. Waar ze bestaan, leiden adequaatheidsbeslissingen tot de minste frictie. Bindende bedrijfsregels (BCR's) en standaardcontractbepalingen (VCA's) bestrijken de meeste resterende overdrachten. Gebruik expliciete instemming alleen als laatste redmiddel.

Koppel het overdrachtsmechanisme aan beperkende recordtoegang (bijvoorbeeld privé-OWD's en delen met doel), zodat een toelaatbare overdracht niet te breed wordt. Documenteer gegevensstroomkaarten om te tonen waar elke gegevenscategorie vandaan komt, wordt doorgevoerd en zich bevindt. Bezoek ze opnieuw wanneer regelgeving of regionale beschikbaarheid verandert.

Uw verantwoordelijkheid: Classificeer verblijfsverplichtingen per gegevenscategorie, bevestig de regionale beschikbaarheid voordat u gegevens aanlevert, selecteer overdrachtsmechanismen (geschiktheid, BHG's/VCA's) voor grensoverschrijdende stromen en documenteer gegevensstroomkaarten.

Het is uw verantwoordelijkheid om oplossingen te ontwerpen die de nalevingsstatus behouden die het platform biedt.

Deze begeleiding is richtinggevend. Regelgevingsvereisten variëren per rechtsgebied en veranderen in de loop van de tijd. U moet altijd specifieke verplichtingen verifiëren op basis van de toepasselijke regelgeving (bijvoorbeeld de toepasselijke wetgeving, toezichthoudende autoriteit of Salesforce-nalevingsdocumentatie) voor uw implementatie.

Salesforce heeft uitgebreide nalevingscertificeringen (beschikbaar op Trust.salesforce.com en compliance.salesforce.com): SOC 2 Type II, ISO 27001, FedRAMP (voor Government Cloud-aanbiedingen), HIPAA, PCI DSS en regionale certificeringen. Deze certificeringen dekken Salesforce-verantwoordelijkheden voor platforminfrastructuur en gedeelde services.

Platformcertificeringen verminderen uw nalevingslast, maar elimineren uw architectonische verantwoordelijkheid niet. Uw aangepaste objecten, Apex code, integraties en configuraties moeten de nalevingsstatus behouden die het platform biedt.

Uw verantwoordelijkheid: Ontwerp oplossingen die de nalevingsstatus handhaven en documenteer hoe architectuur voldoet aan wettelijke vereisten.

• Schakel Shield Platform Encryption in voor alle velden die beschermde gezondheidsinformatie (PHI) bevatten.
• Schakel voor HIPAA-naleving het veldcontroletraject met bewaarbeleid in om te voldoen aan de vereiste voor het bijhouden van HIPAA-records. Bevestig de huidige periode aan de hand van de regelgeving.
• Configureer Event Monitoring om ongeoorloofde PHI-toegangspatronen te detecteren.
• Implementeer alle technische voorzorgsmaatregelen die vereist zijn door de HIPAA-beveiligingsregel, inclusief toegangscontroles, controlelogboeken en transmissiebeveiliging.

• Implementeer scheiding van taken (SoD) via ontwerpen van machtigingensets om te voorkomen dat afzonderlijke gebruikers financiële transacties maken en goedkeuren.
• Vermijd voor PCI-omgevingen het opslaan van volledige primaire accountnummers (PAN) in Salesforce om het bereik van PCI DSS-naleving te minimaliseren.
• Gebruik indien mogelijk tokenisering van betalingsgateway.

• Ontwerp voor AVG en LGPD instemmingsbeheer dat granulaire, doelspecifieke instemming voor aanmelding vastlegt.
• CCPA/CPRA volgt een afmeldingsmodel. Zorg voor duidelijke mechanismen om u af te melden voor de verkoop of het delen van persoonsgegevens in plaats van fijnmazige, op doelen gebaseerde instemming.
• Stel werkstromen voor de rechten van betrokkenen samen die worden voltooid binnen de reactiedeadline van elk framework en die worden bevestigd op basis van de regelgeving.
• Implementeer automatisering voor gegevensbewaring die gegevens opschoont wanneer instemming verloopt.

• Gebruik de Salesforce Government Cloud voor gereguleerde overheidswerkbelasting.
• Implementeer NIST 800-53-besturingselementen die zijn toegewezen aan de Salesforce-configuratie.
• Schakel continue bewaking in via Event Monitoring die naar de SIEM-infrastructuur van de overheid wordt gerouteerd.

Uw verantwoordelijkheid: Configureer Shield, Veldcontroletraject, scheiding van taken, instemmingsbeheer, gegevensbewaring op basis van wettelijke vereisten.

Regelgeving voor gegevensbescherming en privacy verschilt aanzienlijk per rechtsgebied—en specifieke verplichtingen veranderen snel—dus dit niveau vereist besluitvorming in plaats van een tabel per land.

De twee architectonische hefbomen zijn verblijf en grensoverschrijdende overdracht, die worden behandeld onder Gegevensbescherming en Privacy.

Als u zich aan deze regelgeving wilt houden, moet u:

• Classificeren waar elke gegevenscategorie moet zijn ondergebracht
• Bevestig dat er een geschikte regio bestaat voordat u de levering uitvoert
• Ontwerp een wettelijk overdrachtsmechanisme voor gegevens die een grens overschrijden.

Zie Gegevensverblijf en soevereiniteit voor meer informatie over het beslissingsframework.

Alles daarbuiten wordt beschouwd als een momentopname (bijvoorbeeld welk instemmingsmodel een rechtsgebied gebruikt, de deadline voor een verzoek van een betrokkene, de periode voor het informeren van toezichthouders of betroffen personen na een inbreuk en de minimale bewaarperiode voor auditrecords). Deze cijfers worden vastgesteld door regelgeving, verschillen per framework en worden gewijzigd in de planningen van de toezichthouders.

Hardcodeer ze hier niet. U moet de volgende stappen bepalen op basis van de regelgeving voor uw implementatie—of een onderhouden nalevingsbron die een bron vermeldt—en uw ontwerp zo klein mogelijk maken in uw operationele voetafdruk.

Hier zijn de duurzame architectonische gevolgen die bij het ontwerp horen.

• Een deadline voor een verzoek van een betrokkene, die wordt gemeten in dagen van één cijfer, kan niet worden gehaald door een ad-hoc handmatig proces, dus u moet DSR-levering automatiseren wanneer u in een rechtsgebied met korte deadlines werkt. Gebruik Experience Cloud voor intake, Service Cloud voor het bijhouden van cases, Privacycentrum voor ontdekking en Stroom voor levering.
• Een tijdsbestek voor kennisgevingen van inbreuken is te krap om te improviseren, dus u moet de werkstroom voor inbreukreacties vooraf samenstellen. Bepaal anomalieregels voor Event Monitoring, vooraf toegewezen rollen, vooraf opgestelde kennisgevingen van toezichthouders en betrokkenen, en een escalatiepad dat uitgaat van de krapste deadline binnen uw voetafdruk. Afzonderlijke kennisgevingen worden over het algemeen geactiveerd door een beslissing met hoog risico, dus u moet een risicobeoordeling opnemen in de werkstroom.
• Bepaalde rechtsgebieden vereisen of adviseren het bewaren van auditlogboeken in het land—met minimumwaarden voor meerdere jaren—dus u moet SIEM-bewaring beperken tot het langste minimum binnen uw voetafdruk en bevestigen of logboeken het rechtsgebied mogen verlaten.

Uw verantwoordelijkheid: Ontwerp woonplaats en overdracht op basis van gegevensbescherming en privacy, automatiseer DSR- en inbreukresponswerkstromen tot de krapste deadline in uw voetafdruk, en bevestig elk jurisdictiespecifiek cijfer ten opzichte van de regelgeving in plaats van een waarde die in deze handleiding wordt geschreven.

Ontwerp voor continue nalevingsvalidatie in plaats van voorbereiding van punt-in-tijd audits.

• Beveiligingstoestandscontrole beoordeelt configuratie op basis van Salesforce-beveiligingsbaselines en biedt risicoscores. Voer regelmatig controles uit om te controleren of de aanbevelingen voor baseline van Salesforce-beveiliging worden nageleefd. Handhaaf scores van 80% of hoger (Zeer goede of uitstekende bands).
• Event Monitoring legt gedetailleerde logboeken vast voor gebruikersactiviteit, API-aanroepen, authenticatie-events en gegevenstoegangspatronen. Routeer eventlogboekbestanden naar externe SIEM voor langdurige bewaring die native bewaarlimieten overschrijdt.
• Transactiebeveiliging evalueert events op basis van polissen in real-time en kan events blokkeren, een toename van MFA vereisen of u informeren over beleidsschendingen.

Het is belangrijk om nalevingscontroles in implementatiepijplijnen te automatiseren om te valideren dat implementaties geen machtigingsmodellen verzwakken, controle-instellingen uitschakelen of niet-conforme configuraties introduceren.

Uw verantwoordelijkheid: Voer de toestandcontrole elk kwartaal uit, routeer Event Monitoring naar SIEM, configureer transactiebeveiligingsbeleid en automatiseer nalevingsvalidatie in CI/CD.

Ontwerp strategieën voor controletrajecten die zijn gebaseerd op nalevingsvereisten, onderzoeksbehoeften en bewaarverplichtingen.

Implementeer voor gereguleerde omgevingen Event Monitoring met externe SIEM-integratie voor logboekbewaring op lange termijn en systeemoverschrijdende correlatie. Ontwerp beleidsvormen voor Veldcontroletraject die alle velden Beperkt en Vertrouwelijk bestrijken die onderworpen zijn aan wettelijke vereisten voor het bijhouden van records.

Uw verantwoordelijkheid: Schakel Veldcontroletraject in voor gevoelige velden, routeer Event Monitoring naar SIEM en configureer beleidsvormen voor transactiebeveiliging.

Het is uw verantwoordelijkheid om beveiliging te integreren in de gehele ontwikkeling, niet als bijzaak.

Integreer beveiligingspraktijken in een zo vroeg mogelijke ontwikkelingsfase. Dreigingsmodellering tijdens de architectuurfase voorkomt kwetsbaarheden op ontwerpniveau. Beveiligingsvereisten die naast functionele vereisten worden vastgelegd, voorkomen dat u beveiliging als een bijzaak beschouwt.

Beveiligingsfouten kosten aanzienlijk meer om te verhelpen wanneer ze tijdens de productie worden ontdekt, in plaats van tijdens de ontwerp- of ontwikkelingsfase. Een beveiligingsfout op ontwerpniveau die wordt ontdekt tijdens een architectuurbeoordeling, vergt mogelijk slechts één gesprek om te verhelpen. Wanneer dezelfde fout echter in de productieomgeving wordt aangetroffen, zijn herarchitectuur, gegevensmigratie, nalevingsherstel en kennisgeving van potentiële inbreuken vereist.

Daarom oefenen we shift-left security uit, dat zich richt op:

• Dreigingsmodellering vóór ontwerpafronding
• Beveiligingsvereisten in gebruikersstory's
• Veilige programmeertraining voor ontwikkelaars
• Statische analyse die is geïntegreerd in IDE's
• Op beveiliging gerichte codebeoordelingen
• Geautomatiseerde beveiligingstests in CI/CD
• Beveiligingsvalidatie vóór productie-implementatie

Uw verantwoordelijkheid: Dreigingsmodellering uitvoeren, ontwikkelaars trainen, Code Analyzer integreren in CI/CD, beveiligingsbewuste codebeoordelingen vereisen.

Het is belangrijk om verdediging te ontwerpen tegen veelvoorkomende kwetsbaarheden in een Salesforce-context. Laten we eens beter kijken naar de manier waarop we de 2025 OWASP Top 10 bij Salesforce benaderen.

• A01:2025 - Verbroken toegangscontrole: Dwing programmatisch CRUD en beveiliging op veldniveau (FLS) af in alle Apex gegevenstoegang.
  • In API-versie 67.0 of hoger wordt Apex standaard uitgevoerd in gebruikerscontext, wat betekent dat de machtigingen en FLS van de huidige gebruiker worden afgedwongen tijdens de uitvoering van code.
    • WITH SECURITYENFORCED is verwijderd, wat een compilatiefout veroorzaakt. Vervang elk bestaand gebruik door WITH USER_MODE. Het platform dwingt toegang af in de standaard UI.
  • In API-versie 66.0 of lager is de systeemmodus de standaard. Gebruik WITH USERMODE in SOQL-query's of Security.stripInaccessible() voor DML-bewerkingen.
• A01:2025 - Gegevens-API's aan clientzijde: Lightning Data Service en de UI-API dwingen automatisch FLS, CRUD en delen van de huidige gebruiker af, waardoor een component die hierop is gebaseerd, standaard de minste rechten overneemt.
  • Deze bescherming gaat verloren wanneer een component een aangepaste Apex aanroept. Verplichte Apex dwingt alleen toegang af wanneer het wordt uitgevoerd in de gebruikersmodus, waardoor een klasse die wordt gedeclareerd zonder delen, fungeert als een noodluik dat het model stilletjes omzeilt.
  • Gebruik Lightning Data Service en de UI-API voor gegevenstoegang.
  • U moet CRUD, FLS en delen opnieuw bevestigen voor elke verplichte Apex aanroep vanuit een component.
• A02:2025 - Beveiligingsfoutieve configuratie: Controleer configuratieafwijkingen ten opzichte van beveiligingsbaselines met behulp van Controle van toestand.
  • Schakel Gastgebruikerstoegang op Experience Cloud-sites uit (tenzij dit expliciet vereist is op grond van een gedocumenteerde zakelijke rechtvaardiging).
• A05:2025 - Injectie: De categorie 2025-injectie omvat SOQL/SOSL-injectie en cross-site scripting (XSS).
  • Gebruik voor query-injectie bindingsvariabelen voor alle dynamische query's. Voeg invoer van gebruikers nooit rechtstreeks in querytekenreeksen aaneen. De geparametriseerde querymechanismen van het platform elimineren injectierisico's wanneer ze correct worden gebruikt.
  • SOQL- of SOSL-injecties worden beperkt tot een meting die records of velden openbaar maakt die de aanroeper niet zou kunnen bereiken door queryvoorwaarden uit te breiden. Aangezien deze talen gegevens lezen terwijl schrijven via afzonderlijke DML-bewerkingen wordt uitgevoerd, vormt dit een risico voor toegangscontrole en vertrouwelijkheid, omdat het wordt samengesteld wanneer object- en veldmachtigingen niet worden afgedwongen voor de query.
  • Voor XSS bieden Lightning webcomponenten automatische bescherming via de LWC-weergave-engine.
  • Voor Aura-componenten en Visualforce moet u platformcoderingsfuncties (bijvoorbeeld HTMLENCODE, JSENCODE en URLENCODE) toepassen bij het weergeven van dynamische inhoud.

Uw verantwoordelijkheid: Dwing CRUD/FLS af in aangepaste code, pas coderingsfuncties toe, gebruik bindingsvariabelen en bewaak configuratieafwijkingen.

Ontwerp CI/CD-pijplijnen met beveiligingspoorten in elke fase. Beveiliging moet worden geautomatiseerd om mee te schalen met de ontwikkelsnelheid.

Laten we de beveiligingsfasen van de pijplijn eens nader bekijken.

• Bronbeheer gebruikt regels voor filiaalbescherming met verplichte codebeoordelingen. Er zijn geen directe commits naar hoofdvertakkingen of ondertekende commits.
• Statische analyse gebruikt de Salesforce Code Analyzer, die PMD, ESLint en RetireJS bevat om injectie-, XSS- en onveilige patronen te detecteren.
• Scannen van beveiliging maakt gebruik van SAST-tools en detectie van geheimen om inloggegevensverbintenissen en scannen van afhankelijkheidskwetsbaarheid te voorkomen.
• Machtigingenvalidatie maakt gebruik van geautomatiseerde vergelijkingstechnieken om wijzigingen in machtigingen te beoordelen op basis van beveiligingsbaselines, waardoor waarschuwingen worden verzonden met betrekking tot het uitbreiden van machtigingen.
• Implementatiepoorten verbreken de implementatie voor kritieke beveiligingsbevindingen die goedkeuring van het beveiligingsteam vereisen voor wijzigingen die de machtigingen uitbreiden.
• Post-implementation monitoring gebruikt Event Monitoring-waarschuwingen voor afwijkend gedrag na implementaties.

Uw verantwoordelijkheid: Codeanalyzer integreren in CI/CD, filiaalbescherming configureren, implementatiepoorten implementeren en machtigingen automatisch valideren.

Uitgebreide beveiligingstests omvatten meerdere technieken die verschillende kwetsbaarheidsklassen aanpakken. Laten we elke strategie nader bekijken.

• Statische analyse voert Salesforce Code Analyzer uit in ontwikkelaars-IDE's voor onmiddellijke feedback en in CI/CD-pijplijnen als geautomatiseerde poorten. Statische analyse identificeert kwetsbaarheden in broncode zonder de toepassing uit te voeren.
• Penetratietests voeren penetratietests uit voor aangepaste toepassingen die worden blootgesteld aan niet-vertrouwde gebruikers, met name Experience Cloud-sites en openbare API's.
  • Voor AppExchange en AgentExchange Security Review zijn statische analyserapporten altijd vereist.
  • Een dynamisch scanrapport (penetratietest) is vereist wanneer de oplossing een externe webtoepassing of service integreert.
  • Penetratietests simuleren aanvallerstechnieken tegen live toepassingen.
• Op beveiliging gerichte eenheidstests schrijven Apex tests die het afdwingen van toegangscontrole valideren door ze uit te voeren als gebruikers met verschillende machtigingsprofielen. Het is belangrijk om te controleren of CRUD/FLS-afdwinging ongeoorloofde toegang blokkeert.
• Afhankelijkheidsscannen bewaakt AgentExchange-pakketten en JavaScript-bibliotheken op bekende kwetsbaarheden. Het is belangrijk om u te abonneren op beveiligingsadviezen voor geïnstalleerde pakketten.

Uw verantwoordelijkheid: Codeanalyzer uitvoeren, penetratietests uitvoeren, tests van beveiligingseenheden schrijven, afhankelijkheden scannen.

Bij Salesforce richt de respons op beveiliging en gegevensincidenten zich op het detecteren, inperken en herstellen van inbreuken, ongeoorloofde toegang en kwaadwillende gegevensvernietiging. Incidentresponsteams werken samen met twee naburige pijlers die aangrenzende verantwoordelijkheden hebben:

• Operational Excellence bestrijkt de operationele machinerie van incidentbeheer (bijvoorbeeld ernstlagen, oproeprotatie, escalatie en beoordeling na het incident)
• Betrouwbaarheid omvat herstel van beschikbaarheid ten opzichte van RTO- en RPO-doelen, inclusief back-up- en disaster-recovery-strategie.

Als architect bent u verantwoordelijk voor het ontwerpen van de detecteerbaarheid, reactie en herstel van beveiligingsincidenten.

Detecteerbaarheid is een architectonische kwaliteit waarvoor u expliciet moet ontwerpen. Zonder uitgebreide bewaking blijven beveiligingsincidenten mogelijk langere tijd onopgemerkt.

Het is belangrijk om detectie via meerdere kanalen te implementeren.

• Event Monitoring legt ruwe eventlogboeken vast die inlogpogingen, rapport- en gegevensexports, machtigingswijzigingen en API-aanroepen omvatten. U moet bepalen welke events afwijkend zijn. Hiervoor zijn beleidsvormen voor transactiebeveiliging of SIEM-correlaties vereist naast de logboeken die u configureert om de detectielogica te bepalen.
• Transactiebeveiligingsbeleidsvormen evalueren events in real-time en blokkeren verdachte acties. U moet deze beleidsvormen configureren.
• Set-up controletraject houdt de administratieve wijzigingen bij die het platform biedt, maar u moet deze bewaken.
• Aangepaste toepassingsregistratie legt beveiligingsrelevante events vast in Apex die u moet implementeren.

Routeer Event Monitoring-logboeken naar SIEM-platforms voor correlatie met telemetrie voor bedrijfsbeveiliging. Ontwerp waarschuwingsregels die verdachte patronen detecteren en tegelijkertijd vals-positieven minimaliseren door middel van baselines voor gedrag.

Uw verantwoordelijkheid: Routeer Event Monitoring naar SIEM, configureer beleidsvormen voor transactiebeveiliging, implementeer aangepast vastleggen en stel gedragsbaselines vast.

Het is belangrijk om architectonische beslissingen te documenteren die incidentrespons ondersteunen voordat incidenten plaatsvinden.

• Isolation boundaries ontwerpt oplossingen om gecompromitteerde componenten te isoleren zonder kritieke bedrijfsfuncties te verstoren. U moet de intrekking van machtigingensets, IP-beperkingswijzigingen en sessiebeëindiging configureren om snelle isolatiemogelijkheden te bieden.
• Forensische bewaring gebruikt Event Monitoring om gedetailleerde activiteitenlogboeken te bieden (platformvoorziening). Veldcontroletraject behoudt de historie van gegevenswijzigingen op basis van uw configuratie. Ontwerplogboeken routeren naar onveranderbare opslag zodat aanvallers uw architectuur niet kunnen wijzigen.
• Herstelprocedures documenteren geteste herstelprocessen voor veelvoorkomende incidenttypen. Het is belangrijk om back-upintegriteit regelmatig te valideren. U moet uw Recovery Time Objective (RTO) en Recovery Point Objective (RPO) kennen voor scenario's met beveiligingsincidenten.
• Communicatiewerkstromen ontwerpen kennisgevingsmechanismen die functioneren tijdens incidenten (bijvoorbeeld out-of-band communicatiekanalen, vooraf opgestelde sjablonen en escalatieprocedures die niet afhankelijk zijn van potentieel gecompromitteerde systemen).
• Het kwetsbaarheidskanaal is bedoeld voor openbare Experience Cloud-sites. Het biedt externe onderzoekers een gedocumenteerde, bewaakte manier om beveiligingsproblemen aan u te melden via een openbaarmakingsbeleid dat is gepubliceerd in de norm RFC 9116 security.txt. Een extern rapport is vaak het eerste signaal van een incident, dus het is belangrijk om dit intaketraject vast te stellen als onderdeel van de architectuur waarvoor u verantwoordelijk bent.

Uw verantwoordelijkheid: Documenteer isolatieprocedures, routeer logboeken naar onveranderbare externe opslag, test herstelprocedures elk kwartaal, breng out-of-band communicatie tot stand en publiceer een kanaal voor het vrijgeven van kwetsbaarheden voor openbare sites.

Bij Salesforce is het belangrijk om reactiemogelijkheden voor te bereiden voor platformspecifieke scenario's.

• Gecompromitteerde gebruikersaccounts worden gedetecteerd via inloganomalieën van Event Monitoring (bijvoorbeeld onverwachte geografie, ongebruikelijke tijden en nieuwe apparaten). Wanneer accounts worden gecompromitteerd, bevriest u de gebruiker, dwingt u het opnieuw instellen van inloggegevens af, controleert u Set-up controletraject en logboeken voor gegevenstoegang om de compromisperiode te bepalen.
• Bulkgegevensexfiltratie wordt gedetecteerd via exports van rapporten van Event Monitoring en anomalieën van API-gegevenstoegangsvolumes. Wanneer gegevensexfiltratie optreedt, trekt u sessies onmiddellijk in, beperkt u machtigingen en identificeert u betroffen records en classificatieniveaus.
• Ongeautoriseerde code-implementatie wordt gedetecteerd via implementatiebewaking en configuratiewijzigingen van Set-up controletraject. Wanneer ongeoorloofde code wordt geïmplementeerd, draait u de implementatie onmiddellijk terug en controleert u alle wijzigingen vanuit het gecompromitteerde implementatiegegeven.
• Privilege-escalatie wordt gedetecteerd via Set-up Controletrajectbewaking voor machtigingswijzigingen die buiten goedgekeurde wijzigingsperioden vallen. Wanneer escalatie van machtigingen optreedt, trekt u geëscaleerde machtigingen onmiddellijk in en controleert u activiteiten die met verhoogde toegang zijn uitgevoerd.

Uw verantwoordelijkheid: Documenteer reactieprocedures voor platformspecifieke scenario's, configureer bewaking om elk scenario te detecteren, test procedures via oefeningen op tafel.

Na een incident is het belangrijk om een beoordeling na het incident uit te voeren zonder oordeel, die is gericht op architectonische verbeteringen. U moet documenteren wat er is gebeurd, waarom de bestaande controles het incident niet hebben voorkomen of gedetecteerd, en welke architectonische wijzigingen nodig zijn om toekomstige risico's te verminderen.

Doelstellingen voor beoordeling na incident:

• Bepaal de incidenttijdlijn en technieken van de aanvaller.
• Identificeer de controlefouten die het incident hebben ingeschakeld.
• Documenteer alle architectonische zwakke punten die het incident aan het licht heeft gebracht.
• Prioriteer oplossingen die zijn gebaseerd op risicovermindering.
• Deel geleerde lessen binnen teams.
• Werk detectieregels en reactieprocedures bij.

Het is belangrijk om incidentmeetgegevens in de loop van de tijd bij te houden om de gemiddelde tijd voor detectie (MTTD), gemiddelde tijd voor respons (MTTR) en impactscope te bepalen.

Uw verantwoordelijkheid: Voer een tijdige beoordeling na het incident uit, documenteer verbeteringen in ADR's, houd MTTD- en MTTR-trends bij en deel geleerde lessen.

Gebruik deze controlelijst tijdens architectuurbeoordelingen, vóór productie-implementatie en periodiek voor doorlopende beoordeling. Elk item vertegenwoordigt uw verantwoordelijkheden als Salesforce-architect.

Gedeelde verantwoordelijkheid

• Documenteer alles wat Salesforce beveiligt (bijvoorbeeld infrastructuur, platform en nalevingscertificeringen).
• Documenteer alles wat u moet beveiligen (bijvoorbeeld configuratie, toegang, aangepaste code en gegevensbeheer).
• Identificeer gebieden met gedeelde verantwoordelijkheid (bijvoorbeeld incidentrespons, kwetsbaarheidsbeheer en bewaking).
• Communiceer verantwoordelijkheden zo duidelijk en beknopt mogelijk naar belanghebbenden en implementatieteams.

Beveiligingsarchitectuur

• Voltooi het modelleren van bedreigingen met behulp van de STRIDE-methodologie voordat u begint met samenstellen.
• Pas diepgaande besturingselementen toe op gegevens-, toepassings-, identiteits- en integratielagen.
• Implementeer zero Trust principes die expliciete verificatie vereisen voor elk toegangsverzoek.
• Onderhoud de huidige voorraad beveiligingsactivum die gevoelige gegevens, integraties, API's en bevoorrechte accounts bestrijkt.
• Documenteer beveiligingsarchitectuurbeslissingen in ADR's, inclusief dreigingsanalyse en rechtvaardiging van besturing.
• Beveilig headless en namens cliënten aan de Salesforce Trust grens door identiteiten per gebruiker te propageren in plaats van pooltokens.
• Sla OAuth-inloggegevens op, roteer ze en bereik met de minste rechten via Externe clientapps.
• Voor containerintegraties dwingt u containerisolatie af als beveiligingsgrens, versleutelt u intercontainer- en hybride VPN-verkeer met mTLS (wanneer het framework dit vereist) en stemt u implementatieregio's af op gegevensverblijf- en nalevingscertificeringen

Identiteits- en toegangsbeheer

• Stel OWD's in op Privé voor objecten die gevoelige gegevens bevatten.
• Reserveer Openbaar alleen-lezen voor objecten waarvoor brede leestoegang een gedocumenteerde vereiste is.
• Dwing MFA af voor alle toegang tot de productie-UI en hardwarebeveiligingssleutels voor accounts met veel machtigingen. API-only integraties die gebruikmaken van JWT Bearer- of clientinloggegevens zijn vrijgesteld.
• Implementeer SSO met behulp van SAML 2.0 of OpenID Connect met sterke IdP-authenticatie.
• Gebruik OAuth 2.0 (bij voorkeur JWT-bearer) voor alle API-authenticatie. Gebruik OAuth 2.0 nooit voor ingebedde inloggegevens.
• Verleen toegang via machtigingensets die zijn gebaseerd op gedocumenteerde vereisten voor de minste rechten.
• Pas uitgebreide besturingselementen toe op accounts met kritieke gevolgen (bijvoorbeeld IP-beperking, inlogwaarschuwingen en periodieke toegangsbeoordelingen).
• Voer periodieke toegangsbeoordelingen uit met behulp van gedocumenteerde attesten voor accounts met hoge machtigingen, waarbij de frequentie wordt bepaald door organisatorische risicotolerantie en nalevingsvereisten.
• Automatiseer de identiteitslevenscyclus via SCIM-leveringen en detectie van 90 dagen slapende accounts.
• Werknemersagenten uitvoeren in de context van de ingelogde gebruiker en speciale Agentgebruikers met de minste rechten leveren voor klantagenten. Doe dit nooit voor een gastgebruiker op een openbare site.
• Implementeer JWT voor agentauthenticatie met behulp van identifiers van agentinstanties en botdefinities.
• Definieer ABAC-beleidsvormen die overeenkomen met standaarden voor gegevensclassificatie en consistente tags voor metagegevens.

Gegevensbescherming en privacy

• Classificeer alle gegevens en pas beschermingselementen toe die geschikt zijn voor elk classificatieniveau.
• Schakel Shield Platform Encryption voor beperkte gegevens in met behulp van gedocumenteerd sleutelbeheer.
• Vereist TLS 1.2+ voor alle integraties met op een certificaat gebaseerde auth. voor beperkte gegevens.
• Voorkom dat beperkte gegevens niet-productieomgevingen binnenkomen via maskeren of uitsluiting.
• Implementeer instemmingsbeheer met fijnmazige werkstromen voor bijhouden en intrekken per doel.
• Stel werkstromen voor de rechten van betrokkenen samen die worden voltooid binnen de reactiedeadline van elk regelgevend raamwerk. Deze moeten worden gedimensioneerd tot het krapste tijdsbestek in uw operationele voetafdruk en per rechtsgebied worden geparameterd vanuit een onderhouden nalevingsbron waarbij elk cijfer wordt bevestigd ten opzichte van de regelgeving.
• Documenteer vereisten voor gegevensverblijf en valideer Hyperforce regio-uitlijning.

Naleving en naleving van regelgeving

• Valideer platformcertificeringen die voldoen aan de wettelijke vereisten voor uw sector.
• Schakel Event Monitoring met SIEM-routering in voor retentie die native bewaarlimieten overschrijdt.
• Configureer Veldcontroletraject om beperkte velden te bestrijken om ervoor te zorgen dat bewaring voldoet aan wettelijke minimumvereisten.
• Handhaaf scores voor Controle van beveiligingstoestand van 80% of hoger (band Zeer goed of Uitstekend) en leg eventuele uitzonderingen vast.
• Automatiseer nalevingsvalidatie voor CI/CD-pijplijnen die kapot gaan tijdens kritieke schendingen.
• Implementeer transactiebeveiligingsbeleid voor realtime anomaliedetectie en -respons.

Beveiligde ontwikkelingslevenscyclus

• Voer bedreigingsmodellering uit tijdens de ontwerpfase (voordat u aanzienlijke investeringen in bouwen doet).
• Dwing CRUD/FLS af in alle Apex omgevingen.
• Vertrouw op automatische afdwinging van de gebruikersmodus voor API-versie 67.0 of hoger, of gebruik WITH USERMODE of stripInaccessible() voor API-versie 66.0 of lager.
• Gebruik WITH SECURITYENFORCED niet, dat is verwijderd in API-versie 67.0.
• Voer Salesforce Code Analyzer uit in CI/CD wanneer kritieke bevindingen de implementatie blokkeren.
• Codebeoordelingen door beveiligingsbewuste beoordelaars vereisen voor alle productiewijzigingen.
• Voer penetratietests uit voor alle openbare toepassingen en Experience Cloud-sites.
• Valideer en zuiver alle gebruikersinvoer die injectie binnen SOQL-, SOSL- en HTML-contexten voorkomt.

Beveiligingsincidentrespons

• Ontwerp waarschuwingsregels voor Event Monitoring om verdachte patronen te detecteren via gedragsuitgangswaarden.
• Routeer logboeken naar onveranderbare externe opslag voor forensische bewaring.
• Documenteer en test incidentresponsprocedures voor platformspecifieke scenario's.
• Voer onberispelijke beoordelingen na het incident uit met ADR's om architectonische verbeteringen vast te leggen.
• Houd MTTD- en MTTR-meetgegevens bij om detectie- en reactiehiaten te identificeren.

Deel uw feedback over het Goed Architectuurde Framework.