AWS 시작하면, 처음 접하는 것이 권한 부분이다.
AWS 권한은 대부분 IAM, Organization 두 가지를 통해 통제한다.
1. AWS IAM
AWS 사용자 또는 리소스 기반으로 권한을 부여하고 관리하는 서비스이다.
IAM 으로 권한을 부여, 통제하는 방식은 여러가지가 있으며, 일반적으로 많이 사용하는 방식은 하기와 같다.
{Session policy (세션 정책), Access Control List (ACLs, S3 에 사용) 도 있으나 많이 사용하진 않는듯하다.}
- 자격 증명 기반 정책 (Identity-based policy)
- 리소스 기반 정책 (Resource-based policy)
- 권한 경계 (Permissions boundaries)
- 역할 (Role)
AWS 에서 적용할 수 있는 정책의 종류는 3 가지이며
- AWS 관리형 정책 : AWS 에서 생성하여 관리하는 표준 정책
- AWS 고객 관리형 정책 : 사용자가 임의로 생성, 개인이 관리하는 사용자 정의 정책
- 인라인 정책 : 1명의 사용자에게 하나 또는 여러개의 정책을 할당하는 방식
그리고 AWS 정책에는 묵시적, 명시적 개념이 있다.
- 명시적 : 직접 선언, 지정, 명시하여 적용하는 것 (능동적)
- 묵시적 : 직접 선언, 지정, 명시하지 않아도 기본적(default)로 적용되는 것 (수동적)
- 명시적 거부 : 직접 선언, 지정, 명시하여 거부 권한 적용 (능동적)
- 묵시적 거부 : 직접 선언, 지정, 명시하지 않아도 기본적(default)로 적용되는 거부 권한 (수동적)
묵시적/명시적 거부의 개념이 중요한 이유는, AWS 정책 종류들 간 우선순위가 있기 때문이다. AWS 정책에서 우선순위가 가장 높은 부분은 정책의 명시적 거부여서, 명시적 거부를 하면 다른 정책에서 허용을 해도 모두 차단된다.
묵시적 거부는 정책에서 선언, 명시하지 않았을 경우 정책에서 암묵적으로 거부 권한을 적용하는 것이다. 예를 들어 여러 종류의 정책이 적용되어 있고, 그 어느 정책에서도 특정 권한을 명시, 선언하지 않는다면 그 권한은 묵시적으로 차단된다.
1) 자격 증명 기반 정책 (Identity-based policy)
사용자에게(사용자 기준으로) 리소스에 대한 권한을 부여하는 방식이다. 예를 들어 A 사용자가 B ~ D 리소스에 어떤 행위를 허용할 것인지 정하는 것이다.
- 그룹 또는 사용자 개별로 직접 부여 가능
- 사용자 개별로 정책을 부여하면 추후에 관리가 어려워지므로, 그룹 단위로 정책 부여 권장
- json 으로 생성가능하나, AWS에서 제공하는 기본 정책들이 다양해서 기본 정책만으로도 부족함 없이 사용 가능
2) 리소스 기반 정책 (Resource-based policy)
리소스에게 부여하는 것으로, 특정 리소스에 어느 사용자가, 어떤 행위를 허용할 지 권한을 부여하는 것이다. 예를 들어 A 리소스에 B ~ D 사용자가 어떤 행위를 허용할 것인지 정하는 것이다.
- json 형식으로 따로 권한을 만들어야 사용가능하다.
- 사용자, 그룹에게 부여하는 권한이 아니라, 리소스에게 부여하는 권한
cf) 자격 증명 기반, 리소스 기반 차이점
자격 증명 기반 이든, 리소스 기반 이든 적용하면 결과적으로 리소스에 접근한다.
그러면 개념만 다르고 사실상 같은 것 아닌가 라고 생각할 수 있다. 그러나 AWS 공식 문서에서 자격 증명 기반, 리소스 기반으로 분리를 해놓고 다르다고 하니 차이점은 있다.
- 자격 증명 기반은 사용자, 그룹에게 부여, 리소스 기반은 리소스에게 부여한다.
- 자격 증명 기반은 생성되어 있거나, 임의로 만든 권한을 그룹 또는 사용자에게 부여해야 적용되지만, 리소스 기반 정책은 생성 시 사용자를 지정하므로 생성하면 바로 적용된다.
- 차이점을 쉽게 이해하려면 한명의 사용자에게 여러 리소스의 특정 행위를 허용하는 것, 그리고 하나의 리소스에서 여러 사용자의 특정 행위를 허용하는 것을 생각하면 된다. 전자의 경우는 자격 증명 기반이고, 후자의 경우는 리소스 기반이다.
3) 권한 경계 (Permissions boundaries)
권한 경계는 AWS 사용자에 부여하는 최대 권한이다. 권한 경계로 사용할 정책은 json 만들거나, AWS 에서 제공하는 기본 정책을 사용할 수도 있다. 자격 기반 증명과 교집합 형태로 적용된다. 권한 정책(권한 경계의 정책)에 s3, ec2 만 허용해놓는다면, 다른 자격 기반 정책으로 s3,ec2 외 다른 리소스를 허용하더라도 해당 권한은 적용되지 않는다. 왜냐면 공통으로 겹치는 (교집합)부분이 없어서이다.
그런데 리소스 기반 정책에는 권한 경계와 자격 증명 기반 정책의 묵시적 거부 정책이 적용되지 않으니 참고해야 한다. (위 사진은 AWS 공식 홈페이지 자료이다.) 즉 권한 경계 정책과 자격 증명 기반 정책에서 허용 권한을 명시하지 않아도, 리소스 기반 정책에서 허용한다면 사용이 가능하다. (물론 명시적 거부가 있다면, 리소스 기반 정책으로 허용되지 않는다.)
이외 SCP, Session policy 와, 권한 경계 정책 그리고 자격 기반 증명 정책의 관계는 아래와 같으니 참고하면 유용하다.
SCP, 권한 경계 정책, 자격 기반 증명 정책의 관계
세션 정책, 권한 경계 정책, 자격 기반 증명 정책의 관계
4) 정책의 우선순위
자격 증명 기반 정책, 리소스 기반 정책, 권한 경계, Organization SCP/RCP 등 여러개의 정책, 권한이 적용된다면 우선순위는 어떻게 될까 ? 간략하게 표현하자면
명시적 거부(RCP, SCP, 자격 기반, 리소스 기반 등의 거부 설정) > RCP > SCP > 리소스 기반 정책 > 자격 증명 기반 정책 > 권한 경계 정책 > 세션 정책
의 우선순위를 갖는다.
(AWS 공식 문서에서 제공,
출처 : https://docs.aws.amazon.com/ko_kr/IAM/latest/UserGuide/reference_policies_evaluation-logic_policy-eval-denyallow.html )
위 도식을 보면 어떤 정책이 우선적으로 적용되는지 알 수 있다. 도식의 출처 URL에서 관련 내용을 보면, 몇 가지 특이사항을 알 수 있고, 그 중 하나가 리소스 기반 정책의 적용 방식이다.
- 리소스 기반 정책은 권한 경계, 자격 증명 기반 정책의 묵시적 거부 정책에 영향받지 않는다.
리소스 기반 정책에서 허용을 해놓으면, 권한 경계 정책과 자격 증명 기반 정책에서 명시하지 않아도 차단되지 않고 허용된다. 아래의 그림을 보면 이해하기 쉽다.
5) 역할 (Role)
정책이 영구적 자격 증명 이라면, Role 은 임시적 자격 증명이다. 임시 자격 증명이니 만큼 특정 시간 동안만 권한을 획득한다. 정책의 경우 권한이 필요 없을 경우 직접 회수해야 하지만, Role 은 설정된 시간 후에 권한이 자동 회수 된다. 설령 Role 을 부여받은 계정의 권한을 비인가자가 갖더라도, 특정 시간이 지나면 Role 의 권한이 회수 되므로 비교적 안전하다.
| 정책 | 역할 |
|---|---|
| 사용자 또는 그룹에게 부여 | 역할을 부여받은 모든 대상 |
| 영구적 자격 증명 | 임시, 일시적 자격 증명 |
| 정책 부여받은 동안 권한 유효 | 특정시간 동안만 권한 유효 |
2. AWS Organization
IAM 에서는 개인 사용자, 그룹, 리소스 별로 정책을 적용한다. 그러나 대상에게 직접적으로 정책을 적용하는 것 보다, 조직을 만들어 조직별로 정책을 적용하면 더욱 효율적으로 권한 관리를 할 수 있다. 그래서 나온 것이 AWS Organization 이다.
사용자가 적으면 관리가 쉽지만, 사용자가 많아지면 IAM 그룹으로 관리하기 어렵다. 이럴 때 AWS Oragnization을 유용하게 쓸 수 있다. 조직 단위로 계층활 할 수 있는 것외에, 계정 단위로 조직에 추가, 관리하고 필요 시 다른 사용자의 계정을 초대할 수 있다. (관리자가 생성하지 않은 다른 사람의 계정 추가 가능)
AWS Organization 의 장점, IAM 과의 차이점은 다음과 같다.
- OU(단위 조직)을 구성, 계층화하여 OU 별로 각각 다른 권한을 부여할 수 있다.
(IAM 그룹은 계층화 불가능하며 벤다이어그램 처럼 영역만 정의, 그룹에 그룹을 포함시킬 수 없으므로.)
- 조직 내 계정에 부과되는 요금 통합 관리 (통합 청구)
- 조직 내 계정들에 대한 로그를 통합 수집 및 분석하고 다른 AWS 보안 서비스와 연동 가능
- 조직 내 계정들 끼리 리소스 공유
- IAM 은 사용자 단위로 작업 수행을, Organization 은 계정 단위로 작업을 수행하고 자신이 직접 만들지 않은 다른 사람의 계정을 초대할 수 있다.
1) 단위 조직 (OU)
단위 조직이란, Organization 에서 컨트롤(정책 부여) 할 수 있는 최소 조직 단위이다. OU 에는 사용자, OU 를 포함시킬 수 있다. 단위 조직안에 단위 조직을 포함시켜서 계층화가 가능하다. IAM 과 구분되는 가장 큰 차이점이라 볼 수 있다.
OU에 포함되어 구성되는 계정의 종류는 management account(관리자 계정), account(일반 계정) 이다.
- management account (관리자 계정) : OU를 만든 계정이며 다른 계정을 OU에 초대하거나 삭제할 수 있다. 단 하나의 마스터/루트 계정이 존재하고, SCP 의 영향을 받지 않는다.
- account (일반 계정) : 관리자가 생성하거나, 초대받은 AWS 일반 계정이다.
2) 서비스 제어 정책 (SCP)
OU(단위 조직), ACCOUNT(계정)에게 서비스 권한을 부여하는 정책이다. OU, ACCOUNT 에게 특정 서비스의 허용 권한, 거부 권한을 적용할 수 있다. SCP 적용 시 최상위 ROOT 계정에서 하위의 OU, 그리고 OU 에 속한 계정까지 SCP 가 상속된다.
OU 에 적용되는 SCP 의 상속개념은 위와 같다.
위 표는 상속개념을 나타낸 조직도에서, SCP 를 적용했을 때 계정에 최종 적용되는 권한의 예시이다. SCP는 교집합처럼 적용이 된다. 거부 권한의 경우 없어지지 않고 마지막 계층의 계정까지 상속된다. (허용 권한이 있어도 거부 권한이 우선되므로, 동일한 서비스에 대해 허용과 거부가 같이 있을 시 거부 권한이 적용된다.)
SCP 적용 관련 참고 URL
https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_evaluation.html
3) 리소스 제어 정책 (RCP)
OU, 계정에게 리소스에 대한 권한을 부여하는 정책이다. 리소스에 부여하는 정책이지만, 실제로 정책을 부여할 수 있는 리소스 대상은 많지않다. RCP 를 사용할 수 있는 리소스는 아래와 같다. (아마도 출시 된지 얼마 안된 서비스라 그런거 같다.)
- Amazon S3
- AWS Security Token Service
- AWS Key Management Service
- Amazon SQS
- AWS Secrets Manager
AWS 에서 기본으로 제공하는 RCP 는 RCPFullAWSAccess 이며, 이 외 나머지는 JSON 으로 직접 생성해야 한다.(RCPFullAWSAccess 는 모든 리소스에 대한 권한을 허용하는 정책) 그리고 RCP 는 RCPFullAWSAccess 정책에서만 ALLOW (허용 권한)을 쓸 수 있고, 그 외 JSON 으로 RCP 생성 시 ALLOW(허용) 권한을 사용할 수 없고, DENY(거부 권한)만 사용할 수 있다.
SCP 와 비슷하게 관리자 계정의 리소스에 영향을 주지 않으니 참고하자
RCP 는 출시된지 얼마 안되서 관련자료가 많지 않지만, 다행히도(?) AWS에서 관련 개념을 잘 정리해놓았으니 참고 하면 좋다.
