loading...

클라우드의 시작과 끝, 클라우드 보안

클라우드의 시작과 끝, 클라우드 보안

보안, 클라우드 도입의 걸림돌?

보안은 클라우드 전환을 주저하게 만드는 가장 큰 원인입니다. ‘21년 KDI 경제정보센터에서 국내 기업을 대상으로 클라우드 도입 시 장애 요인에 대해 조사한 결과 응답한 기업의 52.5%가 데이터 유출 등 보안 문제를 꼽았습니다. 하지만 반대로 보안에 문제만 없다면 얼마든지 클라우드 전환을 가속할 수도 있다는 의미이기도 합니다. 본 리포트에서는 클라우드 전환 과정을 3개의 단계로 나누고, 각 단계에서 고려해야 하는 클라우드 보안은 어떤 것들이 있는지 살펴보도록 하겠습니다.

클라우드 보안의 단계적 접근

클라우드 전환 초창기 - 소규모 workload가 시범적으로 전환되는 시기
  • legacy security -> legacy security
  • legacy workload -> legacy workload
  • on-premise -> cloud infra
클라우드 전환 과도기 - 주요 workload가 전환되는 시기
  • legacy security -> legacy security
  • legacy workload -> cloud native appl.
  • cloud infra -> cloud infra
클라우드 전환 정착기 - workload가 클라우드에서 최초 개발/구축되는 시기
  • legacy security -> cloud native security
  • cloud native appl. -> cloud native appl.
  • cloud infra -> cloud infra
[그림 1] 클라우드 보안의 단계적 접근

기업의 클라우드 인프라 전환 단계는 크게 ‘초창기’, ‘과도기’, ‘정착기’ 3단계로 나누어 볼 수 있습니다. 클라우드 전환 초창기는 기업의 업무 시스템 중 규모가 작고 중요도가 낮은 시스템 위주로 시범적으로 전환되는 시기입니다. 이 경우는 일부 인프라만 클라우드로 전환된 상태로 대부분의 보안 위협이 Legacy와 동일하기 때문에 기존 보안 솔루션과 수작업에 의한 보안 진단을 통해 대응 가능합니다.

그러나 시범 적용 단계였던 초창기가 지나고 기업의 주요 업무 시스템의 일부 또는 전체가 클라우드로 전환되는 과도기의 경우, 워크로드의 일부 또는 전체를 클라우드 특성에 맞게 재개발하게 되고 개발 방법론도 DevSecOps와 CI/CD 체계로 전환됨에 따라 Legacy 환경처럼 수작업에 의한 보안 관리로는 취약점의 발견과 조치가 어려워집니다.

마지막으로 클라우드 전환 정착기는 모든 워크로드가 처음부터 클라우드상에서 개발되는 단계를 의미합니다. 정착기는 Legacy와는 다른 클라우드를 위한 보안이 필요한 시기입니다. CSP Native 보안 기능을 활용하거나 3rd Party 클라우드 보안 솔루션을 적절하게 활용할 수 있어야 합니다. 단계별로 보안 이슈에 대해 좀 더 상세히 다루어 보도록 하겠습니다.

클라우드 전환 초창기

초창기의 가장 큰 보안 위협은 보안 정책과 진단 부재에 의한 혼란입니다. 이 시기 클라우드 시범 적용은 Best Practice를 만들어 이후 다른 업무 시스템 전환에 적용하기 위함인데, 보안이 누락된 상태로 만들어진 BP는 초창기는 물론, 이후 클라우드 전환의 모든 과정을 위태롭게 만들 수 있습니다.

클라우드 도입 단계에서 가장 먼저 착수해야 할 일은 클라우드 특성이 반영된 보안 정책을 선제적으로 수립 및 배포함으로써 이후의 혼선을 미연에 방지하는 것입니다. 통상 클라우드 보안 정책은 기존 Legacy 환경의 보안 정책에 기반하여 일부 고유명사만 클라우드 용어로 바꾸어 수립하는 경우가 많습니다. 하지만 클라우드 보안은 관점의 변화를 요구하는 것으로서, 클라우드 인프라 특성에 맞는 보안 정책이 필요합니다.

