Windows

Microsoftが、Windows Serverに対してネイティブのパフォーマンス強化機能を正式リリースした。これまでサードパーティ製ツールや独自パッチでカバーしていた領域に、OS本体が直接手を入れてくる——サーバーインフラを担当するエンジニアにとって、無視できないアップデートだ。 何が変わったのか 今回リリースされた機能は、仮想化（Hyper-V）とコンテナワークロードのスループットを大幅に向上させるもの。これまでハイパーバイザー層やコンテナランタイムのネットワーク・I/Oパスで生じていたオーバーヘッドを、OS側が直接最適化する形になる。 ポイントは「ネイティブ」であること。従来、同様の最適化を求めるユーザーは、サードパーティ製のアクセラレーターやドライバー拡張に頼るしかなかった。これらは効果的である一方、OSアップデートとの相性問題やサポートライフサイクルの管理など、運用側に一定の負担を強いてきた。今回のリリースにより、そのトレードオフが大きく解消される。 技術的な背景 仮想化・コンテナ環境でのボトルネックは主にデータパス（ネットワークスタックおよびストレージI/O）に集中する。特にコンテナワークロードでは、ホストとコンテナ間のパケット処理でカーネル内を何度も往復するコストが積み重なり、高負荷時のスループット低下として顕在化しやすい。 Microsoftはこのパスを短縮・効率化するロジックをWindowsカーネルおよびHyper-Vの基盤レイヤーに組み込んだ。結果として、外部ツールなしに「物理ハードウェアの性能に近い数値」が出るケースも報告されている。 Azure上でのワークロード最適化で培った知見を、Windows Server本体に還元したという見方もできる。MicrosoftはAzureの超大規模環境で積み上げてきた最適化技術を、オンプレミスのWindows Serverに降ろす動きを継続しており、今回はその流れの一環と位置づけられる。 日本の現場への影響 日本企業のインフラ環境では、オンプレミスのHyper-V上で基幹システムの仮想マシンを動かし、それと並走してKubernetesやコンテナ基盤を構築しているケースが少なくない。こうした混在環境ほど、今回の最適化恩恵を受けやすい。 IT管理者・インフラエンジニアへの実務ポイント： まずベンチマークを取れ: 「ネイティブ機能が入った」という情報だけで動くのではなく、自社環境での実測値を確認してから判断する。ワークロードの種類によって効果の幅は異なる サードパーティ製アクセラレーターの整理: これまでパフォーマンスのために導入していたツールがある場合、今後の更新サイクルで見直せるかもしれない。ライセンスコストや管理負荷の削減につながる可能性がある Windows Updateの適用判断: 今回のような機能が含まれるKBは、適用後の動作確認を慎重に行う。特に本番環境への適用は、テスト環境での先行確認を必ず挟む コンテナネットワーク設定の再評価: ネイティブ最適化が入ることでコンテナ間通信のパラメーター調整の前提が変わることがある。既存の最適化設定が二重になっていないかを確認する 筆者の見解 Microsoftが長年にわたって培ってきた強みの一つは、「大規模クラウド基盤での実績をWindowsというOSに統合する」能力だ。今回のリリースはその典型であり、率直に評価したい。 サードパーティ製品で解決するしかなかった部分にOS本体が手を入れるというのは、ユーザーにとっても管理者にとっても本来あるべき姿だ。「禁止より安全に使える仕組みを」と常々思っているが、今回はその精神に近い動きと言える。追加コストなしに、公式サポートの範囲内で最適化が完結するのは、長期的な運用コスト削減に直結する。 ただ一点、Windows Serverの機能拡充は歓迎しつつも、現場への伝わり方には注意が必要だ。「ネイティブ機能が入ったから自動的に速くなる」と早合点するのは禁物で、実際の効果は環境・ワークロードに依存する。Microsoftが大きく打ち出した機能が特定の構成でしか効かなかった、という話は珍しくない。 それでも、方向性は正しい。オンプレミスの仮想化・コンテナ基盤がWindowsのネイティブな最適化で強化されていくなら、それはクラウドとオンプレの選択肢を現実的に比較するための土台になる。Windowsが本来持っている力を、地に足のついたかたちで発揮してくれる——そういう積み重ねが、長く使い続けられる基盤を作ると思っている。 出典: この記事は Microsoft releases native Windows feature bringing huge performance boost to Servers の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Windows Server 2025を運用するドメインコントローラー（DC）が突然の再起動ループに陥るという深刻な障害が報告され、Microsoftは2026年4月、帯域外（Out-of-Band）パッチKB5091157を緊急リリースした。しかし今回の騒動で見逃してはならない点がもう一つある。同パッチのリリースに合わせて公表された「Secure Boot証明書の2026年6月失効問題」だ。複数のリスクが同時に浮上した今、Windows Server環境の管理者は即刻対応を検討する必要がある。 DCが再起動ループに陥ることの深刻さ 今回問題となったのは、Windows Server 2025のドメインコントローラーが特定のパッチ適用後に再起動ループへ陥る現象だ。Active Directoryの根幹を担うDCがループ状態に入ると、認証インフラ全体が機能を失う。VPNや内部サービスへのログインから、グループポリシーの適用まで、ほぼすべての業務が止まる可能性がある。 KB5091157はこの再起動ループを修正するための緊急パッチだ。通常の月例更新（Patch Tuesday）とは別に、OOBとして単独リリースされた点からも、Microsoftがこの問題を深刻視していたことが伝わる。OOBパッチは「待てない」と判断された際にのみ出てくるものであり、そのシグナルを軽く見てはいけない。 同時に判明したSecure Boot証明書の失効問題 さらに見過ごせないのが、パッチと合わせて公表されたSecure Boot証明書の失効問題だ。現在多くのデバイスで使用されているSecure Boot証明書の一部が、2026年6月に失効する予定だ。これが適切に更新されないまま放置されると、そのデバイスは起動時にSecure Bootの検証を通過できなくなるリスクがある。 Microsoftはこのリスクへの対応として、Windows Securityアプリに緑・黄・赤のバッジでSecure Bootの状態を視覚的に示す新機能を追加した。 🟢 緑：証明書は有効、問題なし 🟡 黄：要注意、確認が必要 🔴 赤：証明書失効リスクあり、対応必須 この信号機式の表示は、技術に詳しくないユーザーでもリスクを認識しやすくする工夫として評価できる。ただし、表示を見ても「何をすればいいか」が分からなければ意味がない。企業環境では管理者が主体的にデバイス状態を把握し、Windows Updateの適用状況を確認する責任がある。 実務への影響：IT管理者が今すぐやるべきこと ドメインコントローラーへの対応 Windows Server 2025のDCを運用している場合、KB5091157の適用は急務だ。ただし、DCへのパッチ適用は「全台同時」ではなく、段階的に行い適用後の動作確認を挟む運用を強く推奨する。再起動ループが発生する前に手を打つことと、適用自体でトラブルが起きないかを確認することを両立させる必要がある。 Secure Boot証明書の確認ステップ Windows Securityアプリでデバイスの状態バッジを確認する 企業環境ではMicrosoft IntuneやSCCMなどの構成管理ツールを使って一括でデバイス状態を把握する 黄・赤のデバイスはWindows Updateの完全適用状況を確認し、最新の証明書更新パッチが当たっているかを検証する 2026年6月より前に全デバイスへの対応を完了させるスケジュールを今から立てる 特に古いUEFIファームウェアを持つデバイスや、長期間Windows Updateを停止・遅延させてきた端末は優先的にチェックすべきだ。「今動いているから大丈夫」という姿勢が最も危険なのは、こういった期限付きの問題が仕掛けられているケースだ。 筆者の見解 今回気になるのは、「再起動ループの修正」と「Secure Boot証明書失効」という2つの問題が同じタイミングで出てきたことだ。どちらも単独では対処できる問題だが、インフラ担当者が片方に集中している間にもう片方を見落とすリスクがある。情報を整理して優先度をつける判断力が、今まさに問われている。 Secure Boot証明書の失効は、2026年6月という期限がはっきりしている点でむしろ対応しやすい。Windowsのセキュアブートはブートキットやルートキットに対する防御の最前線であり、ここが機能しなくなることの意味は決して小さくない。この方向性、つまりブートレベルのセキュリティを継続的に強化していくMicrosoftの取り組みは正しいと思っている。 その一方で、月例パッチに加えてOOBが出るたびに管理者が追加判断を迫られる状況については、率直に言って「もったいない」と感じる。これだけの技術基盤を持っているのだから、パッチの品質管理と展開の仕組みでもっと現場を楽にできるはずだ。現場の管理者が振り回されるのではなく、Microsoftの技術力をもっと信頼して委ねられる環境を作ってほしい——それが応援する立場からの率直な期待だ。 いずれにせよ、Secure Boot証明書の失効期限は待ってくれない。今日のうちにカレンダーに「2026年6月 Secure Boot証明書確認」を入れておくことを強くお勧めする。 出典: この記事は KB5091157 April 2026 Out-of-Band Fix for Windows Server 2025 Reboot Loops の内容をもとに、筆者の見解を加えて独自に執筆したものです。

PackageKit デーモンに深刻な脆弱性「Pack2TheRoot」（CVE-2026-41651）が発見された。ローカルユーザーが認証なしでシステムパッケージを操作し、root 権限を取得できるこの欠陥は、2014年から実に12年間にわたって静かに潜み続けていた。Deutsche Telekom のレッドチームが発見し、修正版となる PackageKit 1.3.5 が公開されている。 PackageKit とは何か PackageKit は、Linux システム上でソフトウェアのインストール・更新・削除を管理するバックグラウンドデーモンだ。Ubuntu の「ソフトウェアセンター」、GNOME Software、KDE の Discover といった GUI パッケージマネージャーの裏で動いており、エンドユーザーが普段意識することはほとんどない。しかしそのぶん、デスクトップ環境にデフォルトで組み込まれていることが多く、今回の脆弱性の影響範囲は広い。 脆弱性の詳細：認証をすり抜ける仕組み この脆弱性の核心は、PackageKit がパッケージ管理リクエストを処理するメカニズムにある。特定の条件下で pkcon install コマンドが 認証を経ずに実行できてしまう。これにより、ローカルにアクセスできる一般ユーザーがシステムパッケージを操作し、root 相当の権限を手に入れられる。CVSS スコアは 8.8（高危険度）。 注目すべきは、調査チームが AI ツールを活用して脆弱性の悪用可能性を体系的に掘り下げた点だ。現代のセキュリティリサーチでは、AI が脆弱性分析の強力な補助手段になりつつあることを示す好例でもある。 影響を受けるディストリビューション 研究者が実際に悪用可能であることを確認した環境は以下の通り： ディストリビューション バージョン Ubuntu Desktop 18.04 (EOL)、24.04.4 LTS、26.04 (LTS beta) Ubuntu Server 22.04〜24.04 LTS Debian Desktop Trixie 13.4 Rocky Linux Desktop 10.1 Fedora Desktop / Server 43 ただしこのリストは網羅的なものではなく、PackageKit をインストールして有効化している Linux ディストリビューションはすべて潜在的に脆弱と考えるべきだ。 対処方法：今すぐ確認すべきこと バージョン確認： 出典: この記事は New ‘Pack2TheRoot’ flaw gives hackers root Linux access の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

