[테크월드=배유미 기자] 디지털 전환(Digital Transformation)과 함께 데이터와 네트워크, 서버와 관련된 기술도 눈부시게 발전됐다. 하지만 이에 따른 사이버 공격도 더욱 정교해지고 있다. 특히 사이버 공격 시 큰 타격을 입을 수밖에 없는 클라우드 특성상 ‘클라우드 전환’을 고려하고 있는 곳에서는 철저한 보안 방안을 필요로 하고 있는 실정이다.

 

캐피탈 원 유출 사고로 보는 보안의 중요성

2019년 7월 미국 대형은행 캐피탈 원(Capital One)에서 신용카드를 신청한 1억 600만 명의 고객의 개인정보가 해킹되는 대형 사고가 있었다. 유출된 정보는 ▲이름 ▲주소 ▲우편번호 ▲전화번호 ▲생년월일 ▲연간소득 등 14만 개의 미국 고객의 사회보장번호 ▲8만 개의 은행 계좌번호 ▲캐나다 고객의 1만 개 사회보장번호 등이다.

캐피탈 원 개인정보 유출 당시 공격자는 오픈소스 WAF(ModSecurity) 설정 오류를 이용한 SSRF(Server Side Request Forgery)의 취약점 이용 공격을 사용했다. 이것은 웹 서버(Web Server)를 통해, 동일한 로컬 네트워크(Local Network)으로 연결돼 있는 내부 서버(Internal Server)에 있는 리소스(Resource)를 접속(access)할 수 있다.

정상적인 경우라면 사용자는 내부 서버(Internal Server)에 요청(request)를 보낼 수 없지만, 웹 서버(Web Server)가 SSRF(Server-Side Request Forgery) 취약점을 가지고 있는 경우라면, 웹 서버를 통해, 동일한 로컬 네트워크(Local Network)로 연결되어 있는 내부 서버(Internal Server)에 있는 리소스(Resource)를 접근할 수 있다. SSRF 취약점을 이용하면, 웹 서버가 사용자를 대신해 내부 서버에 요청(Request)를 보내도록 할 수 있다. 웹 서버에서 동작하는 웹 어플리케이션(Web Application)이 공격자(사용자)가 조작한 명령/요청(Forgery Request)을 실행하기 때문에 가능하다.

웹 서버(Web Server)가 SSRF 취약점을 가지고 있는 경우라면, 공격자(사용자)는 127.0.01 주소로 접속(access)해, 인증 없이 웹 서버 내부에 있는 내부 정보(Internal Information)를 접속할 수도 있고 이런 요청(request)이 신뢰하는 서버(Server, 또는 IP 주소)로부터 온 것이기 때문에 내부 서버는 응답하고, 응답을 받은 웹 서버는 공격자에게 결과를 전달하게 된다.

이와 관련해 전문가들은 ▲미흡한 웹방화벽 운영 ▲권한 관리 오류(과도한 권한 허용) ▲미흡한 보안 모니터링 ▲웹 애플리케이션의 결함 ▲클라우드 서비스 제공 업체의 결함 등이 복합적으로 합쳐져 이와 같은 사고가 발생한 것이라고 분석하고 있다.

 

클라우드 도입이 어려운 가장 큰 이유, ‘보안 우려’

클라우드 보안과 관련된 통계를 보면, 보안 우려가 높은 것을 알 수 있다. 베스핀글로벌이 2019년 실시한 고객 설문조사에 따르면, 클라우드 도입 시 느낀 어려움 중 1위를 차지한 항목은 ‘보안 우려’로, 응답자의 47%를 차지했다.

 

또한, 클라우드 보안 연합(CSA: Cloud Security Alliances)이 2019년 세계 IT·보안 전문가 700명을 대상으로 ‘클라우드 보안 복잡성: 하이브리드 클라우드/멀티 클라우드 환경의 보안 관리 당면과제’를 위해 실시한 설문조사에서도 응답자 81%가 ‘클라우드 도입 시 보안을 고려한다’고 답했다. 이와 함께 퍼블릭 클라우드 운영 시 가장 우려되는 사항으로 민감한 고객정보와 개인정보 유출, 비인가자의 접근을 들었다.

