認可と職務分掌
Merlon は対話的ユーザーを JWT セッションで、非対話的クライアントを API キーで認証する。両方の経路に同一のロールモデルが適用される。導入組織は、これらのロールを自組織のアクセス制御・変更管理ポリシーにマッピングしなければならない。
| 権限 | Admin | Analyst | Viewer |
|---|---|---|---|
ホワイトリスト登録を申請する(whitelist:request) | Yes | Yes | No |
ホワイトリスト登録を承認する(whitelist:approve) | Yes | No | No |
監査記録を読み取る(audit:read) | Yes | No | No |
ルールの作成・更新・インポート・有効化・無効化(rule:write) | Yes | No | No |
ホワイトリストのワークフローでは、申請者が自身の申請を承認できないことが強制される。これにより、ホワイトリスト判断について、独立した一次申請と二次承認の統制が提供される。
ルールの有効化・無効化についても、同じ分離がアプリケーション内で強制される。事前チェックではなくリポジトリのトランザクション内で実施される(ADR-0014)。対象バージョンを正確にロックしたうえで、承認者と当該バージョンの作成者が同一の場合、またはいずれかの識別情報が欠けている場合は 403 で拒否する。推測による補完は行わず、フェイルクローズドで動作する。API 経由で作成されたルールおよびルールバージョンは常に無効状態であるため、有効化は必ず別個に帰属可能な二つ目の行為となる。
状態変更のたびに、同一トランザクション内で rule_activation_events 行が書き込まれ、対象バージョン・作成者・承認者・要求された状態・タイムスタンプが記録される。サービス実行ロールにはこの承認台帳に対する SELECT と INSERT のみが付与されるため、承認の証跡を事後に改変することはできない。
認証設計と認証情報の取り扱いについては、設定リファレンス を参照。