AWS 계정 보안, 설정 안 하면 생기는 일

핵심 요약: AWS 계정에서 반드시 확인해야 할 보안 설정 10가지를 IAM, S3, CloudTrail, GuardDuty 관점으로 정리해요. Access Key 유출과 ISMS-P 결함을 줄이는 실무 점검 기준을 제공합니다.

실제 엔터프라이즈 환경에서는 이런 상황이 빈번하게 발생해요. 개발자가 테스트 목적으로 만든 IAM Access Key가 GitHub 공개 저장소에 올라가고, 몇 시간 만에 수백만 원짜리 EC2 인스턴스가 수십 대 생성돼요. 요금 청구서를 받고 나서야 사고를 인지하는 거예요.

이건 특정 고객사만의 이야기가 아니에요. AWS 보안 사고의 상당수는 설정 실수나 기본값 방치에서 시작해요. 퍼블릭으로 열린 S3 버킷, 0.0.0.0/0으로 열린 보안 그룹, 루트 계정에 MFA 없이 접근 가능한 상태. 이런 것들이 쌓이면 ISMS-P 심사에서 결함으로 이어지고, 실제 침해 사고로 번지기도 해요.

이 글에서는 AWS 계정을 처음 만들거나 기존 환경을 점검할 때 반드시 확인해야 할 10가지 설정을 정리했어요. 각 설정의 방법뿐 아니라, 왜 필요한지와 어떤 트레이드오프가 있는지도 함께 다룰게요.

AWS 책임공유모델에서 고객이 지켜야 할 영역

AWS는 "클라우드의 보안(Security of the Cloud)"을 책임지고, 고객사는 "클라우드에서의 보안(Security in the Cloud)"을 책임져요. 이걸 책임공유모델(Shared Responsibility Model)이라고 해요.

AWS가 책임지는 영역은 물리 데이터센터, 하드웨어, 네트워크 인프라, 하이퍼바이저예요. 고객사가 책임지는 영역은 운영체제 패치, 애플리케이션 보안, 데이터 암호화, IAM 설정, 네트워크 접근 제어예요.

마치 건물 임대와 비슷해요. 건물주(AWS)는 건물 구조와 공용 시설을 관리하지만, 임차인(고객사)이 자기 사무실 문을 잠그고 방문자를 통제하는 건 임차인의 몫이에요. 건물주가 아무리 튼튼한 건물을 지어도, 임차인이 문을 열어두면 소용없어요.

ISMS-P 심사에서도 이 경계를 명확히 설명할 수 있어야 해요. "이 항목은 AWS가 담당합니다"라고 답변할 때, AWS 보안 백서나 SOC 2 보고서 같은 근거 문서를 제시할 수 있어야 결함을 피할 수 있어요.

구분	AWS 책임	고객사 책임
물리 보안	데이터센터, 서버 하드웨어	해당 없음
네트워크	글로벌 인프라, 백본	VPC, 보안 그룹, NACL
운영체제	하이퍼바이저	EC2 OS 패치, 설정
데이터	스토리지 내구성	암호화, 접근 제어, 백업
계정 관리	해당 없음	IAM, MFA, 루트 계정 보호

IAM 보안 강화와 Access Key 안전 관리

IAM(Identity and Access Management)은 AWS 보안의 출발점이에요. 여기서 실수하면 나머지 설정이 아무 의미가 없어요.

루트 계정 MFA 활성화

루트 계정은 AWS 계정의 모든 권한을 가진 최고 관리자 계정이에요. 일상적인 작업에는 절대 사용하지 않는 게 원칙이에요. 루트 계정에는 반드시 MFA(Multi-Factor Authentication)를 설정하고, Access Key는 생성하지 않는 게 좋아요.

처음에는 이렇게 생각했어요. "루트 계정 비밀번호만 강하게 설정하면 되지 않을까?" 하지만 실제로 운영하다 보니, 비밀번호 단독으로는 피싱이나 크리덴셜 스터핑 공격에 취약하다는 걸 알게 됐어요. MFA가 없으면 비밀번호 하나만 탈취되어도 계정 전체가 위험해져요.

