Livello database

L'approccio multi-schema è OK ma come sempre il diavolo è nei dettagli.

Una tecnica di isolamento importante che è sottostimata è costituita da schemi separati per il proprietario dei dati e per l'accesso all'app Web.

• Ciò riduce l'impatto di qualsiasi compromesso utilizzando il privilegio minimo, eliminando i diritti specifici dell'utente del database di connessione per distruggere realmente il database (non è possibile eliminare tabelle o visualizzare dati nascosti).
• Consente all'applicazione di nascondere i dati (dietro pacchetti o viste).
• Puoi utilizzare i sinonimi per eseguire la mappatura tra gli utenti di app web e gli schemi proprietari di tabelle.

Un esempio di installazione per iniziare.

Data Owner:   MYCLIENT_OWNER
Web User:     MYCLIENT_USER  <- Django points to this schema
Synonyms:     MYCLIENT_USER.TABLE1 -> MYCLIENT_OWNER.TABLE1 (for all required tables)
Grants:       MYCLIENT_USER Granted Select, Insert, Update Delete as appropriate.
Packages:     MYCLIENT_USER Synonyms/Grants for required Packages, Functions and Procedures.

Livello di autenticazione

L'autenticazione degli utenti può essere isolata in un server sso / ldap.

• Riduce l'impatto di un compromesso della tua web-app.
• L'area della superficie del servizio di autenticazione è molto più piccola dell'intero sistema.
• Ma come sempre è più complicato e solitamente più costoso (anche se solo per il tempo di setup).

Codifica simmetrica

Ho sentito che la memorizzazione delle chiavi del portafoglio al di fuori del database è la migliore pratica qui, ma un'alternativa è quella di nascondere i dati dietro le funzioni come sopra.

Ho il sospetto che un servizio di crittografia su una scatola diversa potrebbe essere una buona alternativa, ma non ho mai visto questo disegno usato prima.

Anche se questa è solo una risposta parziale alla tua domanda, puoi usare l'integrazione selinux con postgresql e apache per eseguire il servizio su un dominio diverso (cioè l'equivalente dell'utente in selinux lingo, in modo rude) e impedire l'accesso ai dati ( a livello postgresql, per database) da un'istanza del servizio in esecuzione su apache con un dominio diverso.

Un altro semplice passo sarebbe eseguire diversi processi, uno per ogni inquilino. È possibile ottenere questo risultato con wsgi e assicurarsi che ogni processo sia separato. In questo modo, puoi avere 1 database per inquilino e non condividere la password affatto.

Esistono varie misure di isolamento, come lxc, vserver, vm che potrebbero essere utilizzate per limitare tutto e le comunicazioni tra titolare, ma potrebbe essere eccessivo, quindi dipende da te.

Inoltre, per il certificato con caratteri jolly, è IMHO da evitare in quanto se qualcuno ruba il certificato, questa persona sarebbe in grado di spiare il traffico di altri tenant (dato che hanno la chiave privata nel certificato). Senza un certificato con caratteri jolly, qualcuno può solo spiare 1 sito web.

Per i certificati SSL: i certificati jolly hanno diversi problemi, il più importante dei quali è che tendono ad essere costosi. In effetti, il modello di business della maggior parte delle CA esistenti è la vendita di certificati. Un certificato con caratteri jolly è un certificato che consente di acquistare certificati meno dalla CA, pertanto la CA non gli piace e tenterà di recuperare tali perdite valutando di conseguenza il certificato con caratteri jolly. Inoltre, i certificati jolly generici non sono consentiti dal browser (anche se trovi una CA che accetta di venderti un certificato " *.com ", i browser Web non lo accetteranno).

Viceversa, i certificati pensati per un singolo nome host non jolly possono essere economici, anche così economici da essere considerati come leader della perdita di qualche CA. Ad esempio, StartSSL fornisce gratuitamente certificati SSL di base.

Un punto correlato riguarda la gestione IP. Condividere lo stesso IP tra due server SSL, che hanno lo scopo di utilizzare nomi distinti, è ancora difficile: il server deve indovinare il nome con cui viene contattato, in modo da inviare il certificato giusto. Questo può essere fatto con SNI , che sfortunatamente non è supportato da IE su WinXP (che è ancora una configurazione comune). Il certificato con caratteri jolly può o non può aiutarti, a seconda dei nomi di dominio che desideri supportare (poiché i browser rifiutano caratteri jolly troppo generici). Probabilmente dovrai acquistare qualche IP in più e il costo di questi IP potrebbe superare quello dei certificati.