In generale

Non c'è davvero una risposta a questa domanda e non considererei necessariamente le "grandi aziende" come una cosa distinta con approcci diversi. Certamente, le aziende particolari che hai nominato hanno il loro modo di fare le cose, ma le persone che sarebbero più in grado di rispondere per loro sono i dipendenti di quelle aziende.

Per quanto riguarda le grandi aziende in generale, anche loro variano ampiamente, anche per le aziende "tecnologiche". Alcuni adottano un approccio molto top-down alla sicurezza e all'utilizzo della tecnologia, altri no. Alcuni si preoccupano molto della sicurezza e molti no. Alcune aziende preferiscono creare i propri strumenti, mentre molte preferiscono utilizzare sistemi di terze parti e non reinventare la ruota ogni volta.

Inoltre, può variare notevolmente all'interno di un'azienda. I diversi reparti all'interno dell'organizzazione possono avere i propri metodi, diversi team all'interno dei reparti possono anche fare le cose in modo diverso e quindi, naturalmente, i singoli dipendenti possono spesso fare le proprie cose. Ancora una volta, dipende molto dal fatto che le scelte tecnologiche siano o meno dall'alto verso il basso o più dal basso verso l'alto.

Un esempio

L'azienda per cui lavoro è un'azienda più grande (~ 12.000 dipendenti ) società di commercio elettronico internazionale. Usiamo Single Sign On (SSO) per quasi tutto ciò che è interno, ma forniamo comunque ai dipendenti un account con un gestore di password online. Questo è destinato ad essere utilizzato per tutti gli altri siti Web a cui i dipendenti devono registrarsi nel corso del loro lavoro e a cui non possono accedere utilizzando il nostro SSO (AKA il resto di Internet). L'azienda acquista anche una licenza per un account "personale" con il gestore di password per ogni dipendente, principalmente nella speranza che incoraggi le persone non a memorizzare le password personali nel proprio account aziendale.

In pratica l'utilizzo di questo varia notevolmente da "dipartimento" a "dipartimento", con alcuni che hanno quasi il 100% di adozione mentre altre aree dell'azienda lo usano molto poco e hanno i propri metodi preferiti per memorizzare segreti importanti.

L'autenticazione di Facebook, quando ho lasciato, si è concentrata molto sull'autenticazione a più fattori. Sia Facebook che Google hanno investito nell'acquisto di Yubikeys e Google ha continuato a sviluppare U2F che è diventato FIDO. L'accesso al server era basato sull'emissione del certificato SSH firmato. C'era una chiave ssh "break glass" che era fisicamente conservata in una cassaforte così come alcuni host "super bastion" che potevano essere usati nel caso in cui il sito fallisse così gravemente che la gente iniziò a chiamare la polizia. Gli intervalli IP e i record DNS, tuttavia, possono essere semplici come la configurazione con applicazione automatica da un repository git. Le modifiche al DNS su Facebook sono frequenti.

Quasi tutti gli accessi sono basati sulla normale identità dell'utente, ma di solito con livelli. Una connessione VPN che richiede un certificato abbinato a una verifica della firma in cui la chiave è archiviata nell'enclave sicura del computer può essere utilizzata in modo tale da poter accedere a un sistema con le mie credenziali solo se è coinvolto un computer assegnato a me.

Nelle aziende più piccole che utilizzano AWS, ho implementato il controllo dell'accesso root di AWS inserendo la password e il segreto 2FA in Vault e ho utilizzato la distribuzione della chiave radice SSS integrata di Vault per i backup. Ogni accesso viene registrato ogni volta perché è necessario il codice 2FA rotante (Vault non ti consente di leggere il segreto, solo il valore del token) a meno che tu non collabori per acquisire sia i backup (gestiti da un team) che la collusione necessaria di altri dipendenti.

Lavoro per 1Password.

Abbiamo numerose grandi aziende che utilizzano 1Password, ma non parliamo dei nostri clienti senza il loro esplicito consenso. Nota anche che non possiamo vedere cosa viene memorizzato dove, quindi non possiamo davvero dedurre da ciò che possiamo vedere come stanno gestendo alcune delle domande molto buone di gestione che hai posto. Tuttavia, a volte partecipiamo a discussioni con i team di sicurezza dei nostri clienti su queste cose.

