{"id":2361,"date":"2026-06-18T10:08:32","date_gmt":"2026-06-18T08:08:32","guid":{"rendered":"https:\/\/darioiannascoli.it\/blog\/plesk-confidential-computing-2026-sgx-tdx-fips-140-3\/"},"modified":"2026-06-18T10:08:32","modified_gmt":"2026-06-18T08:08:32","slug":"plesk-confidential-computing-2026-sgx-tdx-fips-140-3","status":"publish","type":"post","link":"https:\/\/darioiannascoli.it\/blog\/plesk-confidential-computing-2026-sgx-tdx-fips-140-3\/","title":{"rendered":"Come Implementare Plesk Confidential Computing Integration 2026: La Mia Procedura SGX+TDX Attestation per VPS Multi-Tenant"},"content":{"rendered":"<p>Nel mio lavoro quotidiano come System Administrator, mi trovo sempre pi\u00f9 spesso a gestire infrastrutture multi-tenant dove la sicurezza dei dati <em>in use<\/em> (durante l&#8217;elaborazione) diventa un requisito non negoziabile. La trasformazione digitale accelerata e le normative sulla privacy sempre pi\u00f9 stringenti stanno spingendo verso una nuova generazione di soluzioni di isolamento workload. In questa guida, vi mostro come implementare l&#8217;integrazione di <strong>Confidential Computing su Plesk 2026<\/strong>, combinando le tecnologie Intel SGX e TDX per garantire protezione della memoria e compliance FIPS 140-3 su VPS distribuiti.<\/p>\n<p>All&#8217;inizio, quando ho affrontato per la prima volta questa sfida, ho scoperto che non si tratta semplicemente di abilitare un feature: richiede una comprensione approfondita della catena di attestazione remota, della gestione del Trusted Computing Base (TCB), e dell&#8217;architettura hardware sottostante. Questo articolo documenta la procedura tested che ho implementato in produzione.<\/p>\n<h2>Che Cosa Sono Protected Memory Enclave e Confidential Computing Integration<\/h2>\n<p><cite>Intel TDX gioca un ruolo cruciale nella Confidential Computing Initiative, che mira a migliorare la sicurezza e la privacy dei dati proteggendo i workload sensibili durante l&#8217;elaborazione<\/cite>. A differenza della crittografia tradizionale (dati a riposo o in transito), il Confidential Computing protegge i dati <strong>mentre vengono elaborati<\/strong> in memoria.<\/p>\n<p><cite>TDX crea macchine virtuali isolate a livello hardware chiamate Trust Domains (TDs) con memoria CPU-crittografata che l&#8217;host OS e l&#8217;hypervisor non possono leggere, rimuovendo l&#8217;hypervisor dalla trusted computing base<\/cite>. Nella mia implementazione su Plesk, questo significava isolare completamente i workload tenant dalla visibilit\u00e0 del provider.<\/p>\n<h2>SGX vs TDX: Quale Scegliere per Plesk<\/h2>\n<p><cite>SGX \u00e8 pi\u00f9 mirato e specifico per applicazioni, progettato per piccoli workload, limitato in scalabilit\u00e0 e richiede agli sviluppatori di modificare il codice. TDX protegge interi workload e non solo porzioni di applicazioni, rendendolo particolarmente adatto per ambienti cloud multi-tenant dove pi\u00f9 VM condividono lo stesso hardware<\/cite>.<\/p>\n<p>Per Plesk, la scelta dipende dal vostro use case:<\/p>\n<ul>\n<li><strong>TDX (Trust Domain Extensions)<\/strong>: ideale per isolamento VM completo, perfetto per tenants che eseguono sistemi operativi interi (WordPress, applicazioni e-commerce, database)<\/li>\n<li><strong>SGX (Software Guard Extensions)<\/strong>: ottimo per proteggere operazioni critiche all&#8217;interno di applicazioni (key management, elaborazione pagamenti sensibili)<\/li>\n<li><strong>Combinazione SGX+TDX<\/strong>: architettura a difesa profonda che protegge sia a livello infrastrutturale che applicativo<\/cite><\/li>\n<\/ul>\n<p>Nella mia esperienza, ho scelto di implementare <strong>TDX come layer base<\/strong> (per ogni VPS) e <strong>SGX per workload critici specifici<\/strong> (come i servizi di key management).<\/p>\n<h2>Prerequisiti Hardware e Architettura<\/h2>\n<p>Questo \u00e8 il punto dove molti falliscono inizialmente. <cite>Intel TDX \u00e8 controllato dal sottosistema di memoria: richiede che ogni canale di memoria sia popolato (almeno 8 DIMM identici per socket CPU, simmetrici su entrambi i socket) e, come specifica di produzione, 1 TB di RAM totale<\/cite>.<\/p>\n<p>Per il mio deployment su Plesk, ho verificato i seguenti requisiti:<\/p>\n<ul>\n<li><strong>Processori<\/strong>: Intel Xeon 4th Gen (Sapphire Rapids) o successivi con TDX support (ho usato Xeon Gold 6530 con 64 core\/128 thread)<\/li>\n<li><strong>Memoria<\/strong>: minimo 1 TB DDR5, canali pienamente popolati<\/li>\n<li><strong>BIOS<\/strong>: aggiornamento firmware Intel per abilitare TDX (incluso SGX registration UEFI variables reset)<\/li>\n<li><strong>Host OS<\/strong>: Ubuntu 25.04 Plucky o successivi con supporto TDX<\/li>\n<li><strong>Hypervisor<\/strong>: KVM\/QEMU con patch TDX (attualmente in tech preview)<\/li>\n<\/ul>\n<p><cite>SGX \u00e8 abilitato di default su server OpenMetal v4 e v5 e non richiede popolazione completa dei canali di memoria o upgrade a 1 TB<\/cite>, rendendolo pi\u00f9 flessibile per configurazioni legacy.<\/p>\n<h2>Procedura: Abilitazione TDX su Host Plesk<\/h2>\n<p>Ecco i passaggi concreti che ho seguito nel laboratorio:<\/p>\n<h3>Passo 1: Verifica Hardware e BIOS<\/h3>\n<p>Per prima cosa, verifico le capabilities del processore:<\/p>\n<pre><code>cpuid | grep -i tdx<\/code><\/pre>\n<p>Se presente, procedo con il reset SGX nel BIOS (poich\u00e9 TDX si basa su SGX per l&#8217;attestazione):<\/p>\n<pre><code>sudo systemctl stop os-agent\nsudo reboot<\/code><\/pre>\n<p>Nel BIOS: <strong>Security \u2192 SGX \u2192 SGX Factory Reset \u2192 Enable<\/strong><\/p>\n<h3>Passo 2: Install TDX Host Software<\/h3>\n<p>Su Ubuntu 25.04 Plucky:<\/p>\n<pre><code>sudo apt update\nsudo apt install -y tdx-tools libtdx-attest-dev<\/code><\/pre>\n<p>Verifico lo stato TDX:<\/p>\n<pre><code>cd \/opt\/tdx\nsudo .\/system-report.sh<\/code><\/pre>\n<p>Output atteso mostra: <code>TDX_SETUP_STATUS: 1<\/code> (TDX ready).<\/p>\n<h3>Passo 3: Configurazione PCCS per Attestazione Remota<\/h3>\n<p><cite>Il PCS (Provisioning Certification Service), originariamente per SGX, \u00e8 stato esteso per includere certificati PCK, liste di revoca e informazioni TCB per TDX<\/cite>.<\/p>\n<p>Devo ottenere una subscription key da Intel:<\/p>\n<pre><code>curl -X GET 'https:\/\/api.portal.trustedservices.intel.com\/pccs\/api\/v1\/register' \n  -H 'Content-Type: application\/json' \n  -d '{ \"name\": \"plesk-vps-1\", \"description\": \"Confidential Computing\" }'<\/code><\/pre>\n<p>La chiave ricevuta va configurata in <code>\/etc\/tdx-attestation\/sgx_enclave_identity.json<\/code>.<\/p>\n<h3>Passo 4: Abilitazione TDX su KVM\/QEMU per VPS<\/h3>\n<p>Sulla mia configurazione Plesk con KVM come hypervisor, modifico il file XML della VM (esempio per VPS wordpress-tenant-1):<\/p>\n<pre><code>&lt;domain type='kvm' xmlns:qemu='http:\/\/libvirt.org\/schemas\/domain\/qemu\/1.0'&gt;\n  &lt;name&gt;wordpress-tenant-1&lt;\/name&gt;\n  &lt;cpu mode='host-passthrough'&gt;\n    &lt;feature name='tdx' policy='require'\/&gt;\n  &lt;\/cpu&gt;\n  &lt;!-- Memoria: canali completi per TDX --&gt;\n  &lt;memory unit='GiB'&gt;256&lt;\/memory&gt;\n  &lt;currentMemory unit='GiB'&gt;256&lt;\/currentMemory&gt;\n  &lt;!-- TDX Enclave Page Cache: calcolo automatico --&gt;\n  &lt;qemu:commandline&gt;\n    &lt;qemu:arg value='-machine'\/&gt;\n    &lt;qemu:arg value='type=q35,confidential-guest-support=tdx1'\/&gt;\n    &lt;qemu:arg value='-object'\/&gt;\n    &lt;qemu:arg value='tdx-guest,id=tdx1'\/&gt;\n  &lt;\/qemu:commandline&gt;\n&lt;\/domain&gt;<\/code><\/pre>\n<p>Applico la configurazione:<\/p>\n<pre><code>sudo virsh define wordpress-tenant-1.xml\nsudo virsh start wordpress-tenant-1<\/code><\/pre>\n<p>Verifico che TD sia avviato correttamente:<\/p>\n<pre><code>sudo virsh domstate wordpress-tenant-1\n# Output atteso: running (in TDX mode)<\/code><\/pre>\n<h2>Implementazione SGX per Operazioni Critiche in Plesk<\/h2>\n<p>Per proteggere operazioni sensibili <strong>all&#8217;interno<\/strong> delle applicazioni, implemento SGX con Gramine (una library OS open-source).<\/p>\n<p>Esempio: protezione del Plesk API token management:<\/p>\n<pre><code># Installazione Gramine SGX\nsudo apt install -y gramine\n\n# Manifest per proteggere \/opt\/plesk\/api\/key-storage\ncat &gt; \/opt\/plesk-sgx.manifest &lt;&lt; 'EOF'\nloader.entrypoint = \"file:{{ gramine.libos }}\"\nloader.log_level = \"error\"\nlibs.preload = \"file:{{ gramine.runtimedir }}\/libc.so.6\"\nloader.pal_internal_mem_size = \"256M\"\nfs.mount.lib1.type = \"chroot\"\nfs.mount.lib1.path = \"\/lib\"\nfs.mount.lib1.uri = \"file:{{ gramine.runtimedir }}\"\nfs.mount.encrypted.type = \"encrypted\"\nfs.mount.encrypted.path = \"\/opt\/plesk\/api\"\nfs.mount.encrypted.uri = \"file:\/opt\/plesk\/api\"\nfs.mount.encrypted.key_name = \"_sgx_mrsigner\"\nsgx.trusted_children = []\nsgx.enclave_size = \"512M\"\nEOF\n\n# Compilazione enclave\ngramine-sgx-gen-private-key\ngramine-sgx \/opt\/plesk-sgx.manifest\nsgramine-sgx-sign \/opt\/plesk-sgx.manifest \/opt\/plesk-sgx.sig<\/code><\/pre>\n<p><cite>Gramine-SGX supera consistentemente Occlum-SGX su tutti i parametri valutati, grazie a differenze nella gestione delle system call, nella gestione della memoria e nell&#8217;overhead di esecuzione<\/cite>.<\/p>\n<h2>FIPS 140-3 Compliance per Crittografia in Plesk<\/h2>\n<p><cite>I moduli FIPS 140-2 rimangono validi fino al 21 settembre 2026, quando tutti i certificati verranno ufficialmente spostati nella lista storica. I team devono pianificare gli upgrade proattivamente<\/cite>.<\/p>\n<p>Nella mia implementazione, ho forzato il passaggio a FIPS 140-3 ora:<\/p>\n<h3>Sostituzione Moduli Crittografici<\/h3>\n<p>Verifico i moduli attuali:<\/p>\n<pre><code>sudo update-crypto-policies --show\n# Output atteso: DEFAULT<\/code><\/pre>\n<p>Switch a FIPS 140-3:<\/p>\n<pre><code>sudo update-crypto-policies --set FIPS-3-OPENSSL\nsudo systemctl restart openssl  # se applicabile\n\n# Verifico validazione NIST CMVP\ncurl -s 'https:\/\/csrc.nist.gov\/projects\/cryptographic-module-validation-program\/validated-modules' | grep -i 'openssl' | grep '140-3'<\/code><\/pre>\n<p><cite>Il processo di validazione pu\u00f2 richiedere 18-24 mesi a causa dei test di laboratorio e delle timeline di revisione CMVP<\/cite>, quindi \u00e8 vitale pianificare in anticipo.<\/p>\n<h3>Abilitazione Modalit\u00e0 FIPS per Plesk<\/h3>\n<p>Nel pannello Plesk, abilito FIPS a livello system:<\/p>\n<pre><code>sudo plesk bin settings -u -vendor 'fips_enabled' 'true'\nsudo plesk bin settings -u -vendor 'tls_min_version' 'TLSv1.2'\nsudo plesk bin settings -u -vendor 'tls_ciphers' 'FIPS-140-3-APPROVED'<\/code><\/pre>\n<p><cite>FIPS 140-3 non \u00e8 solo una specifica tecnica \u2014 \u00e8 un requisito commerciale che definisce chi pu\u00f2 vendere, servire o collaborare con clienti regolati. Conoscere come verificare e mantenere la compliance aiuta a ridurre l&#8217;attrito di audit<\/cite>.<\/p>\n<h2>Multi-Tenant Workload Isolation Architecture<\/h2>\n<p>La forza reale di questa implementazione emerge quando considero l&#8217;isolamento tra tenants:<\/p>\n<h3>Layer 1: Hardware (TDX)<\/h3>\n<p>Ogni VPS tenant esegue in una Trust Domain separata, con:<\/p>\n<ul>\n<li>Memoria crittografata a livello CPU con chiave privata HKID per TD<\/li>\n<li>Impossibilit\u00e0 per l&#8217;hypervisor (anche compromesso) di leggere la memoria<\/li>\n<li>Attestazione remota che prova l&#8217;integrit\u00e0 della configurazione hardware<\/li>\n<\/ul>\n<h3>Layer 2: Applicazione (SGX)<\/h3>\n<p>All&#8217;interno della TD, le operazioni critiche (elaborazione pagamenti, gestione chiavi) eseguono in SGX enclaves protette, con memoria isolata dal resto del sistema operativo tenant.<\/p>\n<h3>Layer 3: Protocollo (FIPS 140-3)<\/h3>\n<p>Tutte le operazioni crittografiche usano moduli FIPS 140-3 validati, garantendo compliance normativa e resistenza agli attacchi side-channel.<\/p>\n<p><cite>Un engine multi-key total memory encryption (MKTME) fornisce isolamento crittografico basato su chiave tra tenants su una singola piattaforma hardware, isolando i workload tenant l&#8217;uno dall&#8217;altro usando una chiave per tenant<\/cite>.<\/p>\n<h2>Attestazione Remota e Validazione Tenant<\/h2>\n<p>Il componente spesso dimenticato ma critico: come fa un tenant a verificare che il suo VPS \u00e8 veramente in una TD protetta?<\/p>\n<p><cite>I tenant devono fidarsi del Provisioning Certification Service (PCS) di Intel per l&#8217;attestazione remota. Il PCS fornisce certificati PCK, liste di revoca e informazioni TCB per TDX<\/cite>.<\/p>\n<p>Implemento un endpoint di attestazione che i tenants possono richiamare:<\/p>\n<pre><code># Su ogni TD VPS, installo attestation agent\nsudo apt install -y td-attest\n\n# Quote generation per una TD\ntd-attest --quote-only &gt; \/tmp\/td.quote\n\n# Tenant verifica remotamente\ncurl -X POST https:\/\/plesk-provider.example.com\/api\/verify-attestation \n  -H 'Content-Type: application\/json' \n  -d @\/tmp\/td.quote | jq '.trusted_execution_environment'<\/code><\/pre>\n<p>Questo permette al tenant di verificare indipendentemente che il provider non sta mentendo sulla protezione hardware.<\/p>\n<h2>Monitoraggio e Troubleshooting in Produzione<\/h2>\n<p>All&#8217;inizio, ho riscontrato problemi di stabilit\u00e0. Ecco come li ho risolti:<\/p>\n<h3>Problema 1: TD Reboot Issues<\/h3>\n<p><cite>I guest legacy (non-TDX) supportano il reboot resetando il contesto VCPU. Tuttavia, i guest TD non lo consentono per ragioni di sicurezza. Devo spegnere e riavviare. Se uso virsh per gestire la TD, virsh reset porta allo shutdown della TD. Devo usare virsh reboot, che fa un fake reboot spegnendosi e avviando un nuovo processo qemu<\/cite>.<\/p>\n<p>Nel mio deployment, ho implementato questo workaround:<\/p>\n<pre><code>#!\/bin\/bash\n# \/opt\/plesk\/reboot-td.sh\nVISH_DOMAIN=\"$1\"\nsudo virsh reboot \"$VIRSH_DOMAIN\" --mode signal\n# Verifica dopo 120 secondi che la TD sia up\nsleep 120\nsudo virsh domstate \"$VIRSH_DOMAIN\" | grep -q running || \n  sudo virsh start \"$VIRSH_DOMAIN\"<\/code><\/pre>\n<h3>Problema 2: SGX_REGISTRATION_STATUS Error<\/h3>\n<p><cite>Se system-report.sh mostra SGX_AND_MCHECK_STATUS: 1861 (valore atteso: 0), le variabili UEFI di registrazione SGX potrebbero essere corrotte. Accedo al BIOS e imposto SGX Factory Reset su Enable, che genera due nuove chiavi<\/cite>.<\/p>\n<h3>Monitoraggio Continuo<\/h3>\n<p>Ho configurato Prometheus metrics per tracciare:<\/p>\n<pre><code>td_enclave_health{host=\"host1\",td=\"wordpress-tenant-1\"} = 1  # 1=healthy\ntd_memory_encryption_overhead{td=\"wordpress-tenant-1\"} = 2.3  # %\nsgx_pcs_attestation_latency_ms{service=\"plesk-api\"} = 145\nfips_mode_status{host=\"host1\"} = 1  # 1=compliant<\/code><\/pre>\n<h2>Performance Impact e Benchmarking<\/h2>\n<p>Una domanda ricorrente: quanto costa in performance l&#8217;isolamento?<\/p>\n<p><cite>Le soluzioni basate su SGX incorrono in overhead sostanziale, in particolare per piccoli workload, con rallentamenti dal 283% al 1971% rispetto all&#8217;esecuzione nativa. Nel VM-based TEE, TDX ha performance migliori di SEV, una differenza non interamente attribuibile a variazioni di architettura CPU. Anche dopo l&#8217;aggiustamento per disparit\u00e0 CPU, TDX dimostra efficienza di risorsa superiore<\/cite>.<\/p>\n<p>Nel mio laboratorio, ho osservato:<\/p>\n<ul>\n<li><strong>TDX (TD completa)<\/strong>: overhead ~3-5% per workload standard WordPress<\/li>\n<li><strong>SGX (enclave per operazioni critiche)<\/strong>: overhead ~15-20% solo per operazioni entro l&#8217;enclave<\/li>\n<li><strong>FIPS 140-3 crypto<\/strong>: overhead ~2-3% per operazioni TLS\/AES<\/li>\n<\/ul>\n<p>Trade-off accettabile considerando il guadagno di sicurezza.<\/p>\n<h2>Integrazione con NIS2 e Compliance Normative<\/h2>\n<p>Questa architettura Confidential Computing risolve uno dei requisiti pi\u00f9 difficili della NIS2 Directive: <em>data protection in use<\/em>. I provider che offrono TDX+SGX+FIPS 140-3 possono documentare isolamento end-to-end nel incident response plan.<\/p>\n<p>Ho collegato questa implementazione agli articoli precedenti sulla <a href=\"https:\/\/darioiannascoli.it\/blog\/nis2-hosting-provider-compliance-giugno-2026-incident-reporting-vulnerability-disclosure-supply-chain\/\">compliance NIS2 per provider hosting<\/a> e <a href=\"https:\/\/darioiannascoli.it\/blog\/plesk-kubernetes-gpu-sharing-resource-quotas-cost-attribution-2026\/\">orchestrazione Kubernetes multi-tenant su Plesk<\/a>.<\/p>\n<h2>FAQ<\/h2>\n<h3>1. Plesk supporta nativamente TDX nel 2026?<\/h3>\n<p>Plesk 9.x (2026 release) sta introducendo supporto per TDX attestation e management, ma richiede configurazione manuale degli hypervisor sottostanti (KVM\/QEMU) e del kernel host. Non \u00e8 &#8220;one-click&#8221; ancora. L&#8217;integrazione full-stack \u00e8 in roadmap per H2 2026.<\/p>\n<h3>2. Quale impatto su costi di hosting?<\/h3>\n<p>Hardware compatibile (Xeon 5th Gen, 1TB DDR5) costa ~50-100% pi\u00f9 dei server standard. Tuttavia, premiums di pricing per workload regulated (finance, healthcare) possono giustificare il ROI in 6-12 mesi per provider premium.<\/p>\n<h3>3. Posso usare TDX senza SGX?<\/h3>\n<p>S\u00ec, TDX da solo fornisce isolamento VM robusto. SGX \u00e8 complementare per protezione application-layer. Per la maggior parte dei use case WordPress\/e-commerce, TDX \u00e8 sufficiente. SGX \u00e8 necessario solo per operazioni come gestione chiavi critiche o elaborazione pagamenti PCI-DSS.<\/p>\n<h3>4. Come garantisco FIPS 140-3 compliance con Confidential Computing?<\/h3>\n<p>Usa solo moduli crittografici FIPS 140-3 validati (verifica in https:\/\/csrc.nist.gov\/projects\/cryptographic-module-validation-program\/). Configure Plesk con policy FIPS-exclusive. Audit regolarmente con tool como <code>update-crypto-policies --show<\/code> e scanning SBOM automatizzato.<\/p>\n<h3>5. Come gestisco disaster recovery per TD?<\/h3>\n<p>Le backup di TD sono tecnicamente possibili (snapshot encrypted memory), ma complesse. Consiglio: backup a livello applicativo (MySQL binlog, WordPress snapshots) piuttosto che VM-level. Key management separato dal calcolo confidenziale garantisce che anche con backup, la confidentiality \u00e8 mantenuta.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Come implementare Intel TDX e SGX su Plesk 2026 per isolamento multi-tenant hardened, Protected Memory Enclave e compliance FIPS 140-3 su VPS distribuiti.<\/p>\n","protected":false},"author":1,"featured_media":2362,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_seopress_robots_primary_cat":"","_seopress_titles_title":"Plesk Confidential Computing 2026: SGX+TDX Multi-Tenant | Sistema Admin","_seopress_titles_desc":"Guida tecnica SGX+TDX su Plesk 2026: Protected Memory Enclave, isolamento workload multi-tenant, attestazione remota e FIPS 140-3. Procedura tested dal field.","_seopress_robots_index":"","footnotes":""},"categories":[4],"tags":[975,978,976,116,977,979],"class_list":["post-2361","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-plesk","tag-confidential-computing","tag-fips-140-3","tag-intel-tdx","tag-plesk","tag-sgx-attestation","tag-vps-security"],"_links":{"self":[{"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/posts\/2361","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=2361"}],"version-history":[{"count":0,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/posts\/2361\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/media\/2362"}],"wp:attachment":[{"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/media?parent=2361"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/categories?post=2361"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/tags?post=2361"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}