パスワードという認証方式が「負け確定」の技術であることは、セキュリティの世界では常識になりつつある。Microsoft Entraの保護リソースに対して、WindowsデバイスからFIDO2ベースのパスキーで認証できる新機能が2026年4月末から順次展開される。6月中旬の一般提供（GA）を目指しており、管理外（非Entra参加・非登録）デバイスへの対応拡充が今回の最大のポイントだ。 パスキーとは何か、何が変わるのか パスキー（Passkey）はFIDO2アライアンスが策定した認証規格をベースにした、デバイスに紐付いた暗号鍵ペアによる認証方式だ。今回の「Entra パスキー on Windows」では、認証情報はWindows Helloコンテナ内にデバイスバインドで保存される。顔認証・指紋・PINのいずれかでローカル認証を行い、その結果をMicrosoft Entra IDへの認証に用いる仕組みだ。 重要な点は、認証情報がネットワークを一切流れないこと。フィッシングメールで偽サイトに誘導されても、パスキーは別のドメインには使えない。マルウェアがメモリをスキャンしても、秘密鍵はTPM（Trusted Platform Module）の保護下にあり取り出せない。従来のパスワードや、SMSやAuthenticatorアプリを使うMFAよりも攻撃耐性が格段に高い。 Windows Hello for Business との違い 混同しやすいので整理しておこう。 比較軸 Entra パスキー on Windows Windows Hello for Business デバイス登録要件 不要（管理外デバイスでもOK） Entra参加/登録が前提 デバイスサインイン 非対応 対応（SSO込み） 管理ポリシー Authentication Methods + Conditional Access Intune / グループポリシー Windows Hello for Businessはデバイス参加が前提で、デバイスサインインとEntra SSOを両立する「企業管理PC向け」の仕組みだ。今回のEntra パスキーはそれとは別物で、個人所有デバイス（BYOD）や共有端末でもEntra認証をパスワードレス化できる点が新しい。 なぜ今、この機能が重要か 2025年以降、Microsoft EntraのSSOアカウントを狙ったSaaSデータ窃取攻撃が急増している。攻撃者は盗んだ認証情報を使ってEntra SSOを悪用し、SharePoint・OneDrive・TeamsといったMicrosoft 365リソースへアクセスする手口を多用している。パスワードと組み合わせのMFAでも、巧妙なリアルタイムフィッシング（AiTM攻撃）によりセッショントークンを奪われるケースが出てきた。 パスキーはこのギャップを塞ぐ。フィッシングでは奪えず、認証情報はデバイス外に出ない。「管理外デバイスからのEntra認証はパスワードしか選択肢がない」という長年のセキュリティ上の穴が、ようやく公式に埋まることになる。 実務での活用ポイント IT管理者が今すぐ確認すべきこと： Authentication Methods ポリシーを確認する — Entra管理センターで「Microsoft Entra ID with passkeys」が有効になっているか確認。対象ユーザーグループを段階的に広げる計画を立てる Conditional Access ポリシーを見直す — 「認証強度（Authentication Strength）」の「Phishing-resistant MFA」定義にパスキーが含まれていることを確認し、管理外デバイスからのアクセス要件をアップデートする BYOD・共有端末の棚卸しをする — 「管理が難しいからパスワードのまま」だったデバイスこそ、優先的にパスキー移行を検討する絶好の機会だ ユーザー教育は最小限で済む — 登録フローはWindows Helloの顔・指紋設定と同様。「PINか生体認証を使ってください」の一言で大半のユーザーは対応できる 筆者の見解 ゼロトラストを推進する立場から言えば、これは正しい方向の一手だ。パスワードはもう認証の中心に置くべき技術ではない。フィッシング耐性のある認証をBYODや共有デバイスにまで広げる今回の施策は、「ネットワーク境界での防御」から「IDと認証そのものの強靱化」へというシフトを着実に進めるものだ。 ...

