AWS SSM Run Command를 활용한 보안 취약점 자동화하기
안녕하세요. 스푼라디오 SRE 팀에서 DevOps 업무를 담당하고 있는 Daniel(남태윤)입니다.
현재 스푼라디오는 고객의 데이터와 서버 보안을 안전하게 관리하고자 여러 심사 및 인증 절차를 받고 있습니다. 그중 서버 보안 점검은 Multi Account & Multi Region인 사내 클라우드 환경에서 500여 개가 넘는 인스턴스의 다양한 정보를 확인 및 관리해야 한다는 요구사항이 있습니다.
이를 위해 매년 보안팀에서 전달해준 보안 점검 스크립트를 실행하고 결과물을 공유 함으로써 업무를 완료했습니다. 단순 반복 업무를 매년 실행하는 것은 비효율적이며, 보안팀에서 필요한 결과물을 즉각적으로 확인 할 수 없다는 한계를 극복하고자 보안 점검 자동화를 고민하게 되었습니다. 해당 업무를 자동화 함으로써 궁극적으로 이루고자 하는 목표는 아래와 같습니다.
- 스크립트 수행을 자동화 함으로써 업무의 효율성을 높인다.
- 스크립트 수행 결과를 하나의 폴더에서 통합 관리한다.
- 보안팀 자체적으로 언제든지 서버 점검을 실행 할 수 있도록 제공한다. 이를 통해 업무 프로세스를 효율화 시킨다.
위의 목표를 기반으로 현재 사내에서 사용하고 있는 AWX와 AWS SSM Run Command를 검토하게 되었고, 목표를 달성하기 위한 적절한 Tool은 무엇일지 고민하게 되었습니다.
AWX를 활용한 보안 점검
스푼라디오는 ArgoCD, Spinnaker, Jenkins 등 다양한 파이프라인 도구를 활용하여 개발자 분들이 안정적이고 신속하게 서비스를 배포하고 있습니다. 이중 AWX는 Jenkins와 함께 연동되어 인스턴스의 서비스 Configuration을 구성 해주고 있습니다. [ Link ]
위와 같이 AWX는 특정 인스턴스에 접속하여 원하는 작업을 실행시킬 수 있습니다. 인스턴스 Tag 정보 기반으로 보안 점검 대상 서버들을 필터링 할 수 있으며, Ansible을 통해 스크립트를 수행하고 결과물을 S3에 업로드 할 수 있습니다.
하지만, 사용자 측면에서 다소 아쉬운 점이 존재합니다. Jenkins를 이용해 배포하고 있는 만큼, 일부 사용자 분들도 AWX 사용여부를 모를 때가 있습니다. 또한 범용적으로 AWX를 사용 하기에는 UI가 다소 불편합니다.
- 비개발자 입장에서 사용자 친화적인 UI 제공 X.
- 직관적으로 작업 수행 결과를 파악하기 어려움.
AWX를 활용해 자동화 했을 경우 이미 사내에서 사용하고 있는 만큼 초기 셋팅 비용은 발생하지 않습니다. 그러나 앞서 언급한 목표 중 하나인 보안팀에서 필요할때 언제든지 서버 점검을 실행하기 위해서는 보다 손쉽게 사용 할 수 있어야 합니다.
AWX의 경우 스크립트 수행 결과를 로그 정보로만 확인 할 수 있고, 이마저도 인스턴스 IP 정보로만 확인 가능합니다. 서버 보안 점검 업무가 자주 실행되지 않는 만큼 사용자 입장에서는 보다 직관적인 UI와 편리한 구성이 필요하며, 다수의 인스턴스 스크립트 실행 결과를 바로 확인 할 수 있어야 합니다.
즉, AWX를 활용해 보안 점검 자동화를 적용하는데 기술적으로 부족한 점은 없으나 사용자 편의성 측면에서 100% 만족 할 수 없었습니다.
Run Command를 활용한 보안 점검
Run Command란 AWS의 System Manager의 기능중 하나로써 모든 EC2 또는 기타 AWS 서비스에 접속하여 일반적인 관리 작업을 자동화하고 대규모로 일회성 구성 변경을 수행할 수 있는 서비스입니다. EC2와 동일하게 각 Region별로 작업을 구성 할 수 있어 동일한 작업 내용이라 해도 초기 설정을 반복적으로 수행해야 합니다.
Run Command는 보안 점검 자동화를 구성하는데 있어서 기술적인 조건을 모두 만족합니다. Tag 정보 기준으로 타겟 인스턴스를 필터링 할 수 있으며 내부에서 동작 할 수 있는 쉘스크립트를 작성 함으로써 업무를 자동화 시킬 수 있습니다. 뿐만 아니라 AWS 환경에서 제공하는 직관적인 UI를 통해 각 인스턴스에서 실행된 작업 결과와 로그 정보를 확인 가능합니다.
앞서 AWX에서 아쉬웠던 사용자 편의성을 보완 해줌으로써 보안 점검 자동화 업무를 구현했을 때 가장 알맞은 Tool이라고 볼 수 있었습니다.
사용성 측면 이외에 Run Command 장점은 비용이 발생하지 않는다는 것입니다. 이미 사내에서 AWX를 사용하고 있는 만큼 만약 Run Command 활용 시 비용이 발생한다면, 비용 절감 및 운영 효율성을 고려하여 재검토 했을 것입니다.
Run Command 적용방법
AWX와 Run Command 모두 기술적으로 자동화 기능을 도입 할 수 있으나 보안팀에서 언제든지 수행 할 수 있도록 제공하기 위해서는 무엇보다 편리한 사용성과 직관적인 UI가 중요합니다. 따라서 Run Command는 AWX와 비교했을 때 각각의 인스턴스에서 실행한 스크립트 결과를 바로 확인 할 수 있으며, 로그 파일을 S3로 저장 및 관리 할 수 있기에 효율적일거라 판단했습니다.
위와 같은 이유로 Run Command를 이용해 보안 점검 자동화를 적용하기로 했으며, 전체적인 구성은 아래와 같습니다.
앞서 설명드린 Run Command에서 인스턴스의 특정 Tag 정보 기준으로 필터링 하기 위해서는 사전 작업이 필요합니다. 보안 점검 대상 인스턴스에 원하는 Tag(securityCheck:true) 정보가 입력되어 있어야 하며, 해당 부분은 AWS CLI를 이용해 실행합니다.
이후 각 인스턴스에서 수행하기 위한 스크립트는 위의 구성과 같이 순서대로 동작 할 수 있게 작성합니다. 그중 Run Command가 아닌 Bibucket Repository를 이용해 필요한 스크립트를 다운로드 받는 이유는 Run Command의 스크립트 용량 제한(Max 65KB)과 보안 점검 파일을 자유롭게 관리하기 위함입니다. 따라서 추가적인 로직(ex. 보안 점검 스크립트 / S3로 파일 업로드)은 Bibucket을 이용해 수행 할 수 있도록 구성합니다.
AWS 메타데이터(http://169.254.169.254/latest/meta-data/instance-id)의 경우 S3에 업로드 시 인스턴스 이름으로 오브젝트를 업로드 하기 위해 관련 정보를 조회하기 위한 용도로 사용합니다.
다만, 위의 구성과 같이 동작하기 위해서는 전제 조건이 필요합니다.
- Secret Manager를 이용해 Bitbucket Repository SSH 설정 필요
- 파일 업로드 하기 위한 S3 권한 필요
Bitbucket Repository를 다운로드 받기 위해서는 지정한 Secret Manager로 부터 SSH키를 전달받고, S3로 스크립트 결과를 업로드 해야합니다. 이러한 과정을 실행하기 위해서는 SSH 키를 관리하고 있는 Secret Manager와 S3 업로드 권한이 필요합니다.
모든 인스턴스에 해당 권한이 필요한 만큼 일괄적으로 적용 할 수 있는 Policy가 필요했고, 다행히 사내에서는 공통된 SSM Policy를 갖고 있어 필요한 리소스 권한만 추가함으로써 문제를 해결 할 수 있었습니다.
그 외 Run Command 셋팅은 직관적인 UI와 설명을 통해 원하는 동작을 실행시킬 수 있으며 실행 결과에 대한 로그 정보도 S3에서 확인 가능합니다.
더 나아가
Run Command 한계점으로는 CloudFront처럼 글로벌 서비스가 아닌 각 리전 제한으로 실행되어 초기 설정을 반복적으로 해야합니다. 또한 상대적으로 AWX보다 편리한 UI이지만 Run Command를 수행하기 위한 인스턴스 스크립트를 입력하는 과정에서 실수가 발생 할 수 있습니다. 스크립트 수행 결과를 관리하는 S3의 경우 개발자 입장에서 편리하지만, 오브젝트 파일을 각각 다운로드 받아야 한다는 단점이 존재합니다.
차후 해당 부분을 보완하고자 Bitbucket Pipeline과 OIDC를 이용해 사용자가 일괄적으로 적용 할 수 있는 프로세스를 만들고자 하며, 수행 결과 또한 Bitbucket Repository에서 확인 할 수 있게끔 만들고자 합니다.
마치며
Run Command를 이용해 보안 점검 자동화를 도입 함으로써 업무 효율화 / 스크립트 수행 결과 통합 관리 / 업무 프로세스 개선을 이뤄낼 수 있었습니다. 특히 업무 프로세스 개선은 보안팀과 협력 함으로써 자체적으로 언제든지 실행 할 수 있는 환경을 제공했습니다.
스푼라디오는 글로벌 서비스로써 Multi Account & Multi Region 환경에서 작업이 이뤄지고 있습니다. 따라서 불가피하게 단순 반복 업무가 발생하며 이를 개선 및 효율화 시키고자 SRE(DevOps)팀에서는 많은 것을 고민하고 있습니다. 저희와 함께 개발 효율화와 클라우드 환경을 관리하고 싶으시다면 현재 적극 채용중에 있으니 많은 관심 부탁드립니다. [Link]
