セキュリティ

ゼロトラストとデータセキュリティ:継続的認可をEAで設計する実践ガイド

ゼロトラスト / データセキュリティ / EA

ゼロトラストは境界防御を捨てる製品導入ではありません。主体、端末、資産、データ、行為、状況を検証し、最小権限を継続評価して、侵害を前提に影響範囲と復旧時間を抑える設計原則です。

本稿は、CISO、CIO、セキュリティ、クラウド、データ、アプリケーション責任者が、構想、要件定義、製品選定、導入、運用を一つの判断体系で進めるための実務ガイドです。

公開日 2026年8月3日 | DX WHEEL編集部 | KW-191

POINT 01成果から逆算する

製品や作業量ではなく、変える業務状態と意思決定を最初に固定します。

POINT 02EA四層をつなぐ

業務・データ・アプリケーション・技術の依存を同じ識別子で追跡します。

POINT 03運用を受入対象にする

品質、例外、変更、停止、復旧、廃止までを導入前に試験します。

EXECUTIVE
OVERVIEW

結論:ゼロトラストとデータセキュリティは、相互依存する経営設計である

ゼロトラスト・データセキュリティは製品や個別施策ではなく、主体、端末、業務権限、データ分類、要求文脈を組み合わせ、最小権限と継続評価を実装することで成果へつながる。

ゼロトラストは境界防御を捨てる製品導入ではありません。主体、端末、資産、データ、行為、状況を検証し、最小権限を継続評価して、侵害を前提に影響範囲と復旧時間を抑える設計原則です。 したがって、ツール導入、データ収集、現場ヒアリングのいずれか一つから始めるのでは不十分です。経営成果と業務能力を起点に、DMBOKの管理責任、BPMNの業務・例外表現、EAの四層を同じ判断単位へ統合します。

  • 適用条件、前提、停止条件を最初に分け、目的の異なる案件を同じ方法論へ押し込まない。
  • 成果物を図の納品物ではなく、所有者、版、有効日、承認、変更理由を持つ管理対象にする。
  • 機能完成ではなく、業務KPI、データ品質、非機能、運用、復旧、廃止の証拠で受け入れる。
FIGURE 01

成果へ至る因果関係:課題をツール導入へ短絡させない

01 現状課題

MFA導入を完了条件にするが起き、認証後の過剰権限、セッション窃取、データ持出し、横展開が残る。

02 設計対象

業務判断、データ、サービス、技術制約をEA四層で同時に扱う。

03 実装

一つの重要価値流で、利用者・委託先・端末・API・データを属性化し、継続認可、特権操作、遮断、限定運転、侵害封じ込め、復旧を演習する。

04 運用変化

所有者、品質閾値、例外、停止・復旧を日常の変更管理へ組み込む。

05 経営成果

最小権限適合率と業務KPIで効果を測り、次の投資判断へ戻す。

01 / 適用判断

まず、解くべき問題と適用境界を固定する

クラウド、SaaS、リモート、委託先、工場・店舗を横断するアクセスが増え、ネットワーク内外だけでは権限、データ持出し、横展開を制御できない。 この状態に対して、症状だけを個別改修すると、別の層へ制約や手作業が移ります。

着手時には、対象となる経営成果、意思決定、価値流、データ、システム、組織、拠点、期間を明記します。対象外も同じ精度で定めます。たとえば全社標準化を掲げながら一部門の都合だけでデータ定義を決めると、後工程で統合費用と例外が増えます。

診断の最低条件は証拠の三角測量です。関係者の説明、業務記録・データ、システム設定・ログの三つを照合し、差異を未解決事項として残します。現状の不確実性を隠して将来像を精緻化しても、移行計画は信頼できません。

FIGURE 02

適用・着手・停止の境界

適用しやすい状態

クラウド、SaaS、リモート、委託先、工場・店舗を横断するアクセスが増え、ネットワーク内外だけでは権限、データ持出し、横展開を制御できない。

着手前の前提

重要業務・資産・データ、主体、端末、アクセス経路、権限、ログ、脅威、停止影響、復旧目標をリスクベースで優先付けできる。

いったん止める状態

資産・データ・主体の棚卸しなしに認証製品だけを導入する場合、または可用性・現場安全・緊急アクセスを無視して一律遮断する場合。

02 / 設計判断

テーマ固有の四つの判断を、受入試験まで具体化する

設計原則は標語ではなく、選択肢を比較して不採用理由も説明できる判断規則です。次の四点は本テーマで特に差が出ます。

1. 保護対象を価値流で優先する

論点:全社を一度に同じ強度で変えると業務影響と例外が増え、形骸化します。

設計判断:重要データ、特権操作、外部経路、侵害時影響から保護面を選びます。

