[데이터넷] 미국 정부가 ‘사이버 보안 개선 행정명령’을 통해 제로 트러스트 채택을 선언하는 등 제로 트러스트 보안 모델에 대한 관심이 높아지고 있다. 그러면서 구체적인 활용모델을 요구하는 기업·기관도 늘어나고 있다. 클라우드 보안 연합(CSA) ‘SDP 아키텍처 가이드’ 3회차에서는 SDP를 구축하는 모델을 알아보고, SDP를 통해 얻을 수 있는 효과를 소개한다.<편집자>

| 연재순서 |
1. SDP의 정의와 특징
2. SDP 아키텍처에 대한 이해
3. SDP 구축모델 방법(이번호)
4. SDP와 기존 보안장비와의 연동방안

미국 바이든 대통령이 5월 서명한 ‘국가 사이버 보안 개선에 대한 행정명령(Executive Order on Improving the Nation’s Cybersecurity)’에서 연방정부 사이버 보안 현대화를 위해 제로 트러스트 아키텍처를 채택한다는 내용이 포함돼 있다. 끊이지 않는 대규모 사이버 공격을 받고 있는 미국 사이버 안보를 위해 제로 트러스트를 도입한다는 점은 시사하는 바가 크다.

이에 제로 트러스트를 구현하는 기술 중 하나인 소프트웨어 정의 경계(SDP) 기술의 도입 속도도 훨씬 빨라질 것으로 예상된다. SDP는 클라우드, 재택·원격근무, 망분리 및 폐쇄망 환경, IoT 및 스마트시티 등 모든 환경에 적용 가능한 안전한 애플리케이션 접속 보안을 제공한다.

공격 타깃인 서버와 애플리케이션을 숨기고, 접근하는 사용자·기기를 확인하며, 안전한 커뮤니케이션을 보장하는 암호화 네트워크로 통신하므로 모든 분산된 환경이나 보안에 취약한 환경에서도 안전하게 업무할 수 있다.

SDP는 기존 IT 인프라를 전면 교체해야 하는 대규모 프로젝트이며, 대규모 분산 환경을 운영하는 기업에만 효과적이라는 인식이 있지만, 사실은 그렇지 않다. SDP는 모든 조직과 환경에서 제로 트러스트 기반 보안을 수립하고 운영할 수 있게 한다.

클라우드 보안 연합(CSA)의 ‘SDP 아키텍처 가이드’에서는 ‘SDP 규격 1.0’을 통해 구현할 수 있는 모델을 다양하게 제시하면서 현재 조직에 쉽고 빠르게 적용 가능하다고 설명한다. SDP를 통해 구현할 수 있는 6가지 예시 모델을 소개한다.

클라이언트→게이트웨이

이 모델은 한 개 또는 복수의 서버를 게이트웨이 후면에서 보호하며, 네트워크 구성과 관계없이 클라이언트/IH(Initial Host)와 게이트 간 접속을 보호한다. 게이트웨이는 동일한 위치에 있거나 또는 전 세계 어느 곳에도 위치 할 수 있다. 클라이언트/IH는 사용자가 사용하는 디바이스일 수도 있고, 서버 그 자체일 수도 있다.

이 모델에서는 클라이언트/IH는 mTLS 터널의 끝점인 게이트웨이에 직접 접속된다. 서버 접속을 안전하게 하려면 추가 예방조치를 취해야 하며, 컨트롤러와 서버들이 동일한 SDP 게이트웨이를 사용할 수 있도록 SDP 컨트롤러는 클라우드 또는 보호된 서버 근처에 위치할 수 있다.

<그림 1>에서 서버는 AH(Accepting Host) 역할을 하는 SDP 게이트웨이 뒤에서 보호된다. 게이트웨이를 통해 서버에 대한 접속을 보호하려면, SDP를 운영하는 조직이 서버 환경을 통제해야 한다.

