Identitets- och åtkomsthantering - Mönster


Lär dig mer om Well-Architected Trust → Identitets- och åtkomsthantering

Mönster

Var man ska letaHur bra ser ut
Plattform | Arkitektur✅ Åtkomstkontroller bekräftar identitet uttryckligen på varje begäran, oberoende av nätverksplats eller enhet
Plattform | Arkitektur✅ Identitetsbaserade säkerhetskontroller ersätter nätverksbaserade Trust antaganden
Plattform | Organisation✅ Åtkomstbeslut överväger vem som begär åtkomst (autentisering), vad de är auktoriserade att göra (auktorisering) och sammanhang (enhet, plats)
Plattform | Dokumentation✅ Säkerhetsarkitektur dokumenterar identitet som den primära Trust gränsen, inte nätverksgränsen

Antimönster

Var man ska letaHur dåligt ser ut
Plattform | Arkitektur⚠️ Användare i företagsnätverk eller VPN antas vara pålitliga och beviljas bredare åtkomst endast baserat på nätverksposition
Plattform | Arkitektur⚠️ Åtkomstkontroller förlitar sig på nätverksperimeter snarare än identitetsbekräftelse
Plattform | Organisation⚠️ Åtkomstbeslut överväger inte sammanhangssignaler (enhet, plats, tid, beteendemönster)
Plattform | Dokumentation⚠️ Säkerhetsarkitektur behandlar nätverksplats som primär Trust gräns

Mönster

Var man ska letaHur bra ser ut
Plattform | Organisation✅ Lösningar använder alla fyra Salesforce-åtkomstlager: Organisation (licenser, funktioner), Objekt (CRUD), Fält (FLS), Post (delning)
Plattform | Organisation✅tkomstmodellen är utformad uppifrån och ner (org → objekt → fält → post) och validerad nedifrån och upp
Plattform | Organisation✅ Organisationsomfattande standarder (OWD) är inställda på Privat för objekt som innehåller känsliga data
Plattform | Organisation✅ OWDs inställda till Offentlig skrivskyddad är begränsade till referensobjekt (produkter, prisböcker) där bred synlighet stöder verksamheten utan att exponera risk
Plattform | Organisation✅ begränsningar på organisationsnivå (licenser, IP-intervall, inloggningstider, funktionsbehörigheter) definierar grundläggande kapacitet för användarpopulationer
Plattform | Organisation✅ Objektbehörigheter (via profiler och behörighetsuppsättningar) styr åtkomsten att skapa, läsa, redigera och ta bort varje objekt för användarsegment
Plattform | Organisation✅ Fältnivåsäkerhet skyddar känsliga fält även när objektåtkomst beviljas
Plattform | Organisation✅ Postnivådelning använder rollhierarki och delningsregler baserat på dokumenterade verksamhetskrav
Plattform | Organisation✅tkomst utökas avsiktligt från restriktiv baslinje, inte begränsad efter behörighetsstandarder

Antimönster

Var man ska letaHur dåligt ser ut
Plattform | Organisation⚠️ Åtkomstmodellen använder inte alla fyra lager (organisation, objekt, fält, post)
Plattform | Organisation⚠️ OWD är inställda till Offentligt Läsa/Skriva för att underlätta under utveckling utan begränsningsplaner
Plattform | Organisation⚠️ Överdrivet tillåtande OWD som ställs in tidigt blir exponentiellt svårare att begränsa när datavolymen ökar och verksamhetsprocesser kristalliseras
Plattform | Organisation⚠️ Fältnivåsäkerhet är inte konfigurerad och förlitar sig endast på åtkomstkontroller på objektnivå eller postnivå

Mönster

