클라우드는 자체적으로 IT를 소유하고 관리하던 종래의 환경과는 달리 정보가 공급자의 관리 아래에 있게 되므로 특정 공간이나 지역에 한정되지 않으며 물리적인 보안 또한 공급자에 의해 관리된다.

클라우드(논리적 관점에서 볼 때)는 데이터를 집중 관리하므로 규모의 경제를 달성하는 데 용이하지만 악의적인 공격자에게는 더 매력적인 공격대상으로 간주되기도 한다. 이러한 모든 특징으로 인해 클라우드는 기존의 IT 환경에 비해 더 높은 수준의 보안 프로세스, 기술 및 의식을 요구하고 있다. 클라우드와 관련된 주요 보안 이슈와 핵심 고려사항을 살펴보자.

클라우드 - 오늘날 IT의 시대정신

클라우드는 IT를 직접 소유하기 보다는 제3자가 제공하는 규격화된 요소들(소프트웨어, 플랫폼, 인프라구조 등)을 필요에 따라 셀프서비스 방식으로 사용하고 그에 따른 경비를 지불하는 모델로 전환할 수 있게 하는 기술적 발전방향을 포괄적으로 일컫는 용어이다. 클라우드를 활용하면 활용도가 매우 낮으면서도 최대 부하를 위해 어쩔 수 없이 유지해야 했던 IT 자산 비용을 사용한 만큼만 경비로 지불하는 경제적 합리성을 이룰 수 있고, 공급자의 서비스 제공 능력에 의지하여 예상했거나 예상치 못했던 과도한 부하에도 대처할 수 있는 가능성이 높아서 많은 관심과 호응을 얻고 있다.

클라우드 보안을 위한 5가지 핵심 고려사항

클라우드가 제공할 수 있는 많은 잠재적 이익에 대해서는 충분히 공감대가 있지만 클라우드와 관련된 여러 가지 우려에 대해서는 아직 충분히 경험하거나 이해되지 못한 점도 있다. 클라우드 컴퓨팅의 이점이 제대로 실현되려면 특히 보안과 관련된 이점과 위험이 처음부터 충분히 강조되어야 한다. 클라우드 솔루션을 평가, 구현, 관리, 유지할 때는 규정준수와 위험관리, 사용자 확인과 액세스 제어, 서비스 무결성, 종단점 무결성, 정보보호 등이 총체적으로 조사되어야 한다.

1. 규정준수와 위험관리

클라우드를 사용할 때 관련된 여러 규정을 준수하는 것은 궁극적으로 사용자에게도 큰 책임이 있다. 규정 준수를 클라우드 서비스 공급자의 책임으로만 오해하는 경우를 종종 볼 수 있는데 이는 사실과 크게 다르다. 비유적으로 말하자면 도로교통에서 보행자와 시설물을 안전하게 보호하기 위해 자동차를 안전하게 운전해야 하는 책임은 운전자에게 있다. 물론 운전자의 의지에 따라 도로교통법을 준수할 수 있게 자동차를 설계·제조할 책임은 제조사에 있지만 모든 안전운전을 제조사의 책임 하에 둘 수는 없는 일이다.

여러 공급자가 제공하는 클라우드 서비스를 혼합하여 사용하는 경우 공급자의 투명성이 절대적으로 요구된다. 클라우드 공급자 입장에서는 서비스 경쟁력을 유지·확대하기 위해 공개하기 힘든 요소들도 있게 마련이다. 그러나 사용자가 규정준수를 위해 올바른 판단을 내리기에 충분할 정도로 하드웨어 자산에 대한 물리적 보안체계, 적용하고 있는 보안 프로세스 등의 정보를 투명하게 공개할 필요가 있다. 사용자는 이러한 정보를 기반으로 위험도를 분석하여 자체적인 규정준수 프레임워크와 결합할 수 있다. 이 과정에서 필요에 따라 추가 정보를 위해 공급자와 협상하기도 해야 한다. 이를 위해서 사용자는 스스로 숙련된 위험관리 팀을 조직·운영해야 한다.

규정준수를 위한 요구사항은 사용자측의 숙련된 내부 팀과 공급자측의 일정 수준의 프로세스 투명성이 조화를 이룰 때 효과적으로 달성될 수 있다.

2. 사용자 확인(AuthN)과 액세스 제어(AuthZ)

클라우드 기반의 서비스는 종종 여러 도메인을 넘나드는 협업을 필요로 한다. 소중한 자산에 접근할 가능성이 있는 서비스를 위한 사용자 확인 및 액세스 제어 시스템은 직접 확인 혹은 이에 준하는 수준의 강력한 프로세스와 견고하게 암호화된 신원정보를 사용하는 사용자정보 프레임워크에 기반하해야 한다.

