Intro

Lavorando sui progetti presso Dojo4 sono spesso sorpreso di vedere come apparentemente piccoli aumenti nella complessità tecnica si sommano in significativi assorbimenti di attenzione e risorse. Di conseguenza, quando i progetti iniziano, tendiamo a preferire uno stack di hosting e applicazioni semplificato che condivide molte caratteristiche comunemente viste nei servizi di hosting condiviso. Questo include scelte come ospitare l'app e il database insieme, impiegare un singolo utente di deployment sul sistema di hosting e un semplice monitoraggio dell'uptime.

Recentemente, il nostro cliente di lunga data, Inspire Commerce, ha sviluppato un nuovo piano aziendale che richiede che la sua applicazione soddisfi i rigorosi requisiti di conformità di sicurezza di livello 1 del Payment Card Industry (PCI) per l'elaborazione, la trasmissione e la memorizzazione delle informazioni delle carte di credito. Molti dei requisiti di sicurezza dettagliati nello standard di Sicurezza dei Dati PCI (DSS) motivano un significativo cambiamento di mentalità rispetto allo stack focalizzato e semplificato menzionato sopra. Questo post elencherà brevemente alcuni di questi dettagli e delineerà le nostre soluzioni.

Lo standard PCI DSS è suddiviso in 12 sezioni che coprono tutto, dalla configurazione del firewall alle politiche di sicurezza del personale. Passerò in rassegna alcune delle sezioni pertinenti allo stack di hosting.

1. Installare e mantenere una configurazione del firewall per proteggere i dati dei titolari di carta

Questa è una sezione piuttosto dettagliata del DSS che impone l'installazione e la configurazione dei servizi firewall su tutti i dispositivi di rete, dalle stazioni di lavoro ai router ai server. Utilizzando Amazon Web Services (AWS) Elastic Compute Cloud (EC2) come base del nostro stack di hosting, molti di questi dispositivi di rete sono astratti dalla nostra vista o controllo. Convenientemente, AWS stesso è conforme al livello 1 PCI lasciando molti di questi dettagli agli ingegneri di Amazon.

Tuttavia, i firewall per i nodi EC2 stessi richiedono qualche considerazione. I nodi EC2 sono protetti da un firewall implementato a livello di hypervisor e configurato dai gruppi di sicurezza AWS. Il nostro gruppo di sicurezza di base ha tutte le porte che negano i pacchetti con l'eccezione delle porte 22, 80 e 443 che accettano da tutte le fonti. Eseguiamo Ubuntu Linux sui nostri nodi e di default hanno il firewall IP Tables configurato con una politica aperta.

Lo standard PCI DSS si concentra sull'utilizzo dei firewall per creare reti private sicure, o Zone Smilitarizzate (DMZ) per i sistemi che ospitano app che elaborano dati di carte di pagamento. I gruppi di sicurezza AWS forniscono un meccanismo utile per creare reti private sicure tra i vari componenti dello stack dell'applicazione. Ad esempio, creando un gruppo di sicurezza WEB e un gruppo di sicurezza DB e aprendo la porta del database nel gruppo di sicurezza DB solo alle fonti del gruppo di sicurezza WEB, il firewall dell'hypervisor EC2 in esecuzione su un server di database consentirà l'accesso al database solo dai server web che si collegano sull'interfaccia della rete privata interna.

Per la ridondanza, specchiamo la configurazione del gruppo di sicurezza AWS per il firewall dell'hypervisor EC2 con il servizio CloudPassage che è in grado di gestire il firewall IP Tables a livello di sistema operativo dei sistemi che ospitano componenti dell'applicazione di elaborazione delle carte. CloudPassage organizza le politiche del firewall in Gruppi di Server che sono in qualche modo analoghi ai gruppi di sicurezza AWS. Un'altra ottima funzionalità di CloudPassage è il servizio GhostPorts. Configuriamo la politica della porta ssh in CloudPassage per accettare connessioni dalle fonti GhostPort. Affinché una macchina client diventi una fonte GhostPort, un utente su quella macchina deve autenticarsi al portale CloudPassage, essere autorizzato ad aprire GhostPort per un gruppo di server e autenticarsi con una chiavetta Yubikey registrata o rispondere a una sfida SMS con un telefono cellulare registrato. Dopo un'autenticazione e autorizzazione di successo, CloudPassage configura IP Tables per accettare connessioni dall'indirizzo IP sorgente della macchina client. Questo è un modo conveniente, sicuro, temporaneo e verificabile per gestire l'accesso agli host sensibili.

