인사이트리포트

들어가며

최근 클라우드 컴퓨팅 서비스의 여러 장점들로 인하여 클라우드를 도입하는 기업과 개인들이 많아지고 있다.

이로 인하여 수십 명 이상의 사용자들이 클라우드 자원에 동시에 접근하게 되면서 각 사용자들의 인증(ID) 정보를 관리하고, 사용자에 따른 권한을 관리하기 위한 보안적 측면이 중요시되고 있다.

아래에서는 대표적인 퍼블릭 클라우드 중 하나인 AWS(Amazon Web Service) 에서의 접근제어 방식을 간단하게 살펴보면서, 접근제어란 무엇인지 이해해보고 접근제어를 어떤 방식으로 설정할 수 있는지, 그리고 조심해야 할 부분에 대해서도 이야기해보고자 한다.

이에 앞서 클라우드 환경에서 접근제어가 필요한 상황을 여러 예시들을 통해 생각해보도록 하자.

• 로그인하지 않은 사용자는 웹서비스(콘솔)에 접근할 수 없다.
• 어떤 사용자에게는 사용자 목록을 조회할 수 있도록 허용하고, 다른 사용자는 사용자 목록을 조회하지 못하도록 금지한다.
• 어떤 사용자는 “instance1” 아이디를 가진 EC2 인스턴스를 조회할 수 있지만, 해당 인스턴스를 수정하거나 삭제하지는 못하도록 금지한다.
• 개발 부서에 속한 사용자는 EC2 인스턴스를 실행(run)할 수 있지만, 개발 부서가 아닌 사용자에게는 해당 인스턴스를 조회만 할 수 있도록 제한한다.
• 업무시간 등 특정 시간대에는 S3 오브젝트를 수정하는 것이 가능하지만, 이외의 시간에서는 해당 S3 오브젝트를 수정할 수 없도록 금지한다.

조금만 생각해봐도 위와 같이 다양한 케이스들을 떠올릴 수 있다. 물론 모든 사용자에게 모든 권한을 부여한다면, 관리자 입장에서는 사용자마다 일일이 권한을 주지 않아도 되므로 편리하겠지만, 당연하게도 이는 매우 위험하고 잘못된 생각임에 분명하다. 자신도 모르는 사이 누군가가 자신이 생성한 자원을 삭제하여 운영 장애가 발생하거나, 또는 누군가 실수로 자원의 사이즈를 매우 크게 늘려 예상치 못한 비용 등이 과다하게 청구될 수도 있다. 따라서 각 사용자들에게 적당한 권한을 부여하는 것이 중요하며, 더 나아가 각 사용자가 필요로 하는 최소한의 권한만 제공해주는 것이 합리적인 방식이라고 생각해볼 수 있다. (이를 최소 권한의 원칙 (POLP, Principal of Least Privilege : 각 사용자에게는 필요로 하는 최소한의 권한만을 부여하는 원칙) 이라고 하며, 접근제어를 고려할 때의 지표 중 하나가 된다.)

여기서 누군가는, 각 사용자들이 할 수 있는 행위들을 각각 나열해두면 되지 않겠느냐 라고 생각할 수 있지만, 만약 클라우드 서비스나 자원을 관리하는 사용자가 수백 명이 넘어가고, 매 시간마다 새로운 자원들이 생성되는 상황을 생각해보자. 조금만 생각해보아도, 위와 같은 방법으로는 점점 더 커지는 클라우드 환경 속에서 사용자들의 접근을 체계적으로 관리하기 어렵다는 생각에 쉽게 도달할 수 있다. 이에 더해 만약 위의 예시처럼, 특정 시간대와 특정 위치에서 호출한 요청은 허용하고 그 외에 들어온 요청은 금지한다거나, 또는 특정 속성을 가진 리소스만 접근할 수 있도록 하는 등의 관점에서도 생각해볼 필요가 있다. 이처럼 다양한 관점에서 접근제어를 세밀하게 설정할 수 있는 시스템이 필요하다는 사실을 느끼게 될 것이다.

