認証維持を「目的」にしないISMS運用とは？形骸化を防ぐ、実効性の高い「守りの仕組み」の作り方

データから紐解くISMS運用の実態と、新規格時代への課題

現代のデジタル経済において、情報資産の保護は企業の社会的責任であると同時に、事業継続における最優先事項のひとつとなっています。その中で、国際規格であるISO/IEC 27001:2022（ISMS：情報セキュリティマネジメントシステム）は、組織が適切な管理体制を構築していることを示す客観的な評価基準として機能してきました。

特に日本国内においては、官公庁の入札要件やプライム市場上場企業との取引条件として認証取得が求められる傾向が強く、世界的に見ても極めて高い取得率を誇っています。

ISMS導入のメリット

2024年7月に一般社団法人情報マネジメントシステム認定センター（ISMS-AC）^*1)から公表されたISMS 適合性評価制度に関する調査報告書によると、ISMS導入の主な効果として、多くの組織が、次のような「認証取得」に留まらない実質的なメリットを実感しています。

• 意識向上と教育： 全項目で最高評価（71.6%）となった「社員のセキュリティ意識向上・教育啓発」への寄与。
• 組織体制・対策の強化： 7割以上の組織が「管理体制」および「セキュリティ対策」の強化を実感。
• 経営層の関与： 経営者の情報セキュリティに対する関与の深化（57.2%）と、トップマネジメントの意識変容。
• 信頼の確保とビジネス活用： 多くの組織が認める「顧客からの信頼確保（63.1%）」や「コンプライアンス面（53.9%）」での有効性。
• インシデント対応力の向上： 事故抑制（51.1%）に加え、発生時の「迅速・適切な対応（48.2%）」への効果。

ISMS運用の課題

しかし、その一方で「認証のパラドックス」とも呼べる深刻な課題が浮き彫りになっています。

• 人材の確保と育成（54.2%）：　専任担当者の不足、後任の育成、兼務による負担増など 。
• 運用のマンネリ化・形骸化（50.8%）：　長期運用に伴う事務局の固定化や、教育内容のマンネリ化 。
• 最新技術動向への対応（38.1%）：　ランサムウェア等の新たな脅威や、クラウド、AIといった急速なIT技術変化への適応 。
• 教育の継続的な工夫（46.7%）：　コンテンツの刷新、役割に応じた教育の実施、理解度の差の解消など 。
• 運用負担の軽減（27.3%）： 膨大な証跡管理や事務作業が現場の重荷となっている。

特に、最新規格（ISO/IEC 27001:2022）への完全移行を経て、管理策はより高度化・複雑化しました。この高度化した要求に対し、「従来のアナログな手法のまま対応し続ける」こと自体が、運用の負荷を増大させ、本来の目的である実効性を損なう要因となっています。

最新規格（ISO/IEC 27001:2022）が求める「合理的で実効性の高い」管理

こうした「認証維持のための運用」から脱却し、いかにして実戦的な防御力を手に入れるか。そのポイントは、ISMSの捉え方を「静的なコンプライアンス」から「動的なリスクマネジメント」へとシフトさせることにあります。JIPDECやISMS-ACの最新調査からも明らかなように、今、多くの企業が『運用を形骸化させず、いかに実務に役立てるか』という壁に直面しています。この課題を解決する一つの答えが、手作業による『管理のための事務』を捨て、テクノロジーによって「実務そのものを自動的に証跡化する」というアプローチです。では、具体的にどのようにしてVantaやJiraを活用し、新規格が求める『実戦的なPDCA』を実装するのか。ここからは、Cloudflareの設定管理をモデルにした実践例を詳しく見ていきましょう。

*1)　https://isms.jp/index.html
*2)　https://isms.jp/topics/news/20240712.html　ISMS適合性評価制度に関する調査報告書

ISMS改訂が求める「静的なコンプライアンス」から「動的なリスクマネジメント」

2013年版から2022年版への改訂は、スナップショット型の形式的な確認から、常にリスクを追い続けるモニタリング型への移行を意味します。これにより、形骸化したコンプライアンス維持ではなく、変化に即応する動的なリスクマネジメントの実現が求められています。

