클라우드 보안은 클라우드 서비스 및 클라우드 컴퓨팅과 관련된 데이터, 애플리케이션, 인프라를 보호하는 것을 의미합니다. 클라우드 환경(퍼블릭, 프라이빗, 하이브리드 클라우드)의 보안은 여러 측면에서 온프레미스 IT 아키텍처 보안과 상당히 동일합니다. 

하이브리드 클라우드 보안 강화클라우드 보안이 다른 이유데이터의 무단 노출 및 유출, 취약한 액세스 제어, 공격에 대한 취약성, 가용성 중단 등과 같은 매우 심각한 정보 기술(IT) 보안 또는 사이버 보안 문제는 기존 IT 시스템뿐만 아니라 클라우드 시스템에도 영향을 미칩니다. 다른 컴퓨팅 환경과 마찬가지로 클라우드 보안도 다음과 같은 보안 요건이 사전에 갖추어져 있어야 합니다.

데이터 및 시스템의 안전성 확인

현재 보안 상태 파악

비정상적인 현상을 즉시 인지

예기치 않은 이벤트 발생 시 추적 및 대응

많은 기업이 클라우드 컴퓨팅 환경의 장점을 잘 알고 있지만 보안 문제가 일어날 가능성이 있기 때문에 사용하기를 주저하고 있습니다. 형태가 없는 리소스가 인터넷과 물리 서버를 통해 전송될 때 그 경로에 있는 모든 것을 파악하기란 쉽지 않습니다. 이러한 동적인 환경에서는 보안 위협과 같이 모든 상황이 계속 바뀝니다. 클라우드 보안은 IT 보안이라고 해도 과언이 아닙니다. 하지만 차이를 구체적으로 이해한다면 '클라우드'라는 단어에서 더 이상 보안 위험을 느끼지 않을 것입니다.

보안 경계 소실

보안은 상당 부분 액세스 제어와 관련이 있습니다. 전통적인 환경에서는 일반적으로 경계 보안 모델을 사용하여 액세스를 규제합니다. 클라우드 환경은 긴밀하게 연결되어 있으므로 트래픽이 기존의 경계 방어벽을 우회하기가 쉽습니다. 안전하지 않은 애플리케이션 프로그래밍 인터페이스(API), 취약한 Identity 및 자격 증명 정보 관리, 해커, 악의적인 내부자는 시스템과 데이터에 위협 요소로 작용할 수 있습니다. 클라우드에서 취약점을 없애고 무단 액세스를 방지하려면 데이터 중심 접근 방식으로 전환해야 합니다. 데이터를 암호화하고 인증 프로세스를 강화해야 합니다. 또한 강력한 암호 및 이중 인증(2FA)이 필요하며 모든 수준에 네트워크 보안 조치를 구축해야 합니다.

소프트웨어 중심

'클라우드'란 소프트웨어를 통해 사용자에게 제공되는 호스팅된 리소스를 말합니다. 처리 중인 모든 데이터와 더불어 클라우드 컴퓨팅 인프라는 역동성, 확장성, 이식성을 제공합니다. 암호화와 같이 워크로드의 고유한 부분이든 클라우드 관리 시스템과 API를 통한 동적 방식을 통해서든 클라우드 보안 제어는 유휴 데이터와 전송 중인 데이터 모두를 다루고 워크로드를 처리하면서 환경 변수에 대응할 수 있어야 합니다. 그래야 시스템 손상 및 데이터 침해로부터 클라우드 환경을 보호하고 안전을 유지할 수 있습니다.

정교해진 보안 위협 환경

정교한 보안 위협이란 클라우드를 포함하여 현대적인 컴퓨팅에 부정적인 영향을 미치는 모든 요인을 말합니다. 지능형 지속 위협(Advanced Persistent Threats, APT)과 같이 점점 정교해지는 맬웨어 및 기타 공격은 컴퓨팅 스택의 취약한 부분을 표적으로 삼아 네트워크 방어 체계를 회피하도록 설계됩니다. 데이터가 유출되면 무단으로 정보가 공개되거나 데이터가 손실 또는 변조될 수 있습니다. 이러한 위협에 대처하기 위한 유일한 방법은 클라우드 보안 방식을 개발하고 최신 상태로 유지하여 신종 위협에 대응하는 것입니다.

클라우드 보안은 공동의 책임

어떤 클라우드 배포를 사용하든 클라우드 내에서 자신이 소유하고 있는 공간을 보호할 책임이 있습니다. 클라우드를 관리해주는 업체가 있다고 해서 보안을 소홀히 해서는 안 됩니다. 실사를 제대로 수행하지 않는 것은 보안 실패의 주요 원인입니다. 클라우드 보안은 모두의 책임이며, 여기에는 다음이 포함됩니다.

