IT用語集 2024/05/30

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

コラム

ABACとは

ABAC（Attribute-Based Access Control：属性ベースのアクセス制御）とは、ユーザーや端末、リソース（データ／アプリ）、そして状況（時間・場所・リスク）などの属性を組み合わせて、アクセス可否を判断する仕組みです。役職や所属部署といった人物属性に限らず、端末の管理状態、接続元ネットワーク、アクセス時刻、要求される操作（閲覧／編集／ダウンロード）なども「属性」として扱えます。

ABACの強みは、単一の条件ではなく複数の属性を同時に評価し、「この条件なら許可／それ以外は拒否」を細かく定義できる点にあります。クラウド利用、外部委託、リモートワーク、SaaS活用が当たり前になった環境では、「社内だから安全」「部署だから許可」といった単純化が通りにくくなりました。ABACは、こうした環境変化に合わせて、より現実的なアクセス制御を実装するための考え方として注目されています。

ABACで扱う「属性」の例

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

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

情報セキュリティが守るべき対象は、機密性・完全性・可用性（CIA）です。ABACは、アクセス要求のたびに条件を評価し、必要最小限の許可を与えることで、不正アクセスや情報漏えいの起点を減らす役割を担います。

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

RBACとABACの違い

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

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

ABACの重要性

クラウド、SaaS、モバイル、外部協力会社の活用が進むほど、「誰が（ユーザー）」「何を（データ）」「どこから・いつ（環境）」の組み合わせは増えます。ABACは、この複雑さを「属性とルール」に落として扱うための枠組みです。

また、ABACはアクセスの判断根拠を明確化しやすいという利点もあります。許可・拒否の理由を、属性条件（例：端末が未管理、MFA未実施、機密データへの一括操作）として説明できるため、監査や説明責任の観点でも整理しやすくなります。

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

ABACのメリット

細かな制御ができる：ロールだけでは表現しにくい「状況」を条件に含められる
動的に判断できる：アクセスのたびに属性を評価し、リスクに応じて可否を変えられる
最小権限に寄せやすい：データ分類や操作種別まで含めて許可範囲を絞り込める
クラウド／ゼロトラストと相性がよい：境界ではなく「都度検証」を前提に設計できる

ABACのデメリット

設計が複雑になりやすい：属性とルールの整理が不十分だと例外が増える
属性データの品質に依存する：部署情報の古さ、端末管理状態の誤りが誤判断につながる
誤設定のリスク：条件の抜け漏れで過剰許可（または過剰拒否）を招きやすい
運用・監査の負荷：ルールの変更管理、影響範囲の確認、テストが欠かせない

メリットとデメリットのバランスをとるために

ABACを成功させるコツは、「いきなり完璧」を狙わないことです。まずは守るべき重要データと危険な操作を優先し、属性とルールを最小から始めると破綻しにくくなります。

属性を増やしすぎない：最初は「部署・データ分類・端末状態・MFA・接続元」など少数で十分
否認（拒否）ルールを先に決める：「未管理端末は機密にアクセス不可」など守りを明確化する
例外の受付窓口を決める：例外を“ルール化”せず、期限付きの申請で扱う
影響範囲をテストする：変更時に「誰が困るか」を事前に見える化する

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

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

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

ABACによるゼロトラストセキュリティ

ゼロトラストセキュリティとは

ゼロトラストは「何も信頼せず、常に検証する」という考え方です。ネットワーク境界を越えたから安全、社内IPだから安全といった前提を置かず、アクセス要求ごとに妥当性を確認します。

ABACがもたらすセキュリティ

ABACは、ゼロトラストの「都度検証」を、具体的な判断ルールに落とし込むための手段になり得ます。たとえば、ユーザー属性（部署）、端末属性（管理状態）、環境属性（接続元・時刻）、リソース属性（機密度）を組み合わせ、許可を最小化します。

つまり、ABACは「誰でも、どこでも」ではなく、「この条件なら、この操作だけ」へ寄せるための実装方針として機能します。

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

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

ABACとゼロトラストの関係性

ゼロトラストは思想であり、ABACは制御モデルの一つです。両者を組み合わせることで、都度検証の判断材料（属性）と、判断の仕組み（ルール）を具体化できます。逆に、属性が不十分だったり更新が止まったりすると、都度検証が形骸化しやすいため、属性データの整備が重要になります。

ABACの導入と実装

必要な準備と考慮点

ABAC導入では、まず「属性が取れるか」「正しいか」「更新されるか」を確認します。属性が存在しない、あるいは更新が遅い状態でABACを導入すると、ルールがどれだけ正しくても判断が崩れます。

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

ABACの導入プロセス

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

ABAC実装のためのヒント

実装面では「判断する場所」を意識すると整理しやすくなります。一般に、アクセス要求を受けるポイント（PEP：Policy Enforcement Point）と、可否を判断するポイント（PDP：Policy Decision Point）を分けて考えます。これにより、ルール変更の影響を局所化しやすくなります。

また、ポリシー記述言語や仕組みとしてはXACMLなどが知られていますが、重要なのは形式ではなく、属性データの信頼性と運用の回る設計です。