AWS IAM으로 배우는 접근 통제의 기본 개념

AWS Identity and Access Management, 줄여서 AWS IAM은 아마존 웹 서비스에서 보안 측면에서 매우 중요한 서비스입니다. 하지만 마치 물과 공기처럼 너무 기본이 되는 서비스인데다가 별도로 과금도 안 되다 보니 오히려 소홀히 여겨지기도 쉬운 것 같습니다.

이번 포스팅에서는 AWS IAM을 통해서 접근 통제의 기본 개념을 함께 이해해보는 시간을 가져보려고 합니다. AWS IAM 자체를 어떻게 사용하는지는 인터넷에 이미 튜토리얼이 많으므로 굳이 다루지 않겠습니다.

AWS IAM 서비스

AWS에서 권한이란 어떤 서비스에서 어떤 리소스를 상대로 어떤 작업을 수행할 수 있는지 또는 없는지를 정의하는데요. 200개가 넘는 서비스로 이루어진 AWS에서 얼마나 많은 권한이 필요할지 굳이 설명드리지 않더라도 상상이 가능하시겠죠? 😅

따라서 AWS는 이렇게 엄두가 나지 않는 권한 관리에 대한 사용자의 부담을 덜어주고자 AWS IAM이라는 별도의 신원/접근 관리 서비스를 제공하고 있는데요. 개인이든 조직이든 안전하게 AWS를 사용하기 위해서는 이 AWS IAM을 제대로 이해하는 것이 매우 중요하겠습니다.

Policy (정책)

AWS IAM에서는 정책(policy)이라는 개념을 통해서 여러 개의 서비스에 걸쳐서 복수의 권한을 한 번에 정의할 수 있도록 해줍니다.

예를 들어, AWS S3에는 특정 버킷(bucket)을 상대로 저장된 객체를 읽거나 삭제하는 등 다양한 권한이 있을 것입니다. 또한 Dynamo DB에는 특정 테이블(table)을 상대로 아이템을 생성하거나 갱신하는 등 또 다양한 권한이 있을 것입니다.

AWS에서는 이렇게 다양한 권한의 모음을 하나의 정책이라고 하는 JSON 문서의 형태로 정의해놓고 관리할 수 있도록 해주는데요. 예를 들어, AWS S3의 모든 버킷에서 객체를 읽을 수 있고 Dynamo DB의 Books 테이블에 아이템을 쓸 수 있는 정책 문서는 대략 다음과 같은 모습일 것입니다.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:Get*", "s3:List*"],
      "Resource": "arn:aws:s3:::*"
    },
    {
      "Effect": "Allow",
      "Action": ["dynamodb:PutItem", "dynamodb:UpdateItem"],
      "Resource": "arn:aws:dynamodb:us-east-2:123456789012:table/Books"
    }
  ]
}

AWS에서는 수많은 권한 정책을 이미 정의해놓고 관리해주고 있기 때문에 사용자들은 필요에 따라 기 정의되어 있는 정책을 조합해서 편리하게 쓸 수 있습니다.

User (사용자)

개인 계정이 아니라면 대부분 조직에서는 하나의 AWS 계정 아래에 여러 사용자를 두게 되는데요. 그래야 각 구성원에게 AWS Console에 로그인할 수 있는 다른 username과 password를 발급해줄 수 있을테니까요.

AWS IAM에서는 사용자(user)라는 개념을 통해서 AWS 계정에 대한 조직 구성원의 접근 통제가 이루어집니다. 막 생성된 사용자는 AWS의 최소 권한 원칙(Least Privilege Principle)에 따라서 기본적으로 어떤한 권한도 없는데요. 따라서 사용자에게 크게 2가지 방식으로 접근 권한을 명시적으로 부여해줘야 합니다.

첫 번째는 다음 섹션에서 다룰 사용자 그룹(user group)에 해당 사용자를 일원으로 추가하는 것입니다. 그러면 해당 사용자는 그룹에 이미 할당되어 있는 정책(policy)을 통해 권한을 부여받게 됩니다. 두 번째는 해당 사용자에게 직접적으로 정책(policy)를 연결해주는 것입니다.

