Quanto è sicuro questa architettura?

Question

Sto costruendo un sistema che ha bisogno di raccogliere alcuni dati sensibili degli utenti tramite connessione web protetta, memorizzare in modo sicuro sul server per una successiva decodifica automatizzato e il riutilizzo. Sistema dovrebbe inoltre consentire all'utente di visualizzare una parte dei dati protetti (per esempio, *****ze) e / o cambiare completamente via web. Il sistema dovrebbe fornire una ragionevole livello di sicurezza.

pensavo seguenti infrastrutture:

App (Web) Server 1

1. Web server con adeguato supporto TLS per connessioni web protette.

2. Utilizzare l'algoritmo a chiave pubblica (ad esempio RSA) per crittografare i dati sensibili immessi dall'utente e inviarlo a App Server 2 via unidirezionale in uscita fissata canale (Esempio ssh-2) senza memorizzarlo ovunque su entrambi i App Server 1 o DB Server 1 .

3. L'utilizzo user-password dipendente a chiave simmetrica algoritmo per crittografare una parte dei dati immessi (ad esempio ultime lettere / cifre) e negozio sul DB Server 1 per dopo il recupero da App Server 1 durante sessione utente web.

4. Riutilizzo passaggio 2 per la modifica dei dati da parte dell'utente via web.

DB Server 1

1. archivio utenti non sensibili non garantito i dati.
2. Conservare una certa parte del sensibile dati utente crittografati su App Server 1 (Vedi sopra il punto 3)

App Server 2

1. Do non EVER inviare nulla a App Server 1 o DB Server 1 .
2. Ricevere utente crittografato sensibili i dati da App Server 1 e conservarla in DB Server 2 .
3. Recupera crittografato i dati sensibili degli utenti da DB Server 2 secondo i programmi locali, decifrare usando la chiave privata (Vedi App Server 1 , punto 2) memorizzati localmente su App Server 2 con una corretta gestione delle chiavi.

DB Server 2

dati sensibili
1. Conservare criptato utenti (vedere la App Server 2 , punto 2)

Se uno App (Web) Server 1 o DB Server 1 o di entrambi sono infetto per poi attaccante non sarà in grado di ottenere tutti i dati sensibili degli utenti (sia criptati o meno ). Tutti attaccante avrà l'accesso ad algoritmi a chiave pubblica e crittografia che sono ben noti in ogni caso. L'attaccante sarà comunque in grado di modificare web-server per ottenere attualmente connesso le password degli utenti in chiaro e decifrare parte di utenti dati sensibili memorizzati nel DB Server 1 (vedi App Server 1 , punto 3), che I don' t considerano come un grande affare. L'attaccante sarà in grado di (tramite la modifica del codice) i dati sensibili degli utenti anche intercettare inseriti dagli utenti via web durante potenziale attacco. Più tardi mi considero un rischio più elevato, ma a condizione che sia difficile (è?) Per l'utente malintenzionato di modificare il codice senza che qualcuno ne accorga Credo che non dovrebbero preoccuparsi molto su di esso.

Se App Server 2 e la chiave privata sono infetto per poi aggressore avrà accesso a tutto, ma App Server 2 o DB Server 2 sono non web rivolto quindi non dovrebbe essere un problema.

Quanto è sicuro questa architettura? È la mia comprensione di come gli algoritmi di crittografia e protocolli protetti funzionano correttamente?

Grazie!

Answer 1

Non credo che posso dare una risposta adeguata, perché non sono sicuro l'obiettivo del sistema è evidente. Mentre apprezzo voi ottenere un feedback su un progetto, è un po 'difficile senza uno scopo.

Vorrei suggerire a voi questa però:

Fortemente documentare e analizzare il modello di minaccia prima

Hai bisogno di venire con un elenco fisso hard-foderato di tutti i possibili scenari di attacco. attaccanti locali, ecc, che stai cercando di proteggere? È anche dire cose come 'con una corretta gestione delle chiavi'; ma questa è una delle cose più difficili da fare. Quindi non solo assumere è possibile ottenere questo diritto; completamente pianificare come si farà questo, con collegamento specifico per chi impedirà attacchi da parte.

Il motivo è necessario fare un modello di minaccia, è che sarà necessario per determinare su quali angoli sarete vulnerabili; perché questo sarà il caso.

Vorrei anche suggerire che, mentre la teoria è buono; in crypto applicazione è anche molto critico. Non basta supporre che farete le cose correttamente, si ha realmente bisogno di prendersi cura di dove numeri casuali vengono, e altre cose del genere.

So che questo è un po 'vago, ma penso che almeno fino a venire con modello formale e forte minaccia, sarà molto utile per voi.

Answer 2

Fin qui tutto bene. Siete sulla buona strada per un'architettura molto sicuro. Ci sono altre preoccupazioni, come firewall, politiche di password, la registrazione, monitoraggio e allerta di prendere in considerazione, ma tutto quello che finora descritte è molto solido. Se i dati sono abbastanza sensibile, prendere in considerazione un terzo di audit di parte della vostra sicurezza.

Answer 3

non mi consiglia di utilizzare qualsiasi forma di chiave pubblica per comunicare dal server web al vostro application server. Se controlli sia il sistema solo un sistema segreto regolare di crittografia. Si conosce l'identità del server app, in modo da mantenere la chiave di sicuro non è un problema. Se hai bisogno di cambiare o aggiornare la chiave segreta solo fare manualmente per evitare che si perde attraverso una connessione.

Quello che mi sarei molto attenti è la direzione di trasferimento dei dati dal server in DMZ, che dovrebbe essere solo il vostro server web, a quelle scatole che risiedono internamente alla rete. Sta diventando sempre più comune per i domini legittimi per essere compromessa per distribuire malware per gli utenti che visitano. Cioè male, ma se il malware dovesse trasformare in corsia alla vostra rete, invece di solo verso l'esterno per gli utenti allora il vostro business sarebbe completamente hosed.

Anche io non ho visto niente su come prevenire SQL injection o indurimento del sistema / patch per prevenire la distribuzione di malware. Questo dovrebbe essere il primo e più importante considerazione. Se la sicurezza fosse importante per voi, allora si sarebbe l'architettura di essere flessibile per minori personalizzazioni di comunicazione inter-server e patch frequenti. La maggior parte dei siti web, anche le grandi imprese legittime, non risolvono i loro buchi di sicurezza anche se sono compromesse. È necessario essere continuamente fori di fissaggio di sicurezza e di cambiare le cose per impedire fori dal sorgere se si vuole evitare di essere compromessa, in primo luogo.

Per evitare di diventare un distributore di malware vorrei suggerire fare regole dure e veloci su come i media è servito che contiene qualsiasi tipo di scripting lato client. scripting lato client può essere trovato in JavaScript, ActiveX, Flash, Acrobat, Silverlight, e altro codice o plugin che esegue sul sistema client. Condizioni per servire tale contenuto deve esistere affinché anomali frammenti di codice possono essere immediatamente identificati. La mia raccomandazione è di Mai embed sul lato client codice direttamente in un browser, ma il riferimento sempre qualche file esterno. Vorrei anche suggerire conslidating come supporti di mentalità per dare un migliore controllo degli asset e di risparmiare larghezza di banda, come ad esempio servire un unico grande file JavaScript, invece di 8 piccoli. Auspico inoltre costringendo tutti questi mezzi di comunicazione su un sistema di distribuzione di contenuti esterni che fa riferimento il dominio nella sua struttura di directory. Quella media modo non è servita dai server direttamente e se servita da voi direttamente si può rapidamente identificare come potenzialmente dannoso e necessittating controlli di sicurezza.