Identitets- og tilgangsadministrasjon – mønstre
Lær mer om Well-Architected Trust → Identity and Access Management
Mønstre
| Hvor du kan se | Hvordan det ser bra ut |
|---|---|
| Plattform | Arkitektur | ✅ Tilgangskontroller bekrefter identiteten eksplisitt for hver forespørsel uavhengig av nettverksplassering eller enhet |
| Plattform | Arkitektur | ✅ Identitetsbaserte sikkerhetskontroller erstatter nettverksbaserte forutsetninger om Trust |
| Plattform | Organisasjon | ✅ Tilgangsbeslutninger vurderer hvem som ber om tilgang (godkjenning), hva de er autorisert til å gjøre (godkjenning) og kontekst (enhet, plassering) |
| Plattform | Dokumentasjon | ✅ Sikkerhetsarkitektur dokumenterer identitet som den primære Trust, ikke nettverksområdene |
Anti-Mønstre
| Hvor du kan se | Hvordan dårlig ser ut |
|---|---|
| Plattform | Arkitektur | ⚡️ Brukere i firmanettverk eller VPN antas å være pålitelige og gis bredere tilgang basert bare på nettverksposisjon |
| Plattform | Arkitektur | ⚡️ Tilgangskontroller er avhengig av nettverksområdene i stedet for identitetsbekreftelse |
| Plattform | Organisasjon | ⚡️ Tilgangsbeslutninger vurderer ikke kontekstsignaler (enhet, plassering, klokkeslett, atferdsmønstre) |
| Plattform | Dokumentasjon | ⚡️ Sikkerhetsarkitektur behandler nettverksplassering som primær Trust |
Mønstre
| Hvor du kan se | Hvordan det ser bra ut |
|---|---|
| Plattform | Organisasjon | ✅ Løsninger benytter alle fire Salesforce-tilgangslag: Organisasjon (lisenser, funksjoner), Objekt (CRUD), Felt (FLS), Post (deling) |
| Plattform | Organisasjon | ✅ Tilgangsmodellen er utformet fra øverst til nederst (organisasjon → objekt → felt → post) og validert fra nederst opp |
| Plattform | Organisasjon | ✅ Organisasjonsomfattende standarder (OWD) settes til Privat for objekter som inneholder sensitive data |
| Plattform | Organisasjon | ✅ OWD-er angitt til Felles skrivebeskyttet er begrenset til referanseobjekter (produkter, prislister) der bred synlighet støtter virksomheten uten å eksponere risiko |
| Plattform | Organisasjon | ✅ Begrensninger på organisasjonsnivå (lisenser, IP-områder, påloggingstider, funksjonstillatelser) definerer grunnleggende funksjonalitet for brukerpopulasjoner |
| Plattform | Organisasjon | ✅ Objekttillatelser (via profiler og tillatelsessett) kontrollerer tilgang til å opprette, lese, redigere og slette hvert objekt for brukersegmenter |
| Plattform | Organisasjon | ✅ Feltnivåsikkerhet beskytter sensitive felt selv om objekttilgang gis |
| Plattform | Organisasjon | ✅ Postnivådeling bruker rollehierarki og delingsregler basert på dokumenterte forretningskrav |
| Plattform | Organisasjon | ✅ Tilgang utvides med vilje fra begrensende standarder, ikke begrenset etter tillatelsesstandarder |
Anti-Mønstre
| Hvor du kan se | Hvordan dårlig ser ut |
|---|---|
| Plattform | Organisasjon | ⚡️ Tilgangsmodellen bruker ikke alle fire lag (organisasjon, objekt, felt, post) |
| Plattform | Organisasjon | ⚡️ OWD-er er satt til Felles lese/skrive for å gjøre det enklere under utvikling uten begrensningsplaner |
| Plattform | Organisasjon | ⚡️ Overdreven tillatte OWD-er angitt tidlig blir eksponentielt vanskeligere å begrense etter hvert som datavolumet øker og forretningsprosesser krystalliseres |
| Plattform | Organisasjon | ⚡️ Feltnivåsikkerhet er ikke konfigurert, avhengig bare av tilgangskontroller på objekt- eller postnivå |
Mønstre
| Hvor du kan se | Hvordan det ser bra ut |
|---|---|
| Plattform | Organisasjon | ✅ Godkjenning med flere faktorer (MFA) håndheves for alle brukere som har tilgang til produksjonsmiljøer (obligatorisk for brukergrensesnitttilgang) |
| Plattform | Organisasjon | ✅ MFA utvides til privilegerte operasjoner, inkludert masseeksport av data, endringer i tillatelser og administrativ konfigurasjon |
| Plattform | Organisasjon | ✅ Enkeltpålogging (SSO) bruker SAML 2.0- eller OpenID Connect-protokoller |
| Plattform | Organisasjon | ✅ Økttidsavbrudd er riktig konfigurert: 2 timer for standardbrukere, 15-30 minutter for administratorer og brukere som har tilgang til begrensede data |
| Plattform | Organisasjon | ✅ IP-restriksjoner håndheves for administrative profiler og integrasjonsbrukere |
| Plattform | Organisasjon | ✅ Påloggingstider begrenser tjenestekontoer til forventede driftsvinduer |
| Plattform | Organisasjon | ✅ Innebygd enhetsaktivering bekrefter pålogginger fra ikke gjenkjente enheter. MFA- og IP-restriksjoner gir beskyttelse for kontoer med høy privilegium |
| Plattform | Organisasjon | ✅ Hvis SSO er aktivert, har godkjente administratorbrukere direkte påloggingstilgang (prosedyrer for pause) |
| Plattform | Organisasjon | ✅ Relasjonen mellom brukere og enheter som logger seg på Salesforce, er 1:1 (ingen delte brukerkontoer) |
| Plattform | Organisasjon | ✅ API-tilgangskontroll hindrer brukere i å godkjenne via uautoriserte tilkoblede apper |
| Plattform | Navngitt legitimasjon | ✅ Navngivne legitimationsoplysninger og eksterne legitimationsoplysninger administrerer godkendelse centralt med rotationsfunktioner |
| Plattform | Navngitt legitimasjon | ✅ Abstrakte godkjenningsdetaljer for navngitt legitimasjon fra kode, aktiverer legitimasjonsoppdateringer uten kodeendringer |
| Plattform | Navngitt legitimasjon | ✅ Legitimasjon er aldri innebygd i kode, konfigurasjonsfiler eller versjonskontroll |
| Plattform | Apex | ✅ Metoder som utfører godkjenning, bruker navngitt legitimasjon til å håndtere brukernavn- og passordflyter |
| Plattform | Apex | ✅ Ingen brukernavn eller passord vises i kode i lesbare formater (ingen hardkodede verdier eller strenger) |
| Plattform | Aura | ✅ Metoder som utfører godkjenning, bruker navngitt legitimasjon til å håndtere brukernavn- og passordflyter |
| Plattform | Aura | ✅ Ingen brukernavn eller passord vises i kode i lesbare formater |
| Plattform | Lightning Web Components (LWC) | ✅ Metoder som utfører godkjenning, bruker navngitt legitimasjon |
| Plattform | Lightning Web Components (LWC) | ✅ Ingen brukernavn eller passord vises i kode |
| Integrasjon | API | ✅ OAuth 2.0 JWT-bærerflyt brukes til server-til-server-integrasjoner i klarerte miljøer (foretrukket for produksjonsintegrasjoner) |
| Integrasjon | API | ✅ OAuth 2.0 nettserverflyt brukes til server-til-server-integrasjoner som krever brukerkontekst |
| Integrasjon | API | ✅ OAuth 2.0-enhetsflyt brukes for hodeløse enheter, CLI- og CI/CD-verktøyet bruker nettserverflyt (sf org login web) eller JWT-bærerflyt (sf org login jwt) – enhetsflyten ble blokkert for den tilkoblede standardappen Salesforce CLI per 28. aug. 2025 |
| Integrasjon | API | ✅ OAuth-flyt for brukernavn-passord brukes ikke. eksisterende integrasjoner som avhenger av det, overføres til JWT-bæreren eller klientlegitimasjonsflyten |
Anti-Mønstre
| Hvor du kan se | Hvordan dårlig ser ut |
|---|---|
| Plattform | Organisasjon | ⚡️ MFA håndheves ikke for produksjonsmiljøtilgang |
| Plattform | Organisasjon | ⚡️ Påloggingskonfigurasjoner er ikke i samsvar med Salesforce MFA-krav |
| Plattform | Organisasjon | ⚡️ MFA utvides ikke til privilegerte operasjoner (masseeksport, tillatelsesendringer, administrativ konfigurasjon) |
| Plattform | Organisasjon | ⚡️ Økttidsavbrudd er ikke konfigurert eller er for tillatt (>24 timer) |
| Plattform | Organisasjon | ⚡️ Øktpolicyer skiller ikke mellom standardbrukere og administratorer/brukere som har tilgang til begrensede data |
| Plattform | Organisasjon | ⚡️ IP-restriksjoner håndheves ikke for administrative profiler og integrasjonsbrukere |
| Plattform | Organisasjon | ⚡️ Tjenestekontoer har ikke påloggingstider begrenset til forventede driftsvinduer |
| Plattform | Organisasjon | ⚡️ Kontoer med høy privilegium avhenger ikke av noe annet enn enhetsaktivering – ingen MFA- eller IP-restriksjoner lagt til |
| Plattform | Organisasjon | ⚡️ Hvis enkeltpålogging er aktivert, har ingen godkjente administratorbrukere direkte påloggingstilgang (ingen pauseglassprosedyrer) |
| Plattform | Organisasjon | ⚡️ Relasjonen mellom brukere og enheter er ikke 1:1 (det finnes delte brukerkontoer) |
| Plattform | Organisasjon | ⚡️ API-tilgangskontroll er ikke aktivert |
| Plattform | Navngitt legitimasjon | ⚡️Påloggingsinformasjon bygges inn direkte i kode, konfigurasjonsfiler eller versjonskontroll |
| Plattform | Apex | ⚡️ Brukernavn og passord vises i kode i lesbare formater |
| Plattform | Apex | ⚡️ Godkjenning håndteres ad hoc uten konsekvent implementering |
| Plattform | Aura | ⚡️ Godkjenning håndteres ad hoc uten navngitt legitimasjon |
| Plattform | Aura | ⚡️ Brukernavn og passord vises i kode |
| Plattform | Lightning Web Components (LWC) | ⚡️ Godkjenning håndteres ad hoc uten navngitt legitimasjon |
| Plattform | Lightning Web Components (LWC) | ⚡️ Brukernavn og passord vises i kode |
| Plattform | Virksomhet | ⚡️ Brukerklargjøring og avklaring av tjenestenivåavtaler og krav finnes ikke |
| Integrasjon | API | ⚡️ OAuth-flyt for brukernavn-passord brukes når mer sikre OAuth-flyter er tilgjengelig |
| Integrasjon | API | ⚡️ OAuth-omfang er for tillatte (full tilgang når begrenset omfang er tilstrekkelig) |
| Integrasjon | API | ⚡️ Klientlegitimasjon (klient-ID, klienthemmelighet) lagres usikker i kode- eller konfigurasjonsfiler |
Mønstre
| Hvor du kan se | Hvordan det ser bra ut |
|---|---|
| Plattform | Organisasjon | ✅ Rollehierarkiets dybde er maksimalt 5-7 nivåer (undgå ytelsesoverhead og feilsøkingskompleksitet) |
| Plattform | Organisasjon | ✅ Tillatelsessett og tillatelsessettgrupper gir fleksibel, additiv tilgang uten profilforlengelse |
| Plattform | Organisasjon | ✅ Tillatelsessett for å gi tilgang til bestemte jobbfunksjoner, søknader eller midlertidige forhøyede rettigheter |
| Plattform | Organisasjon | ✅ Tillatelsessettgrupper kombinerer relaterte tillatelsessett med avslåingsfunksjonalitet for unntak |
| Plattform | Organisasjon | ✅ All funksjonstilgang gis via tillatelsessett og tillatelsessettgrupper (ikke profiler), noe som gir fleksibilitet etter hvert som jobbroller utvikles |
| Plattform | Organisasjon | ✅ Transaksjonssikkerhetspolicyer utvider godkjenning med sanntidskontekstuell evaluering |
| Plattform | Organisasjon | ✅ Transaksjonssikkerhetspolicyer oppdager og blokkerer avvikende virkemåte (nedlasting av massedata som overskrider mønstre, pålogging fra uventede geografier, endringer av tillatelser utenfor endringsvinduer) |
| Plattform | Organisasjon | ✅ IP-restriksjoner er konfigurert for svært sensitive operasjoner eller datatilgang |
| Plattform | Organisasjon | ✅ En unik API-integrasjonsbruker er konfigurert for hver integrasjon |
| Plattform | Apex | ✅ Alle kodetilgang til data håndhever CRUD og FLS ved bruk av metodene MED USER_MODE, MED SYSTEM_MODE-nøkkelord eller Security.stripInaccessible(). |
| Plattform | Apex | ✅ SOQL-spørringer som brukes med USER_MODE eller med SYSTEM_MODE-nøkkelord eksplisitt basert på forretningskrav |
| Plattform | Apex | ✅ DML-operasjoner bruker Security.stripInaccessible() til tilgangshåndhevelse før innsetting/oppdatering/upsert-operasjoner |
| Plattform | Apex | ✅ DatabasedML-setninger erklærer bruker- eller systemmodus eksplisitt for dataoperasjoner |
| Plattform | Apex | ✅ Databaseoperasjoner bruker stripInaccessible()-metoder til å filtrere spørrings- og underspørringsresultater |
| Plattform | Apex | ✅ Nøkkelord for deling (med deling, uten deling, arvet deling) brukes riktig basert på forretningssikkerhetskrav |
| Plattform | Utformingsstandarder | ✅ Brukstilfeller for å gi forhøyede rettigheter (Endre alle data, Vis alle data) er tydelig dokumentert med forretningsbegrunnelse |
Anti-Mønstre
| Hvor du kan se | Hvordan dårlig ser ut |
|---|---|
| Plattform | Organisasjon | ⚡️ Rollehierarkiet er dypere enn 5-7 nivåer, noe som gir ytelsesoverhead i beregninger av deling og feilsøking av kompleksitet |
| Plattform | Organisasjon | ⚡️ Rollehierarki gir bred tilgang uten forretningsbegrunnelse |
| Plattform | Organisasjon | ⚡️ Profiler klones gjentatte ganger for mindre tillatelsesvariasjoner og oppretter dusinvis av profiler med uklare forskjeller |
| Plattform | Organisasjon | ⚡️ Profiler inneholder tilgangskontroller for metadata (må bruke tillatelsessett) |
| Plattform | Organisasjon | ⚡️ Transaksjonssikkerhetspolicyer implementeres ikke for å oppdage avvikende virkemåte |
| Plattform | Organisasjon | ⚡️ IP-restriksjoner er ikke konfigurert for svært sensitive operasjoner eller datatilgang |
| Plattform | Organisasjon | ⚡️ Bare API-brukere er ikke konfigurert eller deles på tvers av flere integrasjoner |
| Plattform | Organisasjon | Tillatelsene Vise alle data eller Endre alle data gis uten dokumentert begrunnelse |
| Plattform | Apex | ⚡️ SOQL/SOSL-spørringer og DML-operasjoner kjører i standard systemmodus uten eksplisitte tilgangskontroller |
| Plattform | Apex | ⚡️ CRUD- og FLS-håndhevelse er inkonsistent eller mangler |
| Plattform | Apex | ⚡️ SOQL er avhengig av WITH SECURITY_ENFORCED, som har blitt fjernet og nå fører til en kompileringsfeil (erstatt med WITH USER_MODE) |
| Plattform | Apex | ⚡️ Nøkkelord for deling brukes inkonsekvent eller ikke i det hele tatt |
| Plattform | Utformingsstandarder | ⚡️ Bruksområder for å gi forhøyede tillatelser er ikke klart dokumentert |
Mønstre
| Hvor du kan se | Hvordan det ser bra ut |
|---|---|
| Plattform | Data 360 | ✅ RBAC (roller, profiler, tillatelsessett) styrer plattformtilgang (som kan bruke Data 360), ABAC styrer datatilgang (hvilke data de ser basert på attributter) |
| Plattform | Data 360 | ✅ AI-agenter utføres i brukerens kontekst (på vegne av), så agentgenererte spørringer er begrenset av brukerens tilgang i stedet for å kjøre med tilgang på systemnivå |
| Plattform | Dokumentasjon | ✅ Dataklassifiseringen dokumenteres med attributdefinisjoner, håndhevsregler og forretningsbegrunnelse |
Anti-Mønstre
| Hvor du kan se | Hvordan dårlig ser ut |
|---|---|
| Plattform | Data 360 | ⚡️ Tilgang som må følge dataklassifisering, tvinges gjennom rollehierarki og deling, som ikke kan uttrykke det, i stedet for å nå for attributtbasert tilgangskontroll |
| Plattform | Data 360 | ⚡️ FLS-bypass: brukere uten tilgang på feltnivå henter data via API- eller SOQL-spørringer som ikke håndhever FLS |
| Plattform | Data 360 | ⚡️ AI-agenter spør data uten å utføre i konteksten til brukeren som spør, agentgenererte spørringer omgår tilgangskontroller på objekt-, felt- og postnivå |
| Plattform | Data 360 | ⚡️ Agentutførelseskontekst inkluderer ikke bruker på vegne av attributter. Agenter opererer med tilgang på systemnivå |
| Plattform | Dokumentasjon | ⚡️ Dataklassifiseringen er udokumentert. Attributtdefinisjoner varierer etter team som oppretter inkonsekvent håndheving |
Mønstre
| Hvor du kan se | Hvordan det ser bra ut |
|---|---|
| Plattform | Organisasjon | ✅ Viktige innvirkningskontoer (systemadministratorer, integrasjonsbrukere, automatiserte prosesskontoer) identifiseres og spores i aktivumlagerbeholdningen |
| Plattform | Organisasjon | ✅ Viktige innvirkningskontoer representerer mål med høy verdi på grunn av forhøyede rettigheter som gir bred plattformtilgang |
| Plattform | Organisasjon | ✅ Maskinvaresikkerhetsnøkler eller godkjenningsapper kreves for MFA (ikke SMS, som er sårbar for SIM-bytting) |
| Plattform | Organisasjon | ✅ IP-områder for pålogging er begrenset til kjente administrative steder |
| Plattform | Organisasjon | ✅ Påloggingsvarsler og tillatelsesendringsvarsler er aktivert |
| Plattform | Organisasjon | ✅ Kvartalsvise tilgangsvurderinger utføres med dokumentert attestering |
| Plattform | Organisasjon | ✅ Break-glass-prosedyrer finnes for nødtilgang med revisjon etter bruk |
| Integrasjon | Tjenestekontoer | ✅ OAuth-flyter brukes til integrerings- og tjenestekontoer (aldri brukernavn-passord) |
| Integrasjon | Tjenestekontoer | ✅ IP-restriksjoner håndheves for integrasjonsbrukere |
| Integrasjon | Tjenestekontoer | ✅ Roteringsplaner for legitimasjon implementeres (kvartalsvis eller per policy) |
| Integrasjon | Tjenestekontoer | ✅ Unormale API-bruksmønstre overvåkes via Hendelsesovervåking |
| Integrasjon | Tjenestekontoer | ✅ Hver integrasjon har en dedikert tjenestekonto med minimum nødvendige tillatelser (ikke delt “integrasjonsbruker” med bred tilgang) |
| Integrasjon | Tjenestekontoer | ✅ Tjenestekontoer bruker minst rettigheter strengt fordi de opererer uovervåket |
Anti-Mønstre
| Hvor du kan se | Hvordan dårlig ser ut |
|---|---|
| Plattform | Organisasjon | ⚡️ Viktige innvirkningskontoer (administrator, integrasjon, automatisering) identifiseres ikke, spores ikke eller lagerbeholdes |
| Plattform | Organisasjon | ⚡️ Systemadministratorer bruker SMS-basert MFA i stedet for maskinvaresikkerhetsnøkler eller godkjenningsapper |
| Plattform | Organisasjon | ⚡️ Viktige innvirkningskontoer har ingen påloggingstids- eller IP-restriksjoner |
| Plattform | Organisasjon | ⚡️ Ingen varsler er konfigurert for endringer av pålogging eller tillatelser for privilegerte kontoer |
| Plattform | Organisasjon | ⚡️ Tilgang til viktige innvirkningskontoer blir aldri gjennomgått eller gjennomgått uregelmessig (ikke kvartalsvis) |
| Plattform | Organisasjon | ⚡️ Det finnes ingen bruddglassprosedyrer for tilgang i hasteavtaler |
| Integrasjon | Tjenestekontoer | ⚡️ En enkelt API-bruker-konto deles på tvers av flere integrasjoner med tillatelsen Endre alle data |
| Integrasjon | Tjenestekontoer | ⚡️ Tjenestekontoer bruker brukernavn-passord-godkjenning når OAuth er tilgjengelig |
| Integrasjon | Tjenestekontoer | ⚡️ Tjenestekontolegitimasjon bruker statiske passord som ikke er endret i flere år (ingen rotasjon) |
| Integrasjon | Tjenestekontoer | ⚡️ Tjenestekontoer har for store rettigheter ut over det integrasjonen krever |
| Integrasjon | Tjenestekontoer | ⚡️ Unormale API-bruksmønstre for tjenestekontoer overvåkes ikke |
Mønstre
| Hvor du kan se | Hvordan det ser bra ut |
|---|---|
| Plattform | Prosess | ✅ Identitetslivssyklus inkluderer følgende: Klargjøring (opprette med standardtilgang), Tilgangsjustering (utstede/oppheve etter hvert som roller endres), Periodisk ny sertifisering (kvartalsvis validering), Fjern klargjøring (umiddelbar oppheving) |
| Plattform | Organisasjon | ✅ SCIM (System for Cross-Domain Identity Management) implementeres for automatisk klargjøring fra identitetsleverandører |
| Plattform | Prosess | ✅ Klargjøring oppretter kontoer med samsvarsfunksjon for grunnleggende tilgang, utløst av HR-systemhendelser |
| Plattform | Prosess | ✅ Tilgangsjustering gir flere tillatelser etter hvert som roller utvides og opphever tillatelser når roller endres |
| Plattform | Prosess | ✅ Periodisk ny sertifisering skjer kvartalsvis der ledere ser gjennom og validerer tilgang for teamene sine |
| Plattform | Prosess | ✅ Forklaring opphever tilgang umiddelbart når ansettelsen avsluttes eller rollen ikke lenger krever Salesforce |
| Plattform | Organisasjon | ✅ Automatisert deteksjon identifiserer brukere som ikke har logget seg på innen 90 dager, og utløser arbeidsflyter for tilgangsvurdering |
| Plattform | Organisasjon | ✅ JIT-klargjøring oppretter brukere automatisk fra enkeltpålogging når det er aktuelt |
Anti-Mønstre
| Hvor du kan se | Hvordan dårlig ser ut |
|---|---|
| Plattform | Organisasjon | ⚡️ SCIM-klargjøring implementeres ikke selv om du har identitetsleverandørintegrering |
| Plattform | Prosess | ⚡️ Nye brukere opprettes manuelt uten standard introduksjonsprosedyrer |
| Plattform | Prosess | ⚡️ Første brukertilgang er inkonsistent eller basert på kopiering av eksisterende brukere |
| Plattform | Prosess | ⚡️ Tilgangsendringer for rolleendringer eller overføringer er forsinket eller ufullstendige |
| Plattform | Prosess | ⚡️ Offboarding er forsinket, tidligere ansatte beholder tilgang etter oppsigelse (ikke deaktivering samme dag) |
| Plattform | Organisasjon | ⚡️ Det finnes ingen automatisering for brukerklargjøring (bare manuell opprettelse av bruker) |
| Plattform | Prosess | ⚡️ Det finnes ingen kampanjer for ny tilgangssertifisering (ingen kvartalsvis eller årlig gjennomgang) |
| Plattform | Prosess | ⚡️ Unødvendig tilgang identifisert under ny sertifisering fjernes ikke |
| Plattform | Prosess | ⚡️ Ny tilgangssertifisering er ikke streng for privilegerte kontoer, tilgang for flere organisasjoner, eksterne brukere |
| Plattform | Organisasjon | ⚡️ Dormant-kontoer (ingen pålogging på 90+ dager) akkumuleres uten gjennomgang eller deaktivering |