이처럼 사용자의 인증 정보(ID) 관리와 권한, 자원에 대한 접근 관리 등을 제공하는 서비스 또는 개념을 IAM(Identity and Access Management) 라고 칭한다. 이처럼 IAM이란 여러 방면에서 접근제어를 아우르는 넓은 개념이나, 본문에서는 각 사용자들의 권한을 관리하는 방법에 초점을 맞추어 이야기해 보고자 한다.

그렇다면 AWS에서는 IAM 서비스가 어떤 방식으로 동작하는지, 나아가 일반 사용자들이 AWS에서 접근제어를 어떻게 사용할 수 있는지를 예제를 통해 간단히 살펴보도록 하자.

AWS IAM 동작 방식

AWS IAM의 동작 방식을 살펴보기 앞서, 권한 관리란 어떠한 테두리(공간) 내에서 동작한다는 점을 짚고 넘어가야 한다. 예로 고등학교에서 각 학년과 반들이 나뉘어져 있고 반에는 담임 교사와 학생들이 있는 상황을 떠올리면 이해하기 쉽다. 각 학급(공간)마다 담임 교사와 반장이라는 직급이 있듯이, IAM 또한 어떤 공간(학급 반)을 기준으로 권한을 관리한다고 볼 수 있다. AWS IAM에서는 AWS 계정(AWS Account) 이 이 공간이라고 볼 수 있다.

AWS 계정이란, 실제 사람이 AWS 콘솔을 통해 AWS에 가입했을 때의 계정을 일컫는데, 가령 누군가가 test@gmail.com 이메일로 AWS에 가입하였다면, test@gmail.com 계정이 생성된다고 보면 된다.

그리고 이렇게 생성한 하나의 계정 안에서 여러 클라우드 자원들과 (가상의) 여러 사용자들이 생성되고, 권한을 부여 받고 해당 리소스들에 접근하게 된다.

여기서 계정과 사용자라는 단어가 계속 등장하는데 이를 정리하고 넘어가도록 하자. AWS IAM에서의 사용자는 크게 다음과 같이 구분할 수 있다.

• 루트 사용자: AWS 계정 생성 시 만들어지는 사용자로, 해당 계정 내에서 AWS의 모든 서비스를 곧바로 이용 가능하고 모든 리소스에 접근할 수 있는 권한을 가지는 사용자

• IAM 사용자: 루트 사용자가 생성하는 사용자로, 루트 사용자가 자신의 클라우드 서비스 및 자원을 관리하려는 사람들에게 발급해주는 가상의 사용자

간단히 예를 들면, 위에서 test@gmail.com 에 해당하는 사용자가 루트 사용자이며, 자신의 클라우드 자원을 이용하고자 하는 세 명의 사람에게 TestUser_1, TestUser_2, TestUser_3 과 같은 IAM 사용자를 만들어 하나씩 제공하는 것이 IAM 사용자라고 볼 수 있다.

위의 설명을 통해, 권한 관리가 어떠한 공간을 단위로 동작한다는 점과, AWS IAM에서는 그 공간이 계정에 해당한다는 것을 확인하였다. 아래에서는 AWS IAM의 전체적인 동작 방식을 그림과 함께 확인해보도록 하자.

1. 주체(사용자)-> 인증(로그인) -> 요청

주체(Principal) 란 간단하게, 어떤 요청을 할 수 있는 대상을 의미하며 위의 IAM 사용자나 루트 사용자 등에 해당한다. (IAM 역할도 주체에 해당하지만 본 글에서는 다루지 않음)

 예시) 어떤 사람이 “TestUser_1” 이라는 IAM 사용자로 로그인해서 어떤 동작을 요청

2. 권한 여부 확인

앞서 주체가 인증(로그인)을 거친 후 요청을 수행하는 것까지 진행하였다.

이번에는 주체가 실제 요청을 수행할 권한이 있는지 판단해야 하는데 이를 인가(Authorization) 라고 한다.

주체의 권한을 검사해보고 권한이 있으면 요청을 수행하고, 권한이 없다면 요청을 수행하지 않는다.

3. 동작 수행

앞선 과정들로부터 주체가 요청을 수행할 권한이 있음을 알았다면, 최종적으로 요청이 수행된다.

가령 요청이 “EC2의 어떤 인스턴스를 실행하라” 이었다면 EC2 서비스는 해당 요청을 받아들여서 그 인스턴스를 실행할 것이다.

