클라우드 공급업체가 지켜야 할 7가지 보안 원칙

클라우드 컴퓨팅 보안은 믿을 수 없을 정도로 넓고 깊은 주제로, 간단 명료하게 파악하기는 쉽지 않다. 그러나 이런 전제 아래 원칙에 충실하도록 노력하자.

첫 번째로 해야 할 일은 모두가 같은 이야기를 하고 있는지 확인하는 것이다. 일부 클라우드 공급업체들은 보안, 신뢰성과 재해 복구/비즈니스 연속성 사이의 경계를 모호하게 하려고 애쓰고 있다. 이들은 모두 중요한 속성으로서 대화에 혼란만 줄 뿐이다. 여기서는 표준적인 보안의 정의에 충실하겠다.

1. 정확한 시스템 파악

자체 구축 시스템에서 보안의 첫 번째 단계는 권한이 없는 사람들이 컴퓨터에 물리적으로 액세스를 할 수 없다는 것을 확인하는 것이다. 누군가가 외부에서 하드웨어에 접속할 수 있거나 시스템을 재구성할 수 있거나 시스템 부팅 주기를 조절할 수 있다면, 보안은 무방비 상태가 된다.

클라우드 기반 서비스에서 보안은 공급업체의 업무로서 서버 측에서 걱정할 필요가 없다. 지난 몇 년 동안 클라우드 서비스의 일시적인 보안 불이행이 있었지만, 클라우드 공급업체들은 상당히 엄격한 보안팀을 유지하고 있으며, 거의 모두가 자신들의 내부 보안 절차를 고도로 보호되고 있는 업계 비밀로 다루고 있다. 이는 그들을 평가할 만한 정보를 많이 확보할 수 없다는 뜻이다. 평판이 좋은 공급업체라면, 이 문제를 무시해도 안전할 것이다.

2. 정체성 노출 위기

두 번째로 다루어야 할 항목은 클라우드의 정체성이다. 먼저 살펴보아야 할 것은 승인과 권한 부여 분야로, 비밀번호의 강도, IP 영역의 블랙리스트/화이트리스트, 로그인 시간, 2단계 승인 등 자체 구축 시스템에 사용되고 있는 모든 요소다. 대다수의 클라우드 공급업체들은 이를 노출되지 않도록, 적어도 애드온 기능이나 모듈로 유지해야 한다.

그리고 물론 지나치게 간과하는 문제는 특권 폐지다. 이는 시스템 자체보다 더 중요한 조치로서 액세스를 엄격히 제한하도록 관리자에게 촉구하거나 특권을 박탈할 필요가 있는 사용자들을 자동으로 경고하는 기능을 모색해야 한다.

반대 측면은 사용자에 대한 권한 부여 절차가 너무 간편하다는 것으로, SSO 접속자들과 위임된 인프라는 실용적인 다중 클라우드 애플리케이션을 필요로 한다. 사용자의 애플리케이션을 협력업체나 공급망으로 확장될 필요가 있으면, 사용자 계정이나 ID의 익명화/난독화가 특히 중요하다.

3. 암호화

암호화는 클라우드 애플리케이션의 명백한 요건이며, https는 모든 사용자의 로그인과 통합 접속을 위한 기준선이다. 그러나 다수의 클라우드 애플리케이션은 클라우드에서 데이터를 암호화할 수 있게 만들어져 있지 않다. 심지어 어떤 경우에는 클라우드 데이터를 암호화 형태로 저장하는 것조차 불가능하다. 이는 고객 개인정보, 기업 염탐 등의 위험을 초래하므로 클라우드 공급업체에게 내부 암호화와 이를 일정표 프레젠테이션에 삽입하도록 요구해야 한다.

4. ILP/DLP

필자가 앞서 발표한 기고에서 기술한 바와 같이 정보 손실 방지(일명 데이터 누출 방지)는 업무용 애플리케이션에 있어서 중요한 문제다. 미국에서는 해마다 8,000만 건의 고객 정보가 우발적인 손실과 고의적인 공격으로 인해 위험에 노출되고 있다. 위키리크스를 옹호한다고 하더라도 업무 정보에 대한 제어권을 잃어버리는 것은 걱정해야 할 일이다.

