✅ 01. Why Security?
클라이언트가 AWS로 보내는 모든 조회/업데이트/생성/삭제 요청은 모두 API로 이루어지게 된다. 또한, AWS 자원들끼리 주고받는 요청과 응답도 모두 API 형태를 띄게 된다. 그렇다면 AWS에서는 어떻게 인증이 이루어지게 될까? 아래는 DynamoDB에 대한 ListTables API에 대한 HTTP Header값이다.
기본적으로 모든 AWS API 요청에는 자격증명이 포함된다. AWS에서의 자격증명은 Access Key ID와 Secret Access Key로 구성되며, 요청이 AWS로 전달될 때 HMAC(Hash-based Message Authentication Code) 서명 방식으로 인증이 수행된다. 또한, IAM Role을 사용하는 경우 임시자격증명이 사용되며, 여기서 Session Token이 추가된다. 요청이 DynamoDB에 도착하면 AWS는 서명 값을 검증 후 허용 여부를 결정한다.
모든 요청은 API로 이루어지고 이러한 인증(Authentication), 인가(Authorization)을 관리하기 위해 IAM을 사용한다.
✅ 01. IAM이란?
AWS IAM은 Identity and Access Management의 약자로 AWS 전반에 걸쳐 사용자의 신원(Identity)를 검증하고, 접근(Access)를 관리하는 서비스다. IAM을 통해 누가(AWS 사용자, 서비스) 무엇을(AWS 리소스) 할 수 있는지를 결정하며, 인증(Authentication), 인가(Authorization)를 제어하는 역할도 수행한다. 다음은 IAM 구성에 대해 살펴보자.
01-1. IAM 구성
IAM은 사용자(User), 사용자 그룹(Group), 정책(Policy), 역할(Role)의 네 가지 구성 요소로 구분된다.
사용자(User)
실제 AWS를 사용하는 사용자나 AWS의 서비스(EC2.. 등등)를 의미한다.
사용자 그룹(User Group)
앞서 말한 사용자의 집합(그룹)으로, 해당 그룹에 정책(Policy)를 붙혀 권한을 얻을 수 있다.
정책(Policy)
정책은 기본적으로 사용자(User), 사용자 그룹(User Group), 역할(Role)에 연결(Attachment) 될 수 있다. 이러한 정책이 의미하는 바는 누가 - 무엇을 - 할 수 있는지를 결정하는 규칙이 정의되어 있는 JSON 문서라 볼 수 있다.
역할(Role)
역할은 AWS 리소스에 부여하여 AWS 리소스(EC2, Lambda)가 무엇을 할 수 있는지 정의한다. 또는, 다른 사용자(aws account)나 사용자 그룹에서 역할을 부여 받아 사용 가능하다. 이 부분은 특정 사용자가 역할을 변경하면서 권한을 획득 하는 것으로 이해하면 된다.
01-2. IAM 권한 검증 과정
우선 IAM의 권한 검증 과정은 위 이미지와 같다.
- 우선 사용자에게 명시적 거부(Deny)가 있는지 확인 한다, 없으면 다음으로 넘어간다
- 우선 사용자에게 S3를 이용할 권한(정책 : Policy)이 있는지 확인
- 사용자에게 권한이 없으면, 사용자 그룹에서 S3를 이용할 권한이 있는지 확인
- 사용자 그룹에도 없으면, 위임받은 역할(Role)에 S3를 이용할 권한이 있는지 확인
- 권한이 있으면 S3를 조회하고, 그렇지 않으면 Deny로 접근이 불가능하다
- ex) Lambda를 사용하는 경우, Lambda에 Attachment된 역할(Role)이 S3에 접근할 수 있는 정책(Policy)가 있어야 접근이 가능
01-3. Assume Role(역할 빌려쓰기)
A 계정의 > 사용자 그룹 > search-test-assume-policy(정책)
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "test",
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam::65xxxxxxxxx:role/test-role"
}
]
}
B 계정의 search-test-assume-role(신뢰 관계 Tab)
{
"Version": "2012-10-17",
"Statement": [
"Sid": "testAssume"
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam:12345678910:root" // Account A ID
},
"Action": "sts:AssumeRole",
"Condition": {
"Bool": {
"aws:MultiFactorAuthPresent": "true" // MFA 활성화 한경우 Assume 허용
}
}
]
}
IAM Assume Role : 내가(사용자, 그룹, 서비스) 잠시동안 특정 신분(role)을 빌려서 사용한다!
AWS에서 IAM Role을 사용하는 이유는 장기 자격 증명(Long-Term Credentials)의 보안 위험을 줄이기 위함이다. IAM Role을 사용하면 개발자가 직접 Access Key & Secret Key를 관리할 필요없이, 필요할때만 임시 자격증명(Temporary Credentials)을 발급받아 사용할 수 있다. 예를 들어, EC2에 Instance Profile을 연결하면, EC2 인스턴스는 자동으로 Role을 Assume하여 별도의 Access Key 없이 AWS 서비스에 접근할 수 있다.
Assume Role이란 AWS에서 하나의 사용자(User), 사용자 그룹(User Group), 또는 AWS 서비스가 다른 IAM 역할(Role)의 권한을 임시로 부여받아 사용하는 기능이다. 즉, 특정 주체(Principal)가 Assume Role API를 호출하여 다른 역할(Role)의 권한을 일시적으로 획득하고, 해당 역할의 권한을 행사하는 것을 의미한다.
Assume Role 사용 예시
- Cross-Account Access
- AWS 계정 A의 사용자가 B 계정의 리소스에 접근하기 위해 B의 특정 Role을 Assume한다
- 예) 나는 서비스 개발1팀의 개발자인데, 아키텍처팀의 리소스에 접근해야 할 일이 생겼다. 이를 위해 아키텍처팀의 IAM Role을 잠시 빌려 해당 리소스에 접근한다.
- STS(Security Token Service) 사용
- AWS CLI or SDK에서 assume-role 호출 시 임시 자격증명을 받아 해당 Role의 권한을 사용할 수 있다
음… 우리에게 익숙한 영화를 통해 IAM Assume Role에 대해 알아보자
“Catch Me If You Can” 영화를 본 사람이라면 이해하기 쉬울 것이다. 영화에서 디카프리오는 사기꾼으로 등장하며, 기장, 변호사, 사업가 등 다양한 직업을 가장하여 활동한다. IAM Role도 이와 비슷한 개념으로 볼 수 있다. 예를 들어, AWS에 로그인한 사용자를 회사의 일반 사원이라고 가정하자. 어느 날, 이 사용자에게 팀장 역할이 주어진다면, 기존에 할 수 없던 업무를 팀장 권한으로 수행할 수 있게 된다. 즉, 역할(Role)이란 특정 권한을 행사할 수 있도록 부여되는 신분이며, 상황에 따라 유동적으로 변경될 수 있다. 즉, 사원이 팀장 역할을 부여받으면, 이는 곧 사원이 팀장의 권한을 Assume(수행)한 것이라고 볼 수 있다.
01-4. Pass Role(역할 넘겨주기)
IAM Pass Role : 사용자, 특정 AWS 서비스가 특정 Role을 사용할 수 있도록 허락한다!
PassRole은 특정 주체가 역할을 Pass하는걸 제어하기도 하고, 권한을 Pass 해주기도 한다.
IAM Pass Role은 특정 AWS 서비스(EC2, Lambda, ECS, CodeBuild)가 특정 Role을 사용할 수 있도록 Role을 넘겨주는(Pass) or 허락하는(Allow) 하는 기능이다. Pass Role의 경우 주어진 상황에 따라 달라지는데 아래와 같다.
사용자에게 정책(Policy)이 있는 경우
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "iam:PassRole",
"Resource": "arn:aws:iam::123456789012:role/MyExampleRole"
}
]
}
중요한 부분은 정책의 Resource에 “*”를 넣으면 모든 Role을 PassRole을 통해 전달 가능하기에 사용을 지양하자
- IAM의 사용자에게 test-passrole-policy가 있다고 가정
- 이러한 경우 사용자는 AWS 리소스(EC2, Lambda)에 MyExampleRole만 전달 할 수 있다
- 사용자 그룹, 역할을 Assume 받은 경우도 위와 동일함
99. 참고 자료
409.Assume role,Pass role 이해
일반 계정 사용자가 AWS서비스를 이용하려고 할때 권한이 없다고 오류가 뜬다. 1. Assume role - 역할전환 - 잠시 역할 위임 받자 2. Pass role 3. Service-Linked Roles 1. Assume role 역할 전환 내가 상대의
brunch.co.kr
AWS AssumeRole, PassRole
AssumeRole AssumRole하는 것으로 IAM role에 설정되어있는 권한을 맡는게 가능하다. sts:AssumeRole이라고 하는데, sts는 Security Token Service이다. 정확히는, sts를 매개로 해서 IAM Role과 같은 권한을 일시적으로
set-sail-it.tistory.com
[IAM] AssumeRole과 PassRole
여러 AWS 서비스에서는 사용자를 대신해서 작업을 실행하기 위해 IAM Role을 부여한다. 그 과정에서 AssumeRole과 PassRole을 자주 볼 수 있는데, 이 둘은 간혹 보면 햇갈리는 점이 있다.이번에는 이 둘
blog.omoknooni.me
'Public Cloud > AWS - Experience' 카테고리의 다른 글
[AWS] AWS에서 자주 사용하는 CLI 정리 (0) | 2025.03.11 |
---|---|
[AWS] ECS 실행중인 Task에 Tag 지정(tag propagation)하기 (0) | 2025.03.10 |
[AWS] EC2의 EBS 스토리지 재부팅 없이 늘리는 방법 (0) | 2025.01.20 |
[AWS] ECS Task Role vs Execution Role 차이 (1) | 2025.01.20 |
[AWS] VPC, Subnet, Routing Table, NAT 생성 과정 정리 (0) | 2025.01.20 |