클라우드 관리 자동화의 4단계

보안 전문가의 클라우드 자동화 여정

컨퍼런스에서 저를 만나신다면 “클라우드 보안은 아키텍처에서 시작해 자동화로 끝난다”고 말하는 것을 듣게 되실 가능성이 큽니다. 그리고 곧이어, 데이터센터 계약이 끝나 불을 끄기 전에 지저분한 리프트 앤 시프트라는 현실에 발이 묶여 있더라도 클라우드 네이티브 사고방식을 갖추는 것이 얼마나 중요한지 덧붙입니다. 듣기 좋은 문구이긴 하지만, 제가 어떻게 기본기 위주의(방화벽과 패치 관리 중심의) 보안 전문가에서 아키텍처와 자동화를 다루는 클라우드 네이티브로 옮겨갔는지는 전혀 설명해 주지 못합니다. 산 위에서 설교하기보다는, 제 개인적인 여정과 그 과정에서 얻은 기술적 깨달음을 이야기하는 편이 더 유용하다고 봅니다. 보안 전문가이시거나, 보안 전문가의 클라우드 역량을 끌어올리려는 분이시라면 아마 매우 비슷한 길을 걷게 되실 것입니다.

1단계: 구성 자동화

제 경우 모든 것은 약 9년 전, Cloud Security Alliance의 첫 교육 프로그램을 만들어 달라는 요청을 받았을 때 시작되었습니다. 초기에 저는 전 세계 어디에서나 실행할 수 있고, “개발자”부터 “서류 작업 위주의 감사인”까지 다양한 역량을 가진 수강생과 강사 모두가 사용할 수 있는 반복 가능한 실습 환경이 필요하다는 것을 깨달았습니다. 당시 Amazon Web Services는 IAM을 본격적으로 출시하기 전이었고 VPC는 프라이빗 네트워크 전용이었습니다. 그리고 Infrastructure as Code 같은 개념은 이제 막 실현 가능해지던 시기였습니다.

그래서 저는 수천 명의 수강생을 위해 클라우드에서 실습형 애플리케이션 스택 랩을 어떻게 구축할지 고민하게 되었습니다. 일관성 있게, *그리고* AWS가 기술을 발전시킬 때마다 업데이트할 수 있어야 했습니다. 당시에는 자체 AMI를 만드는 일이 여전히 번거로운 작업이었는데, 그때 `cloud-init`의 놀라움을 알게 되었습니다. S3 버킷에 호스팅할 수 있는 간단한 스크립트와, 수강생이 인스턴스의 User Data 필드에 붙여넣을 수 있는 두 줄짜리 코드만으로 인스턴스를 시작 시점에 정확히 필요한 대로 구성할 수 있었습니다. 그리고 소프트웨어 업데이트로 문제가 생기면, 공개된 URL의 해당 스크립트만 수정하면 모든 신규 인스턴스가 새 구성을 사용했습니다 — 마법 같았죠! 이미 실행 중인 것을 패치하는 데에는 도움이 되지 않았지만, 새 AMI를 갱신하고 게시하는 것보다 훨씬 손쉽게 좋은 첫 실행 경험을 유지할 수 있었습니다. 그리고 평판을 완전히 무모하게 거는 셈이지만, 이후 버전 중 하나를 아직도 여기 S3에서 보실 수 있습니다.

제 첫 걸음은 `cloud-init`이었습니다. 지금은 더 이상 사용하지 않지만, 복사-붙여넣기와 호스팅된 파일 하나만으로 서버 전체를 스크립트로 구성해 실행할 수 있다는 점은 눈이 번쩍 뜨이는 경험이었습니다.

2단계: 워크플로 자동화

그러나 다음 단계는 훨씬 더 큰 영향을 미쳤습니다. 몇 년간 실습 교육을 진행하고 제 워크로드를 직접 구축한 뒤, 저는 Software Defined Security라는 아이디어를 시험해 보기 시작했습니다. 제 앞에는 “나를 호출해 보라”고 속삭이는 클라우드 API가 풍성하게 놓여 있었습니다. 예제를 찾아보기 시작했지만… 아무것도 없었습니다. Security Monkey조차 아직 공개되기 전이었습니다.