2. Non utilizzare le impostazioni predefinite del fornitore per le password di sistema e altri parametri di sicurezza

Questa sezione sembrerebbe piuttosto ovvia. Un buon esempio dell'importanza di cambiare la password predefinita del fornitore è la password predefinita Splunk Universal Forwarder di changeme.

Tuttavia, sepolta in questa sezione c'è un requisito di hosting piuttosto importante non correlato al titolo della sezione. "2.2.1 Implementare solo una funzione primaria per server per impedire che funzioni che richiedono diversi livelli di sicurezza coesistano sullo stesso server. (Ad esempio, i server web, i server di database e il DNS dovrebbero essere implementati su server separati)".

Come menzionato sopra, i gruppi di sicurezza AWS rendono il compito di separare in modo sicuro servizi come server web e server di database su host diversi piuttosto semplice.

5. Utilizzare e aggiornare regolarmente software o programmi antivirus

ClamAV rende questo requisito semplice su Ubuntu Linux.

8. Assegnare un ID univoco a ciascuna persona con accesso al computer

L'intento di questa sezione è facilitare la verificabilità e la responsabilità eliminando gli account utente condivisi. Poiché utilizziamo un meccanismo di autenticazione basato su chiave per l'accesso secure shell, ci sono tre problemi principali per sapere chi ha fatto cosa. In primo luogo, è necessario impedire agli utenti di poter passare a un altro account utente con il comando su. Questo si ottiene facilmente rimuovendo il permesso di esecuzione sul binario su e modificare /etc/pam.d per impedire tutte le autorizzazioni su. In secondo luogo, assicurarsi che i file authorized_keys per tutti gli account utente contengano solo una singola voce. Infine, assicurarsi che tutte le chiavi utilizzate per l'accesso secure shell siano protette da password e che sia in atto una politica che vieti la condivisione delle chiavi tra gli utenti.

Ora, il Linux Audit Daemon (AuditD) può essere utilizzato per tracciare l'attività del sistema a utenti specifici.

9. Limitare l'accesso fisico ai dati dei titolari di carta

Il titolo di questa sezione è piuttosto autoesplicativo. In sostanza, questa sezione tratta gli argomenti di limitare l'accesso fisico al data center a personale autorizzato. Simile alla discussione sulla configurazione del firewall dei dispositivi di rete sopra, questo è coperto dalla certificazione PCI di livello 1 di AWS e i dettagli possono essere lasciati ad Amazon.

10. Tracciare e monitorare tutti gli accessi alle risorse di rete e ai dati dei titolari di carta

La motivazione di questa sezione è "prevenire, rilevare o minimizzare l'impatto di una compromissione dei dati". Questo comporta argomenti come il logging, la gestione dell'integrità dei file e il rilevamento delle intrusioni. La nostra strategia inizia con l'impiego di un servizio di logging per supportare l'aggregazione dei log, la conservazione dei log, nonché la ricerca dei record di log. Utilizziamo l'applicazione Splunk per questa funzionalità. Abbiamo configurato un'istanza EC2 per un server di logging e installato Splunk. Abbiamo configurato i gruppi di sicurezza AWS e CloudPassage ServerGroups per il nuovo server che ha la porta del listener Splunk che accetta connessioni dalle fonti del server web e del server db sull'interfaccia della rete privata. Successivamente abbiamo configurato Splunk Universal Forwarder sui server web e db e configurato i forwarder per monitorare i log dell'applicazione, apache, mongodb, sys, audit e auth.

Per il monitoraggio dell'integrità dei file e il rilevamento delle intrusioni abbiamo installato l'applicazione OSSEC su tutti i nostri server e aggiunto tutti i log che OSSEC scrive ai forwarder Splunk.