[AWS-Security] 9.1. 리소스 구성 스캐닝

Posted Apr 20, 2026

By haksuperman

views 13 min read

1. 개요

클라우드 환경에는 수백, 수천 개의 리소스가 존재하며 개발 속도에 따라 매일 새로운 리소스가 생성되거나 변경된다. 관리자가 콘솔에 접속하여 일일이 확인하는 것은 불가능하다. 따라서 잘못된 리소스 구성을 찾아내는 자동화된 스캐닝 도구가 필수적이다.

2. 애드혹(Ad-hoc, 일회성) 스캐닝

가장 접근하기 쉬운 방법은 관리자가 필요할 때마다 수동으로 스크립트나 도구를 실행하여 전체 인프라를 훑어보는 ‘일회성 스캐닝’이다.

2.1. AWS SDK(Python `boto3`)를 활용한 직접 구현

AWS에서 제공하는 SDK를 사용하여 보안 검사 자동화 스크립트를 직접 작성할 수 있다. 예를 들어, 계정 내의 모든 S3 버킷을 조회하고 ‘저장 데이터 암호화’가 켜져 있는지 검사하는 파이썬 코드는 아래와 같다.

  
# 계정에서 암호화가 활성화되지 않은 모든 버킷을 찾는 코드
import boto3

s3_client = boto3.client('s3')
buckets = s3_client.list_buckets()['Buckets']  # 계정의 모든 버킷 목록 조회
non_compliant_buckets = []                     # 규정을 위반한(암호화 안 된) 버킷을 담을 리스트

for bucket in buckets:
    bucket_name = bucket['Name']
    try:
        # 버킷의 암호화 설정 조회
        s3_client.get_bucket_encryption(Bucket=bucket_name)
        
    except s3_client.exceptions.ClientError as e:
        # 암호화 설정이 없어서 발생하는 특정 에러 코드 확인
        if e.response['Error']['Code'] == 'ServerSideEncryptionConfigurationNotFoundError':
            non_compliant_buckets.append(bucket_name)  # 위반 버킷 리스트에 추가
        else:
            raise e

print(f"Found {len(non_compliant_buckets)} bucket(s) without encryption:")
print(non_compliant_buckets)

동작 원리
- get_bucket_encryption 메소드를 호출했을 때 정상 반환되면 암호화가 켜진 것이고, ServerSideEncryptionConfigurationNotFoundError 예외(에러가)가 발생하면 암호화가 꺼져 있다는 뜻이다.
- 이를 통해 취약한 버킷을 걸러낸다.

2.2. 오픈 소스 보안 스캐너 ‘Prowler’ 활용

위처럼 모든 보안 모범 사례에 대한 스크립트를 직접 짜는 것은 매우 큰 시간 낭비다. 이를 이미 구현해 놓은 오픈 소스 도구가 바로 Prowler다.

Prowler는 AWS 보안 모범 사례(CIS 벤치마크 등)를 기반으로 100가지가 넘는 자동화된 보안 검사 스크립트를 내장하고 있다.
링크 : https://github.com/toniblyx/prowler
Prowler에 대한 상세 사용 방법은 README.md 참고

  
# Prowler 다운로드 및 단일 검사 실행 명령어

# 1. 깃허브에서 Prowler 리포지토리 다운로드(Clone)
$ git clone https://github.com/toniblyx/prowler
$ cd prowler

# 2. Prowler 설치
pip install .

# 3. AWS 권한 설정
#  - EC2 내부에서 실행 중인 경우 IAM Role 연결(SecurityAudit, ViewOnlyAccess)
#  - IAM Role 사용하지 않는 경우 aws configure 명령으로 Access Key, Secret Key 사용

# 4. 특정 검사 항목(check734: S3 버킷 암호화 확인)만 지정하여 실행
# (-c 플래그를 생략하면 100개 이상의 전체 보안 검사가 모두 실행)
$ ./prowler -c check734

3. 지속적인 모니터링

일회성 스캐닝(스크립트, 도구 등)은 스캔을 실행한 ‘그 시점’의 안전만 확인할 수 있다. 클라우드 환경은 빠르게 변하므로, 스캔 직후에 누군가 리소스 설정을 취약하게 변경하면 다음 스캔 때까지 이를 알아차릴 수 없다. 이를 해결하기 위해 모니터링을 지속적으로 실행하도록 자동화해야 한다.

3.1. 시간 기반 스캐닝 (일정 간격 실행)

가장 간단한 방법은 스캐닝 도구를 주기적으로 실행하는 것이다.

예시
- Amazon CloudWatch 시간 기반 이벤트가 트리거 된다. (24시간마다)
- 서버리스 컴퓨팅인 AWS Fargate 작업이 시작되어 컨테이너 내에서 Prowler 검사를 전체 리소스 대상으로 실행한다.
- 검사 결과(비준수 리소스 목록)를 Amazon SNS로 전송하여 관리자에게 이메일로 알림을 보낸다.
단점
- 24시간 간격은 해커가 취약점을 악용하기에 충분한 시간이다.
- 해커의 악용을 막기 위해 빈번한 시간인 15분으로 단축하면, 변경 중(Updating)인 리소스까지 계속 반복 검사하므로 수천 건의 불필요한 API 호출과 스팸 알림이 발생한다.

3.2. AWS Config를 활용한 이벤트 기반 스캐닝

가장 바람직한 것은 ‘모든 것을 매번 묻는 대신, 무언가 변경 되었을 때만 검사’하는 것이다. AWS Config가 정확히 이 역할을 수행한다.