Un po 'di oscurità

Una cosa da notare è che mentre la sicurezza attraverso l'oscurità è generalmente una cosa negativa , è meglio tenere in silenzio alcuni dei dettagli che menzionate Se, ad esempio, un'organizzazione utilizza Shamir Secret Sharing, potresti non voler rendere pubblico chi detiene le condivisioni e quante condivisioni sono necessarie.

Quindi non ti dirò chi sono gli amministratori di il nostro account 1Password né il modo in cui gestiscono le proprie password principali e le chiavi segrete. Né descriverò in dettaglio gli aspetti dei nostri piani di continuità aziendale che riguardano alcune di quelle persone che vengono investite da un autobus. Questi sono ben pensati e ben protetti, ma non voglio mettere un bersaglio sulla schiena di nessuno. (Certo che puoi indovinare, e alcune di queste ipotesi potrebbero anche essere corrette.)

Suddivisione del potere di ripristino

Una cosa che potresti voler fare se sei un'azienda che utilizza 1Password è cerca di assicurarti di limitare il numero di persone che hanno entrambi i poteri di ripristino all'interno di 1Password e il controllo della posta elettronica all'interno dell'organizzazione. Non voglio entrare nei dettagli cruenti di tutta la gestione delle chiavi utilizzata per il recupero dell'account, oltre a notare che noi di 1Password non abbiamo mai le chiavi per poterlo fare, ma se Alice è il giusto tipo di admin per un team 1Password che include Bob e lei può leggere l'email di Bob, quindi ha il potere di assumere il controllo dell'account 1Password di Bob su quel team. (Anche se non in un modo che sia invisibile a Bob.) Nota che questo è documentato nel nostro documento di progettazione della sicurezza.

Quindi alcune organizzazioni potrebbero voler limitare le persone che avrebbero entrambi i poteri. Questo è un problema più grande per le organizzazioni più piccole rispetto a quelle più grandi. In quelli più piccoli, avrai team IT più piccoli, quindi le persone che potrebbero eseguire il ripristino dell'account potrebbero anche essere il gestore degli indirizzi email dell'organizzazione. Questo, tra l'altro, è uno dei motivi per cui offriamo account familiari gratuiti per i membri di un account aziendale. Il datore di lavoro non ha la capacità di eseguire alcun ripristino o accesso ai dati nell'account familiare di un dipendente.

Poteri amministrativi più fini

Essere un membro del gruppo di recupero per un team significa che alcune chiavi sono state crittografate nella tua chiave pubblica. C'è una grande quantità di attività amministrative che non richiedono l'appartenenza al gruppo di ripristino. Un'azienda può automatizzare in modo sicuro il provisioning e il deprovisioning degli utenti, ad esempio senza essere mai in grado di accedere o decrittografare le chiavi del gruppo di ripristino.

In generale, cerchiamo di rendere facile (o almeno non troppo doloroso) per le organizzazioni seguire una politica dei privilegi minimi per i poteri coinvolti nella gestione degli utenti di 1Password.

Condivisione dei segreti di Shamir, HSM, ecc.

1Password non offre (ancora?) questa tecnologia. Ma ho motivo di credere che alcuni dei nostri clienti lo facciano da soli per alcuni segreti principali. Allo stesso modo, ho motivo di credere che alcuni dei nostri clienti stiano utilizzando HSM per decrittografare alcuni segreti principali.

Credo che sia una buona cosa che lo facciano al di fuori degli strumenti 1Password. Potremmo fare di più per fornire hook per rendere più semplice tale integrazione, ma la gestione delle chiavi dovrebbe avvenire attraverso un altro sistema.

Anche a me piacerebbe saperne di più su ciò che i nostri clienti stanno facendo con questo e quindi non vedo l'ora di seguire le risposte. Ma allo stesso tempo, credo che questa sia una questione di politiche e pratiche in cui un po 'di oscurità è utile.

Parli delle chiavi private. Per questi, un metodo ben noto consiste nell'utilizzare i moduli di sicurezza hardware (HSM). Come le carte di credito basate su chip, tengono la chiave all'interno di una scatola che non puoi aprire e la riponi in un luogo sicuro. L'accesso alla funzione di firma della scatola (senza rivelare la chiave segreta, ovviamente) può anche essere protetto elettronicamente, come la tua carta di credito che richiede un numero PIN. Le scatole possono essere collegate direttamente a un server se è necessario utilizzare spesso la chiave, oppure possono essere archiviate offline.