현재까지 발생한 클라우드 보안 사고 사례와 대응 방안을 분석해 보면 ‘데이터유출’ 위협은 기본적으로 암호화를 적용하고 정교한 네트워크 정책 설정으로 대응을 해야 한다. ‘자격 증명 손상·인증 파괴’ 위협에 대해서는 자격증명이나 암호키를 보호하고 주기적인 암호키 교체와 다중 요소(Multi Factor)를 적용해 완화할 수 있다. 또한, 해킹된 인터페이스와 API의 경우는 인가된 사용자만 호출을 허용하도록 접근제어 정책을 강화해야 한다. 시스템 취약점 공격은 정기 취약점 점검을 수행하고 신속한 보안패치를 관리하는 등 대책이 필요하며, 계정 도용 위협은 계정 비밀번호에 대한 정기적 변경과 계정 자격증명 공유를 금지하고 추가 인증을 적용하며, 모니터링과 감사 기능을 강화하는 것으로 그 위험을 낮출 수 있다.

기존 온프레미스(On-Premise)에서 클라우드로 이전한 고객들은 네트워크 보안(또는 경계보안)만 생각하고 관리하는 경우가 많은데, 많은 클라우드 사고 사례에서 보듯 클라우드에서의 보안은 여러 영역에 대한 복합적인 보안을 고려해야 하고, 회사의 비즈니스와 서비스에 맞는 보안 프레임워크(Security Framework)를 만드는 것으로부터 시작해야 한다.

 

클라우드 네이티브?

인공지능, IoT, 5G 등 첨단 기술이 발전하면서 클라우드 기술을 활용해서 IT의 서비스를 지속적으로 제공하고 만들어 나가는, ‘클라우드 네이티브’의 중요성도 증대되고 있다. 클라우드 네이티브 보안에 대해 이해하기 전에, 클라우드 네이티브에 대한 개념부터 정립해 보자.

레드햇(Red Hat)이 발행한 자료에는 “클라우드 네이티브 애플리케이션이란 프라이빗, 퍼블릭이나 하이브리드 클라우드 환경 전체에 지속적인 개발과 자동화된 관리 환경을 제공하기 위해 특별히 설계된 애플리케이션”이라고 명시돼 있다.

또한, 클라우드 네이티브 컴퓨팅 파운데이션(Cloud Native Computing Foundation) 자료에 따르면, 클라우드를 도입한 조직은 공용, 사설이나 하이브리드 클라우드와 같은 최신 동적 환경에서 확장할 수 있는 응용 프로그램을 빌드하고 실행할 수 있다. 이와 같은 기술을 통해 사용자는 탄력적이고 관리하기 쉬우며, 관찰도 효율적으로 할 수 있는 시스템을 사용할 수 있다. 특히, 강력한 자동화를 통해 엔지니어의 수고를 덜어줄 수 있으며, 효율성을 높일 수 있다.

클라우드 네이티브 시스템에는 몇 가지 속성이 있다. 먼저, 애플리케이션이나 프로세스는 소프트웨어 컨테이너에서 분리된 단위로 실행된다. 또한, 프로세스는 리소스 사용을 개선하고 유지보수 비용을 줄이기 위해 중앙 오케스트레이션 프로그램에 의해 관리된다. 마지막으로, 애플리케이션이나 서비스(마이크로서비스)는 명시된 종속 항목과 느슨하게 결합돼 유연성을 가진다. 다시 말해, 유연성을 가지고 효율적으로 시스템을 사용할 수 있는 것이다.

 

클라우드 네이티브와 마이크로서비스·컨테이너

클라우드 네이티브 시스템은 마이크로서비스, 컨테이너 등 최신 시스템 디자인 수용을 통해 민첩성과 속도를 구현하게 된다. 여기서 주목할 것은 마이크로서비스(microservice)다. 마이크로서비스란 클라우드 네이티브 시스템이 최신 응용 프로그램을 구성하는 데 널리 사용되는 아키텍처 스타일을 말한다. 이와 관련해 마이크로소프트는 마이크로서비스의 몇 가지 특징에 대해 언급했다. 홈페이지 내용에 따르면 먼저, 마이크로서비스는 더 큰 도메인 컨텍스트 내에서 특정 비즈니스 기능을 구현한다. 또한, 자율적으로 개발되며 독립적으로 배포할 수 있다. 자체 데이터 저장소 기술(SQL, NoSQL)과 프로그래밍 플랫폼을 캡슐화하는 자체를 포함하며, 자체 프로세스에서 실행되고 표준 프로토콜을 사용해 타 사용자와 통신한다. 마지막으로 응용 프로그램을 구성하는 데 함께 포함된다.

