Secure data transmission and storage

Il modo migliore per rispondere alla tua domanda è probabilmente quello di assumere un consulente di sicurezza per eseguire una valutazione della sicurezza del tuo approccio. Sembra che tu non abbia molta conoscenza della sicurezza da solo, quindi probabilmente non sarai in una posizione ideale per rispondere alla domanda da solo.

Probabilmente non ci hai fornito abbastanza informazioni per permetterci di eseguire per te una valutazione approfondita della sicurezza. I rischi per la sicurezza del tuo approccio dipenderanno pesantemente da tutti i dettagli su come funziona il tuo sistema e su come è configurato e implementato. Ci sono molti dettagli che non menzioni, ma che sono rilevanti per la sicurezza.

Ecco alcuni esempi di rischi per la sicurezza che potrebbero essere rilevanti per te, a seconda della tua situazione specifica:

• Ingegneria sociale. Chiedere agli utenti di scaricare ed eseguire un programma eseguibile è un'idea dubbia, dal punto di vista della sicurezza. Addestra gli utenti a eseguire file eseguibili da siti Web non fidati, cioè li allena a comportarsi in modo non sicuro. Potresti non voler mai offrire loro un programma dannoso dal tuo sito, ma cosa succede se gli utenti visitano un altro sito e scaricano ed eseguono un programma? Se chiedi agli utenti di farlo regolarmente ogni volta che vogliono usare la tua applicazione, stai insegnando loro che questa pratica è OK.

• Attacchi man-in-the-middle. Non dici se il tuo sito utilizza HTTP o HTTPS (ad esempio, se utilizza la crittografia SSL / TLS). Se è accessibile tramite HTTP, è vulnerabile agli attacchi man-in-the-middle, come quelli possibili su Wifi aperto.

  La migliore difesa è garantire che il tuo sito utilizzi SSL in tutto il sito (dovrebbe essere accessibile solo tramite HTTPS, qualsiasi tentativo di visitare tramite HTTP dovrebbe immediatamente reindirizzare al sito HTTPS, altrimenti il tuo server non dovrebbe mai rispondere via HTTP). Dovresti anche abilitare Sicurezza del trasporto rigoroso HTTP sul tuo server, in modo che i client sappiano che dovrebbero connettersi solo tramite HTTPS.

• Controllo degli accessi. Non ci hai detto come limiti chi è in grado di caricare nuove versioni dell'applicazione sul tuo sito. Ovviamente, la sicurezza del sito è valida solo come protezione per quella funzionalità.

• Sicurezza del server. se qualcuno può hackerare il tuo server, può violare la sicurezza del tuo sito e dei tuoi clienti. Pertanto, è necessario bloccare il server, quindi non è in esecuzione nessun altro servizio oltre a quello necessario per questa applicazione. È necessario abilitare un firewall per garantire che nessuno dall'Internet pubblica possa raggiungere alcun servizio diverso dal servizio Web e possibilmente un server SSH ben protetto per l'accesso amministrativo. (Per SSH, consiglio di consentire solo l'accesso con chiave pubblica e di disabilitare l'autenticazione tramite password.)

• Sicurezza del software. Dovrai assicurarti che non ci siano vulnerabilità nel tuo software personalizzato. Ciò significa che è importante che gli sviluppatori siano addestrati nello sviluppo di software sicuro. Potrebbero anche voler utilizzare strumenti di analisi statica o altro supporto per aiutare a cogliere eventuali bug di sicurezza che potrebbero passare.

• Aggiornamenti. È necessario assicurarsi di mantenere aggiornato il software con tutti gli aggiornamenti e le patch di sicurezza più recenti. Un modo per farlo è configurare Ubuntu per aggiornare automaticamente il suo software, ad esempio, verificando e installando automaticamente gli aggiornamenti una volta al giorno o una volta alla settimana.

In generale, non è probabile che tu abbia una risposta definitiva che "sei sicuro", così come non c'è alcuna garanzia che la prossima volta che attraverserai la strada non verrai colpito da un'auto. Invece, i professionisti della sicurezza identificano possibili rischi / minacce, valutano le attenuazioni / difese che hai messo in atto, valutano se il tuo sistema riduce il rischio a un livello accettabile e identificano per te alcune possibili misure che potresti intraprendere per ridurre il rischio se lo fai scegliere.

Oltre alla risposta di @ DW, è necessario essere consapevoli che un utente malintenzionato può decodificare il file eseguibile per verificare come gestisce la comunicazione con il server. Se ritieni che il file eseguibile possa inviare istruzioni valide, un utente malintenzionato potrebbe utilizzarlo maliziosamente creando istruzioni.

Sicuro contro chi?

Se l'attaccante previsto è una terza parte che può spiare la rete ed eventualmente alterare i dati in transito, allora la tua configurazione è sicura se (e solo se ) le connessioni tra il tuo server e il la macchina dell'utente è protetta con un protocollo appropriato, che è SSL / TLS (noto come "HTTPS" in un contesto Web) ). Ciò vale non solo per i canali tra l'applicazione sul computer dell'utente e i server, ma anche per la distribuzione dell'applicazione stessa; altrimenti, il cattivo potrebbe modificare il codice dell'applicazione in transito, ad es. aggiungere un carico utile dannoso che, una volta eseguito, registra tutto ciò che accade sulla macchina dell'utente. Se c'è un semplice HTTP ovunque nel tuo setup, hai perso. Con HTTPS, cercheresti è fattibile (hai ancora bisogno di farlo bene, e non è facile, vedi la risposta di D.W.).

Se l'attaccante previsto è l'utente stesso , allora sei condannato. Non può esserci codice affidabile che funzioni sul sistema dell'utente stesso. Gli editori di videogiochi hanno cercato di farlo per anni e ripetutamente fallito; (limitato) il successo è stato raggiunto solo quando il sistema dell'utente è chiuso (cioè non è un PC, ma una console di gioco che rifiuta categoricamente, a livello intimamente hardware, di eseguire qualsiasi pezzo di codice che non sia stato debitamente autorizzato attraverso le firme digitali ).