レッスン6：柱④⑤アプリケーションとデータ——分類を権限につなぐ

このレッスンで学ぶこと

データ分類の先にある、ラベル・暗号化・権限・監査の連鎖を理解する
DLP が、この連鎖のどこに位置づけられるかを把握する
属性ベース認可を、データやアプリへのアクセス判断に応用する発想を身につける
API やサービス間通信、ワークロードの ID という、アプリ層の認可の考え方を理解する

前回のレッスンでは、ネットワークの柱を扱い、VPN からの出口をどう設計するかを見てきました。今回は、5 つの柱のうち残る 2 つ、アプリケーションとワークロードの柱、そしてデータの柱をまとめて扱います。この 2 つは、「誰が」「どんな端末で」「どの経路で」に加えて、「何にアクセスしようとしているのか」という対象そのものを扱う柱です。

なぜアプリケーションとデータをまとめて扱うのか

アイデンティティ・デバイス・ネットワークの 3 つの柱は、いずれも「アクセスする側」の状態を評価する柱でした。誰がアクセスしようとしているか、どんな端末を使っているか、どの経路で到達しようとしているか。これに対して、アプリケーションとワークロードの柱、データの柱は、「アクセスされる側」の状態を扱います。

この 2 つの柱は、密接に関わり合っています。データそのものへのアクセスは、多くの場合、業務アプリケーションを経由して行われます。アプリケーション側の認可設計が甘ければ、どれだけデータを丁寧に分類しても、実際のアクセス制御には反映されません。逆に、データの分類が曖昧なままでは、アプリケーション側でどこまで厳しく制御すべきかの判断基準がありません。両者は、片方だけを進めても機能しない、対になった柱です。

この関係は、これまで扱ってきた 3 つの柱とのつながりでも捉え直せます。アイデンティティの柱で「誰が」を確認し、デバイスの柱で「どんな端末で」を確認し、ネットワークの柱で「どの経路で」を確認しても、最終的にアクセスされる対象そのものの区別ができていなければ、判断はそこで行き詰まります。「極秘データにアクセスしようとしている」という一点が把握できて初めて、それまでの 3 つの柱で集めた情報を、より厳しい基準で評価するという判断ができるようになります。アプリケーションとデータの柱は、ほかの 4 つの柱が集めた情報の「使いどころ」を決める柱だとも言えます。

データ分類の先にあるもの

データ分類そのものは、多くの組織がすでに一定の形で取り組んでいます。公開・社外秘・極秘といった区分は、情報セキュリティ関連の入門コースでも扱われている、比較的なじみのある考え方です。ゼロトラストの文脈でこの先に進むために必要なのは、分類を、実際のアクセス制御に結びつける連鎖です。

分類だけを行って満足してしまうケースは、現場で非常によく見られます。「このデータは極秘に分類されている」という情報が、書類やドキュメントの片隅に記されているだけで、実際のアクセス権限には何も反映されていない、という状態です。分類が機能するためには、次の 4 つの段階を、一続きの連鎖としてつなげる必要があります。

flowchart LR
  L[ラベル] --> E[暗号化]
  E --> P[権限]
  P --> A[監査]

ラベル：分類の結果を、データそのものに機械的に読み取れる形で付与する段階です。人が目視で判断するのではなく、システムが自動的に分類を認識できる状態にします
暗号化：ラベルに応じて、保護の強度を変える段階です。極秘のラベルが付いたデータには、より強い暗号化や、より厳格なアクセス経路を要求します
権限：ラベルと暗号化の設定にもとづいて、誰がそのデータにアクセスできるかを決める段階です。ここで初めて、分類が実際のアクセス制御として機能します
監査：誰が、いつ、そのデータにアクセスしたかを記録し、想定外のアクセスがなかったかを継続的に確認する段階です

この連鎖のどこか一箇所でも途切れると、分類は「ラベルだけが存在する飾り」になってしまいます。例えば、ラベルは付いているが権限には反映されていない、権限は設定されているが監査の記録が取られていない、といった状態です。ゼロトラストの観点から見たデータの柱の成熟度は、この連鎖がどこまで途切れずにつながっているかで測ることができます。

💡 ポイント データ分類そのものは目新しい取り組みではありません。ゼロトラストがこの領域に付け加える価値は、「分類した先で、実際のアクセス制御にまで連鎖させる」という一貫性の要求にあります。分類を作業として終わらせず、権限設計まで一直線につなげる設計姿勢が、この柱の核心です。

連鎖が途切れやすい箇所

現場でこの連鎖を構築しようとすると、いくつかの箇所で途切れが起きやすいことがわかります。

ラベルと権限のあいだ：ラベルは付与されているが、そのラベルを読み取って権限設定に反映する仕組みが整っておらず、権限は従来どおり手作業で設定されたままになっている
権限と監査のあいだ：権限設定は行われているが、実際のアクセスログが十分に保存されておらず、想定外のアクセスがあったかどうかを事後に確認できない
既存システムとの接続部分：新しく整備した分類とラベルの仕組みが、古い業務システムのデータ形式に対応しておらず、一部のデータだけ連鎖の外に取り残される

いずれの途切れも、一箇所を直せば解決するわけではなく、連鎖全体を通しで点検する作業が必要になります。データの柱の成熟度を評価する際には、「分類の仕組みがあるかどうか」ではなく、「分類が権限と監査まで途切れずにつながっているかどうか」を基準にすることが重要です。

DLP の位置づけ

この連鎖を運用の中で維持するために使われる仕組みの一つが、DLP です。DLP は、ラベルにもとづいて、データが想定外の経路で外部に持ち出されようとしていないかを監視し、必要に応じて制御する仕組みです。

例えば、極秘のラベルが付いたファイルを、個人のメールアドレスに送信しようとした場合や、許可されていないクラウドストレージにアップロードしようとした場合に、その操作を検知し、警告を出す、あるいは操作そのものをブロックします。DLP は、ラベル・暗号化・権限という前段の設計があって初めて機能する仕組みであり、分類がなされていないデータに対しては、何を守ればよいのかを判断できません。

⚠️ 注意 DLP を導入すれば、データの流出を自動的に防げると期待されがちですが、DLP はあくまで、前段の分類とラベルの精度に依存する仕組みです。分類が粗ければ、DLP の判断も粗くなります。DLP の導入を検討する前に、まずラベルと権限の連鎖が機能しているかを確認することが順序として重要です。

属性ベース認可の実際

レッスン 3 で、RBAC と ABAC という 2 つの認可方式を紹介しました。データとアプリケーションの柱では、この ABAC の考え方が特に力を発揮します。

データそのものが持つ属性（分類のラベル、作成部署、作成日時など）、利用者が持つ属性（所属部署、役職、雇用形態など）、そしてアクセス時の環境の属性（利用している端末の信頼度、アクセス元の場所、時間帯など）。これら複数の属性を組み合わせて、そのつどアクセスの可否を判断するのが、データとアプリケーションの柱における ABAC の実際の使われ方です。

具体的な例で考えてみましょう。「人事部が作成した、社外秘に分類された評価データ」に対して、「人事部に所属し、かつ管理対象端末を使用している利用者」にだけ、閲覧権限を与える、というポリシーを考えます。この場合、データの属性（作成部署・分類）、利用者の属性（所属部署）、環境の属性（端末の信頼度）という 3 種類の属性が組み合わされています。RBAC のように「人事部の役割を持つ利用者にはすべての人事データを見せる」という粗い設計ではなく、データの分類や、アクセス時の状況まで踏み込んで判断する点が、ABAC の実際の強みです。

属性の種類	具体例
データの属性	分類のラベル、作成部署、機密度
利用者の属性	所属部署、役職、雇用形態
環境の属性	端末の信頼度、アクセス元の場所、時間帯

レッスン 3 で述べたとおり、ABAC は条件の組み合わせが複雑になりやすいため、すべてのデータに一律で適用するのではなく、機密度の高いデータや、規制上の要求が強い領域に絞って適用するのが、実務での現実的な進め方です。

もう一つ例を挙げます。「取引先から共有された契約データ」に、「その取引先の担当窓口になっている利用者」だけがアクセスできるようにしたい場合を考えてみましょう。RBAC の発想では、「営業部」という役割を持つ利用者全員に契約データへのアクセス権を与えることになり、担当外の取引先の契約まで見えてしまいます。ABAC であれば、「データの属性（取引先名）」と「利用者の属性（担当している取引先の一覧）」を突き合わせ、一致する場合にだけアクセスを許可する、という細かい制御が可能になります。役割という単位では表現しきれない対応関係を、属性の突き合わせによって実現できる点が、データの柱における ABAC の実務的な価値です。

アプリ層の認可——API・サービス間通信・ワークロードの ID

ここまでは、人がデータやアプリケーションにアクセスする場面を中心に扱ってきました。しかし、現代の業務システムでは、人だけでなく、システムとシステムが直接やり取りする場面が数多く存在します。API を通じたデータの受け渡しや、複数のアプリケーションが連携して一つの業務処理を完了させる仕組みは、その代表例です。

こうしたシステム同士のやり取りにも、ゼロトラストの原則は適用されます。人の利用者にアイデンティティがあるように、個々のアプリケーションやサービスにも、ワークロードの ID と呼ばれる識別情報を持たせ、通信の相手が正しいサービスであることを、そのつど確認します。API を経由した通信であっても、「呼び出し元のサービスは何か」「そのサービスは、この処理を実行してよい権限を持っているか」を確認する仕組みが必要です。

サービス間通信では、次のような設計が典型的です。

個々のサービスに、固有のワークロード ID を割り当てる
サービス間の通信は、そのワークロード ID にもとづいて相互に認証する
API ごとに、呼び出しを許可するワークロード ID の範囲を定義する
通信の記録を残し、想定外のサービスからの呼び出しがないかを監視する

この設計は、レッスン 3 で扱った条件付きアクセスの考え方と、構造的によく似ています。違いは、判断の対象が人の利用者ではなく、システムそのものである点です。ゼロトラストの原則を、人だけでなくシステム間の通信にも一貫して適用することが、アプリケーションとワークロードの柱における、成熟度の高い状態です。

伝統的な業務システムの設計では、社内ネットワークの内部にあるサービス同士の通信は、無条件に信頼されることが少なくありませんでした。「同じ社内ネットワークの中にいるサービス同士だから安全」という発想は、レッスン 1 で見た境界防御の発想が、アプリケーション層にまで及んでいる状態です。一つのサービスが侵害されると、そこから無条件に信頼されているほかのサービスへと、被害が連鎖的に広がるリスクがあります。ワークロードの ID による相互認証は、この連鎖を断ち切るための仕組みでもあり、レッスン 5 で見たラテラルムーブメントの発想を、アプリケーション層に応用したものだと理解すると、柱同士のつながりが見えやすくなります。

📝 補足 人の利用者向けのアイデンティティ管理と、システム向けのワークロード ID の管理は、担当する部署やツールが異なることが少なくありません。データとアプリケーションの柱の成熟度を上げる際には、この 2 つの管理が、別々の仕組みとして孤立していないかを確認する視点が有効です。

アプリケーションとデータの柱の成熟度を段階で見る

レッスン 2 で紹介した 4 段階の成熟度を、この 2 つの柱に当てはめると、次のような姿になります。

段階	アプリケーションとデータの柱での典型的な状態
伝統的	データ分類は文書の見出しに記載される程度で、権限設計や監査には反映されていない
初期	一部の重要なデータにラベルが付与され、DLP による監視が部分的に始まっている
高度	主要なデータでラベル・暗号化・権限の連鎖がつながり、属性ベース認可が高リスクな領域に適用されている
最適	データとアプリケーションの双方で連鎖が一貫し、ワークロードの ID による認可がシステム間通信にも徹底されている

この表からわかるとおり、伝統的段階から初期段階への一歩は、すべてのデータを一斉にラベル付けすることではありません。まずは機密度の高い一部のデータから、連鎖を実際につなげてみることが、現実的な第一歩になります。

アプリケーションとデータの柱でよくあるつまずき

この 2 つの柱に着手する組織が、共通してつまずきやすい点を整理しておきます。

分類の粒度を最初から細かくしすぎる

データ分類を精緻に設計しようとするあまり、区分の数を増やしすぎると、現場での運用が回らなくなります。「公開・社外秘・極秘」のような大まかな区分から始め、必要に応じて細分化していく方が、連鎖を実際に機能させやすくなります。

ラベル付けを利用者の判断に委ねきってしまう

文書を作成した利用者本人に、分類のラベル付けをすべて任せる運用は、判断のばらつきや付け忘れを生みやすくなります。テンプレートによる初期ラベルの自動付与や、一定のキーワードを含む文書への自動分類など、仕組みで支援する設計が、連鎖の安定運用には欠かせません。

アプリケーションの認可を後回しにする

データの分類やラベル付けにばかり注力し、それを実際に読み取って権限を制御するアプリケーション側の対応が後回しになるケースがあります。分類が進んでも、アプリケーション側が対応していなければ、連鎖は「権限」の段階で途切れてしまいます。データとアプリケーションを一体の取り組みとして計画することが重要です。

ワークロードの ID の整備を人向けの基盤と別扱いにする

人の利用者向けのアイデンティティ管理を担当する部署と、システムやサービス間の通信を担当する部署が別々になっている組織では、ワークロードの ID の整備が独自の判断で進められ、条件付きアクセスの設計思想と整合しないまま構築されてしまうことがあります。人向けとシステム向け、2 つのアイデンティティ管理の間で、判断の一貫性を保つ調整の場を設けることが、この柱の成熟度を安定して引き上げる鍵になります。

まとめ

このレッスンでは、以下のことを学びました。

アプリケーションとワークロードの柱、データの柱は、「アクセスされる側」の状態を扱う、対になった柱である
データ分類は、ラベル・暗号化・権限・監査という連鎖につながって初めて、実際のアクセス制御として機能する
DLP は、ラベルにもとづいてデータの想定外の持ち出しを監視・制御する仕組みで、前段の分類の精度に依存する
属性ベース認可は、データ・利用者・環境という複数の属性を組み合わせて、そのつどアクセス可否を判断する
API やサービス間通信にも、ワークロードの ID を通じたゼロトラストの原則が適用される

次のレッスンでは、5 つの柱すべてを支える横断的機能——継続的検証、可視化と分析、自動化とオーケストレーション、ガバナンス——を扱います。柱ごとの設計を、組織全体としてどう束ねるかを見ていきます。

確認クイズ

このレッスンの理解度をチェックしましょう。