Gli HSM di solito sono solo una parte di un'infrastruttura più grande per proteggere le chiavi pur essendo in grado di farlo usarli, ma le aziende non vogliono mostrare nei dettagli come fanno. La IANA, sebbene non sia una grande azienda, è comunque molto aperta al riguardo. E "possiede" chiavi incredibilmente importanti. Le loro cerimonie per la firma della chiave principale sono registrate su video e i video vengono pubblicati online come parte delle loro procedure per creare fiducia con il pubblico. Gli HSM sono archiviati in una cassaforte e collegati solo a dispositivi abbastanza affidabili (un sistema operativo di sola lettura su un computer che è anche archiviato in una cassaforte). La firma di una chiave richiede circa 3 ore poiché sono necessari molti passaggi per trasferire in modo sicuro i dati di una richiesta di firma, inizialmente archiviati su una chiave USB, nell'HSM, quindi per ottenere nuovamente i dati firmati sulla chiavetta USB. Infine, il processo richiede la presenza fisica di diversi esseri umani che non dovrebbero fidarsi l'uno dell'altro.

@CaffeineAddiction Thanks. Sto parlando specificamente di chiavi importanti come chiavi di crittografia, password di root, ecc. Chi le conserva? il CEO / CTO e alcuni dipendenti fidati?

Dipende da chi ha bisogno dell'accesso e dalla gerarchia dell'azienda. Le aziende più grandi hanno in genere più reparti composti da più team. E non tutto il personale di ciascun reparto richiederà lo stesso tipo di accesso.

Esistono più soluzioni per memorizzare i segreti e gestire l'accesso ad essi. Ne evidenzierò uno con cui ho più familiarità, HashiCorp Vault:

Proteggi, archivia e controlla strettamente l'accesso a token, password, certificati, chiavi di crittografia per proteggere i segreti e altri dati sensibili utilizzando un'interfaccia utente, una CLI o un'API HTTP.

Ho anche utilizzato personalmente una combinazione di tecniche di crittografia del disco e dei file in passato, per proteggere l'accesso a questi, ad esempio, dm-crypt e gpg .

Sebbene le soluzioni tecniche siano ottime, la realtà è che molte aziende non le utilizzano. E spesso è una questione di inerzia.

Ho lavorato in una varietà di aziende, dalle piccole startup di due persone alla massiccia multinazionale FTSE-100. Quello che scoprirai è che le piccole aziende agili sono di solito molto più avanti rispetto alle grandi multinazionali in termini di soluzioni tecnologiche.

La sfortunata realtà è che molte grandi aziende utilizzano ancora fogli di calcolo condivisi con password. Molti fanno ancora affidamento sulla memoria delle persone. Ad esempio, nel mio attuale ruolo di dirigente di medio livello in una grande multinazionale, ho la responsabilità e l'accesso a sistemi in cui, se abusato, potrebbe far crollare completamente un'azienda multimiliardaria. Alcuni di questi utilizzano SSO e si autenticano con LDAP aziendale. Tuttavia, alcuni fanno affidamento sull'accesso condiviso, ovvero un accesso condiviso da più persone. Quando ho iniziato a ricoprire questo ruolo, mi è stato detto verbalmente il nome utente / password e di non scriverlo o condividerlo con nessuno.

Da quando sono entrato, ho spinto per soluzioni per la tali compiti. Sfortunatamente, il muro di mattoni che ho colpito è il nostro equivalente del CTO (il titolo ufficiale è diverso, ma qui irrilevante), che è fermamente contrario a qualsiasi gestore di password o caveau elettronici (il suo argomento: "Non mi fido di loro, non preoccuparti di portare questo di nuovo "). E così continuiamo con i fogli di calcolo per molte delle password.

La soluzione specifica che ho provato a spingere è stata un'installazione locale di un noto gestore di password open source (non lo chiamerò qui). Consente agli utenti di aggiungere password e condividerle con altri utenti sulla stessa installazione. In questo modo, non esiste un'unica password da ricordare. Le password condivise vengono archiviate in un account senza nome e condivise con altri utenti che ne hanno bisogno.

