3. ABACとゼロトラストアーキテクチャ適用方針

3.1. ゼロトラストにABACを実装する意義

リスクが比較的変わりやすい業務環境を想定する「ゼロトラストアーキテクチャ適用方針」の各適用方針を実現するにあたり、ABACは次のようなメリットを提供する。

3.1.1 「リソースを識別し、特定できる状態にする」

ゼロトラストアーキテクチャが対象とするリソースの対象はユーザーだけでなく、デバイス、アプリケーション（サービス）も含まれる。つまり管理すべきリソースの量は膨大であることが予想される。そのため、識別や特定作業の効率化が求められる。

DACやMACでは、事前にリソースの識別子を把握しなければ特定できない。RBACはロールから絞り込みができるものの、運用が長くなるにつれ様々な値がつくことから、絞り込みもより複雑になる。ABACであれば属性とその値（情報）を組み合わせて絞り込みができるので、識別と特定作業を効率化できる。

3.1.2 「主体の身元確認・当人認証を実施する」

フィッシング攻撃や不正送金など、その攻撃手法を更新し続ける高い脅威を考慮しなければならない環境において、主体の身元確認・当人認証は重要な処理である。ABACはその処理の結果を関連する付加情報やメタデータを属性情報に取り込むことで、より強固なアクセス制御を実現できる。

身元確認は従業員と称する個人が実在するか確認する処理である。この際、法規制や標準化された手続きに則ることが、業務処理上、重要になることがある。ABACでは、その手続きやあるいはエビデンス元を属性情報としてとりこむことで、実際の処理におけるアクセス制御に身元確認手続きを統合できる。

また、当人認証においても、認証方法を強固なものに限定すべき要件があることもある。昨今のフィッシング攻撃では単純な二要素認証で十分でない事例も少なくないことから、ハードウェアキーを使った認証を適用する要件も考えられる。そういった認証コンテクストもABACでは付加的な情報として活用する[^2]。

3.1.3 「ネットワークを保護する」

業務処理の安全性を確保する場合は、安全な通信経路を使うことが重要であり、そうでない経路であればアクセスは拒否すべきである。ネットワークの通信経路の安全性は、暗号技術を用いて保護されることが多く、それは暗号化する経路を確立する前のやりとりから入手可能な情報である。ABACでは、この情報を環境情報やトランザクションにおける属性情報として扱い、安全な通信経路に限定したアクセス制御を実現可能とする。

境界型ネットワークにおいても、各リソースのネットワーク情報を基にネットワーク制御ルールを作成できることは一般的に知られている。それぞれのリソースが参加するネットワークもまた、属性としてみなせるため、境界型セキュリティのような環境であってもABACを適用できる。

3.1.4 「リソースの状態を確認する」

ゼロトラストアーキテクチャが想定する業務環境は潜在的に脆弱である。そういった環境において、リソースや処理環境が正常な状態であるか、意図通りであるかを確実にしなければ安全性を確保できない。従来とは異なる環境からのサインインなどの正常である確証を持てない処理に対して、システム管理者は適切なリスク対応をとる必要がある。検知と事後的な調査なども１つの手段ではあるが、ABACの特性を活用すれば、過去のサインイン状態やアクセス元のレピュテーションを考慮したアクセス制御により、より防御的な対応が可能になる。

このリソースの正常な状態に対する確証を上げるABAC の特性は、誤検知の低減にも有効である。単一の情報から判定するのではなく、多角的な追加の情報を求めることができるからである。例えば正当性を判断できないサインインについては、追加の認証を要求することで、正当なユーザーによる行為である確証を高められる。あるいは、サインイン元の端末を、資産情報と照合し実在性の確認や、構成情報から最新のパッチ適用状態を確認することで、多層防御をより強化できる。ABACの特性はこのようにトランザクションをとりまく各種リソースの属性情報を統合して判定することで、ゼロトラストアーキテクチャをより安全性が高く効率的なものに実装できる。

3.1.5 「アクセス制御ポリシーで、アクセスを管理する」

ゼロトラストアーキテクチャは特定の業務内で複数のアクセス制御を要する一連の手続きを踏む考え方である（図4）。その中でアクセス制御モデルはそれぞれの手続きにおいて排他的である。例えば、図4におけるリソースA～B間でABACを実装し、リソースY～Z間ではMACを実装することも可能である。既存のアクセス制御モデルをABACに置き換えたとしても、全体のリプレイスにはならないため、影響範囲のコントロールが容易になる。

3.1.6 「リソースとアクセスを観測する」

本項目については、観測に直接的なABAC適用のメリットがあるとは考えられない。管理画面や管理サービスなど、観測に関連するリソースに対するアクセス制御にもABACを適用できる。

3.2. ABAC適用に関連する留意事項

ABACをそのアクセス制御モデルとして採用した際の特有の留意事項が考えられるので、次にあげる。

3.2.1 個人データへの留意

　アクセス制御に関連するシステムを運用するうえで、個人の特定が可能な属性、あるいは個人データそのものが値になる属性がある場合、個人の権利・利益保護のために、個人情報保護法を遵守しなければならない。

3.2.2 運用・保守体制の確保

属性情報、処理に関連する環境情報などABAC特有のコンポーネントが存在する。これらは、アクセス制御機構におけるシステム管理者のみで決定できない。そのため、各リソースを管理する担当者や外部システムの管理者など多岐にわたるステークホルダーを識別・特定し、調整をしなければならない。

3.2.3 属性情報を包有するデータの構造化と標準化

属性および属性情報をアクセス制御に用いる以上、それらを含む情報は機械可読形式なデータ構造を持っていることが望ましい。そのため、属性名や属性情報のデータ型、属性情報として設定可能な値といったものを事前に定め、標準化する必要がある。また、標準化したものを各種ステークホルダーに採用されやすくするため、普及活動や運用支援などの支援活動を行うことが望ましい。

3.2.4 属性情報の送受信にける安全性確保

アクセス制御の入力値として活用する以上、属性の値である属性情報の正確性や信頼性を確保しなければならない。そのためには前述した通り、標準化した構造を運用することに加え、受理したデータを検証する仕組みが必要である。

この際に、不正なエンティティによる改ざん、あるいは不正なエンティティからのなりすましなどの脅威を考慮しなければならない。

また、異なる管理下にあるシステムへのデータ伝送方法についても安全性を確保すべきである。データ構造の標準化に加え、送受信するデータ処理についてポリシーや技術を確立しなければならない。

3.2.5 データ種別や量の考慮

各種リソースの属性や関連する環境情報を活用するため、全体的なデータ量の増加が想定される。そのため、アクセス制御そのものにおける処理速度への影響が考えられるため、適切に容量を見積った設計をしつつ、パフォーマンスの監視などの観測による運用をすべきである。

　又、複数の属性や属性情報を組み合わせることで様々な分析が可能となるが、本来の管理業務外における用途に繋がらないよう管理するべきである。具体例として、運用目的にそぐわない個人の特定などが挙げられる。