[클라우드] IAM Policy 알아보기

반응형

AWS의 엑세스 접근 제어는 우선 정책을 만들고 이 정책을 IAM 자격 증명(사용자, 그룹, Role)에 적용 하거나 리소스에 연결하여 접근을 제어 하는 구조 입니다. 이런 정책은 IAM의 보안 주체(사용자, Role)가 AWS콘솔, CLI, API에서 요청을 수행할때 정책을 검토하게 됩니다. 
 
정책의 유형을 보면 아래와 같습니다. 
 
정책 유형

자격 증명 기반 정책, 리소스 기반 정책, IAM 권한 경계, AWS Organizations SCP(서비스 제어 정책), ACL(액세스 제어 목록) 및 세션 정책의 6가지 정책 유형을 지원하고 이러한 정책의 검토는 요청이 허용 또는 거부되기 전에 수행됩니다.

 

1)자격 증명 기반

IAM 정책이라고도 하는 자격 증명 기반 정책은 IAM 자격 증명(사용자, 사용자가 속한 그룹 또는 역할)에 연결되는 관리형 인라인 정책입니다.

• IAM 보안 주체 권한에 영향)

 

2)리소스 기반

리소스에 연결된 인라인 정책입니다. 리소스 기반 정책의 가장 일반적인 예는 Amazon S3 버킷 정책 및 IAM 역할 신뢰 정책입니다. 리소스 기반 정책은 정책에 지정된 보안 주체에 권한을 부여하므로 보안 주체 정책 요소가 필요합니다. 

 

• 보안 주체 또는 계정(동일 계정 또는 다른 계정)에 권한 부여

예를 들면 아래의 리소스 기반 정책은 Amazon S3 버킷에 연결됩니다. 이 정책에 따라 IAM 사용자 carlossalzar만이 이 버킷에 액세스할 수 있습니다.

3) 권한경계

권한 경계는 자격 증명 기반 정책에서 IAM 엔터티에 부여할 수 있는 최대 권한을 설정합니다. 엔터티는 해당하는 자격 증명 기반 정책 및 권한 경계 모두에서 허용되는 작업만 수행할 수 있습니다. 사용자 또는 역할을 보안 주체로 지정하는 리소스 기반 정책은 권한 경계의 제한을 받지 않습니다.

 

• 연결된 IAM 엔터티에 대한 권한 제한

예를 들어 IAM 사용자 중 한 명이 Amazon S3, Amazon CloudWatch 및 Amazon EC2만 관리할 수 있도록 허용해야 한다고 가정하겠습니다. 이 규칙을 적용하려면 고객 관리형 정책을 사용하여 사용자의 권한 경계를 설정하면 됩니다. 그런 다음, 아래의 condition 블록을 IAM 사용자의 정책에 추가합니다. 사용자가 작업을 수행하도록 허용하는 권한 정책이 있다고 해도 사용자는 IAM을 포함한 다른 서비스에서는 절대 작업을 수행할 수 없습니다.

4)AWS Organizations SCP
AWS Organizations 는 AWS 계정을 그룹화하고 중앙에서 관리할 수 있는 서비스입니다. 조직에서 모든 기능을 활성화할 경우 SCP를 임의의 계정 또는 모든 계정에 적용할 수 있습니다. SCP는 계정 또는 OU(조직 구성 단위)라고 하는 계정 그룹의 최대 권한을 지정합니다. 

• AWS 계정 루트 사용자를 포함하여 AWS 계정의 엔터티에 대한 권한 제한

 
 
5)ACL
ACL을 사용하여 ACL이 연결된 리소스에 액세스할 수 있는 다른 계정의 접근을 제어할 수 잇고  ACL은 Amazon S3 버킷과 객체에서 사용 가능 합니다.  ACL은 지정된 보안 주체에 권한을 부여하는 교차 계정 권한 정책입니다. ACL은 동일 계정 내 엔터티에 권한을 부여할 수 없습니다.
 
6)세션 정책
세션 정책은 사용자가 역할을 맡을 때 세션에 전달하는 인라인 권한 정책입니다. 세션에 대한 권한은 세션을 생성하는 데 사용되는 IAM 엔터티(사용자 또는 역할)에 대한 자격 증명 기반 정책과 세션 정책의 교집합입니다. 권한을 리소스 기반 정책에서 가져올 수도 있습니다. 세션 정책은 역할이나 사용자의 자격 증명 기반 정책을 통해 세션에 부여하는 권한을 제한합니다. 세션 정책에 대한 자세한 내용은 다음 단원에서 다루겠습니다.
 

• 할당된 역할 및 페더레이션 사용자에 대한 권한 제한

 

2. 가드레일 vs 권한 부여

위에서 살펴본것처럼 권한을 제어 하는 정책도 있고 접근 권한을 부여하는데 사용되는 정책도 있습니다. 이들 정책을 조합하여 사용하면 보안 체계를 좀더 강화 시킬수 있습니다. 

