들어가며…

지난 2월 오석윤님이 포스팅해주신 [AWS에서 네트워크 공격 자동차단하기]의 Summary에서 내용을 일부 가져오고자 합니다.

“Public Cloud 환경에서의 서비스 운영은 Legacy 환경의 IDC 서비스 운영과는 너무도 다르기 때문에 보안이 쉽지 않다.”.

특히나 국내 실정에 맞추어 만들어진 ISMS 인증 표준 또한 Cloud 서비스에 맞추기 위해 변화하고 있지만 아직은 IDC 환경의 서비스에서 준비하기가 조금 더 원활하도록 초점이 맞추어져 있다고 생각이 됩니다.

따라서 이번에 ISMS 인증심사를 준비하며 겪었던 몇 가지 이슈사항들과 어떻게 해결하였는지 그 과정을 정리하고자 합니다. 하지만 공개되어 있는 공간이므로 실제 심사 결과의 취약점은 다루지 않고 심사를 준비하며 겪었던 내용을 바탕으로 포스팅해보겠습니다.

솔직히 기술적인 부분이 많이 들어가지 않은 글을 기술 블로그에 쓰려고 하니 걱정이 앞섭니다. [기술이 없는 기술블로그를 작성해보자]

보안인증 관점에서 본 Hybrid-Cloud 환경

우선 보안인증에서 첫걸음으로 가장 중요한 부분은 인증 범위의 선정이라고 볼 수 있습니다. ISMS 인증의 경우 관리체계 수립이 자산을 기준으로 진행됩니다. “배달의민족 서비스”에 대한 ISMS 인증을 받고자 한다면 인증 범위에는 배달의민족 서비스를 위한 자산(서버, DB, 네트워크장비, 개발자의 PC 등)들이 모두 포함되게 됩니다. 그리고 인증 범위에 포함된 자산들이 AWS와 IDC에 나누어져 운영되고 있다면 AWS와 IDC 모두가 인증 범위에 포함되어 인증 대상이 되어야 합니다.

사무실도 예외로 할 수 없습니다. 개발을 하고 기획을 하는 모든 업무가 배달의민족 서비스에 반영되고, 개발자와 기획자가 업무를 하며 이용하는 백오피스 시스템도 배달의민족 서비스의 한 부분이니까요. 따라서 사무실 보안에 대해서도 보안대책을 세워야 합니다.

[CCTV같은 물리적 보안도 포함해서 말이죠]

여기까지 인증 범위 선정하기가 정리되었습니다. 하지만 문제는 여기서부터 발생합니다. 일반적으로 많이 사용하는 IDC와 Cloud 서비스를 제공하는 AWS는 다른 부분이 너무 많았습니다. 물리적으로 존재하는 방화벽이 아닌 SecurityGroup… 서버가 하루가 다르게 생겼다 없어졌다 하는 EC2… 등등 AWS의 이런 편리한 기능들은 서비스와 관리를 하기에는 굉장히 유용하지만 자산을 바탕으로 정보보호 관리체계를 수립해야 하는 ISMS 인증 준비단계에서 큰 고민거리가 되었습니다.

인증을 준비하며 생긴 고민거리들

시스템의 취약점진단과 위험평가

회사에서 정보보호관리체계를 세우기 위해서는 우선 보호하고자 하는 자산의 식별과 식별된 자산의 위험평가 그리고 위험평가를 위한 취약점 진단이 진행되어야 합니다. 하지만 Cloud 서비스에서는 자산의 식별부터 막히게 됩니다. Auto-Scaling 등과 같은 Cloud 서비스의 특성으로 인해 식별되어야 하는 자산이 하루가 다르게 생겼다 없어졌다를 반복해버립니다. 또한 식별이 되었다 한들.. 이렇게 변화무쌍한 서버들에 대해서 취약점 진단과 위험평가는 어떻게 진행해야 할까요. 이 부분이 중요한 이유 중 하나는 ISMS 인증심사 진행 시 심사비용 수수료 결정에 가장 큰 영향을 미칩니다. 자산 수에 따라 심사일수를 정하게 되고, 정해진 심사일수에 따른 수수료가 결정이 되죠.