2026年2月以降、BlackFileと呼ばれる新興の金銭目的ハッキンググループが小売業・ホスピタリティ業を中心に急激に活動を拡大している。Palo Alto Networks の Unit 42 と RH-ISAC（小売・ホスピタリティ情報共有分析センター）の報告によると、このグループはITヘルプデスクのスタッフを装った電話——いわゆるビッシング（Vishing：Voice Phishing）——を起点として、多要素認証（MFA）すら突破する巧妙な攻撃チェーンを構築している。 同グループは CL-CRI-1116、UNC6671、Cordial Spider とも追跡されており、英語圏サイバー犯罪者の緩やかなネットワーク「The Com」との関連も指摘されている。 攻撃の全体像：電話1本から機密データ流出まで 攻撃のフローは非常に体系化されている。 ステップ1：VoIP番号偽装でのビッシング 攻撃者はVoIP番号や発信者番号表示（CNAM）を偽装し、社内ITサポートを名乗って従業員に電話をかける。「アカウントに問題が発生しているので確認が必要です」といった口実で、偽の企業ログインページに誘導する。 ステップ2：認証情報とワンタイムパスコードの同時詐取 フィッシングページはリアルタイムで認証情報とOTPを転送する仕組みになっており、攻撃者側でそのまま正規セッションを確立できる。MFAがあっても、OTPを電話口で「読み上げさせる」ことで突破してしまう。 ステップ3：攻撃者デバイスのMFA登録 奪ったセッションを使って、攻撃者は自分のデバイスをMFA信頼済みデバイスとして登録する。これ以降はOTP不要でログインが可能になる。 ステップ4：社内ディレクトリを使った権限昇格 SharePoint や社内ポータルから従業員ディレクトリをスクレイピングし、経営幹部アカウントへの接触・権限昇格を試みる。 ステップ5：Salesforce・SharePoint APIによる大規模データ窃取 標準的なAPIおよびSharePointのダウンロード機能を使って「confidential」「SSN」などのキーワードでファイルを検索し、CSVデータセットや機密レポートを攻撃者インフラへ転送する。正規のSSO認証済みセッションを装うため、単純なユーザーエージェントベースの検知を回避する。 ステップ6：ダークウェブ公開と身代金要求 窃取データをダークウェブのリークサイトに掲載した上で、侵害した従業員メールや使い捨てGmailアドレスから身代金を要求する。要求額は7桁（≒数百万ドル規模）に上る。 追加の圧力：スワッティング 経営幹部を含む従業員へのスワッティング（虚偽の緊急通報による強制捜査の呼び込み）も報告されており、精神的・組織的な圧力を最大化する戦術として使われている。 日本のIT現場への影響 日本の小売・ホスピタリティ企業も決して対岸の火事ではない。特に以下の点が懸念される。 Salesforce・SharePointの広範な普及：日本企業でも両プラットフォームは標準的に導入されており、APIアクセス制御が甘い環境は格好の標的になりうる。 ヘルプデスク体制の脆弱性：コールセンターや外部委託のITサポートが電話での本人確認を厳格に行っていないケースは多い。「IT担当から電話がかかってきた」という状況を疑わずに対応してしまう文化的背景は日本でも存在する。 MFA導入≠完全防御の誤解：MFAを導入していれば安心、という思い込みが最も危険。ビッシングを組み合わせたMFAバイパスは既知の攻撃手法であり、技術的な対策だけでは不十分だ。 実務で取り組むべきこと： コール確認ポリシーの強化：ITサポートを名乗る電話には、折り返し確認（既知の社内番号に自分からかけ直す）を義務付ける。電話口でのOTP読み上げは絶対禁止をポリシー化する。 MFA登録フローの審査強化：新しいデバイスのMFA登録には、管理者承認または帯域外確認（別チャネルでの本人確認）を必須にする。Conditional Access ポリシーで登録デバイスに準拠デバイス要件を課すことも有効。 Salesforce・SharePoint のAPIアクセスログ監査：大量ダウンロードや「confidential」「SSN」等のキーワード検索をアラート対象にする。Microsoft Purview や Salesforce Shield のデータ損失防止（DLP）ポリシーを活用する。 ソーシャルエンジニアリング訓練の実施：座学でなく、実際のビッシングをシミュレーションした訓練を定期実施する。フロントラインスタッフが「おかしい」と感じたときに即エスカレーションできる文化を作る。 特権アカウントのJust-In-Time化：常時アクセス権を持つ経営幹部アカウントは攻撃者にとって最大のターゲット。必要なときだけ権限を付与するJIT（ジャストインタイム）アクセスモデルへの移行を検討する。 筆者の見解 この攻撃を見て改めて感じるのは、「MFAを導入した」「ゼロトラストを進めている」と言いながら、電話1本で全部崩れてしまう運用がいかに多いか、ということだ。 BlackFile の手口は技術的に新しいものではない。ビッシングによるOTP詐取、デバイス登録でのMFAバイパス——どれも数年前から報告されている手法だ。それでも成功するのは、人間の側の手続きが追いついていないからに尽きる。 「禁止すれば守られる」という発想で対策を打ち続けても限界がある。従業員が「電話でOTPを教えてはいけない」と知識として知っていても、「本物っぽいITサポート」から丁寧に説明されたときに断れるかどうかは別の話だ。実際の状況をシミュレーションした訓練を繰り返し、安全な行動が反射的にできる環境を作ることこそが本質的な対策だと思う。 API経由の大規模データ窃取についても同様で、「Salesforce のAPIは便利だから使っている」状態で、アクセスログを誰も見ていないケースは珍しくない。Non-Human Identity（NHI）やサービスアカウントの管理と同じく、APIアクセスの可視化と異常検知が自動化の前提条件になる時代だ。 ビッシングという古典的な手法が今も高い成功率を誇る現実は、技術的なセキュリティ投資だけでなく、人と手続きのレイヤーを同時に強化しなければ防げないという当たり前の事実を、改めて突きつけている。 出典: この記事は New BlackFile extortion group linked to surge of vishing attacks の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Linuxカーネルの新バージョン7.1が最初のリリース候補（RC1）として公開された。MicrosoftのNTFSファイルシステムに対する大幅なパフォーマンス改善、次世代Intel グラフィックスサポートの追加、そして1989年登場のi486アーキテクチャのサポート終了——いずれも単なるマイナーアップデートとは呼べない、歴史的な意味合いを持つ変更が詰め込まれた注目リリースだ。 NTFSの「爆速化」——Linuxがより良いWindowsの友に 今回最も注目すべき点は、NTFS（NT File System）の大幅なパフォーマンス向上だ。NTFSはWindowsが標準採用するファイルシステムであり、Linuxからネイティブに読み書きできるNTFS3ドライバーはカーネル5.15（2021年）で正式統合されて以来、継続的な改善が加えられてきた。今回の7.1では「ゲームチェンジング」と形容されるほどの性能改善が実現したとされる。 大容量ファイルの転送や多数のファイルを扱う操作において、従来比で顕著な速度向上が見込まれる。WindowsとLinuxのデュアルブート環境を使うユーザーや、Linux上でNTFSパーティションにアクセスする機会が多い開発者・IT管理者にとって、体感できるレベルの改善になりそうだ。 次世代Intel グラフィックスのサポート追加 Intel最新世代GPUアーキテクチャへの対応も今回のハイライトのひとつだ。LinuxにおけるGPUドライバーのカーネルレベルサポートが進むことで、クラウドインフラやHPC環境における最新ハードウェアの安定した活用が容易になる。AIワークロードを意識したGPUサーバー構築においても、最新世代ハードウェアをLinux上で問題なく運用できる基盤が整ってくる。 i486のサポート終了——37年の歴史に幕 技術史の観点でインパクトがあるのが、Intel 486（i486）アーキテクチャのサポート終了だ。1989年登場のi486は32ビット演算の普及を牽引した歴史的なCPUであり、Linuxはその草創期から「どんなハードウェアでも動く」という思想でサポートを維持してきた。今回の削除により、カーネルコードのシンプル化と現代ハードウェア向けの最適化が加速する。過去への敬意を示しつつも、前に進む判断として評価できる。 実務への影響——日本のエンジニア・IT管理者にとっての意味 Windows/Linux混在環境の管理者へ： LinuxベースのNASやファイルサーバーでWindowsクライアントと共存する環境では、NTFSパフォーマンス向上の恩恵を直接受けられる可能性がある。特に大量ファイルを扱う運用でボトルネックを感じていた場合、7.1ベースへのアップデートを検討する価値がある。 WSL2活用者へ： WindowsとLinux間でファイルシステムをまたいだ作業が多い開発者は、7.1ベースのWSL2環境に注目しておきたい。日々の開発ワークフローで体感できる改善につながる可能性がある。 組み込み・レガシーシステム担当者へ： i486系ハードウェアを現役で使っている組み込みシステム担当者は影響を確認しておく必要がある。6.x系の長期サポートカーネルへの移行、またはハードウェア刷新を検討するタイミングだ。 筆者の見解 LinuxカーネルがMicrosoftのNTFSをここまで精力的に最適化し続けているという事実は、興味深い逆説を示している。プラットフォームの枠を超えて互いの技術を取り込み合う時代の到来を象徴するシーンだ。 Microsoft自身がWSL2を通じてWindowsにLinuxを統合し、一方でLinuxカーネルコミュニティがNTFS対応を磨き続ける——この相互発展は、「WindowsかLinuxか」という二項対立が実質的に意味をなさなくなってきたことを示している。IT環境の多様化が進む日本の現場においても、Linuxをクラウドやコンテナの文脈で扱う機会はWindowsエンジニアにとっても増えている。プラットフォームの垣根にとらわれず、最適な技術選択ができる視野の広さが、これからのIT担当者には求められる。 i486のサポート終了は「終わり」よりも「解放」に近い。過去の重荷を下ろすことで、現代的な要求に集中できるカーネルとして進化を続けるLinuxの健全な姿がそこにある。 出典: この記事は Linux 7.1 arrives with a massive NTFS speed boost and the end of an era for i486 の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftが、Windows Updateに関する一連の改善をWindows Insidersへ展開し始めた。強制再起動による業務中断を減らし、ユーザーが更新タイミングをより細かくコントロールできるようにすることが目的だ。担当エンジニアのAria Hanson氏が「この数ヶ月で7,621件のフィードバックを直接読んだ」と述べているように、現場から積み上げられた不満を正面から受け止めた結果の変更群となっている。 主な変更点 1. セットアップ（OOBE）時に更新をスキップ可能に Windowsの初期セットアップ中に「アップデートを今すぐインストール」を強制されるフローが緩和され、まずデスクトップへ到達してから都合の良いタイミングで更新できるようになる。ただし管理対象の業務用PCやポリシー制御下のデバイスは対象外。 2. カレンダーUIで最大35日の一時停止・繰り返し延長が可能に 従来の一時停止機能は期間が固定だったが、新しいフライアウト型カレンダーから日付を直接指定して最大35日停止でき、さらに繰り返し延長も制限なく行えるようになる。「更新を止めたいが、いつ再開するかはまだ決めたくない」という現場のニーズに応えた形だ。 3. 電源メニューから「意図しない更新適用」を排除 「シャットダウン」「再起動」が純粋な電源操作として独立し、更新を適用したい場合のみ「更新して再起動」「更新してシャットダウン」を選ぶ設計に変わる。会議直前にシャットダウンしようとしたら勝手に更新が始まった——そのあの悔しい体験とは、ようやく縁が切れる方向に進む。 4. ドライバー更新の説明にデバイス種別を明示 「Realtek」「Intel」などメーカー名だけが並ぶ謎の更新リストに、「ディスプレイ」「オーディオ」「バッテリー」といったデバイス種別がタイトルに付くようになる。「これ何のドライバーを更新しようとしてる？」という迷子状態が解消される。 5. 月次累積更新への統合で再起動回数を削減 ドライバー、.NET Framework、ファームウェアの更新が月次累積更新とまとめて適用されるようになり、月に何度も再起動を要求される状況が改善される。「バックグラウンドでダウンロードを済ませ、次の品質更新と協調して一括インストール・再起動する」という設計だ。 実務への影響 エンジニアやIT管理者として押さえておきたい点が2つある。 35日停止の繰り返し延長は個人ユーザーには便利だが、Intuneやグループポリシーでパッチ適用を管理している環境では、ユーザーが手動で延長できる余地をポリシー側で制限するか否か、事前に方針を整理しておきたい。管理ポリシーとの競合が想定外の抜け穴になりうる。 月次統合による再起動回数の削減は運用コスト削減に直結する一方、「一度に変わるものが増える」というトレードオフも生じる。問題が発生した際に何が原因か切り分けにくくなるリスクがある。変更点のリストを月次で把握する習慣はむしろ今後より重要になるかもしれない。 現時点ではDev・ExperimentalチャンネルのInsiderのみが対象で、一般向け展開時期は未定だ。本番環境への影響が出るのは先だが、変更内容を把握したうえでIntuneやWSUSの構成を事前に見直しておくのが賢明だろう。 筆者の見解 正直に言う。Windows Updateに関しては「なぜこんな基本的なことがまだできないのか」という感想を何度持ったかわからない。電源メニューの分離も、停止期間のカレンダー指定も、ドライバー説明の改善も、いずれも「数年前から言われてきたこと」ばかりだ。 ただ今回は少し評価したい点がある。「7,621件のフィードバックを直接読んだ」という言葉に誠実さを感じた。数字を出してきたこと、そしてその声に対応する形で電源メニュー・停止UI・ドライバー説明・再起動統合とまとまった改善が一気に来たこと。こういう地道な改善こそが、長期的な信頼の根っこになる。 一方で、InsiderからGAまでに何かが削られたり変更されたりするケースはこれまでも少なくなかった。「ついに改善された！」と喜ぶのは一般向けリリース後でよい。それまでは静かに注視するスタンスが正しい。 もう一点。「すぐ適用したら壊れた」という報告が近ごろ増えているなかで、月次統合による変更量の増大は注意点でもある。再起動回数が減る代わりに一回の変更範囲が広がるわけで、数日様子を見てから適用するという判断は今後ますます理にかなった戦略になるかもしれない。焦って当てることが必ずしもベストではない。それはそれで、立派なセキュリティ判断だ。 出典: この記事は Windows Update gets new controls to reduce forced restarts の内容をもとに、筆者の見解を加えて独自に執筆したものです。

米国CISAと英国NCSCが共同で警告を発した「Firestarter」マルウェアは、Cisco FirepowerおよびSecure Firewallデバイスに感染し、パッチ適用後もファームウェア更新後も生き残るという非常に厄介な永続化手法を持つ、国家レベルの攻撃ツールだ。「パッチを当てれば安全」という前提そのものを覆すこの事例は、すべてのネットワーク管理者が正面から受け止めるべき警告である。 攻撃の全体像——初期侵入から永続化まで 攻撃グループ UAT-4356（「ArcaneDoor」キャンペーンでも知られるサイバースパイ集団）は、2つのCVEを悪用して初期アクセスを獲得する。 CVE-2025-20333: 認可チェック欠如（Missing Authorization） CVE-2025-20362: バッファオーバーフロー まず「Line Viper」と呼ばれるユーザーモードのシェルコードローダーを展開し、VPNセッションを確立した上で管理者認証情報・証明書・秘密鍵を含む全設定情報を収集する。次に永続バックドア「Firestarter」（ELFバイナリ）を投下する、という2段階の構成だ。 Firestarter の「執拗な」永続化メカニズム Firestarter の本当の脅威は、その永続化能力の徹底ぶりにある。 LINA（Cisco ASAのコアプロセス）へのフッキング: プロセス終了シグナル（グレースフルリブート）を受けると自動的に再インストールルーティンを発動 CSP_MOUNT_LIST ブートファイルの改ざん: 起動時の自動実行を確保 ログファイルパスへの偽装保存: /opt/cisco/platform/logs/var/log/svc_samcore.log にコピーを隠蔽し、/usr/bin/lina_cs として動作 ファームウェア更新・セキュリティパッチ適用後も生き残る さらに、XMLハンドラーを改ざんしてメモリ内にシェルコードをインジェクトする機能も持つ。特定の WebVPN リクエストをトリガーとして、攻撃者が指定したペイロードをメモリ上で直接実行できるため、ファイルシステムに痕跡を残さない。検出が極めて難しい設計だ。 実務への影響——今すぐやるべきこと 侵害確認コマンド Cisco は以下のコマンドによる確認を推奨している。 出典: この記事は Firestarter malware survives Cisco firewall updates, security patches の内容をもとに、筆者の見解を加えて独自に執筆したものです。

