ロールベースアクセス制御（RBAC）でAPI連携のセキュリティを確保する方法

要点

ロールベースのアクセスコントロール (RBAC) は、個々のユーザーではなくロールに権限を割り当てるセキュリティモデルであり、APIチームの管理をスケーラブルかつ監査可能にします。 APIコラボレーションのための適切なRBACシステムは、3段階の権限階層（組織 → チーム → プロジェクト）、きめ細かな制御のためのカスタムロール作成、そしてSSOやSCIMなどのエンタープライズ統合を提供する必要があります。Apidogは、3つのレベルにわたる12の組み込みロールと、エンタープライズチーム向けのカスタムプロジェクトロールを備えた包括的なRBACフレームワークを提供し、誰がAPIアセットを表示、編集、テスト、または管理できるかを正確に制御できます。

ボタン

APIチームにとってRBACが重要な理由

API開発には、エンドポイントを作成する開発者、テストを実行するQAエンジニア、仕様を確認するプロダクトマネージャー、ドキュメントを作成するテクニカルライター、アクセスログを監査するセキュリティチームなど、複数のステークホルダーが関与します。構造化されたアクセスコントロールがなければ、混乱が生じます。

現実世界の問題: ジュニア開発者が誤って本番API仕様を変更してしまった。請負業者が、見るべきではない機密性の高い支払いエンドポイントにアクセスしてしまった。退職した従業員の認証情報が、退職後数ヶ月も有効なままだった。これらは架空のシナリオではなく、適切なRBACなしにAPIを管理する組織では日常的に発生しています。

APIセキュリティレポートによると、APIセキュリティインシデントの61%は、不正アクセスまたは過剰な権限が関係していることが判明しました。根本原因は、チームがAPIアセットに対して誰が何ができるかをきめ細かく制御できていないことにあります。

RBACは以下の方法でこれを解決します:

個人ではなくロールに権限を割り当てる — 誰かが参加または退職した場合、50個の個々の権限ではなく、その人のロール割り当てを更新します。
最小特権アクセスを強制する — 各ロールは最小限必要な権限のみを取得します。
監査証跡を作成する — すべてのアクションはロールにマッピングされ、コンプライアンス報告を簡素化します。
チームの成長をスケーリングする — 各アカウントを設定するのではなく、ロールを割り当てることで100人の新しいチームメンバーを追加できます。

ApidogのRBACシステムは、API開発ワークフローのために特別に設計された3層権限モデルでこれらの課題に対処します。その仕組みを見ていきましょう。

3段階の権限階層

効果的なAPIコラボレーションRBACは、「このプロジェクトにアクセスできる」だけでなく、複数のレベルでの権限を必要とします。Apidogは、実際の組織がどのように作業を構造化しているかを反映する3段階の階層を実装しています。

レベル	範囲	制御するもの
組織	会社全体	請求、SSO、メンバー管理、カスタムロール定義
チーム	部門/事業単位	チームメンバーシップ、プロジェクト作成、チームリソース
プロジェクト	個々のAPI	エンドポイント、テスト、ドキュメント、環境、ブランチ

3つのレベルが重要な理由: 決済、ID、分析の3つのチームを持つフィンテック企業を考えてみましょう。各チームは複数のAPIプロジェクトを管理しています。決済チームの開発者は決済APIにはアクセスできるが、IDまたは分析プロジェクトにはアクセスできないべきです。組織管理者はすべてのチームのSSOを設定する必要があるが、必ずしもすべてのAPIエンドポイントを編集する必要はありません。QAエンジニアはAPI仕様を変更することなく、特定のプロジェクトでテストを実行する必要があるかもしれません。

この階層的なアプローチは、2つの一般的な失敗を防ぎます:

過剰な権限付与: きめ細かな制御が複雑すぎるため、全員に管理者アクセス権を与えること。
権限のギャップ: チームレベルの権限を作成したが、プロジェクトレベルの粒度を忘れてしまうこと。

各レベルのロールと機能を見ていきましょう。

組織レベルのロールと権限

組織のロールは、会社全体の設定（請求、IDプロバイダー統合、メンバー管理、リソースガバナンス）を制御します。これらのロールは、組織全体の下にあるすべてのチームとプロジェクトに影響します。

