[CSA SDP 아키텍처 가이드] 급변하는 환경 효과적 보호 방안 제시
상태바
[CSA SDP 아키텍처 가이드] 급변하는 환경 효과적 보호 방안 제시
  • 데이터넷
  • 승인 2021.08.06 11:04
  • 댓글 0
이 기사를 공유합니다

SDP, 단순하지만 강력한 보안 원칙으로 하이브리드 보안 복잡성 문제 해결
네트워크·구축된 보안 솔루션 특징·조직 구성 등 기업 환경 고려해 구축해야
<한동우 엠엘소프트 대표 컨설턴트>

[데이터넷] 소프트웨어 정의 경계(SDP)를 VPN이나 NAC를 대체하는 포인트 솔루션으로 생각하는 경우가 있다. SDP는 단순한 포인트 솔루션이 아니라 기업 인프라를 효율적으로 개선하는 플랫폼이다. VPN, NAC, IAM, NGFW 등 기존 보안 솔루션과 함께 사용해 보안 효과를 개선할 수 있으며, 현재 환경에 맞지 않는 오래된 솔루션을 대체해 단순하지만 강력한보안 아키텍처를 완성할 수 있다. 클라우드 보안연합(CAS) ‘SDP 아키텍처 가이드’ 마지막회인 이번 편에서는 기업에서 일반적으로 사용되는 보안·IT 솔루션 및 클라우드와 SDP를 어떻게 연동할 수 있는지 살펴본다. <편집자>

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

기업의 정보보안 아키텍처는 비즈니스가 성장하고, 공격이 고도화되면서 점점 더 복잡해지고 있다. 클라우드 가속화로 복잡성이 한층 높아졌으며, 분산된 환경에서 접속하는 많은 사람들의 보안 상태를 평가하고 허용-차단하는 것이 어려운 일이 됐다.

소프트웨어 정의 경계(SDP)는 단순하지만 강력한 보안 원칙으로 이 문제를 해결한다. 사용자와 기기의 위치에 관계없이, IT 인프라와 네트워크 환경에 상관없이 모든 조건에서 안전한 접속을 보장한다. SDP의 기본 원칙은 다음과 같다.

- 접속을 허용하기 전에 사용자 권한 부여 및 디바이스 유효성 확인
- 양방향 암호화 통신
- 모두 거부(deny-all) 방화벽에 근거한 동적 제어 및 서버 은폐
- 애플리케이션 컨텍스트와 세밀한 접근 제어 통합

기업 환경에 맞는 SDP 구축 방식 찾아야

SDP를 기업 보안 인프라로 채택할 때 사용자의 수, 네트워크 및 서버 환경, 규정준수 요구사항 등을 고려해야 한다. 현재 운영 중인 IT 환경에 가장 적합한 SDP 구축 방식과 사용자·비즈니스에 어떤 영향을 주는지 등을 살펴봐야 한다.

• 기존 네트워크 기술에 적합한 SDP 구축 방식

SDP를 구축할 때 설계자는 자신의 조직에 가장 적합한 구축 모델을 선택해야 한다. 보호해야 할 서버를 은폐하고 모든 접근을 SDP 게이트웨이를 통해 이뤄지도록 하려면 게이트웨이가 인라인 네트워크에 추가될 수도 있다. 이때 방화벽·라우터 설정을 변경해야 해 조직 네트워크에 영향을 미칠 수 있다.

• SDP는 감시 및 로깅 시스템에 어떻게 영향을 주는가

SDP는 IH(Initial Host)와 AH(Accepting Host) 사이에 mTLS를 사용한다. 암호화된 트래픽을 이용해 연결하기 때문에 트래픽 분석이 어렵다. 보안, 성능, 신뢰성, 모니터링을 위해 이 트래픽을 분석해야 하는 경우 지원이 어려울 수 있다. 따라서 엔터프라이즈 네트워크 설계자는 SDP로 인해 네트워크 트래픽이 어떻게 변하는지, 시스템에 어떤 영향을 미칠 수있는지 파악해야 한다.

SDP는 사용자 접근에 대한 풍부한 컨텍스트와 ID 중심 로깅을 제공하기 때문에 기존 모니터링 시스템을 보강하고 개선하는 데 사용할 수 있다. 또한 SDP 게이트웨이와 컨트롤러에서 통과되지 않은 모든 패킷을 SIEM에 기록해 자세히 분석할 수 있다. 이를 통해 모든 접속 정보(누가, 언제, 무엇을, 어디서)를 수집하기 쉬워진다.

• SDP가 API 통합을 포함한 애플리케이션 배포, 데브섹옵스 프로세스와 툴 세트에 어떻게 영향을 주는가

많은 조직이 데브옵스 또는 CI/CD와 같은 고속 애플리케이션 배포 프로세스를 갖고 있다. 이러한 프로세스와 지원하는 자동화 프레임워크는 보안 시스템과의 신중한 통합이 필요하며, SDP도 예외는 아니다. SDP는 데브옵스 중 권한 있는 사용자만 개발 환경에 효과적으로 접속할 수 있도록 한다. 또한 SDP는 작업 중 권한 있는 사용자로부터 특별히 보호된 서버와 애플리케이션에 대한 접속을 보호할 수 있다.