MetaとAWSが、複数年にわたる数十億ドル規模のAIインフラ契約を締結した。キーとなるのはAWSのカスタムプロセッサ「Graviton5」だ。AI開発の主戦場が「モデルの賢さ」から「インフラの規模と効率」へと移行している今、この契約はその象徴とも言える動きである。 AWSのGraviton5とは何か Graviton5はAWSが独自開発したARMベースのサーバープロセッサだ。前世代比で性能・電力効率を大幅に向上させており、AI推論（Inference）ワークロードに強みを持つ。 NVIDIAのGPUがAI学習（Training）フェーズで圧倒的な地位を占めているのは周知の事実だが、推論フェーズやエージェントAIの常時稼働フェーズでは、CPUの効率性も重要な要素になる。Metaほどの規模の企業がGraviton5を選んだという事実は、カスタムシリコンがAIインフラにおける現実的な選択肢として確立されつつあることを示している。 「エージェントAI」がインフラ要件を根本から変える エージェントAI（Agentic AI）とは、単に質問に答えるだけでなく、自律的にタスクを計画・実行するAIのことだ。検索、コード実行、外部APIの呼び出し、複数ステップを経た推論など、従来のチャットAIとは比較にならない計算量とレスポンス性能が求められる。 エージェントAIを本番規模で動かすには、桁違いのインフラが必要になる。MetaがAWSと組んだ背景には、自社データセンターだけでは賄えない計算需要をクラウドでカバーするという現実的な判断がある。AI開発において「自社完結」にこだわらず、外部クラウドと柔軟に組み合わせるハイブリッド戦略が主流になってきた証でもある。 実務への影響——日本のエンジニア・IT管理者が押さえるべき3点 ① エージェントAIは「試験運用フェーズ」を終えつつある MetaレベルのプレイヤーがAWSと数十億ドルの契約を結ぶということは、エージェントAIが概念実証を超えてビジネスの中核に入ってきたことを意味する。自社のAI活用計画を「まだPoC段階」で止めているなら、周回遅れになるリスクを真剣に意識すべき段階だ。 ② インフラ選択がAIの実用性を左右する エージェントAIは応答時間に敏感だ。適切なインフラを選ばないと、ユーザー体験が著しく悪化する。マルチモーダル・マルチステップの処理を前提としたインフラ設計を、今から検討しておく価値がある。クラウドベンダー各社のAI特化インスタンスの比較検討は後回しにしない方がいい。 ③ AIのコストは「モデル利用料」だけではない 推論インフラのコストは今後のAI予算の主要項目になる。アプリケーション層のAPIコストに目が向きがちだが、自社でAIを動かす場合のコンピュート費用、クラウドのAI特化インスタンスの価格動向は継続的にウォッチしておくべきだ。 筆者の見解 この規模の提携を見るたびに、AIインフラの現実を改めて突きつけられる感覚がある。 エージェントAIは間違いなく次の主戦場だ。単純な質問応答ではなく、複雑なタスクを自律実行するAIが業務フローに組み込まれれば、必要な計算リソースは桁違いに増える。MetaとAWSがその備えをいまのうちに固めているのは、至極合理的な判断だ。 気になるのは、こうした大型インフラ投資の恩恵が「一般企業・エンドユーザー」に降りてくるまでのタイムラグだ。インフラが整っても、それを業務に組み込む設計力・運用力がなければ宝の持ち腐れになる。今のうちにエージェントAIの基礎概念とユースケースを理解し、自社の業務フローに組み込む準備をしている企業と、「まだ様子見」を続ける企業の間には、1〜2年後に大きな実力差が生まれるだろう。 インフラに数十億ドルを投じるのは大企業の話だが、その上で動くサービスを賢く使いこなすのは私たちの仕事だ。仕組みを理解して先手を打てるかどうかが、これからのITエンジニアの価値を決める。 出典: この記事は Meta and AWS ink multi-billion dollar deal to power agentic AI with Graviton5 の内容をもとに、筆者の見解を加えて独自に執筆したものです。

プライバシー重視のパスワードマネージャー「Proton Pass」が、2026年内に実施予定の機能ロードマップを公開した。フォルダによる資格情報の整理、SSHエージェント機能、そのほか複数の改善が予告されており、単なるパスワード保管庫から開発者・IT管理者の認証情報ハブへと進化する方向性が鮮明になった。 何が追加されるのか 今回発表されたロードマップのポイントは大きく3つだ。 フォルダ機能は、増え続けるログイン情報を階層構造で整理できるようにするもの。個人用・業務用・プロジェクト別といった分類が可能になり、これまで「タグ」や「Vault（保管庫）」だけで管理していた煩雑さが解消される。 SSHエージェント機能は、今回の目玉といえる。SSHの秘密鍵をProton Passで管理し、sshコマンドから直接鍵を参照できるようになる。これにより、~/.ssh/に秘密鍵ファイルを置き続けるリスクを減らし、鍵の保管とアクセス制御をパスワードマネージャーの仕組みに統合できる。 そのほか、詳細は明かされていないが「その他の機能」として複数の追加改善がある模様だ。 実務への影響 このアップデートが日本のエンジニア・IT管理者に与える影響は、見た目以上に大きい。 SSH鍵管理の課題は長年の悩みだ。開発チームでは「個人PCの~/.ssh/に秘密鍵が野ざらし」「退職者の鍵をローテーションし忘れた」「踏み台サーバーに複数の鍵が散在している」という状況が珍しくない。SSHエージェントをパスワードマネージャーに統合することで、人間のアカウントと同じ管理サイクル（作成・棚卸し・失効）を鍵にも適用しやすくなる。 特にゼロトラストモデルへの移行を進めている組織では、Non-Human Identity（NHI）――つまりシステムやスクリプトが使う認証情報――の管理が大きなボトルネックになっている。SSHキーをパスワードマネージャーで一元管理できれば、このNHI管理の整備にも間接的に貢献する。 導入を検討する際の実践的なポイントとして、以下を押さえておきたい。 既存のパスワードマネージャーとのスイッチングコストを事前に見積もる（Proton Passはエクスポート/インポート機能を持つが、SSO連携などは別途確認が必要） Protonのゼロ知識暗号化モデルを理解した上で企業の情報セキュリティポリシーとの適合性を確認する SSHエージェント機能はリリース後にPoC環境で動作検証してから本番適用を判断する 筆者の見解 パスワードマネージャーにSSHエージェントを統合するアイデアは、ユーザーエクスペリエンスの観点から見て理にかなっている。「認証情報はここにある」という一元管理の原則を、パスワードだけでなく鍵ベースの認証にも拡張するのは自然な進化だ。 「禁止するより安全に使える仕組みを作れ」というのが私の基本スタンスだが、SSHキーの管理においてまさにこの思想が活きる。秘密鍵をローカルに分散させておくことのリスクを啓蒙するより、安全な保管先を公式に提供してしまう方が実効性が高い。 Proton PassはまだメジャーなB2B市場での実績が薄く、エンタープライズ導入には一定のハードルが残る。しかし、ロードマップが示す方向性――「認証情報管理の統合プラットフォーム」――は、業界全体が向かっている潮流と合致している。今後のリリースを継続してウォッチしていきたい。 出典: この記事は Proton Pass is getting folders, an ssh agent, and other features later this year の内容をもとに、筆者の見解を加えて独自に執筆したものです。