組み込みの組織ロール

ロール	説明	主な機能
組織オーナー	組織の作成者、最高権限者	組織名の変更/移管/解散、完全な管理者権限
組織管理者	組織の管理	メンバー、チーム、SSO、カスタムロール、組織リソースの管理
組織メンバー	基本的な参加者	チームへの参加、プロジェクトへの参加（チーム/プロジェクトの権限に基づく）
請求管理者	財務管理者のみ	サブスクリプションと請求の管理（独立したロール、他のロールと併用可能）

権限マトリックス: 組織設定

機能	組織オーナー	組織管理者	組織メンバー	請求管理者
組織設定へのアクセス	✅	✅	❌	❌
組織名の変更	✅	✅	❌	❌
組織の所有権の移管	✅	❌	❌	❌
組織の解散	✅	❌	❌	❌

権限マトリックス: チーム管理

機能	組織オーナー	組織管理者	組織メンバー	請求管理者
新しいチームの作成	✅	✅	❌	❌
チームを組織に移管	✅	✅	❌	❌
チームを組織外に移管	✅	✅	❌	❌

権限マトリックス: メンバー管理

機能	組織オーナー	組織管理者	組織メンバー	請求管理者
メンバーの招待	✅	✅	❌	❌
メンバーの組織ロールの変更	✅	✅	❌	❌
メンバーの削除	✅	✅	❌	❌

組織メンバーロールは意図的に制限されています — これは「受動的な受け手」のロールです。メンバーはチームに参加し、チーム/プロジェクトレベルの権限に基づいてプロジェクトに参加できますが、組織設定を管理することはできません。この設計は、誤った組織全体の変更を防ぎつつ、コラボレーションを可能にします。

請求管理者はユニークです: このロールは独立しており、他のロールと併用できます。ユーザーは組織メンバーと請求管理者の両方になることができます。請求管理者は組織設定にアクセスしたり、メンバーを管理したり、SSOを設定したりすることはできません — サブスクリプションと請求のみを扱います。

チームレベルのロールと権限

チームロールは、部門レベルの操作（チームメンバーの管理、プロジェクトの作成、チームリソースの設定）を制御します。チームは通常、事業単位、製品ライン、または機能グループ（例：モバイルチーム、バックエンドチーム、QAチーム）を表します。

組み込みのチームロール

ロール	説明	主な機能
チームオーナー	チーム作成者、チームの完全な制御	チームの移管/解散、すべてのチーム設定の管理
チーム管理者	チームの管理	メンバーの招待、ロールの割り当て、プロジェクトの作成/削除、チームリソースの管理
チームメンバー	チーム参加者	メンバー詳細の表示、プロジェクトへの参加（プロジェクト権限に基づく）
ゲスト	外部コラボレーター	チーム管理アクセスなし、プロジェクトアクセスのみ

権限マトリックス: チーム管理

権限	チームオーナー	チーム管理者	チームメンバー	ゲスト
チームメンバー詳細の表示	✅	✅	✅	❌
チームメンバーの招待	✅	✅	❌	❌
チームメンバーロールの割り当て/削除	✅	✅	❌	❌
プロジェクトロールの表示	✅	✅	❌	❌
プロジェクトロールの追加/編集/削除	✅	✅	❌	❌

権限マトリックス: チーム設定

権限	チームオーナー	チーム管理者	チームメンバー	ゲスト
チーム名の編集	✅	✅	❌	❌
チームの移管	✅	❌	❌	❌
チームの解散	✅	❌	❌	❌

権限マトリックス: プロジェクト操作

権限	チームオーナー	チーム管理者	チームメンバー	ゲスト
新しいプロジェクトの作成	✅	✅	❌	❌
プロジェクトのクローン	✅	✅	❌	❌
プロジェクトの削除/移管	✅	✅	❌	❌
プロジェクト名の編集	✅	✅	❌	❌

