IAM 소개

IAM

• IAM : IAM은 AWS의 다양한 리소스로의 접근을 안전하게 관리하도록 해준다.
  AWS 환경 내에서 무엇을 할 수 있는지에 관한 권한을 컨트롤 할 수 있게 한다.

• Root account 은 백업 또는 financial 목적 외에는 사용하지 않는다.

주요 기능

• Users: IAM은 개개인의 "User"를 생성하고 관리하도록 해준다.
  해당 "User"의 Credential과 access key또한 마찬가지다.
  이는 User에게 특정 권한을 부여하여 User가 AWS 리소스에 접근하는 것을 제어할 수 있다는 말이다.

• Groups: Users를 Group에 포함시킬 수 있다.
  User가 아닌 Group에 권한을 부여할 수 있다.
  이는 권한의 부여와 회수를 한 번에 심플하게 처리할 수 있도록 한다.
  유저는 A라는 그룹에 속하면서 B라는 그룹에도 중복으로 속할 수 있다.

• Roles : IAM에서 Roles은 AWS 리소스에게 권한을 위임하는 방법이다.
  보통, 서비스나 AWS 인스턴스에 사용되며 위에 나온 User나 Group에는 사용하지 않는다.
  Role은 Policy와 연관되어 있는데 Policy는 어떤 액션이 어떤 리소스에서 동작하는지 정의한 것이라 볼 수 있다.

만약 S3에 Full Access 하는 Policy를 가진 Role을 EC2에 부여하면, EC2에서는 별 다른 Credential 없이 S3로의 접근이 가능하다. 이는 Node.js와 같은 개발환경에서도 마찬가지이다.

• Policy : IAM Policy는 User 또는 Group 또는 Role에 부여된 권한을 정의하는 JSON 문서이다.
  Policy는 Users, Groups, Roles에 땠다 붙였다 할 수 있다.
  어떤 액션을 allow, deny 할 수 있다.
  일반적으로 least privilege principle 원칙에 따라 최소한의 권한만 부여한다.
  예상치못한 비용 발생을 피하기 위해서이다.

MFA

Vulnerability

쉬운 비밀번호를 설정했을 때 다음의 취약성들이 발생한다.

• Weak Credentials
• Phishing
• Brute Force Attacks
• Misconfigured Security Settings
• and more

MFA

MFA는 Multi-Factor Authentication 이라고 부른다.
Multi-Factor Authentication은 User가 계정에 접속하거나 리소스에 접근할 때 두 개 이상의 인증을 해야만 하는 안전한 메커니즘이다.
기존의 아이디, 패스워드로 인증하는 것 외에도 하나의 안전장치가 주가되는 셈이다.

2개의 인증만 필요한 매커니즘은 2FA라고도 부른다.

• Virtual MFA Device : Users는 virtual MFA 디바이스를 사용할 수 있다. 예를 들어, Google Authenticator 또는 Authy 어플을 이용해서 time-based one-time passwords(TOTPs) 를 생성해 인증할 수 있다.

데스크탑으로 하려면 Authy를 이용한다.

• Hardware MFA Device : Hardware MFA 디바이스는 보통 차키(?)의 형태로 구성되어있는데 이것 또한 TOTPs 방식으로 인증한다.
  물리적인 토큰을 이용해서 인증하는 것을 선호하는 사람들이 사용한다.

차키(?)라고 직역했는데 "form of key fobs" 라고 영어로 표현되니까 대충 전자 리모트 키를 위한 물리적 장치 정도로 알고있자.

• SMS Text Message MFA : Users는 SMS 텍스트 메시지를 통해 MFA 코드를 받을 수 있다.
  그런데 이 방법은 SIM card swapping attacks과 또 다른 SMS-based 인증에 관한 취약점들 때문에 보안이 낮다. 그래서 안쓴다.

CLI

CLI