ハードウェアエンジニアリングの第一人者として知られるジョン・ターナス氏（現ハードウェアエンジニアリング担当上級副社長）がAppleの次期CEOに就任することが現実味を帯びてきた。その任期初弾として10の新製品カテゴリが準備されているという報道は、Apple単独の話にとどまらず、日本の企業IT環境にも波紋を広げる可能性がある。 ジョン・ターナスとはどんな人物か ターナス氏はAppleのハードウェアエンジニアリングを統括し、MacBook Pro、iPad、そしてApple Silicon（M1〜M4チップ）シリーズの開発を主導してきた人物だ。Steve Jobsが体現した「デザインと工学の統合」という哲学に最も近い位置に立つエンジニアと評される。 Tim Cook氏がサプライチェーンとビジネスオペレーションの卓越した設計者だったのに対し、ターナス氏は「作るもの」に情熱を向けるエンジニア出身のリーダーだ。このシフトは単なる顔の入れ替えではなく、Appleが次の10年で「何を軸に置くか」を再定義する宣言とも読み取れる。 10の新製品カテゴリ：何が来るのか 具体的な製品名はまだ明かされていないが、業界アナリストが挙げる有力候補には以下が含まれる。 スマートホームデバイス：ディスプレイ付きスマートスピーカーやHomePod上位モデル ヘルスケア機器：Apple Watchの延長線上にある血糖値センサー内蔵デバイスなど AR/VRの拡張：Vision Proの廉価版・後継機種 車載システム（次世代CarPlay）：独自インフォテインメント統合 ロボティクス：家庭用ロボットアシスタント（複数の特許出願が確認済み） エンジニアリング主導の体制に移行することで、「ハードウェアが主役の製品」が開発優先度を上げてくる可能性は高い。Apple Siliconが証明したように、ターナス氏がコミットしたハードウェアの完成度は本物だ。 実務への影響：日本のIT管理者・エンジニア視点 デバイス管理（MDM）戦略の見直しタイミング 日本企業でもiPadやMacを法人支給またはBYODで運用するケースは増加している。新製品カテゴリが拡充されれば、MDMポリシーの対象デバイス種別も広がる。特にヘルスケアデバイスや車載連携デバイスが業務文脈に入ってくる場合、既存MDMソリューションでの対応範囲を事前に確認しておく必要がある。 調達サイクルとのズレに注意 10カテゴリが一斉リリースとは考えにくいが、新体制の「顔」となる象徴製品は早期に出てくる可能性が高い。IT部門としては現行デバイスのリース・更新サイクルと新製品ロードマップのズレを意識した調達計画が求められる。 エコシステム拡張と管理コストの増大 Appleはデバイス間連携（Handoff、AirDrop、Universal Control等）を一貫して強化してきた。新カテゴリが追加されるとこの「輪」がさらに広がる。複数プラットフォームを混在運用する企業では、Apple輪の内側と外側のデバイスで管理コストの格差が拡大していく点に留意したい。 筆者の見解 正直に言えば、Apple製品を日常的に深く追っているわけではない。それでもジョン・ターナス氏のCEO就任という人事は、業務端末の選定やデバイス管理を担うすべてのIT関係者にとって「他人事」で済まない話だと思っている。 エンジニアリング出身のリーダーが舵を取るということは、製品哲学が変わる可能性を意味する。Tim Cook体制が「いかに普及させるか・いかに売るか」を重視していたとするなら、ターナス体制では「技術的にどこまで突き抜けられるか」が前面に出てくるかもしれない。それはイノベーションとして歓迎すべきことだが、IT管理者にとっては「また新しいカテゴリを管理しなければならない」という現実でもある。 私たちが意識すべきは、特定ベンダーの動向に一喜一憂することではなく、「自分たちのプラットフォーム戦略において、それがどう位置づけられるか」を先手で考えることだ。新CEO体制への移行は、自社のデバイス戦略を棚卸しする絶好のタイミングでもある。10カテゴリのうち何が日本市場に本格投入されるかはまだ見えないが、その答えが出る前に自分たちの方針を整理しておくことが、変化に強いIT組織の条件だと思う。 出典: この記事は John Ternus’s tenure at Apple begins with these 10 new products の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftが内部で進めていたとされる「K2」と呼ばれる秘密プロジェクトが情報流出によって明らかになった。このプロジェクトはWindows 11のパフォーマンスを大幅に改善することを目的としているとされ、長らくWindows 10との比較で「重い」と評価されてきたWindows 11にとって、ターニングポイントになる可能性を秘めている。 「K2」とは何か 流出した情報によれば、「K2」はMicrosoftが密かに進めてきたWindows 11のパフォーマンス改善プロジェクトのコードネームだ。具体的な技術的詳細はまだ限られているが、起動時間の短縮、メモリ管理の効率化、ディスクI/Oの最適化などが含まれる可能性があると見られている。 Windows 11はリリース以来、一部のハードウェアでWindows 10よりも動作が重いという報告が相次いでいた。特にビジネス環境では、ハードウェア要件（TPM 2.0必須など）に加え、パフォーマンスの問題が企業移行の足かせになっているケースも少なくない。 なぜこれが重要か 日本のIT現場では、Windows 11への移行が依然として進んでいない企業が多い。2025年10月に迎えたWindows 10のサポート終了を機に移行を進めている組織は増えているものの、「Windows 11は重い」というイメージは根強く残っている。 K2計画が実現すれば、以下のような影響が期待できる。 既存ハードウェアの延命: パフォーマンスが向上すれば、スペックギリギリのマシンでもより快適に動作する可能性がある 企業移行の促進: 「重いから移行したくない」という心理的障壁が下がる 開発者体験の向上: コンパイルやビルド処理など、CPU・ディスクI/Oに依存する作業が速くなれば開発効率に直結する 技術的背景：セキュリティとのトレードオフ Windowsのパフォーマンス改善において、特に注目されるのはカーネルレベルの最適化だ。Windows 11ではセキュリティ強化のためにVirtualization-based Security（VBS）やHypervisor-protected Code Integrity（HVCI）がデフォルト有効化されており、これがパフォーマンスのオーバーヘッドの一因となっている。 K2計画がこの領域に踏み込むとすれば、セキュリティを維持しながらパフォーマンスを取り戻す——いわば「いいとこ取り」の難しい挑戦に取り組むことになる。これは単なるチューニングではなく、OSアーキテクチャレベルの本格的な取り組みを意味する可能性がある。 実務への影響：IT管理者・エンジニアが今できること 焦らずに状況を見守る: 現時点では流出情報の域を出ていない。正式発表を待ってから移行計画に組み込むのが賢明 ベンチマークを取っておく: Windows Performance Analyzerなどで現在の環境を測定し、将来的な改善を定量的に評価できるよう準備する Windows Updateは慎重に: パフォーマンス関連の更新は副作用が出るケースもある。本番環境への適用は数日様子を見てからでも遅くない VBS/HVCIの設定を確認: セキュリティとパフォーマンスのバランスを意識した設定になっているか、この機会に見直す価値がある 筆者の見解 Windowsの細かい動向を毎回丁寧に追う必要性は年々薄れてきている、と感じていた。しかし、今回の「K2」の話は少し性質が違う。 パフォーマンスはすべてのユーザーに直接関わる根本的な問題だ。いくら機能を積み上げても、動作が遅ければ使いたくないという感情は変わらない。そしてMicrosoftには、それを正面から解決するだけの技術力が確かにある。 セキュリティ強化とパフォーマンスのトレードオフは長年の課題だが、K2がそこに真剣に向き合うプロジェクトであるなら、間違いなく正しい方向だ。「重い」というレッテルを貼られたまま次世代へ進むのはもったいない——Windowsにはちゃんと評価される実力がある。 リリース時期や詳細は依然不透明だが、今後のWindows Insider Previewビルドへの反映や正式発表に注目しておきたい。このニュースが「やっぱり話だけだった」で終わらず、現場に届く形で実を結ぶことを期待している。 出典: この記事は Microsoft’s secret “K2” plan leaks, could bring big Windows 11 performance upgrade の内容をもとに、筆者の見解を加えて独自に執筆したものです。