신뢰할 수 있는 소프트웨어 사용클라우드에 무엇이 있는지 파악하는 것이 중요합니다. 외부 소스에서 다운로드한 여느 코드와 마찬가지로 패키지가 어디에서 왔는지, 누가 구축했는지, 패키지 내에 악성 코드가 들어 있는지 식별해야 합니다. 알려지고 신뢰할 수 있는 소스에서 소프트웨어를 가져오고, 적시에 업데이트를 제공하고 설치할 수 있는 메커니즘이 마련되어 있는지 확인합니다.

컴플라이언스 이해개인 정보, 금융 정보 등 각종 민감한 클라우드 데이터에는 엄격한 규정이 적용될 수 있습니다. 어디에서 누구와 비즈니스를 수행하는가에 따라 적용되는 법률이 달라지며 유럽 연합의 일반 데이터 보호 규정(General Data Protection Regulation, GDPR)을 참조하시기 바랍니다. 클라우드 배포를 선택하기 전에 규정 요구 사항을 확인합니다.

라이프사이클 관리클라우드 네이티브 환경에서는 새로운 인스턴스를 손쉽게 생성할 수 있습니다. 따라서 오래된 인스턴스의 존재를 잊어버리기도 쉽습니다. 방치된 인스턴스는 활성화되어 있으나 모니터링되지 않아 이른바 '클라우드 좀비'가 될 수 있습니다. 이렇게 버려진 인스턴스는 점점 낡게 되어 결국 더는 새로운 보안 패치가 나오지 않습니다. 라이프사이클 관리 및 거버넌스 정책이 이러한 문제에 도움이 될 수 있습니다.

이식성 고려워크로드를 다른 클라우드로 쉽게 옮길 수 있으십니까?

SLA(서비스 수준 계약)에는 클라우드 제공업체가 고객의 데이터 또는 애플리케이션을 반환하는 시기와 방법이 명확히 명시되어 있어야 합니다. 빠른 시일 내에는 아니더라도 언젠가는 이동을 해야 할 때가 올 것입니다. 따라서 이식성을 고려하여 향후에 종속 문제가 발생하지 않게 해야 합니다.

지속적인 모니터링작업 공간에서 진행 중인 작업을 모니터링하면 최소한 보안 침해의 영향을 피하거나 방지할 수 있습니다.

적합한 클라우드 제공업체 선택클라우드 서비스와 보안의 복잡성을 이해하고 자격을 갖춘 신뢰할 수 있는 인력을 고용하고 파트너십을 맺으세요. 퍼블릭 클라우드 제공업체는 최신 정보를 파악하고 있으며 체계적인 보안 팀을 보유하고 있기 때문에 때로는 퍼블릭 클라우드의 인프라가 특정 조직의 프라이빗 클라우드보다 안전할 수도 있습니다.

퍼블릭 클라우드는 안전할까요?이 문제에 대해 살펴보겠습니다. 3가지 클라우드(퍼블릭, 프라이빗, 하이브리드) 배포 간의 보안 차이점에 관해 자세히 설명할 수도 있지만, 사실 정말로 궁금한 것은 "퍼블릭 클라우드는 안전한가?"입니다. 이는 상황에 따라 달라집니다.

Amazon Web Services(AWS), Microsoft Azure, Google과 같은 퍼블릭 클라우드는 여러 유형의 워크로드에 적절한 보안을 제공하지만 프라이빗 클라우드에서 제공하는 분리 기능은 부족하므로 모든 상황에 적합하지는 않습니다. 퍼블릭 클라우드는 멀티테넌시를 지원합니다. 즉, 해당 클라우드 서비스 제공업체의 데이터 센터 성능(또는 스토리지 공간)을 임대하는 또 다른 "테넌트"도 있습니다. 각 테넌트는 누가 어떤 책임을 지는지 명시된 클라우드 제공업체의 서비스 수준 계약(SLA)에 서명합니다. 이러한 절차는 임대주로부터 물리적 공간을 빌리는 것과 비슷합니다. 임대주(클라우드 제공업체)는 건물(클라우드 인프라)을 유지관리하고 키(액세스)를 계속 보유하되, 대체로 임차인의 생활 방식(프라이버시)에 관여하지 않겠다고 약속합니다. 그 대신에 임차인은 건물의 온전한 상태를 손상시키거나 다른 임차인에게 폐를 끼치는 어떠한 행동(예: 보안되지 않는 애플리케이션 실행)도 하지 않기로 약속합니다. 하지만 임차인은 이웃을 선택할 수 없고 해를 끼치는 이웃을 만나게 될 수도 있습니다. 클라우드 제공업체의 인프라 보안 팀이 비정상적인 이벤트를 감시함에도 불구하고 악의적인 DDoS(분산 서비스 거부) 공격과 같은 은밀하거나 공격적인 위협은 여전히 다른 테넌트에게 부정적인 영향을 미칠 수 있습니다.

