Esistono motivi oggettivi per utilizzare utenti / password dedicati anziché provider di identità all'interno di una grande organizzazione?

Per la maggior parte delle organizzazioni, un sistema di identità unificato completo è una cosa positiva. Hai chiesto se ci sono dei motivi per non farlo. Ne elencherò alcuni che potrebbero non essere validi in diverse organizzazioni:

1. Il sistema non supporta il provider di identità. Potresti avere un sistema mainframe basato su terminal legacy che non è facile collegare ad AD. Esistono molti prodotti commerciali per collegare prodotti legacy ai sistemi di identità, sebbene questi possano essere costosi. In alternativa, potresti avere sistemi basati su cloud (come Salesforce) con cui ti sforzi di integrarti.

2. Il sistema è sensibile e non si desidera esporlo in caso di violazione del sistema di identità. Questo può essere valido per un numero limitato di sistemi altamente sensibili, sebbene questo argomento sia sovrautilizzato negli ambienti aziendali. Se il tuo provider di identità è AD, una violazione di AD potrebbe significare una violazione di tutte le workstation che le persone useranno per amministrare questi sistemi, quindi la separazione è poco più che un teatro di sicurezza.

3. Il provider di identità non è accessibile dal sistema. Un esempio comune è rappresentato dai sistemi rivolti su Internet in una DMZ che vengono bloccati da un firewall per accedere all'AD interno. Ho visto grandi organizzazioni che creano un AD separato per i sistemi DMZ. Un problema simile può verificarsi con i sistemi di sviluppo vs produzione.

4. Alcuni utenti non fanno parte del provider di identità. L'esempio classico è dove si hanno alcuni utenti esterni che accedono a un sistema interno. Puoi gestire questo problema facendo in modo che il sistema supporti più metodi di autenticazione o che gli utenti esterni si trovino nel tuo provider di identità, con le opportune restrizioni.

Se le difficoltà di integrare un sistema con il provider di identità valgono i benefici è un atto di bilanciamento. La maggior parte degli amministratori IT accetta che gestire un'orda di credenziali faccia parte del lavoro.

Innanzitutto, Active Directory è un protocollo proprietario che potrebbe non essere il più semplice da utilizzare al di fuori del mondo Windows. Per questo motivo è comune avere almeno 2 autenticazioni, una per il mondo Windows per altri sistemi (comunemente Unix / Linux). Questo può essere reso quasi trasparente per gli utenti a condizione che uno dei provider di autenticazione sia sincronizzato sull'altro.

Questo normalmente può risolvere la maggior parte delle esigenze di autenticazione. Ciò che può ancora rimanere sono:

• software proprietario che insiste nell'avere il proprio sistema di autenticazione privato. È ancora più comune di quanto potremmo desiderare ...
• account di sistema di basso livello (es .: root su un sistema Unix o account dba su un database). Mentre gli account utente normali possono ricevere privilegi o la possibilità di ottenerli tramite sudo, è comune consentire l'accesso amministrativo locale di basso livello per quando le cose vanno male . Ma non dovrebbe essere un problema per gli utenti standard.
• account di sviluppo. Nella fase di sviluppo, un'applicazione non può essere collegata ai principali provider di autenticazione. Quindi gli sviluppatori e i tester devono utilizzare account dedicati.

Questo è per casi d'uso accettabili . Ma c'è ancora un'altra categoria: sistemare un sistema SSO ha un costo in termini di tempo e denaro. Alcune organizzazioni possono scegliere di non andare là perché pensano che non ne valga la pena o, a volte, perché non sono consapevoli del possibile guadagno. Solo in quest'ultimo caso d'uso, potresti suggerire al tuo diretto manager che sarebbe molto interessante, ma dovrai trovare il caso d'uso reale dove risparmiare tempo o prevenire errori. Tutti lo fanno potrebbe non essere sufficiente per convincere un grande capo ...

Active Directory non è sicuro (per impostazione predefinita)

Questo è un colpo contro ADFS perché si basa su AD, che richiede un certo sforzo per proteggere correttamente.

Se si utilizza affatto Active Directory e, in particolare, se controlla l'accesso ai sistemi critici, è necessario progettare il proprio ambiente per risolvere le gravi carenze di sicurezza.

Come minimo, dovresti implementare il design della foresta rossa di Microsoft in in conformità con il loro modello di amministrazione multilivello per mitigare gli attacchi pass-the-hash (PtH), pass-the-ticket (PtT) e golden ticket.

La federazione è il futuro

Quando si tratta di utenti esterni, ADFS è di gran lunga superiore alla creazione di account nel dominio o alla creazione di trust di Active Directory. Se puoi usare ADFS, fallo assolutamente.

Dato che menzioni in modo specifico Google Identity, sono basati su OAUTH e OAUTH dovrebbe interagire con ADFS .

Poiché ADFS è semplicemente l'implementazione di Microsoft di un provider di identità SAML, dovrebbe diventare più utile nel tempo. In termini aziendali, SAML è ancora abbastanza nuovo, ma è in crescita.

Account multipli ancora richiesti