エネルギーや水資源の管理技術を提供する米国のユーティリティテクノロジー企業Itron, Inc.が、2026年4月13日に社内システムへの不正アクセスがあったことを、米SEC（証券取引委員会）への8-K提出書類で公表した。電力グリッド・水道・ガスネットワークと深く連携するIT企業への侵害という性質から、インフラ周辺のサイバーセキュリティに改めて注目が集まっている。 Itronとはどんな企業か Itronはワシントン州に本社を置くNASDAQ上場企業で、スマートメーターをはじめとするエネルギー・水資源管理のIT製品・サービスを提供している。従業員数は約5,600人、2025年の売上高は約24億ドル（約3,600億円）に達する。100カ国・7,700社の顧客を持ち、管理するエンドポイントは1億1,200万件という規模だ。 重要なのは、Itron自身が重要インフラ事業者ではなく、電力会社や水道局といったインフラ事業者を支えるITベンダーという立ち位置である点だ。こうした「インフラ隣接企業」は、攻撃者にとってサプライチェーン攻撃の踏み台として魅力的なターゲットになり得る。 インシデントの概要 同社は4月13日に「不正な第三者が一部のシステムにアクセスした」という通知を受けたと発表。即座にサイバーセキュリティ対応計画を発動し、外部アドバイザーを招集して調査と封じ込めを進めた。不正アクセスはすでにブロックされており、その後の追加活動は確認されていないとしている。 現時点では、顧客システムへの影響は確認されておらず、業務の重大な中断も発生していない。インシデント関連費用の多くは保険でカバーされる見込みだという。ただし調査は継続中であり、影響範囲の最終的な確定には至っていない。また、ランサムウェアグループによる犯行声明は現時点で出ていない。 SEC 8-K開示という透明性の意味 今回の事例で注目すべき点の一つが、SECへの8-K提出（重要事実の開示義務）を通じた迅速な公表だ。米国では2023年にSECがサイバーインシデントの開示ルールを強化しており、上場企業は「重大なインシデント」を4営業日以内に開示することが義務付けられている。 日本でも東証の開示ルール強化が進んでいるが、「判断が難しいから出さない」「まだ全容が不明だから待つ」という対応は今や通用しなくなりつつある。開示の遅れそのものが信頼失墜の引き金となる時代であり、「いつ・何を・どの範囲で開示するか」を平時から設計しておく必要がある。 実務への影響——日本のIT管理者・エンジニアへ 「インフラ隣接企業」のリスクを甘く見るな 「うちは重要インフラそのものではないから大丈夫」という発想は、すでに危険な過信だ。日本においても、電力・水道・交通といった社会インフラにITシステムやサービスを提供している企業は数多い。自社がどのサプライチェーンに位置し、どのような事業者と接続しているかを棚卸しすることを強く勧める。 「今動いているから大丈夫」は通用しない インシデント後も業務に支障が出なかったという事実は、「うまくやり過ごした」ではなく、「攻撃の目的が業務妨害ではなかった可能性がある」と読むべきだ。偵察目的のアクセスや、後日の攻撃に備えた足がかりの設置を排除できない。ランサムウェア声明がない点は、む しろ慎重に見るべきシグナルでもある。 ゼロトラストの観点から 侵害されたのが「内部ネットワーク」だという点は、境界型セキュリティの限界を改めて示している。「内側にいるから信頼できる」という前提が崩れたとき、横移動（ラテラルムーブメント）を食い止める手段がなければ被害は拡大する一方だ。ゼロトラストアーキテクチャへの移行と、Just-In-Timeアクセス管理の導入は、もはや「将来の検討課題」ではない。 筆者の見解 セキュリティの話は正直得意ではないのだが、今回のケースは技術的に非常に示唆に富む。 Itronの初動対応——迅速な対応計画の発動、外部専門家の招集、法執行機関への通知——は教科書どおりだ。計画を「持っているだけ」でなく「動かせた」点は率直に評価したい。SEC開示のスピードも、透明性という観点では模範的な対応だった。 ただし一点、気になることがある。ランサムウェアグループの声明がないという事実は、この攻撃が純粋な金銭目的ではない可能性を示唆している。国家関与やスパイ活動の可能性が完全に排除されていない以上、「業務影響なし・顧客影響なし」という現時点の評価が、調査の進展によって塗り替わるリスクは残る。 日本のエンタープライズが今回の事例から最も学ぶべきは、Itronのインシデント内容そのものではなく、「インシデントが起きたとき、本当に動ける計画と体制が自分たちにあるか」 という問いへの答えを持てているかどうかだと思う。準備のない企業がインシデントに直面したとき、取り返しのつかない情報が漏洩していることに気づくのは、いつだって後からだ。 出典: この記事は American utility firm Itron discloses breach of internal IT network の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Windows 11のセキュリティに関わる重要な変更が、2026年4月のアップデートで静かに入っている。Windows Securityアプリに、Secure Boot証明書の有効期限状態を視覚的に確認できる新UIが追加されたのだ。6月という期限まで残り約2ヶ月。把握していないシステム管理者は今すぐ確認したい。 Secure Bootとは、なぜ証明書が重要なのか Secure Bootは、PCの起動時にデジタル署名を検証し、正規のブートローダーとOSのみを実行させるセキュリティ機能だ。Windowsが読み込まれる前の段階で悪意あるソフトウェア（ブートキット・ルートキット）の侵入を防ぐ、セキュリティの最初の防壁といえる。Windows 11はSecure Bootを必須要件としており、すべてのWindows 11デバイスが影響を受ける。 このSecure Bootの正常動作に必要なデジタル証明書が、2026年6月に有効期限を迎える。Microsoftは以前から告知してきたが、対応確認の手段がPowerShellコマンドという、一般ユーザーには敷居が高い方法だった。 4月アップデートで何が変わったか 今回追加されたのは、Windows Securityアプリ内でSecure Bootの証明書状態を一目で把握できるUIだ。 確認手順はシンプルだ。Windowsの検索バーに「Windows Security」と入力して起動し、「デバイスセキュリティ」→「セキュア ブート」のセクションを確認する。 表示されるメッセージで状態がわかる： 「Secure Bootが有効になっています。起動時に悪意のあるソフトウェアが読み込まれないよう保護されています」 → 証明書は最新。6月以降も問題なし 「Secure Bootは有効ですが、更新が必要な古い起動信頼構成を使用しています」 → 証明書がまだ古い状態。更新が必要 従来はPowerShellで証明書ストアを直接確認するしかなかったが、このUIによって技術的な知識がないユーザーでも状態確認が可能になった。 証明書の更新方法 証明書の更新は、Windows Updateを通じて自動的に適用される。Microsoftは6月までに対象のすべてのWindows 11 PCへ証明書アップデートを配布する予定だ。 対応のために確認しておくべきこと： 自動更新を有効にする — Windows Updateが手動になっている環境では、自動更新へ切り替えるか、定期的な手動更新を確実に実施する 診断データの送信を許可する — 「設定 > プライバシーとセキュリティ > 診断とフィードバック」から有効化。システムが適切な証明書を判断するために使われる Microsoftは今後、5月のPatch Tuesdayまでにさらなる通知機能の追加も予定しており、セキュリティ可視化の強化が続く見込みだ。 日本のIT現場への影響 日本の企業環境で特に注意したいのは、WSUSや社内パッチ管理ツールを使用している環境だ。自動更新を意図的に無効化し、管理された手順で更新を適用している場合、担当者がこの証明書アップデートを認識していないと、6月以降に問題が表面化する可能性がある。 個人ユーザーは自動更新を有効にしていれば基本的に問題ないが、企業の管理者は以下を今すぐ確認しておきたい： 管理下のWindows 11デバイスで証明書の状態を把握しているか パッチ管理の仕組みが、この証明書更新を適切に配信するよう設定されているか エンドユーザーがWindows Securityのメッセージを見たとき、自己対処または問い合わせができる案内が整備されているか 「今起動できているから大丈夫」という判断は、このケースでは通用しない。証明書の有効期限は静かにカウントダウンしている。 筆者の見解 率直に言って、今回の変更は正しい方向性だと思う。セキュリティ情報をエンドユーザーが視認できる形で提供する姿勢は評価したい。PowerShellを叩けなければ状態確認できません、では守れるものも守れない。 ただ、もう少し早くこのUIを用意しておいてほしかった、というのが正直なところだ。6月の期限が迫ってからの追加では、周知が行き届かないデバイスが出てくる可能性を否定できない。証明書管理は本質的に「気づいたときには期限切れ」になりやすい性質を持っている。 それでも、こうした「ユーザーが状態を把握できる仕組み」を積み重ねていくことには意義がある。セキュリティはわかりにくいから避けられる、という構造を少しずつ変えていく取り組みとして、引き続き注目していきたい。この調子で、セキュリティの可視化をもっと積極的に進めてほしいと思う。 出典: この記事は Windows 11 now shows if your Secure Boot certificates are ready for June の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Microsoft Teamsを通じたヘルプデスクなりすまし攻撃が、新たなフェーズに入った。Google傘下のセキュリティ機関Mandiantは、脅威グループ「UNC6692」が独自開発のマルウェアスイート「Snow」を用いた標的型攻撃を展開していることを報告した。メール爆撃→Teamsなりすまし→マルウェア展開→Active Directory奪取という一連の攻撃チェーンは、組織の信頼構造そのものを武器に使う。 攻撃の全体像——4段階で組織を内側から崩す 攻撃は「メール爆撃（email bombing）」から始まる。標的に大量のスパムメールを送りつけて混乱させ、「スパムをブロックするパッチがある、サポートに連絡を」という心理的誘導を作り出す。そこに現れるのが、Microsoft Teams上でIT担当者を装った攻撃者だ。 被害者はパッチのインストールリンクをクリックするよう誘導される。実際に実行されるのはドロッパーであり、AutoHotkeyスクリプト経由で悪意あるChromeエクステンション「SnowBelt」がロードされる。この拡張はヘッドレスのMicrosoft Edgeインスタンス上で動作するため、被害者の画面には何も表示されない。同時にスケジュールタスクとスタートアップフォルダへのショートカットが作成され、再起動後も継続する。 Snowスイートの3層構造 「Snow」は互いに連携する3つのコンポーネントで構成されている。 SnowBelt（Chromeエクステンション）: 持続性の確保と、オペレーターからのコマンドをバックドアへ中継する役割を担う。 SnowGlaze（トンネラー）: WebSocketトンネルを確立してC2（コマンド＆コントロール）インフラとの通信を隠蔽する。さらにSOCKSプロキシ機能により、感染ホストを経由した任意のTCPトラフィックのルーティングも可能にする。 SnowBasin（Pythonバックドア）: ローカルHTTPサーバーを起動し、CMDまたはPowerShellコマンドを実行する。リモートシェルアクセス、データ窃取、スクリーンショット取得、ファイル管理、さらに自己消滅コマンドをサポートする。 侵害後の動き——Active Directoryの完全掌握へ マルウェア展開後、攻撃者はSMBやRDPをスキャンして内部偵察を開始する。LSASS（Local Security Authority Subsystem Service）メモリのダンプで認証情報を抜き出し、パス・ザ・ハッシュ（Pass-the-Hash）で横移動を実行、最終的にドメインコントローラーへ到達する。 侵害の締めくくりとして、フォレンジックツール「FTK Imager」を使ってActive Directoryデータベース（NTDS.dit）とSYSTEM/SAM/SECURITYレジストリハイブを抽出。これによりドメイン全体の認証情報が攻撃者の手に渡る。 実務への影響——日本のIT管理者が今すぐ確認すべき5点 この攻撃が厄介なのは、Teamsという正規のコミュニケーション基盤を入り口として使う点だ。「知らない番号からの電話」なら警戒できるが、日常的に使うTeamsのチャットは心理的な防衛が薄れやすい。 Teamsの外部アクセスポリシー見直し: 外部組織・未管理デバイスからのTeamsチャット要求を制限する。テナント設定で外部ドメインのアクセスを許可リスト管理に切り替える Quick Assist・リモートアクセスツールの制御: Intuneまたはグループポリシーで、IT部門承認のない遠隔操作ツールの実行をブロックする LSASS保護の強化: Windows Credential GuardおよびLSASS Protected Process Light（PPL）を有効化する IoCs・YARAルールの展開: Mandiantが公開しているインジケーターをSIEMおよびEDRに投入して検知ルールを更新する 特権アカウントのJust-In-Time管理: 常時付与されたドメイン管理者権限は、侵害時の被害を指数的に拡大する。Microsoft Entra Privileged Identity Management（PIM）を活用した時限付き昇格に切り替えることを強く推奨する 筆者の見解 今回の攻撃が示しているのは、「信頼されているもの」が最も危険な攻撃ベクターになるという現実だ。Teamsは組織のコミュニケーション基盤として深く根付いており、だからこそ攻撃者にとって「最も疑われにくい入り口」になっている。 ゼロトラストの文脈では、これは教科書通りの事例だ。「社内ツールだから安全」「IT担当者からの連絡だから信頼できる」という前提が崩れたとき、ネットワーク境界だけを守る従来型のモデルはほぼ無力になる。認証・認可・デバイス状態を常時検証する構えがなければ、この手口を正面から止めることはできない。 LSASSダンプからのパス・ザ・ハッシュ、FTK Imagerによるドメインデータベース抽出——どれも既知の技術だ。それでもこの攻撃が成立するのは、多くの組織でいまだ「特権アカウントが常時使える状態」になっているからだ。Just-In-Timeアクセスと最小権限の徹底だけで、侵害後の横展開は大幅に制限できる。 MicrosoftはTeamsのセキュリティ強化を継続しており、今回のような手口を自ら積極的に警告していることは評価したい。防御オプションをもっとデフォルトで安全側に倒してくれれば、それだけで救われる組織が相当数ある。設定を知っている管理者だけが守られる状況は、そろそろ卒業してほしいところだ。 出典: この記事は Threat actor uses Microsoft Teams to deploy new “Snow” malware の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Windows 11標準搭載の「Notepad（メモ帳）」から、「Copilot」という名称が姿を消した。2026年4月26日、この変更がMicrosoftストア経由で一般ユーザー向けへの展開が完了したことが確認された。新しい名称は「Writing Tools（ライティングツール）」。ただし、AI機能そのものは継続して提供されており、実態は「ブランド名の変更」だ。 「Copilot」の看板を下ろした背景 Microsoftは2026年3月20日、Windows 11への大規模な方針変更を発表した際、「Copilotのプレゼンスをより意図的に管理する」と宣言し、Snipping Tool・Photos・Widgets・Notepadを例に挙げて「不要なCopilotエントリーポイントを削減する」と明言した。 今回のNotepadの変更はその方針に沿ったものだ。UIからは「Copilot」という文言が完全に取り除かれ、機能説明も「Smarter writing tools（よりスマートなライティングツール）」という表現に刷新された。テキストを選択すると「書き直し（Rewrite）」「要約（Summarise）」「新規テキスト生成（Write）」へのアクセスが可能であることは変わらない。 MicrosoftはWriting ToolsがAIによって動作していることを、機能起動時に一応開示している。ただし、UIの主要な箇所からAIであることへの言及は大きく後退している。 Snipping ToolはAI機能ごと削除 対照的に、Snipping Tool（切り取りツール）はより踏み込んだ対応を取った。AI統合そのものが完全に削除され、Copilotボタンも一般チャンネルのユーザーには表示されなくなった。 NotepadがAI機能を維持しつつブランドだけを変えたのに対し、Snipping Toolはシンプルさを優先してAI機能ごと取り除くという、異なる判断をした。この2つのアプリの扱いの差が、今回の方針変更の本質を物語っている。 なぜ今、Copilotブランドを縮小するのか 「Copilot」の名称がWindowsの標準アプリに広く展開されて以来、ユーザーからは「本当に使いたい場面で役立たない」「押しつけがましい」という声が増えていた。Microsoftは今回の変更で、AI機能が「本当に価値を発揮できる場所」に絞り込む姿勢を示している。 なお同社は今後、タスクバーへのAIエージェント追加も計画中であり、WindowsからAIを撤退させる意図は一切ない。方針は「縮小」ではなく「選択と集中」だ。 実務への影響 企業のIT管理者にとって、今回の変更の実務インパクトは軽微だ。AI機能はSettings（設定）から引き続きオン・オフが可能であり、グループポリシーやMDMポリシーで制御している場合も挙動に変化はない。 注意点が一つある。社内向けのマニュアルや教育資料に「NotepadのCopilot機能」を記載していた場合、名称を「Writing Tools」に更新する必要がある。ヘルプデスクへの問い合わせが増える可能性も念頭に置いて、先手で周知しておきたい。 エンドユーザー視点では、「Copilot」というブランドに抵抗感を持っていた層が、「Writing Tools」という機能本位の名称の下でAI支援の文章編集を自然に使い始める可能性がある。機能の実態は変わっていないが、名称の変更が心理的ハードルを下げることはある。 筆者の見解 正直に言えば、今回の変更は「もったいない」という印象だ。 AI機能が本来持つ価値を損なっていた要因のひとつは、「Copilot」というブランドが実力以上に広げられすぎた結果、ユーザーの期待と現実がかけ離れてしまった点にあると思う。名称を「Writing Tools」に変えることで機能の実態を素直に伝えようとする姿勢は評価できる。Snipping Toolでの完全削除も、使われない機能を抱えるよりシンプルさを優先した判断として正しい。 ただ、名前を変えるだけでは根本的な課題は解決しない。MicrosoftにはAI統合を本当に輝かせるポテンシャルがあるし、そのための技術力もブランドも持っている。ユーザーが「AIのおかげで作業がはかどった」と実感できる場所を見極め、そこに力を注ぐことが今後の課題だ。今回の「整理」が、より良い体験への布石になることを期待したい。 Windowsの標準アプリにおけるAI体験の再整備は始まったばかりだ。今後の展開で、ブランド変更だけでなく実質的な使い勝手の向上が伴うかどうかが、真の評価軸になるだろう。 出典: この記事は Microsoft drops Copilot branding in Notepad for Windows 11 for everyone, but it’s really just a rename の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Windowsのアンチウイルス機能「Windows Defender」に存在する3つの深刻な脆弱性が、実際の組織への侵害に悪用されたことが確認された。注目すべきはその速度だ——PoCコード（実証コード）が公開されてからわずか5日で野生での攻撃が観測されている。パッチが存在しない脆弱性が2件残っている現時点でも、攻撃は進行中の可能性がある。 今回確認された3つの脆弱性 セキュリティ研究者「Chaotic Eclipse」が今月、自身のブログおよびGitHubに3つのWindows Defender脆弱性のPoC（実証コード）を順次公開した。 BlueHammer：Microsoftが今週パッチをリリース済み。ただし悪用は既に確認されている UnDefend：未パッチ。PoC公開済み RedSun：未パッチ。PoC公開済み 3件いずれも、Windows Defenderを経由して攻撃者が管理者権限を取得できる欠陥とされている。サイバーセキュリティ企業Huntressは、少なくとも1つの組織への実際の侵害を確認し、「BeigeBurrow」と呼ばれるトンネリングエージェントが展開されたことを報告している。 Full Disclosure——なぜ研究者はコードを公開したのか Chaotic Eclipseは公開の動機として、MicrosoftのセキュリティレスポンスチームであるMSRC（Microsoft Security Response Center）との対立を示唆するコメントを残している。「Microsoftをはったりで脅したわけではない、また実行する」という趣旨の投稿も見られた。 本来、脆弱性が発見された際には「協調的開示（Coordinated Disclosure）」が業界標準だ。研究者がベンダーに報告し、修正完了後に公開する——このプロセスが機能していれば、ユーザーが脆弱なまま放置されるリスクは大幅に下げられる。しかし今回のようにそのプロセスが崩れると、PoCコードがGitHubに公開された瞬間に悪用のハードルが劇的に下がる。 攻撃者にとって、GitHubに上がっているPoCは「すぐ使える武器」だ。高い技術力がなくても、コードをそのまま実行するだけで侵害が可能になる。これが今回5日以内で実害につながった直接の理由だ。 日本企業が今すぐとるべき対応 1. BlueHammerのパッチを即適用 Microsoftがすでにパッチをリリースしている。Windows Updateの適用状況をエンドポイント管理ツール（Intune、WSUS等）で即座に確認すること。「しばらく様子を見てから」では遅い。 2. UnDefend・RedSunへの緩和策を検討 パッチが存在しない以上、ネットワーク分離、特権アカウントのJust-In-Time管理、エンドポイントの行動ベース検知といった緩和策が現実的な選択肢になる。Huntressなど各セキュリティベンダーのアドバイザリを参照してほしい。 3. BeigeBurrowの痕跡を監視 不審な外部通信やプロセス起動パターンをSIEM等で検知できているかを確認する。侵害が成功してもトンネリングエージェントの挙動を捕捉できれば被害を最小化できる。 4. パッチ適用プロセスの優先度設計を見直す 月次パッチサイクルという組織は多いが、今回のように5日で悪用が始まるケースには対応できない。「PoC公開済み」「悪用確認済み」といったリスク分類をトリガーに、緊急パッチの適用フローを事前に設計しておくことが必要だ。 筆者の見解 MSRCはWorldクラスの脆弱性対応能力を持つ組織だ。BlueHammerのように迅速にパッチをリリースできる力があることは今回も示された。だからこそ、残るUnDefendとRedSunの対応が急がれる。研究者との対立がどのような経緯であれ、現在進行形で攻撃が行われている以上、正面から勝負する場はここだ。 より根本的な問題として、今回の件は「パッチが出てから当てる」という受け身の防御モデルの限界を改めて示している。PoCが公開されれば48時間以内に武器化されるのが今の現実であり、パッチ適用サイクルが週次・月次の組織では構造的に間に合わない。 多層防御——特権アカウントのJIT管理、エンドポイントの行動検知、ネットワーク分離——をあらかじめ組み合わせておく設計が不可欠だ。Huntressの研究者が言うように「防御者とサイバー犯罪者の綱引き」が続く以上、日本企業に必要なのはその綱引きに参加するための平時の「筋力」を積み上げておくことに尽きる。 出典: この記事は Hackers are abusing unpatched Windows security flaws to hack into organizations の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoft Teamsの通訳AIエージェント「Interpreter」に、新たな逐次通訳（Consecutive Interpretation）モードが追加された。既存の同時通訳モードとの使い分けが可能になり、日本企業のグローバル会議における言語バリア解消に向けた選択肢が広がった。 逐次通訳と同時通訳——何が違うのか 通訳には大きく2つのスタイルがある。 同時通訳（Simultaneous Interpretation）は、話者が話している最中に並行して翻訳を行う。タイムラグが最小で会議のテンポを保てる一方、文脈を追いながらリアルタイムで処理するため、専門用語や複雑な文構造では精度が落ちやすい。国連など大規模な国際会議で使われるスタイルだが、実はプロの通訳者でも最も負荷が高い形式だ。 逐次通訳（Consecutive Interpretation）は、話者がひと区切り話し終えてから翻訳する。若干の間が生まれるが、発言全体の文脈を把握してから翻訳できるため、精度が高い。技術的な仕様確認、契約文書の読み合わせ、医療・法務・金融といった専門性の高い分野で特に威力を発揮する。 Teams Interpreterは今回この逐次通訳モードを追加したことで、会議の性質に応じたモード選択ができるようになった。 なぜこれが重要か Teams Interpreterが登場した当初から、現場ユーザーの間では「便利だが精度が不安」という声が多かった。とりわけ日本企業の実務では、グローバルな製品仕様の議論や、海外ベンダーとの技術要件確認といった場面で「同時通訳のラグとニュアンスのずれ」が課題になっていた。 逐次通訳モードはこのギャップを埋める。特に以下のシナリオで有効だ。 製品仕様・設計レビュー会議: 固有名詞・技術略語が多く、文脈理解が翻訳精度に直結する RFP対応・ベンダー交渉: 曖昧なまま進むと後工程でコストが跳ね上がる コンプライアンス・法務確認: 一言一句の正確性が求められる場面 一方、日次スタンドアップや軽いステータス報告なら、テンポを重視して従来の同時通訳モードで十分だ。 実務での活用ポイント モードの使い分けルールをチームで決める 会議招集時のアジェンダにモード指定を入れておくと混乱が減る。たとえば「技術確認→逐次通訳、進捗共有→同時通訳」と明記するだけで運用がスムーズになる。 AIと人間の補完関係を意識した前準備 逐次通訳モードでも、業界特有の略語やプロジェクト固有の用語は誤訳リスクが残る。会議前にTeamsのチャットへ用語集を貼る、あるいは議題資料を事前共有するといった一手間が、AIの精度を引き上げる現実的な方法だ。 多言語展開の見極め 対応言語ペアは随時拡充されているが、自社で使いたい言語の組み合わせが含まれているかは必ず事前に確認しておくこと。日英以外の言語ペアを必要とする拠点を抱える企業は特に注意が必要だ。 ライセンス・展開要件の確認 Interpreter機能はTeamsのどのライセンスで利用できるかが変動しやすい。テナント管理者はTeams管理センターで現在の利用可能状況を確認し、必要なら展開ポリシーを設定しておこう。 筆者の見解 このアップデート、地味に見えて実はかなり重要な一手だと思っている。 TeamsのAI機能はここ最近Copilotを前面に出した訴求が多いが、「会議の議事録を要約する」より「会議そのものの言語バリアを取り除く」方が、根本的なビジネス価値は高い。特に地方企業や中小企業では英語話者がいない中でグローバル調達や海外パートナーとのやり取りを求められるケースが増えており、専任の通訳者を雇うコストをかけずに精度の高い通訳ができる環境は切実なニーズだ。 逐次通訳モードという設計が示しているのは、「AIは速くて便利なだけでなく、使い方のバリエーションで精度をコントロールできる」という思想だ。全部を同じモードで処理しようとするのではなく、場面に応じて最適なモードを選ぶ——この発想は実務に根ざしている。 Teams Interpreterがさらに進化し、より多くの言語ペアと精度向上が重なれば、グローバル会議の標準インフラとして定着する可能性は十分ある。引き続き現場での活用事例を積み重ねながら、機能の成熟を見守っていきたい。 出典: この記事は Microsoft brings new ‘consecutive interpretation’ mode to Interpreter in Microsoft Teams の内容をもとに、筆者の見解を加えて独自に執筆したものです。

