Archiviazione sicura in un ambiente di hosting condiviso semi-affidabile

5

Sto cercando un pattern per memorizzare un file di configurazione contenente informazioni sensibili in un ambiente di hosting semi-trusted. Semi-fidato in questo caso significa che mi fido di loro in generale, ma non con queste informazioni (password).

In questo caso sto scrivendo un semplice demone per guardare una cartella per le modifiche e spingere quelle modifiche a un database ospitato da qualche altra parte. Preferirei non archiviare i dettagli di quel database in testo in chiaro in questo ambiente semi-fidato, perché non sono sicuro che gli amministratori potrebbero usarlo maliziosamente.

Il mio piano originale consisteva nell'impostare gli script di reporting necessari nel mio ambiente non attendibile e quindi eseguirli in remoto da una posizione attendibile, inviando vali di configurazione ad ogni esecuzione. Tuttavia sembra che registrino tutti i comandi eseguiti sui loro server, quindi questo è un no go in quanto potrebbero semplicemente rivedere quei log.

In alternativa potrei avere un secondo livello di database, le cui credenziali sono memorizzate sul loro server. Questo database agisce come una via di mezzo, consentendo a un set di script in un ambiente non affidabile di inviare dati ad esso e un altro set di script in un ambiente di fiducia per estrarre i dati da esso e spostarli nella destinazione finale. Sono meno preoccupato per loro che corrompono i dati dannosamente e se accedono a questo database non è un grosso problema in quanto è completamente separato dal mio archivio dati principale.

Questo metodo è piuttosto ingombrante e non esattamente sicuro, quindi preferirei evitarlo se possibile.

Sfortunatamente allontanarsi da questo ambiente non affidabile non è un'opzione.

    
posta William King 22.05.2013 - 04:32
fonte

3 risposte

4

Se sei preoccupato che gli amministratori stiano attivamente ficcanasando sulla tua applicazione, non c'è niente che tu possa fare se non utilizzare mai il loro sistema con dati sensibili. Possono fare anche tutto ciò che fa il programma per decifrare o recuperare le credenziali. Per lo stesso motivo, devi fidarti di loro per non consentire l'accesso amministrativo al loro sistema a terze parti inaffidabili.

Un'area in cui vi è spazio per mitigare i rischi è il tempo di reazione in caso di violazione. È difficile dare un consiglio generale perché questo è un compromesso tra disponibilità e riservatezza - se accade qualcosa di "strano", vuoi abbattere il sistema il più rapidamente possibile (e inviarti una pagina per ordinare tutto il casino prima del servizio? può essere ripristinato), o vuoi continuare a correre il più a lungo possibile e informarti che qualcosa potrebbe essere sbagliato? Tieni presente che, anche con il massimo sforzo, non puoi mai essere sicuro che una violazione non avvenga inosservata.

È possibile ridurre leggermente il rischio memorizzando le credenziali in remoto e recuperandole su ciascuna connessione oa brevi intervalli. Per risultati migliori, utilizzare una password che cambia automaticamente ogni pochi minuti. In questo modo, se il server viene compromesso ma l'autore dell'attacco non si trova inizialmente dopo la tua applicazione, potresti avere un po 'di tempo di reazione quando puoi decidere se chiudere il servizio - basta disattivare l'accesso alle credenziali. Questo non è infallibile; se l'attaccante si trova dopo l'applicazione, inizierà a utilizzare le credenziali prima di poter reagire. In ogni caso, assicurati di poter cambiare rapidamente le credenziali prima di interrompere qualsiasi altra cosa (quindi nessuna password condivisa che deve essere cambiata in 20 diversi posti).

Un altro modo per mitigare i rischi è dare a questo sistema semi-fidato il minor numero possibile di privilegi. Nella tua situazione, il sistema semi-attendibile deve solo trasferire le modifiche in un database da qualche altra parte, quindi non dare al sistema semi-fidato alcuna credenziale che gli consenta di accedere direttamente al database. Dare solo il permesso di aggiungere record a una tabella, o alcuni di questi. Utilizzare un'applicazione proxy (in esecuzione in un ambiente completamente affidabile) piuttosto che l'accesso diretto al database per eseguire questo controllo di autorizzazione e fare in modo che registri tutto ciò che fa. In questo modo, se il sistema semi-attendibile è compromesso, potresti finire con documenti falsi (insieme a un timestamp e forse altre informazioni che potrebbero permetterti di ordinare i buoni record da quelli falsi) ma tutto ciò che non deriva da questi i record saranno comunque al sicuro.

    
risposta data 26.05.2013 - 13:34
fonte
1

Non perdere tempo con questo. Non c'è niente che puoi fare. Stai mettendo i tuoi dati su un server che non è tuo e chi gestisce questo server può avere accesso ai tuoi dati.

Supponiamo che tu abbia trovato il modo migliore per archiviare le credenziali del database in modo sicuro. L'amministratore del tuo server ha un account DBA che può comunque accedere al tuo database. Nulla di ciò che risolverà, nemmeno un VPS (Virtual Private Server). Quindi, ecco le opzioni:

  • Ottieni una connessione ad alta velocità e hardware di livello server e crea il tuo server a casa, in ufficio o in qualsiasi posizione attendibile.

  • Registrati con un host web ben controllato e affidabile.

risposta data 22.05.2013 - 08:46
fonte
0

Se il sito può accedervi, gli amministratori possono accedervi. Se volessero, potrebbero semplicemente modificare il tuo sito web per visualizzare le informazioni di configurazione. Non è possibile proteggerlo se il sito deve accedervi. L'unica alternativa è passare a un ambiente fidato. I Virtual Private Server sono piuttosto economici in questi giorni.

    
risposta data 22.05.2013 - 05:55
fonte

Leggi altre domande sui tag