相次ぐ情報漏えいとAI攻撃の高速化
光・ネットワーク エージェント・データ基盤 AIモデル・知能 AIインフラ・産業
この資料の日時
元資料の日付と、その本文が公に存在した確認日時は別の記録です。
本文に含まれる語句 AIエージェント
出典・更新履歴・検証情報
この保存版のデータを照合するための情報です。元記事の初公開日とは区別しています。
- データセットの版
- 2026.10.17.1
- 記事内容のSHA-256
32d877b109fc13e90f668e1b3ef3d43ac4393a2ad0cbfe64f7a06de50dfe056d- 保存版のSHA-256
bc0329a78b4a5a0433e71a2e12f2884f15f26f6f8986cfee357290bfaac34129
外部証明の最終検査結果は詳細を開くと表示します。
相次ぐ情報漏えいとAI攻撃の高速化
#Cybersecurityは「Identity / Action / Traffic / Observability」からどこへ進むのか
#相次ぐ情報漏えいが設計に与える圧力
#2026年秋、大規模な情報漏えいが相次いでいる。
#10月5日、物語コーポレーションは「焼肉きんぐ」公式アプリの会員管理システムへの不正アクセスを公表した。登録10,808,784件のうち、10,788,963件について、会員番号、氏名、メールアドレス、電話番号が漏えいした。ほぼ全登録者に相当する規模である。パスワードやクレジットカード情報は対象外だったが、氏名と連絡先が結びついた巨大な顧客データベースが一度に取得されたことになる。
#同じ10月5日には、デンマークの中央個人登録簿CPRでも約880万人分の氏名、住所、CPR番号などへの不正アクセスが発表された。
#この事件が特徴的なのは、単純に外部からシステムを破壊したのではなく、ある企業に正規に与えられていた検索権限が悪用されたことだ。
#9月にはタイムズカーで約660万アカウントの情報が第三者に取得され、さらに約160万アカウントでは運転免許証画像、住所確認書類、学生証などの本人確認資料まで漏えいしたことが確認されている。
#一方、デジタル庁のGovernment Solution Service、GSSではVPN機器の脆弱性から侵入され、保守運用担当者のアカウントを使って大量のファイルへアクセスされていた。漏えいした可能性がある個人情報は約24.6万件に上る。
#これらは原因も攻撃者も同じではない。
#脆弱性が利用された事件もあれば、正規アクセス権が悪用された事件もあり、大量の個人情報を一つのデータベースへ蓄積していたこと自体が被害規模を拡大した事件もある。
#しかし、別々に見える事件を並べると、一つの共通した問題が浮かび上がる。
#現在の企業ITは、一度正しいIdentityを取得し、内部へ入り、適切な権限まで手に入れれば、非常に大きなDataへ到達できる構造になっている。
#そしてAIによって攻撃速度まで上昇すれば、この構造そのものを変えなければ防御が追いつかなくなる可能性がある。
#今回の記事ではCybersecurityを、
#Identity / Action / Traffic / Observability
#という4つの基本軸から考え、その4軸がどのように変化し、その先に、
#Data / Compute / Policy
#という新しい層がなぜ重要になっていくのかを見ていく。
#
1．まずCyberattackはどのように進むのか
#Cybersecurityを理解するには、最初に攻撃側が何をしようとしているのかを見ると分かりやすい。
#非常に単純化すると、多くの攻撃は次のように進む。
#外部を調査
#Reconnaissance
#↓
#最初の侵入口を作る
#Initial Access
#↓
#ID・Password・Tokenなどを取得
#Credential / Identity Theft
#↓
#より強い権限を得る
#Privilege Escalation
#↓
#他のServer・Cloud・SaaSへ移動
#Lateral Movement
#↓
#価値のあるDataを探す
#Discovery
#↓
#大量に読む
#Collection
#↓
#外へ持ち出す
#Exfiltration
#↓
#売却・恐喝・なりすまし・破壊
#Impact
#Reconnaissanceは「偵察」。
#Initial Accessは「最初の侵入口」。
#CredentialはPassword、Session Token、API Keyなど、本人としてシステムを利用するための認証情報。
#Privilege Escalationは一般ユーザーから管理者へ上がるような「権限昇格」。
#Lateral Movementは一台のPCから別のServer、Cloud、Databaseへ横に侵入範囲を広げていく行為。
#Exfiltrationは最終的にDataを外へ持ち出すことである。
#従来のCybersecurityは、この各段階に別々の製品を置いてきた。
#FirewallがNetworkを守り、EDRがPCを監視し、IAMがLoginを管理し、DLPがData持ち出しを監視し、SIEMが大量のLogを集める。
#ところが、この分業型SecurityにAI時代の攻撃速度が圧力をかけ始めている。
#
2．2026年に目立ち始めた「攻撃までの時間の圧縮」
#Google Threat Intelligence Group、GTIGによると、2026年1月には月5,045件だった脆弱性公開数が、8月には10,740件へ増加した。
#同時に、実際の攻撃で悪用された脆弱性も、2025年平均の月10.5件から、2026年1～8月には月平均18件まで増えた。
#1～8月だけで141種類の脆弱性が実際の攻撃に利用されており、2025年通年の127種類をすでに上回っている。
#Zero-day――修正手段が十分存在しない段階で悪用される脆弱性――も、2025年平均月8件から2026年には平均11件へ増え、8月には22件まで跳ねた。
#しかしGTIGがより重要な変化として挙げているのが、N-dayの高速武器化だ。
#N-dayとは、すでに公表されたり、修正Patchが提供されたりしている脆弱性である。
#AIを利用すれば、
#旧Versionと新Versionの差を調べる。
#Patchでどこが変更されたか読む。
#公開された脆弱性説明を分析する。
#PoC、つまり攻撃可能性を示す試験Codeを探す。
#それらを組み合わせて攻撃Codeを作る。
#という一連の作業を高速化できる。
#GTIGは、2026年の脆弱性悪用増加について、Zero-dayの爆発的増加というより、High-RiskなN-dayの迅速な武器化が重要な要因になっている可能性を指摘している。High-Risk脆弱性の悪用数は2025年の28件から、2026年1～8月だけで75件に増えた。
#さらにGTIGは2026年第2四半期、攻撃者がCloud環境を侵害した後、AI Agentを利用した大規模なCredential収集キャンペーンを計画・構築・実行するまでを6時間未満で行った事例も観測している。
#つまり問題は単に、
#攻撃が増えた
#だけではない。
#より重要なのは、
#攻撃の各工程にかかる時間が圧縮され始めている
#ことである。
#
3．この攻撃を理解するための4軸
#ここからCybersecurityを4つの軸に分けて考えてみる。
#である。
#
4．Identity――「誰なのか」
#Identityは本人性である。
#人間だけではない。
#社員。
#顧客。
#Server。
#Application。
#Service Account。
#API。
#Device。
#そして今後はAI Agent。
#すべてにIdentityがある。
#従来のSecurityでは、
#ID
#-
#Password
#-
#MFA
#↓
#本人確認成功
#↓
#Login
#が大きな境界だった。
#つまり「中へ入れる人かどうか」をIdentityによって判断した。
#しかしデンマークCPR事件のように、正規の権限そのものが悪用されるなら、Login成功だけでは安全性を保証できない。
#Identityの役割は、
#Who are you?――あなたは誰か
#から、
#Are you still trustworthy right now?――今この瞬間も、この操作を許してよいIdentityなのか
#へ変わっていく。
#
5．Action――「何をしてよいのか」
#Identityの次に来るのがActionである。
#例えば同じ社員でも、
#顧客を見る。
#住所を書き換える。
#100万円を送金する。
#Databaseを全部Exportする。
#では危険度がまったく違う。
#従来はRole Based Access Control、RBACと呼ばれる、
#「営業担当ならこの範囲」
#「管理者なら全部」
#という比較的大きな権限単位が多かった。
#しかし巨大漏えいが続けば、より細かく、
#Employee A
#Customer 8172
#READ only
#Field
#name / email
#Duration
#5 minutes
#のように制限する必要が出てくる。
#ここで重要になるのがLeast PrivilegeとJIT Accessだ。
#Least Privilegeは「最小権限」。
#仕事に必要な最低限の権限しか与えない。
#JIT、Just-in-Time Accessは、
#必要になった瞬間だけ短時間の権限を発行する
#仕組みである。
#NISTのZero Trust実装ガイダンスでも、必要な権限を必要な時点だけ与え、その後削除するJust-enough / Just-in-time Accessや、アクセス中も継続して再評価するContinuous Access Evaluationが扱われている。
#これは、
#ADMIN権限を365日持つ
#世界から、
#今から10分間
#このDatabaseだけ
#READだけ許可
#する世界への変化である。
#
6．Traffic――「誰と誰がつながっているのか」
#Trafficとは通信である。
#従来のNetwork Securityでは、
#Internetと社内Networkの境界へFirewallを置き、
#外は危険、中は比較的安全
#と考えていた。
#しかしCloud、Remote Work、SaaS、AI Agentが増えると、この境界が曖昧になる。
#そこでZero Trustでは、
#「社内Networkだから信用する」
#という前提そのものを外す。
#NISTもZero Trustを、物理的・Network上の場所だけでは暗黙のTrustを与えず、User、Device、ServiceなどのIdentityを基にResourceへのAccessを判断するArchitectureとしている。
#つまりTrafficは、
#Packet A
#↓
#Packet B
#を見るだけではなく、
#Identity A
#↓
#Resource B
#というRelationship――関係として見るようになる。
#そして通信内容自体を守るのがE2EEである。
#E2EEはEnd-to-End Encryption。
#端末から許可された相手まで暗号化し、途中のServerや通信経路から内容を読みにくくする仕組みだ。
#将来的には、
#Contentは暗号化して見せない。
#一方、
#誰が、いつ、どこへ、どれくらい通信しているかというMetadataはSecurity監視へ使う。
#という分離が重要になってくる。
#
7．Observability――「実際に何が起きたのか」
#Observabilityは直訳すれば「観測可能性」。
#System内部で何が起きているかを、Log、Metric、Traceなどから理解できる能力である。
#Securityでは例えば、
#Loginした。
#APIを呼んだ。
#Databaseを100件読んだ。
#500MB送信した。
#新しいProcessを起動した。
#普段とは違う国から接続した。
#といった事象を観測する。
#従来は、
#Event
#↓
#Log
#↓
#Alert
#↓
#Human
#↓
#Investigation
#だった。
#しかし毎日何億件ものLogが発生すれば、人間が全部読むことはできない。
#AI Securityでは、
#Identity
#Employee A
#Action
#Customer DB READ
#Traffic
#Server → External Cloud
#Observability
#通常10件/min
#突然500,000件/min
#を一つの行動として読む。
#単独では正規操作に見えても、
#組み合わせとして異常
#と判断できる。
#Google/Mandiantも2026年の防御Architectureについて、明確に識別されたAdaptive Identity ControlとReal-time Behavioral Telemetryへの移行を挙げている。Behavioral Telemetryとは、人間やMachineが「実際にどう行動したか」をリアルタイムに収集する情報である。
#
8．4軸だけでは不足し始める――最初に追加される「Data」
#ここまでなら、
#でかなり多くのCybersecurityを説明できる。
#しかし焼肉きんぐやタイムズカーのような大規模漏えいを見ると、別の問題がある。
#なぜ一つの侵入で1000万人分近いDataへ到達できるのか。
#である。
#ここから独立した第5の軸として、
#を考える必要が出てくる。
#現在のWebでは、利用者が100社のServiceへ登録すれば、
#氏名。
#住所。
#電話番号。
#生年月日。
#本人確認書類。
#などが100社へ複製される。
#DataをコピーすればするほどAttack Surfaceも増える。
#そのためSecurityが、
#Databaseを守る
#だけでなく、
#企業が持つData自体を減らす
#方向へ進む可能性がある。
#
9．Personal Data Vault――Dataの原本を企業ごとにコピーしない
#その一つの考え方がPersonal Data Vaultである。
#これは特定の一製品名ではなく、
#個人Data、Credential、暗号鍵、Access Policyなどを本人中心に管理するArchitecture
#と考えると分かりやすい。
#現在：
#あなた
#│
#├→ EC Database
#│ 氏名
#│ 住所
#│ 生年月日
#│
#├→ Bank Database
#│ 氏名
#│ 住所
#│ 生年月日
#│
#└→ Service Database
#氏名
#住所
#生年月日
#Vault型：
#Personal Vault
#氏名 / 住所 / Credential
#│
#必要なものだけ
#│
#┌──────────┼──────────┐
#↓ ↓ ↓
#EC Bank Service
#企業へDataの原本を大量複製する代わりに、必要な情報だけ渡す。
#この発想を現実化する部品の一つがVerifiable Credentials、VCである。
#VCは運転免許証や学歴などを、暗号技術によって「本当に発行元が発行したもの」と機械的に検証できるDigital Credentialにする仕組みだ。
#W3Cは2025年5月、Verifiable Credentials 2.0を正式なWeb Standardとして公開しており、Credentialの一部分だけを提示するSelective Disclosureにも対応するArchitectureを定義している。
#
10．Selective Disclosure――必要な項目だけ見せる
#Selective Disclosureは「選択的開示」。
#例えば現在、年齢確認のために免許証を見せれば、
#氏名。
#住所。
#生年月日。
#顔写真。
#免許証番号。
#まで見える。
#しかし欲しい情報が、
#20歳以上か
#だけなら、それ以外は本来不要である。
#そこで、
#Credential
#氏名 Hidden
#住所 Hidden
#生年月日 Hidden
#成人確認 TRUE
#のように必要なAttribute、つまり属性だけを提示する。
#これだけでも、企業側が保存する個人情報をかなり減らせる。
#
11．ZKP――Dataそのものではなく「事実」を渡す
#さらに進んだ考え方が、
#Zero-Knowledge Proof、ZKP――ゼロ知識証明
#である。
#ZKPは簡単に言えば、
#秘密そのものを明かさず、その秘密についての条件が正しいことだけ証明する
#暗号技術だ。
#NISTもZKPをPrivacy-Enhancing Cryptographyの主要技術として扱っている。
#例えばVaultに、
#Date of Birth
#2001-05-14
#が保存されている。
#Service側が知りたいのは、
#age >= 20 ?
#だけ。
#ZKPなら、
#Proof
#age >= 20
#TRUE
#を送る。
#企業は本人の正確な生年月日を受け取らなくても、年齢条件を満たしていることを確認できる。
#ここまで進めば、
#Data Sharing
#から、
#Proof Sharing
#への変化になる。
#
12．次に追加される「Compute」
#しかしDataを暗号化するだけでは問題が残る。
#Dataには、
#保存中。
#通信中。
#計算中。
#という3つの状態がある。
#保存中ならStorage Encryption。
#通信中ならTLSやE2EE。
#問題になるのが、
#Data in Use――計算中のData
#である。
#普通はAIでDataを解析する場合、
#Encrypted Storage
#↓
#復号
#↓
#RAM
#↓
#CPU / GPU
#となる。
#計算する以上、どこかで処理可能な状態へ戻す必要がある。
#そこで登場するのがConfidential Computingである。
#
13．Confidential Computing――計算中まで保護する
#Confidential Computingは、
#Hardwareによって隔離されたTrusted Execution Environment、TEEの中で計算し、Data in Useを保護する
#考え方である。
#Confidential Computing Consortiumも、Hardware-basedかつAttestedなTEE内で計算することによってData in Useを守る技術と定義している。
#構造としては、
#Cloud
#Host OS
#Hypervisor
#Cloud Administrator
#│
#│ 読めない
#▼
#┌──────────────────┐
#│ TEE │
#│ │
#│ Sensitive Data │
#│ AI Model │
#│ Application │
#└──────────────────┘
#となる。
#つまり、
#Cloud事業者そのものを全面的に信用する
#のではなく、
#Hardwareで隔離された実行環境をTrust Boundaryにする
#発想だ。
#
14．Attestation――「本当に安全なComputeか」を証明する
#TEEだけでは、
#「本当に正しいTEEなのか」
#「改ざんされたSoftwareが動いていないか」
#が分からない。
#そこで必要になるのがAttestationである。
#Attestationは簡単に言えば、
#このHardware、このFirmware、このSoftwareが、期待した状態で動いていることを暗号学的に証明する仕組み
#である。
#例えばPersonal Vaultなら、
#TEE
#↓
#Attestation Proof
#↓
#Vault verifies
#Hardware OK
#Firmware OK
#Application OK
#↓
#必要なKeyだけ渡す
#という構造にできる。
#Google CloudもAttestationを、Confidential Computing環境が信頼できるHardware-based TEE内で動作していることを遠隔確認する仕組みとして提供している。
#こうなるとIdentityは人間だけではなくなる。
#Human Identity
#Device Identity
#AI Agent Identity
#Workload Identity
#Compute Identity
#まで広がる。
#「誰が計算するのか」に加えて、「どのComputeが計算するのか」までIdentity化するのである。
#そのため第6の軸として、
#が浮かび上がる。
#
15．IdentityはLoginからContinuous Identityへ変わる
#ここまで来ると、Identityの意味もかなり変わる。
#従来：
#Password
#↓
#MFA
#↓
#Login successful
#↓
#Trust
#次世代：
#Human Identity
#Device Identity
#Agent Identity
#Compute Identity
#Credential
#Behavior
#Risk
#↓
#継続評価
#になる。
#つまりIdentityはStaticなIDではなく、
#時間によってTrustが変化するDynamic Identity
#になる。
#午前10時には正常だった社員アカウントでも、
#午前10時5分に突然100万件の顧客情報を読み始めればTrustを下げる。
#これがContinuous IdentityやContinuous Access Evaluationへつながっていく。
#
16．Actionは「権限」からJITへ変わる
#Action側では常時権限が減っていく。
#現在：
#Administrator
#Database Admin
#24 hours
#365 days
#これをStanding Privilege、常設権限と呼ぶ。
#攻撃者から見れば非常に魅力的だ。
#Credential一つを盗めば、その瞬間からAdminだからである。
#JIT Accessでは、
#通常
#Privilege = NONE
#↓
#Task発生
#↓
#Identity
#Device
#Purpose
#Risk
#を評価
#↓
#READ
#Database A
#TTL = 10 min
#とする。
#TTLはTime To Live。
#「この権限はあと何秒有効か」という寿命である。
#10分経過すればCredentialそのものが無効になる。
#
17．TrafficはNetworkからRelationshipへ変わる
#Trafficについても、
#IP address
#Port
#Packet
#を見るだけでは不十分になる。
#重要なのは、
#Human A
#↓
#AI Agent B
#↓
#API C
#↓
#Application D
#↓
#Database E
#というRelationship Graphである。
#つまり、
#誰と誰がつながることを許可されているのか
#を見る。
#これによってZero Trustは、
#危険な通信を見つける
#だけではなく、
#そもそも不要な通信関係を存在させない
#Architectureへ近づく。
#
18．Observabilityは「Log保存」からBehavioral Telemetryへ
#Observabilityも変わる。
#以前は、
#何か起きる
#↓
#Logを書く
#↓
#後で人間が見る
#だった。
#これからは、
#Identity
#Action
#Traffic
#Compute
#Data Access
#をリアルタイムで一つのEvent Graphとして見る。
#例えば、
#03:21
#新しいDeviceからLogin
#03:22
#普段使わないAPI
#03:23
#Database schema探索
#03:24
#10万records取得
#03:25
#External Storageへ通信
#一つ一つなら必ずしも攻撃とは言えない。
#しかし一連の流れなら非常に不自然である。
#AIはこうしたSequence――行動の連続性を見るのに向いている。
#
19．ここで4軸を閉じるのがContinuous Authorization
#ここが重要なControl Pointになる。
#Continuous Authorizationとは、
#一度Loginしたら1時間信用するのではなく、
#Actionを実行している最中も継続的に「まだ許してよいか」を計算する
#仕組みである。
#Identity
#-
#Action
#-
#Traffic
#-
#Data
#-
#Compute
#-
#Observability
#↓
#Risk evaluation
#↓
#ALLOW / DENY
#例えば、
#10:00
#正常
#ALLOW
#10:03
#通常範囲
#ALLOW
#10:05
#大量Data取得開始
#Risk ↑
#10:05:01
#DENY
#となる。
#NISTのZero Trust実装でも、Access Sessionの間に主体とAccessを継続評価するContinuous Access Evaluationが扱われている。
#
20．そして最終的に追加されるのが「Policy」
#ここまで来ると、
#だけでも、
#だけでも、
#だけでもSecurityを決められない。
#必要なのは、
#このIdentityが
#このDeviceから
#このActionを
#このDataに
#このCompute上で
#このNetwork経路を使って
#今行ってよいか？
#という判断である。
#これを決めるのが、
#だ。
#Policyは「ルール」だが、単純な固定ルールだけではない。
#Identity Risk
#Data Sensitivity
#Device Health
#Location
#Behavior
#Time
#Purpose
#Threat Intelligence
#などからDynamicに判断するPolicy Engineへ変わる。
#
21．AI SecurityはPolicyをMachine Speedで回す
#攻撃側がAIを使って数時間、あるいはより短い時間で攻撃工程を進めるなら、防御側が、
#Alertを見る。
#担当者へ連絡。
#会議する。
#調査する。
#責任者の承認を取る。
#Credentialを停止する。
#では間に合わなくなる。
#そのためAI Securityの重要な役割は、
#Observe
#↓
#Reason
#↓
#Decide
#↓
#Act
#↓
#Evaluate
#↓
#Update
#という閉LoopをMachine Speedで回すことになる。
#例えば異常を検出したら、
#Sessionを切る。
#Credentialを失効させる。
#JIT権限を取り消す。
#Deviceを隔離する。
#Network経路をBlockする。
#Encryption KeyをRotationする。
#といった初動を数秒で行う。
#人間はその上位でPolicy設定、例外処理、重大判断などを担当する。
#
22．4軸は最終的に6軸へ広がる
#ここまでをまとめると、現在のSecurityを理解するのに非常に便利な、
#という4軸は、AI時代には次のように拡張した方が分かりやすくなる。
#である。
#そして、その全体を、
#が制御する。
#構造にするとこうなる。
#POLICY + AI
#│
#▼
#Continuous Authorization
#│
#┌──────────┬──────────┬──────────┐
#│ │ │ │
#Data Identity Action Traffic
#│ │ │ │
#│ │ │ │
#Vault VC/ZKP JIT E2EE
#Token Passkey Least Zero Trust
#Agent ID Privilege
#│ │ │ │
#└──────────┴─────┬────┴──────────┘
#│
#Compute
#│
#Confidential Computing
#Attestation
#│
#▼
#Observability
#│
#Behavioral Telemetry
#│
#▼
#AI Security
#│
#Detect / Reason
#│
#Revoke / Block / Isolate
#│
#└──────────────↺
#
23．Personal Vaultはこの構造のどこに入るのか
#Personal Vaultは単独でSecurityを解決する技術ではない。
#むしろ複数技術の起点になる。
#理想形は、
#Personal Vault
#↓
#E2EE
#↓
#Attested Confidential Compute
#↓
#ZKP / Selective Disclosure
#↓
#JIT Access
#↓
#Continuous Authorization
#↓
#AI Security Monitoring
#となる。
#それぞれ役割が違う。
#Personal Vault
#Dataの原本やCredential、Key、Policyを本人中心に管理する。
#E2EE
#途中のNetworkやServerから通信内容を読みにくくする。
#Attested Confidential Compute
#Cloudで計算する必要がある場合も、検証された隔離環境だけにDataを見せる。
#ZKP / Selective Disclosure
#Dataの原本ではなく、必要な属性・事実だけをServiceへ渡す。
#JIT Access
#必要な瞬間だけ短命な権限を発行する。
#Continuous Authorization
#その権限を実行中も継続評価する。
#AI Security Monitoring
#全体のBehaviorを観測し、異常時には権限を止める。
#つまり防御は一枚の壁ではなく、
#DataそのものからActionの実行までを細かく分解した多層制御
#になる。
#
24．攻撃側から見ると、狙う「王冠」も変わる
#この構造が普及すると、攻撃者の標的も変わる。
#現在は、
#Customer Database
#=
#Crown Jewels
#であることが多い。
#Databaseを取れば100万人、1000万人分のDataが取れる。
#しかしPersonal Vault、Tokenization、ZKPなどが普及し、
#企業側が原本Dataを大量に持たなくなれば、
#Database自体の価値は低下する。
#代わりに価値が上がるのが、
#Private Key
#Identity Root
#Policy Engine
#Authorization Engine
#Attestation Root
#AI Agent Credential
#である。
#つまり攻撃者は、
#Dataを直接盗む
#より、
#「正規アクセスを生成する仕組み」を乗っ取る
#方向へ向かう可能性がある。
#これはSecurityに新しい圧力を生む。
#
25．だから暗号化だけでは足りない
#ここで、
#「全部E2EEならよい」
#とはならない。
#E2EEでも、正規のEndpointが乗っ取られればDataは読まれる。
#Confidential Computingでも、TEE内部へ悪意あるApplicationを入れれば危険になる。
#ZKPでも、WalletやPrivate Keyを奪われれば本人になりすまされる可能性がある。
#JITでも、Policy Engineそのものが破壊されれば不正な権限を発行できる。
#つまり将来のCybersecurityは、
#Dataを暗号化する技術
#だけではなく、
#Trustを生成するChain全体
#を守る必要がある。
#Identity
#↓
#Policy
#↓
#Authorization
#↓
#Credential / Key
#↓
#Compute
#↓
#Data
#である。
#
26．AI時代の攻撃と防御を一枚で見る
#全体を攻撃側と防御側の競争として表現すると、こうなる。
#ATTACKER
#│
#Recon / AI Search / Exploit
#│
#▼
#────────────────────────────────────────
#IDENTITY
#Human / Device / Agent / Workload
#攻撃:
#Credential Theft
#Session Hijack
#Agent Identity Abuse
#防御:
#Passkey / MFA
#VC / ZKP
#Continuous Identity
#────────────────────────────────────────
#ACTION
#攻撃:
#Privilege Escalation
#Unauthorized Tool Use
#Malicious API Calls
#防御:
#Least Privilege
#JIT Access
#Continuous Authorization
#────────────────────────────────────────
#TRAFFIC
#攻撃:
#Lateral Movement
#C2 Communication
#Data Exfiltration
#防御:
#Zero Trust
#E2EE
#Microsegmentation
#Egress Control
#────────────────────────────────────────
#COMPUTE
#攻撃:
#Host / Hypervisor compromise
#Malicious workload
#Runtime attack
#防御:
#Confidential Computing
#TEE
#Attestation
#────────────────────────────────────────
#DATA
#攻撃:
#Database theft
#Identity-document theft
#Bulk collection
#防御:
#Data Minimization
#Personal Vault
#Tokenization
#Selective Disclosure
#ZKP
#────────────────────────────────────────
#OBSERVABILITY
#攻撃:
#Log deletion
#Slow exfiltration
#Behavior imitation
#防御:
#Immutable Telemetry
#Behavior Analytics
#Cross-domain correlation
#AI Detection
#────────────────────────────────────────
#↓
#AI SECURITY
#Observe → Reason → Decide
#↓
#Block / Revoke / Isolate
#↓
#Policy Update
#↺
#こうして見ると、AI Securityとは単なる「AI製Antivirus」ではないことが分かる。
#Identity、Action、Traffic、Compute、Data、Observabilityを統合して、すべてのRelationshipを継続的に判断するControl Plane
#に近い。
#
27．今後、需要が強まりそうなSecurity領域
#ここから市場側を見ると、需要の中心も変わってくる可能性がある。
#短期的にまず強い圧力がかかるのは、
#Exposure Management
#である。
#公開された数万件の脆弱性を全部同じ優先度でPatchするのではなく、
#「本当に攻撃されているか」
#「Internetから見えるか」
#「その先に重要Dataがあるか」
#までAIで判断し、優先順位を決める。
#GTIGも、無差別なMass PatchingからThreat Intelligenceを使ったTriageとAgentic Remediationへの移行を求めている。
#次が、
#Identity Security / JIT / Continuous Authorization
#である。
#正規Credentialの悪用を前提とすれば、「Loginできたから安全」という思想は成立しない。
#続いて、
#AI SOC / Autonomous Response
#が伸びる。
#攻撃時間がMachine Speedへ近づけば、防御側もMachine Speedにする必要がある。
#さらに長期では、
#Data Security / Privacy Enhancing Technology
#が重要になる。
#Vault。
#Tokenization。
#Selective Disclosure。
#ZKP。
#MPC。
#FHE。
#Confidential Computing。
#こうした技術によって、
#そもそも企業側に盗めるDataを置き過ぎない
#方向へ進む。
#
28．Cybersecurityの目的そのものが変わる
#従来Cybersecurityの中心的な問いは、
#「どうやって攻撃者を中へ入れないか」#
だった。
#Firewallを厚くする。
#Patchを当てる。
#Passwordを強くする。
#EDRを入れる。
#もちろんこれらは今後も重要である。
#しかしAI時代には、それだけでは足りなくなる。
#次の問いは、
#このIdentityが、このActionを、このDataに対して、このCompute上で、このTraffic経路を使って、今この瞬間に実行してよいのか#
になる。
#つまりCybersecurityは、
#から、
#へ進む。
#
29．「侵入されない会社」から「侵入されても大量には盗めない会社」へ
#さらに重要なのは、防御側が完全勝利を前提としなくなることである。
#Zero-dayは存在する。
#Credentialも盗まれる。
#人間も間違える。
#AI Agentも誤作動する。
#Supply Chainも侵害される。
#それなら、
#いつか何かは突破される
#ことを前提にArchitectureを設計する。
#一つのCredentialが漏れても5分しか使えない。
#一つのAccountでは100件しか読めない。
#一つのServiceには住所の原本が保存されていない。
#Cloud管理者を侵害してもTEE内部を直接読めない。
#年齢確認Serviceには生年月日そのものを渡していない。
#異常行動が始まればContinuous Authorizationが権限を取り消す。
#AIがその一連をMachine Speedで観測する。
#この思想は、
#Prevention中心
#から、
#Blast Radius Minimization――侵害後の被害半径を最小化する
#方向への変化でもある。
#
30．結論――Securityは企業ITの「制御OS」へ近づく
#焼肉きんぐで約1079万件。
#デンマークCPRで約880万人。
#タイムズカーで約660万アカウント。
#GSSで約24.6万件。
#それぞれ原因は異なる。
#そして現時点で、これらすべてを「AI攻撃による事件」と結びつける根拠はない。
#一方で別の事実として、2026年には脆弱性公開・実悪用が増加し、N-dayの高速武器化が観測され、攻撃側でもAgentic AIによる自動化が現実のものになり始めている。
#この二つが同時に進むことで、防御側に強烈な圧力がかかる。
#その結果、
#という現在の主要なSecurity軸は、
#へ拡張され、
#その全体を、
#が継続的に制御するArchitectureへ向かう可能性がある。
#IdentityはLoginからContinuous Identityへ。
#ActionはStanding PrivilegeからJITへ。
#TrafficはNetwork境界からRelationship Controlへ。
#ObservabilityはLog保存からReal-time Behavioral Telemetryへ。
#Dataは巨大DatabaseからVault、Token、Proofへ。
#Computeは通常CloudからAttested Confidential Computeへ。
#そしてそれらをContinuous AuthorizationとAI Securityが一つのLoopへ閉じる。
#これは単にCybersecurity製品が増えるという話ではない。
#Securityそのものが、企業内部の人間、AI Agent、Application、Data、Computeの間で起こるすべてのActionをリアルタイムに制御する「企業ITのControl OS」に近づく
#という構造変化である。
#相次ぐ巨大情報漏えいが突きつけているのは、「もっと高いFirewallが必要」という問題だけではない。
#1000万人分のDataを一つの場所に集め、一つのCredential、一つのApplication、一つの委託先から到達可能にするArchitectureを、このまま続けてよいのか。
#という、より根本的な問題である。
#そしてAIによって攻撃時間が圧縮されるほど、その答えを出すまでの時間もまた、短くなっていく。
#