IAM(Identity and Access Management)
- AWS 서비스 및 리소스에 대한 액세스를 안전하게 관리하기 위한 수단
- 서비스와 리소스 = AWS내 서비스를 사용할 수 있는 권한
- AWS가 제공하는 사용자 계정 관리 서비스
- 정당한 사용자인지 인증하고 사용자마다 이용할 수 있는 서비스 제한
- 신용카드 정보 있음! -> 누출시 고액 청구 발생 가능 -> OTP와 조합하는 다요소 인증(MFA)기능 있음
IAM 계정
- IAM 계정에 AWS에서 조작가능한 권한 한정하기
- 정책( = AWS 서비스에 대한 접근 권한을 설정한 것)
- AWS 관리 정책 : AWS가 생성 및 관리하는 정책
- 고객 관리 정책 : AWS 계정으로 생성 및 관리하는 관리 정책. AWS 관리 정책보다 세세한 정책을 관리할 수 있음.
- 1개 사용자 ID에 설정할 수 있는 정책 : 10개
1. 역할(Role)
- 임시 보안 자격 증명을 사용할 수 있음
- 다수 사용자나 애플리케이션이 사용할 수 있음
- 별도 과금 없음
- 역할은 사용자 또는 서비스에 부여할 수 있음
- 보통 일반 사용자가 아닌 AWS 서비스에게 어떤 접근 권한을 주기위해서 사용
- 여러 AWS 계정 간에 교차 접근 제어를 위해서도 사용할 수 있음
2. 사용자(User)
- 루트 사용자가 아닌 특정한 역할(role)을 가진 또는 그룹으로 묶어서 사용자를 지정하기 위한 용도
3. 사용자 그룹 (User Group)
- 다수의 사용자를 그룹으로 묶고 역할을 부여할 수 있음
IAM 정책 (Policy)
- 정책을 생성하고 IAM 자격 증명(사용자, 사용자 그룹 또는 역할) 또는 AWS 리소스에 연결하여 AWS에서 액세스를 관리
- 정책은 자격 증명이나 리소스와 연결될 때 해당 권한을 정의하는 AWS의 객체
- AWS는 IAM 보안 주체(사용자 또는 역할)가 요청을 보낼 때 이러한 정책을 평가함
- 정책에서 권한은 요청이 허용되거나 거부되는지를 결정
< 정책 유형 (자주 사용하는 정책 순) >
- 자격 증명 기반 정책(Identity-based-policies)
- 리소스 기반 정책(Recource-based-policies)
- 권한 경계(Permissions boundaries)
- Organizations SCPs
- 액세스 제어 목록(ACL: Access control lists)
- 세션 정책(Session policies)
-> 이 중에 ACL을 제외 모든 IAM의 정책에서 JSON 정책 구조를 사용
(JSON 코드를 볼 때마다 뭔지 이해를 못했어서 이참에... 정리~)
< IAM 정책 JSON 문서 구조 >
- 최상위 element 안에 다수개의 statement로 이루어져있는 구조
/* 하나의 정책에 다수의 Statement가 사용된 예 */
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "FirstStatement", // Statement ID로 Statement를 구분 위해 사용
"Effect": "Allow", // 해당 설정 적용을 Allow or Deny 설정
"Action": ["iam:ChangePassword"], // 허용할 행위 (= Action)
"Resource": "*"
},
{
"Sid": "SecondStatement",
"Effect": "Allow",
"Action": "s3:ListAllMyBuckets",
"Resource": "*"
},
{
"Sid": "ThirdStatement",
"Effect": "Allow",
"Action": [
"s3:List*",
"s3:Get*"
],
"Resource": [ // Action이 영향을 미치는 리소스 리스트를 지정
"arn:aws:s3:::confidential-data",
"arn:aws:s3:::confidential-data/*"
],
"Condition": {"Bool": {"aws:MultiFactorAuthPresent": "true"}}
// 조건이 충족되는 경우에만 해당 정책 적용
}
]
}
< JSON 정책 요소 >
- Version
- 사용하고자 하는 정책언어의 버전 지정
- 최신 버전( 2012-10-17) 사용 권장 (구버전은 2008-10-17)
- Id
- 정책 식별자 지정 (필수 아님)
- Id 필요한 경우 UUID(GUID) 값이나 그 일부를 ID로 사용하여 고유성 확보하는 것이 좋음
ex) "Id": "cd3ad3d9-2776-4ef1-a904-4c229d1642ee"
- Statement(설명문) (필수)
- 정책 요소의 컨테이너 역할, 단일문 or 개별 문의 배열 포함할 수 있음 (코드 예시와 같이 [{...},{...}] 이런 식 )
- 나열되는 요소 순서는 상관없음
- Sid
- 설명문(statement)의 Id
- IAM에서 Sid는 IAM API에 노출되지 않음. 이 Id를 근거로 특정 문 가져오기 불가능.
( // 나는 아직 이 API로 어떻게 하는 거에 대한 이해가 부족한 듯 추후 따로 공부해야겠음... )
- Amazon SQS나 Amazon SNS 등은 이 Sid를 필요로 하거나 고유성 요건을 요구하는 경우도 있음
- Effect
- 엑세스를 (문의)허용 or (명시적)거부하는지 설정 ( Allow / Deny )
- 기본적으로 리소스 액세스는 거부 상태
- 허용하려면 "Effect": "Allow"로 설정
- Principal / NotPrincipal
- 리소스 기반 정책을 생성하는 경우 리소스에 대한 액세스가 허용되거나 거부되난 보안주체(계정, 사용자, 역할, 페러레이션 사용자)를 지정
- 보안 주체 이름이나 ARN의 일부를 나타내기 위해 와일드카드(*) 사용 불가능
- 보안 주체는 항상 특정 사용자가 되야하기 때문
- NotPrincipal은 보안 주체 목록에서 예외를 지정 -> 사용하는 경우 거의 없음
보안 주체 | 지정 코드 |
AWS 계정 및 루트 사용자 | - AWS 계정 ID 지정 "Principal": { "AWS": "arn:aws:iam::AWS-account-ID:root" } "Principal": { "AWS": "AWS-account-ID" } - Canonical ID 지정 "Principal": { "CanonicalUser": "canonical-ID" } |
IAM 역할 | "Principal": { "AWS": "arn:aws:iam::AWS-account-ID:role/role-name" } |
역할 세션 | - 수임된 역할 세션 보안 주체 "Principal": { "AWS": "arn:aws:sts::AWS-account-ID:assumed-role/role-name/role-session-name" } - 웹 자격 증면 세션 보안 주체 "Principal": { "Federated": "cognito-identity.amazonaws.com" } - SAML 세션 보안 주체 "Principal": { "Federated": "arn:aws:iam::AWS-account-ID:saml-provider/provider-name" } |
IAM 사용자 | "Principal": { "AWS": "arn:aws:iam::AWS-account-ID:user/user-name" } |
페더레이션 사용자 세션 ( // federated... 알아보기... ) | "Principal": { "AWS": "arn:aws:sts::AWS-account-ID:federated-user/user-name" } |
AWS 서비스 | "Principal": { "Service": [ "service-name1.amazonaws.com", "service-name2.amazonaws.com" ] } |
모든 보안 주체 | "Principal": "*" "Principal" : { "AWS" : "*" } |
- 배열 이용해서 여러개의 계정 지정하기
"Principal": {
"AWS": [
"arn:aws:iam::123456789012:root",
"999999999999",
"CanonicalUser": "79a59df900b949e55d96a1e698fbacedfd6e09d98eacf8f8d5218e7cd47ef2be"
]
}
( 과연 이걸... 내가 언제 쓸까 싶기도 한데... 우선 이런 게 있다더라~ 이렇게 쓴다더라~ 정도만 ^_^ )
- Action / NotAction
- 정책이 허용하거나 거부하는 작업 목록 포함
- "Action" : "작업 서비스 접두사: 작업 이름"
- NotAction은 지정된 작업 목록을 제외한 모든 액션 지정
- ex) "NotAction": "iam:*"
- Resource / NotResource
- IAM 권한 정책을 생성하는 경우 작업이 적용되는 리소스 목록을 지정
- 리소스를 특정할 수 없는 일부 서비스에서는 Resouce를 비워두는 대신 * 입력
- NotResource는 지정된 리소스 목록을 제외한 모든 리소스 지정
- Condition
- 정책에서 권한을 부여하는 상황을 지정
- 조건이 충족되는 경우에만 해당 정책을 적용시킬 수 있는 개념
- "Condition" : { "{condition-operator}" : { "{condition-key}" : "{condition-value}" }}
- condition-operator: 조건 연산자, condition-key: 조건 키, condition-value: 조건 값
조건 연산자는... 종류가 많은데 어떤 연산자가 있는지 목록만 나열하고 세세한 것은 생략하겠다.
( 문자열 조건 연산자, 숫자 조건 연산자, 날짜 조건 연산자, 불린 조건 연산자, 이진 조건 연산자, IP 주소 조건 연산자, ARN 조건 연산자, ifExists 조건 연산자, Null 연산자 등이 있다고 한다! )
[ 추가로 공부해야 할 것 ]
- 서비스 API 구조
- ARN( Amazon Resource Name) 문법 구조
[ 참고 ]
- AWS에서 제공하는 IAM 사용 설명서: https://docs.aws.amazon.com/ko_kr/IAM/latest/UserGuide/iam-ug.pdf#access_policies
+ IAM discussion을 통해 새롭게 알게 된 것
다른 계정과의 리소스 공유
- ex. Identity Federation(Facebook 로그인, 구글 로그인 등)
- 계정 여러개인 경우 같은 거!!
사용자와 역할의 차이
- 사용자는 한 사람 혹은 애플리케이션과 고유하게 연결되지만 역할은 해당 역할이 필요한 사람이면 누구나 수임가능
또, 사용자는 영구적인 장기 자격 증명을 가지고 있지만 역할은 임시 자격 증명만 제공
사용자그룹은 안되고 서비스 구현할 때는 policy를 역할만 부여할 수 있다
'클라우드 > AWS' 카테고리의 다른 글
[AWS] Edge Location - Global Accelerator (2) | 2023.07.24 |
---|---|
[AWS] Computing Service / LightSail, EC2 (0) | 2023.07.13 |
[Hands-on] CloudFront - S3 연결 (0) | 2023.07.10 |
[Hands-on] Bastion host로 private instance 접속하기 (0) | 2023.06.27 |
[Hands-On] ECR, Docker image pull, Flask (0) | 2023.06.22 |