受入確認:対象ごとに脅威、現行制御、残余リスク、業務継続、導入波が承認されていることを確認します。

2. 認可を属性と状況で決める

論点:静的ロールだけでは端末状態、場所、時刻、データ機密度、行為の差を扱えません。

設計判断:主体、端末、資産、データ、行為、環境の属性をポリシーへ組み合わせます。

受入確認:許可・追加認証・制限・拒否の理由が説明でき、属性欠落時の安全な動作を試験します。

3. ポリシー決定と適用を分離する

論点:各製品へ個別ロジックを埋め込むと方針変更と監査が一貫しません。

設計判断:可能な範囲で決定、情報、管理、適用の責務を分離し共通方針を配布します。

受入確認:方針版、適用先、例外、決定ログを追跡し、停止時のフェイルセーフを検証します。

4. 侵害後の封じ込めと復旧を測る

論点:防御率だけでは資格情報窃取や内部不正の影響を評価できません。

設計判断:横展開検知、セッション失効、鍵更新、分離、証跡保全、業務再開を設計します。

受入確認:実践的な侵害シナリオで検知から封じ込め、限定運転、完全復旧までを演習します。

判断記録に必ず残す項目

設計決定記録には、決定する問い、背景、前提、選択肢、評価基準、決定、却下理由、業務・データ・アプリケーション・技術への影響、リスク、例外、有効期限、再評価トリガーを残します。担当者が交代しても、結論ではなく判断経路を再現できる状態が必要です。

03 / EA・BPMN・DMBOK

EA四層、BPMN、DMBOKを同じ調査体系へ統合する

EAは全体の依存構造、BPMNは業務の時間順序と責任、DMBOKはデータ管理責任を補完します。三つを別々の成果物体系にしないことが重要です。

EA四層の役割

業務層は成果、能力、価値流、役割を定義します。データ層は業務で発生・参照・判断される情報の意味、正本、品質、共有条件を定義します。アプリケーション層は能力を支えるサービスと責務、連携、ライフサイクルを定義し、技術層は実行基盤、可用性、セキュリティ、運用、費用の制約を定義します。

BPMNとの対応

BPMNでは、プールとレーンを責任主体、タスクを能力の具体的な実行、イベントを業務事実、ゲートウェイを判断規則、メッセージを組織・システム間の受渡しとして扱います。各タスクに入力・出力データ、利用サービス、KPI、例外を関連付けることで、業務図を要件と受入シナリオへ変換できます。

DMBOKとの対応

本テーマの中心知識領域はData Security/Data Governance/Metadata Managementです。データガバナンスを横断責任として置き、アーキテクチャ、モデリング、統合、品質、メタデータ、セキュリティ、ストレージ・運用など必要な領域を、EA成果物と業務プロセスへ割り当てます。知識領域の網羅を目的にせず、重要データのライフサイクルで必要な責任から適用範囲を決めます。

FIGURE 03

EA四層の設計対象・判断・証拠

EA層設計対象決めること受入証拠
業務重要価値流、役割、第三者、リスク受容、継続、事故対応何を守り、どの行為を誰に許し、遮断時に業務をどう継続するか重要業務・リスク台帳、アクセスBPMN、RACI、継続・事故計画
データ分類、所有者、目的、暗号化、持出し、保持、監査機密度と利用目的に応じ、誰がどの条件で何を読取・変更・共有できるかデータ分類、アクセス方針、鍵・保持・DLP・監査要件
アプリケーションID、認可、API、セッション、特権、ポリシー適用点認証後も取引・データ単位で継続認可し、例外をどう管理するか認可モデル、信頼境界、サービス対応表、特権・例外台帳
技術端末、ネットワーク、テレメトリ、ポリシーエンジン、SIEM、復旧信号の鮮度、可用性、遅延、分離、検知、封じ込めをどう保証するか参照構成、信号・制御設計、監視・対応・復旧ランブック
04 / 成果物

成果物は相互参照し、変更時の因果関係を保つ

本テーマの最小セットは次の六つです。文書の名称より、共通識別子、所有者、版、有効日、承認状態が重要です。

たとえばBPMNのタスクが変わった場合、入出力データ、業務規則、利用サービス、権限、監視、KPI、教育、移行手順への影響をたどります。逆にデータ定義やAPI契約の変更から、影響する業務判断と責任者を逆引きできなければなりません。

FIGURE 04

最小成果物セット:相互参照できる六つの管理対象

01 重要価値流・資産・データリスク台帳

目的、対象、粒度、所有者、版、有効日、承認状態を必須属性とし、会議資料ではなく判断記録として管理します。

02 主体・端末・資産・データ属性モデル