보안 설계자는 SDP 구축 모델과 조직의 데브옵스 메커니즘이 SDP와 어떻게 통합되는지 이해해야 한다. API 통합은 데브옵스 툴셋 통합에 필요한 경우가 많기 때문에 보안 팀은 SDP 구현에 의해 지원되는 API들을 검토해야 한다.

• SDP는 사용자에게 어떠한 영향을 주는가

보안 팀은 사용자에게 최대한 투명하게 솔루션을 제공하기 위해 노력하고 있다. SDP는 최소 권한 원칙을 적용해 사용자가 필요한 항목에 대해서만 접근권한을 갖게 하며, 불필요한 접근은 차단한다. SDP 배포 모델에 따라 사용자는 디바이스에서 SDP 클라이언트 소프트웨어를 실행한다. 보안 설계자는 IT와 협력해 사용자 환경, 클라이언트 소프트웨어 배포 및 디바이스 등록 프로세스를 계획해야 한다.

보안 솔루션 대체 혹은 강화하는 SDP

<그림 1>은 기업 보안 아키텍처의 중요한 요소를 표현한 예시 모델이다. 사내와 클라우드 기반 리소스(IaaS,SaaS·PaaS)로 구성되며, 표준 보안, IT 및 규정 준수 구성 요소가 포함돼 있다. 기업의 주요 보안 요소가 SDP와 어떻게 통합되는지 설명하면 다음과 같다.

<그림 1> 기업 보안 아키텍처 주요 요소

• 보안 정보 및 이벤트 관리(SIEM)

SIEM은 애플리케이션과 네트워크 구성 요소에서 생성된 로그 정보와 보안 위협을 분석한다. 다양한 IT 시스템에서 로그를 수집하고 실시간에 가깝게 분석해 보안 담당자가 신속하게 방어 조치를 취할 수 있도록 하며, 규제 준수를 위한 자동화된 중앙 집중식 보고 기능을 제공한다. 사내 또는 클라우드에서 호스팅되는 SIEM은 IT·보안 관리 시스템의 핵심요소다.

여러 소스에서 정보를 수집하는 SIEM과 SDP 로그를 연계하면 위협 분석과 탐지 정확도를 높일 수 있다. 상용 SDP가 제공하는 내부 로깅 기능을 SIEM에 연동하거나, 기업 시스템이 분산된 SDP에서 직접 정보를 수신해 SIEM으로 전달할 수 있다. 혹은 로그를 수집하는 에이전트를 설치해 SIEM으로 전송할 수 있다. SIEM은 SDP 로그를 통합해 분석, 사전에 정의된 사용자 정의된 이벤트를 중앙 관리 콘솔에 전달하거나 이메일을 통해 지정된 개인에게 경고를 보내는 방식으로 이상 징후를 알려주고 검사를 수행한다.

SDP는 ID와 디바이스를 검색하는 방식으로 접근을 제어하기 때문에 SIEM이 수집하는 일반적인 네트워크와 애플리케이션 모니터링 툴보다 풍부한 정보를 제공할 수 있다. SDP는 모든 접속 정보(누가, 무엇을, 어디서)를 실시간으로 제공해 SIEM의 가치를 높일 수 있다.

SIEM과 SDP를 연계하면 보안 분석가는 여러 로그의 정보를 종합해 무단 사용자(who)를 식별할 수 있다. SIEM만으로 ‘무엇’에서 ‘어디’로 이어지는 무단 접속을 식별하는 것은 어렵지만, SDP 클라이언트가 사용자의 디바이스에 있는 경우, 디바이스에서 특정 정보를 수집해 연결성을 확보할 수 있다.

SDP 게이트웨이에서 차단된 모든 패킷을 저장해 잠재적인 해킹 시도를 분석하거나 감소시키는 효과도 얻을 수 있다. 이는 IP 주소와 포트를 기반으로 제어하는 방화벽의 차단 정책보다 정확하다. 또한 SDP는 여러 기기에서 발생하는 사용자 활동을 수집해 SIEM이 수집하는 데이터의 종류를 다양하게 한다. BYOD와 모바일 기기의 정보까지 수집·분석하려면 SDP가 반드시 필요하다.

SIEM을 SDP와 통합하면 보안 전략을 능동적 보안 운영에서 사전 예방적 보안으로 전환할 수 있다. SIEM은 사용자 접속을 끊고, 검증되지 않은 디바이스 또는 특정 호스트에서 접속을 허용하지 않으며, 의심스러운 접속을 삭제해 위험을 제어할 수 있다. 예를 들어 SIEM에서 의심스러운 권한 없는 사용자의 활동이 탐지됐을 때 SDP는 이 행위에 대한 추가 분석이 끝날 때까지 접속을 차단한다.

로그 정보를 생성하는 다른 시스템과 마찬가지로 SDP 로그는 기업의 잠재적인 중요 데이터와 개인정보 보호 문제를 안고 있다. SIEM과 SDP 로그를 연결할 때 네트워크에 접속하거나 해당 메타데이터를 사용해 분석하는 과정에서 로그의 특정 사용자 정보가 유출되거나 공개될 수 있다. SDP를 배포하는 동안 이 문제에 대한 예방 조치를 취해야 한다. SDP는 SIEM과 연계해 다양한 유형의 공격을 방지, 탐지 및 대응할수 있는 기능을 강화하고 개선한다.

<그림 2> SIEM과 SDP

