NIS2指令は、サプライチェーンリスク管理、インシデント報告、取締役会レベルの説明責任にわたって、組織に直接的な義務を課しています。10月にはEU全域で新たな法的拘束力を持つ期限が到来し、加盟各国は国内法への移行段階から施行段階へと移っていきます。オーストリアでは国内実施法が採択され次第施行され、ポーランドでは国内当局が定めた特定の日付をもって義務的な自己登録が締め切られます。
NIS2への広範な不遵守は、重要事業体には最大1,000万ユーロまたは世界売上高の2%、重要性の高い事業体には最大700万ユーロまたは1.4%の制裁金を科す可能性があり、経営陣個人には、経営幹部職からの一時的な追放を含む個人的責任が及ぶ恐れがあります。
ほとんどの組織は、自分たちがコンプライアンス対応をしなければならないと理解しています。難しいのは、最初の監査を迎える前にチームを疲弊させることなく、どこから着手すべきかという点です。
企業がすべてを一度に片付けようとするのは現実的ではありません。実践的な進め方は、迅速に導入でき、監査で使える証拠を即座に生み出し、かつ最も重要な攻撃経路を塞げる統制を見極めることです。
アクセス管理と認証情報の衛生管理は、この3つの条件すべてに当てはまります。NIS2の全要件をカバーするわけではありませんが、他のほぼどの単一投資よりも、より遠くまで、より速く到達できるでしょう。
なぜ認証情報が依然としてボトルネックなのか
2026年版Verizonデータ侵害調査報告書(DBIR)によると、脆弱性の悪用が単一の初期侵入経路として盗まれた認証情報を上回り、侵害全体の31%を占めるトップとなりました。しかし、この結果を根拠に認証情報の統制の優先度を下げるのは誤った判断です。
DBIR自体のデータも、焦点を初期アクセスの枠組みから広げてみると異なる姿を示しています。攻撃チェーン全体で見た場合、認証情報の悪用は全侵害の39%に登場します。Verizonはこれを明確に「正当な緩和策の標的となるボトルネック」だと位置づけています。認証情報は単に玄関を開けるだけでなく、攻撃者が内部に侵入した後、建物内を移動するための手段でもあるのです。
NIS2の第21条における2つの要件の実施タイムラインを比較してみましょう。
- サプライチェーンリスク管理(第21条2項(d)) — 6~12か月
- アクセス制御の実施(第21条2項(i)) — 2~4週間
Active Directory全体にきめ細かなパスワードポリシーを適用し、共有認証情報を管理型のボールトに移行し、特権アカウントにフィッシング耐性のあるMFAを有効化することは、有能なチームであれば2~4週間で完了するプロジェクトです。コンプライアンス対応の労力に対するROIは、比較にならないほど大きいと言えます。
事前監査で失敗する3つのアクセス管理上の欠陥
1. 管理されていないサービスアカウントとAPIキー
NIS2のアクセス管理に関する議論の多くは、人間のユーザーに焦点を当てています。しかし監査官はますますそこにとどまらなくなっています。サービスアカウント、APIキー、データベース接続文字列、デプロイトークンといった非人間アイデンティティは、人間のアカウントであれば到底許されないような形で、日常的に管理が行き届いていません。
一般的な中堅規模の組織では、サービスアカウントの数が人間のアカウント数を上回っています。共有パスワードの大半は一度もローテーションされておらず、担当者も明記されていません。こうした認証情報は.envファイル、CI/CDパイプラインの設定、共有ドライブといった、攻撃者が初期侵入後にまさに真っ先に探す場所に置かれています。
第21条2項(i)は、ネットワークおよび情報システムにアクセスするすべてのアカウントをアクセス制御ポリシーの対象とすることを求めています。「すべてのアカウント」にはサービスアカウントも含まれます。これらを洗い出せなければ管理することはできませんし、監査官に統制を証明することもできません。
対策はまず棚卸しから始まります。ADからすべてのサービスアカウントを、シークレットストア(あるいは現在ハードコードされている設定ファイル)からすべてのAPIキーを抽出し、ローテーションスケジュールと担当者を明記した管理システムに取り込みましょう。
2. 休眠アカウントとオフボーディングの不備
休眠アカウントとは、実在し、有効な認証情報を持ちながら、もはやアクセスを必要としない人物に紐づいたアカウントを指します。退職した元従業員、契約が終了した業務委託先、6か月前にプロジェクトが終了したベンダーなどです。こうしたアカウントは、アクセス制御ポリシーにライフサイクル管理を含めることを求める第21条2項(i)のもとで、監査における直接的な失格ポイントとなります。
オフボーディングの失敗は、悪意によるものであることはほとんどありません。手続き上の問題です。人事がチケットを閉じ、IT部門がActive Directoryのアカウントを無効化しても、その人物がデータベースへの直接アクセス権、VPN証明書、AWSのIAMユーザー、あるいは本番サーバー3台分のSSH鍵を持っていたかどうかを確認する人は誰もいません。それぞれが個別に取り消す必要のある認証情報であり、ほとんどの組織ではこれらすべてを一元的に追跡できるシステムが存在しません。
アクセスレビューは文書化され、エクスポート可能な状態でなければなりません。監査官が求めるのは、メールのやり取りではなく、明確なレビュー履歴を備えたレポートです。
3. フィッシング耐性のあるMFAの欠如
第21条2項(j)は「適切な場合」にMFAを求めています。ENISAのガイダンスや、より広い規制の方向性からも、「適切な場合」にはすべての特権アクセスと、重要システムへのすべてのリモートアクセスが含まれることが明らかにされています。こうした文脈においては、SMSによるワンタイムパスワードはもはや十分とは言えません。
NIST SP 800-63B(5.2.10節)は、SIMスワッピングやSS7傍受のリスクを理由に、SMSベースのOTPを明示的に制限付き認証手段に分類しています。フィッシング耐性のあるMFA、すなわちFIDO2/WebAuthn、ハードウェアセキュリティキー、証明書ベースの認証こそが、厳しい審査に耐えうる基準です。
多くの組織はMFAを広く導入済みですが、それでもレガシーシステムや共有アカウント、サービスアカウントについては例外を認めているケースがあります。こうした例外は監査官の厳しい目を引くため、技術的な統制と文書化された承認プロセスの両方が求められます。
統制を一元化する単一のポイント
この3つの欠陥にはいずれも共通点があります。それは、認証情報を追跡し、アクセスポリシーを実施し、エクスポート可能な証拠を生成する単一のシステムが存在しないという点です。Passworkはこの課題に直接対応します。
- サービスアカウントのパスワード、APIキー、証明書を、シークレットごとの所有者記録とローテーションスケジュールを備えたセルフホスト型ボールトに保管
- ライフサイクル管理のためのRBACおよびAD/LDAP連携
- ボールトへのアクセスにおけるフィッシング耐性のあるMFAのための、WebAuthnおよびハードウェアセキュリティキーのサポート
- 監査ログがすべての操作をタイムスタンプ付きで記録するため、四半期ごとのアクセスレビューは手作業ではなくレポートのエクスポートで済みます
証拠の問題
統制を備えていることと、統制を証明できることは別問題です。多くの組織が事前監査でつまずくのはまさにこの点です。統制そのものが存在しないのではなく、証拠が存在しないのです。
NIS2第32条は、実施済みのセキュリティ対策に関する文書の提出を要求する権限を所轄当局に与えています。文書化とは、ポリシー本文、それを実施する技術的統制、そしてその統制が実際に稼働し、イベントを生成してきたことを示すログを意味します。
認証情報とアクセス管理について、監査官は以下を求めます。
- アクセス制御ポリシー — 文書化され、バージョン管理され、経営陣によって承認されたもの
- 技術的な実施証拠 — ADのきめ細かなパスワードポリシー設定、MFA登録レポート
- アクセスレビュー記録 — 誰が、いつレビューし、何が取り消されたか
- 所有者情報を含む特権アカウントの棚卸し
- サービスアカウントおよびAPIキーの認証情報ローテーションログ
- 完了日時を含むオフボーディング記録
ログとして記録され、エクスポート可能でなければ、監査官の視点からは存在しないのと同じです。目指すべきは、通常業務の副産物として証拠を自動的に生成するシステムです。
認証情報コンプライアンスへの5つのステップ
ステップ1. すべてを棚卸しする。
存在するものをマッピングします。共有アカウント、サービスアカウント、APIキー、そして管理システムの外側、たとえばスプレッドシートやメール、.envファイルに保管されている認証情報などです。この棚卸しが、あなたの基準線であり、最初の証拠資料となります。
ステップ2. 一元化された認証情報ボールトを導入する。
AES-256暗号化、RBAC、AD/LDAP連携をサポートするソリューションを選びましょう。組織階層を反映するようにボールトの構造を設定します。セルフホスト型の導入であれば、データ主権を確保でき、認証情報をサードパーティのクラウドサービスに保管することを禁じる社内セキュリティポリシーにも適合します。Passworkは、まさにこの導入モデル向けに設計されたプラットフォームの一例で、セルフホスト、AES-256暗号化に加え、RBACとAD/LDAP連携を標準で備えています。
ステップ3. MFAと最小権限アクセスを徹底する。
初日からすべてのボールトアクセスにMFAを有効化します。権限はロール単位で割り当てましょう。最小権限の原則を適用し、各ユーザーおよびサービスアカウントには、その役割に必要な範囲だけのアクセス権を与えます。ロールマトリクスを文書化してください。これが第21条2項(i)のアクセス制御に関する証拠となります。
ステップ4. 管理されていないシークレットをボールトに移行する。
APIキー、データベース認証情報、証明書、サービスアカウントのパスワードをボールトに移行します。.envファイルや共有スプレッドシートは廃止しましょう。可能な範囲でローテーションポリシーを設定します。
ステップ5. 監査ログを設定し、定期的なレビューをスケジュールする。
完全な監査ログを有効化し、導入直後にコンプライアンスレポートをエクスポートします。四半期ごとのアクセスレビューをスケジュールし、休眠アカウント、過剰な権限を持つロール、90日以上アクセスされていない認証情報を確認しましょう。各レビューサイクルは、継続的なコンプライアンスを示す日付入りの証拠資料を生み出します。これはまさに第32条の施行が求めるものです。
どこから始めるべきか
NIS2の監査で苦戦することになる組織は、セキュリティが不完全な組織ではありません。証拠を持たない組織です。IBMの「2026年データ侵害コストレポート」によれば、世界平均の侵害コストは499万ドルに上りますが、侵害をより速く封じ込められる組織は、一貫して自社の認証情報がどこにあるかを可視化できている組織です。
サプライチェーンリスク、インシデント対応、取締役会レベルのガバナンスといった、より困難なNIS2の作業も並行して進める必要があります。しかし、認証情報管理こそが、最初に証明可能な成果を得られる領域です。
まずは棚卸しから始めましょう。
1. サービスアカウントを管理下に置く。
2. 休眠アカウントの積み残しを解消する。
3. 特権アクセスおよびリモートアクセスにフィッシング耐性のあるMFAを徹底する。
4. これらの統制をエクスポート可能な証拠へと変えるログ基盤を構築する。
この作業は30日以内に運用可能な状態にでき、攻撃チェーン全体を通じて全侵害の39%に存在する認証情報のボトルネックを塞ぐことができます。
Passworkは、企業環境向けに構築されたセルフホスト型のパスワード・シークレット管理ツールです。AES-256暗号化、RBAC、AD/LDAP連携、そしてエクスポート可能な監査ログを備えています。
これがNIS2第21条の要件にどう対応するかを確認しましょう。
翻訳元: https://www.helpnetsecurity.com/2026/09/01/nis2-credential-compliance-before-audit/
