現代のセキュリティ要件に対応するため、アクセス制御技術は継続的に進化しています。従來の役割ベースアクセス制御（RBAC）は、ユーザーと役割の関係性を管理するシンプルなモデルでしたが、複雑な業務環境では柔軟性に限界がありました。一方、屬性ベースアクセス制御（ABAC）は、ユーザーの屬性やコンテキスト情報を活用した動的制御を可能にしますが、標準化や実裝の複雑さが課題です。本記事では、RBACとABACの統合戦略を解説し、Apache Fortressを用いた実踐的な実裝方法を紹介します。
RBACは、ユーザー、役割、権限、セッションの4要素を基盤に構築されます（RBAC0）。高階役割（RBAC1）は役割の管理を簡略化しますが、必須ではありません。分離職責（RBAC2）は、役割の組み合わせを制限する靜的または動的な制約を提供します。行政API、審査API、実行時APIを通じて認証、権限付與、ポリシー管理が実現されます。
コンテキスト（context）を導入する際、役割數が指數関數的に増加します。例えば、各クライアントごとに役割を追加する必要がある場合、金融機関などでは數萬の役割が発生し、システムの複雑さと保守コストが増大します。
ABACは、屬性（attribute）を基盤とし、ユーザーのID、時間、場所、デバイスなどの情報が屬性として利用可能です。動的権限付與により、細粒度の制御が可能になります。例えば、特定の時間帯に特定の店舗のカウンター擔當者だけが操作を許可されるといったケースです。事前に役割を定義する必要がなく、柔軟性が高いため、役割爆発（role explosion）の問題を迴避できます。
屬性のソースとデータモデルを明確に定義する必要があります。また、標準化が進んでいないため、実裝の差異が生じやすく、再利用性が低下します。
FortressはRBAC 359規範に基づいて設計され、役割の活性化と屬性制約をサポートします。REST API、Webインターフェース、コアAPIを提供し、Webアプリケーションやバックエンドシステムに適用可能です。役割活性化メカニズムにより、特定のコンテキスト（例：特定の店舗）で役割を有効化できます。
NIST Insight 494規範に基づき、RBACとABACの長所を統合します。役割を有効化する際、屬性制約を導入し、役割爆発問題を迴避しつつ、RBACの使いやすさを維持します。例：ユーザーが「カウンター擔當者」役割を有効化する際、自動的に店舗番號屬性を追加し、操作範囲を制限します。
teller AND store=314）をサポートし、ポリシーランゲージで條件を定義。3ページのアプリケーションと3つのクライアントを組み合わせる場合、ページ-クライアントの組み合わせごとに獨立した役割を定義する必要があります（合計9つの役割）。ユーザーが役割を有効化しないと、対応するページにアクセスできません。
ユーザーが「カウンター擔當者」役割を有効化する際、自動的に店舗屬性を追加し、個別の店舗ごとに役割を定義する必要がありません。屬性條件により、操作範囲を制限（例：アカウント456に対するクエリのみを許可）。
ABACは明確な規範が求められ、実裝の一貫性を高める必要があります。屬性ベースのポリシーランゲージとデータモデルの標準化が鍵です。
RBACとABACの橋渡しとして、屬性制約によりRBACの拡張性問題を解決します。今後は、デバイスタイプや地理的位置などの追加コンテキスト屬性をサポートして、柔軟性を向上させることが期待されます。
ポリシーの保存とクエリに使用される軽量ディレクトリアクセスプロトコル（LDAP）。Apache Directory Studioが利用可能です。ユーザー條目には役割指派と屬性制約情報が含まれます。
RoleConstraintクラスを導入し、役割活性化時に屬性條件を設定。セッションが実行時において屬性條件に基づき役割を有効化します。
役割と屬性を分離し、役割爆発問題を迴避。屬性制約により柔軟な権限管理を実現。
現時點では実裝されていないが、屬性制約を追加することで実現可能。
ABACは柔軟な屬性制御を提供するが、実裝複雑度が高い。RBACはシンプルだが、コンテキスト制約が不足。Apache Fortressは両者の長所を統合した中間解。
Ansible Playbookによるシステム設定を提供。すべての例と設定はGitLabで公開。
屬性制約を活用したRBACの統合により、より細かいアクセス制御を実現し、役割爆発問題を迴避。
動的コンテキスト判斷が必要なシステム（例：金融機関、企業リソース管理）に適しています。
屬性制約メカニズムの継続的な最適化と、権限実行段階での屬性応用の実現が期待されます。