システムで重要な機能の一つに

認可

があります。

認可とは

サービスにアクセスが可能な利用者や端末、場所等に制限をかけて、管理者の許可を得た利用者のみがサービスを利用できるようにする機能

のことです。

具体的には

太郎は会議の議事録を閲覧できるが
次郎は会議の議事録を閲覧できない

といったようなことです。

このような認可の機能が必要な場合、スタートアップなどで経験の浅い若いエンジニアが中心の現場だと

users_files

などというテーブルを作成し、

ユーザーIDとファイルIDを紐付け

users_filesテーブルにuser_idとfile_idがあるユーザー(従業員)は議事録の閲覧が可能

といった

場当たり的な設計をする傾向があります。

上記のような設計をしてしまうと

アプリケーションが成長して、サービスをスケールさせようと思った時に詰みます。

なぜなら、アプリケーションは成長するにつれて

• 機能

• ユーザー数

• 料金体系

などがどんどん増えていくからです。

なので、上記のような場当たり的な発想で設計を進めていくと、データの管理が煩雑になって運用にも支障をきたし、アプリケーションの速度、開発速度、開発コストも一気に肥大化していきます。

このような事態を防ぐためには、ノウハウが体系化された認可手法で設計をする必要があります。

よく使われる認可の手法には

• ACL

• RBAC

• ABAC

があります。

一般的なシステムではACLかRBACが利用されていることが多いですが、大規模で複雑なアプリケーションの認可管理では

ABAC

を利用するケースがあります。

しかし、ABACは資料や設計ノウハウがほとんどない状態です。

なので

アプリケーション開発時に、認可手法の候補にあがることすらほとんどありません

これは非常にもったいないことです。

アプリケーションの認可の仕様がABACで解決できるのであれば、ABACの採用も考慮にいれるべきでしょう。

なので、今回の記事では

• ABACとは

• ABACの利点

• ABACの欠点

• まとめ

について記載します。

ABACとは

ABACは

Attribute-Based Access Control（属性ベースのアクセス制御）の略です。

多くのシステムで採用されているRBACはロール（役割）で認可を管理しますが、ABACでは属性（特性）を評価してアクセスを決定する認可モデルです。

つまり

ユーザー、リソースの属性、環境に応じた権限を管理します。

具体的には

• ユーザーの職位、典型的なタスク、または階級によって、実行できる機能を決定する

• ファイルの種類、その作成者、ドキュメントの機密性によってアクセスの可否を決定する

• ユーザーがファイルにアクセスする場所、時間帯、または日付などの環境によってアクセスを決定する

といったような場合にABACを使います。

ABACの利点

ABACの利点は

• 柔軟性が高い

• 新規ユーザーの権限設定が楽

であることです。

ABACは属性と条件を組み合わせて柔軟な規定(ポリシー)を作成できます。

例えば

「役職」が「課長」のユーザーは、「自分の所属するグループ」のフォルダに置かれたファイルを閲覧できる

ような規定(ポリシー)を作ることが可能です。

さらに柔軟性を持たせて

「役職」が「課長」のユーザーは、「自分の所属するグループ」のフォルダに置かれたファイルを「ファイルが作成されてから1ヶ月」閲覧できる

のようにもできます。

このようにABACでは

さまざまな属性の組み合わせを使用して、状況に応じて限定的または広範なアクセス条件を作成できます。

また、管理者が属性に変更があったユーザー対して権限を付加する労力も軽減されます。

例えば

「役職」が「課長」のユーザーは、「自分の所属するグループ」のフォルダに置かれたファイルを「ファイルが作成されてから1ヶ月」閲覧できる

という規約(ポリシー)が設定済みであれば、新しく「役職」が「課長」に変わったユーザーには、同様の権限が与えられることになります。

ABAC以外の認可方法だと、役職が変更になったユーザーの既存の権限を削除して、新しい権限を付加する

という作業をする必要があります。

ABACではユーザーの属性を設定することで権限が付加されるので、新しい従業員や外部パートナーの権限付与に迅速に対応できます。

ただし、これは

属性が変わると権限も変わってしまう

ということも意味します。

なので、ABACを採用する時は、

自分のアプリケーションがABACの仕様で運用可能かどうか

を考慮する必要があります。

ABACの欠点

ABACの欠点は

実装が複雑

であることです。

ABACは非常に柔軟性の高い認可方法ですが

他の認可方法より、実装と運用コストが段違いに高いです。

なので導入する場合は、認可処理専用のチームを構築する必要があるでしょう。

当然、金銭面でもコストがかかります。

実際、サービスにABACを導入している企業は

• Amazon

• Microsoft

など、資金と人材に余裕のある企業です。

また、XACMLというABACアクセス制御言語がありますが、この仕様を理解してABACを設計、実装するのは、かなりシステム開発に精通した人材が必要になってきます。

XACMLはそのままだと実用性に乏しいので、必要な部分の考え方だけを抽象化し、自分のサービスに合わせて適用する必要があります。

このように、ABACの導入には想像以上にコストがかかります。

自分のサービスがABACのコストを吸収できるかを考えてから、導入するようにしてください。

まとめ

今回の記事では

ABAC

について説明しました。

まとめると

• 認可の設計は、体系化された認可の仕組みを利用するべき

• 複雑なアプリケーションの管理には柔軟性の高いABACが合う

• ABACの導入コストは高いので、本当に必要かどうかを導入前に判断する必要がある

ということです。

この記事があなたの開発タスクに役立てば幸いです。