AWS Service Screener V2

**AWS Service Screener V2: 보안 엔지니어를 위한 시나리오 기반 가이드

(AWS Service Screener V2 : A Scenario-Based Guide for Security Engineers)

• 이 문서에서는 데모 화면을 포함하지 않습니다.
  공식 데모 실행 환경을 아래 링크에서 확인하실 수 있습니다.
  https://dev.d11el1twchxpia.amplifyapp.com/769655955296/CPFindings.html#

가볍게 깃헙 주소에서 다운받아 실행해보시면서 참고 삼아 읽어보시기를 권해드립니다.
https://github.com/aws-samples/service-screener-v2

소개 (Introduction)

기업의 클라우드 보안 담당자인 김보안 엔지니어는 조직의 AWS 사용 현황을 정기적으로 점검하고 있습니다. 최근 회사에서는 AWS에서 사용을 허용한 서비스 목록을 재정비하고, 새로운 AWS 서비스를 도입할 때 보안 위험 평가 절차를 강화하라는 요구를 받았습니다. 김 엔지니어는 제한된 인력으로 방대한 AWS 환경을 효율적으로 점검하기 위해 AWS Service Screener V2라는 도구를 활용하기로 했습니다. 이 글에서는 이러한 시나리오를 통해 AWS Service Screener가 무엇이며, 어떻게 활용할 수 있는지 상세히 살펴보고자 합니다.

AWS Service Screener V2란 무엇인가? (What is AWS Service Screener V2?)

AWS Service Screener V2는 AWS 환경을 자동으로 검사하여 모범 사례에 부합하는지 확인하고 개선 권장 사항을 제공하는 오픈 소스 도구입니다.
AWS 보안 및 커뮤니티의 모범 사례를 기준으로 서비스 구성들을 분석하고, 그 결과를 이해하기 쉬운 보고서 형태로 제공합니다. 이 도구는 보안(Security), 신뢰성(Reliability), 운영 우수성(Operational Excellence), 성능 효율(Performance Efficiency), 비용 최적화(Cost Optimization) 등 AWS 웰-아키텍티드 프레임워크의 여러 필러(pillar)에 걸쳐 서비스 설정을 평가합니다. 각 서비스별로 설정이 모범 사례와 어떻게 다른지 파악하여 빠른 개선이 가능한 항목(예: 비용 없이 다운타임 없이 고칠 수 있는 문제)을 강조합니다. 또한 AWS Well-Architected 프레임워크는 물론 CIS AWS Foundations Benchmark, NIST 800-53, AWS 파트너 FTR(Foundational Technical Review), AWS Startup Security Baseline (SSB) 등 다양한 보안 규범 및 프레임워크에 대한 준수 여부도 함께 점검합니다. 이러한 종합적인 점검을 통해 Service Screener는 현재 AWS 환경의 보안 태세를 한눈에 보여주고, 개선해야 할 사항에 대한 구체적인 권고사항을 제공합니다.

AWS Service Screener V2는 AWS Well-Architected Tool을 보완하기 위해 설계되었습니다. 일반적인 Well-Architected Tool이 설계 원리에 대한 설문 중심의 검토를 수행한다면, Service Screener는 실제 AWS 계정의 설정을 자동으로 검사하여 서비스 레벨의 세부적인 모범 사례 준수 여부를 확인해줍니다. 요약하면, AWS Service Screener는 AWS 환경의 보안 및 아키텍처 품질을 신속하게 점검하여, 보안 엔지니어가 개선이 필요한 부분을 식별하고 우선순위를 결정하는 데 도움을 주는 유용한 도구입니다.

AWS Service Screener 사용 방법 (How to Use AWS Service Screener V2)

AWS Service Screener는 AWS 관리 콘솔의 CloudShell 환경이나 로컬 CLI를 통해 실행할 수 있습니다. 여기서는 CloudShell을 사용하는 방법을 단계별로 설명합니다 (CLI/API 방식도 유사하게 main.py를 실행하는 형태로 동작합니다).