Var man ska letaHur bra ser ut
Plattform | Organisation✅ Flerfaktorsautentisering (MFA) tillämpas för alla användare som får åtkomst till produktionsmiljöer (obligatoriskt för användargränssnittåtkomst)
Plattform | Organisation✅ MFA utökas till privilegierade operationer inklusive massdataexporter, behörighetsändringar och administrativ konfiguration
Plattform | Organisation✅ Enkel inloggning (SSO) använder SAML 2.0- eller OpenID Connect-protokoll
Plattform | Organisation✅ Sessionstimeout är konfigurerad korrekt: 2 timmar för standardanvändare, 15-30 minuter för administratörer och användare som har åtkomst till begränsade data
Plattform | Organisation✅ IP-begränsningar tillämpas för administrativa profiler och integreringsanvändare
Plattform | Organisation✅ Inloggningstider begränsar servicekonton till förväntade operativa fönster
Plattform | Organisation✅ Inbyggd enhetsaktivering verifierar inloggningar från okända enheter; MFA- och IP-begränsningar lägger till skydd för konton med hög behörighet
Plattform | Organisation✅ Om SSO är aktiverat har godkända administratörsanvändare direkt inloggningsåtkomst (glaskrossprocedurer)
Plattform | Organisation✅ Relationen mellan användare och enheter som loggar in i Salesforce är 1:1 (inga delade användarkonton)
Plattform | Organisation✅ API-åtkomstkontroll förhindrar användare från att autentisera via oauktoriserade anslutna appar
Plattform | Autentiseringsuppgifter✅ autentiseringsuppgifter och externa inloggningsuppgifter hanterar autentisering centralt med rotationsfunktioner
Plattform | Autentiseringsuppgifter✅ abstrakta autentiseringsuppgifter från kod, aktivera uppdateringar av inloggningsuppgifter utan kodändringar
Plattform | Autentiseringsuppgifter✅ Inloggningsuppgifter är aldrig inbäddade i kod, konfigurationsfiler eller versionskontroll
Plattform | Apex✅ Metoder som utför autentisering använder autentiseringsuppgifter för att hantera användarnamn / lösenordsflöden
Plattform | Apex✅ Inga användarnamn eller lösenord visas i kod i läsbara format (inga hårdkodade värden eller strängar)
Plattform | Aura✅ Metoder som utför autentisering använder autentiseringsuppgifter för att hantera användarnamn / lösenordsflöden
Plattform | Aura✅ Inga användarnamn eller lösenord visas i kod i läsbara format
Plattform | Lightning webbkomponenter (LWC)✅ Metoder som utför autentisering använder autentiseringsuppgifter
Plattform | Lightning webbkomponenter (LWC)✅ Inga användarnamn eller lösenord visas i kod
Integrering | API✅ OAuth 2.0 JWT-bärarflöde används för server-till-server-integreringar i betrodda miljöer (föredras för produktionsintegreringar)
Integrering | API✅ OAuth 2.0 webbserverflöde används för server-till-server-integreringar som kräver användarsammanhang
Integrering | API✅ OAuth 2.0-enhetsflöde används för sidhuvudlösa enheter. CLI- och CI/CD-verktyg använder webbserverflöde (sf org login web) eller JWT-bärarflöde (sf org login jwt) – enhetsflöde blockerades för Salesforce CLI:s anslutna standardapp från 28 augusti 2025.
Integrering | API✅ Användarnamn-lösenord OAuth-flöde används inte; befintliga integreringar som förlitar sig på det migreras till JWT-bärar- eller klientinloggningsuppgifterflöde

Antimönster

Var man ska letaHur dåligt ser ut
Plattform | Organisation⚠️ MFA tillämpas inte för åtkomst till produktionsmiljöer
Plattform | Organisation⚠️ Inloggningskonfigurationer följer inte Salesforce MFA-kraven
Plattform | Organisation⚠️ MFA utökas inte till privilegierade operationer (buntexporter, behörighetsändringar, administrativ konfiguration)
Plattform | Organisation⚠️ Sessionstimeout är inte konfigurerad eller överdrivet tillåtande (>24 timmar)
Plattform | Organisation⚠️ Sessionspolicyer skiljer inte mellan standardanvändare och administratörer/användare som har åtkomst till begränsade data
Plattform | Organisation️ IP-begränsningar tillämpas inte för administrativa profiler och integreringsanvändare
Plattform | Organisation⚠️ Servicekonton har inte inloggningstider begränsade till förväntade operativa fönster
Plattform | Organisation⚠️ Konton med hög behörighet förlitar sig inte på något utöver enhetsaktivering — inga MFA- eller IP-begränsningar tillagda
Plattform | Organisation⚠️ Om SSO är aktiverat har inga godkända administratörsanvändare direkt inloggningsåtkomst (inga krossglasprocedurer)
Plattform | Organisation⚠️ Relationen mellan användare och enheter är inte 1:1 (delade användarkonton finns)
Plattform | Organisation⚠️ API-åtkomstkontroll är inte aktiverad
Plattform | Autentiseringsuppgifter⚠️ Inloggningsuppgifter är inbäddade direkt i kod, konfigurationsfiler eller versionshantering
Plattform | Apex⚠️ Användarnamn och lösenord visas i kod i läsbara format
Plattform | Apex️ Autentisering hanteras ad hoc utan konsekvent implementering
Plattform | Aura⚠️ Autentisering hanteras ad hoc utan autentiseringsuppgifter
Plattform | Aura⚠️ Användarnamn och lösenord visas i kod
Plattform | Lightning webbkomponenter (LWC)⚠️ Autentisering hanteras ad hoc utan autentiseringsuppgifter
Plattform | Lightning webbkomponenter (LWC)⚠️ Användarnamn och lösenord visas i kod
Plattform | Företag️ Servicenivåavtal och krav för användarprovisionering och avprovisionering finns inte
Integrering | API⚠️ OAuth-flöde med användarnamn och lösenord används när säkrare OAuth-flöden är tillgängliga
Integrering | API⚠️ OAuth-omfång är övertillåtna (fullständig åtkomst när begränsad omfattning är tillräcklig)
Integrering | API⚠️ Klientuppgifter (klient-ID, klienthemlighet) lagras osäkert i kod- eller konfigurationsfiler

