Day 1 - SageMaker IAM 보안: 실행 역할과 최소 권한

권한이 흐르는 두 경로

이번 주는 ML 솔루션을 "안전하고 책임감 있게, 그리고 싸게" 운영하는 영역이고, 첫날 주제는 권한이다. SageMaker는 사용자가 직접 호출하는 작업과 SageMaker가 사용자를 대신해 수행하는 작업이 분리되어 있다. 이 둘을 헷갈리면 권한 시나리오를 매번 틀린다.

[사람 · CI 파이프라인 · SDK 호출자]
        │  ① sagemaker:CreateTrainingJob        ← 사용자 IAM 정책
        │  ② iam:PassRole  (역할을 넘겨줌)       ← 사용자 IAM 정책
        ▼
┌────────────────────────────┐
│      SageMaker 서비스       │
└────────────────────────────┘
        │  ③ sts:AssumeRole                     ← 실행 역할의 "신뢰 정책"
        ▼
┌────────────────────────────┐
│    SageMaker 실행 역할      │
└────────────────────────────┘
        │  ④ 실제 리소스 접근                    ← 실행 역할의 "권한 정책"
        ├──▶ S3         : 학습 데이터 읽기 / model.tar.gz 쓰기
        ├──▶ ECR        : 알고리즘 컨테이너 이미지 pull
        ├──▶ CloudWatch : 로그 스트림 · 학습 지표
        └──▶ KMS        : 암호화된 버킷·EBS 볼륨의 키 사용

경로 ①②는 요청을 받아줄지를, 경로 ③④는 작업이 실제로 돌아갈지를 결정한다. 끊긴 지점이 어디냐에 따라 증상이 완전히 달라진다.

핵심은 이것이다 — 학습 작업이 "S3 접근 거부"로 실패하면 그건 사용자 정책 문제가 아니라 실행 역할의 S3 권한 문제다. 시험은 이 구분을 반복해서 묻는다.

💡 관련 이론: 이 구조는 IAM의 "신뢰 정책 + 권한 정책" 분리에서 나온다. 사용자는 자신의 권한으로 SageMaker에 요청을 넣을 뿐, 그 뒤에 벌어지는 데이터 접근은 서비스가 떠맡은 역할의 신분으로 일어난다. 사용자에게 S3 권한이 아무리 많아도 실행 역할에 없으면 학습은 실패하고, 반대로 실행 역할이 아무리 세도 사용자에게 CreateTrainingJob이 없으면 작업은 만들어지지도 않는다.

신뢰 정책 vs 권한 정책 — 역할의 두 얼굴

역할 하나에는 서로 다른 질문에 답하는 정책 두 개가 붙는다. 둘 다 있어야 역할이 작동한다.

실행 역할이 SageMaker에 의해 assume되려면 신뢰 정책에 SageMaker 서비스 주체가 있어야 한다.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": { "Service": "sagemaker.amazonaws.com" },
      "Action": "sts:AssumeRole"
    }
  ]
}

Principal이 사람이 아니라 Service라는 점이 포인트다. 이 줄이 빠지면 SageMaker가 역할을 떠맡지 못해 작업이 시작조차 안 된다.

최소 권한 실행 역할 만들기

AWS가 제공하는 AmazonSageMakerFullAccess는 학습·실습용으로는 편하지만 프로덕션에는 과도하다. 작업이 실제로 건드리는 리소스만 허용하는 권한 정책을 직접 작성한다.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ReadTrainingData",
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:ListBucket"],
      "Resource": [
        "arn:aws:s3:::ml-train-data-prod",
        "arn:aws:s3:::ml-train-data-prod/*"
      ]
    },
    {
      "Sid": "WriteModelArtifacts",
      "Effect": "Allow",
      "Action": ["s3:PutObject"],
      "Resource": "arn:aws:s3:::ml-model-artifacts-prod/*"
    },
    {
      "Sid": "PullContainerImage",
      "Effect": "Allow",
      "Action": ["ecr:GetDownloadUrlForLayer", "ecr:BatchGetImage", "ecr:GetAuthorizationToken"],
      "Resource": "*"
    },
    {
      "Sid": "WriteLogsAndMetrics",
      "Effect": "Allow",
      "Action": ["logs:CreateLogStream", "logs:PutLogEvents", "cloudwatch:PutMetricData"],
      "Resource": "*"
    }
  ]
}

