Windows

ウクライナのCERT（CERT-UA）が2026年4月、地方政府機関や病院を標的にした新たなマルウェアファミリー「AgingFly」を特定した。このマルウェアの最大の特徴は、コマンドハンドラーをあらかじめ実行ファイルに内蔵せず、C2サーバーからC#ソースコードを受け取って実行時に動的コンパイルするという構造にある。ハッシュ・シグネチャベースの静的検知を大きく困難にする設計であり、遠い国の話として流せない技術的示唆を多く含んでいる。 攻撃チェーンの全貌 攻撃の起点は「人道支援のオファー」を装ったフィッシングメール。リンクをクリックすると、XSS脆弱性を突いて侵害された正規サイト、またはAIツールで生成された偽サイトへ誘導される。 被害者がダウンロードするアーカイブにはLNKショートカットが含まれており、HTA（HTMLアプリケーション）ハンドラーを起動。HTAはリモートリソースからさらなるHTAを取得・実行し、デコイフォームで注意をそらしながら、スケジュールタスクでEXEペイロードを正規プロセスにインジェクションする。その後、XOR暗号化されたTCPセッションでC2サーバーに接続し、AgingFly本体が展開される。 AgingFlyの技術的特徴——動的コンパイルによる検知回避 C#で実装されたAgingFlyは、リモートコントロール・コマンド実行・ファイル窃取・スクリーンショット・キーロガー・任意コード実行といった機能を持ち、WebSocket経由（AES-CBC暗号化）でC2サーバーと通信する。 注目すべきはコマンドハンドラーの動的コンパイルだ。従来のマルウェアは機能を実行可能ファイルに埋め込むが、AgingFlyはC2から受け取ったC#ソースコードをホスト上でその場でコンパイルして実行する。これにより： 初期ペイロードを小さく保てる 機能を必要に応じてオンデマンドで追加・変更できる ハッシュ・シグネチャベースの静的検知をほぼ無効化できる 一方で、この手法はC2への常時接続依存、実行時のフットプリント増加、コンパイル動作による挙動検知リスクという弱点も抱える。つまり、EDR（Endpoint Detection and Response）による行動監視は依然として有効な対抗手段だ。 認証情報窃取に悪用されるオープンソースツール AgingFlyの前段階では、オープンソースのセキュリティツールが認証情報窃取に流用されている： ChromElevator：Chromiumベースブラウザ（Chrome、Edge、Brave）の保存パスワードやCookieを管理者権限なしで復号・抽出できるツール ZAPiDESK：WhatsApp for Windowsのデータベースを復号してメッセージ等を取り出すフォレンジックツール さらに、C2サーバーのアドレスをTelegramチャンネルから取得するPowerShellスクリプト「SILENTLOOP」が使われており、Telegramを指令インフラの中継に使う手法は単純なC2ドメインブロックが効きにくい理由でもある。横展開にはRustScanポートスキャナー、Ligolo-ng・Chiselトンネリングツールが使われ、初期侵入後に素早く内部探索が進む。 実務への影響 日本の組織がこの攻撃パターンから学ぶべき点は3つある。 1. LNK / HTA / JSファイルの実行制限 CERT-UAが推奨する通り、グループポリシーやAppLockerでこれらのファイルタイプの実行を制限することが最も効果的な初期侵入対策の一つだ。メールやWebからのダウンロードに対して、ファイルタイプでの実行制御は今すぐ実施できる低コスト対策だ。 2. ブラウザ認証情報の保存を見直す ChromElevatorに代表される手法は、管理者権限なしでも実行可能という点が重大だ。エンタープライズ環境では認証情報を専用のシークレット管理基盤や条件付きアクセスと連携したパスワードレス認証に移行することを強く推奨する。 3. WhatsApp for Windowsを業務利用している環境への注意 業務コミュニケーションにWhatsAppを用いている組織は、そのローカルデータが標的になりうることを認識する必要がある。特に規制業種では業務チャットの管理ポリシーと保存場所の整備が急務だ。 筆者の見解 AgingFlyが示す最も重要なシグナルは、「静的検知の限界」だ。コマンドハンドラーを動的コンパイルするアプローチは、従来のシグネチャ型アンチウイルスをほぼ無力化する。「セキュリティ製品を入れてあれば大丈夫」という感覚では通用しない時代に確実になっている。 もう一点引っかかるのが、オープンソースツールの流用だ。ChromElevatorもZAPiDESKも本来はセキュリティ研究・フォレンジック目的のツールだが、それが攻撃インフラの一部として使われている。「今動いているから大丈夫」では済まない現実を改めて突きつけられる。 そして見逃せないのが、Telegramをインフラとして使うという点だ。正規のクラウドサービスを踏み台にする手法は、従来のネットワーク境界防御では根本的に検知が難しい。これこそがゼロトラストアーキテクチャが必要な理由の一つであり、「ネットワーク内にいるから信頼する」という前提の危うさを改めて示している。 最終的に防御側が強みにできるのは、行動ベースの異常検知と、認証・認可の厳格化だ。「常時アクセス権の付与」をやめてJust-In-Timeアクセスに移行し、初期侵入を阻止できなかった場合でも横展開を封じる多層防御の構築が、これからのセキュリティ運用の基本線になる。このウクライナでの攻撃事例を、自組織の設計を見直すきっかけにしてほしい。 出典: この記事は New AgingFly malware used in attacks on Ukraine govt, hospitals の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Nginx の管理UIとして広く利用されている「Nginx UI」に、認証なしでサーバーを完全乗っ取りできる致命的な脆弱性（CVE-2026-33032）が発見され、すでに実際の攻撃に使われていることが確認された。430,000件以上のDockerプル実績を持つ人気ツールだけに、影響範囲は決して小さくない。 何が起きているか——MCPエンドポイントが丸裸に Nginx UIはバージョン2系からAIワークフロー連携を想定してModel Context Protocol（MCP）をサポートしているが、その実装に根本的な設計ミスが含まれていた。/mcp_message エンドポイントに対してまったく認証が掛かっておらず、ネットワークさえ到達できれば誰でも特権的なMCPアクションを呼び出せる状態になっていた。 具体的な攻撃手順はシンプルで恐ろしい。 対象のNginx UIインスタンスにSSE（Server-Sent Events）接続を確立する MCPセッションを開き、返却される sessionID を取得する その sessionID を使って /mcp_message に任意のリクエストを送る これだけで、認証ヘッダー一切なしに12種類のMCPツール（うち7種は破壊的操作）が使い放題になる。Nginx設定ファイルの読み取り・改ざん・削除、悪意ある server ブロックの注入、設定リロードのトリガーまで、サーバー管理として想定されるあらゆる操作が外部から可能だ。 タイムラインと現在の状況 日付 出来事 2026年3月14日 Pluto Security AIが発見・報告 2026年3月15日 バージョン2.3.4で修正リリース 2026年3月末 CVE番号・技術詳細・PoCが公開 2026年4月第1週 バージョン2.3.6リリース（現在の最新安定版） 2026年4月15日 Recorded Futureが野外での積極的悪用を確認 Shodanによるスキャンでは現在も約2,600インスタンスが公開状態でインターネットに露出している。地域別では中国・米国・インドネシア・ドイツ・香港が多いが、国内のサーバーも無関係ではない。 なぜこれが重要か——AIプロトコルと特権操作の組み合わせ この脆弱性が単なる「Webアプリの認証バイパス」と根本的に異なる点は、MCPという「AI統合用プロトコル」が特権管理操作と直結していたことだ。 MCPはもともとAIエージェントがツールを呼び出すための通信規格として設計されている。便利だからこそ多機能で、だからこそ今回のように「便利なツール群」が認証なしで露出した場合のダメージが甚大になる。AIと連携できるサーバー管理ツールは今後も増えていくが、その認証・認可設計が追いついていないケースが続出する予感がある。 実務への影響——日本のエンジニア・IT管理者が今すぐやること 即時対応 nginx-ui --version でバージョンを確認する 2.3.6未満であれば即座にアップデートする（docker pull uozi/nginx-ui:latest または公式リリースページから） アップデートが即時困難な場合は、/mcp_message エンドポイントをファイアウォール・リバースプロキシのACLで一時的にブロックする 中期的な対策 Nginx UIをインターネットに直接公開しているなら、まずそれを止める。管理系UIはVPN・踏み台・Private Endpoint越しにアクセスする構成が正しい Docker Composeで動かしている場合、ポートバインディングを 127.0.0.1:80 のようにループバックに限定しているか確認する 設定変更のログを定期的にレビューするか、変更検知の仕組みを入れる 将来を見据えた設計 MCPや類似のAI統合プロトコルを導入する際は「エンドポイントごとの認証スコープ」を設計段階で明確にする。後付けは難しい 特権操作を行うAPIは必ずゼロトラスト原則で設計する。「内部ネットワークだから安全」という前提は捨てること ## 筆者の見解 今回の件で改めて感じるのは、「今動いているから大丈夫」という感覚がいかに危険かということだ。2,600インスタンスが公開されているということは、管理者の多くはそもそも自分のサーバーが外から見えていることすら把握していない可能性がある。 ...