ゲストロールは外部コラボレーションにとって強力です。コンサルタント、請負業者、または部門間の協力者は、特定のプロジェクトへのアクセス権を持つゲストとしてチームに参加できます — チーム管理機能や他のチームプロジェクトにはアクセスできません。これにより、外部ユーザーが関連性のないビジネス領域を閲覧するのを防ぎます。

プロジェクトレベルのロールと権限

プロジェクトロールは、APIレベルの操作（エンドポイントの編集、テストの実行、環境の管理、ドキュメントの公開）を制御します。これが日常的なAPI作業が行われる場所です。

組み込みのプロジェクトロール

ロール	説明	ユースケース
管理者	プロジェクトの完全な制御	プロジェクトリード、APIオーナー
編集者	コンテンツの変更	開発者、QAエンジニア
閲覧者	表示と実行のみ	プロダクトマネージャー、ステークホルダー、レビュー担当者
禁止	アクセスなし	制限されたユーザー、機密プロジェクト

権限カテゴリ

プロジェクトの権限は、主要な8つのカテゴリをカバーしています。

ブランチ管理 — スプリントブランチ、マージリクエスト、保護されたブランチ、APIバージョン
エンドポイント管理 — エンドポイント、ケース、スキーマ、コンポーネント、リクエスト、ゴミ箱操作
自動テスト — テストシナリオ、パフォーマンステスト、スケジュールタスク、テストレポート
環境管理 — グローバル変数、パラメータ、環境、Vaultシークレット
ドキュメント共有 — クイック共有、ドキュメントサイト公開
プロジェクト設定 — 基本設定、メンバー管理、機能設定、通知
リクエスト履歴 — ローカルおよび共有リクエスト履歴
インポート/エクスポート — データインポート、スケジュールインポート、エクスポート操作

主要な権限のハイライト

権限	管理者	編集者	閲覧者	禁止
エンドポイントの表示、実行	✅	✅	✅	❌
エンドポイントの追加、削除、変更	✅	✅	❌	❌
機能テストの実行	✅	✅	✅	❌
テストシナリオの追加、削除、変更	✅	✅	❌	❌
環境変数の表示、編集	✅	✅	✅	❌
環境の追加、削除、変更	✅	✅	❌	❌
Vaultシークレットへのアクセス	✅	✅	❌	❌
ドキュメントサイト公開設定	✅	❌	❌	❌
プロジェクトのクローン	✅	❌	❌	❌
プロジェクトメンバーの管理	✅	❌	❌	❌

「禁止」ロールはセキュリティにとって非常に重要です。チームメンバーが特定のプロジェクト（例：機密性の高い決済API）にアクセスすべきでない場合、チームから削除するのではなく、「禁止」を割り当てます。彼らはチームメンバーのままですが、そのプロジェクトには一切アクセスできません。

きめ細かな制御のためのカスタムロール

組み込みロールはほとんどのシナリオをカバーしますが、エンタープライズチームは、標準カテゴリに収まらないきめ細かな権限を必要とすることがよくあります。ApidogのEnterpriseプランは、きめ細かな権限制御を備えたカスタムプロジェクトロールをサポートしています。

カスタムロールが必要な場合

QAエンジニアロール: テストの実行とテストシナリオの変更はできるが、API仕様は編集できない。
テクニカルライターロール: ドキュメントの編集はできるが、エンドポイントや環境は変更できない。
セキュリティ監査人ロール: 閲覧のみのアクセスに加え、Vaultシークレットを表示できるが、何も変更できない。
インターンロール: エンドポイントの表示とリクエストの実行はできるが、何も削除できない。

カスタムプロジェクトロールの作成

チーム → メンバー → ロールと権限または組織 → メンバー → ロールと権限に移動し、+ 追加をクリックしてカスタムロールを作成します。

8つのカテゴリすべてにわたって権限を設定できます。

カテゴリ	きめ細かな制御
ブランチ管理	ブランチの表示、ブランチのマージ、マージリクエストの送信、保護されたブランチの変更
エンドポイント管理	表示/実行、追加/変更/削除、コード生成、ケース/スキーマ/コンポーネント/リクエストの管理
自動テスト	機能テストの実行、パフォーマンステストの実行、シナリオの変更、スケジュールタスクの管理、レポートの削除
環境管理	現在の値の表示/編集、追加/変更/削除、Vaultシークレットの管理
ドキュメント	クイック共有の表示、クイック共有の変更、ドキュメントサイトのプレビュー、公開設定
プロジェクト設定	設定の表示、設定の変更、メンバーの管理、通知の設定、インポート/エクスポートの管理
リクエスト履歴	ローカル履歴の表示、履歴の共有、共有履歴の表示、共有履歴の削除