정상적으로 허가받은 클라이언트/IH는 기본 드롭(Default-Drop) 방식 방화벽과 단일 패킷 인증(SPA)으로 보호되는 게이트웨이와 컨트롤러가 보호하고 있는 서버에 접근할 수 있지만, 허가받지 않은 클라이언트는 접근할 수 없다. 보호대상 서버는 인가되지 않은 사용자나 잠재된 공격자에게 은폐되어 접속할 수 없으며, 추가 변경 없이 SDP 환경에 포함될 수 있다. 서버가 있는 네트워크는 보호된 서버에 대한 인바운드 접속을 게이트웨이에서 허가하도록 구성해 허가 받지 않은 클라이언 트가 게이트웨이를 우회하는 것을 방지할 수 있다.

SDP 게이트웨이와 보호된 서버 사이에서 운영되는 IDS/IPS 등 기존 보안 솔루션이 변경 없이 사용될 수 있으며, 트래픽은 클라이언트를 게이트웨이에 접속하는 mTLS 터널에서 추출된 후 감시된다.

클라이언트→게이트웨이 모델은 애플리케이션을 클라우드로 전환하는 조직에 적합하다. 클라우드 또는 온프레미스 등 서버 환경이나 위치에 관계없이 게이트웨이와 애플리케이션 간 이동하는 데이터를 안전하고 보호한다. 또한 이 모델은 IH 를 변경할 필요가 없어 사내 레거시 애플리케이션을 보호하는 데도 적합하다.

클라이언트→서버

이 모델은 애플리케이션을 클라우드로 전환하는 조직에 적합하다. 클라우드 또는 온프레미스 등 서버 환경의 위치에 관계 없이 조직은 클라우드 내 애플리케이션에 대한 접속을 완전하게 제어할 수 있다.

애플리케이션을 IaaS 제공자로 이행해 엔드 투 엔드 접속을 보호하는 경우, 서버와 게이트웨이를 단일 호스트로 통합한다. 클라이언트/IH는 서버와 동일한 장소에 배치할 수 있으며, 분산시키는 것도 가능하다. 어느 경우에도 클라이언트/IH와 서버 사이의 접속은 엔드 투 엔드로 보호된다. 클라이언트/IH는 mTLS 터널을 통해 서버에 직접 접속되며, 컨트롤러와 서버가 동일한 게이트웨이를 사용하는 SDP 컨트롤러는 서버 또는 클라우드에 배치할 수 있다.

필요에 따라 서버와 게이트웨이 조합을 복수의 IaaS 제공자 사이에서 이동할 수 있기 때문에 유연성을 개선할 수 있으며, 업그레이드될 수 없는 사내 레거시 애플리케이션을 보호하 기에도 적합하다.

서버는 AH 역할을 하는 SDP 게이트웨이의 후면에서 보호되며, 서버 환경에 있어서 게이트웨이에서 서버로 안전한 접속은 서버 상의 애플리케이션과 서비스 소유자가 통제할 수 있으며, 소유자가 이들의 접속을 완전하게 제어할 수 있다.

보호된 서버는 기본 드롭 방화벽으로 동작하는 SPA로 보호되고 있기 때문에 적합한 클라이언트/IH를 제외하고는 접근할 수 없다. 내·외부 공격자나 부정 사용자는 접근할 수 없으며, 내부자 위협을 최대한 제거한다.

이 모델을 사용하면 보호된 서버에 게이트웨이를 설치해야 한다. 서버가 상주하는 네트워크는 보호된 서버에 대한 인바운드 접속을 허가하도록 구성할 필요는 없다. 서버 상 게이트 웨이는 SPA를 사용해 허가되지 않은 접속을 막아 IDS/IPS, SIEM 등 기존의 네트워크 보안 요소를 쉽게 사용할 수 있게 한다. SDP 게이트웨이와 보호된 서버로부터의 드롭된 패킷을 분석하면서 이상 트래픽을 감시할 수 있어 클라이언트/IH와 서버 사이의 mTLS 접속을 보존할 수 있다.

클라이언트/IH는 사용자 디바이스로서 나타내지만 그 자체가 서버인 경우가 있다. 이 모델에 대해서는 서버→서버 모델 을 참조하면 된다.

서버→서버