現状と将来の差分、依存、先行条件、廃止条件を対応付け、変更時に影響を追跡できるようにします。

03 継続的認可ポリシー・判断表

業務用語と技術要素を共通識別子で結び、同じ名前の異義語と異なる名前の同義語を区別します。

04 信頼境界・ポリシー適用点構成

通常系だけでなく、例外、再処理、取消、権限、監査、停止・復旧まで受入条件に含めます。

05 特権・第三者・例外アクセス台帳

担当者名ではなく役割へ責任を割り当て、作成、承認、利用、変更、廃止の責任を分けます。

06 検知・封じ込め・復旧演習計画

作成して終わらせず、更新イベント、見直し周期、品質閾値、期限付き例外を運用ルールへ組み込みます。

05 / 導入ロードマップ

小さく始めても、業務から運用まで縦に完成させる

短期間のPoCでも、機能デモだけでは本番適合性を判断できません。対象範囲を狭め、因果の鎖は切らずに検証します。

各段階のゲートで証拠が不足していれば、日程を守るために次工程へ送らず、前提の修正、対象縮小、代替案、残余リスク受容のいずれかを明示的に選びます。計画は作業進捗ではなく、不確実性と依存関係の解消順で管理します。

FIGURE 05

5段階ロードマップと次へ進むためのゲート

目的と境界を定義する

経営課題、意思決定、対象価値流、利用者、対象外、制約を一枚にまとめます。成果を製品導入や作業完了ではなく、変化させる業務状態と測定式で表します。

ゲート

目的・対象・対象外・意思決定者・ベースライン・停止条件が承認されている。

現状を証拠で可視化する

ヒアリングだけでなく、業務記録、データプロファイル、設定・ログ、利用実績、費用、障害を照合します。BPMNで通常・例外・判断・責任を記述します。

ゲート

主張ごとに根拠、取得日、所有者、不確実性が記録され、未確認事項が分離されている。

将来像と設計判断を合意する

業務、データ、アプリケーション、技術の将来状態を同じ粒度で定義し、選択肢、評価基準、却下理由、例外、有効期限を設計決定記録へ残します。

ゲート

四層の成果物が共通の能力・データ・サービス識別子で結ばれ、矛盾がない。

限定範囲で通し検証する

機能の一部ではなく、業務開始からデータ発生、処理、判断、例外、監視、復旧までを縦に通します。プロフィールで定義したパイロットを採用します。 本テーマでは「一つの重要価値流で、利用者・委託先・端末・API・データを属性化し、継続認可、特権操作、遮断、限定運転、侵害封じ込め、復旧を演習する。」を検証単位とします。

ゲート

業務KPI、品質、非機能、運用、停止・復旧の受入基準を実データで満たす。

展開と廃止を運営する

価値と依存関係で導入波を決め、教育、移行、共存、旧手順・旧システムの廃止条件を管理します。月次でKPI、リスク、例外、費用を再評価します。

ゲート

次の波の開始条件と前の波の廃止条件が満たされ、残余リスクの受容者が明確である。

06 / 失敗パターン

失敗はツールの不足より、責任と判断境界の曖昧さから起きる

導入時に見落としやすいのは、平常時の機能ではなく、例外、変更、共存、停止、復旧、廃止です。これらを本番開始後の運用課題として先送りしません。

リスクは発生確率だけでなく、業務影響、検知可能性、回復可能性、影響範囲で評価します。対策には予防、検知、封じ込め、復旧のどこを強化するかを明記し、対策後の残余リスクを権限のある業務責任者が受容します。

FIGURE 06

典型的な失敗パターンと設計による予防

MFA導入を完了条件にする

起きること:認証後の過剰権限、セッション窃取、データ持出し、横展開が残る。

設計対応:取引・データ単位の認可、端末信頼、監視、失効までを統合します。

一律に通信を遮断する

起きること:工場や基幹の可用性・安全を損ない、恒久例外が増える。

設計対応:業務影響に応じて段階制御、限定運転、緊急アクセス、事後監査を設計します。

ログを集めるだけにする

起きること:主体、資産、データ、業務取引が結び付かず、調査と封じ込めが遅れる。

設計対応:共通識別子、時刻同期、重要イベント、保持、検知・対応責任を定義します。

07 / KPI

活動量ではなく、業務成果と運用品質を同時に測る

研修回数、会議回数、作成資料数、接続データ数だけでは成果を説明できません。結果指標、先行指標、品質・リスクのガードレールを組み合わせます。

KPIは名称だけで合意せず、目的、計算式、分母、粒度、時間窓、除外、データ源、基準値、目標、更新頻度、所有者、利用する会議、閾値超過時の行動まで定義します。指標の改善が別の品質や現場負荷を悪化させていないか、対となるガードレールも確認します。

