Come superare SOC 2 CC6 Privileged Access Controls — Una Guida Pratica

La preparazione a SOC 2 Type II è una maratona. La maggior parte delle organizzazioni supera la documentazione delle policy, i questionari di valutazione dei vendor e i diagrammi di segmentazione della rete senza troppi problemi. Poi affrontano CC6 — Controlli di Accesso Logico e Fisico — e l'audit diventa difficile.

CC6 è dove gli auditor spendono la maggior parte del tempo ed è dove le aziende ricevono più frequentemente eccezioni. Copre chi ha accesso ai vostri sistemi, come quell'accesso è controllato, come viene monitorato e come viene sottoposto a revisione. Se la vostra risposta riguardante il privileged access management è "usiamo VPN più RDP con credenziali admin condivise", non supererete l'audit.

Ecco esattamente cosa richiede CC6, cosa chiedono gli auditor e come produrre l'evidenza.

CC6.1, CC6.2, CC6.3, CC6.6 — Cosa richiede ogni controllo in linguaggio semplice

CC6.1 — Sicurezza dell'Accesso Logico

Il requisito: l'accesso logico ai vostri sistemi, infrastruttura e dati è limitato agli utenti autorizzati.

In pratica, questo significa:

• Ogni utente che accede a un sistema di produzione ha una ragione documentata per quell'accesso
• L'accesso viene fornito attraverso un processo definito (non ad hoc)
• L'accesso viene rimosso tempestivamente quando un utente se ne va o cambia ruolo
• L'accesso privilegiato (admin, root, DBA) viene tracciato separatamente e tenuto a uno standard superiore

L'evidenza che gli auditor vogliono: un inventario completo di chi ha accesso privilegiato a cosa, come è stato fornito e quando è stato sottoposto a revisione l'ultima volta.

CC6.2 — Identificazione e Autenticazione

Il requisito: gli utenti sono autenticati prima di accedere ai sistemi, e l'autenticazione è sufficientemente forte per la sensibilità della risorsa.

In pratica, questo significa:

• MFA è richiesto su tutti gli account con accesso privilegiato
• Le password soddisfano i requisiti di complessità e rotazione
• Gli account condivisi (Administrator condiviso, root condiviso) vengono eliminati o strettamente controllati
• Gli account di servizio sono inventariati e l'accesso viene sottoposto a revisione

L'evidenza che gli auditor vogliono: screenshot dell'iscrizione MFA, esportazioni dell'inventario degli account, evidenza che gli account admin condivisi sono stati eliminati o dispongono di controlli compensativi.

CC6.3 — Rimozione dell'Accesso

Il requisito: l'accesso viene rimosso quando non è più necessario (cessazione, cambio di ruolo, fine del progetto).

In pratica, questo significa:

• Avete un processo di offboarding documentato che include la revoca dell'accesso privilegiato
• La revoca dell'accesso avviene entro un periodo di tempo definito (24-48 ore per l'accesso di produzione)
• Potete dimostrare che gli utenti terminati non hanno più sessioni attive o credenziali

L'evidenza che gli auditor vogliono: ticket di offboarding che mostrano i passaggi di revoca dell'accesso, screenshot prima/dopo dei diritti di accesso.

CC6.6 — Restrizioni di Accesso Logico

Il requisito: la trasmissione dei dati è crittografata e le restrizioni di accesso logico sono in atto per prevenire l'accesso non autorizzato.

In pratica, questo significa:

• Tutte le connessioni amministrative sono crittografate in transito
• L'accesso a sistemi sensibili è limitato a endpoint o reti autorizzati
• L'attività della sessione è monitorata e registrata

L'evidenza che gli auditor vogliono: diagrammi di rete che mostrano canali crittografati, log di sessione che mostrano attività amministrativa.

Cosa gli Auditor effettivamente chiedono

Quando un auditor SOC 2 esamina CC6, in genere richiede le seguenti evidenze:

Per CC6.1 (inventario degli accessi):

• Foglio di calcolo o esportazione di sistema che mostra tutti gli utenti con accesso privilegiato, i sistemi a cui possono accedere e la giustificazione commerciale
• Evidenza che l'accesso è stato approvato (email, ticket, screenshot del flusso di approvazione)
• Record di revisione dell'accesso che mostrano ricertificazione trimestrale o annuale

Per CC6.2 (autenticazione):

• Screenshot dell'iscrizione MFA per gli account amministrativi
• Documentazione della policy delle password ed evidenza che viene applicata
• Elenco degli account di servizio ed evidenza dell'inventario

