{"id":39334,"date":"2019-10-31T22:30:19","date_gmt":"2019-10-31T19:30:19","guid":{"rendered":"https:\/\/prohoster.info\/blog\/pochemu-traditsionnye-antivirusy-ne-podhodyat-dlya-publichnyh-oblakov-i-chto-delat\/"},"modified":"2019-10-31T22:30:19","modified_gmt":"2019-10-31T19:30:19","slug":"pochemu-traditsionnye-antivirusy-ne-podhodyat-dlya-publichnyh-oblakov-i-chto-delat","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/pochemu-traditsionnye-antivirusy-ne-podhodyat-dlya-publichnyh-oblakov-i-chto-delat","title":{"rendered":"Perch\u00e9 gli antivirus tradizionali non sono adatti per i cloud pubblici. E cosa fare?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Sempre pi\u00f9 utenti stanno spostando l'intera infrastruttura IT nel cloud pubblico. Tuttavia, in caso di insufficienza del controllo antivirus nell'infrastruttura del cliente, sorgono seri rischi informatici. Le esperienze dimostrano che fino all'80% dei virus esistenti prosperano bene in un ambiente virtuale. In questo articolo parleremo di come proteggere le risorse IT nel cloud pubblico e perch\u00e9 i tradizionali antivirus non siano del tutto adatti a questo scopo. <\/b><\/p>\n

\"Perch\u00e9
\n
\nPer iniziare, spiegheremo come siamo arrivati alla conclusione che gli strumenti di protezione antivirus comuni non siano adatti per il cloud pubblico e che siano necessari approcci diversi per la protezione delle risorse. <\/a><\/noindex><\/p>\n

In primo luogo, generalmente i fornitori garantiscono le misure necessarie per assicurare un elevato livello di sicurezza delle proprie piattaforme cloud. Ad esempio, noi di #CloudMTS analizziamo tutto il traffico di rete, monitoriamo i log dei sistemi di sicurezza del nostro cloud e eseguiamo regolarmente test di penetrazione. I segmenti di cloud assegnati a clienti specifici devono anche essere protetti in modo affidabile. <\/p>\n

In secondo luogo, il metodo classico di lotta contro i rischi informatici prevede l'installazione di antivirus e strumenti di gestione su ogni macchina virtuale. Tuttavia, con un numero elevato di macchine virtuali, questa pratica pu\u00f2 risultare inefficace e richiedere notevoli risorse computazionali, aggravando ulteriormente l'infrastruttura del cliente e riducendo le prestazioni complessive del cloud. Questo \u00e8 stato il presupposto chiave per la ricerca di nuovi approcci alla costruzione di una protezione antivirus efficace per le macchine virtuali dei clienti. <\/p>\n

Inoltre, la maggior parte delle soluzioni antivirus disponibili sul mercato non \u00e8 adattata a risolvere le problematiche di protezione delle risorse IT nell'ambiente cloud pubblico. Generalmente, si tratta di pesanti soluzioni EPP (Endpoint Protection Platforms) che, tra l'altro, non offrono la necessaria possibilit\u00e0 di personalizzazione da parte dei clienti del fornitore di cloud. <\/p>\n

Diventa evidente che le soluzioni antivirus tradizionali non siano adatte per il lavoro nel cloud, poich\u00e9 sovraccaricano seriamente l'infrastruttura virtuale durante gli aggiornamenti e le scansioni, e mancano dei necessari livelli di controllo basati sui ruoli e impostazioni. In seguito analizzeremo dettagliatamente le ragioni per cui il cloud ha bisogno di nuovi approcci alla protezione antivirus. <\/p>\n

Cosa deve saper fare un antivirus nel cloud pubblico <\/h2>\n

\nQuindi, prestiamo attenzione alle specificit\u00e0 del lavoro in un ambiente virtuale: <\/p>\n

Efficacia nell'esecuzione di aggiornamenti e verifiche di massa programmate.<\/b> Se un numero significativo di macchine virtuali che utilizzano antivirus tradizionale avvia contemporaneamente un aggiornamento, nel cloud si verificher\u00e0 quella che viene chiamata una \"tempesta\" di aggiornamenti. Le risorse dell'host ESXi, su cui sono ospitate diverse macchine virtuali, potrebbero non essere sufficienti ad affrontare l'ondata di compiti simili avviati per impostazione predefinita. Dal punto di vista del fornitore di cloud, questo problema pu\u00f2 portare a un carico aggiuntivo su un certo numero di host ESXi, che alla fine porter\u00e0 a una diminuzione delle prestazioni dell'infrastruttura virtuale del cloud. Ci\u00f2 pu\u00f2 riflettersi, tra l'altro, sulle prestazioni delle macchine virtuali di altri clienti del cloud. Una situazione simile pu\u00f2 sorgere durante l'avvio della scansione di massa: l'elaborazione simultanea da parte del sistema di archiviazione di numerose richieste simili da diversi utenti influenzer\u00e0 negativamente le prestazioni dell'intero cloud. Con un'alta probabilit\u00e0, la riduzione della funzionalit\u00e0 dello storage rifletter\u00e0 su tutti i clienti. Questi carichi improvvisi non sono graditi n\u00e9 al fornitore n\u00e9 ai suoi clienti, poich\u00e9 influiscono sui \"vicini\" nel cloud. Da questo punto di vista, un antivirus tradizionale pu\u00f2 rappresentare un grande problema.<\/p>\n

Quarantena sicura.<\/b> Se nel sistema viene rilevato un file o un documento potenzialmente infetto da un virus, viene inviato in quarantena. Certamente, il file infetto pu\u00f2 essere eliminato immediatamente, ma questo non \u00e8 spesso accettabile per la maggior parte delle aziende. Gli antivirus aziendali enterprise, che non sono progettati per funzionare nel cloud del fornitore, tendono ad avere un'area di quarantena comune: tutti gli oggetti infetti vi confluiscono. Ad esempio, quelli trovati sui computer degli utenti aziendali. I clienti del fornitore cloud 'vivono' nei propri segmenti (o tenant). Questi segmenti sono opachi e isolati: i clienti non conoscono l'uno dell'altro e, naturalmente, non vedono cosa caricano nel cloud gli altri. \u00c8 chiaro che nella quarantena comune, a cui possono accedere tutti gli utenti dell'antivirus nel cloud, potrebbe finire un documento contenente informazioni riservate o segreti commerciali. Questo \u00e8 inaccettabile per il fornitore e per i suoi clienti. Pertanto, l'unica soluzione \u00e8 avere una quarantena personale per ogni cliente nel suo segmento, a cui n\u00e9 il fornitore n\u00e9 gli altri clienti possono accedere. <\/p>\n

Politiche di sicurezza individuali. <\/b>Ogni cliente nel cloud \u00e8 un'azienda separata, il cui dipartimento IT stabilisce le proprie politiche di sicurezza. Ad esempio, gli amministratori definiscono le regole di scansione e il programma delle verifiche antivirus. Di conseguenza, ogni organizzazione deve avere il proprio centro di gestione per configurare le politiche antivirus. Le configurazioni impostate non devono influenzare gli altri clienti del cloud e il fornitore deve avere la possibilit\u00e0 di assicurarsi che, ad esempio, gli aggiornamenti dell'antivirus avvengano regolarmente per tutte le macchine virtuali del cliente. <\/p>\n

Organizzazione della fatturazione e licensing.<\/b> Il modello cloud si caratterizza per la flessibilit\u00e0 e prevede il pagamento solo per la quantit\u00e0 di risorse IT effettivamente utilizzate dal cliente. Se necessario, ad esempio a causa di fattori stagionali, il volume delle risorse pu\u00f2 essere rapidamente aumentato o ridotto, tutto in base alle attuali esigenze di potenza di calcolo. Un antivirus tradizionale non \u00e8 cos\u00ec flessibile: di solito, il cliente acquista una licenza annuale per un numero prestabilito. server<\/a> o delle stazioni di lavoro. Gli utenti del cloud disconnettono e riconnettono regolarmente macchine virtuali aggiuntive in base alle loro necessit\u00e0 attuali \u2014 di conseguenza, le licenze antivirus devono sostenere lo stesso modello. <\/p>\n

La seconda questione riguarda cosa esattamente coprir\u00e0 la licenza. L'antivirus tradizionale \u00e8 licenziato in base al numero di server o stazioni di lavoro. Le licenze basate sul numero di macchine virtuali protette non sono del tutto appropriate per il modello cloud. Il cliente pu\u00f2 creare qualsiasi numero di macchine virtuali comode tra le risorse disponibili, ad esempio cinque o dieci macchine. Questo numero non \u00e8 costante per la maggior parte dei clienti e monitorarlo non \u00e8 possibile per noi come provider. Non c'\u00e8 la possibilit\u00e0 tecnica di licenziare per CPU: i clienti ricevono processori virtuali (vCPU), su cui deve essere effettuata la licenza. Pertanto, il nuovo modello di protezione antivirus deve prevedere la possibilit\u00e0 per il cliente di definire il numero necessario di vCPU, per i quali ricever\u00e0 le licenze antivirus. <\/p>\n

Conformit\u00e0 legislativa.<\/b> Un punto importante, poich\u00e9 le soluzioni adottate devono garantire il rispetto dei requisiti normativi. Ad esempio, spesso gli 'abitanti' del cloud lavorano con dati personali. In tal caso, il provider deve disporre di un segmento di cloud certificato che sia pienamente conforme ai requisiti della legge sulla 'Protezione dei dati personali'. Cos\u00ec le aziende non devono 'costruire' autonomamente l'intero sistema per lavorare con i dati personali: acquistare attrezzature certificate, collegarle e configurarle, superare la certificazione. Per la sicurezza informatica dei dati personali, l'antivirus per tali clienti deve anche rispettare i requisiti della legislazione russa e avere il certificato FSTEC.<\/p>\n

Abbiamo esaminato i criteri obbligatori che la protezione antivirus deve soddisfare nel cloud pubblico. In seguito condivideremo la nostra esperienza nell'adattare la soluzione antivirus per lavorare nel cloud del provider. <\/p>\n

Come \u00e8 possibile mettere d'accordo antivirus e cloud<\/h2>\n

\nCome dimostrato dalla nostra esperienza, scegliere una soluzione in base alla descrizione e alla documentazione \u00e8 una cosa, mentre implementarla nella pratica in un ambiente cloud esistente \u00e8 un compito completamente diverso per livello di complessit\u00e0. Racconteremo cosa abbiamo fatto nella pratica e come abbiamo adattato l'antivirus per lavorare nel cloud pubblico del provider. Il vendor della soluzione antivirus \u00e8 diventato Kaspersky, che ha nel suo portafoglio soluzioni per la protezione antivirus per ambienti cloud. Abbiamo optato per \"Kaspersky Security per ambienti virtuali\" (Agente leggero). <\/p>\n

Essa include la console unica Kaspersky Security Center. Agente leggero e macchine virtuali di sicurezza (SVM, Security Virtual Machine) e server di integrazione KSC. <\/p>\n

Dopo aver studiato l'architettura della soluzione Kaspersky e condotto i primi test insieme agli ingegneri del vendor, si \u00e8 posto il problema dell'integrazione del servizio nel cloud. Il primo intervento \u00e8 stato realizzato congiuntamente presso il sito cloud di Mosca. Ecco cosa abbiamo capito. <\/p>\n

Per minimizzare il traffico di rete, \u00e8 stata presa la decisione di posizionare SVM su ciascun host ESXi e \"legare\" SVM agli host ESXi. In questo caso, gli agenti leggeri delle macchine virtuali protette si rivolgono a SVM dello stesso host ESXi su cui sono in esecuzione. Per il principale KSC \u00e8 stata scelta una tenant amministrativa separata. Di conseguenza, i KSC subordinati si trovano nelle tenant di ogni singolo cliente e si rivolgono al KSC superiore situato nel segmento di gestione. Questo schema consente di risolvere rapidamente i problemi che si presentano nelle tenant dei clienti. <\/p>\n

Oltre alle questioni relative all'implementazione dei componenti della soluzione antivirus stessa, ci siamo trovati di fronte alla sfida di organizzare l'interazione di rete creando VxLAN aggiuntivi. E sebbene la soluzione fosse inizialmente destinata a clienti enterprise con cloud privati, con l'ingegneria creativa e la flessibilit\u00e0 tecnologica di NSX Edge siamo riusciti a risolvere tutte le problematiche legate alla separazione delle tenant e alla licenza. <\/p>\n

Abbiamo lavorato a stretto contatto con gli ingegneri di Kaspersky. Durante l'analisi dell'architettura della soluzione per quanto riguarda l'interazione di rete tra i componenti del sistema, \u00e8 emerso che, oltre all'accesso da parte di agenti leggeri al SVM, \u00e8 necessaria anche una comunicazione di ritorno \u2013 dal SVM agli agenti leggeri. Questa connettivit\u00e0 di rete non \u00e8 possibile in un ambiente multitenant a causa della possibilit\u00e0 di avere impostazioni di rete identiche per macchine virtuali in diversi tenant del cloud. Pertanto, su nostra richiesta, i colleghi del fornitore hanno riprogettato il meccanismo di interazione di rete tra l'agente leggero e il SVM per escludere la necessit\u00e0 di connettivit\u00e0 di rete dal SVM agli agenti leggeri.<\/p>\n

Dopo che la soluzione \u00e8 stata distribuita e testata sulla piattaforma cloud di Mosca, l'abbiamo replicata su altre piattaforme, incluso il segmento cloud certificato. Ora il servizio \u00e8 disponibile in tutte le regioni del paese. <\/p>\n

Architettura della soluzione di sicurezza informatica nel nuovo approccio<\/h2>\n

\nLo schema generale di funzionamento della soluzione antivirus nell'ambiente cloud pubblico \u00e8 il seguente:<\/p>\n

\"Perch\u00e9
\nSchema di funzionamento della soluzione antivirus nell'ambiente cloud pubblico #CloudMTS<\/i><\/p>\n

Descriviamo le caratteristiche del funzionamento dei singoli elementi della soluzione nel cloud: <\/p>\n

\u2022 Un'unica console che consente ai clienti di gestire centralmente il sistema di protezione: avviare controlli, monitorare gli aggiornamenti e osservare le zone di quarantena. \u00c8 possibile configurare politiche di sicurezza individuali all'interno del proprio segmento. <\/p>\n

\u00c8 importante sottolineare che, sebbene siamo un fornitore di servizi, non interferiamo con le impostazioni stabilite dai clienti. L'unica cosa che possiamo fare \u00e8 ripristinare le politiche di sicurezza ai valori di default in caso di necessit\u00e0 di riconfigurazione. Ad esempio, questo pu\u00f2 essere necessario se il cliente ha inavvertitamente inasprito o allentato notevolmente tali politiche. Ogni azienda pu\u00f2 sempre ottenere un centro di gestione con le politiche predefinite, che pu\u00f2 poi configurare autonomamente. Un punto negativo di Kaspersky Security Center \u00e8 che attualmente la piattaforma \u00e8 disponibile solo per il sistema operativo Microsoft. Tuttavia, agenti leggeri possono funzionare sia su macchine Windows che Linux. Tuttavia, in 'Kaspersky Lab' promettono che KSC funzioner\u00e0 anche su sistemi operativi Linux nei prossimi tempi. Una delle funzioni importanti di KSC \u00e8 la possibilit\u00e0 di gestire la quarantena. Ogni azienda cliente nel nostro cloud ha una quarantena personale. Questo approccio esclude situazioni in cui un documento infetto da virus possa accidentalmente essere reso accessibile al pubblico, come potrebbe accadere con un tradizionale antivirus aziendale con quarantena condivisa.<\/p>\n

\u2022 Agenti leggeri. Nell'ambito del nuovo modello, viene installato un agente leggero Kaspersky Security su ogni macchina virtuale. Questo permette di non memorizzare il database antivirus su ogni VM, riducendo lo spazio su disco occupato. Il servizio \u00e8 integrato con l'infrastruttura cloud e opera tramite SVM, aumentando la densit\u00e0 delle macchine virtuali sull'host ESXi e le prestazioni dell'intero sistema cloud. L'agente leggero costruisce una coda di operazioni per ogni macchina virtuale: controllare il file system, la memoria, ecc. Tuttavia, l'esecuzione di queste operazioni \u00e8 responsabilit\u00e0 di SVM, di cui parleremo in seguito. Inoltre, l'agente svolge funzioni di firewall, controlla le politiche di sicurezza, invia file infetti in quarantena e monitora la 'salute' generale del sistema operativo su cui \u00e8 installato. Tutto ci\u00f2 pu\u00f2 essere gestito tramite l'unica console gi\u00e0 menzionata. <\/p>\n

\u2022 Macchina virtuale di sicurezza. Tutte le attivit\u00e0 ad alta intensit\u00e0 di risorse (come gli aggiornamenti delle basi antivirus e la scansione programmata) sono gestite da una macchina virtuale di sicurezza (SVM) separata. Essa \u00e8 responsabile del funzionamento di un motore antivirus completo e delle relative basi. L'infrastruttura IT di un'azienda pu\u00f2 includere diverse SVM. Questo approccio aumenta l'affidabilit\u00e0 del sistema: se una macchina smette di funzionare e non risponde per trenta secondi, gli agenti iniziano automaticamente a cercarne un'altra. <\/p>\n

\u2022 Server di integrazione KSC. Uno dei componenti principali del KSC, che assegna alle SVM i suoi agenti leggeri secondo l'algoritmo impostato nelle sue configurazioni e monitora la disponibilit\u00e0 delle SVM. In questo modo, questo modulo software garantisce il bilanciamento del carico su tutte le SVM dell'infrastruttura cloud. <\/p>\n

Algoritmo di funzionamento nel cloud: riduzione del carico sull'infrastruttura <\/h2>\n

\nIn generale, l'algoritmo di funzionamento dell'antivirus pu\u00f2 essere rappresentato nel seguente modo. L'agente accede a un file sulla macchina virtuale e lo controlla. Il risultato della scansione \u00e8 salvato in un database centralizzato dei verdetti SVM (denominato Shared Cache), in cui ogni record identifica un campione unico del file. Questo approccio consente di garantire che lo stesso file non venga controllato pi\u00f9 volte di seguito (ad esempio, se viene aperto su diverse macchine virtuali). Il file viene riscanalizzato solo se subisce modifiche o se la scansione \u00e8 stata avviata manualmente.<\/p>\n

\"Perch\u00e9
\nImplementazione della soluzione antivirus nel cloud del fornitore<\/i><\/p>\n

L'immagine mostra lo schema generale di implementazione della soluzione nel cloud. Nella zona di gestione del cloud \u00e8 stato distribuito il principale Kaspersky Security Center, mentre su ciascun host ESXi, tramite il server di integrazione KSC, \u00e8 stata distribuita una SVM individuale (ogni SVM \u00e8 legata a un host ESXi specifico con impostazioni personali su VMware vCenter Server). I clienti operano nei propri segmenti di cloud, dove vengono ospitate macchine virtuali con agenti. Queste sono gestite attraverso server KSC individuali subordinati al principale KSC. In caso di necessit\u00e0 di proteggere un numero ridotto di macchine virtuali (fino a 5), al cliente pu\u00f2 essere fornito accesso alla console virtuale di un server KSC dedicato. L'interazione di rete tra i KSC client e il principale KSC, cos\u00ec come tra gli agenti leggeri e la SVM, avviene tramite NAT attraverso i router virtuali EdgeGW.<\/p>\n

Secondo le nostre stime e i risultati dei test condotti dai colleghi nel fornitore, l'agente leggero riduce il carico sulla infrastruttura virtuale dei clienti di circa il 25% (rispetto a un sistema che utilizza software antivirus tradizionale). In particolare, l'antivirus standard Kaspersky Endpoint Security (KES) per ambienti fisici consuma quasi il doppio del tempo di CPU del server (2,95%) rispetto alla soluzione di virtualizzazione basata su agenti leggeri (1,67%).<\/p>\n

\"Perch\u00e9
\nGrafico di confronto del carico sulla CPU
\n<\/i>
\nSituazione simile si osserva con la frequenza di accesso al disco in scrittura: per l'antivirus tradizionale \u00e8 di 1011 IOPS, mentre per l'antivirus cloud \u00e8 di 671 IOPS.<\/p>\n

\"Perch\u00e9
\nGrafico di confronto della frequenza di accesso al disco
\n<\/i>
\nIl guadagno in prestazioni consente di mantenere la stabilit\u00e0 dell'infrastruttura e di utilizzare pi\u00f9 efficientemente le risorse computazionali. Grazie all'adattamento per funzionare in un ambiente cloud pubblico, la soluzione non riduce le prestazioni del cloud: essa esegue controlli centralizzati dei file e carica aggiornamenti, distribuendo il carico. Ci\u00f2 significa che, da un lato, non verranno trascurate le minacce attuali per l'infrastruttura cloud, e dall'altro, le richieste di risorse per le macchine virtuali diminuiranno in media del 25% rispetto a un antivirus tradizionale.<\/p>\n

Per funzionalit\u00e0, entrambe le soluzioni sono molto simili: di seguito \u00e8 riportata una tabella comparativa. Tuttavia, nel cloud, come mostrano i risultati dei test sopra, \u00e8 comunque pi\u00f9 ottimale utilizzare una soluzione per ambienti virtuali. <\/p>\n

\"Perch\u00e9
\n
\nInformazioni sulla tariffazione nel nuovo approccio.<\/b> Abbiamo deciso di utilizzare un modello che consente di ottenere licenze in base al numero di vCPU. Ci\u00f2 significa che il numero di licenze sar\u00e0 pari al numero di vCPU. \u00c8 possibile testare l'antivirus richiedendo una prova. sul sito<\/a><\/noindex>. <\/p>\n

Nel prossimo articolo sulla tematica cloud parleremo dell'evoluzione dei WAF nel cloud e di cosa sia meglio scegliere: hardware, software o cloud. <\/p>\n

Il testo \u00e8 stato preparato dai dipendenti del fornitore cloud #CloudMTS: Denis Myagkov, architetto principale, e Alexey Afanasyev, manager dello sviluppo dei prodotti di sicurezza delle informazioni. <\/i><\/p>\n

Fonte: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

\u0412\u0441\u0435 \u0431\u043e\u043b\u044c\u0448\u0435 \u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u0435\u043b\u0435\u0439 \u0432\u044b\u0432\u043e\u0434\u044f\u0442 \u0432 \u043f\u0443\u0431\u043b\u0438\u0447\u043d\u043e\u0435 \u043e\u0431\u043b\u0430\u043a\u043e \u0432\u0441\u044e \u0441\u0432\u043e\u044e \u0418\u0422-\u0438\u043d\u0444\u0440\u0430\u0441\u0442\u0440\u0443\u043a\u0442\u0443\u0440\u0443. \u041e\u0434\u043d\u0430\u043a\u043e \u0432 \u0441\u043b\u0443\u0447\u0430\u0435 \u043d\u0435\u0434\u043e\u0441\u0442\u0430\u0442\u043e\u0447\u043d\u043e\u0441\u0442\u0438 \u0430\u043d\u0442\u0438\u0432\u0438\u0440\u0443\u0441\u043d\u043e\u0433\u043e \u043a\u043e\u043d\u0442\u0440\u043e\u043b\u044f \u0432 \u0438\u043d\u0444\u0440\u0430\u0441\u0442\u0440\u0443\u043a\u0442\u0443\u0440\u0435 \u0437\u0430\u043a\u0430\u0437\u0447\u0438\u043a\u0430 \u0432\u043e\u0437\u043d\u0438\u043a\u0430\u044e\u0442 \u0441\u0435\u0440\u044c\u0435\u0437\u043d\u044b\u0435 \u043a\u0438\u0431\u0435\u0440-\u0440\u0438\u0441\u043a\u0438. \u041f\u0440\u0430\u043a\u0442\u0438\u043a\u0430 \u043f\u043e\u043a\u0430\u0437\u044b\u0432\u0430\u0435\u0442, \u0447\u0442\u043e \u0434\u043e 80% \u0441\u0443\u0449\u0435\u0441\u0442\u0432\u0443\u044e\u0449\u0438\u0445 \u0432\u0438\u0440\u0443\u0441\u043e\u0432 \u043e\u0442\u043b\u0438\u0447\u043d\u043e \u0436\u0438\u0432\u0443\u0442 \u0432 \u0432\u0438\u0440\u0442\u0443\u0430\u043b\u044c\u043d\u043e\u0439 \u0441\u0440\u0435\u0434\u0435. \u0412 \u044d\u0442\u043e\u043c \u043f\u043e\u0441\u0442\u0435 \u0440\u0430\u0441\u0441\u043a\u0430\u0436\u0435\u043c \u043e \u0442\u043e\u043c, \u043a\u0430\u043a \u0437\u0430\u0449\u0438\u0442\u0438\u0442\u044c \u0418\u0422-\u0440\u0435\u0441\u0443\u0440\u0441\u044b \u0432 \u043f\u0443\u0431\u043b\u0438\u0447\u043d\u043e\u043c \u043e\u0431\u043b\u0430\u043a\u0435 \u0438 \u043f\u043e\u0447\u0435\u043c\u0443 \u0442\u0440\u0430\u0434\u0438\u0446\u0438\u043e\u043d\u043d\u044b\u0435 \u0430\u043d\u0442\u0438\u0432\u0438\u0440\u0443\u0441\u044b \u043d\u0435 \u0441\u043e\u0432\u0441\u0435\u043c \u043f\u043e\u0434\u0445\u043e\u0434\u044f\u0442 \u0434\u043b\u044f \u044d\u0442\u0438\u0445 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":39335,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-39334","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Perch\u00e9 gli antivirus tradizionali non sono adatti per i cloud pubblici. E cosa fare? | ProHoster","description":"Sempre pi\u00f9 utenti migrano tutta la propria infrastruttura IT nel cloud pubblico. Tuttavia, in caso di insufficiente controllo antivirus nell'infrastruttura del cliente, si creano seri rischi informatici.","canonical_url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/pochemu-traditsionnye-antivirusy-ne-podhodyat-dlya-publichnyh-oblakov-i-chto-delat","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"it_IT","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u041f\u043e\u0447\u0435\u043c\u0443 \u0442\u0440\u0430\u0434\u0438\u0446\u0438\u043e\u043d\u043d\u044b\u0435 \u0430\u043d\u0442\u0438\u0432\u0438\u0440\u0443\u0441\u044b \u043d\u0435 \u043f\u043e\u0434\u0445\u043e\u0434\u044f\u0442 \u0434\u043b\u044f \u043f\u0443\u0431\u043b\u0438\u0447\u043d\u044b\u0445 \u043e\u0431\u043b\u0430\u043a\u043e\u0432. \u0418 \u0447\u0442\u043e \u0434\u0435\u043b\u0430\u0442\u044c? | ProHoster","og:description":"\u0412\u0441\u0435 \u0431\u043e\u043b\u044c\u0448\u0435 \u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u0435\u043b\u0435\u0439 \u0432\u044b\u0432\u043e\u0434\u044f\u0442 \u0432 \u043f\u0443\u0431\u043b\u0438\u0447\u043d\u043e\u0435 \u043e\u0431\u043b\u0430\u043a\u043e \u0432\u0441\u044e \u0441\u0432\u043e\u044e \u0418\u0422-\u0438\u043d\u0444\u0440\u0430\u0441\u0442\u0440\u0443\u043a\u0442\u0443\u0440\u0443. \u041e\u0434\u043d\u0430\u043a\u043e \u0432 \u0441\u043b\u0443\u0447\u0430\u0435 \u043d\u0435\u0434\u043e\u0441\u0442\u0430\u0442\u043e\u0447\u043d\u043e\u0441\u0442\u0438 \u0430\u043d\u0442\u0438\u0432\u0438\u0440\u0443\u0441\u043d\u043e\u0433\u043e \u043a\u043e\u043d\u0442\u0440\u043e\u043b\u044f \u0432 \u0438\u043d\u0444\u0440\u0430\u0441\u0442\u0440\u0443\u043a\u0442\u0443\u0440\u0435 \u0437\u0430\u043a\u0430\u0437\u0447\u0438\u043a\u0430 \u0432\u043e\u0437\u043d\u0438\u043a\u0430\u044e\u0442 \u0441\u0435\u0440\u044c\u0435\u0437\u043d\u044b\u0435 \u043a\u0438\u0431\u0435\u0440-\u0440\u0438\u0441\u043a\u0438.","og:url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/pochemu-traditsionnye-antivirusy-ne-podhodyat-dlya-publichnyh-oblakov-i-chto-delat","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T19:30:19+00:00","article:modified_time":"2019-10-31T19:30:19+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"39334","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-02-09 18:02:23","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 00:51:28","updated":"2026-02-09 18:02:23","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/39334","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/comments?post=39334"}],"version-history":[{"count":1,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/39334\/revisions"}],"predecessor-version":[{"id":158518,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/39334\/revisions\/158518"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media\/39335"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=39334"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=39334"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=39334"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}