SDF識別子(Identifier)ベースのライセンス共通モデル
| 著者 | 日付 | 変更内容 |
|---|---|---|
| 朝鮮王朝 | 2026-02-02 | 最初の作成 |
1. 目的
SDF(Sensitive Docs Flow)は、業務システムで文書を暗号化・復号化するために呼び出す連携型文書セキュリティ処理サービスです。
既存の運営構造では、次のような問題が存在していました。
- サーバー(App)単位の運用のため、コンテナ環境での呼び出し主体の追跡が難しいです。
- ポリシー/ログ/課金基準がサーバー中心で一貫していません。
- ライセンス範囲とAPI呼び出し認証要素が混在して運用混乱が発生します。
したがって、本書はSDF運営基準を**識別子(Identifier)**中心に転換する構造を定義します。
SDFライセンスの共通運用基準であり、Container/App/Hybrid文書の上位基準です。
2. 運営基準 の転換
SDFは運用基準単位を既存のサーバー中心から業務単位識別子中心に転換します。
| 区分 | 既存（サーバー中心） | 変更後（識別子中心） |
|---|---|---|
| 運用基準 | サーバー/アプリ単位 | 業務単位識別子 |
| ポリシーの適用 | ドキュメントプロパティ中心 | 識別子ベースのポリシー |
| ログ追跡 | 結果中心 | 識別子基準追跡 |
| 課金基準 | サーバーユニットの推定 | 業務単位の明確化 |
つまり、識別子はSDF運営の中心軸になります。
3. コア概念の定義
SDF運営モデルは次の3つの要素を明確に分離します。
3.1 ライセンスキー (License Key)
ライセンスキーは顧客の使用範囲を有効にするキーです。
- テナントの使用権限を有効にします。
- 許可される識別子の数を決定します。
- App環境では許可されるサーバー数を決定します。
3.2 識別子(Identifier)
識別子は実際の業務単位運営の基準です。
- 業務目的単位で区分します。(例: 電子決裁、承認返却)
- ポリシー適用基準になります。
- ログ追跡の基準になります。
- 感謝および課金基準となります。
※識別子(Identifier)は業務単位の区分値であり、Container/Appの実行環境を区分するための値としては使用しません。
3.3 アクセスキー (Access Key, AK)
アクセスキー(AK)はSDF API呼び出し認証キー(Secret)です。
- 誰が呼び出したかを証明します。
- 外部業務システムの認証手段として使用されます。
- ライセンスとは別に管理されます。
アクセスキーは「呼び出し主体認証」要素です。
[別添1] 核心概念の比較: 識別子 / 文書ID / 文書グレード
SDFの運用では、「識別子」だけでなく、文書単位の追跡のための文書IDや、セキュリティ 制御のための文書グレードの概念が存在します。
三つの概念は目的と適用基準が異なるため、混同してはいけません。
| 区分 | 識別子 | 文書ID | 文書のグレード |
|---|---|---|---|
| 管理目的 | 業務システムの用途区分 | 個別文書の追跡 | ランクベースの文書制御 |
| 使用基準 | ライセンス、ポリシー、条件付きポリシー、ログ管理 | 文書履歴およびセキュリティトラッキング | 文書履歴およびセキュリティトラッキング |
| 生成時点 | SDF変換リクエスト時 | 文書作成時 | 文書作成時 |
| 維持範囲 | 文書ライフサイクル全体（メタデータベース） | 文書ライフサイクル全体 | 文書ライフサイクル全体 |
| 文書の含有可否 | X (運用メタデータ) | O | O |
| 役割の要約 | 運営管理基準 | 追跡基準 | セキュリティ等級基準 |
つまり、SDFは識別子を基準に業務単位を区分し, ライセンス, 条件付きポリシー, ログ管理を一貫して適用します。
4. APIリクエスト構造標準
SDF APIを呼び出す際には、必ず次の2つの値が一緒に渡される必要があります。Identifierのない呼び出しは、ポリシー/ログ/課金基準が成り立たないため、許可しない方向を原則としています。
Access Key (AK) : 호출 주체 인증
Identifier : 업무 구분
※ APIヘッダーフィールド名はシステム標準に従うため、英語のままにします。
5. SDF内部処理フロー（識別子ベース）
SDFはリクエストを次の順序で処理します。
- アクセスキー(AK)を検証して呼び出しの許可可否を判断します。
- 識別子を検証してライセンスの範囲内であるかどうかを確認します。
- 識別子ベースの条件付きポリシーを適用します。
- 文書の暗号化・復号化処理を行います。
- ログおよびドキュメントヘッダーに識別子を記録します。
結果として、
- ポリシー運営
- 監査トレース
- 課金基準
すべては識別子中心に統合されます。
6. 識別子運用ポリシー
6.1 作成基準
識別子は業務単位に基づいて生成することを推奨します。
例:
- 電子決裁
- 承認出荷
- 外部協業文書
識別子生成の乱発を防ぐために、案内文を提供します。
6.2 作成権限
識別子の生成と管理は、Org Admin以上の権限に制限されています。
6.3 識別子構造
識別子はユーザーフレンドリーさとシステムの安定性のために次の構造を持っています。
- 表示名: ユーザーが入力する業務名です。
- 識別子コード: システムが自動生成するユニークコード(GUID)です。
ユーザーはDisplay Nameのみを認識すればよく、Identifier Codeはシステムで管理されます。
7. アクセス権限システム (RBAC)
各管理者は担当範囲に応じて、次のように運用権限が区分されます。
| 役割 | 権限範囲 |
|---|---|
| マスター管理者 | ライセンスキーの登録/変更、ユーザー/権限管理、アクセスキー(AK)の原文照会/再発行 |
| 運用管理者 | 識別子の生成/管理、業務システムの登録、アクセスキー(AK)の状態管理 |
| 照会管理者 | ポリシー運用、ログ照会 |
[別添2] 権限タイプ別運営構造詳細テーブル
| 区分 | マスター管理者 | 運用管理者 | 照会管理者 | メンテナンス担当者 |
|---|---|---|---|---|
| 役割範囲 | SDFサービス全体運営 | 担当業務 システム運営 | 運営状況の確認（編集不可） | メンテナンスの実施 |
| 管理対象 | 全業務システム | 担当業務システム | なし | 全体 |
| 識別子管理 | O (全体生成/削除) | X | X | △ (照会) |
| ポリシー設定 | O (全体ポリシー) | O (担当業務システム) | X | △ (照会) |
| ログの照会 | O (全体) | O (担当業務システム) | O (担当範囲) | O (全体) |
| ダッシュボード | O (全体) | O (担当業務システム) | O (担当範囲) | O (全体) |
| ログ/ダッシュボード エクスポート | O | O | X | O |
| 連携システム管理 | O | O (担当業務システム) | X | X |
| ライセンス管理 | O | X | X | X |
| サーバー管理(App環境) | O (全体) | O (担当範囲) | X | △ (照会) |
| 管理者権限管理 | O | X | X | X |
※ アプリ環境でのみ “サーバー管理” 機能が追加されます。 コンテナ環境ではサーバーの概念は存在しません。
8. マイグレーションの基本方針
既存顧客のアップグレード時には、次のポリシーを適用します。
- 基本識別子を1つ自動生成します。
例:
Legacy-Default - 既存のログおよび運用データは基本識別子に帰属します。
- 顧客は業務ごとの識別子を追加生成し、徐々に分離することができます。
転換案内文の例は 次のとおりです。
“識別子ベースの運用に切り替えられました。 基本識別子が自動生成されました。 業務ごとの識別子を追加登録してください。”
9. まとめ
識別子ベースの運用モデルは、SDFのポリシー/ログ/トラッキング/課金システムを業務単位で統合するための重要な転換です。
この文書は運用基準を定義し、後続の文書はこれをUIで実装します。
この文書はSDF運用基準を定義する最上位文書であり、後続文書は環境ごとの運用方法に応じて次のように拡張されます。
[別添 3] 環境別ライセンス適用の違い
SDFは実行環境に応じてライセンス適用基準が異なります。
| 区分 | コンテナ環境 | App(On-Prem) 環境 |
|---|---|---|
| サーバーの概念 | なし | あります |
| 制限基準 | 識別子の数のみ制限 | 識別子数 + サーバー数制限 |
| サーバー登録 | 不必要 | 必須（キーに基づく検証方式を推奨） |
| 運用基準 | 識別子中心の運用 | 識別子中心 + サーバー参照 |
| 適用理由 | Pod オートスケーリング | 設置規模とコ スト管理 |