NIS2の実装――官僚的な手続きに足を取られずに

NIS2 は、欧州の指令や規制が抱える中核的な問題を象徴しています。すなわち、不必要な官僚的手続きを生み、望ましい効果が得られることはあまりない、という点です。

サプライチェーン法であれ、 GDPR の影響評価であれ、ITセキュリティ法であれ――共通しているのは、企業が山のような文書を作らされることです。しかもそれは実際のセキュリティ向上につながらず、現実的に検証可能でもありません。

コンプライアンスを満たしている組織とは、通常、あらゆるプロセスの包括的な文書と定期監査を提示できる組織です。この文書はたいてい非常に詳細で、作成するだけでもほとんど理不尽と言えるほどの労力を要し、手作業でのレビューは事実上不可能になります。仮にレビューできたとしても、その情報は本物のセキュリティを示すには十分に精緻ではありません。

セキュリティは計画段階に組み込むべき

これが多くの企業で不条理な運用につながっています。技術チームが動くインフラを構築し、その後で別途、コンプライアンス担当者が「その解決策が安全であるはずだ」という長い正当化文書を書くのです。

これは、フォルクスワーゲンが車を作り、あとから誰かが「その車が安全基準を満たすべき理由」を40ページにわたって書くのと大差ありません。現実の産業界では当然、やり方は違います。安全要件は計画に組み込まれ、最低限の技術標準が定義され、品質プロセスが実装を自動的に監視します。コンプライアンスは技術から生まれるのであって、バインダーから生まれるのではありません。

税務監査のような他分野では、この問題は以前から認識されており、関連プロセスの自動化が法的に義務付けられています（キーワード：電子レジ、監査対応の会計ソフト）。これにより、誠実な事業者の膨大な手作業が削減されるだけでなく、何より不正のリスクが低減します。

残念ながら、ドイツで税の徴収ほど一貫して実装されているものは多くありません。

税負担の問題とは異なり、企業は自社のITセキュリティを正しく実装することに内在的な利害があります。NIS2違反の罰金は最大で1,000万ユーロ、または全世界年間売上高の2%に達し得ます。サイバー攻撃が成功した場合の経済的損害はしばしば存亡に関わり、すでに年間数千億ユーロ規模に上ります。

法律で明示的に求められているわけではないとしても、いまや――AI支援ツールのおかげもあり――セキュリティプロセスとその完全な文書化を、セキュリティ、コンプライアンス、監査可能性を単一の技術プロセスに統合できるほどまで自動化することが可能です。これはリソースを節約するだけでなく、実際のセキュリティも向上させます。

クラウド上のSaaSアプリケーションの例は、これが具体的にどのような姿になるかを詳細に示します。

移行期のIT：テキスト文書から宣言的テクノロジーへ

NIS2が本質的に求めているのは3つです。具体的なセキュリティ対策、それらの対策を管理するためのプロセスとガイドライン、そして実運用で機能していることを示す強固な証拠です。

プロセス文書――すなわちポリシー、責任、手順――は、多くの大企業にとって根本的に新しいものではありません。 ISO 27001に基づく情報セキュリティマネジメントシステム、HRプロセス、マネジメントマニュアルは、しばしば何年も前から整備されています。したがってNIS2で重要になるのは2つのレベルです。技術的対策と、それらが有効であることの証拠です。

まさにここに、近年の変革がはっきりと表れています。以前は、ソフトウェアやITインフラの概念、対策、仕様は主としてテキストで文書化されていました。プログラムコードは複雑すぎ、設定はファイルやチケッティングシステム、あるいは個々の管理者の頭の中に散在していました。その後になって文書が書かれ――多くの場合、別分野の同僚によって――作成されました。このやり方が問題だった理由は主に2つあります。成長し分散した環境ではスケールしないこと、そして技術プロセスを一貫して自動化するという目標と整合しないことです。

そのため現代のシステムは、テスト駆動開発やビヘイビア駆動開発、そしてInfrastructure as Code（IaC）のような手法に依拠しており、これらを一貫して適用すれば、テキスト文書を大部分置き換えられます。NIS2が求める技術仕様は、これらの成果物を直接参照できます。IaC定義は暗号化、ネットワークセグメント、バックアップシナリオを定義し、CI/CDパイプラインが監査に耐える形で本番へデプロイします。

