2025年9月03日·1 分
複数製品に跨る権限を管理するウェブアプリの作り方
複数製品に跨るロール、グループ、権限を一元化し、監査、SSO、段階的な導入を備えた権限管理ウェブアプリの設計と構築方法を学びます。
複数製品に跨るロール、グループ、権限を一元化し、監査、SSO、段階的な導入を備えた権限管理ウェブアプリの設計と構築方法を学びます。
「複数の製品で権限を管理したい」と言う場合、通常は次のいずれかを意味します：
チームは壊れ始めてからでないと明確に名前を付けられないことが多いです。
**ロールとポリシーの不整合。**ある製品の「Editor」はレコードを削除できるが、別の製品ではできない。ユーザーは自分に必要なものが分からずアクセスを過剰にリクエストする。\n **手動のプロビジョニング／デプロビジョニング。**アクセス変更がSlackメッセージ、スプレッドシート、チケットキューで行われる。オフボーディングは特に危険で、あるツールではアクセスが切れても別のツールでは残る。\n **所有権が不明確。**誰がアクセスを承認できるのか、誰がレビューすべきか、権限ミスでインシデントが発生したときに誰が責任を負うのか分からない。\n
良い権限管理ウェブアプリは単なるコントロールパネルではなく、明快さを生み出すシステムです。\n **中央管理で一貫した定義。**ロールは理解しやすく再利用可能で、製品間で整合する（少なくとも差異は明示する）。\n **ガードレール付きセルフサービス。**ユーザーは適切な人を探さずにアクセスを要求でき、機微な権限は承認が必要となる。\n **承認フローと説明責任。**すべての変更にオーナーがいる：誰がリクエストし、誰が承認し、なぜか。\n 監査可能性をデフォルトに。「いつ誰が何にアクセスしていたか」を5つのシステムのログを継ぎ接ぎせずに答えられる。\n
速度と安全性に沿った成果を追跡します：
アクセス変更をより早く、かつより予測可能にできれば、正しい方向に進んでいます。
ロール設計や技術選定の前に、初日で何をカバーするか、明確にしておきましょう。スコープを絞ると途中で全て作り直すリスクが減ります。
最初は短いリスト（多くは1〜3製品）から始め、各製品が現在どのようにアクセスを表現しているかを書き出します：
is_admin フラグを使っているか？\n- 権限はグローバル（製品全体）か、エンティティ（プロジェクト、ワークスペース、アカウント）に紐づくか？\n- 現在どこで権限が強制されているか（フロント、バック、両方）？\n
もし二つの製品のモデルが根本的に異なるなら、早めにメモしておきましょう — すぐに単一形に無理やり合わせるのではなく翻訳レイヤーが必要になるかもしれません。権限システムは「エンドユーザー」以上を扱う必要があります。少なくとも定義してください：
ビジネスとユーザーにとって重要なアクションを列挙します。一般的なカテゴリ：
アイデンティティと属性がどこから来るかを明確にします：
最初の大きな決定は「認可をどこに置くか」です。この選択が統合努力、管理体験、将来的な権限の安全な進化に影響します。
集中モデルでは専用の認可サービスが全製品のアクセスを評価します。製品はそれを呼び出す（または中央発行の決定を検証する）ことでアクションを許容します。
一貫したポリシー挙動、横断的なロール、変更の監査を一か所で行える点が魅力です。主なコストは統合：全製品が共有サービスの可用性、レイテンシ、決定フォーマットに依存するようになります。
フェデレートモデルでは各製品が自前で権限を実装・評価します。「マネージャーアプリ」は主に割当ワークフローを扱い、その結果を各製品に同期します。
製品の自律性が最大化され、共有のランタイム依存が減ります。欠点はドリフト：名前や意味、エッジケースが乖離し、横断管理とレポートが難しくなることです。
実務的な折衷案は、権限マネージャをコントロールプレーン（単一の管理コンソール）とし、製品を実行時の強制ポイントにすることです。
共通で一致させる必要がある概念（例：「Billing Admin」「Read Reports」）の共有権限カタログを維持し、同時に製品固有の権限の余地も残します。製品はロールや付与、グループマッピングをプルするか受け取り、ローカルで強制します。
権限システムはデータモデルで成功か失敗かが決まります。説明しやすく、管理しやすく、監査しやすいようにまずRBACで単純に始め、RBACでは粗すぎる場合にだけ属性（ABAC）を追加してください。
最低限、次の概念を明示的にモデル化します：
project.read, project.write, billing.manage）。\n- Roles：権限の集合として名前付けされたもの。\n
実務的なパターン：ロール割当はプリンシパル（ユーザーまたはグループ）をスコープ（製品全体、リソースレベル、またはその両方）内のロールに紐付けます。各製品ごとにロールを定義して語彙を明確に保ちます（例：Product Aの「Analyst」はProduct Bの「Analyst」と同じ意味である必要はない）。
次にロールテンプレートを追加します：テナントや環境、顧客アカウントで再利用できる標準化されたロールです。その上で、複数製品に共通する業務機能のためのバンドル（例：「サポートエージェントバンドル」= Product A + Product B + Product C のロール群）を作ると、管理工数を下げつつ全てを一つの巨大ロールにまとめずに済みます。
デフォルトの体験を安全にします：
billing.manage、user.invite、audit.export のような高リスク権限は分離して扱う。\n「地域に属するチケットのみ閲覧できる」「ステージングのみデプロイ可能」など、RBACでは表現が難しいルールが出てきたらABACを導入します。属性は制約（region、environment、data_classification）に使い、RBACは人間がアクセスを考えるための主要手段に保ちます。
役割命名やスコープの慣例に関する詳細ガイドは社内ドキュメントや /docs/authorization-model を参照してください。
権限アプリは人、製品、ポリシーの間に位置するため、各リクエストが「誰が行っているか」「どの製品が問い合わせているか」「どの権限を適用するか」を明確にする計画が必要です。
各製品（と環境）をクライアントとして扱います：
二つの入り口をサポートします：
二つの一般的なパターン：
実務的なハイブリッド：JWTに identity + tenant + roles を入れつつ、細かい権限判定はエンドポイントで確認する。\n
バックグラウンドジョブに対してユーザートークンを流用しないでください。サービスアカウントを作り、明示的なスコープで client-credential トークン を発行し、監査ログで人のアクションと分けて記録します。
製品が同じ質問をし、一貫した回答を得られなければ権限アプリは機能しません。各製品が一度実装すれば再利用できる、小さく安定したAPIセットを定義することが目標です。
全製品が必要とする操作に集中したコアエンドポイントを用意します：
多くのチームは組み合わせを使います：
POST /authz/check を呼ぶ（またはローカルSDKを使う）。\n- ローカル強制（非同期レプリケーション）：製品がエンタイトルメントの読み取りモデルを保持し、UIゲーティングやオフライン判定を高速化する。\n
実務ルール：中央のチェックは高リスクアクションの真のソース・オブ・トゥルースにし、複製データはUX（メニュー、フィーチャーフラグ、"アクセスあり" バッジ）向けに使う。時折の古さは許容する。権限が変わったときに全製品がポーリングするのは避けましょう。
role.granted、role.revoked、membership.changed、policy.updated のようなイベントをキューやWebhookで公開します。製品はサブスクライブしてローカルキャッシュや読み取りモデルを更新します。
イベント設計の要点：
アクセスチェックは高速である必要がありますが、キャッシュの無効化が弱いとセキュリティバグになります。
一般的なパターン：
権限は製品が機能追加するたびに進化します。計画してください：
/v1/authz/check）\n- 可能な限り権限は加法的に扱う（意味を変えるより新しいアクションを追加する）\n- 廃止はスケジュールとテレメトリで行う：古いエンドポイントを呼んでいる製品を計測し、移行期間を設ける\n
互換性への小さな投資が、権限システムを新機能のボトルネックにすることを防ぎます。権限システムは技術的に正しくても、管理者が「誰が何にアクセスしているか、なぜそうなっているか」に自信を持てなければ失敗します。UXは推測を減らし、誤った過剰付与を防ぎ、一般的な作業を迅速にします。
日常業務の80%をカバーする小さなページセットから始めます：
バルクツールは時間を節約しますがミスを拡大するので、安全設計が必要です：
多くの組織は軽量なプロセスを必要とします：
Request → Approve → Provision → Notify
リクエストはビジネスコンテキスト（"Q4締めのため"）と期間をキャプチャします。承認はロールと製品に応じた適切な承認者が行い、プロビジョニングは監査エントリを生成して申請者と承認者に通知します。
命名を一貫させ、UIで略語を避け、インライン警告（"これは顧客のPIIにアクセスします"）を表示します。キーボード操作、読みやすいコントラスト、空の状態の明示（"まだロールは割り当てられていません—追加してください"）にも配慮してください。
監査は「アクセスが正しいと思う」から「証明できる」へ変える要です。権限を複数の製品で管理する場合、特にロール付与、ポリシー編集、管理者アクションは追跡可能でなければなりません。
最低でも「誰が、いつ、どのような理由で、何を変更したか」を記録します：
監査イベントは**追記のみ（append-only）**として扱ってください。アプリケーションコードからの更新や削除を許可せず、修正が必要な場合は補償イベントを書きます。
保持期間はリスクと規制で決めます：多くのチームはホットな検索可能ログを30〜90日保持し、1〜7年でアーカイブします。エクスポートを容易にし、日次納品やSIEM向けのストリーミングを提供します。少なくとも改行区切りJSONをサポートし、重複排除のための安定IDを含めてください。
シンプルな検出器を作ってフラグを立てます：
実務的でエクスポート可能なレポートを用意します：
権限管理アプリ自体が高価値なターゲットです：一つの誤った決定で全製品に広範なアクセスが与えられます。管理面と認可チェックを"Tier-0"システムとして扱ってください。
最小権限から始め、昇格を意図的に難しくします：
管理APIはエンドユーザーAPIと同じ露出にしてはいけません：
HttpOnly、Secure、SameSite、短いセッション寿命、ブラウザフローのCSRF保護。\n
よくある失敗モード：ポリシー書き込みが可能なサービス認証情報が漏れる。認可バグは通常「拒否の欠如（missing deny）」です：
権限システムはローンチで「完成」するものではありません — 安全に段階的に展開して信頼を得ます。目標はアクセス判断が正しいことを実証し、サポートが迅速に問題を解決でき、ロールバックが容易なことです。
役割が明確でアクティブユーザーがいる単一製品で始めます。その製品の現在のロール／グループを新システムの小さな正準ロールにマッピングし、製品が現在強制している形式（APIスコープ、フラグ、DBフラグ等）に変換するアダプタを作ります。
パイロット中、フルループを検証します：
レガシー権限は混沌としています。既存のグループ、例外、製品固有ロールを新モデルに変換するステップを計画し、移行された各割当を説明できるマッピングテーブルを残してください。
ステージングでドライランを行い、波状（組織、地域、顧客ランク別）で移行します。難しい顧客には"シャドウモード"を残して旧判定と新判定を比較できるようにし、強制は後で切り替えます。
フラグにより"書き込み経路"と"強制経路"を分離できます。典型的な段階：
一般的なインシデントに対するランブックを用意します：ユーザーが製品にアクセスできない、ユーザーにアクセスが多すぎる、管理者の誤操作、緊急取り消し。オンコール、確認すべきログ、実効権限の確認方法、迅速に反映される"ブレイクグラス"取り消し手順を含めます。
パイロットが安定したら同じプレイブックで製品ごとに繰り返します。新しい製品は統合作業として扱われ、権限モデルの再発明にはしないことが理想です。
堅牢な権限管理アプリを出すのに珍しい技術は不要です。正確さ、予測可能性、運用性を優先し、それから最適化してください。
一般的なベースライン：
プロトタイプやパイロットを素早く作るなら、Koder.ai のようなプラットフォームがチャット駆動のワークフローで管理UI（Reactベース）、Go＋Postgresのバックエンド、監査ログ／承認のスキャフォールドを生成してくれるので役立つことがあります。実装の正しさは厳密にレビューする必要がありますが、スペックから動くパイロットまでの時間を短縮できます。
権限システムはユーザーリストの同期、下流製品への割当プロビジョニング、ロールテンプレート変更後の派生権限再計算、定期的な整合性チェック（孤立した割当の検出）など、リクエストをブロックしないジョブを多数抱えます。
ジョブは冪等で再試行可能にし、テナントごとのジョブステータスを保存してサポート可能にします。
最低限計測する項目：
deny-by-error の急増（DBタイムアウトなど）や権限チェックのp95/p99レイテンシにアラートを設定してください。展開前に permission-check エンドポイント をリアルなパターンで負荷試験します：
コアな権限モデルが機能したら、運用を大幅に楽にする"エンタープライズ"機能を追加できます。これらは製品の強制方法を変えずにスケーラビリティを高めます。
SSOは多くの場合 SAML 2.0（古い企業IdP向け）か OpenID Connect (OIDC)（モダンスタック向け）です。重要な設計は IdPから何を信頼するか です。
実務的パターン：IdPからのアイデンティティと高レベルのグループ所属を受け取り、そのグループを各テナントごとのロールテンプレートにマップします。例：IdPグループ Acme-App-Admins がテナント acme の Workspace Admin にマップされる。マッピングは明示的でテナント管理者が編集可能にし、ハードコードしないでください。
IdPグループを直接権限として使うのは避けてください。組織上の都合でグループは変わりやすく、アプリ側のロールは安定させるべきです。IdPは「そのユーザーが誰か」と「どの組織グループにいるか」を伝えるソースとして扱い、各製品での具体的な行為はアプリ側のロールで決めるべきです。
SCIMにより顧客はアカウントライフサイクル（ユーザー作成、無効化、グループ同期）を自動化できます。これが手動招待を減らし、退職時のセキュリティギャップを閉じます。
実装のヒント：
マルチテナントのアクセス制御は、トークン内識別子、DBの行レベルフィルタ、キャッシュキー、監査ログのあらゆる場所でテナントの分離を保証しなければなりません。
管理境界を明確にします：テナント管理者は自テナント内のみユーザーとロールを管理でき、プラットフォーム管理者はデフォルトで製品アクセスを付与せずにトラブルシュートできるようにします。
より深い実装ガイドやパッケージ選定は /blog を参照してください。どの機能をどのプランに含めるか決める際は /pricing と整合させてください。
まず統合する最初の1～3製品を一覧化し、それぞれについて以下をドキュメント化してください：
モデルが大きく異なる場合は、すぐに単一モデルに無理やり落とし込もうとせず、変換層（translation layer）を計画してください。
評価をどこで行いたいかによって選びます：
複数製品や頻繁な変更を見込むなら、ハイブリッドが無難なデフォルトです。
実務的な出発点はRBACをベースに、明確なエンティティを定義することです：
billing.manage のような原子アクション）その上でを の形で保存すると、「誰がどこで何を持っているか」を把握しやすくなります。
RBACを人間向けのインターフェースとし、RBACだけでは表現しづらい制約が出てきたときにABACを導入してください。
ABACを使う典型的なケース：
属性は最小限に保ち（region、environment、data_classificationなど）、ロールは引き続き主要な付与単位にしてください。
単一の巨大ロールを避けるために階層化します：
決定パターンに応じて設計します：
すべての製品が一度だけ実装すればよい、安定した小さなコアを提供します：
POST /authz/check（ホットパス）語彙を標準化してください：, , , （tenant/org/workspace）、任意の（属性）。コアAPIに製品固有ロジックを入れないことが重要です。
変更をポーリングに頼らずイベントで配信してください。公開するイベント例：
role.granted / role.revoked\n- membership.changed\n- policy.updated\n
イベントは冪等かつ可能なら subject+tenant 単位で順序保証し、(a) ローカル状態を更新できるだけの自己記述性があるか、(b) 再同期用の「現在の状態取得」エンドポイントと組み合わせてください。ミスを減らすための画面とガードレールを含めてください：
権限変更の全てをappend-onlyイベントとして記録し、「誰が、いつ、どこから、なぜ」変更したかを証明できるようにします。
最低限含める項目：
エクスポート（改行区切りJSONなど）をサポートし、SIEM向けの安定IDを含めてください。
(プリンシパル=ユーザー/グループ) + (ロール) + (スコープ=テナント/製品/リソース)