또 다른 예로, 만약 요청이 “IAM의 어떤 사용자를 삭제하라” 이었다면 요청에 명시된 IAM 사용자를 삭제하도록 동작할 것이다.

사용자, 그룹 및 권한 연결이번에는 직접 IAM 사용자를 등록하여 확인해보도록 하자. 아래는 루트 사용자로 접속한 후, IAM 사용자 TestUser_1, TestUser_2, TestUser_3 을 등록한 화면이다.

IAM 사용자 상세 화면에 들어가보면 (아래 그림 참고), 현재 열려있는 탭에 권한 추가하기 (Add Permissions) 라는 버튼을 볼 수 있다.

(권한은 아래에서 다시 다뤄보기로 하고, 여기서는 IAM 사용자에 권한이라는 것을 연결할 수 있다 정도로만 기억하고 넘어가자.)

또한 Permissions 탭 바로 옆의 Groups 탭을 통해 IAM 사용자를 그룹에 연결할 수도 있다.

<IAM 사용자 상세화면>

여기서 그룹(Group)이란, 간단히 IAM 사용자들을 모아둔 개념이라고만 이해하여도 충분하다.

그리고 그룹도 IAM 사용자와 마찬가지로 권한이 연결될 수 있음을 알아두자. (참고로 IAM 사용자는 여러 개의 그룹에 포함되는 것이 가능하다.)

그럼 IAM 사용자는 자신에게 직접 권한을 연결되거나 또는 권한이 연결된 그룹들에도 포함될 수 있는데, 그렇다면 한 명의 IAM 사용자가 여러 개의 권한에도 연결될 수 있는 것일까? 이에 대한 답은 “그렇다” 이며, 이와 같이 사용자 한 명에게 권한이 여러 개 연결된 경우에 대해서는 아래에서 다시 살펴보기로 하자.

Tip) 개인적인 관점에서는 각 사용자에게 직접 권한을 연결하는 방식의 경우, 사용자 별로 어떠한 권한을 가지고 있는지 파악하기가 번거롭기 때문에, 장기적으로 볼 때 관리해야 할 부분이 불필요하게 늘어난다고 생각된다.

따라서 반드시 필요한 경우가 아니라면 사용자에게 직접 권한을 연결하는 방법보다는, 같은 권한을 가진 사용자들을 모아서 그룹 단위로 권한을 관리하는 것이 좀더 관리 측면에서 유리한 방법이 아닐까 여겨진다.

권한과 정책

우선 권한이란 어떤 행위나 동작을 할 수 있는 자격을 나타낸다고 생각해볼 수 있다. 따라서 아무런 권한도 부여 받지 않은 사용자는 어떠한 행위도 할 수 없게 된다. 반대로 권한이 있다면 어떤 행위를 할 수 있는 자격이 있다고 볼 수 있다. 그럼 권한은 항상, 모두 있거나 또는 모두 없어야만 할까? 본문 초반부의 예시를 떠올려보면, 특정 리소스를 읽을 수는 있지만 해당 리소스를 수정하거나 삭제할 수는 없도록 금지하는 등의 제한이 필요할 수 있다. 나아가, 사용자가 수행할 수 있는 모든 행위들을 각각 정의해 놓는다면 그만큼 사용자들의 권한을 세밀하게 관리할 수 있다는 의미가 된다.

AWS IAM에서는 이와 같은 행위들을 미리 정의하여 제공하고 있다. EC2 인스턴스를 모니터링하는 행위, 인스턴스를 실행시키는 행위 등이 그에 대한 예시라고 볼 수 있는데, AWS에서는 이러한 각각의 행위들을 AWS 액션(AWS Action) 이라고 부른다. 즉 사용자의 권한을 최소로 나누는 단위는 이 액션에 해당한다. (사용자에게 EC2 인스턴스를 모니터링하는 액션을 연결하면 사용자는 인스턴스를 모니터링할 수 있고, 만약 EC2 인스턴스를 실행하는 액션을 연결하면 사용자는 EC2 인스턴스를 실행할 수 있다.) 이때 하나하나 액션을 지정하기 번거로운 경우에는, 아래와 같이 서비스에 등록된 모든 액션을 한꺼번에 표현하는 것 또한 가능하다.