最新の国際規格への改訂において、最も大きな変化の一つは管理策の構造そのものです。従来の114項目から93項目へと数が減少しましたが、これは単なる簡略化ではありません。既存の項目が現代のIT環境に合わせて高度に統合・整理され、そこに今の時代に欠かせない11の管理策が新たに追加された、極めて密度の高い再編と言えます。

この再編が目指しているのは、形骸化した事務作業の積み上げではなく、ビジネスの実態に即した「合理的で実効性の高い」管理です。具体的に、私たちの働き方にどう関わってくるのか、ポイントを紐解いてみましょう。

統合・整理された管理策の例

具体的にどのように整理されたのか、実務に影響の大きい4つのポイントを挙げてみましょう。

• 「方針・レビュー」の統合（旧 A.5.1.1, A.5.1.2 / A.18.2.2, A.18.2.3など）
  これまで別々のルールとして存在していた「セキュリティ方針の策定」と「その定期的な見直し」が統合されました。これは、「作って終わり」ではなく「作ることと改善することを一つのサイクルとして回す」という、現代のビジネスでは当たり前の習慣にISMSが歩み寄った形と言えます。
• 「アクセス制御」の整理（旧 A.9.1.1, A.9.1.2 / A.9.2.5, A.9.2.6など）
  アクセス制御の方針や利用者登録、特権管理といった、かつては細かく分かれていた手続きが「5.15 アクセス制御」と「5.18 アクセス権」に集約されました。「誰が、どのシステムに、どうやって入るか」というルールと権限管理を一貫したプロセスで捉えます。ここで重要になるのが、単にIDがあるかだけでなく、MFA（多要素認証）が全ユーザーで有効になっているかといった実効性の管理です。バラバラだった管理項目が統合されたことで、こうした認証の健全性を一元的にモニタリングし、不備があれば即座に検知する仕組みが作りやすくなりました。
• 「ログ・監視」の集約（旧A.12.4.1, A.12.4.2, A.12.4.3）
  ログの取得、保護、作業ログの管理といったバラバラだった項目が、「証跡の信頼性を保つ」という一つの目的に集約されました。取得ルールの定義から実際の運用、そして正しく取得できているかの確認までを一連の流れで捉えることで、今の時代に不可欠な「常時モニタリング」を前提とした管理へと進化しています。
• 「開発・変更管理」の整理（旧14.2.2, 14.2.3, 14.2.4）
  システムの変更管理や技術的レビュー、パッケージソフトの変更制限などが統合されました。かつてのウォーターフォール型開発を前提とした細かな制約から、現代のアジャイル開発やCI/CD（継続的インテグレーション／継続的デリバリー）といったスピード感のある開発現場に馴染む、柔軟で実効性の高い「変更管理プロセス」へとまとめられました。

ISO/IEC 27001:2022で新たに追加された管理策の例

新しく追加された管理策のうち、特徴的なものを見ていきます。

• クラウドサービス利用時の情報セキュリティ（ISO/IEC 27001:2022 - A.5.23）：　AWS/Azure/GCPなどのクラウドやSaaSの設定ミスが最大の漏えい原因となっている現状を反映した最重要項目です。また、年に一度、設定ミスがないかどうかを確認するだけでは不十分な項目です。誰かがうっかり間違えて公開設定に変更したものをできる限り早いタイミングで検知できるような、常時モニタリングをすべき設定です。
• 構成管理（ISO/IEC 27001:2022 - A.8.9）
  組織の情報システム、ハードウェア、ソフトウェア、サービス、ネットワークのセキュリティ構成などの要素を正しく識別し、確立・実装、監視およびレビューする必要があります。具体的には、以下の3つのプロセスを確実に回すことが求められます。
  • 識別： すべての資産を「見える化」する
    サーバー、PC、クラウド、ネットワーク機器などのIT資産を漏れなく洗い出し、「今、どんな設定で動いているか」を常に明確にすることです。
  • 確立・実装： 守りの「基準」を適用する
    OSのパッチ適用ルールやクラウドのアクセス制限など、自社にとって安全な「標準設定」を定義し、実際の環境に反映させることです。
  • 監視およびレビュー： 基準からの乖離を検知する
    設定して終わりにせず、許可のない変更や基準外の状態を継続的にチェックし、必要に応じて設定やルール自体を見直すことです。
