IT用語集 2024/05/30

ABACとは？わかりやすく10分で解説

コラム

ABACとは

ABAC（Attribute-Based Access Control：属性ベースのアクセス制御）とは、ユーザー、端末、データ、操作内容、接続時の状況を見て、アクセス可否を決める方式です。部署や役職だけで決めるのではなく、「どの端末から」「いつ」「何をしようとしているか」まで見ます。

クラウド、外部委託、リモートワーク、SaaS利用が広がると、「社内だから許可」「この部署だから許可」だけでは足りない場面が増えます。ABACは、そうした場面で条件ごとに権限を分けたいときに使われます。

ABACは属性を組み合わせてアクセス可否を決める方式です
RBACより細かい条件を扱いやすい一方、設計は複雑になりやすくなります
機密データ、外部利用、在宅勤務が混ざる環境で向いています

ABACで扱う条件の例

主体（ユーザー／端末）の属性：部署、役職、雇用形態、資格、端末の管理状態（MDM管理下／暗号化／OSバージョン）
リソースの属性：データ分類（機密／社外秘）、保管場所、所有者、対象システム
操作：閲覧、更新、削除、ダウンロードなど
環境条件：アクセス時刻、接続元（社内／社外）、国・地域、リスクスコア、多要素認証の有無

情報セキュリティにおけるABACの役割

情報セキュリティでは、機密性・完全性・可用性（CIA）を守る必要があります。ABACは、アクセス要求ごとに条件を見て、必要な範囲だけ許可する方式です。これにより、不正アクセスや情報漏えいにつながる無駄な権限を減らしやすくなります。

たとえば「経理の正社員が、社内ネットワークから、平日9〜18時に、経理システムの支払データを閲覧する」は許可し、「同じ利用者が深夜に海外IPから、未管理端末で、機密データを一括でダウンロードする」は拒否するといった制御ができます。

RBACとABACの違い

RBAC（Role-Based Access Control：役割ベースのアクセス制御）は、「ロール（役割）」を単位に権限を割り当てる方式です。運用が比較的シンプルで、組織図と連動させやすい点がメリットです。

一方、ABACはロールに限らず、複数の属性を組み合わせて判断します。そのため、要件が細かいほどABACが有利になりやすい反面、設計と運用を誤ると「ルールの増殖」「例外だらけのポリシー」になりやすい点には注意が必要です。

ABACが必要になりやすい場面

クラウド、SaaS、モバイル、外部協力会社の活用が進むと、「誰が」「何に」「どこから」「いつアクセスするか」の組み合わせが増えます。こうした環境では、部署や役職だけで決める方式では足りず、条件を組み合わせて判断する必要が出てきます。

ABACの利点は、許可した理由と拒否した理由を条件で説明しやすいことです。たとえば「未管理端末からは機密データを見せない」「多要素認証を済ませた利用者だけに社外からの閲覧を許可する」といった形で、判断の根拠を示せます。

ABACのメリットとデメリット

ABACのメリット

細かな制御ができる：ロールだけでは表しにくい状況を条件に含められる
アクセス要求ごとに判断できる：利用時の条件に応じて許可・拒否を変えられる
最小権限に寄せやすい：データ分類や操作内容まで含めて許可範囲を絞り込める
クラウドやゼロトラストと合わせやすい：境界ではなく都度確認を前提に組み立てられる

ABACのデメリット

設計が複雑になりやすい：属性とルールの整理が不十分だと例外が増える
属性データの品質に左右される：部署情報の古さ、端末状態の誤りが判断ミスにつながる
誤設定のリスクがある：条件の抜け漏れで過剰許可や過剰拒否を招きやすい
運用負荷がかかる：ルール変更、影響確認、テストを続ける必要がある

最初に決めたい進め方

ABACは、最初から細かく作り込みすぎない方が進めやすくなります。先に決めたいのは、どのデータを守るか、どの操作を止めたいかです。対象を絞って始めると、運用で崩れにくくなります。