Windows 11のInsiderチャンネル（Dev / Experimental）向けに、ウィンドウのスナップ・リサイズ・閉じるボタンへのホバーなど、日常的なUI操作に触覚フィードバック（Haptic Feedback）を加える機能が段階的に展開されている。ビルド番号は 26300.8155 以降が対象で、対応するハプティクス対応トラックパッドを搭載したデバイスで利用可能だ。 どんな操作でフィードバックが来る？ 現時点でMicrosoftが公式に確認している対応アクションは次のとおりだ。 ウィンドウのスナップ（Snap Layouts） ウィンドウのリサイズ 閉じるボタンへのホバー PowerPoint上でのオブジェクト整列 Microsoftのデザイン担当パートナーディレクターであるMarch Rogers氏は「使ってみるまでは欲しいとわからない機能だ」とコメントしている。確かに、触覚フィードバックは実際に指先で感じてはじめてその価値が伝わるものだ。 ON/OFFの切り替えは 設定 > Bluetoothとデバイス > マウス > Hapticシグナル から行える。なお、今回の施策とは別に、Canaryビルドでは右クリックゾーンのサイズをカスタマイズできる新設定も追加されており、トラックパッド全体の操作性改善がMicrosoftの優先テーマになっていることが読み取れる。 「ハードウェアがなければ意味がない」という現実 この機能の最大の制約は、対応するハプティクス対応トラックパッドを搭載した端末が市場に少ないことだ。 AppleはMacBookのほぼ全ラインナップにForce Touchトラックパッドを標準搭載しており、ユーザーの「当然のもの」という期待値を作り上げてきた。一方、Windowsエコシステムにおいてハプティクス対応トラックパッドを積極的に採用してきたのはMicrosoft Surface Laptopくらいで、他のOEMは優先度を低く見ていた節がある。 直近の例を挙げると、Snapdragon X2 Elite Xtremeを搭載した ASUS Zenbook A16（約1,999ドル）でさえ、ハプティクス対応トラックパッドを省いている。価格帯からすれば搭載して当然という声もあるが、現状はそうなっていない。 Logitech MX Master 4のようなプレミアムマウスが独自のハプティクス機構を持っているケースもあるが、今回のWindows 11側の実装がそれらに対応するかどうかはまだ明らかにされていない。 実務への影響 現時点で多くのビジネスユーザーが使っているWindows PCは、この機能を体感できる環境に届いていない。実務観点でのチェックポイントを整理しておこう。 端末調達の判断材料に加える: 次の端末更改サイクルで比較検討する際、ハプティクス対応トラックパッドの有無を評価項目に追加しておくと、将来の機能拡張に備えられる。 Surface Laptopはこの点で先行: 手厚い触覚体験を求めるなら、現状はSurface Laptopが最も実用レベルに近い選択肢だ。 IT管理者はポリシー設計を: 組織によっては触覚フィードバックをOFFにしたいニーズもあるかもしれない。設定経路（Hapticシグナル）をポリシーで制御できるか今後確認しておきたい。 Insider / Experimental段階: 本番環境での使用にはまだ早い。一般提供（GA）後に展開を計画するのが現実的だ。 筆者の見解 この機能そのものの方向性は正しいと思っている。ウィンドウを「ピタッ」とスナップしたときに指先にクリック感が返ってくる体験は、操作の確実性と満足感を高める。UIの洗練という観点で、Microsoftがこういった細部に注目しているのは評価したい。 ただ、課題の本質はソフトウェアではなくエコシステムにある。どれほど優れたOS側の実装をしても、対応デバイスが市場に広まらなければ「知る人ぞ知る機能」のまま終わってしまう。MicrosoftはSurface Laptopで高水準の実装を見せているが、それをOEMパートナー全体に波及させる力をどこまで発揮できるかが問われている。 Windowsというプラットフォームの強みは多様なOEMと幅広い価格帯にあるが、ユーザー体験の統一感という点では課題を抱えやすい構造でもある。この機能が「一部のプレミアムモデルだけの話」にならないよう、OEMへの働きかけと、対応要件の明文化を期待したい。Microsoftにはその影響力があるはずだ。 出典: この記事は Windows 11 adds haptic feedback for snapping, resizing, and more but most laptops can’t use it yet の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

2024年9月から多くのWindowsサーバー管理者を悩ませてきた「意図しないWindows Server 2025への自動アップグレード」問題が、Microsoft自身の修正によってついに解消された。対象はWindows Server 2019および2022で、ライセンスを持っていないServer 2025への予期せぬアップグレードが、一夜にして実施されるという深刻な事態が相次いで報告されていた。 何が起きていたのか Microsoftの説明によれば、Windows Updateの設定画面にServer 2025へのアップグレードを促すバナーが表示されていたことが発端だ。本来は「希望する管理者向けの案内」のはずが、サードパーティ製のアップデート管理ソフトウェアによる自動処理と組み合わさり、管理者の意図しないアップグレードが実行されるケースが続出した。 Microsoftは当初、サードパーティソフトウェアの設定ミスを原因として示唆したが、ソフトウェアベンダー側は「Microsoftのリリース手順上の問題であり、リリース速度とアップデートの分類方法に誤りがあった」と反論。責任の所在について異なる見解が示される展開となった。 修正完了と同時に、Microsoftは一時的に無効化していたWindows Updateのアップグレードオファー機能を再有効化。「Settings画面からのアップグレードオファーは解決済みであり、機能を再有効化した」と公式の更新情報で発表している。 実務への影響 この問題が日本の企業IT環境に与えた影響は小さくない。多くの企業ではWindows Server 2019や2022のサポート期間内で安定稼働を維持しており、計画外のメジャーアップグレードは業務停止リスクに直結する。特にライセンス上の問題（Server 2025のライセンスを持たない状態でのアップグレード）は、コンプライアンスの観点からも看過できない。 IT管理者がいま確認すべきポイント サーバーのOSバージョン棚卸し: 意図せずServer 2025にアップグレードされていないか確認する。winver や systeminfo コマンドで即座に確認できる Windows Update管理ポリシーの見直し: GPO（グループポリシー）やWSUS、Intune等でアップグレードオファーの自動受け入れを明示的に制限しているか再確認する サードパーティ製パッチ管理ツールの設定確認: 今回の問題を機に、Feature Updateの自動適用ポリシーが意図した設定になっているかを見直す 変更管理プロセスの強化: OSアップグレードは変更管理の承認プロセスを経る運用を徹底し、自動化の範囲を明確に定義する 修正後も、Windows Updateの管理は「任せきり」ではなく「制御された自動化」が基本だ。特にサーバー環境では、クライアントPCとは異なる慎重な更新戦略が求められる。 筆者の見解 今回の件で残念に思うのは、修正までに1年以上かかったという事実だ。報告が相次いでいた2024年9月から数えれば、影響を受けた組織にとってはずいぶん長い「待ち時間」だったことになる。 Microsoftには、Windowsサーバープラットフォームを長年支えてきた実力と信頼がある。だからこそ、「ライセンスのないOSバージョンに自動でアップグレードされる」というインシデントが起きたときの初動対応には、もっと速度と透明性があってほしかった。ベンダー側への責任転嫁ととられかねない初期のコミュニケーションも、エンタープライズの信頼という観点では傷跡を残した。 Windows Updateに関しては、「すぐに当てたら壊れた」という報告がクライアント・サーバー問わず増えている昨今、「数日様子を見る判断」が一種のベストプラクティスになりつつある。特に本番サーバーでは、展開速度よりも安定性を優先する設計が欠かせない。Microsoft自身も、そのような慎重な運用姿勢を前提とした品質保証プロセスを一層強化してほしいと思う。 インフラ基盤として日本の多くの企業が依存しているWindowsサーバーだからこそ、品質への高い期待が揺らがないよう、次のリリースサイクルでの改善を期待したい。 出典: この記事は Microsoft fixes bug behind Windows Server 2025 automatic upgrades の内容をもとに、筆者の見解を加えて独自に執筆したものです。

米国サイバーセキュリティ・インフラセキュリティ庁（CISA）が、Windowsの中核コンポーネント「Task Host（タスクホスト）」に存在する権限昇格脆弱性 CVE-2025-60710 を「実際の攻撃で悪用されている脆弱性カタログ（KEV: Known Exploited Vulnerabilities）」に追加した。連邦機関には2週間以内の対応が義務付けられており、民間企業にも速やかなパッチ適用が強く推奨されている。 Task Hostとは何か、なぜ狙われるのか Task Host（taskhostw.exe）は、DLLベースのプロセスをバックグラウンドで動作させるための「コンテナ」として機能するWindowsのコアコンポーネントだ。シャットダウン時にプロセスを適切に終了させてデータ破損を防ぐ役割も担っており、OSの安定動作に欠かせない存在である。 今回の脆弱性は 「リンクフォロー（Link Following）」 と呼ばれる弱点に起因する。ファイルアクセス前のリンク解決が不適切なため、攻撃者が巧妙に細工したシンボリックリンクやジャンクションを使ってアクセス先を操作し、一般ユーザー権限（低権限）からSYSTEM権限へのローカル昇格を実現できてしまう。 影響対象: Windows 11 および Windows Server 2025 攻撃複雑度: 低（Low）——特別な技術は不要 必要な権限: 通常のローカルユーザー権限のみ パッチリリース日: 2025年11月のPatch Tuesday 攻撃シナリオと実際のリスク ローカル権限での昇格脆弱性というと「物理アクセスが必要では」と思われがちだが、実際のリスクはそれだけではない。 典型的な攻撃チェーンは以下のようなパターンが想定される： フィッシングメールや不正なファイルなどで最初の侵入口を確保（一般ユーザー権限） CVE-2025-60710を使ってSYSTEM権限へ昇格 セキュリティソフトの無効化、ラテラルムーブメント、認証情報の窃取へと展開 特にリモートデスクトップ（RDP）や共有端末環境、クラウドVDI環境では、限定的な初期アクセスから一気に全権奪取につながるため要注意だ。CISAは「この種の脆弱性は悪意ある攻撃者が頻繁に利用する攻撃ベクターであり、連邦エンタープライズに重大なリスクをもたらす」と警告している。 実務での対応ポイント 1. パッチ適用状況の即時確認 2025年11月のWindows Update（KB番号はMicrosoftのアドバイザリを参照）が適用済みかどうかを確認する。Windows UpdateのスキャンをPowerShellで一括確認する方法が効率的だ： 出典: この記事は CISA flags Windows Task Host vulnerability as exploited in attacks の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftが毎年開催するバグバウンティイベント「Zero Day Quest」の2026年版が締め括られ、合計230万ドル（約3億3,000万円）もの報奨金が支払われた。世界20か国以上の研究者から約700件の脆弱性報告が寄せられ、そのうち80件超がクラウドやAI基盤に影響する高インパクトな問題として認定された。 Zero Day Questとは何か Zero Day Questは、Microsoftのバグバウンティプログラムを発展させた形のライブハッキングイベントだ。2026年版は最大5,000万ドルの賞金プールを設定し、「史上最大のハッキングイベント」として発表されていた。昨年2025年版では1.6億ドルを支払っており、年々規模が拡大している。 参加した研究者たちは、Microsoftの定めた「Rules of Engagement（交戦規定）」に従い、顧客データや他テナントのシステムには一切アクセスしない形で検証を実施した。その制約の中でも、クレデンシャル露出・SSRFチェーン・テナント間の不正アクセスといった深刻な経路が発見されている。 Secure Future Initiative（SFI）の文脈 このイベントはMicrosoftが2023年11月に立ち上げた「Secure Future Initiative（SFI）」の一環だ。SFIは米国国土安全保障省のサイバー安全審査委員会がMicrosoftのセキュリティ文化を「不十分であり抜本的な見直しが必要」と指摘したことを受けた、組織横断のセキュリティ強化活動である。 SFIの柱は「デフォルトで安全・設計で安全・運用で安全」の3原則。Zero Day Questで得た知見は社内横断で共有され、CVEプログラムを通じて透明性をもって公開されると明言している。 実務への影響――クラウド管理者が今すぐ確認すべきこと クレデンシャル露出・SSRF・テナント間アクセスという3つの脆弱性クラスは、Azure環境を運用する日本のIT部門にとっても他人事ではない。 クレデンシャル露出は、サービスプリンシパルやマネージドIDの設定ミス、またはコードリポジトリへの誤コミットが引き金になることが多い。Microsoft Entra Workload IDの棚卸しと、シークレットの有効期限・ローテーション設定を定期的に見直す習慣が重要だ。 SSRF（Server-Side Request Forgery）チェーンは、クラウドのメタデータエンドポイントへの不正アクセスへとつながる経路として研究者から注目されている。Azure IMDSへのアクセス制限やネットワーク分離の徹底が基本対策となる。 テナント間アクセスについては、ゲストアカウントや外部コラボレーションの設定が想定外に緩くなっていないか、Microsoft Entra Cross-Tenant Access Settingsを改めて確認するとよい。 またMicrosoftは2025年12月、第三者が書いたコードに起因するオンラインサービスの脆弱性についても報奨金対象とすることを発表している。SaaSやPaaSを使う側としても、依存ライブラリのサプライチェーンリスクが間接的に自テナントのリスクになり得る点を意識してほしい。 筆者の見解 セキュリティというジャンル、正直なところ細かい話が多くて得意分野ではない。それでも今回のZero Day Questの結果を見て、素直に「やっているな」と思った。 SFIはもともと、手厳しい外部評価を受けて始まった取り組みだ。それを言い訳にせず、最大規模のバグバウンティに予算を張り、世界中の研究者を正面から招き入れてクラウドとAIのアーキテクチャを叩かせる。この姿勢は評価に値する。 見つかった脆弱性の類型――クレデンシャル露出・SSRF・テナント間アクセス――は、どれも「設計の甘さ」や「運用の慣れ」が原因で生まれやすいものだ。AIサービスの急拡大に伴い、内部で処理される認証情報の経路が増えているのは確かで、それが攻撃対象となった背景もうなずける。 ゼロトラストの観点から言えば、今回報告された問題の多くは「信頼を前提にした設計」が根に残っていることを示唆している。テナント間アクセスの設計であれ、クレデンシャルの扱いであれ、「ネットワーク内にいるから大丈夫」という前提を捨てる方向性は間違っていない。SFIの3原則――デフォルトで安全・設計で安全・運用で安全――はまさにそこを突いている。 Microsoftにはこの路線をこのまま続けてほしい。外圧で始まった取り組みが内発的な文化に変わるとき、本当の強さが生まれる。今がそのフェーズだと思って見ている。 出典: この記事は Microsoft pays $2.3M for cloud and AI flaws at Zero Day Quest の内容をもとに、筆者の見解を加えて独自に執筆したものです。