カスタムロールのベストプラクティス

コピーから始める — 既存のロール（編集者、閲覧者）をコピーして変更し、ゼロから作成するのではなく、既存のロールを参考にします。
「すべての権限」チェックボックスを使用する — モジュールの「すべての権限」にチェックを入れると、そのモジュールに追加される将来の権限も自動的に付与されます。
デプロイ前にテストする — テストプロジェクトを作成し、カスタムロールを割り当て、権限が期待どおりに機能するかを確認します。
カスタムロールを文書化する — ロールの命名規則を作成し、各カスタムロールが何を実行できるかを文書化します。
四半期ごとに見直す — カスタムロールは、チームのニーズにまだ合致していることを確認するために定期的に見直すべきです。

エンタープライズセキュリティ機能

RBACは基盤ですが、エンタープライズAPIプログラムには追加のセキュリティ機能が必要です。Apidogは、RBACと連携して機能するエンタープライズグレードのセキュリティ機能を統合しています。

シングルサインオン (SSO)

SAML 2.0によるSSOは、以下のようなIDプロバイダーを介した集中認証を可能にします。

Microsoft Entra ID (Azure Active Directory)
Okta
Google Workspace
OneLogin
カスタムSAML 2.0プロバイダー

RBACにとってSSOが重要な理由:

ローカルパスワードのリスクを排除 — 脆弱なパスワード、パスワード共有、認証情報の忘れなし
ID管理を一元化 — 人事部がユーザーを1箇所で追加/削除し、変更はApidogに同期されます
多要素認証を強制 — IdPレベルのMFAがApidogアクセスに適用されます
オンボーディングを簡素化 — 新入社員は企業の認証情報でサインインでき、別途アカウントを作成する必要がありません

SCIMプロビジョニング

SCIM (System for Cross-domain Identity Management)は、ユーザープロビジョニングを自動化します。

機能	実行内容
ユーザーの追加	IdPがユーザーを作成すると、自動的にApidog組織に追加されます
ユーザーの削除	IdPがユーザーを削除すると、Apidogからも削除され、アクセスが残存しません
アカウントのリンク	SSOのIDは既存のApidogアカウントに自動的にリンクされます

SCIMの利点:

即時デプロビジョニング — 退職者のアクセス権は数日ではなく数分で失われます
管理者オーバーヘッドの削減 — 手動での招待/削除ワークフローが不要になります
コンプライアンスの遵守 — 監査証跡により、いつアクセスが付与/削除されたかが正確に示されます
エラーの排除 — アカウントの忘れや手動ミスの排除

チームへのグループマッピング

ApidogはSAMLグループマッピングをサポートしており、IdPグループはApidogチームに自動的にマッピングされます。

IdP（例：Azure ADグループ）でグループクレームを設定します。
各IdPグループをApidogチームにマッピングします。
各グループに対してチームロール権限を設定します。

例: Azure ADグループ「API開発者」は、Apidogの「バックエンドチーム」にチームメンバーロールでマッピングされます。Azure ADグループ「API管理者」は、「プラットフォームチーム」にチーム管理者ロールでマッピングされます。

従業員がSSOを介してサインインすると、適切な権限を持つ正しいチームに自動的に参加します — 手動での割り当ては不要です。

Vaultシークレット

Vaultシークレットは、集中管理された認証情報管理を提供します。

機能	セキュリティ上の利点
暗号化されたストレージ	APIキー、パスワード、トークンは環境ファイルではなく、暗号化されて保存されます
参照ベースのアクセス	ユーザーは名前でシークレットを参照し、実際の値を見ることはありません
ロールベースの可視性	管理者と編集者のみがVaultシークレットを追加/変更できます
監査証跡	すべてのシークレットアクセスはコンプライアンスのためにログに記録されます