Ottima domanda!

Dichiarazione di non responsabilità: ho lavorato per grandi aziende tecnologiche e questa risposta si basa su questo. Non vengono divulgate tecniche specifiche o proprietarie dell'azienda.

Autenticazione delle persone

Scommetto che Facebook, Google, Twitter e altre grandi aziende tecnologiche non utilizzare tali servizi di terze parti per le loro password interne

In realtà, almeno alcuni fanno gestori di password di terze parti - per dipendenti e servizi non critici . Per la natura dell'attività, i dipendenti hanno spesso bisogno di interagire con siti Web di terzi (gestione delle informazioni dei dipendenti, prenotazione di viaggi, carte di credito dei dipendenti, ...). Tieni presente che queste sono credenziali individuali: autenticano una persona, non una risorsa o un processo

Il più grande dei servizi supporterà SSO (single sign-on) fornito dall'azienda. SSO è molto più sicuro, ma non tutti i fornitori lo supporteranno.

Un'altra pratica adottata nella maggior parte delle grandi aziende tecnologiche è l'uso di chiavi di sicurezza per l ' autenticazione a due fattori utilizzando U2F / FIDO o più recentemente WebAuthn / FIDO2

TOTP (" Google Authenticator") è comune, ma più vulnerabile agli attacchi MITM.

Autenticazione di risorse e processi

In che modo un'azienda molto grande può gestire alcune delle password più sensibili al mondo? (esempio: password di accesso root del team Gmail!)

Non esiste una "password root del team Gmail". La sua esistenza costituirebbe una minaccia enorme per la privacy dei dati degli utenti e, per estensione, per l'azienda.

C'è una sottile differenza con il tuo ultimo caso qui. Non stiamo autenticando le persone, stiamo autenticando risorse e processi.

Di solito non c'è di solito bisogno o vantaggio di usare una password per quei casi, ma sono ancora utilizzati per comodità, facilità di implementazione o perché non ci sono altre alternative.

Esaminiamo alcuni scenari ispirati a esempi di vita reale presso grandi aziende tecnologiche :

Il pin a 8 cifre della cassaforte contenente il cavo che ti collega al data center

Questa cassaforte potrebbe contenere o meno un cavo

Qui stiamo parlando di una risorsa condivisa che viene autenticata utilizzando una credenziale condivisa . Non esiste un modo (semplice) per renderlo più sicuro supportando credenziali individuali o accesso isolato.

Altri esempi:

• codici di accesso
• codici di disabilitazione allarmi
• credenziali "break-glass" -for-key di emergenza

Best practice per questo tipo della risorsa è:

• Condivisione del segreto attraverso un canale sicuro (come un gestore di password)
• Controllo dell'accesso segreto (le persone vengono autenticate e l'accesso al segreto viene registrato)
• Rotazione segreta: il segreto viene cambiato periodicamente

Ovviamente, troverai spesso anche pratiche sub-par!

• Condivisione segreta in un foglio di calcolo
• Segreto scarabocchiato in qualche post-it
• Segreto conosciuto da questo ragazzo che la gente conosce

Scenario 2 - Il processo software che memorizza la posta elettronica degli utenti

Ti fideresti di questo pezzo casuale di codice per memorizzare i tuoi segreti più intimi?

Questo scenario è più complesso. Qui abbiamo un processo che deve identificarsi con altri processi (come un database o un server web).

Le migliori pratiche possono includere:

• Nessun utilizzo di password (o segreti condivisi).
• Utilizzo di token di autenticazione di breve durata, comuni in protocolli come Kerberos
• Utilizzo di piattaforme di gestione delle chiavi come Hashicorp Vault o AWS Key Management Services, che facilitano la generazione, la rotazione e l'autenticazione dei segreti.
• Utilizzo di moduli di protezione hardware, garantendo che l'accesso a un dispositivo fisico debba avvenire affinché il processo possa svolgere la sua funzione
• Utilizzo di revisione del codice protocolli. Questo ha un duplice scopo di controllo degli accessi e auditing, per garantire che nessuna singola persona possa ottenere il controllo del sistema

Le peggiori pratiche includono:

• Codifica hard di password / chiavi nel codice sorgente

• Consentire a persone a caso di modificare il codice senza approvazione alle 4 del mattino

