ID, 리소스, 경계

개발자를 위한 AWS 보안 활용

Rahul Singh

Technical Product Manager

어떤 정책이 우선할까요?

아무것도 바꾸지 않는 수정

  • 1장: 명시적 거부, 또는 허용 없음
  • 이번 장: 세 번째 원인

세 개의 정책 검사 스택을 만나는 요청, 결정이 내려질 지점에 물음표가 표시되어 있다.

개발자를 위한 AWS 보안 활용

어떤 정책이 우선할까요?

최대 세 개 계층

  1. 호출자에 대한 ID 정책
  2. 리소스에 대한 리소스 정책
  3. 상위 경계, 권한을 빼기만 함

같은 계정 내에서는 둘 중 하나만 허용해도 충분합니다

만나는 계층 중 하나라도 거부하면 거부됩니다

요청이 위에서 아래로 ID 정책, 리소스 정책, 권한 경계 세 검사를 순서대로 거쳐 허용 결과에 도달한다.

개발자를 위한 AWS 보안 활용

정책이 존재할 수 있는 두 위치

ID 기반 정책

  • 호출자에 연결
  • 해당 ID가 할 수 있는 작업
  • 착용하는 출입증

상단의 역할이 ID 기반 정책을 가지고 있고, 아래쪽에는 같은 요청의 리소스 측을 위한 공간이 있다.

개발자를 위한 AWS 보안 활용

정책이 존재할 수 있는 두 위치

ID 기반 정책

  • 호출자에 연결
  • 해당 ID가 할 수 있는 작업
  • 착용하는 출입증

리소스 기반 정책

  • 리소스에 연결
  • 누가 접근할 수 있는지
  • 교차 계정 호출자에게 필요

상단의 역할이 ID 기반 정책을, 아래쪽 S3 버킷이 리소스 기반 정책을 가지며, 요청이 그 사이를 아래로 이동한다.

개발자를 위한 AWS 보안 활용

사용자를 위한 관리, 또는 사용자에 의한 관리

ID 기반 정책의 두 종류

  • AWS 관리형: AWS가 소유
  • 고객 관리형: 사용자가 소유

두 개의 카드가 쌓여 AWS가 소유하고 기본적으로 범위가 넓은 AWS 관리형 정책과, 사용자가 소유하고 작업에 맞춰 범위가 제한된 고객 관리형 정책을 비교한다.

개발자를 위한 AWS 보안 활용

사용자를 위한 관리, 또는 사용자에 의한 관리

ID 기반 정책의 두 종류

  • AWS 관리형: AWS가 소유
  • 고객 관리형: 사용자가 소유

 

편의성 또는 정밀성

  • AWS 관리형: 빠르게 진행
  • 고객 관리형: 최소 권한

두 개의 카드가 쌓여 AWS가 소유하고 기본적으로 범위가 넓은 AWS 관리형 정책과, 사용자가 소유하고 작업에 맞춰 범위가 제한된 고객 관리형 정책을 비교한다.

개발자를 위한 AWS 보안 활용

경계는 정책이 부여하는 권한을 제한합니다

계정이 경계를 연결하는 이유

  • 개발자가 역할을 만들어도 아무도 권한을 상승시킬 수 없음

권한 경계

  • 정책이 부여할 수 있는 권한의 상한선
  • 유효 권한: 둘 다 허용해야 적용

ID 정책이 부여한 세 가지 권한이 S3 작업만 허용하는 권한 경계로 전달되며, iam:CreateUser 권한은 차단되고 나머지 두 권한은 아래의 유효 권한으로 계속 전달된다.

개발자를 위한 AWS 보안 활용

경계는 정책이 부여하는 권한을 제한합니다

계정이 경계를 연결하는 이유

  • 개발자가 역할을 만들어도 아무도 권한을 상승시킬 수 없음

권한 경계

  • 정책이 부여할 수 있는 권한의 상한선
  • 유효 권한: 둘 다 허용해야 적용

iam:CreateUser가 아무 효과도 없었던 이유

  • 권한을 빼기만 할 뿐 부여하지 않음