IAM 사용자 대신 IAM Role 사용

장기 자격증명인 Access Key 대신, IAM Role의 임시 자격증명(Assume Role)을 사용하는 방식으로 전환하는 게 좋아요. EC2, Lambda, ECS 같은 AWS 서비스에서 다른 AWS 서비스에 접근할 때는 Access Key를 코드에 넣지 않고 Instance Profile이나 Execution Role을 활용해야 해요.

# Access Key를 환경변수에 직접 넣는 방식 (금지)
export AWS_ACCESS_KEY_ID=AKIA...
export AWS_SECRET_ACCESS_KEY=...

# IAM Role을 활용한 방식 (권장)
# EC2 Instance Profile 또는 ECS Task Role 설정 후
aws sts get-caller-identity  # 임시 자격증명 자동 사용

git-secrets로 코드 유출 방지

Access Key가 GitHub에 올라가는 사고는 생각보다 자주 발생해요. git-secrets 같은 도구를 CI/CD 파이프라인에 통합하면, 커밋 전에 자격증명 패턴을 자동으로 검사해요.

# git-secrets 설치 및 설정
brew install git-secrets
git secrets --install
git secrets --register-aws

트레이드오프가 있어요. IAM Role 기반 구조로 전환하면 로컬 개발 환경에서 AWS CLI를 사용할 때 별도 설정이 필요해요. AWS SSO나 aws-vault 같은 도구를 함께 사용하면 개발자 경험을 크게 해치지 않으면서 보안을 강화할 수 있어요.

데이터 보안, S3 퍼블릭 차단과 네트워크 접근 제어

S3 퍼블릭 접근 차단

S3 버킷이 퍼블릭으로 열려 있으면 인터넷 누구나 데이터에 접근할 수 있어요. 고객 개인정보나 내부 문서가 담긴 버킷이 퍼블릭으로 노출된 사례가 국내외에서 반복적으로 발생하고 있어요.

계정 수준에서 S3 퍼블릭 접근을 차단하는 설정을 먼저 적용하고, 이후 퍼블릭 접근이 필요한 버킷(정적 웹사이트 호스팅 등)만 예외로 허용하는 방식이 안전해요.

// S3 계정 수준 퍼블릭 접근 차단 설정
{
  "BlockPublicAcls": true,
  "IgnorePublicAcls": true,
  "BlockPublicPolicy": true,
  "RestrictPublicBuckets": true
}

AWS Config 규칙 s3-bucket-public-read-prohibited를 활성화하면, 퍼블릭으로 변경된 버킷을 자동으로 감지하고 알림을 받을 수 있어요.

보안 그룹 최소 권한 원칙

보안 그룹에서 0.0.0.0/0(모든 IP)으로 열린 인바운드 규칙은 ISMS-P 심사에서 단골 결함 항목이에요. 특히 SSH(22번 포트)와 RDP(3389번 포트)가 퍼블릭으로 열려 있으면 브루트포스 공격에 노출돼요.

운영하면서 계속 느낀 건, 보안 그룹 규칙이 시간이 지날수록 누적된다는 거예요. 처음에는 특정 IP만 허용했다가, 개발자가 바뀌거나 IP가 변경되면서 기존 규칙을 지우지 않고 새 규칙을 추가하는 패턴이 반복돼요. 정기적인 보안 그룹 감사가 필요한 이유예요.

VPC Flow Logs 활성화

VPC Flow Logs는 VPC 내 네트워크 트래픽을 기록해요. 침해 사고 발생 시 원인 추적에 필수적인 데이터예요. CloudWatch Logs나 S3에 저장할 수 있어요.

비용이 발생한다는 점은 고려해야 해요. 트래픽이 많은 환경에서는 Flow Logs 저장 비용이 상당할 수 있어요. 전체 트래픽 대신 REJECT 트래픽만 기록하거나, 샘플링 비율을 조정하는 방식으로 비용을 줄일 수 있어요.

위협 탐지와 감사 로그, CloudTrail·GuardDuty·EventBridge