Scenario 3: il gruppo amministrativo mondiale che può riavviare tutti i server

Sai di avere un problema quando devi spiegare a tante persone di non premere il pulsante rosso

Qui abbiamo un'azione o un'attività che può essere eseguito da determinati tipi di persone .

La migliore pratica è l'utilizzo di un appropriato sistema di controllo degli accessi basato sui ruoli (RBAC). Questi sono spesso fatti su misura e variano da organizzazione a organizzazione. Un esempio primitivo è un gruppo UNIX.

Come nell'esempio delle "credenziali condivise", il controllo / registrazione è essenziale e in questo caso più semplice, poiché la risorsa è elettronica / software -basato. L'appartenenza al gruppo può essere data o presa liberamente, da un gruppo di amministratori (che è solo un altro gruppo!) O anche da un quorum di membri del gruppo stesso

Sull'importanza dei processi rispetto a tech

Sono note grandi aziende per utilizzare implementazioni di Shamir's Secret Sharing?

Un po '. Anche nel regno dei cripto-nerd che conducono calcoli super sicuri, scoprirai che in pratica i processi umani sono spesso importanti quanto quelli tecnici.

Esempi famosi:

• La IANA DNSSEC Root Signing Cerimony, che protegge praticamente tutta Internet
• I codici multipli detenuti da diverse persone necessarie per lanciare un nucleare attacco

Gestione del rischio e controlli di accesso basati sui ruoli (RBAC)

OP chiede soluzioni tecnologiche a quello che è, in ultima analisi, un problema relativo al rischio. Altre risposte forniscono un buon esempio dei tipi di strumenti disponibili (ad es. 1Password, Hashicorp Vault, ecc ...) ma vorrei affrontare la questione sottostante dei rischi. Ciò determinerà quale delle molte opzioni ha più senso. Non esiste una risposta valida per tutti, poiché diverse aziende hanno diversi modelli di minaccia e affrontano diverse fonti di rischio.

OP fondamentalmente chiede informazioni sul rischio di:

• Unico controllore del segreto diventa canaglia o non è disponibile
• Uno dei tanti controllori perde il segreto o diventa canaglia

La misura usuale del rischio è la probabilità di perdita x valore di perdita. Ad esempio, hai l'1% di possibilità di perdere 1 milione di dollari all'anno a causa di $ BAD_THING. Se puoi acquistare un'assicurazione per meno di $ 10.000 contro quella perdita, vale la pena farlo. Stai valutando il tuo rischio e ti stai assicurando contro di esso. Se l'assicurazione è troppo costosa e scegli di non fare nulla sperando di essere fortunato, stai accettando il rischio. Se metti in atto politiche e controlli per impedire che $ BAD_THING accada, stai mitigando il rischio.

Le aziende valutano il potenziale di perdita derivante dalla perdita (o dal furto) delle loro chiavi crittografiche, attribuendo un prezzo a quell'evento e quindi cercare controlli per valutare i costi.

"Molti controllori" delle chiavi consente all'azienda di scambiare un rischio con un altro, il che potrebbe essere più appetibile. Un singolo controller viene colpito da un bus e l'unica chiave viene negata all'azienda è una minaccia esistenziale piuttosto grande se tutto dipende da quella chiave / controller. Quindi dai al controller l'accesso a più persone. Ora non perdi l'accesso alla chiave, ma aumenti le possibilità di "diventare un ladro". Quanto è probabile? Scegli un numero. 1% di possibilità per dipendente con accesso all'anno? Ora puoi iniziare a modellare quante persone dovrebbero avere accesso in un dato momento.

Questo ti porta a RBAC. "Jane the CTO" non dovrebbe mai avere accesso personale a SuperSecret. Tuttavia, potrebbe essere l'unico membro fidato del gruppo SecretAdmins. Quel gruppo ha accesso al SuperSecret, ma l'appartenenza a quel gruppo è dinamica, può essere verificata e modificata secondo necessità.

Ciò offre all'azienda la possibilità di regolare la propensione al rischio e bilanciare interessi in competizione con fonti diverse di rischio.

La tecnologia specifica è quasi irrilevante. La parte importante è che il design del controllo segreto corrisponda al profilo di rischio.