클라우드가 확산되기 이전부터 AuthN과 AuthZ를 위한 여러 기술들이 개발되어 왔으며 사용자명/암호, X.509, Kerberos, SAML 등이 널리 사용되고 있다. 그러나 이들을 그대로 클라우드에 적용하기에는 몇 가지 문제점이 있다. 먼저 각각의 기술은 특정 시나리오에는 잘 적용되지만 다른 시나리오에는 적용하기 어려운 문제가 있다. 그 결과 채택된 기술에 따라 그 기술을 사용하는 서비스에도 제한사항이 그대로 반영되는 경우가 많다.

그러므로 서로 다른 요구사항을 가진 여러 도메인을 넘나드는 클라우드 서비스를 위한 AuthN/AuthZ 시스템은 특정 기술에 종속되지 않고 여러 기술의 상호운용이 가능한 체제를 기반으로 해야 한다. 또 다른 문제점은 프라이버시 부분이다. 보안을 강화하기 위해서 사용자에게 필요 이상으로 많은 정보를 요구하다 보면 프라이버시를 침해할 수 있으며, 이는 규정준수를 어렵게 하기도 한다. 그러므로 정확히 필요한 정보만 사용하는 체제가 요구된다.

클레임-기반 ID(Claims-based Identity)는 이러한 문제점들에 대한 근원적인 해결책을 제시한다. 이는 서비스와 ID를 효과적으로 분리하여 시나리오에 구애 받지 않는 보편적인 솔루션을 가능하게 하고, 기존의 여러 ID 기술을 수용할 수 있어서 서로 다른 기술의 상호운용을 가능하게 하며, 필요 이상의 정보 노출을 방지할 수 있는 최신 기술과도 결합될 수 있는 등 여러 측면에서 클라우드 서비스에 적용하기에 용이하다.

클레임-기반 ID는 ID 제공자, ID 사용자, 서비스 사용자의 3자 사이의 정보 흐름을 기반으로 하고 있는데 이 가운데 ID 제공자의 무결성이 절대적으로 중요하다. 그러므로 가능하다면 ID 제공자 승인과 등급 지정도 고려해볼 만하다. 클레임-기반 ID는 클라우드 뿐만 아니라 기존의 자체보유 IT 환경에도 적용될 수 있으며 이는 IT 환경 전반에 걸쳐 보안과 데이터 무결성을 획기적으로 개선할 수 있을 것으로 기대된다.

클라우드를 위한 디지털 ID 시스템은 여러 기관, 클라우드 공급자에 걸쳐 상호운용이 가능해야 하고 강력한 프로세스에 기반해야 한다.

3. 서비스 무결성(Integrity)

서비스 무결성은 클라우드 공급자가 서비스의 개발 전 과정에서 보안을 반영하도록 하는 방법과 개발된 서비스가 사용자가 원하는 정도의 신뢰성과 지원 수준을 만족하도록 운영하는 방법을 포함한다.

▲서비스 개발의 무결성

제품에 보안과 프라이버시가 반영되도록 하는 것은 어느 소프트웨어나 필수적인 요구이며 클라우드도 예외가 아니다. 클라우드 공급자는 분명 높은 수준의 보안 전문지식을 보유하고 있겠지만 개발 및 유지보수의 각 단계마다 보안과 프라이버시를 결합하는 것 또한 매우 중요하다. 마이크로소프트는 보안 개발 주기(Security Development Lifecycle)를 사용하여 클라우드 컴퓨팅 환경 개발 전 과정, 즉 요구분석, 설계, 구현, 검증, 발매, 대응에 이르는 각 단계에 보안을 빈틈없이 결합하여 관리하고 있다.

클라우드 서비스 공급자를 평가할 때 공급자의 보안 개발 프로세스에 대한 구체적인 사항에 대해 질의할 필요가 있다. 또한, 위협 모델(Threat Model)은 얼마나 자주 갱신되는지, 보안 대응팀이 얼마나 잘 작동하고 있는지, 보안 업데이트에 대해 사용자들이 제대로 공지를 받는지 등에 관한 지속적인 보안 노력에 대해서도 정기적으로 확인해야 한다.

공급자는 처음부터 전체 주기에 걸쳐 서비스에 보안과 프라이버시가 결합될 수 있도록 분명하고, 잘 정의되며, 입증 가능한 프로세스에 따라야 한다.

▲서비스 전달의 무결성

클라우드 공급자는 서비스 수준에 관한 정보를 제공할 때 보안에 관한 정보도 충실하게 제공하고, 사용자는 이를 근거로 제공받기를 원하는 서비스가 보안에 관한 요구사항을 만족하는가를 판단할 수 있어야 한다.

서비스 수준에 포함될 수 있는 대표적인 사항으로는 성능 관리, 필요에 따른 네트워크 및 이미지 포렌식 수행 등을 위한 구체적인 계획은 물론 서비스 공급이 중단될 때를 대비한 고객 대응 연락처와 복구 프로세스 등도 포함되어야 한다. 서비스 수준 협약은 어떤 보안 모니터링과 감사 기능이 제공되는지, 이에 따르는 비용이 얼마인지 등에 관해 정의해야 한다.