개인정보 암호화통신 이슈

두 번째로는 개인 정보를 전송할 때에는 암호화 통신이 되어야 합니다. 하지만 서비스를 AWS와 IDC에서 함께 사용하는 환경인 경우, 정적인 통신 대상과 동적인 통신 대상이 있고 시스템의 환경 설정을 할 수 없도록 되어있는 Public Cloud의 관리형 서비스 환경 등… 이렇게 제한되어 있는 상황에서 어떤 보호대책을 수립해야 효율적인 서비스를 유지하면서 컴플라이언스를 만족할 수 있을까요.

[서울에도 Region이 있다. 이건 비밀인데 어디에 있냐면…]

보안장비의 운영

세 번째로 AWS은 사용되는 IP 주소 목록이 Public 하게 공개되어 있습니다. 그에 따른 보안 위협은 끊임없이 들어오는 단순 스캔 공격만 봐도 알 수 있습니다. 보안 위협을 방어하기 위한 IPS, 웹방화벽 등과 같은 보안장비의 적용이 필요합니다. 하지만 일반적으로 AWS에서는 IDC 환경처럼 물리적 보안장비를 직접 구축하여 운영할 수가 없습니다. Region이 어디 있는지 모르고, 어디 있는지 알더라도 들어갈 수 없으니까요. 공격자가 전산센터의 위치가 어디 있는지 모르고 들어갈 수 없지만 사용자도 같이 모르고 들어갈 수가 없으니 안전하다니… 대체 어떻게 해야 할까요.

[심심하면 들어오는 SSH BruteForce 공격]

고민거리들의 극복방법

시스템의 취약점진단과 위험평가 수행

AWS의 급변하는 인스턴스에 맞춰 자산을 식별하려면 자산 식별의 기준이 필요했습니다. 첫 번째로 자산 목록을 결정할 특정 기준일을 정했습니다. 해당 특정 기준일을 시점으로 최근 한 달간 변화를 보고 최소로 줄어든 인스턴스 개수를 자산목록에 기입하여 식별하였습니다. 예를 들어 하나의 Baemin-server라는 호스트네임을 가진 인스턴스가 Auto-Scaling으로 인해 한 달간 최대로 늘어난 수가 Baemin-server-1~20이고, 최소가 Baemin-server-1~4로 나타났다면 자산 식별 수는 4개로 결정하고, 식별된 자산 목록에는 Baemin-server-1,2,3,4로 4개의 server가 들어갑니다.

다음 식별된 자산을 기준으로 취약점 진단을 진행해야 하는데, 동일한 설정을 가진 시스템이라는 전제하에 1대씩 샘플링으로 진행을 합니다. 일반적으로 취약점 진단은 체크리스트를 기반으로 스크립트를 통한 수동 점검을 진행합니다. 하지만 AWS에는 애플리케이션의 취약성 또는 모범 사례와 비교한 차이점을 자동으로 평가하는 Amazon Inspector(이하 Inspector)라는 취약점 자동 점검 툴이 있습니다. 운영 중인 서비스에 직접 툴을 적용할 경우 리소스 과부하가 발생하지 않으리라는 보장이 없기 때문에 운영 인스턴스들을 복사하여 별도의 VPC를 생성한 뒤 툴을 적용한 후 취약점 점검을 진행하였습니다.

하지만 Inspector를 통한 점검 결과로 위험평가를 진행하기에는 기존의 위험평가 Concerns List와는 다른 점이 많았습니다. 그래서 기존의 항목을 기반으로 Inspector를 이용하여 점검할 수 있는 항목을 Concerns List에 녹여냈습니다.

[서버 취약점 점검 평가 항목]

