08 アクセス制御

□未翻訳

□翻訳中

□翻訳完了（中垣健志）

■レビュー(細田謙二)

アクセス制御

Auth

Access Control

RBAC

DAC

MAC

web2pyには、パワフルでカスタマイズ可能なロールベースのアクセス制御メカニズム（RBAC）が含まれています。

web2py includes a powerful and customizable Role Based Access Control mechanism (RBAC).

Wikipediaでの定義を以下に示します：

Here is a definition from Wikipedia:

「ロールベースアクセス制御（英: Role-based access control, RBAC）は、権限のあるユーザーに対してシステムアクセスを制限する手法の一種。強制アクセス制御 (MAC) や任意アクセス制御 (DAC) に対するより新しい代替手法である。RBACはロールベースのセキュリティとして参照されることもある。

"Role-Based Access Control (RBAC) is an approach to restricting system access to authorized users. It is a newer alternative approach to mandatory access control (MAC) and discretionary access control (DAC). RBAC is sometimes referred to as role-based security.

RBAC は、政策的に中立で、柔軟にアクセス制御できる技術であり、DACやMACもシミュレート可能である。逆にMACは、ロールの構造が半順序ロール階層(Partially ordered role Hierarchy)ではなく、ツリーに制限されている場合に限り、RBACをシミュレートできる。

RBAC is a policy neutral and flexible access control technology sufficiently powerful to simulate DAC and MAC. Conversely, MAC can simulate RBAC if the role graph is restricted to a tree rather than a partially ordered set.

RBAC が開発されるまで、アクセス制御のモデルとして知られていたのは MAC と DAC しかなかった。従って、モデルがMACでないなら DAC を、DAC でないならMAC であると考えられていた。90年代後半の研究では、RBAC はそのどちらにも分類されていない。

Prior to the development of RBAC, MAC and DAC were considered to be the only known models for access control: if a model was not MAC, it was considered to be a DAC model, and vice versa. Research in the late 1990s demonstrated that RBAC falls in neither category.

組織において、ロール（役割）は仕事上の機能のために作られる。ある操作を実行する許可（パーミッション）は、特定のロールに対して割り当てられる。従業員(またはシステムユーザー)には特定のロールが割り当てられ、そのロールの割り当てを通して特定のシステム機能を実行するパーミッションが与えられる。コンテキストベースアクセス制御 (CBAC) とは異なり、RBAC はメッセージのコンテキスト（コネクションがどこから起動されているかなど）を考慮しない。

Within an organization, roles are created for various job functions. The permissions to perform certain operations are assigned to specific roles. Members of staff (or other system users) are assigned particular roles, and through those role assignments acquire the permissions to perform particular system functions. Unlike context-based access control (CBAC), RBAC does not look at the message context (such as a connection's source).

ユーザーに対して直接パーミッションが与えられるわけではなく、ロールを通して与えられるため、各人のアクセス権の管理はユーザーへのロールの適切な割り当てに単純化される。つまり、これによりユーザーの追加やユーザーの部門の異動などの共通の操作が単純化される。

Since users are not assigned permissions directly, but only acquire them through their role (or roles), management of individual user rights becomes a matter of simply assigning appropriate roles to the user; this simplifies common operations, such as adding a user, or changing a user's department.

RBAC は従来の任意アクセス制御システムで用いられているアクセス制御リスト (ACL) とも異なる。ACL は低レベルのデータオブジェクトに対してパーミッションを与えるが、RBACｈ組織において意味のある特定の操作に対してパーミッションを与える。例えば、一つのアクセス制御リストは特定のシステムファイルへの書き込みを許可/拒否するために用いられるが、そのファイルがどのように変更できるかは規定しない。」

RBAC differs from access control lists (ACLs) used in traditional discretionary access control systems in that it assigns permissions to specific operations with meaning in the organization, rather than to low level data objects. For example, an access control list could be used to grant or deny write access to a particular system file, but it would not dictate how that file could be changed."

web2pyには、RBACを実装したAuthクラスがあります。

The web2py class that implements RBAC is called Auth.

Authは下記のテーブルが必要です（そして定義を行います）。

    • auth_user ユーザーの名前、メールアドレス、パスワード、ステータス（登録、保留、許可、禁止）が保存される

    • auth_group 多対多の構造においてユーザーに対するグループまたはロールが保存される。デフォルトでは各ユーザーは自分自身のグループに属している。しかし、１人のユーザーを複数のグループに所属させることも、各グループに複数のユーザーを含めることもできる。グループは、ロールと説明文で識別される

    • auth_membership 多対多の構造においてユーザーとグループを結ぶ

    • auth_permission グループとパーミッションを結ぶ。パーミッションは名前（テーブルとレコードが含まれることもある）で識別される。例えば、特定のグループのメンバーは、特定のテーブルの特定のレコードの"更新"のパーミッションが与えられる

    • auth_event これ以外の他のテーブルに対する変更や、RBACにより制御されたオブジェクトへのCRUDを介して成立したアクセスを記録する

Auth needs (and defines) the following tables:

  • auth_user stores users' name, email address, password, and status (registration pending, accepted, blocked)

  • auth_group stores groups or roles for users in a many-to-many structure. By default, each user is in its own group, but a user can be in multiple groups, and each group can contain multiple users. A group is identified by a role and a description.

  • auth_membership links users and groups in a many-to-many structure.

  • auth_permission links groups and permissions. A permission is identified by a name and, optionally, a table and a record. For example, members of a certain group can have "update" permissions on a specific record of a specific table.

  • auth_event logs changes in the other tables and successful access via CRUD to objects controlled by the RBAC.

原則として、ロールの名前とパーミッションの名前に制限はありません。つまり、開発者は組織内のロールやパーミッションに合わせてそれらを作成することができます。一度これらのテーブルが作成されると、web2pyは、ユーザーがログインしているかどうか、グループに属しているかどうか、および／または必要なパーミッションを持つグループの一つに属しているかどうかを確認するAPIを提供します。

In principle, there is no restriction on the names of the roles and the names of the permissions; the developer can create them to fix the roles and permissions in the organization. Once they have been created, web2py provides an API to check if a user is logged in, if a user is a member of a given group, and/or if the user is a member of any group that has a given required permission.

web2pyは、ログイン、メンバシップ、パーミッションに基づいて任意の関数へのアクセスを制限するデコレータも提供しています。

web2py also provides decorators to restrict access to any function based on login, membership and permissions.

web2pyはまた、いくつかの特別なパーミッション、すなわち、CRUDメソッド（削除、読み込み、更新、作成）に対応した名前を持つパーミッションに対応しており、デコレータを使用しなくても自動的にそのパーミッションを強制することができます。

web2py also understands some specific permissions, i.e., those that have a name that correspond to the CRUD methods (create, read, update, delete) and can enforce them automatically without the need to use decorators.

この章では、RBACのそれぞれの構成要素を一つ一つ解説していきます。

In this chapter, we are going to discuss different parts of RBAC one by one.