CloudTrail 활성화

CloudTrail은 AWS 계정에서 발생하는 모든 API 호출을 기록해요. 누가, 언제, 어떤 작업을 했는지 추적할 수 있어요. ISMS-P 심사에서 로그 관리 항목의 핵심 증적이에요.

모든 리전에서 CloudTrail을 활성화하고, 로그를 별도 S3 버킷에 저장하는 게 기본이에요. 로그 파일 무결성 검증(Log File Validation)을 활성화하면 로그 변조 여부를 확인할 수 있어요.

# CloudTrail 생성 (모든 리전, 로그 무결성 검증 포함)
aws cloudtrail create-trail \
  --name my-trail \
  --s3-bucket-name my-cloudtrail-bucket \
  --is-multi-region-trail \
  --enable-log-file-validation

로그 보관 기간은 최소 1년을 권장해요. S3 Lifecycle 정책으로 90일 이후 S3 Glacier로 이동하면 비용을 줄일 수 있어요.

GuardDuty, AI 기반 이상 행위 탐지

GuardDuty는 CloudTrail, VPC Flow Logs, DNS 로그를 분석해서 이상 행위를 자동으로 탐지해요. 크리덴셜 탈취, 비정상적인 API 호출, 악성 IP와의 통신 등을 감지해요.

원인을 추적한 끝에 발견한 건, GuardDuty가 탐지한 알림 중 상당수가 실제 위협이 아닌 오탐(False Positive)이라는 거예요. 초기에는 알림이 많아서 피로감이 생길 수 있어요. 신뢰할 수 있는 IP나 서비스를 화이트리스트에 등록하고, 알림 우선순위를 설정하는 튜닝 과정이 필요해요.

비용은 분석하는 데이터 볼륨에 따라 달라져요. 처음 30일은 무료 체험이 가능해요.

CloudTrail 보안 이벤트 실시간 감지

특정 보안 이벤트가 발생했을 때 즉시 알림을 받으려면 EventBridge와 SNS를 연동하면 돼요. 루트 계정 로그인, IAM 정책 변경, 보안 그룹 변경 같은 이벤트를 실시간으로 감지할 수 있어요.

// EventBridge 규칙 예시: 루트 계정 로그인 감지
{
  "source": ["aws.signin"],
  "detail-type": ["AWS Console Sign In via CloudTrail"],
  "detail": {
    "userIdentity": {
      "type": ["Root"]
    }
  }
}

Lambda를 연동하면 알림을 넘어서 자동 대응(예: 의심스러운 IAM 키 비활성화)도 가능해요. 다만 자동 대응은 오탐 시 서비스 장애로 이어질 수 있어서, 처음에는 알림만 받고 수동으로 대응하는 방식을 권장해요.

비용 이상 감지와 계정 관리

CloudWatch Billing 알람과 AWS Budgets

요금폭탄을 막는 가장 기본적인 방법은 비용 알람이에요. CloudWatch Billing 알람은 월 누적 비용이 임계값을 초과하면 알림을 보내요. AWS Budgets는 더 세밀한 예산 관리가 가능해요. 서비스별, 리전별, 태그별로 예산을 설정하고 초과 시 알림을 받을 수 있어요.

# AWS Budgets 생성 예시 (월 $100 초과 시 알림)
aws budgets create-budget \
  --account-id 123456789012 \
  --budget '{"BudgetName":"monthly-budget","BudgetLimit":{"Amount":"100","Unit":"USD"},"TimeUnit":"MONTHLY","BudgetType":"COST"}' \
  --notifications-with-subscribers '[{"Notification":{"NotificationType":"ACTUAL","ComparisonOperator":"GREATER_THAN","Threshold":80},"Subscribers":[{"SubscriptionType":"EMAIL","Address":"[email protected]"}]}]'

비용 알람은 사후 감지예요. 이미 비용이 발생한 후에 알림을 받는 구조예요. 예방을 위해서는 IAM 권한 최소화와 Service Control Policy(SCP)로 고비용 서비스 생성을 제한하는 방법을 함께 사용해야 해요.