• 방화벽(Traditional Firewall)

기존 방화벽은 OSI의 데이터 링크 계층(L2), 네트워크 계층(L3), 전송 계층(L4)이 적용되는 7계층 개방형 시스템 상호 접속 모델에 따라 네트워크 트래픽을 모니터링하고 제어한다. 이들은 소스와 대상 IP, 포트를 기반으로 네트워크 패킷 데이터를 필터링하고, 네트워크 프로토콜의 정의를 필터링하는 5-튜플(5-tuple) 방법을 준수한다. 방화벽은 네트워크 주소 변환(NAT), 포트 주소 변환(PAT)을 비롯한 다른 기능도지원할 수 있다.

방화벽은 수십 년간 기업 네트워크 보안의 주축이었지만 제한된 5-튜플 환경 내에서만 운영되기 때문에 많은 한계를 갖고 있다. 전통적인 방화벽은 정적 규칙 집합만 표현할 수 있으며 ID 정보에 기반한 규칙을 표현하거나 적용할 수 없다. 방화벽을 사용하거나 동등한 네트워크 트래픽 시행 기능을 구현하는 SDP는 기업이 현재 방화벽을 사용하는 방식을 크게 개선할 수 있다. SDP는 조직에서 방화벽을 통해 제어하는 네트워크 접근 제어 시행의 대부분을 담당한다. 기업은 SDP를 통 해 방화벽 규칙을 줄일 수 있다.

SDP는 5-튜플의 제약 내에서 ID 중심(Identity-centric) 접근 제어를 모델링하는 대신 SDP 접근 제어를 통해 보다 정확한 판단과 강제화를 가능하게 한다. SDP는 복잡한 환경에서 방화벽 규칙을 작성, 테스트, 디버그 및 배포하는데 필요한 노력을 줄일 수 있을 뿐 아니라 보다 풍부하고 정확한 접근 제어 메커니즘을 지원한다.

<그림 3>은 단일 방화벽이 사용자 서브넷(192.168.100.0/18)에서 로컬 데이터센터 서브넷으로 접근을 제어하는 기존 사무실 LAN 환경에서 접근 보안을 시도하기 위한 어렵다는 사실을 보여준다. 방화벽은 사무실 네트워크 사용자가 IP 주소로만 표시되기 때문에 사용자를 구분할 수 없다. 많은 사용자가 정기적으로 사용하는 노트북이 있기 때문에 사용자의 IP주소가 자주 변경된다.

일반적인 데이터센터 네트워크에는 테스트 시스템과 업무시스템을 모두 포함해 다양한 워크로드가 저장된다. 일부 애플리케이션은 수명이 길고 정적 IP 주소를 사용하는 반면, 다른 애플리케이션은 정기적으로 생성 및 삭제되는 가상 시스템을 기반으로 구축되므로 IP를 예측할 수 없다.

개별 사용자가 데이터센터의 모든 서버와 해당 서버의 모든 포트 접근을 요구하는 것은 아니지만, 이러한 환경에서는 사무실 LAN의 모든 IP가 데이터센터 네트워크의 모든 IP에 접근할 수 있도록 방화벽에 규칙 집합이 있어야 한다.<그림 3> 기존의 방화벽 설정

<그림 3> 기존의 방화벽 설정

 

<그림 4> SDP 클라이언트 → 게이트웨이 모델 사용으로 개선된 보안

<그림 4>는 클라이언트에서 게이트웨이로(Client-to-Gateway) 향하는 모델을 통해 방화벽 중심 모델보다 개선된 보안 환경을 보여준다. 다른 SDP 배포 모델도 마찬가지로 적용된다. 이 예시에서는 네트워크 방화벽이 동일한 기능을 수행하는 SDP 게이트웨이로 교체됐다.

SDP는 특정 ID와 사용하는 디바이스를 기반으로 접근을 제어하기 때문에 데이터센터에 대한 세분화된 접근 제어를 할 수 있다. 대규모 공격의 대상이 되는 개방적이고 보편적(open, flat)인 네트워크는 최소화되고 있다. 데이터센터 서버에 더 가까이 또는 더 많은 SDP 게이트웨이를 추가하면 특정 서비스에 대한 세분화된 접근통제를 할 수 있다.

• 침입탐지·방지시스템(IDS/IPS)

침입탐지·방지시스템(IDS/IPS)은 네트워크나 시스템에서 악의적인 활동이나 정책 위반을 모니터링한다. 트래픽을 검사하는 네트워크 기반 분석이나 행위와 잠재적 네트워크 트래픽을 검사하는 호스트 기반 분석을 사용한다. 네트워크 기반의 경우 SDP는 IDS의 구성을 변경해야 할 수도 있지만 IDS/IPS 시스템 구축을 강화할 수 있다. 단일 네트워크 원격사무실과 같은 소규모 운영 환경에서는 SDP가 IDS/IPS의 역할을 할 수 있다.

SDP는 클라이언트와 게이트웨이 간 상호인증(mTLS) 암호화를 사용하기 때문에 네트워크 트래픽 기반 IDS는 네트워크 트래픽을 볼 수 없다. IDS는 인증서를 가져와 TLS 트래픽을 프록시 하는데, 이 과정에서 공격 가능한 취약점이 발생할 수 있다. 그러나 SDP는 상호인증(mTLS) 암호화를 기반으로 하기 때문에 공격 대상을 증가시키지 않는다. mTLS 세그먼트는 SDP 자격 증명을 사용해 암호화되고, 이 트래픽을 분석하려는 시스템에서는 접근할 수 없기 때문에 외부 시스템에는 확인이 불가능하다.