FIGURE 07

KPI:定義・証拠・改善責任を一体で持つ

指標測定定義データ源所有者
最小権限適合率重要アクセスのうち目的・属性・期限・所有者が認定済みの割合IAM・権限レビューセキュリティ責任者
継続認可カバー率重要取引・データアクセスのうち状況評価と方針適用を行う割合ポリシー決定ログゼロトラスト責任者
封じ込め時間高重大度の侵害検知から横展開停止と資格情報失効までの時間SIEM・事故管理CSIRT責任者
復旧演習達成率定義時間内に限定運転、証跡保全、権限再発行、業務再開を完了した割合演習記録事業継続責任者
08 / 運用ガバナンス

月次で成果、品質、変更、例外、廃止を一つの場で見直す

アーキテクチャレビューを図の審査会にせず、経営成果と残余リスクを更新する意思決定の場にします。

業務オーナーは成果と例外を、データオーナーは定義・品質・利用条件を、サービスオーナーは変更とSLOを、アーキテクトは層間整合と技術負債を、セキュリティ・リスク責任者は残余リスクを説明します。期限付き例外は期限前に標準化、代替、廃止、再承認のいずれかを選びます。

FIGURE 08

運用ガバナンス:月次レビューの確認項目

  • 経営成果から業務能力、データ、アプリケーション、技術、投資施策まで双方向に追跡できる。
  • BPMNに開始・終了、通常経路、判断、例外、責任主体、受渡しデータが表現されている。
  • 重要データに定義、正本、所有者、品質規則、機密区分、保持、利用条件がある。
  • 設計判断に選択肢、評価基準、決定理由、影響、例外、有効期限、再評価条件がある。
  • 変更要求で影響する業務、データ、サービス、連携、権限、運用、指標を特定できる。
  • 導入波ごとに開始条件、受入条件、共存条件、戻し方、旧資産の廃止条件がある。
  • KPIに定義、分母、データ源、更新頻度、基準値、目標、所有者、是正トリガーがある。
  • 例外は承認者、理由、補完統制、期限、縮退計画を伴い、無期限に残らない。
09 / 一次資料

参照した公式一次資料

標準・公式ガイドは、そのまま組織へ適用するのではなく、対象範囲、前提、法令、契約、既存統制に照らしてテーラリングします。公開日・版は導入時に再確認してください。

  • Cybersecurity Framework

    National Institute of Standards and Technology
    サイバーリスク管理の枠組み。本記事では一次資料の趣旨を実務向けに再構成し、個別製品の宣伝資料を根拠にしていません。
  • NIST SP 800-207: Zero Trust Architecture

    National Institute of Standards and Technology
    ゼロトラストアーキテクチャ。本記事では一次資料の趣旨を実務向けに再構成し、個別製品の宣伝資料を根拠にしていません。
  • NIST SP 1800-35: Implementing a Zero Trust Architecture

    National Institute of Standards and Technology
    ゼロトラスト実装指針。本記事では一次資料の趣旨を実務向けに再構成し、個別製品の宣伝資料を根拠にしていません。
  • DAMA-DMBOK

    DAMA International
    データマネジメント知識体系。本記事では一次資料の趣旨を実務向けに再構成し、個別製品の宣伝資料を根拠にしていません。

関連記事

現状調査から、判断可能なEA成果物へ

ゼロトラストとデータセキュリティの構想、現状診断、要件定義、設計レビューを、業務・データ・アプリケーション・技術の一貫した体系で支援します。

相談内容を整理する

本記事は一般的な情報提供を目的としています。個別の法令、契約、セキュリティ、会計、労務、製品仕様への適合は、対象組織の責任者および必要な専門家と確認してください。

NEXT DECISION

解説を、自社の設計判断へ進める

継続的認可をID・データ・業務コンテキスト・監視で実装する

03 / ASSESS

DX実行力を20問で診断

経営戦略、業務、データ、アーキテクチャ、実行・定着の弱点と次の優先行動を可視化します。

無料セルフチェックを始める

自社の前提で判断材料を整理する

製品選定前の構想、停滞案件の立て直し、RFP・要件定義、データ・AI基盤まで相談できます。

専門家へ相談する

この記事を書いた人

関連記事

  1. 物流DXの進め方:企業間データと現場イベントを標準化する実践ガイド

  2. 分散していた在庫情報を統合し、補充判断を早期化

  3. エンタープライズアーキテクチャ(EA)とは?DXを全体最適へ導く実践ガイド

  4. Salesforce Sales Cloudの導入を目標とした要件定義、及び、開発実装、社内教育

  5. 問い合わせ対応を支える生成AI連携基盤を構築

TOP