사용하지 않는 리전 비활성화

AWS는 기본적으로 모든 리전이 활성화되어 있어요. 사용하지 않는 리전에서 리소스가 생성되면 모니터링 사각지대가 생겨요. 실제로 사용하는 리전만 활성화하고 나머지는 비활성화하면 공격 표면을 줄일 수 있어요.

AWS Organizations를 사용하는 경우, SCP로 특정 리전에서의 리소스 생성을 차단할 수 있어요.

// SCP 예시: ap-northeast-2(서울) 외 리전 차단
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": "ap-northeast-2"
        }
      }
    }
  ]
}

루트 계정 이메일 알림과 연락처 정보 관리

루트 계정에 등록된 이메일 주소는 AWS에서 보안 알림을 보내는 주요 채널이에요. 담당자가 바뀌거나 이메일 계정이 비활성화되면 중요한 알림을 놓칠 수 있어요.

실수하기 쉬운 부분이 있어요. 개인 이메일 주소로 AWS 계정을 만들고, 담당자가 퇴사한 후에도 그 이메일이 루트 계정에 등록된 채로 남아 있는 경우예요. 팀 공용 이메일 주소를 사용하고, 연락처 정보를 주기적으로 검토하는 프로세스가 필요해요.

Trusted Advisor 기본 보안 점검

Trusted Advisor는 AWS 계정의 보안, 비용, 성능, 내결함성을 자동으로 점검해요. 무료 플랜에서도 기본 보안 점검 7가지를 제공해요. MFA 미설정, 퍼블릭 S3 버킷, 보안 그룹 과도한 허용 등을 자동으로 감지해요.

Business 또는 Enterprise Support 플랜을 사용하면 전체 점검 항목에 접근할 수 있어요. 비용이 추가되지만, 대규모 AWS 환경을 운영하는 고객사라면 투자 대비 효과가 있어요.

10가지 설정 한눈에 보기

#	설정 항목	비용	운영 복잡도	ISMS-P 관련성
1	IAM MFA 활성화	무료	낮음	접근통제
2	Access Key → IAM Role 전환	무료	중간	접근통제
3	git-secrets 통합	무료	낮음	접근통제
4	S3 퍼블릭 접근 차단	무료	낮음	데이터 보호
5	보안 그룹 최소 권한	무료	중간	네트워크 보안
6	VPC Flow Logs	유료 (데이터 볼륨)	낮음	로그 관리
7	CloudTrail 활성화	유료 (이벤트 수)	낮음	로그 관리
8	GuardDuty 활성화	유료 (데이터 볼륨)	중간	침해사고 대응
9	EventBridge + SNS 알림	소액	중간	침해사고 대응
10	Billing 알람 + Budgets	무료	낮음	비용 관리

무료로 적용할 수 있는 설정부터 시작하는 게 좋아요. IAM MFA, S3 퍼블릭 차단, Billing 알람은 비용 없이 즉시 적용할 수 있어요. CloudTrail과 GuardDuty는 비용이 발생하지만, 침해 사고 대응 비용과 비교하면 훨씬 저렴해요.

핵심 요약

AWS 보안 사고의 대부분은 설정 실수와 기본값 방치에서 시작해요. 루트 계정 MFA, S3 퍼블릭 차단, 보안 그룹 최소 권한은 즉시 적용해야 해요.
IAM Access Key는 장기 자격증명이라 탈취 시 피해가 커요. IAM Role 기반 임시 자격증명으로 전환하고, git-secrets로 코드 유출을 방지해야 해요.
CloudTrail은 ISMS-P 심사의 핵심 증적이에요. 모든 리전에서 활성화하고, 로그 무결성 검증을 켜두어야 해요.
GuardDuty는 초기 오탐이 많아요. 화이트리스트 설정과 알림 튜닝 과정을 거쳐야 실질적인 위협 탐지 도구로 활용할 수 있어요.
비용 알람은 사후 감지예요. IAM 권한 최소화와 SCP로 예방 체계를 함께 갖춰야 해요.

FAQ