또한 SDP는 드롭된 패킷과 같이 암호화되지 않은 트래픽을 원격 IDS에 전달한다. 호스트 기반 IDS는 네트워크 기반 IDS/IPS보다 보안 작업을 더 향상시킬 수 있다. SDP가 네트워크 기반 IDS에

영향을 미치는 유일한 기술은 아니다. 클라우드 기반 애플리케이션으로의 전환으로 호스트 기반 IDS의 효과와 적용도 늘어났다.

SDP를 배치하려면 IDS 시스템에 대한 일부 변경이 필요할 수 있지만, 승인되지 않은 모든 네트워크 트래픽을 차단해 시스템의 노이즈를 줄이는 장점을 얻을 수 있다. 이러한 변화를 통해 IDS와 이를 운영하는 팀은 네트워크 트래픽을 인증된 애플리케이션으로 집중시키고 리소스를 내부자 위협 탐지로 전환할 수 있다.

SDP는 ‘허니팟’ 시스템의 구축과 효과를 단순화하고 향상시킬 수 있다. 보호 시스템은 공격자에게 보이지 않기 때문에 SDP는 악성 행위자를 허니팟으로 유인해 공격 활동을 더 빠르게 탐지할 수 있다.

• 가상 사설 네트워크(VPN)

VPN은 신뢰할 수 없는 네트워크에서 보안 전용 네트워크 접속을 설정한다. VPN은 일반적으로 외근 직원과 회사 사이트 간의 통신과 같이 원격에서 안전하게 접근할 때 사용된다. TLS 또는 IPSec을 사용하며, 네트워크 트래픽 캡슐화와 암호화를 이용한다. 안전한 사이트 간 통신이나 사이트 간 엑스트라넷 등 다른 회사 간 통신에도 사용된다.

VPN은 라이선스 비용이 낮을 수 있지만, 상당한 운영 노력이 필요할 수 있다. VPN은 광범위하고 지나치게 넓은 네트워크 접근을 제공한다. 서브넷 범위 기반 등 기본 접근 제어 제한만 제공하기 때문에 사용자와 네트워크를 충분히 보호하지 못한다. 이러한 제한은 많은 조직에서 보안 및 규정 준수 위험으로 나타난다.

분산된 환경에서 VPN은 사용자 트래픽을 불필요하게 백홀링하기 때문에 대기 시간과 대역폭 비용을 늘릴 수 있다. VPN 서버가 인터넷에서 서비스로 노출돼 있어 공격자에게 잠재적으로 취약해질 수 있다.

또한 VPN은 사용자에게 상당한 부담을 주며, 엔드포인트 장애와 접속 지연을 발생시킨다. 사용자는 VPN을 사용해야 하는 애플리케이션이나 사용하지 않는 애플리케이션을 기억해야 하며, 수동으로 접속하거나 접속을 끊어야 한다. 여러 원격 위치에 접근해야 하는 사용자는 VPN이 두 위치에 동시에 접속하지 못하도록 설정돼 있기 때문에 수동으로 환경을 전환시켜야 하는 불편함이 있다.

클라우드로 인해 VPN 관리는 더 복잡해진다. IT 관리자는 여러 위치에서 VPN과 방화벽 정책을 구성하고 동기화해야 하는데, 이 같은 정책 설정과 변경 업무가 늘어나면서 확인되지 않은 접근을 제거하는데 어려움을 겪는다.

SDP는 VPN을 대체할 수 있는 대표적인 기술이다. VPN 대신 SDP를 사용하면 원격접속, 사내 접속 및 모바일 기기 또는 사용자 관리 통제를 위한 일관된 단일 접근 제어 플랫폼을 구축할 수 있다. 특히 인터넷에 노출된 서비스에게 SDP는 SPA 및 동적 방화벽을 통해 제로 가시성을 제공함으로써 일반적인 VPN 서버보다 공격에 훨씬 더 탄력적인 보안을 제공한다.

• 차세대 방화벽(NGFW)

NGFW는 기존 방화벽의 특성에 추가기능을 갖추고 있다. 미리 정의된 규칙에 따라 네트워크 패킷을 모니터링하고 OSI 2~4 계층 정보를 사용해 데이터를 필터링한다. NGFW는 세션 계층, 프레젠테이션 계층, 애플리케이션 계층 등 5~7계층의 정보를 사용해 추가 기능을 수행한다.

NGFW는 공급업체에 따라 다음과 같은 기능을 제공한다.

- 애플리케이션 인식: 응용 프로그램을 인식해 검색할 공격 유형 결정
- 침입탐지시스템(IDS): 네트워크 보안 상태 모니터링
- 침입방지시스템(IPS): 보안 위반을 방지하기 위해 트래픽 거부
- ID 인식(사용자 및 그룹 제어): 사용자가 접근할 수 있는 리소스 관리
- VPN: 신뢰할 수 없는 네트워크에서 원격 사용자 접근 제어

NGFW는 기존 방화벽에 비해 크게 향상된 기능을 제공하지만 SDP와 비교할 때 다음과 같은 제한 사항이 있다.