「署名されているから安全」という前提が崩れつつある 2026年4月、セキュリティ企業 Huntress の研究者たちが衝撃的なキャンペーンを詳報した。デジタル署名付きのアドウェアが、SYSTEM権限でウイルス対策製品を完全に無効化するペイロードを展開していたというものだ。被害は教育機関・公共インフラ・政府機関・医療機関を含む世界124か国、わずか1日で2万3,500台以上のエンドポイントが感染ホストとして観測された。 「PUP（Potentially Unwanted Program）だから大したことない」という甘い認識が、いかに危険かを突きつける事例だ。 手口の全体像——合法ツールを踏み台にした「サイレント侵害」 今回の攻撃の主役は、Dragon Boss Solutions LLC という企業が署名した一連の「ブラウザ」アプリだ。Chromstera、Chromnius、WorldWideWeb、Artificius Browserといった名称で流通しており、多くのセキュリティ製品からPUP扱いを受けていた。 表向きはブラウザとして動作しつつ、内部では Advanced Installer という商用パッケージングツールの自動更新機構を悪用している点が巧妙だ。正規ツールのアップデート機能を間借りすることで、セキュリティ製品の検知をすり抜けやすくしている。 侵害の流れ 更新チェック — 設定ファイルに埋め込まれた複数のフラグにより、ユーザー操作を一切必要とせずサイレント実行 偵察フェーズ — 管理者権限の有無、仮想マシン検出、インターネット接続確認、レジストリからのAV製品特定（Malwarebytes、Kaspersky、McAfee、ESETを明示的にターゲット） MSIペイロード展開 — Setup.msi をGIF画像に偽装して取得・実行。SYSTEM権限で動作 ClockRemoval.ps1 の投下 — AVサービスの停止・プロセス強制終了・インストールディレクトリの削除・レジストリ消去を実施 再インストール封鎖 — hostsファイルを改ざんしてAVベンダーのドメインを 0.0.0.0 にヌルルーティング。更新も再インストールも不能に 永続化 — システム起動時・ログオン時・30分ごとのタスクスケジューラ登録でAV除去を繰り返し実行 Opera、Chrome、Firefox、Edgeのインストーラーも標的にされているが、これはブラウザハイジャック機能への干渉を避けるためと分析されている。 なぜこれが重要か——「署名 ≠ 安全」を現場に刻め コード署名証明書は、ソフトウェアの「発行元の身元」を証明するものだ。しかしそれは「中身が安全である」ことを保証しない。今回の攻撃は、この前提の混同を意図的に突いている。 日本の組織でも、「署名済みだからインストール許可」という運用ルールを持っているケースは少なくない。AppLocker や Windows Defender Application Control（WDAC）の構成が甘ければ、署名の有無だけで制御を通過させてしまう。 PUPは「迷惑なだけで害はない」と軽視されがちだが、今回のケースはその出発点から最終的にAV完全無効化・ドメイン封鎖・SYSTEM権限の乗っ取りへと進展している。初期侵害の経路として「アドウェア」が使われる時代に入っていると認識しなければならない。 実務への影響——明日から使える対策ポイント 1. WDAC / AppLocker の証明書だけに頼らないポリシー設計 発行元証明書に加えて、ファイルハッシュ・製品名・バージョンの組み合わせで制御する構成に見直す。Intelligent Security Graph（ISG）との連携も有効だ。 2. 「PUP検知=即対処」の運用ルール化 SIEM/EDRの検知ルールでPUPアラートを「低優先度」に分類している場合、今すぐ見直す。アドウェアであっても高権限で動作している痕跡があれば最優先にエスカレートする。 3. hostsファイル・レジストリの変更監視 FIM（ファイル整合性監視）を有効にし、C:\Windows\System32\drivers\etc\hosts への書き込みをリアルタイムでアラートする。これは本攻撃の「再インストール封鎖」を早期発見する最も現実的な手段だ。 4. 定期的な「AV有効性確認」の自動化 ...

