SDP Specification 2.0

 

SDP Specification 2.0 은 CSA(Cloud Security Aliance)에서 발표한 문서로

SDP(Software-Defined-Perimeter)의 아키텍처, 구성 요소, 보안 모델, 구현 방식 등을 체계적으로 정의한 표준 가이드라인 이다. (네트워크 보안을 위한 새로운 접근 방식)

 

출처: SDP_Architecture_Guide

 

SDP를 도입하고자 하는 기업이나 기관이 제로 트러스트 보안 모델을 효과적으로 구현할 수 있도록 구체적인 참조 모델을 제공한다.

 

공식 문서 개요

• 문서명: Software Defined Perimeter (SDP) Specifacation v2.0
• 발행기관: Cloud Security Alliance(CSA) https://cloudsecurityalliance.org/
• 버전: 2.0

 

핵심 목적

• 기존의 경계 기반 보안(Perimeter-based Security)의 한계를 극복
• 제로 트러스트기반으로 접속 제어 및 리소스 은폐 구현
• 클라우드, 하이브리드, 원격 환경에서도 안전한 접근 보장

즉 정보 보호 대상을 외부에 공개하지 않고 접근 전 인증과 암호화를 통해 접근 제어와 데이터 통신을 분리하여 잠재적인 공격을 차단하는 방식

 

 

아키텍처 구성 요소

1. IH (Initiating Host)

• 클라이언트 역할을 하며 SDP에 접근을 시도하는 사용자 혹은 시스템
• Agent가 탑재되어 있음
• 인증/인가 요청 수행

 

2. PEP (Policy Enforcement Point)

• 접근을 실제 허용하거나 거부하는 게이트웨이 또는 프록시 역할
• 사용자의 요청이 인가되었을 경우에만 리소스에 연결 허용

 

3. PDP (Policy Decision Point)

• 정책을 기반으로 접근 허용 여부를 판단
• 다양한 정보를 바탕으로 접근 제어 정책 평가
• 사용자 ID, 단말기 상태, 위치, 위험도 등

 

4. Controller

• SDP 구성 요소의 중추, 정책관리 + 세션제어 담당
• 인증, 정책 분배, 세션 제어 등의 역할 수행
• 외부 연동 (IdP, SIEM, NAC 등) 지원

 

 

주요 보안 흐름

1. IH => Controller 로 인증 요청
2. Controller => PDP와 연동하여 정책 평가
3. 승인 시 Controller => PEP로 세션 허용 지시
4. IH는 PEP를 통해 실제 리소스에 접근

인증 이전에는 리소스 주소 자체가 보이지 않음 (Stealth)

인증 후에도 세분화된 권한 기반으로 최소 권한의 접근만 허용

 

조금 더 쉽게 설명하면

1. 인증: 네트워크에 접근하려는 사용자나 기기가 정말로 자신이 주장하는 그 사람 또는 그 기기가 맞는지 확인 (이름/비밀번호, 생체인식, 이중인증, 인증서기반인증 등) , SDP 는 단순히 하나의 인증 방법만 사용하는 것이 아니라 여러 인증 방법을 조합해서 사용할 수 있음. (MFA)
2. 인가: 인증된 사용자나 기기가 어떤 리소스에 접근할 수 있는지 결정하는 과정으로 사용자의 역할이나 직책, 접속위치, 접속시간, 사용중인 기기의 종류와 상태, 소속된 부서나 팀등을 고려해서 결정
3. 연결: SDP가 동적으로 1:1 네트워크 연결을 생성함, 연결은 필요한 순간에만 생성하고, 사용이 끝나면 즉시 종료, 오직 허가된 리소스에만 연결할 수 있고 다른 네트워크 부분은 완전히 숨김, 연결 자체가 암호화 되어 있어서 중간에 가로채기가 거의 불가능

 

 

SDP Specification 2.0 의 주요 내용 요약