• AWS CLI는 AWS가 제공하는 통합 툴이다. CLI를 이용하여 Users가 그들의 AWS 리소스들과 서비스를 관리하고 상호작용 하도록 한다.
• 주요 기능 :
  • Cross-Service Compatibility : AWS CLI는 AWS 서비스의 넓은 범위를 컨트롤 할 수 있도록 지원해준다. 즉, 일관된 cli를 통해 EC2, S3 버킷, RDS 등과 같은 리소스들을 Users가 관리할 수 있다.
  • Scripting and Automation : AWS CLI는 스크립팅과 자동화 목적으로 광범위하게 사용된다.
    Users는 반복적인 tasks를 자동화하고 인프라를 배포하고 프로그래밍적으로 리소스들을 관리하는 스크립트를 생성할 수 있다.
  • Authentication and Security : AWS CLI는 다양한 인증 방법을 제공한다.
    AWS access keys, AWS IAM roles, temporary sessioon tokens을 예로 들 수 있다.
  • Customization and Configuration : Users는 CLI 환경을 설정할 수 있다. 기본 출력 포맷이나 리전 등 또 다른 기본 설정을 특정할 수 있다.
    이는 CLI 환경을 개인의 워크플로우 요구조건에 부합하느 맞춤형으로 커스텀 할 수 있다는 말이다.
  • Output Formats : AWS CLI는 JSON과 TEXT를 포함한 다른 출력방식을 제공한다.
    이는 다른 툴 또는 시스템과 통합하기에 편리하다.
  • Version Compatibility : AWS CLI는 규칙적으로 업데이트 된다. 따라서 AWS의 새로운 서비스와 기능들을 지원한다. Users는 AWS 환경에서 최신 기능들과 상호작용 할 수 있따.
  • Plugin Support : Users는 플러그인을 설치 및 사용을 통해 CLI 기능을 확장시킬 수 있다.
    플러그인은 AWS 또는 커뮤니티가 제공한다.

AWS Credential

IAM을 통해 Users의 Access key와 Secret Key를 생성할 수 있다.

AWS CLI 설치

AWS CLI를 이용하기 위해서는 설치가 필요하다.
설치방법은 공식문서를 참조하자.

AWS CLI 환경설정

aws configure 하면 초기 환경을 설정할 수 있다.
액세스 키와 시크릿 키, 리전, 출력 포맷을 안내에 따라 작성하면 된다.
다 작성하면 홈 디렉토리에 .aws 라는 숨김 폴더가 생성된다.
그 안에는 config 라는 파일과 credentials 라는 파일이 존재한다.
각각 region, output과 access key, secret key가 삽입되어 있다.
해당 key를 가진 User는 자신에게 부여된 policy 에 따라 권한이 설정된다.

IAM Role

• Trust Relationship : Roles는 trust relationship을 갖는다. trust relationship은 해당 role을 할당받은 사람 또는 특정 엔티티를 말한다.
  이 관계는 trust policy라는 JSON 문서에 기술되어 있다.
  Trust policy는 role을 할당할 수 있는 trusted principals(주체)가 나열되어 있다.
  예를 들어, AWS 서비스나 특정 IAM User가 해당 role을 할당받도록 지정할 수 있다.
  

• Permissions Policies : trust policy 뿐만 아니라, role는 permissions policies를 자신에게 땠다 붙였다 할 수 있다.
  Permissions policies는 trust relationship이 수행하는 특정한 액션(API operations)이 승인되거나 거부되는 것을 정의한다.
  이러한 policies은 JSON 포맷으로 쓰여졌고 세분화된 제어를 정의하기 위해 사용된다.
  AWS 서비스나 IAM User와 같은 trusted entity가 role을 이용해 AWS 리소스로 접근하기를 원할 때 trusted entity는 해당 role에 대한 임시 security credentials을 요청한다.
  이 credentials는 문제 없을 시 AWS Security Token Service(STS)를 통해 제공된다.
  그 후 해당 entity는 이 임시 credentials를 이용해 AWS 리소스에 접근한다.

S3에 모든 접근을 할 수 있는 policy를 role에 attach하고 role의 trust policy에 EC2를 설정해놓았다고 가정해보자.
EC2 콘솔에 접근해서 aws s3 ls 를 치면 credentials가 없다고 나온다.
해당 EC2에 위의 role을 적용한 후 다시 aws s3 ls 를 치면 정상적인 결과가 출력된다.

IAM Best Practice

• root account는 백업 및 finantial 목적 외에는 사용하지 말자.
• IAM User는 한 사람당 한 개씩 사용하도록 한다. 안그러면 나중에 관리가 힘들어진다.
• 항상 유저는 그룹에 넣고 그룹에 policy를 적용해서 관리하자.
• 패스워드는 가장 어렵게 만드는것이 좋다.
• MFA를 사용하자.
• AWS Service를 사용할 땐 항상 roles를 적용하자.
• AWS CLI를 사용할 때는 꼭 Access key를 사용하고 그 키는 로테이션 하자.
• 감사 목적으로 IAM credential reports와 IAM access advisor로부터 인사이트를 추출하자.
• IAM User와 access key는 공유금지

credential reports는 Users의 생성날짜, 언제 패스워드를 바꿨는지, MFA 설정이 되어있는지 등을 볼 수 있다.
access advisor는 User가 associated 되어있는 모든 permission에 대한 활동을 볼 수 있다.