- 지연 시간: IDS/IPS와 마찬가지로 네트워크 트래픽, 특히 파일 검사를 수행할 때 추가 지연 시간 발생
- 확장성: 확장하기 위해서는 높은 성능의 하드웨어 필요
- 규칙 복잡성: 일부 NGFW 공급업체는 사용자, 그룹 속성 같은 ID와 관련된 기능을 포함하지만, 기능 구현이 복잡함

SDP는 이미 배치된 NGFW를 보완할 수 있다. 기업은 SDP를 사용해 사용자 접근 정책을 보장하는 동시에 핵심 방화벽 보호에는 NGFW를, 트래픽 검사에는 IDS/IPS를 사용할 수 있다. 가시성을 ‘제로(Zero)’로 설정하고 NGFW를 동적으로 만들어 SDP와 NGFW 통합의 이점을 강화할 수 있다. NGFW를 IAM 또는 AD와 통합해 사용자 접근 정책은 시행할 수 있지만, SDP는 이 구성보다 강력한 통제를 지원해 진정한 보안 접속을 구현할 수 있다.

어떤 면에서 NGFW가 SDP와 경쟁하는 기술일 수 있다. 10년여 동안 NGFW 공급업체는 SDP가 해결하는 것과 동일한 몇 가지 문제를 해결해 왔다. NGFW와 VPN 기능을 사용자와 애플리케이션 인식과 결합함으로써 기업은 SDP의 많은 목표 중 어느 정도를 실현할 수 있다.

그러나 이 작업을 수행하는 것과 SDP를 구현하는 것에는 구조적인 차이가 있다. NGFW는 IP 기반이지만, SDP는 접속 기반이다. NGFW는 제한된 ID 중심 기능과 애플리케이션 중심 기능을 제공한다. 이들의 접근 정책 모델은 일반적으로 엄격하지 않아 사용자에게 정확히 필요한 것보다 더 광범위한 네트워크 접근을 제공할 수 있다.

NGFW는 또한 접근 결정에 외부 시스템을 포함할 수 있는 SDP보다 동적으로 대응하지 못하는 경향이 있다. 예를 들어 SDP는 승인된 변경 관리 화면으로만 임시 서버에 대한 개발자 접근을 허용할 수 있다. SDP는 일반적으로 NGFW에서 지원되지 않는 단계적 인증도 적용할 수 있다.

NGFW는 여전히 방화벽이며 종종 사이트 간 접속을 하는 전통적인 경계 중심 네트워크 아키텍처를 요구한다. SDP 구축은 일반적으로 분산되고 유연한 네트워크를 지원하므로 유연한 네트워크 분할 기능이 가능하다. SDP는 기본적으로 권한 없는 사용자와 권한 없는 디바이스로부터 권한 없는 서비스를 숨기는 화이트리스트 보안 모델을 기반으로 한다.

SDP는 SPA 및 동적 방화벽을 활용해 인증된 접속을 보호하고 숨긴다. NGFW는 일반적으로 가시성이 높은 환경에서 작동되기에 SDP보다 위험성이 높다.

• ID 및 접근 관리(IAM)

IAM 시스템은 사용자와 디바이스가 인증을 통해 신원을 확인하고 해당 ID에 대한 관리 속성과 그룹 구성원 자격을 저장할 수 있는 메커니즘을 제공한다. SDP 아키텍처는 LDAP, 액티브 디렉토리(AD), SAML과 같은 기존 엔터프라이즈 IAM 공급자와 통합되도록 설계됐다.

SDP 제어 접근은 일반적으로 IAM 속성과 그룹 멤버십을 포함한 요소, 접속에 사용되는 디바이스 속성을 기반으로 한다. 사용자, 디바이스 권한 부여 기준을 조합하면 접근 권한을 부여하거나 제한하는 세분화된 접근 규칙을 만들 수 있으므로 권한 있는 디바이스의 권한 있는 사용자가 권한 있는 응용 프로그램에 대한 권한 있는 접근만 보장할 수 있다.

IAM과 SDP를 통합하면, 초기 사용자 인증뿐만 아니라 중요한 시스템에 접근하기 위해 OTP를 요청하는 것과 같은 단계적 인증, 원격접근이나 사내 접근과 같은 특정 환경에서 사용될 수 있다. IAM 시스템은 계정 비활성화, 그룹 구성원 자격 변경, 사용자로부터의 접속 삭제 또는 사용자 역할 변경과 같은 ID 라이프사이클 작업에 대한 API 호출을 통해 SDP와 통신할 수 있다.

IAM은 SDP 내에서 사용자를 인증하고, SDP가 인증 결정을 내릴 때 사용하는 정보를 제공하며, 등록된 디바이스에서 사용자에게 부여된 모든 접근에 대해 풍부한 감사 로그를 사용하도록 하기 위해 사용된다.

네트워크 접근이나 IP 주소 기반 접근이 아닌 애플리케이션 접근 정책을 적용, 사용자가 애플리케이션에 접속하면 로깅에 유용한 접속 정보를 얻을 수 있으며 보안 또는 규정 준수를 위해 과거 접근을 감사해야 할 경우 IT 오버헤드를 크게 줄일 수 있다.

