Lees hier meer over onze updateschema's.

Een beveiligd systeem beschermt belanghebbenden en gegevens van een organisatie. Veilige architecturen verifiëren gebruikersidentiteiten, beperken gegevenstoegang tot alleen noodzakelijke informatie en voorkomen dat gegevens worden gecompromitteerd.

Salesforce geeft prioriteit aan Customer Trust en gegevensbeveiliging. Het Salesforce Platform zorgt voor privacy en beveiliging. Realtime systeemprestaties en beveiligingsinformatie zijn beschikbaar bij Salesforce Trust.

Het beschermen van uw organisatie- en klantgegevens is de basis voor het samenstellen van veilige Salesforce-oplossingen. Als Salesforce-architect bent u verantwoordelijk voor het beveiligen van uw organisatie- en klantgegevens door middel van de ingebouwde beveiligingsvoorzieningen van Salesforce. Houd bij het nemen van deze beslissingen rekening met geografische distributie, sector, bedrijfsprocedures en typen klantgegevens.

U kunt uw oplossingen veiliger maken door u te richten op drie gebieden: organisatorische beveiliging, sessiebeveiliging en gegevensbeveiliging.

Organisatorische beveiliging beschermt systemen tegen ongeoorloofde toegang door ervoor te zorgen dat alleen gevalideerde, geautoriseerde gebruikers toegang hebben tot een systeem en alleen noodzakelijke voorzieningen en gegevens.

Tekenen dat u een problematische organisatorische beveiliging hebt, zijn:

• Ad-hocprocessen om gebruikers te activeren of deactiveren
• Onduidelijke stappen voor het bijwerken van autorisatie voor wijzigingen in gebruikers- of systeemrollen
• Vertrouwen op de institutionele Knowledge van individuen voor correcte toewijzingen van gebruikersbeveiliging
• Niet in overeenstemming zijn met bestaande beveiligingskaders of best practices uit de sector
• Ontbreken van een gestructureerd raamwerk voor gegevensgovernance en ondersteunend beleid

U kunt betere organisatorische beveiligingscontroles voor uw Salesforce-organisaties samenstellen door u te richten op authenticatie en autorisatie.

Authenticatie is cruciaal voor beveiligings- en toegangsbeheer, waarbij de identiteit wordt geverifieerd van gebruikers die proberen toegang tot uw systeem te krijgen. Dit geldt voor zowel menselijke gebruikers (medewerkers, klanten) als geautomatiseerde gebruikers (externe systemen, integraties), waarbij elk gebruikerstype specifieke authenticatieschema's vereist. Als u veilige toegang wilt garanderen tot alle Salesforce-invoerpunten in uw organisatie, moet u verschillende authenticatiemethoden instellen.

Veilige authenticatiestromen maken in Salesforce:

• Maak Salesforce-gebruikers op basis van individuen, niet op basis van identiteiten. De ingebouwde controlemogelijkheden van Salesforce zijn het meest effectief wanneer elke gebruikersaccount overeenkomt met één individu dat toegang heeft tot het platform. Het gebruik van gedeelde gebruikersaccounts compromitteert de effectiviteit van deze controles, introduceert extra beveiligingskwetsbaarheden, escaleert de potentiële gevolgen van accountinbreuken en bemoeilijkt uw vermogen om effectieve autorisatieschema's te maken. Dit omvat gebruikersaccounts voor integratiegebruikers.
• Op UI gebaseerde toegangsscenario's beveiligen. De meeste menselijke gebruikers hebben een soort op UI gebaseerde toegang (vaak inlogtoegang genoemd) nodig voor een Salesforce-organisatie. Salesforce biedt verschillende beschermingslagen voor deze inlogscenario's, waaronder:
  • Wachtwoordbeleid. Cybercriminelen richten zich vaak op gebruikersnamen en wachtwoorden om ongeoorloofde toegang tot toepassingen te krijgen. Hoewel het configureren van wachtwoordbeleidsvormen een fundamentele stap is in het beschermen van inlogtoegang, is het belangrijk om te weten dat dit alleen niet voldoende is, aangezien Salesforce overschrijvingen per gebruiker van deze beleidsvormen toestaat.
  • Multi-factorenauthenticatie (MFA). Salesforce vereist MFA voor alle op UI gebaseerde gebruikerslogins. MFA biedt een essentiële verdediging tegen inloggegevenslekken en brute-force-aanvallen door gebruikers te verplichten een extra vorm van identificatie of factor op te geven nadat ze hun gebruikersnaam en wachtwoord hebben ingevoerd. Deze extra factor heeft doorgaans een fysieke vorm, zoals een mobiel apparaat, beveiligingssleutel of biometrische markering.
  • Single Sign-On (SSO). In SSO-scenario's gebruiken gebruikers slechts één set inloggegevens voor alle toepassingen van een organisatie. Toegang tot systemen wordt geleverd en beheerd vanaf een centrale locatie, wat de beveiliging verbetert. Salesforce kan optreden als serviceprovider of identiteitsleverancier in SSO-scenario's. Zorg ervoor dat sommige of alle beheerders rechtstreeks bij Salesforce kunnen inloggen, zodat ze storingen of problemen met uw SSO-implementatie kunnen oplossen.
  • Post-login stappen. Voor sommige gebruikscases vereist u mogelijk dat gebruikers aanvullende stappen voltooien voordat ze toegang krijgen tot uw systeem. Aangepaste inlogstromen kunnen worden geïmplementeerd om gebruikers door deze extra processtappen te begeleiden. Voorbeelden omvatten:
    • Algemene voorwaarden accepteren
    • Werken met scenario's voor inlogontdekking en inloggen zonder wachtwoord
    • Het aantal gelijktijdige Salesforce-sessies per gebruiker beperken om de kans op sessiegebaseerde aanvallen te verkleinen (zie sessiebeveiliging).
    • Verbinden met geofencing-services
