AWS SAA 자격증 공부-2. IAM

Ryu's Tech

AWS SAA 자격증 공부-2. IAM

Ryusstory 2018. 11. 18. 17:53

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 내용을 말하는 것이다.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:Get*",
                "s3:List*"
            ],
            "Resource": "*"
        }
    ]
}

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 역할은 권한을 부여하는 더욱 안전한 방법으로 짧은 기간 동안 유효한 키를 발행합니다.