현재 기업들은 20년 전과 거의 동일한 방식(VPN, 프록시, 원격 데스크톱 등)으로 직원들과 써드파티 사용자들에게 애플리케이션에 대한 원격 접속을 제공하고 있습니다. 이런 방식을 사용할 경우 먼저 사용자와 디바이스를 신뢰할 수 있는지 확인한 다음에 네트워크 보안 경계를 통해 사용자가 요청하는 리소스에 접속을 제공합니다. 기존에는 보호해야 하는 자산이 Trusted Zone(보안 영역)에 위치했고 자산에 대한 접속은 Untrusted Zone(신뢰할 수 없는 외부 인터넷)에서 발생했습니다.
이렇게 외부에서 내부로 들어오는 접속은 방화벽을 통과해야 합니다. 많은 기업들은 이 방화벽 경계가 공격에 특히 취약하다는 점을 잘 인식하고 있음에도 불구하고 기존의 방식을 그대로 유지하고있는 것이 현실입니다.
하지만 이제 새로운 트렌드와 환경 변화로 인해 다른 방법을 모색할 수 밖에 없습니다. 써드파티 사용자 접속으로 인한 대규모 보안 사고가 빈번하게 발생하고 있기 때문에 새로운 써드파티 접속 솔루션의 필요성이 더욱 부각되고 있습니다. 새로운 접속 솔루션을 구현하려면 먼저 기업 환경을 둘러싼 5가지 핵심 트렌드인 파트너 에코시스템의 성장, 모바일 디바이스의 확대, 클라우드화로 인한 어려움, 제로 트러스트 모델 도입, IT 애플리케이션의 SaaS화를 정확하게 이해해야 합니다.

1. 파트너·써드파티 에코시스템의 성장
비즈니스를 성장시켜 나가기 위해 파트너, 협력업체, 공급업체, 프랜차이즈 가맹점, 기타 써드파티와 협력하는 기업들이 점차 증가하고 있습니다. 써드파티 협력업체 사용자들에게 필요에 따라 네트워크 접속을 허용하는 기업들도 있고 서비스를 전적으로 아웃소싱한 경우 지속적으로 접속을 허용하기도 합니다. 이런 파트너사들은 기업 네트워크 외부에서 인터넷을 통해 기업 애플리케이션에 접속합니다.
기업 에코시스템에 새로운 파트너가 추가되고 외부에서 내부 애플리케이션으로 접속해 필요한 리소스를 사용하는 파트너가 증가하면서 접속에 대한 룰을 방화벽에 적용해야 합니다. 애플리케이션과 리소스가 여러 곳에 걸쳐 분산되어 있는 경우 각각의 지역에 동일한 룰을 구현해야 합니다. 이는 오래전부터 계속된 문제인데 Network World는 2004년 “방화벽에 너무 많은 홀(hole)이 존재해 실제로 방어 역할을 거의 하지 못한다”고 언급했습니다.
이후 상황은 더 악화됐고 보안 유출로 인한 피해 역시 언론에 보도되기 시작했습니다. Target 데이터 유출 사고의 근본 원인은 네트워크 접속이었습니다. Target 네트워크에 접속 권한이 있었던 HVAC 협력업체가 해킹을 당했고 공격자들은 Target의 핵심 시스템에 접속할 수 있었습니다. 기업들은 IDS/IPS, DLP, WAF 등을 통과하는 공격자를 파악하고 보안 경계가 침투되는 것에 대응하기 위해 보안 레이어를 지속적으로 추가해 왔습니다. 하지만 레이어가 추가될 때마다 복잡성이 가중되고 관리해야 하는 정책 역시 늘어났지만 그럼에도 불구하고(혹은 이런 복잡성으로 인해) 보안 경계는 여전히 공격에 취약한 상태로 남아 있습니다.
네트워크가 침투되는 문제를 해결하려면 새로운 접속 방식이 필요합니다. 보안의 기본은 ‘최소 권한의 원칙’인데 사용자가 업무를 수행할 때 필요한 최소한의 리소스에만 접속을 허용하는 것입니다. 하지만 VPN과 원격 데스크톱 등 기존의 접속 방법은 네트워크상의 모든 리소스에 대해 디폴트로 광범위한 접속을 허용하고 있습니다. 결과적으로 사용자 디바이스에 존재하는 멀웨어가 접속이 허용되는 한도 내에서 자유롭게 네트워크에 침투할 수 있게 됩니다. 기업들은 네트워크에 대한 광범위한 접속을 차단하고 파트너들이 업무를 수행하는데 반드시 필요한 리소스에만 접속을 허용하는 새로운 접속 솔루션을 도입해야 합니다.

