지난 포스팅에서는 트래픽의 유출과 유입을 어떻게 통제하는지에 대해서 다루어 보았다. 하지만 누구에게 접근권한을 주고 누구에게는 권한을 주지않고를 어떻게 선택할 수 있는지 궁금할 것이다. 이번 포스팅에서는 신분기반 정책을 통해 어떤 방식으로 접근을 제어하는지 알아볼 것이다.

신분기반 정책 VS 리소스 기반 정책

접근을 제어하는 방식에 AWS는 크게 두가지 정책이 있다. 바로 신분기반 정책과 리소스 기반 정책이다.

• 신분기반 정책 : 내가 접근 권한을 부여하는 대상이 누구인지 알며, 대상의 숫자가 많지 않을 때 사용한다.
  📌 IAM이 대표적이다.
• 리소스기반 정책 : 만약 인터넷에서 익명으로 접근하는 대상이라면 대상이 누구인지 알고 권한을 증명하는 신분증을 줄 수 있겠는가, 이렇게 대상이 불문명하며, 일일이 신분증을 다 부여할 수 없을 정도로 매우 많은 대상이 접근한다면, 리소스 기반 정책을 사용한다.
  📌 S3 : 버킷정책 , KMS : 키정책 , SNS : 주제정책
  SQS : 큐정책 등이 대표적이다.

IAM

우리는 리소스를 안전하게 보호해야 한다. 따라서 접근을 제어해야 한다. 하지만 과다하게 접근을 제어하는 것은 원하는 대상도 접근을 하지 못하는 경우가 생긴다. 이러한 신분과 접근의 균형을 맞추는 서비스를 IAM(Identity and Access Management)라 한다.
IAM에는 4가지 종류의 권한 개체가 있다.

• 루트 계정
• IAM 사용자
• IAM 롤
• IAM 그룹

루트 계정

처음 AWS계정을 생성하면 루트 유저라는 계정을 받는다. 루트유저는 모든 리소스와 서비스에 접근할 수 있는 막강한 권한을 가지고 있다. 따라서 주로 해커의 공격대상이며, 루트계정은 봉인하고, 일상적인 업무에서는 다른계정을 이용해야 한다.

루트 계정 보호

• 루트 계정과 연계된 모든 엑세스 키를 삭제한다.
• 길고 복잡한 패스워드를 작성한다.
• MFA(Multi-Factor-Authentication)를 활성화 한다.
• 일상적인 업무에서 루트계정 사용을 자제하고 새 계정을 만든다.

  일상적인 업무에서 사용하는 계정은 보통 Administrator정책을 부여하며 , 이것 또한 모든 리소스에 접근권한이 있다.
  그렇다면 Administrator계정과 루트계정은 차이점이 없어보인다. 하지만 루트계정은 전계정에 대한 예산 관리 권한과 특정 S3버킷에 대한 MFA Delete권한을 가지고 있다.

MFA

MFA란 다중인증 서비스로서 사용자가 로그인을 할 때나 어떤 액션을 수행할 때 물리적 디바이스 또는 스마트폰에 설치된 MFA 어플리케이션을 통해 1회성 패스코드를 입력받아 인증하는 서비스이다. 쉽게말해 어릴적 메이플스토리라는 게임을 해본 사람들은 아시다시피 UOTP와 같은것이다.

IAM 사용자

위에서 말했다시피 일상적인 업무에서 루트계정을 사용하지 않고 특정 리소스에 특정 권한을 부여한 IAM사용자를 이용한다. IAM은 기본적으로 계정에서 어떤한 작업도 DENY다. 즉 권한을 명시하지 않는다면 어떠한 작업도 하지 못한다는 것이다.
또한 권한을 명시하기 위해 4가지의 요소를 작성해야 한다.

• Effect : 액션 허용 여부 결정 (deny or allow)
• Resouce : 어떤 대상에 작업을 수행할 것인지
• Action : 대상에 어떤 작업을 수행할 것인지.
• Principal : 권한 부여를 위한 조건 부여
  ex) MFA를 요구하거나, 지정된 시간에만 작업 할 수있도록 해줌. 즉, MFA로 인증을 받은 사용자만 위의 명시된 권한을 얻을 수 있음.

위 사진에서 S3버킷에 대해 액션은 GET과 PUT이고 ALLOW를 하였기 때문에 해당 IAM을 가진 IAM사용자는 이 계정으로 S3에 GET과 PUT 작업을 수행할 수 있다.
📌 동일 리소스에 동일한 액션에 대해 각각 deny와 allow가 공존한다면, 반드시 deny를 우선으로 한다.

최소 권한부여 원칙

정보보안에서 근본적인 개념은 최소 권한부여 원칙이다. 즉 반드시 필요한 리소스에 대해 필요한 권한만 부여해야 한다는 것이다. 이것은 IAM에서도 가장 중요한 원칙이며 명심해야 한다.

