--- schema_version: "1" id: e64083821e1400fc9a0852d7641cee1b00a050ab99ae9daf87433134cea52e6d title: Gestione delle identità e degli accessi - Schemi collection: architect version: current locale: it-it portal_url: https://docs.salesforce.com/architect/current/it-it/well-architected/guides/trust-identity-access-patterns.md canonical_url: https://architect.salesforce.com/docs/architect/it-it/well-architected/guide/trust-identity-access-patterns.html source_site: architect.salesforce.com content_type: documentation content_hash: 44457c46890d6372dd9118c0507746795fb6effa91de016f3f0885519248d4a1 products: - Framework ben progettato - Architect Site Content Repo --- # Gestione delle identità e degli accessi - Schemi
Ulteriori informazioni su Well-Architected [Trust](/docs/architect/it-it/well-architected/guide/trust.html) → [Gestione identità e accessi](/docs/architect/it-it/well-architected/guide/trust.html#identity-and-access-management) ## Identità come perimetro principale **Schemi** | Dove cercare | Che bell'aspetto | | --- | --- | | Piattaforma \| Architettura | ✅ I controlli di accesso verificano l'identità in modo esplicito su ogni richiesta, indipendentemente dalla posizione di rete o dal dispositivo | | Piattaforma \| Architettura | ✅ I controlli di sicurezza basati sull'identità sostituiscono i presupposti Trust basati sulla rete | | Piattaforma \| Organizzazione | ✅ Le decisioni di accesso considerano chi richiede l'accesso (autenticazione), cosa è autorizzato a fare (autorizzazione) e contesto (dispositivo, posizione) | | Piattaforma \| Documentazione | ✅ L'architettura di sicurezza documenta l'identità come confine Trust principale, non come perimetro di rete | **Anti-schemi** | Dove cercare | Che brutto aspetto | | --- | --- | | Piattaforma \| Architettura | ⚠️ Gli utenti su rete aziendale o VPN sono considerati affidabili e ricevono un accesso più ampio in base alla sola posizione di rete | | Piattaforma \| Architettura | ⚠️ I controlli di accesso si basano sul perimetro della rete anziché sulla verifica dell'identità | | Piattaforma \| Organizzazione | ⚠️ Le decisioni di accesso non considerano i segnali di contesto (dispositivo, posizione, ora, modelli di comportamento) | | Piattaforma \| Documentazione | ⚠️ L'architettura di sicurezza considera la posizione di rete come confine Trust principale | ## Modello di accesso a quattro livelli Salesforce **Schemi** | Dove cercare | Che bell'aspetto | | --- | --- | | Piattaforma \| Organizzazione | ✅ Le soluzioni sfruttano tutti e quattro i livelli di accesso Salesforce: Organizzazione (licenze, funzioni), Oggetto (CRUD), Campo (FLS), Record (condivisione) | | Piattaforma \| Organizzazione | ✅ Il modello di accesso è progettato dall'alto verso il basso (organizzazione → oggetto → campo → record) e convalidato dal basso verso l'alto | | Piattaforma \| Organizzazione | ✅ Le impostazioni predefinite dell'organizzazione (OWD) sono impostate su Privato per gli oggetti contenenti dati sensibili | | Piattaforma \| Organizzazione | ✅ OWD impostati su Sola lettura pubblica sono limitati agli oggetti di riferimento (prodotti, listini prezzi) in cui un'ampia visibilità supporta il business senza esporre rischi | | Piattaforma \| Organizzazione | ✅ I vincoli a livello di organizzazione (licenze, intervalli IP, orari di accesso, autorizzazioni funzioni) definiscono le funzionalità di base per le popolazioni di utenti | | Piattaforma \| Organizzazione | ✅ Le autorizzazioni oggetto (tramite profili e insiemi di autorizzazioni) controllano l'accesso in creazione, lettura, modifica ed eliminazione a ogni oggetto per i segmenti di utenti | | Piattaforma \| Organizzazione | ✅ La protezione a livello di campo protegge i campi sensibili anche quando viene concesso l'accesso agli oggetti | | Piattaforma \| Organizzazione | ✅ La condivisione a livello di record utilizza la gerarchia dei ruoli e le regole di condivisione in base ai requisiti aziendali documentati | | Piattaforma \| Organizzazione | ✅ L'accesso viene ampliato deliberatamente dalla base di riferimento restrittiva, non limitato dopo le impostazioni predefinite permissive | **Anti-schemi** | Dove cercare | Che brutto aspetto | | --- | --- | | Piattaforma \| Organizzazione | ⚠️ Il modello di accesso non sfrutta tutti e quattro i livelli (organizzazione, oggetto, campo, record) | | Piattaforma \| Organizzazione | ⚠️ Gli OWD sono impostati su Lettura/Scrittura pubblica per comodità durante lo sviluppo senza piani di restrizione | | Piattaforma \| Organizzazione | ⚠️ Le OWD troppo permissive impostate in anticipo diventano esponenzialmente più difficili da limitare man mano che il volume dei dati cresce e i processi aziendali si cristallizzano | | Piattaforma \| Organizzazione | ⚠️ La protezione a livello di campo non è configurata, basandosi esclusivamente sui controlli di accesso a livello di oggetto o record | ## Architettura di autenticazione **Schemi** | Dove cercare | Che bell'aspetto | | --- | --- | | Piattaforma \| Organizzazione | ✅ L'autenticazione a più fattori (MFA) viene applicata per tutti gli utenti che accedono agli ambienti di produzione (obbligatoria per l'accesso all'interfaccia utente) | | Piattaforma \| Organizzazione | ✅ La MFA è estesa alle operazioni privilegiate, incluse le esportazioni di dati in blocco, le modifiche delle autorizzazioni e la configurazione amministrativa | | Piattaforma \| Organizzazione | ✅ Single Sign-On (SSO) utilizza protocolli SAML 2.0 o OpenID Connect | | Piattaforma \| Organizzazione | ✅ Timeout sessione configurato in modo appropriato: 2 ore per gli utenti standard, 15-30 minuti per gli amministratori e gli utenti che accedono a Dati limitati | | Piattaforma \| Organizzazione | ✅ Le restrizioni IP vengono applicate per i profili amministrativi e gli utenti integrazione | | Piattaforma \| Organizzazione | ✅ Gli orari di accesso limitano gli account di servizio alle finestre operative previste | | Piattaforma \| Organizzazione | ✅ L'attivazione nativa del dispositivo verifica gli accessi da dispositivi non riconosciuti; le restrizioni MFA e IP aggiungono protezione per gli account con privilegi elevati | | Piattaforma \| Organizzazione | ✅ Se SSO è abilitato, gli utenti amministratori approvati hanno accesso diretto (procedure break-glass) | | Piattaforma \| Organizzazione | ✅ La relazione tra utenti ed entità che accedono a Salesforce è 1:1 (nessun account utente condiviso) | | Piattaforma \| Organizzazione | ✅ API Access Control impedisce agli utenti di eseguire l'autenticazione tramite applicazioni connesse non autorizzate | | Piattaforma \| Credenziali denominate | ✅ Le credenziali denominate e le credenziali esterne gestiscono l'autenticazione a livello centrale con funzionalità di rotazione | | Piattaforma \| Credenziali denominate | ✅ Le credenziali denominate astraggono i dettagli di autenticazione dal codice, abilitando gli aggiornamenti delle credenziali senza modifiche del codice | | Piattaforma \| Credenziali denominate | ✅ Le credenziali non sono mai incorporate nel codice, nei file di configurazione o nel controllo delle versioni | | Piattaforma \| Apex | ✅ I metodi che eseguono l'autenticazione utilizzano le credenziali denominate per gestire i flussi nome utente / password | | Piattaforma \| Apex | ✅ Nessun nome utente o password viene visualizzato nel codice in formati leggibili (nessun valore o stringa codificati) | | Piattaforma \| Aura | ✅ I metodi che eseguono l'autenticazione utilizzano le credenziali denominate per gestire i flussi nome utente / password | | Piattaforma \| Aura | ✅ Nessun nome utente o password viene visualizzato nel codice in formati leggibili | | Piattaforma \| Componenti Web Lightning (LWC) | ✅ I metodi che eseguono l'autenticazione utilizzano le credenziali denominate | | Piattaforma \| Componenti Web Lightning (LWC) | ✅ Nessun nome utente o password viene visualizzato nel codice | | Integrazione \| API | ✅ Il flusso bearer JWT OAuth 2.0 viene utilizzato per le integrazioni da server a server in ambienti affidabili (preferito per le integrazioni di produzione) | | Integrazione \| API | ✅ Il flusso server Web OAuth 2.0 viene utilizzato per le integrazioni da server a server che richiedono contesto utente | | Integrazione \| API | ✅ il flusso dispositivo OAuth 2.0 viene utilizzato per i dispositivi headless; il tooling CLI e CI/CD utilizzano il flusso server Web (`sf org login web`) o il flusso bearer JWT (`sf org login jwt`): il flusso dispositivo è stato bloccato per l'applicazione connessa Salesforce CLI predefinita a partire dal 28 agosto 2025 | | Integrazione \| API | ✅ Il flusso OAuth nome utente-password non viene utilizzato; le integrazioni esistenti che si basano su di esso vengono migrate al flusso bearer JWT o credenziali client | **Anti-schemi** | Dove cercare | Che brutto aspetto | | --- | --- | | Piattaforma \| Organizzazione | ⚠️ La MFA non viene applicata per l'accesso all'ambiente di produzione | | Piattaforma \| Organizzazione | ⚠️ Le configurazioni di accesso non sono conformi ai requisiti della MFA di Salesforce | | Piattaforma \| Organizzazione | ⚠️ La MFA non è estesa alle operazioni privilegiate (esportazioni in blocco, modifiche delle autorizzazioni, configurazione amministrativa) | | Piattaforma \| Organizzazione | ⚠️ Timeout sessione non configurato o eccessivamente permissivo (>24 ore) | | Piattaforma \| Organizzazione | ⚠️ Le policy di sessione non distinguono tra utenti standard e amministratori/utenti che accedono a Dati limitati | | Piattaforma \| Organizzazione | ⚠️ Le restrizioni IP non vengono applicate per i profili amministrativi e gli utenti integrazione | | Piattaforma \| Organizzazione | ⚠️ Gli account di servizio non hanno orari di accesso limitati alle finestre operative previste | | Piattaforma \| Organizzazione | ⚠️ Gli account con privilegi elevati non si basano su nulla oltre all'attivazione del dispositivo – nessuna restrizione MFA o IP aggiunta | | Piattaforma \| Organizzazione | ⚠️ Se SSO è abilitato, nessun utente amministratore approvato ha accesso diretto (nessuna procedura break-glass) | | Piattaforma \| Organizzazione | ⚠️ La relazione tra utenti ed entità non è 1:1 (esistono account utente condivisi) | | Piattaforma \| Organizzazione | ⚠️ Controllo accesso API non abilitato | | Piattaforma \| Credenziali denominate | ⚠️ Le credenziali sono incorporate direttamente nel codice, nei file di configurazione o nel controllo delle versioni | | Piattaforma \| Apex | ⚠️ I nomi utente e le password vengono visualizzati nel codice in formati leggibili | | Piattaforma \| Apex | ⚠️ L'autenticazione viene gestita ad hoc senza un'implementazione coerente | | Piattaforma \| Aura | ⚠️ L'autenticazione viene gestita ad hoc senza credenziali denominate | | Piattaforma \| Aura | ⚠️ I nomi utente e le password vengono visualizzati nel codice | | Piattaforma \| Componenti Web Lightning (LWC) | ⚠️ L'autenticazione viene gestita ad hoc senza credenziali denominate | | Piattaforma \| Componenti Web Lightning (LWC) | ⚠️ I nomi utente e le password vengono visualizzati nel codice | | Piattaforma \| Business | ⚠️ Non esistono SLA e requisiti di provisioning utente | | Integrazione \| API | ⚠️ Il flusso OAuth nome utente-password viene utilizzato quando sono disponibili flussi OAuth più sicuri | | Integrazione \| API | ⚠️ Gli ambiti OAuth sono eccessivamente permissivi (accesso completo quando è sufficiente un ambito limitato) | | Integrazione \| API | ⚠️ Le credenziali client (ID client, segreto client) sono memorizzate in modo non sicuro in codice o file di configurazione | ## Autorizzazione e controllo dell'accesso **Schemi** | Dove cercare | Che bell'aspetto | | --- | --- | | Piattaforma \| Organizzazione | ✅ La profondità della gerarchia dei ruoli è di 5-7 livelli massimi (evitando sovraccarichi di prestazioni e complessità di risoluzione dei problemi) | | Piattaforma \| Organizzazione | ✅ Gli insiemi di autorizzazioni e i gruppi di insiemi di autorizzazioni offrono un accesso flessibile e additivo senza proliferazione dei profili | | Piattaforma \| Organizzazione | ✅ Gli insiemi di autorizzazioni concedono l'accesso a funzioni lavorative, applicazioni o privilegi temporanei elevati | | Piattaforma \| Organizzazione | ✅ I gruppi di insiemi di autorizzazioni combinano gli insiemi di autorizzazioni correlati con le funzionalità di disattivazione delle eccezioni | | Piattaforma \| Organizzazione | ✅ Tutto l'accesso alle funzionalità viene concesso tramite insiemi di autorizzazioni e gruppi di insiemi di autorizzazioni (non profili), offrendo flessibilità man mano che i ruoli lavorativi si evolvono | | Piattaforma \| Organizzazione | ✅ Le policy sulla sicurezza delle transazioni estendono l'autorizzazione con una valutazione contestuale in tempo reale | | Piattaforma \| Organizzazione | ✅ Le policy sulla sicurezza delle transazioni rilevano e bloccano il comportamento anomalo (download di dati in blocco che superano gli schemi, accesso da aree geografiche impreviste, modifiche delle autorizzazioni al di fuori delle finestre di modifica) | | Piattaforma \| Organizzazione | ✅ Le restrizioni IP sono configurate per operazioni altamente sensibili o accesso ai dati | | Piattaforma \| Organizzazione | ✅ Un utente integrazione solo API univoco è configurato per ogni integrazione | | Piattaforma \| Apex | ✅ Tutto il codice che accede ai dati impone CRUD e FLS utilizzando le parole chiave WITH USER_MODE, WITH SYSTEM_MODE o i metodi Security.stripInaccessible() | | Piattaforma \| Apex | ✅ Le query SOQL utilizzano parole chiave WITH USER_MODE o WITH SYSTEM_MODE in modo esplicito in base ai requisiti aziendali | | Piattaforma \| Apex | ✅ Le operazioni DML utilizzano Security.stripInaccessible() per l'imposizione dell'accesso prima delle operazioni di inserimento/aggiornamento/inserimento | | Piattaforma \| Apex | ✅ le istruzioni DML del database dichiarano esplicitamente la modalità utente o di sistema per le operazioni sui dati | | Piattaforma \| Apex | ✅ Le operazioni del database utilizzano metodi stripInaccessible() per filtrare i risultati delle query e delle sottoquery | | Piattaforma \| Apex | ✅ Le parole chiave di condivisione (con condivisione, senza condivisione, condivisione ereditata) vengono utilizzate in modo appropriato in base ai requisiti di sicurezza aziendali | | Piattaforma \| Standard di progettazione | ✅ I casi d'uso per la concessione di privilegi elevati (Modifica tutti i dati, Visualizza tutti i dati) sono chiaramente documentati con giustificazione aziendale | **Anti-schemi** | Dove cercare | Che brutto aspetto | | --- | --- | | Piattaforma \| Organizzazione | ⚠️ La gerarchia dei ruoli è più profonda di 5-7 livelli, creando un sovraccarico di prestazioni nei calcoli di condivisione e nella risoluzione dei problemi | | Piattaforma \| Organizzazione | ⚠️ La gerarchia dei ruoli concede un ampio accesso senza giustificazione aziendale | | Piattaforma \| Organizzazione | ⚠️ I profili vengono clonati ripetutamente per lievi variazioni delle autorizzazioni, creando decine di profili con distinzioni poco chiare | | Piattaforma \| Organizzazione | ⚠️ I profili contengono controlli di accesso per i metadati (dovrebbero utilizzare gli insiemi di autorizzazioni) | | Piattaforma \| Organizzazione | ⚠️ Le policy sulla sicurezza delle transazioni non vengono implementate per rilevare comportamenti anomali | | Piattaforma \| Organizzazione | ⚠️ Le restrizioni IP non sono configurate per le operazioni altamente sensibili o l'accesso ai dati | | Piattaforma \| Organizzazione | ⚠️ Gli utenti solo API non sono configurati o sono condivisi tra più integrazioni | | Piattaforma \| Organizzazione | ⚠️ Le autorizzazioni Visualizza tutti i dati o Modifica tutti i dati vengono concesse senza giustificazione documentata | | Piattaforma \| Apex | ⚠️ Le query SOQL/SOSL e le operazioni DML vengono eseguite in modalità di sistema predefinita senza controlli di accesso espliciti | | Piattaforma \| Apex | ⚠️ L’applicazione di CRUD e FLS è incoerente o mancante | | Piattaforma \| Apex | ⚠️ SOQL si basa su WITH SECURITY_ENFORCED, che è stato rimosso e ora causa un errore di compilazione (sostituire con WITH USER_MODE) | | Piattaforma \| Apex | ⚠️ Le parole chiave di condivisione vengono utilizzate in modo incoerente o non vengono utilizzate affatto | | Piattaforma \| Standard di progettazione | ⚠️ I casi d'uso per la concessione di autorizzazioni elevate non sono chiaramente documentati | ## Controllo dell'accesso basato sugli attributi (ABAC) e Data 360 **Schemi** | Dove cercare | Che bell'aspetto | | --- | --- | | Piattaforma \| Data 360 | ✅ RBAC (ruoli, profili, insiemi di autorizzazioni) controlla l'accesso alla piattaforma (chi può utilizzare Data 360), ABAC controlla l'accesso ai dati (quali dati visualizzano in base agli attributi) | | Piattaforma \| Data 360 | ✅ Gli agenti AI vengono eseguiti nel contesto dell'utente richiedente (per conto dell'utente), quindi le query generate dall'agente sono limitate dall'accesso dell'utente anziché essere eseguite con l'accesso a livello di sistema | | Piattaforma \| Documentazione | ✅ La tassonomia di classificazione dei dati è documentata con definizioni attributo, regole di applicazione e giustificazione aziendale | **Anti-schemi** | Dove cercare | Che brutto aspetto | | --- | --- | | Piattaforma \| Data 360 | ⚠️ L'accesso che deve seguire la classificazione dei dati viene forzato attraverso la gerarchia dei ruoli e la condivisione, che non può esprimerlo, invece di raggiungere il controllo dell'accesso basato sugli attributi | | Piattaforma \| Data 360 | ⚠️ Ignoramento FLS: gli utenti senza accesso a livello di campo recuperano i dati tramite API o query SOQL che non applicano l'FLS | | Piattaforma \| Data 360 | ⚠️ Gli agenti AI eseguono query sui dati senza eseguire query nel contesto dell'utente richiedente; le query generate dagli agenti ignorano i controlli di accesso a livello di oggetto, campo e record | | Piattaforma \| Data 360 | ⚠️ Il contesto di esecuzione dell'agente non include gli attributi utente per conto; gli agenti operano con accesso a livello di sistema | | Piattaforma \| Documentazione | ⚠️ La tassonomia di classificazione dei dati non è documentata; le definizioni degli attributi variano a seconda del team creando un'imposizione incoerente | ## Account con impatto critico **Schemi** | Dove cercare | Che bell'aspetto | | --- | --- | | Piattaforma \| Organizzazione | ✅ Gli account con impatto critico (amministratori di sistema, utenti integrazione, account di processi automatizzati) vengono identificati e tracciati nell'inventario degli asset | | Piattaforma \| Organizzazione | ✅ Gli account con impatto critico rappresentano target di alto valore a causa di privilegi elevati che forniscono un ampio accesso alla piattaforma | | Piattaforma \| Organizzazione | ✅ Le chiavi di protezione hardware o le app di autenticazione sono necessarie per la MFA (non gli SMS, che sono vulnerabili allo scambio delle SIM) | | Piattaforma \| Organizzazione | ✅ Gli intervalli IP di accesso sono limitati a posizioni amministrative note | | Piattaforma \| Organizzazione | ✅ Gli avvisi di accesso e le notifiche di modifica delle autorizzazioni sono abilitati | | Piattaforma \| Organizzazione | ✅ Le revisioni trimestrali dell'accesso sono condotte con attestazione documentata | | Piattaforma \| Organizzazione | ✅ Esistono procedure di break-glass per l'accesso di emergenza con controllo post-uso | | Integrazione \| Account di servizio | ✅ I flussi OAuth vengono utilizzati per l'integrazione e gli account di servizio (mai nome utente-password) | | Integrazione \| Account di servizio | ✅ Le restrizioni IP vengono applicate per gli utenti integrazione | | Integrazione \| Account di servizio | ✅ vengono implementate pianificazioni di rotazione delle credenziali (trimestrali o per policy) | | Integrazione \| Account di servizio | ✅ Gli schemi di utilizzo API anomali vengono monitorati tramite Monitoraggio evento | | Integrazione \| Account di servizio | ✅ Ogni integrazione ha un account di servizio dedicato con autorizzazioni minime richieste (non condiviso "utente integrazione" con ampio accesso) | | Integrazione \| Account di servizio | ✅ Gli account di servizio applicano rigorosamente i privilegi minimi poiché operano incustoditi | **Anti-schemi** | Dove cercare | Che brutto aspetto | | --- | --- | | Piattaforma \| Organizzazione | ⚠️ Gli account con impatto critico (amministratore, integrazione, automazione) non vengono identificati, tracciati o inventariati | | Piattaforma \| Organizzazione | ⚠️ Gli amministratori di sistema utilizzano la MFA basata su SMS anziché le chiavi di protezione hardware o le app di autenticazione | | Piattaforma \| Organizzazione | ⚠️ Gli account con impatto critico non hanno orari di accesso o restrizioni IP | | Piattaforma \| Organizzazione | ⚠️ Non vengono configurati avvisi per l'accesso o le modifiche delle autorizzazioni sugli account con privilegi | | Piattaforma \| Organizzazione | ⚠️ L'accesso agli account con impatto critico non viene mai rivisto o rivisto in modo irregolare (non trimestrale) | | Piattaforma \| Organizzazione | ⚠️ Non esistono procedure di break-glass per l'accesso di emergenza | | Integrazione \| Account di servizio | ⚠️ Un singolo account "Utente API" è condiviso tra più integrazioni con l'autorizzazione Modifica tutti i dati | | Integrazione \| Account di servizio | ⚠️ Gli account di servizio utilizzano l'autenticazione nome utente-password quando OAuth è disponibile | | Integrazione \| Account di servizio | ⚠️ Le credenziali account di servizio utilizzano password statiche invariate per anni (nessuna rotazione) | | Integrazione \| Account di servizio | ⚠️ Gli account di servizio hanno privilegi eccessivi oltre a quelli richiesti dall'integrazione | | Integrazione \| Account di servizio | ⚠️ Gli schemi di utilizzo API anomali per gli account di servizio non vengono monitorati | ## Gestione del ciclo di vita dell'identità **Schemi** | Dove cercare | Che bell'aspetto | | --- | --- | | Piattaforma \| Processo | ✅ Ciclo di vita dell'identità include: Provisioning (creazione con accesso di base), Rettifica dell'accesso (concessione/revoca al variare dei ruoli), Ricertificazione periodica (convalida trimestrale), Deprovisioning (revoca immediata) | | Piattaforma \| Organizzazione | ✅ SCIM (System for Cross-domain Identity Management) è implementato per il provisioning automatico dai provider di identità | | Piattaforma \| Processo | ✅ Il provisioning crea account con accesso di base corrispondente alla funzione lavorativa, attivata da eventi di sistema HR | | Piattaforma \| Processo | ✅ La rettifica dell'accesso concede autorizzazioni aggiuntive man mano che i ruoli si espandono e revoca le autorizzazioni quando i ruoli cambiano | | Piattaforma \| Processo | ✅ La ricertificazione periodica avviene ogni trimestre in cui i responsabili rivedono e convalidano l'accesso per i loro team | | Piattaforma \| Processo | ✅ Il provisioning revoca immediatamente l'accesso quando l'impiego termina o il ruolo non richiede più Salesforce | | Piattaforma \| Organizzazione | ✅ Il rilevamento automatico identifica gli utenti che non hanno eseguito l'accesso entro 90 giorni e attiva i flussi di lavoro di revisione dell'accesso | | Piattaforma \| Organizzazione | ✅ Il provisioning just in time (JIT) crea automaticamente gli utenti da SSO quando appropriato | **Anti-schemi** | Dove cercare | Che brutto aspetto | | --- | --- | | Piattaforma \| Organizzazione | ⚠️ Il provisioning SCIM non viene implementato nonostante l'integrazione con il provider di identità | | Piattaforma \| Processo | ⚠️ I nuovi utenti vengono creati manualmente senza procedure di orientamento standard | | Piattaforma \| Processo | ⚠️ L'accesso iniziale degli utenti è incoerente o basato sulla copia di utenti esistenti | | Piattaforma \| Processo | ⚠️ Le modifiche di accesso per le modifiche o i trasferimenti di ruolo sono ritardate o incomplete | | Piattaforma \| Processo | ⚠️ L'offboarding è ritardato; gli ex dipendenti mantengono l'accesso dopo la cessazione (non la disattivazione nella stessa giornata) | | Piattaforma \| Organizzazione | ⚠️ Non esiste automazione per il provisioning utente (solo creazione manuale dell'utente) | | Piattaforma \| Processo | ⚠️ Non esistono campagne di ricertificazione dell'accesso (nessuna revisione trimestrale o annuale) | | Piattaforma \| Processo | ⚠️ L'accesso non necessario identificato durante la ricertificazione non viene rimosso | | Piattaforma \| Processo | ⚠️ La ricertificazione dell'accesso non è rigorosa per gli account con privilegi, l'accesso tra organizzazioni e gli utenti esterni | | Piattaforma \| Organizzazione | ⚠️ Gli account dormienti (nessun accesso in 90+ giorni) si accumulano senza revisione o disattivazione |