Le chiavi più sensibili dovrebbero essere generate e archiviate su moduli di sicurezza hardware (HSM) e non lasciarle mai. La sicurezza diventa quindi l'accesso fisico all'HSM stesso, oltre a un modo per gestire la revoca della chiave in caso di furto del dispositivo. L'esempio più ovvio per questo è sufficiente è la gestione delle chiavi private dei certificati TLS del server web. Se l'HSM si interrompe, ottieni solo un nuovo certificato. Se viene rubato, si revoca il certificato.

Nel caso in cui la perdita della chiave sarebbe un problema significativo, l'idea principale è quella di memorizzare la chiave in uno o più HSM e usarla solo per crittografare altri chiavi (si archiviano le chiavi crittografate in modo sicuro da qualche parte, ma non è la fine del mondo se le chiavi crittografate vengono rubate), il modo in cui i certificati radice TLS vengono utilizzati per firmare i certificati intermedi, e quindi quelle chiavi crittografano altre chiavi e quelle le chiavi sono meno preziose e facili da sostituire e sono quelle che vengono utilizzate per qualcosa di diverso dalla crittografia delle chiavi. Con la crittografia a chiave pubblica questo è molto, molto più semplice di quanto non fosse con le sole chiavi simmetriche.

La chiave principale è suddivisa e distribuita, ma il modo in cui viene gestita è particolare per ogni azienda. È possibile utilizzare HSM separati per generare e memorizzare chiavi separate e quindi combinarle per formare la chiave master semplicemente mediante concatenazione. Oppure puoi XOR insieme. In molti casi, è sufficiente dividere la chiave in due. Qualsiasi chiave di cui ho conoscenza personale diversa dalle chiavi radice dell'autorità di certificazione TLS è stata divisa solo in 2 o 3 parti, tagliando la chiave in pezzi o XORing la chiave con numeri casuali. Spero che le persone stiano usando la condivisione segreta di Shamir in modo più ampio ora, ma non lo so.