보안 정책은 클라우드 인프라 생성과 폐기가 기존 Legacy와는 달리 상시 생성/폐기가 가능함을 고려해야 합니다. 클라우드는 인프라의 구매/설치 과정이 필요했던 Legacy와는 달리 법인카드, 세금계산서만으로도 즉시 사용 가능하기 때문에 기업 내부의 누구나 언제든 새로운 인프라를 클라우드상에 구축할 수 있습니다. 마찬가지로 운영과정에서 필요에 따라 클라우드 리소스 부분 폐기가 상시 발생할 수 있습니다. 이 과정에서 관리 대상에서 누락되는 Shadow IT가 발생하지 않도록 심사/승인 절차를 마련하고 보안부서를 포함한 모든 유관부서에 통보될 수 있도록 해야 합니다.

외부 침해 대응 및 취약점 진단 가이드를 마련할 때에도 클라우드의 특성을 고려해야 합니다. 클라우드를 도입하는 경우 외부 공격에 의한 침해 대응 외 내부자의 실수 또는 고의에 의해 발생하는 보안 사고 가능성을 인정하고 이를 탐지, 대응하는 절차를 마련해야 합니다. Legacy 환경의 경우 관리자가 물리적 인프라가 구축된 내부에서만 접속하도록 제한할 수 있지만 클라우드는 인터넷이 되는 곳이라면 어디서든 관리자가 접속할 수 있기 때문입니다. 또한 CSP 특성에 맞는 취약점 진단 기준을 새로 수립해야 하는데 CSP 콘솔을 통해 인프라 생성/삭제와 보안 기능의 설정/해제까지 가능하므로 각 CSP 콘솔의 기능을 클릭하는 순서까지 정확히 기재된 보안 진단과 조치 가이드가 제공되어야 합니다.

클라우드 전환 과도기

과도기는 주요 업무시스템이 클라우드로 전환되는 만큼 구성원 대부분이 클라우드를 접하게 되는 시기로서, 개발자 주도의 빠른 개발 및 배포를 위해 DevSecOps와 컨테이너가 적극 활용되는 시기입니다. 이에 보조를 맞추어 자동화된 보안 도구와 클라우드 보안 역량을 갖추는 것이 중요합니다.

보안의 관점에서 컨네이너가 VM 또는 물리 서버와 다른 가장 큰 차이점은 배포의 용이성에 의한 짧은 LifeCycle입니다. 통상 물리서버는 내구연한 5년 정도, VM이라면 수개월에서 수년 정도이지만 컨테이너는 몇 분, 몇 시간, 며칠 정도의 짧은 LifeCycle을 갖습니다.

Legacy
  • Appl. / Appl. /Appl.
  • Library
  • Host OS
  • Hardware
  • 물리 장비의 교체 시 재구축 - 통상 5년+
Virtualized
  • Appl. / Appl. / Appl. / Appl.
  • Library / Library
  • Guest OS / Guest OS
  • VM / VM
  • Host OS / Hyperviser
  • Hardware
  • 논리 아케텍처 변경 시 재구축 - 통상 수개월 ~ 수년
Container
  • Appl. / Appl. / Appl.
  • Library / Library / Library
  • Container / Container / Container
  • Host OS / Container Runtime
  • Hardware
  • 개발 및 배포 시점 마다 재구성 - 분/시간 ~ 일일 단위 이하
[그림 2] 클라우드 인프라의 변화

컨네이너 이미지의 경우 내부 개발자에 의해 만들어지는 경우도 있지만 이미 누군가 만들어둔 컨테이너를 다량으로 사용해야 빨라진 개발 속도를 맞출 수 있는 경우가 많습니다. 그러나 인터넷 상에 유통되는 컨테이너 이미지에는 다수의 취약점도 발견되고는 합니다.

2020年 Prevasio에서 Container 이미지가 가장 많이 유통되는 Docker Hub를 조사한 결과, CVE (Common Vulnerability & Exposures) 기준 9.0 이상의 Critical 취약점을 갖는 경우가 51% 이상이며, 취약점이 존재하지 않는 Container 이미지는 20%에 지나지 않았습니다. 특히 1% 가량의 컨테이너 이미지에서는 가상화폐 채굴기, 해킹 도구 등이 발견되었는데, Legacy나 VM의 단계였다면 수년 또는 수개월에 한 번 감수할만한 위험이었을 수 있으나 컨테이너의 짧은 LifeCycle을 감안한다면 매일 같이 직면하는 위험이 되는 것입니다.

