メインコンテンツまでスキップ

SDF APP 運用モデル

著者日付変更内容
朝鮮王朝2026-02-03最初の作成

1. 目的​

SDFアプリ（オンプレミス）環境は、インストールサーバーが明確に存在するため、識別子ベースの運用とともに**サーバー数制限（サーバースロット）**実行が必要です。

この文書は「サーバーをどのように区別するか」ではなく、サーバーの数の制限をどのように「確実に実施」するかに焦点を当てます。

つまり、IP/MACのような「変動可能な値」の代わりにサーバーが所有するキー（秘密鍵）で「登録されたサーバーであること」を証明する構造を目指します。

  • ライセンス1つにつき
    • 識別子3つ基本提供
    • アプリ環境は**許可されたサーバー数の制限（サーバースロット）**必要
    • IP/MACベースのデバイス識別は失敗事例が多く信頼性が低い →**キーに基づく検証（登録サーバーのみ許可）**への移行

※ ハイブリッド運用基準は上位文書(SDFハイブリッド運用モデル)で定義されており、本文書はApp(On-Prem)環境で追加されるサーバースロット実行方式を詳細に説明します。

2. 運営基準および核心概念の定義​

2.1. 運営基準​

SDFは基本的に識別子中心の運用モデルに従います。

アプリ環境では、識別子運用構造の上にサーバーユニットの実行要素が追加されます。

  • つまり、App 環境は業務単位 + サーバ単位の実行が同時に必要します。
区分コンテナ環境App(On-Prem) 環境
サーバーの概念なしあります
制限基準識別子の数のみ制限識別子+ サーバースロット制限
運営単位業務識別子中心業務識別子 + インストールサーバー

※ コンテナ/App 共通運用基準は識別子であり、App 環境でのみサーバースロットの実行が追加されます。

2.2 コア概念の定義​

概念意味
ライセンスキー識別子数 + サーバースロット数の決定
AK(Access Key)呼び出し主体認証シークレット
識別子業務単位（ポリシー/ログ/課金基準）
サーバースロット登録可能な App Server 最大台数
  • 例示
    • 識別子3つまで許可：業務システムは最大3つの業務単位で運用可能
    • サーバースロット2つ許可: App Serverは最大2台までインストール/運用可能です。

3. サーバースロットの執行 (Enforcement)​

  • 登録: スロットの残りがある場合のみ登録を許可
  • 呼び出し: 未登録サーバーリクエストのブロック
  • 運用: 登録/廃棄/回避試行監査ログ記録

4. IP/MAC の制限​

4.1 IPベースの限界​

  • IPはネットワーク構成(DHCP/NAT/再割り当てなど)により変更/共有可能です。
  • そのサーバーを代表するのは難しく、サーバー数制限の実施には不適切です。
  • IPはサーバーのアイデンティティというよりも「現在のネットワーク位置」に近い → サーバー台数の実行（2台/3台制限）に不正確

**結論:**サーバー登録基準をIPのみにする方式は運用リスクが大きい。

4.2 MACに基づく限界​

  • マルチNICサーバーはMACアドレスが複数あるため混乱が発生します
  • 仮想NIC/セキュリティソリューション/ドライバー環境で代表MACが揺れる可能性があります
  • Java環境でのOSインターフェース選択が不安定で失敗事例多数
  • MACは一意に見えますが、仮想/複数NIC環境では代表値の選択が不安定で、スプーフィングの可能性も存在します。

結論:“MAC 1つの代表値固定”方式は誤動作/障害の可能性が高い

5. サーバー検証設計原則(To-Be)​

5.1 原則​

  • サーバー数の制限は「サーバーを当てる問題」ではなく登録されたサーバーのみを通過させる検証問題
  • サーバーを値（IP/MAC）で識別せず、サーバーが持つ秘密鍵(Private Key)「私が登録されたサーバー」であることを証明する方法が安定している
  • したがって、IP/MACの代わりにプライベートキーに基づく検証構造に移行します。
    • キーに基づく検証は「サーバーがキーを所有しているか（Proof of Possession）」を証明するため、ネットワーク/環境の変化に強いです。

5.2 推奨アプローチ​

  • **サーバー登録(Enrollment) + キーに基づく証明(Proof of Possession)**構造
  • OS/ハードウェアフィンガープリンツは単独実行ではなく補助信号ロマン活用（異常徴候検出/交換確認）

つまり、Device Identification（値ベースの識別）ではなく、Device Verification（キー ベースの検証）方式に切り替えます。

6. サーバー登録および証明書ベースの実行構造（提案）​

6.1 なぜ「登録」が必要なのか？​

サーバーの制限をするには「このサーバーは許可されたサーバーである」という検証可能な状態値この必要

IP/MACは揺れるので、登録されたサーバーのみが保有するキー/証明書で証明