• 개별 액션 표현 방법 – ec2:MonitoringInstances, ec2:RunInstances, iam:GetUser
• 서비스에 속한 모든 액션을 표현하는 방법 – ec2:*

그리고 이러한 액션들을 하나 이상 모아둔 액션 묶음을 만들어 사용자에게 연결하면, 해당 사용자는 그 묶음에 있는 액션들을 모두 수행할 수 있게 된다. 그렇다면 만약, 권한을 주고 싶지 않은 경우에는 이를 어떻게 표현할 수 있을까? 가령 사용자들이 instance1 이라는 특정 EC2 인스턴스는 삭제하지 못하도록 금지하는 경우에 해당한다. 이와 같은 케이스를 수용하기 위하여, 권한은 액션을 항상 허용하는 형태만이 아닌, 액션을 금지해야 하는 경우도 함께 고려되어야 한다. (추가로, instance1 에 대한 정보도 어딘가에는 명시해둘 수 있어야 한다.)

따라서 이러한 내용들을 모아둘 대상이 필요한데, AWS IAM에서는 이를 AWS 정책(AWS Policy) 이라고 정의하고 있다. 그리고 이러한 정책에 연결된 사용자는, 자신이 연결된 정책에 명시되어 있는 대로 권한을 따르게 된다. 여기서 위의 예시들을 다시 정책의 관점에서 생각해본다면 아래와 같은 형태일 것이다.

• 정책 A : IAM 사용자 목록을 조회할 수 있다.
• 정책 B : IAM 사용자 중 id=1인 IAM 사용자는 삭제할 수 없다.
• 정책 C : EC2 인스턴스를 모니터링할 수 있다.
• 정책 D : id=instance1 인 EC2 인스턴스는 삭제할 수 없다.

쉽게 생각하여, 만약 IAM 사용자 TestUser_1에게 정책 A, C를 연결하면 TestUser_1은 (정책 A에 의해)IAM 사용자 목록을 조회할 수 있고 (정책 C에 의해)E2 인스턴스를 모니터링할 수 있는 권한이 주어진다고 생각하면 이해하기 쉽다.

예시로 EC2 서비스의 GetInstanceUefiData, StartInstances 액션을 포함한 정책을 확인해보자.

여기서 Resources 부분을 살펴보면, instance와 license-configuration 항목이 있는 것을 볼 수 있다. 이는 위에서 지정한 액션들(GetInstanceUefiData, StartInstances)이, 대상으로 하는 자원들이 있기 때문에 이를 지정해준 것이다. 예로 StartInstances 액션은 이미 존재하는 EC2 인스턴스 자원을 시작하는 작업으로, 모든 EC2 인스턴스가 아닌 특정 EC2 인스턴스만 시작할 수 있도록 제어하고 싶을 수 있다. 이처럼 액션들 중에서는 자원에 따라 권한을 제어하고 싶은 경우가 있는데, 이러한 액션들은 자원 단위로도 권한을 설정할 수 있다. 예로 id가 “test”으로 시작하는 EC2 인스턴스만 중지시킬 수 있는 정책을 만들고 싶다면, 아래와 같이 대상 자원 정보를 입력하여 정책을 구성할 수 있다. (참고로 AWS는 각 자원들을 유일하게 식별하기 위해 ARN(Amazon Resource Number)를 사용하는데, 자원마다 유일하게 정해지는 값 정도로 이해하면 될 듯하다.)

위 내용을 다시 정리해보자면, AWS에서는 권한을 검사할 각각의 독립적인 행위들을 액션이라고 부르며, 몇몇 액션들을 묶어놓은 것이 하나의 정책에 해당한다고 볼 수 있다. 추가로, 이러한 정책에는 해당 액션들과 그 액션들을 허용할지 또는 금지할지에 대한 여부, 그리고 대상이 되는 자원 정보 등을 나열할 수 있는 구조를 가진다. 최종적으로 해당 정책들이 사용자에게 연결됨으로써 사용자는 해당 정책에 명시되어 있는 권한이 적용되게 된다고 이해하면 될 것 같다.

