Drupal Security e due DB

No. Sospetto che questa difesa non sia probabilmente un buon uso del tuo tempo.

Se non avessi i link, le informazioni sarebbero difficili da usare per te - difficile da usare per i bravi ragazzi. Ciò è negativo per l'usabilità, perché le informazioni non sono facili da usare, probabilmente non sono di grande utilità per molti dei tuoi utenti. Ma i cattivi non sono sotto questi limiti. Probabilmente i cattivi potrebbero comunque ottenere molte informazioni sensibili e mettere insieme le cose abbastanza per darti una brutta giornata.

Ti ricordi la storia degli studenti rivoluzionari iraniani che hanno preso d'assalto l'ambasciata degli Stati Uniti in Iran? Gli abitanti degli Stati Uniti hanno distrutto molti dei loro documenti prima di evacuare, ma gli studenti iraniani erano ancora in grado di ricostruire meticolosamente i frammenti di documenti triturati in un tutto, come un puzzle. Avevano il tempo e la pazienza per farlo. Quei documenti tagliuzzati sarebbero stati praticamente inutili per un diplomatico autorizzato legittimo degli Stati Uniti, ma erano sufficienti per gli aggressori a elaborare un sacco di informazioni sensibili che gli Stati Uniti non volevano che fossero. La sicurezza è spesso così; i cattivi sono disposti a impegnarsi di più per recuperare i tuoi dati rispetto a qualsiasi altro utente del tuo sito.

E in ogni caso, se il tuo sito viene violato, vuoi essere in grado di dire alla stampa "Oh, sì, hanno preso tutti i dati, ma non hanno ricevuto i link , quindi va tutto bene? " Non sembra il tipo di cosa che ispirerà fiducia tra i tuoi clienti. Non è una bella immagine.

Quindi, ti suggerisco di spendere le tue energie altrove. Ricorda, la sicurezza è uno sforzo di gestione del rischio. Ciò significa che devi dare la priorità a dove trascorri il tuo tempo, in base a ciò che ti offre il massimo vantaggio in termini di sicurezza per il minor tempo, energia e costi. Non penso che questa difesa sia buona. Invece, mi concentrerei sulle basi, cose come la sicurezza delle applicazioni (SDL), la gestione della configurazione, la sicurezza della rete, la preparazione e il ripristino di emergenza, l'istruzione interna e così via. La maggior parte delle organizzazioni ha molto spazio per migliorare, anche sulle basi.

Provocherebbe un colpo alle prestazioni. Inoltre, dipende da ciò che ti preoccupa di aver rubato. È possibile che anche se lo fai, un utente malintenzionato potrebbe comunque essere in grado di acquisire il tuo elenco clienti e potenzialmente le informazioni di pagamento se lo stai archiviando.

Anche se i dati non sono utili nella tua applicazione senza una chiave di relazione, un utente malintenzionato sarebbe probabilmente abbastanza contento dei dati non correlati se tali dati sono coerenti in alcun modo.

Considerando tale minaccia come 0 giorni, è assolutamente pazzesco, assicurarsi che quando il sito è compromesso, il database principale non venga rubato. Inoltre non ti esponi come Mat Honan con il tuo indirizzo e hai enormi problemi di sicurezza, rivelando il buco e fornendo l'indirizzo del tuo sito web.

Questo può essere implementato sulla base del server di autenticazione esterno che medierà la sicurezza tra il server principale ei nodi.

Se potessi descrivere in dettaglio più tecnici cosa stai facendo, potrei fare un esempio.

Il server di autenticazione utilizza tutti i meccanismi di sicurezza e ha una capacità limitata di servire solo come servizio di recupero password e autenticazione, quindi non è esposto agli exploit remoti Drupal più comuni. Inoltre ha le password crittografate e così via. Inoltre, non è esposto a Internet e ha filtri più rigidi. In questo modo, nessuno dei siti / database dovrebbe essere tecnicamente in grado di fornire all'utente alcun dato prima di autenticarsi e servire solo i dati a cui si ha accesso, tramite API, accesso diretto al DB o classi OO. Ciò richiede talvolta aggiornamenti anche a DB e al codice, come schemi e controlli di sicurezza, ma prima è bene assicurarsi che la password di root di MySQL o qualsiasi altra cosa non sia utilizzata da nessuna parte, e che l'accesso di amministratore sia cambiato in qualcos'altro, anche la pagina di amministrazione e di accesso è disponibile solo con FQDN e il back-end è accessibile tramite link nascosto (quindi non è visibile dal maggior numero di scanner).