AWS 클라우드에서 데이터를 다루다 보면 반드시 맞닥뜨리는 질문이 있습니다. "이 서비스가 저 서비스에 접근해도 되는가?" 그리고 "이 사람이 이 데이터를 볼 수 있는가?" 보안은 크게 두 단계로 나뉩니다. 인증(Authentication)은 "당신이 누구인지" 확인하는 과정이고, 권한 부여(Authorization)는 "당신이 무엇을 할 수 있는지" 결정하는 과정입니다. 현실에서 비유하자면, 회사 건물에 들어갈 때 사원증을 찍는 것이 인증이고, 사원증에 따라 특정 층이나 방에만 들어갈 수 있는 것이 권한 부여입니다. 데이터 엔지니어링 시험에서 이 두 개념은 매우 자주 출제됩니다.
인증 (Authentication) — 당신이 누구인지 확인하기
인증은 접근을 시도하는 주체가 정말 그 주체가 맞는지 검증하는 단계입니다. AWS 데이터 파이프라인에서는 사람이 아니라 서비스끼리 서로를 인증하는 경우가 훨씬 많습니다. Glue가 S3에서 파일을 읽으려면, EMR이 데이터를 처리하려면, Lambda가 DynamoDB에 쓰려면 — 모두 먼저 "나는 이 서비스입니다"라는 신원을 증명해야 합니다.
IAM 역할 — 서비스 간 신뢰의 열쇠
IAM(Identity and Access Management)은 AWS의 중앙 신원 관리 시스템입니다. 사람이 로그인할 때 쓰는 IAM 사용자와 달리, IAM 역할(Role)은 AWS 서비스나 애플리케이션이 일시적으로 빌려 쓰는 신원입니다. 위임장이라고 생각하면 됩니다. "Glue 서비스는 이 역할을 빌려서 S3에 접근할 수 있다"는 선언입니다.
데이터 파이프라인에서 자주 등장하는 IAM 역할 패턴:
| 시나리오 | 역할 유형 | 예시 | |---------|----------|------| | Glue ETL 작업이 S3에서 데이터 읽기/쓰기 | Glue 서비스 역할 | AWSGlueServiceRole | | Lambda 함수가 DynamoDB 테이블에 접근 | Lambda 실행 역할 | LambdaExecutionRole | | EMR 클러스터가 S3에서 데이터 처리 | EC2 인스턴스 프로파일 | EMR_EC2_DefaultRole | | Step Functions가 Lambda와 Glue 호출 | Step Functions 실행 역할 | StatesExecutionRole |
역할이 없으면 어떻게 될까요? Glue가 S3 파일을 읽으려 할 때 역할이 없으면 "Access Denied" 오류가 발생합니다. 파이프라인이 갑자기 멈추는 원인 1위가 바로 IAM 역할 설정 누락이나 권한 부족입니다. 역할을 설정할 때는 어떤 서비스가 어떤 서비스에 접근하는지 명확히 파악하고, 그에 맞는 역할을 생성하고 연결해야 합니다.
VPC 네트워크 보안 — 데이터가 이동하는 도로 통제하기
인증이 "누구인지" 확인한다면, 네트워크 보안은 "어느 길로 와야 하는지"를 제어합니다. VPC(Virtual Private Cloud)는 AWS 안에 만드는 나만의 사설 네트워크입니다. 인터넷에서 분리된 격리된 공간이라고 생각하면 됩니다.
기본적으로 EC2나 Lambda에서 S3에 접근하면 트래픽이 인터넷을 통해 나갔다가 돌아옵니다. 이는 보안상 위험하고 데이터 전송 비용도 발생합니다. VPC 엔드포인트를 사용하면 트래픽이 AWS 내부 네트워크만을 통해 이동합니다.
두 가지 VPC 엔드포인트 유형:
게이트웨이 엔드포인트는 S3와 DynamoDB에 사용하며 무료입니다. 라우팅 테이블에 경로를 추가하면 해당 서비스로의 트래픽이 자동으로 내부 네트워크를 통해 라우팅됩니다.
인터페이스 엔드포인트(PrivateLink)는 Glue, KMS, Secrets Manager, Kinesis 등 대부분의 AWS 서비스에 사용합니다. VPC 안에 프라이빗 IP 주소를 생성하고, 그 IP를 통해 AWS 서비스에 접근합니다. 시간당 소액의 비용이 발생합니다.
보안 그룹(Security Group)은 EC2, EMR, Redshift 클러스터에 대한 방화벽입니다. 어떤 IP 주소, 어떤 포트에서 오는 트래픽을 허용할지 인바운드/아웃바운드 규칙으로 정의합니다. 예를 들어 Redshift 클러스터는 데이터 분석팀 VPC의 IP에서 오는 5439 포트만 허용하도록 설정합니다.
AWS PrivateLink는 서로 다른 VPC나 AWS 계정 간에 프라이빗 연결을 제공합니다. 파트너사나 다른 팀의 계정과 데이터를 주고받을 때 인터넷을 거치지 않아도 됩니다.
자격 증명 관리 — 비밀번호를 안전하게 보관하기
데이터 파이프라인에서 외부 데이터베이스나 API에 연결할 때 비밀번호가 필요합니다. 이 비밀번호를 코드에 직접 넣는 것은 절대 해서는 안 됩니다. Git 저장소에 올라가거나, 로그에 출력될 수 있고, 코드를 보는 누구나 접근할 수 있게 됩니다.
AWS Secrets Manager는 비밀번호, API 키, DB 연결 문자열 등을 안전하게 암호화해서 저장합니다. 가장 강력한 기능은 자동 교체(Auto Rotation)입니다. 보안 정책상 DB 비밀번호를 90일마다 변경해야 한다면, Secrets Manager가 Lambda 함수를 통해 자동으로 비밀번호를 교체합니다. RDS, Redshift, DocumentDB와 네이티브 통합을 제공합니다. 파이프라인 코드는 항상 Secrets Manager에서 최신 비밀번호를 가져오므로 서비스 중단 없이 교체가 완료됩니다.
AWS Systems Manager Parameter Store는 Secrets Manager보다 가벼운 설정값 저장소입니다. 암호화가 필요한 민감한 값과 그렇지 않은 일반 설정값을 경로 기반으로 저장하고 관리합니다.
| 비교 항목 | Secrets Manager | Parameter Store | |---------|----------------|----------------| | 자동 교체 | 지원 (Lambda 연동) | 미지원 | | 비용 | 비밀당 월 $0.40 | 표준 파라미터 무료 | | 주요 용도 | DB 비밀번호, API 키 | 앱 설정, 환경변수 | | 크로스 계정 접근 | 지원 | 지원 |
!인증(Authentication) vs 인가(Authorization)
권한 부여 (Authorization) — 무엇을 할 수 있는지 결정하기
신원이 확인됐다면 이제 "이 신원이 무엇을 할 수 있는가"를 결정해야 합니다. AWS에서 권한 부여는 IAM 정책과 서비스별 접근 제어로 구현됩니다.
IAM 정책 — 권한의 설계도
IAM 정책은 JSON 형식의 문서로, 어떤 서비스의 어떤 리소스에 어떤 작업을 허용 또는 거부하는지를 정의합니다. 정책은 역할, 사용자, 그룹에 연결됩니다.
서비스 역할 정책은 Glue, EMR 같은 서비스가 다른 AWS 서비스에 접근하기 위한 정책입니다. Glue 서비스 역할에는 보통 S3 읽기/쓰기, CloudWatch 로그 쓰기, Glue 카탈로그 접근 권한이 포함됩니다.
리소스 정책은 S3 버킷이나 SQS 큐 같은 리소스 자체에 붙이는 정책입니다. "이 S3 버킷은 계정 A의 특정 역할에서만 접근 가능하다"처럼 크로스 계정 접근 제어에 특히 중요합니다.
최소 권한 원칙(Least Privilege)은 필요한 것만 허용하는 원칙입니다. Glue 작업이 특정 S3 버킷의 raw/ 폴더만 읽으면 된다면, 전체 S3에 대한 읽기 권한이 아니라 그 특정 경로에만 권한을 줘야 합니다. 이렇게 하면 혹시라도 자격 증명이 유출되더라도 피해 범위가 최소화됩니다.
Lake Formation 권한 — 데이터 레이크의 세밀한 접근 제어
Amazon Lake Formation은 데이터 레이크의 중앙 거버넌스 시스템입니다. S3에 저장된 데이터를 Glue 카탈로그를 통해 테이블로 관리하고, 그 테이블에 대한 세밀한 접근 제어를 한 곳에서 관리합니다.
Lake Formation 이전에는 S3 버킷 정책, IAM 정책, Glue 카탈로그 정책을 각각 따로 설정해야 해서 복잡하고 실수가 잦았습니다. Lake Formation은 이 모든 것을 통합해 하나의 인터페이스에서 관리합니다.
Lake Formation이 제공하는 권한 수준:
데이터베이스 수준: 특정 데이터베이스 전체에 대한 접근 허용 테이블 수준: 특정 테이블에만 접근 허용 열(Column) 수준: 민감한 열(예: 주민등록번호, 신용카드번호)을 특정 사용자에게 숨김 행(Row) 수준: 데이터 필터를 통해 특정 조건의 행만 보이게 제한
데이터 필터 예시: 영업 데이터 테이블에서 서울팀은 region='seoul' 행만, 부산팀은 region='busan' 행만 볼 수 있도록 설정합니다. 같은 테이블이지만 사용자마다 다른 뷰를 제공합니다. 데이터를 복사하거나 이동하지 않고도 가능합니다.
RBAC(Role-Based Access Control, 역할 기반 접근 제어)는 사람의 조직 내 역할에 따라 권한을 부여하는 방식입니다. "데이터 분석팀 역할을 가진 사람은 reporting 데이터베이스를 읽을 수 있다"처럼 역할 단위로 권한을 관리합니다. 신입 직원이 오면 역할만 부여하면 해당 권한이 자동으로 적용됩니다.
TBAC(Tag-Based Access Control, 태그 기반 접근 제어)는 리소스와 사용자 모두에 태그를 붙이고, 태그가 일치할 때 자동으로 접근을 허용하는 방식입니다. 예를 들어 테이블에 "sensitivity=confidential" 태그, 특정 사용자에게 "clearance=confidential" 태그를 붙이면 Lake Formation이 자동으로 매칭해서 접근을 허용합니다. 수백 개의 테이블이 있을 때 개별 권한 설정 없이 태그만으로 관리할 수 있어 훨씬 효율적입니다.
Redshift 접근 제어 — 데이터 웨어하우스의 다층 보안
Redshift는 데이터 웨어하우스이므로 IAM 외에도 데이터베이스 내부의 접근 제어가 필요합니다.
Redshift 사용자와 그룹은 PostgreSQL과 유사하게 동작합니다. 데이터베이스 내부에서 사용자를 만들고, 그룹에 넣고, 그룹에 스키마나 테이블에 대한 SELECT, INSERT 등의 권한을 부여합니다. 이는 IAM과는 별개의 데이터베이스 수준 접근 제어입니다.
Redshift 데이터 공유(Data Sharing)는 서로 다른 Redshift 클러스터나 AWS 계정 간에 데이터를 복사하지 않고 실시간으로 공유하는 기능입니다. 데이터를 제공하는 쪽(Producer)이 공유 객체를 만들면, 받는 쪽(Consumer)은 읽기 전용으로 접근합니다. 운영 클러스터와 분석 클러스터를 분리할 때 유용합니다.
Redshift Spectrum으로 S3 데이터를 쿼리할 때는 Lake Formation 권한이 적용됩니다. Spectrum이 Glue 카탈로그에서 테이블을 찾은 뒤, Lake Formation에서 SELECT 권한을 확인합니다. Lake Formation이 접근을 거부하면 Redshift의 IAM 역할이 S3 읽기 권한을 갖고 있더라도 쿼리가 실패합니다.
시험 핵심 정리
| 시험 키워드 | 정답 서비스/개념 | |-----------|--------------| | 서비스가 다른 서비스에 접근 | IAM 서비스 역할 | | 인터넷 없이 S3에 프라이빗 접근 | VPC 게이트웨이 엔드포인트 | | DB 비밀번호 자동 교체 | Secrets Manager | | 앱 설정값 저장 (비용 절감) | Parameter Store | | 데이터 레이크 열/행 수준 접근 제어 | Lake Formation | | 태그로 접근 권한 자동 매칭 | TBAC (Tag-Based Access Control) | | 역할에 따라 접근 권한 관리 | RBAC (Role-Based Access Control) | | 다른 Redshift 클러스터와 데이터 공유 | Redshift 데이터 공유 | | Redshift Spectrum의 S3 접근 제어 | Lake Formation 권한 | | 필요한 것만 허용하는 보안 원칙 | 최소 권한 원칙 (Least Privilege) |