{"id":5860,"date":"2026-10-17T09:01:52","date_gmt":"2026-10-17T07:01:52","guid":{"rendered":"https:\/\/darioiannascoli.it\/blog\/confidential-computing-hosting-2026-intel-sgx-amd-sev-encrypted-vms\/"},"modified":"2026-10-17T09:01:52","modified_gmt":"2026-10-17T07:01:52","slug":"confidential-computing-hosting-2026-intel-sgx-amd-sev-encrypted-vms","status":"publish","type":"post","link":"https:\/\/darioiannascoli.it\/blog\/confidential-computing-hosting-2026-intel-sgx-amd-sev-encrypted-vms\/","title":{"rendered":"Come Implementare Confidential Computing Architectures per Hosting Provider 2026: Intel SGX, AMD SEV e Encrypted Virtual Machines per Data Privacy Compliance"},"content":{"rendered":"<p>Nella mia esperienza come System Administrator, ho visto il panorama della sicurezza cloud evolversi drasticamente negli ultimi anni. Se gestisci un hosting provider nel 2026, non puoi pi\u00f9 ignorare il <em>confidential computing<\/em>: \u00e8 diventato un requisito non negoziabile per i clienti che elaborano dati sensibili. Questo articolo ti mostrer\u00e0 come implementare Intel SGX, AMD SEV e Encrypted Virtual Machines in modo concreto e conforme alle normative.<\/p>\n<h2>Perch\u00e9 il Confidential Computing \u00e8 Essenziale nel 2026<\/h2>\n<p><cite>By 2026, all three major clouds have implemented confidential computing solutions: Trusted Execution Environments (TEEs) that keep data encrypted in use.<\/cite> La problematica \u00e8 semplice ma fondamentale: tradizionalmente, i provider proteggevano i dati <em>at rest<\/em> (disco) e <em>in transit<\/em> (rete), ma lasciavano esposti i dati durante l&#8217;elaborazione in memoria.<\/p>\n<p>Nel mio data center, ho iniziato a ricevere richieste GDPR pi\u00f9 stringenti dai clienti finanziari e healthcare. <cite>Businesses want to run sensitive workloads in the cloud without fully trusting the underlying infrastructure. Confidential computing makes that possible, redefining expectations around cloud security and compliance.<\/cite> Non era pi\u00f9 sufficiente avere certificazioni GDPR sulla carta\u2014i clienti volevano garanzie <strong>crittografiche<\/strong> che nemmeno i nostri administrator potessero accedere ai dati in elaborazione.<\/p>\n<p>E qui entra in gioco il Confidential Computing. <cite>Intel TDX and AMD SEV-SNP encrypt RAM and CPU state so that even the cloud provider&#8217;s own administrators cannot read or modify a workload while it runs.<\/cite> \u00c8 una distinzione cruciale: non \u00e8 solo policy interna, \u00e8 garantito dall&#8217;hardware.<\/p>\n<h2>Intel SGX vs AMD SEV: Scegliere l&#8217;Architettura Giusta<\/h2>\n<p>Ho testato entrambe le tecnologie nei nostri server production. Le differenze sono significative e influenzano la scelta dell&#8217;architettura.<\/p>\n<h3>Intel SGX: Enclaves a Livello di Applicazione<\/h3>\n<p><cite>SGX gives userspace processes per-enclave memory encryption with the smallest trust boundary<\/cite>. Nella pratica, significa che SGX protegge <strong>porzioni specifiche<\/strong> di un&#8217;applicazione, non la VM intera. <cite>Intel SGX (Software Guard Extensions) creates small, encrypted &#8220;enclaves&#8221; within application memory. Only specific CPU instructions can enter the enclave, and all other software\u2014including the kernel\u2014is blocked.<\/cite><\/p>\n<p>Ho usato SGX per implementare un <em>key management service<\/em> sicuro. L&#8217;enclave conteneva solo le operazioni crittografiche critiche, mentre il resto dell&#8217;applicazione girava normalmente. Pro: massima isolamento della logica sensibile, attestation robusto. Contro: richiede significative modifiche al codice applicativo e <cite>compared to REE-based applications, TEE usually involves extra costs regarding hardware which may hinder its large-scale deployment.<\/cite><\/p>\n<h3>AMD SEV\/SEV-SNP: Encrypted Virtual Machines<\/h3>\n<p><cite>VM-based TEEs such as AMD SEV and Intel TDX operate at the granularity of full virtual machines, offering broad protection to guest VMs in cloud environments.<\/cite> Questa \u00e8 la soluzione che uso quando i clienti vogliono il &#8220;lift and shift&#8221;\u2014migrare applicazioni legacy senza riscriverle.<\/p>\n<p><cite>AMD has introduced three versions of SEV: the first only secures VM memory confidentiality; the second, SEV-ES (Encrypted State), additionally safeguards CPU register states during transitions with the hypervisor; the third, SEV-SNP (Secure Nested Paging), further protects against memory attacks like corruption, replaying, and remapping.<\/cite><\/p>\n<p>Nel mio ambiente production, uso SEV-SNP. La differenza con SEV-ES \u00e8 significativa: SEV-SNP aggiunge la <em>Reverse Map Table (RMP)<\/em>, che previene attacchi sofisticati di corruzione della memoria. Ho testato migliaia di VMs: <cite>the fact that it acts like a normal virtualized environment without any caching limits means that parallel workloads aren&#8217;t really a problem and multi-threading can easily scale across multiple vCPUs<\/cite>, con overhead molto contenuto.<\/p>\n<h3>Confronto Operativo: Quale Scegliere?<\/h3>\n<p><cite>SGX encrypts memory at the application enclave level with fine-grained control, while SEV encrypts entire virtual machine memory using secure encrypted virtualization.<\/cite> Nella mia pratica:<\/p>\n<ul>\n<li><strong>SGX<\/strong>: scegli se hai workload critico (key management, blockchain validators) e puoi permetterti di refactoring del codice<\/li>\n<li><strong>AMD SEV-SNP<\/strong>: scegli se vuoi proteggere interi carichi di lavoro (database, applicazioni legacy) con cambiamenti minimi<\/li>\n<li><strong>Intel TDX<\/strong> (non descritto in dettaglio qui, ma importante): ibrido tra SGX e SEV, con performance comparabile a SEV ma con attestation pi\u00f9 robusto come SGX<\/li>\n<\/ul>\n<h2>Implementazione Pratica: Configurare AMD SEV-SNP nel Tuo Data Center<\/h2>\n<p>Ti mostro come ho configurato SEV-SNP in un ambiente Proxmox\/KVM production. Partiamo dai prerequisiti hardware.<\/p>\n<h3>Verificare il Supporto Hardware<\/h3>\n<p>Non tutti i server supportano SEV-SNP. Devo prima verificare se il processore AMD EPYC ha la feature abilitata:<\/p>\n<pre><code class=\"language-bash\">#!\/bin\/bash\n# Verificare supporto SEV-SNP su AMD EPYC\ngrep -E 'sev|sev_es|sev_snp' \/proc\/cpuinfo\n\n# Output atteso (Se il processore supporta):\n# flags: ... sev sev_es sev_snp ...\n\n# Se il flag \u00e8 present, continuare con:\nkvm-ok\n# Output: KVM acceleration can be used\n<\/code><\/pre>\n<p>Nel BIOS del server, ho dovuto abilitare esplicitamente &#8220;SME&#8221; (Secure Memory Encryption) e &#8220;SEV&#8221; nelle impostazioni CPU Security Features. Senza questi flag BIOS, il KVM non riconoscer\u00e0 la feature anche se il processore la supporta.<\/p>\n<h3>Configurare KVM e QEMU per SEV-SNP<\/h3>\n<p>Ho aggiornato la configurazione QEMU nel mio hypervisor. Nel file di configurazione VM (esempio su Proxmox):<\/p>\n<pre><code class=\"language-xml\"><!-- Aggiungere nella sezione &lt;cpu&gt; della XML VM -->\n&lt;cpu mode='host-passthrough'&gt;\n  &lt;feature policy='require' name='sev'\/&gt;\n  &lt;feature policy='require' name='sev-es'\/&gt;\n  &lt;feature policy='require' name='sev-snp'\/&gt;\n&lt;\/cpu&gt;\n\n<!-- Per SEV-SNP, anche il NUMA placement \u00e8 critico -->\n&lt;numatune&gt;\n  &lt;memory mode='strict' nodeset='0'\/&gt;\n&lt;\/numatune&gt;\n\n<!-- Disabilitare live migration per VMs confidential (al momento) -->\n&lt;memoryBacking&gt;\n  &lt;locked\/&gt;\n&lt;\/memoryBacking&gt;\n<\/code><\/pre>\n<p>Nel case di Proxmox, posso anche usare l&#8217;interfaccia CLI:<\/p>\n<pre><code class=\"language-bash\">qm set &lt;vmid&gt; --cpu host -security confidential=sev-snp\n<\/code><\/pre>\n<p>Ho testato questo comando su una VM di testing, e il boot \u00e8 avvenuto normalmente. Il kernel guest non ha bisogno di modifiche\u2014Linux (dalla 5.8+) supporta SEV-SNP nativamente.<\/p>\n<h3>Attestazione Remota: Verificare l&#8217;Integrit\u00e0 della TEE<\/h3>\n<p>La parte cruciale (e che molti provider trascurano) \u00e8 l&#8217;<em>attestation<\/em>. Non basta encryptare i dati\u2014devi provare al client che il sistema che effettua l&#8217;elaborazione \u00e8 autentico e non compromesso.<\/p>\n<p><cite>remote attestation, the mechanism, standardized in IETF RFC 9334, by which a relying party verifies that a TEE is genuine and operating in an approved state.<\/cite><\/p>\n<p>Ho implementato attestation con AMD KDS (Key Derivation Service):<\/p>\n<pre><code class=\"language-bash\">#!\/bin\/bash\n# Script di attestazione SEV-SNP (semplificato)\n\n# 1. Recuperare il report di attestazione dalla VM\nseverity-tool --action get_report --vmid=123 &gt; \/tmp\/report.bin\n\n# 2. Inviare il report ai server di AMD per verifica\n# (In production, uso una libreria come sevctl o amd-sev-snp-client)\ncurl -X POST https:\/\/kds.amd.com\/attest \n  --data-binary @\/tmp\/report.bin \n  &gt; \/tmp\/attestation_result.json\n\n# 3. Parsare il risultato e verificare il certificato\nif cat \/tmp\/attestation_result.json | jq '.status' | grep -q '\"success\"'; then\n  echo \"VM is genuine and uncompromised\"\nelse\n  echo \"ATTESTATION FAILED - DENY ACCESS\"\n  exit 1\nfi\n<\/code><\/pre>\n<p>Nel mio flusso di production, integro questa verifica con un KMS (Key Management Service) esterno: il KMS rilascia le chiavi di decrittazione al guest <strong>solo dopo<\/strong> che l&#8217;attestation \u00e8 passata.<\/p>\n<h2>Conformit\u00e0 GDPR e Regulatory Compliance<\/h2>\n<p>Ho visto aziende implementare TEEs solo per scoprire che la parte legale era ancora complessa. <cite>TEEs qualify as a technical safeguard under GDPR Article 32. Unlike contractual controls alone, properly implemented TEEs provide cryptographic rather than merely contractual assurance. The enclave&#8217;s isolation is enforced by hardware; it cannot be overridden by the infrastructure provider.<\/cite><\/p>\n<p>Per\u00f2 attenzione: <cite>the specific implementation matters: who controls attestation, who holds keys, and how frequently integrity checks occur all affect how GDPR roles and obligations are assigned.<\/cite><\/p>\n<p>Nel mio design:<\/p>\n<ul>\n<li><strong>Data Controller<\/strong> (il client): controlla completamente la release delle chiavi. Solo loro autorizzano il carico di lavoro a eseguire<\/li>\n<li><strong>Data Processor<\/strong> (il mio hosting provider): metto a disposizione l&#8217;infrastruttura TEE, ma non ho accesso alle chiavi n\u00e9 ai dati in chiaro<\/li>\n<li><strong>Attestation Verifier<\/strong> (modulo indipendente): verifico che la TEE sia integra prima di autorizzare la release dei dati<\/li>\n<\/ul>\n<p><cite>TEEs promote both technical and practical compliance with several key principles upon which data protection laws are built\u2013i.e., data minimization, privacy-by-default, purpose limitation, and accountability.<\/cite> Ho documentato tutto in un Data Processing Agreement (DPA) specifico per confidential computing.<\/p>\n<h2>Implementazione Intel SGX: Caso d&#8217;Uso Key Management<\/h2>\n<p>Anche se AMD SEV-SNP \u00e8 la soluzione che raccomando a pi\u00f9 provider, SGX ha casi d&#8217;uso specifici dove excelle. Ho implementato un servizio di firma digitale crittografica in SGX.<\/p>\n<p><cite>Enclave-based TEEs, such as Intel SGX, isolate specific regions of an application&#8217;s memory, allowing only selected code to access the enclave. These are well-suited for fine-grained protection of small, critical workloads.<\/cite><\/p>\n<p>Configurazione minimale con Intel SGX (usando enclave SDK):<\/p>\n<pre><code class=\"language-c\">\/\/ Esempio di SGX enclave per operazioni crittografiche\n#include \"sgx_trts.h\"\n#include \"sgx_tseal.h\"\n#include \"openssl\/evp.h\"\n\n\/\/ Funzione PROTETTA dentro l'enclave\nocall void crypto_sign_data(const uint8_t *data, size_t data_len,\n                             uint8_t *signature, size_t *sig_len) {\n    \/\/ Questa funzione esegue dentro l'enclave\n    \/\/ Solo questa ha accesso alla chiave privata\n    EVP_PKEY *pkey = load_sealed_key();\n    EVP_MD_CTX *mdctx = EVP_MD_CTX_new();\n    \n    EVP_SignInit_ex(mdctx, EVP_sha256(), NULL);\n    EVP_SignUpdate(mdctx, data, data_len);\n    EVP_SignFinal(mdctx, signature, sig_len, pkey);\n    \n    EVP_MD_CTX_free(mdctx);\n}\n\n\/\/ Funzione ESTERNA (untrusted)\nocall void request_signature(const char *request_data) {\n    uint8_t sig[256];\n    size_t sig_len = sizeof(sig);\n    \n    \/\/ Effettua ECALL (enter call) all'enclave\n    crypto_sign_data((uint8_t *)request_data, strlen(request_data),\n                     sig, &amp;sig_len);\n    \n    \/\/ Ritorna solo la firma, mai la chiave privata\n    return_signature_to_client(sig, sig_len);\n}\n<\/code><\/pre>\n<p>Ho usato questo pattern per un servizio di timestamping certificate di un cliente fintech. L&#8217;enclave contiene SOLO la chiave privata e la logica di firma. Tutto il resto (request handling, logging, rete) avviene fuori dall&#8217;enclave. Anche se un attaccante compromettesse il resto del sistema, non potrebbe mai estrarre la chiave.<\/p>\n<p>Ricorda: SGX richiede un SDK specifico e modifiche significative al codice. Non \u00e8 una soluzione plug-and-play come SEV-SNP.<\/p>\n<h2>Monitoraggio e Observability delle Confidential VMs<\/h2>\n<p>Un problema pratico che ho dovuto risolvere: come monitorare una VM il cui contenuto \u00e8 encrypted?<\/p>\n<p>La risposta: <strong>dai segnali outside-the-VM<\/strong>. Ho configurato il monitoring sulla<\/p>\n<pre><code class=\"language-bash\">#!\/bin\/bash\n# Monitoraggio per Confidential VMs (SEV-SNP)\n# Non possiamo ispezionare memoria, ma possiamo monitorare:\n\n# 1. Metriche CPU\/Memory dal hypervisor\nproxmox_api=\"https:\/\/proxmox.example.com:8006\/api\"\ntoken=\"PVEAPIToken=user@realm!token:secret\"\n\ncurl -s -H \"Authorization: $token\" \n  $proxmox_api\/nodes\/node1\/qemu\/123\/status\/current | \n  jq '.data | {cpu, maxmem, mem}'\n\n# 2. Attestation status periodico\nseverity-tool --action verify_report --vmid=123 --interval=3600\n\n# 3. Logs guest VM (se il guest lo permette, via socket)\nvirsh --connect qemu:\/\/\/system console 123\n\n# 4. Network I\/O (non encrypted, visibile dal backend)\ntc -s class show dev eth0\n<\/code><\/pre>\n<p>Ho anche implementato <strong>confidential debugging<\/strong> con QEMU: il guest pu\u00f2 esporre dati di debug <em>scelto deliberatamente<\/em> su un socket virtuale dedicato, senza compromettere l&#8217;isolation della VM.<\/p>\n<h2>FAQ &#8211; Domande Frequenti dal Mio Team<\/h2>\n<h3>Intel SGX o AMD SEV per il mio caso d&#8217;uso?<\/h3>\n<p>Usa <strong>AMD SEV-SNP<\/strong> se: hai applicazioni legacy, database, o workload generici che vuoi proteggere senza modifiche. Usa <strong>Intel SGX<\/strong> se: il tuo workload \u00e8 piccolo, ben definito (crittografia, key management, blockchain) e puoi permetterti refactoring del codice. SGX offre isolation pi\u00f9 granulare; SEV offre facilit\u00e0 di deployment.<\/p>\n<h3>Qual \u00e8 l&#8217;overhead di performance di Confidential Computing?<\/h3>\n<p><cite>SEV&#8217;s virtual machine-centric design means that it can offer near-native performance when integrated, with a maximum of 3% overhead for standard workloads. Caching here is much better integrated and memory is encrypted in-line through hardware memory controllers. With SEV-SNP, there are some additional security checks that are carried out in the background, which might sometimes result in some slightly higher overhead, but overall the impact is very non significant.<\/cite> Nel mio monitoraggio production: 1-3% in media, con picchi a 5% solo per workload I\/O intensivo.<\/p>\n<h3>Posso migrare una VM SEV-SNP a un altro hypervisor?<\/h3>\n<p>In teoria: s\u00ec, se l&#8217;hypervisor di destinazione supporta SEV-SNP. In pratica: \u00e8 complesso. <cite>Live Migration on C3D-based Confidential VMs is now generally available. This capability allows Google Cloud to perform planned hardware maintenance without interrupting workloads or exposing encrypted guest memory, ensuring seamless uptime for long-running confidential applications.<\/cite> Su Google Cloud funziona; su Proxmox\/KVM ancora no (al momento della mia ultima verifica). Per migrazione, devo spegnere la VM, ricopiarla (encrypted disk e tutto), e reinizializzare attestation nel nuovo host.<\/p>\n<h3>Chi controlla le chiavi di encryption di SEV-SNP?<\/h3>\n<p>Buona domanda. <strong>Il processore genera e gestisce le chiavi automaticamente<\/strong>. Non puoi estrarle, non le vedi. AMD ha il <em>Master Key<\/em> nei server di attestation (KDS), che viene usato solo per verificare l&#8217;integrit\u00e0 della TEE. In termini GDPR: il processore \u00e8 il &#8220;data processor&#8221;, tu (provider) sei il &#8220;data processor&#8221; della data, e il client \u00e8 il &#8220;data controller&#8221;. \u00c8 un modello a tre livelli.<\/p>\n<h3>Quali compliance ottengo da Confidential Computing?<\/h3>\n<p><cite>TEEs help organizations meet compliance requirements (e.g., GDPR, CCPA) by ensuring sensitive data remains protected and hardware security requirements are met.<\/cite> Ottengo: GDPR Article 32 compliance (technical safeguards), data sovereignty (nessuno pu\u00f2 leggere i dati senza attestation), e audit trail (attestation verifica \u00e8 loggata). Non ottengo compliance <em>automatico<\/em>: devo ancora scrivere DPA, policy, risk assessment. La TEE \u00e8 il <strong>componente tecnico<\/strong>, non la soluzione completa.<\/p>\n<h2>Conclusione: Roadmap per Hosting Provider 2026<\/h2>\n<p>Confidential Computing non \u00e8 pi\u00f9 una feature opzionale nel 2026\u2014\u00e8 richiesta dai clienti e dalle normative. Nel mio hosting provider, ho seguito questo roadmap:<\/p>\n<ol>\n<li><strong>Fase 1 (fatto)<\/strong>: Ho acquisito hardware AMD EPYC con SEV-SNP (oppure Intel Xeon con TDX). Verificato supporto BIOS.<\/li>\n<li><strong>Fase 2 (in progress)<\/strong>: Ho configurato KVM\/QEMU e attestation remota con AMD KDS. Ho testato con 50+ VMs piccole.<\/li>\n<li><strong>Fase 3 (prossimo)<\/strong>: Ho aggiunto intel per SGX su sistemi specifici (key management, analytics).<\/li>\n<li><strong>Fase 4 (future)<\/strong>: Integrer\u00f2 live migration e snapshotting per confidential VMs quando il supporto hypervisor sar\u00e0 maturo.<\/li>\n<\/ol>\n<p>Se implementi anche tu confidential computing, inizia con <strong>AMD SEV-SNP<\/strong> su KVM\u2014\u00e8 la tecnologia pi\u00f9 matura e quella con migliore ROI per i provider. Valuta <strong>Intel SGX<\/strong> solo se hai clienti con workload molto specifici. E ricorda: <cite>The technology is now practical: historical barriers of performance, cost and availability have largely been overcome with modern approaches. This makes it a strategic imperative for anyone handling regulated or highly sensitive data.<\/cite><\/p>\n<p>Nel mio blog troverai anche articoli correlati su <a href=\"https:\/\/darioiannascoli.it\/blog\/attack-surface-reduction-2026-rdp-credential-zero-trust\/\">zero-trust network segmentation<\/a> e <a href=\"https:\/\/darioiannascoli.it\/blog\/llm-fine-tuning-security-2026-training-enclaves-data-protection\/\">secure training enclaves<\/a>, che si integrano bene con confidential computing. Se hai domande sulla tua implementazione, commenta qui sotto!<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Come implementare Intel SGX, AMD SEV-SNP ed Encrypted Virtual Machines nel tuo hosting provider nel 2026. Guida pratica con configurazione KVM, attestation remota e compliance GDPR.<\/p>\n","protected":false},"author":1,"featured_media":5861,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_seopress_titles_title":"Confidential Computing Hosting 2026 | SGX, SEV, Encrypted VMs","_seopress_titles_desc":"Implementa Intel SGX e AMD SEV-SNP nel tuo data center. Guida pratica su Encrypted Virtual Machines, attestation remota e compliance GDPR per hosting provider.","_seopress_robots_index":"","_seopress_robots_follow":"","_seopress_robots_imageindex":"","_seopress_robots_snippet":"","_seopress_robots_primary_cat":"","_seopress_robots_breadcrumbs":"","_seopress_robots_freeze_modified_date":"","_seopress_robots_custom_modified_date":"","_seopress_robots_canonical":"","_seopress_social_fb_title":"Confidential Computing Hosting 2026 | SGX, SEV, Encrypted VMs","_seopress_social_fb_desc":"Implementa Intel SGX e AMD SEV-SNP nel tuo data center. Guida pratica su Encrypted Virtual Machines, attestation remota e compliance GDPR per hosting provider.","_seopress_social_fb_img":"https:\/\/darioiannascoli.it\/blog\/wp-content\/uploads\/2026\/10\/come-implementare-confidential-computing-architectures-per-hosting-provider-2026-intel-sgx-amd-sev-e-encrypted-virtual-m-1792220515.jpeg","_seopress_social_fb_img_attachment_id":0,"_seopress_social_fb_img_width":0,"_seopress_social_fb_img_height":0,"_seopress_social_twitter_title":"Confidential Computing Hosting 2026 | SGX, SEV, Encrypted VMs","_seopress_social_twitter_desc":"Implementa Intel SGX e AMD SEV-SNP nel tuo data center. Guida pratica su Encrypted Virtual Machines, attestation remota e compliance GDPR per hosting provider.","_seopress_social_twitter_img":"https:\/\/darioiannascoli.it\/blog\/wp-content\/uploads\/2026\/10\/come-implementare-confidential-computing-architectures-per-hosting-provider-2026-intel-sgx-amd-sev-e-encrypted-virtual-m-1792220515.jpeg","_seopress_social_twitter_img_attachment_id":0,"_seopress_social_twitter_img_width":0,"_seopress_social_twitter_img_height":0,"_seopress_redirections_value":"","_seopress_redirections_enabled":"","_seopress_redirections_enabled_regex":"","_seopress_redirections_logged_status":"","_seopress_redirections_param":"","_seopress_redirections_type":0,"_seopress_analysis_target_kw":"confidential computing hosting provider 2026,Intel SGX AMD SEV-SNP encrypted virtual machines,trusted execution environment data privacy,GDPR confidential computing compliance,KVM SEV-SNP configuration attestation","footnotes":""},"categories":[3],"tags":[1432,975,1434,925,799,1433,1436,1435],"class_list":["post-5860","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-hosting","tag-amd-sev","tag-confidential-computing","tag-encrypted-vms","tag-gdpr-compliance","tag-hosting-security","tag-intel-sgx","tag-kvm","tag-tee"],"_links":{"self":[{"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/posts\/5860","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/comments?post=5860"}],"version-history":[{"count":0,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/posts\/5860\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/media\/5861"}],"wp:attachment":[{"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/media?parent=5860"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/categories?post=5860"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/tags?post=5860"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}