SDF Container Operating Model
| Author | Date | Change log |
|---|---|---|
| Joseonwoo | 2026-02-02 | First Draft |
1. Purpose
This document is about SDF (Sensitive Docs Flow)**Container Environment (Based on Kubernetes Pod)**Defines the menu structure and configuration flow of the web console for operation.
In a container environment, SDF has the following characteristics.
- There is no concept of a server.
- API call authentication is**Access Key (AK)**It is performed as.
- Operational and Tracking Criteria areIdentifierIt will be integrated around.
- **The license key limits the number of identifiable registrations (slots).**It is applied in the following way.
- In a container environment, by default, 1 license per container is required.Three Identifiersis provided, and the operator must configure the work units within the allowed range of identifiers.
※ The hybrid operation criteria are defined in the upper document (SDF Hybrid Operation Model), and this document describes the operation/console configuration limited to the Container environment.
2. Assumptions for Operating Container Environments
2.1 Excluding Server Management
In a container environment, Pods are auto-scaled, making fixed server unit management impossible.
Therefore, the following features are not provided in the web console.
- Server Registration/Deletion/Status Management
- Server Slot Execution and Server Registration Function (App Only)
2.2 Core Elements of Operation
,
The key elements necessary for operation in a container environment are as follows.
| element | Purpose |
|---|---|
| License Key | Activation of service usage scope and granting of identifier registration limit (default 3 provided) |
| Identifier | Work Unit Classification (Policy/Log/Tracking/Billing Criteria) |
| Access Key (AK) | API Call Subject Authentication |
| Business System | Logical Call System Registration (Optional) |
| Integration Service (Document Security) | Integration with External Systems for Document Encryption and Decryption |
In a container environment, billing is not applied on a per-server basis, and licenses are operated based on the number of identifiable registrations.
- For example, when registering 1 basic licenseThree IdentifiersIt is possible to create and operate up to __PH_0__.
※ The licensing enforcement criteria for the container environment is the identifier slot, and the business system/integration service items are operational convenience features.
3. Web Console Menu Structure (IA)
The container environment web console provides the following top-level menus.
홈
조건부 정책
로그
설정
The settings menu is organized as follows based on the operational flow.
설정
├ 라이선스 키 관리
├ API 연동 설정 ← (통합 진입점)
│ ├ 식별자 관리 (업무 단위)
│ └ 액세스 키(AK) 관리 (호출 인증)
├ 업무 시스템 관리
├ 연동 서비스 관리(Document Security)
└ 관리자/권한 관리
Menu Composition Principles
- The identifier and access key (AK) are always used together in API requests, but since they have different roles, the operational concepts are separated.
- However, for user convenience, the web console provides a unified "API Integration Settings" menu, which is managed in a tab format within the screen.
※ In a container environment, there is no concept of a server, so the "Server Management" menu is not provided.
4. Configuration Flow
In a container environment, the administrator completes the setup in the following order before operating SDF. The operational standards of the container environment are structured around "Identifier + Access Key (AK)".
4.1 Configuration Order
1) 라이선스 키 등록
- 식별자 등록 가능 개수(기본 3개)가 활성화됩니다.
2) API 연동 설정
2-1) 식별자 생성 (업무 단위 생성)
2-2) 액세스 키(AK) 발급 (API 호출 인증키 준비)
3) 업무 시스템 등록(선택)
- SDF를 호출하는 논리적 시스템 정보를 관리합니다.
- 업무 시스템은 반드시 특정 식별자와 연결됩니다.
4) 연동 서비스 설정
- 문서 암·복호화를 수행하는 외부 보안 서버(SCI)를 등록합니다.
- 연결 테스트를 통해 정상 연동 여부를 확인합니다.
5) 조건부 정책 설정 및 운영 시작
- 식별자 단위로 업무별 정책을 적용합니다.
6) 로그 모니터링 및 감사 대응
- 식별자 기반 로그를 통해 운영 상태를 추적합니다.
4.2 Operating Principles
- The identifier and access key (AK) are always used together in API requests.
- The license limits the number of identifiers that can be generated.
- The settings menu is designed to guide the user through the process in the order specified above.
4.3 Initial Setup Wizard (Design Review)
The web console provides a checklist format for users to sequentially configure based on the above setup order. Each step indicates whether it is completed, and clicking on it will take you directly to the corresponding setup screen.
example
[SDF 초기 설정 진행]
1. 라이선스 키 등록 완료
→ 이동: 설정 > 라이선스 키 관리
2. 식별자 생성 미완료
→ 이동: 설정 > API 연동 설정 > 식별자 탭
3. 액세스 키(AK) 발급 미완료
→ 이동: 설정 > API 연동 설정 > 액세스 키(AK) 탭
4. 연동 서비스 연결 설정 완료
→ 이동: 설정 > 연동 서비스 관리(Document Security)
5. 조건부 정책 적용 (활성 정책 ≥ 1 필요)
활성 3개 / 전체 7개 완료
→ 이동: 조건부 정책 메뉴
-------------------------------------------------
→ 다음 단계: 식별자를 생성해 주세요.
[설정 > API 연동 설정 > 식별자 탭으로 이동]
5. Screen Composition
5.1 Home (Dashboard)
Purpose
The home (dashboard) is the screen where the operator first checks the SDF status. At the top of the dashboard, core operational information is summarized in the form of 6 cards/charts.
Top Filter Configuration
The dashboard provides a period filter that is identical to the attached UI. Operators can quickly switch the period unit to check trends.
[기간 선택]
6H / 1W / 1M + 날짜 범위 선택(Calendar)
기본값: 최근 6시간(6H)
Card 1. Identifier Usage
Displays the current usage compared to the allowed identifier slots with the license key.
example
- Allowed identifiers: 3
- Identifiers in use: 2
- Remaining slots: 1
UI Configuration
- Progress Bar
- Warning Notification for Slot Overrun
Card 2. License Information
Summarizes the current license status.
The operator can proactively check for license overage risks through this card.
Display Item (Example)
- Plan Name (Basic/Standard/Enterprise)
- Number of Allowed Identifiers
- License expiration date (if applicable)
- Status (Normal/Expiring/Expired)
Card 3. Recent Processing Count
Summarizes the document processing count for the selected period.
Display Item
- Total number of transactions
- Success Count / Failure Count
- Failure Rate (%)
- Separate period selection filter (1h / 24h / 7d)
※ The analysis of failure causes is provided in a separate "Top 5 Error Types" widget.
Card 4. Document Processing Event Handling Status
Displays the number of document events processed over time.
Example Event (Review Needed)
- DRM Encryption
- AIP Encryption
- Decryption
- Export
UI Type
- Trends Based on Bar/Line Charts
Card 5. File Type Top5
Summarize the processed file extension types into Top 5.
Example (same as SHIELD Mail)
- Docx / Xlsx / PDF / PPT / Doc
Card 6. Top 5 Error Types
We provide the Top 5 error types so that the operator can immediately identify the cause of the failure.
example
- Call authentication failed (access key error)
- Integration Failure (SCI Connection Failure)
- Policy Discrepancy
- Missing Identifier Request
- Other system errors
※ In a container environment, server slot related cards/indicators are not displayed.
5.2 Conditional Policy (To-Be)
- Planned redesign of identifier-based new conditional policy structure and UI
- The design file only shows the menu.
- Conditional policies are applied based on identifiers rather than the execution environment.
5.3 Log (To-Be)
- Identifier-based log structure and UI redesign planned
- The design file only shows the menu.
- Log tracking is also integrated and operated at the identifier level.
6. Settings Menu Details
The settings menu provides core management functions for SDF operations. In a container environment, there is no concept of a server, so the settings are organized around the following elements.
- License Key Based Identifier Slot Operation
- API Integration Settings (Identifier + Access Key)
- Registering a Business System (Optional)
- Document Encryption/Decryption Integration Service Management
- Management of Administrator Permissions (RBAC)
6.1 License Key Management
Purpose
License key management is the initial setup step that activates the operational scope in the SDF container environment.
In a container environment, there is no server-based license, and the license key is applied based on the number of identifiable registrations (slots).
- Provides 3 basic identifiers per license
- The identifier slot must be activated for subsequent settings (API integration, policies) to be possible.
In a container environment, there is no execution of server slots, and the server slot item is displayed as inactive (app-only) on the license screen.
Operating Concepts
The license key performs the following roles.
- Activate SDF Service Availability Status
- Number of Identifiers That Can Be Generated (Slots)
- Completion conditions for Step 1 of the Wizard Progression
In other words, before registering the license key, it is not possible to set the identifier / access key / policy.
Screen Composition
The license key management screen isStatus Summary Area + Key Registration Areais composed of.
1. License Status Summary Card
It is displayed at the top so that the operator can immediately grasp the current license status.
Display Item (Example)
- Plan Name: Basic
- Allowed identifiers: 3
- Identifiers in use: 2
- Remaining slots: 1
- Status: Normal
UX Points
- The identifier slot is always clearly displayed as a number.
- Highlight in warning color when the remaining slots are 0.
2. License Key Registration Area
Activate the service usage scope by entering the license key.
Components
- License Key Input Field
- [Register] button
Operation Flow
라이선스 키 입력
→ 등록 버튼 클릭
→ 키 검증
→ 식별자 슬롯 활성화
→ 상태 카드 갱신
→ 위저드 Step 1 완료 처리
User Action
- License Key Registration
- Check License Status (Active/Expired)
※ The license key cannot be modified after registration, and if changes are necessary, it will be processed by registering a new key.
Wizard Integration
License key registration is done through the wizard'sStep 1 Completion Criteriais.
[초기 설정 진행]
1. 라이선스 키 등록 완료
→ 이동: 설정 > 라이선스 키 관리
Once the license key is successfully registered, the next step (identifier generation) will be activated.
Validation and Exception Handling
The following validation is performed when registering the license key.
- Key format error
- Already used key
- Expired Key
- Attempt to register as an unauthorized user
UX Principles in Case of Failure
- Provide clear wording for the reason for failure
- Identifier slot is not activated.
- The wizard step is not completed.
6.2 API Integration Settings (Identifier / Access Key Management)
API integration settings are a key configuration area for SDF operations. Operators can create business unit identifiers and issue access keys (AK), which are the means of authentication for API calls, in this menu. The identifier and access key (AK) are always used together in API requests, but their roles are different, so the concepts are separated. However, for user convenience, the web console provides a unified "API integration settings" menu, managing them in a tab format within the screen.
Screen Layout (Tab Structure)
설정 > API 연동 설정
[ 식별자 관리 ] [ 액세스 키(AK) 관리 ]
- Identifier Tab: Creating Operational Standards for Work Units
- Access Key Tab: Issuance and Control of API Call Authentication Keys
※ The identifier is the central unit of SDF operations, and operators must create identifiers by business unit.
Screen Composition
1. Identifier Usage Summary Card
Displays usage compared to slots granted by the license key. When the slots reach 0, the identifier generation button will be disabled.
example
- Allowed identifiers: 3
- Identifiers in use: 2
- Remaining slots: 1
2. Identifier List Table
| item | Description |
|---|---|
| Display Name | Task name entered by the user |
| Creation Date | Identifier creation time |
| status | Active/Inactive |
| Recent call time | Last API request time |
3. Identifier Generation Button
- Clicking the [Generate Identifier] button provides a creation modal.
Identifier Generation Flow
[식별자 생성 버튼 클릭]
→ 표시명 입력(필수)
→ 설명(선택)
→ 생성 요청(필수)
→ 시스템이 Identifier Code 자동 생성
→ 목록 반영
Control Policy
- Cannot create when exceeding allowed slots
- Error Notification for Duplicate Display Names
- Deletion is restricted (to prevent disruption of operational tracking)
6.2.2 Access Key (AK) Management Tab
Purpose
An access key (AK) is a means of authenticating SDF API calls.
- Proving "Who called?"
- It is essential when an external business system calls the SDF.
- It is managed separately from the scope of the license.
Screen Composition
The access key management screen is composed of the following areas.
1. Access Key List Table
| item | Description |
|---|---|
| Key Name | Separator name specified by the operator |
| Issue Date | Key creation time |
| status | Activate/Deactivate |
| Last Used Time | Recent call time |
| Management Features | Copy/Reissue/Stop |
2. Key Issuance Button
- Clicking the [Key Issuance] button generates a new key.
3. Key Issuance Flow
[키 발급 버튼 클릭]
→ 키 이름 입력(필수)
→ 설명(섵택)
→ 발급 완료
→ 최초 1회 원문 표시
→ 이후 마스킹 처리
Security Policy (Required)
The access key is a Secret value, so the following policy is applied.
- Basic Screen Display: Masking Processing
- View and reissue original text: Only Super Admin can do this.
- Copy Function: Allowed for Org Admin and above
- Immediate revocation of the existing key upon reissuance
- Query/Copy/Res issuance is subject to audit log records.
Definition of Key Actions
| Action | Description |
|---|---|
| copy | Copyable without unmasking (permission required) |
| stop | Disable key to block calls |
| Reissue | Issuance of New Key After Discarding Existing Key |
| delete | In principle, not provided (to prevent tracking discontinuity) |
6.2.3 Identifier + Access Key Operational Relationship
SDF API requests must always include the following two values together.
Access Key(AK) : 호출 주체 인증
Identifier : 업무 구분 기준
- If there is no access key (AK), the call will be blocked.
- If there is no identifier, the policy/log/billing criteria cannot be established, so the request is not allowed.
6.2.4 Summary of Operational UX Points
- Identifier = Business Unit Operation Standards
- Access Key (AK) = Call Authentication Method
- They are always used together, and in the web console, they are managed as tabs within a single menu.
- Identifier generation must be completed for policy/log operation to be possible.
6.3 Business System Management (Formerly Integration App Management)
Business system management registers external systems that call the SDF API and the systems that will use it.Access Key (AK)WowIdentifierIt is a feature that manages together.
The business system means the following in SDF operations.
- Caller (electronic approval, ERP, etc.)
- API Authentication (AK) Unit
- Work Classification (Identifier) Unit
Key Changes
In the existing integration app registration screen, the key was issued under the name "License Key," but in the SDF structure, that value is**Access Key (AK)**performs a role.
In the future, it is essential to register the work system for the purpose of distinguishing work units.Identifier Selection OptionsThis will be added.
Screen Composition
1. Integration App Registration Modal
Expand the input fields while maintaining the existing screen structure.
| item | Required 여부 | Description |
|---|---|---|
| Linked App Name | required | Call System Name |
| Integration App URL | required | API Call Endpoint |
| Identifier Selection | required | Work Unit Classification Value |
| Usage status | required | Active/Inactive |
| Integration App Description | Selection | Operating Memo |
Newly Added Item: Identifier Selection
- The business system must be attributed to a single identifier.
- API calls without an identifier are not allowed.
example
식별자 선택 ▼
- 전자 결재
- 승인반출
- 외부협업
Check Integration Information (Key Issuance)
When the integration app registration is complete, the system will**Access Key (AK)**issues a license. The area previously labeled as "License Key" in the existing UI will be clearly changed as follows.
Integration Information Confirmation Popup
업무 시스템 등록이 완료되었습니다.
발급된 액세스 키(AK)를 복사하여 별도 저장해 주세요.
(최초 1회만 확인 가능합니다)
Access Key(AK): B367-C3199-F66A-574C4
[복사]
※ You cannot use the SDF API without integration information.
6.4 Integration Service Management
Integration service management is a configuration feature that registers the document encryption and decryption server (SCI) and checks the connection status. This feature is the same as the existing SHIELD DRM's Document Security integration method, and the screen is also the same.
6.5 Administrator / Permission Management (RBAC)
6.5.1 Purpose
Admin/Permission management in the SDF container environment
Maintaining a Secure Identifier-Based Operating ModelThis is a role-based access control (RBAC) feature for achieving.
Operators are granted varying levels of access to settings, policies, logs, and licenses based on their roles.
6.5.2 Permission Design Principles
- All rights areRoleIt is granted based on the criteria.
- Roles are assigned at the user account level.
- In a container environment, there are no server management privileges.
- Identifier creation/management permissions are granted restrictively to prevent abuse.
6.5.3 Basic Role Definition
| role | Description |
|---|---|
| Super Admin | SDF Service Overall Operations Manager |
| Organization Administrator (Org Admin) | Operations Manager |
| Auditor | Users for Inquiry and Audit Only |
| Maintenance Manager | User for Fault Analysis and Technical Support |
6.5.4 Role-based Permission Scope
Comparison Table by Permission Type
| division | Master Administrator | Operations Manager | Query Manager | Maintenance Manager |
|---|---|---|---|---|
| SDF Full Configuration | O | X | X | X |
| License Key Management | O | X | X | X |
| Identifier Creation/Deletion | O | X | X | △ (Query) |
| Identifier Lookup | O | O | O | O |
| Access Key (AK) Management | O | O(state/copy) | X | △ (Query) |
| Business System Management | O | O(Scope of Responsibility) | X | X |
| Conditional Policy Management | O | O(Responsible Identifier) | X | △ (Query) |
| Log Inquiry | O | O(Person in Charge Identifier) | O | O |
| Log/Dashboard Export | O | O | X | O |
| Integration Service (Document Security) | O | O | X | △ (Query) |
| Admin Account Management | O | X | X | X |
※ △ : View only
※ There are no server management permissions in the container environment.
Identifier-based permission application
Permissions are not just for simple menu access,Identifier Scopewill be applied together.
example
- The operations manager is only responsible for the identifiers assigned to them.
- Policy Settings
- Log Inquiry
- Dashboard available
- The query manager can only view all identifiers.
Administrator Account Management Features
Administrators can perform the following functions.
- Registering/Deleting Administrator Accounts
- Role Assignment
- Setting Identifier Access Scope (Optional)
Required fields when creating an administrator account
- Account ID
- Role
- Access Identifier Scope (Optional)
Audit and Security Policy
The following actions are subject to audit log recording.
- License Key Lookup/Change
- Identifier Creation/Deletion
- Access Key (AK) View/Copy/Regenerate
- Change Administrator Permissions
Audit logs cannot be deleted separately and can only be viewed in the log menu.