Cancellazione / crittografia del file temporaneo

2

Sto lavorando su un'app .net all'interno di aws. Fondamentalmente la nostra app ricava dati "generici" da un'altra organizzazione allo scopo di creare report personalizzati. I dati ci vengono inviati tramite ssl / tls e inviati allo stesso modo ... l'elaborazione è tutta eseguita in RAM. È solo quando i report devono entrare in formati specifici c'è un periodo di tempo in cui il file viene scritto sul disco locale e poi inviato indietro. Al termine del trasferimento, il file viene eliminato.

Ha più senso dal punto di vista della sicurezza / progettazione che alcuni programmi sovrascrivano questo spazio file, crittografano i dati localmente o su s3. L'accesso al di fuori di questa transazione a fini gestionali è strettamente controllato. Sembra che ci fosse un modo per forzare il file in un contenitore specifico, quindi fare in modo che un programma eseguisse una funzione di cancellazione sarebbe più semplice della crittografia?

Questo non è un dato classificato in termini di pci / hipaa, ecc. ma può contenere informazioni riservate sui clienti. Qualcosa del genere è davvero un grosso ostacolo anche dal punto di vista della sicurezza?

Altri pensieri?

    
posta Travis Howe 26.08.2013 - 22:24
fonte

3 risposte

3

Suppongo che tu abbia bisogno di un file temporaneo per alimentare un programma di formattazione esterno che offra solo un'interfaccia basata su file (forse qualcosa come Crystal Reports o Adobe Acrobat o altro).

Un approccio generale potrebbe essere quello di limitare la tua esposizione. È possibile montare il file temporaneo su una partizione o unità dedicata separata e limitare ulteriormente l'accesso. Se si mantiene la partizione temporanea il più piccola possibile, i settori eliminati saranno più rapidamente riassegnati e sovrascritti. Potresti usare una partizione criptata.

Ancora meglio, è possibile implementare il disco rigido dedicato con un disco RAM (noto anche come unità RAM) in modo che i byte non colpiscano mai effettivamente supporti di memorizzazione fisici durevoli. Un power-off o il riavvio della macchina assicurerà che sia stato cancellato.

    
risposta data 26.08.2013 - 22:46
fonte
1

La scrittura dei file sul posto è difficile e praticamente impossibile con i sistemi operativi attuali. Ecco il blocco di avvertenza dato dal venerabile comando shred:

CAUTION: Note that shred relies on a very important assumption: that the file system overwrites data in place. This is the traditional way to do things, but many modern file system designs do not satisfy this assumption. The following are examples of file systems on which shred is not effective: ...ext3...RAID−based file systems... NFS

fonte: link

Ci sono alcune cose che potresti fare per minimizzare la tua esposizione. Potresti:

Pulisci correttamente

Quando si utilizzano i file temporanei, molti programmatori commetteranno il seguente errore:

tmp_file = generate_tmp()    

do_something(tmp_file)  

rm -f tmp_file
exit

Questo purtroppo non garantisce la pulizia. Se do_something() esce dal tuo programma / script, il file temporaneo rimarrà attivo fino a quando non si ottiene una sorta di processo di pulizia.

L'approccio migliore è quello di utilizzare qualcosa come la trappola di BASH o Java finalmente per garantire i file temporanei vengono puliti correttamente in qualsiasi condizione. Quindi un approccio accettabile sarebbe qualcosa come:

tmp_file = generate_tmp()

try {
  do_something(tmp_file)
}
finally {
  rm -f tmp_file
}
exit

Scrivi nella memoria volatile

Come notato da John, scrivere i contenuti su un disco volatile come tmpfs / ramfs che verrebbe cancellato sul sistema shut / powerdown. Sebbene questo sia ovviamente limitato dalla dimensione della RAM, nel qual caso si potrebbe anche fare tutta la generazione / elaborazione in memoria.

    
risposta data 26.08.2013 - 23:46
fonte
0

È difficile dire quale sistema operativo si sta utilizzando, forse è UNIX o Linux.

Supponendo che lo stai facendo, puoi immediatamente open() di un file temporaneo, quindi remove() esso. Rimane aperto per la durata del processo che ha aperto il file. O fino a quando quel pocess chiama esplicitamente close() sul descrittore del file. I socket UDP trasferiranno i descrittori di file tra i processi. Il descrittore trasferito è valido per entrambi i processi.

Dato che la tua domanda è un po 'vaga, questo può essere completamente fuori base da ciò che è necessario. È tuttavia una vecchia e utile funzionalità di sicurezza.

Fare riferimento a Stevens & Rago 'Advanced Programming in UNIX Environment' o Michael Kerrisk 'L'interfaccia di programmazione Linux' Ci sono esempi rilevanti di tutto questo in entrambi i libri.

    
risposta data 27.08.2013 - 04:48
fonte

Leggi altre domande sui tag