ABAC을 활용한 보다 세밀한 권한 제어

앞서 정책에 대하여 살펴보았으며, 사용자의 권한은 연결된 정책에 의해서 결정된다는 것을 알아보았다. 그렇다면 같은 정책들에 연결된 사용자들은 어느 경우에나 항상 같은 권한을 가지게 될 텐데, 실제로는 보다 더 세밀하게 권한을 관리하고 싶은 경우가 있다. 가령 현재 요청한 사람의 부서나 접속한 IP, 요청한 시간 그리고 자원이 위치해있는 리전 등에 따라 더욱 정밀하게 권한을 제어하고 싶은 경우가 있다.

권한 관리에서는 일반적으로 이와 같은 정보(사용자의 부서, IP, 자원의 위치 등)를 속성(Attribute) 이라고 부르고 있다. 사용자의 부서가 “개발팀1” 이라면 해당 사용자의 “부서” 속성에 대한 속성값은 “개발팀1”이 되는 셈이다. 그리고 이러한 속성에 따라 권한을 세밀하게 제어하는 것을 ABAC(Attribute Based Access Control) 이라고 부른다.

그렇다면 위에서 설명한 정책에 ABAC이 적용되는 것을 생각해보자. 우선 지금까지 정의한 정책은, 간단하게 “A 액션을 (R 리소스에 대해) 허용/금지한다.” 와 같은 구조로 나타낼 수 있다. (참고로 리소스 부분을 괄호로 표시한 이유는, 액션에 따라 대상 리소스가 없을 수도 있기 때문) 여기서 속성을 검사하는 조건을 추가한다면 다음과 같이 표현될 수 있다: “어떤 C 조건을 만족하는 경우, A 액션을 (R 리소스에 대해) 허용/금지한다.” 여기서 어떤 조건이란, 위에서 예시로 들었던 사용자의 부서일 수도 있으며 또는 사용자가 접속한 IP 등등 다양한 조건들이 들어올 수 있다.

이해를 돕기 위해 “요청의 IP가 100.100.100.0/24 대역이고, 리전이 us-east-2 인 경우에만 EC2 서비스의 모든 액션을 허용한다.”  라는 정책을 예시로 들어보자.

<정책 예시 1>

위의 그림에서 Request Conditions 부분을 보면 Source IP가 체크되어 있고 100.100.100.0/24 가 입력된 것을 볼 수 있는데, 이는 요청이 들어왔을 때 IP가 해당 대역에 속할 경우에만 이 정책을 적용하라는 의미로 해석된다. 그리고 바로 아래에는 ec2:Region (StringEquals us-east-2) 가 따라오는 것을 볼 수 있는데, 이는 리전이 us-east-2 인 경우에만 이 정책을 적용하라는 것으로 이해할 수 있다. 따라서 위 정책에 연결된 사용자는, IP 조건과 리전 조건을 모두 만족한 경우 정책에 명시된 액션들을 수행할 수 있음을 의미한다. 당연하게도 이러한 속성은, 위의 두 경우 말고도 무수히 많은 속성들이 존재할 수 있다.

그렇다면 위의 IP나 리전 조건처럼, 이미 AWS에 정의되어 있는 속성들만 사용이 가능한 것일까. 가령 사용자가 자신이 속한 부서의 자원들만 접근할 수 있도록 하고 싶은 경우이다. (아마 “부서”라는 속성은 기 정의된 AWS 속성 중에는 없을 것이다.) 이처럼 원하는 속성이 없는 경우에는 임의로 속성을 만들어서 권한 검사할 때 사용하는 것이 가능하다. 가령 “부서”를 속성으로 만들면, 각각의 IAM 사용자는 그 속성에 대한 값(e.g. “개발1팀”, “개발2팀”, “경영팀”, …)을 지정해줄 수 있게 된다.

아래는 사용자가 “개발1팀” 에 속해 있는 경우에만 타 IAM 사용자의 패스워드를 바꿀 수 있는 정책 예시에 해당한다. Request Conditions에서 aws:PrincipalTag/부서 (StringEquals 개발1팀) 부분을 해석해보면, 해당 요청을 한 사용자의 “부서” 속성이 “개발1팀” 인 경우에 ChangePassword 액션을 수행할 수 있다 라고 이해하면 된다.

