Fondamentalmente, sto considerando di memorizzare una password codificata AES-Base64 in un file nascosto, con un permesso di 600, in una posizione insolita di un server Unix / Linux.
Quella password sarebbe stata usata da un automa nel crontab per connettersi ad altri server.
Quanto è grave questa idea? (Considerando che l'utente root è bloccato e che i server non hanno accesso a Internet e c'è un tunneling proxy per connettersi al server che manterrà questo file nascosto)
In primo luogo, veramente devi usare le password? Le chiavi SSH sarebbero molto più adatte per "un automa nel crontab per connettersi ad altri server".
Se è necessario memorizzare tali password, l'installazione corretta creerebbe un account utente specifico (non root) per questo caso, memorizzando il file in un file di autorizzazione di 400 di proprietà di questo utente e eseguendo l'esecuzione binaria dell'automa con setuid bit ( link ) impostato sullo stesso account.
I.e., per un normale account utente quel file sarebbe leggibile solo attraverso quell'automa e non con altri mezzi.
Non credo che la crittografia aggiunga sicurezza se la memorizzazione della chiave di crittografia non è più sicura dell'archiviazione della password.
Se l'automa è un file binario e qui includi una chiave, devi assicurarti che sia eseguibile ma non leggibile. Se l'automa è uno script eseguibile, non è possibile memorizzare la chiave al suo interno in modo sicuro.
Questa è una sfida molto comune e può essere eseguita in modo sicuro se si è in grado di accettare un certo numero di compromessi di sicurezza in cambio dei vantaggi dell'automazione. Lo stiamo facendo comunque sempre, mantenendo le chiavi private TLS non crittografate sui server web per evitare di digitare passphrase ogni volta che riavviamolo :) Basta usare tutti i controlli di sicurezza disponibili disponibili in un sistema multiutente, come suggerito da Peteris sopra e vorrei aggiungere solo due cose: