情シス部門のゼロトラスト導入に向けて#4　動的ポリシーについて考えてみよう

最近バズワードになっている「ゼロトラスト」について「会社の指示で情シス部門がゼロトラストを導入しなければならない」、「クラウドにSSOを導入するのと何が違うのか」といった相談がありました。ゼロトラストについてうまく説明できないとしたら、予算を作ることも導入に踏み切ることも難しいと思います。こうした疑問についてNISTやIPAのゼロトラスト・アーキテクチャからラックの考えるゼロトラストについてひもといて行きたいと思います。

アクセス制御ポリシー作成するためには利用者、端末、場所などから業務で必要となる様々なクラウドサービス等のアクセスを洗い出して、ゼロトラストの成熟度を判断する必要があります。そこで前回は、クラウドの普及が進み始めた2016年をモデルケースとして、NISTによるゼロトラストの考え方から「企業リソースへのアクセスは、セッション単位で付与する」について解説しました。

今回は「リソースへのアクセスは、クライアントID、アプリケーション、要求する資産の状態、その他の行動属性や環境属性を含めた動的ポリシーによって決定する」について、ラックの考えるゼロトラストをお伝えいたします。

NISTの基本的な考え方

NISTによるゼロトラストの考え方

• 1.すべてのデータソースとコンピューティングサービスはリソースとみなす
• 2.ネットワークの場所に関係なく、全ての通信を保護する
• 3.企業リソースへのアクセスは、セッション単位で付与する
• 4.リソースへのアクセスは、クライアントID、アプリケーション、要求する資産の状態、その他の行動属性や環境属性を含めた動的ポリシーによって決定する
• 5.企業は、全ての資産の整合性とセキュリティ動作を監視し、測定する
• 6.全ての資産の認証と認可は動的に行われ、アクセスが許可される前に厳格に実施する
• 7.企業は、資産やネットワークインフラストラクチャ、通信の現状について可能な限り多くの情報を収集し、それをセキュリティ対策の改善に利用する

出典 PwCコンサルティング NIST SP800-207「ゼロトラスト・アーキテクチャ」の解説と日本語訳

PwCコンサルティングが翻訳したNISTによるゼロトラストの考え方は、端的に言えば1は対象範囲、2は通信保護、3は権限付与、4はポリシー、5は監視、6は認証認可、7は改善活動です。つまり情報セキュリティとは、機密性、完全性、可用性の3つの概念によって構成されていましたが、さらに7つの概念を加えます。

前回は3の権限付与について、クラウドの普及が進み始めた2016年をモデルケースに掘り下げて解説しておりますが、今回の4「リソースへのアクセスは、クライアントID、アプリケーション、要求する資産の状態、その他の行動属性や環境属性を含めた動的ポリシーによって決定する」も同様に対象は「アイデンティティ管理/ログオン管理/アクセス許可製品（SSO含む）」となります。

「アイデンティティ管理/ログオン管理/アクセス許可製品（SSO含む）」 導入率19.0%

最近は、業務でクラウドサービスを利用することも一般的になってきたと思います。例えばActive Directoryと社内システムを1つのパスワードでログインできるSSOを導入していたとしても、様々なクラウドサービスまではSSOに対応できませんでした。そこで、アイデンティティ・プロバイダーが提供するIDaaSは様々なクラウドサービスに対応しておりSSOが利用できます。さらにアクセス元の信頼性を評価して認証認可を行います。

IDaaS (Identity as a Service：アイダース，アイディーアース)

クラウド上の様々なサービスの ID 管理を一元的に行うクラウドサービスのこと。SaaS（Software as a Service）等への認証（多要素認証，シングルサインオン）・認可（アクセスコントロール）・ID 管理・ID 連携を行う機能を有している。

• シングルサインオン（認証）
  一度メインの ID 管理システムへサインインすれば，他の複数のサービスやシステムへのサインインを自動で行ってくれる機能のこと。利用者は，サービス毎に ID・パスワードを入力する必要がなくなる。
• アクセスコントロール（認可）
  サービス・フォルダ等にアクセスが可能な利用者や端末，場所等に制限をかけ，管理者の許可を得た利用者のみがサービスを利用できるようにする。
• ID 管理
  アカウント作成や削除及び配属変更時の情報変更を一元管理が行えるサービス。アカウント情報をもつマスターシステムの情報を変更することによりシステム毎に情報を変更する必要がなくなる。

出典 IPA ゼロトラスト導入指南書 ～情報系・制御系システムへのゼロトラスト導入～

参考例：Microsoft ADFS、Okta、HENNGE、Cyber Ark、Ping Identityなど

参考までに、最新の実態調査ではアイデンティティ管理が6.2%に低下していることから、導入する上で何かしらの障壁があることが推測されます。こうした現状を踏まえて、ひも解いていきます。

NISTの考え方に対する現状とのギャップ

NISTの基本的な考え方＜ポリシー＞

組織は、どのようなリソースを持っているか、そのメンバーが誰であるか（またはコミュニティにおけるユーザーに関する認証）、またそれらのメンバーが必要とするリソースへのアクセスを定義することで、リソースを保護します。ゼロトラストの場合、クライアントアイデンティティには、ユーザーアカウント（またはサービスアイデンティティ）と、企業がそのアカウントに割り当てた関連属性、または自動化されたタスクを認証するための機能を含められます。リクエストする資産の状態には、インストールされているソフトウェアのバージョン、ネットワークの場所、リクエストの日時、以前に観察された動作、インストールされているクレデンシャルなどのデバイスの特性を含められます。

行動属性には、自動化された主体（ユーザー）の分析、デバイスの分析、および観察された使用パターンからの測定された逸脱が含まれますが、これらに限定されないポリシーとは、組織が主体（ユーザー）、データ資産、またはアプリケーションに割り当てる属性に基づくアクセスルールのセットです。環境属性には、アクセス元のネットワークの場所、時間、報告されたアクティブな攻撃などが含まれます。これらのルールと属性は、ビジネスプロセスのニーズと許容可能なリスクレベルに基づいています。リソースのアクセスとアクションの許可ポリシーは、リソース／データの機密性に基づいて変化します。最小特権の原則により、可視性とアクセス性の観点から制限します。

出典 PWC NIST SP800-207「ゼロトラスト・アーキテクチャ」の解説と日本語訳

NISTによると、ゼロトラストでは、クライアントのアイデンティティやリクエストする資産の状態、行動属性、環境属性などを考慮します。そこで、組織のリソースを保護するために、どのようなリソースを持っているか、メンバーが誰であるか、そして必要とするリソースへのアクセスを定義します。ポリシーには、ビジネスのニーズと許容可能なリスクレベルに基づいて、主体（ユーザー）、データ資産、またはアプリケーションに割り当てる属性に基づくアクセスルールを決めます。すなわち、リソースのアクセスとアクションの許可ポリシーは、機密性に基づいて動的に変化し、最小特権の原則によって制限します。

アクセス制御の一般論として「情シス部門のゼロトラスト導入に向けて#3　権限付与について考えてみよう」が参考になると思います。一方で今回は、新たに機密性に基づいて動的に変化する、リソースのアクセスとアクションの許可ポリシーについて考察します。

ABACの基本的な考え方

アクセス制御モデルについて

RBAC

例えば、Active Directoryではドメイン単位で組織図の役割（ロール）に基づくアクセスルールを与える役割（ロール）ベース（RBAC）が用いられています。

このようなアプローチは、管理が煩雑になりがちです。例えば、図「従来型（非ABAC）の複数組織アクセス方式」では、example.com（組織A）の営業部に所属する佐藤さんが、組織Bのリソースにアクセスする場合、事前に佐藤さんのアカウントを組織Bで作成しアクセスリストに登録することが必要です。

さらに、主体（ユーザー）と役割（ロール）の関連付けに基づいて決定を下すRBACは、実世界のアクセス要求を表すには不十分であることが多いです。動的なアクセス制御が必要な場合、アドホックにメンバーシップが限定された多数の役割（ロール）を作成する必要があり、しばしば「ロールの爆発」と呼ばれる事態を招きます。

ABAC

一方で、ゼロトラストにおいては機密性に基づいて動的に変化する、行動属性、環境属性などに基づくアクセスルールを与えるため、属性ベース（ABAC）を用います。

これは、組織をまたいで一貫して定義されている主体（ユーザー）とオブジェクトの属性によって、個々の主体（ユーザー）に権限を直接割り当てる必要性を回避することで、適切なセキュリティレベルを維持しながら、認証と認可の活動を同じまたは別のインフラストラクチャで実行および管理できます。よって、アクセス制御リストや役割（ロール）とグループの管理に手間のかかるような大規模な組織でも柔軟に対応できます。

※ Attribute Based Access Control（ABAC）：オブジェクトに対する要求を、主体（ユーザー）属性、オブジェクトの属性および環境の条件、それらの属性と条件から定義される一連のポリシーに基づいて許可または拒否するアクセス制御方法。

ABACの概要としては、図「基本的なABACシナリオ」に示すように、ABACアクセス制御機構（ACM）が主体（ユーザー）のアクセス要求を受け取り、主体（ユーザー）とオブジェクトの属性を特定のポリシーに照らし合わせて判断します。

基本的なABACシナリオ

1. 主体（ユーザー）がオブジェクトへのアクセスを求める
2. アクセス制御機構（ACM）は以下の条件から判定する
   • a.アクセス制御ポリシー
   • b.主体（ユーザー）属性
   • c.オブジェクト属性
   • d.環境条件
3. 主体（ユーザー）は、許可された場合、オブジェクトへのアクセスを許可する

各項目の説明

• 主体（ユーザー）
  オブジェクトに対する操作を実行するためにアクセス要求を発行します。
• オブジェクト
  ABACによってアクセスが管理されるリソースであり、情報を保有、または受信するデバイス、ファイル、レコード、テーブル、プロセス、プログラム、ネットワーク、またはドメインなど、主体（ユーザー）によって操作されるあらゆるものが含まれます。
• 属性
  主体（ユーザー）、オブジェクト、または環境条件の特徴を名前と値のペアで与えられます。
• アクセス制御ポリシー
  主体（ユーザー）やオブジェクトの属性値、場合によっては環境条件などを考慮して、要求されたアクセスを許可すべきかどうかを判断するためのルールや関係です。
• 環境条件
  アクセス要求が発生する運用上または状況に関する条件。環境条件とは、主体（ユーザー）や オブジェクトに依存せず、現在の時刻、曜日、ユーザーの位置、現在の脅威レベルなど測定可能な環境特性を用います。
• 実行
  読み取り、書き込み、編集、削除、コピー、実行、変更など主体（ユーザー）の要求による機能の実行です。
• アクセス制御機構（ACM）
  主体（ユーザー）からアクセス要求を受け取り、主体（ユーザー）およびオブジェクトの属性をアクセス制御ポリシーに照らしてアクセスを決定する論理コンポーネント

つまり、Active Directoryではドメイン単位で組織図の役割（ロール）に基づくアクセスルールを与えていたものを、ABACでは、オブジェクト作成時に属性が割り当てられており、アクセス制御ポリシーに既存の役割（ロール）に基づくアクセスルールと環境条件（勤務時間、平日、社内など）に基づいたルールを付与してアクセス許可を判断できます。また新しい主体（ユーザー）が組織に加わると属性が付与され、ルールやオブジェクトを修正する必要はありません。

ABACのポリシーと属性について

ISMS（ISO27000シリーズ）などを用いてリスクアセスメントを行いアクセス制御ポリシーについて検討します。

参考：情シス部門のゼロトラスト導入に向けて#3　権限付与について考えてみよう

なお、多くの企業では、セキュリティポリシーまたはセキュリティガイドラインを作成しており、従業員のアクセスに関する資格管理を行っています。このような文書化されている既存のルールからアクセス制御機構（ACM）で実行可能なデジタルポリシー（DP）を作成します。これは、主体（ユーザー）の属性とオブジェクトの属性、そしてアクセス制御ポリシーを作成しリポジトリに保存し、組織間で作成、保存、共有します。

ABACを組織間で用いる場合は、公平かつ一貫したルールの適用が必要なため、主体（ユーザー）とオブジェクトの全てのパターンと許容する操作を特定します。そこから組織間におけるデジタルポリシー（DP）の階層的な権限、競合、また保存と更新を行うためのDPを管理する、メタポリシー（MP）を定義します。主体（ユーザー）属性およびオブジェクト属性は、同等のポリシーを実施できるように組織間でマッピングされ、一貫性を持たせる必要があります。このような属性を管理する上でメタ属性を用いて定義します。

なお、デジタルポリシー（DP）とメタポリシー（MP）を管理、保管、検証、更新、優先順位付け、コンフリクトの解消、共有、廃止、実施する必要があります。そのためデジタルポリシー管理（DPM）が用いられます。

参考：
Microsoft Azure Policy とは | Microsoft Learn
IAM でのポリシーとアクセス許可 - AWS Identity and Access Management
Google Anthos Config Management - Policy Controller