ID 정책이 부여한 세 가지 권한이 S3 작업만 허용하는 권한 경계로 전달되며, iam:CreateUser 권한은 차단되고 나머지 두 권한은 아래의 유효 권한으로 계속 전달된다.

개발자를 위한 AWS 보안 활용

경계는 정책이 부여하는 권한을 제한합니다

계정이 경계를 연결하는 이유

  • 개발자가 역할을 만들어도 아무도 권한을 상승시킬 수 없음

권한 경계

  • 정책이 부여할 수 있는 권한의 상한선
  • 유효 권한: 둘 다 허용해야 적용

iam:CreateUser가 아무 효과도 없었던 이유

  • 권한을 빼기만 할 뿐 부여하지 않음

세션 정책: 하나의 AssumeRole 세션

ID 정책이 부여한 세 가지 권한이 S3 작업만 허용하는 권한 경계로 전달되며, iam:CreateUser 권한은 차단되고 나머지 두 권한은 아래의 유효 권한으로 계속 전달된다.

개발자를 위한 AWS 보안 활용

조건은 허용 범위를 좁힙니다

조건 키

  • 요청의 컨텍스트에 따라 허용 범위를 좁힘

  • aws:SourceIp: 요청이 들어온 네트워크

S3 객체를 읽기 위한 허용이 소스 네트워크 키와 호출자 태그 키를 나열한 조건 영역을 거쳐, 컨텍스트가 일치하면 허용 경로로, 일치하지 않으면 거부 경로로 나뉜다.

개발자를 위한 AWS 보안 활용

조건은 허용 범위를 좁힙니다

조건 키

  • 요청의 컨텍스트에 따라 허용 범위를 좁힘

  • aws:SourceIp: 요청이 들어온 네트워크

  • aws:PrincipalTag: 호출자에 지정된 태그

ABAC: 속성 기반 접근 제어

  • 하나의 정책, 여러 주체

S3 객체를 읽기 위한 허용이 소스 네트워크 키와 호출자 태그 키를 나열한 조건 영역을 거쳐, 컨텍스트가 일치하면 허용 경로로, 일치하지 않으면 거부 경로로 나뉜다.

개발자를 위한 AWS 보안 활용

테이블 하나, 테넌트는 한 번에 하나씩

하나의 공유 테이블

  • DynamoDB, 테넌트당 파티션 키 하나
  • 그 자체만으로는 격리가 아님

테넌트 A 호출자가 선행 키 조건을 거쳐 공유 DynamoDB 테이블에 접근하면, 테넌트 A의 행은 반환되고 테넌트 B와 테넌트 C의 행은 차단된다.

개발자를 위한 AWS 보안 활용

테이블 하나, 테넌트는 한 번에 하나씩

"Condition": {
  "ForAllValues:StringEquals": {
    "dynamodb:LeadingKeys": ["${aws:PrincipalTag/tenant}"]
  }
}

하나의 공유 테이블

  • DynamoDB, 테넌트당 파티션 키 하나
  • 그 자체만으로는 격리가 아님

조건 하나로 범위를 좁힘

  • ForAllValues: 제공된 모든 키가 일치해야 함
개발자를 위한 AWS 보안 활용

테이블 하나, 테넌트는 한 번에 하나씩

"Action": ["dynamodb:Query", "dynamodb:GetItem", "dynamodb:Scan"],
"Condition": {
  "ForAllValues:StringEquals": {
    "dynamodb:LeadingKeys": ["${aws:PrincipalTag/tenant}"]
  }
}

하나의 공유 테이블

  • DynamoDB, 테넌트당 파티션 키 하나
  • 그 자체만으로는 격리가 아님

조건 하나로 범위를 좁힘

  • ForAllValues: 제공된 모든 키가 일치해야 함
남는 허점: 모든 요청이 파티션을 지정하지는 않음
  • dynamodb:Scan은 아무것도 지정하지 않으므로 실패할 수 없음
개발자를 위한 AWS 보안 활용

연습해 봅시다!

개발자를 위한 AWS 보안 활용

Preparing Video For Download...