Gli utenti amministrativi continueranno a richiedere più account. Non puoi ragionevolmente eliminare quella necessità. Qualsiasi account che può accedere a Internet non dovrebbe avere accesso privilegiato per gestire la tua infrastruttura o apportare modifiche negli ambienti di sviluppo / test.

Potresti ancora riuscire a consolidare, anche se gli amministratori devono avere 2-3 account AD individuali. Ad esempio, sia Oracle che MS SQL supportano l'autenticazione con le credenziali di Windows, quindi i DBA e gli sviluppatori non avrebbero più bisogno di account utente / pass unici in ogni istanza.

Un problema che vorrei sollevare sarebbe la mancanza di accesso agli attacchi in tempo reale del sistema di gestione delle identità. Ad esempio, se qualcuno sta attaccando il tuo server di gestione delle identità e sta entrando con successo, puoi agire non appena ne sei a conoscenza. Nel caso di qualcuno che compromette un fornitore di identità di terze parti, potresti non sapere per un paio di mesi quando / se decidono di rivelare la violazione.

Prima di tutto, potrei anche non desiderare che alcuni sistemi abbiano un tale sistema di "single sign-on". In un commento hai citato database e altri sistemi. Come tecnico, preferirei una chiave SSH separata (protetta da password) per connettersi a server, password per accedere ai database, ecc. Quindi la soluzione di un provider di identità centralizzato non è adatta a tutte le esigenze. Soprattutto considerando che questo approccio aggiunge un altro sistema (il tuo provider di identità) che deve essere raggiungibile al fine di autenticarsi. Questo è molto probabilmente il caso per la maggior parte del tempo, ma è comunque un requisito da tenere a mente.

Inoltre, i sistemi devono essere in grado di lavorare con i provider di identità. Dubito che l'accesso a un database possa generalmente essere autorizzato usando un provider di identità di questo tipo al posto di username / password. La migrazione di tutti i sistemi per utilizzare un provider di identità potrebbe (e sicuramente lo farà) causare problemi che non ti aspettavi. Forse nessuno vuole investire tempo e denaro per cambiarlo, dato che username / password è sicuramente più facile da implementare.

Supponendo che gli utenti che scrivono le loro credenziali sia il problema che stai cercando di risolvere, promuoverò pesantemente l'utilizzo di gestori di password (magari con l'immagine del sistema operativo predefinita?) una password per domarli tutti e gli utenti possono comunque mantenere password difficili da decifrare per ogni servizio. Alcuni utenti continueranno a scriverli su un pezzo di nastro sotto la loro tastiera, ma quello è un business usus (sfortunatamente).

Per essere chiari, mi piace l'idea di un fornitore di identità centralizzato. Sono tutti punti contro di esso, posso pensarci proprio ora. Qualsiasi aggiunta è benvenuta (è una domanda interessante).

Molte buone risposte / commenti prima quindi cerco di farla breve:

Per me il motivo principale per utilizzare account utente diversi con credenziali diverse è la sicurezza delle credenziali a lungo termine, indipendentemente dal fatto che si utilizzino password (ad esempio LDAP), segreti condivisi (ad esempio Kerberos, TOTP, ecc.), asimmetrica schemi di firma (ad es. chiavi SSH).

Un semplice esempio di password:

Non vuoi accettare la stessa password che un utente ha memorizzato sul suo telefono cellulare per leggere la posta elettronica per concedere l'accesso amministrativo a un server di database back-end bloccato con tutti i dati dei tuoi clienti.

Un altro esempio di chiavi SSH separate:

Per un sottoinsieme di sistemi SSH potresti essere costretto a utilizzare l'inoltro dell'agente chiave SSH o, ancora peggio, a copiare la tua chiave privata personale su un host jump. Pertanto, non si desidera utilizzare la stessa chiave privata come chiave autorizzata su altri sistemi con requisiti di sicurezza diversi.

Sì, mantenere account separati in file Excel o simili è un incubo e dimostra che la maggior parte dei sistemi e dei processi IAM non gestisce molto bene più account per persona. Questo problema può essere risolto scegliendo un buon sistema IAM.

(Potresti richiedere diverse combinazioni di schemi di autenticazione per sistemi diversi ma è anche un incubo da solo.)

Per quanto riguarda tutti i tipi di mech single sign-on come CAS, SAML, OpenID (Connect) ecc.:

Penso che sia un obiettivo ammirevole utilizzarli se possibile perché le credenziali a lungo termine non superano sistemi potenzialmente più insicuri del tuo servizio di accesso centralizzato. Oggi è abbastanza facile integrare le applicazioni web. Devi verificare se possono gestire più sessioni di identità o configurare diverse istanze SSO.

Ma ad es. per gli accessi SSH o il controllo dell'accesso alla rete con 802.1x attualmente non vedo soluzioni SSO o 2FA facilmente utilizzabili. Per questi casi d'uso che emettono certificati a breve termine (certificati OpenSSH o certificati X.509) potrebbe essere una soluzione praticabile.

TLDR: non cadere nella trappola dell'uno o dell'altro. Utilizzare un sistema IAM decente e fornire i front-end di autenticazione corretti per qualsiasi sistema e applicazione con cui si ha a che fare.