이 모델은 IoT, 가상머신(VM) 환경에 적합하며, 기본 네트워크 또는 IP 인프라와 관계없이 서버 간 모든 접속이 암호화되도록 보장한다. 서버 간 모델(Server-to-Server) 또한 조직의 SDP 화이트리스트 정책에 의해 통신이 명확하게 허용 되도록 보장한다. 신뢰할 수 없는 네트워크를 통한 서버 간의 통신은 보호되며, 경량 SPA 프로토콜을 사용해 서버를 모든 부정 접속으로부터 숨긴다.

이 모델은 IH 자체가 서버이며, SDP AH 역할을 할 수 있다는 점을 제외하고는 ‘클라이언트-서버’ 모델과 유사하다. 서버 간 모델도 SDP 게이트웨이 또는 유사한 경량 기술이 각 서버에 설치되고 모든 서버 간 트래픽이 보안 생태계의 다른 요소를 ‘은폐’ 상태로 만든다.

이 모델은 SDP 게이트웨이에서 드롭된 패킷을 가져오도록 네트워크 기반의 IDS/IPS를 구성해야 한다. 또한 조직은 호스 트 기반 IDS/IPS 시스템에 의존할 수도 있다. SDP 컨트롤러는 컨트롤러와 서버가 동일한 SDP 게이트웨이를 사용하도록 서버에 위치할 수 있다. SDP 컨트롤러는 클 라우드에 있을 수 있다. 서버는 AH 역할을 하는 SDP 게이트웨이 후면에서 보호된다.

서버 환경에서 게이트웨이를 통과하는 서버에 대한 보안 접속은 서버 애플리케이션·서비스 소유자가 제어할 수 있다. 보호된 서버는 화이트리스트에 있는 다른 서버 외에는 접속할 수 없으며, 게이트웨이와 컨트롤러는 기본 드롭 방화벽으로 보호되므로, 서버를 ‘은폐(dark)’ 상태로 보호할 수 있다. 내 부와 외부 모두에서 권한 없는 사용자들이 서버에 접근할 수 없어 내외부 위협으로부터 보호할 수 있다.

이 모델을 사용하면, 보호된 서버에 게이트웨이 또는 경량 SPA 프로토콜을 설치해야 한다. 서버가 상주하는 네트워크는 보호된 서버에 대한 인바운드 접속을 제한하도록 구성할 필요 가 없다. 통제 포인트가 되는 서버의 게이트웨이는 SPA를 활 용해 내부와 외부 무단 접속을 모두 방지한다.

이 모델을 사용하면 IDS/IPS 및 SIEM과 같은 네트워크 보안 구성 요소를 보다 쉽게 사용할 수 있다. SDP 게이트웨이와 보 호된 서버에서 손실된 모든 패킷을 분석해 트래픽을 모니터링 할 수 있으므로 보호된 서버 간의 mTLS 접속이 유지된다.

이 모델은 IoT 및 VM 환경을 클라우드로 전환하는 모든 환 경에 적합하다. 클라우드 또는 온프레미스 등 서버가 어디에 있는지 관계없이 조직은 클라우드 환경과의 접속을 완벽하게 제어할 수 있다.

클라이언트→서버→클라이언트

IP 전화, 채팅, 화상회의 서비스와 같이 경우에 따라 피어 투 피어(peer-to-peer) 트래픽이 중간 서버를 통과하는 경우가 있다. 이 경우 SDP는 접속 클라이언트의 IP 주소를 난독화 하고 구성 요소간의 네트워크 접속을 암호화해 SPA를 통한 무단 네트워크 접속으로부터 서버/AH를 보호한다.

컨트롤러와 서버가 동일한 SDP 게이트웨이를 사용할 수 있는데, SDP 컨트롤러는 서버 또는 클라우드에 있을 수 있다. 위에서 설명한 것처럼, 서버는 AH 역할을 하는 SDP 게이트웨 이 후면에서 보호된다. 게이트웨이를 통과하는 서버에 대한 보안접속은 기본적으로 서버의 애플리케이션과 서비스 소유자에 의해 제어된다.

보호된 서버는 인가 받은 사용자 외에는 접속할 수 없으며, 게이트웨이와 컨트롤러는 기본 드롭 방화벽이 있는 SPA로 보호돼 서버가 은폐되므로 공격자와 권한이 없는 내·외부 사용자는 접근할 수 없다.

이 모델은 보호된 서버에 게이트웨이 또는 경량 SPA 프로토콜을 설치해야 한다. 서버가 존재하는 네트워크는 보호된 서버에 대한 인바운드 접속을 제한하도록 구성할 필요가 없다. 시행 포인트가 되는 서버의 게이트웨이는 SPA를 사용해 내·외부 부정 접속을 모두 방지한다.

이 모델을 사용하면 IDS/IPS 및 SIEM과 같은 네트워크 보안 구성 요소를 보다 쉽게 사용할 수 있다. SDP 게이트웨이와 보호된 서버에서 손실된 모든 패킷을 분석해 트래픽을 모니터 링할 수 있으므로 클라이언트와 보호되는 서버 간의 mTLS 접속이 유지된다.

이 모델은 조직에서 피어 투 피어 애플리케이션을 클라우드 로 전환하는 모든 환경에 적합하다. 클라우드 또는 사내 등 서버 환경이 어디에 있든지 관계없이 조직은 클라이언트와의 접속을 완벽하게 제어할 수 있다.

클라이언트→게이트웨이→클라이언트

이 모델은 클라이언트-서버-클라이언트 모델의 변형으로, SDP 접근 정책을 적용하는 동안 클라이언트가 서로 직접 접속하거나 접속해야 하는 P2P 네트워크 프로토콜을 지원한다. 애플리케이션 프로토콜에 따라 각각 IH, AH 또는 두 가지 역할을 동시에 수행하는 클라이언트 간 논리적 접속이 발생한다. 애플리케이션 프로토콜은 클라이언트가 서로 접속하는 방법을 결정한다. SDP 게이트웨이는 클라이언트 간의 방화벽 역할을 한다.

게이트웨이→게이트웨이

이 모델은 IoT 환경에 적합하다. 하나 이상의 서버가 AH 후 면에 배치돼 AH가 클라이언트와 서버 사이의 게이트웨이 역할을 한다. 동시에 하나 이상의 클라이언트가 IH 후면에 구성 되고 IH도 게이트웨이 역할을 한다.

이 모델에서 클라이언트 디바이스는 SDP 클라이언트 소프트웨어를 실행하지 않는다. 이 디바이스에는 프린터, 스캐너, 센서 및 IoT 디바이스와 같은 SDP 클라이언트를 설치할 필요가 없거나 설치할 수 없는 디바이스가 포함될 수 있다. 이 모델에서 게이트웨이는 구현에 따라 방화벽으로 작동하며, 상 황에 따라 라우터 또는 프록시로도 작동한다.

SDP 구축 모델과 관련 시나리오

SDP는 제로 트러스트 네트워크 액세스(ZTNA)를 위한 요건을 대부분 만족한다. 앞서 설명한 구축 방식을 활용해 ZTNA를 어떻게 구현할 수 있는지 소개한다.

- ID 방식 네트워크 접근제어

• 앞서 설명한 모든 SDP 모델이 ID 방식 네트워크 접근제어를 지원한다.
• 클라이언트→서버 모델에서는 네트워크와 서비스에 대한 안전 한 접속을 제공한다.
• 게이트웨이→게이트웨이 모델에서는 특정 SDP를 구현하는 디 바이스 식별과 검증을 수행하는 방법에 따라 디바이스를 식별할 수 있는 정도가 달라진다. 예를 들어 MAC 주소는 802.1x보다 취약한 ID인증을 제공한다.

- 네트워크 세분화

• 모든 SDP 모델은 개별 접속을 보호해 네트워크 세분화를 제공한다.
• 클라이언트→게이트웨이 모델은 클라이언트와 게이트웨이 간 접속을 보호해 세분화를 제공하지만, 게이트웨이 후면에 있는 서버에 대한 세분화는 제공하지 않는다.
• 클라이언트→서버 모델은 서버에 대한 모든 접속을 보호해 네트워크 세분화를 제공한다. 또한 게이트웨이를 호스팅하는 서버는 은폐된다.
• 서버→서버 모델은 해당 서버에 대한 모든 접속을 보호해 네트워크 세분화를 제공한다. 또한 게이트웨이를 호스팅하는 서버는 은폐된다.

- VPN 대체하는 원격접속 보안

• SDP는 기존 VPN을 대체할 수 있다.
• 모든 모델에서 컨트롤러와 게이트웨이/AH는 원격 디바이스에 서 SPA를 사용해 접속을 시작할 수 있도록 접근할 수 있다.

- 제 3의 사용자 접속

• SDP는 보안이 필요한 접속에 따라 모든 시나리오에 대해 제3자 접근을 지원한다. 제 3자는 원격 또는 사내일 수 있으며, 이들이 인증하는 별도의 ID 제공자가 있을 수도 있다.
• 서버→서버 모델에서는 내부 애플리케이션에 접근하는 모든 제 3자 애플리케이션의 접속을 보호하며 제 3자 애플리케이션이 클라이언트 역할을 한다.

- 권한 있는 사용자 접속 보호

• SDP는 클라이언트의 접속에 대한 권한 있는 사용자 접속을 보호한다. 일반적으로 권한 있는 사용자 접근은 서버에 접속하는 클라이언트를 의미하지만 해당 애플리케이션에 따라 모든 모델에 적용할 수 있다.
• 단 클라이언트를 제어할 필요가 없는 서버→서버 모델과 게이트 웨이→게이트웨이 모델은 권한있는 사용자 접속 보호를 지원하지 않는다.

- 고부가가치 애플리케이션 접속 보안

• 게이트웨이와 게이트웨이를 제외한 모든 모델은 해당 특정 모델 에 의해 보호되는 고부가 가치 애플리케이션과 관련된 모든 접속을 보호한다.
• 단 서버와 클라이언트를 제어하지 않는 게이트웨이→게이트웨 이 모델은 애플리케이션 접속보안을 지원하지 않는다.

- 관리되는 서버 접속 보안

• 이 시나리오는 관리되는 서버에 대한 서비스 공급자 접속을 위한 것이다. 서버는 게이트웨이에 의해 완전히 은폐되거나 관리되는 서비스 환경의 경우 관리적 측면만 게이트웨이에 의해 은폐될 수 있다.
• 클라이언트→서버 모델에서는 SDP 게이트웨이 소프트웨어가 서버에 배포된다. 서버는 숨겨지고 MSSP/관리 서비스는 서비스에 대한 접속을 탐지하고 제어한다.
• 클라이언트→게이트웨이→클라이언트 모델은 서버를 제어하지 않기 때문에 이 기능을 지원하지 않는다.

- 네트워크 연동 단순화

• 모든 SDP 구축 모델은 이 시나리오를 지원하며 다양한 유형의 보안 접속이 필요하다.
• 클라이언트→서버 모델과 서버→서버 모델은 서버에 있는 서비스를 게이트웨이로 은폐할 수 있다는 장점이 있다.

- IaaS 클라우드로 안전하게 전환

• 이 시나리오에서는 사내에서 클라우드 서비스를 이동해야 한다. 모든 SDP 모델이 이를 지원한다.

- 강력한 인증 체계

• 모든 SDP 모델은 종종 다중 인증과 스텝업 인증을 통해 인증을 강화할 수 있는 기능을 제공한다.
• 사용자가 없는 서버→서버 모델은 일회용 암호를 묻는 메시지를 표시할 수 없다. 그러나 PKI 또는 서버 기반 HSM을 사용하는 것과 같은 다중 요소 인증을 지원할 수 있다. ID 관리 시스템은 사용자뿐만 아니라 시스템이나 디바이스에도 사용할 수 있고 또한 사용돼야 한다.

- 간소화된 규정준수 통제 및 보고서

• 모든 SDP 모델은 통제 기능을 통합해 규정준수를 간소화할 수 있다.

- 디도스 공격 방어

• 모든 SDP 모델은 게이트웨이 내에서 SPA를 사용하기 때문에 디도스 공격에 대한 조직의 대응이 향상된다. 전부 거부(deny-all) 게이트웨이를 사용하지 않는 경우, 인터넷 대면 서비스는 내부 호스팅 서비스에 비해 디도스 대상이 되는 경우가 많다.

SDP, 접속 전 인증으로 ZTNA 구현

SDP는 네트워크 스택의 모든 계층에서 접속을 보호하는 프로토콜을 제공한다. 주요 위치에 게이트웨이와 컨트롤러를 설치해 조직에 가장 중요한 접속 보안에 집중할 수 있으며 네트워크 기반, 도메인 간 공격으로부터 이러한 접속을 보호할 수 있다.

SDP 기술의 가장 중요한 요소 중 하나는 TCP/IP의 개방적이고 안전하지 않은 특성을 보완하는 ‘접속 전 인증’ 모델을 요구하고 시행한다는 것이다. SDP는 컨트롤러 또는 게이트웨이 등의 시스템에 네트워크를 허용하기 전에 디바이스나 사용자의 신원을 확인하는 경량 보안 프로토콜인 단일 패킷 인증(SPA)을 통해 접속 전 인증을 실현한다. 요청자의 IP 주소를 포함한 접속 요청에 대한 정보는 단일 네트워크 메시지에서 암호화 및 인증된다. SPA의 목적은 기본 드롭 방화벽을 통해 서비스를 노출되지 않게 하는 것이다.

시스템은 모든 TCP 및 UDP 패킷을 드롭하고 이러한 시도에는 응답하지 않아야 하며 포트가 모니터링되고 있다는 정보를 잠재적인 공격자에게 제공하지 않는다. 인증 및 인가 후 사용자에게 서비스에 대한 접근 권한이 부여된다. SPA는 SDP의 일부로서 클라이언트와 컨트롤러, 게이트웨이와 컨트롤러, 클라이언트와 게이트웨이 간의 접속을 위한 통신을 개시하는 필수적 요소이다.

SPA 구현은 각각의 모델마다 약간 다를 수 있지만 다음과 같은 원칙이 있다

• 패킷은 암호화되고 인증돼야 한다.
• 패킷은 필요한 모든 정보를 자체 포함해야 하며, 패킷 헤더만으로는 신뢰받을 수 없다.
• 패킷을 생성하고 전송하기 위해 관리자 또는 루트 수준 권한에 종속되지 않아야 한다. 패킷 조작은 허용되지 않는다.
• 서버는 패킷을 최대한 자동으로 수신 및 처리해야 한다. 응답 또는 확인 메시지는 전송되지 않는다

SPA, 서버 은폐해 안전한 원격 접속

SPA는 SDP에서 중요한 역할을 한다. SDP의 목표 중 하나 는 ‘접속 후 인증’ 모델을 따르는 TCP/IP의 개방적이며 안전 하지 않은 기본 특성을 극복하는 것이다. 오늘날 사이버 보 안의 위협의 상황을 생각하면, 악성 공격자가 기업의 시스템을 스캔해 접속하는 것을 허가하는 것은 받아들이지 않는다. SPA와 SDP의 조합은 두 가지 방법으로 이 취약성을 해결할 수 있다.

SDP 아키텍처를 사용하는 애플리케이션은 SDP 게이트웨이/AH 후면에 숨겨져 있으므로 허가된 사용자만 접근할 수 있다. 또한 SDP 구성 요소 자체인 컨트롤러 및 게이트웨이는 SPA에 의해 보호된다. 이를 통해 인터넷 환경에서 안전하게 배치할 수 있어 합법적인 사용자에게는 생산적이고 신뢰할 수 있는 접근을 보장받는 반면 권한이 없는 사용자는 애플리케이션이 숨겨져 있어 접근 시도조차 할 수 없다.

