IAM이란?
쉽게 말해서 AWS의 유저와 접근 권한을 관리하는 것이다.
그럼 그냥 '계정 설정(Account Settings)'이나 '로그인 창(Login)'이라고 쓰면 되지, 왜 굳이 IAM이라고 거창하게 서비스를 따로 만들어놓은 걸까?
내 추측이지만, 그만큼 AWS의 보안이 더 중요하고 까다롭기 때문에 그런 것 같다. 일반 포털 사이트나 온라인 쇼핑몰과 달리 AWS는 막대한 비용이 청구될 수 있는 클라우드 서비스를 다루고 있으며, 개인뿐만 아니라 기업 단위로 쓰기도 한다. 때문에 유저를 설정하고 권한을 부여하는 데 공을 들이는 게 어떻게 보면 당연해 보인다.
가능한 루트 계정 대신 IAM 유저로 접속해야 하는 이유
AWS을 아주 처음 시작했을 때 아이디를 만들고 패스워드 입력했다면 루트 계정(root account)를 한 번이라도 써본 것이다.
한 사용자(사람)는 하나의 루트 계정만을 가지고 있다.
리눅스를 써본 사람이라면 알겠지만, 루트 계정은 AWS에서도 마찬가지로 한 사용자의 모든 자원에 막힘없이 접근할 수 있다.
근데 이게 뭐 어때서? 굳이 IAM 유저를 여러 개 만들고 일일이 권한 설정할 필요 없이 루트 계정 하나만 있으면 언제든지 편하게 접근할 수 있는 거 아닌가?
하지만 만약 클라우드를 쓰는 주체가 개인이 아니라 기업이라면 어떨까? 처음에는 여러 개발자들이 루트 계정을 돌려가면서 쓸 수도 있다. 각 팀원마다 IAM 유저 만들어서 권한 설정하는 게 귀찮기도 하고, 개발만 해도 시간이 부족하기 때문이다.
근데 시간이 흐를수록 프로젝트 규모는 점점 커지고, 클라우드 비용도 증가한다. 그런데 여전히 개발자들은 루트 계정을 공유해서 쓰고 있다. 그러던 어느 날, 누군가 회사의 클라우드 계정이 해킹당했다는 사실을 깨닫는다. 급히 신고를 했지만, 이미 수십(또는 수백) 대의 인스턴스를 돌려놓고 있었기 때문에 며칠 만에 수천만 원어치의 손실이 발생했다.
물론 가상의 시나리오지만 충분히 일어날 법한 일이다. 왜 해킹을 당했을까?
금고가 아무리 많은 자물쇠로 잠겨 있어도, 결국 마스터키를 손에 쥐고 있는 사람이 너무 많았기 때문이다.
누군가 루트 계정 정보가 포함된 텍스트 파일을 (절대 이러지 말자) 카톡에 업로드했거나, 드라이브나 메일로 백업해 놓았는데 해커가 몰래 탈취해 간 걸 수도 있다. 여하튼 열쇠를 손에 쥔 사람이 많을수록, 단 한 번이라도 분실 사고가 일어날 가능성은 높아진다는 건 분명하다.
따라서 AWS를 이용할 땐 가능한 root user를 쓰지 않아야 한다. 대신 각 구성원의 역할과 업무 범위에 따라 IAM 유저를 따로 만들어야 한다. 귀찮고 번거로울수록 그만큼 보안은 철저해진다.
유저와 유저 그룹
유저와 유저 그룹 생성하기
AWS를 본격적으로 사용하기 앞서 가장 먼저 건드려야 할 건 IAM(Identity and Access Management)이다.
클라우드 서비스라는 비용에 민감한 자원을 사용하려면 보안과 접근 권한을 철저하게 설정하는 게 우선이다.
IAM 대시보드로 들어가면, region 설정이 Global로 되어있는 걸 확인할 수 있다.
즉 IAM 서비스는 (이것도 AWS 서비스의 일종이다) region을 따로 설정할 필요가 없고, region 자체를 활성화할 수도 없다. 유저 생성 단계는 다음과 같다:
- 유저 이름(User name) 만들기
- AWS Management Console의 접근 권한 여부 -> 'Yes'로 설정
- 콘솔(Console) 패스워드 - 자동 생성 vs. 수동 설정: '다음에 로그인할 때 새 비밀번호를 생성하도록 설정하시겠습니까?'라고 묻는데 이건 체크표시를 해제하자. 어차피 비밀번호는 수동으로 설정할 거고, 이후에도 이 비밀번호로 계속 접속할 것이기 때문이다.
- 유저의 권한 설정(Set permissions): 리눅스에 유저와 유저 그룹이 있는 것처럼, AWS에도 여러 사용자를 묶을 수 있는 그룹이 존재한다. 유저에 그룹을 설정 안 할 수도 있지만(그룹이 꼭 필수는 아니다) 가능한 그룹을 설정해 주는 게 좋다.
유저의 권한을 설정할 땐 permission을 하나씩 직접 부여할 수도 있지만, 보통은 policy를 선택하는 게 일반적이다. policy에 대해선 뒤에서 더 자세히 설명하기로 하자.
- 예를 들어 유저에게 모든 권한(바람직하진 않다)을 부여하고 싶다면, 1) 그룹 이름 지정 2) 권한 정책(permission policy) 중 AdministratorAccess를 선택하면 된다.
- 유저를 구별하기 쉽게 태그를 달 수도 있다. 예를 들어 key엔 회사 부서, value엔 프로젝트 이름이나 사원 이름, 아니면 기간을 적을 수 있을 것 같다.
IAM 유저로 로그인하기
방금 전 IAM 유저를 만들 때 AWS Management Console의 접근 권한 여부를 'Yes'로 설정했다면, AWS 콘솔에서 IAM 유저로 로그인이 가능하다.
AWS로 IAM 유저로 로그인하려면 일반적인 아이디 + 패스워드 조합 외에도 한 가지 정보가 더 필요하다.
바로 root account에 대응하는 계정 번호다. 만약 계정 번호 12자리를 외우는 게 힘들다면, alias를 만들 수도 있다.
IAM DashBoard > AWS Account에서 설정하면 된다.
- 계정번호 또는 alias
- IAM 유저 이름
- IAM 유저의 비밀번호
를 입력하면 된다. 간혹 1)과 2)를 헷갈릴 수도 있는데, 1)은 한 물리적인 사용자에 대응하는 12자리 계정 번호이므로 같은 사람이라면 1)은 매번 똑같아야 한다. 반면 2)와 3)은 IAM 유저를 여러 개 만들어놓았다면 서로 다를 수 있다.
IAM Policy란?
Policy는 세부 permission을 모아놓은 집합이다
AWS 서비스를 이용하기 위해선 권한(permission)이 있어야 한다. 그런데 AWS 서비스 종류가 워낙 많기도 하고 또 이 권한이라는 게 매우 세분화되어 있다.
비유를 들어보자. 금고를 연다고 했을 때, '금고 자물쇠를 보는 권한', '금고 자물쇠에 손을 댈 수 있는 권한', '금고 자물쇠를 따고 다시 잠글 수 있는 권한' 등등 각 행위마다 이름 붙일 수 있는 권한이 정말 많다.
그런데 금고를 지킬 사람을 고용해다가 (전산상으로) 권한을 부여한다고 가정해 보자.
매번 사람이 바뀔 때마다 많은 권한을 일일이 부여하는 게 참 귀찮고 힘들다. 근데 어차피 금고지기가 할 역할은 정해져 있으니까, 필요한 권한을 세트로 정리해 두면 편하지 않을까? 그래서 등장한 게 정책(policy)이다. 금고지기의 업무는 '금고를 수시로 열어서 내용물이 잘 들어있는지 확인'하는 것이다. 따라서 이 업무에 필요한 여러 권한을 하나로 묶어서 정리해 두는 게 더 편하다. 그리고 나중에 새 후임자(프로젝트에 새로 합류한 개발자나 팀원)가 와도 금고지기 역할에 맞는 정책을 부여하면 된다.
IAM Policy 다루기
AWS에서 IAM Policy는 json 문서 형식으로 편집, 저장할 수 있다.
이 말은 IAM Policy 일부를 텍스트로 복사, 붙여 넣기를 하거나 json 파일로 저장해서 어딘가에 다시 불러올 수도 있다는 뜻이다. 때문에 자유도가 높고 개발자에게 적합한 형식이다.
예시로 AmazonEKSClusterPolicy 내용을 살펴보자.
AWS 웹페이지에서 IAM > Policies에 들어간다. 아무 policy나 클릭한 다음, 우측에 'Summary' 버튼 대신 바로 옆의 'JSON'을 클릭하면 아래 같은 내용을 확인할 수 있다.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"autoscaling:DescribeAutoScalingGroups",
"autoscaling:UpdateAutoScalingGroup",
"ec2:AttachVolume",
"ec2:AuthorizeSecurityGroupIngress",
"ec2:CreateRoute",
"ec2:CreateSecurityGroup",
"ec2:CreateTags",
...
"kms:DescribeKey"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "iam:CreateServiceLinkedRole",
"Resource": "*",
"Condition": {
"StringEquals": {
"iam:AWSServiceName": "elasticloadbalancing.amazonaws.com"
}
}
}
]
}
다음은 IAM policy json 파일에 들어있는 항목이다.
- Version: policy 언어 버전으로, 항상 "2012-10-17"이 들어간다.
- Id: policy를 구별하기 위해 Id를 붙일 수도 있고 뺄 수도 있다(optional). 위 예시에선 없다.
- Statement: 이게 핵심이다. policy의 내용(어떤 행위, 어떤 리소스를 허용할지 등등)을 서술하는 부분이다.
주의사항
policy 중에 AdministratorAccess를 선택해서 json 내용을 보면 Action과 Resource가 모두 "*"로 적혀 있는 걸 확인할 수 있다. 정규표현식에서 "*"는 wildcard, 즉 0개 이상의 모든 문자에 해당하는 특수문자를 말한다.
마찬가지로 이 예시에서 "*"는 모든 행위/리소스를 다 허용하겠다는 뜻이다.
Statement는 다음 요소로 나뉜다.
- Sid: statement의 ID에 해당한다. Policy의 ID와 마찬가지로 있어도 되고 없어도 된다.
- Effect: statement에 명시된 리소스에 접근을 허용할지 말지 여부를 나타낸다. 'Allow' 또는 'Deny' 둘 중에 값 하나만을 쓸 수 있다. 기본(default) 값은 'Deny' 즉 리소스를 허용하지 않음 상태이다.
- Action: 어떤 행위를 허용할지 리스트 형식으로 나타낸다.
- Resource: 어떤 객체(object) 사용을 허용할지 나타낸다. S3 버킷이 될 수도 있고 테이블이 될 수도 있고 다양하다. IAM ARN(Amazon Resource Name) 규칙을 따른다.
- Condition: 언제 해당 policy의 효력을 발휘할지 나타내는 조건을 말한다. 위 예시에서는 안 보이는데, 이것도 Sid처럼 이건 optional이기 때문이다.
원하는 IAM Policy를 직접 만들 수도 있다
AWS에서는 이미 사전에 정의된 수많은 policy를 제공하지만, 본인 입맛에 맞게 직접 policy를 만들 수도 있다.
IAM > Policies > Create Policy 클릭 > Visual 또는 JSON 에디터 둘 중에 하나 선택하면 된다.
IAM 보안 강화하기
1. MFA(Multi Factor Authentication)
나는 컴퓨터에서 네이버에 로그인을 할 때마다 귀찮지만 2단계 인증을 꼭 거친다.
그래서 1차로 아이디와 패스워드를 입력해서 로그인하면,
모바일 기기에 알림이 온다. 여기서 다시 한번
'예'를 눌러야 네이버에 로그인할 수 있다.
AWS에도 유사한 기능이 있다. 바로 MFA(Multi Factor Authentifaction)이다.
MFA를 설정하면, 아이디와 패스워드로 AWS에 로그인을 해도 2차 인증을 거쳐야 한다.
현재 로그인하려는 기기(컴퓨터)가 아닌 다른 기기(핸드폰 등)에 설치된 Google Authenticator(모바일 only)이나 Authy(컴퓨터나 모바일 둘 다 가능) 앱을 사용해서 인증번호를 받아야 한다.
2. Password Policy 설정하기
해킹을 막는 가장 간단하고 확실한 방법은 비밀번호를 어렵게 설정하는 것이다.
IAM > Account Settings > Password Policy로 들어가서 customize 할 수 있다.
'AWS' 카테고리의 다른 글
| AWS EKS 실습 비용 분석하기 - 1편 (AWS EKS 요금/가격) (0) | 2024.04.14 |
|---|---|
| [AWS Week 1] Region과 Availability Zone (0) | 2024.04.02 |
