Application Service > ROLE > 概要

ROLEサービスとは？

運営環境にアクセスするユーザーのリソースアクセス制御を体系的に管理できるサービスです。

全体構造

[図1]全体構造

RBAC(Role-based access control)

まず、必要なロールを定義する必要があります。 ロールは他のロールを関連ロールとして指定することができ、その関連ロールに指定された他の関連ロールと条件属性を継承できます。これにより、体系的なロール構造を設計できます。 特定の機能を実行できるロールを定義し、このようなロールを束ねて、特定の職務を実行できるロールに関連関係として構成できます。 ユーザーに小さなスコープの機能を実行できるロールを割り当てることもできますし、より多くの機能を実行できるロールを割り当てることもできます。

ABAC(Attribute-based access control)

認可ポリシーを設計する際、ロールだけでは不十分な場合があります。条件属性に基づいてロールを定義して細かいポリシーを構成できます。 条件属性はID-値形式で構成することができ、ユーザーまたはロールに付与できます。条件属性に付与された値と一致するか、一致しない場合にアクセスを許可するように構成できます。

例) bucket-name属性IDを定義します。この属性は、それぞれのアクセス対象が持つバケット名を定義します。ユーザーに同じ条件属性IDと許可する属性値を付与します。 例えば、bucket-name属性IDにproductという名前の属性値をユーザーに付与した場合、ユーザーが対象にアクセスする時、productと一致する属性値を持つ対象である場合のみアクセスが許可されます。

上の例のように 特定の属性IDを持つ保護されたリソースにアクセスする時、ユーザーに付与した属性値がアクセスしようとする対象の条件属性と一致する場合のみリソースへのアクセスを許可するように構成できます。

リソース

リソースは、保護リソースを定義する単位です。URIベースのhierarchy構造で構成することができ、各リソースには、リソースの識別情報とリソースにアクセスできる 権限(ロール-操作ペア)のリストを指定できます。 リソースベースで認可に関するポリシーを策定する場合に便利です。 ただし、ロールベースでアクセス制御ポリシーを策定する場合、リソース定義は必要ありません。

例) 掲示板の投稿をリソースとして定義して修正と削除は管理者ロールだけを許可し、ゲストロールは閲覧のみ許可するように構成できます。また管理者ロールにゲストのロールを関連ロールとして指定すると閲覧オペレーションを実行できるので、重複適用することなく効率的に管理できます。

ユーザー

ユーザーのアクセス権限は、ユーザーに付与されたロールとそのロールの関連ロールで検査します。 ユーザーにロールを付与する際、そのロールの有効スコープを一緒に指定できます。スコープは、運用環境でロールや条件属性、リソース体系が同じ複数の組織や対象がある場合に便利です。

認可は、ロールベースとリソースベースで提供されます。ロールベースは、ユーザーが指定したロールへのアクセスを許可するかどうかを検査し、ユーザーやロールに付与された属性があれば、属性についても一緒に検査します。 リソースベースは、ユーザーが指定したリソースとオペレーションへのアクセスを許可するかどうかを検査します。同様に、リソースにアクセス可能なロールに属性が付与されている場合、属性についても一緒に検査します。

主な機能

[図2]機能の説明

• RBACとロールに対するABACを提供します。
• ロール間の継承が可能で、多数のロールを体系的に管理できます。
• 特定のロールを未使用にしたり、条件を設定することで、多様で細かなユーザーアクセス制御が可能です。
• Path variableを含むAnt PathベースのREST APIリソースをサポートします。
• ロールベースおよびリソースベースのユーザーアクセス制御機能を提供します。
• REST API及びSDKを提供します。

サービス用語

用語	説明
ユーザー	ロールを持つ主体
ロール	リソースアクセス制御のための最小単位
スコープ	ロールが持つことができる有効スコープ
オペレーション	ユーザーがリソースに対して行うことができる行為
リソース	ロールがアクセスできるすべての対象
条件属性	ロールに追加できる条件属性