つまり、サーバースロットは「数字」ではなく**登録（状態） + 検証（通過/ブロック）**で執行されなければならない

6.2 登録ステージの詳細シナリオ​

サーバースロットの実行のために、App Serverは最初に1回の登録手続きを実行します。

  1. 管理者（ウェブコンソール）がライセンスキーを登録する

    • 識別子スロット3つを有効化
    • サーバースロット N 個を有効化

  2. App Serverがサーバー登録リクエスト

    • アプリサーバー内部で**鍵ペア（公開鍵/秘密鍵）**生成
    • 個人鍵は外部に露出してはいけません（ローカル安全保存）
    • 公開鍵基盤**CSR（証明書署名要求）**生成

  3. コンソール/ライセンスサーバーが登録承認

    • サーバースロット残り数確認
    • 承認時に「登録完了」状態を保存
    • サーバースロット 1個消費（残り -1）

  4. 証明書の発行/インストール完了

    • その後、API呼び出し時にサーバーはこの証明書で自分を証明します。

6.3 複製インストール防止（運用ポイント）​

  • サーバープログラム/イメージを複製しても登録されたキー/証明書がない場合は未登録サーバーで処理されて呼び出しがブロックされました
  • 再インストール/交換は再登録で制御されます
  • (選択) TPMバインディングによる秘密鍵の複製難易度を高めるオプションの検討

7. API 呼び出しステップの実行（各リクエスト）​

運用中のAPIリクエストは、次の順序で検証されます。

検証順序​

  1. 登録サーバーの有無確認
  2. AK 呼び出し主体認証
  3. 業務単位識別子ライセンス範囲検証
  4. ポリシーの適用とドキュメント変換処理
  5. ログ記録

サーバースロットの実行は必ず1段階（登録サーバー検証）でブロック可能でなければならない 未登録サーバーがアクセストークン/識別子をバイパスして呼び出すのを根本的にブロックするため したがって、サーバー検証（mTLSまたは署名検証）はAPI Gatewayレベルで最初に実行される

推奨検証方式​

  • サーバーはクライアント証明書自分を証明する
  • システムは「登録された証明書のリスト」と照合して許可の可否を決定します。

(代替) サインベースのトークン方式​

mTLSが難しい環境（プロキシ/特殊ネットワーク）では、次の代替案も可能です。

  • サーバーがリクエストにnonce + timestampを含み、秘密鍵で署名
  • サーバー/コンソールが登録された公開鍵で署名を検証
  • 再送信攻撃を防ぐためにnonceの保存/期限処理が必要です

8. 運用の安定性(Heartbeat)​

8.1 ハートビートの目的​

  • 登録サーバーは定期的に状態を報告し、コンソールはこれに基づいて正常/未接続/期限切れ間近の状態を表示します。

8.2 ハートビートデータ（例）​

  • serverId(登録 ID)
  • appVersion
  • lastSeenAt
  • certExpireAt
  • hostname(表示用)
  • ipList/macList(補助/参考用)
  • メトリクス（オプション）：スループット/エラーレート

9. サーバーの交換/再インストール/障害復旧（運用必須）​

9.1 手順​

  • 廃棄(De-register)
    • 該当サーバー証明書の廃棄（即時ブロック）
    • サーバースロット 1個回収(+1)
    • 廃棄理由/作業者/時間ログ必須
  • 再登録 (Re-enroll)
    • 新しいサーバーでの登録手続きを実行する
    • サーバースロットを再消費する(-1)

9.2 権限/ポリシー（運用防御）​

  • サーバー廃棄は管理者権限でのみ可能
  • 廃棄即時遮断（再利用不可）
  • 廃棄理由は必須入力で、監査ログに記録されます。

スロットの回収/再割り当て機能がないと、障害復旧時にサービスが停止する可能性があります。

10. サーバースロット実行ルール（運用ポリシー）​

10.1 基本ルール​

  • サーバースロットは登録されたサーバー数に基づいて強制
  • 登録サーバー数が許可Nを超えた場合
    • 新規登録リクエストは失敗しました
    • 未登録サーバー呼び出しはブロックされます

10.2 サーバースロット超過時エラーメッセージ​

슬롯 초과 시 신규 등록은 실패합니다.
서버 슬롯 초과: 허용 N대 / 등록 M대

10.3 例外/運用ケース​

  • 緊急障害復旧
    • (オプション) 24h/72h 一時スロット（期間限定）提供
  • VMの複製/イメージ配布
    • 指紋が同じでも、秘密鍵/証明書が異なれば別のサーバーで処理可能
  • オフライン/クローズドネットワーク
    • オンラインコンソールアクセス制限時のオフライン登録手続きが必要です

オフライン登録（ファイルベース）例​

  1. サーバーがCSRファイルを生成/エクスポートします
  2. 管理者がコンソールでCSRをアップロードした後に承認
  3. 承認結果（証明書/登録トークン）をダウンロードしてサーバーに反映
  • 承認時のサーバースロット消費ロジックは同じです。

