CISecurity AMI EC2 Amazon

Question

CISecurity AMI EC2 Amazon

#1 da (1 voti)
#2 da (0 voti)

1

Stiamo passando ad Amazon dalla nostra infrastruttura on-premise e sto cercando di seguire questo documento per aumentare la nostra sicurezza delle istanze di ec2: CISecurity Benchmark per Amazon Linux

Nel documento, viene chiesto di creare 6 partizioni differenti per: - / tmp - / var - / var / tmp - / var / log - / var / log / audit - / home

Voglio dire, la creazione di quelle partizioni separate aumenta davvero la sicurezza? Dal momento che il costo per me sembra aumentare in modo significativo il costo di ogni istanza aggiungendo 6 diversi volumi EBS per quelle partizioni ...

Grazie per la tua condivisione delle conoscenze.

audit amazon content-security-policy

posta metalraiden 18.11.2016 - 23:59

fonte

2 risposte

Leggi altre domande sui tag audit amazon content-security-policy

TLS handshake proof of private key posession [chiuso] L'html è sufficiente per mitigare xss nell'attributo html se il valore è racchiuso tra virgolette doppie

score 1 · Answer 1

Questa è una minaccia a basso rischio e potresti ignorarla nella maggior parte dei casi.

Detto questo, il documento spiega la logica alla base della garanzia che esistano partizioni separate per ciascuno dei punti di mount specificati. Poiché sono scrivibili in tutto il mondo, si corre il rischio di esaurimento delle risorse senza vincoli di punti di montaggio su una partizione separata. Inoltre, separando le partizioni è possibile impostare un flag noexec sui montaggi che non dovrebbero contenere file eseguibili. Infine, semplifica il ridimensionamento sul cloud.

Infine, non sono necessari 6 volumi EBS separati; /tmp potrebbe essere montato usando ramdisk; potresti avere più partizioni per lo stesso volume fisico.

score 0 · Answer 2

Come ha detto Jedi , si tratta di una minaccia a basso rischio. Non hai bisogno di volumi separati quanto di partizioni separate ma con opzioni di mount point appropriate (di nuovo come ha detto Jedi), ad esempio noexec o ro . Ho visto casi in cui inodes nella partizione root era esaurito a causa della generazione di un numero elevato di file e questo ha portato il server inattivo perché non si poteva scrivere più nulla sul disco.

A meno che tu consideri /tmp come effimero (dovresti), es. non hai bisogno di nessuno dei dati in /tmp per il riavvio dell'istanza persistente, non dovresti montarlo come ramdisk.

E c'è sempre LVM .