빠른참조 · 7

보안과 암호화

가중치가 가장 큰 도메인(30퍼센트)의 판단 재료를 모았습니다. IAM 정책의 모양, 암호화 방식의 선택 기준, 탐지 서비스의 역할 구분 세 가지입니다.

정책 스니펫은 시험이 요구하는 최소한의 형태만 담았습니다. 문법을 외우는 것이 아니라 어떤 요소가 어떤 통제를 만드는지를 보십시오.

이 페이지 쓰는 법

정책 평가 순서와 결합 규칙

요청이 허용되는 과정 — 우선순위
순위 판정 결과
1 어떤 정책에서든 명시적 거부(explicit Deny)가 있는가 있으면 즉시 거부. 다른 허용을 모두 덮습니다
2 명시적 허용(explicit Allow)이 있는가 있으면 허용 — 단, 상한 정책(권한 경계 · SCP · 세션 정책)도 허용해야 합니다
3 아무것도 없는 경우 암묵적 거부(implicit Deny) — 기본값은 거부입니다
정책 유형을 조합했을 때의 결과
조합 결과 기억할 문장
자격 증명 기반 + 리소스 기반 (같은 계정) 합집합 둘 중 하나만 허용해도 됩니다
자격 증명 기반 + 권한 경계 교집합 둘 다 허용해야 합니다
자격 증명 기반 + 서비스 제어 정책(SCP) 교집합 둘 다 허용해야 합니다
자격 증명 기반 + 세션 정책 교집합 둘 다 허용해야 합니다
셋 이상이 함께 있을 때 전부 허용해야 합니다 상한을 하나라도 통과하지 못하면 거부입니다

정책 문서의 뼈대

policy-skeleton.json — 정책 문 하나가 담는 다섯 요소
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DescribeWhatThisAllows",
      "Effect": "Allow",
      "Action": ["s3:GetObject"],
      "Resource": ["arn:aws:s3:::example-bucket/reports/*"],
      "Condition": {
        "Bool": { "aws:SecureTransport": "true" }
      }
    }
  ]
}
정책 요소가 만드는 통제
요소 무엇을 정하는가
Effect Allow 또는 Deny. Deny는 다른 허용을 덮습니다
Action 어떤 API 호출인가. 서비스 접두사와 작업 이름으로 씁니다
Resource 어떤 대상인가. 최소 권한은 대부분 여기를 좁히는 일입니다
Principal 리소스 기반 정책과 신뢰 정책에만 있습니다. 누가 요청하는가
Condition 어떤 상황에서만 적용되는가. 암호화 강제, 전송 보안, 출처 제한이 여기서 만들어집니다

IAM 정책 패턴

아래 패턴은 시험 시나리오에서 반복되는 형태입니다. 계정 ID는 123456789012, 리소스 이름은 예시값이며 실제 값이 아닙니다.

최소 권한 — 대상을 좁힌다