• 脅威インテリジェンス（ISO/IEC 27001:2022 5.7）
  情報セキュリティの脅威に関する最新情報を収集・分析し、自社のリスク状況と照らし合わせることで、具体的な防御策や検知ルールへと反映させる必要があります。「世の中で起きている攻撃手法」と「自社の資産や脆弱性」を突き合わせ、自社にとっての真のリスクを特定した上で、優先順位を持って対策をアップデートし続けるプロセスを構築する必要があります。
• 監視活動（ISO/IEC 27001:2022 8.16）
  ネットワークやアプリケーション、システムの挙動を監視し、異常を検知し、是正します。潜在的な情報セキュリティインシデントを評価するために適切な措置が講じられる必要があります。何か異変に気づいたら報告するという属人的な運用から、システムが不審なログインや大量のデータ転送といった「異常な挙動」を自動で検知できる体制への転換を求めています。こちらも昨今のサイバー攻撃の巧妙化を踏まえ、まずは侵入されないこと、侵入された場合も被害を最小限に食い止めるための早期発見・早期対応を仕組み化することが、この管理策の本質です。

このように、これらの新しい管理策に共通しているのは、一度決めたルールを守るだけでなく、現在の状態を常に把握し、変化に対応するという動的な姿勢が求められている点です。監査員に見せるための「管理のための管理」から、ビジネスのスピードを止めず、かつ進化し続ける脅威から組織をリアルタイムで守り抜くための、より合理的で実戦的なフレームワークへとISMSが進化したのです。

このような2022年版への対応にあたり、例え、増えたチェック項目を埋めることができたとしても、それが「管理のための管理」で終わってしまっては意味がありません。とはいえ、最新規格が求める「変化に対応する動的な姿勢」をすべて手作業で実現しようとすれば、現場の負担は重くなるばかりです。今回の改訂の本質は、人間による報告を待つ受動的な管理から、システムによる検知を前提とした動的な守りへのアップデートにあります。もし手作業での運用に限界を感じているのであれば、それは最新規格が求めるリアルタイムな管理へとシフトする、絶好の機会かもしれません。

新規格時代に求められる実戦的な「運用の在り方」

ISO/IEC 27001の本来の目的は、情報の機密性・完全性・可用性を維持すること、つまり「漏洩、改ざん、破壊、紛失、不正アクセス」といった現実の脅威から資産を適切に保護することにあります。だからこそ、本来は一体であるべき「セキュリティの実務」と「認証に必要な証跡の記録」が、シームレスに繋がっていない状態は、現場に過度な負荷を強いるだけでなく、結果としてセキュリティ対策の効率を著しく下げてしまいます。

特に昨今のサイバーセキュリティ事案を振り返ると、「適切なアカウント管理さえできていれば防げていた」と思われるケースが少なくありません。退職者のアカウント放置や、過剰な権限が付与されたままの特権アカウントなどは、今や攻撃者にとって格好の入り口となっています。

とはいえ、これまで挙げた「アカウントの状態や構成の継続的な監視」を、すべて人手で行うのは現実的ではありません。従来の「年に一度のエクセルによるアカウント棚卸し」という手法では、日々刻々と変化する利用状況や、最新の攻撃スピードに追いつくのは困難です。

だからこそ、最新のISMS運用には、テクノロジーによる「運用の仕組み化」が不可欠となります。

もちろん、すべてが全自動で解決するわけではありません。大切なのは、システムが異常を素早く「検知」し、人間が「判断・対応」すべき材料をあらかじめ揃えてくれる状態を作ることです。具体的にどのように運用をシフトすべきか、以下の3つのポイントで解説します。

• 運用状況を『継続的』に可視化する仕組み
• 異常の「早期検知」と「対応の迅速化」を図る仕組み
• 運用の『証跡』を自動で生成する仕組み

それでは、ひとつずつ見ていきましょう。

運用状況を『継続的』に可視化する仕組み