Per CC6.3 (rimozione dell'accesso):

• Ticket di offboarding campione (tipicamente 3-5 esempi dal periodo di audit)
• Evidenza che l'accesso privilegiato è stato revocato entro SLA
• Record di integrazione del sistema HR o verifica manuale

Per CC6.6 (monitoraggio della sessione):

• Log di sessione che mostrano attività amministrativa (chi ha effettuato l'accesso, quando, a quale sistema, cosa ha fatto)
• Evidenza che le sessioni sono registrate
• Diagramma di rete che mostra la crittografia in transito

L'evidenza deve coprire l'intero periodo di audit (tipicamente 12 mesi per un audit Type II). Gli auditor campionaranno eventi durante quel periodo — non potete fare affidamento su evidenza dalle ultime due settimane prima del lavoro sul campo dell'audit.

Errori comuni in CC6 e come evitarli

Credenziali admin condivise Il finding più comune in CC6. "Usiamo l'account Administrator condiviso perché alcuni sistemi non supportano account individuali" non è un controllo accettabile. VaultPAM risolve questo: gli utenti si connettono attraverso sessioni mediate senza ricevere la credenziale. Il vault contiene la password; i log di audit mostrano esattamente quale utente ha avviato ogni sessione.

MFA non applicato su tutti gli account privilegiati Le organizzazioni spesso hanno MFA sulla loro posta elettronica aziendale ma non sull'accesso diretto al server (RDP, SSH). Gli auditor lo controllano specificamente. Ogni sessione privilegiata deve richiedere MFA.

Nessuna evidenza di revisione dell'accesso Molte organizzazioni conducono revisioni dell'accesso informalmente. Gli auditor vogliono evidenza documentata: chi ha revisionato, cosa è stato revisionato, quando e quali azioni sono state intraprese. "Abbiamo condotto una revisione nel Q3" senza ticket, foglio di calcolo o report non è evidenza.

Accesso non revocato tempestivamente Il divario tra quando un dipendente se ne va e quando il suo accesso viene revocato è un finding ricorrente. Se il vostro processo di offboarding richiede una settimana e l'accesso privilegiato è incluso nella stessa coda, avete un problema CC6.3.

Log di sessione incompleti o inaccessibili Mantenere i log di sessione è solo metà della risposta. Gli auditor vogliono vedere che potete recuperare eventi specifici e che i log sono completi e a prova di manomissione. I log in silos disparati (Windows Event Log su ogni server, log di auth SSH su ogni box Linux) senza aggregazione centrale sono difficili da presentare come evidenza.

Come VaultPAM produce automaticamente evidenza pronta per l'audit per CC6

VaultPAM è progettato intorno al presupposto che il vostro auditor stia leggendo da dietro le vostre spalle. L'evidenza che produce è mappata direttamente a ciò che CC6 richiede:

Controllo CC6	Cosa produce VaultPAM
CC6.1 — inventario degli accessi	Report completo di tutti gli utenti, sistemi target, policy di accesso e approvazioni — esportabile come CSV o accessibile via API
CC6.2 — applicazione MFA	TOTP e WebAuthn applicati a livello di sessione — ogni sessione privilegiata richiede autenticazione; lo stato di iscrizione MFA è visibile nel dashboard di amministrazione
CC6.2 — nessuna credenziale condivisa	Brokering della sessione — gli utenti accedono ai target senza ricevere password; il vault contiene la credenziale, non l'utente
CC6.3 — rimozione dell'accesso	Revocare un utente in VaultPAM termina immediatamente la loro capacità di avviare nuove sessioni; le sessioni attive possono essere terminate forzatamente
CC6.6 — monitoraggio della sessione	Registrazione completa della sessione (video + log di attività) per ogni sessione RDP, SSH, VNC e HTTP; a prova di manomissione tramite catena hash BLAKE3; ricercabile per utente, target e intervallo di tempo
CC6.6 — crittografia in transito	Tutte le sessioni mediate su mTLS; nessuna porta inbound diretta nei sistemi target

Il processo di revisione dell'accesso è supportato dalle esportazioni del log di audit di VaultPAM: potete produrre un report completo di ogni sessione privilegiata negli ultimi tre mesi, ordinato per utente e target, in pochi minuti. Presentate quello al vostro auditor insieme alla configurazione della policy di accesso e allo screenshot dell'iscrizione MFA — quello è il vostro pacchetto di evidenza per CC6.

---

Lavorate verso la preparazione a SOC 2 Type II? VaultPAM produce automaticamente evidenza pronta per l'audit per i controlli CC6 — registrazioni di sessioni, log di accesso, applicazione MFA e configurazione della policy sono tutti reportabili da un'unica dashboard.

Scaricate il nostro riepilogo sulla conformità SOC 2 per una mappatura completa dei controlli di VaultPAM ai Criteri dei Servizi Fiduciari SOC 2.