명시적 거부와 묵시적 거부

명시적 거부는 적용 가능한 정책에 Deny 문이 포함되는 경우 요청은 명시적으로 거부되고 요청에 적용되는 정책에 Allow 문과 Deny 문이 포함된 경우 Deny 문이 Allow 문보다 우선합니다. 따라서 요청이 명시적으로 거부됩니다.

 

묵시적 거부는 적용 가능한 Deny 문이 없지만 적용 가능한 Allow 문도 없을 때 발생합니다. IAM 사용자, 역할 또는 페더레이션 사용자의 액세스 권한이 기본적으로 거부되기 때문에 이들이 작업을 수행할 수 있도록 명시적으로 허용해야 합니다. 그렇지 않으면 묵시적으로 액세스가 거부됩니다.

 

아래 그림은 보안 주체를 인증할때의 순서를 보여 줍니다. 

계정 내에서 서비스 제어 정책과 IAM 정책 또는 리소스 기반 정책이 필요합니다. 모든 계정에서 서비스 제어 정책과 IAM 정책 및 리소스 기반 정책이 필요합니다.
 
3. 보안 주체
보안 주체는 AWS 리소스에서 작업을 요청할 수 있는 사람, 역할 또는 애플리케이션입니다. 보안 주체는 AWS에 요청할 수 있는 AWS 계정 루트 사용자 또는 IAM 엔터티로 인증됩니다. 호출이 인증되면 IAM은 보안 주체와 호출 자체에 대한 컨텍스트를 수집합니다. 다음은 인증 프로세스에서 사용할 수 있는 컨텍스트의 예입니다.

• 보안 주체 태그 – arn:aws:iam::<AWS-account-ID>:user/<username>
• Principal tags – dept=123, project=blue
• 조건 키 – aws:UserID, aws:SourceIP, aws:PrincipalArn, aws:PrincipalAccount, etc.

보안 주체로는 아래와 같은 객체들이 있습니다. 
 
1)AWS계정

정책에서 AWS 계정 식별자를 보안 주체로 사용하는 것은 계정에 권한을 위임하는 것입니다. 해당 계정 내에서, 해당 계정의 IAM 사용자 및 역할을 포함한 모든 자격 증명에 정책 명령문의 권한을 부여할 수 있습니다. AWS 계정을 지정할 때 Amazon 리소스 이름(ARN) arn:aws:iam::AWS-account-ID:root 또는 aws: prefix 접두사 뒤에 계정 ID가 오는 단축된 양식을 사용할 수 있습니다.

 

예를 들어 계정 ID가 123456789012인 경우 다음 방법 중 하나를 사용하여 Principal 요소에서 해당 계정을 지정할 수 있습니다.

 
2)IAM 사용자

다음 예제와 같이 개별 IAM 사용자를 보안 주체로 지정할 수 있습니다. 요소에서 둘 이상의 보안 주체를 지정할 때 보안 주체마다 권한을 부여합니다. 한 번에 하나의 보안 주체로 인증되기 때문에 이것은 논리적 AND가 아닌 논리적 OR입니다. Principal 요소에서 사용자 이름은 대/소문자를 구분합니다. Principal 요소에서 사용자를 지정할 때 "모든 사용자"를 의미하는 와일드카드(*)를 사용할 수 없습니다. 보안 주체는 항상 특정 사용자가 되어야 하기 때문입니다.

 
3)페더레이션 사용자

AWS 외부에서 사용자 자격 증명을 이미 관리하고 있다면 AWS 계정에서 IAM 사용자를 생성하는 대신 IAM 자격 증명 공급자를 사용할 수 있습니다. 자격 증명 공급자(IdP)를 사용하면 AWS 외부에서 사용자 자격 증명을 관리하고, 이러한 외부 사용자 자격 증명에 계정의 AWS 리소스를 사용할 수 있는 권한을 부여할 수 있습니다. IAM은 Login with Amazon, Amazon Cognito, 페이스북 또는 구글과 같은 SAML 기반 IdP 및 웹 자격 증명 공급자를 지원합니다. 

 

다음은 페더레이션 웹 자격 증명 사용자 및 페더레이션 SAML 사용자에게 사용되는 Principal 요소의 예입니다.

 
4)IAM Role

보통은 AWS 리소스에 대한 액세스 권한이 없는 사용자, 애플리케이션 또는 서비스에 역할을 사용해 액세스 권한을 위임할 수 있습니다. 예를 들어 AWS 계정 사용자에게 평상시에는 액세스 권한이 없는 리소스에 대한 액세스 권한을 부여하거나, 한 AWS 계정 사용자에게 다른 계정의 리소스에 대한 액세스 권한을 부여해야 할 경우가 있습니다. 역할을 수임하는 엔터티는 원래 권한을 상실하고, 수임하는 역할과 연결된 액세스 권한을 얻습니다.

 

※본 포스팅은 www.amazon.com을  을 참고로 작성 되었습니다.