IAM 툴은 일반적으로 ID 라이프사이클을 유지하고 ID 정보가 리소스에 대한 접근을 제어하는 데 사용되는 방식을 표준화하는 비즈니스 프로세스에 초점을 맞춘다. 예를 들어 접근을 위한 프로비저닝은 사용자를 위한 메커니즘은 일반적으로 수동 프로세스와 자동화된 프로세스의 조합이다.

SDP는 IAM 툴에 의해 관리되는 ID 속성 및 그룹 멤버십에 의존하기 때문에 IAM 프로세스를 지원한다. 사용자 속성 또는 그룹 구성원 자격이 변경되면 SDP는 이러한 변경 사항을 자동으로 감지하고 IAM 프로세스를 변경하지 않고 사용자 접근을 변경한다.

SDP는 SAML과 통합된다. SDP 배치에서 SAML 제공자는 사용자 속성 또한 MFA 등 인증 공급자의 ID 제공자 역할을 할 수 있다. SAML 외에도 공개인증(OAuth), 오픈ID 커넥트(OpenID Connect), W3C 웹 어센티케이션(W3C Web Authn), FIDO 얼라이언스 클라이언트 투 어센티케이션 프로토콜(CTAP) 등 많은 개방형 인증 프로토콜을 지원한다.

• 네트워크 접근제어(NAC)

NAC는 일반적으로 네트워크에 접속할 수 있는 디바이스와 접근할 수 없는 네트워크 대상을 제어한다. 이러한 솔루션은 네트워크에 접근하기 전 표준 기반 하드웨어(802.1X)와 소프트웨어를 사용해 디바이스를 검증하고 OSI 모델의 계층 2에서 작동한다.

디바이스가 네트워크에 처음 접속할 때 NAC는 디바이스 유효성 검증을 수행한 다음 디바이스를 VLAN(네트워크 세그먼트)에 할당한다. 실제로 NAC는 소수의 네트워크에 디바이스를 할당하는 데 사용된다. 대부분의 조직은 ‘게스트’, ‘직원’, ‘프로덕션’과 같은 소수의 네트워크만 가지고 있다.

NAC는 네트워크의 계층 2에서 작동하므로 특정 네트워크 디바이스가 필요하고 클라우드 환경에서 작동하지 않으며 원격으로 사용할 수 없는 경우가 많다.

SDP는 사용자와 디바이스 접근을 통합할 수 있으며, NAC를 대체할 수 있다. 그러나 프린터, 복사기, 유선 전화, 보안 카메라와 같이 NAC를 사용하는 것이 더 적합한 환경도 있다. 이러한 디바이스에는 SDP 클라이언트 설치를 지원할 수 없다. 이러한 디바이스를 보호하고 사용자 접근을 제어하는 SDP 게이트웨이 대 게이트웨이 모델은 더 나은 옵션이며 향후 SDP 연구의 주제가 될 것이다.

• 엔드포인트 관리(EMM·MDMUEM)

많은 기업이 엔터프라이즈 모빌리티 매니지먼트(EMM), 모바일 기기 관리(MDM), 통합 엔드포인트 관리(UEM) 등 엔드포인트 관리 시스템을 활용한다. 이는 엔터프라이즈 IT와 보안의 중요한 요소이며 SDP를 통해 가치와 중요성이 증대된다.

엔드포인트 관리 시스템을 사용해 사용자 디바이스 간에 SDP 클라이언트의 배포와 설치를 자동화할 수 있다. 이러한 시스템은 SDP와 동일한 IAM 시스템을 사용하는 경우가 많기 때문에 롤아웃을 긴밀하게 조정해 사용자 환경을 간소화할 수 있다.

이러한 시스템은 기기 보호, 프로필 평가 등 풍부한 기능을 제공하는 경우가 많다. SDP는 디바이스 관리 플랫폼에 API를 호출해 특정 디바이스에 대한 정보를 얻고, 그 정보를 기반으로 동적 접근 결정을 내릴 수 있다.

엔드포인트 관리 시스템이 없는 조직은 SDP가 제공하는 디바이스의 관리 및 제어를 활용할 수 있다.

• 웹방화벽(WAF)

WAF는 웹 애플리케이션 간 HTTP(S) 웹 트래픽을 필터링, 모니터링, 차단하도록 설계됐다. WAF는 애플리케이션 프로토콜 트래픽을 검사해 SQL 인젝션, 크로스 사이트 스크립팅(XSS), 파일 인클루전과 같은 애플리케이션 보안 결함의 공격을 차단한다.

WAF는 IDS/IPS와 유사한 방식으로 사용자와 애플리케이션 네트워크에서 인라인 방식으로 작동하지만, 네트워크 접근 제어 또는 네트워크 보안 솔루션이 아니다. WAF는 주로 HTTP(S) 프로토콜 트래픽을 검사해 악의적인 콘텐츠를 탐지하고 차단한다.

WAF는 SDP와 보완적인 관계다. 예를 들어 클라이언트 투 게이트웨이 모델에서 WAF는 SDP 게이트웨이 뒤에 배치되어 SDP mTLS 터널에서 추출된 기본 웹 애플리케이션 트래픽에서 작동한다. 클라이언트 투 서버, 서버 투 서버 모델에서 WAF는 서버의 SDP 게이트웨이와 통합돼 HTTP(S) 트래픽 검사를 분산적으로 제어할 수 있다.

• 로드 밸런서(Load Balancers)

