Day 1 - 접근 제어: IAM과 Lake Formation 권한

IAM 기초와 최소 권한 원칙

데이터 보안의 출발점은 "누가 무엇에 접근할 수 있는가"를 정하는 접근 제어다. AWS 분석 환경에서는 IAM 이 서비스 API 수준의 넓은 권한을, Lake Formation 이 카탈로그 수준의 세밀한 권한을 맡는다.

• 역할(Role) 은 임시 자격 증명을 준다. Glue·EMR 같은 서비스가 사용자 대신 일할 때, 그리고 다른 계정이 접근할 때 쓴다.
• 최소 권한(Least Privilege) 은 작업에 꼭 필요한 권한만 주는 것이다. 와일드카드(*)를 남발하지 않고 Resource 와 Condition 으로 범위를 좁힌다.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowReadSpecificPrefix",
      "Effect": "Allow",
      "Action": ["s3:GetObject"],
      "Resource": "arn:aws:s3:::lake-curated/sales/*",
      "Condition": {
        "StringEquals": { "aws:RequestedRegion": "ap-northeast-2" }
      }
    }
  ]
}

💡 관련 이론: IAM 평가 로직은 "명시적 거부(Deny) > 명시적 허용(Allow) > 묵시적 거부"다. 어떤 정책에든 Deny 가 하나라도 맞으면 즉시 차단되고, 어디에도 Allow 가 없으면 기본값인 묵시적 거부로 끝난다. 권한 경계와 SCP 는 권한을 주지 않는다. 줄 수 있는 범위를 깎을 뿐이다.

• 교차 계정 요청은 두 계정에서 각각 평가되고, 둘 다 허용이어야 통과한다. "버킷 정책에 상대 계정을 넣었는데도 거부된다"면 상대 계정의 역할에 S3 권한이 없는 것이다.

Lake Formation 은 어떻게 접근을 통제하나

Lake Formation 은 Glue Data Catalog 의 데이터베이스·테이블·컬럼 권한을 한곳에서 관리한다. 동작의 핵심은 S3 위치의 등록(register) 과 자격 증명 발급(credential vending) 이다.

① 관리자가 S3 위치를 Lake Formation 에 등록(등록 시 그 위치를 읽고 쓸 수 있는 역할을 지정)
② 사용자가 Athena 로 쿼리
③ Athena 가 Lake Formation 에 요청 → Lake Formation 이 권한(테이블·컬럼·행)을 확인
④ 통과하면 등록 역할을 맡아 만든 임시 자격 증명을 Athena 에 발급
⑤ Athena 는 그 자격 증명으로 S3 를 읽되, 허용된 컬럼·행만 사용자에게 돌려준다

• 사용자는 S3 버킷에 대한 IAM 권한을 직접 갖지 않아도 된다. S3 접근 권한은 등록에 쓴 역할이 갖는다.
• 대신 사용자(또는 서비스의 실행 역할)에게 IAM 권한 lakeformation:GetDataAccess 가 있어야 한다. 이 권한의 Resource 는 * 만 지원된다. Athena 는 사용자 본인에게, 다른 통합 서비스는 실행 역할에 이 권한을 요구한다.
• Lake Formation 은 S3 API 로 직접 들어오는 접근을 막지 않는다. 사용자에게 IAM 으로 s3:GetObject 가 남아 있으면 컬럼 필터를 건 테이블의 원본 파일을 그대로 내려받을 수 있다. Lake Formation 으로 통제하려면 직접 경로의 S3 권한을 걷어 낸다.

사용자 요청 → [IAM 정책 통과?] → [Lake Formation 권한 통과?] → 데이터 접근
              둘 중 하나라도 거부되면 차단

기본 설정이 만드는 함정: IAMAllowedPrincipals

Lake Formation 은 기존 Glue 사용자와의 호환을 위해 처음에는 사실상 꺼진 상태다.

• 기존 카탈로그 리소스 전부에 IAMAllowedPrincipals 그룹이 Super 권한을 갖고 있다.
• 새 리소스에는 "IAM 접근 제어만 사용" 설정이 켜져 있다.
• 결과적으로 접근은 IAM 정책만으로 결정되고, 개별 Lake Formation 권한은 효력이 없다.

• Lake Formation 통제를 실제로 켜려면 새 리소스의 기본 설정을 바꾸고, 기존 리소스에서 IAMAllowedPrincipals 권한을 회수한다.
• 한 번에 바꾸기 어려우면 하이브리드 액세스 모드를 쓴다. 특정 사용자 집합에만 Lake Formation 권한을 적용하고 나머지 기존 워크로드는 IAM 방식 그대로 둔 채 옮겨 갈 수 있다.

Lake Formation 권한의 종류

• 권한은 부여(grant) 방식이다. with grant option 을 붙이면 받은 사람이 다른 주체에게 다시 줄 수 있다.
• 데이터 위치 권한은 읽기 권한이 아니다. "이 S3 경로를 가리키는 테이블을 만들어도 되는가"를 통제한다. 누군가 민감 경로 위에 자기 테이블을 만들어 우회하는 것을 막는 장치다. 데이터를 읽고 쓰는 데는 SELECT·INSERT 면 충분하다.

세분화 권한: 컬럼·행·셀과 데이터 필터

세 수준 모두 데이터 필터(Data Cells Filter) 하나로 표현한다. 필터를 만들고, 그 필터에 SELECT 를 부여한다.

{
  "Name": "analyst_kr_no_pii",
  "TableCatalogId": "111122223333",
  "DatabaseName": "sales",
  "TableName": "orders",
  "ColumnWildcard": { "ExcludedColumnNames": ["email", "ssn"] },
  "RowFilter": { "FilterExpression": "region = 'ap-northeast-2'" }
}