2. 모바일 디바이스의 확대
2014년 모바일 디바이스 대수는 72억 개를 넘으면서 전세계 인구수를 넘어섰습니다. 또한 모바일 디바이스는 전세계 인구보다 5배 더 빠른 속도로 증가하고 있습니다. 내부 리소스 접속에 대한 보안 업무를 담당하고 있는 사내 보안팀에게 모바일 디바이스의 급증은 부담스러울 수밖에 없습니다.
기업들은 지난 15년 동안 모바일 디바이스의 급증과 BYOD에 대응하기 위해 모바일 디바이스가 Trusted Zone에 안전하게 접속할 수 있는 방법에 대해 고민해 왔습니다.  

NAC(Network Access Control) 기술과 비교적 최신 기술인 MDM(Mobile Device Management) 또는 EMM(Enterprise Mobility Management) 등은 디바이스에 클라이언트와 인증서를 설치함으로써 사용자와 디바이스의 신뢰성을 높일 수 있는 방법입니다. 이는 기존의 보안 경계 내부로 사용자를 포함시키는 것이 아니라 기업의 보안 경계를 확장해 외부 사용자를 포함시키는 방법입니다. 하지만 이런 기술은 실행 및 관리가 복잡할 뿐만 아니라 Stagefright와 같은 멀웨어가 디바이스를 장악해 보안 신뢰성을 완전히 무너뜨릴 수도 있습니다.

결국, NAC,MDM, EMM 등의 기술은 기대에 부응하지 못했습니다.  보안 경계를 확장하는 방식은 복잡성을 높이고 IT 부서의 업무 부담을 가중시킴으로써 결국 기업의 보안이 취약해지는 결과를 가져왔습니다. 인터넷 연결 디바이스가 급증하고 있는 상황에서 사용자 디바이스의 신뢰성을 확보하려는 시도는 점차 어려워지고 있습니다. 따라서, 디바이스의 신뢰성에 전적으로 의존하지 않는 새로운 모델이 필요합니다.

