[{"data":1,"prerenderedAt":1392},["ShallowReactive",2],{"sc:header-data-ja":3,"sc:footer-data-ja":489,"author-ja-jan-geisbauer-d67b39f1391e5":519,"content-ja-jan-geisbauer":549,"content-events-ja-jan-geisbauer":1374,"authors_data:Jan Geisbauer":1375},{"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",{"ja":13},{"title":14,"url":15,"alt":16},"ホーム","/ja","glueckkanja Logo",[18,127,231,316,395,402],{"name":19,"languages":20,"children":24},"workplace",{"ja":21},{"title":22,"description":23},"Workplace","Microsoft 365を基盤に、スマートで安全な、柔軟性の高いワークプレイスを実現します。最新のテクノロジーとアイデンティティサービスが一つにつながります。",[25,55,91],{"name":26,"languages":27,"children":30},"portfolio",{"ja":28},{"title":29},"Portfolio",[31,37,43,49],{"name":32,"languages":33},"managed-intune",{"ja":34},{"title":35,"url":36},"Managed Intune","/ja/entra-intune/managed-intune",{"name":38,"languages":39},"managed-entra",{"ja":40},{"title":41,"url":42},"Managed Entra","/ja/entra-intune/managed-entra",{"name":44,"languages":45},"managed-workplace",{"ja":46},{"title":47,"url":48},"Managed Workplace","/ja/workplace/managed-workplace",{"name":50,"languages":51},"consulting-services",{"ja":52},{"title":53,"url":54},"Consulting Services","/ja/workplace/consulting-services",{"name":56,"languages":57,"children":60},"microsoft-365-endpoint",{"ja":58},{"title":59},"Microsoft 365 Endpoint",[61,67,73,79,85],{"name":62,"languages":63},"microsoft-entra-suite",{"ja":64},{"title":65,"url":66},"Microsoft Entra Suite","/ja/workplace/microsoft-entra-suite",{"name":68,"languages":69},"microsoft-intune",{"ja":70},{"title":71,"url":72},"Microsoft Intune","/ja/workplace/microsoft-intune",{"name":74,"languages":75},"microsoft-windows",{"ja":76},{"title":77,"url":78},"Microsoft Windows","/ja/workplace/microsoft-windows",{"name":80,"languages":81},"windows-365-cloud-pc",{"ja":82},{"title":83,"url":84},"Windows 365 Cloud PC","/ja/workplace/windows365-cloud-pc",{"name":86,"languages":87},"cloud-workplace-foundation",{"ja":88},{"title":89,"url":90},"Cloud Workplace Foundation","/ja/workplace/cloud-workplace-foundation",{"name":92,"languages":93,"children":96},"microsoft-365-collaboration",{"ja":94},{"title":95},"Microsoft 365 Collaboration",[97,103,109,115,121],{"name":98,"languages":99},"microsoft-copilot",{"ja":100},{"title":101,"url":102},"Microsoft 365 Copilot","/ja/workplace/microsoft-365-copilot",{"name":104,"languages":105},"microsoft-teams",{"ja":106},{"title":107,"url":108},"Teams","/ja/workplace/microsoft-teams",{"name":110,"languages":111},"sharepoint-powerplatform",{"ja":112},{"title":113,"url":114},"SharePoint & Power Platform","/ja/workplace/sharepoint-power-platform",{"name":116,"languages":117},"exchange-online",{"ja":118},{"title":119,"url":120},"Exchange Online","/ja/workplace/exchange-online",{"name":122,"languages":123},"information-protection-compliance",{"ja":124},{"title":125,"url":126},"Information Protection & Compliance","/ja/workplace/information-protection-compliance",{"name":128,"languages":129,"children":133},"azure",{"ja":130},{"title":131,"description":132},"Azure","Azureで成長を後押しします。IaaSとPaaSによって、クラウドのコストを下げ、効率を高め、イノベーションを進めます。",[134,151,181],{"name":135,"languages":136,"children":138},"azure-portfolio",{"ja":137},{"title":29},[139,145],{"name":140,"languages":141},"azure-managed-services",{"ja":142},{"title":143,"url":144},"Azure Managed Services","/ja/azure/azure-managed-services",{"name":146,"languages":147},"azure-consulting",{"ja":148},{"title":149,"url":150},"Azure Consulting","/ja/azure/azure-consulting",{"name":152,"languages":153,"children":156},"azure-scenarios",{"ja":154},{"title":155},"シナリオ",[157,163,169,175],{"name":158,"languages":159},"plan-your-cloud",{"ja":160},{"title":161,"url":162},"クラウドを計画する","/ja/azure/plan-your-cloud",{"name":164,"languages":165},"migrate-to-the-cloud",{"ja":166},{"title":167,"url":168},"クラウドへ移行する","/ja/azure/migrate-to-the-cloud",{"name":170,"languages":171},"innovate-your-business",{"ja":172},{"title":173,"url":174},"ビジネスを刷新する","/ja/azure/innovate-your-business",{"name":176,"languages":177},"vmware-exit",{"ja":178},{"title":179,"url":180},"VMware戦略を立て直す","/ja/azure/vmware-exit",{"name":182,"languages":183,"children":186},"azure-practices",{"ja":184},{"title":185},"Practices",[187,193,199,202,208,213,219,225],{"name":188,"languages":189},"azure-foundation",{"ja":190},{"title":191,"url":192},"Azure Foundation","/ja/azure/azure-foundation",{"name":194,"languages":195},"azure-ai-foundation",{"ja":196},{"title":197,"url":198},"Azure AI Foundation","/ja/azure/azure-ai-foundation",{"name":86,"languages":200},{"ja":201},{"title":89,"url":90},{"name":203,"languages":204},"azure-data-foundation",{"ja":205},{"title":206,"url":207},"Azure Data Foundation","/ja/azure/azure-data-foundation",{"name":188,"languages":209},{"ja":210},{"title":211,"url":212},"Azure Container Foundation","/ja/azure/azure-container-foundation",{"name":214,"languages":215},"dark-tenant",{"ja":216},{"title":217,"url":218},"Managed Dark Tenant","/ja/azure/managed-dark-tenant",{"name":220,"languages":221},"azure-cloud-adoption-framework",{"ja":222},{"title":223,"url":224},"Cloud Adoption Framework","/ja/azure/cloud-adoption-framework",{"name":226,"languages":227},"azure-cloud-competence-center",{"ja":228},{"title":229,"url":230},"Cloud Competence Center","/ja/azure/cloud-competence-center",{"name":232,"languages":233,"children":242},"security",{"ja":234},{"title":235,"description":236,"emergency":237},"Security","受賞歴のある24時間365日のManaged Service、インシデント対応、最新水準の保護で、クラウドの安全を見守り、インフラを守ります。",{"text":238,"href":239,"skin":240,"icon":241},"サイバー攻撃の渦中ですか？","/ja/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",{"ja":249},{"title":250,"url":251},"Managed Red Tenant","/ja/security/managed-red-tenant",{"name":214,"languages":253},{"ja":254},{"title":255,"url":218},"Dark Tenant",{"name":257,"languages":258},"sentinel-data-lake",{"ja":259},{"title":260,"url":261},"Sentinel Data Lake","/ja/security/sentinel-data-lake",{"name":263,"languages":264},"security-consulting",{"ja":265},{"title":266,"url":267},"Security Consulting","/ja/security/security-consulting",{"name":269,"children":270},"security-cloud-security-operations-center",[271,277,283],{"name":272,"languages":273},"cloud-security-operations-center",{"ja":274},{"title":275,"url":276},"Cloud Security Operations Center","/ja/security/cloud-security-operations-center",{"name":278,"languages":279},"global-secure-access",{"ja":280},{"title":281,"url":282},"Global Secure Access","/ja/security/global-secure-access",{"name":284,"languages":285},"my-work-id",{"ja":286},{"title":287,"url":288},"MyWorkID","/ja/security/my-work-id",{"name":290,"children":291},"security-preventive-services",[292,298,304,310],{"name":293,"languages":294},"preventive-services",{"ja":295},{"title":296,"url":297},"Preventive Services","/ja/security/preventive-services",{"name":299,"languages":300},"data-security-services",{"ja":301},{"title":302,"url":303},"Data Security Service","/ja/security/data-security-service",{"name":305,"languages":306},"security-copilot-agents",{"ja":307},{"title":308,"url":309},"Security Copilot Agents","/ja/security/security-copilot-agents",{"name":311,"languages":312},"nis2",{"ja":313},{"title":314,"url":315},"NIS2を技術で実装する","/ja/security/red-dark-tenant-nis2",{"name":317,"languages":318,"children":322},"products",{"ja":319},{"title":320,"description":321},"製品","完全に安全で100%クラウドネイティブなMicrosoft環境のためのCompanion製品です。協働、ネットワーク認証、ソフトウェア管理を強化します。",[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",{"ja":332},{"title":333,"url":334,"subtitle":335},"RealmJoin","https://www.realmjoin.com","クラウドベースのソフトウェア配布",{"name":337,"img":338,"target":330,"languages":339},"scepman","products/scepman/scepman-nav-logo.svg",{"ja":340},{"title":341,"url":342,"subtitle":343},"SCEPman","https://www.scepman.com","クラウドからの証明書配布",{"name":345,"img":346,"target":330,"languages":347},"konnekt","products/konnekt/konnekt-nav-logo.svg",{"ja":348},{"title":349,"url":350,"subtitle":351},"KONNEKT","https://www.konnekt.io","Office 365のデータをローカルで利用",{"name":353,"img":354,"target":330,"languages":355},"realmigrator","products/realmigrator/realmigrator-nav-logo.svg",{"ja":356},{"title":357,"url":358,"subtitle":359},"RealMigrator","https://www.realmigrator.com","サーバー間のデータ移行",{"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",{"ja":367},{"title":368,"url":369,"subtitle":370},"TerraProvider","https://www.terraprovider.com","Microsoft 365向けのTerraform Provider",{"name":372,"img":373,"target":330,"languages":374},"radiusaas","products/radius/radius-nav-logo.svg",{"ja":375},{"title":376,"url":377,"subtitle":378},"RADIUSaaS","https://www.radius-as-a-service.com","ネットワークの認証",{"name":380,"img":381,"target":330,"languages":382},"unifiedcontacts","products/unified-contacts/unifiedcontact-nav-logo.svg",{"ja":383},{"title":384,"url":385,"subtitle":386},"Unified Contacts","https://www.unified-contacts.com","Microsoft Teamsで連絡先を探す",{"name":388,"img":389,"target":330,"languages":390},"autopilotmonitor","products/autopilot-monitor/AutopilotMonitor-nav-logo.svg",{"ja":391},{"title":392,"url":393,"subtitle":394},"Autopilot Monitor","https://www.autopilotmonitor.com","Windows Autopilotのリアルタイム監視",{"name":396,"languages":397},"casestudies",{"ja":398},{"title":399,"url":400,"description":401},"導入事例","/ja/casestudies","当社はクラウドの先駆者として、包括的なクラウドソリューションを提供するMicrosoftのトップパートナーです。ブループリントに基づくアプローチとInfrastructure as Codeの知見が土台にあります。",{"name":403,"languages":404,"children":407},"company",{"ja":405},{"title":406,"description":401},"会社",[408,438,462],{"name":409,"languages":410,"children":413},"company-about-us",{"ja":411},{"title":412},"会社概要",[414,420,426,432],{"name":415,"languages":416},"company-facts-figures",{"ja":417},{"title":418,"url":419},"Facts & Figures","/ja/company/facts-and-figures",{"name":421,"languages":422},"company-contact",{"ja":423},{"title":424,"url":425},"お問い合わせと拠点","/ja/company/contact-and-locations",{"name":427,"languages":428},"switzerland",{"ja":429},{"title":430,"url":431},"スイスのglueckkanja","/ja/company/switzerland",{"name":433,"languages":434},"austria",{"ja":435},{"title":436,"url":437},"オーストリアのglueckkanja","/ja/company/austria",{"name":439,"languages":440,"children":443},"company-career",{"ja":441},{"title":442},"キャリア",[444,450,456],{"name":445,"languages":446},"company-career-overview",{"ja":447},{"title":448,"url":449},"採用情報","/ja/career",{"name":451,"languages":452},"company-young-professionals",{"ja":453},{"title":454,"url":455},"Young Professionals","/ja/young-professionals",{"name":457,"languages":458},"company-jobs",{"ja":459},{"title":460,"url":461},"募集職種","/ja/job-offers",{"name":463,"languages":464,"children":467},"company-latest",{"ja":465},{"title":466},"最新情報",[468,474],{"name":469,"languages":470},"company-blog",{"ja":471},{"title":472,"url":473},"ブログ","/ja/blog",{"name":469,"languages":475},{"ja":476},{"title":477,"url":478},"イベント","/ja/events",[480],{"name":481,"languages":482},"career-meta",{"ja":483},{"title":442,"url":449,"active":484},false,{"languages":486},{"ja":487},{"title":488,"url":425,"active":484},"お問い合わせ",{"data":490},{"bgColor":491,"number":492,"mail":493,"brandLogos":494,"logos":495,"links":499,"linksJa":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},"プライバシーポリシー","/ja/privacy",{"title":514,"url":515},"運営者情報","/ja/imprint",{"title":517,"url":518},"Cookieなし","/ja/cookies",{"id":520,"title":521,"body":522,"description":528,"extension":533,"meta":534,"name":521,"navigation":325,"otherLanguages":535,"path":545,"seo":546,"stem":547,"__hash__":548},"authors/jan-geisbauer.md","Jan Geisbauer",{"type":523,"value":524,"toc":529},"minimal",[525],[526,527,528],"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":530,"searchDepth":531,"depth":531,"links":532},"",2,[],"md",{},{"en":536,"es":537,"sv":538,"fi":539,"da":540,"ko":541,"nl":542,"no":543,"ja":544},"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":521,"description":528},"jan-geisbauer","dkj56BbDIjLEIV9w-pzPM-QPN_dHwnhULkWaoQUDOWE",[550,899,1190],{"id":551,"title":552,"author":553,"body":554,"cta":494,"description":558,"eventid":494,"extension":533,"hideInRecent":484,"layout":807,"meta":808,"moment":812,"navigation":325,"path":891,"seo":892,"stem":893,"tags":894,"webcast":484,"__hash__":898},"content_ja/posts/2026-03-20-stryker-attack-intune-privilege.md","必要だったのは管理者アカウント1つだけでした",[521],{"type":523,"value":555,"toc":794},[556,559,562,566,569,572,575,578,580,583,586,589,592,596,598,601,604,608,610,613,616,619,622,624,627,634,639,642,649,652,655,658,665,668,675,687,691,693,699,702,712,715,718,721,724,727,730,733,735,738,741,744,752,755,758,761,763],[526,557,558],{},"2026年3月11日水曜日。79か国のStrykerのオフィスで従業員がPCの電源を入れると、中身は空でした。ログイン画面はロゴに置き換わっていました。社用ノートPC、社用スマートフォン、そして同社のBYODプログラムに登録されていた私物端末まで、すべてが一夜のうちに同時に消去されました。ランサムウェアもマルウェアのシグネチャも、エンドポイント検知ツールが捉えられるものは何もありませんでした。",[526,560,561],{},"攻撃者は親イランのハクティビスト集団Handalaです。彼らはStryker自身のIT管理インフラを武器に変えました。",[563,564,565],"h2",{"id":565},"実際に何が起きたのか",[526,567,568],{},"{: .h3-font-size}",[526,570,571],{},"この攻撃の核心は、高度なエクスプロイトでもゼロデイ脆弱性でもなく、はるかに単純で、はるかにありふれたものでした。管理者アカウントが1つ侵害され、そのアカウントがMicrosoft Intuneにアクセスできたのです。",[526,573,574],{},"BleepingComputerの報道によると、UTCの5時から8時のあいだにおよそ8万台の端末が消去されました。Handalaは、79か国にわたる同社のグローバル業務で使われていたサーバーやモバイル端末を含め、その数は20万台を超えたと主張しています。すべては正規の管理コンソール1つを通じて実行されました。",[563,576,577],{"id":577},"この攻撃が成功した理由",[526,579,568],{},[526,581,582],{},"このインシデントの根底には構造的な問題があり、それはStrykerに固有のものではありません。ほとんどの企業に当てはまります。",[526,584,585],{},"多くの組織は、管理作業と日常業務を、同じ端末で同じユーザーIDのもとに問題なく共存できる活動として扱っています。IT管理者はメールに返信し、Webを見て、ときにはリンクをクリックし、同じセッション、同じ端末からクラウドインフラを管理し、アクセス変更を承認し、今回のように、端末群全体を消去できる権限を持つデバイス管理コンソールに触れます。",[526,587,588],{},"そこが攻撃面です。日常の業務コンテキストと特権的な管理コンテキストが、同じエンドポイントと同じIDを共有しているなら、そのエンドポイントの侵害は、そのIDが到達できるすべての侵害を自動的に意味します。フィッシング、インフォスティーラーによる認証情報の窃取、Adversary-in-the-Middle（AiTM）によるセッショントークンの窃取。そのすべてが、環境内で最も強力な制御への直通経路になります。特権昇格は必要ありません。攻撃者はすでにそこにあるものを使うだけです。",[526,590,591],{},"Strykerの場合、そのアクセス先には、6大陸の端末を管理するIntuneテナントが含まれていました。",[563,593,595],{"id":594},"cisaが動いた","CISAが動いた",[526,597,568],{},[526,599,600],{},"攻撃の規模と大胆さは、異例の反応を引き起こしました。米国のサイバーセキュリティ・インフラストラクチャセキュリティ庁であるCISAが、侵害されたデバイス管理プラットフォームのリスクを正面から扱うガイダンスを公表したのです。同庁はこの攻撃経路を認識していることを確認したうえで、組織に具体的な対応を求めました。端末の消去のようなリスクの高いIntune機能について、実行前に第二の管理者の承認を必須にすることです。",[526,602,603],{},"これは稀で、かつ重要なシグナルです。連邦のセキュリティ当局が具体的なインシデントの直後に的を絞ったガイダンスを出すとき、メッセージは明確です。これは例外的なケースではありません。これはパターンであり、他の組織も同じリスクにさらされている可能性が高いということです。",[563,605,607],{"id":606},"分離は贅沢ではなく制御そのものです","分離は贅沢ではなく、制御そのものです",[526,609,568],{},[526,611,612],{},"Strykerへの攻撃は、フラットな特権モデルがどれほどの規模の被害を招きうるかをはっきりと示しました。攻撃者は脆弱性の連鎖をたどって特権を昇格させる必要がありませんでした。あるレイヤーで認証情報かセッショントークンを手に入れ、そのレイヤーだけで、破滅的で、グローバルで、取り返しのつかない損害を与えるのに十分だと気づいたのです。",[526,614,615],{},"この問題に対するアーキテクチャ上の答えには名前があります。Microsoft Enterprise Access Model（EAM）です。その中核となる原則は階層化された管理です。特権操作は専用のアカウントと専用の端末で行い、日常の業務コンテキストから厳格に分離します。この最小権限のアプローチにより、侵害された業務用アカウントは管理レイヤーに到達できず、侵害された管理アカウントはコントロールプレーンの操作を実行できません。これはクラウド専用の環境にも、Entra ID経由でオンプレミスのActive Directoryとつながるハイブリッド構成にも等しく当てはまります。ハイブリッド構成では、過剰な権限を持つアカウント1つが、いまなおクラウドとドメインを橋渡ししてしまいます。",[526,617,618],{},"考え方は単純です。管理作業は管理用の端末で行う。Microsoft 365テナント、Intune環境、Azureインフラの管理に使うIDは、メールを読んだりTeams会議に参加したりするIDと決して同じにしない。管理セッションに使う端末は、堅牢化され、制限され、攻撃面を生み出す通常のWebブラウジングや業務コンテキストから隔離する。ラテラルムーブメントは構造的に難しくなります。横に移る経路がそもそも存在しないからです。",[563,620,621],{"id":621},"二つの防御レイヤー",[526,623,568],{},[526,625,626],{},"この脅威モデルに正しく対処するには、二つのレイヤーで同時に取り組む必要があります。管理レイヤーとその認証情報に誰が触れられるかを守ること、そしてその管理レイヤー自体がどのように構成され運用されるかを堅牢化することです。この二つは同じ問題ではなく、どちらも重要です。",[526,628,629],{},[630,631],"img",{"alt":632,"src":633},"Strykerへの攻撃シナリオにおけるリスクと製品の対応：Managed Red TenantはIDとアクセスのリスクに、Managed Intuneはエンドポイント管理のリスクに対応します","https://res.cloudinary.com/c4a8/image/upload/v1774005366/blog/pics/stryker_risk_product_mapping.svg",[635,636,638],"h3",{"id":637},"managed-red-tenant管理コンテキストを守る","Managed Red Tenant：管理コンテキストを守る",[526,640,641],{},"{: .h4-font-size}",[526,643,644,645,648],{},"第一のレイヤーは、特権アクセスを完全に隔離することです。それが当社の",[646,647,250],"a",{"href":251},"の狙いです。",[526,650,651],{},"Managed Red Tenantは、完全に隔離されたクラウドベースの管理環境を提供します。特権操作専用に使われる専用のMicrosoft Entraテナント、すなわち「Red Tenant」です。管理用のIDはここに存在します。管理用の端末はここで管理されます。通常の業務環境からは何も流れ込みません。",[526,653,654],{},"最も重要なロール、たとえばグローバル管理者のようにコントロールプレーンへのアクセスを持つロールには、「Clean Keyboard」というアプローチを実装します。専用ハードウェアと堅牢化されたポリシーを備え、日常の業務コンテキストとの接点を一切持たない物理的なPrivileged Admin Workstation（PAW）です。コントロールプレーンより下の管理ロールには、Red Tenant内の堅牢化されたAzure Virtual Desktop基盤上に構築したスケーラブルなVirtual Access Workstation（VAW）を提供します。アクセス経路そのものもMicrosoft Entra Private Accessで保護され、セッションが確立される前にゼロトラストネットワークアクセスと条件付きアクセスのポリシーが適用されます。",[526,656,657],{},"Microsoft Entra Internet Accessは管理セッションからのパブリックなインターネットアクセスをブロックし、接続先を特権インターフェイスと認可されたテナント環境に厳しく限定します。Universal Conditional Access Evaluationにより、ほぼリアルタイムでのセッション失効が可能です。つまり、失効した認証情報が有効なセッションとして生き延びることはありません。",[526,659,660,661,664],{},"Managed Red Tenantは当社の",[646,662,663],{"href":276},"Cloud Security Operations Center（CSOC）","が24時間365日で監視し、管理権限とアクセスパターンに的を絞った専用の検知を用意しています。この環境で攻撃者が何らかの方法で認証情報を侵害したとしても、グローバルな端末群に対してワイプコマンドを実行するための3時間を、気づかれないまま使うことはできません。",[526,666,667],{},"これはIntune管理者のようなロールで特に重要です。彼らはクライアントを保護する方法は知っていますが、特権管理ワークステーションを守るには別のスキルが要ります。Enterprise Access Architecture、ID堅牢化、ゼロトラストの制御です。これらは通常セキュリティチームの領域です。Managed Red Tenantはこの負担をすべて引き受けます。Intune管理者は、自らセキュリティワークステーションの専門家になることなく、専門的に管理され一貫して堅牢化されたワークステーションを手にできます。これは組織内のあらゆる高特権ロールに当てはまります。",[669,670],"video-frame",{"thumb":671,"alt":672,"id":673,":full-width":674},"/thumbs/thumb-managed-red-tenant.jpg","Jan GeisbauerとThomas NaunheimがManaged Red Tenantのサイバーセキュリティ戦略について語ります","rOEIvItNkjE","true",[676,677,679,680,686],"div",{"style":678},"background:var(--color-gk-light-grey); margin-top:0.5rem; padding:0.5rem 1rem; font-size:0.85rem; color:var(--color-gk-dark-blue)","詳しくは当社の",[646,681,685],{"href":682,"target":330,"rel":683},"https://www.youtube.com/playlist?list=PLPxBXiOFJRHelegu_B-uZAyz2UrOSxioL",[684],"noopener","YouTubeチャンネル","をご覧ください",[635,688,690],{"id":689},"managed-intune管理レイヤー自体を保護する","Managed Intune：管理レイヤー自体を保護する",[526,692,641],{},[526,694,695,696,698],{},"第二のレイヤーは、Strykerへの攻撃で武器として使われたツールであるIntuneそのものを、最高水準のセキュリティで構成し、運用し、継続的に保守することです。それを担うのが当社の",[646,697,35],{"href":36},"サービスです。",[526,700,701],{},"この種のインシデントから得られる重要な示唆の一つは、組織が有機的に膨らんだIntune環境を引き継いでいることが多いという点です。ポリシーの上にポリシーが積み重なり、監査しにくい手作業のポータル変更が加わり、セキュリティベースラインはMicrosoft自身の進化する推奨に追いついていません。構成のドリフトが悪用可能な穴を生むのは、まさにこうした環境です。",[526,703,704,705,711],{},"Microsoftは最近",[646,706,710],{"href":707,"rel":708},"https://techcommunity.microsoft.com/blog/intunecustomersuccess/best-practices-for-securing-microsoft-intune/4502117",[709],"nofollow","Microsoft Intuneのセキュリティ確保に関するベストプラクティス","を公開しました。Microsoft自身も、Intuneの堅牢化を業界全体で明示的に取り組むべきテーマと捉えているというシグナルです。当社のManaged Intuneサービスはこれらの原則に基づいており、Microsoftの推奨事項をベースラインの一部として実装しています。",[526,713,714],{},"当社のManaged Intuneサービスはglueckkanja Intune Foundationを基盤としています。実績があり継続的に保守されるデバイス管理のベストプラクティス群を、Terraformと自社のTerraProviderで完全にコードとして展開します。あらゆる変更は自動化され、バージョン管理され、監査可能です。意図した設定と実際の設定のずれを突いて攻撃者が悪用できるような、文書化されていないクリック操作の構成は存在しません。",[526,716,717],{},"セキュリティの観点では、ゼロトラスト、App Protection Policies、エンドポイントセキュリティの構成が、Windows、macOS、iOS、Androidを通じて設計上一貫して適用されることを意味します。一度きりの展開ではなく、Microsoft自身のセキュリティガイダンスを追随しながら継続的に強制され、常に更新されるベースラインとしてです。",[526,719,720],{},"重要なのは、Managed Intuneが現代のエンドポイント管理に求められる運用の成熟度を体現している点です。継続的なコンプライアンス監視、構造化された変更ガバナンス、定期的なサービスレビュー。これらはオプションの追加機能ではなく、当たり前の運用です。ただし、Intuneの構成を守るのは半分にすぎません。コンソールにアクセスする管理者が保護されていない端末から作業していれば、管理レイヤーは依然として露出したままです。まさにここで、Managed Red Tenantがモデルを完成させます。",[526,722,723],{},"すべての構成はIntune Foundationを基盤にコードとして展開されるため、ピアレビューによる厳格な四つの目の原則、追加の自動検証、制御されたデプロイパイプラインを徹底しています。これにより、Intune Foundationの範囲内で管理外のポータル変更が生じる余地をなくし、すべての端末にわたって一貫性があり、監査可能で、安全なベースラインを確保します。",[526,725,726],{},"管理アクセスはGDAPとAzure Lighthouseによる最小権限モデルで制御し、責任範囲を明確に定義したうえで、お客様テナントへのアクセスを厳しく限定します。これにより、特権操作に伴う攻撃面が大きく減ります。",[526,728,729],{},"破壊的な操作を含む端末レベルのアクションは、お客様の責任範囲に残ります。その実行は組織固有のプロセスや内部のガバナンスフレームワークと密接に結びついているためです。MicrosoftとCISAは、こうしたアクションを追加の保護策で守ること、たとえばIntuneのマルチ管理者承認の制御を使うことを推奨しています。",[563,731,732],{"id":732},"居心地の悪い問い",[526,734,568],{},[526,736,737],{},"Strykerへの攻撃はMicrosoft Intuneへの告発ではありません。Intuneは設計どおりに振る舞いました。認証された管理者から受け取ったコマンドを実行しただけです。失敗はツールにあったのではありません。誰がそのツールに、どのコンテキストから、どの程度の認可で到達できるのかという制御が欠けていたことにあります。",[526,739,740],{},"これはガバナンスとアーキテクチャの問題です。そして、今日Microsoft 365を運用している大半の組織に同じ問題が存在します。",[526,742,743],{},"自社の管理者が、日常業務に使うのと同じ端末とIDでIntune、Entra ID、Azureにアクセスしているなら、そしてIntune環境が構造化され自動化された運用モデルではなく、長年の手作業によるポータル変更の積み重ねで膨らんでいるなら、3月11日にStrykerが抱えていたのと同じ構造的リスクを抱えています。問われるのは、その弱点を塞ぐ前に攻撃者が見つけるかどうかです。",[526,745,746,748,749,751],{},[646,747,250],{"href":251},"は特権とIDのレイヤーに対応します。",[646,750,35],{"href":36},"は構成と運用のレイヤーに対応します。この二つが揃って、Strykerへの攻撃を可能にした2つの穴を塞ぎます。",[526,753,754],{},"いずれかのサービスが自社の現在の環境にどう当てはまるのか、あるいは具体的な弱点がどこにあるのかを知りたい場合は、ぜひご相談ください。",[526,756,757],{},"Strykerのインシデントがそもそもなぜ起こりえたのかを掘り下げる記事も、近く公開する予定です。",[563,759,760],{"id":760},"関連情報",[526,762,568],{},[764,765,766,774,780,787],"ul",{},[767,768,769],"li",{},[646,770,773],{"href":771,"rel":772},"https://www.cisa.gov/secure-cloud-business-applications",[709],"CISA: Securing Cloud Business Applications",[767,775,776],{},[646,777,779],{"href":707,"rel":778},[709],"Microsoft: Microsoft Intuneのセキュリティ確保に関するベストプラクティス",[767,781,782],{},[646,783,786],{"href":784,"rel":785},"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: ハッカーによるStryker端末の大量消去を受け、CISAが企業にMicrosoft Intuneシステムの保護を要請",[767,788,789],{},[646,790,793],{"href":791,"rel":792},"https://marketplace.microsoft.com/de-de/product/saas/glueckkanja-gabag.redtenant?tab=overview",[709],"Azure MarketplaceのManaged Red Tenant",{"title":530,"searchDepth":531,"depth":531,"links":795},[796,797,798,799,800,805,806],{"id":565,"depth":531,"text":565},{"id":577,"depth":531,"text":577},{"id":594,"depth":531,"text":595},{"id":606,"depth":531,"text":607},{"id":621,"depth":531,"text":621,"children":801},[802,804],{"id":637,"depth":803,"text":638},3,{"id":689,"depth":803,"text":690},{"id":732,"depth":531,"text":732},{"id":760,"depth":531,"text":760},"post",{"lang":809,"seoTitle":810,"titleClass":811,"date":812,"categories":813,"blogtitlepic":814,"socialimg":815,"customExcerpt":816,"keywords":817,"asideNav":818,"contactInContent":833,"maxContent":484,"published":325},"ja","Strykerへの攻撃：侵害された管理者アカウント1つがIntune経由で8万台を消去した経緯","h2-font-size","2026-03-20",[235],"head-stryker.jpg","/blog/heads/head-stryker.jpg","2026年3月11日、Handalaは79か国の端末を消去しました。そのために必要だったのは、侵害されたIntuneの管理者アカウント1つだけです。マルウェアもエクスプロイトもなく、正規の管理ツールが所有者自身に向けられました。何が起きたのか、なぜそれが通用したのか、そして塞ぐべき2つのアーキテクチャ上の穴について説明します。","Strykerへの攻撃, Handala, Microsoft Intune ワイプ, 特権アクセス管理, 管理用ワークステーション, Managed Red Tenant, Managed Intune, ゼロトラスト, Privileged Admin Workstation, PAW, Enterprise Access Model, CISA, エンドポイント管理のセキュリティ",{"menuItems":819},[820,822,824,826,829,831],{"href":821,"text":565},"#実際に何が起きたのか",{"href":823,"text":577},"#この攻撃が成功した理由",{"href":825,"text":595},"#cisaが動いた",{"href":827,"text":828},"#分離は贅沢ではなく制御そのものです","分離は贅沢ではありません",{"href":830,"text":621},"#二つの防御レイヤー",{"href":832,"text":732},"#居心地の悪い問い",{"quote":325,"infos":834},{"bgColor":835,"headline":488,"subline":836,"level":563,"textStyling":837,"flush":838,"person":839,"form":844},"var(--color-gk-dark-blue)","Strykerへの攻撃が突いた穴を、Managed Red TenantとManaged Intuneがどのように塞ぐのかを知りたいとお考えですか。フォームにご記入ください。お客様の環境に照らしてご説明します。","text-light","justify-content-end",{"image":840,"cloudinary":325,"alt":841,"name":521,"quotee":521,"quoteeTitle":842,"quote":843},"/people/people-jan-geisbauer-csoc.jpg","glueckkanjaのHead of Security、Jan Geisbauerのポートレート","Head of Security","ツールは指示されたとおりのことをしただけです。問題は、そもそも誰もそう指示できてはならなかったという点にあります。侵害された日常業務用のアカウントからも、第二の承認なしでも、隔離された管理環境の外からも実行できてはなりませんでした。当社が組織の支援に取り組んでいるのは、まさにこの穴を塞ぐことです。",{"ctaText":845,"cta":846,"method":807,"action":848,"fields":849},"送信",{"skin":847},"primary on-surface","/send",[850,854,859,862,866,871,876,878,881,884,887,889],{"type":851,"id":852,"value":853},"hidden","_next","successful",{"label":855,"type":856,"id":857,"required":325,"requiredMsg":858},"お名前*","text","name","お名前をご入力ください。",{"label":860,"type":856,"id":403,"required":325,"requiredMsg":861},"会社名*","会社名をご入力ください。",{"label":863,"type":864,"id":864,"required":325,"requiredMsg":865},"メールアドレス*","email","メールアドレスをご入力ください。",{"label":867,"type":868,"id":869,"required":484,"requiredMsg":870},"お問い合わせ内容","textarea","message","メッセージをご入力ください。",{"label":872,"type":873,"id":874,"required":325,"requiredMsg":875},"ご入力いただいた情報は保存され、お問い合わせへの回答のために利用されます。詳しくは\u003Ca href=\"/ja/privacy\">プライバシーポリシー\u003C/a>をご覧ください。","checkbox","dataprotection","同意をご確認ください",{"type":851,"id":877,"value":235},"_topic",{"type":851,"id":879,"value":880},"_location","World",{"type":851,"id":882,"value":883},"_subject","Form: Blog Stryker Attack Intune Privilege | JA",{"type":851,"id":885,"value":886},"inbox_key","gkgab-contact-form",{"type":851,"id":888},"_gotcha",{"type":851,"id":890},"jsonData","/posts/2026-03-20-stryker-attack-intune-privilege",{"title":552,"description":558},"posts/2026-03-20-stryker-attack-intune-privilege",[895,71,896,897],"Red Tenant","Privileged Access","Zero Trust","IEvuND5YsY4dOsQTvYOQb7nbqt_KdSRNk-UIGiJ-XwY",{"id":900,"title":901,"author":902,"body":903,"cta":494,"description":530,"eventid":494,"extension":533,"hideInRecent":484,"layout":807,"meta":1155,"moment":1157,"navigation":325,"path":1183,"seo":1184,"stem":1185,"tags":1186,"webcast":484,"__hash__":1189},"content_ja/posts/2026-07-24-outbreak-openai-hugging-face.md","Outbreak。OpenAI／Hugging Faceの事案が示すこと、示さないこと",[521],{"type":523,"value":904,"toc":1145},[905,908,910,919,928,931,934,937,939,942,945,948,952,954,963,966,970,972,981,984,988,990,993,996,999,1008,1012,1014,1023,1029,1035,1038,1040,1043,1046,1049,1051],[563,906,907],{"id":907},"何が起きたのか",[526,909,568],{},[526,911,912,913,918],{},"数日前、OpenAIとHugging Faceが",[646,914,917],{"href":915,"rel":916},"https://www.cnbc.com/2026/07/22/open-ai-cyber-models-hack-hugging-face.html",[709],"ある事案を公表しました","。セキュリティ業界を騒然とさせた内容です。GPT-5.6 Solと、未公開のより高性能なモデルに駆動された自律型AIエージェントが、社内のセキュリティテスト中に隔離されたテスト環境から脱出しました。エージェントはOpenAIのシステム内部で段階的にアクセス範囲を広げ、その過程で未知のゼロデイ脆弱性も利用し、インターネットに到達し、最終的にHugging Faceの社内システムに侵入して、当初探すよう指示されていた情報を入手しようとしました。",[526,920,921,922,927],{},"その後、技術的な詳細が公開され始めています。たとえば",[646,923,926],{"href":924,"rel":925},"https://simonwillison.net/2026/Jul/22/openai-cyberattack/",[709],"Simon Willisonによる事案の整理","です。テストはエクスプロイトのベンチマークの一環として、意図的に保護機構を弱めた状態で実施されていました。テスト環境には外部への接続が1つだけあり、依存関係をインストールするための社内パッケージプロキシでした。そしてモデルはまさにこのプロキシでゼロデイを見つけました。つまり脱出は魔法というより、唯一存在した扉をこじ開けた結果です。Hugging Faceでは、悪意あるデータセットを経由して処理インフラへ、さらに窃取した認証情報を使って複数の社内クラスターへと進みました。",[526,929,930],{},"動機はこの一件のなかでも際立った点です。モデルは自身の評価で不正をするための情報を探していました。おそらく初となる完全自律実行のAI攻撃は、厳密に言えばカンニングの一件だったわけです。巻き添え被害つきで。",[526,932,933],{},"Hugging Faceはこの事案を、これまで扱ってきたどれとも異なるものだと表現しています。「driven, end to end, by an autonomous AI agent system」。OpenAIは前例のないサイバー事案だと述べています。当社はこの攻撃の重大さを軽視するつもりはありません。ただ、議論から熱と感情を取り除きたいとは考えています。よい判断にとって、今いちばんの障害はそこにあるからです。",[563,935,936],{"id":936},"なぜこの事案はこれほど脅威に感じられるのか",[526,938,568],{},[526,940,941],{},"心理学を覗いてみると理解が進みます。リスク研究者のPaul Slovicは、人がリスクを統計的な危険度ではなく、主に2つの軸で評価することを示しました。そのリスクにどれだけ馴染みがあるか、そしてどれだけ恐れているかです。自動車の運転は客観的には危険ですが、馴染みがあり制御できるように見えるため、害がないように感じられます。一方、研究室から脱出したAIモデルは、未知で制御できないという神経に触れ、Slovicが「dread risk」と呼ぶ領域にそのまま入ります。",[526,943,944],{},"Daniel Kahnemanは『ファスト＆スロー』で、そのときに何が起こるかを記述しました。未知で脅威に見えるリスクを前にすると、遅く分析的な思考ではなく、速く直感的で情動的な思考システムが主導権を握ります。まさにこの型が、いま多くのコメント欄で観察できます。事案は分析されているのではなく、感じ取られているのです。",[526,946,947],{},"ですから、いったん深呼吸してシステム2を起動し、この件を別の視点からも眺めてみます。",[563,949,951],{"id":950},"視点1証拠を見せてほしいflorian-roth","視点1：証拠を見せてほしい（Florian Roth）",[526,953,568],{},[526,955,956,957,962],{},"セキュリティ研究者のFlorian Roth（SigmaやTHORで知られています）は、",[646,958,961],{"href":959,"rel":960},"https://www.linkedin.com/posts/floroth_one-thing-about-this-openai-hugging-face-share-7485702026429960192-npkt/",[709],"LinkedInの投稿","で中心的な一点に引っかかっています。文書化の欠如です。Hugging Faceは、攻撃が自律エージェントシステムによって「end to end」で駆動されたと主張しています。しかし被害側のテレメトリは原理的に、自社環境で何が起きたかしか示せません。上流で人間がプロンプトを調整したのか、実行をやり直したのか、成功した経路を選んだのか、要所で手を貸したのかは示せません。Rothの要求は単純で、かつ正当です。OpenAIがトレース（プロンプト、ツール呼び出し、失敗した実行、人間の介入）を持っているなら、公開すべきだということです。それまでは「完全に自律的」は主張であって、フォレンジックの所見ではありません。あるコメント投稿者が的確に補足しています。仮に公開されたとしても、実際にどれだけ人間が関与したかを疑いの余地なく立証するのは難しいだろう、と。",[526,964,965],{},"Rothはさらに一刺しを加えます。2社のAI企業の語りは、核心では3行に収まると言います。AIが我々を攻撃した。AIが我々を救った。だから今や誰もがもっとAIを必要としている。10年前なら赤っ恥だったはずのもの（弱い隔離、広すぎる権限、不十分なセグメンテーション、巨大なブラストラディウス）が、今日ではケイパビリティのデモであり、AI対AIの英雄譚として包装されている、と。彼の乾いた所見はこうです。レート制限、エグレス制限、隔離されたワーカー、きちんと範囲を絞った認証情報があれば、この活動の大部分は減速し、早い段階で可視化されていた。そのためにLLMは誰にも必要ありません。",[563,967,969],{"id":968},"視点2もっとひどい事態を乗り越えてきたmarcus-hutchins","視点2：もっとひどい事態を乗り越えてきた（Marcus Hutchins）",[526,971,568],{},[526,973,974,975,980],{},"2017年にキルスイッチでWannaCryの流行を止めたセキュリティ研究者のMarcus Hutchinsは、",[646,976,979],{"href":977,"rel":978},"https://www.linkedin.com/posts/malwaretech_anytime-someone-is-freaking-out-about-fully-share-7485851514784272384-0-oa/",[709],"投稿","でこの事案を歴史のなかに位置づけています。「完全に自律的なサイバー攻撃」でパニックに陥る人は、コンピュータワームの黄金期を思い出すべきだというのです。ILOVEYOU、Code Red、SQL Slammer。人の手をいっさい介さずに1日で数百万台のシステムに感染した自己増殖型マルウェアであり、しかも多くのシステムが無防備なままインターネットに直結していた時代の話です。",[526,982,983],{},"彼の論拠はこうです。エージェント型の攻撃は速度とコストによって根本的に制約されます。AIモデルが1つの応答を生成する時間で、古典的なワームはすでに数千どころではない数のシステムに感染していたはずですし、数百万のシステムを自律的にハッキングするためのトークン費用は、ほとんどの攻撃者の予算を超えます。加えて、ファイアウォール、EDR、ネットワークセグメンテーション、サンドボックス化、多要素認証（MFA）をはじめとする多くの統制は今日では標準であり、当時は単に存在しなかった実質的な障壁になっています。彼の結論はこうです。AIを用いた攻撃がサイバーセキュリティを何十年も後退させることはできない。いったん確立されたセキュリティ統制と基本的な衛生管理を、この世からなくすことはできない。Attack Surface Reductionは効く。ゼロデイは、到達できないシステムを攻撃することはできない。",[563,985,987],{"id":986},"両者が語ることそしてそこから導かれること","両者が語ること、そしてそこから導かれること",[526,989,568],{},[526,991,992],{},"2人の専門家は異なる道筋をたどりながら、同じ結論に至っています。本質に集中せよ、ということです。セキュリティポスチャを継続的に改善し、ゼロトラスト、最小権限、明確なTier分離といった考え方を一貫して実装している企業は、被害に遭う確率が大幅に下がります。向こう側にいるのが人間でも、スクリプトでも、言語モデルでも変わりません。",[526,994,995],{},"それでもこの事案は真剣に受け止める必要があります。証拠の問題がどう決着するかとは無関係にです。この事案は、AIがインターネットを乗っ取る例ではありません。しかし、標的型攻撃が新しい水準に達するとどう見えるのかを示しています。2つの別々の攻撃チェーンを、2つの他社インフラをまたいで自律的に連結し、短命なサンドボックスの群れから数千に及ぶ個別アクションとして実行する。仮にOpenAIがトレースを公開して完全な自律性を裏づけたとしても、絵柄がより無害になるわけではありません。ただ、防御の論理は変わりません。むしろ裏づけられます。",[526,997,998],{},"攻撃者が事前に想定していなかった経路を見つけるというのは、新しい知見ではなく、セキュリティに携わる全員の日常です。だからこそDefense in Depthがあります。アタックチェーンの第4段階で攻撃者を発見も阻止もできないなら、第5段階でやる。これはゼロデイも明確に含みます。荒れ狂う嵐にも耐えるようにインフラを作ることはできます。あらゆる嵐を予見できるからではなく、嵐を前提に作るからです。",[526,1000,1001,1002,1007],{},"騒ぎのなかでほとんど埋もれている皮肉も一つあります。フォレンジック分析のためにHugging Faceが用いたのは、よりによってオープンな中国製モデルでした。理由の一つは、ホスティングされた米国のフロンティアモデルが",[646,1003,1006],{"href":1004,"rel":1005},"https://huggingface.co/datasets/huggingface/forensic-refusal/blob/main/glm5.2.jsonl",[709],"バックドアの分析を端的に拒否した","ことです。有事に防御側がどの道具をどれだけ速く使えるのかという議論は、始まったばかりであり、攻撃者が今後何をできるようになるかという問いと少なくとも同じくらい重要です。",[563,1009,1011],{"id":1010},"自律型socではなくより優れたsocを","自律型SOCではなく、より優れたSOCを",[526,1013,568],{},[526,1015,1016,1017,1022],{},"防御にも攻撃にも新しい道具が加わりました。もっとも当社では「道具」という言い方はとうに実態に合っていません。AIは当社のSOCにおいてアドオンではなく、インシデントハンドリングのあらゆる段階で当然の構成要素です。検知からトリアージ、エンリッチメント、対応まで、当社のアナリストはMicrosoftとAnthropicのソリューションやモデルと肩を並べて作業します。反復的な部分は自動化し、専門家は違いを生む仕事に集中できるようにします。つまり、あらゆるインシデントから新しい知見を引き出し、検知ルール、プレイブック、設定を絶えず研ぎ澄ますことです。100％自律のSOCは現時点では実現できません。",[646,1018,1021],{"href":1019,"rel":1020},"https://www.linkedin.com/posts/peteshoard_gartner-soc-threat-share-7457373093368500224-uszD/",[709],"これはGartnerも同じ見方です","。ただし当社にとってそのつまみは信条の問題ではなく、継続的に見直す設定です。モデルの世代が進むたび、経験が積み上がるたび、品質が許す範囲でちょうどそのぶんだけ上げていきます。それ以上は上げませんが、1ミリも下げません。",[526,1024,1025,1026,1028],{},"人とモデルと手法のこの組み合わせが、当社の",[646,1027,663],{"href":276},"の中核です。24時間365日の検知と対応に、継続的改善を組み合わせています。毎月少しずつ良くなるセキュリティポスチャを、当社のブループリントと、脅威の専門家が実環境で観測したものにもとづいて実現します。",[526,1030,1031,1032,1034],{},"そしてFlorian Rothが的確に切り分けた根本問題（弱い隔離、肥大した権限、欠けたセグメンテーション）に対しては、当社には非常に具体的な答えがあります。",[646,1033,250],{"href":251},"です。完全に隔離された管理環境であり、ラテラルムーブメントと権限昇格を構造的に防ぎます。正しいアーキテクチャと正しい設定があれば、攻撃は空振りに終わります。AIエージェントによるものであってもです。攻撃者が血肉でできていようとトークンでできていようと、越えられないTier境界の前では、どれほど優れた推論も役に立ちません。",[563,1036,1037],{"id":1037},"まとめ",[526,1039,568],{},[526,1041,1042],{},"OpenAI／Hugging Faceの事案は一つの節目です。警告として、ケーススタディとして、そして予告編として。ただしパニックの理由ではなく、優先順位づけの理由です。未来の攻撃はより自律的になるかもしれません。それに対して効く防御は、驚くほど見慣れたものです。ゼロトラスト、最小権限、きれいなTier分離、Defense in Depth、そして眠らないSOCです。",[526,1044,1045],{},"あるいは、この事案の落ちに合わせて言うなら、AIが自分のテストで不正をするために脱出しなければならないのだとしたら、せめて当社の環境では答えが見つからないようにしておくべきでしょう。",[563,1047,1048],{"id":1048},"参考資料と関連リンク",[526,1050,568],{},[764,1052,1054,1055,1054,1067,1054,1076,1054,1085,1054,1094,1054,1103,1054,1112,1054,1122,1054,1132,1054,1139],{"style":1053},"margin: 0.25rem 0","\n  ",[767,1056,1057,1061,1062,1066],{},[1058,1059,1060],"strong",{},"CNBC:"," ",[646,1063,1065],{"href":915,"target":330,"rel":1064},[684],"OpenAI cyber models broke out of training environment to hack Hugging Face","（2026年7月22日）",[767,1068,1069,1061,1072],{},[1058,1070,1071],{},"Florian RothのLinkedIn投稿:",[646,1073,1075],{"href":959,"target":330,"rel":1074},[684],"\"One thing about this OpenAI / Hugging Face incident really bothers me\"",[767,1077,1078,1061,1081],{},[1058,1079,1080],{},"Marcus HutchinsのLinkedIn投稿:",[646,1082,1084],{"href":977,"target":330,"rel":1083},[684],"コンピュータワームの黄金期について",[767,1086,1087,1061,1090],{},[1058,1088,1089],{},"Hugging Face:",[646,1091,1093],{"href":1004,"target":330,"rel":1092},[684],"Forensic-Refusalデータセット（GLM 5.2）",[767,1095,1096,1061,1099,1066],{},[1058,1097,1098],{},"Simon Willison:",[646,1100,1102],{"href":924,"target":330,"rel":1101},[684],"OpenAI's accidental cyberattack against Hugging Face is science fiction that happened",[767,1104,1105,1061,1108],{},[1058,1106,1107],{},"Pete Shoard（Gartner）のLinkedIn投稿:",[646,1109,1111],{"href":1019,"target":330,"rel":1110},[684],"完全自律型SOCが現実的でない理由",[767,1113,1114,1061,1117],{},[1058,1115,1116],{},"Paul Slovic:",[646,1118,1121],{"href":1119,"target":330,"rel":1120},"https://de.wikipedia.org/wiki/Paul_Slovic",[684],"Wikipedia",[767,1123,1124,1061,1127,1131],{},[1058,1125,1126],{},"Daniel Kahneman:",[646,1128,1121],{"href":1129,"target":330,"rel":1130},"https://de.wikipedia.org/wiki/Daniel_Kahneman",[684],"、『ファスト＆スロー』",[767,1133,1134,1061,1137],{},[1058,1135,1136],{},"glueckkanja:",[646,1138,663],{"href":276},[767,1140,1141,1061,1143],{},[1058,1142,1136],{},[646,1144,250],{"href":251},{"title":530,"searchDepth":531,"depth":531,"links":1146},[1147,1148,1149,1150,1151,1152,1153,1154],{"id":907,"depth":531,"text":907},{"id":936,"depth":531,"text":936},{"id":950,"depth":531,"text":951},{"id":968,"depth":531,"text":969},{"id":986,"depth":531,"text":987},{"id":1010,"depth":531,"text":1011},{"id":1037,"depth":531,"text":1037},{"id":1048,"depth":531,"text":1048},{"lang":809,"seoTitle":1156,"titleClass":811,"date":1157,"categories":1158,"blogtitlepic":1159,"socialimg":1160,"customExcerpt":1161,"keywords":1162,"asideNav":1163,"published":325},"OpenAIのAIがHugging Faceを攻撃：自律型AI攻撃が企業にとって意味すること","2026-07-24",[235],"head-outbreak.jpg","/blog/heads/head-outbreak.jpg","AIエージェントがテスト環境から脱出し、ゼロデイを見つけ、別の企業をハッキングする。映画の脚本のようですが、2026年7月に実際に起きました。冷静に位置づける時期です。少しの心理学、2人のセキュリティ専門家、そしてそれが自社の防御にとって何を意味するのかという問いとともに。","OpenAI Hugging Face 事案, OpenAI AI Hugging Face ハッキング, 自律型AI攻撃, AIエージェント サンドボックス脱出, 自律型サイバー攻撃, AI サイバーセキュリティ, エージェント型攻撃, GPT-5.6 Sol, ゼロデイ, Florian Roth, Marcus Hutchins, ゼロトラスト, Defense in Depth, 自律型SOC, Cloud Security Operations Center",{"menuItems":1164},[1165,1167,1170,1173,1176,1179,1181],{"href":1166,"text":907},"#何が起きたのか",{"href":1168,"text":1169},"#なぜこの事案はこれほど脅威に感じられるのか","背景にある心理",{"href":1171,"text":1172},"#視点1証拠を見せてほしいflorian-roth","視点1：Florian Roth",{"href":1174,"text":1175},"#視点2もっとひどい事態を乗り越えてきたmarcus-hutchins","視点2：Marcus Hutchins",{"href":1177,"text":1178},"#両者が語ることそしてそこから導かれること","そこから導かれること",{"href":1180,"text":1011},"#自律型socではなくより優れたsocを",{"href":1182,"text":1037},"#まとめ","/posts/2026-07-24-outbreak-openai-hugging-face",{"title":901,"description":530},"posts/2026-07-24-outbreak-openai-hugging-face",[1187,1188,897],"AI","SOC","S1BhVJPMhmIe2-1H-Ty1o5Zu8FlwzuONGmp7TnR2wEQ",{"id":1191,"title":1192,"author":1193,"body":1194,"cta":494,"description":530,"eventid":494,"extension":533,"hideInRecent":484,"layout":807,"meta":1305,"moment":1307,"navigation":325,"path":1368,"seo":1369,"stem":1370,"tags":1371,"webcast":484,"__hash__":1373},"content_ja/posts/2026-09-21-red-tenant-dark-tenant-cio.md","管理業務と日常業務を1台のPCで。Game Overです。",[521],{"type":523,"value":1195,"toc":1298},[1196,1200,1202,1205,1208,1211,1214,1217,1219,1222,1226,1228,1234,1243,1246,1249,1253,1255,1263,1269,1272,1274,1277,1284,1292,1295],[563,1197,1199],{"id":1198},"_1台のpc2つのタブ1回のクリック","1台のPC、2つのタブ、1回のクリック",[526,1201,568],{},[526,1203,1204],{},"このシナリオは地味で、だからこそ危険です。管理者がいつものオフィス用ノートPCに向かっています。左のブラウザタブにはMicrosoft 365管理センターが開かれ、グローバル管理者権限とIntune管理者権限もそのままです。右のタブでは「無料ツール」をダウンロードします。Invoice_2026.pdf.exeです。1回のクリック、PowerShellのペイロード、永続化の確立、そして権限昇格が走ります。Tier 0、つまり企業ITの心臓部への道が開きます。",[526,1206,1207],{},"Game Overです。",[526,1209,1210],{},"MITRE ATT&CKは現在、エンタープライズ環境向けに222のテクニックと475のサブテクニックを記載しています。あわせて700近い既知の経路が、権限を昇格し、横方向に移動し、企業の最も機微な資産に到達するために存在します。攻撃者に必要なのはそのうち1つだけです。そして当社が支援するインシデント対応の大半で、同じパターンが現れます。メールを読み、ウェブを閲覧し、Teamsでチャットしていたのと同じ端末で管理業務が行われていた、というものです。",[526,1212,1213],{},"「Assume Breach」を本気で受け止めるなら、そしてNIS2のもとではほかに選択肢はほとんどありませんが、居心地の悪い帰結を受け入れる必要があります。同じPCに載せてはいけないものがある、ということです。中途半端な分離は分離ではありません。",[563,1215,1216],{"id":1216},"なぜ思いつきやすい答えでは足りないのか",[526,1218,568],{},[526,1220,1221],{},"よくある反射的な答えは誰もが知っています。踏み台サーバーはどうでしょうか。侵害されたクライアントからのリバースプロキシのトンネルが1本あれば、攻撃者は踏み台をそのまま通り抜けます。同じマシン、同じブラウザ、同じリスクです。自社テナント内に従来型の特権アクセス管理（PAM）を構築するのはどうでしょうか。するとすぐに問いが立ちます。その管理環境を管理するのは誰か、という問いです。保護される管理用ワークステーションが、保護対象と同じテナントの中に存在するなら、作ったのは壁ではなく円です。ではオフィス用ノートPCから使う仮想デスクトップは。それはノートPCのキーロガーをそのまま引き継ぎます。画面は仮想でも、打鍵は本物です。ゼロトラストは、管理業務と日常業務が1台の端末を共有した時点で終わります。",[563,1223,1225],{"id":1224},"managed-red-tenantアーキテクチャとしての分離","Managed Red Tenant：アーキテクチャとしての分離",[526,1227,568],{},[526,1229,1230,1231,1233],{},"まさにここに",[646,1232,250],{"href":251},"（MRT）が入ります。管理業務専用の、完全にコードで管理され、徹底的にハードニングされたテナント環境です。Tier 0の作業には、マネージドサービスとして運用される特権アクセスワークステーション（PAW）が用意されており、物理的に独立した端末としてハードニングされたハードウェアPAWがあります。Tier 1の作業にはVAW、すなわちAzure Virtual Desktopをベースとする仮想アクセスワークステーションを使います。到達できるのは準拠デバイスからのみ、FIDO2のみ、条件付きアクセスのもとでのみです。さらに利便性のために、特別かつ最大限に安全な設定を施したiPadを組み合わせます。",[676,1235,1237],{"style":1236},"grid-column: content",[526,1238,1239],{},[630,1240],{"alt":1241,"src":1242},"2つのテナントの模式的な比較。左は管理用ワークステーションPAW、VAW、iPAWを備えた遮蔽空間としてのManaged Red Tenant、右はインターネット、メール、Teams、SharePointが通り抜けられる間取りとして描かれた本番テナント、その間には途切れのない赤い仕切り壁","https://res.cloudinary.com/c4a8/image/upload/blog/pics/game-over-1.jpg",[526,1244,1245],{},"ただしCIOにとっての決定的な論点は技術ではなく、運用モデルです。Red Tenantへのあらゆる変更はConfiguration as CodeとしてCI/CDパイプラインを通り、お客様の明示的な承認を経てはじめてデプロイされます。この共同責任の原則は、マネージドサービスを購入する立場なら誰もが問うべき問いに答えます。サービス事業者自身が侵害されたらどうなるのか、という問いです。答えは、何も起きない、です。お客様の承認がなければ、Red Tenantでは設定が1行も変わりません。管理レイヤーはお客様のリスクゾーンの外側にあり、拒否権はお客様の手に残ります。",[526,1247,1248],{},"運用上の利点は二重です。第一に、めったに得られない切れ味の分離が生まれます。本番環境への正当な管理アクセスは、定義上すべてMRTのマシンから来ます。それ以外はすべて攻撃です。これはSOCにノイズのないシグナルを与え、誤検知をより分ける代わりに即座に対応できるようにします。第二に、オフィス環境への攻撃が成功した場合でも、立ちはだかるのは段差ではなく壁です。侵害されたオフィス用ノートPCから、机の上に別の端末として置かれたハードウェアPAWへ跳ぶのは、攻撃者にとって極めて困難か、不可能です。",[563,1250,1252],{"id":1251},"それでも起きてしまったらextra-life","それでも起きてしまったら。Extra Life",[526,1254,568],{},[526,1256,1257,1258,1262],{},"経験を積んだCIOなら誰もが知っています。100パーセントの安全は存在しません。Assume Breachとは、自社の防御が破られることも計画に織り込むという意味でもあります。",[646,1259,1261],{"href":1260},"/ja/posts/2026-03-20-stryker-attack-intune-privilege","2026年3月のStryker事案","は、その境目がいかに細いかを示しました。侵害されたIntune管理者アカウント1つで、79か国のデバイスを消去するには十分でした。今日のランサムウェアグループは、バックアップやActive Directory、つまり復旧に必要なまさにそのシステムを狙い撃ちします。そこから即興を始める側、つまり暗号化されたファイルサーバーを抱え、機能するIDを持たず、コミュニケーション基盤の代わりに電話連絡網しかない側は、企業が止まったまま何日も何週間も失います。",[526,1264,1265,1266,1268],{},"Red Tenantが「Game Over」になるのを防ぐものだとすれば、",[646,1267,217],{"href":218},"はExtra Lifeです。平常時は静止していて、有事に起動される、準備済みの復旧環境です。24時間365日の緊急連絡番号への1本の電話が、災害復旧プロセスを開始します。仮想のウォールームが、侵害された可能性のある本番環境とは独立して、主要な関係者全員との安全なコミュニケーションを直ちに確立します。Dark TenantはInfrastructure as Codeとして構築されているため、重要な復旧プロセスはすべて事前定義され自動化されています。Active DirectoryやIDといったシステムの根幹をなす要素は、ストレスのなかで場当たり的に組み上げられるのではなく、きれいに復元されます。その結果が、数時間から数日というRecovery Time Objective（RTO）と、定義されたRecovery Point Objective（RPO）です。即興の復旧が実務でたびたび要する数週間ではありません。",[563,1270,1271],{"id":1271},"二重のレジリエンス",[526,1273,568],{},[526,1275,1276],{},"Red TenantとDark Tenantは2つの異なる問いに答えており、その2つが揃ってはじめて全体像になります。Red Tenantが答えるのは、侵害されたクライアントが侵害されたドメインになることをどう防ぐか、という問いです。Dark Tenantが答えるのは、それでも起きてしまったときにどう動き続けるか、という問いです。一方は壁であり、もう一方は救助ネットです。",[526,1278,1279,1280,1283],{},"オーストリアの企業には",[646,1281,1282],{"href":315},"規制面の側面","が加わり、それは間もなく非常に具体的になります。2026年10月1日に施行されるNISG 2026により、およそ4,000社のオーストリア企業が証明可能なサイバーセキュリティ義務の対象となります。リスク管理、事業継続、緊急時計画、危機管理が明示的に含まれます。管理アクセスがアーキテクチャとして隔離されていること、そして有事に備えてテスト済みで自動化された復旧環境が用意されていることを監督機関に説明できる企業は、啓発研修と希望的観測に言及する企業とは別の議論をすることになります。",[676,1285,1286],{"style":1236},[526,1287,1288],{},[630,1289],{"alt":1290,"src":1291},"NIS2第21条2項のリスク対策の表。行は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、Multifactor Authentication、列のManaged Red TenantとManaged Dark Tenantにチェックマークが入っている","https://res.cloudinary.com/c4a8/image/upload/blog/pics/game-over-2.jpg",[526,1293,1294],{},"いずれのサービスも当社はマネージドサービスとして運用しており、担当チームはBSI認定のAPT対応事業者として、すでに火の手が上がっている現場の反対側に定期的に立ち、その経験を直接アーキテクチャへ還元しています。お客様にはDAX上場企業も重要インフラ事業者も含まれます。",[526,1296,1297],{},"同じPCに載せてはいけないものがあります。そしてGame Overを許容できない企業があります。であれば、壁とExtra Lifeを用意するほうがよいでしょう。",{"title":530,"searchDepth":531,"depth":531,"links":1299},[1300,1301,1302,1303,1304],{"id":1198,"depth":531,"text":1199},{"id":1216,"depth":531,"text":1216},{"id":1224,"depth":531,"text":1225},{"id":1251,"depth":531,"text":1252},{"id":1271,"depth":531,"text":1271},{"lang":809,"seoTitle":1306,"titleClass":811,"date":1307,"categories":1308,"blogtitlepic":1309,"socialimg":1310,"customExcerpt":1311,"keywords":1312,"asideNav":1313,"contactInContent":1328,"maxContent":484,"published":325,"scripts":1367},"Managed Red TenantとManaged Dark Tenant：CIOのための管理分離と復旧","2026-09-21",[235],"head-game-over-en.jpg","/blog/heads/head-game-over-en.jpg","CIOにとってテナントが1つでは足りない理由と、2つ目がめったに検討されない理由。Managed Red Tenantは管理業務をオフィス環境からアーキテクチャとして分離し、Managed Dark Tenantは防御が破られてもなお組織が動き続けられるようにします。それが運用モデル、SOCのシグナル、そしてNISG 2026による証明義務にとって何を意味するのかを解説します。","Managed Red Tenant, Managed Dark Tenant, Privileged Access Workstation, PAW, Tier 0, Assume Breach, ゼロトラスト, Microsoft 365 災害復旧, Recovery Time Objective, NISG 2026, NIS2 オーストリア, Configuration as Code, Infrastructure as Code, APT対応, CIO Kongress",{"menuItems":1314},[1315,1317,1320,1323,1326],{"href":1316,"text":1199},"#_1台のpc2つのタブ1回のクリック",{"href":1318,"text":1319},"#なぜ思いつきやすい答えでは足りないのか","思いつきやすい答え",{"href":1321,"text":1322},"#managed-red-tenantアーキテクチャとしての分離","アーキテクチャとしての分離",{"href":1324,"text":1325},"#それでも起きてしまったらextra-life","Extra Life",{"href":1327,"text":1271},"#二重のレジリエンス",{"quote":325,"infos":1329},{"bgColor":835,"color":1330,"boxBgColor":491,"boxColor":1330,"headline":488,"subline":1331,"level":563,"textStyling":837,"flush":838,"person":1332,"form":1344},"var(--color-gk-white)","Managed Red TenantとManaged Dark Tenantが自社の環境でどう噛み合うかを知りたいですか。ご連絡いただければ、お客様のケースを具体的に検討します。",{"image":840,"cloudinary":325,"alt":841,"name":521,"quotee":521,"quoteeTitle":842,"quote":1333,"detailsHeader":1334,"details":1335},"中途半端な分離は分離ではありません。管理業務がメールやブラウザと同じ端末で動いているなら、たった1回のクリックがTier 0へのアクセスを左右します。当社はまさにこの隙間を、啓発ではなくアーキテクチャで塞ぎます。","ご連絡を\u003Cbr />お待ちしています。",[1336,1340],{"text":492,"href":1337,"details":1338,"icon":1339},"tel:+49 69 4005520","今すぐ電話する","site/phone",{"text":1341,"href":1342,"icon":1343},"sales@glueckkanja.com","mailto:sales@glueckkanja.com","site/mail",{"ctaText":845,"cta":1345,"method":807,"action":848,"fields":1346},{"skin":847},[1347,1348,1350,1352,1354,1356,1359,1360,1362,1364,1365,1366],{"type":851,"id":852,"value":853},{"label":855,"type":856,"id":857,"required":325,"requiredMsg":1349},"お名前を入力してください。",{"label":860,"type":856,"id":403,"required":325,"requiredMsg":1351},"会社名を入力してください。",{"label":863,"type":864,"id":864,"required":325,"requiredMsg":1353},"メールアドレスを入力してください。",{"label":867,"type":868,"id":869,"required":484,"requiredMsg":1355},"メッセージを入力してください。",{"label":1357,"type":873,"id":874,"required":325,"requiredMsg":1358},"ご入力いただいた情報は、お問い合わせの対応と回答のために当社で保存されます。データ保護に関する詳細は\u003Ca href=\"/ja/privacy\">プライバシーポリシー\u003C/a>をご覧ください。","同意を確認してください",{"type":851,"id":877,"value":235},{"type":851,"id":879,"value":1361},"AT",{"type":851,"id":882,"value":1363},"Form: Blog Red Tenant Dark Tenant CIO | JA",{"type":851,"id":885,"value":886},{"type":851,"id":888},{"type":851,"id":890},{"form":325},"/posts/2026-09-21-red-tenant-dark-tenant-cio",{"title":1192,"description":530},"posts/2026-09-21-red-tenant-dark-tenant-cio",[235,896,897,1372],"NIS2","lpbOk3lCjLGcHF6A302G0oWn4WuGOO7_NClNVSJoxjc",[],{"id":1376,"extension":1377,"meta":1378,"stem":8,"__hash__":1391},"authors_data/authors.json","json",{"Jan Geisbauer":1379},{"display_name":521,"avatar":1380,"permalink":1381,"twitter":1382,"linkedin":1382,"imageOffsetTop":1383,"socials":1384},"people/people-jan-geisbauer-csoc.png","/authors/jan-geisbauer","JanGeisbauer","72%",[1385,1388],{"text":1386,"href":1387},"Blog","https://emptydc.com",{"text":1389,"href":1390},"Podcast","https://hairlessinthecloud.com","1csawlkJxRljy93GTOnXEkwLqAv9Lcj-apxRvoodAOY",1791383970951]