ホームセキュリティ大手ADTが、ShinyHuntersによるデータ流出脅迫を受けて侵害を公式に認めた。攻撃の起点となったのは、音声フィッシング（ヴィッシング）によるOkta SSOアカウントの乗っ取りだ。「ネットワーク境界を守っていれば安全」という時代はとっくに終わった——このインシデントは、そのことをまた一度突きつけている。 何が起きたのか 2026年4月20日、ADTはシステムへの不正アクセスを検知し、即座に遮断と調査に乗り出した。流出した情報は氏名・電話番号・住所が中心で、一部には生年月日や社会保障番号（SSN）の下4桁も含まれていたとされる。一方で支払い情報（銀行口座・クレジットカード）はアクセスされておらず、顧客の防犯システム自体も影響を受けていないという。 ShinyHuntersは自身のリークサイトに「1,000万件以上の個人情報と内部企業データを取得済み」と掲載し、4月27日までに支払いがなければ公開すると脅迫している。ADT側は件数については確認していない。なお、ADTは2024年8月・10月にもデータ侵害を開示しており、今回が3件目となる。 攻撃のメカニズム：ヴィッシング＋SSOの組み合わせが凶器 ShinyHuntersが語ったとされる攻撃手口はシンプルで、だからこそ恐ろしい。 ヴィッシング（電話による音声フィッシング） で従業員のOkta SSOアカウントを侵害 そのSSOアカウントを使い、連携しているSalesforceインスタンスにアクセス データを窃取し、身代金を要求 この手口はADTだけの話ではない。ShinyHuntersはここ1年以上、Microsoft Entra・Okta・Google SSO を標的にした広範なヴィッシングキャンペーンを展開している。一度SSOアカウントを奪えば、そこに連携されたSalesforce・Microsoft 365・Google Workspace・SAP・Slack・Atlassian・Dropboxといった主要SaaSを一網打尽にできる。 「SSO＝ひとつの鍵で全部の部屋が開く」という構造的な脆弱性が、ここに顕在化している。 なぜこれが重要か：日本のIT現場への影響 日本企業も同じ構造を抱えている。Okta・Microsoft Entra IDを中心としたSSOは国内でも急速に普及しており、そこに多数のSaaSが連携されている環境は珍しくない。 より深刻なのは、日本の大手エンタープライズに多く見られる「古いセキュリティモデルとゼロトラストの中途半端な融合」だ。境界防御の考え方が残ったまま、SSOだけゼロトラスト的に導入する——これがアカウント侵害時の被害を最大化する。ネットワーク境界を通過したアカウントに対し「内側の人間だから信頼できる」という暗黙の前提が残っていれば、侵害されたSSOアカウントは最強の攻撃ツールになる。 実務での活用ポイント 1. フィッシング耐性のある多要素認証（MFA）へ移行する SMS・音声コードベースのMFAはヴィッシングに脆弱だ。FIDO2／パスキー（YubiKeyやWindows Helloなど）への移行を優先的に検討する。Microsoft Entra IDであれば「認証強度」ポリシーでフィッシング耐性MFAを強制できる。 2. 条件付きアクセスで「不審なサインイン」を弾く Microsoft Entra・Oktaいずれも、リスクベースの条件付きアクセスポリシーが使える。通常と異なる場所・デバイス・時間帯からのアクセスには追加認証を要求する設定を入れておく。 3. Just-In-Timeアクセスを徹底する 「常時アクセス権を付与している状態」は特権アカウント管理における最大のリスクだ。特権アカウントはもちろん、SaaS連携アカウントについても、必要なときだけ・必要な権限だけを付与するJIT（Just-In-Time）アクセスの考え方を導入する。 4. SSO連携先SaaSのアクセスログを一元監視する Salesforce・M365・Slack等、SSOで連携されているSaaSのアクセスログを統合監視できる体制を作る。SIEM統合が難しければ、まず主要SaaSにアラートルールを設定するところから始める。 5. ヴィッシング訓練をセキュリティ教育に組み込む フィッシングメール訓練はやっていても、「電話でのなりすまし」訓練を実施している企業は少ない。「IT部門・セキュリティ部門を名乗る電話」に対して従業員が検証手順を持てるよう、シナリオ訓練を追加することを検討してほしい。 筆者の見解 ADTのケースで特に注目すべきは、「セキュリティ製品が足りなかった」という話ではなく、「正規のSSOアカウントそのものが攻撃の凶器になった」という点だ。 現代の攻撃は、脆弱性を突くより「人間を騙す」方が圧倒的に効率がいい。ヴィッシングで従業員一人を誘導し、Okta／Microsoft Entraのアカウントを奪えば、あとは連携SaaSを漁るだけ。高度なマルウェアもゼロデイ脆弱性も要らない。 ゼロトラストは「ネットワーク内にいるから安全」という前提を捨てることが出発点だ。しかしアカウントベースの認証を信頼しすぎてしまえば、そのアカウント自体が攻撃ベクターになる。「ネットワーク層を疑う」だけでなく「認証された正規ユーザーの挙動も疑う」——行動分析・リスクベース認証・JITアクセスの組み合わせが、現時点での現実的な答えだと考えている。 ADTは今回で3度目の侵害だ。同じ組織が繰り返して被害を受けるのは、根本的なアーキテクチャが変わっていない可能性を示唆している。「なんとなく直した」止まりでは、攻撃者は何度でも同じドアをノックしてくる。この轍は、他の組織が踏む前に踏まないための格好の教材だ。攻撃者は毎回同じ手口を使う。同じ手口で何度もやられることほど、もったいないことはない。 出典: この記事は ADT confirms data breach after ShinyHunters leak threat の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftが Windows Insider Program の構造を大きく見直した。2026年春、従来の Dev・Canary という2系統の「先行チャンネル」体制に加え、新たに Experimental（実験的プレビュー）チャンネル が設立され、その第1号ビルドが公開された。単なる名称変更ではなく、「テストの哲学」そのものの再設計だ。 階層構造の再定義——どのチャンネルが何を担うのか これまでの Windows Insider は大まかに以下の4層で運用されていた。 チャンネル 位置付け Canary 最先端・壊れる可能性あり Dev 安定寄りの先行機能 Beta リリース候補に近い機能 Release Preview 最終確認段階 今回の刷新で、Canaryの「さらに上」に Experimental が新設された。Canaryでさえ躊躇されてきた破壊的・試験的な変更——UI の抜本的な再設計、カーネルレベルのアーキテクチャ変更など——をここに集約する方針だ。Canaryは相対的に「実験寄りながらも継続的に使えるビルド」として位置付けが整理されることになる。 初の Experimental ビルドに含まれる変更 第1号ビルドは、新チャンネルの「テストベッド」としての性格を明確にする内容になっている。具体的には、シェルやタスクバー周りの新しい UI コンセプト、スタートアップや電源管理に関わる低レイヤーの変更が含まれる。機能として「使える」というより、「方向性を確かめる」ためのビルドという色合いが強い。 Microsoft は公式に「Experimental ビルドは日常利用を前提としない」と注意書きしており、参加には覚悟が必要だ。メインマシンに入れるのは推奨されず、仮想マシンや専用ハードウェアでの検証が求められる。 なぜこれが重要か——「試験の責任の所在」が変わる 表面上は「チャンネルが増えた」だけに見えるが、本質的な意義はもっと深い。 これまで Canary は「壊れる可能性がある」と言いながらも、実態としては多くの機能が本番 Windows に近い水準で提供されていた。結果として「Canary は壊れる」という前提がいつしか形骸化し、大きな変更を出すときにためらいが生じていた側面がある。 Experimental チャンネルを設けることで、本当に「壊れていい」空間 が明示的に確保された。これにより Canary と Dev のビルド品質が安定しやすくなり、企業の IT 部門が先行評価に使いやすくなる効果も期待できる。 実務への影響——日本のIT管理者が知っておくべきこと すぐ Experimental に参加する必要はない。 ただし、以下のシナリオでは注目する価値がある。 ゼロトラスト移行を検討中の組織: 低レイヤーの認証・ID 管理に関わる変更が Experimental に先行投入される可能性があり、早めに動向を把握できる 標準イメージ管理担当者: 新チャンネルの変更が Dev → Beta へ降りてくる前にパターンを掴んでおくと、展開計画の精度が上がる セキュリティ担当者: カーネルドライバーの扱いやブート周りの変更は Experimental で先行テストされることが増えそうで、セキュリティ影響の早期把握に使える Experimental が「人柱」を公式に引き受ける場になるということは、Dev と Beta の信頼性向上に直結する。管理者としては「Beta の品質が上がる」という恩恵を受ける形になるはずだ。 ...