ABACの導入について

ABAC導入に関する配慮

「IPA 2021年度 中小企業における情報セキュリティ対策に関する実態調査」の「アイデンティティ管理/ログオン管理/アクセス許可製品（SSO含む）」ではアイデンティティ管理が6.2%に低下していることから、導入に障壁があることが想定されます。
そこで、IPAの「ゼロトラスト移行のすゝめ」Phase5の検証・改善に以下のような説明があります。

ゼロトラスト環境は、構築して終わりではない。IDaaS のアクセスポリシーや、EDR、SIEM の脅威検知ルールなど、あらゆるソリューションで運用の中でのチューニングが必要である。その際、セキュリティ強度を求めすぎた結果、ユーザー利便性の低下に繋がってはいけない。セキュリティ強度とユーザー利便性のバランスの取れたゼロトラスト環境を維持するためには、日々ユーザーの声に耳を傾ける必要がある。

出典 IPA ゼロトラスト移行のすゝめ

つまり、アイデンティティ管理の導入に障壁があることについて「ゼロトラスト環境は、構築して終わりではない」ことが要因として考えられます。そこで、実装に取り組む際に障壁となった課題として、68.6%が実装にコスト（時間・人・予算）が掛かり過ぎる・不足していると挙げられています。

つまり日々ユーザーの声に耳を傾ける中で、必要に応じて、Phase3に立ち返り、投資判断を行う必要があります。

PwCコンサルティングが翻訳したNISTによるゼロトラストの考え方は、端的に言えば1は対象範囲、2は通信保護、3は権限付与、4はポリシー、5は監視、6は認証認可、7は改善活動といった考え方を基に、論理的構造と設計思想などゼロトラスト・アーキテクチャを説明したものです。

そこで、組織の管理や運営についてはマネジメントフレームワークを適用します。
マネジメントフレームワークについて、NIST SP800-207「Zero Trust Architecture」P.32には、第6章「ゼロトラスト・アーキテクチャと既存の連邦ガイダンスとの連携の可能性」があります。

既存の連邦政府の政策とガイダンスのいくつかは、ZTAの計画、展開、運用と関連しています。これらのポリシーは、企業にとってゼロトラスト指向のアーキテクチャへの移行を妨げるものではありませんが、省庁のゼロトラスト戦略の策定が影響を与える可能性があります。

出典 PWC NIST SP800-207「ゼロトラスト・アーキテクチャ」の解説と日本語訳

つまり、連邦政府の政策とガイダンスは、ゼロトラスト・アーキテクチャの計画、展開、運用と関連しており、企業にとってもゼロトラストの移行に利用できます。

既存のサイバーセキュリティポリシーやガイダンス、ID クレデンシャルおよびアクセス管理、継続的な監視、さらにサイバーハイジーンなどを補完すれば、ZTAは組織のセキュリティポスチャーを強化し、多くの脅威から組織を守ることができます。

出典 PWC NIST SP800-207「ゼロトラスト・アーキテクチャ」の解説と日本語訳

また、ゼロトラストだけでなく、セキュリティ体制の強化が重要です。なお、サイバーセキュリティポリシーやガイダンス、ID クレデンシャルおよびアクセス管理、継続的な監視については、それぞれ

• IPA中小企業の情報セキュリティ対策ガイドライン
• LAC WATCH連載「デジタル・アイデンティティのセキュリティを考える」
  デジタル・アイデンティティのセキュリティを考える#3　NIST SP 800-63-3 認証の "レベル"
• ゼロトラスト移行のすゝめ　p.10「ログ収集・分析」の関連するソリューションとしてSIEM

などを参考にしてください。

続いて「6.1 ゼロトラスト・アーキテクチャとNISTリスクマネジメントフレームワーク」を確認します。ここに「ゼロトラスト環境は、構築して終わりではない」ことの対策が書かれております。

ZTAの導入には、指定されたミッションまたはビジネスプロセスに対する許容可能なリスクに関するアクセスポリシーの策定が必要です。リソースへのネットワークアクセスをすべて拒否し、接続された端末経由のアクセスのみを許可することは可能ですが、大半のケースで不釣り合いな制限となり、業務の達成を阻害する可能性があります。連邦機関がその使命を遂行するためには、許容できるレベルのリスクが存在します。与えられた任務の遂行に関連するリスクを特定し、評価し、受け入れるか、軽減しなければなりません。これを支援するために、NISTリスクマネジメントフレームワーク（RMF）が開発されました[SP800-37]。