이 2가지 방식을 혼용할 수 있으나 사용자 그룹(user group)을 사용하는 편이 아무래도 좀 더 유연한 권한 관리에 도움이 될 것입니다.

참고로 AWS 계정을 처음 만들 때 생성되는 루트(root) 사용자는 해당 AWS 계정 내의 모든 리소스를 상대로 모든 작업을 할 수 있는 너무 강력한 권한이 있기 때문에 굳이 조직이 아니더라도 개인 계정도 IAM에서 사용자를 별도로 생성하여 필요한 권한만 할당해서 쓰는 것이 권장됩니다.

User Group (사용자 그룹)

AWS IAM에서 사용자 그룹(user group)은 말 그대로 여러 구성원으로 이루어진 하나의 사용자 집단을 나타내는데요. 관리자 그룹, DevOps 그룹, 개발자 그룹, DBA 그룹, QA 그룹 등을 생성해놓고 사용자 그룹 별로 서로 다른 권한을 주기 위해서 사용할 수 있습니다.

하나의 사용자 그룹에는 기본적으로 여러 개의 권한 정책(policy)를 연결시켜놓을 수 있는데요. 이를 통해서 특정 사용자 그룹에 속한 모든 사용자가 AWS의 리소스를 상대로 수행할 수 있는 작업 목록을 명시할 수 있습니다.

개별 사용자 단위가 아닌 사용자 그룹 단위로 권한 관리를 하면 여러 사용자를 대상으로 일괄적으로 권한을 부여하거나 회수하는 것이 매우 편리해집니다. 뿐만 아니라 한 사용자가 여러 그룹에 속할 수도 있기 때문에 복잡한 실제 조직의 구조에 맞춰서 세팅해놓고 사용하기도 용이합니다.

Role (역할)

AWS IAM에서 마지막으로 살펴볼 개념은 역할(role)인데요. 역할은 위에서 다룬 사용자(user)와 비슷한 개념이지만 AWS에서 인증을 위해서 사용할 수 없다는 차이가 있습니다. 따라서 역할은 보통 일반 사용자가 아닌 AWS 서비스에게 어떤 접근 권한을 주기위해서 사용되는데요.

예를 들어, EC2 인스턴스나 Lambda 함수가 AWS S3와 Dynamo DB에 접근해야한다면 역할을 통해서 관련 AWS의 API를 호출할 수 있도록 허용할 수 있습니다.

역할은 또한 여러 AWS 계정 간에 교차 접근 제어를 위해서도 사용할 수 있는데요. 이 부분은 본 포스팅의 범위에서 넘어가므로 언급만 하고 넘어가도록 하겠습니다.

마치면서

지금까지 살펴본 AWS IAM의 기본 개념들은 비단 AWS을 사용할 때 뿐만 아니라 접근 통제가 필요한 모든 애플리케이션에서 도움이 되는 개념입니다. AWS와 같은 방대한 클라우드 서비스에서 통하는 모델이라면 우리가 사용하거나 개발하는 왠만한 다른 애플리케이션에서도 문제없이 차용이 가능할테니까요.

예를 들어, HTTP 기반의 백엔드 API를 개발하신다면 각 엔드포인트(endpoint)가 리소스(resource)가 되고 GET, POST, PUT, DELETE와 같은 HTTP 메서드(method)는 해당 리소스를 상대로 수행할 수 있는 동작(action)이 될 것입니다. 이를 토대로 권한(permission)을 정의할 수 있다면 AWS IAM처럼 여러 개의 권한으로 이루어진 정책(policy)도 설계하여 각 사용자(user)에게 맞는 접근 권한을 부여할 수 있을 것입니다. 뿐만 아니라, 좀 더 복잡한 API에서는 사용자 그룹(user group)이나 역할(role) 개념도 도입하여 AWS 수준의 확장성있는 접근 관리도 고려해볼 수 있지 않을까요?

사실 이러한 개념들은 완전히 새로운 것이 아니라 AWS보다 더 오래된 프레임워크에서도 조금씩 다른 이름으로 쓰여왔기 때문에 어떤 프레임워크를 공부할 때도 도움이 될 수 있어요. 따라서 굳이 접근 통제를 밑바닥부터 직접 개발하지 않는 경우라도 숙지해두시면 좋을 것 같습니다.