AWS Certified Developer - IAM

Juls·2023년 12월 24일

AWS Certified Developer

목록 보기

3/6

시리즈의 첫번째는 AWS IAM 서비스이다. 아마 AWS에 처음 가입 후 가장 먼저 만져야할 서비스가 아닐까싶다. AWS에서도 권장하는 기본 원칙은, root 계정 사용을 자제하고 IAM user를 생성하여 최소한의 권한으로 접속하는 것이다. 심지어는 root로 접속하자마자 관리자 IAM user부터 생성하고, 또다른 최소 권한 사용자를 생성하여 필요한 권한이 있을때마다 root가 아닌 관리자 IAM user로 권한을 부여하기를 권장한다.
나는 이를 지키지 않아 한번 해킹을 당한 적이 있다(대략 4천만원 상당의 요금이 나왔던 것으로 기억한다). 경험 상 IAM 서비스와 root 계정 보호는 모든 서비스 중에서도 가장 중요한 서비스라고 강조해도 모자르지 않다고 생각한다. 여러분은 계정 보안을 철저히 하여 나와 같은 일을 겪지 않기를 바란다.

AWS IAM은 AWS 서비스의 접근과 자격증명을 관리하는 서비스이다. 처음엔 IAM user가 없으므로 root 계정이 가장 처음 접하는 서비스일 것이다.

IAM을 통해, user를 생성하여 팀원에게 전달하고, 필요한 권한을 부여하며, 접근 기록을 모니터링한다. 어떻게 이것들을 조절하느냐에 따라 보안이 상승하고, 권한 관리가 간편해지기도한다. 그럼 각 개념들이 어떤 상황에서, 어떻게 쓰이는지 알아보자.

Users

IAM user를 생성한다는 것은 이것을 생성한다는 의미와 같다. 실제 유저가 사용하는 것으로, 콘솔 접속을 하고, 이를 위해 패스워드를 소유한다.
Policy를 통해 권한을 부여할 수 있어, 필요한 서비스에 접근하도록 허가할 수 있다.
AWS에서는 root 계정을 사용하는 대신 이것, IAM user를 생성하여 사용하는 것을 권장한다. root 계정은 기본적으로 모든 권한이 오픈되어있기 때문에, 매우 "편리"한 계정이다. 그렇다. 해커에게도 매우 편리하므로, 본인만 알고있는 비밀번호로 설정한 뒤 계정을 마음속에 봉인하자.
대신 IAM user로 관리자 user를 생성하여 사용하면 된다.
root 계정과 마찬가지로, MFA를 반드시 사용한다. 비밀번호만으로는 계정 보안이 매우 취약하다. Google Authentication과 같은 앱이나 크롬 확장프로그램을 이용하면 된다.

Groups

IAM user를 묶어 하나의 그룹으로 관리할 수 있는 개념이다.
Group은 또다른 Group을 포함할 수 없다. 단 User 여럿을 포함할 순 있다.
이 역시 Policy를 통해 권한을 부여할 수 있는데, User 여럿을 포함할 수 있으므로 같은 권한을 부여할 User를 한 Group으로 묶고, 그 Group에 권한을 부여한다. 예를 들면, 부서, 팀과 같은 단체를 Group으로 관리하면 좋다.

Policy

리소스에 대한 User나 Group의 접근 권한을 정의하는 JSON 포맷의 document이다. 아래는 그 예시이다.

{
    "Version": "2012-10-17",
    "Id": "S3-Account-Permissions",
    "Statement": [
        {
        	"Sid": "1",
        	"Principal": {
            	"AWS": ["arn:aws:iam::121431:root"]
            },
            "Effect": "Allow",
            "Action": [
                "s3:Get*",
                "s3:List*",
                "s3:Describe*",
                "s3-object-lambda:Get*",
                "s3-object-lambda:List*"
            ],
            "Resource": "*"
        }
    ]
}

Version과 Id는 해당 정책에 대한 메타데이터일뿐이고, Statement가 중요하다.

Sid

Statement ID로, 정책의 식별자이다. JSON 정책 내에서 고유해야한다.

Principal

누구 혹은 어디에 정책을 적용할 것인지 적용 대상을 정의한다. 허용/거부와는 관계없다. 기본적으로 IAM user, IAM role, 서비스에 지정할 수 있고, 크로스 계정 액세스인 경우 12자리 식별자를 이용하여 계정을 지정할 수 있다.
*크로스 계정 액세스(Cross-account access): 한 계정의 IAM user가 타 계정의 리소스에 접근할 수 있는 방법이다.

Effect

Enum의 형태로, Allow 또는 Deny가 될 수 있다. 각각 해당 리소스에 대해 접근을 허가하는 정책을 정의할지, 거부하는 정책을 정의할지 결정하는 값이다.

Action

리소스의 어떤 동작에 대해 허가 또는 거부할지 정의하는 값이다. 예를 들어, s3:GetObject에 대해 Effect:Allow라고 하면 S3 리소스에 대해 객체 읽기 권한을 허가하겠다는 뜻이다.
Effect가 Allow일 경우, 기본이 되는 원칙이 있다. 바로 "최소한의 권한"이다. 어떤 유저가 필요로하는 권한이 있다면 해당 권한만을 Action에 추가해야한다. 와일드카드 표현식(asterisk; '*')의 사용이 가능하긴 하나, 가급적 사용을 자제하도록 하자. 향상된 보안을 유지하는 하나의 원칙이다.

Resource

정책의 대상 리소스를 정의한다.

Roles

AWS Service를 위한 권한이다. 특정 서비스가 다른 서비스에 접근할 수 있는 권한을 부여한다.
예를 들어, ECS task가 SQS에 접근하기 위해서는 권한이 필요하다. 이럴 때 SQS에 접근을 허가하는 role을 정의하고, ECS task에 role을 지정한다.
*SQS: AWS의 Simple Queue Service. 메세지 큐로 사용할 수 있는 서비스이다. CLI나 SDK를 통해 메시지를 읽을 수 있다.

Security

IAM에서 보안이란 MFA와 Password Policy를 합한 보안을 말한다. AWS Shared Responsibility Model라는 것인데, 사용자는 책임감을 가지고 MFA 등록을 촉진하고, Password Policy 운영으로 IAM user들의 보안 유지를 준수해야한다.
*AWS Shared Responsibility Model: AWS측과 사용자측 책임 공유 모델. AWS는 인프라의 정상적인 유지에 힘쓰고, 사용자는 IAM 유저의 보안 유지에 책임을 갖는다는 의미이다.
특히 IAM user뿐만 아니라 root 계정은 반드시 MFA를 등록하고, 비밀번호는 가급적 매우 높은 등급을 유지해야한다.

IAM Security Tools

IAM credentials report: account-level의 정보로, 모든 유저와 다양한 credential의 상태가 목록화된 리포트이다.
IAM Access Advisor: user-level의 정보로, 유저에게 부여된 서비스 권한과 그 권한의 마지막 액세스가 언제인지 보여준다. 고로, 어느 권한을 제거해도 되는지 확인할 수 있다. 사용하지 않는 권한의 방치는 "over-permission"일 뿐이다.