이와 같이 원하는 속성을 키와 값 형태로 지정하여 권한 관리에 이용할 수 있는데, AWS에서는 이를 Tag라고 부른다. (위에서는 “부서”가 태그 키에 해당하며, “개발1팀”과 같은 값들이 태그 값에 해당한다.)

이를 응용하여 하나의 예시를 더 살펴보도록 하자. 만약 자신이 속한 부서에 등록된 EC2 인스턴스만 모니터링 할 수 있도록 제한하고 싶은 경우를 생각해보자. 위에서는 단순히 사용자가 “개발1팀” 부서인지 검사하였으나, 이번에는 접근하려는 자원의 부서가 사용자의 부서와 같아야 하는 상황이다. 이러한 경우는 아래 그림과 같이, 자원의 부서 속성이 요청한 사용자의 부서 속성과 같은지 검사하는 조건을 정책에 추가할 수 있다. 참고로 아래 정책에서 사용된 ${aws:PrincipalTag/부서} 표현식은, 현재 요청한 사용자의 부서를 가리키는 값이라고 생각하면 된다. (“부서”:“개발1팀” 인 사용자가 요청을 날린 경우 위의 표현식은 “개발1팀” 값을 가지게 된다.)

참고로 AWS는 요청의 주체나 자원 등으로부터 동적으로 속성값을 참조할 수 있는 표현식들을 제공하는데, 이처럼 키에 사용될 수 있는 표현식들을 AWS 글로벌 조건 컨텍스트 키(AWS global condition context keys) 라고 부른다. 예로 주체의 유형을 가리키는 aws:PrincipalType, 요청의 IP를 가리키는 aws:SourceIp, 사용자의 id를 가리키는 aws:userid 등 매우 다양한 표현식들이 존재한다는 점을 참고로 알아두자.

위에서는 권한을 더욱 세밀하게 제한하기 위한 방법들을 살펴보았다. ABAC의 개념과 접근제어를 보다 세분화하여 처리하는 방법, 그리고 이를 통해 얻을 수 있는 이점 등에 대하여 알아보았다. 나아가 AWS에서는 어떤 방식으로 ABAC 기능을 제공하고 있는지에 대해 알아보고, 사용자가 검사하기를 원하는 속성들을 태그를 활용하여 권한을 검사하는 방법 등, 다양한 방법으로 권한을 제한하는 방법에 대하여 살펴보았다. 물론 깊은 내용들까지는 다루지 않았지만, 이쯤으로 정책과 관련된 설명은 마무리하기로 하고, 마지막으로 사용자가 여러 개의 정책들과 연결된 경우에 대하여 살펴보자.

사용자가 여러 개의 정책에 연결된 경우

앞서, 사용자는 자신에게 직접 정책이 연결되거나 또는 그룹을 통해 여러 개의 정책과 연결될 수 있음을 알아보았다. 그렇다면 사용자가 여러 개의 정책에 동시에 연결되어 있는 경우가 있을 텐데, 이런 경우에는 어떤 기준으로 권한이 있는지 판단하게 되는 것일까.

우선 가장 간단한 경우로, 만약 사용자에게 연결된 정책이 없거나 연결된 정책 중에서 요청한 액션에 매칭하는 정책이 없는 경우를 생각해보자. 위의 예시를 빌리자면 사용자가 요청한 액션은 CreateVpc인데, 사용자가 연결된 정책의 액션은 MonitorInstances만 있는 경우이다. 당연하지만 이 경우에는 사용자가 해당 요청을 수행할 권한이 없다는 것을 알 수 있다.

사용자에 연결된 정책이 여러 개인 경우를 언급하기 전에, 앞서 정책은 액션을 허용하는 정책과, 액션을 금지하는 정책으로 분류될 수 있음을 언급하였다. 따라서 사용자가 허용 정책과 거부 정책에 동시에 연결되어 있는 경우도 고려해보아야 한다.