[위험평가 Concern List 일부인데 잘 안보이는게 맞습니다. 가렸으니까요.]

그 다음은 당연히 발견된 취약점에 대해 위험조치계획을 수립하고 위험관리를 수행하면 됩니다.

개인정보 암호화통신을 위해서 해야할일

실제 우아한형제들의 시스템 간 네트워크 구성이 어떻게 되어있는지는 언급하지 못하므로 검토했던 내용 중 2가지에 대해 간략하게 기술해보겠습니다. 우선 AWS-IDC 간 개인정보가 평문으로 전송되지 않도록 하는 것이 핵심이었습니다. 개인정보의 암호화 통신이 키워드이니까요.

첫 번째로 AWS에서 제공하는 Direct Connect 서비스가 있습니다. 용어 그대로 IDC환경의 온프레미스 IT 자원과 AWS 클라우드 자원을 전용 회선으로 연결하는 서비스입니다. 전용선을 구축할 경우 암호화통신으로 볼 수 있기 때문에 개인정보 암호화통신 이슈를 해결할 수 있습니다.

두 번째로 IDC의 서비스와 분리하여 배달의민족 서비스가 AWS 내부에서만 통신 가능하도록 구성하는 방법이 있습니다. 완전한 Cloud 서비스 환경으로 구성하는 아주아주 간단한(?) 방법입니다. IDC가 아닌 Cloud 내부에서만 통신을 하게 된다면 이슈가 줄어들게 됩니다.

여러 가지 방법들 중 회사의 환경과 상황에 맞게 구축 진행하면 해결할 수 있는 문제였습니다.

[이러지 않았으면 좋겠습니다.]

클라우드환경에 적용하기 힘든 보안장비들

현재도 그렇고 앞으로도 가장 고민이 많은 부분입니다. 보안장비를 구축함에 있어서 석윤님이 포스팅해주신 “자동화”가 핵심이라고 생각합니다. 공개되어 있는 공간인 만큼 특정 제품을 언급하지는 못하지만, Public Cloud 환경의 특성상 선택폭이 상대적으로 크지가 않습니다.

하지만 현재 AWS에 적용이 가능한 보안 제품들이 많이 나오고 있으며, appliance 형태의 보안장비가 아닌 SaaS 형태의 보안장비는 AWS에 인스턴스를 생성하여 구축, 운영할 수 있습니다. 현재 회사에서 꼭 필요한 것이 무엇인지, 또 잘 활용할 수 있는 보안장비가 무엇인지 파악하는 것이 중요하다고 생각합니다.

하지만 아직 가야할 길이 멀다.

[이번 고비가 지나면 다음 고비가 온다. 정말로. 꼭 옵니다.]

현재 많은 기업들이 비용 면에서 효율적인 Public Cloud 서비스를 이용하고 있습니다. 하지만 아직 국내 컴플라이언스가 Public Cloud 환경과 맞지 않는 부분이 많은 것으로 보입니다.

(우아한형제들의 공식적인 입장이 아닙니다. 우아한형제들은 국내 보안규정을 준수하고 있습니다.)

컴플라이언스를 충족하면서 정보보호관리체계를 구축하고 운영하려면 아직 많은 고민거리들이 존재합니다.

  1. AWS에서 제공하는 클라우드 보안 제품은 많지만 서울리전에서 사용이 가능한 제품(예를 들면 AWS WAF)은 상당부분 제한됩니다.
  2. Cloud 서비스만 사용하였을때 여러가지 부가적인 비용(RDS, Aurora 등)이 생각보다 많이 발생합니다.

등등… 많은 고민들이 생겨나고 해결되고 또 다시 생겨나게 될 겁니다.


물론 위에서 언급했던 방안들이 모두 정답이라고는 할 수 없습니다.
하지만 급변하는 IT 환경 속에서도 우리는 답을 찾을 것입니다. 언제나 늘 그랬듯이

  • 기술적인 부분에서 도움주신 오석윤님께 감사드립니다.