[{"data":1,"prerenderedAt":1394},["ShallowReactive",2],{"sc:header-data-it":3,"sc:footer-data-it":489,"author-it-jan-geisbauer-d67b39f1391e5":518,"content-it-jan-geisbauer":548,"content-events-it-jan-geisbauer":1377,"authors_data:Jan Geisbauer":1378},{"lang":4,"home":5,"navigation":17,"meta":479,"contact":485},"de",{"name":6,"folderSwitch":7,"imgLight":10,"img":11,"languages":12},"home",[8,9],"authors","blog","/logos/gk-Logo-sw.svg","/logos/gk-Logo-rgb.svg",{"it":13},{"title":14,"url":15,"alt":16},"Home","/it","glueckkanja Logo",[18,127,231,316,395,402],{"name":19,"languages":20,"children":24},"workplace",{"it":21},{"title":22,"description":23},"Workplace","Basato su Microsoft 365 per postazioni di lavoro intelligenti, sicure e flessibili, con integrazione di tecnologie moderne e servizi di identità.",[25,55,91],{"name":26,"languages":27,"children":30},"portfolio",{"it":28},{"title":29},"Portfolio",[31,37,43,49],{"name":32,"languages":33},"managed-intune",{"it":34},{"title":35,"url":36},"Managed Intune","/it/entra-intune/managed-intune",{"name":38,"languages":39},"managed-entra",{"it":40},{"title":41,"url":42},"Managed Entra","/it/entra-intune/managed-entra",{"name":44,"languages":45},"managed-workplace",{"it":46},{"title":47,"url":48},"Managed Workplace","/it/workplace/managed-workplace",{"name":50,"languages":51},"consulting-services",{"it":52},{"title":53,"url":54},"Consulting Services","/it/workplace/consulting-services",{"name":56,"languages":57,"children":60},"microsoft-365-endpoint",{"it":58},{"title":59},"Microsoft 365 Endpoint",[61,67,73,79,85],{"name":62,"languages":63},"microsoft-entra-suite",{"it":64},{"title":65,"url":66},"Microsoft Entra Suite","/it/workplace/microsoft-entra-suite",{"name":68,"languages":69},"microsoft-intune",{"it":70},{"title":71,"url":72},"Microsoft Intune","/it/workplace/microsoft-intune",{"name":74,"languages":75},"microsoft-windows",{"it":76},{"title":77,"url":78},"Microsoft Windows","/it/workplace/microsoft-windows",{"name":80,"languages":81},"windows-365-cloud-pc",{"it":82},{"title":83,"url":84},"Windows 365 Cloud PC","/it/workplace/windows365-cloud-pc",{"name":86,"languages":87},"cloud-workplace-foundation",{"it":88},{"title":89,"url":90},"Cloud Workplace Foundation","/it/workplace/cloud-workplace-foundation",{"name":92,"languages":93,"children":96},"microsoft-365-collaboration",{"it":94},{"title":95},"Microsoft 365 Collaboration",[97,103,109,115,121],{"name":98,"languages":99},"microsoft-copilot",{"it":100},{"title":101,"url":102},"Microsoft 365 Copilot","/it/workplace/microsoft-365-copilot",{"name":104,"languages":105},"microsoft-teams",{"it":106},{"title":107,"url":108},"Teams","/it/workplace/microsoft-teams",{"name":110,"languages":111},"sharepoint-powerplatform",{"it":112},{"title":113,"url":114},"SharePoint & Power Platform","/it/workplace/sharepoint-power-platform",{"name":116,"languages":117},"exchange-online",{"it":118},{"title":119,"url":120},"Exchange Online","/it/workplace/exchange-online",{"name":122,"languages":123},"information-protection-compliance",{"it":124},{"title":125,"url":126},"Information Protection & Compliance","/it/workplace/information-protection-compliance",{"name":128,"languages":129,"children":133},"azure",{"it":130},{"title":131,"description":132},"Azure","Crescita con Azure: riduci i costi cloud, aumenta l'efficienza e spingi l'innovazione con IaaS e PaaS.",[134,151,181],{"name":135,"languages":136,"children":138},"azure-portfolio",{"it":137},{"title":29},[139,145],{"name":140,"languages":141},"azure-managed-services",{"it":142},{"title":143,"url":144},"Azure Managed Services","/it/azure/azure-managed-services",{"name":146,"languages":147},"azure-consulting",{"it":148},{"title":149,"url":150},"Azure Consulting","/it/azure/azure-consulting",{"name":152,"languages":153,"children":156},"azure-scenarios",{"it":154},{"title":155},"Scenari",[157,163,169,175],{"name":158,"languages":159},"plan-your-cloud",{"it":160},{"title":161,"url":162},"Pianifica il tuo cloud","/it/azure/plan-your-cloud",{"name":164,"languages":165},"migrate-to-the-cloud",{"it":166},{"title":167,"url":168},"Migra al cloud","/it/azure/migrate-to-the-cloud",{"name":170,"languages":171},"innovate-your-business",{"it":172},{"title":173,"url":174},"Innova la tua azienda","/it/azure/innovate-your-business",{"name":176,"languages":177},"vmware-exit",{"it":178},{"title":179,"url":180},"Ripensa la tua strategia VMware","/it/azure/vmware-exit",{"name":182,"languages":183,"children":186},"azure-practices",{"it":184},{"title":185},"Practices",[187,193,199,202,208,213,219,225],{"name":188,"languages":189},"azure-foundation",{"it":190},{"title":191,"url":192},"Azure Foundation","/it/azure/azure-foundation",{"name":194,"languages":195},"azure-ai-foundation",{"it":196},{"title":197,"url":198},"Azure AI Foundation","/it/azure/azure-ai-foundation",{"name":86,"languages":200},{"it":201},{"title":89,"url":90},{"name":203,"languages":204},"azure-data-foundation",{"it":205},{"title":206,"url":207},"Azure Data Foundation","/it/azure/azure-data-foundation",{"name":188,"languages":209},{"it":210},{"title":211,"url":212},"Azure Container Foundation","/it/azure/azure-container-foundation",{"name":214,"languages":215},"dark-tenant",{"it":216},{"title":217,"url":218},"Managed Dark Tenant","/it/azure/managed-dark-tenant",{"name":220,"languages":221},"azure-cloud-adoption-framework",{"it":222},{"title":223,"url":224},"Cloud Adoption Framework","/it/azure/cloud-adoption-framework",{"name":226,"languages":227},"azure-cloud-competence-center",{"it":228},{"title":229,"url":230},"Cloud Competence Center","/it/azure/cloud-competence-center",{"name":232,"languages":233,"children":242},"security",{"it":234},{"title":235,"description":236,"emergency":237},"Security","Vigilanza nel cloud con un managed service 24/7 pluripremiato, incident response e protezione moderna per la tua infrastruttura.",{"text":238,"href":239,"skin":240,"icon":241},"Sotto attacco?","/it/security/are-you-under-attack","primary","emergency",[243,268,289],{"name":244,"children":245},"security-security-consulting",[246,252,256,262],{"name":247,"languages":248},"managed-red-tenant",{"it":249},{"title":250,"url":251},"Managed Red Tenant","/it/security/managed-red-tenant",{"name":214,"languages":253},{"it":254},{"title":255,"url":218},"Dark Tenant",{"name":257,"languages":258},"sentinel-data-lake",{"it":259},{"title":260,"url":261},"Sentinel Data Lake","/it/security/sentinel-data-lake",{"name":263,"languages":264},"security-consulting",{"it":265},{"title":266,"url":267},"Security Consulting","/it/security/security-consulting",{"name":269,"children":270},"security-cloud-security-operations-center",[271,277,283],{"name":272,"languages":273},"cloud-security-operations-center",{"it":274},{"title":275,"url":276},"Cloud Security Operations Center","/it/security/cloud-security-operations-center",{"name":278,"languages":279},"global-secure-access",{"it":280},{"title":281,"url":282},"Global Secure Access","/it/security/global-secure-access",{"name":284,"languages":285},"my-work-id",{"it":286},{"title":287,"url":288},"MyWorkID","/it/security/my-work-id",{"name":290,"children":291},"security-preventive-services",[292,298,304,310],{"name":293,"languages":294},"preventive-services",{"it":295},{"title":296,"url":297},"Preventive Services","/it/security/preventive-services",{"name":299,"languages":300},"data-security-services",{"it":301},{"title":302,"url":303},"Data Security Service","/it/security/data-security-service",{"name":305,"languages":306},"security-copilot-agents",{"it":307},{"title":308,"url":309},"Security Copilot Agents","/it/security/security-copilot-agents",{"name":311,"languages":312},"nis2",{"it":313},{"title":314,"url":315},"Implementazione di NIS2","/it/security/red-dark-tenant-nis2",{"name":317,"languages":318,"children":322},"products",{"it":319},{"title":320,"description":321},"Prodotti","Prodotti complementari per un ambiente Microsoft sicuro e 100 % cloud-native, che rafforzano la collaborazione, l'autenticazione di rete e la gestione software.",[323,360],{"name":324,"products":325,"children":326},"lorem ipsum 1",true,[327,336,344,352],{"name":328,"img":329,"target":330,"languages":331},"realmjoin","products/realmjoin/realmjoin-nav-logo.svg","_blank",{"it":332},{"title":333,"url":334,"subtitle":335},"RealmJoin","https://www.realmjoin.com","Distribuzione software dal cloud",{"name":337,"img":338,"target":330,"languages":339},"scepman","products/scepman/scepman-nav-logo.svg",{"it":340},{"title":341,"url":342,"subtitle":343},"SCEPman","https://www.scepman.com","Distribuzione dei certificati dal cloud",{"name":345,"img":346,"target":330,"languages":347},"konnekt","products/konnekt/konnekt-nav-logo.svg",{"it":348},{"title":349,"url":350,"subtitle":351},"KONNEKT","https://www.konnekt.io","Lavora con i tuoi dati locali di Office 365",{"name":353,"img":354,"target":330,"languages":355},"realmigrator","products/realmigrator/realmigrator-nav-logo.svg",{"it":356},{"title":357,"url":358,"subtitle":359},"RealMigrator","https://www.realmigrator.com","Migra i dati da un server all'altro",{"name":361,"products":325,"children":362},"lorem ipsum 2",[363,371,379,387],{"name":364,"img":365,"target":330,"languages":366},"terraprovider","products/terraprovider/terraprovider-nav-logo.svg",{"it":367},{"title":368,"url":369,"subtitle":370},"TerraProvider","https://www.terraprovider.com","Terraform Provider for Microsoft 365",{"name":372,"img":373,"target":330,"languages":374},"radiusaas","products/radius/radius-nav-logo.svg",{"it":375},{"title":376,"url":377,"subtitle":378},"RADIUSaaS","https://www.radius-as-a-service.com","Autenticazione per la tua rete",{"name":380,"img":381,"target":330,"languages":382},"unifiedcontacts","products/unified-contacts/unifiedcontact-nav-logo.svg",{"it":383},{"title":384,"url":385,"subtitle":386},"Unified Contacts","https://www.unified-contacts.com","Trova contatti in Microsoft Teams",{"name":388,"img":389,"target":330,"languages":390},"autopilotmonitor","products/autopilot-monitor/AutopilotMonitor-nav-logo.svg",{"it":391},{"title":392,"url":393,"subtitle":394},"Autopilot Monitor","https://www.autopilotmonitor.com","Monitoraggio di Windows Autopilot in tempo reale",{"name":396,"languages":397},"casestudies",{"it":398},{"title":399,"url":400,"description":401},"Case Studies","/it/casestudies","Pioniere nel cloud: il tuo Microsoft partner di riferimento per soluzioni cloud con un approccio blueprint-based e competenza in Infrastructure-as-Code.",{"name":403,"languages":404,"children":407},"company",{"it":405},{"title":406,"description":401},"Azienda",[408,438,462],{"name":409,"languages":410,"children":413},"company-about-us",{"it":411},{"title":412},"Chi siamo",[414,420,426,432],{"name":415,"languages":416},"company-facts-figures",{"it":417},{"title":418,"url":419},"Fatti e numeri","/it/company/facts-and-figures",{"name":421,"languages":422},"company-contact",{"it":423},{"title":424,"url":425},"Contatti e sedi","/it/company/contact-and-locations",{"name":427,"languages":428},"switzerland",{"it":429},{"title":430,"url":431}," glueckkanja Switzerland","/it/company/switzerland",{"name":433,"languages":434},"austria",{"it":435},{"title":436,"url":437},"glueckkanja Austria","/it/company/austria",{"name":439,"languages":440,"children":443},"company-career",{"it":441},{"title":442},"Carriera",[444,450,456],{"name":445,"languages":446},"company-career-overview",{"it":447},{"title":448,"url":449},"Panoramica carriera","/it/career",{"name":451,"languages":452},"company-young-professionals",{"it":453},{"title":454,"url":455},"Young Professionals","/it/young-professionals",{"name":457,"languages":458},"company-jobs",{"it":459},{"title":460,"url":461},"Offerte di lavoro","/it/job-offers",{"name":463,"languages":464,"children":467},"company-latest",{"it":465},{"title":466},"Novità",[468,474],{"name":469,"languages":470},"company-blog",{"it":471},{"title":472,"url":473},"Blog","/it/blog",{"name":469,"languages":475},{"it":476},{"title":477,"url":478},"Eventi","/it/events",[480],{"name":481,"languages":482},"career-meta",{"it":483},{"title":442,"url":449,"active":484},false,{"languages":486},{"it":487},{"title":488,"url":425,"active":484},"Contatti",{"data":490},{"bgColor":491,"number":492,"mail":493,"brandLogos":494,"logos":495,"links":499,"linksIt":509},"var(--color-gk-mid-blue)","+49 69 4005520","info@glueckkanja.com",null,[496],{"img":10,"alt":16,"url":497,"class":498},"index.html","max-w-19rem",[500,503,506],{"title":501,"url":502},"Datenschutz","/de/privacy",{"title":504,"url":505},"Impressum","/de/imprint",{"title":507,"url":508},"No Cookies","/de/cookies",[510,513,516],{"title":511,"url":512},"Privacy","/it/privacy",{"title":514,"url":515},"Imprint","/it/imprint",{"title":507,"url":517},"/it/cookies",{"id":519,"title":520,"body":521,"description":527,"extension":532,"meta":533,"name":520,"navigation":325,"otherLanguages":534,"path":544,"seo":545,"stem":546,"__hash__":547},"authors/jan-geisbauer.md","Jan Geisbauer",{"type":522,"value":523,"toc":528},"minimal",[524],[525,526,527],"p",{},"Seit über 20 Jahren beschäftigt sich Jan Geisbauer beruflich mit Microsoft-Technologien. Die meiste Zeit davon als Consultant bei glueckkanja. Heute leitet er das Security Team, zu dem einige der erfahrensten Security Experten der Branche gehören. Als Microsoft Security MVP baut er Brücken zwischen den Security Produkt-Gruppen und den Experten bei glueckkanja. Zusammen mit seinem Kollegen Marco Scheel veranstaltet er einen der erfolgreichsten deutschen Podcasts rund um Microsoft-Technologie: Hairless in the Cloud.",{"title":529,"searchDepth":530,"depth":530,"links":531},"",2,[],"md",{},{"en":535,"es":536,"sv":537,"fi":538,"da":539,"ko":540,"nl":541,"no":542,"ja":543},"Jan Geisbauer has been professionally involved with Microsoft technologies for over 20 years. Most of this time as a consultant at glueckkanja. Today, he leads the Security Team, which includes some of the most experienced security experts in the industry. As Microsoft Security MVP, he builds bridges between the security product groups and the experts at glueckkanja. Together with his colleague Marco Scheel, he hosts one of the most successful German podcasts about Microsoft technology: Hairless in the Cloud.","Jan Geisbauer trabaja profesionalmente con tecnologías de Microsoft desde hace más de 20 años, la mayor parte de ese tiempo como Consultant en glueckkanja. Hoy dirige el Security Team, del que forman parte algunos de los expertos en seguridad más experimentados del sector. Como Microsoft Security MVP, tiende puentes entre los grupos de producto de seguridad y los expertos de glueckkanja. Junto con su compañero Marco Scheel produce uno de los podcasts alemanes de mayor éxito sobre tecnología de Microsoft: Hairless in the Cloud.","Jan Geisbauer har arbetat professionellt med Microsoft-teknik i över 20 år, större delen av tiden som Consultant på glueckkanja. I dag leder han Security Team, som består av några av branschens mest erfarna säkerhetsexperter. Som Microsoft Security MVP bygger han broar mellan säkerhetsproduktgrupperna och experterna på glueckkanja. Tillsammans med sin kollega Marco Scheel driver han en av de mest framgångsrika tyska poddarna om Microsoft-teknik: Hairless in the Cloud.","Jan Geisbauer on työskennellyt Microsoft-teknologioiden parissa jo yli 20 vuoden ajan, suurimman osan siitä ajasta Consultant-roolissa glueckkanjalla. Nykyään hän johtaa Security Teamia, johon kuuluu joitakin alan kokeneimmista tietoturva-asiantuntijoista. Microsoft Security MVP:nä hän rakentaa siltoja tietoturvatuoteryhmien ja glueckkanjan asiantuntijoiden välille. Yhdessä kollegansa Marco Scheelin kanssa hän tuottaa yhtä menestyneimmistä saksalaisista Microsoft-teknologiaan keskittyvistä podcasteista: Hairless in the Cloud.","Jan Geisbauer har i over 20 år arbejdet professionelt med Microsoft-teknologier, størstedelen af tiden som Consultant hos glueckkanja. I dag leder han Security Team, som tæller nogle af branchens mest erfarne sikkerhedseksperter. Som Microsoft Security MVP bygger han bro mellem sikkerhedsproduktgrupperne og eksperterne hos glueckkanja. Sammen med sin kollega Marco Scheel står han bag en af de mest succesfulde tyske podcasts om Microsoft-teknologi: Hairless in the Cloud.","Jan Geisbauer는 20년 넘게 Microsoft 기술 분야에서 전문적으로 일해 왔으며, 그 대부분의 기간을 glueckkanja의 Consultant로 보냈습니다. 현재는 업계에서 가장 경험이 풍부한 보안 전문가들이 속해 있는 Security Team을 이끌고 있습니다. Microsoft Security MVP로서 그는 보안 제품 그룹과 glueckkanja의 전문가들 사이에서 가교 역할을 합니다. 동료 Marco Scheel과 함께 Microsoft 기술을 다루는 독일에서 가장 성공적인 팟캐스트 중 하나인 Hairless in the Cloud를 운영하고 있습니다.","Jan Geisbauer werkt al meer dan 20 jaar beroepsmatig met Microsoft-technologieën, het grootste deel daarvan als Consultant bij glueckkanja. Vandaag leidt hij het Security Team, waartoe enkele van de meest ervaren security experts van de branche behoren. Als Microsoft Security MVP bouwt hij bruggen tussen de security productgroepen en de experts bij glueckkanja. Samen met zijn collega Marco Scheel maakt hij een van de succesvolste Duitse podcasts over Microsoft-technologie: Hairless in the Cloud.","Jan Geisbauer har jobbet profesjonelt med Microsoft-teknologier i over 20 år, mesteparten av tiden som konsulent hos glueckkanja. I dag leder han Security-teamet, som består av noen av bransjens mest erfarne security-eksperter. Som Microsoft Security MVP bygger han bro mellom Microsofts security-produktgrupper og ekspertene hos glueckkanja. Sammen med kollegaen Marco Scheel driver han en av de mest suksessrike tyske podkastene om Microsoft-teknologi: Hairless in the Cloud.","Jan Geisbauerは20年以上にわたり、仕事としてMicrosoftの技術に取り組んできました。その大半はglueckkanjaのコンサルタントとしてです。現在は、業界でも屈指の経験を持つセキュリティ専門家が集まるSecurity Teamを率いています。Microsoft Security MVPとして、Microsoftのセキュリティ製品グループとglueckkanjaの専門家をつなぐ役割も担っています。同僚のMarco Scheelとともに、Microsoftの技術を扱うドイツで最も成功しているポッドキャストの一つ「Hairless in the Cloud」を制作しています。","/jan-geisbauer",{"title":520,"description":527},"jan-geisbauer","dkj56BbDIjLEIV9w-pzPM-QPN_dHwnhULkWaoQUDOWE",[549,901,1196],{"id":550,"title":551,"author":552,"body":553,"cta":494,"description":557,"eventid":494,"extension":532,"hideInRecent":484,"layout":809,"meta":810,"moment":814,"navigation":325,"path":894,"seo":895,"stem":896,"tags":897,"webcast":484,"__hash__":900},"content_it/posts/2026-03-20-stryker-attack-intune-privilege.md","Bastava un account admin.",[520],{"type":522,"value":554,"toc":796},[555,558,561,566,569,572,575,579,581,584,587,590,593,597,599,602,605,609,611,614,617,620,624,626,629,636,641,644,651,654,657,660,667,670,677,688,692,694,699,702,712,715,718,721,724,727,730,734,736,739,742,745,753,756,759,763,765],[525,556,557],{},"Mercoledì 11 marzo 2026. I dipendenti negli uffici Stryker di 79 paesi hanno acceso i loro computer e li hanno trovati vuoti. Schermate di login sostituite da un logo. Laptop aziendali, telefoni di servizio, dispositivi personali registrati nel programma BYOD dell'azienda, tutti cancellati simultaneamente, nel corso di una notte. Nessun ransomware, nessuna firma malware, nulla che uno strumento di endpoint detection avrebbe potuto rilevare.",[525,559,560],{},"L'attaccante, un gruppo hacktivista pro-iraniano chiamato Handala, aveva trasformato in arma la stessa infrastruttura di IT management di Stryker.",[562,563,565],"h2",{"id":564},"cosè-successo-davvero","Cos'è successo davvero",[525,567,568],{},"{: .h3-font-size}",[525,570,571],{},"Il cuore dell'attacco non è stato un exploit sofisticato o una vulnerabilità zero-day, ma qualcosa di molto più semplice e molto più comune: un account amministratore è stato compromesso, e quell'account aveva accesso a Microsoft Intune.",[525,573,574],{},"Secondo i report di BleepingComputer, circa 80.000 dispositivi sono stati cancellati tra le 5:00 e le 8:00 UTC. Handala ha rivendicato che il numero superava i 200.000, inclusi server e dispositivi mobili nelle operazioni globali dell'azienda in 79 paesi. Un attacco eseguito esclusivamente attraverso una console di management legittima.",[562,576,578],{"id":577},"perché-questo-attacco-ha-avuto-successo","Perché questo attacco ha avuto successo",[525,580,568],{},[525,582,583],{},"Alla radice di questo incidente c'è un problema strutturale che non è specifico di Stryker. Riguarda la maggior parte delle aziende.",[525,585,586],{},"La maggior parte delle organizzazioni tratta le attività amministrative e il lavoro quotidiano come attività che possono coesistere senza problemi sullo stesso dispositivo, sotto la stessa identità utente. Un amministratore IT risponde alle email, naviga in internet, occasionalmente clicca su un link e dalla stessa sessione, sullo stesso dispositivo, gestisce infrastruttura cloud, approva modifiche di accesso o, come in questo caso, tocca una console di gestione dispositivi con l'autorizzazione di cancellare l'intera flotta.",[525,588,589],{},"Questa è la superficie di attacco. Quando il contesto di lavoro quotidiano e il contesto amministrativo privilegiato condividono un endpoint comune e un'identità comune, ogni compromissione di quell'endpoint diventa automaticamente una compromissione di tutto ciò che quell'identità può raggiungere. Phishing, furto di credenziali tramite malware infostealer, furto di token di sessione via Adversary-in-the-Middle (AiTM), tutto questo diventa un percorso diretto verso i controlli più potenti dell'ambiente. Nessuna privilege escalation necessaria. L'attaccante utilizza semplicemente ciò che è già presente.",[525,591,592],{},"Nel caso di Stryker, quell'accesso comprendeva un tenant Intune che gestiva dispositivi in sei continenti.",[562,594,596],{"id":595},"cisa-ne-ha-visto-abbastanza","CISA ne ha visto abbastanza",[525,598,568],{},[525,600,601],{},"La portata e l'audacia dell'attacco hanno provocato una reazione inusuale: CISA, la Cybersecurity and Infrastructure Security Agency statunitense, ha pubblicato linee guida che affrontano direttamente il rischio di piattaforme di gestione dispositivi compromesse. L'agenzia ha confermato di conoscere il vettore di attacco e ha invitato le organizzazioni ad adottare misure concrete, come assicurarsi che funzioni Intune ad alto rischio, come la cancellazione dei dispositivi, richiedano l'approvazione di un secondo amministratore prima di essere eseguite.",[525,603,604],{},"È un segnale raro e significativo. Quando un'agenzia federale per la sicurezza emette linee guida mirate immediatamente dopo un incidente concreto, il messaggio è chiaro: non è un caso isolato. È un pattern, e altre organizzazioni sono con alta probabilità esposte allo stesso rischio.",[562,606,608],{"id":607},"la-separazione-non-è-un-lusso-è-il-controllo","La separazione non è un lusso. È il controllo.",[525,610,568],{},[525,612,613],{},"L'attacco Stryker mostra con chiarezza quale portata possa avere un modello di privilege piatto. L'attaccante non ha dovuto scalare privilegi attraverso una catena di vulnerabilità. Ha ottenuto accesso a credenziali o a un token di sessione a un solo livello e ha scoperto che quel livello era già sufficiente per causare danni catastrofici, globali e irreversibili.",[525,615,616],{},"La risposta architetturale a questo problema ha un nome: il Microsoft Enterprise Access Model (EAM). Il suo principio fondamentale è l'amministrazione a livelli: le operazioni privilegiate vengono eseguite con account dedicati e dispositivi dedicati, rigorosamente separati dal contesto di lavoro quotidiano. Questo approccio least-privilege significa che un account di produttività compromesso non può raggiungere il livello di management, e un account di management compromesso non può eseguire operazioni sul control plane. Vale allo stesso modo per ambienti puramente cloud e per setup ibridi, compresa la connessione on-premises ad Active Directory tramite Entra ID, dove un singolo account sovra-privilegiato può ancora collegare cloud e dominio.",[525,618,619],{},"L'idea è semplice. Il lavoro amministrativo avviene su dispositivi amministrativi. L'identità utilizzata per gestire il tenant Microsoft 365, l'ambiente Intune o l'infrastruttura Azure non è mai la stessa identità usata per leggere le email o partecipare a chiamate Teams. Il dispositivo utilizzato per queste sessioni amministrative è hardened, ristretto e isolato dal normale browsing internet e dal contesto di produttività che genera la superficie di attacco. Il movimento laterale diventa strutturalmente più difficile, perché non esiste un percorso laterale.",[562,621,623],{"id":622},"due-livelli-di-difesa","Due livelli di difesa",[525,625,568],{},[525,627,628],{},"Per affrontare correttamente questo modello di minaccia bisogna lavorare simultaneamente su due livelli: mettere in sicurezza chi può toccare il livello di management e le sue credenziali, e hardening del modo in cui questo livello di management viene configurato e gestito. Non sono lo stesso problema, ed entrambi contano.",[525,630,631],{},[632,633],"img",{"alt":634,"src":635},"Mappatura di rischi e prodotti per lo scenario dell'attacco Stryker: Managed Red Tenant affronta i rischi di identità e accesso, Managed Intune affronta i rischi di endpoint management","https://res.cloudinary.com/c4a8/image/upload/v1774005366/blog/pics/stryker_risk_product_mapping.svg",[637,638,640],"h3",{"id":639},"managed-red-tenant-proteggere-il-contesto-amministrativo","Managed Red Tenant: proteggere il contesto amministrativo",[525,642,643],{},"{: .h4-font-size}",[525,645,646,647,650],{},"Il primo livello è l'isolamento completo dell'accesso privilegiato. È per questo che è stato progettato il nostro ",[648,649,250],"a",{"href":251},".",[525,652,653],{},"Il Managed Red Tenant offre un ambiente amministrativo cloud completamente isolato, un tenant Microsoft Entra dedicato («il Red Tenant») utilizzato esclusivamente per operazioni privilegiate. Le identità amministrative vivono qui. I dispositivi amministrativi vengono gestiti qui. Nulla dell'ambiente di lavoro regolare passa dall'altra parte.",[525,655,656],{},"Per i ruoli più critici, quelli con accesso al control plane come i Global Administrator, implementiamo l'approccio «Clean Keyboard»: una Privileged Admin Workstation (PAW) fisica con hardware dedicato, policy hardened e nessun punto di contatto con il contesto di lavoro quotidiano. Per i ruoli amministrativi al di sotto del control plane offriamo Virtual Access Workstation (VAW) scalabili, costruite su un'infrastruttura Azure Virtual Desktop hardened all'interno del Red Tenant. Il percorso di accesso stesso è protetto da Microsoft Entra Private Access, con Zero Trust Network Access e policy Conditional Access, prima che sia possibile stabilire una sessione.",[525,658,659],{},"Microsoft Entra Internet Access blocca l'accesso pubblico a internet dalle sessioni amministrative e limita rigorosamente le connessioni alle interfacce privilegiate e agli ambienti tenant autorizzati. La revoca delle sessioni in tempo quasi reale è possibile grazie a Universal Conditional Access Evaluation, il che significa che una credenziale revocata non persiste come sessione valida.",[525,661,662,663,666],{},"Il Managed Red Tenant è monitorato 24 ore su 24 dal nostro ",[648,664,665],{"href":276},"Cloud Security Operations Center (CSOC)",", con detection sviluppate appositamente e mirate a autorizzazioni amministrative e pattern di accesso. Un attaccante che in qualche modo compromettesse una credenziale in questo ambiente non avrebbe tre ore non rilevate per eseguire comandi wipe su una flotta globale di dispositivi.",[525,668,669],{},"Questo è particolarmente rilevante per ruoli come gli amministratori Intune. Sanno come mettere in sicurezza i client, ma la messa in sicurezza di una privileged admin workstation richiede competenze diverse: Enterprise Access Architecture, identity hardening, Zero Trust controls. Queste ricadono tipicamente sul team di security. Un Managed Red Tenant toglie completamente questo peso: gli admin Intune ricevono una workstation gestita professionalmente e coerentemente hardened, senza dover diventare esperti di security workstation. Vale per ogni ruolo altamente privilegiato dell'organizzazione.",[671,672],"video-frame",{"thumb":673,"alt":674,"id":675,":full-width":676},"/thumbs/thumb-managed-red-tenant.jpg","Jan Geisbauer e Thomas Naunheim discutono la strategia di cybersecurity del Managed Red Tenant","rOEIvItNkjE","true",[678,679,681,682],"div",{"style":680},"background:var(--color-gk-light-grey); margin-top:0.5rem; padding:0.5rem 1rem; font-size:0.85rem; color:var(--color-gk-dark-blue)","Altri contenuti sul nostro ",[648,683,687],{"href":684,"target":330,"rel":685},"https://www.youtube.com/playlist?list=PLPxBXiOFJRHelegu_B-uZAyz2UrOSxioL",[686],"noopener","canale YouTube",[637,689,691],{"id":690},"managed-intune-mettere-in-sicurezza-il-livello-di-management-stesso","Managed Intune: mettere in sicurezza il livello di management stesso",[525,693,643],{},[525,695,696,697,650],{},"Il secondo livello consiste nell'assicurarsi che Intune, lo strumento trasformato in arma nell'attacco Stryker, venga configurato, gestito e mantenuto secondo il più alto standard di sicurezza. È di questo che si occupa il nostro servizio ",[648,698,35],{"href":36},[525,700,701],{},"Una delle intuizioni chiave da incidenti come questo è che le organizzazioni ereditano spesso ambienti Intune cresciuti organicamente: policy su policy, modifiche manuali via portale difficili da verificare, security baseline che non hanno tenuto il passo con le raccomandazioni in evoluzione di Microsoft. È esattamente il tipo di ambiente in cui la configuration drift crea lacune sfruttabili.",[525,703,704,705,711],{},"Microsoft ha recentemente pubblicato le ",[648,706,710],{"href":707,"rel":708},"https://techcommunity.microsoft.com/blog/intunecustomersuccess/best-practices-for-securing-microsoft-intune/4502117",[709],"nofollow","Best Practices per la messa in sicurezza di Microsoft Intune",", un segnale che anche Microsoft considera l'hardening di Intune un tema che richiede attenzione esplicita a livello di settore. Il nostro servizio Managed Intune si basa su questi principi, e abbiamo implementato le raccomandazioni di Microsoft come parte della nostra baseline.",[525,713,714],{},"Il nostro servizio Managed Intune si basa sulla glueckkanja Intune foundation: un insieme collaudato e continuamente aggiornato di best practice per il device management, deployato integralmente come codice con Terraform e con il nostro TerraProvider. Ogni modifica è automatizzata, versionata e verificabile. Non esistono configurazioni click-through non documentate che un attaccante possa sfruttare cogliendo la differenza tra ciò che era previsto e ciò che è stato effettivamente impostato.",[525,716,717],{},"Dal punto di vista della security, questo significa che Zero Trust, App Protection Policies e configurazioni Endpoint Security vengono applicate in modo coerente by design, su Windows, macOS, iOS e Android, non come deployment una tantum, ma come baseline applicate in continuo e costantemente aggiornate, che seguono le linee guida di sicurezza di Microsoft.",[525,719,720],{},"Fondamentalmente, Managed Intune riflette la maturità operativa che l'endpoint management moderno richiede: monitoraggio continuo della compliance, change governance strutturata e service review regolari, non come extra opzionali, ma come operazioni baseline. Ma mettere in sicurezza la configurazione di Intune è solo metà del lavoro. Se l'amministratore che accede alla console lo fa da un dispositivo non protetto, il livello di management resta comunque esposto, ed è esattamente qui che il Managed Red Tenant completa il modello.",[525,722,723],{},"Dato che tutte le configurazioni vengono deployate come codice sulla base della Intune foundation, applichiamo un rigoroso four-eyes principle con peer review, ulteriore validazione automatizzata e pipeline di deployment controllate. Questo elimina le modifiche non gestite via portale all'interno della Intune foundation e garantisce una baseline coerente, verificabile e sicura su tutti i dispositivi.",[525,725,726],{},"L'accesso amministrativo è governato da un modello least-privilege con GDAP e Azure Lighthouse, con responsabilità chiaramente definite e accesso strettamente limitato al tenant del cliente. Questo riduce sensibilmente la superficie di attacco associata alle operazioni privilegiate.",[525,728,729],{},"Le azioni a livello di dispositivo, incluse le operazioni distruttive, rimangono di responsabilità del cliente, perché la loro esecuzione è strettamente legata a processi organizzativi specifici e a framework di governance interni. Microsoft e CISA raccomandano di proteggere azioni di questo tipo con misure di salvaguardia aggiuntive, ad esempio tramite controlli di approvazione multi-admin in Intune.",[562,731,733],{"id":732},"la-domanda-scomoda","La domanda scomoda",[525,735,568],{},[525,737,738],{},"L'attacco Stryker non è un atto d'accusa contro Microsoft Intune. Intune si è comportato esattamente come era stato progettato. Ha eseguito i comandi ricevuti da un amministratore autenticato. Il fallimento non era nel tool. Era nell'assenza di controlli su chi poteva raggiungere quel tool, da quale contesto e con quale grado di autorizzazione.",[525,740,741],{},"È un problema di governance e di architettura. Ed è lo stesso problema che esiste nella maggior parte delle organizzazioni che oggi utilizzano Microsoft 365.",[525,743,744],{},"Se i tuoi amministratori accedono a Intune, Entra ID o Azure dagli stessi dispositivi e con le stesse identità che usano per il lavoro quotidiano, e se il tuo ambiente Intune è cresciuto in anni di modifiche manuali via portale invece che attraverso un modello operativo strutturato e automatizzato, porti con te lo stesso rischio strutturale che Stryker portava l'11 marzo. La domanda è se un attaccante troverà questa vulnerabilità prima che tu la chiuda.",[525,746,747,749,750,752],{},[648,748,250],{"href":251}," affronta il livello di privilege e di identità. ",[648,751,35],{"href":36}," affronta il livello di configurazione e operations. Insieme chiudono le due lacune che hanno reso possibile l'attacco Stryker.",[525,754,755],{},"Se vuoi capire come uno dei servizi si applica al tuo ambiente attuale o dove si trovano le tue vulnerabilità concrete, ne parliamo volentieri.",[525,757,758],{},"Pubblicheremo a breve anche un articolo di approfondimento che analizza come l'incidente Stryker sia stato reso possibile.",[562,760,762],{"id":761},"ulteriori-informazioni","Ulteriori informazioni",[525,764,568],{},[766,767,768,776,782,789],"ul",{},[769,770,771],"li",{},[648,772,775],{"href":773,"rel":774},"https://www.cisa.gov/secure-cloud-business-applications",[709],"CISA: Securing Cloud Business Applications",[769,777,778],{},[648,779,781],{"href":707,"rel":780},[709],"Microsoft: Best Practices per la messa in sicurezza di Microsoft Intune",[769,783,784],{},[648,785,788],{"href":786,"rel":787},"https://techcrunch.com/2026/03/19/cisa-urges-companies-to-secure-microsoft-intune-systems-after-hackers-mass-wipe-stryker-devices/?utm_campaign=social",[709],"TechCrunch: CISA invita le aziende a mettere in sicurezza i sistemi Microsoft Intune dopo che gli hacker hanno cancellato in massa i dispositivi Stryker",[769,790,791],{},[648,792,795],{"href":793,"rel":794},"https://marketplace.microsoft.com/de-de/product/saas/glueckkanja-gabag.redtenant?tab=overview",[709],"Managed Red Tenant nell'Azure Marketplace",{"title":529,"searchDepth":530,"depth":530,"links":797},[798,799,800,801,802,807,808],{"id":564,"depth":530,"text":565},{"id":577,"depth":530,"text":578},{"id":595,"depth":530,"text":596},{"id":607,"depth":530,"text":608},{"id":622,"depth":530,"text":623,"children":803},[804,806],{"id":639,"depth":805,"text":640},3,{"id":690,"depth":805,"text":691},{"id":732,"depth":530,"text":733},{"id":761,"depth":530,"text":762},"post",{"lang":811,"seoTitle":812,"titleClass":813,"date":814,"categories":815,"blogtitlepic":816,"socialimg":817,"customExcerpt":818,"keywords":819,"asideNav":820,"contactInContent":835,"maxContent":484,"published":325},"it","L'attacco Stryker: come un account admin compromesso ha cancellato 80.000 dispositivi tramite Intune","h2-font-size","2026-03-20",[235],"head-stryker.jpg","/blog/heads/head-stryker.jpg","L'11 marzo 2026 Handala ha cancellato dispositivi in 79 paesi, e tutto ciò che è servito è stato un account admin Intune compromesso. Nessun malware, nessun exploit, solo strumenti di management legittimi rivolti contro i loro proprietari. Cosa è successo, perché ha funzionato e quali sono le due lacune architetturali da chiudere.","Attacco Stryker, Handala, Microsoft Intune Wipe, Privileged Access Management, Admin Workstation, Managed Red Tenant, Managed Intune, Zero Trust, Privileged Admin Workstation, PAW, Enterprise Access Model, CISA, sicurezza endpoint management",{"menuItems":821},[822,824,826,828,831,833],{"href":823,"text":565},"#cosè-successo-davvero",{"href":825,"text":578},"#perché-questo-attacco-ha-avuto-successo",{"href":827,"text":596},"#cisa-ne-ha-visto-abbastanza",{"href":829,"text":830},"#la-separazione-non-è-un-lusso-è-il-controllo","La separazione non è un lusso",{"href":832,"text":623},"#due-livelli-di-difesa",{"href":834,"text":733},"#la-domanda-scomoda",{"quote":325,"infos":836},{"bgColor":837,"headline":838,"subline":839,"level":562,"textStyling":840,"flush":841,"person":842,"form":847},"var(--color-gk-dark-blue)","Contattaci","Vuoi sapere come Managed Red Tenant e Managed Intune chiudono le lacune che l'attacco Stryker ha sfruttato? Compila il modulo e ti spiegheremo come si applica al tuo ambiente.","text-light","justify-content-end",{"image":843,"cloudinary":325,"alt":844,"name":520,"quotee":520,"quoteeTitle":845,"quote":846},"/people/people-jan-geisbauer-csoc.jpg","Ritratto di Jan Geisbauer, Head of Security di glueckkanja","Head of Security","Il tool ha fatto esattamente quello che gli è stato detto di fare. Il problema è che nessuno avrebbe dovuto essere in grado di dirglielo, non da un account di lavoro quotidiano compromesso, non senza una seconda approvazione, non senza un ambiente amministrativo isolato. Questa è la lacuna che aiutiamo le organizzazioni a chiudere.",{"ctaText":848,"cta":849,"method":809,"action":851,"fields":852},"Invia",{"skin":850},"primary on-surface","/send",[853,857,862,865,869,874,879,881,884,887,890,892],{"type":854,"id":855,"value":856},"hidden","_next","successful",{"label":858,"type":859,"id":860,"required":325,"requiredMsg":861},"Nome*","text","name","Inserisci il tuo nome.",{"label":863,"type":859,"id":403,"required":325,"requiredMsg":864},"Azienda*","Inserisci la tua azienda.",{"label":866,"type":867,"id":867,"required":325,"requiredMsg":868},"Indirizzo email*","email","Inserisci il tuo indirizzo email.",{"label":870,"type":871,"id":872,"required":484,"requiredMsg":873},"Il tuo messaggio per noi","textarea","message","Inserisci un messaggio.",{"label":875,"type":876,"id":877,"required":325,"requiredMsg":878},"I tuoi dati saranno memorizzati e utilizzati per rispondere alla tua richiesta. Per ulteriori informazioni consulta la nostra \u003Ca href=\"/it/privacy\">Informativa sulla privacy\u003C/a>.","checkbox","dataprotection","Conferma",{"type":854,"id":880,"value":235},"_topic",{"type":854,"id":882,"value":883},"_location","World",{"type":854,"id":885,"value":886},"_subject","Form: Blog Stryker Attack Intune Privilege | IT",{"type":854,"id":888,"value":889},"inbox_key","gkgab-contact-form",{"type":854,"id":891},"_gotcha",{"type":854,"id":893},"jsonData","/posts/2026-03-20-stryker-attack-intune-privilege",{"title":551,"description":557},"posts/2026-03-20-stryker-attack-intune-privilege",[71,898,899],"Privileged Access","Zero Trust","8qX5S8ZbOSK74iW3XjmzvrK48MlzrtYW8olHR-Xux1E",{"id":902,"title":903,"author":904,"body":905,"cta":494,"description":529,"eventid":494,"extension":532,"hideInRecent":484,"layout":809,"meta":1161,"moment":1163,"navigation":325,"path":1189,"seo":1190,"stem":1191,"tags":1192,"webcast":484,"__hash__":1195},"content_it/posts/2026-07-24-outbreak-openai-hugging-face.md","Outbreak. Cosa rivela il caso OpenAI/Hugging Face e cosa no",[520],{"type":522,"value":906,"toc":1151},[907,911,913,922,931,934,937,941,943,946,949,952,956,958,967,970,974,976,985,988,992,994,997,1000,1003,1012,1016,1018,1027,1033,1039,1043,1045,1048,1051,1055,1057],[562,908,910],{"id":909},"cosa-è-successo","Cosa è successo",[525,912,568],{},[525,914,915,916,921],{},"Pochi giorni fa OpenAI e Hugging Face hanno ",[648,917,920],{"href":918,"rel":919},"https://www.cnbc.com/2026/07/22/open-ai-cyber-models-hack-hugging-face.html",[709],"reso pubblico un incidente"," che ha elettrizzato la community della security: un AI agent autonomo, alimentato da GPT-5.6 Sol e da un modello ancora inedito e più performante, è evaso dal suo ambiente di test isolato durante un test di sicurezza interno. L'agent si è procurato passo dopo passo più accessi all'interno dei sistemi OpenAI, sfruttando tra l'altro una vulnerabilità zero-day fino a quel momento sconosciuta, ha raggiunto internet e ha infine penetrato i sistemi interni di Hugging Face, per procurarsi lì le informazioni che gli era stato originariamente assegnato di cercare.",[525,923,924,925,930],{},"Nel frattempo sono pubblici i primi dettagli tecnici, tra l'altro nell'",[648,926,929],{"href":927,"rel":928},"https://simonwillison.net/2026/Jul/22/openai-cyberattack/",[709],"analisi del caso di Simon Willison",": il test si è svolto nell'ambito di un benchmark di exploit, deliberatamente con meccanismi di protezione ridotti. L'ambiente di test aveva esattamente una connessione verso l'esterno, un proxy interno per l'installazione delle dipendenze, ed è proprio in quel proxy che il modello ha trovato lo zero-day. L'evasione è stata dunque meno magia che il forzamento dell'unica porta esistente. In Hugging Face la strada è poi passata attraverso un dataset malevolo verso l'infrastruttura di elaborazione, e da lì, con credenziali sottratte, verso diversi cluster interni.",[525,932,933],{},"Il motivo è quasi la battuta migliore dell'intera storia: il modello cercava informazioni con cui poter barare alla propria valutazione. Il primo attacco AI presumibilmente eseguito in modo completamente autonomo è stato quindi, a rigore, un caso di frode d'esame. Con danni collaterali.",[525,935,936],{},"Hugging Face descrive l'incidente come qualcosa che si distingue da tutto ciò che ha trattato finora: \"driven, end to end, by an autonomous AI agent system\". OpenAI parla di un incidente cyber senza precedenti. Non vogliamo in alcun modo minimizzare la portata di questo attacco. Ma vogliamo togliere dal dibattito il calore e l'emotività, perché proprio quelle sono in questo momento il rischio maggiore per le buone decisioni.",[562,938,940],{"id":939},"perché-questo-incidente-sembra-così-minaccioso","Perché questo incidente sembra così minaccioso",[525,942,568],{},[525,944,945],{},"Uno sguardo alla psicologia aiuta. Il ricercatore del rischio Paul Slovic ha dimostrato che non valutiamo i rischi in base alla loro pericolosità statistica, ma soprattutto secondo due dimensioni: quanto ci è familiare un rischio e quanto lo temiamo. Guidare è oggettivamente pericoloso, ma sembra innocuo perché appare familiare e controllabile. Un modello di AI evaso dal laboratorio, invece, colpisce il nervo dell'ignoto e dell'incontrollabile e finisce esattamente nella categoria che Slovic descrive come \"dread risk\".",[525,947,948],{},"Daniel Kahneman in \"Pensieri lenti e veloci\" ha descritto cosa succede poi: di fronte a rischi ignoti e dall'apparenza minacciosa prende il comando il nostro sistema di pensiero rapido, intuitivo, emotivo, non quello lento e analitico. È esattamente questo schema che osserviamo in questo momento in molte sezioni dei commenti: l'incidente non viene analizzato, viene sentito.",[525,950,951],{},"Quindi: un respiro profondo, accendere il Sistema 2 e guardare il caso da altre prospettive.",[562,953,955],{"id":954},"prospettiva-1-mostrate-le-prove-florian-roth","Prospettiva 1: mostrate le prove (Florian Roth)",[525,957,568],{},[525,959,960,961,966],{},"Il ricercatore di security Florian Roth (noto tra l'altro per Sigma e THOR) contesta nel suo ",[648,962,965],{"href":963,"rel":964},"https://www.linkedin.com/posts/floroth_one-thing-about-this-openai-hugging-face-share-7485702026429960192-npkt/",[709],"post su LinkedIn"," un punto centrale: la documentazione mancante. Hugging Face sostiene che l'attacco sia stato guidato \"end to end\" da un sistema di agent autonomi. Ma la telemetria della vittima può in linea di principio mostrare solo ciò che è accaduto nel proprio ambiente. Non può mostrare se a monte delle persone hanno adattato prompt, riavviato esecuzioni, selezionato i percorsi riusciti o dato una mano a mano nei punti decisivi. La richiesta di Roth è tanto semplice quanto legittima: se OpenAI ha i trace (prompt, tool call, esecuzioni fallite, interventi umani), allora li pubblichi. Fino a quel momento \"completamente autonomo\" è un'affermazione, non un riscontro forense. Un commentatore aggiunge a proposito: anche in quel caso sarebbe difficile dimostrare senza dubbi quanta interazione umana ci sia effettivamente stata.",[525,968,969],{},"E Roth ci aggiunge una punta. Il racconto delle due aziende di AI si riduce in sostanza a tre righe: l'AI ci ha attaccati. L'AI ci ha salvati. Quindi ora a tutti serve più AI. Ciò che dieci anni fa sarebbe stata una figuraccia (isolamento debole, privilegi troppo estesi, segmentazione insufficiente, blast radius enorme) viene oggi confezionato come capability demo e come epica storia AI contro AI. Il suo verdetto asciutto: rate limit, restrizioni sull'egress, worker isolati e credenziali ben delimitate avrebbero frenato gran parte di questa attività e l'avrebbero resa visibile presto. Per questo non serve a nessuno un LLM.",[562,971,973],{"id":972},"prospettiva-2-siamo-sopravvissuti-a-cose-peggiori-marcus-hutchins","Prospettiva 2: siamo sopravvissuti a cose peggiori (Marcus Hutchins)",[525,975,568],{},[525,977,978,979,984],{},"Marcus Hutchins, il ricercatore di security che nel 2017 ha fermato l'epidemia di WannaCry con un kill switch, inquadra storicamente il caso nel suo ",[648,980,983],{"href":981,"rel":982},"https://www.linkedin.com/posts/malwaretech_anytime-someone-is-freaking-out-about-fully-share-7485851514784272384-0-oa/",[709],"contributo",". Chi si lascia prendere dal panico per i \"cyberattacchi completamente autonomi\" dovrebbe ricordarsi dell'era d'oro dei worm informatici: ILOVEYOU, Code Red, SQL Slammer. Malware autoreplicante che senza alcun intervento umano infettava milioni di sistemi in una sola giornata, in un'epoca in cui molti sistemi erano appesi a internet direttamente e senza protezione.",[525,986,987],{},"Il suo argomento: gli attacchi agentici sono fondamentalmente limitati da velocità e costi. Nel tempo in cui un modello di AI genera una singola risposta, un worm classico avrebbe già infettato decine di migliaia di sistemi, e i costi in token per hackerare in modo autonomo milioni di sistemi sfondano il budget della maggior parte degli attaccanti. A questo si aggiunge: firewall, EDR, segmentazione di rete, sandboxing, MFA e molti altri controlli sono oggi standard e costituiscono ostacoli reali che allora semplicemente non esistevano. La sua conclusione: gli attacchi supportati dall'AI non possono riportare la cybersecurity indietro di decenni. Non possono cancellare dal mondo i controlli di sicurezza una volta consolidati né l'igiene di base. L'attack surface reduction funziona. Uno zero-day non può colpire un sistema che non raggiunge.",[562,989,991],{"id":990},"cosa-dicono-entrambi-e-cosa-ne-consegue","Cosa dicono entrambi e cosa ne consegue",[525,993,568],{},[525,995,996],{},"I due esperti arrivano per strade diverse alla stessa conclusione: concentrarsi sull'essenziale. Le aziende che migliorano continuamente la propria security posture e attuano con coerenza concetti come Zero Trust, least privilege e una netta separazione dei tier hanno una probabilità nettamente inferiore di diventare vittime, indipendentemente dal fatto che all'altro capo ci sia una persona, uno script o un modello linguistico.",[525,998,999],{},"L'incidente va comunque preso sul serio, e questo a prescindere da come si concluda la questione delle prove. Questo incidente non è un esempio di come l'AI si impadronisca di internet. Ma mostra che aspetto ha un attacco mirato a un nuovo livello: il concatenamento autonomo di due catene d'attacco separate attraverso due infrastrutture altrui, eseguito in molte migliaia di singole azioni da uno sciame di sandbox effimere. Se OpenAI dovesse pubblicare i trace e dimostrare la piena autonomia, il quadro non diventerebbe più innocuo. Alla logica della difesa, però, questo non cambia nulla. La conferma.",[525,1001,1002],{},"Che gli attaccanti trovino strade che non si erano previste non è una scoperta nuova, ma il pane quotidiano di chiunque lavori nella security. Proprio per questo esiste la defense in depth: se non individuo o fermo l'attaccante alla stazione 4 della attack chain, allora lo fermo alla 5. E questo include espressamente gli zero-day. Si possono costruire infrastrutture capaci di resistere anche a tempeste violente. Non perché si preveda ogni tempesta, ma perché si costruisce per le tempeste.",[525,1004,1005,1006,1011],{},"Un'ironia marginale che nel frastuono quasi si perde: per l'analisi forense Hugging Face ha puntato proprio su un modello cinese aperto, anche perché un modello frontier statunitense in hosting ",[648,1007,1010],{"href":1008,"rel":1009},"https://huggingface.co/datasets/huggingface/forensic-refusal/blob/main/glm5.2.jsonl",[709],"si è semplicemente rifiutato di analizzare una backdoor",". Il dibattito su quali strumenti i difensori possano usare, e con quanta rapidità, in caso di emergenza è dunque appena iniziato, ed è almeno tanto importante quanto la domanda su cosa sapranno fare in futuro gli attaccanti.",[562,1013,1015],{"id":1014},"non-un-soc-autonomo-ma-uno-migliore","Non un SOC autonomo, ma uno migliore",[525,1017,568],{},[525,1019,1020,1021,1026],{},"Sia la difesa sia l'attacco hanno ricevuto nuovi strumenti. Anche se da noi \"strumento\" da tempo non è più la parola giusta. Nel nostro SOC l'AI non è un add-on, ma parte ovvia di ogni fase dell'incident handling: dalla detection al triage e all'enrichment fino alla response, le nostre analiste e i nostri analisti lavorano fianco a fianco con le soluzioni e i modelli di Microsoft e Anthropic. Ciò che è ripetitivo gira automatizzato, così le nostre esperte e i nostri esperti possono concentrarsi su ciò che fa la differenza: trarre nuove conoscenze da ogni incident e affinare continuamente detection, playbook e configurazioni. Un SOC autonomo al 100 % non è attualmente possibile, ",[648,1022,1025],{"href":1023,"rel":1024},"https://www.linkedin.com/posts/peteshoard_gartner-soc-threat-share-7457373093368500224-uszD/",[709],"e del resto lo pensa anche Gartner",". Ma da noi la manopola non è una questione di fede, bensì un'impostazione che rivalutiamo continuamente: con ogni generazione di modelli e ogni esperienza acquisita la alziamo esattamente quanto la qualità lo consente. Non oltre, ma nemmeno un millimetro in meno.",[525,1028,1029,1030,1032],{},"Questo gioco di squadra tra persona, modello e metodo è il nucleo del nostro ",[648,1031,665],{"href":276},": detection & response 24/7, combinate con il continuous improvement. Ogni mese un pezzo di security posture migliore, basato sui nostri blueprint e su ciò che i nostri esperti di threat osservano in natura.",[525,1034,1035,1036,1038],{},"E contro il problema di fondo che Florian Roth seziona con tanta precisione (isolamento debole, privilegi dilaganti, segmentazione mancante) abbiamo una risposta molto concreta: il ",[648,1037,250],{"href":251},". Un ambiente amministrativo completamente isolato, che impedisce strutturalmente lateral movement e privilege escalation. Con l'architettura giusta e le configurazioni giuste gli attacchi vanno a vuoto, anche quelli degli AI agent. Perché sia che un attaccante sia di carne e ossa o di token: contro un confine di tier che non si può superare non serve nemmeno il miglior reasoning.",[562,1040,1042],{"id":1041},"conclusioni","Conclusioni",[525,1044,568],{},[525,1046,1047],{},"Il caso OpenAI/Hugging Face è una pietra miliare: come avvertimento, come caso di studio e come anticipazione. Ma non è un motivo per farsi prendere dal panico, bensì per stabilire priorità. Gli attacchi del futuro saranno forse più autonomi; la difesa che serve contro di loro è sorprendentemente familiare: Zero Trust, least privilege, una netta separazione dei tier, defense in depth e un SOC che non dorme mai.",[525,1049,1050],{},"Oppure, per restare alla battuta di questo caso: se un'AI deve proprio evadere per barare al proprio test, facciamo in modo che da noi almeno non trovi risposte.",[562,1052,1054],{"id":1053},"fonti-e-link-di-approfondimento","Fonti e link di approfondimento",[525,1056,568],{},[766,1058,1060,1061,1060,1073,1060,1082,1060,1091,1060,1100,1060,1109,1060,1118,1060,1128,1060,1138,1060,1145],{"style":1059},"margin: 0.25rem 0","\n  ",[769,1062,1063,1067,1068,1072],{},[1064,1065,1066],"strong",{},"CNBC:"," ",[648,1069,1071],{"href":918,"target":330,"rel":1070},[686],"OpenAI cyber models broke out of training environment to hack Hugging Face"," (22.07.2026)",[769,1074,1075,1067,1078],{},[1064,1076,1077],{},"Florian Roth su LinkedIn:",[648,1079,1081],{"href":963,"target":330,"rel":1080},[686],"\"One thing about this OpenAI / Hugging Face incident really bothers me\"",[769,1083,1084,1067,1087],{},[1064,1085,1086],{},"Marcus Hutchins su LinkedIn:",[648,1088,1090],{"href":981,"target":330,"rel":1089},[686],"Sull'era d'oro dei worm informatici",[769,1092,1093,1067,1096],{},[1064,1094,1095],{},"Hugging Face:",[648,1097,1099],{"href":1008,"target":330,"rel":1098},[686],"Dataset dei rifiuti forensi (GLM 5.2)",[769,1101,1102,1067,1105,1072],{},[1064,1103,1104],{},"Simon Willison:",[648,1106,1108],{"href":927,"target":330,"rel":1107},[686],"OpenAI's accidental cyberattack against Hugging Face is science fiction that happened",[769,1110,1111,1067,1114],{},[1064,1112,1113],{},"Pete Shoard (Gartner) su LinkedIn:",[648,1115,1117],{"href":1023,"target":330,"rel":1116},[686],"Perché un SOC completamente autonomo non è realistico",[769,1119,1120,1067,1123],{},[1064,1121,1122],{},"Paul Slovic:",[648,1124,1127],{"href":1125,"target":330,"rel":1126},"https://de.wikipedia.org/wiki/Paul_Slovic",[686],"Wikipedia",[769,1129,1130,1067,1133,1137],{},[1064,1131,1132],{},"Daniel Kahneman:",[648,1134,1127],{"href":1135,"target":330,"rel":1136},"https://de.wikipedia.org/wiki/Daniel_Kahneman",[686],", \"Pensieri lenti e veloci\"",[769,1139,1140,1067,1143],{},[1064,1141,1142],{},"glueckkanja:",[648,1144,665],{"href":276},[769,1146,1147,1067,1149],{},[1064,1148,1142],{},[648,1150,250],{"href":251},{"title":529,"searchDepth":530,"depth":530,"links":1152},[1153,1154,1155,1156,1157,1158,1159,1160],{"id":909,"depth":530,"text":910},{"id":939,"depth":530,"text":940},{"id":954,"depth":530,"text":955},{"id":972,"depth":530,"text":973},{"id":990,"depth":530,"text":991},{"id":1014,"depth":530,"text":1015},{"id":1041,"depth":530,"text":1042},{"id":1053,"depth":530,"text":1054},{"lang":811,"seoTitle":1162,"titleClass":813,"date":1163,"categories":1164,"blogtitlepic":1165,"socialimg":1166,"customExcerpt":1167,"keywords":1168,"asideNav":1169,"published":325},"L'AI di OpenAI hackera Hugging Face: cosa significa l'attacco AI autonomo per le aziende","2026-07-24",[235],"head-outbreak.jpg","/blog/heads/head-outbreak.jpg","Un AI agent evade dal suo ambiente di test, trova uno zero-day e hackera un'altra azienda. Sembra una sceneggiatura, ma nel luglio 2026 è successo davvero. È il momento di un inquadramento lucido: con un po' di psicologia, due veterani della security e la domanda su cosa significhi tutto questo per la tua difesa.","caso OpenAI Hugging Face, AI di OpenAI hackera Hugging Face, attacco AI autonomo, evasione dalla sandbox di un AI agent, cyberattacco autonomo, AI cybersecurity, attacchi agentici, GPT-5.6 Sol, zero-day, Florian Roth, Marcus Hutchins, Zero Trust, defense in depth, SOC autonomo, Cloud Security Operations Center",{"menuItems":1170},[1171,1173,1176,1179,1182,1185,1187],{"href":1172,"text":910},"#cosa-è-successo",{"href":1174,"text":1175},"#perché-questo-incidente-sembra-così-minaccioso","La psicologia dietro",{"href":1177,"text":1178},"#prospettiva-1-mostrate-le-prove-florian-roth","Prospettiva 1: Florian Roth",{"href":1180,"text":1181},"#prospettiva-2-siamo-sopravvissuti-a-cose-peggiori-marcus-hutchins","Prospettiva 2: Marcus Hutchins",{"href":1183,"text":1184},"#cosa-dicono-entrambi-e-cosa-ne-consegue","Cosa ne consegue",{"href":1186,"text":1015},"#non-un-soc-autonomo-ma-uno-migliore",{"href":1188,"text":1042},"#conclusioni","/posts/2026-07-24-outbreak-openai-hugging-face",{"title":903,"description":529},"posts/2026-07-24-outbreak-openai-hugging-face",[1193,1194,899],"AI","SOC","pwAa-SM7PvP8owg39TJDz62WTCwjBXHBwmcWSeuiN8U",{"id":1197,"title":1198,"author":1199,"body":1200,"cta":494,"description":529,"eventid":494,"extension":532,"hideInRecent":484,"layout":809,"meta":1313,"moment":1315,"navigation":325,"path":1371,"seo":1372,"stem":1373,"tags":1374,"webcast":484,"__hash__":1376},"content_it/posts/2026-09-21-red-tenant-dark-tenant-cio.md","Admin e quotidianità sullo stesso computer? Game Over.",[520],{"type":522,"value":1201,"toc":1306},[1202,1206,1208,1211,1214,1217,1220,1224,1226,1229,1233,1235,1241,1250,1253,1256,1260,1262,1270,1276,1280,1282,1285,1292,1300,1303],[562,1203,1205],{"id":1204},"un-computer-due-tab-un-clic","Un computer, due tab, un clic",[525,1207,568],{},[525,1209,1210],{},"Lo scenario non ha niente di spettacolare, ed è proprio questo a renderlo così pericoloso: un amministratore è al suo solito laptop office. Nel tab di sinistra del browser è aperto il Microsoft 365 Admin Center, diritti di global admin e di Intune admin inclusi. Nel tab di destra scarica un «tool gratuito», Invoice_2026.pdf.exe. Un clic, un payload PowerShell, persistenza stabilita, privilege escalation in corso. La strada verso il Tier 0, verso il cuore dell'IT aziendale, è aperta.",[525,1212,1213],{},"Game Over.",[525,1215,1216],{},"MITRE ATT&CK documenta attualmente 222 tecniche per gli ambienti enterprise, più 475 sotto-tecniche, insieme quasi 700 modi noti per escalare privilegi, muoversi lateralmente e raggiungere gli asset più sensibili di un'azienda. Agli attaccanti ne serve esattamente uno. E nella maggior parte degli interventi di incident response che accompagniamo emerge lo stesso schema: si amministrava sullo stesso dispositivo su cui si leggevano email, si navigava e si chattava in Teams.",[525,1218,1219],{},"Chi prende sul serio l'«Assume Breach», e con NIS2 le alternative sono poche, deve accettare una conseguenza scomoda: alcune cose semplicemente non devono stare sullo stesso computer. Una separazione a metà non è una separazione.",[562,1221,1223],{"id":1222},"perché-le-risposte-più-ovvie-non-bastano","Perché le risposte più ovvie non bastano",[525,1225,568],{},[525,1227,1228],{},"I riflessi consueti li conosciamo tutti. Jump server? Un tunnel reverse proxy dal client compromesso, e l'attaccante passa a cavallo direttamente attraverso la jump box: stessa macchina, stesso browser, stesso rischio. Costruire un privileged access management (PAM) classico nel proprio tenant? Allora si pone subito la domanda: chi gestisce l'ambiente di management? Se le admin workstation protette vivono nello stesso tenant che dovrebbero proteggere, si è costruito un cerchio, non un muro. E il desktop virtuale usato dal laptop office? Erediterà il suo keylogger. Lo schermo è virtuale, i tasti premuti sono reali. Lo Zero Trust finisce esattamente dove admin e quotidianità si dividono un dispositivo.",[562,1230,1232],{"id":1231},"il-managed-red-tenant-la-separazione-come-architettura","Il Managed Red Tenant: la separazione come architettura",[525,1234,568],{},[525,1236,1237,1238,1240],{},"È esattamente qui che entra in gioco il ",[648,1239,250],{"href":251}," (MRT): un ambiente tenant dedicato, gestito integralmente tramite codice e irrobustito in modo massiccio, destinato esclusivamente al lavoro amministrativo. Per i compiti di Tier 0 sono disponibili privileged access workstation (PAW) gestite come Managed Service, PAW hardware irrobustite come dispositivi fisici dedicati. Per il lavoro di Tier 1 servono le VAW, access workstation virtuali basate su Azure Virtual Desktop, raggiungibili solo da compliant device, solo con FIDO2, solo con Conditional Access. Il tutto integrato da iPad configurati in modo specifico e con la massima sicurezza, per maggiore comodità.",[678,1242,1244],{"style":1243},"grid-column: content",[525,1245,1246],{},[632,1247],{"alt":1248,"src":1249},"Confronto schematico di due tenant: a sinistra il Managed Red Tenant come spazio schermato con le admin workstation PAW, VAW e iPAW, a destra il tenant produttivo con internet, mail, Teams e SharePoint come pianta con passaggi aperti, e tra i due una parete divisoria rossa continua","https://res.cloudinary.com/c4a8/image/upload/blog/pics/game-over-1.jpg",[525,1251,1252],{},"Il punto decisivo per i CIO non è però la tecnica, ma il modello operativo. Ogni modifica al Red Tenant passa come Configuration as Code attraverso una pipeline CI/CD e viene deployata solo dopo un'approvazione esplicita del cliente. Questo principio di shared responsibility risponde alla domanda che ogni acquirente di managed services dovrebbe porre: cosa succede se il fornitore stesso viene compromesso? La risposta: niente. Senza l'approvazione del cliente nel Red Tenant non cambia una riga di configurazione. Il livello di management sta fuori dalla zona di rischio del cliente, il diritto di veto resta al cliente.",[525,1254,1255],{},"Il guadagno operativo è doppio. In primo luogo nasce una nitidezza di separazione che si ha raramente: ogni accesso amministrativo legittimo all'ambiente di produzione arriva per definizione da una macchina MRT. Tutto il resto è un attacco. Questo dà al SOC un segnale senza rumore, a cui può reagire subito invece di smistare falsi allarmi. In secondo luogo, in caso di attacco riuscito all'ambiente office c'è di mezzo un muro, non un dosso: il salto da un laptop office compromesso a una PAW hardware che sta accanto sulla scrivania come dispositivo separato è estremamente difficile, fino a impossibile, per gli attaccanti.",[562,1257,1259],{"id":1258},"e-se-succede-comunque-lextra-life","E se succede comunque? L'Extra Life.",[525,1261,568],{},[525,1263,1264,1265,1269],{},"Ogni CIO esperto lo sa: la sicurezza al cento per cento non esiste. Assume breach significa anche mettere in conto il fallimento della propria difesa. Il ",[648,1266,1268],{"href":1267},"/it/posts/2026-03-20-stryker-attack-intune-privilege","caso Stryker del marzo 2026"," ha mostrato quanto sia sottile il confine: è bastato un account admin Intune compromesso per cancellare dispositivi in 79 paesi. I gruppi ransomware oggi puntano in modo mirato ai backup, all'Active Directory, esattamente ai sistemi che servirebbero per la ricostruzione. Chi a quel punto comincia a improvvisare, con fileserver cifrati, senza identità funzionanti, con una catena telefonica invece di un'infrastruttura di comunicazione, perde giorni e settimane in cui l'azienda è ferma.",[525,1271,1272,1273,1275],{},"Se il Red Tenant evita che si arrivi al «Game Over», allora il ",[648,1274,217],{"href":218}," è l'Extra Life: un ambiente di ripristino preparato, dormiente nella normale operatività, che viene attivato in caso di emergenza. Una chiamata al numero di emergenza 24/7 avvia il processo di disaster recovery. Una war room virtuale stabilisce immediatamente una comunicazione sicura con tutti gli stakeholder chiave, indipendentemente dall'ambiente di produzione eventualmente compromesso. Poiché il Dark Tenant è costruito come Infrastructure as Code, tutti i processi critici di ripristino sono predefiniti e automatizzati: i componenti di sistema critici come Active Directory e le identità vengono ripristinati in modo pulito, invece di essere assemblati ad hoc sotto stress. Il risultato: un recovery time objective (RTO) da poche ore a pochi giorni e un recovery point objective (RPO) definito, invece delle settimane che nella pratica i ripristini improvvisati costano regolarmente.",[562,1277,1279],{"id":1278},"resilienza-in-doppia-copia","Resilienza in doppia copia",[525,1281,568],{},[525,1283,1284],{},"Red Tenant e Dark Tenant rispondono a due domande diverse, che solo insieme danno un quadro completo. Il Red Tenant risponde: come evito che un client compromesso diventi mai un dominio compromesso? Il Dark Tenant risponde: come resto operativo se succede comunque? Uno è il muro, l'altro il telo di salvataggio.",[525,1286,1287,1288,1291],{},"Per le aziende austriache si aggiunge una ",[648,1289,1290],{"href":315},"dimensione regolamentare",", e diventerà presto molto concreta. Con il NISG 2026, che entra in vigore il 1° ottobre 2026, circa 4.000 aziende austriache ricadono sotto obblighi di cibersicurezza dimostrabili, espressamente inclusi risk management, business continuity, piano di emergenza e gestione delle crisi. Chi può spiegare all'organo di vigilanza che gli accessi amministrativi sono isolati architetturalmente e che per l'emergenza è pronto un ambiente di ripristino testato e automatizzato conduce una discussione diversa da chi rimanda a corsi di awareness e alla speranza.",[678,1293,1294],{"style":1243},[525,1295,1296],{},[632,1297],{"alt":1298,"src":1299},"Tabella delle misure di gestione del rischio NIS2 secondo l'articolo 21.2 con le righe Incident Handling, Business Continuity, Supply Chain Security, Security in Network and Information Systems, Effectiveness of Cybersecurity Risk Management Measures, Human Resources Security and Access Control e Multifactor Authentication, e segni di spunta nelle colonne Managed Red Tenant e Managed Dark Tenant","https://res.cloudinary.com/c4a8/image/upload/blog/pics/game-over-2.jpg",[525,1301,1302],{},"Entrambi i servizi li gestiamo come Managed Service, con un team che come fornitore di APT response qualificato dal BSI si trova regolarmente sull'altro fronte, quando l'incendio è già in corso, e che fa rifluire questa esperienza direttamente nell'architettura. Tra i nostri clienti figurano gruppi del DAX così come operatori di infrastrutture critiche.",[525,1304,1305],{},"Alcune cose non devono stare sullo stesso computer. E alcune aziende non possono permettersi un Game Over. Allora meglio con muro ed Extra Life.",{"title":529,"searchDepth":530,"depth":530,"links":1307},[1308,1309,1310,1311,1312],{"id":1204,"depth":530,"text":1205},{"id":1222,"depth":530,"text":1223},{"id":1231,"depth":530,"text":1232},{"id":1258,"depth":530,"text":1259},{"id":1278,"depth":530,"text":1279},{"lang":811,"seoTitle":1314,"titleClass":813,"date":1315,"categories":1316,"blogtitlepic":1317,"socialimg":1318,"customExcerpt":1319,"keywords":1320,"asideNav":1321,"contactInContent":1336,"maxContent":484,"published":325,"scripts":1370},"Managed Red Tenant e Managed Dark Tenant: isolamento amministrativo e ripristino per i CIO","2026-09-21",[235],"head-game-over-en.jpg","/blog/heads/head-game-over-en.jpg","Perché per i CIO un solo tenant non basta, e il secondo viene raramente messo in conto. Il Managed Red Tenant separa architetturalmente il lavoro amministrativo dall'ambiente office, il Managed Dark Tenant mantiene l'azienda operativa quando la difesa cede comunque. Cosa significa per il modello operativo, per il segnale al SOC e per gli obblighi di prova previsti dal NISG 2026.","Managed Red Tenant, Managed Dark Tenant, privileged access workstation, PAW, Tier 0, assume breach, Zero Trust, disaster recovery Microsoft 365, recovery time objective, NISG 2026, NIS2 Austria, Configuration as Code, Infrastructure as Code, APT response, CIO Kongress",{"menuItems":1322},[1323,1325,1328,1331,1334],{"href":1324,"text":1205},"#un-computer-due-tab-un-clic",{"href":1326,"text":1327},"#perché-le-risposte-più-ovvie-non-bastano","Le risposte più ovvie",{"href":1329,"text":1330},"#il-managed-red-tenant-la-separazione-come-architettura","La separazione come architettura",{"href":1332,"text":1333},"#e-se-succede-comunque-lextra-life","L'Extra Life",{"href":1335,"text":1279},"#resilienza-in-doppia-copia",{"quote":325,"infos":1337},{"bgColor":837,"color":1338,"boxBgColor":491,"boxColor":1338,"headline":838,"subline":1339,"level":562,"textStyling":840,"flush":841,"person":1340,"form":1352},"var(--color-gk-white)","Vuoi sapere come Managed Red Tenant e Managed Dark Tenant lavorano insieme nel tuo ambiente? Scrivici, esaminiamo il tuo caso in concreto.",{"image":843,"cloudinary":325,"alt":844,"name":520,"quotee":520,"quoteeTitle":845,"quote":1341,"detailsHeader":1342,"details":1343},"Una separazione a metà non è una separazione. Quando il lavoro amministrativo gira sullo stesso dispositivo su cui girano email e browser, è un singolo clic a decidere dell'accesso al Tier 0. È esattamente questa lacuna che chiudiamo architetturalmente, non con l'awareness.","Non vediamo l'ora\u003Cbr />di sentirti.",[1344,1348],{"text":492,"href":1345,"details":1346,"icon":1347},"tel:+49 69 4005520","Chiama ora","site/phone",{"text":1349,"href":1350,"icon":1351},"sales@glueckkanja.com","mailto:sales@glueckkanja.com","site/mail",{"ctaText":848,"cta":1353,"method":809,"action":851,"fields":1354},{"skin":850},[1355,1356,1357,1358,1359,1360,1362,1363,1365,1367,1368,1369],{"type":854,"id":855,"value":856},{"label":858,"type":859,"id":860,"required":325,"requiredMsg":861},{"label":863,"type":859,"id":403,"required":325,"requiredMsg":864},{"label":866,"type":867,"id":867,"required":325,"requiredMsg":868},{"label":870,"type":871,"id":872,"required":484,"requiredMsg":873},{"label":1361,"type":876,"id":877,"required":325,"requiredMsg":878},"I tuoi dati vengono conservati presso di noi per elaborare e rispondere alla tua richiesta. Ulteriori informazioni sulla privacy le trovi nella nostra \u003Ca href=\"/it/privacy\">informativa sulla privacy\u003C/a>.",{"type":854,"id":880,"value":235},{"type":854,"id":882,"value":1364},"AT",{"type":854,"id":885,"value":1366},"Form: Blog Red Tenant Dark Tenant CIO | IT",{"type":854,"id":888,"value":889},{"type":854,"id":891},{"type":854,"id":893},{"form":325},"/posts/2026-09-21-red-tenant-dark-tenant-cio",{"title":1198,"description":529},"posts/2026-09-21-red-tenant-dark-tenant-cio",[235,898,899,1375],"NIS2","kpvLl8Q320JluSbrZwx_qKlsemmf_xn7i4Yqg6-KiS4",[],{"id":1379,"extension":1380,"meta":1381,"stem":8,"__hash__":1393},"authors_data/authors.json","json",{"Jan Geisbauer":1382},{"display_name":520,"avatar":1383,"permalink":1384,"twitter":1385,"linkedin":1385,"imageOffsetTop":1386,"socials":1387},"people/people-jan-geisbauer-csoc.png","/authors/jan-geisbauer","JanGeisbauer","72%",[1388,1390],{"text":472,"href":1389},"https://emptydc.com",{"text":1391,"href":1392},"Podcast","https://hairlessinthecloud.com","1csawlkJxRljy93GTOnXEkwLqAv9Lcj-apxRvoodAOY",1791383970622]