동작 원리 : 특정 S3 버킷의 설정이 변경되는 순간, AWS Config가 이를 실시간으로 감지하고 해당 버킷에 대해서만 즉시 보안 검사를 수행한다.
AWS Config 규칙 : AWS는 보안 모범 사례를 자동으로 검사해 주는 사전 구축된 ‘관리형 Config 규칙’들을 제공한다.
- iam-password-policy : 강력한 비밀번호 정책이 설정되어 있는지 확인
- ec2-instance-no-public-ip : EC2에 Public IP가 할당되지 않았는지 확인
- s3-default-encryption-kms : S3 버킷에 저장 데이터 암호화가 활성화되어 있는지 확인
  AWS CLI를 사용하여 S3 암호화를 강제하는 Config 규칙(s3-default-encryption-kms)을 활성화하는 방법은 아래와 같다.

  
# PutConfigRule을 사용해 관리형 규칙 활성화

$ aws configservice put-config-rule --config-rule '{ \
    "ConfigRuleName": "MyRule", \
    "Source": {"Owner": "AWS", \
    "SourceIdentifier": "S3_DEFAULT_ENCRYPTION_KMS"} \
  }'

Owner를 AWS로 설정하면 우리가 직접 코드를 짜지 않아도 AWS가 미리 만들어둔 관리형 규칙(SourceIdentifier)을 가져와 적용하겠다는 의미이다.

3.3. 규정 준수 타임라인의 장점

위와 같이 Config 규칙을 활성화해 두면, 누군가 S3 버킷의 암호화를 끄거나 퍼블릭 접근을 허용하는 순간 아래의 일련 과정을 보다 손쉽게 구성할 수 있다.

상태 변경 : Config 콘솔의 리소스 타임라인에 해당 버킷이 즉시 ‘Noncompliant(규정 미준수, 빨간색)’ 상태로 바뀐다.
원인 추적 : 타임라인 하단의 Changes 및 CloudTrail Events 탭을 통해, 취약하게 만든 원인(누가 언제 어떤 설정 값을 바꿨는지)을 찾아낼 수 있다.
이후 관리자가 다시 설정을 올바르게 고치면 타임라인은 다시 ‘Compliant(규정 준수, 초록색)’로 복구된다.

4. 규정 준수 표준 및 벤치마크

수많은 보안 모범 사례 중 어떤 기준을 실제로 적용해야 할까?라는 의문이 있을 수 있다.
모든 보안 규칙을 억지로 다 지킬 필요는 없다. 애플리케이션 특성에 맞지 않아 오히려 복잡성만 키우는 규칙들을 과감히 비활성화해도 무방하다.

하지만, 반드시 시켜야만 하는 엄격한 지침(표준)이 요구될 때도 있다.

PCI-DSS : 신용카드 결제 및 데이터를 처리하는 시스템이 반드시 지켜야 하는 표준
CIS AWS Foundations Benchmark : 비영리 단체(CIS)에서 만든 AWS 환경을 안전하게 구성하기 위한 전 세계적으로 가장 잘 알려진 기본 보안 가이드라인

4.1. AWS Security Hub

표준(PCI-DSS, CIS 등)을 준수해야 할 때, AWS Config 규칙을 하나하나 수동으로 찾아 조합하는 것을 비효율적이다. 이에 적합한 서비스가 AWS Security Hub다.

동작 원리 : Security Hub의 ‘표준(Standard)’ 기능은 특정 벤치마크(CIS 등)를 만족시키기 위해 필요한 수십~수백 개의 검사 항목(Control, 제어)을 하나의 패키지로 묶어 놓은 것이다.
(Control은 내부적으로 AWS Config 규칙과 동일하게 동작하여 리소스 변경 시마다 자동으로 평가된다.)

사용 가능한 Security Hub 표준

표준명	ARN (식별자)	주요 용도 및 특징
CIS AWS Foundations Benchmark	`arn:aws:securityhub:::ruleset/cis-aws-foundations-benchmark/v/1.2.0`	비영리 단체 CIS에서 정의한 가장 대중적인 AWS 보안 기본 가이드라인
PCI DSS (Payment Card Industry Data Security Standard)	`arn:aws:securityhub:us-west-2::standards/pci-dss/v/3.2.1`	신용카드 결제 및 금융 데이터를 취급하는 조직이 반드시 지켜야 하는 엄격한 보안 표준
AWS Foundational Security Best Practices	`arn:aws:securityhub:us-west-2::standards/aws-foundational-security-best-practices/v/1.0.0`	AWS 보안 전문가들이 권장하는 핵심 리소스별 보안 모범 사례 세트

4.2. AWS Security Hub 활성화

특정 표준(CIS 벤치마크)을 AWS CLI를 통해 계정에 활성화하는 명령어는 다음과 같다.

  
# batch-enable-standards로 Security Hub 표준 활성화

$ aws securityhub batch-enable-standards \
    --standards-subscription-requests '{"StandardsArn": "STANDARD_ARN"}'

STANDARD_ARN 자리에는 활성화하고자 하는 표준의 고유 ARN을 입력한다.

4.3. Security Hub 대시보드와 보안 점수

보안 점수 (Security Score) : 우리의 AWS 인프라가 벤치마크를 얼마나 잘 준수하고 있는지를 ‘50%’와 같이 백분율 점수로 시각화해 보여준다.
실패 항목 세부 정보 : 하단에는 통과하지 못한(Failed) 개별 제어 항목들이 심각도(CRITICAL, HIGH 등)와 함께 나열된다. 이를 클릭하면 세부적으로 어떤 리소스가 문제인지, 이를 해결하기 위해 어떻게 해야 하는지 등에 대한 가이드를 확인할 수 있다.

CLOUD, AWS

This post is licensed under CC BY 4.0 by the author.