出典 PWC NIST SP800-207「ゼロトラスト・アーキテクチャ」の解説と日本語訳

要約すると、ゼロトラストを導入すると大半のケースで業務を阻害するため、見直しが必要です。そこでNIST SP800-37 リスクマネジメントフレームワークを活用しましょう。

ABACの導入にシステムリスクマネジメントフレームワークを適用する

こちらが、NIST SP800-37 リスクマネジメントフレームワークです。図に示されたリスクマネジメントフレームワークは、ステップが1から6まであります。そして、ステップ1にアーキテクチャについての記述があり「SP800-207 ゼロトラスト・アーキテクチャ」はここにあたるものです。さらに必要に応じて、投資判断を行う必要があると思います。

よって、このフレームワークは、情報セキュリティとリスクマネジメント活動をシステム開発ライフサイクルに組み入れるためのものです。

例えば、ステップ5の継続的な運用認可判断からのフィードバックをリスクエグゼクティブに提供する、ステップ6脅威およびリスクに関する最新情報を運用認可責任者および情報システムのオーナーに提供します。これが、情報セキュリティ要求事項を、システム開発ライフサイクルに組み入れられるだけでなく、組織内のプログラム、計画、および予算編成活動にも組み入れられ、これにより組織は、必要な時にリソースを利用できるようになり、組織内の活動も一元的に管理され、プロジェクトのマイルストーンも達成することができます。

つまり組織を保護するための最も費用対効果が高く効率的な手段となります。

具体的には、「ゼロトラスト移行のすゝめ 投資判断（Phase3）の投資効果に関するポイント」を踏まえつつ、投資の承認を得るため、経営者に向けて「この対策を行わなかった場合、このような被害が出る可能性がある」といったホラーストーリーで説明することはおすすめできません。

なぜなら、どの程度の確率でどの程度の被害が発生するのかも不確実で分かりにくく、理解されない場合があるからです。IT戦略として捉え「どのようなリスクに対応可能になるか」といったセキュリティ観点の効果と併せて、「ユーザーの利便性向上」や「運用の効率化」などを総合的に盛り込んで説明を行うことが重要です。

すなわち、セキュリティ管理策がどの程度正しく導入されているか、どの程度意図した通りに運用されているか、システムのセキュリティ要求事項に対する適合性の観点から所望の結果をどの程度算出しているかを判断するために、ステップ4のセキュリティ管理策をアセスメントしてください。これには予算や目的に合わせて脆弱性診断やペネトレーションテストなどが有効です。

念のために、NIST SP 800-37 Revision 2として2018年に改訂されております。改訂の目的の一つとして、より効果的、効率的、費用対効果の高いリスクマネジメントフレームワークの実施を促進するための柔軟なステップ構造として、新たに「準備」を加えて制度化しております。準備のステップが完了した後は順不同に実行できます。

ABACの導入にシステム開発ライフサイクルを適用する

システム開発ライフサイクルとは、着手、分析、設計、実装、保守から廃棄までの多段階のプロセスを通じて、情報システムを開発、実装、廃止させる全体のプロセスです。ここでは着手フェーズについて解説を行います。

着手フェーズ

ABACを導入する上で、業務を分析し、対象とするスコープを定義する必要があります。その為に他の組織からのケーススタディや導入実績レポートが参考になります。ゼロトラスト成熟度モデルを用いた段階的なアプローチで、対象とするスコープを限定して実装することで、ポリシーと属性の定義が洗練され、企業全体でより広範なABACの使用をサポートするために必要なガバナンスが発揮できます。

参考：情シス部門のゼロトラスト導入に向けて#3　権限付与について考えてみよう - ゼロトラスト成熟度モデル

ABACを組織間で用いる場合は、公平かつ一貫したルールの適用が必要ですが、スケーラビリティの観点から企業の規模が大きく、多様であるほど、主体（ユーザー）とオブジェクトのパターンが複雑になっていきます。またフィージビリティの観点でアプリケーションがサポートできるかチェックが必要です。こうした潜在的な相互作用にはパフォーマンスの負荷に繋がるため、対象とするオブジェクトのスコープを決定する際に評価します。

このようなスケーラビリティ、フィージビリティ、およびパフォーマンス要件を考慮したうえで、最適なアーキテクチャを構築します。

