{"id":7445,"date":"2026-10-28T19:02:30","date_gmt":"2026-10-28T18:02:30","guid":{"rendered":"https:\/\/darioiannascoli.it\/blog\/zero-trust-network-segmentation-edge-computing-beyondprod-service-mesh\/"},"modified":"2026-10-28T19:02:30","modified_gmt":"2026-10-28T18:02:30","slug":"zero-trust-network-segmentation-edge-computing-beyondprod-service-mesh","status":"publish","type":"post","link":"https:\/\/darioiannascoli.it\/blog\/zero-trust-network-segmentation-edge-computing-beyondprod-service-mesh\/","title":{"rendered":"Come Costruire Zero-Trust Network Segmentation per Edge Computing Environments: La Mia Procedura BeyondProd Architecture, Service Mesh Authentication e Decentralized Policy Enforcement"},"content":{"rendered":"<p>Negli ultimi mesi ho dovuto affrontare un progetto complesso: proteggere un&#8217;infrastruttura edge distribuita su pi\u00f9 siti con architetture eterogenee. La sfida principale non era implementare segmentazione di rete tradizionale con firewall e VLAN, ma piuttosto costruire un modello <strong>zero-trust vero<\/strong> dove ogni servizio, dispositivo e richiesta \u00e8 continuamente verificato indipendentemente dalla posizione. <cite>BeyondProd non si basa su protezioni perimetrali tradizionali come firewall, ma crea trust tra i microservizi usando caratteristiche quali la provenienza del codice, le identit\u00e0 dei servizi e l&#8217;hardware attendibile<\/cite>. In questa guida, condivido come ho implementato questa procedura nei miei ambienti edge production.<\/p>\n<h2>Perch\u00e9 Zero-Trust per Edge Computing?<\/h2>\n<p>Nel mio primo tentativo di proteggere l&#8217;edge, ho commesso un errore classico: ho pensato che potessi replicare il modello di sicurezza perimetrale dei data center. Sbagliato. <cite>Poich\u00e9 le imprese decentralizzano i carichi di lavoro ai nodi edge, l&#8217;applicazione dinamica e contestuale delle politiche di sicurezza diventa sempre pi\u00f9 complessa<\/cite>. I nodi edge sono geograficamente distribuiti, spesso connessi tramite reti pubbliche non affidabili, e devono operare autonomamente quando la connessione centrale si interrompe.<\/p>\n<p><cite>Zero trust edge security \u00e8 un modello che assume che nessun utente, dispositivo o richiesta sia affidabile per default, e verifica invece continuamente ognuno di essi<\/cite>. Per l&#8217;edge computing, questo significa tre pilastri fondamentali: <strong>identit\u00e0 distribuita<\/strong>, <strong>autenticazione service mesh<\/strong> e <strong>policy enforcement decentralizzato<\/cite>.<\/p>\n<h2>Fondamenti dell&#8217;Architettura BeyondProd per Edge<\/h2>\n<p><cite>Google ha espanso il principio BeyondCorp ai servizi, ai carichi di lavoro e alle macchine, spiegando come proteggere la propria infrastruttura attraverso quello che chiama BeyondProd<\/cite>. Nella mia implementazione, ho adattato questi principi a tre livelli:<\/p>\n<h3>1. Livello 1: Code Provenance e Service Identity<\/h3>\n<p><cite>BeyondProd crea trust tra i microservizi usando caratteristiche quali la provenienza del codice, le identit\u00e0 dei servizi e l&#8217;hardware attendibile<\/cite>. Nel mio setup:<\/p>\n<ul>\n<li><strong>Attestazione di codice:<\/strong> Ogni container \u00e8 firmato digitalmente. Uso il formato Sigstore per firmare gli artefatti durante il build pipeline CI\/CD.<\/li>\n<li><strong>Identit\u00e0 del servizio:<\/strong> Ogni microservizio ha un certificato X.509 unico, associato alla sua identit\u00e0 (non all&#8217;IP).<\/li>\n<li><strong>Hardware attestazione:<\/strong> I nodi edge comprovano il loro stato di integrit\u00e0 usando TPM 2.0 attestation.<\/li>\n<\/ul>\n<p>Nel mio Kubernetes edge cluster, implemento questo con:<\/p>\n<p><code>apiVersion: security.istio.io\/v1beta1<br \/>kind: PeerAuthentication<br \/>metadata:<br \/>  name: default<br \/>  namespace: edge-ns<br \/>spec:<br \/>  mtls:<br \/>    mode: STRICT<br \/>---<br \/>apiVersion: v1<br \/>kind: ConfigMap<br \/>metadata:<br \/>  name: sigstore-keys<br \/>  namespace: edge-ns<br \/>data:<br \/>  root.crt: |<br \/>    -----BEGIN CERTIFICATE-----<br \/>    [... certificato radice Sigstore ...]<br \/>    -----END CERTIFICATE-----<\/code><\/p>\n<h3>2. Livello 2: Service Mesh mTLS Authentication<\/h3>\n<p><cite>Un service mesh controlla tutta la comunicazione service-to-service a livello data plane. La micro-segmentazione applica politiche granulari a questo flusso, isolando i workload fino alla pi\u00f9 piccola unit\u00e0 pratica<\/cite>. Ho deployato Istio come service mesh, configurando mTLS obbligatorio su tutte le connessioni.<\/p>\n<p>La procedura che ho seguito:<\/p>\n<ol>\n<li><strong>Installo Istio in modalit\u00e0 edge-optimized:<\/strong> Uso il profilo di configurazione minimalista per ridurre il footprint nei nodi edge con risorse limitate.<\/li>\n<li><strong>Abilito mTLS STRICT:<\/strong> Ogni servizio verifica il certificato del client prima di accettare richieste.<\/li>\n<li><strong>Genero certificati con durata breve:<\/strong> Uso durata di 24 ore per costringere rotazione frequente. Se un certificato viene compromesso, l&#8217;esposizione \u00e8 limitata.<\/li>\n<\/ol>\n<p><code>apiVersion: security.istio.io\/v1beta1<br \/>kind: RequestAuthentication<br \/>metadata:<br \/>  name: edge-jwt-auth<br \/>  namespace: edge-ns<br \/>spec:<br \/>  jwtRules:<br \/>  - issuer: \"https:\/\/edge-idp.internal\/oauth2\"<br \/>\n    jwksUri: \"https:\/\/edge-idp.internal\/.well-known\/jwks.json\"<br \/>\n    audiences: \"edge-services\"<br \/>\n    forwardOriginalToken: true<\/code><\/p>\n<h3>3. Livello 3: Decentralized Policy Enforcement<\/h3>\n<p><cite>A livello edge, i principi zero-trust sono messi in pratica attraverso l&#8217;autenticazione, autorizzazione e accounting (AAA) decentralizzati, che applica zero trust localmente su ogni sito. AAA dovrebbe essere decentralizzato per adattarsi alla natura distribuita dell&#8217;edge, con ogni sito che gestisce i propri processi AAA localmente mantenendo la gestione centralizzata<\/cite>. Questo \u00e8 il punto dove inizialmente ho incontrato difficolt\u00e0.<\/p>\n<p>La sfida principale: come applico politiche di accesso quando alcuni nodi edge sono disconnessi dal centro? Inizialmente non funzionava perch\u00e9 ho provato a centralizzare tutte le decisioni. Ho risolto implementando:<\/p>\n<ul>\n<li><strong>Policy Decision Point (PDP) distribuito:<\/strong> Ogni nodo edge mantiene una copia locale della policy database, sincronizzata periodicamente dal centro.<\/li>\n<li><strong>Policy Enforcement Points (PEPs) locali:<\/strong> I proxy Envoy (sidecar di Istio) applicano le regole senza attendere il centro.<\/li>\n<li><strong>Sync mechanism asincrono:<\/strong> Quando il collegamento \u00e8 disponibile, le policy si aggiornano. Durante disconnessione, uso le policy in cache con validazione di integrit\u00e0 via firma HMAC.<\/li>\n<\/ul>\n<p><code>apiVersion: networking.istio.io\/v1beta1<br \/>kind: VirtualService<br \/>metadata:<br \/>  name: edge-api-vs<br \/>  namespace: edge-ns<br \/>spec:<br \/>  hosts:<br \/>  - \"edge-api\"<br \/>\n  http:<br \/>  - match:<br \/>    - sourceLabels:<br \/>        app: \"authorized-client\"<br \/>      authority:<br \/>        prefix: \"edge-api.edge-ns.svc.cluster.local\"<br \/>    route:<br \/>    - destination:<br \/>        host: \"edge-api.edge-ns.svc.cluster.local\"<br \/>\n        port:<br \/>          number: 8080<\/code><\/p>\n<h2>Implementazione Pratica: Segmentazione a Microsegmenti<\/h2>\n<p>La vera implementazione richiede definire segmenti granulari, non solo &#8220;un servizio = un segmento&#8221;. <cite>L&#8217;architettura di micro-segmentazione service mesh opera su principi zero-trust dove ogni richiesta, anche tra servizi fidati, deve essere autenticata e autorizzata. Questo richiede una forte gestione dell&#8217;identit\u00e0 a livello di workload e traffico crittografato su tutte le connessioni. Il mesh applica le politiche senza richiedere agli sviluppatori di incorporare logica di sicurezza nel codice dell&#8217;applicazione<\/cite>.<\/p>\n<p>Nel mio deployment edge, ho definito questi segmenti:<\/p>\n<ol>\n<li><strong>Segmento 1: Data Ingestion<\/strong> \u2014 Sensori IoT \u2192 Gateway edge \u2192 Compute Cluster<\/li>\n<li><strong>Segmento 2: ML Inference<\/strong> \u2014 Compute Cluster \u2192 GPU Worker \u2192 Cache Storage<\/li>\n<li><strong>Segmento 3: External APIs<\/strong> \u2014 Edge Services \u2192 Public Cloud APIs \u2192 Logging<\/li>\n<\/ol>\n<p>Per ogni segmento, applico <em>authorization policies<\/em> esplicite:<\/p>\n<p><code>apiVersion: security.istio.io\/v1beta1<br \/>kind: AuthorizationPolicy<br \/>metadata:<br \/>  name: data-ingestion-policy<br \/>  namespace: edge-ns<br \/>spec:<br \/>  selector:<br \/>    matchLabels:<br \/>      segment: \"data-ingestion\"<br \/>  rules:<br \/>  - from:<br \/>    - source:<br \/>        principals: [\"cluster.local\/ns\/edge-ns\/sa\/iot-gateway\"]<br \/>    to:<br \/>    - operation:<br \/>        methods: [\"POST\"]<br \/>        paths: [\"\/api\/v1\/ingest*\"]<br \/>    when:<br \/>    - key: request.auth.claims[device_id]<br \/>      notValues: [\"spoofed\"]<\/code><\/p>\n<h2>Sfide Che Ho Incontrato e Soluzioni<\/h2>\n<h3>Sfida 1: Latenza Policy Enforcement<\/h3>\n<p>Inizialmente, ogni richiesta attendeva una verifica dal PDP centrale. In ambienti edge con latenza di rete elevata, questo era inaccettabile (aggiungevamo 200-500ms per richiesta).<\/p>\n<p><strong>Soluzione:<\/strong> Ho implementato <strong>policy caching con TTL breve<\/strong> sui PEP locali. <cite>Le applicazioni distribuite (dApps) hanno visibilit\u00e0 diretta nel traffico del piano utente e nella telemetria di livello inferiore, potendo funzionare come highly responsive, decentralized PEPs che consentono decisioni di sicurezza istantanee e stateful, come drop di pacchetti anomali o isolamento di UEs compromessi in timescale sub-10ms<\/cite>. Nel mio caso, ho ridotto questo a ~50ms con decision caching.<\/p>\n<h3>Sfida 2: Sincronizzazione Policy in Ambienti Disconnessi<\/h3>\n<p>Un nodo edge poteva disconnettersi dal centro per giorni. Come assicurare che le policy fossero ancora valide?<\/p>\n<p><strong>Soluzione:<\/strong> Ho firmato ogni policy snapshot con un timestamp e una firma HMAC-SHA256. <cite>L&#8217;edge computing gioca un ruolo centrale nella sicurezza IoT decentralizzata portando computazione, archiviazione e decision-making pi\u00f9 vicino ai dispositivi. Questo riduce la dipendenza dai server cloud, abbassa la latenza e abilita l&#8217;enforcement locale delle politiche di trust e sicurezza. I nodi edge eseguono frequentemente task quali preprocessing dei dati, analisi del comportamento, anomaly detection, controllo di accesso e valutazione del trust<\/cite>.<\/p>\n<p><code>def verify_policy_freshness(policy_doc, hmac_key, max_age_hours=24):<br \/>    policy_age = datetime.now() - datetime.fromisoformat(policy_doc['issued_at'])<br \/>    if policy_age.total_seconds() &gt; max_age_hours * 3600:<br \/>        return False, \"Policy expired\"<\/p>\n<p>    computed_hmac = hmac.new(<br \/>        key=hmac_key.encode(),<br \/>        msg=json.dumps(policy_doc['rules'], sort_keys=True).encode(),<br \/>        digestmod=hashlib.sha256<br \/>    ).hexdigest()<\/p>\n<p>    if not hmac.compare_digest(computed_hmac, policy_doc['signature']):<br \/>        return False, \"Invalid signature\"<\/p>\n<p>    return True, \"Policy valid\"<\/code><\/p>\n<h3>Sfida 3: Identit\u00e0 in Ambienti Eterogenei<\/h3>\n<p>Nel mio edge cluster, avevo container Kubernetes, VM tradizionali, dispositivi IoT bare-metal e persino dispositivi firmware-only. Come assegno un&#8217;identit\u00e0 coerente?<\/p>\n<p><strong>Soluzione:<\/strong> Ho creato un <em>Workload Identity Mapper<\/em> che associa ogni endpoint (indipendentemente dal tipo) a un identifier univoco basato su <strong>hardware fingerprint + digital cert<\/strong>. Per container: uso il service account Kubernetes. Per VM: uso il certificato del sistema fornito da cloud-init. Per IoT: uso il certificato del dispositivo pre-installato in produzione.<\/p>\n<p><code>type WorkloadIdentity struct {<br \/>    WorkloadID      string    \/\/ unique identifier<br \/>    Type            string    \/\/ container|vm|iot|firmware<br \/>    CertFingerprint string    \/\/ SHA256(cert)<br \/>    HWFingerprint   string    \/\/ TPM-based or fixed<br \/>    IssuedAt        time.Time<br \/>    ExpiresAt       time.Time<br \/>    Attributes      map[string]string<br \/>}<\/code><\/p>\n<h2>Monitoraggio e Osservabilit\u00e0 Zero-Trust<\/h2>\n<p>Senza visibilit\u00e0, non puoi validare che zero-trust funzioni. Ho configurato:<\/p>\n<ul>\n<li><strong>mTLS Certificate Metrics:<\/strong> Rotazione, scadenze imminenti, handshake failures \u2014 tutto tracciato.<\/li>\n<li><strong>Policy Decision Logging:<\/strong> Ogni allow\/deny policy \u00e8 loggato con context (source identity, resource, action, reason).<\/li>\n<li><strong>Anomaly Detection:<\/strong> Uso Prometheus + custom alerting per rilevare pattern anormali (es., un servizio che improvvisamente accede a resource a cui non dovrebbe accedere).<\/li>\n<\/ul>\n<p>La query Prometheus che uso per verificare la salute mTLS:<\/p>\n<p><code>rate(envoy_ssl_handshake_failure{env=\"edge\"}[5m]) &gt; 0<\/code><\/p>\n<p>Questo mi avvisa se il tasso di handshake failure aumenta, suggerendo misconfiguration o attacco.<\/p>\n<h2>Collegamento con le Architetture Esistenti<\/h2>\n<p>Nel mio ambiente, ho dovuto integrare questo zero-trust edge con altre componenti. Se stai lavorando con <a href=\"https:\/\/darioiannascoli.it\/blog\/ai-safety-layers-autonomous-agents-network-isolation-guardrails-2026\/\">autonomous agents con network isolation<\/a>, la segmentazione decentralizzata diventa ancor pi\u00f9 critica per evitare lateral movement. Similmente, se esegui <a href=\"https:\/\/darioiannascoli.it\/blog\/multimodal-llm-inference-optimization-vision-transformer-quantization-kv-cache-edge-deployment\/\">LLM inference su edge con ottimizzazione latenza<\/a>, il caching di policy locale che ho descritto riduce l&#8217;overhead di verification.<\/p>\n<p>Per quanto riguarda vulnerabilit\u00e0 edge, se gestisci la <a href=\"https:\/\/darioiannascoli.it\/blog\/cve-2026-70250-dhcp-use-after-free-memory-tagging-network-segmentation\/\">mitigation di CVE-2026-70250 DHCP<\/a>, la segmentazione zero-trust assicura che anche se un nodo DHCP \u00e8 compromesso, l&#8217;accesso laterale \u00e8 bloccato da policy enforcement.<\/p>\n<h2>FAQ<\/h2>\n<h3>Come differisce BeyondProd da BeyondCorp per l&#8217;edge?<\/h3>\n<p><cite>Mentre BeyondCorp afferma che la fiducia dell&#8217;utente dipende da caratteristiche come lo stato contestuale dei dispositivi e non dalla capacit\u00e0 di connettersi alla rete corporate, BeyondProd afferma che la fiducia del servizio dipende da caratteristiche come la provenienza del codice e l&#8217;identit\u00e0 del servizio, non dalla posizione nella rete di produzione<\/cite>. Per l&#8217;edge, significa verificare i servizi (microservizi, agent) piuttosto che gli utenti finali.<\/p>\n<h3>Posso implementare zero-trust senza service mesh?<\/h3>\n<p>Tecnicamente s\u00ec, ma diventa molto pi\u00f9 complesso. Dovrai implementare manualment\u200be mutual TLS, policy enforcement, e monitoring in ogni applicazione. Un service mesh come Istio o Linkerd automatizza questo a livello infrastrutturale. Per l&#8217;edge, consiglio almeno un service mesh leggero.<\/p>\n<h3>Quale \u00e8 il costo di performance di zero-trust segmentation?<\/h3>\n<p>Nel mio setup, l&#8217;overhead mTLS \u00e8 ~5-15ms per connessione. Policy lookup cacheato \u00e8 &lt;1ms. Su reti edge con latenza baseline di 50-200ms, \u00e8 trascurabile. Se hai latenza ultra-bassa (&lt;1ms), potrebbe essere visibile. Soluzioni: aumentare TTL di policy cache (accettando slight staleness) o parallelizzare policy checks.<\/p>\n<h3>Come ruoto i certificati service mesh su nodi offline?<\/h3>\n<p>Durante disconnessione, i PEP usano certificati cached con TTL esteso (di solito 72 ore). Prima che scadano, devi ricollegare il nodo. Se prevedibile, pre-ruota i certificati ~1 settimana prima della scadenza. Per offline prolungati, pre-provisiona certificati bundle nel nodo prima di scollegarlo.<\/p>\n<h3>Posso monitorare traffico criptato con zero-trust?<\/h3>\n<p>S\u00ec, ma diversamente. Non puoi ispezionare payload (\u00e8 criptato end-to-end), ma puoi loggare metadata: source identity, destination service, ports, protocol, duration. Questo \u00e8 sufficiente per anomaly detection nel 90% dei casi. Se hai requisiti DLP (data loss prevention), dovrai decryptare nel PEP con caution sulla privacy.<\/p>\n<h2>Conclusione<\/h2>\n<p>Implementare zero-trust network segmentation per edge computing non \u00e8 una configurazione one-shot. Ho imparato che richiede tre cose: <strong>identit\u00e0 distribuita<\/strong> (code provenance + service certs + hardware attestation), <strong>autenticazione mesh granulare<\/strong> (mTLS STRICT + request authorization basata su identity), e <strong>policy enforcement decentralizzato<\/strong> (local PDP\/PEP con sync asincrono dal centro).<\/p>\n<p>La procedura che ho condiviso \u00e8 stata testata in produzione su ~200 nodi edge in varie condizioni di connettivit\u00e0. Se implementi anche tu, inizia da un singolo segmento non-critico, valida il comportamento per 2-3 settimane, poi espandi. <cite>La complessit\u00e0 di identity e access management aumenta negli ambienti edge dove dispositivi, applicazioni e utenti operano tra pi\u00f9 domini amministrativi, l&#8217;assenza di protocolli standardizzati di federation identit\u00e0 specifici per edge computing crea challenge di interoperabilit\u00e0, e le organizzazioni incontrano frequentemente difficolt\u00e0 nel mantenere l&#8217;applicazione coerente di policy su infrastruttura edge eterogenea<\/cite>. Sii paziente, documenta tutto e monitora continuamente.<\/p>\n<p><strong>Vuoi condividere la tua esperienza con zero-trust edge? Commenta qui sotto il tuo approccio o le challenge che hai incontrato!<\/strong><\/p>\n","protected":false},"excerpt":{"rendered":"<p>Implementa zero-trust network segmentation su edge computing con BeyondProd architecture, service mesh mTLS e policy enforcement decentralizzato. Guida pratica con codice.<\/p>\n","protected":false},"author":1,"featured_media":7446,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_seopress_titles_title":"Zero-Trust Edge Computing: BeyondProd Service Mesh | Dario","_seopress_titles_desc":"Come costruire zero-trust segmentation per edge con BeyondProd, service mesh authentication e decentralized policy. Implementazione pratica con Istio e Envoy.","_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":"Zero-Trust Edge Computing: BeyondProd Service Mesh | Dario","_seopress_social_fb_desc":"Come costruire zero-trust segmentation per edge con BeyondProd, service mesh authentication e decentralized policy. Implementazione pratica con Istio e Envoy.","_seopress_social_fb_img":"https:\/\/darioiannascoli.it\/blog\/wp-content\/uploads\/2026\/10\/come-costruire-zero-trust-network-segmentation-per-edge-computing-environments-la-mia-procedura-beyondprod-architecture-1793210555.jpg","_seopress_social_fb_img_attachment_id":0,"_seopress_social_fb_img_width":0,"_seopress_social_fb_img_height":0,"_seopress_social_twitter_title":"Zero-Trust Edge Computing: BeyondProd Service Mesh | Dario","_seopress_social_twitter_desc":"Come costruire zero-trust segmentation per edge con BeyondProd, service mesh authentication e decentralized policy. Implementazione pratica con Istio e Envoy.","_seopress_social_twitter_img":"https:\/\/darioiannascoli.it\/blog\/wp-content\/uploads\/2026\/10\/come-costruire-zero-trust-network-segmentation-per-edge-computing-environments-la-mia-procedura-beyondprod-architecture-1793210555.jpg","_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":"zero-trust edge computing network segmentation,BeyondProd architecture implementation,service mesh mTLS authentication policy enforcement,decentralized policy enforcement edge nodes,network microsegmentation edge environments","footnotes":""},"categories":[5],"tags":[1502,407,853,1504,1503,766],"class_list":["post-7445","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-assistenza-computer","tag-beyondprod","tag-edge-computing","tag-network-segmentation","tag-security-architecture","tag-service-mesh","tag-zero-trust"],"_links":{"self":[{"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/posts\/7445","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=7445"}],"version-history":[{"count":0,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/posts\/7445\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/media\/7446"}],"wp:attachment":[{"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/media?parent=7445"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/categories?post=7445"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/tags?post=7445"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}