ISO/IEC 27001:2022で「構成管理」や「アクセス権」の管理策を自社のルールとして採用した場合、それらが「今、この瞬間にどうなっているか」を常に把握し続ける必要があります。ここで大きな力を発揮するのが、Vantaのようなトラスト管理プラットフォームを活用した自動管理です。例としてVantaでA.8.9 構成管理がどのように管理できるかを見ていきましょう。

ISO/IEC 27001:2022の「構成管理（A.8.9）」において最も重要なのは、組織として「どう守るか」の明確な基準を確立し、その基準が現場で一切の例外なく維持されていることを、客観的に証明し続けることにあります。Vantaはこの「ルールの定義」と「実態の監視」をシームレスに繋ぎます。具体例として、Vantaが弊社の環境をどのように管理しているかを見ていきましょう。

【Vantaでの実装例：ポリシーを起点とした構成管理】

Vantaの運用は、まず組織のルールを定義する「Operations Security Policy（運用セキュリティポリシー）」の承認から始まります。Vantaはこのポリシーで定めた管理目的を補完するように、VantaとAPIでインテグレーションされている環境に対しベストプラクティスに基づいた「自動テスト」を多数備えています。これらAPI経由のテストを継続的に実行することで、現場の設定状況がセキュリティ基準を満たしているかを、客観的な証跡として収集します。

弊社の環境を例に挙げると、Vantaが各サービスから最新の資産データ（インベントリ）を直接取得し、それらが「あるべき構成」を維持しているかを以下のようなレイヤーで可視化し、管理できているかのテストをおこないます。

1. 境界防御（Cloudflare）　
   • 不正トラフィックの遮断： カスタムルールやマネージドルールセットによるファイアウォール保護が有効かを確認し、悪意あるトラフィックを未然に防げているかをチェック。
   • アクセス制限の遵守： ポリシーで定めた「IPアクセスルール」がアクティブ（有効）な状態で運用されているかを監視。
   • 異常検知の有効化： 異常を検知するための通知設定（HTTP DDoS攻撃のアラートや、オリジンサーバの監視通知など）が、ポリシー通りに有効化されているかをチェック。
2. インフラ基盤（Azure）
   ロードバランサー等の構成が、社内で合意した安全な設計基準（ベースライン）から逸脱していないか。
3. エンドポイント（Intune）
   「全端末でのスクリーンロック強制」というルールが、Intuneに登録されたデバイス一台一台に、例外なく適用されているか。

もし設定に不備がありテストが「不合格（Fail）」となった場合でも、Vantaは単に警告を出すだけではありません。どのように修正するかを提示、もしくは、具体的な対応手順が記されたガイドページへのリンクを提示します。管理者はその指示に従って設定を修正するだけで、「あるべき構成」へ最短距離で復旧させることが可能です。

また、これらのテストは、Vantaとインテグレーション（API連携）された環境に合わせて自動的にセットアップされます。担当者が何をチェックすべきかをゼロから考える必要はなく、システムが提示する実戦的な基準に沿って、即座に運用を開始できるのが大きな特徴です。

例として境界防御（Cloudflare）のテストケースの異常検知の有効化のテストケースを見ていきます。

【Cloudfrareの異常検知の有効化がされているかを確認するテストの概要】
Cloudflareにおける重要な通知設定が有効であることを検証します。

現時点で、以下の通知設定が一つも見つかっていないようです。設定が無効、または未設定の状態のようです。

• ルート漏洩検知アラート（Route Leak Detection Alert）： ネットワーク経路の異常を検知する通知
• パッシブ・オリジン・モニタリング（Passive Origin Monitoring）： オリジンサーバ（接続元）の通信状態を監視する通知
• ヘルスチェック・ステータス（Health Checks status）： サービスの稼働状況（死活監視）に関する通知
• HTTP DDoS 攻撃アラート / 高度な HTTP DDoS 攻撃アラート（HTTP DDoS Attack Alert / Advanced HTTP DDoS Attack Alert）： DDoS攻撃などの不正アクセスを検知した際の緊急通知

このテストは設定が正しく行われていない（テストが不合格の）ため、How to remediate をクリックして修正方法を確認します。すると、具体的な対応手順が記されたインストラクションページへのリンクが表示されます。

