1. IAM(Identity and Access Management)
- AWS의 모든 자원을 통제하는 서비스로 VPC만큼 중요한 개념
- 유효한 사용자인지를 확인하는 인증(Authentication)과정과 허가된 작업인지를 확인하는 인가(Authorization)과정을 진행한다.
- AWS 계정 관리 및 자원/사용자/서비스의 권한 제어 및 인증 정보 부여
- AWS 자원을 사용하려는 모든 행위는 IAM을 거쳐야 한다. 즉, AWS의 서비스를 의도한 방향으로 사용하기 위해서는 반드시 알아두어야 한다.
- 의도한 방향이란? 최소한의 권한만 주는 것(principle of least privilege)
- IAM은 리전별로 구분된 것이 아닌, 글로벌 서비스이다.
- IAM을 이용해 실질적으로 하는 행위는 아래와 같다.
“1)정책을 작성한 뒤, 2)사용자/사용자그룹/역할에 부여한다.”
2. IAM_정책
- 사용자(그룹), 역할이 무엇을 할 수 있는지 작성한 문서로, AWS가 정의한 문법에 맞추어 JSON으로 기술한다.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:*",
"s3-object-lambda:*"
],
"Resource": "*"
}
]
}2.1. Version
- “2012–10–17” 상수값(현재 버전)을 반드시 모든 문서에 넣어주어야 한다. 그렇지 않을 경우, 정책 변수가 동작하지 않는다.
2.2. Statement
- 여러개의 정책을 기술할 수 있다.
- 내부의 정책은 필수값(Effect, Action, Resource), 선택(Condition, Principal)으로 기술되어 해당 구문 내에서 효력을 발휘한다.
2.3. Effect
- 반드시 Allow/Deny 중에 1개의 값만을 가진다.
- 후술된 정책을 허용할것인지, 차단할것인지를 결정한다.
2.4. Resource
- 요청의 목적지가 되는 서비스를 기술한다.
- 여러개의 목적지를 입력할 수 있다.
- 와일드카드(*) 사용 시, 모든 리소스를 의미한다.
- 특정 리소스의 특정 테이블 혹은 특정 버킷/폴더/객체 단위로 제어가 가능하다.
- 리소스의 경우 ARN(Amazon Resource Name) 문법으로 작성한다.
2.5. Action
- 요청의 접근 방법을 기술한다.
- 여러개의 접근 방법을 입력할 수 있다.
- 와일드카드(*) 사용 시, 모든 접근 방법을 의미한다.
- 와일드 카드(*)를 사용하지 않고, 특정 행위만을 기술할 수도 있다.
- 위의 예시에선 S3에 대한 모든 행위와 S3-Object-Lambda의 모든 행위를 허용한다.
- Effect: Deny인 경우에는 차단할 행위를 의미한다.
2.6. 정책 구조
- Effect, Resource, Action은 Statement에 반드시 기술해야 하는 필수값이며 이 외에 Principal, Condition을 선택적으로 추가할 수 있다.
- Principal, Condition을 사용하면 더 강력하고 복잡한 정책을 생성할 수 있다.
- ex) Source IP 지정, 정책이 유효한 날짜 지정, 특정 VPC, 특정 계정 지정
2.7. 정책 예제
- Effect: 허용
- Action: DynamoDB 레코드 읽기/쓰기 권한 보유
- Resource: 요청의 목적지를 DynamoDB의 테이블 중 MyTable으로 한정
- Principal을 한정 짓지 않았으므로, EC2 서비스에 정책(역할)을 부여할 수 있다.
- Condition: SourceIP를 추가해서, 정책 사용자의 주소 IP를 제한했다.
3. IAM_사용자
- AWS 워크스페이스를 생성 시, 루트 계정을 부여받는다. 루트 계정은 모든 권한을 포함하고 있어 위험하므로, 사용자를 생성 후 알맞은 정책을 부여하여 사용한다.
- IAM 사용자란 하나의 AWS계정(워크스페이스 개념)에서 AWS의 리소스를 사용하기 위한 인증 정보를 가진 주체
- AWS에서는 2가지 방식으로 AWS 자원에 접근할 수 있는 액세스 유형을 부여한다.
3.1. Credential 정보
- 한쌍의 Access Key(ID)와 Secret Access Key(Password)로 이루어진 영구적 인증 정보
- AWS SDK 혹은 HTTP API를 구현할 때 헤더에 Credential 정보로 입력하여 AWS 자원에 접근한다.
- 키를 재발급하지 않는 이상 영구적으로 사용할 수 있다.
- 키를 탈취당할 경우 해당 Access Key로 대표되는 IAM 사용자의 모든 권한 행사가 가능하다. 따라서, AccessKey를 하드코딩 하는 방법은 위험하다.
Q. 그럼 Access Key 입력 없이 어떤 방식으로 사용해야 하나요? EC2에 웹서버를 띄우고, 해당 EC2를 통해 S3 파일 읽기/쓰기 작업이 필요합니다!
→ 임시자격증명 부여방식(Assume role)을 이용해서 해결하는 것을 권장합니다.
3.2. 콘솔 로그인 방식
- AWS 웹 콘솔에 로그인하기 위한 ID/Password 방식
3.3 IAM 사용자그룹
- 사용자의 집합
- 그룹에 속한 사용자는 그룹에 부여된 권한을 행사
4. IAM_역할
- 단기간 동안 유효한 Credential을 가진 자격 증명으로 사용자와 마찬가지로 정책을 가질 수 있다.
- AWS 리소스, 계정 혹은 써드파티(구글, 페이스북)계정에 연결할 수 있다.
- 역할의 경우 일정 시간이 지나면 만료 되는 토큰을 함께 발급하여, 장기 Credential에 비해 훨씬 안전하다. 이렇게 사용하는 것을 Assume Role이라 한다.
- 여러개의 역할을 상황에 따라 교체하여 AWS 자원을 사용할 수 있다.
4.1. 사용자에게 역할을 부여한 경우
4.2. 리소스에 역할을 부여한 경우
Q. 리소스에 역할을 부여할 필요가 있나요? IAM 사용자를 생성하고, 사용자 Credential을 EC2에 저장해서 사용하면 될것 같은데요?
→ 관리할 EC2가 소수라면, 충분히 그렇게 진행할 수 있습니다. 하지만 대규모의 서버(100대 이상)를 관리한다는 상황이라면? 키를 교체해야 한다면? 관리자가 퇴사하여 신규 관리자가 왔는데, 관련 히스토리를 모른다면?
이런 상황을 방지하기 위해서, IAM 역할을 생성 후 리소스(EC2)에 직접 설정해주는 것이 좋은 전략일 수 있습니다.
5. IAM 구조
- 사용자A는 정책A, 정책C, 정책D, 정책E의 권한을 가진다.
- 사용자B는 정책B, 정책C, 정책D의 권한을 가진다.
- EC2는 정책E의 권한을 가진다.
Q. 여러개의 정책간 Deny와 Allow가 상충되면 어떻게 동작하나요?
→ AWS 정책은 기본 디폴트가 Deny이고, 명시적 Deny > 명시적 Allow의 우선순위를 갖습니다.
