Identitets- og adgangsstyring - mønstre
Læs mere om Well-Architected Trust → Identity and Access Management
Mønstre
| Hvor skal du se | Hvad der ser godt ud |
|---|---|
| Platform | Architektur | ✅ Adgangskontroller bekræfter identitet eksplicit på hver anmodning, uafhængigt af netværksplacering eller enhed |
| Platform | Architektur | ✅ Identitetsbaserede sikkerhedskontroller erstatter netværksbaserede Trust |
| Platform | Organisation | ✅ Adgangsafgørelser tager højde for, hvem der anmoder om adgang (godkendelse), hvad de er godkendt til at gøre (godkendelse) og kontekst (enhed, placering) |
| Platform | Dokumentation | ✅ Sikkerhedsarkitektur dokumenterer identitet som den primære Trust, ikke netværksperimeter |
Anti-mønstre
| Hvor skal du se | Hvad ser dårligt ud |
|---|---|
| Platform | Architektur | ⚡️ Brugere på virksomhedsnetværk eller VPN antages at være pålidelige og tildeles bredere adgang baseret på netværksposition alene |
| Platform | Architektur | ⚡️ Adgangskontroller er afhængige af netværksperimeter snarere end identitetsbekræftelse |
| Platform | Organisation | ⚡️ Adgangsafgørelser tager ikke kontekstsignaler med i betragtning (enhed, placering, tid, adfærdsmønstre) |
| Platform | Dokumentation | ⚡️ Sikkerhedsarkitektur behandler netværksplacering som den primære Trust |
Mønstre
| Hvor skal du se | Hvad der ser godt ud |
|---|---|
| Platform | Organisation | ✅ Løsninger bruger alle fire Salesforce-adgangslag: Organisation (licenser, funktioner), Objekt (CRUD), Felt (FLS), Registrering (deling) |
| Platform | Organisation | ✅ Adgangsmodel er designet top-down (organisation → objekt → felt → registrering) og valideret bund-op |
| Platform | Organisation | ✅ Standarder for hele organisationen (OWD) er indstillet til Privat for objekter, der indeholder følsomme data |
| Platform | Organisation | ✅ OWD’er, der er indstillet til Offentlig skrivebeskyttet, er begrænset til referenceobjekter (produkter, prislister), hvor bred synlighed understøtter forretning uden at vise risiko |
| Platform | Organisation | ✅ Begrænsninger på organisationsniveau (licenser, IP-områder, logintider, funktionstilladelser) definerer basislinjefunktioner for brugerpopulationer |
| Platform | Organisation | ✅ Objekttilladelser (via profiler og tilladelsessæt) kontrollerer adgangen Opret, Læs, Rediger og Slet til hvert objekt for brugersegmenter |
| Platform | Organisation | ✅ Sikkerhed på feltniveau beskytter følsomme felter, selv når der gives objektadgang |
| Platform | Organisation | ✅ Deling på registreringsniveau bruger rollehierarki og delingsregler baseret på dokumenterede forretningskrav |
| Platform | Organisation | ✅ Adgang udvides med vilje fra restriktiv basislinje, ikke begrænset efter tilladelsesstandarder |
Anti-mønstre
| Hvor skal du se | Hvad ser dårligt ud |
|---|---|
| Platform | Organisation | Adgangsmodel bruger ikke alle fire lag (organisation, objekt, felt, registrering) |
| Platform | Organisation | ⚡️ OWD’er er indstillet til Offentlig Læs/Skriv for at gøre det nemmere under udvikling uden begrænsningsplaner |
| Platform | Organisation | ⚡️ Overdrevent tilladende OWD’er, der er angivet tidligt, bliver eksponentielt vanskeligere at begrænse, efterhånden som datamængden vokser, og forretningsprocesser krystalliseres |
| Platform | Organisation | ⚡️ Sikkerhed på feltniveau er ikke konfigureret, der udelukkende er afhængig af adgangskontroller på objekt- eller registreringsniveau |
Mønstre
| Hvor skal du se | Hvad der ser godt ud |
|---|---|
| Platform | Organisation | ✅ Godkendelse med flere faktorer (MFA) håndhæves for alle brugere, der får adgang til produktionsmiljøer (obligatorisk for brugergrænsefladeadgang) |
| Platform | Organisation | ✅ MFA udvides til rettighedshandlinger, herunder massedataeksport, tilladelsesændringer og administrativ konfiguration |
| Platform | Organisation | ✅ Single sign-on (SSO) bruger SAML 2.0- eller OpenID Connect-protokoller |
| Platform | Organisation | ✅ Sessionstimeout er konfigureret korrekt: 2 timer for standardbrugere, 15-30 minutter for administratorer og brugere, der har adgang til begrænsede data |
| Platform | Organisation | ✅ IP-begrænsninger håndhæves for administrative profiler og integrationsbrugere |
| Platform | Organisation | ✅ Logintider begrænser servicekonti til forventede driftsmæssige vinduer |
| Platform | Organisation | ✅ Indbygget enhedsaktivering bekræfter logins fra ikke-genkendte enheder. MFA- og IP-begrænsninger tilføjer beskyttelse for konti med høje rettigheder |
| Platform | Organisation | ✅ Hvis SSO er aktiveret, har godkendte administratorbrugere direkte loginadgang (brudglasprocedurer) |
| Platform | Organisation | ✅ Relationen mellem brugere og enheder, der logger på Salesforce, er 1:1 (ingen delte brugerkonti) |
| Platform | Organisation | ✅ API-adgangskontrol forhindrer brugere i at godkende via ikke-autoriserede tilsluttede apps |
| Platform | Navngivne legitimationsoplysninger | ✅ Navngivne legitimationsoplysninger og eksterne legitimationsoplysninger administrerer godkendelse centralt med roteringsfunktioner |
| Platform | Navngivne legitimationsoplysninger | ✅ Navngivne legitimationsoplysninger - abstrakte godkendelsesdetaljer fra kode, der aktiverer opdateringer af legitimationsoplysninger uden kodeændringer |
| Platform | Navngivne legitimationsoplysninger | ✅ Legitimationsoplysninger integreres aldrig i kode, konfigurationsfiler eller versionskontrol |
| Platform | Apex | ✅ Metoder, der kører godkendelse, bruger navngivne legitimationsoplysninger til at håndtere brugernavn/adgangskode-forløb |
| Platform | Apex | ✅ Ingen brugernavne eller adgangskoder vises i kode i læsbare formater (ingen hardcodede værdier eller strenge) |
| Platform | Aura | ✅ Metoder, der kører godkendelse, bruger navngivne legitimationsoplysninger til at håndtere brugernavn/adgangskode-forløb |
| Platform | Aura | ✅ Ingen brugernavne eller adgangskoder vises i kode i læsbare formater |
| Platform | Lightning Web-komponenter (LWC) | ✅ Metoder, der kører godkendelse, bruger navngivne legitimationsoplysninger |
| Platform | Lightning Web-komponenter (LWC) | ✅ Ingen brugernavne eller adgangskoder vises i kode |
| Integration | API | ✅ OAuth 2.0 JWT Bearer-forløb bruges til server-til-server-integrationer i betroede miljøer (foretrækkes for produktionsintegrationer) |
| Integration | API | ✅ OAuth 2.0-webserverforløb bruges til server-til-server-integrationer, der kræver brugerkontekst |
| Integration | API | ✅ OAuth 2.0-enhedsforløb bruges til headless-enheder. CLI og CI/CD-værktøjer bruger webserverforløb (sf org login web) eller JWT Bearer-forløb (sf org login jwt) – enhedsforløbet blev blokeret for Salesforce CLI-standardtilsluttet app fra den 28. aug. 2025 |
| Integration | API | ✅ Brugernavn-adgangskode OAuth-forløb bruges ikke. Eksisterende integrationer, der er afhængige af det, migreres til JWT Bearer- eller klientlegitimationsforløb |
Anti-mønstre
| Hvor skal du se | Hvad ser dårligt ud |
|---|---|
| Platform | Organisation | ⚡️ MFA håndhæves ikke for produktionsmiljøadgang |
| Platform | Organisation | ⚡️ Loginkonfigurationer er ikke i overensstemmelse med Salesforce MFA-krav |
| Platform | Organisation | ⚡️ MFA udvides ikke til rettighedshandlinger (masseeksporter, tilladelsesændringer, administrativ konfiguration) |
| Platform | Organisation | ⚡️ Sessionstimeout er ikke konfigureret eller er overdrevent tilladende (>24 timer) |
| Platform | Organisation | ⚡️ Sessionspolitikker skelner ikke mellem standardbrugere og administratorer/brugere, der har adgang til begrænsede data |
| Platform | Organisation | IP-begrænsninger håndhæves ikke for administrative profiler og integrationsbrugere |
| Platform | Organisation | ⚡️ Servicekonti har ikke logintider begrænset til forventede driftsvinduer |
| Platform | Organisation | ⚡️ Konti med høje rettigheder er afhængige af intet udover enhedsaktivering – ingen MFA- eller IP-begrænsninger tilføjet |
| Platform | Organisation | ⚡️ Hvis SSO er aktiveret, har ingen godkendte administratorbrugere direkte loginadgang (ingen pauseglasprocedurer) |
| Platform | Organisation | ⚡️ Relationen mellem brugere og enheder er ikke 1:1 (der findes delte brugerkonti) |
| Platform | Organisation | ⚡️ API-adgangskontrol er ikke aktiveret |
| Platform | Navngivne legitimationsoplysninger | ⚡️ Legitimationsoplysninger integreres direkte i kode, konfigurationsfiler eller versionskontrol |
| Platform | Apex | ⚡️ Brugernavne og adgangskoder vises i kode i læsbare formater |
| Platform | Apex | ⚡️ Godkendelse håndteres ad hoc uden ensartet implementering |
| Platform | Aura | ⚡️ Godkendelse håndteres ad hoc uden navngivne legitimationsoplysninger |
| Platform | Aura | ⚡️ Brugernavne og adgangskoder vises i kode |
| Platform | Lightning Web-komponenter (LWC) | ⚡️ Godkendelse håndteres ad hoc uden navngivne legitimationsoplysninger |
| Platform | Lightning Web-komponenter (LWC) | ⚡️ Brugernavne og adgangskoder vises i kode |
| Platform | Forretning | ⚡️ Brugerprovisionering og deprovisionering af servicelaftaler og krav findes ikke |
| Integration | API | ⚡️ Brugernavn-adgangskode OAuth-forløb bruges, når der er flere sikre OAuth-forløb tilgængelige |
| Integration | API | OAuth-omfang er overdrevent tilladende (fuld adgang, når begrænset omfang er tilstrækkeligt) |
| Integration | API | ⚡️ Klientlegitimationsoplysninger (klient-id, klienthemmelighed) lagres usikret i kode- eller konfigurationsfiler |
Mønstre
| Hvor skal du se | Hvad der ser godt ud |
|---|---|
| Platform | Organisation | ✅ Rollehierarkiets dybde er 5-7 niveauers maksimum (undgå overhead-ydeevne og fejlfindingskompleksitet) |
| Platform | Organisation | ✅ Tilladelsessæt og tilladelsessætgrupper giver fleksibel, yderligere adgang uden profiludbredelse |
| Platform | Organisation | ✅ Tilladelsessæt tildeler adgang til specifikke jobfunktioner, applikationer eller midlertidige forhøjede rettigheder |
| Platform | Organisation | ✅ Tilladelsessætgrupper kombinerer relaterede tilladelsessæt med deaktiveringsfunktioner for undtagelser |
| Platform | Organisation | ✅Al funktionel adgang tildeles gennem tilladelsessæt og tilladelsessætgrupper (ikke profiler), hvilket giver fleksibilitet, efterhånden som jobroller udvikles |
| Platform | Organisation | ✅ Politikker for transaktionssikkerhed udvider autorisation med kontekstuel evaluering i realtid |
| Platform | Organisation | ✅ Politikker for transaktionssikkerhed registrerer og blokerer uregelmæssig adfærd (massedata downloads, der overskrider mønstre, login fra uventede geografiske områder, tilladelsesændringer uden for ændringsvinduer) |
| Platform | Organisation | ✅ IP-begrænsninger konfigureres for meget følsomme handlinger eller dataadgang |
| Platform | Organisation | ✅ En entydig kun API-integrationsbruger konfigureres for hver integration |
| Platform | Apex | ✅ Alle kodeadgang til data gennemtvinger CRUD og FLS ved brug af METHUSER_MODE, SYSTEM_MODE-nøgleord eller Security.stripInaccessible()-metoder |
| Platform | Apex | ✅ SOQL-forespørgsler bruger med USER_MODE eller med SYSTEM_MODE-nøgleord eksplicit baseret på forretningskrav |
| Platform | Apex | ✅ DML-handlinger bruger Security.stripInaccessible() til adgangshåndhævelse før insert/update/upsert-handlinger |
| Platform | Apex | ✅ Database DML-erklæringer erklærer brugeren eller systemtilstanden eksplicit for datahandlinger |
| Platform | Apex | ✅ Databasehandlinger bruger stripInaccessible()-metoder til at filtrere forespørgsels- og underforespørgselsresultater |
| Platform | Apex | ✅ Delingsnøgleord (med deling, uden deling, overtaget deling) bruges korrekt baseret på forretningssikkerhedskrav |
| Platform | Designstandarder | ✅ Anvendelsessituationer til tildeling af forhøjede rettigheder (Rediger alle data, Vis alle data) er tydeligt dokumenteret med forretningsjustering |
Anti-mønstre
| Hvor skal du se | Hvad ser dårligt ud |
|---|---|
| Platform | Organisation | Rollehierarki er dybere end 5-7 niveauer, hvilket skaber overhead-ydeevne i delingsberegninger og fejlfinding af kompleksitet |
| Platform | Organisation | ⚡️ Rollehierarki giver bred adgang uden forretningsjustering |
| Platform | Organisation | Profiler duplikeres gentaget for mindre tilladelsesvariationer og opretter dusinvis af profiler med uklare forskelle |
| Platform | Organisation | Profiler indeholder adgangskontroller for metadata (skal bruge tilladelsessæt) |
| Platform | Organisation | ⚡️ Politikker for transaktionssikkerhed implementeres ikke for at registrere afvigelse |
| Platform | Organisation | IP-begrænsninger er ikke konfigureret for meget følsomme handlinger eller dataadgang |
| Platform | Organisation | ⚡️ Kun API-brugere er ikke konfigureret eller deles på tværs af flere integrationer |
| Platform | Organisation | Tilladelserne Vis alle data eller Rediger alle data tildeles uden dokumenteret begrundelse |
| Platform | Apex | ⚡️ SOQL/SOSL-forespørgsler og DML-handlinger kører i standardsystemtilstand uden eksplicitte adgangskontroller |
| Platform | Apex | ⚡️ CRUD- og FLS-håndhævelse er inkonsekvent eller mangler |
| Platform | Apex | ⚡️ SOQL er afhængig af WITH SECURITY_ENFORCED, som er blevet fjernet og nu forårsager en kompileringsfejl (erstat med WITH USER_MODE) |
| Platform | Apex | Delingsnøgleord bruges inkonsekvent eller slet ikke |
| Platform | Designstandarder | ⚡️ Anvendelsessituationer til tildeling af forhøjede tilladelser er ikke tydeligt dokumenteret |
Mønstre
| Hvor skal du se | Hvad der ser godt ud |
|---|---|
| Platform | Data 360 | ✅ RBAC (roller, profiler, tilladelsessæt) kontrollerer platformsadgang (der kan bruge Data 360), ABAC kontrollerer dataadgang (hvad data de ser baseret på attributter) |
| Platform | Data 360 | ✅ AI-agenter eksekveres i den anmodende brugers kontekst (på vegne af), så agentgenererede forespørgsler begrænses af den pågældende brugers adgang i stedet for at køre med adgang på systemniveau |
| Platform | Dokumentation | ✅ Dataklassificeringens taksonomi dokumenteres med attributdefinitioner, håndhævelsesregler og forretningsjustering |
Anti-mønstre
| Hvor skal du se | Hvad ser dårligt ud |
|---|---|
| Platform | Data 360 | Adgang, der skal følge dataklassificering, tvinges gennem rollehierarki og deling, som ikke kan udtrykke det, i stedet for at gå til attributbaseret adgangskontrol |
| Platform | Data 360 | ⚡️ FLS-tilsidesættelse: brugere uden adgang på feltniveau henter data via API- eller SOQL-forespørgsler, der ikke håndhæver FLS |
| Platform | Data 360 | ⚡️ AI-agenter forespørger på data uden at køre i den anmodende brugers kontekst. Agentgenererede forespørgsler tilsidesætter adgangskontroller på objekt-, felt- og registreringsniveau |
| Platform | Data 360 | ⚡️ Agentkørselskontekst inkluderer ikke bruger-på vegne-attributter. Agenter fungerer med adgang på systemniveau |
| Platform | Dokumentation | ⚡️ Dataklassificeringsklassificering er ikke-dokumenteret. Attributdefinitioner varierer efter team, der opretter inkonsekvent håndhævelse |
Mønstre
| Hvor skal du se | Hvad der ser godt ud |
|---|---|
| Platform | Organisation | ✅ Kritiske påvirkningskonti (systemadministratorer, integrationsbrugere, automatiserede proceskonti) identificeres og spores i aktivlager |
| Platform | Organisation | ✅ Kritiske påvirkningskonti repræsenterer mål af høj værdi på grund af forhøjede rettigheder, der giver bred platformsadgang |
| Platform | Organisation | ✅ Hardware-sikkerhedsnøgler eller godkendelsesapps kræves for MFA (ikke sms, som er sårbare over for SIM-omskifter) |
| Platform | Organisation | ✅ IP-loginområder er begrænset til kendte administrative placeringer |
| Platform | Organisation | ✅ Loginadvarsler og tilladelsesændringsadviseringer er aktiveret |
| Platform | Organisation | ✅ Kvartalsvise adgangsgennemgange udføres med dokumenteret attestation |
| Platform | Organisation | ✅ Der findes pauseglasprocedurer for nødadgang med efterbrugsovervågning |
| Integration | Servicekonti | ✅ OAuth-forløb bruges til integrations- og servicekonti (aldrig brugernavn-adgangskode) |
| Integration | Servicekonti | ✅ IP-begrænsninger håndhæves for integrationsbrugere |
| Integration | Servicekonti | ✅ Roteringsplaner for legitimationsoplysninger implementeres (kvartalsvis eller pr. politik) |
| Integration | Servicekonti | ✅ Uregelmæssige API-anvendelsesmønstre overvåges gennem Begivenhedsovervågning |
| Integration | Servicekonti | ✅ Hver integration har en dedikeret servicekonto med mindst krævede tilladelser (ikke delt “integrationsbruger” med bred adgang) |
| Integration | Servicekonti | ✅ Servicekonti anvender mindst rettighed strengt, da de fungerer uovervåget |
Anti-mønstre
| Hvor skal du se | Hvad ser dårligt ud |
|---|---|
| Platform | Organisation | ⚡️ Kritiske påvirkningskonti (administrator, integration, automatisering) identificeres, spores eller lagres ikke |
| Platform | Organisation | ⚡️ Systemadministratorer bruger SMS-baseret MFA i stedet for hardware-sikkerhedsnøgler eller godkendelsesapps |
| Platform | Organisation | ⚡️ Kritiske påvirkningskonti har ingen begrænsninger for logintid eller IP |
| Platform | Organisation | ⚡️ Der konfigureres ingen advarsler for login- eller tilladelsesændringer på rettighedskonti |
| Platform | Organisation | Adgang til kritisk påvirkende konti gennemses eller gennemses aldrig uregelmæssigt (ikke kvartalsvist) |
| Platform | Organisation | ⚡️ Der findes ingen pauseglasprocedurer for nødadgang |
| Integration | Servicekonti | ⚡️ En enkelt “API-bruger”-konto deles på tværs af flere integrationer med tilladelsen Rediger alle data |
| Integration | Servicekonti | ⚡️ Servicekonti bruger brugernavn-adgangskode-godkendelse, når OAuth er tilgængelig |
| Integration | Servicekonti | ⚡️ Servicekontolegitimationsoplysninger bruger statiske adgangskoder, der er uændrede i årevis (ingen rotation) |
| Integration | Servicekonti | ⚡️ Servicekonti har overdreven rettigheder ud over det, som integrationen kræver |
| Integration | Servicekonti | ⚡️ Uregelmæssige API-anvendelsesmønstre for servicekonti overvåges ikke |
Mønstre
| Hvor skal du se | Hvad der ser godt ud |
|---|---|
| Platform | Proces | ✅ Identity-livscyklus inkluderer: Klargøring (opret med basisadgang), Adgangsjustering (tildel/tilbagekald, når roller ændres), Periodisk gencertificering (kvartalsvis validering), Afgrænsning (øjeblikkelig tilbagekaldelse) |
| Platform | Organisation | ✅ SCIM (System for Cross-Domain Identity Management) implementeres til automatiseret provisionering fra identitetsudbydere |
| Platform | Proces | ✅ Provisionering opretter konti med basisadgangsmatchningsjobfunktion, udløst af HR-systembegivenheder |
| Platform | Proces | ✅ Adgangsjustering tildeler yderligere tilladelser, når roller udvides og tilbagekalder tilladelser, når roller ændres |
| Platform | Proces | ✅ Periodisk gencertificering forekommer kvartalsvist, hvor managers gennemser og validerer adgang for deres teams |
| Platform | Proces | ✅ Fjernelse af provisionering tilbagekalder adgang med det samme, når beskæftigelsen slutter, eller rollen ikke længere kræver Salesforce |
| Platform | Organisation | ✅ Automatiseret registrering identificerer brugere, der ikke er logget ind inden for 90 dage, og udløser arbejdsflows for adgangsgennemgang |
| Platform | Organisation | ✅ JIT-provisionering opretter brugere automatisk fra SSO, når det er relevant |
Anti-mønstre
| Hvor skal du se | Hvad ser dårligt ud |
|---|---|
| Platform | Organisation | ⚡️ SCIM-provisionering implementeres ikke på trods af at have identitetsudbyderintegration |
| Platform | Proces | ⚡️ Nye brugere oprettes manuelt uden standardintroduktionsprocedurer |
| Platform | Proces | ⚡️ Indledende brugeradgang er inkonsekvent eller baseret på kopiering af eksisterende brugere |
| Platform | Proces | ⚡️ Adgangsændringer for rolleændringer eller overførsler er forsinkede eller ufuldstændige |
| Platform | Proces | ⚡️ Offboarding er forsinket. Tidligere medarbejdere bevarer adgang efter opsigelse (ikke deaktivering samme dag) |
| Platform | Organisation | ⚡️ Der findes ingen automatisering for brugerprovisionering (kun manuel brugeroprettelse) |
| Platform | Proces | ⚡️ Der findes ingen gencertificeringskampagner (ingen kvartalsvis eller årlig gennemgang) |
| Platform | Proces | ⚡️ Unødvendig adgang, der er identificeret under gencertificering, fjernes ikke |
| Platform | Proces | ⚡️ Gencertificering af adgang er ikke rigtigt for rettighedskonti, krydsorganisationsadgang, eksterne brugere |
| Platform | Organisation | Dormant-konti (ingen login på 90+ dage) akkumuleres uden gennemgang eller deaktivering |