로드 밸런서는 많은 네트워크 및 애플리케이션 아키텍처의 일부이다. 로드 밸런싱 디바이스에는 DNS 및 네트워크 기반 솔루션이 포함되며, 설계자는 SDP 구축을 계획할 때 조직에서 이러한 솔루션을 어떻게 사용하는지 이해해야 한다.

예를 들어 네트워크 기반 로드 밸런서는 네트워크, 클라이언트와 서버 간에 인라인으로 배치되며, 위의 WAF 논의와 유사하게 SDP 구성요소 간의 mTLS 접속을 검사하지 못할 수 있다. SDP 구축 및 로드 밸런싱 접근법의 구체적인 내용은 SDP를 최대한 활용할 수 있도록 세심한 분석이 필요하다.

• 클라우드 접근 보안 브로커(CASB)

CASB는 클라우드 서비스 사용자와 클라우드 애플리케이션 사이에 배치되며 보안 정책 시행과 관련된 모든 활동을 모니터링한다. 사용자 작업 모니터링, 잠재적으로 위험한 작업에 대한 경고, 보안 정책 규정 준수 적용, 악성소프트웨어 자동 차단 등의 서비스를 제공한다. CASB는 공급업체 및 SaaS 플랫폼 내 API 지원 수준에 따라 사용자와 클라우드 서비스 사이에 배치하거나, SaaS API를 사용해 SaaS 내부에 배치될 수 있다.

CASB 기능은 애플리케이션 트래픽을 검사하는 애플리케이션 계층에서 작동하기 때문에 SDP의 기능과 중복되지 않는다. CASB는 네트워크 보안 또는 접근 제어를 제공하지 않지만, SDP를 사용해 데이터 보호와 사용자 행동 분석을 통해 운영을 간소화할 수 있다.

• 서비스형 인프라(IaaS)

IaaS 플랫폼 보안은 클라우드 공급자가 특정 영역의 책임을 지고, 고객은 클라우드 내 애플리케이션에 대해 책임지는 업계 표준 책임 공유 모델을 기반으로 구축된다. IaaS 고객은 클라우드 네트워크 보안 그룹을 사용해 클라우드 리소스에 대한 접근을 제어한다. 이러한 네트워크 보안 그룹은 단순한 방화벽으로 구성되고 작동한다. 이러한 보안 수단을 SDP와 통합해 훨씬 강력한 보안 환경을 구축할 수 있다.

• 서비스형 소프트웨어(SaaS)

세일즈포스, 오피스 365와 같은 SaaS 애플리케이션은 멀티테넌트이며, 인터넷에서 공개적으로 접근할 수 있다. 권한 없는 사용자의 네트워크 수준 접근을 방지하는 것은 SaaS의 목표가 아니다. SaaS를 사용할 때 조직은 다음과 같은 보안 문제를 해결해야 한다.

- 인증된 기기에서 인증된 사용자만 특정 조직의 SaaS 테넌트에 접근할 수 있도록 보장
- 관리되는 회사 IAM 자격 증명을 사용해 SaaS 응용 프로그램을 인증하는지 확인
- SaaS 애플리케이션 접근을 위한 다중 요소 인증 적용
- SaaS 애플리케이션에 대한 모든 사용자 방문 확인 및 기록 확인

점점 더 많은 SaaS 공급업체들이 엔터프라이즈 고객이 이러한 장점을 원한다는 것을 인식하고 ‘소스 IP 주소 및 디바이스제한’ 기능을 포함하기 시작했다. 이러한 기능은 SDP 및 기존 VPN과 동일하게 작동하며, SaaS 고객은 특정 IP 주소를 통해 도메인(테넌트)에 대한 사용자 접근(로그인 및 사용)을 제한할 수 있다. SDP의 경우 해당 소스 IP는 사용자 트래픽이 라우팅되고 승인되거나 거부되는 시스템(게이트웨이)의요소다.

• 서비스형 플랫폼(PaaS)

PaaS 오퍼링을 통해 기업은 표준 하드웨어 또는 IaaS 기반 시스템보다 오버헤드가 적은 맞춤형 애플리케이션을 구축하고 구현할 수 있다. IaaS·SaaS와 달리 PaaS에 대한 네트워크 접근 제어 혹은 SDP가 관련되는 정도는 제공된 기능과 PaaS 공급자가 외부 접근 제어를 가능하게 한 방법에 따라달라진다.

주요 PaaS 공급업체는 IaaS 플랫폼과 동일한 네트워크 보안 모델을 지원한다. 예를 들어 마이크로소프트 애저 PaaS 보안 모델은 애저 네트워크 보안 그룹을 통해 소스 IP 주소 제한을 지원한다. 구글 클라우드 플랫폼 앱 엔진, AWS 엘라스틱 빈스톡도 마찬가지다. PaaS 애플리케이션이 무엇이고 어떤 접속을 보안해야 하는지에 따라 다양한 SDP 모델을 배치할 수 있다

• 거버넌스, 리스크, 컴플라이언스(GRC)

리스크 관리 및 규정 준수 원칙을 통해 조직은 보안 목표를 실현하고 무결성을 유지하도록 지원한다. GRC 소프트웨어를 통해 구현되는 GRC 시스템은 일반적으로 SOX, PCI 등 표준과 지침을 통해 IT를 포함한 많은 조직 시스템에 대한 제어를 정의하고 시행한다.