移行について

ABACが導入され、アクセス制御が変わると、新しいプロセスや機能を日々の業務や既存のやり方に統合させる必要があります。なぜ移行する必要があるのか、既存のやり方にどのような影響があるのかユーザーに理解してもらいます。

具体的には、ABACを使用するために必要なアプリケーションの改修するコストには、主体（ユーザー）の属性とポリシーの管理・保守のコスト、および追加のシステムサポートなど予め考慮します。企業によっては特定の規制や指令への準拠を証明するため、各個人がどのようなアクセス権をもっているのか確認したい場合、または監査を実施する上で、特定のオブジェクトまたはオブジェクト属性に割り当てられた個々のリソースへのアクセス権を所有している人を決定することは、ABACの場合は労力が必要となります。

オブジェクトの保護要件の理解

オブジェクトのアクセスへは、ローカルなビジネスルール、暗黙知や長年に渡って積み重ねられたポリシーなどによってコントロールされています。ABACを実装する上で、そのような既存の保護要件について徹底的に分析して理解する必要があります。理解の解像度が低いと開発と実装にかかるコストは劇的に増加します。よってABACの実装は、十分に保護要件を理解したうえで定義され、管理され、文章化されたオブジェクトに適用することを推奨します。

ガバナンスコントロール

ABACの導入を成功させるためには、業務プロセスと技術的要素の調整と決定をするうえで、企業の責任と権限の確立が必要となります。このような適切なガバナンスモデルがなければ、システムはサイロ化して開発は大幅に遅れることになります。

ABACの実装に関する展開と移行における一貫性のある管理を行うため、各組織は主体的に推進することが必要です。更に「トラストモデル」を開発し、情報とサービスの所有権および責任、追加のポリシー、ガバナンスの必要性、信頼関係の検証または、実施するソリューションの要件を決定することに役立てます。この「トラストモデル」によって、情報がどのように使用され保護されるかについて明確になり、他の組織を信頼して情報を共有することが出来ます。

さらに、企業の認証サービスは、セキュリティ監査、データ損失防止、セキュリティ構成管理、継続的な監視、およびサイバーディフェンスと統合する必要があります。企業のセキュリティ要件とABACの実装がもたらす影響を十分に理解することが必要です。

ABACが適切に機能するためには、アクセス制御リスト（ACL）はオブジェクトの所有者または管理者によって確立されており、ACLにユーザーを追加することでオブジェクトへのアクセスを提供し、オブジェクトのアクセスルールを実施するトラストチェーンが必要です。ABACのトラストアンカーは、主体（ユーザー）属性やポリシーなどの多くのソースから得られます。

組織に内在するリスク源は多岐にわたるため、企業をリスクから保護するために一貫したポリシーを実装したガバナンスモデルを確立します。そのためトラストアンカーと、不正なアクセスを監視するための仕組みを組織全体で推進し、リスクを管理することが必要です。

オブジェクトの識別とポリシーの割り当て

保護する対象のオブジェクトを識別し、分類し、ポリシーを割り当てる一連のビジネスプロセスを確立するために、予めオブジェクトをリストアップし、ポリシーまたはルールを文章化する必要があります。

属性のポリシー定義とアーキテクチャ

アクセス制御ポリシーは、属性の観点から作成します。したがって必要な属性はすべて定義され、ポリシーによって許容値を定めた属性のスキーマを用意します。スキーマに基づいてオブジェクト所有者がルールを作成し、属性リポジトリ、検索サービス、完全性チェックサービスのアーキテクチャを確立します。

主体（ユーザー）属性

対象となる主体（ユーザー）の属性は、業務上の役割、物理的な場所、送信されたデバイスなどが含まれており、評価し品質を保証するプロセスが必要です。そこで、主体（ユーザー）属性を提供する機能は、品質、保証、プライバシー、およびサービスに関して、信頼できる属性実施書（APS：Attribute Practice Statement）を定義します。これは、企業全体で使用する属性のリストを提供して、信頼できる属性ソースを特定できます。さらに、組織間で主体（ユーザー）属性を共有するために、属性の機密性、完全性、可用性を維持する能力を考慮したネットワークインフラが必要です。

オブジェクトの属性

オブジェクトの作成時にオブジェクトの所有者または管理者が、適切にオブジェクト属性を割り当て、外部のリポジトリに保存して参照できるようにします。また、属性の割り当てを検証して適切なアクセスをサポートする仕組みが必要です。