何が起きたか 2026年4月、WordPressプラグイン開発会社「EssentialPlugin」が提供する30本以上のプラグインに悪意のあるコードが仕込まれていたことが判明した。被害を受けたプラグインの総インストール数は数十万に達する。 発端は、マネージドWordPressホスティング「Anchor Hosting」の創業者Austin Ginderへの内部情報提供だった。調査を進めたところ、すべての汚染がEssentialPluginが6桁の金額（数百万円規模）で新オーナーに買収された2025年8月以降に遡ることが分かった。 バックドアは数ヶ月間、完全に沈黙していた。そして最近になって突如「活性化」し、外部のコマンド＆コントロール（C2）サーバーへ接続して wp-comments-posts.php（正規の wp-comments-post.php に似せた名前）を取得。このファイルがWordPressのコア設定ファイル wp-config.php にマルウェアを注入する仕組みだ。 攻撃の巧妙さ——3つのポイント 1. イーサリアムベースのC2アドレス解決 通常のマルウェアはIPアドレスやドメインをハードコードするが、本攻撃ではEthereumブロックチェーンを使ってC2サーバーのアドレスを動的に解決する。ブロックチェーンは書き換えが困難なため、C2インフラをブロックされにくい。インフラのテイクダウンへの耐性が高く、検出・無効化がきわめて難しい設計だ。 2. Googlebot専用のスパム配信 注入されたコードは、スパムリンク・リダイレクト・偽ページをGooglebot（Googleの検索クローラー）にしか表示しない。サイトオーナーが自分のサイトを開いても何も見えないため、被害に長期間気づけない。SEOの毀損と検索順位の下落として静かに被害が積み上がる。 3. 「時限式」サプライチェーン攻撃 買収直後にバックドアを仕込み、しばらく休眠させてから一斉に活性化する手法は近年増加傾向にある。オープンソースプロジェクトやSaaS系サービスの「買収」を入口にする攻撃は、従来のコード審査やウイルス対策では検知が難しい。 WordPress.orgの対応と残る課題 WordPress.orgは報告を受けて迅速に動き、問題プラグインのリポジトリへのアクセスを閉鎖。強制アップデートを配布してバックドアの通信経路を無効化した。 ただし「強制アップデートは wp-config.php の汚染を修復しない」とWordPress.orgは明示している。データベース接続情報など重要な設定が記載された wp-config.php が汚染されたままの場合、バックドアの通信が止まっても攻撃者はすでにサイト情報を取得済みの可能性がある。 また、マルウェアの潜伏場所が wp-comments-posts.php だけとは限らず、他のファイルにも潜んでいる可能性があることも警告されている。 実務への影響——日本のエンジニア・IT管理者がいまやるべきこと 即時確認 自社・顧客サイトでEssentialPlugin製品（旧称: WP Online Support）を使用していないか確認する 対象プラグインのリストはPatchStackの調査記事で公開されている wp-comments-posts.php（正規ファイルは wp-comments-post.php、末尾の s に注意）の有無を確認 wp-config.php の内容を直接確認し、不審なコードがないかチェック 中長期の対策 プラグインの購入・導入審査にサプライチェーンリスクの観点を加える: 「誰が所有しているか」「最近買収されていないか」をチェックするフローを設ける File Integrity Monitoring（FIM）の導入: wp-config.php などのコアファイルに対する変更をリアルタイム検知する仕組みを入れる 最小権限の原則: プラグインが持つファイル書き込み権限を必要最小限に絞る Webアプリケーションファイアウォール（WAF）: Googlebot偽装のアウトバウンド通信をブロックするルール整備 筆者の見解 この事件が示すのは、「コードの品質チェック」や「脆弱性スキャン」だけではもはや十分でないという現実だ。攻撃者は合法的な手段（プラグインの正規買収）でサプライチェーンに侵入し、時間をかけて信頼を積み上げてから攻撃を発動する。8ヶ月間の潜伏期間中、このバックドアはどんな静的解析にも引っかかりようがなかった。 C2アドレスの解決にイーサリアムブロックチェーンを使うアプローチは、インフラのテイクダウン耐性という観点で技術的に興味深い。今後、同様の手法が他の攻撃でも使われることは間違いなく、ネットワーク層での検知戦略の見直しが急務だ。 Non-Human Identity（NHI）の観点からも示唆が多い。WordPress環境ではプラグインがサーバー上のファイルを読み書きし、外部APIと通信し、データベースに接続する——これらはすべてNHIとして管理されるべき「アクセス権」だ。「インストールしたら終わり」ではなく、「このプラグインがどのリソースに対してどんな権限を持ち続けているか」を継続的に把握する仕組みが求められる。 WordPress自体を使うかどうかという選択論に持ち込むのは生産的ではない。現実的には、既存サイトの大半はWordPressで動いており、完全移行は現実的でない。だからこそ「禁止」ではなく「安全に使い続けるための仕組みを作る」という発想で、FIMの導入・権限の最小化・サプライチェーンの定期的な棚卸しを着実に進めることが今できる最善策だ。 すでに wp-config.php が書き換えられている場合、強制アップデートで「通信は止まった」状態でも、攻撃者がDB接続情報を入手済みである可能性を捨てられない。このケースではパスワードローテーションとログの精査を最優先で実施してほしい。 出典: この記事は WordPress plugin suite hacked to push malware to thousands of sites の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Snapが従業員の約16%にあたる1,000人以上のレイオフを発表し、同時に300の求人枠も閉鎖した。単なるコスト削減ではなく、「AIを活用した小規模チームがすでに大きな成果を出している」という手応えを組織再編の根拠に据えている点が、今回の動きをとりわけ注目すべきものにしている。 何が起きているのか Snapの発表によれば、今回の構造改革は同社にとってここ数年で最大規模のものだ。削減対象は開発・運営部門に広く及び、一方でAIエンジニアリングへの投資は強化される方向性が示されている。経営陣は「AIが武器になった今、組織の形そのものを変えなければ競争力を維持できない」というメッセージを明確に打ち出している。 注目すべきは、この発表が単なる業績不振による人員整理ではない点だ。Snap自身が「AIチームはすでに成果を出している」と述べており、これは「AI導入による生産性向上」が具体的な組織変更の根拠として機能し始めた、業界初期の事例のひとつといえる。 「少数精鋭×AI」が組織の標準形になる 従来のソフトウェア開発では、機能追加・品質保証・インフラ管理それぞれに専任チームを置くことが当然とされてきた。しかしAIがコード生成・テスト・インフラ管理の多くを担えるようになった今、「人間が担うべき作業の絶対量」が劇的に減少している。 Snapの事例が示すのは、その変化が理論ではなく実際の経営判断に反映される段階に入ったということだ。ソーシャルメディアという競争の激しい領域で、1,000人規模の削減と並行してAI投資を拡大するという判断は、経営層が「AIで代替できる仕事の範囲」を相当広く見積もっていることを示している。 実務への影響：日本のIT現場で何を考えるべきか この動きは日本のIT部門にとっても対岸の火事ではない。以下の点を今すぐ自組織に照らし合わせて考えてほしい。 1. 「人員数＝処理能力」の方程式を疑う プロジェクトが遅延した際に「人を増やす」判断が先に来るなら、一度立ち止まる価値がある。同じ課題をAIを活用した少人数チームで解決できないか検討してみてほしい。 2. 「仕組みを作れる人材」の価値が急騰する AIに指示を出し、自律的に動くパイプラインを設計・改善できる人材は、今後ますます希少かつ高価値になる。コードを書くだけでなく「AIを使って仕組みを動かす」スキルを身につけることが、キャリアにおける最重要投資のひとつだ。 3. 採用計画の前提を見直す 毎年一定数の新卒・中途を採用し続けるモデルが本当に最適かどうか、再検討する時期に来ている。採用数よりも「どんな仕組みを持った組織を作るか」を先に考える順序が、今の時代には合っている。 4. 既存メンバーのリスキリングを優先する Snapのような企業は「AIに置き換えられる役割を削減」している。一方で、AIを使いこなせる人材への需要は高まっている。既存メンバーをAI活用の担い手に育てる投資は、採用コストよりも即効性が高いケースが多い。 筆者の見解 Snapの今回の動きを見て、「ついにここまで来たか」という実感がある。AIが「補助ツール」から「組織設計の前提」に変わる転換点を、具体的な数字で目の当たりにしたような感覚だ。 正直に言えば、日本のIT業界では「AIで生産性が上がった話」は増えているのに、「組織の形を変えた」という話がまだほとんど出てこない。技術的には変革が起きているのに、組織・人事・採用の構造は10年前とほぼ同じという企業が多すぎる。Snapの事例はその矛盾を鋭く突きつけてくる。 「少数の仕組みを作れる人が、AIを使って大きな仕事を動かす」——これはもう未来の話ではなく、すでに起きていることだ。毎年同じ規模で新卒採用を繰り返し、頭数で課題を乗り越えようとするアプローチは、構造的なコスト競争力を失い続けるリスクがある。 とはいえ、大切なのは「AI導入で人を減らす」ことそのものではなく、「AIを活かした仕組みを作れる人材を組織の中心に置く」ことだ。削減ありきではなく、組織が何を実現したいかから逆算して役割と人員を設計する。Snapの判断が正しいかどうかは数年後に明らかになるが、「AIで何が変わるかを経営判断に組み込む必要がある」という問い自体は、すべてのIT組織が今すぐ向き合うべきものだと思っている。 出典: この記事は Snap cuts 16% workforce as it aggressively doubles down on AI の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは、Windows 11向けの累積アップデート KB5083769 および KB5082052 を適用した端末において、BitLockerのリカバリモードが誤って起動してしまう不具合を公式に認めた。影響範囲はWindows 11の全サポートバージョンにとどまらず、Windows 10およびWindows Serverにも及んでいる。 何が起きているのか BitLockerは、ディスク全体を暗号化してデータを保護するWindowsの機能だ。通常、ハードウェア構成の変更やTPMの状態変化など「何か重要なものが変わった」と検知したときにリカバリキーの入力を求める。今回のケースは、OSアップデートによって不適切にその条件が満たされたと誤認され、再起動後にいきなり回復キーの入力画面が表示されるという事象だ。 Microsoftの公式見解では、この問題はアップデートのインストールプロセスにおけるBitLockerとTPMの状態管理に起因するとされており、回避策の調査中としている。 なぜこれが重要か BitLockerのリカバリキーは、多くの企業環境でActive DirectoryやMicrosoft Entra IDに保管されている。IT管理者がいるならまだリカバリは可能だが、問題はエンドユーザーが一人で作業している時間帯や、出先・在宅勤務中にこの画面に遭遇したときだ。リカバリキーがどこにあるか分からないユーザーは、完全に作業不能になる。 さらに深刻なのはサーバー環境だ。Windows Serverに同様の問題が発生した場合、サービス停止に直結する。BitLockerを有効化しているサーバーで再起動後にリカバリ画面が出れば、物理的またはコンソールアクセスが必要になるケースもあり、クラウド仮想マシンでは対応がより複雑になる。 実務での対応ポイント 【IT管理者向け】 パッチの展開を一時停止する判断も正解: 問題が公式確認されている状況では、KB5083769・KB5082052の自動展開を保留にすること。Microsoftが修正済みパッチをリリースするまで待つのは立派なセキュリティ判断だ。 BitLockerリカバリキーの保管状況を今すぐ確認: Microsoft Entra IDまたはActive DirectoryにリカバリキーがエスクローされているかをPowerShellや管理コンソールで確認する。保管されていない端末が一台でもあれば、今すぐ対処が必要だ。 影響端末の洗い出し: 既に該当パッチを適用済みの端末リストを作成し、ヘルプデスクに「BitLockerリカバリ画面が出た場合の対応手順」を共有しておく。 サーバーへの適用は特に慎重に: 本番サーバーへの展開前に、テスト環境での検証を必ず実施すること。 【一般ユーザー向け】 もし再起動後にBitLockerのリカバリキー入力画面が出た場合は、焦らずIT部門に連絡する。 個人PCでBitLockerを有効にしている場合は、Microsoftアカウントのセキュリティページからリカバリキーをあらかじめ確認・保存しておくこと。 筆者の見解 Windowsのアップデートが端末を「文鎮化」しかねない問題は、残念ながら珍しい話ではなくなりつつある。今回はBitLockerという、まさにセキュリティの要である機能が誤動作するという点で、インパクトが大きい。 このような不具合が続くと、IT管理者の現場では「すぐに当てるべきか、様子を見るべきか」という判断がますます難しくなる。セキュリティパッチは速やかに適用することが原則だが、パッチそのものが別のリスクを生む状況では、テスト環境での検証フェーズを設けることが現実的な対応だ。「数日様子を見てから展開する」という判断は、臆病ではなく、リスク管理として正しい行動だと筆者は考えている。 Microsoftには、品質管理プロセスの強化を期待したい。これだけの規模のエコシステムを持ち、Windows Updateという強力な配布基盤があるのだから、その基盤の信頼性を守ることがすべての前提になる。セキュリティ機能を守るためのパッチが、セキュリティ機能を壊すという矛盾は、早期に解消されることを強く願っている。 修正パッチのリリース情報は、Microsoftの公式リリースノートおよびWindows Updateのサポートページで随時更新される予定だ。影響を受けた場合は公式情報を都度確認してほしい。 出典: この記事は Microsoft confirms Windows 11 KB5083769, KB5082052 wrongly forcing BitLocker recovery の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Windows 11の物議を醸す機能「Recall」が、またも厳しい視線にさらされている。新たに公開されたツールにより、Recallが蓄積するスクリーンショットや入力データを容易に抽出できることが実証された。Microsoftは「設計上の欠陥はない」と主張するが、セキュリティ研究者コミュニティの反応は冷ややかだ。 Recallとは何か——おさらい Recallは、PCの操作履歴をスクリーンショットとして定期保存し、自然言語で「あのとき見ていたページ」を検索できるようにするWindows 11の機能だ。2024年に発表された当初から「スパイウェアそのものだ」「ローカルに個人情報が大量蓄積される」として批判を集め、リリースが延期。その後Copilot+ PC向けにオプトイン形式で段階的に提供が始まった。 Microsoftは再設計にあたり、データをTPM（Trusted Platform Module）で保護し、Windows Helloによる生体認証が必要な「Secure Enclave」内に保存すると説明してきた。この説明が今、改めて問われている。 何が明らかになったか 今回公開されたツールは、Recallが使用するSQLiteデータベースと蓄積されたスナップショット画像に対して、管理者権限またはRecallデータへのアクセス権を持つユーザーのコンテキストからアクセスし、内容を一括エクスポートできることを示した。 Microsoftの反論は「これは想定された動作範囲内であり、アクセス権を持つユーザーが自分のデータを読めるのは当然」というものだ。技術的には間違っていない。しかし批判の核心は別のところにある。 問題の本質は「データが存在すること」そのものだ。 マルウェアが管理者権限を奪取した場合、Recallのデータベースはそのまま「過去数週間〜数カ月の行動記録」として流出する 企業環境でエンドポイントが侵害されたとき、Recallが有効だったPCは被害範囲が格段に広がる可能性がある フィッシングやソーシャルエンジニアリングで一般ユーザーのアカウントが乗っ取られた場合も同様 Microsoftが「欠陥なし」と言うのは「鍵のかかった金庫に泥棒が入ったとき金庫を開けられるのは設計どおり」と言っているに等しい。議論がかみ合っていない。 企業・IT管理者が取るべき対応 Recallの現実的なリスク評価 環境 推奨 機密情報を扱う企業PC Recall無効化を強く推奨 医療・法務・金融 コンプライアンス要件次第では即時無効化必須 一般コンシューマー オプトイン前提なので、デフォルトは無効のはず 個人の趣味用途 リスクを理解した上で各自の判断 グループポリシーでの制御 Intune / グループポリシーで Turn off saving snapshots for Windows ポリシーを有効化すれば企業全体でRecallを無効にできる。Copilot+ PC対象機器が社内に増えてきた場合、今から構成を確認しておくことを推奨する。 エンドポイントセキュリティとの組み合わせ Recallを使用する場合でも、EDR（Endpoint Detection and Response）ソリューションによるプロセス監視を組み合わせることで、不審なDBアクセスを検知できる体制を整えるべきだ。「機能を禁止する」より「使える状態で安全に管理する」アプローチが長続きする。 筆者の見解 Recallはアイデア自体は面白い。「あのとき調べていた情報をもう一度」というニーズは確かに存在するし、ローカル処理でプライバシーを守るというコンセプトも正しい方向性だと思っている。 ただ、Microsoftがセキュリティ研究者の指摘に対して「想定内の動作」と繰り返すだけでは、ユーザーの信頼回復にはつながらない。今の時代、エンドポイントへの侵害を「起きないこと」として設計するのはもう通用しない。侵害されることを前提にしたデータの最小化設計——「侵害されてもRecallのデータが渡らない」アーキテクチャ——こそが必要なはずだ。 Microsoftにはそれを実現する技術力が十分にある。Plutonチップ、Windows Helloの多要素認証、Confidential Computingと、セキュリティの基盤技術は世界トップクラスだ。だからこそ、「設計上の欠陥はない」という守りの一点張りではなく、「こういう侵害シナリオに対してはこう対応する」という前向きな議論を期待したい。 Recallはまだ発展途上の機能だ。このまま不信感の中で死んでいくには、ポテンシャルがもったいない。 出典: この記事は Windows 11’s controversial Recall is under fire again, while Microsoft denies flaws の内容をもとに、筆者の見解を加えて独自に執筆したものです。