아래, 액션을 금지하는 정책을 하나 살펴보자. (빨간색 레이블의 DENY로 된 부분을 주목하자.) 우선 해당 정책을 해석해 보자면, TerminateInstances라는 액션을 EC2의 my-instance-100 인스턴스에 대해 금지하는 정책이라고 볼 수 있다. (여기서 조건에 대한 설명은 생략하였음)

<정책 예시 3>

만약 사용자가 한 요청이 허용 정책과 거부 정책이 동시에 적용되는 경우에 해당한다면, 거부 정책을 우선시하여 권한이 검사된다. (즉 사용자가 10개의 정책 중 9개에서 요청한 액션에 대해 권한이 있다고 하여도, 1개의 정책이 해당 액션을 금지하는 정책이라면 권한을 얻을 수 없음)

이해를 돕기 위하여 사용자에 연결된 정책이 아래와 같은 경우를 생각해보면, 사용자는 3번 정책에 의해 my-instance-1 인스턴스를 삭제할 수 있는 권한이 없게 된다.

• 사용자에 연결된 정책

1번 정책 : “EC2: TerminateInstances 액션을 모든 리소스에 대해서 허용한다.”

2번 정책 : “EC2: TerminateInstances 액션을 my-instance-1 에 대해서 허용한다.”

3번 정책 : “EC2: TerminateInstances 액션을 my-instance-1 에 대해서 금지한다.”

• 권한 수행 결과
• 권한 없음 (3번 정책에 의하여)

거부 정책을 더 우선시하는 검사방법은 합리적이라고 생각되는데, 그 이유는 만약 허용 정책을 우선시할 경우 관리자가 알지 못하는 사이 불특정 다수의 사용자들에게 권한이 부여될 수 있는 문제가 발생할 수 있다. 이는 위에서 언급한 최소 권한의 원칙 관점에서 생각해보았을 때, 사용자가 필요로 하는 최소한의 권한만 부여한다는 원칙에 어긋난다고도 볼 수 있다. (즉 허용 정책보다 거부 정책을 우선시하는 것이 사용자에게 보다 더 적은 권한을 부여하는 방법이라고 볼 수 있다.)

본 문단을 통하여, 사용자에게 여러 개의 정책이 연결된 경우 권한이 결정되는 방법과 판단 근거에 대해서도 간략하게 살펴보는 시간을 가졌다.

마치며

지금까지 클라우드 환경에서의 접근제어가 필요한 이유와 AWS에서의 접근제어 방식에 대하여 간단하게 살펴보았다. 우선 본 글을 통하여 클라우드 컴퓨팅 환경에서 접근제어의 필요성에 대하여 생각해보는 계기가 되었으면 좋겠으며, 만약 클라우드 서비스를 이용중인 독자라면 현재 사용자와 자원들에 대해 권한을 느슨하게 관리하고 있지는 않은지 되돌아보는 시간을 가져도 의미있을 거라고 생각한다.

나아가 여기서 그치지 않고, 위에서 언급한 거부 정책 등을 활용하여 중요한 자원들에 대한 보안을 강화하는 방법도 고려해보면 좋을 것 같다. 또한 ABAC을 활용하여 접근제어를 좀더 세분하게 설정함으로써, 예기치 못한 상황에서 요청이 수행되는 상황 등을 막는 것 또한 생각해볼 수 있을 것 같다.

비록 위에서는 AWS에서의 접근제어에 대한 내용을 중점으로 다루었지만, 타 CSP(클라우드 서비스 제공업체) 에서도 정책이나 역할, 그리고 ABAC 등의 개념을 사용하는 경우가 종종 있기 때문에, 하나의 CSP에 대해서만 정확하게 숙지하고 있어도 타 CSP의 접근제어를 이해하는 데 있어서도 도움이 될 것이라 생각한다. (물론 다른 방식으로 접근제어를 구현한 CSP도 있겠으나, 접근제어의 필요성과 목적을 의식하고 있는 것만으로도 접근제어 시스템을 이해하는 데 많은 도움이 될 거라 생각한다.) 클라우드 환경이 가파르게 커지고 있는 만큼, 클라우드 보안에 대한 중요성 또한 나날이 높아지고 있다. 이러한 과정 속에서 접근제어를 더욱 세밀하게 조정하는 것은 점점 선택이 아닌 필수라고 생각하며 글을 마친다.