Limitazione dell'esposizione del codice sorgente

0

Supponiamo che non ti fidi dei tecnici del data center (o del management) ma non hai altra scelta che ospitare la tua applicazione web con loro.

Inoltre, supponiamo che tu voglia mantenere certi file inaccessibili alle persone che hanno accesso al server in una capacità on-rack (live) e fuori rack (disattivata).

Domanda
Quanto sarebbe efficace la seguente installazione nel proteggere il codice sorgente e altri file sensibili?

Metodo di protezione:

Presumi l'applicazione utilizza lo stack seguente: LEMP + Redis + Node (Websocket)

A. Configurazione una sola volta

  1. Disabilita l'avvio automatico di Nginx, Redis e MySQL
  2. Crea una directory root per una partizione RAMDISK: %codice%
  3. Cambia la directory dei dati di MySQL a mkdir -p /media/private

B. Dopo ogni riavvio

  1. Crea e monta una partizione RAMDISK:
    /media/private/mysql
  2. Crea sottodirectory richieste in mount -t tmpfs -o size=2048M tmpfs /media/private/
  3. Carica i file di dati MySQL, il file di configurazione Nginx, i file cert SSL, il file di configurazione Redis, i file di origine PHP e i file di app del nodo nella directory appropriata in /media/private
  4. Avvia server Redis con configurazione personalizzata
  5. Avvia il server MySQL
  6. Avvia Nginx con configurazione personalizzata
posta Majid Fouladpour 26.07.2018 - 19:01
fonte

2 risposte

0

[Continuo a ritenere la mia risposta alla verifica dei frame vale, quindi sto postando una seconda risposta rispondendo al chiarimento nei commenti]

Se comprendo correttamente la tua domanda;

Obiettivo di sicurezza: impedisce a un utente con accesso fisico al server (durante l'esecuzione o se spento) di accedere a qualsiasi file all'interno del sistema operativo.

Soluzione proposta: non memorizzare nulla su disco. Al boot, crea un ramdisk e carica tutti i file sensibili direttamente in ramdisk.

(corretto finora?)

Innanzitutto, stai introducendo un massiccio punto singolo di errore in quel caricamento collettivo dopo il riavvio. Come è assicurato? Da dove provengono i file? Quali indurimenti e pratiche di sicurezza sono su quella macchina? Un utente malintenzionato può bloccare il caricamento sul server DoS? ecc ecc.

Successivamente, la soluzione potrebbe proteggere dalle informazioni sensibili che finiscono nelle immagini del disco, ma perché eseguire il rollover anziché utilizzare soluzioni standard a questo problema, come la crittografia a disco intero? Il provider cloud offrirà la crittografia a riposo che si interfaccia con il loro sistema di gestione delle chiavi ( AWS per esempio ), e / o abilitare la crittografia del disco a livello del kernel Linux richiede una password all'avvio.

Infine, la tua soluzione non protegge dai dump della memoria (magari tramite accesso fisico come attacco di avvio a freddo , prendendo un live snapshot / memoria dump tramite l'hypervisor, altri?). Ancora una volta, non eseguire il rollover, ma forse esaminare la crittografia della memoria?

risposta data 26.07.2018 - 21:49
fonte
0

Penso che tu stia andando indietro a questo proposito; stai delineando una soluzione e ti stai chiedendo se è sicura contro le persone "con accesso al server", ma non ci hai detto a quale livello di "sicurezza" stai puntando.

Srotoliamo quello; sicuro contro cosa? Quali livelli di accesso stai cercando di bloccare, e a che punto sei disposto a lasciarlo andare?

  • Proteggere dagli amministratori di rete che colpiscono le porte della VM? Probabilmente lo hai già fatto.
  • Proteggere dagli amministratori di sistema che possono accedere all'immagine del disco della VM? Ciò può essere d'aiuto, anche se potrebbero esserci più soluzioni disponibili, come fornire una password di crittografia del disco completo all'avvio.
  • Proteggere dagli amministratori di sistema che possono ottenere chiavi ssh sulla tua VM? Questo probabilmente non aiuta.
  • Proteggere dagli amministratori di sistema che possono eseguire i dump di memoria diretti della VM in esecuzione? Questo probabilmente non aiuta, sebbene tu possa esaminare la crittografia della memoria.
  • Proteggere dai dipendenti del data center che possono strappare le RAM dalla macchina e immergerle in azoto liquido in un attacco a freddo ? Questo probabilmente non aiuta, sebbene tu possa esaminare la crittografia della memoria.

Quindi ti suggerisco di farlo in un altro modo: definisci il livello di sicurezza desiderato e poi progetta una soluzione che lo raggiunga.

[scusa per aver dato una non risposta, ma sento che questo richiede un frame-challenge ]

    
risposta data 26.07.2018 - 20:37
fonte

Leggi altre domande sui tag