企業内でのAI利用が急拡大する中、IT部門が頭を抱えている問題が「シャドーAI」だ。Microsoftは、Microsoft Edgeブラウザに新たなグループポリシーを追加し、IT管理者が職場のAIアプリ利用をコントロールできる仕組みを整備する方針を明らかにした。 何が変わるのか この新機能により、IT管理者はEdge上で動作するAIアシスタントのアクセスをポリシーで制御できるようになる。具体的には、従業員が業務中に利用するAIアプリをCopilot in Edgeへ誘導したり、他のサードパーティAIアプリへのアクセスに制限をかけたりすることが可能になる。 ターゲットは明確だ。いわゆる「シャドーAI」——IT部門の承認を得ずに従業員が勝手に使い始める外部AIサービスを、ガバナンスの傘の下に収めることが目的だ。業務データが未審査のAIサービスに流れるリスクを、管理側のポリシーで封じ込めようとする動きである。 シャドーAI問題の現実 日本の企業でも、生成AIの業務利用は急速に広がっている。一方でセキュリティ・コンプライアンス担当者の悩みは深い。従業員がどのAIサービスに何のデータを入力しているか、実態を把握しきれていないケースがほとんどだからだ。 これは単なるポリシー違反の問題ではない。個人情報保護法・不正競争防止法・各種業法への抵触リスク、そして万が一のデータ漏洩時の責任所在の問題でもある。「禁止通達を出した」だけでは何も解決しないことは、過去のBYODやクラウド利用制限の歴史が証明している。 実務での活用ポイント 1. 「禁止」ではなく「統制」で設計する グループポリシーでAIアプリを一律ブロックするアプローチは、かえって業務非効率を生み、従業員が個人端末や個人回線で使い始めるという抜け道を生む。今回のEdgeポリシーのように「承認済みツールを優先表示・誘導する」設計の方が現実的かつ長期的に機能する。 2. Microsoft Entra ID + Conditional Accessとの組み合わせを検討 EdgeのAIポリシーは、既存のMicrosoft 365コンプライアンス基盤と連携させてこそ真価を発揮する。Conditional Accessによるデバイスコンプライアンス確認と合わせて設計することで、ゼロトラスト的な多層防御が実現する。 3. データ分類ポリシーとセットで運用する どのデータをAIに入力してよいか・よくないかを明文化し、MIPラベルなどの情報保護機能と組み合わせる。技術的な制御だけでなく、従業員への教育・啓発もセットで行うことが不可欠だ。 筆者の見解 このEdgeポリシー追加の方向性は、基本的に正しい。「禁止で封じ込める」のではなく、「承認済みツールを使いやすくすることで自然に誘導する」というアプローチは、ガバナンスの本来あるべき姿だ。シャドーAIを生む根本原因は「承認されたツールが不便だから」であることが多い。その意味で、IT管理者がコントロールできる土台を整備すること自体は歓迎したい。 ただし、正直に言えば、この仕組みが本当に機能するかどうかは、Copilot in Edgeが「使われたいと思われる品質」を持てるかどうかにかかっている。管理者がポリシーで誘導できたとしても、実際に業務で役立つ体験を提供できなければ、従業員は個人端末での利用に逃げるだけだ。 Microsoftにはプラットフォーム・ブランド・エンタープライズ信頼性という、他が簡単に真似できない強みがある。その総合力を活かして、ガバナンス基盤と実用性を両立した本物のAIアシスタント体験を実現できる力は十分にあるはずだ。「使わされている」ではなく「これが一番便利だから使っている」と従業員が思える状態を作ること——そこに向けて全力を注いでほしい。プラットフォームの整備は着実に進んでいる。あとは中身の勝負だ。 出典: この記事は Microsoft will allow IT admins to force Copilot in Edge over other AI apps の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Windows 10のサポート終了期日「2026年10月14日」はIT管理者の間でも周知されてきた。しかし、実はそれよりも深刻な問題が同年に潜んでいる。Secure Boot証明書の失効だ。単なるソフトウェアライフサイクルの話ではなく、物理的に起動できなくなるリスクを孕むこの問題は、まだ十分に語られていないと感じる。 2026年10月のEOLとは何か MicrosoftはWindows 10を2015年にリリースした際、10年間のサポートを明言していた。2020年にメインストリームサポートが終了し、延長サポートは本来2025年まで——それをさらに1年延長して2026年10月までとなった経緯がある。 EOL以降は、リモートコード実行・権限昇格・情報窃取を可能にする脆弱性を含むいかなるセキュリティ更新も提供されない。OSとしての機能は動き続けるが、攻撃者にとっては「既知の穴が塞がれないまま放置されたターゲット」になる。 Secure Boot証明書失効：こちらの方が深刻かもしれない Windows 10が使用する Microsoft Corporation UEFI CA 2011 証明書は、2026年中に有効期限を迎える。Secure Bootはブートプロセスに信頼済み署名付きソフトウェアのみをロードさせる仕組みだが、この証明書が失効すると検証に失敗し、システムが起動不能になるか、Secure Boot自体を無効化せざるを得なくなる。 Secure Bootを無効化するということは、ブートキット攻撃（OSロード前にマルウェアが制御を奪う）に対して無防備になることを意味する。Microsoftが証明書を任意に延長できない理由は、暗号学的な設計上の制約と、定期的な証明書ローテーションというセキュリティベストプラクティスにある。これはMicrosoftが「やらない」のではなく「できない」話だ。 EOL後もパッチ未適用で使い続ける判断をする組織は多いが、Secure Boot失効はOSが動くかどうかという土台の問題であり、セキュリティリスクとは別の次元の話である。 Extended Security Updates（ESU）：コストと限界 移行が間に合わない組織向けに、MicrosoftはESUプログラムを提供する。コンシューマー向けは初年度30ドル/デバイスとされているが、エンタープライズ向けは年々倍増する設計だ——1年目約61ドル、2年目約122ドル、3年目約244ドル（2029年まで）という試算がある。 ESUがカバーするのは重要なセキュリティ脆弱性のみであり、機能更新・非セキュリティ修正・テクニカルサポートは含まれない。年次更新が必要で、2029年以降は完全終了となる。延命策ではあるが、根本的な解決にはならない。 実務への影響——日本のIT管理者が今すぐやるべきこと 1. 台数把握と証明書確認を急げ まずWindows 10端末の棚卸しが必要だ。Get-WmiObject Win32_OperatingSystem や Microsoft Entra・Intuneのデバイスレポートで把握する。Secure Boot有効化状況も msinfo32 や PowerShell で確認できる。 2. Windows 11移行可否の判定 TPM 2.0・Secure Boot対応・CPU要件を満たさない古い端末は「更新プログラムで上げる」ではなくハードウェア更新が必要になる。調達リードタイムを考えると、2026年10月は決して遠くない。 3. ESUの費用対効果を計算する どうしても移行できない端末はESUで繋ぐが、「とりあえずESUで延命」の積み重ねは結局コストを押し上げる。Windows 10延長サポートに費やすコストをWindows 11端末の調達予算に回す判断を今から経営層に説明しておくべきだ。 4. Secure Boot無効化だけは避けよ 「起動しなくなった」問題を解決するためにSecure Bootをオフにする対処は、攻撃面を大幅に広げる。カーネルドライバーの締め出しをはじめとするWindowsのセキュリティ強化はSecure Bootを前提に設計されている。 筆者の見解 Windows 10のEOLは「ずっと前からわかっていた話」だ。しかしSecure Boot証明書の失効という問題は、エンドユーザーやSMB規模のIT担当者にはほぼ伝わっていないと感じる。「OSが動いているから大丈夫」という感覚は、この問題の前では通用しない。 Microsoftが1年の延長サポートを加えたり、コンシューマー向けESUを設けたりと、移行の猶予を作ろうとしている姿勢は評価できる。ただ、Secure Boot証明書の失効リスクについては、もっとわかりやすく・大きな声で周知してほしかったというのが本音だ。MicrosoftはWindowsのセキュリティ基盤をここ数年着実に強化してきた。その成果を正しく活かすためにも、ユーザーが「動いているから問題ない」のまま取り残されない情報発信を期待したい。 IT管理者の皆さんには、単なる「EOLのリマインダー」としてではなく、Secure Boot証明書失効という具体的な技術的タイムリミットとして今回の問題を捉え直してほしい。対応は早ければ早いほど選択肢が広い。 出典: この記事は Windows 10 End of Support 2026: Secure Boot Expiry, ESU Costs, and Critical Security Risks の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Googleが長年ユーザーから要望の多かった縦型タブ（Vertical Tabs）と、より賢くなったリーディングモードをChromeに実装することを発表した。一見地味なUI改善に見えるが、情報収集を日常的に行うエンジニアやIT管理者にとっては、作業効率を左右する実質的なアップデートだ。 縦型タブとは何か 従来のブラウザタブは画面上部に横並びで表示される。タブを大量に開くと、各タブのタイトルがほぼ見えなくなるという問題は、多くのヘビーユーザーが日々直面している現実だ。 縦型タブは、タブ一覧をサイドバーとして縦に並べる方式に切り替える。これにより： タイトルの視認性が飛躍的に向上：横に並べると潰れてしまうタイトルが、縦配置なら十分な幅で表示できる タブの整理・把握がしやすくなる：グループ化や折りたたみも行いやすく、タブ管理が格段に改善する ワイドスクリーンとの相性が良い：横幅の広いモニターでは、縦方向のサイドバーにタブを逃がすことでコンテンツ表示領域を有効活用できる スマートリーディングモードの進化 リーディングモードは、Webページから広告やナビゲーションなどの「ノイズ」を取り除き、本文だけをすっきりとした形式で表示する機能だ。今回の「スマート」版では、AIを活用してコンテンツの主要部分をより精度高く抽出し、長文記事や技術ドキュメントの可読性をさらに高める方向で改善が加えられているとされている。 特にエンジニアが英語の技術記事やドキュメントを読む場面では、余計なサイドバーやポップアップが消えるだけで集中力の維持に大きく貢献する。 実務への影響——日本のエンジニア・IT管理者にとっての意味 タブ管理の見直し 日常的に調査や情報収集を行うエンジニアは、気づけば30〜50タブを開いた状態になることも珍しくない。縦型タブへの切り替えは、そのカオスを整理する一手になりうる。特にデュアルモニター環境や大型ディスプレイを使っているなら、縦型タブの恩恵を受けやすい。 リーディングモードの業務活用 技術ドキュメントや英語記事を読む際に積極的に活用したい。翻訳ツールとの組み合わせも相性が良く、本文だけを抽出してから翻訳にかけると精度と可読性が上がるケースがある。 組織内のブラウザ管理 法人でChromeを管理している場合、新UIの展開タイミングや企業ポリシーへの影響を事前に確認しておくと安心だ。特にChrome Enterprise環境では、機能フラグや管理コンソールの設定で展開を制御できる場合がある。 筆者の見解 正直に言えば、縦型タブはすでに数年前から他のブラウザで実装済みの機能だ。ヘビーユーザーの間では「なぜChromeにはないのか」という声が長く続いていた。ようやく追いついてきたという印象は否めない。 とはいえ、Chromeのシェアを考えれば、この機能が「世界規模で当たり前になる」という意味合いは小さくない。縦型タブが普及することで、より多くの人がタブ管理に意識を向けるようになれば、情報整理の文化そのものが底上げされる可能性がある。 リーディングモードの強化は、AIを「派手な会話UI」としてではなく「黒子として情報品質を高める」方向に使うという点で、筆者は好意的に見ている。これは「道のド真ん中」のAI活用であり、ユーザーが意識せずに恩恵を受けられる形だ。こういうアプローチこそが、AIの実質的な普及を進める。 ブラウザ選択はあくまでユーザーの自由だが、今回のアップデートを機に「自分はどのブラウザのどの機能を本当に使っているか」を一度棚卸しする良いタイミングかもしれない。どのブラウザを選ぶにしても、意図された使い方をきちんと理解して使うことが、結局は一番効率の良い選択につながる。 出典: この記事は Chrome finally gets vertical tabs and a smarter reading mode の内容をもとに、筆者の見解を加えて独自に執筆したものです。

