オーナーベースのRBAC機能
このガイドでは、同一プラットフォーム内で複数のチームが作業する大規模組織向けに設計された機能である、オーナーベースのRBAC（Owner-Based RBAC）について説明します。これにより、ユーザーがアクセス可能なオーナー（Owner）のリストに基づいて、プラットフォーム内の各要素へのアクセス権限をきめ細かく調整できます。
オーナーベースRBACを適用しないアクセスモデル
オーナーベースRBACを導入する前は、プラットフォームは組織全体を対象としたロールベースアクセス制御を採用しています。
Admin：すべてに対する完全な読み取りおよび書き込みアクセス権に加え、インテグレーションの管理、IAM設定、組織構成などの管理操作権限を持ちます。
User：アセット、スキャン、チケットなど、組織内のすべてのリソースに対する読み取りおよび書き込みアクセス権を持ちます。インテグレーションやIAM設定の変更などの管理操作は実行できません。
Reader：組織内のすべてのリソースに対する読み取り専用アクセス権を持ちます。変更権限を付与せずに可視性を確保する必要があるステークホルダーに最適です。
Attack Surface Auditor：アセットへのアクセス管理にオーナーを既に使用しているレガシーロールです。このロールは非推奨（deprecated）となっており、将来のリリースで削除される予定です。
課題：組織内の全員がすべてのリソースを閲覧できてしまい、チーム間の境界が存在しません。大規模な複数チーム環境では、これによりノイズや混乱が生じ、チーム間の意図しない干渉を引き起こす可能性があります。
オーナーベースRBACは、チーム単位のきめ細かなアクセス制御を追加することでこの課題を解決します。
オーナーベースRBACとは？
オーナーベースRBACは、組織内のチームを表す論理グループである「オーナー（Owner）」と呼ばれる中間アクセスレイヤーを導入します。
フローはシンプルです。オーナーはユーザーに割り当てられます。オーナーはアセット（モバイルアプリ、ドメイン、IPアドレスなど）およびタグを管理・制御します。スキャンはアセットに対して実行されます。スキャン完了後、検出された脆弱性に対してチケットが作成されます。アクセス権は自動的に伝播します。特定のオーナーへのアクセス権が付与されると、そのオーナーに紐づくすべてのアセット、タグ、スキャン、チケットへ自動的にアクセスできるようになります。オーナーが割り当てられていないタグは、組織管理者（Admin）のみに厳格に表示制限されます。手動による複雑な権限管理は一切不要です。本システムは階層構造をサポートしており、オーナーは組織構造を反映した親子関係を持つことができます。これにより、プラットフォームが複雑な権限計算をバックグラウンドで自動処理しながら、自然で管理しやすいアクセスパターンを実現します。
オーナーベースRBACにおけるユーザーロール
オーナーベースRBACを有効化すると、各ロールの機能と権限スコープが変化します。
Admin：変更なし。すべてに対する無制限の完全アクセス権限を持ちます。オーナーによる制限をすべてバイパスします。インテグレーションの管理やIAM設定などの管理操作を実行できます。
User：割り当てられたオーナー内のアセットおよびタグに対する読み取りおよび書き込みアクセス権を持ちます。自チームのオーナーリソースに対してスキャンを開始し、脆弱性を管理し、チケットを操作できます。重要：オーナーが1つも割り当てられていない場合、ユーザーは組織の「すべて」のリソースにアクセスできます。
Reader：割り当てられたオーナー内のアセットおよびタグに対する読み取り専用アクセス権を持ちます。いかなる変更も加えることはできません。重要：オーナーが1つも割り当てられていない場合、リーダーは組織の「すべて」のリソースに対して読み取りアクセス権を持ちます。
Attack Surface Auditor：非推奨のレガシーロールです。現在はUserロールと同様に動作します。将来のリリースで削除される予定のため、代わりにUserロールを使用してください。
重要な差別化点：Adminはオーナーの境界を無視してアクセスできます。UserおよびReaderはオーナーの割り当てを遵守し、オーナーが割り当てられていない場合は完全なアクセス権が付与されます。
アクセス階層 — 基本構造
アクセス権は明確な連鎖を通じて伝播します。
ステップ1：オーナーがユーザーに割り当てられます — これがすべてのアクセス権の基盤となります。
ステップ2：オーナーがアセット（モバイルアプリ、ドメイン、IPアドレス）およびタグを管理・制御します。
ステップ3：スキャンはアセットに対して実行されます。アセットへのアクセス権があれば、そのスキャンにもアクセスできます。
ステップ4：スキャンによってチケットが生成されます。スキャンへのアクセス権があれば、生成されたチケットにもアクセスできます。
例外：スタンドアロンチケット（スキャンを伴わずに手動で作成されたチケット）は、組織全体のすべてのユーザーに表示されます。これにより、重要なお知らせや手動で登録したセキュリティ所見が組織全体に確実に届きます。
この階層構造により、実際のセキュリティワークフローを反映した自動的かつ段階的なアクセス権の継承が実現します。
オーナー階層 — 親子関係
オーナーは階層構造を形成でき、組織構造を反映した親子関係を構築できます。
下方向へのアクセス継承が重要なポイントです。
親オーナーに割り当てられたユーザーは、配下のすべての子オーナーとそのアセットを閲覧できます。複数のチームを統括するマネージャーに最適です。
子オーナーに割り当てられたユーザーは、その子オーナーと自身のアセット「のみ」を閲覧でき、親オーナーや同階層の兄弟オーナーは閲覧できません。これにより、チームメンバーは無関係なデータに煩わされることなく、自身の担当範囲に集中できます。
例：Mobile Teamに割り当てられた場合、Mobileのアセットのみが表示され、親のEngineeringや兄弟のWeb Teamは表示されません。
親のEngineeringに割り当てられた場合、Engineeringに加えてすべての子チーム（Mobile TeamおよびWeb Team）が表示されます。
これは再帰的に機能し、孫オーナーは祖父母オーナーから閲覧可能です。明確なアクセス境界を持った深い組織構造を構築できます。
アクセス伝播の具体例 — チェーンを追跡する
アクセス伝播の実際のフローを追跡してみましょう。
Jane は Mobile Team オーナーに割り当てられています。
Mobile Team は2つのアセット（Banking App と Payment App）を管理しています。Jane は自動的に両方にアクセスできます。
スキャンが実行されます。Banking App に対する Scan #12345、Payment App に対する Scan #12346 です。Jane は自身が所属するオーナーのアセットに対するスキャンであるため、両方のスキャンにアクセスできます。
検出された脆弱性：Banking App でSQLインジェクションとXSS、Payment App で脆弱な暗号化（Weak Crypto）が検出されました。Jane はこれら3つのチケットすべてに自動的にアクセスできます。
1つの割り当て → 7つのリソースへアクセス。チェーンは自動的に機能します：ユーザー → オーナー → アセット → スキャン → チケット。手動によるパーミッション管理は一切不要です。
オーナーベースRBACの有効化
オーナーベースRBACを有効化するには、まず画面左上のメニューボタンをクリックします。
メニュー内の「Settings」を選択します。
続いて「Organization」をクリックします。
下にスクロールして、「Enable Object Level Access Control」のトグルスイッチを見つけます。
トグルがオフの場合、プラットフォームはすべてのユーザーが組織内のすべてのリソースを閲覧できるレガシーモードで動作します。トグルをオンに切り替えると、新しいオーナーベースRBACシステムが有効化され、すべてのクエリがオーナー割り当てによってフィルタリングされるとともに、オーナー割り当てインターフェースが利用可能になります。
本ガイドでは、同一プラットフォーム上で作業する複数のチームを抱える大規模組織向けに設計された強力な機能である、オーナーベースRBACについて解説しました。全員がすべてを閲覧できることによるノイズや混乱を排除し、チーム単位のきめ細かなアクセス制御を実現する方法を確認しました。