클라우드 시스템에는 누출 가능한 2가지 주요한 위험 분야가 있다. 첫 번째 분야는 사용자가 공급업체를 면밀히 조사하는 방법 이외에는 제어할 수가 없는 클라우드 공급업체 내부의 틈새다. 그러나 사용자는 최소한 클라우드 공급업체의 SLA 중 일부로 사용자의 데이터에 영향을 미치는 어떤 틈새도 알려달라고 요구할 수 있다  

사용자가 제어권을 가져야 할 두 번째 틈새는 최종 지점에서의 손실이다. 이는 클라우드 애플리케이션에서 제공하거나 데이터를 처리하는 각 서버, PC와 모바일 기기를 위한 애드 온 소프트웨어나 하드웨어를 필요로 한다. 그 목적은 승인된 데이터만 전송되는지, 그 데이터가 기기와 파일/목표 레벨에 이르기까지 통제되고 있는지 확인하기 위한 것이다.

게다가 파일의 암호화와 기기 제어권을 상실할 경우에 자동 삭제가 필요하며, 기업이 대규모 외근 인력을 보유하고 있을 경우에 특히 그렇다. 다목적 ILP/DLP 제품이 좋은 출발점이지만, 현재 일부 신샌업체가 클라우드 기반 소프트웨어에 대한 특정 요구 사항에 맞춘 솔루션을 제공하고 있다.

5. 개인정보

사용자의 사업 분야와 위치에 따라 PCI, GLBA, CA1386, HIPAA, FERPA, 지침 95/46/EC 등 클라우드 애플리케이션이 준수해야 할 필요가 있는 엄청난 개인정보 관련 용어가 있으며, 이 목록은 한이 없다. 먼저 해야 할 일은 ILP/DLP를 굳건히 하는 것이다. 정보가 사용자 기업에서 새어 나온다면 어떤 개인정보 표준도 준수할 수 없다.

다음 단계는 클라우드 공급업체가 규정을 준수하거나 최소한 세이프 하버 인증은 가지고 있는지 확인하는 것이다. 다수의 클라우드 애플리케이션 공급업체가 이를 충족하고 있지만, 일부 공급업체는 현재 세대의 서비스로는 인증을 받을 수 없는 분야도 있다. 특히 클라우드 통합 업체들이 그렇다.

다수의 개인정보 영역에 대한 준수는 사용자 측의 절차 변경을 필요로 하므로 이는 완전히 공급업체에게 거짓말을 할 수 있는 문제가 아니다. 이런 말은 하기 싫지만, "변호사와 상담하기 바란다."

6. 감사

로그인 역사에서 경영 활동과 데이터 변경에 대한 감사는 보안에 본질적인 사항이다. 감사가 틈새를 매울 수는 없지만 무슨 일이 발생했는지, 그리고 이를 개선하는 방법에 관해 중요한 법적 근거를 제공한다.

백업 또는 기록 보관소가 기본 대책이기는 하지만 그들은 누가 무엇을 언제 변경했는지에 대한 공식적인 감사에 대한 대안은 아니다. 클라우드 공급업체가 사용자가 서비스에 서명을 하기 전에 로그인에 대한 옵션을 제공하는지, 사용자 자신이 그 옵션을 날마다 작동시키고 있는지 확인한다. 사용자는 아마 모든 분야의 변경을 감사할 수는 없을 것이므로 가장 민감하고 관련성이 있는 것을 선택하고 있는지 확인한다.

마지막으로, 감사 결과가 불과 몇 달 뒤에 사용자 시스템에서 사라질지도 모르므로 감사 결과를 사용자 자신의 현장 매체에 백업되고 있는지 확인한다. 이들 서비스에 대한 감사 결과의 복원은 대단히 비용이 많이 들 수가 있다.

7. 서비스 거부 공격

DoS 공격은 영구적으로 존재할 것 같다. 해커들이 사용자 기업을 공격 대상으로 삼지는 않겠지만, 클라우드 공급업체가 공격을 받으면 사용자의 비즈니스 연속성에 영향을 받을 수 있다. 사용자는 클라우드 공급업체가 재해 복구와 같은 어떤 적절한 개선 전략을 가지고 있는지 알아야 할 필요가 있으며, 서비스 복원 시간을 포함하여 SLA에 대해 협의할 필요가 있다.  

*David Taber는 신간 "세일즈포스닷컴의 성공 비결(Salesforce.com Secrets of Success)” 저자이며, 세일즈로지스틱스(SalesLogistix)의 CEO다.

 editor@idg.co.kr