「既製品」の限界に達したメタが選んだ道 マーク・ザッカーバーグが率いるメタ・プラットフォームズが、半導体大手ブロードコム（Broadcom）と組んで独自のAIシリコンエコシステムを構築することが明らかになった。数十億人のユーザーを抱えるSNS基盤のAI推論・学習を、既製の汎用GPUに頼らず自社設計チップで賄おうという、極めて大規模な戦略転換だ。 これは単なる「コスト削減のためのカスタマイズ」ではない。AIインフラの主導権を誰が握るかという、産業構造レベルの問いに対するメタなりの回答である。 なぜブロードコムなのか ブロードコムはネットワーク機器やASIC（特定用途向け集積回路）設計で長年の実績を持つ。Googleの「TPU（Tensor Processing Unit）」もブロードコムとの協業で開発されてきた経緯がある。つまりメタは、AIチップ開発の実績がある既存パートナーシップの方程式に乗る形を選んだわけだ。 NVIDIAのGPUは汎用性が高く、どんなワークロードにも対応できる反面、「どんなワークロードにも対応できる」ために生じるオーバーヘッドが大きい。推論フェーズ（学習済みモデルを使って実際にサービスを動かす段階）では、そのオーバーヘッドがコストと消費電力に直結する。数十億ユーザーへのリアルタイムAI応答を支えるとなれば、専用設計チップへの移行は理にかなった選択だ。 カスタムシリコン戦略の構造 メタが目指すアーキテクチャの骨格は以下のようなものとみられる： 学習（Training）: 引き続きNVIDIA GPUクラスターを活用しつつ、将来的には独自チップへの置き換えも視野に 推論（Inference）: ブロードコムとの協業で設計した専用ASICで低レイテンシ・低コストを実現 ネットワーク基盤: ブロードコムが強みを持つ高速スイッチング技術で、チップ間通信のボトルネックを解消 GoogleがTPUでやり遂げ、Amazonが「Trainium」「Inferentia」で追いかけ、AppleがNeural Engineで独自路線を確立したパターンを、今度はメタが本格的に踏もうとしている。 実務への影響——日本のエンジニア・IT管理者はどう読む？ このニュースは一見「テック巨人同士の話」に見えるが、日本のIT現場にも無関係ではない。 クラウドAIサービスのコスト構造が変わる: MetaはFacebook・Instagram・WhatsAppを通じてAIレコメンデーション、コンテンツモデレーション、広告最適化を巨大スケールで動かしている。カスタムシリコンによるコスト削減が実現すれば、メタのAIプラットフォームを利用するビジネスへの価格競争力が増す。 「AIはNVIDIAがすべて」という前提が崩れる: エンタープライズがAI基盤を設計するとき、GPUクラスター一辺倒ではなく推論専用アクセラレータとの組み合わせを検討する流れが加速する。AWSのInferentia、GoogleのTPU、AzureのMaia 100と同様に、「用途に応じたシリコン選択」が当たり前になっていく。 オープンソースLLMとの関係: メタはLlamaシリーズをOSSで公開している。自社シリコンに最適化されたLlamaモデルが出てくれば、オンプレミスや独自クラウドでLlamaを動かしている企業は最適化の恩恵を受けられる可能性もある。 ## 筆者の見解 「統合プラットフォームの全体最適」という観点から言えば、メタのこの判断は非常に筋が通っている。汎用部品を組み合わせた部分最適を積み重ねても、スケールが上がるほど全体コストは膨らむ。自社ワークロードに最適化された専用シリコンを持つことで、はじめて全体が効率化される。 興味深いのは、このアプローチがソフトウェア企業の「AIインフラの内製化」という大きなトレンドの一環だという点だ。今後は「AIを使う」だけでなく、「AIを支えるインフラを誰が設計するか」が競争の主戦場になっていく。 日本企業の多くは依然として「クラウドベンダーにすべてお任せ」の段階にある。それ自体は悪くない選択だが、インフラの主導権がどこにあるかを理解した上で採用するのと、単に惰性で選ぶのとでは、5年後のポジションが大きく変わってくる。 メタとブロードコムの動きは、「仕組みを設計できる少数の組織」と「仕組みを使わせてもらう多数の組織」という分断をさらに加速させるかもしれない。それを他人事として眺めるのか、自分たちのアーキテクチャを問い直すきっかけにするのか——その判断こそが、これからのIT組織の命運を分けると思っている。 出典: この記事は Zuckerberg taps Broadcom to build a massive AI silicon empire for billions of users の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは最新の累積更新プログラムKB5083769をWindows 11向けにリリースし、リモートデスクトップ（RDP）の動作に大きな変更を加えた。テレワークが定着した日本のIT現場では直接影響を受ける可能性が高く、IT管理者はこの変更内容を早めに把握しておきたい。 KB5083769が変えるリモートデスクトップの何か このアップデートにおけるリモートデスクトップの変更は、主に以下の3点に集約される。 接続フローの刷新 RDPクライアントの接続シーケンスが見直された。従来の動作と比較して、認証フェーズのタイミングや資格情報の受け渡し方法が変更されており、特定の環境では接続確立までの挙動が変わる場合がある。グループポリシーや条件付きアクセス（Conditional Access）と組み合わせている環境では動作確認を推奨する。 ネットワークレベル認証（NLA）の動作調整 NLA（Network Level Authentication）まわりの処理が調整されており、セキュリティ強度を維持しながらも互換性を改善する方向で手が入っている。古いRDPクライアントとの相互接続性に影響が出るケースが報告されているため、社内にWindows 10以前のクライアントが混在する環境では十分な検証が必要だ。 資格情報の保護強化 Credential Guardとの連携部分でも変更が加わっており、資格情報のメモリ保護の観点で強化が図られている。これはPass-the-Hash攻撃への対策として正しい方向性であり、ゼロトラスト的なアーキテクチャを推進している組織にとっては歓迎できる変更だ。 実務への影響——日本のエンジニア・IT管理者にとっての意味 リモートデスクトップは日本の企業環境で依然として広く使われている。クラウドファーストを掲げつつも、オンプレミスのWindows Serverへのリモートアクセス手段としてRDPが生き残っているケースは多い。以下の点を確認しておくことを強く推奨する。 今すぐ確認すべき項目： テスト環境でKB5083769を先行適用し、既存のRDP接続が正常に動作するか確認する。特にAzure Virtual DesktopやWindows 365をRDP経由で利用している環境は優先度を上げる **グループポリシーのコンピューターの構成 > 管理用テンプレート > Windowsコンポーネント > リモートデスクトップサービス**配下の設定項目を見直し、意図しないオーバーライドがないか確認する サードパーティのRDPクライアント（FreeRDP等）を使用している場合は互換性テストを実施する Windows Updateの展開タイミングを組織内で調整し、RDPが業務クリティカルな環境への適用は段階展開にする 設定変更を要するケース： NLAが無効化されているレガシー環境では、この機会に有効化を検討する（無効のままでは接続できなくなるリスクが今後高まる） 多要素認証（MFA）をRDP接続に組み合わせていない環境は、Microsoft Entra ID（旧Azure AD）の条件付きアクセスとの統合を検討するタイミングだ ## 筆者の見解 リモートデスクトップまわりのセキュリティ強化は、個人的には明確に支持する。特に資格情報保護の強化はゼロトラスト実現に向けた重要なピースであり、「常時アクセス権を与えてVPNで囲む」という古いモデルから脱却するうえで不可欠な変化だ。 ただし、日本の企業IT現場の現実を見ると、この手の変更が「突然RDP接続できなくなった」という問い合わせ爆発につながることは容易に想像できる。MicrosoftがKBのドキュメントで変更内容を詳細に公開している姿勢は評価したいが、ユーザーへの事前周知という点ではまだ改善の余地がある。 Windows Updateについては以前から「数日様子を見る選択肢も立派なセキュリティ判断」と考えているが、セキュリティ修正を含む更新は早期適用が原則だ。今回のケースは接続互換性への影響があるため、「まず検証環境に当てて確認する」というプロセスを踏む価値がある。 長期的には、RDPという30年選手のプロトコルに依存し続けるアーキテクチャ自体を見直すべきだろう。Azure Virtual DesktopやWindows 365への移行が進めば、こうした個別のKB変更に翻弄されるリスクも減る。この更新を「既存環境の棚卸し」のきっかけにしてほしい。 出典: この記事は Microsoft details Windows 11 KB5083769 Remote Desktop changes の内容をもとに、筆者の見解を加えて独自に執筆したものです。

