본문으로 건너뛰기

SDF APP 운영 모델

작성자일자변경 내용
조선우2026-02-03최초 작성

1. 목적​

SDF App(On-Prem) 환경은 설치 서버가 명확히 존재하므로, 식별자 기반 운영과 함께 서버 수 제한(서버 슬롯) 집행이 필요합니다.

본 문서는 “서버를 어떻게 구별할 것인가”가 아니라, 서버 수 제한을 어떻게 ‘확실히 집행’할 것인가에 초점을 둡니다.

즉, IP/MAC 같은 “변동 가능한 값” 대신 서버가 소유한 키(비밀키)로 ‘등록된 서버임’을 증명하는 구조를 목표로 합니다.

  • 라이선스 1개당
    • 식별자 3개 기본 제공
    • App 환경은 허용 서버 수 제한(서버 슬롯) 필요
    • IP/MAC 기반 장비 식별은 실패 사례가 많아 신뢰성이 낮음 → 키 기반 검증(등록 서버만 허용) 으로 전환

※ Hybrid 운영 기준은 상위 문서(SDF Hybrid 운영 모델)에서 정의하며, 본 문서는 App(On-Prem) 환경에서 추가되는 서버 슬롯 집행 방식을 상세히 설명합니다.

2. 운영 기준 및 핵심 개념 정의​

2.1. 운영 기준​

SDF는 기본적으로 식별자 중심 운영 모델을 따릅니다.

App 환경에서는 식별자 운영 구조 위에 서버 단위 집행 요소가 추가됩니다.

  • 즉, App 환경은 업무 단위 + 서버 단위 집행이 동시에 필요합니다.
구분Container 환경App(On-Prem) 환경
서버 개념없음있음
제한 기준식별자 수만 제한식별자+ 서버 슬롯 제한
운영 단위업무 식별자 중심업무 식별자 + 설치 서버

※ Container/App 공통 운영 기준은 식별자이며, App 환경에서만 서버 슬롯 집행이 추가됩니다.

2.2 핵심 개념 정의​

개념의미
라이선스 키식별자 수 + 서버 슬롯 수 결정
AK(Access Key)호출 주체 인증 Secret
식별자업무 단위(정책/로그/과금 기준)
서버 슬롯등록 가능한 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 대신 Private Key 기반 검증 구조로 전환
    • 키 기반 검증은 “서버가 키를 소유하는가(Proof of Possession)”를 증명하므로 네트워크/환경 변화에 강함

5.2 권장 접근​

  • 서버 등록(Enrollment) + 키 기반 증명(Proof of Possession) 구조
  • OS/하드웨어 지문(Fingerprint)은 단독 집행이 아니라 보조 신호로만 활용(이상징후 탐지/교체 확인)

즉, Device Identification(값 기반 식별)이 아니라 Device Verification(키 기반 검증) 방식으로 전환

6. 서버 등록 및 인증서 기반 집행 구조(제안)​

6.1 왜 “등록”이 필요한가?​

서버 수 제한을 하려면 “이 서버는 허용된 서버다”라는 검증 가능한 상태값이 필요

IP/MAC은 흔들리므로, 등록된 서버만이 보유한 키/인증서로 증명

즉, 서버 슬롯은 “숫자”가 아니라 등록(상태) + 검증(통과/차단) 으로 집행되어야 함

6.2 등록 단계 상세 시나리오​

서버 슬롯 집행을 위해 App Server는 최초 1회 등록 절차를 수행

  1. 관리자(웹콘솔)가 라이선스 키 등록

    • Identifier 슬롯 3개 활성화
    • 서버 슬롯 N개 활성화

  2. App Server가 서버 등록 요청

    • 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 Heartbeat 목적​

  • 등록 서버는 주기적으로 상태를 보고하며 콘솔은 이를 기반으로 정상/미접속/만료임박 상태를 표시

8.2 Heartbeat 데이터(예시)​

  • serverId(등록 ID)
  • appVersion
  • lastSeenAt
  • certExpireAt
  • hostname(표시용)
  • ipList/macList(보조/참고용)
  • metrics(optional): 처리량/오류율

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) 라이선스 상태 카드​

  • 허용 Identifier: 3
  • 사용 Identifier: X
  • 허용 서버 슬롯: N
  • 등록 서버: M
  • 잔여 슬롯: N - M
  • 만료 정보: 라이선스 만료일

※ Identifier Slot은 고객 기준 통합 적용되며, Server Slot은 App 환경에서만 추가 집행됩니다.

11.3 화면 2) 서버 등록 요청(승인 워크플로)​

테이블 컬럼(예시)

  • 요청시간
  • 서버 라벨(관리자용 이름)
  • CSR 요약(지문/공개키 해시)
  • 요청자(서버가 제시한 정보)
  • 승인 상태(대기/승인/거절)
  • 처리자/처리시간
  • 비고(사유)

버튼/동작

  • 승인(슬롯 차감)
  • 거절(사유 필수)
  • 재전송 요청(옵션)

11.4 화면 3) 등록 서버 목록​

테이블 컬럼(예시)

  • 서버 라벨
  • 상태(정상/미접속/만료임박/차단)
  • 최근 접속(Heartbeat)
  • 인증서 만료일
  • App 버전
  • 등록일
  • 마지막 에러(옵션)

액션

  • 폐기(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. 결론​

  • App 환경은 식별자 기반 운영을 유지하면서 서버 수 제한이 필요
  • 서버 슬롯 기반 등록 집행 모델을 도입
  • IP/MAC 기반 불안정성을 제거하고 운영/감사/복구 체계를 포함

15.관련 문서​

  • SDF Identifier 기반 운영 모델: 링크
  • SDF Hybrid 운영 모델: 링크
  • SDF Container 운영 모델: 링크