IAM 소개
IAM 이란?
IAM은 Identity and Access ManageMent의 약자로 사용자를 생성하고 그룹에 배치하는 글로벌 서비스에 해당한다.
AWS 계정을 만들었다면 모르는 사이 이미 IAM을 사용한 것이다. 계정을 만들 때 루트 계정을 만들었을텐데 이는 기본으로 생성되는 것이다. 만든 계정의 루트 사용자가 되는 것이다. 후에 서술하겠지만 루트 계정은 오직 계정을 생성할 때만 사용되어야 한다. 그 후에는 루트 계정을 더 이상 사용해서도, 공유해서도 안된다. 대신 사용자를 생성해야 한다.
IAM에서 사용자를 생성할 때 하나의 사용자는 조직 내의 한 사람에 해당된다. 필요하다면 사용자들을 그룹으로 묶을 수도 있으며 한 사용자가 다수의 그룹에 속할 수도 있다. 권장하는 방법은 아니지만 모든 사용자가 필수적으로 그룹으로 묶여야 하는 것도 아니다.
왜 사용자와 그룹을 생성할까?
이들이 AWS 계정을 사용하도록 허용하기 위함이다. 그리고 허용을 위해선 이들에게 권한을 부여해야 한다. 이를 위해 사용자 또는 그룹에게 정책 또는 IAM 정책이라고 불리는 JSON 문서를 지정할 수 있다.
IAM 정책은 특정 사용자, 혹은 특정 그룹에 속한 모든 사용자들이 어떤 작업에 권한을 가지고 있는지를 설명해 놓은 것이다. 이와 같은 JSON 문서를 통해 사용자들이 AWS 서비스를 이용하도록 허용하는 것이다.
이 정책들을 사용해 사용자들의 권한을 정의할 수 있게된다. AWS에서는 새로운 사용자가 너무 많은 서비스를 실행하여 큰 비용이 발생하거나, 보안 문제를 야기할 수 있기 때문에 최소권한의 원칙을 적용한다. 즉, 사용자가 꼭 필요로 하는 것 이상의 권한을 주지 않는 것이다.
IAM 정책
IAM 정책 예시
아래처럼 그룹이 나뉘어져 있다고 생각해보자.
- 개발팀: Alice, Bob, Charles
- 운영팀: David, Edward
- 감사팀: Charles, David
- 그룹 없음: Fred
개발자 그룹에는 Alice, Bob, Charles가 있다. 이때 IAM 정책을 그룹 레벨에 적용하게 되면 정책이 그룹의 모든 구성원에게 적용된다. 즉, 정책의 상속이 가능한 것이다.
운영자 그룹엔 David, Edward가 있다. 운영자 그룹은 개발자 그룹과는 다른 정책을 적용받을 것이다.
Fred는 그룹에 속해있지 않다. 이런 경우 사용자에게만 연결이 가능한 인라인 정책이라는 걸 생성할 수도 있다. 사용자가 그룹에 속해 있든, 아니든 원하는 사용자에게 인라인 정책을 적용 가능하다.
감사팀에도 정책을 연결할 수 있다. 이 경우 감사팀인 Charles와 David는 본인이 속한 각 그룹의 정책과 감사팀에 해당하는 정책도 상속하게 된다. 그럼 Charles는 개발팀과 감사팀의 정책, David는 운영팀과 감사팀의 정책을 적용받는 것이다.
IAM 정책 구조
- Version: 정책 언어 버전이며 보통은 날짜(ex: “Version”: “2012-10-17”)
- Id: 정책을 식별하는 Id (선택 사항)
- Statement: 하나 또는 여러 개일 수 있다.
- Sid: Statement의 Id로 문장의 식별자이다 (선택 사항)
- Effect: 명시적 정책에 대한 허용 혹은 차단
- Principal: 접근을 허용 혹은 차단하고자 하는 대상
- Action: 허용 혹은 차단하고자 하는 접근 타입 (Effect에 기반함)
- Resource: 요청의 목적지가 되는 서비스
- Condition: 명시적 조건이 유효하다고 판단될 수 있는 조건
IAM MFA 개요
IAM을 통해 사용자와 그룹을 만들었으므로 이러한 사용자와 그룹이 손상되지 않도록 보호해야 한다. 보호 방법에는 두 가지 방어 매커니즘이 있다. 첫 번째는 비밀번호 정책을 정의하는 것이고, 두 번째는 다중 인증 또는 MFA 이다.
비밀번호 정책 정의
비밀번호 정책을 정의하는 이유는 사용하는 비밀번호가 강력할수록 계정 보안이 강화되기 때문이다. 따라서 AWS에서는 다양한 옵션으로 비밀번호 정책을 설정할 수 있다.
최소 비밀번호 길이 설정, 특정 문자 유형 요구
- 대문자, 소문자, 숫자, 물음표와 같은 특수 문자를 포함할 수 있다.
- IAM 사용자들이 자신의 비밀번호를 변경하도록 허용하거나 허용하지 않을 수 있다
- 일정 시간 후에 사용자에게 비밀번호를 변경하도록 요구하여 비밀번호가 만료되도록 할 수 있다.
- 사용자가 비밀번호를 변경할 때 이미 설정하거나 이전에 설정된 비밀번호로 변경하지 않도록 비밀번호 재사용을 방지할 수도 있다.
다중 인증/MFA
MFA란 Multi Factor Authentication의 약자로 사용자의 비밀번호와 보안 장치의 조합을 사용한다. 예를 들어 로그인 시 비밀번호를 입력하는 것 이외에도 MFA 생성 토큰까지 인증된 후에야 로그인을 할 수 있는 것이다. MFA의 이점은 사용자의 비밀번호가 알려진 경우에도 해당 사용자의 물리적 장치도 확보해야 하므로 계정이 손상되지 않는다는 점이다.
일부 웹사이트에서 MFA를 이미 사용했을 수도 있지만 AWS에서는 필수이며 사용하는 것을 매우 권장한다.
AWS에서 MFA 장치 옵션에는 가상 MFA, 유니버설 세컨드 팩터 또는 UTF 보안 키, 하드웨어 보안 토큰 MFA가 있다.
가상 MFA
한 번에 하나의 전화에서만 작동하거나 인증을 사용하는 구글 인증기를 사용할 수 있다. 따라서 인증의 경우 단일 장치에서 여러 토큰을 지원한다.
즉, 가상 MFA 장치를 사용하면 루트 계정, IAM 사용자, 다른 계정, 다른 IAM 사용자를 가질 수 있다. 가상 MFA 장치에서 원하는 만큼 많은 사용자와 계정을 보유할 수 있으므로 사용하기 매우 간편한 솔루션이라고 볼 수 있다.
유니버설 세컨드 팩터 또는 UTF 보안 키
물리적인 장치다. 물리적 보안 키를 이중 인증의 일부로 추가하여 인증 보안을 강화하는 것이다. 해당 키는 단일 보안 키로써 여러 루트 및 IAM 사용자를 지원하기 때문에 사용자 수만큼 많은 키가 필요하지 않다.
하드웨어 보안 토큰 MFA 장치
AWS와는 다른 회사인 젬알토에서 제공하는 장치와 미국 정부 클라우드인 AWS GovCloud를 사용하고 있다면 SurePassID에서 제공하는 보안 토큰을 사용할 수도 있다.
AWS에 액세스하는 방법
AWS에 액세스하는 방법은 세 가지가 있다.
AWS 콘솔
사용자 이름 및 비밀번호와 다요소 인증으로 보호된다.
CLI(Command Line Interface)
이건 컴퓨터에서 설정하는 것으로 액세스 키에 의해 보호된다. 액세스 키란 자격 증명으로 터미널에서 AWS 액세스를 가능하도록 해준다.
AWS CLI는 명령줄 셸에서 명령어를 사용하여 AWS 서비스들과 상호작용할 수 있도록 해 주는 도구이다. AWS CLI를 사용하면 AWS 서비스의 공용 API로 직접 액세스가 가능하다. 또한 리소스를 관리하는 스크립트를 개발해서 일부 작업을 자동화할 수도 있다.
이런 이유로 AWS 관리 콘솔 대신 사용되기도 한다.
AWS SDK(Software Developer Kit)
AWS로부터 애플리케이션 코드 내에서 API를 호출하고자 할 때 사용되는 방식이다.
먼저 SDK란 소프트웨어 개발 키트로 특정 언어로 된 라이브러리의 집합이다. 따라서 프로그래밍 언어에 따라 개별 SDK가 존재한다. 이 방식을 사용해서도 역시 AWS 서비스나 API에 프로그래밍을 위한 액세스가 가능하도록 해준다.
하지만 SDK는 터미널 내에서 사용하는 것이 아니라 코딩을 통해 애플리케이션 내에 심어 두어야 한다.
두 번째와 세 번째 방식 모두 완전히 동일한 액세스 키로 보호가 된다.
액세스 키는 관리 콘솔을 사용해서 생성할 수 있으며 사용자들이 자신들의 액세스 키를 직접 관리한다. 사용자의 측면에서 액세스 키는 비밀번호와 마찬가지이다. 따라서 자신만의 액세스 키를 생성하게 되면 동료와 절대 공유해선 안된다.
AWS 서비스에 대한 IAM 역할
AWS 서비스 몇 가지를 사용자의 계정에서 실행하려면 어떤 권한이 필요하다. 따라서 AWS 서비스에 권한을 부여해야 한다. 그러기 위해서는 IAM 역할을 만들어야 한다.
IAM 역할은 사용자와 같지만 실제 사람이 사용하도록 만들어진 것이 아니고 AWS 서비스에 의해 사용되도록 만들어졌다.
예를 들어 EC2 인스턴스를 만든다면 해당 인스턴스는 AWS에서 어떤 작업을 수행하려고 할 수 있다. 그러기 위해선 EC2 인스턴스에 권한을 부여해야 한다.
이를 위해 IAM 역할을 만들어서 역할과 인스턴스를 하나의 개체체로 만든다. 이로써 인스턴스가 AWS에 있는 어떤 정보에 접근하려고 할 때 IAM 역할을 사용하게 될 것이다. 만약 역할의 권한을 올바르게 부여한 경우, 호출하고자 하는 것에 접근할 수 있을 것이다.
IAM 보안 도구
- IAM 자격 증명 보고서 (
계정 수준에서 가능)- 보고서는 계정에 있는 사용자와 다양한 자격 증명의 상태를 포함한다
- IAM 액세스 관리자 (
사용자 수준에서 가능)- 액세스 관리자는 사용자에게 부여된 서비스의 권한과 해당 서비스에 마지막으로 액세스한 시간이 보인다.
- 해당 도구를 사용하여 어떤 권한이 사용되지 않는지 보고 사용자의 권한을 줄여 최소권한 원칙을 지킬 수 있다.
IAM 모범 사례
- AWS 계정을 설정할 때를 제외하고는 루트 계정을 사용하지 말 것
- 루트 계정과 개인 계정이라는 두 개의 계정이 있어야 함
- 한 명의 AWS 사용자는 한 명의 물리적 사용자와 동일함
- 누군가 AWS를 사용하고 싶어하는 경우 자격 증명 정보를 제공하지 말고 새로운 사용자를 생성 후 사용자를 그룹에 할당하고 그룹에 권한을 할당하여 보안이 그룹 수준에서 관리되도록 할 수 있다.
- 강력한 비밀번호 정책을 만들 것
- 또한 다중 인증이나 MFA를 사용하여 계정이 해커로부터 더 안전할 것임을 실제로 보장할 수 있다면 서비스에 권한을 부여할 때 역할을 생성하고 사용하는 편이 좋다.
- 여기엔 프로그래밍 방식이나 CLI를 통한 AWS 사용할 때의 가상 서버인 EC2 인스턴스가 포함
- CLI 또는 일부 SDK에서 액세스 키를 생성해야 한다.
- 계정의 권한을 감사하기 위해선 IAM 자격 증명 보고서나 IAM 액세스 관리자 기능을 사용할 수 있다.
- IAM 사용자와 액세스 키를 절대 공유하지 말 것
IAM을 위한 공동 책임 모델
AWS의 경우
- AWS는 제공하는 모든 것에 책임이 있다.
- 인프라나 글로벌 네트워크 보안, 구성과 취약성 분석 그리고 책임 사항을 모두 준수하는 것이다.
즉, AWS는 모든 인프라에 관한 책임이 있다.
사용자의 경우
- 자체 사용자와 그룹, 역할과 정책을 생성하고 그 정책을 관리하고 모니터링하는 것
- 모든 계정에서 MFA를 활성화하고 시행하는 것
- 키를 자주 교체하는 것
- IAM 도구를 사용해서 적합한 권한을 적용했는지 확인하고 액세스 패턴을 분석하고 계정 권한을 검토하는 것
즉, 사용자는 인프라 사용에 관한 책임이 있다.
