Accesso root ai server per un nuovo dipendente IT: l'indagine di sicurezza è obbligatoria?

Ai sensi della legge federale tedesca sulla protezione dei dati, il trattamento dei dati dei dipendenti deve rispettare i principi di necessità e proporzionalità. La richiesta del certificato penale è legittima solo se strettamente legata alle mansioni previste; precedenti violazioni prive di attinenza non possono giustificare un mancato inserimento. Formalizzare l'intera procedura con il supporto di un giuslavorista mette al riparo da eventuali contenziosi legali.

Non create accessi root nominali e incontrollati. L'autenticazione a due fattori con token hardware deve essere obbligatoria e tutti i comandi 'sudo' devono essere inviati in tempo reale a un server di log centralizzato e non modificabile. Il dipendente deve sapere che ogni singola azione lascia una traccia di audit indipendente. Questa trasparenza è molto più deterrente di qualsiasi indagine.

Non date subito il pieno accesso al candidato domani stesso. In Germania, il periodo di prova legale (Probezeit) è lo strumento migliore per questo tipo di verifiche di affidabilità. Nei primi sei mesi aprite i permessi di accesso gradualmente; prima date gli ambienti di test e sviluppo e subordinate l'accesso ai sistemi di produzione al lavoro in coppia con il team leader.

Negli accordi sul livello di servizio (SLA) o nei contratti di elaborazione dati (AVV) firmati con i vostri clienti avete un impegno specifico sul controllo del personale? A volte i clienti enterprise possono richiedere che i dipendenti abbiano determinate certificazioni di sicurezza o che seguano corsi annuali di formazione sulla sicurezza.

Dieci anni fa, con un timore simile, imponemmo restrizioni così rigide a un sistemista appena assunto che al secondo mese diede le dimissioni; ci disse: "se non vi fidate di me, perché mi avete preso?". E aveva pure ragione. Invece di cercare indagini di sicurezza, ora facciamo colloqui di controllo referenze davvero approfonditi prima dell'assunzione. Parlare direttamente con i suoi precedenti responsabili e sondare la sua integrità nei momenti di crisi ci dice molto di più dei controlli sulla carta.

l'indagine ufficiale è roba statale cmq non la fanno fare a noi. noi chiediamo il casellario giudiziale e poi sui server abbiamo disattivato del tutto il login root ognuno entra col suo account e fa sudo i log vanno dritti sul cloud esterno.

PS: è stato chiesto qui sotto, ho scritto la risposta nel secondo messaggio.

Per mettere in sicurezza l'infrastruttura seguite questi tre passaggi: 1) Limitate l'accesso diretto ai database di produzione tramite VPN e restrizione IP. 2) Rendete obbligatorio il principio dei quattro occhi per le modifiche critiche di configurazione. 3) Configurate un identity provider centralizzato con cui revocare tutti i permessi con un solo clic in caso di uscita del dipendente.

Hai fatto bene ad aprire questo thread.

Racconto cosa mi è successo, magari vi è utile. La sicurezza non è assoluta; significa rendere l'attacco non conveniente.

Se avete domande, scrivete, rispondo per quanto possibile.

Grazie per averlo scritto, è proprio così. Il vero problema non è il numero, ma su cosa si basa quel numero.

Il vero problema non è il numero, ma su cosa si basa quel numero. Se scrivete qui il risultato, sarà utile anche ad altri.

Parlo dal lato opposto io sono dalla parte dei fornitori. Da noi la cosa che faceva perdere più tempo era non sapere chi decidesse.

È tutto scusate se mi sono dilungato.

Grazie per averlo scritto, è proprio così. Un backup non testato non è un backup.

Io seguirei questa strada.

Esatto, e non è nemmeno così noto. La sicurezza non è assoluta; significa rendere l'attacco non conveniente.

nel nostro caso è andata così. quando prendete una decisione, scrivete anche lo scenario peggiore, non solo quello migliore.

se ricevete tre rissposte diverse su un argomento la domanda è posta male e boh correggetemi se sbaglio.

Mi farebbe piacere se scrivesse il risultato.

Lo sentiamo dire da tempo, ma da noi non è mai andata così. Se è la prima volta, inizia in piccolo, il ridimensionamento viene dopo.

Se avete domande, scrivete, rispondo per quanto possibile.

Riassumo l'argomento, perché sono state date diverse risposte. La maggior parte degli incidenti non inizia da una vulnerabilità, ma da una password trapelata.

Se è la prima volta, inizia in piccolo, il ridimensionamento viene dopo. Naturalmente cambia se la vostra situazione è diversa.

Concordo pienamente. La risposta varia molto in base al settore, non esiste una regola generale.