항목	설명
제로 트러스트 기반	기본적으로 아무것도 신뢰하지 않는다 는 원칙 하에 설계
동적 접근 제어	상황 기반(사용자, 디바이스, 위치, 시간 등) 정책 허용
리소스 은폐	네트워크 스캔이나 포트 스캐닝으로도 리소스 노출되지 않음
다단계 인증	mTLS, X.509인증서, SAML/OAuth 기반의 인증 구성
분산 아키텍처	PEP는 각 리소스 가까이에 설치 가능 => 확장성 우수
통합 로그 및 모니터링	SIEM 연계하여 보안 이벤트 중앙화 가능
기존 보안 시스템 연계	NAC, CASB, DLP, VPN 등과 병행 또는 대체 가능

 

구현 예시

• Google BeyondCorp: SDP 철학을 가장 먼저 제품화한 사례
• Zscaler Private Access (ZPA): 클라우드 기반 SDP 구현
• AppGate SDP: 온프레미스와 클라우드 혼합 환경 지원

 

 

비즈니스 관점에서의 장점

보안 강화	리소스 은폐 + 사용자 중심 인증 방식
운영 효율성	사용자 위치와 관계없이 일관된 보안 적용 가능
확장성	온프레미스 + 클라우드 + 하이브리드 환경 대응
VPN 대체	사용자 경험 개선 (속도, 보안, UX 측면)

 

전통적인 접근제어와의 비교

핵심 비교	전통적인 접근제어	SDP
중심 철학	경계보안 + 강력한 추적	제로트러스트 + 은폐와 인증 중심 제어
강점	내부망 통제, 명령어 감사, 행위 추적	외부 접근 통제, 동적 정책, 확장성
한계	외부 위협, 클라우드/모바일 환경 대응에 제약	내부 행위 추적이나 명령어 감사 미비

이상적인 방향은 두 체계를 융합하여 '내부통제 + 외부보안' 을 모두 강화하는 하이브리드 보안 모델 구축이다.

 

더 자세히 정리해 보자.

구분	전통적인 접근제어	SDP
보안 철학	경계기반	제로트러스트
적용 대상	서버, DB, 시스템 계정 등 내부 리소스	사용자, 디바이스, 위치, 컨텍스트 등 전방위
접근 방식	ID+Password, OTP등 인증 후 서버 접근 통제	인증 전에 리소스 자체를 은폐, 인증 후 세분화 된 접근 허용
구성 요소	GW, Agent, Manager, 정책서버등	IH, Controller, PDP, PEP 등
세션 추적	세션기반 명령어 로그, 동작 기록	리소스 접근에 대한 제어 + 동적 정책 기반 세션 허용
사용자식별	AD/LDAP 연동, 내부 계정 인증 기반	mTLS, X.509, SAML, OAuth 등 다양한 표준 프로토콜 인증 지원
정책 모델	Role 기반 접근 제어 (RBAC)	속성 기반 접근제어(ABAC), 위험기반 인증
주 환경	온프레미스 서버 환경, 행정망/내부망 등 폐쇄망	클라우드, 하이브리드, 재택/원격 근무 환경 포함한 개방형 구조
위협대응력	명령어 단위 로깅 제어	접근 시도 자체를 차단하거나 은폐, 네트워크 스캔 불가

1. 보안철학

• 사실 전통적인 접근제어도 제로트러스트를 기반으로 하고 있긴 한데 전통적인 접근제어 방식은 인증 후 최소 권한만 부여하는 제로트러스트 기반이라면 CSA에서 정의하는 SDP모델은 더 네트워크 중심적 제로트러스트로서 '리소스 존재 자체를 노출하지 않는다' 는 은폐개념을 강조한다.

 

2. 적용대상

• 전통: 사용자 A가 root 계정으로 B서버에 접근하려 할 때 허용 여부 판단
• SDP: 이 사용자가 신뢰된 기기에서 근무시간에 저위험 세션으로 접근하는가를 평가
• 즉, 적용 범위의 확장성과 속성기반 접근 시나리오 수용 범위에서 차이가 있다.

 