• オブジェクトの属性値（アクセス権限）をユーザーは把握しない、アクセス制御メカニズム（ACM）が判断して、ユーザーは自身に適用される属性値のみ把握できる
• オブジェクト属性は、属性名と許容値を定める属性のスキーマが必要
• 属性は、デジタルポリシー（DP）、メタポリシー（MP）、自然言語ポリシー（NLP）で一貫性を保つこと

環境条件

アクセス要求を認可する際に、現在の日付、時間、場所、脅威、システム状態などの環境条件を評価します。ABACポリシーは、このように主体（ユーザー）／オブジェクト属性だけでは記述できない動的なアクセス制御（ABAC）ルールを指定できます。このようなルールを構成する際には、環境条件変数とその値がグローバルにアクセス可能であること、改ざんを防止すること、実際の使用環境に関する情報であることのチェックが重要です。

アクセス制御ルール

自然言語ポリシー（NLP）を正確かつ完全に反映し、適用、維持、共有および公開する必要があります。共有と保護の適切なバランスを調整する新たな技術を取り入れ、オブジェクトに適用されるルールを可視化することで、主体（ユーザー）が属性を操作し不正な権限を得られないようにすることや、アクセスを拒否された主体（ユーザー）が、拒否の原因となった理由を知ることや修正できる方法も必要です。また、組織の管理者が拒否された状況を追跡して、ルールが適切であったか確認することがあります。このようなルールの矛盾を判断するためのルールデコンフリクション（ルール衝突回避）機能と解決のプロセスが必要です。

アクセス制御メカニズム（ACM）は、オブジェクト保護の競合や脆弱性を避けるため、例えば同一オブジェクトを2つの組織が保有している場合など、相互運用性を考慮した管理、維持、適用の一貫性が必要です。コンテキストハンドリングとは、アクセス制御の決定を行う際に必要な環境条件であり、データ収集するワークフローです。さらに、パフォーマンスとスケーラビリティの観点からも、ポリシー、属性など、それらの情報が組織のどこに、どのように保存され、交換されるかは、重要な検討事項です。

最後に

ゼロトラストでは、クライアントのアイデンティティやリクエストする資産の状態、行動属性、環境属性などを考慮します。そこで、組織のリソースを保護するために、どのようなリソースを持っているか、メンバーが誰であるか、そして必要とするリソースへのアクセスを定義します。ポリシーには、ビジネスのニーズと許容可能なリスクレベルに基づいて、主体（ユーザー）、データ資産、またはアプリケーションに割り当てる属性に基づくアクセスルールを決めます。

すなわち、リソースのアクセスとアクションの許可ポリシーは、機密性に基づいて動的に変化し、最小特権の原則によって制限する必要がありました。これらが「リソースへのアクセスは、クライアントID、アプリケーション、要求する資産の状態、その他の行動属性や環境属性を含めた動的ポリシーによって決定する」についての考え方となります。

経験豊富な専門家に相談を

しかし、「IPA2021年度 中小企業における情報セキュリティ対策に関する実態調査」の「アイデンティティ管理/ログオン管理/アクセス許可製品（SSO含む）」ではアイデンティティ管理が6.2%に低下していることから、導入に障壁があることが想定されます。

つまり、アイデンティティ管理の導入に障壁があることについて「ゼロトラスト環境は、構築して終わりではない」ことが要因として考えられます。そこで、実装に取り組む際に障壁となった課題として、68.6%が実装にコスト（時間・人・予算）が掛かり過ぎる・不足していると挙げられております。よって情報セキュリティとリスクマネジメント活動をシステム開発ライフサイクルに組み入れてください。

つまり、ゼロトラスト移行にあたっては道に迷わないように、情報セキュリティプランニング（セキュリティリスクの可視化、対策立案、ロードマップ作成）が必要です。また、保護に必要なソリューション（セキュリティ製品やサービス）を導入することになるため、手戻りを防ぐためにも実装経験が豊富なSIベンダーからアドバイスをもらうことをお勧めいたします。

今回は4番目の「リソースへのアクセスは、クライアントID、アプリケーション、要求する資産の状態、その他の行動属性や環境属性を含めた動的ポリシーによって決定する」について解説しました。次回は5番目の「企業は、全ての資産の整合性とセキュリティ動作を監視し、測定する」について、ラックの考えるゼロトラストをお伝えいたします。