3. 클라우드화로 인한 어려움
클라우드 컴퓨팅은 이제 확실한 트렌드로 자리 잡았습니다. IDG에 따르면 퍼블릭 클라우드 컴퓨팅 서비스를 사용하는 기업은 2012년 57%에서 2014년 69%로 크게 증가했습니다. 클라우드 컴퓨팅 서비스(AWS, Microsoft Azure, IBM Softlayer 등)와 기존의 가상화된 기업 인프라를 통합하는 하이브리드 클라우드의 도입률은 향후 3년간 3배 이상 증가할 것으로 전망됩니다. 대부분의 기업들이 하이브리드 클라우드 전략을 채택하고 있고, Time, Inc., Yamaha와 같은 일부 기업은 사설 데이터센터를 없애고 100% 클라우드로 마이그레이션하기로 결정했습니다.
클라우드로 이동하면 신속성, 유연성, 비용 등 여러 측면에서 장점이 있지만 다음과 같은 2가지 문제점에 직면하게 됩니다.
첫째, 클라우드의 네트워크 구성 요소와 서버를 세밀하게 관리할 수 없습니다. 즉, 클라우드 인프라는 사설 데이터센터와 다른 방식으로 구축해야 합니다. 둘째, 사용자들은 물리적으로 ‘클라우드’에 존재하지 않습니다. 클라우드 네트워크 상에 존재하는 사용자는 아무도 없고, 사용자는 인터넷을 통해 클라우드에 존재하는 애플리케이션에 접속합니다.
클라우드는 끊임 없이 변화하는 여러 개의 환경으로 구성되어 있습니다. 하나의 클라우드만 사용하는 기업은 거의 없습니다. 대부분의 기업은 AWS가 VPC(Virtual Private Cloud∙가상 프라이빗 클라우드)라 명명한 클라우드를 다수 사용하고 있습니다. 기존의 데이터 센터와 달리 VPC는 몇 분 안에 구축 및 해제가 가능하며, 각각의 VPC 는 개별적인 방화벽과 네트워크를 갖고 있습니다. 기존의 접속 솔루션은 VPC마다 별도의 보안 및 접속 정책을 관리해야 했습니다. 예를 들어, VPN을 통해 접속이 이루어진 경우 클라우드마다 터미네이션 포인트가 필요합니다. 사용자는 디바이스에서 여러 개의 VPN을 실행해야 하고, 특정 VPC에 접속하려면 어떤 VPN을 사용해야 하는지, 특정 애플리케이션은 어느 VPC 에서 실행되는지를 파악해야 했습니다. VPC사이를 연결하는 오버레이 WAN을 구축하고 다수의 인터넷 브레이크아웃 포인트에 대한 접속을 통합하는 것이 하나의 대안이 될 수 있습니다. 하지만 장비를 구매하는데 드는 비용, 설계, 배치, 트러블슈팅에 많은 인건비를 지출해야 합니다. 따라서 VPN과 오버레이 WAN 모두 실용적인 대안이 될 수 없습니다.
클라우드가 주류로 자리잡으면서 사용자들의 위치에 상관없이 애플리케이션에 접속할 수 있고, IT 팀이 애플리케이션의 위치에 상관없이 접속 정책과 보안을 관리할 수 있는 솔루션이 필요하게 됐습니다. 또한, 사용자와 리소스 사이의 인프라 의존성을 제거할 수 있는 접속 아키텍처가 필요해졌습니다.

4. 제로 트러스트 모델(zero-trust model) 도입
사용자의 신원을 정확하게 파악해야 신뢰할 수 있는 사용자인지 판단이 가능합니다. 사용자 인증 정보는 신뢰성을 구축하는데 핵심 요소입니다. 하지만 처음엔 신뢰할 수 있었던 사용자도 중간에 더이상 신뢰할 수 없게 될 수 있습니다. 사용자 이름과 암호로 구성된 인증정보를 투팩터(이중 인증) 혹은 멀티팩터(다중인증)로 강화하거나 탄력적인 접속 정책을 적용하면 인증정보가 도용되었을 때 사용자 신원을 확인하는데 도움이 될 수 있습니다. 하지만 Heartbleed 취약점이나 최근 발생한 Stagefright 사고는 특허의 허점이나 운영 체제가 모르는 사이에 장악될 수 있다는 우려 때문에 사용자 디바이스에 대한 신뢰성에 대해 재고하는 기회로 작용했습니다.
VPN같은 기존의 접속 모델은 사용자가 네트워크 방화벽을 통과해 접속할 수 있도록 허용하기 때문에 모든 사용자와 디바이스를 신뢰할 수 없다고 가정할 경우 더이상 사용할 수 없게 됩니다. 제로트러스트 모델은 기본적으로 모든사용자를 신뢰할 수 없다고 간주하기 때문에 신뢰할 수 없는 사용자에게 내부 네트워크에 대한 접속 권한을 줄 경우 큰 보안 리스크를 떠안게 됩니다. 새로운 접속 아키텍처는 모든 사용자를 신뢰할 수 없다는 가정에서 시작되고 특정 사용자에 대한 신뢰성 역시 최소한의 기간 동안 한시적으로 유지됩니다.
이런 접속 방식을 확장해 보면 사용자들이 내부 네트워크를 통해 애플리케이션이나 데이터에 접속하는 대신 사용자들이 요청하는 애플리케이션만 선택적으로 접속을 허용하는 모델을 도출할 수 있습니다. 새로운 접속 아키텍처는 관리자를 제외한 어떤 사용자도 내부 네트워크에 접속하지 못하도록 차단하고 애플리케이션과 사용자를 분리합니다.