1. IAM 권한 준비 및 로그인: 먼저 Screener를 실행할 AWS 계정에서 필요한 IAM 권한을 갖춘 사용자로 로그인해야 합니다. 해당 IAM 사용자에게는 대부분의 AWS 리소스에 대한 읽기 전용 권한이 있어야 하며, AWS CloudShell을 사용할 수 있는 권한과 CloudFormation 스택 생성/삭제 권한이 추가로 필요합니다. AWS에서는 Service Screener 실행에 필요한 권한들을 정리한 샘플 IAM 정책도 제공하니 참고할 수 있습니다. 조직 내 여러 계정을 한 번에 검사하려는 경우, 각 계정에 대한 접근을 위해 교차 계정 역할 및 STS 구성을 해야 합니다 (예: iam:SetSecurityTokenServicePreferences 권한). 이러한 준비를 마친 후 해당 IAM 사용자로 AWS 콘솔에 로그인합니다.

2. CloudShell 실행 및 Screener 설치: AWS 콘솔에서 CloudShell을 실행하고, 제공된 설치 절차에 따라 Service Screener를 환경에 세팅합니다. CloudShell이 열리면 Python 가상환경을 만들고 깃허브의 AWS Service Screener 저장소 코드를 복제한 뒤 필요한 패키지를 설치합니다 . 구체적으로 cd /tmp && python3 -m venv . && source bin/activate 등 명령어를 통해 가상환경을 구성하고, git clone https://github.com/aws-samples/service-screener-v2.git으로 코드를 내려받습니다. 이후 해당 디렉터리로 이동해 pip install -r requirements.txt로 의존 라이브러리를 설치하고, python3 unzip_botocore_lambda_runtime.py 스크립트를 실행하여 AWS SDK 호환성을 위한 준비를 합니다. 마지막으로 alias screener='python3 $(pwd)/main.py' 명령을 실행하면 CloudShell에서 screener라는 단축 명령으로 이 도구를 사용할 수 있게 됩니다.

3. Screener 실행: 이제 준비된 환경에서 Screener를 실행하여 환경 점검을 수행합니다. 기본 명령 형식은 screener --regions <대상 리전> --services <서비스 목록>인데, 매개변수를 조정하여 원하는 범위를 검사할 수 있습니다. 예를 들어 특정 리전의 S3 서비스만 점검하려면 다음과 같이 실행합니다: screener --regions ap-northeast-2 --services s3 (서울 리전의 S3 검사). 여러 리전을 동시에 지정하거나 여러 서비스를 콤마로 구분하여 검사할 수도 있습니다. 예를 들어 싱가포르(ap-southeast-1)와 버지니아(us-east-1) 리전의 RDS와 IAM 서비스만 선택적으로 점검하려면: screener --regions ap-southeast-1,us-east-1 --services rds,iam와 같이 실행하면 됩니다. --regions ALL 옵션을 사용하면 모든 리전에 대해 점검을 수행할 수도 있습니다. 또한 --beta 1 옵션을 주면 Screener에 포함된 베타 기능(예: Modernize 항목의 분석 등)을 활성화하여 실행할 수 있습니다. 명령을 실행하면 각 서비스에 대한 여러 AWS API describe/get 호출이 백그라운드에서 수행되어 설정 정보를 수집하며, 검사 대상 규모에 따라 수분 내에 완료됩니다 (테스트 결과 약 몇 분 내외 소요). CloudShell 터미널에 진행 로그와 완료 메시지가 표시되고, 결과 리포트가 압축 파일로 생성됩니다.

4. 보고서 다운로드 및 확인: Screener 실행이 완료되면 CloudShell 홈 디렉터리(~/service-screener-v2/)에 결과 보고서 파일(output.zip)이 생성됩니다. CloudShell 콘솔 우측 상단의 Actions 메뉴에서 “Download file” 기능을 이용해 이 ZIP 파일을 로컬로 다운로드합니다. 다운로드한 ZIP을 풀면 AWS 계정 ID별 폴더 안에 index.html 파일과 정적 리소스들이 포함되어 있습니다. 이 index.html 파일을 웹 브라우저로 열면 상세한 결과 대시보드를 확인할 수 있습니다.

