IAM이란?
IAM(identity Access Management)으로 말그대로 권한 관리 서비스라고 생각하면 된다.
주요 기능
계정의 중앙관리 기능: AWS의 경우 하나의 계정에서 다수 계정 발급이 가능함. 최초 생성계정을 리눅스 root 계정이라고 생각하면 되고, 이후에 유저를 추가하는 방식으로 권한을 나눠서 계정을 발급해서 사용한다고 생각하면 됨.
계정간 자원공유: 계정간에 리소스 공유가 가능함. (자원공유가 실제 IP나 DNS같은 endpoint가 아니라 aws 내에서 자원공유가 가능함)
Granular Permissions: 권한의 세분화, 읽기/쓰기/리스트 권한 정도가 아니라 세부 동작 자체에 권한을 부여 가능.
Identity Federation: aws와 ID 제공업체와 협력해서 액세스 제어 가능.
Multi-factor authentication: OTP와 같은 다중인증.
필요시 사용자/장치에 임시 액세스 제공: 웹 서비스나 모바일 앱처럼 일시적인 액세스
주요 구성
Users - End user
Groups - 퍼미션으로 구성된 유저의 모음
Roles - AWS 자원에 대한 권한. 실제 할당이 가능한 자원.
Polices - 하나 혹은 하나 이상의 권한이 정의된 문서
IAM 처음 접속
최초 IAM에 접속하면 먼저 IAM 사용자 로그인 링크를 볼수 있게 됨.
최초 접속하면 랜덤하게 생성된 숫자 링크(https://1234569789.signin.aws.amazon.com/console)를 볼 수 있는데 옆의 사용자 지정을 통해 이를 https://별칭.signin.aws.amazon.com/console 형태로 사용 가능. 바로 삭제도 가능.
그 아래로 차례로 설명하면
루트 액세스 키 삭제
루트 계정은 너무 큰 권한을 가지고 있으므로, 루트 계정에는 액세스 하는 방법을 제한하여, 계정 관리로만 사용하고 개별 사용자를 생성해서 필요한 리소스를 사용하도록 권장.
실제로 AWS root key를 잘못 노출하거나 했을 경우 엄청나게 비용이 나올 수 있기 때문에 주의 필요.
루트 계정에서 MFA 활성화
OTP 앱으로 사용가능.
예로, Google OTP 앱이나 Authy 를 사용가능한데, MFA 의 개념과는 좀 다르긴 하지만 authy를 사용하면 휴대폰 분실시에도 복구가 가능함.
분실/OS 재설치가 잦은 휴대폰 이용자는 authy 사용도 괜찮음.
개별 IAM 사용자 생성
별도 사용자를 생성 권장. 위 루트 내용과 같음.
그룹을 사용하여 권한 할당
다수 계정 사용시 절차 간소화
IAM 비밀번호 정책 적용 (아래 이미지 참조)
사용자 생성
1단계. 사용자 정보 및 액세스 유형 선택
사용자 이름을 설정하고 액세스 유형을 선택
액세스 방법에는 프로그래밍 방식 액세스와 AWS Management Console 액세스가 있는데,
1. AWS Management Console 액세스는 기본 방식처럼 ID/PW로 웹 콘솔에 접근하는 방법을 말하고,
이 형태를 선택하면 패스워드 자동생성/수동지정 과 최초 로그인시 비밀번호 변경 요청을 정의할 수 있다.
2. 프로그래밍 방식 액세스의 경우 액세스 키와 시크릿 키가 제공되는데 해당 키로 접근해서 사용하는 경우(awscli나 sdk로 접근)를 말한다.
2단계. 권한 설정
권한 설정으로 넘어가면,
1. 그룹에 사용자 추가
2. 기존 사용자에서 권한 복사
3. 기존 정책 직접 연결
의 세 가지 방법이 있다.
기존 정책 연결의 경우 AmazonS3ReadOnlyAccess 관한을 살펴보면 아래처럼 JSON 형태로 권한이 설명되어 있다.
앞에서 정책이 하나 혹은 하나 이상의 권한이 정의된 문서라고 했는데, 이 JSON 내용을 말하는 것이다.
3단계. 태그(선택사항)
강의에는 나오지 않았는데, 현재는 IAM 사용자도 TAG를 통해 관리할 수 있다.
예를 들면, 기업의 경우 username은 단순 유저 확인용이지만 TAG를 통해 email 이나, 소속 부서, 직책 등 필요한 정보를 column화 시켜서 관리할 수 있다.
4단계. 리뷰
검토 단계로 앞서 정의한 것들을 확인한다.
특이점은, 내가 할당한 정책은 s3 read-only 뿐이지만 앞서 1단계에서 아래와 같은 설정을 체크했기 때문에 자동으로 추가된다.
비밀번호 재설정 필요
사용자가 다음에 로그인할 때 새 비밀번호 생성 요청
사용자가 비밀번호를 변경할 수 있도록 허용하는 IAMUserChangePassword 정책을 자동으로 가져옵니다.
5단계. 완료
액세스 키의 경우 액세스 키와 비밀 액세스 키의 쌍으로 이루어져 있으며, 프로그램 방식의 ID와 비밀번호라 생각해도 된다. 하지만 비밀 액세스 키의 경우 분실시 액세스 키를 다시 발급해서 확인해야 한다.
그렇기 때문에 여기서 꼭 필요한 정보를 받거나, 다운로드해둬야한다.
확인 및 정리
위와 같은 형태로 몇몇 계정을 더 추가하고 확인해봤는데, 아직 TAG를 정의해서 볼수는 없는 것 같다. 주요 서비스인 EC2의 경우 정의한 태그를 대시보드의 열에 추가할 수 있다. 차후 업데이트 될 것 같다.
그리고, 실제 Dropbox의 경우 이러한 방식으로 유저별로 S3의 권한 넘겨주는 형태로 구성되서 시작됐다고 한다.
유저 생성시 access key, secret access key를 통해 자신의 S3 버킷 생성 및 권한 부여.
그룹생성
절차
그룹생성도 사용자 생성과 거의 동일한데
1단계: 그룹이름생성
2단계: 정책연결(앞서 JSON형태의 정책문서)
3단계: 검토
로 이루어져 있다.
사용자 연결시
간단하게 glacier read-only 정책을 그룹에 설정해서 testgroup을 생성한 뒤 앞서 생성한 s3 read-only 권한을 줬던 test1 사용자에 연결을 하게 되면
아래와 같이 사용자에서 설정된 권한과 그룹에서 설정된 권한을 모두 확인할 수 있다.
Role
Role의 개념
Role은 사용자에 권한을 부여하는 것이 아니라 개체(리소스)에 권한을 부여하는 것을 말한다.
예를들어,
test1 사용자에게는 EC2 관련 권한이 있고 해당 EC2를 생성한 뒤
S3 정책 권한을 설정한 Role을 만들어서 해당 EC2에 할당하면
EC2에서 정책에서 부여된 권한대로 S3에 접근할 수 있다.
이렇게 되면 실제 test1 사용자는 S3에 접근할 수 없지만, 생성된 EC2 에서는 S3로 접근이 가능하다.
실제 End User가 아닌 AWS 자원에서의 접근권한을 Role이라고 생각하면 된다.
IAM 역할이란 무엇입니까?
IAM 역할은 신뢰하는 개체에 권한을 부여하는 안전한 방법입니다. 개체의 예는 다음을 포함합니다.
다른 계정의 IAM 사용자
AWS 리소스에서 작업을 수행해야 하는 EC2 인스턴스에서 실행 중인 애플리케이션 코드
계정 내 리소스에서 작업을 수행하여 기능을 제공해야 하는 AWS 서비스
SAML을 통해 인증 연동을 사용하는 사내 디렉토리의 사용자
IAM 역할은 권한을 부여하는 더욱 안전한 방법으로 짧은 기간 동안 유효한 키를 발행합니다.
1단계. 신뢰할 수 있는 유형의 개체 선택
보통 AWS 내에서는 위와 같은 형태로 Role을 사용하지만 아래처럼 다른계정이나 웹ID 등 외부에서 들어오는 인증정보에 대해서도 권한을 할당할 수 있다.
그래서 앞서 말한 EC2와 S3 예처럼 이번에는 권한을 정의 하는 것이 아니라, 1단계가 역할을 사용할 서비스를 먼저 선택한다.
1단계에서 EC2를 선택하고,
2단계. 권한 정책 연결
2단계에서는 사용자 추가에서 본 정책 추가 내용과 동일하다.
여기서 S3 access를 선택하면
3단계 태그
생략
4단계. 검토
이러한 형태로 EC2에서 S3 정책을 허용하는 Role이 만들어진다.
추가 설명. 실제 정책 연결
생성한 정책을 사용하려면 아래와 같이 EC2 생성에서 IAM 역할에서 정의해 주면되고, 앞서 Role 을 생성할 시에 신뢰할 개체를 선택하는데, 거기서 EC2를 선택한 IAM Role만 여기에서 보이게 된다.
그리고 IAM Role 변경/추가/삭제의 경우 서비스 다운없이 즉시 적용된다.