또한 클라우드의 장점이었던 탄력성은 보안 관점에서는 기준 정보가 유동적이라는 어려움으로 작용합니다. 따라서 Legacy 환경처럼 수작업에 의한 보안 관리로는 취약점을 발견하고 조치하는 것이 어려워지기 때문에 자동화된 클라우드 보안 솔루션이 필수입니다. CSPM (Cloud Security Posture Management), CWPP (Cloud Workload Protection Platform)와 같은 클라우드 보안 솔루션이 유용하게 활용될 수 있습니다.

CSPM은 클라우드의 Misconfiguration을 탐지하기 위한 솔루션입니다. 클라우드의 모든 인프라와 보안 설정은 콘솔을 통해 이루어지는데 이를 취약하게 설정하거나 Default 상태로 방치하는 것을 Misconfiguration이라고 하며, 클라우드 보안 사고의 가장 큰 원인으로 지목되고 있습니다.

CSPM을 도입하면 미리 등록해둔 보안 정책을 기준으로 상시 자동 진단함으로써 Misconfiguration을 최소화하고, 보안 담당자 외에도 개발자, 운영자들이 상시 진단 내용을 확인할 수 있도록 진단 결과를 제공하여 보안 담당자가 인지하고 통지하는 방식보다 빠르게 취약점 조치가 가능합니다.

CWPP는 컨테이너 환경에 특화된 보안 솔루션으로 Registry에 등록되었거나 신규로 등록되는 컨테이너 이미지의 알려진 취약점을 진단하고, 체크리스트 기반으로 컨테이너가 구동되는 Docker, K8s, VM Instance 등을 Run-time 진단합니다.

기업은 CWPP에 의해 진단 및 조치되지 않은 이미지를 배포하지 못하도록 강제하는 프로세스를 수립하고, 내부 개발자가 만든 컨테이너 이미지와 외부에서 반입한 컨테이너 이미지를 나누어 관리함으로써 클라우드 보안을 강화할 수 있습니다.

클라우드 전환 정착기

모든 워크로드가 클라우드상에서 개발되는 정착기에는 CSP Native 보안 기능 적용을 적극 검토하게 됩니다. CSP Native 보안 기능은 최근 클라우드 보안에서 각광을 받는 주제로서 비용 효율성, 가용성, 탄력성, 도입 및 전환 속도 면에서 3rd Party 대비 우위에 있습니다.

  • 비용 효율성 - csp native는 초기 투자 비용이 없으며 사용한 만큼 지불 할 수 있음
  • 가용성 - csp native는 csp가 SLA를 보상하며, 고객의 운영 부담이 낮음
  • 탄력성 - csp native는 사용량 증감에 따라 csp가 자동으로 resource를 조절함
  • 도입 및 전환 속도 - csp native 보안 기능은 구매 / 설치 등의 절차가 불필요함
  • multi 클라우드 - 3rd party ISV는 모든 csp에 동일 솔루션 적용 및 관리 가능함
  • Hybird 클라우드 - 3rd party ISV는 on-premise 까지 동일 솔루션 적용 및 관리 가능함
  • 난이도 및 기술지원 - 3rd party ISV는 각 솔루션 제조사의 기술지원을 받기 용이함
비교 우위
  • csp native
  • csp native
  • csp native
  • csp native
  • 3rd party ISV
  • 3rd party ISV
  • 3rd party ISV
[그림 3] CSP Native vs 3rd Party 보안 솔루션 비교

CSP Native 보안 기능은 호출 횟수당, 또는 사용할 때만 지불하는 Pay-per-use 방식으로 비용 효율적이며, 별도의 계약과 구매 프로세스 없이 CSP 콘솔에서 클릭 몇 번만으로 즉시 사용할 수도 있습니다. 또한 Full-Managed로 제공되기 때문에 장애에 대한 우려도 현격히 적습니다.

하지만 CSP Native이므로 경쟁상대인 타 CSP를 위한 보안 기능을 제공하지 않기 때문에 멀티 클라우드 환경에서는 CSP마다 Native 보안 기능을 사용하기 위한 요금은 물론 인적 학습 비용을 지불해야 하고, On-Premise까지 포괄하지 못하기 때문에 Hybrid 클라우드 환경에서는 CSP Native와 On-Premise 보안 솔루션 양쪽을 모두 사용해야 합니다.