Vaultシークレット vs. ローカル環境ファイル:

アプローチ	セキュリティリスク
ローカル環境ファイル	プロジェクトにアクセスできる人全員にシークレットが見え、Gitを介して共有される可能性あり
Vaultシークレット	集中管理され、暗号化され、ロールによって制御され、監査可能

ApidogでのRBACの設定方法

一般的なAPIチームのための完全なRBAC構造を設定する手順を見ていきましょう。

ステップ1: チーム構造を定義する

ロールを設定する前に、組織をマッピングします。

組織: あなたの会社
├── チーム: 決済
│   ├── プロジェクト: 決済ゲートウェイAPI
│   ├── プロジェクト: 不正検出API
│   └── プロジェクト: 請求サービスAPI
├── チーム: ID
│   ├── プロジェクト: 認証サービスAPI
│   └── プロジェクト: ユーザー管理API
└── チーム: 分析
    ├── プロジェクト: メトリクスAPI
    └── プロジェクト: レポートAPI

ステップ2: 組織ロールを設定する

組織オーナー（1名）：CEO、CTO、またはプラットフォームリード
組織管理者（2～3名）：エンジニアリングマネージャー、セキュリティリード
組織メンバー（その他全員）：開発者、QA、PM、ライター

ステップ3: チームロールを設定する

各チームについて：

チーム	チームオーナー	チーム管理者	チームメンバー
決済	決済リード	決済マネージャー	開発者5名、QA2名
ID	IDリード	IDマネージャー	開発者3名、QA1名
分析	分析リード	分析マネージャー	開発者2名

ステップ4: プロジェクトロールを設定する

各プロジェクトについて、責任に基づいてロールを割り当てます。

人物	決済ゲートウェイAPI	不正検出API	認証サービスAPI
シニア開発者A	管理者	編集者	禁止
シニア開発者B	編集者	管理者	禁止
ジュニア開発者C	編集者	閲覧者	禁止
QAエンジニア	編集者	編集者	禁止
プロダクトマネージャー	閲覧者	閲覧者	禁止
請負業者	編集者	禁止	禁止

ステップ5: 事前に設定されたロールを持つメンバーを招待する

ユーザーを招待する際に、すぐにロールを設定できます。

チーム招待 — チームロール + デフォルトのプロジェクトロールでチームに招待。
プロジェクト招待 — プロジェクトロールで特定のプロジェクトに招待 + 自動的にメンバーとしてチームに追加。

外部協力者向け: 「その他のプロジェクト = 禁止」でプロジェクトレベルの招待を使用し、招待されたプロジェクトのみに可視性を制限します。

ステップ6: SSOとSCIMを設定する（エンタープライズ向け）

組織設定でSAML SSOをセットアップします。
IdPダッシュボードからSCIMトークンを設定します。
IdPグループをApidogチームにマッピングします。
展開前にパイロットグループでテストします。

APIコラボレーションセキュリティのベストプラクティス

1. 最小特権の原則を適用する

最小限の権限から始め、必要に応じて追加します。

新しいチームメンバー: 閲覧者 → 必要性に応じて増加
請負業者: ほとんどのプロジェクトで禁止 → 割り当てられたプロジェクトのみ編集者
QAエンジニア: テストは編集者、仕様は閲覧者

2. 開発環境と本番環境のアクセスを分離する

開発/ステージング/本番用に個別のプロジェクトまたはブランチを作成します。

環境	開発者アクセス	QAアクセス	管理者アクセス
開発	編集者	編集者	管理者
ステージング	閲覧者	編集者	管理者
本番	禁止	閲覧者	管理者

3. 特殊な機能にはカスタムロールを使用する

特定の業務が専門化されている場合、汎用的なロールに強制的に押し込まないでください。

セキュリティチーム: 閲覧者 + Vaultシークレットへのアクセス
テクニカルライター: ドキュメントは編集者、エンドポイントは閲覧者
パフォーマンスエンジニア: テストは編集者、仕様は閲覧者

4. 四半期ごとに権限を見直す

RBACは設定して放置するものではありません。四半期ごとのレビューをスケジュールしましょう。