※ クローズドネットワーク顧客サポートのための選択機能であり、初期範囲は後日確定します。

11. ウェブコンソール設計草案​

※ 統合ウェブコンソールでは、「サーバー管理」メニューはApp環境でのみ条件付きで提供されます。 （Container環境ではサーバーの概念がありません。）

11.1 メニュー構造（例）​

  • ライセンス
    • ライセンス状態（識別子/サーバースロット）
    • 識別子管理
  • サーバー管理(App専用メニュー)
    • サーバー登録リクエスト
    • 登録サーバー一覧
    • サーバー廃棄履歴（監査）

11.2 画面 1) ライセンス状態カード​

  • 許可された識別子: 3
  • 使用識別子: X
  • 許可されたサーバースロット: N
  • 登録サーバー: M
  • 残りスロット: N - M
  • 有効期限情報: ライセンスの有効期限

※ Identifier Slotは顧客基準で統合適用され、Server SlotはApp環境でのみ追加実行されます。

11.3 画面 2) サーバー登録リクエスト（承認ワークフロー）​

テーブルカラム（例）

  • リクエスト時間
  • サーバーラベル（管理者用名前）
  • CSRの要約（指紋/公開鍵ハッシュ）
  • リクエスター（サーバーが提示した情報）
  • 承認状態（待機/承認/拒否）
  • 処理者/処理時間
  • 備考（理由）

ボタン/動作

  • 承認（スロット減少）
  • 拒否（理由必須）
  • 再送信リクエスト（オプション）

11.4 画面 3) 登録サーバー一覧​

テーブルカラム（例）

  • サーバーラベル
  • 状態（正常/未接続/期限切れ間近/ブロック）
  • 最近の接続(Heartbeat)
  • 証明書の有効期限
  • アプリバージョン
  • 登録日
  • 最後のエラー（オプション）

アクション

  • 廃棄(De-register)
  • 証明書の更新案内（オプション）
  • 詳細表示（サーバー情報/ログ）

11.5 状態定義​

  • 正常: Heartbeat 正常 + 証明書 有効
  • 未接続: Heartbeat 未受信(閾値超過)
  • 期限切れ間近: 証明書の有効期限 D-n
  • ブロック: 廃棄/ポリシーブロック/誤検知防止ブロック

12. 監査(Audit) ログ​

12.1 ログイベント​

  • サーバー登録リクエストの作成
  • 登録承認/拒否
  • サーバー廃棄
  • サーバー再登録
  • 未登録サーバー呼び出しのブロック
  • 証明書の期限切れ/期限切れ間近の通知（オプション）

12.2 監査ログの例フィールド​

  • actor(管理者/システム)
  • action(REGISTER_APPROVE, DEREGISTER, CALL_BLOCKED…)
  • target(serverId)
  • reason(廃棄理由/拒否理由)
  • timestamp
  • metadata(公開鍵ハッシュ、証明書の有効期限、ipListなど)

13. サーバー識別候補群の比較 (参考)​

  • 単一の値1つで完璧な識別は難しく、実行はキーに基づく検証で行い、指紋は補助的に使用される。
候補群概念（簡単に）利点欠点/リスク推奨用途
IPネットワークアドレス実装が簡単変更/共有/バイパス可能、サーバーの代表性が低い非推奨
MACNIC 物理アドレス理論上唯一マルチ/仮想NIC、スプーフィング、Java取得不安定非推奨（単独実行 X）
Hostname機器名見やすさ重複/変更が容易補助
OS machine-idOS ローカル固有 ID比較的安定画像の複製時の重複リスク補助（ハッシュ推奨）
SMBIOS UUIDBIOS/ファームウェア UUID物理サーバーは比較的安定VMの移動/コピー/設定に変更可能補助
Disk Serialディスクシリアル番号比較的固定交換/RAID/仮想ディスクが不安定補助
CPU/Board SerialHW シリアル番号物理サーバーの固定が可能未記入/重複/VMでの意味が弱い補助
mTLS(クライアント証明書)秘密鍵で「登録サーバー」を証明安定的な執行、スプーフィングの難易度↑証明書の運用（発行/廃止）が必要推奨（実行の核心）
TPM バインディング（オプション）TPMによるキー保護/証明キー複製防止強化TPMなしのサーバーの存在可能性選択（強化オプション）

14. 結論​

  • アプリ環境は識別子ベースの運用を維持しながら、サーバー数の制限が必要です。
  • サーバースロットベースの登録実行モデルを導入
  • IP/MACに基づく不安定性を排除し、運用/監査/復旧体制を含む

15.関連文書​

  • SDF識別子に基づく運用モデル:リンク
  • SDFハイブリッド運用モデル:リンク
  • SDFコンテナ運用モデル:リンク