• Veilige op API gebaseerde toegangsscenario's. Elke gebruiker kan op API gebaseerde toegang aanvragen voor een Salesforce-organisatie. Salesforce biedt verschillende beschermingslagen voor op API gebaseerde scenario's, waaronder:
  • API-toegangscontrole. Zonder API-toegangscontrole kan iedereen met een geldige set inloggegevens elke app gebruiken om verbinding te maken met uw organisatie, zelfs als de verbonden app niet is geïmplementeerd in de organisatie. Controles voor gegevenstoegang worden nog steeds afgedwongen, maar gebruikers kunnen op ongecontroleerde manieren toegang krijgen tot informatie. Zo kan een app worden gebruikt om grote hoeveelheden gegevens te downloaden of zelfs beschadigde informatie te uploaden zonder goedkeuring van een systeembeheerder.
  • API Only-machtigingen. U kunt API Only-gebruikersmachtigingen configureren in Salesforce. Wijs dit als onderdeel van een machtigingenset toe aan alle geautomatiseerde of integratiegebruikersidentiteiten om op UI gebaseerde toegang volledig te blokkeren.
  • Certificaten en sleutels. Met certificaten en sleutels kan Salesforce valideren dat aanvragen afkomstig zijn van geautoriseerde bedrijven of bedrijven. U moet certificaten en sleutels configureren als u SSO met Salesforce wilt gebruiken.
  • Verbonden apps. Als u verbonden apps in Salesforce configureert, kunt u externe systeemtoegang tot Salesforce beheren, inclusief vereiste authenticatieprotocollen, autorisatiebereik en sessiewerking in één definitie.
  • Benoemde inloggegevens. Met benoemde inloggegevens kunt u externe toegangspunten en authenticatieprotocollen beheren in één definitie binnen Salesforce. Gebruik ze voor het veilig definiëren en beheren van authenticatie voor aanroepen vanuit Apex, externe services en Salesforce Connect gegevensbronnen.
• Agentforce Agent Users Authentication. Agentforce agenten, gebouwd op Salesforce, gebruiken agent-gebruikerobjecten met beheerbare machtigingen, net als die van echte gebruikers. Wanneer u een agent instelt, stemt u de toegang zorgvuldig af op de rol die de agent speelt, waarbij u gegevenstoegang beperkt tot alleen wat nodig is om de eindgebruikers te bedienen. Net zo belangrijk is dat agenten kunnen worden geconfigureerd met zowel openbare als privéacties. Voor privéacties valideert en authenticeert u eindgebruikers, waarbij u ze toewijst aan agentcontext. Hierdoor kan de agent zich voordoen als en werken binnen de toegangscontroles van de eindgebruiker, waarbij beveiliging en Trust behouden blijven.

De onderstaande lijst met patronen en antipatronen toont hoe de juiste (en slechte) authenticatiearchitectuur eruitziet in een Salesforce-organisatie. Gebruik deze om uw ontwerpen te valideren voordat u gaat bouwen of om mogelijkheden voor verdere verbeteringen te identificeren.

Zie Tools Relevant to Secure voor meer informatie over authenticatietools die beschikbaar zijn vanuit Salesforce.

Autorisatie definieert tot welke voorzieningen, functionaliteit en gegevens een gebruiker toegang heeft, alsmede de acties die deze met deze resources kan uitvoeren nadat deze is geauthenticeerd. Autorisatiebesturingselementen zijn niet alleen voor menselijke gebruikers, ze moeten ook worden afgestemd op Agentforce Agent-gebruikers, met name agenten die services leveren aan niet-geauthenticeerde eindgebruikers.

Hoewel het beperken van wie kan authenticeren bij uw organisatie een cruciale eerste stap is, is het net zo belangrijk om sterke authenticatie te koppelen aan robuuste autorisatie. Zonder adequate autorisatiecontroles kunnen gebruikers mogelijk records maken, bewerken en verwijderen of toegang krijgen tot systeemfunctionaliteit op manieren die schadelijk zijn voor uw bedrijf en uw belanghebbenden. Gebrekkige autorisatiecontrole kan ook het gebruik van systemen bemoeilijken. Door te bepalen wat gebruikers binnen het systeem kunnen doen, bevordert u een hoger niveau van Trust, waarbij zowel uw systeem als uw gebruikers worden beschermd.

Veilige autorisatieschema's voor Salesforce samenstellen:

• Volg het principe van de minste rechten. Omarm het principe van de minste rechten (PoLP) door aan gebruikers alleen de benodigde machtigingen voor hun taken toe te wijzen. Ontwerp voor het volgen van dit principe fijnmazige en modulaire machtigingensets. Dit maakt geavanceerde toegangscontroles mogelijk via groepen machtigingensets, waardoor machtigingen nauwkeurig kunnen worden beheerd, inclusief de mogelijkheid om machtigingen te dempen, vervaldatums in te stellen en meer. Stem functionele eenheden van uw systeem af op bedrijfsmogelijkheden om fijnmazige machtigingen en effectieve groepen machtigingensets te definiëren. Vergeet niet dat machtigingen van toepassing zijn op toegang tot metagegevens in Salesforce. Zie Delen en zichtbaarheid voor details over het configureren van PoLP voor Salesforce-gegevenstoegang.
• Denk aan gebruikerstoegang in termen van identiteiten, niet in termen van individuen. Autorisatie (of beveiliging in het algemeen) in termen van individuele gebruikers zal uw systeem niet instellen op schaal en ontwikkeling. Ontwerp en beheer in plaats daarvan identiteiten die groepen gebruikers vertegenwoordigen. Veilige Salesforce-oplossingen gebruiken individuen voor authenticatie en identiteiten voor autorisatie. Door beveiligingsconfiguraties voor afzonderlijke identiteiten te definiëren, krijgt u gedetailleerde controle over toegang en privileges in uw beveiligingsmodel, waardoor de noodzaak van refactoren op de lange termijn wordt geminimaliseerd. Neem de beveiligingsidentiteiten die u definieert op in uw ontwerpstandaarden en documentatie.
• Bepaal gebruikerstoegang tot metagegevens met behulp van machtigingensets en groepen machtigingensets. Machtigingensets en groepen machtigingensets bepalen tot welke metagegevens gebruikers toegang hebben en wat ze met die metagegevens kunnen doen. Zie Metagegevens versus gegevens voor meer informatie over Salesforce-metagegevens. Configureer apptoewijzingen, activeringen van voorzieningenlicenties, toegang tot beheerde pakketten, systeemmachtigingen, toegang tot CRUD en toegang op veldniveau via machtigingensets en groepen machtigingensets. Neem deze toegang op in uw ontwerpnormen en documentatie.
• Gebruik standaardinstellingen voor de hele organisatie (OWD's) en delen om gegevenstoegang voor gebruikers te bepalen. Gegevens en metagegevens zijn afzonderlijke entiteiten in Salesforce, waarvoor afzonderlijke toegangscontroles vereist zijn. Gebruik OWD's en ingebouwde tools voor delen om toegang tot Salesforce-gegevens (afzonderlijke records, bestanden en documenten) te configureren. Zie Gegevensbeveiliging voor meer informatie.
• Gebruik OAuth-bereiken om toegang voor verbonden apps te bepalen. Wanneer u een verbonden app configureert, definieert u het bereik of de toegangsmachtigingen die appgebruikers krijgen voor Salesforce-resources. Zie Sessiebeheer voor meer informatie over het beheer van OAuth-tokens.
• Maak één Salesforce-gebruiker voor elke integratie. Als u zich wilt houden aan het principe van de minste rechten, maakt u voor elke integratie een unieke Salesforce integratiegebruiker. Hierdoor kunt u specifieke gegevenstoegang toewijzen, de controle over bewerkingen verbeteren, de traceerbaarheid van transacties garanderen en de impact van potentiële beveiligingsinbreuken minimaliseren.
• Implementeer unieke accounts met de PoLP voor alle Agent-gebruikers. Elke Agentforce Agent-gebruiker moet uniek zijn en mag niet worden hergebruikt voor meerdere agenten. Machtigingen voor deze accounts moeten strikt voldoen aan het principe van de minste rechten. Houd er rekening mee dat acties die worden uitgevoerd door een agentgebruiker, kunnen werken in een context van verhoogde beveiliging binnen Salesforce of tegen externe systemen die Salesforce-toegangscontroles niet respecteren. Dit kan ertoe leiden dat acties toegang krijgen tot of gevoelige informatie onthullen aan gebruikers.
• Minimaliseer het gebruik van profielen en migreer eventuele toegangscontroles uit profielen. Profielen bieden de mogelijkheid om toegang te beperken tot inlog-IP-bereiken, inlog-uren en voorzieningen die specifiek zijn voor de verouderde Salesforce Classic gebruikersinterface (met name standaard recordtypen en paginalay-outtoewijzingen). Alle andere functionaliteit die zich momenteel in profielen bevindt, moet worden gemigreerd naar equivalente functionaliteit in machtigingensets en groepen machtigingensets. Functionaliteit in uw profielen die zijn gekoppeld aan Salesforce Classic UI-voorzieningen, moet worden gericht op herstel.

De onderstaande lijst met patronen en antipatronen toont hoe goede (en slechte) autorisatiepraktijken eruitzien in een Salesforce-organisatie. Gebruik deze om uw ontwerpen te valideren voordat u gaat bouwen of om mogelijkheden voor verdere verbeteringen te identificeren.

Zie Tools Relevant to Secure voor meer informatie over autorisatietools die beschikbaar zijn vanuit Salesforce.

Deze tabel toont een selectie van patronen die u in uw organisatie kunt zoeken (of samenstellen) en antipatronen die u kunt vermijden of die u kunt gebruiken voor herstel.

✨ Ontdek meer patronen voor organisatorische beveiliging in de Patroon & Anti-patroon Explorer.

Een sessie is de reeks verzoeken en reacties die zijn gekoppeld aan een gebruiker over een bepaalde periode. Een sessie wordt geïnitieerd wanneer een gebruiker zich met succes bij Salesforce authenticeert. Sessiebeveiliging is het configureren van uw systeem om ongeoorloofde toegang en gegevensinbreuken te voorkomen door sessie-interferentie of kaping te dwarsbomen.

Alle gebruikersactiviteit in uw systeem vindt plaats binnen de context van een sessie, dus het is van cruciaal belang om rekening te houden met de manier waarop sessies worden geïnitieerd, wat er kan plaatsvinden tijdens een sessie, welke apparaten gebruikers gaan (en moeten) gebruiken, en hoe verdacht of afwijkend sessiegedrag te detecteren en erop te reageren.

U kunt sessiebeveiliging in Salesforce samenstellen door u te richten op drie sleutels: sessiebeheer, apparaattoegang en detectie en reactie van bedreigingen.

Sessies worden geïnitieerd wanneer een gebruiker met succes authenticeert en toegang krijgt tot Salesforce. Met deze sessies kan het platform specifieke verzoeken en reacties koppelen aan die specifieke gebruiker.

Het HTTPS-protocol vergemakkelijkt de communicatie tussen een front-endclient en het Salesforce Platform. Clients kunnen browsers, mobiele toepassingen, lokale toepassingen, enzovoort omvatten. HTTPS is een staatloos protocol, wat betekent dat elke communicatie discreet is en niet gerelateerd is aan eerdere of toekomstige communicatie.

Deze stateless benadering versnelt netwerkcommunicatie en elimineert fouten die worden veroorzaakt door verbroken koppelingen tussen pakketten. Webapps hebben echter nog steeds een manier nodig om de identiteit van elke gebruiker en andere gerelateerde informatie bij te houden voor meerdere verzoek- en reactie-interacties. Salesforce bereikt dit, net als de meeste webtoepassingen, met behulp van sessies en tokens.

• Met sessies kan Salesforce verzoeken en reacties koppelen aan gebruikers. Nadat een gebruiker is geauthenticeerd, stuurt het platform een sessie-ID terug naar de clientapp, die deze ID bevat bij alle gebruikersverzoeken (zoals navigeren, zoeken en gegevens indienen).
• Met tokens kunnen gebruikers en verbonden toepassingen hun identiteit eenmalig verifiëren en vanaf dat moment een uniek toegangstoken gebruiken. Tokens hebben een beperkte levensduur en bieden alleen toegang tot specifieke resources (zie Autorisatie voor meer informatie over het configureren van toegangsniveaus). Tokens geven toegang tot geautoriseerde resources zonder dat gebruikers hoeven in te loggen.

Als sessies en tokens niet op de juiste manier zijn beveiligd, kunnen kwaadwillenden deze verstoren en zich voordoen als gebruikers of kwaadaardige code uitvoeren in uw systeem.

Veilig sessiebeheer voor Salesforce samenstellen:

• Begrijp hoe Salesforce sessietypen classificeert. Identificeer goedgekeurde sessietypen en wijs deze toe aan identiteiten van beveiligingsgebruikers, en leg deze vast in uw documentatie.
• Bepaal hoe sessies kunnen ontstaan en waar sessieverkeer naartoe kan gaan. Zodra u hebt bepaald welke soorten sessies verschillende gebruikersidentiteiten mogen starten, configureert u besturingselementen om sessies te blokkeren die afkomstig zijn uit niet-goedgekeurde bronnen of contexten. Salesforce biedt verschillende manieren om de herkomst en het verkeer van sessies te controleren, waaronder:
  • Ingebouwde sessiebescherming. Salesforce schakelt automatisch bescherming voor de hele organisatie in voor op sessies gebaseerde kwaadaardige activiteiten, waaronder cross-site scripting, cross-site verzoekvervalsing, content sniffing, clickjacking en meer. Deze beveiligingen mogen nooit worden uitgeschakeld; sommige kunnen niet worden uitgeschakeld.
  • Domeinen en IP-bereiken. Alle Salesforce-organisaties hebben Mijn domein standaard ingeschakeld, waardoor een bedrijfsspecifiek subdomein voor Salesforce-toegang wordt gemaakt. U kunt de aan een organisatie gekoppelde naam aanpassen of wijzigen via Mijn domein. Daarnaast ondersteunt Salesforce extra domeinconfiguraties voor Experience Cloud-sites en andere toepassingspagina's. Opmerking: Als uw gebruikers toegang nodig hebben tot Salesforce vanachter een bedrijfsfirewall, voegt u de vereiste domeinen toe aan de goedgekeurde lijsten van uw firewall. U kunt inlog-IP-bereiken en vertrouwde IP-bereiken instellen om inkomende inlog- en sessieverzoeken aan Salesforce te beheren.
  • Inloguren. Als bepaalde gebruikersidentiteiten werkuren hebben ingesteld, kunt u hun toegang tot Salesforce buiten gedefinieerde inloguren beperken.
• Beheer activiteiten die extra beveiliging op sessieniveau vereisen. Standaard kunnen sessies twee soorten beveiligingsniveaus hebben: standaard en grote zekerheid. Gebruik deze beveiligingsniveaus om te bepalen hoe gebruikers wel en niet activiteiten kunnen uitvoeren, zoals toegang tot rapporten en dashboards, of het beheren van de beveiligingsconfiguraties in een Salesforce-organisatie. Beleidsvormen voor beveiliging op sessieniveau kunnen vereisen dat gebruikers sessies met grote zekerheid opzetten om bewerkingen uit te voeren of gebruikers blokkeren om gevoelige bewerkingen uit te voeren.
• Beheer activiteiten die toegevoegde op sessie gebaseerde machtigingen vereisen. Salesforce ondersteunt op sessies gebaseerde machtigingenactiveringen om gebruikers tijdelijk verhoogde autorisatie of toegang tot machtigingen te verlenen tijdens een bepaalde sessie. U kunt op sessies gebaseerde machtigingen activeren en deactiveren via Flow- of Salesforce-API's.
• Beheer inactieve gebruikerssessies via time-outs. Het beëindigen van inactieve sessies is een belangrijk onderdeel van het beheren van sessiebeveiliging. Dit helpt uw systeem te beschermen wanneer een gebruiker bijvoorbeeld een Salesforce-sessie open laat in een browsertabblad, maar actief in een andere toepassing werkt, of wanneer het mobiele apparaat van een gebruiker is ingelogd bij Salesforce, maar onbeheerd is. Salesforce heeft een standaardtime-out voor sessie-inactiviteit van twee uur. U kunt time-outniveaus voor sessie-inactiviteit verhogen of verlagen, maar time-outs verhogen mag alleen worden gedaan met een dwingende en goed gedocumenteerde rechtvaardiging.
• Beheer sessies van verbonden apps via tokenconfiguratie. Wanneer u een verbonden app configureert, definieert u ook het bereik, of het niveau van autorisatie, dat wordt verleend aan gebruikers die toegang tot Salesforce krijgen via de verbonden app. Dit bereik wordt afgedwongen op sessieniveau door middel van OAuth-tokens, die worden uitgegeven nadat een gebruiker van een verbonden app zich met succes heeft geauthenticeerd. U kunt bepalen hoe lang een token geldig moet zijn via beleidsvormen voor tokenvernieuwing. Organisatiebeheerders kunnen tokens handmatig intrekken per gebruiker en per organisatie, indien nodig.

De onderstaande lijst met patronen en antipatronen toont hoe goed (en slecht) sessiebeheer eruitziet in een Salesforce-organisatie. Gebruik deze om uw ontwerpen te valideren voordat u gaat bouwen of om mogelijkheden voor verdere verbeteringen te identificeren.

Zie Tools Relevant voor Secure voor meer informatie over sessiebeheertools die beschikbaar zijn vanuit Salesforce.

In de huidige context is een apparaat elk stuk elektronische apparatuur dat een individu gaat gebruiken om toegang te krijgen tot Salesforce, zoals een desktopwerkstation, laptop, tablet of mobiele telefoon.

Draagbare apparaten bieden gebruikers de flexibiliteit om vanaf elke locatie toegang tot Salesforce te krijgen. Dit gemak introduceert echter potentieel extra aanvalsvectoren voor kwaadwillende actoren. Deze bedreigingsvectoren variëren van eenvoudige tactieken, zoals schoudersurfen op een openbare plaats om inloggegevens te stelen, tot meer geavanceerde methoden zoals het installeren van malware op een apparaat of het maken van een nep openbaar Wi-Fi-netwerk om gegevensoverdrachten te onderscheppen. Daarom is het beveiligen van apparaten — met name draagbare apparaten — essentieel voor de algehele systeembeveiliging.

Toegang tot apparaten beveiligen voor Salesforce:

• Gebruik de oplossingen van de mobiele app die Salesforce biedt. Laat gebruikers op mobiele apparaten die toegang tot Salesforce nodig hebben, de officiële Salesforce-apps gebruiken. Als bedrijfsbehoeften een aangepaste mobiele oplossing vereisen, moet u de Salesforce Mobile SDK gebruiken, die methoden voor veilige authenticatie en autorisatie biedt.
• Ontwerp het gebruik van mobiele apparaten in uw sessiebeheer. Sessiebeveiligingsniveaus, sessietime-outs en andere sessiecontextbesturingselementen moeten rekening houden met eventuele verwachte toegang van gebruikers op mobiele apparaten. Denk na over welke apparaten wel en welke gebruikers geen toegang moeten hebben tot Salesforce en welke soorten gebruikers toegang moeten hebben tot mobiele sessies. Neem standaarden voor mobiele toegang op in de documentatie van uw beveiligingsidentiteit. Zie Sessiebeheer voor meer informatie over dit onderwerp.
• Vul beveiliging op apparaatniveau aan met Mobile Device Management-technologie (MDM). De Salesforce-apps voor iOS en Android zijn compatibel met veel populaire MDM-suites. U kunt extra toegangsbesturingselementen configureren voor de Salesforce-app op gebruikersapparaten via uw favoriete MDM-oplossing.
• Vul beveiliging op appniveau aan met Mobile Application Management-technologie (MAM). MAM-technologie ondersteunt besturingselementen op appniveau op mobiele apparaten. Salesforce biedt een betaalde MAM-uitbreiding voor mobiele Salesforce-apps.

De onderstaande lijst met patronen en antipatronen toont hoe goed (en slecht) apparaatbeheer eruitziet in een Salesforce-organisatie. Gebruik deze om uw ontwerpen te valideren voordat u gaat bouwen of om mogelijkheden voor verdere verbeteringen te identificeren.

Zie Tools Relevant to Secure voor meer informatie over apparaatbeheertools die beschikbaar zijn vanuit Salesforce.

Dreigingsdetectie is het proces waarbij gedragspatronen in uw systeem worden geïdentificeerd die kunnen duiden op kwaadwillige activiteit. Dit kan gaan om grotere dan gemiddelde volumes aan gegevens die worden gedownload of om het wijzigen van velden met gevoelige gegevens voor verschillende records binnen een korter dan gemiddeld tijdsbestek. Reacties op bedreigingen kunnen geautomatiseerde sessieverval, waarschuwingen en andere kennisgevingen omvatten.

Het doel van dreigingsdetectie is om potentiële problemen zo snel mogelijk te identificeren en erop te reageren. Actie ondernemen op basis van real-time dreigingsdetectie kan kwaadwillig gedrag in de sporen stoppen. Salesforce biedt realtime eventbewaking als uitbreiding of als onderdeel van Salesforce Shield. Gebruik een van deze oplossingen als u zeer gevoelige toepassingen hebt of robuuste realtime detectie- en reactiemogelijkheden voor bedreigingen nodig hebt.

Als u een effectieve strategie voor dreigingsdetectie en -respons wilt samenstellen voor uw Salesforce-oplossingen:

• Gebruik ingebouwde controlemogelijkheden. Salesforce biedt een verscheidenheid aan ingebouwde tools om wijzigingen in uw organisatie bij te houden en te controleren. Zo kunt u met het Set-up controletraject de controlehistorie van beheeracties weergeven. Salesforce houdt wijzigingen op veldniveau standaard voor een beperkte periode bij, maar u kunt Veldhistorie bijhouden activeren om veldwijzigingen gedurende maximaal 18 maanden weer te geven in de UI en maximaal 24 maanden via de API. Daarnaast kunt u Field Audit Trail activeren om een controlehistorie voor wijzigingen op veldniveau voor onbepaalde tijd te bewaren (totdat u de gegevens handmatig verwijdert).
• Regelmatige controlebeoordelingen opstellen. Controle is cruciaal voor het identificeren van abnormale wijzigingen die realtime dreigingsdetectie mogelijk over het hoofd ziet. Denk aan een scenario waarin een gebruiker met legitieme toegang consistent een klein aantal records per dag gedurende een langere periode verwijdert. Aangezien deze gebruiker geldige inloggegevens heeft, de juiste autorisatie heeft om records te verwijderen en geen groot volume records tegelijk verwijdert, is het onwaarschijnlijk dat de activiteit als een real-time bedreiging wordt gedetecteerd. Een auditteam dat gebruikersactiviteitsrapporten beoordeelt, zou deze trend van buitensporige verwijdering van records door één gebruiker in de loop van de tijd echter duidelijk aan het licht brengen, waardoor het gemakkelijker wordt om dit aan te pakken. Als onderdeel van uw governancebeleid stelt u regelmatige intervallen in voor het controleren van de inloghistorie, gebruikerssessieactiviteit en gebruik van verbonden apps.
• Ontwikkel een dreigingsresponsstrategie en neem deze op in uw beveiligingsbeleid. Maak een strategie voor dreigingsrespons die het volgende omvat:
  • Definities van typen dreigingsreacties (bijvoorbeeld waarschuwingen en automatiseringen) en alle belanghebbendengroepen die betrokken moeten zijn. Zie Fouten en kennisgevingen voor meer informatie over het ontwerpen van berichten of waarschuwingen.
  • Specifieke categorieën voor realtime wijzigingen of activiteiten die als bedreigingen kunnen worden beschouwd, en het gekoppelde reactietype voor elke categorie
  • Een duidelijke lijst van alle geautomatiseerde dreigingsreacties (zoals het intrekken van tokens, beëindigen van sessies, deactiveren van gebruikersaccounts of blokkeren van toegang tot resources) en automatiseringstriggers

Event Monitoring biedt de gegevens die nodig zijn om dit principe af te dwingen door realtime detectie en reactie van bedreigingen in te schakelen. Transactiebeveiliging past de beleidsgestuurde acties van uw bedrijf toe en eventtypen ondersteunen de bewaking van gebruikers- en toepassingstoegang in de loop van de tijd.

De native service Dreigingsdetectie van Salesforce gebruikt statistische en machine learning-modellen om verdacht gedrag te identificeren. Deze service genereert specifieke events die beschermen tegen cyberaanvallen en toegang tot verdachte gegevens.

Transactiebeveiliging gaat nog een stap verder omdat het een raamwerk biedt dat belangrijke events onderschept die in uw organisatie plaatsvinden en de beleidsgestuurde acties van uw bedrijf toepast. Hierdoor wordt Event Monitoring van een vastleggingstool een belangrijke component van een geautomatiseerde beveiligingsverdediging.

De onderstaande lijst met patronen en antipatronen toont hoe de juiste (en slechte) detectie en reactie van bedreigingen eruitziet in een Salesforce-organisatie. Gebruik deze om uw ontwerpen te valideren voordat u gaat bouwen of om mogelijkheden voor verdere verbeteringen te identificeren.

Zie Tools Relevant voor Secure voor meer informatie over tools voor dreigingsdetectie, waarschuwing en responsautomatisering die beschikbaar zijn vanuit Salesforce.

Deze tabel toont een selectie van patronen die u in uw organisatie kunt zoeken (of samenstellen) en antipatronen die u kunt vermijden of die u kunt gebruiken voor herstel.

✨ Ontdek meer patronen voor sessiebeveiliging in de Patroon & Anti-patroon Explorer.

Gegevensbeveiliging is de praktijk van het beschermen van uw gegevens tegen ongeoorloofde toegang, corruptie of onbedoelde verwijdering. Gegevensbeveiliging omvat het beschermen van gegevens zowel onderweg als in ruste.

Sterke gegevensbeveiliging minimaliseert de risico's en potentiële schade door ongeoorloofde toegang tot uw systeem. Gebrekkige gegevensbeveiliging maakt systemen kwetsbaar voor gegevensinbreuken, die ernstige gevolgen kunnen hebben voor klanten en uw bedrijf. Daarom is het beschermen van uw gegevens essentieel voor het bouwen van veilige architecturen.

Het verbeteren van gegevensbeveiliging begint met een duidelijk inzicht in wat als gegevens binnen Salesforce wordt beschouwd, samen met de classificatie ervan. De afzonderlijke records, bestanden en documenten die zijn opgeslagen in een Salesforce-organisatie, zijn de gegevens ervan. Zie Basisprincipes van Salesforce-architectuur voor meer informatie over het onderscheid tussen metagegevens en gegevens.

U kunt uw Salesforce-oplossingen beter beveiligen door u te richten op delen en zichtbaarheid en het gebruik van encryptie.

Opmerking: Wanneer u ontwerpt voor gegevensbeveiliging, moet u rekening houden met gegevensprivacy en archiveren en opschonen, aangezien beide concepten van invloed zijn op de algemene gegevensbeveiliging van uw oplossingen.

Identificeer en classificeer alle gegevens die zijn opgeslagen binnen het Salesforce-platform op basis van de gevoeligheid ervan (bijv. openbaar, intern, vertrouwelijk, beperkt). Definieer een duidelijk beleid voor gegevensclassificatie dat aangeeft hoe elk gegevenstype moet worden behandeld en beschermd. Implementeer passende beveiligingsmaatregelen, zoals beveiliging op veldniveau, encryptie en gegevensmaskering, om het beleid af te dwingen en gevoelige gegevens te beschermen tegen ongeoorloofde toegang of blootstelling. Controleer en controleer deze classificaties en controles regelmatig om ervoor te zorgen dat ze in overeenstemming blijven met bedrijfs- en nalevingsvereisten.

Delen en zichtbaarheid omvat het configureren van uw systeem om te bepalen hoe gebruikers toegang krijgen tot gegevens binnen Salesforce. Het is belangrijk om te weten dat delen en zichtbaarheid bepalen tot welke afzonderlijke records een gebruiker toegang heeft, maar deze instellingen alleen bepalen uiteindelijk niet wat een gebruiker met een bepaalde record kan doen, of welke specifieke velden binnen die record zichtbaar zijn. Machtigingen voor het uitvoeren van gegevensbewerkingen (zoals CRUD) worden aan gebruikers toegewezen via toegangscontroles voor metagegevens, die voor een gebruiker kunnen worden geconfigureerd op individueel object- en veldniveau. Zie Autorisatie voor meer informatie hierover.

Agentforce acties kunnen gegevens zichtbaar maken voor zowel geauthenticeerde als anonieme gebruikers die doorgaans geen directe toegang hebben. Denk bij het samenstellen van Agentforce Agenten zorgvuldig na over en documenteer alle Acties die aan de Agent zijn toegewezen. Voor elke actie moet u het volgende begrijpen:

• Tot welke gegevens de acties toegang hebben.
• In welke beveiligingscontext de acties worden uitgevoerd.
• Of de acties Knowledge retrieval of andere mogelijkheden hebben die gevoelige of beperkte gegevens kunnen opnemen in de Agent-sessie.

Effectief delen en zichtbaarheid configureren in Salesforce:

• Ontwerp toegang rond zinvolle functies. Maak een beveiligingsmatrix die uw gebruikersidentiteiten toewijst aan bedrijfsfuncties die ze moeten uitvoeren. Gebruik deze sjabloon als basis voor het ontwerpen van uw delen en zichtbaarheid. Zie Functionele eenheden voor meer informatie over het identificeren van zinvolle bedrijfsfuncties.
• Kies de eenvoudigste weg om het beginsel van de minste rechten toe te passen. Terwijl u het principe van minste rechten toepast bij het ontwerpen van schema's voor delen en zichtbaarheid, doet u dat op de meest eenvoudige manier. Vermijd overmatig ontworpen gegevensbeperkingen en schema's voor delen, die verderop in de stroom problemen kunnen veroorzaken voor de onderhoudbaarheid, schaalbaarheid en aanpasbaarheid van het systeem. Maak in plaats daarvan gebruik van flexibel, gelaagd delen van gegevens om verfijnde regels voor gebruikerstoegang op gegevensniveau te configureren.
• Stel interne standaardinstellingen voor de hele organisatie (OWD's) in op Openbaar alleen-lezen, tenzij uw bedrijf te maken heeft met gevoelige gegevens. Gebruik vervolgens Privé. OWD's bepalen het niveau van de "minste" rechten die gebruikers op gegevensniveau hebben. U kunt de toegang niet beperken tot onder het niveau van uw OWD. Hoewel privé-OWD's in elke gebruikscase ideaal lijken, kunnen gebruikers in het hele bedrijf vaak onbedoeld een meer tolerante OWD repliceren via complexe deelschema's. Daarnaast kunnen privé-OWD's ertoe leiden dat gebruikers duplicaatgegevens maken. Berekeningen voor delen (en herberekeningen) kunnen een aanzienlijke hoeveelheid tijd vergen, afhankelijk van het gegevensvolume en de scheefheid van bovenliggend/onderliggend of eigendom — privé-OWD's verergeren dit. OWD's bepalen niet de CRUD-machtigingen en zichtbaarheid op veldniveau. Kies alleen een OWD van Privé wanneer dit gerechtvaardigd is door zakelijke behoeften — meestal zullen dergelijke rechtvaardigingen gerelateerd zijn aan naleving.
• Stel externe standaardinstellingen voor de hele organisatie in op Privé, tenzij u een dwingende zakelijke reden hebt om meer toegang toe te staan. Externe OWD's zijn van toepassing op gebruikers die toegang hebben tot Salesforce-gegevens vanuit Experience Cloud-sites, portals, enzovoort. Hierdoor kunt u afzonderlijke OWD-baselines configureren voor interne en externe gebruikers, om verschillende typen "minste" machtigingen mogelijk te maken. Stel de OWD voor externe gebruikers altijd in op Privé. Uitzonderingen voor een meer open niveau moeten duidelijk worden gemotiveerd door bedrijfsbehoeften.

De onderstaande lijst met patronen en antipatronen toont hoe goed (en slecht) delen en zichtbaarheid eruitzien in een Salesforce-organisatie. Gebruik deze om uw ontwerpen te valideren voordat u gaat bouwen of om mogelijkheden voor verdere verbeteringen te identificeren.

Zie Tools Relevant voor Secure voor meer informatie over tools voor delen en zichtbaarheid van Salesforce.

Encryptie converteert leesbare gegevens naar een onontcijferbare, gecodeerde indeling. Versleutelde gegevens kunnen worden ontsleuteld of via een sleutel worden terugvertaald naar de oorspronkelijke vorm. Daarom is encryptie een van de meest effectieve methoden voor het beveiligen van gegevens, zowel "at rest" als "in transit", waardoor wordt gegarandeerd dat zelfs als onbevoegden toegang tot de gegevens krijgen, deze onleesbaar zijn.

Ontwerpen voor het juiste gebruik van encryptie in uw Salesforce-oplossingen:

• Versleutel gegevens onderweg altijd adequaat. Salesforce gebruikt Transport Layer Security (TLS) voor alle sessies die plaatsvinden in een door Salesforce ondersteunde browser en vereist dat uitgaande gesprekken die HTTPS gebruiken, voldoen aan specifieke beveiligingsnormen. Platform-API's gebruiken standaard ook HTTPS. Daarnaast worden gegevens die worden verzonden tussen een Salesforce Experience Cloud-site of een portal en de bijbehorende Salesforce-organisatie, standaard versleuteld onderweg. Als u de geïntegreerde e-mailservices van Salesforce gebruikt, zijn er standaardniveaus voor de TLS (Transport Layer Security) die Salesforce gebruikt voor het verzenden en afleveren van e-mail. U moet er ten minste voor zorgen dat de organisatie-instellingen niet lager zijn dan de standaardinstellingen, tenzij u een duidelijke zakelijke rechtvaardiging hebt. Op basis van de classificatie en gevoeligheid van uw gegevens kunt u overwegen om een privénetwerkverbinding met Salesforce te gebruiken via AWS Direct Connect of Salesforce Private Connect. Dit zorgt ervoor dat uw gegevens niet via het openbare internet gaan, maar veilig via een privénetwerkverbinding stromen voor zowel gebruikerstoegang als integraties.
• Als het bedrijf dit vereist, versleutelt u gegevens at rest. Salesforce biedt verschillende manieren om gegevens at rest te versleutelen.
  • Hyperforce. Gegevens worden at rest versleuteld in organisaties die Hyperforce gebruiken. Encryptie wordt voor uw organisatie beheerd door Salesforce. U kunt uw eigen encryptiesleutels niet maken (of vernietigen).
  • Salesforce Shield. Salesforce Shield stelt u in staat om gegevens at rest in een Salesforce-organisatie te versleutelen op extra lagen, inclusief de toepassings- en databaselagen. Met Shield hebt u volledige beheermogelijkheden voor de encryptiesleutels van uw belanghebbende, inclusief robuuste BYOK-opties (Bring Your Own Key). U kunt ook niet-gestructureerde gegevens versleutelen (inclusief bestanden, bijlagen, zoekindexen en events). Hyperforce gebaseerde exemplaren bieden de optie om een externe sleutelbeheerder te gebruiken, waardoor u uw eigen AWS KMS kunt meenemen. Met deze mogelijkheid behoudt u volledige controle over de encryptiesleutels binnen uw KMS die worden gebruikt voor het versleutelen en ontsleutelen van de gegevens die zijn opgeslagen in Salesforce, waardoor de beveiliging wordt versterkt en wordt voldaan aan de nalevingsvereisten van uw organisatie.

De onderstaande lijst met patronen en antipatronen toont hoe juist (en slecht) gebruik van encryptie eruitziet in een Salesforce-organisatie. Gebruik deze om uw ontwerpen te valideren voordat u gaat bouwen of om mogelijkheden voor verdere verbeteringen te identificeren.

Zie Tools Relevant to Secure voor meer informatie over encryptietools die beschikbaar zijn bij Salesforce.

Deze tabel toont een selectie van patronen die u in uw organisatie kunt zoeken (of samenstellen) en antipatronen die u kunt vermijden of die u kunt gebruiken voor herstel.

✨ Ontdek meer patronen voor gegevensbeveiliging in de Patroon & Anti-patroon Explorer.

Help ons Salesforce Goed ontworpen relevant voor u te houden; neem deel aan onze enquête om feedback te geven over deze inhoud en vertel ons wat u als volgende wilt zien.