蓄積された権限（ロールの肥大化）をチェックする
請負業者のアクセスがプロジェクトの範囲を超えていないか確認する
新機能や担当の変更に合わせてカスタムロールを更新する
退職した従業員のアクセスはSCIMを介して即座に削除する

5. ロール定義を文書化する

以下の内容を明確に示すドキュメントを作成します。

各ロールができることとできないこと
誰がどのロールを持つべきか
ロール変更を要求する方法
アクセス紛争のエスカレーションパス

6. 監査ログを有効にする

エンタープライズプランには、以下の追跡を行う監査ログが含まれています。

誰が何にアクセスしたか
いつアクセスしたか
どのようなアクションを実行したか
ロールの割り当てと変更

監査ログは以下に利用します。

コンプライアンス報告
セキュリティインシデント調査
権限最適化分析

RBACの比較: Apidogとその他のツール

ApidogのRBACは、他のAPIコラボレーションプラットフォームとどのように比較されるでしょうか？

機能	Apidog	Postman	SwaggerHub	Bruno
権限レベル	3 (組織/チーム/プロジェクト)	2 (組織/チーム)	2 (組織/ワークスペース)	1 (Gitベース)
組み込みロール	12ロール	5ロール	4ロール	なし (Git権限)
カスタムロール	✅ (エンタープライズ)	✅ (エンタープライズ)	✅ (エンタープライズ)	❌
SSO/SAML	✅	✅	✅	❌
SCIMプロビジョニング	✅	✅	❌	❌
グループマッピング	✅	✅	✅	❌
Vaultシークレット	✅	✅ (エンタープライズ)	❌	❌
プロジェクト分離	✅ (禁止ロール)	限定的	限定的	Gitベース
外部協力者制御	✅ (ゲスト + 禁止)	限定的	限定的	Gitアクセス制御

Apidogの利点:

3段階の階層 — Postman/SwaggerHubの2段階よりもきめ細かい
禁止ロール — チーム内で明示的なアクセス禁止制御
ゲストロール — 制御された可視性を持つ外部協力者
SCIM統合 — 自動プロビジョニング/デプロビジョニング
統合プラットフォーム — RBACは、設計、テスト、ドキュメント、モックを1つのツールでカバー

Apidog RBACが理想的な場合:

複数のAPIチームを持つ大規模組織
エンタープライズコンプライアンス要件（SSO、SCIM、監査可能性）
部門横断型チーム（開発者、QA、PM、セキュリティ、ライター）
制御されたアクセスを必要とする外部協力者
厳格なアクセス境界を必要とする機密API

結論

ロールベースのアクセスコントロールは、APIコラボレーションを混乱からガバナンスへと変革します。RBACがなければ、チームの成長は権限の複雑さ、セキュリティリスク、コンプライアンスの問題を意味します。適切なRBACがあれば、チームメンバー、請負業者、ステークホルダーを追加しても制御を失うことなく、自信を持ってスケールできます。

主要なポイント:

3段階の階層（組織 → チーム → プロジェクト）は、実際のチームの働き方に合致します。
12の組み込みロールは、カスタム設定なしで標準的なシナリオをカバーします。
カスタムプロジェクトロールは、特殊なニーズに合わせてきめ細かな権限を可能にします。
SSOとSCIMは、エンタープライズのID管理と統合されます。
Vaultシークレットは、ロールベースのアクセスで認証情報管理を一元化します。
禁止ロールは、機密性の高いプロジェクトに対して明示的なアクセス拒否制御を提供します。
グループマッピングは、IdPグループに基づいてチームの割り当てを自動化します。

ApidogのRBACシステムは、5人規模のスタートアップから1000人規模のエンタープライズまで、7つの原則すべてを実装するためのツールを提供します。

ボタン

よくある質問: APIチームのためのロールベースのアクセスコントロール

API開発におけるロールベースのアクセスコントロール (RBAC) とは何ですか？

API開発におけるRBACは、個々のユーザーではなくロールにアクセス権限が割り当てられる権限モデルです。ユーザーはロール（管理者、編集者、閲覧者など）を受け取り、それらのロールがどのAPIリソースを表示、変更、テスト、管理できるかを決定します。これにより、誰かのロールを変更するだけでそのすべての権限が一度に更新されるため、チーム管理が簡素化されます。

