Quali precauzioni dovrei prendere quando creo utenti che verranno utilizzati dalle applicazioni e non dalle persone?

21

Ho alcune applicazioni che devono accedere a un bus dei servizi web . Le proprie applicazioni che accedono al bus si autenticano utilizzando un servizio web su quel bus ma in questo caso ho bisogno che le applicazioni di terzi accedano ad alcuni servizi web nel bus.

Queste applicazioni di terzi devono autenticarsi in un LDAP ( Oracle OID ). Devo creare un utente e una password per ogni applicazione che deve essere autenticata.

Esiste un modo più sicuro per autenticare queste applicazioni di terze parti nel bus webservices?

Quali precauzioni dovrei prendere quando creo questi utenti nell'OID?

Quali precauzioni dovrei prendere quando creo utenti che verranno utilizzati dalle applicazioni e non da persone?

    
posta Eloy Roldán Paredes 24.12.2015 - 08:54
fonte

3 risposte

8

L'identificazione e il monitoraggio diventano importanti ma sorprendentemente difficili.

Per prima cosa, tagga gli account nella directory in modo da poterli identificare come ID non-utente.

Ogni account non utente deve essere associato al proprietario di un account, qualcuno responsabile della protezione del sistema a cui accede. Memorizza l'identità del proprietario nella voce della directory dell'ID non utente, quindi se vai a cercarli più tardi, sai chi deve essere contattato. Ricorda che i proprietari vanno e vengono con promozioni dei dipendenti, fatturato, ecc., Quindi potresti avere bisogno di un reparto o di un altro tag organizzativo per andare con l'ID del dipendente. L'adesione al gruppo può aiutare qui. Inoltre, man mano che i dipendenti escono, i loro account di directory possono essere eliminati, rendendo inutilizzabile un'ID sconosciuta - un nome è almeno qualcuno che altre persone possono aiutarti a rintracciare.

Potrebbe anche essere utile sapere a quale macchina sono associati gli account. Tieni anche queste informazioni nella tua directory.

Se hai un sistema di richiesta formale, in cui le persone inseriscono i loro requisiti per richiedere l'account, la macchina, ecc., memorizzo il numero di richiesta nella voce della directory. Tuttavia, tieni presente che i sistemi di tracciamento delle richieste possono essere modificati e che le informazioni associate ai numeri di monitoraggio rilasciati 5 anni fa potrebbero non essere più disponibili. Ti consiglio di mantenere il proprietario e le informazioni sulla macchina anche sul registro.

Se non si dispone già di un processo di revisione formale per i propri account, si consideri che quando si implementa uno, si avrà una grande pila di account non utente nella propria directory. Questi dati ti aiuteranno a identificare i revisori (i proprietari dei sistemi dovrebbero rivederli per appropriatezza su base periodica). Considerare di tenere i dati della revisione con il record; potresti persino voler mantenere le informazioni "ultime riviste su / da" nella directory per fornire ai revisori dei conti.

Il motivo principale per conservare queste informazioni è in caso di compromissione. Durante la fase di risposta, è necessario essere in grado di identificare rapidamente le persone associate all'account in modo da poter modificare le password, eseguire la scansione dei sistemi e rintracciarli rapidamente, con il minimo sforzo. Tieni presente che potrebbe essere necessario svolgere questa attività senza avvisare i proprietari del sistema, almeno finché l'indagine è attiva. Potrebbe anche essere necessario fornire informazioni di revisione agli investigatori. È una triste realtà che il compromesso possa provenire da una fonte interna.

Per rispondere al resto della tua domanda, dovresti generare una lunga password, usando un generatore di password crittograficamente strong (non javascript's random ()). Se puoi assegnare questi account e password senza coinvolgere gli umani, utilizzando uno strumento di gestione delle password, è ancora meglio. Ci sono sistemi commerciali che si collegano ai server LDAP per fare molto di questo (dato che sei un negozio Oracle, dovresti controllare con il tuo rappresentante del conto perché vendono un sistema del genere.)

    
risposta data 31.12.2015 - 17:29
fonte
3

In generale non c'è un'enorme differenza tra gli utenti creati per l'automazione e gli utenti creati per persone reali. Dovresti comunque limitare l'accesso a ciascun utente solo a ciò che è richiesto.

È un po 'più ambiguo pensare a come segmentare l'accesso ai servizi di terze parti a una risorsa attendibile. Una persona ha normalmente un solo account e non creiamo più account per utente (con alcune eccezioni a questo). Ma il tuo "servizio" può essere pensato in più modi. Solo tu puoi determinare come delinearlo e se diverse parti di ciò che potresti pensare come un singolo servizio potrebbero necessitare di diversi livelli di accesso.

Ad esempio, c'è un server di posta noto come postfix. Ad un livello elevato puoi pensare a postfix come a un singolo servizio. Ad un livello inferiore, è davvero progettato più processi che compongono ogni servizio al suo interno. Ogni processo ha la minima quantità di privilegi necessari per portare a termine il lavoro.

Con un software di terze parti, potresti o meno essere in grado di realizzare un "minimo privilegio" di fare le cose. Ma è ancora una considerazione importante nel design quando si imposta l'automazione che non è rilevante quando si ha a che fare con persone reali.

    
risposta data 31.12.2015 - 17:09
fonte
3
  1. Un altro commentatore ha suggerito di utilizzare i certificati invece di LDAP - Ma non consiglierò di utilizzare 2 meccanismi di autenticazione se non è possibile farlo facilmente. Avere un sistema di autenticazione assicurerà che ci saranno meno probabilità di implementazioni inadeguate.
  2. Per le password complesse utilizzare un algoritmo di generatore "UUID tipo 4" - questo ti darà una stringa casuale che ti si addice (non sarà immaginabile).
  3. Gli utenti che non sono utilizzati dall'applicazione hanno la debolezza di avere le autorizzazioni complete dell'utente mentre possono essere controllati da chiunque abbia accesso ad essi (in modo che gli ex dipendenti possano ancora accedervi) - assicurarsi che l'accesso a tali applicazioni sono gestite (insieme alle loro autorizzazioni - forniscono solo permessi sufficienti per il loro funzionamento). Gestisci anche la scadenza della password con cautela - Se un'applicazione non incorporerà tale opzione di scadenza e sarà abilitata, potrebbe smettere di funzionare in un orario inatteso.
risposta data 01.01.2016 - 13:37
fonte

Leggi altre domande sui tag