보고서 대시보드의 Findings 섹션에서는 모든 발견 항목이 리스트업되어 각 리소스별로 어떤 문제가 발견되었는지 요약을 제공합니다. Compliances/Frameworks 섹션을 클릭하면, 앞서 언급한 CIS Benchmarks나 FTR, SSB 등의 기준에 비추어 현재 워크로드가 어느 정도 충족되고 있는지를 보여줍니다 (각 프레임워크별 요구사항 대비 현황을 점검) . 왼쪽 메뉴에서 특정 서비스명을 클릭하면 해당 서비스에 국한된 세부 점검 결과를 볼 수 있습니다. 예를 들어 S3를 클릭하면 S3 버킷들의 퍼블릭 접근 설정, 암호화 설정 등이 모범 사례에 맞게 설정되어 있는지에 대한 검사 결과와 개선 권고가 표시됩니다. 각 점검 항목을 펼쳐보면 설명과 발견된 문제 자원, 그리고 권장 조치 사항이 상세히 나타납니다. 이러한 권장 조치에는 예를 들어 “해당 S3 버킷에 퍼블릭 접근이 허용되어 있으므로 블록하도록 설정 변경할 것” 또는 “IAM 정책에 불필요한 * 권한이 있으므로 최소 권한 원칙에 맞게 수정할 것”과 같은 구체적인 가이드가 제공됩니다. JSON 형태의 원시 결과(api-raw.json)와 전체 결과(api-full.json) 파일도 함께 제공되므로, 원한다면 이 데이터를 활용하여 별도의 보고서나 대시보드를 구성할 수도 있습니다.

이상으로 AWS Service Screener의 기본적인 사용 방법과 결과 확인 과정을 살펴보았습니다. 다음으로는, 보안 엔지니어의 입장에서 이 도구를 어떻게 활용할 수 있는지 시나리오별 사례를 알아보겠습니다.

보안 엔지니어에게 유용한 사용 사례 (Use Cases for Security Engineers)

AWS Service Screener V2는 보안 엔지니어의 다양한 업무 시나리오에서 유용하게 활용될 수 있습니다. 앞서 소개한 김보안 엔지니어의 사례를 통해, 실제 상황에서 Screener가 어떻게 쓰일 수 있는지 두 가지 예시를 들어보겠습니다.

시나리오 1: 조직의 허용된 서비스 선별 및 준수 여부 점검

김 엔지니어의 회사는 클라우드 거버넌스 정책에 따라 사용을 승인한 AWS 서비스 목록을 가지고 있습니다. 새로운 프로젝트에서 정책에 없는 AWS 서비스를 사용하려면 보안팀의 승인을 받아야 하죠. 그러나 개발 팀이 정책을 숙지하지 못했거나, 실수로 금지된 서비스를 사용하는 경우도 발생할 수 있습니다. 김 엔지니어는 AWS Service Screener를 활용해 조직 계정 전체를 스캔함으로써 사용 중인 AWS 서비스 현황을 일괄 파악하고, 정책 위반 소지가 있는 서비스를 찾아냅니다.

예를 들어, Screener를 모든 리전, 모든 서비스 대상으로 실행하면 해당 AWS 계정(또는 조직의 여러 계정)에 현재 리소스가 존재하는 모든 서비스가 보고서에 나타납니다. 왼쪽 메뉴의 References 섹션 아래에는 해당 계정에서 리소스가 발견된 서비스들만 리스트업되므로, 김 엔지니어는 정책상 허용되지 않은 서비스가 이 목록에 포함되어 있는지 쉽게 확인할 수 있습니다. 만약 정책에 없는 서비스가 발견되면, 해당 서비스명을 클릭하여 그 서비스의 상세 내역과 리소스를 검토하고, 필요 시 관련 팀에 통보하여 사용 중단이나 아키텍처 변경을 요구할 수 있습니다.

또한 Service Screener의 Compliances/Frameworks 결과 중 CIS AWS Foundations Benchmark 대응 현황을 확인함으로써, 기본적으로 권장되지 않는 서비스나 설정이 사용되고 있는지도 파악합니다. (CIS Benchmarks에는 예를 들어 사용하지 않는 권역의 계정 리소스 최소화 등이 포함되어 있습니다.) 김 엔지니어는 이러한 정보를 토대로 조직 정책을 위반한 사항들을 신속히 찾아내어 시정 조치를 취함으로써, 클라우드 사용이 거버넌스 기준을 준수하도록 관리할 수 있었습니다.