こうして変更は技術的に正確に記述されるだけでなく、コミットやデプロイを通じて時系列で追跡可能になります。完全に宣言できない側面――たとえばソフトウェアサプライチェーンやアプリケーションコードの安全性――の証拠は、CI/CDパイプライン内のセキュリティチェックと、SIEMおよびCNAPPシステムによる継続的評価で表現できます。

次の領域は、これが実務でどのように見えるかを特に分かりやすく示します。

• アイデンティティおよびアクセス管理
• ソフトウェアサプライチェーンおよび監視における脆弱性管理
• インシデント対応
• 報告義務

アイデンティティおよびアクセス管理：Excelのロールではなく、ポリシーをコードとして

アイデンティティおよびアクセス管理はNIS2の中核的な柱の一つです。求められるのは単なる「何らかの」ロールではなく、Need-to-Know（知る必要性）、Least Privilege（最小権限）、Separation of Duties（職務分離）に基づくアクセス概念です。実務では、これを3つのレベルで効果的に構想できます。意図的な権限付与、権限の現実的なライフサイクル、そして横展開（ラテラルムーブメント）を可能な限り防ぐアーキテクチャです。

Excel、管理用UI、散在するWikiで権限を管理する代わりに、ロールとアクセス権は「ポリシーをコードとして」またはIaCとして定義します。たとえばGitリポジトリ内のTerraformモジュールやJSON/YAMLポリシーです。すべての変更はマージリクエスト経由のみに限定し、CI/CDパイプラインでデプロイします。

これにより、誰がどの権限を変更し、誰が承認し、いつ本番反映されたかが明確に追跡可能になります。NIS2の文書化要件と説明責任要件は、追加のWord文書を書かなくても、Gitの履歴とパイプラインログから直接生まれます。

ロールモデルだけでは最小権限の原則は保証されません。NIS2は、権限を定期的に見直し、不要な権限を削除することを求めます。数百のアカウント、サービス、Pod、関数があるクラウド環境では、これを手作業で管理するのは事実上不可能です。

ここでクラウド・アイデンティティ・エンタイトルメント管理（CIEM）システムが役立ちます。CIEMは環境内の実効権限をすべて読み取り、監査ログと相関させ、実際に使われている権限と過剰付与（オーバープリビレッジ）が存在する箇所を示します。これは非人間アイデンティティ（サービスアカウント、ワークロード）にとって特に重要です。まさにこの領域で、後に攻撃者の足掛かりになり得る非常に広範な権限が付与されがちだからです。

最近では、AIを用いて該当ロールのIAMポリシーを自動生成できるCIEMシステムを提供するスタートアップさえあります。

脆弱性管理とソフトウェアサプライチェーン：スキャナーPDFではなくSBOM

NIS2と、デジタルサービス向けの新しい実施規則2024/2690が法制化している第2の領域は、企業の自社コードおよびサプライチェーンにおける脆弱性管理です。これには、定期的な脆弱性スキャン、評価と優先順位付けの手順、重大な脆弱性の迅速な修正、規定された脆弱性対応、そして必要に応じて協調的脆弱性開示が求められます。クラウドおよびSaaSプロバイダーも、たとえばクラウド、CI/CD、レジストリのサービスプロバイダーに対するものなど、追加のサプライチェーン義務に直面します。

従来の脆弱性管理では、SCA、SAST、DASTスキャナーを単に「すべてにかける」だけです。その結果、終わりのない検出リストが生まれ、その大半は誤検知か当該システムに無関係です。こうしたデータはExcelシートや脆弱性データベースに流れ込み、チームが優先順位付けを試みます。特にゼロデイ脆弱性では、場当たり的な分析に追い込まれます。どのコンポーネントが影響を受けるのか？ そもそも我々のアーキテクチャで悪用可能なのか？ パッチが出るまで何をすべきか？

現代的なアプローチは、すべてのDevSecOpsの検出結果を中央システムに集約することです。そこではSCA、SAST、DASTの結果が統合され、ソフトウェア部品表（SBOM）、アーキテクチャ、露出（エクスポージャ）といった文脈で補強され、AIで事前フィルタリングされます。これにより誤検知が大幅に減り、真に関連する脆弱性の集合が大きく絞り込まれ、特定の構成における重大度評価も含められます。