의도적으로 좁힌 부분은 다음과 같다. S3는 특정 버킷 ARN으로 제한했고 읽기 버킷과 쓰기 버킷을 분리했다. 데이터 버킷에 s3:DeleteObject나 s3:*를 넣지 않는 것이 최소 권한의 핵심이다. 학습 작업이 실제로 필요로 하는 권한은 아래 다섯 갈래로 정리된다.

⚠️ 함정: KMS는 역할의 IAM 정책과 KMS 키 정책 양쪽에서 허용돼야 한다. IAM 정책에만 kms:Decrypt를 넣고 키 정책을 손대지 않아 계속 거부되는 사례가 흔하다. "S3 목록은 되는데 객체 읽기만 실패한다"면 십중팔구 SSE-KMS 키 권한이다.

최소 권한(least privilege)은 "필요한 만큼만"이 전부가 아니다. 세 축으로 좁힌다 — ① 액션(s3:* 대신 GetObject만), ② 리소스(* 대신 특정 버킷 ARN), ③ 조건(Condition 블록으로 특정 VPC·태그·암호화 강제). 시험에서 "가장 안전한 정책"을 고르라면 보통 액션과 리소스가 가장 좁은 보기가 정답이다.

Condition으로 한 단계 더 좁히기

Condition 블록은 정책을 상황에 따라 제한한다. 특정 태그가 붙은 작업만 허용하거나, 암호화되지 않은 업로드를 거부할 수 있다.

{
  "Sid": "DenyUnencryptedUploads",
  "Effect": "Deny",
  "Action": "s3:PutObject",
  "Resource": "arn:aws:s3:::ml-model-artifacts-prod/*",
  "Condition": {
    "StringNotEquals": { "s3:x-amz-server-side-encryption": "aws:kms" }
  }
}

이 Deny는 KMS 암호화 없는 업로드를 원천 차단한다. 명시적 Deny는 어떤 Allow보다 우선하므로 가드레일을 강제할 때 강력하다.

마지막 세 줄이 중요한 이유는 거버넌스를 사후 점검이 아니라 생성 시점에 막는 방식이기 때문이다. "VPC 밖에서 학습을 돌리지 마세요"라고 문서로 공지하는 대신, VPC 설정 없는 CreateTrainingJob 요청 자체를 IAM에서 거부하면 규칙이 우회될 여지가 없다.

사용자 정책과 PassRole

사용자가 학습 작업을 만들 때는 실행 역할을 SageMaker에 "넘겨준다(pass)". 그래서 사용자 정책에 iam:PassRole이 필요하다. 이게 없으면 작업 생성 권한이 있어도 역할을 붙이지 못해 실패한다.

{
  "Effect": "Allow",
  "Action": "iam:PassRole",
  "Resource": "arn:aws:iam::123456789012:role/SageMakerExecutionRole",
  "Condition": {
    "StringEquals": { "iam:PassedToService": "sagemaker.amazonaws.com" }
  }
}

• Resource를 특정 역할 ARN으로 못박는다. "Resource": "*"는 사실상 계정 내 아무 역할이나 서비스에 실어 보낼 수 있다는 뜻이다.
• iam:PassedToService 조건으로 "이 역할은 SageMaker에만 넘길 수 있다"고 한정한다.
• 두 가지를 다 빼면 권한 상승(privilege escalation) 통로가 된다 — 권한이 약한 사용자가 강한 역할을 골라 서비스에 실어 보내고, 그 역할의 신분으로 코드를 실행할 수 있다.

iam:PassRole은 시험 범위에 든다. "사용자가 학습 작업을 만들 권한은 있는데 자꾸 실패한다"는 시나리오의 정답은 대개 PassRole 누락이다. PassRole은 "역할을 떠넘기는 행위"에 대한 권한이지 역할 자체의 권한이 아니다. 오류 메시지에 iam:PassRole이 그대로 찍히므로 식별도 쉽다.