5. IT 애플리케이션의 'SaaS화'
SaaS는 이제 우리 생활의 일부가 되었습니다. 디바이스나 위치에 상관없이 쉽게 접속할 수 있는 Facebook, Gmail, Uber 같은 애플리케이션이 대표적인 예입니다. SaaS는 비즈니스 분야에서도 광범위하게 사용되고 있습니다. 많은 기업들이 쉽고 간편하게 Salesforce.com, Workday, Microsoft Office 365 등과 같은 애플리케이션을 사용하고 있습니다. 과거 소비자화가 진행될 때와 마찬가지로 SaaS화 역시 사용자 기대치가 점차 높아지고 있습니다.
기업의 SaaS 도입률은 가파르게 증가하고 있지만 실제로 기업에서 자체적으로 개발한 내부 애플리케이션(Private Application) 개수를 살펴보면 모든 애플리케이션이 빠른 시일 내에SaaS로 이동할 가능성은 매우 낮아 보입니다. 하지만 사용자들은 SaaS 애플리케이션 혹은 SaaS가 아닌 기업 내부 애플리케이션에 접속할 때 모두 동일한 성능을 기대하고 있으며 사용자 위치나 디바이스에 상관없이 VPN이나 클라이언트 소프트웨어를 설치하지 않고 항상 애플리케이션에 접속하고 싶어 합니다.
하지만 SaaS애플리케이션과 동일한 성능을 전송하는 것은 생각보다 상당히 어렵습니다. SaaS는 기존의 경계에 대한 보안 조치를 적용할 뿐만 아니라 애플리케이션을 프론트엔드에 배치해야 하고 DDoS 공격을 방어해야 합니다. 또한, 성능 문제나 지연(latency) 문제를 해결할 수 있는 가속 기능을 제공하고 특정 애플리케이션 레이어 공격 역시 방어해야 합니다.
새로운 접속 아키텍처는 사내 애플리케이션에 대해 SaaS 애플리케이션과 동일한 성능 및 보안을 확보하고 사용자의 높은 기대치에 부합해야 합니다.

6. 새로운 접속 아키텍처
이런 5가지 근본적인 변화에 대응하려면 사내 애플리케이션에 접속할 수 있는 새로운 아키텍처가 필요합니다. 사내 애플리케이션은 프라이빗 데이터센터 혹은 퍼블릭 클라우드 컴퓨팅 환경 등 실행되는 위치에 상관없이 기존의 접속 방식보다 보안과 편의성이 한층 강화된 방식으로 고객, 파트너, 협력업체에 애플리케이션이 전송되어야 합니다.
현재 기업이 요구하는 새로운 접속 아키텍처는 다음과 같습니다.
• 전체 네트워크에 대한 접속을 허용하는 대신 사용자들이 업무를 수행하는데 필요한 최소한의 애플리케이션에만 접속 허용
• 각각의 디바이스별로 신뢰성을 확인하고 최소한의 기간 동안만 신뢰성을 유지
• 사용자와 리소스 사이에 존재하는 인프라에 대한 의존성 제거
• SaaS 애플리케이션과 동일한 성능 및 사용자 경험을 사내 애플리케이션에도 전송

출처: ComputerWeekly.com