RBAC（ロールベースのアクセス制御） とは

2022年のUberのハッキング（攻撃者が同社の内部ネットワークに侵入してツールにアクセスした）の後、業界では1つの大きな気づきがありました。つまり、セキュリティ侵害は対応するものではなく、防御するものであるということです。この流れで組織が進むことができる大きな一歩は、ソフトウェアをアクセス制御ポリシーの下に置いて、アクセスとアクションを継続的に監査することです。

市場には現在、RBAC（ロールベースのアクセス制御）など、これを行うのに役立つ複数のアクセス制御メカニズムがあります。この記事では、操作性とセキュリティの観点から見たRBACの利点、スキーマでRBACを実装する方法、およびコンプライアンスにどのように役立つかについて説明します。また、他のアクセス制御メカニズムもいくつか取り上げ、それらの機能について理解します。

RBACの基本

RBAC（ロールベースのアクセス制御）は、ユーザーに割り当てたロールに定義されている権限に基づいて、特定のリソースへのアクセスをユーザーに許可するメカニズムです。RBACには、次の3つの主要なコンポーネントがあります。

• ロール
• Permissions
• ユーザー

各ロールには、特定のリソースにアクセスするための特定の権限が付与され、ユーザーには特定のロールが割り当てられます。したがって、ロールが付与されると、ユーザーはそのロールにアクセスが許可されているすべてのものを表示および使用できるようになります。

RBACスキーマ

組織は、スキーマを利用してRBACを実装します。このSQLベースの擬似スキーマでは、ロール、ユーザー、および権限をマップする方法を見ていきます。データベーススキーマには、テーブルとその関係が含まれています。RBACスキーマを実装するために必要な主なテーブルは5つあります。

• Users：すべてのユーザーとその基本的な詳細を追跡します。
• Permissions：システムで定義されている権限を示します。権限は、リソースごとおよびそのリソースに対して許可されるアクションごとに、さらに分割できます。
• Roles：システムで定義されているロール。
• User_Roles：ユーザーごとのロールのマッピングで、ユーザーが持つすべてのロールが表示されます。多対多の関係。
• Role_Permissions：ロールと権限の関連付けを示します。

固有の要件が少しあるため、ユーザーにいくつかの権限を直接割り当てることが必要になる場合があります。これを行うと歯止めがなくなり、1人のユーザーに直接割り当てられる権限をチームが大量に作成してしまう可能性があるため、まったく推奨されません。特定のユースケースでこれに対応する場合は、User_Permissionsという別のテーブルを作成して、ユーザーを権限に関連付けることができます。

これら5つまたは6つのテーブルを使用すると、承認確認を実行する機能を作成できます。以下は、権限を確認するための擬似的な機能です。

function check_permissions(user, permissions):
user_role = get_role(user)
user_permissions = user_role.get_permissions()
if permissions in user_permissions:
Return “allowed”
else:
Return “Not allowed”

ここでの権限の定義は、実装ごとに異なる場合があります。ある実装では、ユーザーがプロファイルを編集できることを意味する「profile-edit」のようなオブジェクト権限になる可能性があります。

また、ロール階層を実装することもできます。つまり、1つのロールがさまざまなロールを持つことができ、権限はこれらのロールを基に解決されます。このような場合、実装は少し面倒になる可能性があります。is_parent_roleとchild_rolesの2つのフィールド名が必要です。または、このマッピングのために別のテーブルを作成することもできます。

RBAC（ロールベースのアクセス制御）の重要性

RBAC（ロールベースのアクセス制御）は、運用タスクを実行するための権限をユーザーに付与するプロセスを標準化します。RBACの利点は次のとおりです。

• 冗長な作業の軽減：ロールは定義されているので、ユーザーにロールを割り当てるだけで、適切な権限が付与されます。そうでなければ、ユーザーごとに各権限を手動で追加しなければなりません。
• セキュリティの向上：これらのロールは一元的なチームが定義するため、RBACはエラーが発生しにくく、管理が容易になります。また、ロールが定義されていると、誤って不適切な権限が付与される可能性が低くなります。
• 監査が簡単：ロールが事前定義されているということは、ロールの定義と割り当ての変更が少ないことを意味し、ユーザーごとに権限を割り当てる場合と比較して監査が簡単になります。
• コンプライアンス要件：アクセス制御を実装すると、コンプライアンス規制を遵守するのに役立ちます。これは常にセキュリティの重要な側面です。

