アカウントが1つ。
すべてが失われる？
そうとは限りません。
NIS2は10項目のリスク管理措置を求めています。Managed Red TenantとDark Tenantで、その技術的な実装を支援します。攻撃リスクを大きく下げ、万一のときも数時間で業務を再開できる確かさが手に入ります。
2026年3月11日のStryker攻撃で興味深いのは、被害を受けた端末の数ではありません。79か国で8万台という数字は確かに目を引きますが、注目すべきは手口の平凡さです。エクスプロイトもゼロデイもなく、ごく一部の人しか知らないインフラ部品を狙った手の込んだ攻撃もありませんでした。侵害されたIntune管理者アカウントが1つあれば十分で、外から見た攻撃の様子は通常の運用と変わりませんでした。技術的な意味ではまさに通常の運用であり、ただ実行者が別人だっただけです。何が起きたのかはStryker攻撃に関するブログ記事で説明しています。
多くの企業インフラは、この規模の被害が起こりうる形で組み上がっています。担当者が怠慢だったからではなく、広範な権限を持つ特権アカウントが長年にわたって便利なものとして扱われてきたからです。どこにでもアクセスできるアカウントは日々の作業時間を節約してくれますし、IT部門において時間は、予算よりもさらに足りない唯一のものです。NIS2第21条は、この慣行から結論を引き出しています。特権IDは、侵害されてもインフラ全体を道連れにしない形で分離されていなければならず、それでも被害に遭った場合は数時間で業務を再開できなければなりません。
NIS2とは何か、誰が対象になるのかはこちらで説明しています。このページで扱うのは、Managed Red TenantとManaged Dark Tenantによるリスク管理措置の技術的な実装支援です。
Managed Red Tenant：侵害された1つのアカウントをマスターキーにしないために
Stryker事件で通用した攻撃パターンは、目新しいものではありません。攻撃者は特権システムへのアクセスを与えるアカウントを侵害し、そこから残りのインフラへ移動して、最も多くの権限を握っている領域で被害を出します。この手口が確実に通用するのは、多くの企業で通常の業務環境と、インフラ全体の乗っ取りに足りてしまう管理用アクセスとのあいだに、構造的な分離が存在しないからです。
Managed Red Tenantは、管理用のIDとそれに紐づく端末を完全に分離されたMicrosoftテナントへ移すことで、このパターンを断ち切ります。専用のEntra IDアカウントと専用の堅牢化された端末を用意し、攻撃者がラテラルムーブメントに使えるような本番環境へのネットワーク接続は持ちません。侵害された標準の業務端末から重要システムへたどり着こうとすると、そこには以前は存在しなかった境界が現れます。
Managed Red Tenantを見る
Managed Dark Tenant：起きてほしくはないが、起こりうる事態のための備え
大規模なランサムウェア攻撃のあと、企業が処理しなければならない問題は2種類に分かれます。1つは技術的な問題で、速くはないにせよ解決できます。もう1つは組織的な問題で、非常時に誰が何をするのか、どの順番で意思決定するのか、自社のインフラが信用できなくなったときに何を土台に連絡を取るのかを、誰も事前に決めていません。Covewareはランサムウェア攻撃後の平均停止期間を24日としていますが、実際のインシデント対応の経験からわかるのは、時間を奪うのは主に技術的な手段の不足ではなく、平常時には一度も必要にならないプロセスを、極度の圧力のもとで初めて考え出さなければならないことです。
Managed Dark Tenantは、あらかじめプロビジョニングされた完全に隔離されたMicrosoft環境です。非常時には24時間365日対応のホットラインを通じて起動し、数時間以内に危機対応チームへ、すぐ使えるコミュニケーション手段、Windows 365の作業環境、ADの復旧パイプラインを提供します。すべてInfrastructure as Codeに基づいており、必要になる前に定義とテストを済ませてあります。背後にある設計原則はMinimum Viable Companyです。まず連絡手段、次に重要文書、そして基幹アプリケーションという順序を事前に定め、定期的にファイアドリルで確かめておきます。
Managed Dark Tenantを見る技術的な実装を支援します
| Risk Measures | GK Services | NIS2 | CSOC | APT Response | Preventive Services | Managed Red Tenant | Managed Dark Tenant | Data Security | Workplace / Azure |
|---|---|---|---|---|---|---|---|---|
| Risk Analysis and Information System Security | 21.2 a) | |||||||
| Incident Handling | 21.2 b) | NEU | NEU | |||||
| Business Continuity | 21.2 c) | NEU | ||||||
| Supply Chain Security | 21.2 d) | NEU | ||||||
| Security in Network and Information Systems | 21.2 e) | |||||||
| Effectiveness of Cybersecurity Risk Management Measures | 21.2 f) | NEU | NEU | |||||
| Basic Computer Hygiene Practices and Cybersecurity Training | 21.2 g) | |||||||
| Cryptography | 21.2 h) | |||||||
| Human Resources Security, Access Control Policies and Asset Management | 21.2 i) | NEU | ||||||
| Multifactor Authentication or Secured Communication | 21.2 j) | NEU |
2つのサービス、NIS2第21条への1つの答え
Managed Red Tenant
特権IDと端末を、本番環境へのネットワーク接続を持たない完全に分離されたMicrosoftテナントに置きます。ラテラルムーブメントはなく、侵害された標準アカウントがマスターキーになることもありません。
Managed Dark Tenant
あらかじめプロビジョニングされた隔離済みのMicrosoft環境を、非常時に24時間365日対応のホットラインで起動します。コミュニケーション手段、Windows 365の作業環境、ADの復旧パイプラインは、必要になる前に定義とテストを済ませてあります。
MRTとMDTの組み合わせ
Red Tenantは、攻撃がインフラ全体に及ぶ確率を下げます。Dark Tenantは、それでも及んでしまったときの停止期間を縮めます。NIS2があろうとなかろうと、この2つの組み合わせは規制上の圧力とは関係なく理にかなっています。
関連する記事
管理業務と日常業務を1台のPCで。Game Overです。
CIOにとってテナントが1つでは足りない理由と、2つ目がめったに検討されない理由。Managed Red Tenantは管理業務をオフィス環境からアーキテクチャとして分離し、Managed Dark Tenantは防御が破られてもなお組織が動き続けられるようにします。それが運用モデル、SOCのシグナル、そしてNISG 2026による証明義務にとって何を意味するのかを解説します。