Share
Sign In

IAM

키워드
유저(Users)
그룹(Groups)
정책(Policies)
역할(Roles)
MFA(Multi Factor Authentication)
패스워드 정책
엑세스 키
자격 증명 보고서(Credential Report)
엑세스 관리자(Access Advisor)
IAM 이란?
IAM은 글로벌 서비스인데, 여기서는 유저를 생성하고 그룹에 할당하는 작업을 할 것이다. 놀랍게도 우리들은 우리가 모르는 사이에 이미 IAM을 썼었다. 계정을 만들 때 말이다. 계정을 만듦으로서 그 계정은 root 유저로 IAM에 등록되었다.
Root 계정: 기본적으로 생성되며 사용하거나 공유하서는 안된다.
유저: 조직의 각 개인을 의미한다. 그룹으로 묶을 수 있다.
그룹: 유저만 담을 수 있다. 그룹 안에 그룹을 담을 수는 없다
유저는 그룹이 없을 수도 있고, 여러 그룹에 속할 수도 있다.
IAM 정책
정책: 유저나 그룹이 어떤 AWS 서비스에 어떤 권한을 가질지 정의하는 JSON 문서이다.
대체로 각 그룹별로 정책이 할당되는데 간혹 그룹이 없는 유저가 있거나 특수한 경우에는 유저 자체에 정책을 할당하기도 한다. 이때 정책을 inline policy라고 부른다.
IAM 정책 구조
JSON 문서를 뜯어보자. 주석에서 (필수)은 필수 요소란 뜻이고 (선택)은 필수가 아니란 뜻이다. 공식 문서
주석을 달기위해 JavaScript 문법으로 작성했기 때문에 이대로 쓰면 절대 안된다!
{ Version: "2012-10-17", // (필수) 정책 언어의 버젼이다. 항상 "2012-10-17" Id: "S3-Permissions", // (선택) 정책의 Id Statement: [ // (필수) 한 개 이상의 Statement를 포함한다. { Sid: "1", // (선택) 각 statement의 Id Effect: "Allow", // (필수) Action은 허용/차단할 것인지 결정 (Allow, Deny) Principal: { // (선택) 특정한 유저에게만 정책을 부여한다 AWS: ["arn:aws:iam::123456789012:root"] }, Action: [ // (필수) 허용/차단할 정책을 나열한다. "s3:GetObject", "s3:PutObject" ], Resource: [ // (필수) 정책을 적용할 리소스를 나열한다. "arn:aws:s3:::mybucket/*" ], Condition: ... // (선택) Condition을 만족해야만 이 Statement를 적용한다. } ] }
패스워드 정책
유저들의 패스워드 정책을 할당하여 보안을 높게 유지할 수 있다.
AWS에서는 다양한 패스워드 정책을 지원하는데,
패스워드 최소 길이 설정
특정 문자 타입 필수 포함(대문자/소문자/숫자/특수기호)
패스워드 변경 가능 여부
패스워드 만료(만료되면 사용하지 못하기 때문에 패스워드 변경을 강제할 수 있다)
같은 비밀번호 재사용 불가
Multi Factor Authentication (MFA)
보안을 강화하기 위해 패스워드 뿐만 아니라 사용자의 보안 장비를 인증하여 사용자를 인식한다. 해커는 패스워드를 알아내더라도 보안 장비 (휴대폰 등)를 가지고 있지 않기 때문에 접근이 불가하다.
MFA = password you know + security device you own
AWS에서 지원하는 MFA Device 옵션은 다음과 같다.
Virtual MFA Device
휴대폰 등의 장비에서 토큰 번호를 발급 받아 입력하는 방식이다. 계정별로 하나의 토큰이 생성되고 각 토큰은 일정 시간이 지나면 만료된다. Google Authenticator (phone only), Authy (multi-device)가 있다.
Universal 2nd Factor (U2F) Security Key
Key가 입력된 물리적인 장비를 들고 다니는 방식이다. 하나의 Key로 등록된 모든 계정에 접근할 수 있다. YubiKey by Yubico가 있다.
Hardware Key FoB MFA Device / for AWS GovCloud (US)
은행에서 쓰는 방식이다. 토큰을 발급하는 장비에서 자동으로 토큰이 발급된다. 미 정부를 위한 장비가 따로 있다.
AWS에 엑세스하기 위한 방법
Console: 크롬으로 접근하는 것이라 생각하면 된다. 패스워드MFA가 필요하다.
CLI: 터미널 창에서 AWS를 제어하는 것을 말한다. 엑세스 키가 필요하다.
SDK: 소스 코드를 통해 AWS를 제어하려 할 때 사용한다. 엑세스 키가 필요하다.
엑세스 키는 AWS Console에서 발급하며, 비밀번호와 같이 절대 공유해서는 안된다.
SDK는 Software Development Kit의 약자이며 언어별로 API가 다르기 때문에 언어에 맞춰 사용해야 한다. 우리가 만든 프로그램으로 AWS 서비스에 접근이 가능하게 하는데, CLI와는 다르게 어플리케이션에 내장된다.
AWS CloudShell
💡
리전별로 사용 가능한 서비스가 다르다. us-east-2 리전은 어지간한 서비스는 다 지원한다.
CloudShell은 콘솔에서 사용하는 터미널 정도로 생각할 수 있다. 클릭 한 번으로 각 리전의 AWS CLI 환경에 접근할 수 있다. 또한 CloudShell 안에 파일을 생성하면 다시 접속해도 그 파일은 유지되고 그 외 다양한 기능들을 클릭 한 번으로 쓸 수 있다.
IAM Role (for AWS Services)
User가 서비스를 조작하듯이 서비스가 서비스를 조작할 필요도 있다. 이때 서비스에 IAM Role을 부여해 그 권한을 준다. Roles은 각자 Policy를 가지고 있고 이루어져 있고 유저와 서비스에 각각 할당된다. 주로 EC2나 Lambda가 역할을 부여 받아 다른 서비스에 접근한다.
IAM Security Tools
IAM 자격 증명 보고서(Credentials Report) - Account level
모든 유저의 계정과 다양한 인증의 상태를 담은 보고서
IAM 엑세스 관리자 (Access Advisor) - User level
각 유저별로 언제 서비스에 마지막으로 접근했는지 등의 정보를 제공한다. 만약 서비스를 사용하지 않는다면 제거하는 등의 의사 결정을 수행할 수 있다.
IAM 가이드라인
Root 계정은 AWS 계정을 관리할 때 빼고는 사용하면 안된다.
각 사용자마다 하나씩 계정을 할당한다.
유저를 그룹에 넣고, 그룹에 권한을 할당한다.
MFA를 사용하고 또 사용하도록 강제한다.
AWS Role을 만들어 AWS 서비스에 권한을 할당한다.
프로그램적으로 접근할 때는 엑세스 키를 사용한다. (CLI/SDK)
IAM 자격 증명 보고서를 통해 각 계정의 권한을 분석, 감사한다
IAM 유저와 엑세스 키를 절대 공유하지 않는다.
💡
IAM Policy Simulator로 정책들을 실험할 수 있다.
실습하기
실습 1 : 관리자 계정 만들기
💡
root 계정이랑 똑같은 이름을 만들어도 상관은 없지만 되게 헷갈린다😉
실습 2: 관리자 계정으로 로그인하기
Root 계정이 아닌 사용자는 이 계정의 IAM 사용자를 위한 로그인 URL이라는 URL에 접속해서 로그인을 해야 한다. 계정 별칭을 만들 수도 있다. 같은 브라우저를 쓰면 로그인이 이미 되어 있기 때문에 실습을 할 수 없다. 크롬 시크릿 창을 이용하거나 다른 브라우저를 이용하자.
실습 3: 정책 만들기
Json을 쳐 넣어도 되고 GUI 편집기에서 만들어도 되지만 복붙을 하기 위해 Json을 사용하였다.
실습 4: CLI로 로그인하기
CLI를 사용하여 로그인을 하려면 먼저 콘솔에서 엑세스 키를 발급받아야 한다. 또한 리전을 선택해 주어야 하는데 나는 무조건 us-east-2 (Ohio) 선택한다.