RBACのベストプラクティス

1つの不適切な実装が、最も安全なシステムを妨げる可能性があります。したがって、ベストプラクティスに従うことが何よりも重要です。

各ロールの詳細な情報と、それが実行すべき内容を記述します。ロールテーブルにメモ列を含めて、各ロールの使用方法と作成理由を定義します。やみくもにロールを作成しないようにします。代わりに、すでに存在する最適なロールを見つけて、それらを割り当ててみます。

明示的なユーザーレベルの権限は避けます。混乱を招き、不適切な権限が付与される可能性があるためです。

すべてのテーブルにcreated_by、updated_by、updated_at、created_atの列があることを確認します。また、権限が不適切に割り当てられていないかや、昇格された不必要な権限が誰かに付与されていないかを特定するために、テーブルの各変更は一元化された監査システムに出力する必要があります。

誰がロールを変更できるのかを、誰でも制御できるようにしてはなりません。これは重要な操作であり、すべての変更は、十分に監査された承認ベースのパイプラインを通過する必要があります。

これらとは別に、アクセス制御を管理するチームは、ロールの権限を作成する方法についてのガイドラインを公開する必要があります。

その他のアクセス制御メカニズム

今日では、複数のアクセス制御メカニズムが使用されています。主要なもののいくつかを以下で取り上げます。

属性ベースのアクセス制御

このアクセス制御メカニズムでは、リソースの属性に基づいてリソースに権限が付与されます。この主な例の1つがAWSで、タグを使用してリソースへのアクセスを提供できます。

長所：これは非常に柔軟な方法です。ユーザーが権限を受け取るための属性を簡単に変更できます。

短所：属性が別のエンティティに関連付けられている場合、意図しない権限が伝播される可能性があります。また、各リソースを属性に関連付ける必要があり、チームがそれらの属性を定義して計画する必要があるため、実装に時間がかかります。

ユーザーレベルのアクセス制御

このメカニズムでは、ユーザーに直接割り当てられた権限に基づいて、ユーザーにリソースへのアクセスが許可されます。

長所：最初は単純に見え、実装するのが最も簡単なメカニズムです。

短所：ユーザーや権限が増えると、非常に複雑になる可能性があるため、管理が困難です。

ポリシーベースのアクセス制御

ここでは、ビジネスレベルでユーザーに定義されているポリシーに基づいて、ユーザーにアクセス権が付与されます。このポリシーは、主体、対象、アクション、およびコンテキストを評価します。主体は、エンジニアリングなどの部門にすることができ、対象は、SonarQubeのようなツールにすることができます。アクションは、実行しようとしているアクティビティ（レポートの表示など）にすることができ、コンテキストは、ステージングや本番などの特定の環境です。

長所：人間が判読できるポリシーは、より理にかなっており、コンテキストレベルで制御できます。

短所：その実行にさまざまな業種とそのツールが関与する可能性があるため、実装が複雑です。

まとめ

アクセス制御を実装する方法はたくさんあります。非常に一般的な方法は、RBACとABACを組み合わせることです。AWSは、これら2つをより良く組み合わせたように見えるものを実装しています。

制御メカニズムを選択するだけでなく、あらゆるイベントが監査され、誤った権限が作成された場合に備えてアラート機能が用意されていることを、確認する必要があります。

複数の障害に直面するため、これらの要件をすべてスムーズに解決することは、非常に困難です。例えば、使用する一元化されたツールは、多数の内部ツールと統合する必要があります。一部のツールは制限されており、一部のプロトコルしかサポートしていない場合があります。

問題は別にして、システムが危険にさらされるシナリオにおいて、アクセス制御は自信を与えてくれるため、すべてのシステムで実装する必要があります。