Best practice per l'archiviazione delle credenziali nel data center

6

Ho uno script di riscaldamento della cache che voglio avviare in risposta a un determinato evento lato server. Questo script richiede le credenziali dell'utente per eseguire il proprio lavoro (account di sola lettura). Finora ho evitato di automatizzare questo processo perché non volevo memorizzare QUALUNQUE credenziale sul server, ma sono giunto al punto in cui ho davvero bisogno di automatizzare il processo. Il server è CentOS 6.

So che memorizzare le credenziali è un rischio, quindi sono curioso di sapere quale sia lo standard del settore se non riesco ad accedere a un terminale per accedere a una credenziale ogni volta che ho bisogno di eseguire questo processo.

Aggiorna La domanda radice: Se NON è ok per avere le credenziali archiviate in chiaro, quali sono le altre opzioni?

    
posta Jeremy Mullin 17.01.2013 - 17:49
fonte

2 risposte

1

Per evitare di utilizzare completamente le credenziali, disaccoppia il trigger dello script di riscaldamento della cache dall'evento sul lato server.

Il concetto è:

  • evento lato server imposta un flag in un percorso condiviso
  • processo persistente eseguito da script di riscaldamento della cache che l'utente monitora la posizione condivisa
  • se il processo permanente vede che il flag è impostato, il flag è cancellato e lo script di riscaldamento della cache viene eseguito

Poiché il processo persistente può essere eseguito tramite cron o come demone di proprietà dell'utente di script di riscaldamento della cache, è sufficiente impostarlo una volta, non è necessario passare mai le credenziali dell'account utente.

Località condivisa:

Stabilire una posizione condivisa a cui è possibile accedere e scrivere sia dall'evento lato server che dall'utente che deve eseguire lo script di riscaldamento della cache. In un sistema con un database, questa potrebbe essere una variabile in una tabella di configurazione. Ma questo potrebbe anche essere solo un file in una directory che è + rw da entrambi gli utenti e viene toccato dall'evento sul lato server.

Impostazione del flag:

Se stai usando un database, un esempio di impostazione di un flag sarebbe se hai una tabella di variabili che ha colonne chiave e valore, impostando il valore di una particolare chiave su 1. Se è un file, sarebbe l'esistenza di un file.

Vantaggi secondari:

Se devi limitare la frequenza di esecuzione dello script di riscaldamento della cache, puoi sempre implementare la logica nel processo permanente per tenere traccia dell'ultima volta in cui è stato eseguito lo script per evitare un uso eccessivo se qualcosa va male.

È possibile aggiungere facilmente più trigger dello script di riscaldamento della cache da altri eventi lato server perché il metodo di attivazione dello script è nascosto dietro l'interfaccia di posizione condivisa.

    
risposta data 17.01.2013 - 20:29
fonte
1

Per quanto riguarda l'aggiornamento: Se NON è ok per avere le credenziali archiviate in chiaro, quali sono le altre opzioni?

Generalmente una volta che un'entità vuole autenticarsi su un servizio, l'entità deve disporre di un token di autenticazione. Detto questo, se si utilizza l'autenticazione della password e si desidera eseguirla automaticamente, è necessario rendere la password accessibile in qualche modo in un testo in chiaro, altrimenti sarà necessario un altro token per trasformarlo da "forma sicura a testo in chiaro".

Tornando al tuo problema originale, è sempre bene considerare chi, perché e come qualcuno potrebbe (volere) abusare delle credenziali (se fossero in un file in chiaro leggibile solo dall'utente che esegue lo script di riscaldamento della cache per esempio ). Potrebbe risultare che assicurarlo non ha molto senso o che il concetto generale di sicurezza del progetto è difettoso.

Potresti chiedere su Sicurezza SE - è probabile che rispondi in modo più approfondito.

    
risposta data 18.01.2013 - 00:35
fonte

Leggi altre domande sui tag