마침 Black Hat 보안 컨퍼런스에서 진행할 강의가 예정되어 있었고, 저는 이를 핑계 삼아 Ruby와 (Ruby SDK를 통한) AWS API를 익히기로 했습니다. 결국 세 가지 데모를 작성하게 되었습니다.

• 인스턴스를 격리하고, 모든 메타데이터를 분석하며, AWS IAM으로 잠그고, 모든 스토리지를 이미지화한 뒤, 연결된 스냅샷을 분석할 준비가 된 포렌식 분석 서버를 기동하는 사고 대응 애플리케이션. 예전에는 30분이 걸리던 작업을 3초 만에 처리했습니다.
• AWS와 Chef에 연결해 Chef를 실행하지 않는 모든 인스턴스(‘비관리’ 서버)를 식별하는 소규모 애플리케이션. 전통적인 데이터센터에서는 몇 주가 걸릴 수 있는 작업입니다.
• Qualys 스캐너에 대해 보안 그룹을 열고, 스캔을 실행한 뒤, 완료되면 보안 그룹을 다시 닫는 또 다른 애플리케이션.

이전에 Ruby로 코딩해 본 적이 없었기 때문에 세 가지를 모두 구동하기까지 파트타임으로 약 두 달이 걸렸습니다. 매우 단순한 것들이었지만, 값진 교훈을 얻었습니다.

• 자격 증명 관리는 매우 중요했고, 동시에 코드를 공유하고 다른 사람들이 환경을 올바르게 구성하도록 하는 일을 더 어렵게 만들었습니다. 구성 파일에서 값을 가져오는 방식은… 번거로웠습니다. 특히 어느 리전의 어떤 보안 그룹을 격리 그룹으로 사용할지와 같은 사항에서 그랬습니다.
• 로컬 시스템의 Ruby에서는 잘 작동했지만, AWS 인스턴스에서 코드를 실행하면 서비스 한도를 초과해 지연 타이머를 삽입해야 했습니다. API 서비스 한도는 결코 우군이 아닙니다.
• 이 모든 것이 사실상 정적이었습니다. 데모용으로는 꽤 그럴듯했지만, 결국 데스크톱이나 인스턴스에서 코드를 수동으로 실행하는 것에 불과했습니다. 그 방식은 세월을 잘 견디지 못했습니다.

저는 이것들을 “SecuritySquirrel”로 패키징했으며, GitHub에서 2014년 버전을 확인하실 수 있습니다. 믿기 어려우시겠지만, 그것들조차 게시 전 몇 년간 사용했던 원본은 아닙니다.

3단계: 클라우드 자체의 자동화

AWS가 CloudWatch용 Rules를 출시했을 때, 저는 그다음 토요일 아침 약 2시간 만에 Python 코드를 급히 작성해 10-15초 이내에 모든 보안 그룹 변경을 되돌릴 수 있게 만들었습니다. 여기에는 태그, VPC 또는 변경 요청자를 기준으로 방어 범위를 지정하는 필터도 포함되었습니다. 코드와 설명서를 다운로드하실 수 있으며, 제 Ruby 코드와 달리 3년 된 클라우드 코드치고는 지금도 꽤 잘 작동합니다.

그 첫 데모 이후 저는 Lambda에서 실행되는 이벤트 기반 자동화 라이브러리를 구축해 왔으며, 그중 일부는 다운로드하실 수 있습니다. 그 패키지에서 제가 가장 좋아하는 것은 `identify_internet_facing_servers.py`로, 데모 목적으로 Amazon Dash 버튼의 IoT 버전을 클릭하면 실행되도록 연결해 두었습니다. 맞습니다, 저는 실제 물리적인 Easy 버튼을 주머니에 넣고 다닙니다. 이 스크립트는 인터넷에 22번 포트가 열려 있는 모든 인스턴스를 찾아내며, 버튼을 두 번 클릭하면 해당 규칙을 취소하고 모든 것이 안전해지면 휴대폰으로 문자 메시지를 받습니다.