La parte fondamentale può essere memorizzata su un HSM, una chiavetta USB o carta comune. Può essere conservato in caveau o in un armadietto sicuro in una struttura sicura (ad esempio, il tipo di edificio in cui le banche elaborano i bonifici bancari è abbastanza sicuro che un armadietto chiuso a chiave in una stanza chiusa a chiave in un tale edificio potrebbe essere considerato abbastanza sicuro da contenere un parte chiave se nessun'altra parte della chiave era nello stesso edificio). Oppure può essere memorizzato nel portafoglio del CEO.

Per una chiave distribuita, l'importante è assicurarsi che venga rilevato qualsiasi furto di qualsiasi parte in modo che la chiave possa essere cambiata. Alcuni sistemi dispongono di una chiave primaria e secondaria già fornita, quindi la chiave primaria può essere revocata in caso di emergenza senza dover prima eseguire il processo di provisioning o installare una nuova chiave. Quindi l'amministratore delegato può tenere la propria parte nel portafoglio in modo che, nel caso in cui vengano rapiti, non avranno problemi a consegnarla piuttosto che cercare di sopportare qualunque cosa i rapitori abbiano in mente per fare pressione. La sicurezza è sempre una serie di compromessi.

Vale la pena rivedere il hack RSA del 2011. Il fatto che le loro chiavi token private (o seed, che possono essere trasformate in chiavi con un algoritmo di ingegneria inversa) non siano state tenute fisicamente separate è stato uno shock per molti di noi. A quel tempo, avevo più fiducia che una volta effettuato l'accesso al mio account aziendale protetto con token RSA 2FA, stavo davvero lavorando in un tunnel sicuro.

Oh beh, tanto per quello.

Il mio datore di lavoro sembra nutrire dubbi simili, poiché ora proibisce ai dipendenti statunitensi di accedere dall'esterno degli Stati Uniti senza l'approvazione di molti livelli. Ora è un grave reato portare fuori dal paese un dispositivo crittografato di proprietà dell'azienda, e tanto meno accenderlo. (Questo ha devastato espatriati e dipendenti immigrati che potrebbero tornare a visitare la famiglia nel paese di origine per alcune settimane.)

Da quello che vedo nei media commerciali, le aziende stanno prendendo più seriamente la necessità di archiviazione delle chiavi con aria (e cassaforte in acciaio), completamente scollegata e fisicamente protetta. Si può sperare che misure come quelle prese per la cerimonia della firma di root DNSSEC ne siano un esempio. Siamo molto lontani dai giorni in cui Jon Postel poteva assumere il controllo del DNS solo per fare un punto. (O lo siamo?)

Ma scommetto che Facebook, Google, Twitter e altre grandi aziende tecnologiche non utilizzano tali servizi di terze parti per le loro password interne e hanno i propri gestori di password per le password più critiche.

Buffo che tu abbia menzionato Twitter. Secondo quanto riferito:

gli hacker hanno violato gli account dei dipendenti Slack e hanno trovato le credenziali per il backend di Twitter bloccate all'interno di un canale Slack.

Se questo è vero, significa che le password piuttosto cruciali che consentono di impersonare gli utenti sono (erano?) semplicemente appuntate su una bacheca in cui i dipendenti possono accedervi.

Sono a conoscenza del fatto che le aziende (non così grandi) memorizzano tutte le password principali in un foglio google o in un file di testo. La migliore pratica che abbia mai visto nella vita reale è un file KeePass condiviso.

La maggior parte dei grandi clienti con cui ho lavorato, molti con più di 20.000 host unix, semplicemente non si fidano delle password da sole. Pensa alle grandi industrie finanziarie, energetiche e ad altri settori altamente regolamentati.

Usano un prodotto come "Powertech BoKS" per controllare l'accesso separando l'autenticazione dall'autorizzazione. Ad esempio, non importa se conosci la password di root (autenticazione) se non hai una regola (autorizzazione) che ti consenta di usarla. E sì, ciò include la console!

L'integrazione di token e un forte controllo degli accessi è probabilmente il metodo n. 1 per proteggere questi grandi ambienti. Non si basano semplicemente sulla conoscenza della password per determinare l'accesso.

Ad esempio: l'accesso a un server (tramite SSH, telnet, ftp, x, ecc.) È consentito solo a utenti specifici ... anche se molti gli utenti hanno account su un host, forse alcuni possono usare SSH, alcuni possono usare SCP e altri possono usare FTP. Inoltre, possono provenire solo da fonti note identificate.

Un amministratore di sistema potrebbe essere in grado di accedere a un host utilizzando la sua password nome utente personale ... ma, per passare all'account root, deve usare 2FA. E ... anche se ha una risposta 2FA valida, deve avere il permesso di passare a root o l'accesso viene negato. L'amministratore non è a conoscenza della password di root.

Molte di queste società limitano ulteriormente l'uso dell'account di root a finestre temporali specifiche. Ciò significa che anche se l'amministratore di sistema conosce la password di root, o ha una risposta 2FA valida per diventare root, il suo accesso sarebbe negato se tentasse di ottenere tale accesso al di fuori di una finestra di controllo delle modifiche.

anche l'amministratore deve provenire da un host o una rete noti ... ad es. la connessione non può provenire dalla DMZ, o forse è consentita solo quando proviene da uno specifico jump-host.

Questi tipi di controlli rigorosi sono fondamentali per proteggere queste grandi organizzazioni.

Per quanto riguarda la vera password di root ... perché tutti sappiamo che ad un certo punto qualcuno ne avrà bisogno ... Le password di root sono solitamente conservate in un vault. Un amministratore di sistema può "controllare" la password di root in caso di emergenza. Tieni presente che anche la possibilità di controllare quella password è strettamente controllata. Nella maggior parte dei casi, l'amministratore non può verificarlo a meno che non abbia una regola che gli concede l'accesso al sistema del vault stesso e una regola che consente il checkout della password di root specifica per un host specifico. Avrebbe anche bisogno di usare il suo 2FA per accedere al caveau per cominciare. In alcune implementazioni più avanzate, non può controllare la password senza associare il checkout a un ticket di controllo delle modifiche valido. Una volta estratto, il vault randomizzerà automaticamente una nuova password per l'account root.

Questi concetti sono validi per molte grandi aziende, ma si applicano anche alle aziende con un minimo di 25 host unix. Non è tanto un fattore di quanto è grande l'azienda o quanti server potrebbero avere, è quanto sensibili considerano i loro dati. Anche le piccole aziende possono essere soggette a requisiti normativi che devono soddisfare.