現在の導線
一時的な ID ブートストラップ
公開向けの passkey-first サインインはまだ有効化していません。最初の所有者ブートストラップだけは、既存の Ronova private 管理セッションから一時的な高信頼セッションを作れます。
この橋渡しは意図的に狭く保たれています。既存の private 管理セッションが必要で、他ドメイン向けの共有 Cookie は作りません。
ガバナンス画面
Ronova ID 管理
登録済みクライアント、ロール、権限、監査確認を扱う管理用の統制画面です。
どのアプリケーションが何を求められるか、誰が承認できるか、重要変更がどう記録されるかを定める場です。
ガバナンス画面
ID 全体モデルを行き来する
管理ガバナンスは、同じ ID 基盤と同じアカウント側確認モデルの上に乗っています。
ガバナンス
管理画面が制御するもの
管理画面は、Ronova ID が抽象設計から実運用の制御面へ変わる場所です。
クライアント登録
各アプリケーションや各コンソールは、既知の戻り先と既知の権限境界を持ったうえで登録されてから ID を求めます。
高信頼の画面が無名クライアントとして現れてはいけません。
権限バンドル
権限はロールに束ねられ、繰り返し現れる作業へ毎回場当たりの権限を作らずに済みます。
付与にも見直しにも役立ちます。
監査ストリーム
監査の流れは、ID イベントをクライアント、行為者、実行された変更へ結び付けるべきです。
平時の統制にも障害対応にも有効です。
統制の循環
管理変更の流れ
重要な ID 変更は、ワンクリックの魔法ではなく、意図的な順序で進むべきです。
- 01
クライアントに名前を与える
アプリケーションを登録し、戻り先を定義し、その役割を後から見ても読める形で残します。
- 02
範囲を定める
本当に必要な権限だけを付け、繰り返し作業は名前付きロールへ束ねます。
- 03
意図的に承認する
高権限アクセスは、行為者、理由、対象 ID を見える状態にして承認または拒否します。
- 04
結果を監査する
その結果の監査連鎖を見直し、統制が想定どおり働いたかを確かめます。
管理一覧
管理者が統治する対象
管理画面は、隠れた裏部屋ではなく、ID 運用の統制台帳として感じられるべきです。
クライアント登録簿
許可済みアプリケーション、その戻り先、求めてよい権限を管理します。
一覧の起点はクライアント登録です。
ロール一覧
運用担当、確認担当、所有者の責務を、名前のついたロールとして権限束にまとめます。
束にすると場当たり的な権限判断が減ります。
監査ビュー
サインイン、承認、失効、リダイレクト結果、重要変更を一つの視点で確認します。
監査画面が ID ガバナンスを読みやすくします。
原則
管理ガバナンスの原則
管理は権力の話だけではありません。その権力が限定され、見直され、正しいクライアントへ結び付いていたと証明する話でもあります。
狭く始める
新しいクライアントやロールは、快適に感じるより狭く始め、実際の業務が必要性を示したときだけ広げます。
最小権限は出発姿勢です。
意図して昇格する
影響の大きい変更は、より強い確認や、目に見えて別の高権限セッションを要求するべきです。
段階的な昇格が重要作業を切り分けます。
境界を検査可能に保つ
ID 側とアプリケーション側の双方で、リダイレクト問題、権限問題、悪用報告を追えるだけの共通視界が必要です。
境界が見えるほど統制は機能します。