Salta ai contenuti

PAM

Il modulo PAM — Privileged Access Management — governa gli account con privilegi elevati: chi può usarli, quando, con quale approvazione, e che cosa ne è stato fatto.

È in Operatività → PAM e richiede il permesso menu.pam.

Un utente non riceve mai la password di un account privilegiato. Chiede un accesso, che viene valutato secondo le policy, eventualmente approvato, concesso per un tempo limitato, registrato e chiuso. Le credenziali restano in Arcanum e vengono usate dalla piattaforma per conto dell’utente.

Il risultato è che una credenziale privilegiata non circola, non finisce in un gestore di password personale e non resta valida dopo che la persona ha cambiato ruolo.

PaginaContenuto
DashboardAccessi in corso, richieste in attesa, scadenze imminenti, anomalie
ApprovazioniLe richieste da valutare, con contesto e motivazione
EmergenzaLa procedura di accesso di emergenza

Esiste, perché un sistema che non prevede l’emergenza viene aggirato la prima volta che serve — e l’aggiramento non lascia traccia.

L’accesso di emergenza concede privilegi immediatamente, senza attendere l’approvazione. In cambio: notifica immediata agli approvatori, durata ridotta, registrazione obbligatoria e revisione a posteriori. È una scorciatoia controllata, non una porta di servizio.

PaginaContenuto
Sistemi di destinazioneI sistemi su cui esistono gli account gestiti
Account gestitiGli account privilegiati sotto controllo
Policy di rotazioneQuando e come cambiare le credenziali
Policy di accessoChi può chiedere che cosa, con quale approvazione
Livelli di privilegioLa scala dei privilegi e le regole per ciascuno
Utenti AD dinamiciAccount creati al momento e rimossi alla scadenza
Pool utentiGli insiemi di utenti che possono richiedere accesso

Per alcuni scenari, invece di condividere un account esistente, la piattaforma crea un account in Active Directory al momento della concessione e lo rimuove alla scadenza.

È la forma più pulita di accesso privilegiato: l’account esiste solo per la durata dell’intervento, è nominale, e ciò che ha fatto è attribuibile a una persona senza ambiguità.

Le policy di rotazione definiscono ogni quanto cambiare le password degli account gestiti, e la rotazione avviene automaticamente: la piattaforma cambia la password sul sistema di destinazione e ne deposita il nuovo valore cifrato.

La rotazione avviene anche dopo ogni uso, se la policy lo prevede: una credenziale usata una volta non è più valida per l’accesso successivo.

Gli esiti sono in Log di rotazione. Una rotazione fallita è una condizione da trattare: significa che l’account gestito non è più sotto controllo.

PaginaContenuto
SessioniTutte le sessioni privilegiate, con la registrazione
Log di rotazioneEsiti delle rotazioni
ConformitàScostamenti rispetto alle policy configurate

La registrazione delle sessioni PAM non è disattivabile. Un accesso privilegiato senza traccia non è un accesso privilegiato governato, ed è esattamente ciò che il modulo esiste per evitare.

Il PAM ha un insieme di permessi propri, e la separazione fra chi chiede, chi approva e chi configura è il punto:

PermessoConsente
pam.viewVedere la dashboard e lo stato
pam.approveApprovare le richieste
pam.emergencyUsare l’accesso di emergenza
pam.systems.manageGestire i sistemi di destinazione
pam.accounts.manageGestire gli account
pam.policies.manageGestire le policy
pam.sessions.viewConsultare le sessioni e le registrazioni
pam.rotation_logs.viewConsultare i log di rotazione
pam.enforcement.viewConsultare gli scostamenti di conformità

Un utente che può approvare le proprie richieste rende l’approvazione un passaggio burocratico senza contenuto: la separazione dei ruoli va progettata prima di attivare il modulo, non dopo.

Le credenziali sono cifrate dal motore transit di Arcanum. La chiave non lascia mai Arcanum, e cifratura e decifratura avvengono al suo interno.

Una copia del database, per chi riuscisse a ottenerla, non contiene credenziali utilizzabili. Vedi Arcanum.