{"id":28240,"date":"2023-11-27T12:45:25","date_gmt":"2023-11-27T10:45:25","guid":{"rendered":"https:\/\/www.kaspersky.it\/blog\/?p=28240"},"modified":"2023-11-27T12:45:25","modified_gmt":"2023-11-27T10:45:25","slug":"container-security","status":"publish","type":"post","link":"https:\/\/www.kaspersky.it\/blog\/container-security\/28240\/","title":{"rendered":"La sicurezza dei container dalla A alla Z"},"content":{"rendered":"

Al giorno d\u2019oggi una qualche forma di virtualizzazione o containerization \u00e8 presente in quasi tutte le grandi soluzioni IT. I container offrono numerosi vantaggi durante lo sviluppo, l\u2019installazione, la manutenzione e l\u2019utilizzo del sistema. Accelerano lo sviluppo, assicurano risparmi sui costi e consentono di salvaguardare le altre risorse. Allo stesso tempo, molte soluzioni di sicurezza che funzionano su server fisici e virtuali non sono direttamente applicabili ai container. Quali rischi dovrebbero prendere in considerazione le aziende durante l\u2019implementazione della containerization e quali misure sono necessarie per proteggere l\u2019infrastruttura dei container?<\/p>\n

Vantaggi della containerization per lo sviluppo e le operazioni<\/h2>\n

Un container \u00e8 un ambiente isolato per l\u2019esecuzione di una singola applicazione creato da strumenti a livello di kernel del sistema operativo. L\u2019immagine del container include sia l\u2019applicazione che le impostazioni richieste e i componenti ausiliari, rendendo molto pratico per gli sviluppatori inserire tutto ci\u00f2 di cui hanno bisogno nel container. Chi utilizza i container li trova molto pi\u00f9 semplici da utilizzare rispetto a un\u2019infrastruttura vecchio stile. Inoltre, l\u2019isolamento riduce notevolmente l\u2019influenza reciproca delle applicazioni containerizzate. Un\u2019infrastruttura container presenta quindi meno possibilit\u00e0 di errori, aumentando al tempo stesso le capacit\u00e0 di controllo per gli amministratori.<\/p>\n

La containerization \u00e8 una tecnologia pi\u00f9 leggera della virtualizzazione: i container non emulano l\u2019hardware e non \u00e8 necessario fornire l\u2019intero contenuto della macchina virtuale, in particolare il sistema operativo guest. In molti casi, i carichi di lavoro containerizzati sono pi\u00f9 facili da scalare.<\/p>\n

Senza dubbio, lo strumento pi\u00f9 comune per la creazione e l\u2019archiviazione delle immagini dei container \u00e8 Docker, mentre l\u2019orchestrazione dei carichi di lavoro dei container viene spesso implementata con Kubernetes, Docker Swarm o Red Hat OpenShift.<\/p>\n

La containerization \u00e8 diventata una parte essenziale dei moderni approcci di sviluppo IT. Molte applicazioni sono sviluppate in un\u2019architettura di microservizi: le singole funzionalit\u00e0 di un\u2019applicazione di grandi dimensioni sono allocate a microservizi che comunicano con le altre parti dell\u2019applicazione tramite API. Un esempio \u00e8 un lettore video in un social network o il processo di pagamento di un negozio online. Questi microservizi vengono spesso distribuiti come container, consentendo agli sviluppatori di adottare il proprio ciclo di sviluppo e distribuzione.<\/p>\n

I container si integrano perfettamente con la moderna metodologia CI\/CD (Continuous Integration\/Continuous Delivery), quindi gli aggiornamenti delle applicazioni vengono rilasciati pi\u00f9 rapidamente e con minori quantit\u00e0 di bug. Questo approccio prevede un ciclo di sviluppo breve, team che lavorano in parallelo sullo stesso codice e l\u2019automazione delle azioni di routine. La containerization in una pipeline CI\/CD migliora anche l\u2019efficienza della pipeline: il sistema CI\/CD utilizza le immagini del container come modelli e fornisce la build come immagine pronta per la distribuzione. Il punto chiave \u00e8 che gli aggiornamenti vengono forniti sotto forma di nuove immagini, anzich\u00e9 distribuiti all\u2019interno di un container esistente e operativo. Ci\u00f2 accelera la preparazione e il debug della release, riduce i requisiti per l\u2019infrastruttura sia dello sviluppatore che del cliente, migliora la stabilit\u00e0 operativa e semplifica la scalabilit\u00e0 dell\u2019applicazione.<\/p>\n

Integrando correttamente i requisiti di sicurezza dei container nei processi di sviluppo e compilazione, un\u2019azienda compie un grande passo avanti verso la piena implementazione di DevSecOps.<\/p>\n

Minacce fondamentali per l\u2019infrastruttura dei container<\/h2>\n

Il sistema host, gli ambienti di containerization e le applicazioni containerizzate sono tutti soggetti alla maggior parte dei tipici rischi per la sicurezza delle informazioni, come vulnerabilit\u00e0 nei componenti, impostazioni non sicure e simili.<\/p>\n

I cybercriminali stanno gi\u00e0 sfruttando attivamente questi rischi. Ad esempio, nel repository Docker Hub pubblico sono state individuate 1.650 immagini di container con malware<\/a>. In un caso simile, le immagini dannose non sono state rilevate per circa un anno<\/a>. Alcune campagne dannose utilizzano l\u2019API Docker per creare container con malware su sistemi mirati<\/a>, disabilitare i sistemi di monitoraggio e avviare attivit\u00e0 di mining. In un altro attacco, gli autori delle minacce hanno colpito i cluster Kubernetes con PostgreSQL configurato in modo errato<\/a>. Un altro problema comune \u00e8 che le immagini dei container obsolete che contengono vulnerabilit\u00e0 note come Log4shell possono essere archiviate nei repository per diverso tempo. Inoltre, gli sviluppatori lasciano regolarmente chiavi API e altri segreti nei container<\/a>.<\/p>\n

Sistematizzando le minacce per ciascun elemento nel sistema di containerization, otteniamo questo schema leggermente semplificato:<\/p>\n\n\n\n\n\n\n\n\n
Immagini<\/strong><\/td>\nRegistro delle immagini<\/strong><\/td>\nOrchestrator<\/strong><\/td>\nContainer<\/strong><\/td>\nSistema operativo host<\/strong><\/td>\n<\/tr>\n
Utilizzo di immagini non attendibili<\/td>\nConnessione non protetta<\/td>\nAccesso amministrativo illimitato<\/td>\nVulnerabilit\u00e0 dell\u2019ambiente di runtime<\/td>\nKernel del sistema operativo condiviso per tutti i container<\/td>\n<\/tr>\n
Vulnerabilit\u00e0 software<\/td>\nImmagini obsolete con vulnerabilit\u00e0<\/td>\nAccesso non autorizzato<\/td>\nAccesso illimitato alla rete<\/td>\nVulnerabilit\u00e0 dei componenti del sistema operativo<\/td>\n<\/tr>\n
Errore di configurazione<\/td>\nAutenticazione e autorizzazione insufficienti<\/td>\nMancanza di isolamento e ispezione del traffico tra i container<\/td>\nConfigurazione di runtime non sicura<\/td>\nAutorizzazioni utente errate<\/td>\n<\/tr>\n
Malware<\/td>\n<\/td>\nNessuna separazione dei container con diversi livelli di sensibilit\u00e0 dei dati tra gli host<\/td>\nVulnerabilit\u00e0 delle applicazioni nei container<\/td>\nFile system accessibile dai container<\/td>\n<\/tr>\n
Segreti in chiaro<\/td>\n<\/td>\nErrori di configurazione dell\u2019orchestrator<\/td>\nContainer non conformi nell\u2019ambiente di runtime<\/td>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Container e protezione tramite strumenti di protezione tradizionali<\/h2>\n

Molte difese che funzionavano bene per le macchine virtuali non possono essere applicate alla sicurezza dei container. In genere, non \u00e8 possibile eseguire un agente EDR all\u2019interno di un container come in una macchina virtuale. Inoltre, ci\u00f2 che accade nel container non \u00e8 completamente disponibile per l\u2019analisi da parte dei sistemi di sicurezza convenzionali nel sistema host. Pertanto, il rilevamento, ad esempio, di software vulnerabile e dannoso all\u2019interno del container \u00e8 problematico, cos\u00ec come l\u2019applicazione di strumenti di protezione come WAF nelle applicazioni containerizzate. Il traffico tra i container viene spesso trasmesso su una rete virtuale a livello di orchestrator e potrebbe non essere accessibile agli strumenti di protezione della rete.<\/p>\n

Anche nel sistema operativo host, un agente di protezione non adattato pu\u00f2 comportare un degrado delle prestazioni o della stabilit\u00e0 delle applicazioni containerizzate distribuite. La protezione del cluster deve essere fornita a livello di host in linea con il particolare ambiente di orchestrazione e la natura dei carichi di lavoro dei container.<\/p>\n

Esistono anche problemi specifici che devono essere risolti per gli ambienti container, come impedire l\u2019esecuzione di container non attendibili, individuare la presenza di segreti nei container e limitare il traffico di rete per ogni container specifico in base alle relative funzioni. Tutto questo \u00e8 disponibile solo in soluzioni specializzate come Kaspersky Container Security<\/a>.<\/p>\n

Che dire della protezione con strumenti nativi?<\/h2>\n

Tutti i principali fornitori di container sembrano impegnarsi a fondo per migliorare la sicurezza dei loro prodotti. Gli strumenti nativi di Kubernetes, ad esempio, possono essere utilizzati per configurare quote di risorse e criteri di registrazione, nonch\u00e9 per implementare RBAC (Role-Based Access Control) con il principio dei privilegi minimi. Tuttavia, esistono intere classi di attivit\u00e0 di protezione delle informazioni che non possono essere affrontate con gli strumenti nativi, come il monitoraggio dei processi all\u2019interno di un container in esecuzione, l\u2019analisi delle vulnerabilit\u00e0, il controllo della conformit\u00e0 ai criteri e alle best practice di protezione delle informazioni e molto altro.<\/p>\n

Ma soprattutto, un sistema maturo e completo per la sicurezza dei container deve garantire la protezione fin dalle prime fasi della containerizzazione: lo sviluppo, la distribuzione e l\u2019archiviazione. Per raggiungere questo obiettivo, la sicurezza della containerizzazione deve essere incorporata nel processo di sviluppo e integrata con gli strumenti di sviluppo.<\/p>\n

In che modo la protezione dei container diventa parte di DevSecOps<\/h2>\n

L\u2019approccio DevOps si \u00e8 evoluto in DevSec<\/em>Ops, a causa delle crescenti richieste di affidabilit\u00e0 e sicurezza delle applicazioni. Per rendere la sicurezza una parte organica dello sviluppo, i requisiti fondamentali di sicurezza delle informazioni vengono verificati automaticamente in tutte le fasi della preparazione e della distribuzione dell\u2019applicazione, laddove possibile. Gli ambienti container facilitano questa operazione.<\/p>\n

Fase di pianificazione: protezione delle operazioni di VCS e registro.<\/strong> All\u2019inizio del ciclo di sviluppo, gli sviluppatori di software selezionano i componenti, inclusi quelli containerizzati, da distribuire nell\u2019applicazione. Il sistema di protezione deve eseguire la scansione delle immagini del registro per verificarne l\u2019aggiornamento e analizzare i file di configurazione (IaC, in particolare Dockerfile) alla ricerca di errori e impostazioni non sicure. Le immagini di base utilizzate nello sviluppo devono essere scansionate alla ricerca di vulnerabilit\u00e0, malware, segreti e simili. In tal modo, gli sviluppatori riducono significativamente i rischi di compromissione della supply chain.<\/p>\n

Fase di compilazione e test: protezione delle operazioni di Continuous Integration.<\/strong> In questa fase \u00e8 necessario assicurarsi che nell\u2019immagine non siano presenti segreti, versioni vulnerabili delle librerie o malware e che tutti gli aspetti della sicurezza delle informazioni che possono essere analizzati siano conformi ai requisiti delle autorit\u00e0 di regolamentazione e dell\u2019azienda stessa. La compilazione di un\u2019applicazione non pu\u00f2 essere completata correttamente se sono presenti violazioni dei criteri<\/strong>. Questa operazione viene eseguita integrando il sistema di sicurezza dei container con una piattaforma CI\/CD, che si tratti di Jenkins, Gitlab o CircleCI. Insieme ai test statici e dinamici della sicurezza delle applicazioni (AppSec), questa misura \u00e8 ci\u00f2 che distingue DevSecOps da altri approcci di sviluppo.<\/p>\n

Fase di delivery e distribuzione: sicurezza a livello di Continuous Delivery<\/strong>. Le immagini rese operative devono essere scansionate per garantire l\u2019integrit\u00e0 e la piena conformit\u00e0 ai criteri adottati. Se la situazione richiede un\u2019eccezione (ad esempio, una vulnerabilit\u00e0 viene pubblicata ma non \u00e8 ancora stata corretta), deve essere sempre documentata e limitata nel tempo.<\/p>\n

Fase operativa: protezione dell\u2019orchestrator e dei container in esecuzione.<\/strong> Avvio e controllo del funzionamento dei container. Questa fase riduce al minimo i rischi associati alle vulnerabilit\u00e0 nell\u2019ambiente di runtime o alla sua errata configurazione. Cosa ancora pi\u00f9 importante, solo qui \u00e8 possibile rilevare varie anomalie nel funzionamento dell\u2019applicazione, come un carico computazionale eccessivo o comunicazioni impreviste con altri container e la rete nel suo insieme. Questa fase monitora anche la sicurezza della personalizzazione dell\u2019orchestrator e la possibilit\u00e0 di accedervi. Per la sicurezza dei container, il funzionamento nativo con l\u2019orchestrator Kubernetes o OpenShift \u00e8 fondamentale. Al tempo stesso, il sistema operativo host non deve essere lasciato senza protezione.<\/p>\n

Per operare in queste fasi, lo stesso sistema di sicurezza per i container deve essere multicomponente. L\u2019illustrazione mostra gli elementi principali di Kaspersky Container Security e la loro relazione con la piattaforma di containerization e la piattaforma CI\/CD.<\/p>\n

\"Kaspersky

Kaspersky Container Security: architettura a ciclo chiuso<\/p><\/div>\n

Quali misure di protezione adottare per ciascun componente dell\u2019ambiente container?<\/h2>\n

Diamo un\u2019occhiata a un elenco pi\u00f9 dettagliato di misure di protezione che devono essere applicate a ciascun componente del sistema di containerization perch\u00e9 la sua sicurezza possa essere definita completa.<\/p>\n\n\n\n\n\n\n\n\n\n
Immagini<\/strong><\/td>\nRegistro delle immagini<\/strong><\/td>\nOrchestrator<\/strong><\/td>\nContainer<\/strong><\/td>\nSistema operativo host<\/strong><\/td>\n<\/tr>\n
Vulnerability assessment<\/td>\nIntegrazione del registro e scansione delle immagini<\/td>\nRilevamento di errori di configurazione e correzioni consigliate<\/td>\nControllo dell\u2019avvio e del funzionamento solo dei container attendibili<\/td>\nRilevamento di errori di configurazione e correzioni consigliate<\/td>\n<\/tr>\n
Scansione alla ricerca di errori di configurazione delle immagini<\/td>\n\u201cElenco chiuso\u201d: utilizzo solo di immagini approvate e aggiornate<\/td>\nVisualizzazione delle risorse nel cluster<\/td>\nMonitoraggio dell\u2019integrit\u00e0 dei container<\/td>\nMitigazione dei rischi per la sicurezza tramite il controllo dell\u2019avvio dei container<\/td>\n<\/tr>\n
Scansione anti-malware<\/td>\nRicerca di configurazioni e impostazioni di accesso errate<\/td>\nRilevamento e scansione delle immagini nel cluster (ricerca di container di cui non \u00e8 stato tenuto conto)<\/td>\nControllo dell\u2019avvio di applicazioni e servizi all\u2019interno dei container<\/td>\nVersione del sistema operativo adattata per ridurre al minimo la superficie di attacco<\/td>\n<\/tr>\n
Ricerca di segreti<\/td>\n<\/td>\n<\/td>\nMonitoraggio del traffico dei container<\/td>\n<\/td>\n<\/tr>\n
Valutazione del rischio e identificazione di immagini potenzialmente pericolose<\/td>\n<\/td>\n<\/td>\nRiduzione al minimo dei privilegi dei container<\/td>\n<\/td>\n<\/tr>\n
<\/td>\n<\/td>\n<\/td>\nRaggruppamento dei container negli host per livello di rischio\/importanza<\/td>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

L\u2019elemento centrale del sistema di sicurezza \u00e8 la scansione approfondita delle immagini. Il sistema di sicurezza deve essere integrato con i registri chiave (come DockerHub, GitLab Registry o JFrog Artifactory), sia pubblici che aziendali, ed eseguire regolarmente la scansione delle immagini utilizzate in conformit\u00e0 con i criteri aziendali. Ogni scansione nell\u2019elenco \u00e8 importante di per s\u00e9, ma il profilo di rischio e le specifiche delle applicazioni variano per ogni azienda, quindi potrebbe, ad esempio, essere possibile consentire l\u2019utilizzo di immagini con vulnerabilit\u00e0 a bassa criticit\u00e0. Inoltre, a seconda dei criteri di sicurezza applicati, i suggerimenti CIS Kubernetes o vari database di vulnerabilit\u00e0 possono essere fondamentali.<\/p>\n

Le immagini dei container che non superano la scansione vengono semplicemente contrassegnate per gli amministratori o bloccate nelle fasi successive di sviluppo e distribuzione.<\/p>\n

\"Kaspersky<\/p>\n

\"Kaspersky<\/p>\n

Il secondo gruppo di strumenti di protezione, altrettanto importante e specifico, opera nella fase di distribuzione e avvio del container. Innanzitutto, viene impedita l\u2019esecuzione dei container non conformi ai criteri e non inclusi negli elenchi attendibili.<\/p>\n

La protezione dell\u2019ambiente di runtime \u00e8 incompleta senza l\u2019ispezione dell\u2019orchestrator stesso. Questa aiuta a identificare errori di configurazione, non conformit\u00e0 con i criteri di sicurezza e tentativi non autorizzati di modificare la configurazione. Una volta che i container sono in esecuzione, il monitoraggio dell\u2019attivit\u00e0 dell\u2019orchestrator consente di rilevare e arrestare le attivit\u00e0 sospette sia all\u2019interno che tra i cluster.<\/p>\n

\"Kaspersky<\/p>\n

\"Kaspersky<\/p>\n

Alcune attivit\u00e0 della matrice non possono essere delegate a una soluzione di sicurezza di alcun tipo. Queste includono la scelta iniziale di una build del sistema operativo sicura e minimalista, appositamente adattata per l\u2019esecuzione dei carichi di lavoro dei container, oltre all\u2019attivit\u00e0 cruciale del raggruppamento dei container. Per una corretta protezione a pi\u00f9 livelli e una gestione pratica, i container in esecuzione devono essere raggruppati negli host in modo che le informazioni con determinati requisiti di sicurezza vengano elaborate separatamente dalle informazioni con requisiti di sicurezza inferiori. L\u2019implementazione dipende dall\u2019orchestrator in uso, ma in ogni caso si tratta principalmente di un esercizio di valutazione del rischio e di modellazione delle minacce.<\/p>\n

In generale, esistono numerose attivit\u00e0 di protezione dei container e tentare di affrontarle singolarmente, con i propri strumenti o con una configurazione manuale, comporterebbe un aumento dei costi. Pertanto, gli ambienti container di medie e grandi dimensioni richiedono soluzioni di sicurezza olistiche profondamente integrate con la piattaforma di containerization, la pipeline CI\/CD e gli strumenti di protezione delle informazioni utilizzati nell\u2019azienda.<\/p>\n

Il lavoro degli esperti di sicurezza delle informazioni \u00e8 semplificato da: integrazione con SIEM e canali di notifica dei problemi rilevati, scansione automatica periodica di tutte le immagini rispetto a un database di vulnerabilit\u00e0 aggiornato (come NVD), funzionalit\u00e0 per l\u2019accettazione temporanea dei rischi per la sicurezza delle informazioni e la registrazione dettagliata degli eventi amministrativi nel sistema di protezione dell\u2019ambiente di containerization.<\/p>\n

In che modo Kaspersky Container Security implementa la protezione<\/h2>\n

La nostra soluzione completa protegge l\u2019infrastruttura dei container \u201cby design\u201d: i suoi componenti proteggono l\u2019intero ciclo di vita delle applicazioni containerizzate, dallo sviluppo all\u2019esecuzione quotidiana. Lo scanner dedicato funziona con le immagini dei container e fornisce una protezione statica, mentre l\u2019agente KCS in esecuzione come container separato sotto il controllo dell\u2019orchestrator protegge gli host nell\u2019ambiente di runtime e l\u2019ambiente di orchestrazione nel suo insieme. Al tempo stesso, il componente centrale di Kaspersky Container Security integra questi elementi e fornisce un\u2019interfaccia di gestione.<\/p>\n

La piattaforma ad alte prestazioni offre una protezione efficiente per i cluster K8s con centinaia di nodi.<\/p>\n

\"Kaspersky<\/p>\n

La prima versione di Kaspersky Container Security, che implementa la protezione di base per gli ambienti container, \u00e8 gi\u00e0 disponibile. Siamo inoltre impegnati a sviluppare il prodotto e a estenderne le funzionalit\u00e0 in futuro.<\/p>\n\n","protected":false},"excerpt":{"rendered":"

Esaminiamo in modo approfondito la protezione e la configurazione dei sistemi di containerization.<\/p>\n","protected":false},"author":2706,"featured_media":28247,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[2364,2955],"tags":[58,2670,3778,3560,3779,3250,961,638,3003,941,3570,67,1653],"class_list":{"0":"post-28240","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-business","8":"category-enterprise","9":"tag-cloud","10":"tag-cloud-ibrido","11":"tag-containerization","12":"tag-containerizzazione","13":"tag-devops","14":"tag-infrastruttura","15":"tag-linux","16":"tag-minacce","17":"tag-open-source","18":"tag-prodotti","19":"tag-strategia","20":"tag-suggerimenti","21":"tag-sviluppo"},"hreflang":[{"hreflang":"it","url":"https:\/\/www.kaspersky.it\/blog\/container-security\/28240\/"},{"hreflang":"en-in","url":"https:\/\/www.kaspersky.co.in\/blog\/container-security\/26389\/"},{"hreflang":"en-ae","url":"https:\/\/me-en.kaspersky.com\/blog\/container-security\/21910\/"},{"hreflang":"en-us","url":"https:\/\/usa.kaspersky.com\/blog\/container-security\/29079\/"},{"hreflang":"en-gb","url":"https:\/\/www.kaspersky.co.uk\/blog\/container-security\/26671\/"},{"hreflang":"ru","url":"https:\/\/www.kaspersky.ru\/blog\/container-security\/36087\/"},{"hreflang":"x-default","url":"https:\/\/www.kaspersky.com\/blog\/container-security\/49325\/"},{"hreflang":"ru-kz","url":"https:\/\/blog.kaspersky.kz\/container-security\/26827\/"},{"hreflang":"en-au","url":"https:\/\/www.kaspersky.com.au\/blog\/container-security\/32673\/"},{"hreflang":"en-za","url":"https:\/\/www.kaspersky.co.za\/blog\/container-security\/32415\/"}],"acf":[],"banners":"","maintag":{"url":"https:\/\/www.kaspersky.it\/blog\/tag\/containerizzazione\/","name":"containerizzazione"},"_links":{"self":[{"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/posts\/28240","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/users\/2706"}],"replies":[{"embeddable":true,"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/comments?post=28240"}],"version-history":[{"count":2,"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/posts\/28240\/revisions"}],"predecessor-version":[{"id":28249,"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/posts\/28240\/revisions\/28249"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/media\/28247"}],"wp:attachment":[{"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/media?parent=28240"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/categories?post=28240"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/tags?post=28240"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}