ロールと権限

ロールベースのアクセス制御（RBAC）を使うと、カスタムロールを定義し、チームメンバーごとにきめ細かな権限を割り当てられます。Enterpriseプランで利用できます。

RBACを有効にすると、各メンバーの権限は割り当てられたロールによって決まります。ロールがないメンバーもサインインはできますが、何も管理できません。RBACが無効な場合は、すべてのメンバーがデフォルトでフルアクセスになります（Teamを参照）。

権限#

すべてのロールは、次の5つの権限の組み合わせで構成されます。

org:manage_billing と org:delete はOwner専用です。これらを含むロールを割り当てて付与できるのは、現在のOwnerだけです。

ロール#

ロールは次の3種類です。

• Owner — すべての権限を持つシステムロールです。組織を作成したユーザーが最初のOwnerとなり、既存のOwnerは追加のOwnerを任命できます。このロール自体は編集も削除もできず、組織には常に少なくとも1人のOwnerが必要です。
• Full Access — 組織の作成時に org:manage_team、org:manage_settings、engine:access を含む状態で自動作成されます。他のカスタムロールと同様に編集でき、信頼できるチームメンバー向けの安全なデフォルトです。
• Custom roles — 作成した任意のロールです。名前を付けて、権限一覧から必要な権限を自由に組み合わせて選べます。

ロールの割り当て#

Teamページを開き、メンバーを選んでロールを指定します。ロールを外しても、そのユーザーは権限を持たない組織メンバーとして残ります。サインインはしたままですが、どのエンジン、設定、請求にもアクセスできません。

別のメンバーをOwnerに昇格したり、Ownerを降格したりできるのは既存のOwnerだけです。こうした変更には、Owner権限そのものが必要です。

エンジンへのアクセス#

デフォルトでは、ロールに engine:access を含むメンバーは、組織内のすべてのローカライゼーションエンジンを表示できます。

アクセスを絞り込むには、各エンジンのMembersタブから、特定のユーザーを特定のエンジンに追加します。エンジン単位の付与は加算式です。組織レベルの engine:access がある場合は、常にそちらが優先されます。ユーザーを1つのエンジンだけに制限したい場合は、engine:access を含まないロールを割り当てたうえで、そのエンジンに個別に追加してください。

Service API keys も同じモデルに従います。キーにはロール（包括的な権限）、エンジン単位のスコープ、その両方、またはどちらも持たせることができます。権限昇格を防ぐガードは作成時と編集時の両方で適用され、サービスキーに割り当てられるロールは、権限セットが engine:access のみのものに制限されます。

Service API keys#

サービスキーはRBAC専用の仕組みです。Personal keyはすべてのプランで利用でき、作成者のロールを継承します。Service keyはRBACの利用権が有効な場合にのみ使え、独自の権限を持ちます。

• サービスキーの作成には org:manage_team が必要です。これはロールの割り当てを管理するのと同じスコープです。
• ロールを持たないサービスキーも有効です。アクセス権は、そのキーに指定されたエンジンの一覧だけで決まります。
• Enterpriseプランが終了すると、組織内のすべてのサービスキーは無効化され、利用権名を含む型付き403が返されます。これにより運用担当者は、存在しないエンジンスコープの不具合を疑うのではなく、プランを復旧するかPersonal keyに切り替えるべきだと判断できます。

サービスキーのロールとエンジンスコープは、API Keysページから管理できます。

所有権の移譲#

自分が唯一のOwnerで、その役割を退きたい場合は、Teamページの「Transfer ownership」を使います。新しいOwnerと、その後に自分が持つロール（またはロールなし）を選択してください。昇格と自分自身の降格は1つのトランザクションでまとめて確定するため、組織がOwner不在になることはありません。

このフローは、Ownerを退くためのものです。単にOwnerの役割を分担したいだけであれば、通常のロール選択から2人目のユーザーをOwnerに昇格させてください。

次のステップ#