SDP는 GRC에 필요한 접근 제어를 적용하고 문서화해 GRC 시스템과 상호 작용하고 지원할 수 있다. 예를 들어, GRC 시스템은 비생산 시스템과 격리돼야 하고, 생산 시스템에 대한 모든 사용자 접근을 기록해야 할 수 있다. SDP는 이 네트워크 분할을 시행할 수 있으며 GRC 시스템에 유효성 검사를 위한 감사 로그를 제공할 수 있다.

• 공개 키 인프라(PKI)

PKI는 디지털 인증서를 생성, 관리, 배포, 사용, 저장 및 폐기하고 암호화, 암호 해독, 해싱 및 서명에 사용되는 개인 및 공용 키를 관리하는 데 필요한 역할, 정책 및 절차의 집합이다. SDP는 TLS 인증서 및 보안 접속을 생성하기 위해 PKI를 사용할 수 있다. PKI 인프라가 없는 경우에도 SDP는 안전한 접속을 위해 TLS 인증서를 제공할 수 있다.

기존 PKI는 SDP 인증서 생성과 사용자 인증에 선택적으로 사용할 수 있기 때문에 SDP에 자연스럽게 통합할 수 있다.

• 소프트웨어 정의 네트워킹(SDN)

SDN은 IT 네트워크 내에서 네트워크 라우팅을 통합하는 데 사용되는 API 기반의 오케스트레이션이다. SDN은 성능 및 모니터링을 개선하기 위해 효율적인 네트워크 구성을 지원한다. SDN의 초점은 보안·인증이 아니라 트래픽 효율성이다. 제대로 실행되는 SDN은 기업에 안정적이고 효율적이며 적응력이 뛰어난 네트워크 대역폭을 제공한다.

SDP는 기본 네트워크 인프라에 관계없이 네트워크의 개체 간 접속 오케스트레이션을 제공한다. SDP는 SDN의 구축으로 이득을 얻기 위해 통합될 수 있지만, SDN은 필요하지 않다. 예를 들어 SDP와 SDN 컨트롤러를 통합할 수 있다. 또한 SDN은 난독화 되고 암호화된 mTLS 접속을 위한 네트워크 QoS(서비스 품질)를 제공할 수 있다.

• 서버리스 컴퓨팅

컴퓨팅 모델이 발전함에 따라 보안 툴과 아키텍처도 함께 발전해야 한다. 하나의 예로 클라우드 공급자가 사용자 정의 코드(FaaS) 또는 사전 빌드된 코드 세트(서버리스 데이터베이스)를 실행할 수 있도록 제공하는 서버리스 컴퓨팅 모델이 성장하는 것이다.

FaaS 모델은 공용 단말기를 전체 인터넷에 노출시키고 API 키를 사용해 인증과 인가를 제어할 수 있다. 이 경우는 접속이 공개되도록 설계됐기 때문에 SDP 모델은 이러한 모델에는 적용되지 않을 것이다. 그러나 다른 서비스나 다른 클라우드 제공자는 각 고객이 ‘As a Service’ 기능을 위한 전용 액세스 포인트를 필요로 할 수 있다. 이 모델에서는 SDP 게이트웨이를 통해 프라이빗 액세스 포인트를 보호하는 데 SDP를 적용할 수 있다.

아키텍처상의 고려 사항

SDP는 광범위한 네트워크 접근 시나리오를 지원하지만 모든 보안 문제를 해결하지는 않는다. 다음 항목들은 SDP 지원 범위에서 제외된다.

- 인증이 필요하지 않은 웹 사이트와 같은 공용 네트워크 서비스에 대한 접근 보안 또는 제어
- SDP는 멤버십 기반 서비스에 보다 적합
- 엔드포인트 보호
- 서버리스 컴퓨팅과 같은 특정 컴퓨팅 모델
- SDP 구축 모델에 따라 피어 투 피어와 같은 특정 네트워크 접속 토폴로지

정보 보안은 오늘날의 기업과 정부기관에 매우 중대한 보안과제이므로 조직의 데이터 자산을 보호기 위해 보다 효과적인 접근 방식을 채택해야 한다. SDP 접근 방식은 조직의 보안 전문가에게 개발, 운영 및 보안을 위한 강력하고 접근성이 용이하며 관리 가능한 기반을 제공하기 위해 솔루션을 제공할 수 있다.

한편 클라우드 보안 연합(CSA)은 개별 SDP 구축 모델과 통합에 대한 가이드, 다양한 비즈니스에 대한 SDP의 장점 상세화, SDP 구축을 기반으로 한 규정준수 통제 솔루션 등 다양한 연구를 제공할 계획이다.

CSA SDP 워킹그룹에 가입해 연구에 참여하고 발전을 위해 기여해주기 바란다. 워킹그룹에서 안전하고 개방적이며 이용 가능한 인터넷을 지원하는 보안 전문가로서, 윤리적으로 동기부여를 받은 사람으로서, 더 나은 미래를 위해 노력할 기회를 갖길 바란다



댓글삭제
삭제한 댓글은 다시 복구할 수 없습니다.
그래도 삭제하시겠습니까?
댓글 0
댓글쓰기
계정을 선택하시면 로그인·계정인증을 통해
댓글을 남기실 수 있습니다.