CapordiaNominare i responsabili prima di distribuire gli accessi
Distingui il responsabile del fascicolo di noleggio, la persona che autorizza l'accesso al progetto e quella che può applicare le modifiche tecniche sulla destinazione. Il responsabile dei risultati non ha necessariamente bisogno di avviare processi o di amministrare la macchina. Scrivi le operazioni richieste prima di scegliere i diritti: leggere un export, depositare input, eseguire un'attività o modificare un ambiente.
Verifica poi il perimetro degli accessi effettivamente assegnati. Se non disponi del diritto di creare identità o di impostare i permessi, fai confermare la procedura possibile prima di invitare altri collaboratori. Non aggirare questo limite distribuendo la password dell'account Capordia. La condivisione del lavoro e la gestione del fascicolo commerciale sono due questioni diverse.
Usare un'identità individuale e conoscerne la portata
Un'identità individuale permette di revocare l'accesso di una persona senza sostituire quello di tutta la squadra. In un'organizzazione SSH basata su chiavi, OpenSSH distingue la chiave pubblica nota al server e la chiave privata detenuta dall'utente. Il documento di coordinamento può contenere un riferimento o un'impronta di chiave pubblica; non deve mai contenere la chiave privata o la sua passphrase.
Due chiavi diverse che danno accesso allo stesso account di sistema non creano automaticamente due perimetri di file diversi. I permessi dipendono dall'account e dai meccanismi configurati sulla macchina. Decidi quindi se il requisito riguarda solo l'autenticazione individuale o anche la separazione delle azioni. Per le automazioni, prevedi un'identità e un proprietario espliciti, senza riutilizzare di nascosto l'identità personale di un collega.
Verificare la destinazione prima di presentarle un'identità
Al primo accesso, controlla il nome della macchina, l'account previsto e l'impronta della sua chiave di host a partire da un riferimento attendibile ottenuto nel processo di consegna degli accessi. Questa chiave di host identifica il server; è distinta dalla tua chiave utente. Un messaggio inatteso di cambiamento dell'identità del server merita un esame, non la cancellazione automatica del riferimento noto.
OpenSSH conserva le chiavi di host e segnala i loro cambiamenti. Usa questa informazione insieme al contesto: ricostruzione annunciata della macchina, indirizzo modificato o evento non spiegato. Fai confermare il cambiamento prima di procedere se non è previsto. Lo scopo non è aggiungere un rituale a ogni connessione, ma evitare di trattare un avviso di identità come un semplice fastidio di visualizzazione.
Esempio fittizio: tre collaboratori, tre esigenze
La squadra fittizia «Dossier delle opere» prepara una settimana di lavoro. Idriss esegue le elaborazioni del progetto A, Noémie rilegge gli export e Sacha interviene temporaneamente per configurare l'ambiente. La squadra desidera i diritti della tabella, ma deve verificare che siano applicabili con il sistema effettivamente consegnato. Non si tratta né di account clienti esistenti né di funzioni di gestione del team annunciate da Capordia.
Il principio decisivo è che Noémie non ottenga un accesso di amministrazione per aprire un risultato e che l'intervento di Sacha abbia una fine. Una sola approvazione umana non configura alcun diritto: il responsabile tecnico applica i meccanismi disponibili, poi ciascuno esegue i controlli previsti. Se la separazione desiderata non è realizzabile, il progetto deve adattare la propria organizzazione prima di introdurre dati che richiedono tale separazione.
| Collaboratore | Esigenza | Perimetro desiderato | Riesame |
|---|---|---|---|
| Idriss, esercizio | Depositare input e avviare il progetto A | Spazio di lavoro A, senza amministrazione generale | Fine campagna o cambio di ruolo |
| Noémie, validazione | Leggere gli export consegnati | Risultati selezionati, senza modifica degli input | Fine validazione |
| Sacha, intervento | Preparare l'ambiente autorizzato | Modifica definita e approvata | Al ricevimento dell'intervento |
Preparare una scheda di accesso e testare i limiti
La scheda collega una persona o un'automazione, un'identità tecnica, un approvatore, un perimetro, una giustificazione e una scadenza. Conserva il riferimento della chiave pubblica e la procedura di revoca senza memorizzare i segreti. OpenSSH ssh-keygen permette di visualizzare l'impronta di una chiave pubblica: questo riferimento aiuta a designare la chiave giusta durante un'aggiunta o una rimozione, senza copiarne la parte privata.
Testa un'azione autorizzata su un file sintetico e poi un'azione volutamente fuori perimetro, prevista come rifiutata. Per un ruolo di lettura, l'apertura deve funzionare e un tentativo di modifica controllato deve essere rifiutato. Non usare dati reali per testare un divieto di cancellazione. Verifica anche i percorsi comuni e la destinazione degli output, perché un diritto corretto su una cartella non garantisce tutti i percorsi del programma.
Pianificare la revoca e verificare una nuova connessione
Attiva la revoca alla fine dell'intervento, all'uscita di una persona o dopo un sospetto di compromissione. Il responsabile individua tutte le autorizzazioni interessate, compresi gli altri percorsi di accesso consentiti per la stessa identità. Applica la revoca in base alla configurazione reale. La direttiva RevokedKeys di OpenSSH è un meccanismo possibile tra quelli documentati; non va dato per attivo su una macchina senza verifica.
Verifica poi che una nuova autenticazione con l'identità revocata venga rifiutata, senza eliminare l'accesso di recupero del responsabile. Esamina separatamente le sessioni già aperte, le attività in corso e le identità di automazione: revocare un'autorizzazione e fermare un'attività sono decisioni diverse. Se un lavoro deve proseguire, trasferisci la sua responsabilità secondo una procedura concordata invece di lasciare un'identità orfana.
Evitare scorciatoie che impediscono il controllo
Una chiave privata condivisa impedisce di sapere chi deve sostituirla e spesso impone una rotazione collettiva. Un accesso ampio "in attesa" tende a durare se nessuno ha fissato la sua data di revisione. Un account di validazione usato anche per amministrare la macchina rende difficili da interpretare i controlli di separazione. Correggi questi problemi nella scheda di accesso prima che diventino una dipendenza dell'operatività.
Evita anche di aggiungere inoltri dell'agente, tunnel o eccezioni di accesso solo per aggirare una difficoltà non diagnosticata. Fai descrivere l'esigenza di connessione e i suoi vincoli al responsabile autorizzato. Questa guida non propone una configurazione server universale: i meccanismi dipendono dai diritti concessi, dall'ambiente e dai requisiti del progetto. Una documentazione generale non equivale alla validazione della destinazione.
Consegnare un'organizzazione degli accessi che resti verificabile
Al ricevimento, raccogli la matrice approvata, le identità attive, i test consentiti e rifiutati, le scadenze e la persona in grado di revocare un accesso. Verifica che una persona assente possa essere sostituita senza diffondere il suo segreto. La continuità si basa su una procedura e su un responsabile di riserva autorizzato, non su una password condivisa nella cartella del progetto.
Durante il passaggio di consegne, rivedi gli accessi diventati inutili e le automazioni che dipendono da un'identità personale. Se un rifiuto inatteso blocca il lavoro, costituisci un dossier di incidente mirato con identità tecnica, percorso interessato ed errore epurato. Non aggiungere diritti generali solo per far sparire il sintomo. La chiusura corretta è un accesso necessario, testato e con una fine nota.
Domande per decidere
Bisogna condividere l'account Capordia con tutti gli operatori?
No. Il monitoraggio del noleggio e gli accessi tecnici al lavoro devono essere organizzati separatamente. Definisci le identità di macchina possibili con i diritti realmente concessi. Questo metodo non presuppone alcun sistema di inviti o ruoli di team nello spazio Capordia.
Una chiave pubblica concede automaticamente i diritti corretti?
No. Serve per l'autenticazione quando è autorizzata; le azioni accessibili dipendono poi dall'account e dai permessi del sistema. Verifica un'azione consentita e un'azione che deve essere rifiutata su file sintetici.
Cosa verificare dopo l'uscita di un operatore?
Revoca le sue autorizzazioni, controlla il rifiuto di una nuova autenticazione ed esamina le sessioni, i lavori e gli automatismi ancora legati alla sua identità. Mantieni un responsabile autorizzato per il recupero e il monitoraggio. Non concludere che la revoca sia avvenuta in base a una semplice casella spuntata.