属性を増やしすぎない：最初は「部署・データ分類・端末状態・多要素認証の有無・接続元」くらいで十分です
拒否条件を先に決める：たとえば「未管理端末は機密データにアクセス不可」のように先に線を引きます
例外の扱いを決める：例外を通常ルールに混ぜず、期限付き申請で処理します
変更前に確認する：適用前に、どの利用者と業務に影響が出るかを見ます

メリット・デメリットから見るABACの適用範囲

ABACは、機密データを扱い、かつ利用条件が変わりやすい領域で効果が出やすい手法です。たとえば、委託先や在宅勤務が混在する業務、SaaSと社内システムが併存する環境、端末が多様な環境などが対象になります。

一方、アクセス条件が単純で、利用者と業務が固定的なシステムでは、RBACのほうが運用負荷を抑えられるケースもあります。要件に対して、最小の複雑さで回る方式を選ぶことが現実的です。

ABACとゼロトラスト

ゼロトラストとは

ゼロトラストは、アクセスを暗黙に信頼せず、要求ごとに確かめる考え方です。ネットワーク境界を越えたから安全、社内IPだから安全といった前提を置かず、アクセス要求ごとに妥当性を見ます。

ABACが果たす役目

ABACは、ゼロトラストで必要になる都度確認を、実際の条件に落とし込むときに使えます。たとえば、ユーザー属性（部署）、端末属性（管理状態）、環境条件（接続元・時刻）、リソース属性（機密度）を組み合わせて、許可する範囲を絞ります。

要するに、ABACは「誰でも、どこでも」ではなく、「この条件なら、この操作だけ」と決めるための方式です。

ゼロトラストを実現するABACの戦略

データ分類を先に決める：機密・社外秘・公開など、守る単位を明確にする
危険な操作を絞る：一括ダウンロード、外部共有、削除などを重点管理する
強い条件を段階適用する：機密データでは多要素認証を必須にする、未管理端末は禁止する、などを順に広げる

ABACだけでゼロトラストが完結するわけではない

ゼロトラストは考え方であり、ABACはアクセス判断の方式の一つです。ABACを使うと、都度検証で使う条件と判断ルールを定義しやすくなります。

ただし、ABACを入れるだけでゼロトラストになるわけではありません。利用者の本人確認、端末状態の確認、ログ監視、継続的な見直しまでそろってはじめて、ゼロトラストの運用として機能します。

ABACの導入と実装

導入前に確認したいこと

ABACを入れる前に、まず「属性を取れるか」「その値が正しいか」「更新が止まらないか」を見ます。属性が不足していたり更新が遅かったりすると、ルールが正しくても判断がずれます。

属性の取得元：人事DB、IdP、MDM、ログ基盤、資産管理、データ分類など
更新の速さ：異動、退職、端末状態、リスク評価がいつ反映されるか
権限の単位：閲覧・編集・共有・ダウンロードをどこまで分けるか

ABACの導入プロセス

対象の絞り込み：機密データや重要システムから始める
属性の定義：最小限の属性セットを決め、取得・更新の仕組みを固める
ポリシー設計：許可条件と拒否条件を整理し、例外は期限付きにする
テストと段階展開：影響範囲を確認し、段階的に適用範囲を広げる
監査と改善：アクセスログと運用実態からルールを継続改善する

実装で押さえたい点

実装では「どこで判断し、どこで止めるか」を分けて考えると整理しやすくなります。一般に、アクセス要求を受ける場所（PEP：Policy Enforcement Point）と、許可・拒否を決める場所（PDP：Policy Decision Point）を分けます。こうしておくと、ルールを変えたときに見直す場所を絞りやすくなります。

XACMLのようなポリシー記述言語はありますが、先に見るべきなのは、属性データが正しく更新されるか、運用で無理が出ないかという点です。