다행히도 업계가 인정한 보안 표준, 규정 그리고 CSA(Cloud Security Alliance)의 CCM(Cloud Controls Matrix)과 같은 제어 프레임워크가 있습니다. 또한 테넌트는 손상된 인프라에서 워크로드를 보호하는 추가 보안 툴(예: 암호화 및 DDoS 완화 기술)을 배포하여 멀티테넌트 환경에서 자신을 분리시킬 수 있습니다. 이렇게 해도 보안이 충분하지 않을 경우 클라우드 액세스 보안 브로커를 배포하여 활동을 모니터링하고 위험성이 낮은 엔터프라이즈 기능에 대한 보안 정책을 강화할 수 있습니다. 이러한 모든 조치를 취하더라도 엄격한 개인 정보 보호 규정, 보안 규정, 준수 규정에 따라 운영되는 업계에서는 충분하지 않을 수도 있습니다.

클라우드 네이티브 보안을 위한 DevSecOpsDevSecOps는 조직이 IT 보안을 강화하고 소프트웨어 환경의 위험을 줄일 수 있는 수단으로 DevOps 사례와 보안 전략을 결합한 것입니다. 쿠버네티스, 컨테이너, 마이크로서비스, 서비스 메쉬 등의 클라우드 네이티브 기술 은 조직에서 클라우드 애플리케이션을 보다 동적이고 안정적이며 대규모로 구축, 배포 및 실행하는 데 필요한 구성 요소를 제공하기 때문에 큰 인기를 얻게 되었습니다. 

클라우드 네이티브 기술이 도입한 변화로 인해 조직에는 보안을 DevSecOps 모델로 발전시켜야 할 필요성이 생겼습니다. 즉, 보안 및 엔지니어링팀이 서로 협력해 조직이 현대적이고 확장 가능한 애플리케이션을 구축 및 실행할 수 있도록 지원할 성공적인 전략을 개발해야 한다는 의미입니다. 이는 보안을 코드로 구현하는 워크플로우를 소프트웨어 개발 라이프사이클 초반에 통합하는 shift left 사례를 통해 가능합니다.

피해사례로 알아보는 클라우드의 문제점

다양하고 편리한 클라우드의 장점 이면에도 심각한 문제점이 존재한다. 특히 안전성 부분이 가장 문제가 되고 있다. 데이터센터를 대체할 수 있는 클라우드의 유연성과 편의성은 이미 입증되었지만 더욱 더 대중화되지 못한 이유 중 하나는 안전성에 대한 우려 때문일 것이다. 예를 들어 클라우드 서비스 제공자의 서버가 정전 또는 트래픽 충돌 등의 이유로 정상적인 서비스가 불가능해 질 경우 해당 서비스를 이용하고 있는 모든 고객에게 피해가 확산되기 때문이다. 실제로도 클라우드 시장의 핵심업체들 모두 이러한 문제를 겪었었다. 이러한 문제 발생을 방지하기 위해 대부분 “백업의 백업”을 구비해두었지만 이마저도 수많은 시스템의 상호 복합성에 의해 예상치 못한 일들이 발생하곤 한다.  더 나아가, 클라우드 컴퓨팅 수요가 늘어남으로써 클라우드 제공업체도 덩달아 증가하면서 이러한 문제의 발생 빈도와 피해도 증폭될 것으로 보인다. 더 자세한 내용은 클라우드 중단사고 사례를 통해 살펴보도록 하겠다.  

1) 클라우드 서비스의 대표적 사고 사례

2011년 4월 Amazon 웹서비스 중단 사고가 발생했다. 역대 최악의 클라우드 서비스 사고였는데 Amazon 클라우드를 사용하는 4개의 대형 사이트가 4일간이나 중단된 사고였다. 현재에는 이처럼 장시간 중단되지는 않지만 짧게 서비스가 멈추는 현상은 자주 발생하고 있는 것으로 나타났다.  

2016 년 3월에는 Google의 클라우드 서비스인 ‘Compute Engine’이 20분간 중단된 사고가 발생하였다.  네트워크 장비를 업데이트하는 과정에서 오류가 발생하였고, 문제를 파악하여 자동으로 수정해주는 자동화 소프트웨어 역시 오류가 발생하여 잘못된 기술정보가 네트워크 전체로 퍼지게 되어 서비스가 강제 종료된 것이다.

