{"id":248621,"date":"2022-05-21T16:09:00","date_gmt":"2022-05-21T13:09:00","guid":{"rendered":"https:\/\/vpn.inform.click\/?p=248621"},"modified":"2023-06-19T03:59:33","modified_gmt":"2023-06-19T00:59:33","slug":"i-container-sono-ovunque-come-li-proteggi","status":"publish","type":"post","link":"https:\/\/vpn.inform.click\/it\/i-container-sono-ovunque-come-li-proteggi\/","title":{"rendered":"I container sono ovunque: come li proteggi?"},"content":{"rendered":"\n

I container stanno aumentando di numero ogni giorno e sembrano essere ovunque, poich\u00e9 le organizzazioni sono ansiose di raccogliere i numerosi vantaggi offerti da loro, come lo sviluppo agile di applicazioni e la distribuzione<\/strong> su tutte le piattaforme.<\/p>\n

Molti credono inoltre che l'uso dei container possa aiutarli a ridurre al minimo i vincoli di sicurezza a causa della loro natura di breve durata. \u00c8 vero o \u00e8 solo un'altra errata percezione?<\/p>\n

Sebbene i container non presentino insicurezze intrinseche, vengono spesso implementati in modo non sicuro, con conseguenti numerose sfide alla sicurezza.<\/p>\n

Problemi di sicurezza durante la distribuzione di container<\/h2>\n

Il numero, la versatilit\u00e0 e lo stato effimero dei container distribuiti, oltre al fatto che i container devono comunicare con altre entit\u00e0, portano le organizzazioni a non avere la capacit\u00e0 di possedere un'adeguata visibilit\u00e0 del traffico tra container.<\/p>\n

A causa di questa mancanza di visibilit\u00e0, i container vengono spesso dimenticati e le misure di prevenzione delle intrusioni e i controlli di sicurezza diventano inefficaci, aumentando la superficie di attacco e quindi il rischio aziendale complessivo. Inoltre, la mancanza di visibilit\u00e0 pu\u00f2 comportare una scarsit\u00e0 di responsabilit\u00e0 poich\u00e9 i container attraversano ambienti diversi dallo sviluppo alla produzione.<\/p>\n

Un'altra sfida alla sicurezza relativa ai container \u00e8 la scarsa gestione delle vulnerabilit\u00e0. Ad esempio, quando si clonano immagini esistenti per creare nuovi contenitori, anche le loro vulnerabilit\u00e0 verranno replicate.<\/p>\n

Ci\u00f2 evidenzia la necessit\u00e0 che la sicurezza sia parte integrante della strategia del contenitore organizzativo<\/a>. In caso contrario, gli errori di configurazione e le patch mancanti potrebbero essere la causa della distribuzione e dell'esecuzione di immagini non autorizzate negli ambienti di produzione, determinando una maggiore superficie di attacco e attacchi pi\u00f9 efficaci.<\/p>\n

Infine, poich\u00e9 i contenitori utilizzano un kernel del sistema operativo condiviso, una compromissione del kernel del sistema operativo host da parte di un contenitore canaglia pu\u00f2 portare alla perdita di accesso a tutti oa tutti i contenitori<\/a> in esecuzione sull'host allo stesso modo come potenzialmente altri host sulla rete.<\/p>\n

Come mettere in sicurezza i tuoi container<\/h2>\n

Forse la migliore pratica per proteggere il tuo ambiente containerizzato \u00e8 riconoscere la necessit\u00e0 di farlo. Fatta eccezione per questo concetto fondamentale, ci sono alcuni buoni consigli da seguire per proteggere efficacemente i tuoi contenitori.<\/p>\n

Ottieni visibilit\u00e0 sui tuoi container<\/h2>\n

Prima di distribuire un container, assicurati di aver compreso le sue dipendenze e cosa \u00e8 incluso in esso. Per garantire che le immagini del tuo contenitore siano incontaminate, devi ottenere visibilit\u00e0 in ogni fase, dallo sviluppo alla produzione.<\/p>\n

Non fidarsi del software di un container \u00e8 un ottimo punto di partenza. Devi controllarlo molto attentamente per capire "da dove provengono, come sono stati prodotti e le loro fonti corrispondenti", come ha sottolineato Dirk Hohndel, vicepresidente di VMware, all'Open Source Leadership Summit 2019<\/a>.<\/p>\n

In poche parole, ricontrolla il contenuto dei tuoi contenitori prima di distribuirli e non eseguire mai un contenitore con software sconosciuto o obsoleto. Solo perch\u00e9 un'immagine contenitore afferma di contenere i programmi e le librerie pi\u00f9 recenti e migliori, ci\u00f2 non significa che lo faccia effettivamente.<\/p>\n

Un modo per mitigare questo problema consiste nell'utilizzare applicazioni che possono aiutarti a ripulire i tuoi contenitori<\/a>. Anche se non mi piace reinventare la ruota, forse l'approccio migliore \u00e8 smettere di usare le immagini dei contenitori di altre persone.<\/p>\n

Se tu, proprio come Hercules, prendi la strada pi\u00f9 difficile di Virtue e inizi a costruire le tue immagini di container, avrai una comprensione molto migliore di cosa sta succedendo all'interno dei container, il che ha vantaggi oltre la sicurezza.<\/p>\n

Controlla l'accesso alla radice<\/h2>\n

La maggior parte dei container viene compilata con l'accesso root per impostazione predefinita. Tuttavia, questa \u00e8 una pratica discutibile. Sebbene sia pi\u00f9 facile per gli sviluppatori eseguire i container come root, ci sono enormi rischi con l'accesso come root.<\/p>\n

Esistono diversi approcci per gestire questo problema. Un modo consiste nell'accertare una politica aziendale in base alla quale nessun container pu\u00f2 mai essere eseguito come root. Un modo alternativo consiste nell'esercitare il principio del privilegio minimo. Puoi specificare un utente non root all'interno del Dockerfile, quando crei un'immagine del contenitore, per eseguire il contenitore come quell'utente specifico con l'accesso al sistema minimo richiesto.<\/p>\n

Infine, puoi anche utilizzare lo spazio dei nomi utente<\/a> durante l'esecuzione di processi contenitore con privilegi per aiutare i contenitori sicuri. Con questo metodo, l'UID per l'esecuzione di questi processi all'interno del contenitore \u00e8 zero (che \u00e8 la radice), ma al di fuori del contenitore l'UID \u00e8 1000 senza privilegi.<\/p>\n

Controllare il runtime del contenitore<\/h2>\n

La " Guida alla sicurezza dei container delle applicazioni<\/a> " SP 800-190 del National Institute of Standards and Technology (NIST) sottolinea che anche i runtime dei container sono vulnerabili agli attacchi. Sebbene questa non sia una lacuna di sicurezza comune, il NIST sottolinea che le vulnerabilit\u00e0 della sicurezza del runtime dei container possono essere " particolarmente pericolose<\/strong> " se consentono scenari in cui il software dannoso pu\u00f2 attaccare le risorse in altri container e lo stesso sistema operativo host.<\/p>\n

Un utente malintenzionato pu\u00f2 anche essere in grado di sfruttare le vulnerabilit\u00e0 per compromettere il software di runtime stesso e quindi alterare quel software in modo da consentire all'attaccante di accedere ad altri container, monitorare le comunicazioni da container a container, ecc.<\/p>\n

I problemi di sicurezza sono molto pi\u00f9 comuni con le configurazioni di runtime. I runtime del contenitore in genere espongono molte opzioni configurabili. Un'impostazione impropria pu\u00f2 ridurre la sicurezza relativa del sistema.<\/p>\n

Ad esempio<\/strong>, sugli host di container Linux, l'insieme delle chiamate di sistema consentite \u00e8 spesso limitato per impostazione predefinita solo a quelle richieste per il funzionamento sicuro dei container. Se questo elenco viene ampliato, potrebbe esporre i contenitori e il sistema operativo host a un rischio maggiore da un contenitore compromesso.<\/p>\n

Allo stesso modo, se un container viene eseguito in modalit\u00e0 privilegiata, ha accesso a tutti i dispositivi dell'host, consentendogli di agire essenzialmente come parte del sistema operativo host e di influire su tutti gli altri container in esecuzione su di esso.<\/p>\n

Un altro esempio di configurazione di runtime non sicura consiste nel consentire ai contenitori di montare directory sensibili sull'host. Se un container compromesso pu\u00f2 apportare modifiche a questi percorsi, potrebbe essere utilizzato per elevare i privilegi e attaccare l'host stesso, nonch\u00e9 altri container in esecuzione sull'host.<\/p>\n

Rafforza il sistema operativo<\/h2>\n

Il NIST consiglia inoltre di eseguire un sistema operativo specifico per container<\/a> perch\u00e9 le minacce sono in genere pi\u00f9 minime poich\u00e9 i sistemi operativi sono progettati specificamente per ospitare container e hanno altri servizi e funzionalit\u00e0 disabilitati.<\/p>\n

Inoltre, poich\u00e9 questi sistemi operativi ottimizzati sono progettati specificamente per l'hosting di container, in genere presentano file system di sola lettura e utilizzano altre pratiche di protezione avanzata per impostazione predefinita. Quando possibile, le organizzazioni dovrebbero utilizzare questi sistemi operativi minimalisti per ridurre le loro superfici di attacco e mitigare i rischi tipici e le attivit\u00e0 di rafforzamento associati ai sistemi operativi generici.<\/p>\n

Le organizzazioni che non possono utilizzare un sistema operativo specifico per container devono seguire le indicazioni in NIST SP 800-123, Guide to General Server Security<\/a> per ridurre il pi\u00f9 possibile la superficie di attacco dei propri host.<\/p>\n

Ad esempio<\/strong>, gli host che eseguono contenitori devono eseguire solo contenitori e non eseguire altre app, come un server Web o un database, al di fuori dei contenitori. Il sistema operativo host non deve eseguire servizi di sistema non necessari, come uno spooler di stampa, che ne aumenta la superficie di attacco.<\/p>\n

Infine, gli host dovrebbero essere continuamente scansionati alla ricerca di vulnerabilit\u00e0 e aggiornamenti applicati rapidamente, non solo al runtime del contenitore ma anche ai componenti di livello inferiore come il kernel su cui i contenitori fanno affidamento per un funzionamento sicuro e compartimentato.<\/p>\n

La sicurezza dei container \u00e8 una priorit\u00e0 assoluta<\/h2>\n

Con sempre pi\u00f9 aziende che adottano e distribuiscono container, la loro sicurezza sta diventando una delle principali priorit\u00e0 aziendali. Secondo un recente sondaggio<\/a>, il 94%<\/strong> degli intervistati ha subito un incidente di sicurezza nei propri container. Ci\u00f2 evidenzia solo quanto sia importante ottenere i diritti di sicurezza dei container per proteggere la tua azienda e i tuoi clienti.<\/p><\/p>\n","protected":false},"excerpt":{"rendered":"

I container stanno aumentando di numero ogni giorno e sembrano essere ovunque, poich\u00e9 le organizzazioni sono ansiose di raccogliere i numerosi vantaggi offerti da loro, come lo sviluppo agile di applicazioni e la distribuzione su tutte le piattaforme.<\/p>\n","protected":false},"author":1,"featured_media":243869,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":"","_wp_rev_ctl_limit":""},"categories":[8590,8478,8437],"tags":[],"class_list":["post-248621","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-varie","category-vpn-e-privacy","category-vpn-per-computer"],"_links":{"self":[{"href":"https:\/\/vpn.inform.click\/it\/wp-json\/wp\/v2\/posts\/248621","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/vpn.inform.click\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/vpn.inform.click\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/vpn.inform.click\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/vpn.inform.click\/it\/wp-json\/wp\/v2\/comments?post=248621"}],"version-history":[{"count":0,"href":"https:\/\/vpn.inform.click\/it\/wp-json\/wp\/v2\/posts\/248621\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/vpn.inform.click\/it\/wp-json\/wp\/v2\/media\/243869"}],"wp:attachment":[{"href":"https:\/\/vpn.inform.click\/it\/wp-json\/wp\/v2\/media?parent=248621"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/vpn.inform.click\/it\/wp-json\/wp\/v2\/categories?post=248621"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/vpn.inform.click\/it\/wp-json\/wp\/v2\/tags?post=248621"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}