무엇보다도 CSP Native 보안 기능의 가장 큰 난관은 난이도입니다. 3rd Party 보안 솔루션은 제조사, 총판으로 이어지는 체계를 통해 기술지원을 받을 수 있지만 CSP Native 보안 기능은 사용자가 직접 모든 문제를 해결해야 하기 때문입니다.

좀 더 구체적으로 보안 기능의 난이도에 대해 설명하자면, CSP의 보안 기능을 사용하기 위해서는 Compute, Storage, Network, Management에 해당하는 배경 지식과 활용 역량이 요구됩니다. 명시적으로 보안으로 분류되지 않더라도 보안에 필수 불가결한 기능들인 네트워크 격리 기능이나 전용선 연결, 보안 형상관리 기능 등에 대한 활용도 필요합니다. 결국 클라우드 보안의 역량이 클라우드 자체의 역량으로 귀결되는 것입니다.

이러한 어려움을 극복하기 위해서는 클라우드 및 클라우드 보안과 관련된 내부 운영 인력들의 역량 강화가 중요하며, 만약 자체 인력의 역량 강화가 어려운 상황이라면 이를 채워주기 위한 MSP (Managed Service Provider) 또는 MSSP (Managed Security Service Provider) 등을 통해 전문적인 도움을 받는 것이 좋습니다.

삼성SDS 클라우드 보안 서비스 - 국내 유일, 클라우드와 보안 전문성을 모두 보유한 삼성SDS의 클라우드 보안 서비스

클라우드의 시작과 끝은 클라우드 보안

클라우드 전환은 단순 인프라 전환이 아닌 보안 정책을 포함한 모든 보안 시스템의 전환을 필요로 합니다. 기존 Legacy 보안과 클라우드 보안은 고려해야 할 사항이 크게 다르기 때문에 기존 보안 방식으로 접근하다 보면 새로운 보안 위협에 노출되기 쉬우며, 클라우드 서비스의 경우 사용자의 자원 통제 권한 범위가 넓기 때문에 보안 사고 발생 그 피해 범위도 더 클 수밖에 없습니다.

읽으시는 분들도 처하신 상황에 따라 나의 클라우드 전환 단계는 어디쯤인지 가늠하시고, 클라우드 보안을 위해 지금 해야 할 것과 미래에 해야 할 것 또는 미처 챙기지 못하고 지나쳐간 것이 무엇인지 파악하신다면 성공적인 클라우드 전환이라는 결과를 얻으실 수 있을 거로 생각합니다.



References
[1] Top challenges/obstacles for organizations for using public cloud resources 2020
(https://www.statista.com/statistics/1127599/top-public-cloud-challenges/)
[2] Gartner predicts that, through 2020, 95% of cloud security failure will be the customer's fault.
(https://www.gartner.com/en/information-technology/insights/cloud-strategy)
[3] CNCF, Cloud Native Interactive Landscape (https://landscape.cncf.io/)
[4] Analysis of 4 Million Docker Images Shows Half Have Critical Vulnerabilities (https://www.securityweek.com/analysis-4-million-docker-images-shows-half-have-critical-vulnerabilities)
[5] Gartner Magic Quadrant for Network Firewalls 2021 (https://www.gartner.com/en/documents/4007809)




▶   해당 콘텐츠는 저작권법에 의하여 보호받는 저작물로 기고자에게 저작권이 있습니다.
▶   해당 콘텐츠는 사전 동의 없이 2차 가공 및 영리적인 이용을 금하고 있습니다.


이 글이 좋으셨다면 구독&좋아요

여러분의 “구독”과 “좋아요”는
저자에게 큰 힘이 됩니다.

subscribe

구독하기

subscribe

천준호
천준호 보안 전문가

삼성SDS 클라우드보안서비스그룹

지난 10여년의 절반은 클라우드 조직에서 보안 업무를, 나머지 절반은 보안 조직에서 클라우드를 담당했습니다. 지금은 신생 클라우드보안서비스그룹이 다양한 경험을 가진 동료들이 모여 새로운 기회를 얻는, 이민자의 부서가 될 수 있도록 노력하고 있습니다.

공유하기