Skip to main content

SDF APP Operating Model

AuthorDateChange log
Joseonwoo2026-02-03First Draft

1. Purpose​

The SDF App (On-Prem) environment has a clearly defined installation server, so it operates based on identifiers along with**Server Slot Limit (Server Slots)**Execution is required.

This document is not about "how to distinguish servers," but rather,How to 'enforce' server count limitsfocuses on.

In other words, instead of "variable values" like IP/MACProving 'registered server' with the key (secret key) owned by the serveraims for a structure that does.

  • per license 1 unit
    • Three identifiers provided by default
    • The app environment is**Limit on the number of allowed servers (server slots)**need
    • IP/MAC-based device identification has many failure cases and low reliability →**Key-based validation (only allows registration servers)**switch to

※ The hybrid operation criteria are defined in the upper document (SDF Hybrid Operation Model), and this document provides a detailed explanation of the server slot execution method added in the App (On-Prem) environment.

2. Definition of Operational Standards and Key Concepts​

2.1. Operating Standards​

SDF fundamentally follows an identifier-centric operational model.

In the app environment, server-level execution elements are added on top of the identifier operation structure.

  • In other words, the App environment is**Execution at both the business unit and server unit is required simultaneously.**does.
divisionContainer EnvironmentApp(On-Prem) Environment
Server ConceptNoneexists
Limit CriteriaLimit only the number of identifiersIdentifier + Server Slot Limit
Operating UnitWork Identifier CenteredWork Identifier + Installation Server

※ The common operational standards for Container/App are identifiers, and server slot execution is added only in the App environment.

2.2 Definition of Key Concepts​

ConceptMeaning
License KeyDetermining the number of identifiers + server slots
AK(Access Key)Caller Authentication Secret
IdentifierWork Unit (Policy/Log/Billing Criteria)
Server SlotMaximum number of App Servers that can be registered
  • example
    • Allowable 3 identifiers: The business system can operate with a maximum of 3 business units.
    • Allow up to 2 server slots: The App Server can only be installed/operated on a maximum of 2 units.

3. Server Slot Enforcement​

  • Registration: Registration is only allowed when there are remaining slots.
  • Call: Block Unregistered Server Requests
  • Operation: Registration/Disposal/Bypass Attempt Audit Log Recording

4. IP/MAC Limitations​

4.1 Limitations of IP-based Systems​

  • IP can be changed/shared through network configuration (DHCP/NAT/reassignment, etc.)
  • Difficult to represent the server, unsuitable for enforcing server count limits.
  • IP is closer to "current network location" rather than server identity → inaccurate for server instance execution (limit of 2/3 instances).

**Conclusion:**The method of registering servers based solely on IP carries a high operational risk.

4.2 Limitations Based on MAC​

  • Multi-NIC servers can cause confusion due to having multiple MAC addresses.
  • The representative MAC may fluctuate in a virtual NIC/security solution/driver environment.
  • Unstable selection of OS interface in Java environment has led to numerous failure cases.
  • MAC may seem unique, but in virtual/multiple NIC environments, the selection of representative values is unstable and there is a possibility of spoofing.

**Conclusion:**The "Fixed representative value for 1 MAC" method has a high possibility of malfunction/failure.

5. Server Validation Design Principles (To-Be)​

5.1 Principles​

  • The server limit is not a "server guessing problem."Validation issue that only allows registered servers to pass
  • instead of identifying the server by value (IP/MAC),Server's Private KeyA reliable way to prove that "I am the registered server."
  • Therefore, switch to a Private Key-based verification structure instead of IP/MAC.
    • Key-based verification proves "Does the server possess the key (Proof of Possession)," making it resilient to changes in the network/environment.
  • Server Enrollment + Key-Based Proof of PossessionStructure
  • OS/Hardware fingerprinting is not executed independently.Auxiliary SignalRoman Utilization (Anomaly Detection/Replacement Confirmation)

That is, switching from Device Identification (value-based identification) to Device Verification (key-based verification).

6. Server Registration and Certificate-Based Execution Structure (Proposal)​

6.1 Why is "registration" necessary?​

To limit the number of servers, you need to specify "This server is an allowed server."Verifiable state valuethis need

IP/MAC can fluctuate, soProof with keys/certificates held only by registered servers