시나리오 2: 신규 서비스 도입 시 위험 평가 및 보안 검토

회사의 개발 부서에서 AWS의 신규 서비스를 도입하고자 할 때, 보안 엔지니어는 해당 서비스의 사용이 가져올 수 있는 위험 요소를 검토해야 합니다. 김 엔지니어는 새로운 서비스에 대한 보안 모범 사례 검토에 AWS Service Screener를 활용합니다. 예를 들어, 팀에서 AWS의 머신 러닝 서비스인 SageMaker를 처음 도입하려 한다고 가정해 보겠습니다. 김 엔지니어는 우선 소규모 테스트 AWS 계정에서 SageMaker 관련 리소스를 생성한 후, 그 계정에 대해 Service Screener를 실행합니다 (--services sagemaker 옵션 사용). Screener는 SageMaker 노트북 인스턴스, 엔드포인트, S3 데이터 저장 등 관련 설정을 자동 점검하여, 암호화 설정이 올바르게 적용되었는지, 인터넷에 노출된 엔드포인트는 없는지, IAM 역할에 과도한 권한이 부여되지 않았는지 등의 결과를 보고서로 제시해줍니다.

보고서에서 SageMaker 서비스 부분을 확인한 김 엔지니어는 만약 암호화되지 않은 S3 버킷이나 퍼블릭 액세스가 가능한 인스턴스 등이 발견될 경우 해당 위험 요소를 인지하고, 이를 개선하거나 사용을 제한하라는 권고를 개발팀에 전달합니다. 또한 Screener가 제공하는 권장 조치를 통해, 해당 서비스의 보안 강화를 위해 어떤 설정을 변경해야 하는지 구체적으로 안내할 수 있었습니다.

이처럼 신규 서비스에 대한 사전 보안 점검 용도로 Screener를 활용하면, 서비스 특유의 설정 실수나 놓치기 쉬운 보안 취약점을 미리 발견할 수 있습니다. 김 엔지니어는 Screener 결과를 바탕으로 신규 서비스 도입과 관련된 위험 평가 보고서를 작성하여 경영진에 보고하고, 승인 전에 필요한 보안 설정을 반영하도록 했습니다. 그 결과, 새 서비스 도입 시에도 기업의 보안 기준을 만족하도록 사전 대비를 할 수 있었습니다.

이 외에도 AWS Service Screener는 정기 보안 감사 시 환경 변화를 모니터링하는 용도로 활용되기도 합니다. 예를 들어 분기별로 Screener를 실행하여 이전 스캔 대비 개선되었거나 퇴보한 항목을 비교함으로써, 보안 수준의 추이를 관리할 수 있습니다. 또한 여러 프로젝트팀에 걸쳐 공통적으로 발견되는 취약점(예: IAM 권한 남용 등)을 식별하여 교육 자료를 만들거나, 조직 차원의 정책 강화 근거로 활용할 수도 있습니다.

AWS 보안 전략 및 정책 수립에서의 Screener 역할 (Role in Security Strategy and Policy)

AWS Service Screener V2는 조직의 클라우드 보안 전략 수립 및 정책 관리 과정에서 유용한 도구로 활용될 수 있습니다. 보안 엔지니어는 Screener를 통해 얻은 인사이트를 토대로, 거시적인 보안 전략을 개선하거나 세부 정책을 수립할 수 있습니다.

먼저, Screener의 프레임워크 매핑 기능은 전략 수립에 큰 도움을 줍니다. Screener는 AWS Well-Architected 보안 모범 사례 준수 여부는 물론, 국제 표준(예: NIST 800-53)이나 업계 규범(예: CIS Benchmark) 등에 대해 현재 환경이 얼마나 부합하는지 보여줍니다. 이를 통해 김 엔지니어는 우리 회사의 클라우드 운영 수준이 업계 모범 수준에 견주어 어느 부분이 부족한지 파악할 수 있었고, 보안 전략의 우선 순위를 결정하는 데 활용했습니다. 예를 들어 CIS Benchmark 항목 중 미준수 항목이 다수 발견되었다면, 해당 항목들을 개선하는 것을 단기 목표로 설정하고 관련 보안 정책(스크립트 배포, 구성 규정 등)을 마련하게 됩니다.

