[SaaS 보안 05] 클라우드와 보안 아키텍처

출처: pexels.com
최근 유명 대기업 브랜드의 아파트 일부가 무너져서 사회적 불안과 비난이 비등해졌다. 전문가들은 설계, 시공, 감리에 모두 문제가 있다는 의견을 내놨다. 시공과 감리의 토대가 된다는 점에서 대기업 브랜드의 아파트에 설계 문제가 있었다는 지적은 상당히 충격적이다. 설계가 잘못되면 시공이 잘될 리 없고, 감리에서 그것을 잡아내기도 쉽지 않을 것이기 때문이다.
소프트웨어 개발에서 ‘아키텍트’(Architect), ‘아키텍처’(Architecture)’라는 용어는 건축에서 왔다. 건축과 마찬가지로 구현(코딩)하기 전에 설계가 이뤄져야 한다는 뜻이다. 건설에서 온 용어는 그대로 사용하면서도, 설계 없는 시공은 상상할 수 없지만, 설계 없는 코딩은 (국내) 소프트웨어 개발에서는 종종 일어난다. 설계가 있다 하더라도 코딩하는 개발자의 손끝에서 바뀌는 일 역시 드물지 않다. 오히려 하청-재하청-재재하청-재재재하청을 통해 ‘프리랜서’로 이어지는 국내 SI 업계의 ‘단가 후려치기’ 구조는 건설산업을 닮았다.
보안 분야에서도 ‘보안 아키텍처’가 중요하다는 말을 가끔 한다. 대규모로 시스템을 구축하는 대기업이나 금융회사에서는 엔터프라이즈 아키텍처(EA) 또는 IT 아키텍처의 하나로 보안 아키텍처를 설계하는 것이 보통이지만, 중견·중소기업에서 서비스를 개발하면서 보안 아키텍처를 심각하게 검토하는 경우는 별로 보지 못했다.
네트워크와 시스템, 엔드포인트, 데이터, 사업, 컴플라이언스, 보안 위협 등에서 나오는 보안 요구사항을 종합적으로 대응할 수 있는 보안 아키텍처를 구성해야 하는데 말이다. 회사에 이미 IT 시스템이 구축되어 있으면, 보안 솔루션을 도입할 때, 현 IT 아키텍처에 적당하게 끼워 넣곤 한다. 개인정보보호법을 준수하기 위해 ‘침입차단장치’를 운용해야 하니 네트워크 방화벽을 적당하게 도입하는 식이다.

그림 1. 시스템 설계 시 다루는 영역 (출처: 마이크로소프트, “보안 핵심 요소 개요”, 클라우드 기술 과제, 2023)
클라우드에서는 보안 아키텍처를 제대로 구성하지 않으면 침해사고가 나기 십상이다. 온프레미스(On-premise)와는 달리 클라우드는 인터넷을 사용하는 사람이라면 누구나 쉽게 접근할 수 있어서다. 급성장한 대형 스타트업에서 개인정보 유출 사고가 난 것도 이 때문일 가능성이 높다.
예를 들어 AWS에서 VPC를 하나 생성하려면, 목적에 따라 이용할 리전(region)과 가용영역을 선정하고, public/private subnet을 구성해야 한다. 웹 서비스, WAS, DBMS를 어디에, 어떻게 구성할지 역시 정해야 한다. 또한, 어떤 권한을 가진 사람이 어떤 방법으로 안전하게 각 가상자원에 접속할지 방안을 수립해야 한다.
NACL(Network Access Control List) SG(Security Group), WAF(웹 방화벽) 등 네트워크 보안 설정도 마찬가지다. S3를 사용한다면 그에 대한 보안 설정 역시 검토해야 한다. 잘못하면 인터넷을 이용하는 ‘아무나’ 접속할 수도 있다. 그런 클라우드를 노리는 악의적 공격자에게는 좋은 먹잇감이다. S3 저장한 데이터의 유출 사건이 종종 일어나는 이유가 바로 여기에 있다. 이 모든 과정에서 언제나 편의성과 보안, 비용의 세 변수를 고려해야 한다.

그림 2. AWS에서의 로깅과 모니터링 (출처: 스캐터랩 기술블로그)
가트너가 ‘적응형 보안 아키텍처’로서 “예측-예방-탐지-대응”을 제안했는데, 클라우드에서는 클라우드의 가상자원에서 발생하는 대부분의 활동을 손쉽게 로깅하여 모니터링할 수 있다. 보안 관련 로그를 생성하는 서비스가 클라우드에서 제공하는 것을 사용한다면 로그의 수집과 분석이 훨씬 쉬워진다. 거기에 ‘람다’(Lambda) 기능을 활용하면 탐지와 대응을 자동화할 수 있다.
소프트웨어 개발 플랫폼으로서 클라우드를 이용한다면, 개발 환경을 어떻게 꾸릴지도 중요한 과제다. 개발 환경에 강력한 보안 울타리를 치고, 개발자가 그 안에서 자유롭게 개발과 시험을 해 볼 수 있도록 하는 것이 보통이다. 다만 개발 환경과 운영 환경을 명백하게 구분, 차단하지 않으면, ‘자유로운 영혼’을 가진 개발자들이 운영 시스템도 개발 시스템에 접속하듯 접근하는 위험이 발생할 수 있다.
로컬이나 데이터 센터에서 자체적으로 구성한 시스템에 새로운 시스템을 추가하거나 기존 시스템을 변경할 때는 이들 시스템의 이력을 잘 아는 엔지니어가 잘 처리해 주지만, 클라우드를 사용하려고 하면 상황이 많이 다르다. 클라우드에 적합한 방식으로 새롭게 아키텍처를 구성해야 한다. 일반적으로 일정한 보안 수준을 제공하는 레퍼런스 보안 아키텍처가 있으므로, 이를 기반으로 회사의 요구사항을 수용해 클라우드 인프라를 구성하는 것이 바람직하다.
국내에서 본격적으로 퍼블릭 클라우드를 사용한 경험이 그리 길지 않아서 클라우드 보안 분야는 경험 있는 인력이 많이 부족하고 각 회사가 쌓은 경험을 공유하는 수준이다. 클라우드 업체는 물론이고 클라우드 관리서비스 제공업체(MSP)에서도 속 시원한 지원을 받기가 쉽지 않다. 따라서 클라우드를 이용하려는 조직에서는 무엇보다도 클라우드 보안 인력 확보에 노력을 기울일 필요가 있다. 클라우드 인프라 운영도 함께할 수 있는 인력(SecOps)이라면 더욱 좋다. 퍼블릭 클라우드를 이용하기 위해 토대를 쌓는 일이다. 잘못하면 소 잃고 외양간 고칠 일이 생길 수 있다.