In other words, the server slot is not a "number".**Registration (Status) + Verification (Pass/Block)**must be executed with

6.2 Registration Stage Detailed Scenario​

To execute server slot allocation, the App Server performs an initial registration procedure once.

  1. Admin (Web Console) Registering License Key

    • Activate 3 Identifier slots
    • Activate N server slots

  2. App Server server registration request

    • Inside the App Server**Key pair (public key/private key)**Create
    • The private key must not be exposed externally (local secure storage)
    • Public Key Based**CSR (Certificate Signing Request)**Create

  3. Console/License Server Registration Approval

    • Check Remaining Server Slot Count
    • Save "Registration Complete" status upon approval
    • Consume 1 server slot (remaining -1)

  4. Certificate issuance/installation completed

    • After this, the server will prove itself with this certificate when making API calls.

6.3 Preventing Duplicate Installations (Operational Points)​

  • Server program/Even if you duplicate the imageIf there are no registered keys/certificates, unregistered serverblocked due to processing
  • Reinstallation/Replacement is controlled by re-registration
  • Consider options to increase the difficulty of private key duplication with (optional) TPM binding.

7. API Call Execution Steps (Per Request)​

API requests during operation are validated in the following order.

Verification Order​

  1. Check if it is a registration server
  2. AK Call Subject Authentication
  3. Work Unit Identifier License Scope Validation
  4. Policy Application and Document Conversion Processing
  5. Log Records

Server slot execution must be blocked at step 1 (Registration Server Verification). This is to fundamentally prevent unregistered servers from bypassing access keys/identifiers. Therefore, server verification (mTLS or signature verification) should be performed first at the API Gateway level.

  • server isClient Certificateprove yourself
  • The system determines whether to allow based on a comparison with the "registered certificate list."

(Signature) Signature-based Token Method​

In environments where mTLS is difficult (proxy/special networks), the following alternatives are also possible.

  • The server responds to the request.nonce + timestampinclude and sign with a private key
  • Verify the signature with the registered public key of the server/console
  • Need to store/expire nonce to prevent replay attacks

8. Operational Stability (Heartbeat)​

8.1 Purpose of Heartbeat​

  • The registration server periodically reports its status, and the console displays normal/disconnected/expiring soon status based on this.

8.2 Heartbeat Data (Example)​

  • serverId (Registration ID)
  • appVersion
  • lastSeenAt
  • certExpireAt
  • hostname (for display)
  • ipList/macList (Supplementary/Reference)
  • metrics(optional): throughput/error rate

9. Server Replacement/Reinstallation/Fault Recovery (Operational Essential)​

9.1 Procedure​

  • De-register
    • Revoke the server certificate (immediate block)
    • Recover 1 server slot (+1)
    • Reasons for Disposal/Operator/Time Log Required
  • Re-enroll
    • Perform registration procedure on the new server
    • Consume server slot again (-1)

9.2 Permissions/Policies (Operational Defense)​

  • Server DecommissioningAdministrator Privilegesonly available at
  • Block immediately upon disposal (not reusable)
  • Mandatory input for disposal reasons, recorded in the audit log.

If there is no slot recovery/reallocation feature, the service may stop during disaster recovery.

10. Server Slot Execution Rules (Operational Policy)​

10.1 Basic Rules​

  • server slot isForced based on the number of registered servers
  • When the number of registration servers exceeds N seconds
    • New registration request failed
    • Blocking of unregistered server calls

10.2 Server Slot Exceeded Error Message​

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

10.3 Exception/Operational Cases​

  • Emergency Disaster Recovery
    • (Optional) 24h/72h temporary slot (time-limited) provided
  • VM Cloning/Image Deployment
    • Even if the fingerprints are the same, if the private key/certificate is different, it can be processed on a different server.
  • Offline/Closed Network
    • Offline registration procedure required when online console access is restricted

Offline Registration (File-Based) Example​

  1. The server generates/exports the CSR file.
  2. Administrator approves CSR upload from the console.
  3. Download the approval result (certificate/registration token) and reflect it on the server.
  • The server slot consumption logic upon approval is the same.

※ This is an optional feature for closed network customer support, and the initial scope will be confirmed later.

11. Web Console Design Draft​

※ The "Server Management" menu is conditionally provided only in the App environment in the integrated web console. (There is no server concept in the Container environment.)