둘째, AWS Service Screener V2는 AWS Well-Architected Tool과 통합이 가능하여, 조직의 아키텍처 리뷰 프로세스에 자동화를 도입할 수 있습니다. Screener 실행 시 WA 통합 옵션을 사용하면 Well-Architected Tool에 워크로드와 마일스톤을 자동으로 생성하여 Screener 결과를 해당 워크로드의 리뷰 기록으로 남길 수 있습니다. 김 엔지니어는 이를 활용해 주요 서비스별로 Well-Architected 리뷰를 생성하고, Screener 점검 결과를 기반으로 한 개선 활동을 추적했습니다. 특히 보안 분야의 위험 요소들은 Well-Architected Tool 내에서 Issue로 기록하고 소유자를 지정하여 조치를 추적함으로써, 체계적인 보안 거버넌스 사이클을 구축했습니다.

또한 Screener는 기존 보안 서비스들과 보완적으로 활용될 수 있습니다. 예를 들어 AWS Config나 Security Hub를 통해 지속적으로 모니터링을 하면서도, Screener를 정기 진단 도구로 사용하면 둘 사이에 시너지 효과가 있습니다. Security Hub가 실시간으로 발견한 이슈와 Screener의 종합 리포트 결과를 교차 검증하여 놓친 항목이 없는지 점검하거나, Screener에서 권고된 개선 사항을 Config 규칙으로 구현하여 지속 준수시키는 전략을 세울 수 있습니다. 김 엔지니어는 Screener 결과 중 반복적으로 지적되는 사항(예: EBS 볼륨 암호화 누락 등)에 대해서는 AWS Config의 규칙으로 자동화하여 새로운 위반이 발생하지 않도록 정책에 반영했습니다. 이처럼 Screener는 현재 상태 파악과 모범사례 가이드 제공을 통해 보안 정책 수립의 출발점을 제시하고, 이후의 지속적 개선 사이클에 기반 자료로 활용될 수 있습니다.

요약하면, AWS Service Screener V2는 조직의 클라우드 보안 전략에서 진단 및 계획 수립을 지원하는 역할을 합니다. 경영진이나 감사 대응을 위해 현황 보고서를 작성할 때도 유용하며, 보안 로드맵의 타당성을 뒷받침하는 데이터 소스로 쓰여 정책 결정에 객관성을 부여합니다.

장점 (Advantages)

AWS Service Screener V2를 활용함으로써 보안 엔지니어가 얻을 수 있는 이점은 다양합니다:
• 종합적이고 깊이 있는 점검: Screener는 AWS 환경을 다각도로 검사하여, 보안, 비용, 운영, 성능 등 전 분야의 모범 사례 준수 여부를 한 번에 진단합니다. 별도의 여러 도구를 쓰지 않고도 한 번의 실행으로 광범위한 영역을 커버할 수 있기 때문에 효율적입니다. 특히 보안 측면에서는 AWS 권장 설정뿐만 아니라 업계 표준에 비추어 부족한 부분을 알려주므로, 포괄적인 보안 점검 도구로 활용할 수 있습니다.
• 쉬운 사용과 해석: AWS Service Screener는 AWS 콘솔에서 바로 사용할 수 있는 CloudShell 스크립트로 제공되어, 별도의 설치 복잡성 없이 빠르게 실행할 수 있습니다. 결과 보고서 또한 웹 대시보드 형태로 제공되어 한눈에 상태를 파악하기 쉽고, 시각화와 카테고리별 정리가 잘 되어 있습니다