Mönster

Var man ska letaHur bra ser ut
Plattform | Organisation✅ Rollhierarkidjup är 5-7 nivåer max (undvik prestanda overhead och felsökning komplexitet)
Plattform | Organisation✅ Behörighetsuppsättningar och behörighetsuppsättningsgrupper ger flexibel, additiv åtkomst utan profilspridning
Plattform | Organisation✅ Behörighetsuppsättningar beviljar åtkomst för specifika jobbfunktioner, program eller tillfälliga utökade behörigheter
Plattform | Organisation✅ Behörighetsuppsättningsgrupper kombinerar relaterade behörighetsuppsättningar med ignoreringsmöjligheter för undantag
Plattform | Organisation✅ All funktionell åtkomst beviljas genom behörighetsuppsättningar och behörighetsuppsättningsgrupper (inte profiler), vilket ger flexibilitet när jobbroller utvecklas
Plattform | Organisation✅ Transaktionssäkerhetspolicyer utökar auktorisering med sammanhangsutvärdering i realtid
Plattform | Organisation✅ Transaktionssäkerhetspolicyer upptäcker och blockerar avvikande beteende (massdatanedladdningar som överskrider mönster, inloggning från oväntade geografiska områden, behörighetsändringar utanför ändringsfönster)
Plattform | Organisation✅ IP-begränsningar är konfigurerade för mycket känsliga operationer eller dataåtkomst
Plattform | Organisation✅ En unik API-endast integreringsanvändare är konfigurerad för varje integrering
Plattform | Apex✅ All kod som kommer åt data tillämpar CRUD och FLS med hjälp av MED USER_MODE, MED SYSTEM_MODE nyckelord eller Security.stripInaccessible() metoder
Plattform | Apex✅ SOQL-frågor använder MED USER_MODE eller MED SYSTEM_MODE nyckelord uttryckligen baserat på verksamhetskrav
Plattform | Apex✅ DML-operationer använder Security.stripInaccessible() för åtkomsttillämpning innan infoga/uppdatera/infoga operationer
Plattform | Apex✅ Databas DML-uttryck deklarerar användar- eller systemläge uttryckligen för dataoperationer
Plattform | Apex✅ Databasoperationer använder stripInaccessible()-metoder för att filtrera sökfrågor och underfrågeresultat
Plattform | Apex✅ Delningsnyckelord (med delning, utan delning, ärvd delning) används korrekt baserat på affärssäkerhetskrav
Plattform | Designstandarder✅ Användningsfall för att bevilja utökade privilegier (Ändra alla data, Visa alla data) dokumenteras tydligt med verksamhetsmotivering

Antimönster