3. 접근 방식

• 전통: 사용자가 인증되면 자신이 접근할 수 있는 타겟 서버 목록이 UI에 노출됨
• SDP: 인증 전에는 네트워크 포트 레벨에서 리소스 존재 자체가 숨겨짐
  • 포트 스캔 시에도 응답이 없고, 방화벽에서 차단하는 것이 아님 => '존재하지 않는 것 처럼 보임'
  • SDP는 네트워크 계층에서부터 은폐하여 심지어 인증되지 않으면 포트/서버 자체가 존재하지 않게 보임 (전통적인 ACL이나 방화벽 정책 이상의 은폐 기술 - Single Packet Authorization을 포함함)

 

4. 구성 요소

• 이름은 다르지만 역할은 유사하다. 그러나 SDP는 기능 분리 및 표준 프로토콜 기반 통신이라는 것이 핵심이다. SDP의 Controller 는 OpenID Connect, OAuth2, SAML 등과 통합 가능성이 높고 정책 서버와 동적 연계한다.

 

5. 세션 추적

• 전통: 세션 단위 추적 시 로그인부터 로그아웃, 명령어 추적
  • 명령어 레벨 감사 가능
  • 주 목적: 운영자 통제, 기록 남기기
• SDP: 접근 흐름 추적은 가능하나, 세부 명령어 로깅은 목적이 아님
  • Application 수준 감사는 연계 필요
  • 주 목적: 접속 경로 최소화 및 동적 제어
• 즉, SDP는 접근제어가 목적이고 전통 방식은 접근 제어 + 접근 후 활동의 통제와 감시

 

 

6. 사용자 식별 - 인증 프로토콜 다양성

• 전통: ID+PW, SAML, OAuth2, AD/LDAP 등의 인증 지원
• SDP: 다양한 인증을 조합하고 정책에 동적으로 반영 (ex. device trust + location + mTLS + SSL 조합)
• 즉, ID 기반 인증에서 신뢰도 기반 인증으로 확장되는 것의 차이

 

7. 정책 모델

• ABAC(Attribute-Based Access Control) = 속성 기반 접근 제어
• 정책조건:
  - 사용자 속성: "조직 = 보안팀", "직급 = 과장", "휴대폰 인증됨"
  - 리소스 속성: "DB서벗 = 운영계", "데이터 유형 = 민감정보"
  - 환경 속성: "시간 = 업무시간", "위치 = 내부망"
• 정책:
  - 위 조건을 만족할 경우에만 특정 리소스 접근 허용

• 실사용 속성 예시
  • 사용자 속성: ID, 부서, 직급, 인증 수단
  • 디바이스 속성: OS, 패치 상태, mTLS 인증 여부
  • 네트워크 속성: IP, 지리위치, VPN 여부
  • 리소스 속성: 민감도, 운영계/개발계 구분
  • 세션 속성: 접속 시간, 세션 위험 점수
• ABAC은 정책 조건이 다양하고 동적이기 때문에 자동화된 정책 생성 및 업데이트에 적합함

 

8. 주 사용 환경

• 전통: VPN + Agent 설치 후 내부망 자산 접근
• SDP: 인터넷 환경에서도 안전하게 인증 후 특정 SaaS나 API 리소스에만 접근
• 전통적인 방식도 클라우드 등을 지원하지만 SDP는 기본 설계부터가 인터넷 기반 사용자를 대상으로 만들어짐, 즉 접근제어가 '네트워크 영역' 을 넘어서 '애플리케이션 계층까지 커버' 되는 정도의 차이

 

9. 위협 대응력 - 은폐란?

• SDP는 공격자가 스캔할 수 없게 만든다 는 점에서 탐지 가능성 자체를 낮추는 전략을 사용한다.
• 이는 APT나 내부자 공격 대응에 강점이 된다.

 

 

 

 

 

 

[참고자료]

Software-Defined Perimeter (SDP) Specification v2.0 - Korean | CSA