여기서 얻은 핵심 교훈은 예상 밖의 것이었습니다. 이러한 이벤트 기반 자동화가 호스트 기반 워크플로를 대체한 것이 아니라, 서로 다른 목적을 수행한다는 점이었습니다. 저는 제가 일을 더 빠르게 처리하기 위한 워크플로 구축에서, 백그라운드에서 안전을 지켜주는 가드레일 구축으로 옮겨왔다는 것을 깨달았습니다. 두 가지 모두 엄청난 가치를 지닙니다.

4단계: 모든 것의 자동화

가장 최근에 제가 진행한 작업은 Jenkins와 Infrastructure as Code(주로 CloudFormation)를 활용해 보안을 강화하는 것이었습니다. 이 조합을 통해 인프라와 애플리케이션 자체에 보안을 자동화해 넣고 외부 도구에 대한 의존도를 낮출 수 있습니다.

예를 들어, 저는 Jenkins에서 실행되어 빌드를 시작하기도 전에 저장된 액세스 키를 찾아내는 간단한 자격 증명 스캐너를 공개했습니다. 나중에 찾아내려고 기다릴 이유가 있을까요? 이후 저는 Jenkins에서 원하는 거의 모든 평가 도구를 실행하고, 네트워크 스캔과 같은 보안 테스트에 실패하면 빌드를 실패 처리할 수 있도록 다른 테스트 하네스를 작성했습니다(팁: 스크립트에서 0 이외의 종료 코드를 보내면 Jenkins는 빌드를 실패 처리합니다).

다시 처음으로 돌아가서, 저희는 이제 CloudFormation 템플릿을 사용해 애플리케이션 스택의 모든 요소를 구축하는 방식으로 교육 과정을 운영하며, 덕분에 수강생은 보안을 더하는 데 집중할 수 있습니다. 일관된 교육용 서버를 구축하던 단계에서 일관된 교육용 환경을 구축하는 단계로 나아갔으며, 맞춤형 AMI는 전 세계적으로… 아주 적은 노력으로 몇 분 만에 업데이트할 수 있고, 모든 소프트웨어가 사전 설치되어 최종 구성만 남은 상태입니다.

제 클라우드 여정은 약 9년 전에 시작되었고, 자동화 여정도 거의 같은 시기에 시작되었습니다. 처음에는 무언가를 만든 다음 일부를 자동화하려 했지만, 지금은 자동화를 전제로 시작합니다. 초기 작업은 운영에 관한 것이었지만, 요즘은 거의 전부가 보안에 집중되어 있습니다. 운영 부담을 녹여 없애고, 제 머릿속의 보안 영역이 가장 잘하는 일에 집중할 수 있게 하는 데 말입니다. 그 과정에서 모든 자동화가 동등하지는 않다는 점도 배웠습니다. 가드레일, 워크플로, 크로스 플랫폼 오케스트레이션, Infrastructure as Code, 파이프라인 자동화가 각각 쓰일 자리가 있습니다. 이 모든 것이 이제 상상하기 어려울 만큼의 보안 이점을 제공하지만, 문서화가 부실한 API를 역으로 분석하느라 일주일을 날릴 수도 있는, 여전히 매우 이른 시기에 있습니다.

보안 업무를 하고 계시다면 이제 코드 역량을 갖추실 때입니다. 개발이나 운영 업무를 하고 계시다면 이제 보안 역량을 갖추실 때입니다. 가장 큰 교훈은, 우산처럼 덮어씌우는 보안의 시대는 끝났고 구조 안에 짜여 들어간 보안의 시대가 왔다는 것이기 때문입니다.