PR16.1 - Gestione degli Accessi
Procedura di Gestione degli Accessi
Revisioni
| Rev. | Data | Descrizione | Redatto | Approvato |
|---|---|---|---|---|
| 0.1 | 16/07/2026 | Prima bozza — documento mancante generato per colmare una lacuna rilevata nella SOA | IA | Da approvare |
1 Introduzione
La presente procedura descrive le modalità operative con cui VECTORLAB attua i principi definiti in "PO16 - Gestione degli Accessi", disciplinando in modo pratico le attività di:
1) > richiesta, approvazione e provisioning di una nuova utenza
2) > gestione dell'autenticazione e dei fattori di autenticazione
3) > modifica dei privilegi a seguito di cambio ruolo
4) > revoca degli accessi
5) > riesame periodico delle utenze attive
6) > gestione delle credenziali e dei segreti applicativi
7) > gestione degli accessi di terze parti e ospiti.
1.1 Riferimenti e Allegati
ALPO31.A - Lettera incarico AdS
ALPR16.1.A - Lista utenze
MDPR05.1.A - Checklist Documenti per Inserimento Personale
MDPR05.1.L - Checklist documenti per uscita personale
MDPR05.1.V - Modulo_consegna_riconsegna_HW_utenze
PO16 - Gestione degli Accessi
PO17 - Crittografia
PR14.1 - Gestione Asset
PR18.1 - Gestione sicurezza fisica e ambientale
PR27.1 - Gestione degli incidenti e dei data breach
REG01 - Regolamento sull'utilizzo degli strumenti aziendali.
1.2 Definizioni, Acronimi, Abbreviazioni
AdS - Amministratore di Sistema
IAM - Identity and Access Management
MFA - Multi-Factor Authentication
RSGI - Responsabile del Sistema di Gestione Integrato
SGI - Sistema di Gestione Integrato.
2 Procedura di Gestione degli Accessi
2.1 Richiesta e provisioning di una nuova utenza
All'inserimento di una nuova risorsa (dipendente o collaboratore), la richiesta di attivazione delle utenze necessarie viene formalizzata nell'ambito della checklist di onboarding "MDPR05.1.A - Checklist Documenti per Inserimento Personale". La richiesta indica, per ciascun sistema, il livello di accesso necessario in base al ruolo della risorsa (es. sviluppatore, System Administrator, Amministrazione).
Il flusso operativo è il seguente:
-
il responsabile della funzione richiedente (o l'Amministrazione, nell'ambito del processo di inserimento del personale) individua i sistemi e i livelli di accesso necessari alla nuova risorsa;
-
[DA CONFERMARE: la richiesta viene aperta come ticket sul sistema di ticketing aziendale (ClickUp/Jira), secondo lo stesso canale utilizzato per le richieste IT descritte in REG01];
-
il System Administrator, in qualità di Amministratore di Sistema designato (cfr. "ALPO31.A - Lettera incarico AdS"), crea le utenze nominali necessarie sui sistemi individuati (es. Google Workspace, AWS, GitHub, ClickUp/Jira, Postman, MongoDB, N8N, Discord, Bitwarden), assegnando i privilegi minimi necessari allo svolgimento delle mansioni previste;
-
le credenziali iniziali vengono comunicate alla risorsa tramite canale riservato e devono essere modificate al primo accesso, secondo quanto previsto da "REG01 - Regolamento sull'utilizzo degli strumenti aziendali";
-
l'attivazione di ciascuna utenza viene registrata in "ALPR16.1.A - Lista utenze", con indicazione di sistema, ruolo/profilo assegnato e data di creazione;
-
la consegna di eventuali strumenti/dispositivi aziendali collegati (es. PC, cellulare) è tracciata separatamente tramite "MDPR05.1.V - Modulo_consegna_riconsegna_HW_utenze", secondo quanto descritto in "PR14.1 - Gestione Asset".
2.2 Autenticazione e MFA
Per ciascuna utenza attivata, ove il servizio lo consenta, viene abilitata l'autenticazione a più fattori (MFA), in particolare per i servizi cloud principali (Google Workspace, AWS, GitHub). Il System Administrator verifica, in fase di provisioning e nel corso dei riesami periodici, che la MFA risulti attiva per gli account con privilegi amministrativi e per quelli con accesso a informazioni classificate come "Confidenziale".
2.3 Gestione dei privilegi e principio del minimo privilegio
I privilegi assegnati a ciascuna utenza sono limitati a quanto strettamente necessario per lo svolgimento delle mansioni della risorsa. I privilegi amministrativi (es. accesso root/amministratore alla console AWS, ruoli di owner sui repository e sull'organizzazione GitHub, ruoli di amministratore su Google Workspace) sono riservati al System Administrator e, per specifiche esigenze, al CTO/Amministratore Unico.
Eventuali richieste di privilegi aggiuntivi rispetto a quelli inizialmente assegnati devono essere motivate e approvate dal responsabile della funzione richiedente o dal RSGI, prima di essere eseguite dal System Administrator.
2.4 Modifica degli accessi (cambio ruolo/mansione)
In caso di cambio di ruolo, mansione o progetto, il responsabile della funzione di destinazione richiede l'adeguamento dei privilegi di accesso della risorsa. Il System Administrator:
-
rimuove gli accessi non più coerenti con il nuovo ruolo;
-
attiva i nuovi accessi necessari, secondo il principio del minimo privilegio;
-
aggiorna di conseguenza "ALPR16.1.A - Lista utenze".
2.5 Revoca degli accessi (cessazione del rapporto)
Alla cessazione del rapporto di lavoro o di collaborazione, a fronte della checklist di uscita "MDPR05.1.L - Checklist documenti per uscita personale", il System Administrator disattiva tutte le utenze assegnate alla risorsa uscente, con le seguenti modalità:
-
per l'account di posta elettronica/Google Workspace si applica la procedura descritta in "REG01 - Regolamento sull'utilizzo degli strumenti aziendali" (disattivazione delle credenziali, risponditore automatico per il periodo previsto, rimozione definitiva dell'account al termine del periodo);
-
per gli altri sistemi (AWS, GitHub, ClickUp/Jira, Postman, MongoDB, N8N, Discord, Bitwarden) le utenze vengono disattivate o rimosse contestualmente all'ultimo giorno lavorativo;
-
la restituzione di eventuali strumenti/dispositivi aziendali è tracciata tramite "MDPR05.1.V - Modulo_consegna_riconsegna_HW_utenze";
-
la disattivazione viene registrata in "ALPR16.1.A - Lista utenze", con indicazione della data di revoca.
Coerentemente con quanto previsto per gli Amministratori di Sistema (cfr. "ALPO31.A - Lettera incarico AdS"), il System Administrator disattiva inoltre le credenziali di autenticazione non utilizzate da oltre sei mesi, anche in assenza di una cessazione formale del rapporto.
In caso di smarrimento, furto o sospetta compromissione delle credenziali, la persona autorizzata segnala l'accaduto secondo quanto previsto da "PR27.1 - Gestione degli incidenti e dei data breach" e il System Administrator procede alla revoca/reset immediato delle credenziali interessate.
2.6 Riesame periodico delle utenze e dei privilegi
[DA CONFERMARE: con cadenza almeno annuale, il RSGI e il System Administrator effettuano un riesame formale del contenuto di "ALPR16.1.A - Lista utenze", verificando la coerenza tra utenze attive, ruoli assegnati e privilegi concessi, ed eventuale presenza di utenze orfane (prive di un titolare identificabile) o inattive]. Le eventuali azioni correttive (revoca di utenze non più necessarie, riduzione di privilegi non coerenti con il ruolo) vengono tracciate ed eseguite dal System Administrator.
2.7 Accesso Wi-Fi ospiti
Per i visitatori che necessitano di accesso a Internet durante la permanenza in sede, è disponibile una rete Wi-Fi dedicata (VLAN Guest), segregata dalla rete interna aziendale, come descritto in "REG01 - Regolamento sull'utilizzo degli strumenti aziendali". L'accesso avviene tramite voucher temporaneo richiesto all'IT (System Administrator), che ne traccia il rilascio. La gestione degli accessi fisici dei visitatori alla sede è disciplinata da "PR18.1 - Gestione sicurezza fisica e ambientale" (Registro dei Visitatori).
2.8 Gestione delle credenziali e dei segreti
Le password personali seguono i requisiti di complessità, storicità e durata definiti in "REG01 - Regolamento sull'utilizzo degli strumenti aziendali". Le credenziali e i segreti condivisi tra più persone (es. accessi a servizi di team, chiavi API) sono gestiti tramite Bitwarden, evitandone la conservazione in chiaro in altri strumenti (chat, ticket, repository di codice). I parametri e i segreti applicativi utilizzati dai sistemi in produzione sono gestiti tramite AWS Parameter Store, con accesso limitato al personale e ai processi automatizzati (es. pipeline GitHub Actions) effettivamente autorizzati.
2.9 Ruolo dell'Amministratore di Sistema e log di accesso
Il System Administrator opera come Amministratore di Sistema formalmente designato (cfr. "ALPO31.A - Lettera incarico AdS") e, in tale veste:
-
assegna, modifica e disattiva le credenziali di autenticazione agli incaricati del trattamento, su indicazione del Titolare o dei responsabili di funzione;
-
effettua attività di monitoraggio dei log di sistema, di rete e di backup, nei limiti e con le finalità previste dalla designazione;
-
garantisce che le registrazioni degli accessi logici (access log) siano conservate per almeno sei mesi e non siano in alcun modo alterabili;
-
è soggetto a verifica periodica, con cadenza almeno annuale, da parte del Titolare (Amministratore Unico), anche tramite controllo dei log di accesso, disconnessione ed errore di autenticazione.
2.10 Accesso di terze parti e collaboratori esterni
L'accesso di fornitori, consulenti e sviluppatori esterni (anche in P.IVA) ai sistemi e ai repository di codice di VECTORLAB è subordinato alla sottoscrizione di un accordo di riservatezza (NDA) e viene concesso limitatamente alla durata dell'incarico e al perimetro strettamente necessario (es. singolo repository, singolo ambiente), secondo quanto già previsto in "PR14.1 - Gestione Asset". Al termine della collaborazione, gli accessi vengono revocati con le stesse modalità previste al paragrafo 2.5.