SPA는 서비스를 보이지 않게 하는 중요한 장점을 제공한 다. 기본 드롭 방화벽은 포트 검색 및 관련 탐색 기술을 억제 한다. 이러한 유형의 방화벽은 SPA 구성 요소를 인증되지 않은 사용자에게 보이지 않게해 전체 SDP의 공격 대상을 크 게 줄인다.

SPA는 또한 디도스 공격으로부터 보호한다. 서비스가 공용 인터넷에 노출돼 공격받게 될 경우 상대적으로 적은 양의 트래픽으로 HTTPS 서비스를 오프라인으로 전환할 수 있다. SPA는 인증된 사용자에게만 서비스를 개방해 디도스 공격은 보호되는 서비스에 닿지 않고 기본 드롭 방화벽에 의해 처리 된다.

SDP는 개방형 포트 및 기타 취약성을 가지고 있는 VPN보 다 더 많은 안전한 보안 기능을 제공하며, 제로데이 공격을 차단한다. 취약성이 새로 발견될 때 인증된 사용자만 영향을 받 는 서비스에 접근할 수 있는 경우 본질적으로 피해를 최소화 할 수 있다.

SPA는 SDP 보안 계층의 일부일 뿐 자체적으로 완전하지 않다. SPA 구현은 공격 재생을 할 수 있도록 복원력 있게 설 계되어야 하지만, SPA는 중간자 공격(MITM)의 대상이 될 수 있다. 특히 MITM 공격자가 SPA 패킷을 캡처·변경할 수 있다면, 공격자는 인증된 클라이언트가 아니어도 컨트롤러/AH에 TCP 접속을 할 수도 있다.

그러나 이 공격자는 클라이언트의 인증서 없이 mTLS 접속을 완료할 수 없다. 따라서 컨트롤러/AH는 이 접속 시도를 거 부하고 TCP 접속을 차단해야 한다. MITM 시나리오에도 불 구하고 SPA는 표준 TCP보다 훨씬 안전하다.

사용자 인증 전용 접근제어 강화

SDP가 새로운 아키텍처로서 갖는 가치는 접근 제어 관리를 강화하고, 사용자 접근 관리, 네트워크 접근 제어, 시스템 인증 제어를 구현하기 위한 표준을 설정하는 것이다. SDP는 권한이 없는 사용자 또는 검증되지 않은 디바이스로부터 접근하는 네트워크 레벨의 모든 접근을 사전에 방지해 접근 제어를 강제화할 수 있다.

SDP는 게이트웨이 설정을 모두 거부(deny-all)로 구현하기 때문에 IH와 AH 간에 네트워크 패킷이 흐르지 않도록 차단하거나 허용한다. 최소한 SDP를 통해 조직은 어떤 주체가 어떤 네트워크 서비스를 어떠한 검증된 디바이스에서 접근해야 하는지 결정하는 정책을 정의하고 수립할 수 있도록 한다.

SDP는 기존 ID 및 접근 관리 솔루션을 대체하려고 시도하지 않고 사용자 인증 전용 접근 제어를 강화한다. SDP는 사용 자 인증 및 권한을 다른 보안 구성 요소와 통합해 잠재적인 공 격 대상을 크게 줄인다

예를 들어 사용자 제인은 회사의 생산 재무관리 서버에 로 그인할 수 있는 자격 증명이 없을 수 있지만, 제인의 디바이스에서 네트워크상 해당 서버가 보인다면 보안 위험이 발생할 수 있다.

만약 제인의 회사가 SDP 아키텍처를 구현한다면, 재무 관리 서버는 제인의 디바이스에서는 볼 수 없도록 숨겨져 있다. 따라서 공격자가 제인의 컴퓨터에 거점을 두고 있더라도 SDP 는 제인의 디바이스에서 자격 증명이 없는 금융 관리 서버에 접속하는 것을 방지할 수 있다.

제인이 재무 관리 서버에 대한 접근을 허용하는 자격 증명 을 가지고 있더라도 SDP 클라이언트를 디바이스에 설치하 면 추가적인 보호를 제공한다. 공격자는 여전히 강력한 디 바이스 유효성 검사와 결합된 MFA 사용자 인증에 의해 차단된다.