(자료출처=Microsoft)

이러한 마이크로서비스를 사용하는 가장 큰 목적은 민첩성을 제공하기 위함이다. 모놀리식으로 빌드된 것과 비교했을 때 마이크로서비스는 수명 주기를 가지며, 독립적으로 발전하고 자주 배포할 수 있다. 이를 통해 전체 시스템을 방해하는 위험을 줄일 수 있는 복잡한 응용 프로그램의 작은 영역을 업데이트할 수 있게 되며, 독립적으로 확장될 수 있기도 하다. 전체 응용 그로그램을 단일 단위로 확장하는 대신 더 많은 처리 능력 또는 네트워크 대역폭이 필요한 서비스만 확장할 수 있게 되는 것이다. 이처럼 크기 조정에 대한 세분화된 접근 방식의 사용은 시스템을 보다 효과적으로 제어할 수 있고 확장 시 비용을 효율적으로 사용할 수 있다.

마이크로서비스와 더불어 클라우드 네이티브를 언급할 때 컨테이너(Container)란 단어도 빠지지 않고 등장한다. 클라우드 네이티브 컴퓨팅 파운데이션에 따르면, 마이크로서비스와 컨테이너화가 클라우드 기본 구조의 첫 번째 단계라고 볼 수 있는데, 이는 클라우드 전환을 시작하는 기업에 대한 기본적인 지침을 제공한다. 즉, 컨테이너는 동일한 구조를 다른 곳에 이식하고, 환경 간 일관성을 보장한다. 모든 항목을 단일 패키지로 캡슐화해 기본 인프라에서 마이크로서비스와 해당 종속성을 격리한다. 여기에서 도커(Docker)와 같은 도구는 이미지를 만들고 컨테이너를 실행하는 동안 관리하는 역할을 한다(Orchestrator).

 

클라우드 보안을 위해 알아야 할 것들

클라우드에서의 보안은 클라우드의 보안을 책임지는(Security of the Cloud) 클라우드 서비스 사업자(Cloud Service Provider)와 클라우드에서의 보안(Security in the Cloud)을 책임지는 클라우드 이용자(Customer) 간 역할이 분담된다. 이처럼 책임분담 모델(Shared Responsibility Mode)을 갖추고 있다.

클라우드 서비스 사업자는 데이터센터, 하드웨어, 호스트 운영 체제(Host Operating System), 하이퍼바이저(Hypervisor) 등 인프라 자체 보안에 대한 책임을 지며, 클라우드 서비스 이용자는 클라우드 모델에 따라 다르지만 IaaS(Infrastructure as a service) 기준으로 운영체제(OS), 미들웨어(Middleware), 데이터(Data, DB)에 대한 책임(ex. CSP Native 보안 서비스 사용시에 구성과 설정)을 갖는다.

소비자와 기업(AWS) 간 공동책임모델 (자료출처= AWS 홈페이지)

또한, 클라우드 네이티브 환경에서는 필요에 따라 신속하게 인프라 자산을 구성하고, 서비스를 배포할 수 있어야 한다. 이를 위해서는 표준 컴플라이언스(Compliance), 모범사례, 원천적인 취약점 점검이 핵심이 돼야 하며, 새로운 기술 인프라 보호도 필요하다.

또한, 컨테이너와 서버리스 환경에서 보안 자동화를 위해서는 기업의 운영 거버넌스와 소프트웨어의 개발(Development)과 운영(Operations)을 합친 데브옵스(DevOps) 성숙도에 따라 순차적으로 보안 영역을 도입할 수 있도록 구성한 보안 자동화를 이뤄야 한다. 마지막으로 개발, 운영, 보안을 하나의 조직(팀)에서 수행할 수 있는 체계도 마련해야 한다.

이 데브옵스에 보안을 추가한 것이 데브섹옵스(DevSecOps)다. IT의 모든 것은 보안(security)과 연계돼 있어야 한다는 개념이다. 다음 호에서는 데브섹옵스에 대해 좀 더 자세히 알아보도록 하겠다.

 

이 기사를 공유합니다
저작권자 © 테크월드뉴스 무단전재 및 재배포 금지
이 기사와 관련된 기사