권한의 경계

어드민은 권한의 경계를 이용해 IAM권한 개체에게 부여할 수 있는 최대 권한의 한계를 설정할 수 있다. 쉽게 말해, 한 계정에게 너무 많은 권한이 부여되는 것을 방지하기 위한 것이다.

예시로 모든 EC2에대한 모든 액션을 ALLOW하는 IAM을 부여한 사용자에게 모든 리소스에 대한 권한을 허용하는 Administrator Access정책을 부여하더라도 권한의 경계의 속성에 의해 여전히 EC2에 대한 작업만 가능하다.
즉, 권한의 경계 적용을 받는 유저는 더 높은 수준의 권한을 부여받더라도 권한의 경계를 벗어난 작업을 할 수 없게 된다.

로그인 방식

IAM권한을 가진 유저가 계정에 로그인하는 방식은 생성 단계에서 선택할 수 있다.

• 콘솔을 이용한 방식 : username과password 필요 + MFA옵션 추가 가능
• 프로그래밍을 방식 : 엑세스 키 ID와 시크릿 엑세스 키 필요

IAM 롤

이전에 IAM 사용자에 대해 배워보면서 궁금한 점이 있을 것이다. 만약 IAM을 부여해야 하는 사용자가 많다면 또는 접근해야 하는 리소스가 많다면 , 각 사용자마다 일일이 각 리소스를 정의하고 어떤 액션을 수행 할 것이고 허용 여부를 결정하는 것은 매우 비효율적일 것이다.

IAM롤은 IAM사용자와 반대 알고리즘이라 생각하면 된다.
사용자마다 어떤 리소스에 접근해서 어떤 액션을 수행 할 것인지 정의 하는 것이 아닌, 접근하고자 하는 대상인 리소스에 롤을 만들어 부여하고 접근하는 대상에게 IAM롤을 주어서 롤에 명시된 권한만을 해당 리소스에 수행할 수 있게 하는것이다.

롤에는 두가지 정책이 있다.

• 퍼미션 정책 : 롤을 가진 리소스에 접근해서 어떤 권한을 수행 할 수 있는지 명시되어 있다.
• 신뢰 정책 : 어떤 리소스가 롤을 가지고 있는지 명시되어 있다.

IAM롤을 가진 대상이 롤이 있는 리소스에 접근 할때 엑세스키 ID나 시크릿 키, 세션토큰을 부여받게 된다. 따라서 접근하는 사용자는 어떠한 패스워드,엑세스 키도 필요없이 세션토큰에 부여된 기간만큼만 접근할 수 있다.
📌 IAM롤은 임시 신분증이라고도 많이 불린다.

예시로 A라는 사용자가 B인스턴스에 DELETE라는 액션을 수행하고자 한다. B인스턴스에 DELETE를 수행할 수 있는 퍼미션 정책이 있는 롤을 만들어 B인스턴스에 부여하고 롤이 가진 신뢰정책에 A사용자가 믿을수 있는 사용자라는 것을 정의한다. 이후 IAM롤을 A사용자에게 부여하면 A사용자는 B인스턴스에 어떠한 키,패스워드 없이 토큰에 명시된 기간만큼만 접근해 퍼미션 정책에 명시된 권한만큼만 수행할 수 있다.

IAM 그룹

IAM사용자를 가진 다수를 필요에 따라 그룹 별로 묶은 것을 IAM그룹이라 한다.

회사에서 개발 팀은 특정 개발도구에만 접근 하는 권한을 부여받아야 하고 , 디자인팀은 디자인도구에만 접근 하는 권한을 부여 받아야한다. 이때 개발 팀 내 모든 사용자는 동일한 권한을 부여 받기 때문에 굳이 일일이 IAM사용자로 부여 할 필요가 없다. 이때 사용하는것이 IAM그룹이다.
쉽게 말해 IAM그룹을 만들어 개발팀을 다 포함시켜 해당 개발도구에 대한 권한을 허용하고 디자인팀에 대한 IAM그룹을 만들어 디자인도구에 대한 권한을 부여하면 된다.

이점

• 개발팀에서 특정 워크로드를 추가해야 할때 한번의 조작으로 개발팀원 전체에 관련 권한을 부여할 수 있다.
• 디자인 팀에서 더이상 특정 도구를 사용하지 않는다면 디자인 그룹에서 관련 권한을 삭제하면 디자인팀원 전체에 해당 도구에 대한 권한을 삭제 할 수 있다.

마치며

이번 포스팅에서는 신분을 기반으로 한 접근제어에 대해서 알아보았다. 다음 포스팅에서는 리소스 기반 정책을 통한 접근제어에 대해서 다루어 볼 예정이다.