Var man ska letaHur dåligt ser ut
Plattform | Organisation⚠️ Rollhierarki är djupare än 5-7 nivåer, vilket skapar prestandaoverhead i delningsberäkningar och felsökning av komplexitet
Plattform | Organisation⚠️ Rollhierarki beviljar bred åtkomst utan affärsmotivering
Plattform | Organisation⚠️ Profiler klonas upprepade gånger för mindre behörighetsvarianter, vilket skapar dussintals profiler med oklara skillnader
Plattform | Organisation⚠️ Profiler innehåller åtkomstkontroller för metadata (bör använda behörighetsuppsättningar)
Plattform | Organisation⚠️ Transaktionssäkerhetspolicyer implementeras inte för att upptäcka avvikande beteenden
Plattform | Organisation⚠️ IP-begränsningar är inte konfigurerade för mycket känsliga operationer eller dataåtkomst
Plattform | Organisation⚠️ API-användare är inte konfigurerade eller delade över flera integreringar
Plattform | Organisation⚠️ Behörigheterna Visa alla data eller Ändra alla data beviljas utan dokumenterad motivering
Plattform | Apex⚠️ SOQL/SOSL-frågor och DML-operationer körs i standardsystemläge utan uttryckliga åtkomstkontroller
Plattform | Apex️ CRUD och FLS-tillämpning är inkonsekvent eller saknas
Plattform | Apex⚠️ SOQL förlitar sig på WITH SECURITY_ENFORCED, som har tagits bort och nu orsakar ett kompileringsfel (ersätt med WITH USER_MODE)
Plattform | Apex⚠️ Delningsnyckelord används inkonsekvent eller inte alls
Plattform | Designstandarder⚠️ Användningsfall för att bevilja förhöjda behörigheter är inte tydligt dokumenterade

Mönster

Var man ska letaHur bra ser ut
Plattform | Data 360✅ RBAC (roller, profiler, behörighetsuppsättningar) styr plattformsåtkomst (vem som kan använda Data 360), ABAC styr dataåtkomst (vilka data de ser baserat på attribut)
Plattform | Data 360✅ AI-agenter körs i den begärande användarens sammanhang (på uppdrag av), så agentskapade sökfrågor begränsas av den användarens åtkomst istället för att köras med åtkomst på systemnivå
Plattform | Dokumentation✅ Dataklassificering taxonomi dokumenteras med attributdefinitioner, tillämpningsregler och verksamhetsmotivering

Antimönster

Var man ska letaHur dåligt ser ut
Plattform | Data 360⚠️ Åtkomst som måste följa dataklassificering tvingas genom rollhierarki och delning, som inte kan uttrycka det, istället för att sträcka sig efter attributbaserad åtkomstkontroll
Plattform | Data 360⚠️ FLS-bypass: användare utan fältnivååtkomst hämtar data via API- eller SOQL-frågor som inte tillämpar FLS
Plattform | Data 360⚠️ AI-agenter frågar data utan att köra i den begärande användarens sammanhang; agentskapade frågor kringgår åtkomstkontroller på objekt-, fält- och postnivå
Plattform | Data 360️ Agentkörningssammanhang inkluderar inte användare på uppdrag av attribut; agenter arbetar med åtkomst på systemnivå
Plattform | Dokumentation⚠️ Dataklassificeringens taxonomi är odokumenterad; attributdefinitioner varierar beroende på team vilket skapar inkonsekvent tillämpning

Mönster

Var man ska letaHur bra ser ut
Plattform | Organisation✅ Kritisk påverkan konton (systemadministratörer, integreringsanvändare, automatiserade processkonton) identifieras och spåras i tillgångslager
Plattform | Organisation✅ Kritisk påverkan konton representerar högt värde mål på grund av förhöjda privilegier som ger bred plattformsåtkomst
Plattform | Organisation✅ Hårdvarusäkerhetsnycklar eller autentiseringsappar krävs för MFA (inte SMS, som är sårbart för SIM-byte)
Plattform | Organisation✅ IP-intervall för inloggning är begränsade till kända administrativa platser
Plattform | Organisation✅ Inloggningsvarningar och behörighetsändringsnotiser är aktiverade
Plattform | Organisation✅ Kvartalsvisa åtkomstgranskningar utförs med dokumenterad attestering
Plattform | Organisation✅ Krossglasprocedurer finns för nödåtkomst med granskning efter användning
Integrering | Servicekonton✅ OAuth-flöden används för integration och servicekonton (aldrig användarnamn-lösenord)
Integrering | Servicekonton✅ IP-begränsningar tillämpas för integreringsanvändare
Integrering | Servicekonton✅ Inloggningsrotation scheman genomförs (kvartalsvis eller per policy)
Integrering | Servicekonton✅ avvikande API-användningsmönster övervakas genom händelseövervakning
Integrering | Servicekonton✅ Varje integrering har ett dedikerat servicekonto med minsta nödvändiga behörigheter (inte delad “integreringsanvändare” med bred åtkomst)
Integrering | Servicekonton✅ Servicekonton tillämpar minst privilegier strikt eftersom de fungerar obevakade