least-privilege-s3.json — 특정 버킷의 특정 접두사만 읽기 (자격 증명 기반 정책)
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ListOnlyThatPrefix",
      "Effect": "Allow",
      "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::example-bucket",
      "Condition": {
        "StringLike": { "s3:prefix": ["reports/*"] }
      }
    },
    {
      "Sid": "ReadObjectsUnderPrefix",
      "Effect": "Allow",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::example-bucket/reports/*"
    }
  ]
}

버킷 수준 작업(s3:ListBucket)과 객체 수준 작업(s3:GetObject)은 리소스 ARN의 모양이 다릅니다. 버킷은 arn:aws:s3:::버킷, 객체는 arn:aws:s3:::버킷/키입니다. 둘을 섞어 쓰면 정책이 동작하지 않습니다.

EC2 인스턴스 역할 — 액세스 키를 심지 않는다

ec2-trust-policy.json — 역할의 신뢰 정책. 누가 이 역할을 맡을 수 있는가
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": { "Service": "ec2.amazonaws.com" },
      "Action": "sts:AssumeRole"
    }
  ]
}

교차 계정 접근 — 양쪽이 필요하다

cross-account-trust.json — 신뢰하는 쪽(역할이 있는 계정)의 신뢰 정책
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": { "AWS": "arn:aws:iam::123456789012:root" },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringEquals": { "sts:ExternalId": "example-external-id" },
        "Bool": { "aws:MultiFactorAuthPresent": "true" }
      }
    }
  ]
}
cross-account-caller.json — 호출하는 쪽 주체에게 필요한 자격 증명 기반 정책
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "sts:AssumeRole",
      "Resource": "arn:aws:iam::210987654321:role/ExampleCrossAccountRole"
    }
  ]
}

교차 계정은 양쪽이 모두 허용해야 성립합니다. 역할 쪽 신뢰 정책만 고치고 호출자 쪽 권한을 빠뜨리는 것이 전형적인 실수이고, 문항에서는 "한쪽만 바꾸는 선택지" 로 나타납니다. sts:ExternalId는 제삼자에게 역할을 위임할 때 혼동된 대리인 문제를 막는 장치입니다.

조건으로 강제하기

enforce-tls-and-sse.json — 버킷 정책으로 전송 보안과 암호화를 강제
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyInsecureTransport",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": [
        "arn:aws:s3:::example-bucket",
        "arn:aws:s3:::example-bucket/*"
      ],
      "Condition": {
        "Bool": { "aws:SecureTransport": "false" }
      }
    },
    {
      "Sid": "DenyUploadsWithoutKmsEncryption",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::example-bucket/*",
      "Condition": {
        "StringNotEquals": {
          "s3:x-amz-server-side-encryption": "aws:kms"
        }
      }
    }
  ]
}
시험에 자주 나오는 조건 키
조건 키 무엇을 강제하는가
aws:SecureTransport HTTPS로만 접근하게 합니다. false일 때 거부하는 형태로 씁니다
s3:x-amz-server-side-encryption 지정한 암호화 방식으로만 업로드하게 합니다
aws:MultiFactorAuthPresent 다중 인증을 거친 세션만 허용합니다
aws:SourceVpce 특정 VPC 엔드포인트를 통과한 요청만 허용합니다
aws:SourceIp 특정 IP 대역에서 온 요청만 허용합니다
aws:PrincipalOrgID 우리 조직에 속한 주체만 허용합니다
aws:RequestedRegion 특정 리전에서만 작업하게 합니다. 데이터 레지던시 요구에 씁니다
sts:ExternalId 제삼자 역할 위임에서 혼동된 대리인 문제를 막습니다

비공개 경로만 허용하기

vpce-only-bucket.json — 지정한 VPC 엔드포인트를 지나지 않은 요청 거부
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyAccessOutsideVpcEndpoint",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": [
        "arn:aws:s3:::example-bucket",
        "arn:aws:s3:::example-bucket/*"
      ],
      "Condition": {
        "StringNotEquals": {
          "aws:SourceVpce": "vpce-0123456789abcdef0"
        }
      }
    }
  ]
}

"데이터가 인터넷을 거치면 안 된다" 는 요구는 두 겹으로 만족시킵니다. 경로는 VPC 엔드포인트로 만들고, 강제는 위와 같은 버킷 정책으로 겁니다. 경로만 만들고 정책을 걸지 않으면 다른 경로로도 여전히 접근할 수 있습니다.

상한 걸기 — 권한 경계와 SCP

permissions-boundary.json — 이 주체가 넘을 수 없는 최대 권한
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:*", "cloudwatch:*", "logs:*"],
      "Resource": "*"
    }
  ]
}
scp-region-restriction.json — 조직 단위에 거는 리전 제한 서비스 제어 정책
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyOutsideApprovedRegions",
      "Effect": "Deny",
      "NotAction": ["iam:*", "organizations:*", "cloudfront:*", "route53:*", "support:*"],
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": ["ap-northeast-2", "us-east-1"]
        }
      }
    }
  ]
}
권한 경계와 서비스 제어 정책의 차이
항목 권한 경계 서비스 제어 정책(SCP)
적용 대상 IAM 사용자 또는 역할 하나 계정 또는 조직 단위(OU) 전체
붙이는 곳 주체에 직접 AWS Organizations의 루트 · OU · 계정
권한 부여 하지 않음 — 상한만 정합니다 하지 않음 — 상한만 정합니다
루트 사용자 해당 없음 멤버 계정의 루트에도 적용됩니다
대표 용도 개발자에게 역할 생성 권한을 주되 그 역할의 권한을 제한 조직 전체에 리전 제한, 특정 서비스 금지, 로깅 해제 금지

저장 데이터 암호화 매트릭스

네 방식의 차이는 한 줄로 요약됩니다 — 키를 누가 쥐고, 사용 기록이 남는가입니다.

Amazon S3의 서버 측 암호화 네 가지
항목 SSE-S3 SSE-KMS DSSE-KMS SSE-C
키 관리 주체 Amazon S3 AWS KMS AWS KMS (이중 계층) 고객 — 요청마다 키를 보냅니다
키 정책으로 접근 통제 불가 가능 가능 해당 없음
키 사용 감사 남지 않습니다 KMS 호출이 AWS CloudTrail에 남습니다 남습니다 남지 않습니다
키 교체 Amazon S3가 관리합니다 고객 관리형 키면 자동 교체를 켤 수 있습니다 같습니다 고객 책임입니다
AWS의 키 저장 저장합니다 저장합니다 저장합니다 저장하지 않습니다 — 잃으면 복구할 수 없습니다
고르는 신호 "암호화만 되면 된다" "키 사용을 감사", "키 접근을 따로 통제" 규정이 이중 암호화를 명시할 때 "키를 AWS에 맡길 수 없다"
그 밖의 서비스에서 저장 데이터를 암호화하는 방식
서비스 방식 주의할 점
Amazon EBS 볼륨 생성 시 KMS 키로 암호화합니다 암호화된 볼륨의 스냅샷과 그 스냅샷으로 만든 볼륨도 암호화 상태를 이어받습니다
Amazon RDS 인스턴스 생성 시 지정합니다 이미 만들어진 암호화되지 않은 인스턴스는 스냅샷을 암호화해 복원하는 방식으로 전환합니다
Amazon DynamoDB 저장 시 암호화가 적용됩니다 키 종류를 고르는 선택이 남습니다
Amazon EFS · Amazon FSx 파일 시스템 생성 시 지정합니다 전송 중 암호화는 별도 설정입니다
AWS Secrets Manager · Parameter Store KMS 키로 값을 암호화합니다 Parameter Store는 SecureString일 때만 암호화됩니다
전송 중 암호화 AWS Certificate Manager 인증서로 TLS를 종료합니다 붙이는 지점은 Application Load Balancer · Amazon CloudFront · Amazon API Gateway입니다

AWS KMS — 키 종류와 봉투 암호화

KMS 키 세 종류의 통제 범위
항목 AWS 소유 키 AWS 관리형 키 고객 관리형 키
키 정책 편집 불가 불가 가능
계정에서 보이는가 보이지 않습니다 보입니다 보입니다
자동 교체 AWS가 관리합니다 매년 자동 — 켜고 끌 수 없습니다 켤 수 있고 기본 주기는 365일입니다
교차 계정 사용 불가 불가 가능 — 키 정책으로 허용합니다
삭제 해당 없음 해당 없음 대기 기간을 두고 예약 삭제합니다. 되돌릴 수 없습니다
고르는 신호 특별한 요구가 없을 때의 기본 서비스가 알아서 만들어 주는 키 "키를 직접 통제", "교차 계정", "감사", "직접 교체 주기 지정"
KMS 자동 교체의 확인된 값
항목 값
고객 관리형 키 자동 교체 주기 기본 365일. RotationPeriodInDays로 조정할 수 있습니다
AWS 관리형 키 매년 자동 교체되며 켜고 끌 수 없습니다
지원 대상 대칭 암호화 키만 — 비대칭 · HMAC · 가져온 키 재료 · 사용자 지정 키 스토어는 제외됩니다
주기 변경 이력 2022년 5월에 3년에서 1년으로 바뀌었습니다

봉투 암호화 — 대용량 데이터가 KMS를 지나지 않는 이유

봉투 암호화의 순서
순서 일어나는 일
1 애플리케이션이 KMS에 데이터 키 생성을 요청합니다
2 KMS가 평문 데이터 키와 암호문 데이터 키 두 벌을 돌려줍니다
3 애플리케이션이 평문 데이터 키로 데이터를 암호화합니다
4 평문 데이터 키를 메모리에서 지우고, 암호문 데이터 키를 암호화된 데이터와 함께 저장합니다
5 복호화할 때는 암호문 데이터 키를 KMS에 보내 평문 키를 받아 온 뒤 데이터를 풉니다
결론 데이터 본체는 KMS를 지나지 않습니다. 그래서 크기 제약 없이 대용량을 다룰 수 있습니다

탐지 서비스 네 가지 — 입력 데이터로 구분합니다

Amazon GuardDuty · Amazon Inspector · Amazon Macie · AWS Security Hub의 역할 구분
항목 Amazon GuardDuty Amazon Inspector Amazon Macie AWS Security Hub
무엇을 입력으로 읽는가 로그와 네트워크 신호 워크로드의 소프트웨어와 네트워크 노출 Amazon S3의 데이터 내용 다른 보안 서비스의 결과
대답하는 질문 지금 수상한 활동이 일어나고 있는가 알려진 취약점이 있는가 민감 정보가 어디 있는가 전체 보안 상태가 표준에 맞는가
에이전트 필요 없습니다 대상에 따라 필요합니다 필요 없습니다 필요 없습니다
고르는 신호 "비정상 접근", "암호화폐 채굴 탐지", "침해 징후" "인스턴스와 컨테이너 이미지 점검", "CVE" "개인정보가 들어 있는지", "규정 대상 데이터 식별" "한곳에서 모아 본다", "규정 준수 점수"
감사와 조사에 쓰는 서비스의 역할 구분
서비스 대답하는 질문 이 서비스를 지목하는 표현
AWS CloudTrail 누가 무엇을 호출했는가 "API 호출 기록", "누가 이 리소스를 지웠나"
AWS Config 구성이 규칙을 지키는가 "규정 준수 여부 평가", "언제부터 어긋났나", "구성 변경 이력"
Amazon CloudWatch 얼마나 잘 동작하는가 "지표", "알람", "로그 패턴"
Amazon Detective 이 탐지 결과의 원인이 무엇인가 "근본 원인 조사", "관련 활동 추적"
IAM Access Analyzer 외부에 열린 접근 경로가 있는가 "의도치 않게 공유된 리소스", "쓰이지 않는 권한"

누구의 자격 증명인가

자격 증명 서비스의 대상 구분
서비스 누구를 위한 것인가 고르는 신호
AWS IAM 역할 AWS 리소스와 서비스 "EC2에서 S3를 호출", "Lambda가 DynamoDB에 접근"
AWS IAM Identity Center 직원이 여러 AWS 계정에 접근 "사내 사용자가 여러 계정에", "외부 IdP와 연동한 단일 로그인"
Amazon Cognito 사용자 풀 애플리케이션의 최종 사용자 인증 "모바일 앱 회원 가입과 로그인"
Amazon Cognito 자격 증명 풀 인증된 사용자에게 임시 AWS 자격 증명 부여 "앱이 직접 S3에 업로드해야 한다"
AWS Directory Service Active Directory 기반 인증 "도메인 조인", "기존 AD 자격 증명 사용"
AWS STS 모든 임시 자격 증명의 발급자 "역할 위임", "교차 계정", "페더레이션"

비밀 저장과 자동 교체의 선택은 Secrets Manager와 Parameter Store 비교에 있습니다. 판단 기준은 하나, 자동 교체가 필요한가입니다.

이어서 볼 곳

공식 문서 출처