APIコラボレーションにはなぜ3段階の権限が必要なのですか？

APIチームは、組織全体（請求、SSO）、チーム全体（プロジェクト作成、メンバー管理）、プロジェクト固有（エンドポイント編集、テスト実行）の3つのレベルで作業します。3段階のRBACは、この構造に合致しており、過剰な権限付与（過度なアクセスを与えること）や権限のギャップ（必要な制御が欠けていること）を防ぎます。

組織管理者とチーム管理者の違いは何ですか？

組織管理者は、メンバー招待、チーム作成、SSO設定、カスタムロール定義など、会社全体の設定を管理します。チーム管理者は、チームメンバーの招待、チーム内でのプロジェクト作成、チームリソースの設定など、チーム固有の操作を管理します。組織管理者はより広範な範囲を持ち、チーム管理者はチームに特化した制御を行います。

「禁止」プロジェクトロールはどのように機能しますか？

「禁止」ロールは、特定のプロジェクトへのすべてのアクセスを明示的に拒否します。ユーザーはチームメンバーのままでいられますが、「禁止」プロジェクトには一切アクセスできません。これは、特定のチームメンバーがプロジェクトコンテンツを一切見るべきではない機密性の高いAPI（決済システム、セキュリティサービスなど）に役立ちます。

「ゲスト」チームロールは何のためにありますか？

「ゲスト」は、プロジェクトへのアクセスが必要だが、チームを管理すべきではない外部協力者（請負業者、コンサルタント、部門間の派遣社員）向けです。ゲストは、チームメンバーの詳細を表示したり、メンバーを招待したり、チーム設定にアクセスしたりすることはできません。プロジェクトレベルの権限に基づいて、プロジェクトにのみ参加します。

特定の権限を持つカスタムロールを作成できますか？

はい、Apidog Enterpriseプランはカスタムプロジェクトロールをサポートしています。ブランチ管理、エンドポイント管理、自動テスト、環境管理、ドキュメント共有、プロジェクト設定、リクエスト履歴、インポート/エクスポートの8つのカテゴリにわたって、きめ細かな権限を持つロールを定義できます。「QAエンジニア」（テスト編集のみ）や「テクニカルライター」（ドキュメント編集のみ）のようなロールを作成できます。

SSO統合はRBACとどのように連携しますか？

SSOは、IDプロバイダー（Okta、Microsoft Entra IDなど）を通じて認証を一元化します。SSOが有効になっている場合、チームメンバーは企業の認証情報でサインインします。SSOは、IdPグループをApidogチームとロールにマッピングすることもでき、グループメンバーシップに基づいて適切な権限を自動的に割り当てます。

SCIMプロビジョニングとは何ですか、またなぜそれを使用するのですか？

SCIMは、ユーザーライフサイクル管理を自動化します。誰かが会社に入社すると、IdPが自動的にApidogアカウントをプロビジョニングします。誰かが退職すると、SCIMがそのアクセス権を即座に削除します。これにより、手動での招待/削除ワークフローが不要になり、退職した従業員の認証情報が残存するのを防ぎます。

VaultシークレットはRBACとどのように連携しますか？

Vaultシークレットは、暗号化された認証情報（APIキー、パスワード、トークン）を集中管理します。ユーザーは実際の値を見ることなく、名前でシークレットを参照します。RBACは、Vaultシークレットを追加、変更、またはアクセスできる人を制御します — 通常は管理者と編集者です。これにより、環境ファイルやGitリポジトリを介した認証情報の漏洩を防ぎます。

請負業者は組織メンバーロールまたはゲストロールのどちらを持つべきですか？

請負業者は通常、チームレベルではゲストロールを持ち、プロジェクトレベルでは編集者または閲覧者ロールを持つべきです。「その他のプロジェクト = 禁止」でプロジェクトレベルの招待を使用し、割り当てられたプロジェクトのみに可視性を制限することで、無関係なビジネス領域へのアクセスを防ぐことができます。