11.1 Menu Structure (Example)​

  • License
    • License Status (Identifier/Server Slot)
    • Identifier Management
  • Server Management (App Exclusive Menu)
    • Server Registration Request
    • Registered Server List
    • Server Disposal History (Audit)

11.2 Screen 1) License Status Card​

  • Allowed Identifier: 3
  • Usage Identifier: X
  • Allowed server slots: N
  • Registration Server: M
  • Remaining slots: N - M
  • Expiration Information: License Expiration Date

※ The Identifier Slot is applied uniformly based on the customer, while the Server Slot is only executed in the App environment.

11.3 Screen 2) Server Registration Request (Approval Workflow)​

Table Column (Example)

  • Request Time
  • Server Label (Admin Name)
  • CSR Summary (Fingerprint/Public Key Hash)
  • Requester (Information provided by the server)
  • Approval Status (Pending/Approved/Rejected)
  • Processor/Processing Time
  • Remarks (Reason)

Button/Action

  • Approval (Slot Deduction)
  • Rejection (Reason Required)
  • Resend Request (Option)

11.4 Screen 3) Registered Server List​

Table Column (Example)

  • Server Label
  • Status (Normal/Not Connected/Expiring Soon/Blocked)
  • Recent Access (Heartbeat)
  • Certificate Expiration Date
  • App Version
  • Registration Date
  • Last Error (Option)

Action

  • De-register
  • Certificate Renewal Guide (Optional)
  • View Details (Server Information/Logs)

11.5 State Definition​

  • Normal: Heartbeat Normal + Certificate Valid
  • Not Connected: Heartbeat Not Received (Threshold Exceeded)
  • Expiring Soon: Certificate Expiration D-n
  • Blocking: Disposal/Policy Blocking/Fraud Prevention Blocking

12. Audit Log​

12.1 Log Events​

  • Create Server Registration Request
  • Registration Approval/Denial
  • Server Decommissioning
  • Server Re-registration
  • Blocking Unregistered Server Calls
  • Certificate Expiration/Upcoming Expiration Notification (Optional)

12.2 Example Fields of Audit Log​

  • actor(Administrator/System)
  • action(REGISTER_APPROVE, DEREGISTER, CALL_BLOCKED…)
  • target(serverId)
  • reason(disposal reason/rejection reason)
  • timestamp
  • metadata(public key hash, certificate expiration date, ipList, etc.)

13. Comparison of Server Identification Candidates (Reference)​

  • Perfect identification with a single value is difficult, and execution is done through key-based verification while fingerprints are used as a supplement.
CandidatesConcept (Easy)AdvantagesDisadvantages/RisksRecommended Use
IPNetwork AddressEasy ImplementationChange/Share/Bypass possible, low server representativenessNot Recommended
MACNIC Physical Addresstheoretically uniqueMultiple/Virtual NIC, Spoofing, Java Acquisition InstabilityNot Recommended (Standalone Execution X)
HostnameEquipment NameEase of ViewingEasy Duplication/ModificationAssistance
OS machine-idOS Local Unique IDrelatively stableRisk of Duplication When Cloning ImagesAuxiliary (Hash Recommended)
SMBIOS UUIDBIOS/Firmware UUIDPhysical servers are relatively stableVM can be changed by moving/copying/configuring.Assistance
Disk SerialDisk Serial Numberrelatively fixedReplacement/RAID/Unstable with Virtual DiskAssistance
CPU/Board SerialHW Serial NumberPhysical server can be fixedUnfilled/Duplicate/Weak Meaning in VMAssistance
mTLS (Client Certificate)Proof of "Registration Server" with Secret KeyStable execution, increased spoofing difficultyCertificate Management (Issuance/Revocation) RequiredRecommended (Execution Core)
TPM Binding (Optional)Key Protection/Proof in TPMStrengthening Key Duplication PreventionPossibility of Servers Without TPMSelection (Enhancement Option)

14. Conclusion​

  • The app environment requires a limit on the number of servers while maintaining identifier-based operations.
  • Introduction of a server slot-based registration execution model
  • Eliminating IP/MAC-based instability and including operational/audit/recovery systems
  • SDF Identifier-based Operating Model:link
  • SDF Hybrid Operating Model:link
  • SDF Container Operating Model:link