Studio·노트북에서의 권한 분리

SageMaker Studio와 노트북 인스턴스도 각자의 실행 역할로 동작한다. 데이터 사이언티스트가 노트북에서 학습을 돌리면 그 노트북의 실행 역할 권한으로 S3 접근과 학습이 수행된다. 권한을 너무 넓게 주면(예: AdministratorAccess) 노트북이 곧 백도어가 된다.

팀·프로젝트별로 역할을 분리하고, 각 역할이 필요한 데이터 버킷만 허용하는 것이 표준이다. 태그 기반 Condition을 쓰면 "프로젝트 태그가 내 것인 작업만 볼 수 있다" 같은 경계를 정책 하나로 만들 수 있다.

권한 문제를 진단하는 순서

권한 사고가 났을 때 추측 대신 확인부터 한다. 작업 설명에는 실제로 사용된 역할 ARN과 실패 사유가 그대로 들어 있다.

import boto3
 
sm = boto3.client('sagemaker')
desc = sm.describe_training_job(TrainingJobName='my-training-job')
 
print(desc['RoleArn'])        # 이 작업이 실제로 사용한 실행 역할
print(desc['FailureReason'])  # AccessDenied면 어떤 리소스인지 여기에 찍힌다
 
# 그 역할에 실제로 붙어 있는 정책 확인
iam = boto3.client('iam')
role_name = desc['RoleArn'].split('/')[-1]
print(iam.list_attached_role_policies(RoleName=role_name))  # 관리형 정책
print(iam.list_role_policies(RoleName=role_name))           # 인라인 정책

FailureReason에 찍힌 리소스 ARN이 정책의 Resource와 한 글자라도 다르면(버킷 이름 오타, prefix 누락) 그게 원인이다. 정책이 맞는데도 거부된다면 명시적 Deny를 의심한다.

IAM 평가 순서는 명시적 Deny > 명시적 Allow > 암묵적 Deny다. 역할 정책이 완벽해도 조직의 SCP, 역할에 걸린 권한 경계(permissions boundary), S3 버킷 정책 중 어느 하나가 Deny면 거부된다. "권한을 다 줬는데 왜 안 되지"의 답은 대개 이 세 곳 중 하나다.

권한이 막힐 때: 증상 → 원인 → 조치

내일은 네트워크 격리 — VPC 모드로 SageMaker를 인터넷에서 떼어내는 방법을 다룬다.

📖 용어

• 실행 역할 (execution role) : SageMaker가 사용자를 대신해 떠맡는 IAM 역할. 학습 중의 S3·ECR·CloudWatch 접근은 전부 이 역할의 신분으로 일어난다.
• 신뢰 정책 (trust policy) : "누가 이 역할을 맡을 수 있는가"를 정의하는 정책. SageMaker 역할이면 sagemaker.amazonaws.com이 들어간다.
• 권한 정책 (permission policy) : "이 역할이 무엇을 할 수 있는가"를 정의하는 정책. 액션·리소스·조건으로 구성된다.
• AssumeRole : 어떤 주체가 역할의 신분을 잠시 빌려 쓰는 동작. 신뢰 정책이 허락해야 가능하다.
• iam:PassRole : 역할을 다른 서비스에 넘겨주는 행위에 대한 권한. 역할 자체의 권한이 아니라 "넘기기"에 대한 권한이다.
• 최소 권한 (least privilege) : 필요한 액션·리소스만 허용하는 원칙. 액션·리소스·조건 세 축으로 좁힌다.
• Condition 블록 : 정책이 언제 적용될지 상황을 제한하는 부분. 태그·암호화·VPC 같은 조건을 걸 수 있다.
• 명시적 Deny : Effect: Deny로 직접 적은 거부. 어떤 Allow보다 우선하므로 가드레일 용도로 쓴다.
• 권한 경계 (permissions boundary) : 역할이 가질 수 있는 권한의 상한선. 정책이 허용해도 경계 밖이면 거부된다.
• 권한 상승 (privilege escalation) : 약한 권한의 사용자가 강한 역할을 손에 넣는 것. 무제한 PassRole이 대표적 통로다.