2017년 1월 MS Office 사용자들은 수 일간 클라우드 이메일 계정을 사용하지 못하여 많은 불편함을 겪었다. MS 측은 전자메일 라우팅 및 필터링을 처리하는 몇 가지 인프라 구성요소가 과도한 리소스 사용으로 인해 성능이 저하되어 발생한 사고라고 보도했다. 

2017년 3월 또 다시 Amazon 웹서비스가 4시간 동안 작동이 정지되어 미국의 수 천개 웹사이트가 동시에 마비되는 사건이 발생했다. 이로 인해 아마존은 대쉬보드를 2시간 동안 사용하지 못하였으며, 시스템 상당 부분이 종료되는 현상이 발생했다. 정확한 사고 원인은 밝혀지지 않았지만 인적 사고 또는 코드 내의 버그로 인한 사고일 가능성이 높다고 보고 있다. 

클라우드 서비스 중단 사고 중 가장 높은 비율은 차지하는 원인은 무엇일까?

- 인적 사고 (Human error)

올해 초 발생한 Amazon 클라우드 서비스중단 사태는 사람의 실수로 밝혀졌다. Amazon 직원이 Billing(계산)시스템의 오류를 디버깅하는 과정에서 의도치 않은 다른 서버를 실수로 종료시켜 발생했다고 한다. 실수로 종료 시킨 서버를 시작으로 두 개의 보조시스템이 추가로 다운되었고 도미노 효과로 피해가 확산되었다. 결론적으로 피해 확산과정에서 중요한 파일이 삭제됨으로써 시스템 전체의 재부팅이 필요하게 된 것이다. 현재 아마존에서는 이런 문제에 대응하기 위해, 직원이 사용하는 디버깅 및 서버 용량을 제거하는 툴 등을 개선한다고 공표한 상태지만, 가트너의 클라우드 분석가 Lydia Leong이 “이러한 클라우드 중단사태는 사람의 실수가 가장 큰 원인이다” 라고 했듯이, 사람은 누구나 실수를 하므로 앞으로도 이런 사고의 반복가능성을 배제할 수는 없다. 

- 기계적 오류 (Machine error) 

위에서 말한 것처럼 아무리 완벽해 보이는 사람이라도 실수를 하기 마련이다. 그럼 기계는 과연 어떨까? 기계는 사람과 같이 기술적인 실수를 범하지는 않지만 노화된 회로, 전력 급증, 물리적 손상 또는 결함이 있는 부품이나 제작기술로 인해 부분적 또는 전체적인 고장이 발생하기 쉽다. 실제로 2013년 Amazon 웹서비스는 네트워크 장비에 오류가 발생하여 데이터 손실을 겪은 바 있다.

그렇다면, 클라우드 컴퓨팅이 중단될 때 그에 따른 부정적인 영향은? 

고의적인 보안 공격, 인적 사고, 또는 하드웨어 및 소프트웨어 문제이던 간에 서비스가 중단되면 클라우드 제공업체와 고객 모두에게 경미하거나 막대한 피해를 줄 수 있다.  많은 고객들은 이메일, 데이터베이스, 웹 페이지 및 전자상거래 뿐만 아니라 앱을 이용한 회계, 급여, 인사와 같은 비즈니스 기능 처리에 이미 클라우드를 전적으로 의존하고 있다. 그러므로 이 클라우드 서비스가 멈추면 문자 그대로 이 모든 작업이나 사업을 수행할 수 없는 업무불능의 상태가 되는 것이다.

그 뿐만 아니라 클라우드를 사용하고 있지 않는 수 많은 사이트들도 직간접적인 영향을 받으므로 클라우드 컴퓨팅 서비스 중단으로 인한 부정적인 영향은 막대하다고 볼 수 있다.

클라우드 컴퓨팅은 모든 일상생활에 녹아 들어 있어 마치 공기나 물과 같은 존재로 자리잡고 있다. 그만큼 없어서는 안될 필수불가결한 요소로 자리 잡고 있으나 전술한 Amazon의 경우 처럼 인적 사고나 기계적 오류로 중단되거나, 또는 보안노출로 인해 취약성이 노출되는 등 비정상적으로 운영될 경우, 오히려 부메랑이 되어 막대한 피해를 초래할 수도 있다. 

급속도로 수요가 늘어나는 만큼 안전성 역시 보장되어야 할 것이다. 이를 위해서는 인적 사고, 기계적 결함, 그리고 취약한 보안 문제 등이 개별적이기 보다는 복합적으로 고려되어야 하겠다.