Overview
AWS IAM에 대해서 공부해보려고 한다.
AWS IAM이란?
AWS Identity and Access Management(IAM)는 사용자의 AWS 리소스에 대한 액세스를 안전하게 제어하는 데 도움이 되는 서비스이다. IAM을 사용하면 AWS 사용자 및 그룹을 생성 및 관리하고 권한을 사용하여 AWS 리소스에 대한 액세스 권한을 부여하거나 거부할 수 있다.
AWS IAM 작동방식
IAM의 작동 방식은 아래의 순서를 거친다.
보안주체(Principal) - 요청(Request) - 인증(Authentication) - 인가(Authorization)
- 작업 또는 연산(Action or Operation) - 리소스(Resource)
보안주체(Principal)
보안 주체는 AWS 리소스에 대한 조치 또는 작업을 수행하도록 요청하는 AWS의 엔터티(사용자, 서비스 또는 역할)이다. 주체는 보안 자격 증명(예: 액세스 키 ID 및 보안 액세스 키)을 사용하거나 임시 보안 자격 증명으로 IAM 역할을 가정하여 인증된다.
요청(Request)
사용자, 서비스 또는 애플리케이션이 AWS 리소스에 대한 조치 또는 작업을 수행하도록 요청한다. 요청자는 보안 자격 증명(예: 액세스 키 ID 및 보안 액세스 키)을 사용하거나 임시 보안 자격 증명으로 IAM 역할을 가정하여 인증된다.
인증(Authentication)
AWS IAM은 보안 주체와 연결된 권한을 확인합니다. 이러한 권한은 사용자, 그룹 또는 역할에 연결된 IAM 정책에서 정의된다. 정책은 어떤 조건에서 어떤 리소스에 대해 어떤 작업/작업이 허용되거나 거부되는지 지정하는 JSON 문서이다.
경우에 따라 IAM은 사용자 정책, 그룹 정책 또는 리소스 기반 정책(예: S3 버킷 정책)과 같은 여러 정책을 평가해야 할 수 있다.
인가(Authorization)
인가는 보안 주체와 연결된 권한을 정의하는 정책을 기반으로 한다. 정책은 사용자, 그룹 또는 역할에 연결할 수 있다.
보안 주체가 AWS 리소스에 대한 작업을 수행하도록 요청하면 IAM은 연결된 정책을 평가하여 요청이 허용되는지 또는 거부되는지 결정한다. 최종 승인 결정은 이러한 정책의 조합을 기반으로 한다. 액세스를 명시적으로 거부하는 정책이 있으면 다른 정책에서 허용하더라도 요청이 거부된다.
작업 또는 연산(Action or Operation)
요청 엔터티가 평가된 정책을 기반으로 요청된 작업 또는 연산을 수행할 권한이 있는 경우 IAM은 요청을 진행하도록 허용한다. 그렇지 않으면 IAM이 요청을 거부하고 작업이 수행되지 않는다.
리소스(Resource)
요청이 IAM에 의해 승인된 경우 지정된 AWS 리소스에서 작업이 수행된다(예: S3 버킷에서 데이터 읽기, EC2 인스턴스 시작 등).
요약하면 AWS IAM은 AWS 리소스에 대한 조치 또는 작업을 수행하기 위한 요청을 인증하고 권한을 부여(인가)하는 방식으로 작동한다. 이 프로세스는 요청으로 시작되고 IAM이 연결된 정책의 권한을 확인한다. 권한이 있는 경우 요청된 작업이 지정된 리소스에서 수행된다.
AWS IAM 개요
사용자(Users)
AWS IAM에서 AWS 리소스에 액세스해야 하는 사람 또는 애플리케이션에 대해 개별 사용자를 생성할 수 있다.
각 사용자는 액세스 키 ID 및 보안 액세스 키와 같은 고유한 보안 자격 증명 세트를 가지고 있어 AWS 서비스를 인증하고 상호 작용할 수 있습니다. 추가 보안을 위해 다단계 인증(MFA)을 활성화할 수도 있다.
사용자 그룹(Groups)
IAM 사용자를 그룹으로 구성하여 권한을 더 잘 관리할 수 있다. 그룹은 동일한 권한 집합을 공유하는 사용자 모음이다. 그룹에 권한을 적용하면 해당 그룹 내의 모든 사용자가 해당 권한을 상속한다. 이렇게 하면 사용자 수가 증가함에 따라 권한을 보다 쉽게 관리하고 유지할 수 있다.
역할(Roles)
IAM 역할은 리소스에 액세스해야 하는 사용자 또는 서비스에 권한을 부여하는 또 다른 방법이다. 역할은 일련의 권한이 있는 IAM 엔터티이지만 자체 보안 자격 증명 집합은 없다. 대신 사용자 또는 서비스는 해당 역할과 관련된 권한을 일시적으로 얻기 위해 역할을 맡을 수 있다. 역할은 AWS 서비스 또는 다른 AWS 계정의 사용자에게 권한을 부여하거나 사용자가 여러 보안 자격 증명 세트를 관리할 필요 없이 다른 권한이 있는 역할 간에 전환할 수 있도록 하는 데 유용하다.
정책(Policies)
정책은 사용자, 그룹 또는 역할에 대한 권한을 정의하는 JSON 문서이다. 정책은 작업이 허용되거나 거부되는 작업, 리소스 및 조건을 지정한다. 사용자 지정 정책을 생성하거나 AWS에서 유지 관리하는 사전 정의된 정책인 AWS 관리형 정책을 사용할 수 있다.
자격 증명 공급자(Identity Federation)
IAM은 또한 자격 증명 연동을 지원하므로 회사 디렉터리의 사용자, 소셜 미디어 계정 또는 기타 자격 증명 공급자와 같이 이미 AWS 외부에 자격 증명이 있는 사용자에게 AWS 리소스에 대한 액세스 권한을 부여할 수 있다. 이를 통해 각 개인에 대해 별도의 IAM 사용자를 생성하지 않고도 중앙에서 사용자 액세스를 관리할 수 있다.
AWS IAM 역할이란?
IAM 역할
IAM 역할은 다양한 엔터티가 AWS 리소스에 액세스할 수 있는 권한을 부여하기 위해 생성할 수 있는 AWS 자격 증명이다.
역할 생성 시 신뢰할 수 있는 엔터티 유형
AWS 서비스(AWS Service)
역할을 생성하여 AWS 서비스(ex: EC2, Lambda)에 대신 리소스에 액세스할 수 있는 권한을 부여할 수 있다. 이는 EC2 인스턴스가 S3 버킷에 액세스하도록 허용하는 것과 같은 작업에 유용하다.
Trust an AWS service (Amazon EC2) - Example code
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "ec2.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
AWS 계정(AWS Account)
역할을 사용하여 교차 계정 액세스 권한을 부여하여 다른 AWS 계정의 IAM 사용자가 계정의 리소스에 액세스할 수 있다.
Trust another AWS account - Example code
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::<OTHER_AWS_ACCOUNT_ID>:root"
},
"Action": "sts:AssumeRole"
}
]
}
웹 자격 증명 연동
IAM 역할을 사용하여 웹 자격 증명 공급자(ex: Amazon, Facebook 또는 Google)가 인증한 사용자에게 AWS 리소스에 대한 액세스 권한을 부여할 수 있다. 이렇게 하면 IAM 사용자를 생성할 필요 없이 외부 사용자가 특정 권한이 있는 역할을 맡을 수 있다.
Trust an OpenID Connect (OIDC) identity provider - Example code
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::<AWS_ACCOUNT_ID>:oidc-provider/<PROVIDER_DOMAIN>"
},
"Action": "sts:AssumeRoleWithWebIdentity"
}
]
}
SAML 2.0 연동
역할을 사용하여 AD FS(Active Directory Federation Services)와 같은 SAML 2.0 자격 증명 공급자(IdP)에 의해 인증된 사용자에게 AWS 리소스에 대한 액세스 권한을 부여할 수 있다. 이를 통해 기존 자격 증명 관리 시스템을 통해 AWS 리소스에 대한 사용자 액세스를 관리할 수 있다.
Trust a SAML 2.0-based identity provider - Example code
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::<AWS_ACCOUNT_ID>:saml-provider/<PROVIDER_NAME>"
},
"Action": "sts:AssumeRoleWithSAML"
}
]
}
사용자 지정 신뢰 정책
신뢰 정책은 역할을 맡을 수 있는 엔터티를 정의한다. 사용자 지정 신뢰 정책을 생성하여 특정 IP 주소에 대한 액세스 제한 또는 다단계 인증(MFA) 요구와 같이 역할을 수임할 수 있는 조건을 지정할 수 있다.
AWS IAM 정책이란?
IAM 정책
IAM 정책은 하나 이상의 권한을 정의하는 JSON 문서이다. 특정 AWS 리소스에 대해 허용되거나 거부된 작업을 지정한다.
IAM JSON 정책요소
버전(Version)
이 요소는 선택 사항이며 정책 언어 버전을 나타낸다. 현재 버전은 "2012-10-17"이다.
선언문(Statement)
선언문은 정책의 핵심 요소이다. 각각 단일 권한을 설명하는 개별 문의 배열이다. 명령문에는 여러 요소가 있다.
효과(Effect)
명령문이 지정된 작업을 허용하거나 거부하는지 여부를 지정한다. 가능한 값은 "Allow" 또는 "Deny"이다.
보안주체(Principal)
리소스 기반 정책의 "Principal" 요소는 리소스에 대한 액세스가 허용되거나 거부되는 IAM 자격 증명(사용자, 그룹, 역할 또는 AWS 계정)을 정의한다. 보안 주체는 Amazon 리소스 이름(ARN), 계정 ID 또는 사전 정의된 AWS 식별자를 사용하여 지정할 수 있다.
작업(Action)
정책이 허용하거나 거부하는 작업 또는 서비스 작업을 나열합니다. 작업은 서비스 접두사 다음에 작업을 사용하여 지정된다(ex: "s3:PutObject").
리소스(Resource)
작업이 적용되는 리소스를 나타낸다. 리소스는 AWS 리소스를 고유하게 식별하는 Amazon 리소스 이름(ARN)을 사용하여 지정된다. 와일드카드()를 사용하여 여러 리소스 또는 리소스 유형을 지정할 수 있다.
예를 들어 "arn:aws:s3:::example-bucket/"은 "example-bucket" 내의 모든 객체에 적용된다.
조건(Condition) - Option
명령문에 지정된 작업에 대한 추가 제약 조건을 제공한다. 조건은 날짜, IP 주소 또는 특정 태그와 같은 속성을 기반으로 할 수 있다. 조건은 날짜, IP 주소, 리소스 태그 또는 AWS 서비스 고유의 기타 속성과 같은 다양한 속성을 기반으로 할 수 있다. 조건은 조건 연산자(예: "StringEquals", "IpAddress", "DateGreaterThan") 및 관련 키/값을 사용하여 지정된다.
IAM 정책 예시
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::somaz-bucket"
]
},
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:PutObject"
],
"Resource": [
"arn:aws:s3:::somaz-bucket/*"
],
"Condition": {
"StringEquals": {
"aws:RequestedRegion": "ap-northeast-2"
}
}
},
{
"Effect": "Deny",
"Action": [
"s3:DeleteObject"
],
"Resource": [
"arn:aws:s3:::somaz-bucket/*"
],
"Condition": {
"Bool": {
"aws:MultiFactorAuthPresent": "false"
}
}
}
]
}- 첫 번째 명령문은 사용자가 "somaz-bucket"의 내용을 나열할 수 있도록 한다.
- 두 번째 명령문은 요청된 지역이 "ap-northeast-2"인 경우에만 사용자가 "somaz-bucket"에 객체를 가져오고 넣을 수 있도록 허용한다.
- 세 번째 명령문은 MFA(Multi-Factor Authentication)가 없는 경우 사용자가 "somaz-bucket"에서 개체를 삭제할 수 있는 기능을 거부한다.
IAM 정책 유형
아래와 같이 6개의 정책유형이 있고 가장 자주 사용되는 것부터 나열하였다.
자격 증명 기반 정책(Identity-based policies) - ID 기반 정책
IAM 사용자, 그룹 또는 역할에 연결된 정책이다. IAM 자격 증명이 수행할 수 있는 작업, 액세스할 수 있는 리소스 및 관련 조건을 제어한 자격 증명 기반 정책은 두 가지 하위 유형으로 더 나눌 수 있다.
- 관리형 정책
- AWS 관리형 정책(AWS Managed Policies)
- 고객 관리형 정책(Customer Managed Policies)
- 인라인 정책(Inline Policies)
리소스 기반 정책(Resource-based policies)
Amazon S3 버킷, Amazon SQS 대기열 또는 AWS KMS 키와 같은 AWS 리소스에 연결된 정책이다. 리소스 기반 정책은 리소스에 액세스할 수 있는 IAM 자격 증명과 수행할 수 있는 작업을 정의한다. 이러한 정책은 자격 증명 기반 정책을 수정하지 않고 특정 리소스에 대한 교차 계정 액세스 권한을 부여해야 할 때 유용하게 사용한다.
권한 경계(Permissions boundaries)
권한 경계는 IAM 엔터티(사용자 또는 역할)가 가질 수 있는 최대 권한을 설정하는 데 사용되는 고급 IAM 기능이다. IAM 엔터티에 연결하는 정책이며 경계 역할을 하여 더 많은 허용 정책이 연결되어 있더라도 엔터티에 부여된 권한을 제한한다. 권한 경계는 부여할 수 있는 최대 권한에 대한 제어를 유지하면서 다른 사용자에게 IAM 권한 관리를 위임하려는 경우에 유용하다.
조직 SCP[Organizations SCPs (Service Control Policies)]
SCP는 조직 또는 특정 조직 단위(OU) 내의 모든 계정에 대한 권한을 정의하기 위해 AWS Organizations에서 사용되는 정책 유형이다. SCP는 가드레일 역할을 하여 조직 내에서 액세스할 수 있는 작업과 리소스를 제한한다. IAM 자격 증명에 더 많은 허용 정책이 연결되어 있어도 마찬가지이다. SCP는 조직 정책 및 액세스 제한이 모든 AWS 계정에서 일관되게 적용되도록 한다.
액세스 제어 목록(ACL) - Access control lists
ACL은 Amazon S3 버킷 및 객체와 같은 특정 AWS 리소스에 대한 액세스를 제어하는 데 사용되는 레거시 정책이다. 여전히 사용할 수 있지만 AWS는 일반적으로 보다 세분화된 액세스 제어 및 관리 용이성을 위해 리소스 기반 정책 또는 자격 증명 기반 정책을 사용할 것을 권장한다.
세션 정책 - Session policies
세션 정책은 역할의 임시 자격 증명 권한을 제한하려는 경우에 사용되는 고급 정책이다. AWS STS를 사용하여 역할을 수임할 때 선택적 세션 정책을 전달하여 역할의 권한 정책에서 부여하는 권한을 추가로 제한할 수 있다. 이렇게 하면 역할 자체보다 액세스가 더 제한된 임시 자격 증명을 생성하여 추가 보안 수준을 제공할 수 있다.
IAM 자격 증명 기반 정책(Identity-based policies) - ID 기반 정책
IAM ID 기반 정책은 AWS 리소스에 액세스하기 위한 권한을 정의하는 데 사용되며 관리형 정책에는 AWS 관리형 정책과 고객 관리형 정책의 두 가지 유형이 있다.
이 두 가지 유형의 관리형 정책 간의 차이점을 살펴보려고 한다.
AWS 관리형 정책(AWS Managed Policies)
AWS에서 생성하고 유지 관리하는 정책이다. 보편적인 사례를 다루고 사용자가 AWS 리소스에 안전하게 액세스하는 데 도움이 되는 특정 권한을 제공한다.
AWS 관리형 정책은 사용자 지정 정책을 생성 및 유지 관리할 필요 없이 권한을 관리하는 더 간단한 방법을 제공하도록 설계되었다.
AWS 관리형 정책의 몇 가지 예
- AmazonS3ReadOnlyAccess: 모든 Amazon S3 버킷에 대한 읽기 전용 액세스 권한을 부여한다.
- AmazonEC2FullAccess: Amazon EC2 리소스에 대한 전체 액세스 권한을 부여한다.
- AWSLambdaFullAccess: AWS Lambda 리소스에 대한 전체 액세스 권한을 부여한다.
- AdministratorAccess : 계정 내의 모든 AWS 리소스 및 서비스에 대한 전체 액세스 권한을 부여하는 강력한 정책이다.
AWS 관리형 정책은 새로운 서비스나 기능이 도입되면 AWS에서 업데이트하므로 수동 개입 없이 정책을 최신 상태로 유지할 수 있다.
그러나 AWS 관리형 정책은 특정 요구 사항이나 사용 사례와 완벽하게 일치하지 않을 수 있다. 이러한 경우 고객 관리형 정책이라고 하는 고유한 사용자 지정 정책을 만들 수 있다.
고객 관리 정책(Customer Managed Policies)
특정 요구 사항에 맞게 만들고 유지 관리하는 정책이다. 고객 관리형 정책을 사용하면 IAM 사용자, 그룹 또는 역할에 부여하는 권한을 완전히 제어할 수 있다. 세분화된 액세스 규칙을 정의하여 조직의 필요에 맞게 권한을 조정할 수 있다.
고객 관리형 정책을 생성할 때 작업, 리소스 및 선택적 조건을 지정하여 정책 문서를 JSON 형식으로 작성해야 한다. 계정 내의 여러 IAM 사용자, 그룹 또는 역할에 고객 관리형 정책을 연결할 수 있다.
인라인 정책
인라인 정책은 단일 IAM 사용자, 그룹 또는 역할에 직접 포함되는 IAM 정책이다. 관리형 정책과 같은 독립형 정책이 아니며 여러 IAM 엔터티에 공유하거나 연결할 수 없다. 인라인 정책은 연결된 특정 사용자, 그룹 또는 역할에 권한을 부여하는 데 사용된다.
사용 사례
인라인 정책은 특정 IAM 사용자, 그룹 또는 역할에 고유한 일회성 권한을 부여해야 하는 상황에서 사용한다. 또한 IAM 엔터티와 해당 정책 간에 엄격한 일대일 관계를 적용하여 정책이 실수로 다른 곳에서 공유되거나 재사용되지 않도록 하려는 경우에도 사용할 수 있다.
리소스 기반 정책(Resource-based policies)
리소스 기반 정책은 Amazon S3 버킷과 같은 리소스에 연결하는 JSON 정책 문서이다.
IAM 리소스 기반 정책은 IAM 엔터티(사용자, 그룹 또는 역할)가 아닌 AWS 리소스에 직접 연결된 액세스 제어 정책 유형이다. 이러한 정책은 허용되는 작업, 해당 작업을 수행할 수 있는 IAM 자격 증명 및 관련 조건을 지정하여 연결된 리소스에 액세스하기 위한 권한을 정의한다.
그리고 사용자 또는 역할의 자격 증명 기반 정책을 수정하지 않고 특정 리소스에 대한 액세스 권한을 부여해야 하는 상황에서 유용하다. 또한 일반적으로 교차 계정 액세스 권한을 부여하여 다른 AWS 계정의 IAM 자격 증명이 리소스에 액세스할 수 있도록 하는 데 사용된다.
리소스 기반 정책을 지원하는 일부 AWS 서비스에는 Amazon S3, Amazon SQS, AWS KMS, AWS Lambda 및 Amazon SNS가 포함된다.
IAM 역할과 리소스 기반 정책의 차이점
IAM 역할은 임시 보안 자격 증명으로 AWS 리소스에 액세스하기 위해 다른 엔터티가 맡을 수 있는 AWS 자격 증명이다.
리소스 기반 정책은 AWS 리소스에 직접 연결된 액세스 제어 정책으로, 자원. 역할은 교차 계정 액세스 및 AWS 서비스 또는 외부 사용자에게 권한 부여와 같은 시나리오에 사용된다.
그리고 IAM 자격 증명의 자격 증명 기반 정책을 수정하지 않고 특정 리소스에 대한 액세스 권한을 부여하는 데 사용됩니다.
권한 정책과 권한 경계
AWS IAM에서는 정책을 사용하여 권한을 제어하고 관리할 수 있다. 권한을 관리할 때 이해해야 하는 두 가지 개념인 권한 정책과 권한 경계가 있다.
권한 정책(Permission Policies)
권한 정책은 IAM 사용자, 그룹 또는 역할에 대한 권한을 정의하는 JSON 문서이다. 이러한 정책은 특정 조건에서 특정 AWS 리소스에 대해 허용되거나 거부되는 작업을 지정한다.
정책은 IAM 사용자, 그룹 또는 역할에 직접 연결하거나 관리형 정책(AWS 관리형 또는 고객 관리형)으로 생성한 다음 여러 IAM 엔터티에 연결할 수 있습니다.
두 가지 기본 유형의 권한 정책이 있다.
- 자격 증명 기반 정책(Identity-based policies)
- IAM 사용자, 그룹 또는 역할에 연결된 정책이며 보안 주체(사용자, 그룹 또는 역할)에 권한을 부여한다. 보안 주체가 리소스 액세스를 요청할 때 권한이 적용된다.
- 리소스 기반 정책(Resource-based policies)
- 특정 AWS 리소스에 연결된 정책이다(ex: S3 버킷 정책 또는 Lambda 함수 정책). 정책에 지정된 보안 주체에 권한을 부여한다. 리소스 기반 정책은 교차 계정 액세스 권한을 부여하거나 AWS 서비스가 리소스에 대해 작동하도록 허용하는 데 사용된다.
권한 경계(Permission Boundaries)
권한 경계는 IAM 사용자 또는 역할에 부여할 수 있는 최대 권한을 제한하는 메커니즘이다. 관리자가 IAM 사용자 및 역할을 생성하거나 관리하는 기능을 다른 사용자에게 무제한 액세스 권한을 부여하지 않고 위임해야 하는 조직에서 특히 유용할 수 있다.
또한 권한 경계를 생성하여 IAM 사용자 또는 역할과 연결할 수 있다. 권한 경계가 있는 사용자가 IAM 엔터티(사용자 또는 역할)를 생성한 후 권한은 권한 경계의 권한과 사용자 또는 역할에 연결된 IAM 정책의 권한의 교집합이다.
권한 경계는 보호 장치 역할을 하여 연결된 정책이 더 광범위한 권한을 부여하더라도 IAM 엔터티의 권한이 경계에 정의된 최대 권한을 초과하지 않도록 한다.
예를 들어 IAM 사용자 및 역할을 생성할 수 있는 관리자가 있지만 Amazon EC2 인스턴스를 생성하거나 삭제할 수 있는 권한을 부여할 수 없도록 하고 싶을 수 있다. "ec2:CreateInstance" 및 "ec2:TerminateInstances" 작업을 거부하고 이를 관리자와 연결하는 권한 경계 정책을 생성할 수 있다. 연결된 정책이 더 광범위한 권한을 부여하더라도 관리자가 생성한 모든 IAM 사용자 또는 역할에 대한 결과 권한은 권한 경계에 의해 제한된다.
마지막으로 권한 정책은 IAM 사용자, 그룹 또는 역할에 부여된 권한을 정의하는 반면 권한 경계는 IAM 사용자 또는 역할에 부여할 수 있는 최대 권한에 대한 제한 역할을 한다. IAM 사용자 또는 역할 생성의 위임이 필요하지만 특정 권한 세트로 제한되어야 하는 시나리오에서 권한을 제어하는 데 유용하다.
조직 SCP[Organizations SCPs (Service Control Policies)]
서비스 제어 정책(SCP)은 조직 또는 특정 조직 단위(OU) 내의 모든 AWS 계정에 대한 권한을 중앙에서 관리하고 제어하기 위해 AWS Organizations에서 사용되는 정책 유형이다.
SCP는 가드레일 역할을 하여 조직 내에서 액세스할 수 있는 작업과 리소스를 제한한다. IAM 자격 증명에 더 많은 허용 정책이 연결되어 있어도 마찬가지이다. SCP는 조직 정책 및 액세스 제한이 모든 AWS 계정에서 일관되게 적용되도록 한다.
SCP의 주요 구성 요소 및 개념
- AWS Organizations
- SCP는 여러 AWS 계정을 중앙에서 관리하고 통합하는 데 도움이 되는 서비스인 AWS Organizations를 사용할 때만 사용할 수 있다. AWS Organizations는 마스터 계정, 멤버 계정 및 OU의 계층 구조로 구성된다.
- 상속(Inheritance)
- SCP는 조직 계층 구조의 여러 수준에서 연결될 수 있다. 루트에 SCP를 연결하면 조직 내의 모든 계정에 적용된다. SCP를 OU에 연결하면 해당 OU 및 하위 OU 내의 모든 계정에 적용된다. SCP는 계층 아래로 상속되며 계정의 유효 권한은 각 수준에 연결된 SCP의 교집합이다.
- 권한 경계(Permissions boundaries)
- SCP는 조직 내 계정에 대한 권한 경계 역할을 한다. 자체적으로 권한을 부여하지는 않지만 계정 내 IAM 엔터티에 부여할 수 있는 최대 권한을 정의한다. IAM 엔터티의 유효 권한은 엔터티의 자격 증명 기반 또는 리소스 기반 정책과 계정에 적용된 SCP의 교차점이다.
- 정책 구조(Policy structure)
- SCP는 "Effect"(허용 또는 거부), "Action"(AWS 서비스 작업), "Resource"(AWS 리소스) 및 선택적 "Condition"과 같은 요소가 있는 IAM 정책과 유사한 구조를 따릅니다. (컨텍스트에 따른 제한). 주요 차이점은 SCP가 연결된 계정 또는 OU의 모든 IAM 엔터티에 적용되므로 SCP에는 "Principal" 요소가 포함되어 있지 않다는 것이다.
SCP를 효과적으로 사용하는 방법
- 제한적인 접근 방식으로 시작
- 제한적인 권한 집합으로 SCP를 생성하여 시작하고 조직의 요구 사항에 따라 권한을 점진적으로 확장한다.
- 여러 SCP 사용
- 계정 또는 OU에 여러 SCP를 연결할 수 있다. 해당 계정의 IAM 엔터티에 대한 유효 권한은 연결된 SCP에서 "허용(access)" 효과의 합집합과 "거부(deny)" 효과의 교차점이다.
- 구조에 OU 활용
- 다양한 팀이나 환경에 필요한 권한을 기반으로 AWS 계정을 OU로 구성하고 OU에 SCP를 적용하여 계정 전체에서 일관되게 권한을 관리한다.
액세스 제어 목록(ACL) - Access control lists
액세스 제어 목록(ACL)은 Amazon S3 버킷 및 객체와 같은 특정 AWS 리소스에 대한 액세스를 제어하는 레거시 방법이다. 리소스 및 허용되는 작업에 액세스할 수 있는 AWS 계정 또는 사전 정의된 그룹을 정의하여 개별 리소스의 권한을 관리하는 방법을 제공한다.
Amazon S3의 ACL은 버킷과 객체에 적용되는 규칙 집합으로, READ, WRITE 또는 FULL_CONTROL과 같은 작업을 수행할 수 있는 보안 주체(AWS 계정 또는 사전 정의된 그룹)를 지정한다.
그러나 IAM 정책, 특히 자격 증명 기반 및 리소스 기반 정책이 액세스 제어를 위해 Amazon S3의 ACL을 대체로 대체했다는 점에 유의해야 한다. IAM 정책은 ACL에 비해 더 세분화된 제어와 더 나은 관리 용이성을 제공한다.
Amazon S3의 ACL과 IAM 정책 비교
- 세분성(Granularity)
- IAM 정책은 ACL에 비해 작업 및 리소스에 대해 더 세분화된 제어를 제공한다. IAM 정책을 사용하면 개별 작업을 기반으로 액세스를 지정할 수 있지만 ACL은 READ 또는 WRITE와 같은 더 광범위한 권한을 사용한다.
- 보안 주체(Principal)
- ACL에서 개별 AWS 계정 또는 사전 정의된 그룹(예: "모든 사용자" 또는 "인증된 사용자")에 대한 액세스를 지정할 수 있으며 IAM 정책을 통해 IAM 사용자, 그룹, 역할 또는 AWS 계정에 대한 권한을 정의할 수 있다. .
- 조건(Conditions)
- IAM 정책은 IP 주소, 날짜 또는 AWS 서비스와 관련된 특정 속성과 같은 컨텍스트를 기반으로 액세스를 정의할 수 있는 조건을 지원한다. ACL은 조건을 지원하지 않는다.
- 관리 용이성(Manageability)
- IAM 정책은 IAM 자격 증명(사용자, 그룹, 역할) 또는 리소스에 연결할 수 있고 ACL은 각 리소스(버킷 또는 객체)에 개별적으로 적용해야 하므로 관리하기가 더 쉽다.
세션 정책 - Session policies
AWS IAM 세션 정책은 IAM 역할을 맡을 때 발급되는 임시 보안 자격 증명의 권한을 추가로 제한하는 데 사용되는 고급 액세스 제어 정책이다.
AWS Security Token Service(STS)를 사용하여 역할을 맡을 때 선택적 세션 정책을 전달하여 역할의 권한 정책에서 부여하는 권한을 제한할 수 있다. 이렇게 하면 역할 자체보다 액세스가 더 제한된 임시 자격 증명을 생성하여 추가 보안 수준을 제공할 수 있다.
그리고 역할 또는 연동 사용자에 대한 임시 세션을 프로그래밍 방식으로 생성할 때 매개 변수로 전달하고, AssumeRole, AssumeRoleWithSAML또는 API 작업을 사용하여 프로그래밍 방식으로 역할 세션을 만들고 세션 정책을 전달할 수 있다.
세션 정책은 특정 작업을 위해 또는 제한된 기간 동안 리소스에 대한 임시적이고 제한된 액세스 권한을 부여하려는 시나리오에서 유용할 수 있다.
예를 들어 Amazon S3에 액세스할 수 있는 광범위한 권한이 있는 IAM 역할이 있을 수 있지만 사용자에게 짧은 시간 동안 특정 버킷에 대한 임시 액세스 권한을 부여해야 한다고 하면, 세션 정책을 사용하여 해당 특정 버킷에 대한 액세스만 허용하도록 임시 자격 증명을 제한할 수 있다.
세션 정책과 관련된 주요 개념
- 임시 보안 자격 증명(Temporary security credentials)
- IAM 사용자, AWS 서비스 또는 외부 자격 증명 공급자가 IAM 역할을 맡을 때 역할의 권한 정책에 정의된 권한을 상속하는 임시 보안 자격 증명을 받는다. 이러한 자격 증명은 기간이 제한되어 있으며 액세스 키 ID, 비밀 액세스 키 및 세션 토큰으로 구성된다.
- 권한의 교차점(Intersection of permissions)
- 임시 보안 자격 증명의 유효 권한은 역할의 권한 정책과 세션 정책의 교차점이다. 즉, 세션 정책은 역할에 의해 부여된 권한을 추가로 제한할 수 있지만 확장할 수는 없다.
- 정책 구조(Policy structure)
- 세션 정책은 "Effect"(허용 또는 거부), "Action"(AWS 서비스 작업), "Resource"(AWS 리소스) 및 선택적 " 조건"(선택)
- 정책 크기 제한(Policy size limit)
- 세션 정책의 크기 제한은 2,048자로 정책에 포함할 수 있는 권한 및 조건의 수에 영향을 줄 수 있다.
AWS Security Token Service(STS)
AWS Security Token Service(STS)는 AWS 리소스에 액세스해야 하는 사용자, 애플리케이션 또는 서비스에 임시 보안 자격 증명을 제공하는 웹 서비스이다. 이러한 임시 보안 자격 증명은 기간이 제한되어 있어 장기 액세스 키에 비해 더 안전한 옵션이다.
STS는 리소스에 대한 액세스 권한을 위임하거나, 교차 계정 액세스 권한을 부여하거나, ID 공급자를 통해 인증된 외부 사용자에게 액세스 권한을 제공해야 하는 시나리오에서 특히 유용하다.
AWS STS의 주요 기능 및 개념
- 임시 보안 자격 증명(Temporary security credentials)
- STS는 액세스 키 ID, 비밀 액세스 키 및 세션 토큰으로 구성된 임시 보안 자격 증명을 발급한다. 이러한 자격 증명은 연결된 IAM 역할 또는 사용자의 권한을 상속하며 AWS 서비스에 프로그래밍 방식으로 요청하는 데 사용할 수 있다.
- 기간(Duration)
- STS에서 제공하는 임시 보안 자격 증명은 기간이 최소 15분에서 최대 12시간(또는 SAML 연합과 같은 특정 사용 사례의 경우 36시간)으로 제한되어 있다. 손상된 자격 증명은 지정된 기간이 지나면 자동으로 만료되므로 이러한 시간 제한적 특성은 장기 액세스 키와 관련된 위험을 줄인다.
- 위임(Delegation)
- STS를 사용하여 IAM 역할을 생성하고 수임함으로써 AWS 리소스에 대한 액세스 권한을 위임할 수 있다. IAM 역할은 특정 권한이 있는 AWS 자격 증명이며 다른 엔터티(ex: IAM 사용자, AWS 서비스 또는 외부 자격 증명 공급자)는 해당 리소스에 일시적으로 액세스하는 역할을 맡을 수 있다.
- 교차 계정 액세스(Cross-account access)
- STS를 사용하면 한 계정의 AWS 리소스에 대한 액세스 권한을 다른 계정의 IAM 엔터티에 부여할 수 있다. 대상 계정에서 역할을 생성하고 수임하면 원본 계정의 사용자가 추가 액세스 키를 관리할 필요 없이 지정된 리소스에 액세스할 수 있다.
- 외부 자격 증명 공급자(External identity providers)
- STS를 사용하여 SAML 2.0 또는 OIDC(OpenID Connect) 공급자와 같은 외부 자격 증명 공급자를 통해 인증된 사용자에게 AWS 리소스에 대한 임시 액세스 권한을 부여할 수 있다. 이를 통해 기존 자격 증명 관리 시스템을 기반으로 AWS 리소스에 대한 액세스를 관리할 수 있다.
- 세션 정책(Session policies)
- STS를 사용하여 역할을 맡을 때 선택적 세션 정책을 전달하여 역할의 권한 정책에서 부여하는 권한을 추가로 제한하여 추가 보안 수준을 제공할 수 있다.
임시 보안 자격 증명(Temporary security credentials)의 3가지 구성요소
- 액세스 키 ID(Access Key)
- 임시 보안 자격 증명과 연결된 고유 식별자이다. AWS 서비스에 요청할 때 임시 자격 증명을 식별하는 데 사용된다.
- 비밀 액세스 키(Secret Access Key)
- AWS 서비스에 대한 요청에 서명하기 위해 액세스 키 ID와 함께 사용되는 비밀 키이다. 기밀로 유지해야 하며 로그나 코드에서 공유하거나 노출해서는 절때로 안된다.
- 세션 토큰(Session Token)
- AWS 서비스에 요청할 때 Access Key ID 및 Secret Access Key와 함께 포함되어야 하는 고유하고 불투명한 문자열이다. 세션 토큰은 AWS 서비스가 자격 증명을 검증하고 적절한 권한과 연결하고 만료를 결정하는 데 도움이 된다.
AWS STS API Reference
기본적으로 모든 AWS STS 요청은 단일 엔드포인트로 이동한다. 글로벌 엔드포인트 - (https://sts.amazonaws.com)
엔드 포인트는 IAM 계정설정에서 활성화 할 수 있고, 리전에 따른 엔드포인트도 확인할 수 있다.
AWS에서는 글로벌 엔드포인트 대신 리전 AWS STS 엔드포인트를 사용하는 것을 권장한다. 그 이유는 지연 시간을 줄이고, 중복성을 구축하고, 세션 토큰 유효성을 높일 수 있다.(AWS recommends using Regional AWS STS endpoints instead of the global endpoint to reduce latency, build in redundancy, and increase session token validity.)
AWS STS와 함께 사용할 리전을 활성화한 후 해당 리전으로 AWS STS API 호출을 보낼 수 있다. 호출을 보낼 땐 리전과 엔드포인트를 모두 제공하는 것을 권장한다.
CloudTrail을 사용하면, AWS STS에 성공적으로 전송된 요청과 요청 보낸 사람 및 시간을 확인할 수 있다.
AWS IAM 자격증명 공급자란?
AWS Identity and Access Management(IAM) 자격 증명 공급자는 AWS 환경에서 외부 자격 증명을 통합하고 관리하는 데 도움이 되는 엔터티이다. 자격 증명 공급자를 사용하면 AWS 리소스에 대한 연합 액세스를 활성화하여 외부 자격 증명 시스템의 사용자가 AWS 계정 내에서 IAM 사용자를 생성할 필요 없이 임시 AWS 보안 자격 증명을 얻고 AWS 서비스에 액세스할 수 있다.
IAM 자격 증명 공급자 유형
SAML 2.0 IdP(Identity Providers)
SAML 2.0(Security Assertion Markup Language 2.0)은 당사자 간, 특히 ID 공급자와 서비스 공급자 간에 인증 및 권한 부여 데이터를 교환하기 위한 XML 기반 표준이다.
SAML 2.0 IdP(예: Microsoft Active Directory Federation Services, Okta 또는 Shibboleth)를 AWS IAM과 통합하면 AWS Management Console에 대한 SSO(Single Sign-On)를 활성화하여 사용자가 기존 리소스를 기반으로 AWS 리소스에 액세스할 수 있다.
OIDC(OpenID Connect) ID 제공자(OIDC Providers)
OpenID Connect는 OAuth 2.0 프로토콜 위에 있는 간단한 ID 계층으로 클라이언트가 권한 부여 서버에서 수행한 인증을 기반으로 최종 사용자의 ID를 확인할 수 있다.
OIDC 공급자는 일반적으로 모바일 및 웹 애플리케이션에서 사용자를 인증하는 데 사용된다. OIDC IdP(예: Google, Auth0 또는 Amazon Cognito)를 AWS IAM과 통합하면 STS 'AssumeRoleWithWebIdentity' API를 사용하여 OIDC 자격 증명 토큰을 AWS 보안 자격 증명으로 교환하여 사용자에게 AWS 리소스에 대한 임시 액세스 권한을 부여할 수 있다.
그리고 Amazon EKS 클러스터를 생성하면 OIDC 발급자 URL이 자동으로 생성되고 구성된다. 클러스터 생성 프로세스 중에 OIDC 발급자 URL에 대한 설정을 지정할 필요가 없다.
OIDC 발급자 URL은 EKS 클러스터의 Kubernetes API 서버에 연결되며 https://oidc.eks.<region>.amazonaws.com/id/ <cluster id>형식이다. 여기서 <region >는 클러스터가 생성된 AWS 리전이고 <cluster-id>는 EKS 클러스터의 고유 식별자이다.
Reference
AWS Identity And Access Management
IAM 작동방식
Explained Simply: AWS IAM and Kubernetes RBAC
Identity providers and federation
IAM의 정책 및 권한
- https://docs.aws.amazon.com/ko_kr/IAM/latest/UserGuide/access_policies.html
- https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-choosing-managed-or-inline.html
I
AM 역할과 리소스 기반 정책의 차이점
관리형 정책과 인라인 정책 중에서 선택
Welcome to the AWS Security Token Service API Reference(AWS STS Token API 참고)
'AWS' 카테고리의 다른 글
| AWS Secrets Manager란?(OAuth, SSO) (0) | 2023.04.01 |
|---|---|
| AWS CLI 정리 (0) | 2023.03.31 |
| AWS S3 권한이란? (0) | 2023.03.29 |
| AWS S3란?(개념, 속성) (0) | 2023.03.28 |
| AWS S3 맛보기 (0) | 2022.02.13 |