Antimönster

Var man ska letaHur dåligt ser ut
Plattform | Organisation⚠️ Konton med kritisk påverkan (administratör, integrering, automatisering) identifieras, spåras eller inventeras inte
Plattform | Organisation⚠️ Systemadministratörer använder SMS-baserad MFA istället för hårdvarusäkerhetsnycklar eller autentiseringsappar
Plattform | Organisation⚠️ Konton med kritisk påverkan har inga inloggningstimmar eller IP-begränsningar
Plattform | Organisation⚠️ Inga varningar konfigureras för inloggning eller behörighetsändringar för privilegierade konton
Plattform | Organisation⚠️ Kontoåtkomst med kritisk påverkan granskas eller granskas aldrig oregelbundet (inte kvartalsvis)
Plattform | Organisation⚠️ Det finns inga förfaranden för krossat glas för nödåtkomst
Integrering | Servicekonton⚠️ Ett enskilt “API-användare”-konto delas över flera integreringar med behörigheten Ändra alla data
Integrering | Servicekonton⚠️ Servicekonton använder användarnamn-lösenord-autentisering när OAuth är tillgängligt
Integrering | Servicekonton⚠️ Servicekontouppgifter använder statiska lösenord oförändrade i flera år (ingen rotation)
Integrering | Servicekonton⚠️ Servicekonton har överdrivna privilegier utöver vad integrering kräver
Integrering | Servicekonton⚠️ Avvikande API-användningsmönster för servicekonton övervakas inte

Mönster

Var man ska letaHur bra ser ut
Plattform | Process✅ Identitet livscykel inkluderar: Provisionering (skapa med grundläggande åtkomst), Åtkomstjustering (bevilja/återkalla när roller ändras), Periodisk återcertifiering (kvartalsvis validering), Deprovisionering (omedelbar återkallande)
Plattform | Organisation✅ SCIM (System för Cross-Domain Identity Management) implementeras för automatiserad provisionering från identitetsleverantörer
Plattform | Process✅ Provisionering skapar konton med grundläggande åtkomst matchande jobbfunktion, utlöst av HR-systemhändelser
Plattform | Process✅ Åtkomstjustering beviljar ytterligare behörigheter när roller utökas och återkallar behörigheter när roller ändras
Plattform | Process✅ Periodisk omcertifiering inträffar varje kvartal där chefer granskar och validerar åtkomst för sina team
Plattform | Process✅ Deprovisionering återkallar åtkomst direkt när anställningen avslutas eller rollen inte längre kräver Salesforce
Plattform | Organisation✅ Automatisk upptäckt identifierar användare som inte har loggat in inom 90 dagar och utlöser åtkomstgranskningsflöden
Plattform | Organisation✅ Just-in-time (JIT) provisionering skapar användare automatiskt från SSO vid behov

Antimönster

Var man ska letaHur dåligt ser ut
Plattform | Organisation⚠️ SCIM-provisionering implementeras inte trots att identitetsleverantörsintegrering har skett
Plattform | Process⚠️ Nya användare skapas manuellt utan standardrutiner för introduktioner
Plattform | Process⚠️ Inledande användaråtkomst är inkonsekvent eller baserad på att kopiera befintliga användare
Plattform | Process⚠️ Åtkomständringar för rolländringar eller överföringar är försenade eller ofullständiga
Plattform | Process️ Offboarding försenas; tidigare anställda behåller åtkomst efter uppsägning (inte inaktivering samma dag)
Plattform | Organisation⚠️ Det finns ingen automatisering för användarprovisionering (endast manuellt användarskapande)
Plattform | Process⚠️ Det finns inga kampanjer för omcertifiering av åtkomst (ingen kvartalsvis eller årlig översyn)
Plattform | Process⚠️ Onödig åtkomst som identifierats under omcertifiering tas inte bort
Plattform | Process⚠️ Omcertifiering av åtkomst är inte rigorös för privilegierade konton, korsorganisationsåtkomst, externa användare
Plattform | Organisation⚠️ Vilande konton (ingen inloggning på 90+ dagar) ackumuleras utan granskning eller inaktivering