SQL Serverを日常的に扱うデータベース管理者・開発者にとって、SQL Server Management Studio（SSMS）のアップデートは地味だが確実に業務効率に効いてくる出来事だ。Microsoftは今月、SSMS 22.5を公開した。移行作業の合理化、SQLプロジェクト機能の強化、全体的な生産性向上がこのリリースの柱となっている。 SSMS 22.5の主な改善点 マイグレーション支援の強化 オンプレミスのSQL ServerからAzure SQL Database、Azure SQL Managed Instance、またはより新しいSQL Serverバージョンへの移行を支援する機能が強化された。移行アセスメントの精度向上と、移行前の互換性チェックが改善されており、「移行してみたら動かなかった」という事態を未然に防ぎやすくなっている。 日本のエンタープライズ環境では、SQL Server 2012や2014といった長期サポート終了済みバージョンがいまだ現役稼働しているケースが珍しくない。こうした環境からのリフトアップを検討している担当者にとって、移行前の影響調査ツールが充実することは直接的なメリットになる。 SQLプロジェクト機能の改善 SQL Projectsは、データベーススキーマをソースコードとして管理する仕組みで、DevOpsパイプラインへのDB定義の組み込みを可能にする。SSMS 22.5ではこのプロジェクト機能のUI操作性が向上し、スキーマ変更の追跡・比較・展開がよりスムーズに行えるようになった。 インフラやアプリコードはGitで管理しているのに、DBスキーマだけは属人的な手順書で管理——という二重管理の非効率は多くの現場で生じている。SQLプロジェクト機能を活用すれば、この課題にアプローチできる。 全体的な安定性・UXの改善 クエリエディタのIntelliSense応答性の向上、オブジェクトエクスプローラーの読み込み速度改善、一部の接続エラー修正なども含まれる。地道な改善だが積み重ねで体験は変わる。 実務への影響 DB管理者・DBAへ 移行アセスメント機能を使って、現行環境の互換性リスクを棚卸ししておくタイミングとして最適だ。特にSQL Server 2016以前のバージョンを運用している組織は、延長サポート終了のカウントダウンが迫っており、早期調査に越したことはない。 開発者・DevOpsエンジニアへ SQL Projectsをまだ使っていないなら、このリリースを機に試してみる価値がある。スキーマのバージョン管理は「ベストプラクティス」の話ではなく、CI/CDパイプラインの完成度に直結する実務課題だ。Azure DevOpsやGitHub ActionsとSQL Projectsを組み合わせれば、スキーマ変更のレビュー→テスト→本番展開を自動化できる。 IT管理者へ SSMS 22.xは.NET 8ベースに刷新されており、SSMS 18.x以前とは構造が大きく異なる。まだ旧バージョンを使い続けている環境は、バージョン共存に注意しつつ計画的な移行を検討したい。 筆者の見解 SSMSは長い間「使えるが重い、UIも古い」というイメージを持たれてきたツールだ。22.x系への刷新でその印象はかなり改善されつつあり、22.5もその延長線上にある地道なアップデートだと評価している。 個人的に注目しているのは、マイグレーション支援の継続的な充実だ。日本のSQL Server運用現場では、クラウド移行の「必要性は分かっているが踏み出せない」という状況が長く続いている。アセスメントツールが使いやすくなることで、「まず現状を可視化する」という最初の一歩が踏み出しやすくなる。Microsoftにはこの方向の投資をぜひ続けてほしい。 一方、SQLプロジェクトとDevOpsの統合については、まだ「使いこなせている現場が少ない」印象がある。ツールが整備されても、組織の習慣が追いつかなければ意味がない。この領域でのドキュメント整備や日本語情報の充実に期待したい。 SSMSは地味なツールだが、SQL Serverが現役で動いている現場は日本にまだ無数にある。そのエコシステムを着実にメンテし続けているMicrosoftの姿勢は、素直に評価できる点だ。 出典: この記事は SQL Server Management Studio 22.5 now out, here is what’s new の内容をもとに、筆者の見解を加えて独自に執筆したものです。

WordPressの人気フォームビルダープラグイン「Ninja Forms」のFile Upload拡張機能に、CVSS スコア 9.8 という最高クラスの深刻な脆弱性が発見された。認証なしにサーバー上へ任意のファイルをアップロードできるこの欠陥は、すでに実際の攻撃に悪用されており、日本を含む世界中のWordPressサイト管理者にとって緊急対応が求められる事態となっている。 脆弱性の詳細：何が問題だったのか 今回の脆弱性（CVE-2026-0740）は、Ninja Forms File Upload バージョン 3.3.26 以前に存在する。問題の核心は、ファイルアップロード処理におけるファイル種別・拡張子の検証が完全に欠如していたことだ。 Wordfenceの研究者の解析によると、ファイルを移動する処理において、移動先ファイル名に対するファイルタイプや拡張子のチェックが一切実装されていなかったという。これにより、攻撃者は .php 拡張子を持つファイル——つまりPHPスクリプト——をそのままサーバー上にアップロードできてしまう。 さらに問題を深刻にしているのがパストラバーサル（Path Traversal）の組み合わせだ。ファイル名のサニタイズ処理も行われていないため、アップロード先のパスを操作してWebルートディレクトリにファイルを配置することすら可能になる。攻撃のシナリオを整理すると： 認証なしに悪意あるPHPスクリプトをアップロード パストラバーサルでWebからアクセス可能なディレクトリに配置 そのURLにブラウザやcurlでアクセスするだけでリモートコード実行（RCE）が成立 この流れは教科書的なWebシェル設置攻撃そのものであり、成功した場合はサイトの完全乗っ取りにつながる。 発見から修正までのタイムライン セキュリティ研究者のSélim Lanouar氏（whattheslime）が2026年1月8日にWordfenceのバグバウンティプログラムへ報告。同日のうちにベンダーへ詳細が開示され、Wordfenceはファイアウォールルールによる暫定的な保護をユーザーへ展開した。 2月10日に部分的な修正が行われ、最終的な完全修正版（バージョン 3.3.27）が3月19日にリリースされた。発見から修正まで約70日。速いとは言えないが、バグバウンティ経由での調整プロセスとしては標準的な範囲だろう。 深刻なのはその後だ。修正版が公開されてから2週間以上が経過しているにもかかわらず、Wordfenceは直近24時間だけで3,600件以上の攻撃をブロックしていると報告している。File Upload拡張機能の利用者は約9万件。更新が完了していないサイトが相当数残っていることが、これだけの攻撃頻度から見てとれる。 実務への影響：WordPress運用者が今すぐやるべきこと 即時対応（今日中に） Ninja Forms File Upload を使用している場合、バージョンを 3.3.27以上 に更新する 更新前後でファイルアップロード機能の動作確認を実施する サーバーのアクセスログを遡り、不審なPHPファイルへのPOSTリクエストがないか確認する アップロードディレクトリに .php 拡張子のファイルが存在しないか確認する 中期的な対策 WordPressのアップロードディレクトリには、PHPの実行を禁止する .htaccess を設置しておくことを強く推奨する。これは今回のような脆弱性が将来再発した際の多層防御（Defense in Depth）として機能する。 出典: この記事は Hackers exploit critical flaw in Ninja Forms WordPress plugin の内容をもとに、筆者の見解を加えて独自に執筆したものです。