각 발견 항목에는 설명과 권장 해결책이 명시되어 있어, 사용자는 문제를 이해하고 다음 행동을 결정하기가 수월합니다. 이는 보안 엔지니어뿐 아니라 서비스 오너, 개발자와도 커뮤니케이션을 원활히 해주는 장점입니다.
• 빠른 피드백 및 비용 효율: Screener는 일반적으로 수 분 내에 결과를 산출하므로, 실시간에 가까운 빠른 피드백을 제공합니다. 덕분에 신규 설정을 배포하거나 변경한 후 곧바로 모범 사례 위배 여부를 확인할 수 있어 DevSecOps 사이클에 통합하기에도 적합합니다. 또한 비용 면에서도 거의 부담이 없습니다. AWS Free Tier 범위 내에서 실행이 가능하며, Free Tier를 초과하더라도 한 번 실행에 $0.01 미만의 API 호출 비용만 발생할 정도로 경미합니다. 별도의 유료 솔루션 없이도 AWS 계정만 있으면 바로 활용할 수 있다는 점에서 경제적입니다.
• 오픈 소스 및 사용자 커뮤니티: AWS Service Screener는 오픈 소스로 개발되어 GitHub에서 공개되어 있기 때문에, 투명하게 어떤 검사를 하는지 확인할 수 있고 필요에 따라 커스터마이징도 가능합니다. 커뮤니티를 통해 지속적으로 업데이트와 개선이 이루어지고 있어, 신규 AWS 서비스에 대한 대응이나 새로운 모범 사례 추가 등이 비교적 신속히 반영됩니다. 사용자는 GitHub 이슈나 풀 리퀘스트를 통해 의견을 전달할 수도 있고, 이미 활발한 AWS 전문가 커뮤니티가 존재하므로 정보를 얻기도 쉽습니다.
• 다계정 및 멀티 리전 환경 대응: Screener는 여러 리전은 물론 여러 AWS 계정(Organization 전체)에 대한 점검도 지원합니다 (교차 계정 권한 구성 필요). 대기업이나 멀티계정 전략을 쓰는 조직의 보안 엔지니어는 일일이 각 계정을 검사하지 않고도 Screener로 한꺼번에 점검할 수 있어 관리 효율이 높아집니다. 이는 조직 전체의 보안 수준을 균일하게 유지하고 중앙에서 통제하는 데 도움이 됩니다.

이러한 장점들 덕분에, AWS Service Screener는 AWS 보안 현황 진단을 신속하고 종합적으로 수행해야 하는 보안 엔지니어들에게 매우 유용한 도구로 평가받고 있습니다. 김보안 엔지니어 또한 “Screener를 통해 짧은 시간에 AWS 환경의 보안 취약점을 한눈에 파악하고, 개선 방향까지 알 수 있어 업무에 큰 도움이 되었다”고 말합니다.

한계점 (Limitations)

물론 AWS Service Screener V2에도 몇 가지 알아두어야 할 한계와 제한 사항이 있습니다:
• 실시간 모니터링 아님: Screener는 주기적으로 수동 실행하는 진단 도구이지, 지속적으로 환경을 모니터링하여 실시간 경보를 주는 서비스는 아닙니다. 따라서 두 스캔 사이의 기간 동안 발생한 보안 이슈는 즉각 포착하지 못할 수 있습니다. 지속 모니터링이 필요한 경우 AWS Config, CloudWatch Events, Security Hub 등의 서비스와 병행하여 운영하고, Screener는 정기 점검 및 감사 용도로 활용하는 것이 바람직합니다.
• 자동 수정 불가: Screener는 발견된 문제에 대한 권장 조치를 제시하지만, 실제 수정 작업을 자동으로 수행하지는 않습니다. 예를 들어 퍼블릭으로 열린 S3 버킷을 찾아내어도, 이를 닫는 작업은 사용자에게 맡겨집니다. 따라서 Screener 결과를 토대로 별도의 수동 작업이나 자동화 스크립트를 통해 개선 조치를 이행해야 합니다. (AWS Systems Manager, Terraform 등의 도구와 결합해 후속 조치를 자동화하는 방안을 고려할 수 있습니다.)
• 지원 범위 제한: Screener가 모든 AWS 서비스와 모든 규정 기준을 다 포괄하는 것은 아닙니다. 현재 버전(v2 기준)에서는 주요 서비스들에 대한 점검을 커버하지만, 일부 최신 출시 서비스나 특수한 리전(예: GovCloud, 중국 리전 등)은 지원이 불완전할 수 있습니다. 실제로 AWS 중국 리전의 경우 별도 엔드포인트 체계 등으로 인해 Screener를 바로 쓸 수 없어 커뮤니티에서 수정 버전이 제공되고 있습니다 . 또한 NIST 프레임워크 지원의 경우 “작업 진행중(Work in progress)”인 등 아직 완전하지 않은 부분도 있습니다 . 사용 전에 현재 지원 목록을 GitHub 리포지토리에서 확인하는 것이 좋습니다.
• 오탐지 및 한계: 자동화된 스캐닝 툴의 특성상 모든 결과가 우리 환경에 정확히 적용되지 않을 수 있습니다. 예를 들어 의도적으로 퍼블릭 설정을 해놓은 리소스도 Screener에는 위험으로 표시될 것입니다. 또한 복잡한 아키텍처 맥락을 고려하지 못하고 정적인 설정 값만 점검하므로, 일부 이슈는 과장되거나 경미하게 표시될 수 있습니다. 보안 엔지니어는 Screener 결과를 맥락에 따라 해석할 필요가 있으며, 필요한 경우 결과를 필터링하거나 예외 처리를 염두에 두어야 합니다.
• 공식 지원 미제공: AWS Service Screener V2는 AWS에서 공식 서비스로서 제공하는 것이 아니라 AWS Solutions Architect들이 주도한 오픈 소스 프로젝트입니다. 따라서 AWS 공식 서비스처럼 AWS Support를 통해 직접적인 기술 지원을 받기는 어렵습니다. 문제 발생 시 GitHub 이슈 등록이나 커뮤니티 포럼 등을 활용해야 하며, 이는 일부 조직에서 도구 채택 시 고려해야 할 요소입니다. 다만 AWS 직원들이 프로젝트에 관여하고 있어 비교적 신뢰할 만하지만, 중요한 프로덕션 환경에 적용할 때는 충분한 테스트를 거치는 것이 좋습니다.