不備が見つかった際は、提示されたリンク先のガイド (https://developers.cloudflare.com/notifications/get-started/) に従って設定を修正するだけです。専門的な調査に時間を費やすことなく、誰でも迷わず正しい状態へ復旧できる。このスピード感こそが、実戦的なISMS運用には欠かせません。

仕組みのポイント
システムが、各資産やアカウントの状態を、SLAに基づいた一定のサイクルで自動スキャンし続けます。一度チェックして終わりにせず、自動で定期的に確認する、これこそがVantaを使う一番のメリットです。

実務のメリット
設定不備や不要なアカウントの放置を、Vantaの画面越しにいつでも最新の状態で把握・是正できるため、運用が形骸化しません。

異常の「早期検知」と「対応の迅速化」を図る仕組み

管理策の形骸化を防ぐ鍵は、設定の不備が放置される時間を最小限に抑えることにあります。Vantaは単なる定期スキャンに留まらず、異常検知から是正準備までのプロセスを「ワークフロー」として仕組み化します。

例として、前のセクションで挙げた「Cloudflareの異常検知（通知設定）が有効かを確認するテスト」を例に見ていきましょう。

Create workflowからあらかじめワークフローを作成します。このワークフローにより、テストが実行され、Fail（不合格）した場合には、Jiraのチケットが担当者宛てに自動で作成されます。

Jira側では、このようにチケットが自動で作成されたことが確認できます。チケット内には、具体的な対応手順が記されたインストラクションページへのリンクが自動で挿入されます。

• 仕組みのポイント
  管理者が「何が起きたのか」「どう直せばいいのか」を一から調査する必要はありません。チケットを開いた瞬間に、解決に向けたすべての情報が揃っている状態を作り出せます。
• 実務のメリット
  属人的なスキルや記憶に頼ることなく、誰でも同じ品質で迅速に是正アクションを起こせるようになります。これが、Vantaを活用した「形骸化させない」運用の強みです。

運用の『証跡』を自動で生成する仕組み

ISMS運用において最も負担となるのは、審査の際などに「ルール通りに運用していたこと」を客観的に証明するエビデンス（証跡）の準備です。

仕組みのポイント
承認された「オペレーションセキュリティポリシー」に基づき、Cloudflareなどの設定不備（Fail）が検知されると、Vantaを起点としJiraチケットが自動起票されるよう設定できます。リンクしているJira側のヒストリー機能ではいつチケットが作成され、誰が対応し、いつクローズされたかの記録を確認できます。これがポリシーに従って適切に是正処置を行ったという証跡となります。

実務のメリット
Vantaでの異常検知をトリガーにJiraチケットが自動作成され、解決までをJiraで管理することで、タスクのアサインから完了までの経緯を正確にトラッキングできます。また、SLAに基づきテストが自動実行されるため、修正後はVantaで手動実行せずともVantaで設定したSLAのタイミングでテストが自動実行され変更が完了しているとこのテストのステータスがPassに変わります。この一連のプロセスを、Vantaのテスト結果と、そこにリンクされたJiraチケットの履歴から客観的に追うことができるため、審査のために証跡を「別途作成」するのではなく、適切な運用の「結果」として記録が残ります。これにより、事務作業を大幅に削減しながら、客観性と信頼性の高いエビデンスを確保できます。

「認証のための運用」を卒業し、「守るための運用」を実装する

ISO/IEC 27001:2022の本質は、PDCAサイクルが実効性を持って回り続けていることにあります。しかし、このサイクルを人手だけで完結させるには、現代のIT環境では限界があります。

もちろん、最前線の防御はCloudflareや各種セキュリティ製品が担います。しかし、組織全体でポリシー通りにPDCAが回っていることを証明するために、各ツールからエビデンスをかき集めるのは、実務の本質から乖離した形式的な管理工数と言わざるを得ません。

ISMSの実効性を担保するポイントは、Vantaのようなツールを活用し、「日常の適切な運用」がそのまま「客観的な証跡」として積み上がる状態を構築することにあります。監査のために資料を「作る」のではなく、日々の運用の「結果」を提示するだけ。このシフトこそが、事務作業を最小化し、事業を守るための本質的なセキュリティに注力できる「新規格時代のISMS」の姿です。