Q. AWS 계정을 처음 만들었을 때 가장 먼저 해야 할 설정은 무엇인가요?

루트 계정 MFA 활성화가 첫 번째예요. 루트 계정은 모든 권한을 가지고 있어서, 탈취되면 계정 전체가 위험해져요. MFA 설정 후에는 일상 작업용 IAM 사용자를 별도로 만들고, 루트 계정은 잠가두는 게 좋아요. 그다음으로 Billing 알람을 설정해서 예상치 못한 비용 발생을 감지할 수 있게 해야 해요.

Q. Access Key를 이미 GitHub에 올렸다면 어떻게 해야 하나요?

즉시 해당 Access Key를 비활성화하고 삭제해야 해요. GitHub에 올라간 순간부터 자동화된 스캐너가 탐지해서 악용할 수 있어요. 비활성화 후에는 CloudTrail에서 해당 Access Key로 발생한 API 호출 이력을 확인해서 피해 범위를 파악해야 해요. 이후 IAM Role 기반 구조로 전환하고, git-secrets를 설치해서 재발을 방지해야 해요.

Q. GuardDuty를 활성화하면 비용이 얼마나 드나요?

GuardDuty 비용은 분석하는 데이터 볼륨에 따라 달라져요. CloudTrail 이벤트, VPC Flow Logs, DNS 로그 각각에 대해 GB당 요금이 부과돼요. 처음 30일은 무료 체험이 가능해요. 중소 규모 환경에서는 월 수만 원 수준이지만, 트래픽이 많은 환경에서는 비용이 상당히 늘어날 수 있어요. AWS 비용 계산기로 사전에 예상 비용을 확인하는 걸 권장해요.

Q. ISMS-P 심사에서 AWS 보안 설정 관련 결함을 피하려면 무엇을 준비해야 하나요?

설정 자체보다 증적이 더 중요해요. 보안 그룹 변경 이력, IAM 정책 변경 이력, CloudTrail 로그 보관 현황, 정기적인 보안 점검 수행 이력을 문서화해야 해요. Terraform이나 CloudFormation으로 인프라를 관리하고 있다면, 변경 이력이 자동으로 남아서 증적으로 활용할 수 있어요. AWS Config 규칙을 활성화하면 설정 변경을 자동으로 감지하고 기록할 수 있어요.

Q. 소규모 스타트업도 이 모든 설정을 다 해야 하나요?

규모와 상관없이 무료로 적용할 수 있는 설정은 반드시 해야 해요. 루트 계정 MFA, S3 퍼블릭 차단, Billing 알람은 비용 없이 즉시 적용 가능해요. CloudTrail은 관리 이벤트 기준으로 리전당 첫 번째 트레일은 무료예요. GuardDuty는 30일 무료 체험 후 비용이 발생하지만, 침해 사고 대응 비용과 비교하면 투자 가치가 있어요.

AWS 계정 보안, 설정 안 하면 생기는 일

AWS 계정 보안, 설정 안 하면 생기는 일

AWS 책임공유모델에서 고객이 지켜야 할 영역

IAM 보안 강화와 Access Key 안전 관리

루트 계정 MFA 활성화

IAM 사용자 대신 IAM Role 사용

git-secrets로 코드 유출 방지

데이터 보안, S3 퍼블릭 차단과 네트워크 접근 제어

S3 퍼블릭 접근 차단

보안 그룹 최소 권한 원칙

VPC Flow Logs 활성화

위협 탐지와 감사 로그, CloudTrail·GuardDuty·EventBridge

CloudTrail 활성화

GuardDuty, AI 기반 이상 행위 탐지

CloudTrail 보안 이벤트 실시간 감지

비용 이상 감지와 계정 관리

CloudWatch Billing 알람과 AWS Budgets

사용하지 않는 리전 비활성화

루트 계정 이메일 알림과 연락처 정보 관리

Trusted Advisor 기본 보안 점검

10가지 설정 한눈에 보기

핵심 요약

FAQ

AWS 보안 설정, 어디서부터 시작해야 할지 모르겠다면. 에이핀이 함께 점검합니다.