이러한 한계에도 불구하고, 적절히 활용하면 Screener는 여전히 값진 인사이트를 제공합니다. 중요한 것은 Screener를 만능으로 간주하기보다는, 다른 보안 통제와 함께 보완적으로 사용하고 한계점을 인지하는 것입니다. 김보안 엔지니어는 Screener 결과를 항상 이중 확인하고, 필요한 경우 수동 점검을 추가 수행함으로써 오탐이나 누락에 대비하고 있습니다.

실무 적용 시 고려사항 (Considerations: Permissions, Constraints, and Cost)

마지막으로 AWS Service Screener V2를 실제 업무에 도입할 때 염두에 두어야 할 사항들을 정리하면 다음과 같습니다:
• IAM 권한 설정: 앞서 강조했듯 Screener를 실행하려면 폭넓은 읽기 권한이 필요합니다. 보안 원칙에 따라 최소 권한 원칙을 지키면서도 필요한 서비스 조회를 모두 허용하도록 IAM 정책을 세심하게 구성해야 합니다. AWS가 제공하는 샘플 정책을 기반으로 필요 시 조정하고, CloudShell 및 CloudFormation 권한도 누락되지 않게 포함합니다. 또한 조직 내 여러 계정을 스캔하려는 경우, 각 대상 계정에 교차 액세스를 위한 IAM 역할(예: SecurityAudit 역할 등)을 사전에 만들어 두고 실행 계정에서 이를 Assume Role 할 수 있도록 설정해야 합니다. 이러한 권한 준비 작업은 초기에 다소 시간이 들 수 있지만, 일회성으로 세팅해두면 이후 반복 사용이 가능합니다.
• 환경 제약 및 네트워크: AWS Service Screener는 CloudShell을 통해 인터넷에 연결된 상태로 GitHub에서 코드를 내려받고 AWS API를 호출합니다. 만약 조직 보안 정책상 인터넷에 나가는 연결이 제한된 네트워크 구획이라면 CloudShell 사용이 불가할 수 있습니다. 이 경우에는 Screener 코드를 미리 다운로드하여 오프라인 환경에 반입하거나, AWS CodeCommit 등의 내부 저장소에 복제한 후 실행하는 등의 방법을 고려해야 합니다. CloudShell을 사용하지 못한다면 로컬 PC나 AWS EC2 인스턴스에서 AWS CLI 환경을 갖추고 main.py를 실행하는 방법도 있습니다 (일부 사용자는 Docker 컨테이너로 Screener를 패키징하여 사내 CI 파이프라인에서 주기적으로 실행하기도 합니다). 단, 어떤 방식으로 실행하든 AWS API 호출 권한이 필요하다는 점은 동일합니다.
• 보고서 보안: Screener가 생성하는 리포트는 조직의 아키텍처와 설정에 대한 민감한 정보를 담고 있습니다. 때문에 보고서를 로컬에서만 확인하고 인터넷에 노출하지 않는 것이 중요합니다. 예컨대, 생성된 HTML 리포트를 무심코 퍼블릭 웹서버에 올려두면 환경 구성과 취약점 정보가 외부에 노출될 수 있습니다. AWS Service Screener의 공식 지침에서도 해당 보고서는 반드시 로컬에 호스팅하고 외부에 공개하지 말 것을 명시하고 있습니다. 김 엔지니어는 리포트를 내부자들만 접근 가능한 공유 드라이브에 저장하고, 필요 시 PDF로 출력하여 제한된 인원에게만 배포하는 등 취급에 주의하고 있습니다.
• 실행 비용: 비록 Screener 실행 비용이 매우 저렴하거나 무료이지만 , 대규모 환경의 경우 API 호출량이 많아질 수 있으므로 비용 모니터링을 간과해서는 안 됩니다. 예를 들어 수백 개 계정, 모든 리전에 대해 자주 스캔한다면 누적 호출량이 쌓일 수 있습니다. 비용은 대부분 CloudWatch에 기록되므로 주기적으로 확인하고, 필요에 따라 실행 빈도를 조절합니다. 일반적으로는 월 1~2회 정도 정기 실행 시 비용 영향은 무시할 수준이지만, 조직 정책에 따라 사전 승인을 받아 두는 것이 좋습니다.
• 결과 해석 및 조치 계획: Screener를 도입하면 그 결과로 다량의 개선 권고사항이 나올 수 있습니다. 이를 어떻게 처리할지에 대한 내부 프로세스를 마련해두는 것이 좋습니다. 예를 들어, 높은 위험도(High)로 표시된 항목은 즉시 티켓을 발행해 담당자 지정 후 조치하고, 중간 위험(Medium) 이하는 분기별로 모아 일괄 개선 프로젝트를 진행하는 등의 정책을 세울 수 있습니다. 또한 Screener 권고에 대해 예외 승인 절차도 필요합니다. 특정 사례에서는 모범 사례를 따르지 않는 것이 불가피할 수 있는데, 이 경우 해당 항목을 위험 수용으로 처리하고 문서화하는 등 프로세스를 통해 일관성을 유지합니다. 김 엔지니어의 조직도 Screener 결과를 보안 위험 레지스터에 반영하여 관리하고, 경영진에 주기적으로 보고하는 체계를 갖추고 있습니다.
• 업데이트 및 유지보수: AWS의 서비스는 지속적으로 변화하고 모범 사례도 진화합니다. 따라서 Screener도 정기적인 업데이트를 적용하여 최신 체크 항목을 반영해야 합니다. GitHub 저장소의 업데이트 내역을 모니터링하고, 새로운 릴리스(major update)가 나오면 설치 스크립트를 다시 실행하여 최신 버전으로 갱신합니다. 만약 조직 내 CI 파이프라인에 통합해 자동으로 실행 중이라면, 컨테이너 이미지를 재빌드하거나 람다 함수를 업데이트하는 등 작업이 필요할 수 있습니다. 한편, Screener를 통해 발견된 공통 취약점은 장기적으로 AWS 서비스의 신규 기능 (예: S3 Block Public Access 도입 등)을 통해 해소되는 경우도 있으므로, 서비스 팀과 협업하여 근본적 해결책을 모색하는 것도 중요합니다.

정리하면, AWS Service Screener를 현업에 적용할 때는 사전 준비(권한, 네트워크), 사후 처리(보고서 보안, 개선 프로세스), 그리고 지속 관리(업데이트, 비용 모니터링) 측면을 두루 고려해야 합니다. 이러한 사항을 잘 관리하면 Screener 도입은 순조롭게 진행될 것이며, 조직의 클라우드 보안 수준 향상에 실질적인 기여를 할 수 있을 것입니다.