これらの集約された検出結果は、チケッティングシステムや SOCへ直接送ることができ、インシデントとして扱われ、追跡され、NIS2報告のために評価されます。こうして、増殖するスキャナー出力は、法的要件と運用現実の双方を反映した管理可能なプロセスへと変わります。

監視、インシデント対応、報告センター

NIS2がすぐに張り子の虎になりがちな第3の領域は、監視、インシデント対応、新たな報告要件の組み合わせです。指令は明確な期限を定めています。24時間以内の早期警告、72時間後の構造化レポート、そして遅くとも1か月以内の最終報告です。多くの組織は、新しいテンプレート、Excelシート、報告マニュアルを作ることで対応しています――しかも既存のSOCから大きく切り離された形で。

重大局面では、SOCがインシデントに対処する一方で、同時に「NIS2タスクフォース」がチケット、メール、場当たり的なチャットから情報をかき集め、フォームに収まるよう加工しようとします。その結果、作業の重複、情報の欠落、ページ数は埋まるが検知と対応がどれほど機能したかはほとんど分からない報告書が生まれます。

クラウドSaaS環境では別のアプローチが可能です。NIS2報告を別個の文書プロジェクトとして扱うのではなく、DevSecOpsに基づく現代的なSOCを構築し、最初からすべてのセキュリティ関連シグナルが一か所に集約されるようにします。クラウドインフラ、CI/CDパイプライン、アプリケーション、IdP、IAMです。

このデータを相関させ、補強し、インシデントへ変換するルールはコードとして定義され、バージョン管理されます。脅威検知と対応ロジック、しきい値、プレイブックはリポジトリに置かれ、アプリケーションコードと同様にパイプラインでデプロイされます。これにより、従来のSOC作業の大部分を自動化できます。生ログは、テキスト断片の手作業コピー＆ペーストを必要とせず、一貫性があり文脈化されたインシデントへと変換されます。 

クラウドネイティブ・アプリケーション保護プラットフォーム（CNAPP）などのプラットフォームは、同時にデータの保存とアーカイブも担い、監視活動の証拠が別の文書化ループではなくシステム内で生成されることを保証します。機械学習やAIコンポーネントは、誤検知の削減、類似イベントのクラスタリング、異常パターンの強調にも役立ち、SOCが本当に注意を要する少数のインシデントに集中できるようにします。

プロセスのレベルでは、プレイブックと報告チャネルは重要であり続けます――ただし簡素化されます。インシデント対応プレイブックは、インシデント区分、エスカレーション経路、コミュニケーションルールを定義し、いつインシデントが「NIS2上重要」と見なされるかの基準も含みます。報告プロセスは、SOCと事業部門からの情報を誰が集約し、BSI報告センターを通じて提出するかを規定します。

実際の文書化も、ここでは大部分が自動生成されます。インシデントチケットにはタイムライン、影響を受けたサービス、影響、原因、対策が含まれ、「NIS2関連」インジケーターと報告ステータスが外部報告と紐づけます。MTTD、MTTR、または検知から初回報告までの時間といった主要業績指標（KPI）は、 SIEM およびIRデータから直接算出できます――まさに、NIS2が実際に運用されているプロセスなのか、それとも文書キャビネットの引き出しが一つ増えただけなのかを明らかにする指標です。

NIS2は文書化演習ではなく、アーキテクチャのテスト

NIS2は企業に対し、セキュリティ対策、プロセス、文書化を明確に定義することを強制します。これは不便です――特にこれまで場当たり的に運用してきた組織にとっては。ですが、これが単なる形式に終わるのか、本当のセキュリティ改善になるのかは、法文ではなくアーキテクチャに左右されます。

Word、PowerPoint、Excelでポリシーを「文書で片付けよう」とする人は、多大な労力とわずかなレジリエンスしか生みません。しかし、IdPとIAM、CI/CDパイプライン、SBOMと脆弱性ツール、SIEM、IRプラットフォームが、必要な統制と証拠をほとんど副次的に提供するよう構成されていれば、NIS2準拠は現代的なセキュリティ環境の副産物として達成されます。