aws lakeformation grant-permissions \
  --principal DataLakePrincipalIdentifier=arn:aws:iam::111122223333:role/RegionAnalyst \
  --permissions SELECT \
  --resource '{"DataCellsFilter":{"TableCatalogId":"111122223333","DatabaseName":"sales","TableName":"orders","Name":"analyst_kr_no_pii"}}'

• 행 필터 표현식은 PartiQL 의 WHERE 절 문법을 따른다. 문자열은 작은따옴표로 감싼다. 모든 행을 허용하려면 "모든 행" 와일드카드를 쓴다.
• 필터는 읽기에만 적용된다. 필터와 함께 줄 수 있는 권한은 SELECT 뿐이다.
• 테이블 하나에 필터를 여러 개 만들고, 역할마다 다른 필터를 부여한다. 같은 쿼리를 날려도 역할에 따라 결과가 달라진다.
• Athena, Redshift Spectrum, EMR 같은 통합 엔진이 이 필터를 적용한다. 셀 수준 필터가 걸린 테이블을 읽는 Glue 잡에서는 잡 북마크, 푸시다운 조건 등 일부 기능을 쓸 수 없다.

대규모 권한 관리: LF-Tags(TBAC)

명명형(named resource) 권한은 사용자와 테이블이 늘수록 GRANT 문이 곱으로 늘어난다. LF-Tags 는 리소스에 태그를 붙이고, 태그 값에 권한을 부여한다.

{
  "TagPolicy": {
    "Expression": [
      { "TagKey": "sensitivity", "TagValues": ["public", "internal"] },
      { "TagKey": "domain", "TagValues": ["sales"] }
    ],
    "Permissions": ["SELECT", "DESCRIBE"]
  }
}

• 위 예시는 sensitivity 가 public 또는 internal 이고 domain 이 sales 인 리소스에 SELECT 를 준다. 키끼리는 AND, 한 키의 값끼리는 OR 다. sensitivity=confidential 리소스는 자동으로 빠진다.
• 태그는 상속된다. 데이터베이스의 태그를 테이블이, 테이블의 태그를 컬럼이 물려받고, 아래에서 값을 덮어쓸 수 있다. 컬럼 하나에만 sensitivity=confidential 을 붙이면 그 컬럼만 빠지는 컬럼 수준 통제가 된다.
• 새 테이블은 태그만 맞으면 권한이 자동으로 적용된다. GRANT 를 새로 쓸 필요가 없다.
• LF-Tags 는 IAM 태그가 아니다. 서로 바꿔 쓸 수 없다. LF-Tags 는 Lake Formation 권한 부여에, IAM 태그는 IAM 정책 조건에 쓴다.

교차 계정 접근

{
  "Effect": "Allow",
  "Principal": { "AWS": "arn:aws:iam::444455556666:root" },
  "Action": "sts:AssumeRole"
}

• 공유받은 계정에서 Athena·Redshift Spectrum 으로 조회하려면 리소스 링크(resource link) 를 만들어야 한다. 공유된 테이블이 쿼리 엔진에 보이게 하는 로컬 포인터다.
• 공유받은 계정의 데이터 레이크 관리자는 받은 권한을 자기 계정의 사용자에게 다시 부여해야 한다. 계정에 공유됐다고 그 계정의 모든 사용자가 읽을 수 있는 것은 아니다.
• 데이터가 고객 관리형 KMS 키로 암호화돼 있으면 키 정책에도 교차 계정 주체를 허용해야 한다. AWS 관리형 키(aws/s3)는 키 정책을 바꿀 수 없어 교차 계정 공유에 쓸 수 없다.

💡 관련 이론: 교차 계정 접근은 "신뢰하는 쪽(trust policy)"과 "권한을 주는 쪽(permission policy)" 양쪽이 모두 설정돼야 한다. 암호화된 데이터라면 KMS 키 정책까지 세 겹이 맞아야 성공한다. 문제에서 둘은 맞는데 실패한다면 남은 하나가 답이다.

증상 → 원인 → 조치

지문 단서 → 정답 판별표

내일은 접근을 허용받은 뒤에도 데이터를 보호하는 층, KMS 와 서비스별 암호화를 다룬다.

📖 용어

• 최소 권한 : 일을 하는 데 꼭 필요한 권한만 주는 원칙.
• 신뢰 정책 : 역할에 붙어 "누가 이 역할을 맡을 수 있는가"를 정하는 리소스 기반 정책.
• 등록(register) : S3 위치를 Lake Formation 이 통제하도록 맡기는 일. 이때 그 위치를 읽고 쓸 역할을 지정한다.
• credential vending : Lake Formation 이 권한을 확인한 뒤 쿼리 엔진에 임시 자격 증명을 내주는 방식.
• IAMAllowedPrincipals : IAM 정책으로 허용된 모든 주체를 뜻하는 가상 그룹. 이 그룹의 권한이 남아 있으면 Lake Formation 통제가 걸리지 않는다.
• 데이터 필터 : 볼 수 있는 컬럼과 행 조건을 하나로 묶은 Lake Formation 객체.
• LF-Tags : 카탈로그 리소스에 붙여 권한 부여의 기준으로 쓰는 Lake Formation 전용 태그.
• 명명형 권한 : 데이터베이스·테이블 이름을 하나하나 지정해 주는 권한 부여 방식.
• 리소스 링크 : 다른 계정에서 공유받은 테이블을 내 카탈로그에서 가리키는 포인터.
• 데이터 위치 권한 : 특정 S3 경로를 가리키는 카탈로그 리소스를 만들 수 있는 권한.