공급자의 서비스 전달 역량과 사용자의 보안 관리 및 감사 필요성이 결합될 수 있어야 한다.

4. 종단점(Endpoint) 무결성

클라우드 보안에 관해 논의할 때 공급자의 보안 품질과 관행 및 서비스 자체로 한정하는 경우가 종종 있다. 그러나 클라우드 서비스는 조직 내부에서, 혹은 PC나 휴대기기에서 시작(요청)되고 종료되므로 클라우드 외부 요소를 포함하는 전체 서비스 사슬을 고려해야만 한다.

클라우드 서비스의 전반적인 신뢰도를 높이기 위해 온라인 ID 도용, 웹사이트 교차 스크립트 공격, 피싱 공격, 악의적인 소프트웨어 다운로드 등을 포함하는 위협으로부터 사용자를 보호할 수 있도록 전체 스펙트럼을 아우르는 보안 활동이 요구된다. 특히, 여러 공급자로부터의 서비스를 혼용하여 사용하는 환경에서는 전체 기관에 걸쳐 서비스가 전달되고 소비되는 방법과 이와 관련된 여러 종단점을 함께 고려하는 것이 중요하다.

클라우드 기반 서비스를 위한 보안에서는 종단점을 포함하는 것이 매우 중요한 고려사항이다.

5. 정보보호

민감한 정보를 공격자로부터 보호하는 것은 클라우드 보안의 핵심 중 핵심이다. 공급자가 서비스를 관리하는 경우 트랜잭션 전 과정을 통해 규정 준수를 보장하기 위해 액세스 제어를 활용할 수 있다. 그러나 여기에서 선행되어야 할 것은 민감성이나 기밀성을 기준으로 데이터를 분류하는 것이다. 분류결과에 따라 어느 데이터를 어떤 클라우드에 배치하는 것이 더 안심이 되는지 판단할 필요가 있다. 공용 클라우드와 사설 클라우드는 근본 개념에 있어서는 유사하지만 데이터 배치 관점에서의 심리적 저항 수준은 매우 다르다. 기밀성이 중요한 민감한 데이터를 사설 클라우드에 배치함으로써 이러한 심리적 저항을 극복할 수 있다.

정보보호는 암호화와 권한관리 등의 영구적인 보호와 트랜잭션 처리 과정에서 이동 중인 데이터의 보호도 고려해야 한다. 정보보호는 기존의 IT 환경에 비해 새로운 많은 이슈를 발생시키는데 대표적으로 데이터 주권(Data Sovereignty) 문제를 들 수 있다. 이는 클라우드에 보관된 데이터를 검열하거나 조회할 권리에 관한 문제인데 흔히 데이터센터의 위치한 지역적 관할(대표적으로는 국가 및 국경)과 연관되어 있다. 새로이 개발되는 일부 서비스들은 이러한 문제를 고려하여 데이터가 실제 저장될 물리적 위치를 명시할 수 있도록 하고 있다.

정보의 관리 및 제어 권한이 공급자에게 이양된 경우 정보에 접근하기 위한 ID와 인증체제를 누가 관리하는지, 백업 데이터는 어디에 보관되는지, 데이터 암호화는 지원되는지, 암호화로 인한 손실은 무엇인지(특정기능 사용불가 등), 서비스 가입을 취소할 때 사용자 데이터는 안전하게 폐기되는지 등에 관해 충분히 이해하는 것이 중요하다.

데이터 분류는 어떤 데이터가 어떤 환경에서 어떤 제어와 함께 클라우드에 배치할 수 있는지 결정하는데 도움을 준다.

맺음말

지금까지 클라우드 보안과 관련된 난점들과 해결책을 제시했다. 그러나 기본적으로 전제되어야 할 것은 클라우드 공급자들이 기존 IT 환경에 비해 현저히 높은 수준의 프로세스와 기술을 도입하고 월등히 많은 노력을 기울여 보안에 신경 쓰고 있다는 것이다. 그러므로 보안을 이유로 클라우드 도입을 주저하기 보다는 클라우드 시대에 어울리는 사고의 전환이 요구된다.

클라우드가 보다 높은 수준의 보안을 제공하고 있다고는 하지만 모든 클라우드 공급자가 동일한 수준의 보안을 제공하는 것은 아니다. 그러므로 클라우드 공급자는 서비스 개발·운영 등을 위한 기술과 프로세스에 있어서 어떤 표준과 관행을 실현하고 있는지 명시적으로 투명하게 공개하고 이를 기반으로 사용자는 적합한 수준의 보안을 제공하는 공급자와 서비스를 선택하는 것이 중요하다.

또한 모든 데이터가 동일한 수준의 민감한 기밀 데이터는 아니므로 데이터 분류를 기초로 하여 적절한 제어 및 배치 모델을 선택하는 것도 클라우드 도입의 전략이 될 수 있다.