米国の暗号資産取引所Krakenが、インサイダー脅威を起点とした恐喝被害を公表した。CSO（最高セキュリティ責任者）のNick Percoco氏が声明を発表し、内部システムへのアクセス映像を公開すると脅す犯罪グループの存在を明かした。「システムそのものは侵害されていない」「資金は安全だ」とする一方で、「支払わない・交渉しない」という明確な姿勢を打ち出している。 暗号資産業界特有の話に見えるかもしれないが、この事件の構造はあらゆる業界のIT担当者にとって他人事ではない。 何が起きたのか 2025年2月、信頼できる情報筋から「クライアントサポートシステムへのアクセスを示す映像が犯罪グループ間で出回っている」という提供を受けたKrakenは調査を開始。その結果、脅威アクターに採用・買収されたサポート従業員1名が特定された。 その後、さらに別の映像が出回っていることが判明し、2件目の不正アクセスも確認。いずれも迅速に当該従業員のアクセスを剥奪し、影響を受けたユーザーへの個別通知を行った。 影響を受けたアカウントは約2,000件（全ユーザーベースの0.02%）で、露出した情報はクライアントサポートデータに限定。顧客資金へのリスクはなかったとしている。Krakenは現在、複数の司法管轄にまたがる連邦法執行機関と連携して法的措置を進めているという。 インサイダー脅威という構造的問題 今回の手口は「従業員をスカウト・買収して内部アクセスを得る」という古典的かつ非常に有効なアプローチだ。技術的な防御が強固になればなるほど、攻撃者は人間という最も管理しにくいポイントを狙う傾向が強まる。 同じく暗号資産交換所のCoinbaseでも2025年中旬に類似の事件が発生している。インド拠点のカスタマーサポート代理店の従業員が買収され、約7万人の顧客情報が流出。Coinbaseは損害総額を約4億ドルと試算した。 業界や規模は異なっても、この構造は共通している。外部の技術的境界線を突破できなければ、人を使って内側から扉を開けようとする——これが現代の攻撃シナリオの現実だ。 最小権限とJust-In-Timeアクセスが鍵 サポート従業員が「アクセスすべきでないデータにアクセスできた」という事実こそが問題の核心だ。技術的な制御がどこかで機能していれば、内部不正はここまでスムーズには進まなかったはずだ。 ここで重要になるのが最小権限の原則（Principle of Least Privilege）とJust-In-Time（JIT）アクセスだ。常時アクセス権を付与しておくことは、インサイダー脅威に対してほぼ無防備に等しい。「必要な時に、必要なスコープだけ、期限付きで付与する」設計が、ダメージの最小化に直結する。 あわせて、UEBA（User and Entity Behavior Analytics）によるアクセスログの常時監視と異常パターン検知も有効だ。不正が行われたとしても早期検知できれば、被害拡大を防げる可能性が大きく高まる。 日本のIT現場への影響 日本の大企業では、従来のネットワーク境界型セキュリティとゼロトラストの考え方が中途半端に混在しているケースが多い。「社内ネットワーク内なら信頼できる」という思想が残っていると、インサイダーによる不正アクセスを技術的に防ぐ仕組みが機能しない。 クラウドサービスや外部委託パートナーが当たり前になった今、「誰がどのデータに触れられるか」を厳密に管理するIAM（Identity and Access Management）の整備は待ったなしだ。SaaSのカスタマーサポートやヘルプデスク業務を外部委託している組織は特に、データスコープの設計とアクセス制御の粒度を今すぐ見直してほしい。 Krakenの対応自体は迅速だった。アクセス剥奪・調査・ユーザー通知・法執行機関との連携——いずれも教科書通りのインシデントレスポンスだ。「払わない・交渉しない」という姿勢も正しい。恐喝に応じることは次の攻撃を招くだけだ。 筆者の見解 今回の事件が示す最も重要な教訓は、「技術的に堅牢なシステムでも、アクセス権を持つ人間が弱点になりうる」という当たり前の事実だ。そして、この問題に対する答えは「人を信頼しない設計」にある。これは人間不信ではなく、構造として不正を難しくするということだ。 少し気になる点がある。1件目の対応後、なぜ同じ経路での再発を防ぐ仕組みが機能しなかったのか——外部からは見えない部分だが、2件目が発覚してからの公表という経緯には再発防止策の実効性という観点で問うべき点が残る。 インサイダー脅威への対策として明日から取り組めることを整理する： 常時アクセス権の棚卸し: サポート担当者が「見える必要のないデータ」にアクセスできていないか確認する JITアクセスの導入検討: Azure AD（Entra ID）のPIM（Privileged Identity Management）などを活用し、昇格アクセスに承認フローと有効期限を設ける 操作ログの可視化と自動アラート: 通常業務では発生しないアクセスパターンを検知する仕組みを整備する 外部委託先のアクセス範囲の見直し: 委託先従業員のアクセス制御は自社従業員と同等以上に厳格に 技術的な境界線を固めた次のフロンティアは、確実に「人」だ。セキュリティ投資を考える際、このインサイダー脅威という視点を必ず組み込んでほしい。 出典: この記事は Crypto-exchange Kraken extorted by hackers after insider breach の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Disneyがまた静かにSteamのライブラリを縮小させた。今回の削除対象は15本に上り、Star Warsシリーズをはじめとした映画タイアップ作品やクラシックタイトルが含まれる。公式なアナウンスも、理由の説明も一切ない。ユーザーが気づいたのは、ストアページが消えていたからだ。 何が消えたのか 今回の一斉削除は「最初の波」ではない。Disneyはここ数ヶ月で段階的にSteamからタイトルを取り下げており、今回はその延長線上にある。対象作品には長年ファンに親しまれてきたゲームが多く含まれ、すでに購入済みのユーザーについても今後のサポートや動作保証が不透明な状況だ。 削除の背景として考えられる要因はいくつかある。 ライセンス期限切れ: 映画タイアップ作品は音楽・映像素材のライセンスが複雑で、更新コストが見合わないと判断されることがある Disney+への統合戦略: コンテンツをストリーミングプラットフォームに集約し、ゲームも独自チャンネルに誘導する意図がある可能性 保守コストの問題: 旧来のゲームエンジンや32ビット対応など、維持に工数がかかるタイトルを整理している いずれも推測の域を出ないのは、Disneyが何も語っていないからだ。 デジタル所有権という幻想 この件で改めて浮き彫りになるのは、デジタルコンテンツの「購入」は実質的にライセンスの取得に過ぎないという現実だ。 Steamで5,000円払ってゲームを「買った」としても、パブリッシャーがストアから引き上げれば新規購入はできなくなる。すでにライブラリに入っているタイトルは引き続き遊べる場合が多いが、OSのバージョンアップや端末の変更によって動作しなくなるリスクは常にある。 物理メディアと異なり、デジタル購入には「手元に残る」という確実性がない。これはゲームに限らず、電子書籍・動画・音楽にも共通する構造的な問題だ。 実務への影響——IT担当者・開発者の視点 一見「ゲームの話」に見えるが、この問題はエンタープライズのIT運用とも地続きだ。 クラウドサービス依存のリスク管理 SaaSやクラウドサービスも、ベンダーの事業判断次第でいつでも仕様変更・廃止になりうる。「今動いているから大丈夫」という感覚は危険で、代替手段の確保と依存度の可視化が常に必要だ。 契約・ライセンス条件の精査 「購入」と「ライセンス取得」の違いを契約書レベルで理解しておくことは、個人だけでなく法人調達でも重要な視点になっている。 データポータビリティの確保 ゲームセーブデータのみならず、業務データについても「サービスが消えたときに自分のデータを取り出せるか」を事前に確認しておくべきだ。 筆者の見解 ゲーム産業におけるデジタル移行は、便利さと引き換えに「永続性の保証」を手放させた。ディスクがあれば20年後でも遊べる。しかしデジタル購入は、パブリッシャーのビジネス判断に全面依存している。 Disneyの今回の対応で残念なのは、説明がないことだ。理由がライセンス問題であれコスト問題であれ、誠実に伝えることはできたはずで、そこを省いたのはユーザーへの敬意という点でもったいない判断だと思う。 より広い文脈で言えば、このような事例が積み重なるたびに「デジタルコンテンツを信頼してよいのか」という問いが強くなる。プラットフォームと権利者が協力してユーザーの「買ったものは残る」という合理的な期待に応えていく仕組みを業界全体で整えていくことが、長期的な信頼構築につながるはずだ。 ゲームの保存・アーカイブに取り組むコミュニティの存在は、こうした問題への一つの答えでもある。技術的な記録を後世に残すという意味でも、デジタル保存の議論はこれからも重要であり続けるだろう。 出典: この記事は Disney delists 15 more classic games from Steam without an explanation の内容をもとに、筆者の見解を加えて独自に執筆したものです。