お盆休みに飛び込んできたCVSS 10.0
大型連休は、システム管理者にとって少し嫌な時期だ。
社内の人間は少ない。取引先も休んでいる。何か問題が起きても担当者や意思決定者を捕まえにくい。
攻撃者にとって大型連休だから脆弱性が増えるわけではない。しかし、異常の発見や初動対応が遅れやすい時期であることは間違いない。
そんな日本のお盆休みを狙ったかのようなタイミングで、Microsoftから穏やかではない数字が並んだ。
CVSS 10.0が3件。さらにCVSS 9.9が4件。
CVSS（Common Vulnerability Scoring System）は、脆弱性の深刻度を0.0から10.0までの数値で表す指標だ。
10.0はもちろん最高値である。
今回Microsoftが公開した脆弱性には、Azure SQL DatabaseやMicrosoft Teamsなど、企業でも広く利用されているクラウドサービスが含まれている。
Microsoft Security Response Center（MSRC）でも、それぞれの脆弱性情報が公開されている。たとえばMicrosoft Teamsに存在したCVE-2026-65667、Azure SRE AgentのCVE-2026-62830についても、MicrosoftのSecurity Update Guideで確認できる。
「CVSS 10.0が3件」と聞けば、Windows管理者なら身構えるだろう。
すぐにWindows Updateを確認すべきなのか。
緊急パッチを全端末へ展開する必要があるのか。
休暇中の担当者を呼び戻す必要があるのか。
ところが、今回の話は少し違う。
これは基本的に、利用者がWindows Updateを実行して解決する脆弱性ではない。
問題になったのは、Microsoftが運用するクラウドサービスだ。
つまり、脆弱性を抱えているシステムを管理しているのもMicrosoftなら、それを修正できるのもMicrosoftである。
利用者はパッチをダウンロードすることもできない。
修正を早めることもできない。
自社でソースコードを確認することもできない。
Microsoftが問題を発見し、Microsoftが修正し、Microsoftが「修正した」と公表する。
利用者にできることは極めて限られている。
これは一見すると楽な話でもある。
大型連休中にCVSS 10.0が出ようとも、全国のシステム管理者が慌ててPCを起動する必要はない。
Microsoftが直してくれる。
クラウドサービスとは、そういうものだ。
しかし、見方を変えれば少し怖い。
クラウドは「パッチを管理する面倒」から利用者を解放した。同時に、「自分でパッチを当てる権利」からも利用者を解放してしまった。
CVSS 10.0という派手な数字よりも、今回考えてみたいのはこちらである。
私たちはクラウドに何を預け、代わりに何を手放したのだろうか。
CVSS 10.0とはどれほど危険なのか
そもそも、CVSS 10.0とはどれほど危険なのだろうか。
CVSSは単純に「危険だから10点」と決めているわけではない。
攻撃をどこから実行できるのか。攻撃は難しいのか。事前に権限が必要なのか。利用者の操作が必要なのか。そして攻撃に成功した場合、機密性・完全性・可用性にどれほど影響するのか。
こうした複数の条件を組み合わせてスコアが算出される。
今回10.0と評価された脆弱性には、次の3件が含まれている。
- CVE-2026-63508：Planetary Computer Pro
- CVE-2026-56162：Azure SQL Database
- CVE-2026-65667：Microsoft Teams
Microsoft Security Response Centerでは、Microsoft TeamsのCVE-2026-65667を「Missing Authorization」、つまり必要な認可処理が欠けていたことによる権限昇格の脆弱性として公開している。
問題は、10.0という数字そのものより攻撃条件だ。
CVSSで使われる言葉を、少々乱暴に人間の言葉へ翻訳してみよう。
インターネットなどのネットワーク越しから攻撃できる。
高度な攻撃条件を必要としない。
事前に特別な権限を持っている必要がない。
利用者にリンクをクリックさせるような操作も必要ない。
こうした条件が並ぶ。
よくある脆弱性では「攻撃対象へログイン済みであること」「利用者に細工したファイルを開かせること」「特殊なシステム構成になっていること」など、攻撃を成立させるための条件が付くことがある。
その条件が少ないほど、攻撃者にとって使いやすい脆弱性になる。
今回の10.0組が不気味なのはここだ。
たとえばフィッシングなら、最後には人間を騙してリンクを踏ませなければならない。
パスワード攻撃なら、何らかの方法で認証を突破しなければならない。
しかし「認証不要」「利用者操作不要」「ネットワーク越し」という条件が揃えば、その最後の壁すら必要なくなる。
もちろん、CVSS 10.0だからといって、ただちに世界中から攻撃されているという意味ではない。
CVSSが評価しているのは脆弱性の深刻度であって、現在どれだけ攻撃されているかではない。
ここは非常に重要だ。
「10.0の脆弱性が存在する」と「10.0の脆弱性を使った攻撃が現在進行中である」は、まったく別の話である。
数字だけを見て「Microsoftクラウドがいま危険だ」と結論付けるのは早い。
一方で、今回の対象を見ると気になることもある。
Azure SQL Databaseはデータベース。
Microsoft Teamsは企業のコミュニケーション基盤。
さらに9.9まで範囲を広げれば、Azure Service Bus、Azure SRE Agent、Entra Provisioning Serviceなども並ぶ。
どれもMicrosoftクラウドの片隅にある小さなアプリケーションとは言い難い。
データ。
通信。
ID。
運用。
コラボレーション。
企業がクラウドへ預けてきた重要な機能のあちこちから、極めて高い深刻度を持つ脆弱性が同時期に公開された。
しかし、ここでもう一つ妙なことに気付く。
これほど深刻な脆弱性なら、利用企業のシステム管理者は何をすればいいのだろう。
Windowsならパッチを当てる。
サーバーならアップデートする。
ネットワーク機器ならファームウェアを更新する。
では、Azure SQL DatabaseやMicrosoft Teamsに存在する脆弱性を、利用者はどうやって修正すればいいのか。
答えは簡単だ。
利用者には修正できない。
ここからが、今回の話の本題である。
ところが、利用者にはパッチを当てられない
CVSS 10.0。
認証不要。利用者の操作も不要。ネットワーク越しに攻撃できる。
そんな説明を読めば、システム管理者なら次に考えることは決まっている。
「で、パッチはどこにある？」
しかし今回、その問いには少々奇妙な答えが返ってくる。
ない。
正確には、利用者が適用するパッチがない。
Microsoftは2024年、クラウドサービスで発見された重大な脆弱性について、顧客側でパッチ適用などの対応が必要ない場合でもCVEを公開する方針を明らかにした。
それ以前のクラウドサービスでは、問題が発見されてもMicrosoft側で修正が完了し、利用者に作業が必要なければ、必ずしもCVEとして公開されていなかった。
考えてみれば当然でもある。
Microsoft Teamsを使っている企業が、Teamsのサーバーへログインして修正プログラムをインストールすることなどできない。
Azure SQL Databaseの内部システムを、自社のシステム管理者がアップデートすることもできない。
サービスを運用しているのはMicrosoftだからだ。
そこでMicrosoftは、こうしたクラウドサービス固有の脆弱性を識別できるようにした。
CVE情報に付けられる「exclusively-hosted-service」というタグである。
Microsoftの説明は明快だ。
このタグは、顧客側で必要なアクションがないことを示す。
つまり今回のような重大なクラウドサービスの脆弱性を見つけても、システム管理者が慌てて社内PCへパッチを配布する必要はない。
Microsoftが直す。
利用者は何もしなくていい。
これはクラウドの巨大なメリットである。
オンプレミスなら、脆弱性情報を確認し、影響する製品を洗い出し、検証環境でアップデートを試し、本番環境へ展開する。
失敗すればサービスが止まるかもしれない。
古いシステムとの互換性問題が発生するかもしれない。
24時間稼働しているサーバーなら、いつ再起動するのかという調整まで必要になる。
大型連休の直前に緊急パッチなど公開された日には、システム管理者にとって悪夢である。
クラウドでは、その仕事をMicrosoftが引き受ける。
実際、MicrosoftがクラウドサービスのCVE公開を拡大した理由も興味深い。
これまでは「顧客が更新プログラムをインストールする必要がないなら、追加情報も必要ない」という考え方が一般的だったという。
それをMicrosoft自身が改めた。
利用者が何もしなくてよい脆弱性であっても、重大な問題なら公開する。
クラウドの内部で何が起き、何が修正されたのか。
利用者にも知らせるべきだという方向へ変わったのである。
これは評価していい。
今回CVSS 10.0という数字を私たちが知ることができるのも、その透明性向上の結果だからだ。
だから「利用者には直せない」という事実だけを取り上げて、クラウドは危険だと結論付けるのはフェアではない。
むしろ逆だろう。
何百、何千という企業のシステム管理者が個別にパッチを適用するより、サービスを最もよく知るMicrosoftが一括して修正した方が合理的である。
問題は、その次だ。
Microsoftが直してくれる。
では、Microsoftが直すまで、利用者には何ができるのだろう。
自分でパッチを当てることはできない。
修正の優先順位を上げることもできない。
内部でどのような対策が行われているのか、そのすべてを確認することもできない。
クラウドへ移行するということは、サーバーを自社からMicrosoftのデータセンターへ移すだけではない。
脆弱性にどう対応するかという判断と実行の一部まで、クラウド事業者へ預けるということだ。
私たちはクラウドによって、パッチ管理という面倒な仕事から解放された。
それは間違いなく進歩である。
しかし同時に、
自分でパッチを当てる権利も手放した。
便利さと引き換えに何を渡したのか。
今回のCVSS 10.0は、その普段見えない交換条件を非常に分かりやすく見せている。
クラウドは「パッチ管理」を消した
ここまで「利用者には直せない」と書いてきたが、それ自体は必ずしも悪いことではない。
むしろ、多くの企業にとってはその方が安全だろう。
オンプレミスでサーバーを運用した経験があれば分かる。
パッチは公開されたからといって、自動的に適用されるわけではない。
まず脆弱性情報を知る必要がある。
自社環境が影響を受けるのか調べる。
アップデートによる不具合がないか確認する。
場合によっては検証環境で試す。
サービス停止時間を確保する。
関係部署へ通知する。
バックアップを取る。
そして、ようやく適用する。
当然ながら、そこには人間の判断が入る。
「このサーバーは止められない」
「古いアプリケーションが動かなくなるかもしれない」
「来週メンテナンスがあるから、そのとき一緒にやろう」
「担当者が休みだから連休明けにしよう」
どれも現場では珍しくない話だ。
そして、パッチが公開されているにもかかわらず、何年も適用されないシステムが生まれる。
クラウドは、この問題のかなりの部分を消した。
Microsoft Teamsの利用企業が1万社あったとして、1万社の管理者がそれぞれTeamsのサーバーへパッチを適用する必要はない。
Microsoftが一度修正すればいい。
利用企業が100万社でも基本的な構造は変わらない。
しかも、利用企業側の担当者が休暇中でも関係ない。
お盆休みでも、ゴールデンウィークでも、年末年始でも、Microsoft側でサービスが修正されれば利用者側の環境にも反映される。
「大型連休にはセキュリティ事故に注意しろ」と毎年のように言われる理由の一つは、人がいなくなるからだ。
監視する人が減る。
異常を発見する人が減る。
問題が発生しても判断できる人間が捕まらない。
緊急対応しようにもベンダーまで休んでいる。
技術的な脆弱性が大型連休になると突然増殖するわけではない。
人間側の対応能力が落ちる。
クラウドによる自動運用は、この弱点に対して非常に強い。
少なくともMicrosoft側で完結する脆弱性なら、自社の担当者を休日に呼び出して数百台のPCへパッチを展開する必要はない。
そして、もう一つ重要な違いがある。
オンプレミスには、
パッチを当てない自由がある。
少し妙な表現だが、これは管理者がシステムを支配している以上、当然のことだ。
Microsoftが「Critical」と評価しても、適用するかどうかを最後に決めるのは自社である。
今日適用してもいい。
来月でもいい。
極端な話、永久に適用しなくてもいい。
その結果侵害されれば責任も自分たちが負う。
自由と責任がセットになっている。
SaaSでは、この自由がほとんどない。
Microsoftが修正すると決めれば修正される。
利用者が「今のバージョンをあと半年使いたい」と言っても、原則としてサービス提供者側の更新を止めることはできない。
これはソフトウェア運用の世界では、とてつもなく大きな変化だった。
かつて企業のシステム管理者が握っていた、
「いつ、何を、どう更新するか」
という権限のかなりの部分をクラウド事業者が持つようになった。
その結果、世界中に大量に存在した「パッチを当てないサーバー」は減らせる。
古いバージョンを何年も放置する問題も減らせる。
専門家を何十人も抱えられない中小企業でも、Microsoftのセキュリティチームによる運用の恩恵を受けられる。
この意味では、クラウド化はセキュリティを大きく前進させた。
だから私は、
「オンプレミスなら自分でパッチを当てられるから安全だ」
とは思わない。
自分で管理できることと、実際に適切に管理できることは別問題だからだ。
多くの企業にとって、自分たちでMicrosoftより上手にMicrosoft TeamsやAzure SQL Databaseを運用するなど現実的ではない。
Microsoftに任せた方がいい。
おそらく、その判断は正しい。
ただし、管理を任せるということは、
失敗したときに自分で介入する能力まで手放すということでもある。
普段は、それを意識する必要がない。
クラウドが正常に動き続けている限り、利用者はサーバーの存在すら忘れていられる。
しかしCVSS 10.0という数字が突然表に出てくると、その構造が見える。
自分たちの重要なデータやコミュニケーション基盤のどこかに重大な欠陥が存在していた。
それを発見するのもMicrosoft。
修正するのもMicrosoft。
安全になったと判断するのもMicrosoft。
利用者は、その一連のプロセスを信頼する。
クラウドによって消えたのは、サーバールームだけではない。
システムを自分で守るための主権の一部も、そこから一緒に消えている。
同時に「自分で守る権利」も消した
クラウドサービスを使う以上、Microsoftを信用するしかない。
そう書くと、Microsoft批判のように聞こえるかもしれない。
しかし、これはMicrosoft固有の問題ではない。
AWSでもGoogle Cloudでも同じだ。
SaaSならさらに分かりやすい。
Google Workspaceを利用しながら、Googleのサーバーへ自社のセキュリティ担当者を送り込むことはできない。
Microsoft 365を利用しながら、Teamsのサーバーへ自社製のパッチを適用することもできない。
クラウドとは、そもそもそういうコンピューティングモデルである。
サーバーを所有しない。
ハードウェアを管理しない。
OSの面倒を見ない。
サービスによってはアプリケーションすら管理しない。
その代わりに利用料金を払い、クラウド事業者が提供する機能を使う。
私たちはクラウドへ移行するたびに、面倒な仕事を一つずつ手放してきた。
ハードウェア障害への対応。
電源設備。
ネットワーク。
バックアップ。
冗長化。
OSの更新。
ミドルウェアの管理。
そしてパッチ適用。
どれも企業のIT部門にとって重い仕事だった。
それを専門事業者へ集約できるからクラウドは普及した。
ただし、仕事を外へ出せば、その仕事に対する直接的な支配権も外へ出る。
これはセキュリティでも同じだ。
オンプレミスなら、重大な脆弱性が発見されたときに自社の判断でネットワークからサーバーを切り離せる。
特定のポートを閉じることもできる。
WAFに緊急ルールを追加することもできる。
サービスそのものを停止するという最後の手段もある。
もちろんクラウドでも、利用者が管理できる範囲なら同様の対策は可能だ。
しかし、Microsoft Teamsそのものの内部実装に脆弱性が見つかったとしても、利用企業がTeamsのプログラムを書き換えることはできない。
Azure SQL Databaseのサービス内部に問題があっても、Microsoftの管理領域へ入って修正することはできない。
そこには明確な境界線がある。
自分たちが管理する領域と、クラウド事業者しか管理できない領域だ。
今回のような脆弱性は、その向こう側で発生した。
普段、その境界線を意識することはほとんどない。
Teamsを開けば会議ができる。
Azure SQL Databaseへ接続すればデータが返ってくる。
Entra IDへログインすれば認証される。
裏側で何台のサーバーが動き、どのようなコードが実行され、昨日どんなアップデートが行われたのかを利用者が知る必要はない。
知らなくても使えることこそクラウドの価値である。
しかし、そのブラックボックスの中で重大な脆弱性が発見された瞬間、同じ性質が反対方向に働く。
知らなくても使えるということは、知りたくても分からない領域が存在するということでもある。
利用者ができるのは、Microsoftが公開する情報を確認すること。
自社側で制御できる認証やアクセス権限を見直すこと。
ログを監視すること。
異常がないか確認すること。
必要ならサービスの利用方法そのものを制限すること。
しかし、脆弱性そのものを直すことはできない。
だからクラウドセキュリティでは、少し奇妙な構造が生まれる。
企業はクラウド事業者を完全には検証できない。
それでもクラウド事業者を信頼しなければサービスを利用できない。
つまりクラウドとは、計算資源を外部化しただけではない。
信頼まで外部化したシステムである。
ここで重要なのは、「だからクラウドは危険だ」という結論ではない。
逆だ。
自社の数人のIT担当者だけで巨大なシステムを守るより、MicrosoftやGoogle、Amazonのセキュリティ組織へ任せた方が安全である可能性は高い。
問題は、
任せたからリスクが消えたわけではない
ということだ。
リスクの場所が変わっただけである。
オンプレミスでは、自社のパッチ適用漏れがリスクになる。
クラウドでは、サービス提供者側の実装や運用がリスクになる。
前者は自分で改善できる。
後者は基本的にサービス提供者へ委ねるしかない。
そして今回、Microsoftはその自分たちの管理領域からCVSS 10.0の脆弱性が見つかったことを公開した。
これはMicrosoftのクラウドが危険である証拠とは限らない。
むしろ、かつてなら利用者には見えなかった問題までCVEとして公開するようになったという意味では、透明性の向上と評価することもできる。
それでも、この数字には意味がある。
クラウドへ移行した瞬間にセキュリティリスクが消滅するわけではない。
自分たちの目の届かない場所へ移動するリスクもある。
「管理しなくていい」と「心配しなくていい」は、同じ意味ではない。
クラウドを利用する企業が本当に理解しておくべきなのは、おそらくこの違いだ。
EntraとSRE Agentの9.9が示す次の問題
今回公開された脆弱性で、CVSS 10.0の3件ばかりに目を奪われるのは少々もったいない。
そのすぐ下には、CVSS 9.9というほとんど上限に近い脆弱性が4件並んでいる。
対象にはAzure Service Bus、Entra Provisioning Service、そしてAzure SRE Agentなどが含まれる。
この顔ぶれが興味深い。
特に気になるのが、IDと権限を扱う領域である。
Microsoft Entraは、単なるログイン画面ではない。
企業のクラウド環境において、
「あなたは誰なのか」
「どの組織に所属しているのか」
「どのシステムへアクセスできるのか」
「そこで何をしてよいのか」
を決める基盤である。
クラウドサービスが増えれば増えるほど、その重要性は高くなる。
昔なら、社内LANへ入れれば多くのシステムへアクセスできた。
現在は違う。
社員は自宅からアクセスする。
スマートフォンからアクセスする。
SaaS同士も接続する。
APIもシステムへアクセスする。
社内と社外という単純な境界線だけでは守れなくなった。
そこで重要になったのがIdentity、つまり「誰であるか」と、それに紐付くAuthorization、「何を許可されているか」である。
だからこそ、認証や認可に関する脆弱性は厄介だ。
玄関の鍵を破られるだけではない。
誰がどの部屋へ入ってよいのかを決めている管理台帳そのものに問題が生じる可能性がある。
そしてAI Agentの普及によって、この問題はさらに重要になる。
今回CVSS 9.9の脆弱性が公開されたAzure SRE Agentは、その名前の通りAI Agentを使ってAzure環境の運用を支援するサービスだ。
MicrosoftはAzure SRE Agentについて、Azureリソースや監視システムと連携し、インシデント対応や運用作業を支援するAIベースのサービスとして提供している。
ここで考えてみたい。
AI Agentを便利にするためには何が必要だろう。
チャットで質問に答えるだけなら、モデルに大きな権限は必要ない。
しかし、
「障害の原因を調べてくれ」
「ログを確認してくれ」
「このリソースの状態を調べてくれ」
「問題があれば対応してくれ」
となれば話は変わる。
Agentはシステムを見なければならない。
ログを読まなければならない。
APIを呼び出さなければならない。
場合によっては、何らかの操作まで実行しなければならない。
Agentが役に立つほど、Agentには権限が必要になる。
これは生成AI特有の問題ではない。
サービスアカウントでも、RPAでも、自動運用ツールでも昔から存在していた。
強力な自動化には強力な権限が必要になる。
権限を与えれば、その権限自体が攻撃対象になる。
AI Agentは、この古典的な問題を猛烈な勢いで拡大しようとしている。
しかもAI Agentの場合、人間が一つずつ操作する必要がない。
情報を集め、判断し、別のシステムを呼び出し、次の処理へ進む。
それこそがAgentの価値である。
だからこそ、その入口にある認証と認可が重要になる。
ここで誤解してはいけない。
今回のAzure SRE Agentの脆弱性は、
AIが暴走した事件ではない。
AIが悪意を持ったわけでもない。
AIがMicrosoftの命令を無視して勝手に権限を奪ったわけでもない。
問題になったのは認可である。
極めて古典的なセキュリティの話だ。
しかし、その古典的な脆弱性が存在する場所が変わった。
これまでは、人間が操作する管理ツールの権限を心配していた。
これからは、
人間の代わりにシステムを操作するAI Agentの権限
まで考えなければならない。
AIの安全性というと、私たちはついモデルばかりを見る。
危険な質問に答えないか。
機密情報を出力しないか。
ハルシネーションを起こさないか。
悪意ある命令に従わないか。
もちろん、それらも重要だ。
しかし企業システムへAI Agentが入っていくなら、もっと古臭くて現実的な問いが重要になる。
そのAgentは、いったい何の権限を持っているのか。
その権限は誰が与えたのか。
どこまでアクセスできるのか。
権限昇格は起きないか。
認証情報が奪われたら何ができるのか。
Agentが呼び出す別のサービスでは、同じ権限がどう扱われるのか。
AIがどれほど安全に設計されていても、土台となるIdentityとAuthorizationに穴があれば意味がない。
そしてクラウドでは、その土台の一部までサービス提供者へ預けている。
今回並んだEntraとAzure SRE Agentの重大な脆弱性は、その構造を象徴しているように見える。
AI Agent時代のセキュリティで本当に怖いのは、
AIが突然悪意を持つことだけではない。
善良なAIに与えた強力な権限を、別の誰かが使える状態になることだ。
未来的なAIの話をしているようで、その入口にあるのは昔から変わらない。
認証。
認可。
最小権限。
そして、「誰をどこまで信用するのか」。
AI Agentが新しくなっても、セキュリティの基本原則まで新しくなるわけではない。
大型連休に考える「クラウドだから安心」の意味
大型連休の前になると、セキュリティ対策を呼びかける記事が増える。
OSを最新の状態にする。
ソフトウェアをアップデートする。
バックアップを確認する。
不審なメールに注意する。
休暇中の緊急連絡体制を確認する。
どれも正しい。
人が少なくなり、異常の発見や初動が遅れやすい大型連休は、攻撃者にとって都合のいい時期でもある。
だからシステム管理者は、休みに入る前にあれこれ確認する。
かつてなら、そこにもう一つ大きな仕事があった。
パッチは全部当たっているか。
サーバーを確認する。
PCを確認する。
ネットワーク機器を確認する。
休暇中に重大な脆弱性が公開されれば、最悪の場合は担当者を呼び戻す。
クラウドは、その風景を大きく変えた。
今回MicrosoftのクラウドサービスからCVSS 10.0の脆弱性が3件公開された。
さらに9.9も4件ある。
それでも、多くの利用企業のシステム管理者が休日出勤してパッチを適用する必要はない。
Microsoftが修正するからだ。
これは間違いなくクラウドの恩恵である。
世界中の企業が、それぞれ同じ脆弱性情報を読み、それぞれ検証し、それぞれパッチを適用する必要がない。
専門家を大量に抱えられない企業でも、巨大なクラウド事業者のセキュリティ運用に乗ることができる。
私なら、その恩恵を捨ててまで何でもオンプレミスへ戻そうとは思わない。
ただし、
「クラウドだから安心」
という言葉には注意した方がいい。
クラウドへ移行したから脆弱性がなくなるわけではない。
今回のCVSS 10.0が、それを証明している。
パッチ適用という作業が消えたのでもない。
自分たちがやらなくなっただけだ。
Microsoftの中では、誰かが脆弱性を調査し、影響範囲を確認し、修正し、検証し、サービスへ反映している。
私たちは、その仕事を見る必要がなくなった。
見えなくなったとも言える。
だからクラウド時代のセキュリティでは、昔とは少し違う能力が必要になる。
すべてを自分で守ろうとすることではない。
どこまで自分で守り、どこから先を誰に任せるのかを理解することだ。
自社で管理するIdentity。
利用者へ与える権限。
多要素認証。
アクセス制御。
ログ監視。
バックアップ。
クラウド事業者へ預けている領域。
それぞれの境界を理解していなければ、何か起きたときに自分たちが何をすべきなのかすら分からない。
そしてAI Agentが企業システムへ入ってくれば、その境界はさらに複雑になる。
人間だけではなく、AgentにもIdentityが与えられる。
Agentにも権限が与えられる。
AgentもAPIを呼ぶ。
Agentも別のクラウドサービスへアクセスする。
便利になるほど、信頼関係は増えていく。
今回のAzure SRE AgentやEntraをめぐる重大な脆弱性は、その未来が決して遠い話ではないことも示している。
しかし、だからクラウドをやめるべきだという話ではない。
今回Microsoftがクラウドサービス内部の重大な脆弱性までCVEとして公開していること自体、以前より透明性は高まっている。
問題を隠すことと、問題が存在することは別だ。
重大な脆弱性が公開されたという事実だけを見て、
「Microsoftクラウドは危険だ」
と結論付けるのも違う。
むしろ私たちが問うべきなのは、
Microsoftへ任せるリスクと、自分たちで管理するリスクのどちらを選ぶのか。
ということだろう。
自社でサーバーを管理すれば、自分でパッチを当てられる。
同時に、自分でパッチを当て忘れることもできる。
クラウドならMicrosoftが修正してくれる。
同時に、Microsoftが修正するまで自分では直せない。
どちらにもリスクがある。
違うのは、そのリスクを誰が管理しているかだ。
今回のCVSS 10.0という数字が不気味なのは、単に最高点だからではない。
普段は見えないクラウドの内部にも、当然ながら重大な欠陥は生まれる。
そして、その領域を守る鍵を持っているのは利用者ではない。
Microsoftである。
私たちは、その鍵を預ける代わりに、巨大なクラウド基盤を自分で管理する仕事から解放されている。
それがクラウドという取引なのだと思う。
だから、
クラウドは安全だから使うものではない。
自分で管理するより、Microsoftに管理させた方が安全だと判断して使うものだ。
大型連休にCVSS 10.0が3件。
それでもシステム管理者がパッチを抱えて会社へ走らなくていい。
それはクラウドが実現した大きな進歩である。
ただし、安心して休めるようになったことと、
誰も信用しなくてよくなったことは、まったく別の話だ。
