brunch

브런치북 Vietnamin 베트남인 25화

라이킷 9 댓글

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by Patrick 김도연 Dec 26. 2021

우리 회사 클라우드 보안은 안전하나요?

쉽게 외부로 노출되는 계정 정보

지난주 베트남의 계신 지인분께서 직접 운영하시는 e-commerce platform이 베트남에서 불특정한 해커들의 끊임없는 해킹 시도 때문에 매일 밤 다리를 못 뻗고 주무신다는 얘기를 듣고 클라우드 보안 관련 몇 가지 사항들을 공유해 드렸습니다.

현재 서비스는 베트남 IDC (Internet Data Center) 환경에서 Firewall (방화벽) 정도의 서비스를 받고 계시는데, 해당 IDC의 보안 서비스에 대해 문의해 보았습니다.

베트남 로컬 클라우드의 보안 서비스 (출처 : Viettel IDC)

현재 베트남 IDC나 로컬 클라우드에서 제공하는 서비스는 네트워크에서 port 접근 권한과 DDoS 공격을 막기 위한 보안 서비스가 제공되고 있습니다.

사실 보안이라는게 보안 서비스를 받고 있다고 해서 해킹으로부터 완전히 자유로울 수도 없으며, IDC 보안이 나쁘다, 클라우드 보안이 더 안전하다 그리고 보안 사고가 발생하였을 경우 누구의 잘잘못이라는 것을 따지는 것도 쉽게 단정할 수는 없습니다.

하여 우리는 초기에 클라우드 서비스 제공자 (CSP: Amazon, Google, Microsoft), 클라우드 관리 사업자 (MSP: Amazon, Google partners), 고객사간의 R&R을 잘 정리하여 평소에 향후 발생할 수 있는 보안 사고를 미리 방지하기 위한 방안과 이에 대한 공동 대응이 필요하다고 생각합니다.

사실 클라우드는 제공자(CSP)들은 클라우드 고객과 책임을 나눠 갖는(Shared Responsibility Model) 모델을 예초부터 제안하고 있으나 최근 잇단 고객사 해킹, 정보 유출 사고등이 클라우드 환경에서도 발생하고 있어서 책임론은 계속 논쟁의 대상이 되고 있습니다.

AWS 공동 책임 모델 (Shared Responsibility Model)

엄밀히 말하면 클라우드 서비스 제공자(CSP)는 클라우드의 인프라를 제공하고, 관리는 고객이 직접 운영하므로 고객이 클라우드를 운영하면서 생긴 보안 문제는 책임을 가지지 않는다고 말합니다. 다만 고객들이 보안를 잘 설계하기 위한 가이드와 MSP를 통한 보안 컨설팅과 인증은 계속 강화하고 있습니다.

AWS에서 제공되는 대표적인 보안 서비스들 (출처 : AWS Korea)

그럼 CSP와 고객간의 오해의 소지가 없도록 각 서비스마다 발생 가능한 보안적 위협 요소 파악과 이를 사전에 미리 대비할 수 있는 정책과 실천이 필요해 보입니다.

기업내 보안은 사용자별 역할과 업무 특성, 책임에 맞는 최소 권한만 부여하는 인증부터 데이터 보관 및 전송의 암호화등 다양합니다.

우리 회사 보안 관리에 스스로 질문해 볼 사항들

이번 세션에서는 기업에서 가장 간과하기 쉬운 “내부의 적” 인증과 권한 그리고 흔희 실수하기 쉬운 사용자 계정에 대해 말씀드리겠습니다.

클라우드 관리자가 갑자기 퇴사하였는데, AWS 계정관리는 어떻게 해야 하나요?

이 역시 IT회사의 대표님들이 자주 하시는 질문입니다. 담당 직원이 퇴사하고 나서 요금이 부쩍 더 늘었는데, 알고 보니 전 직장의 AWS 계정을 가지고 (혹은 IAM 계정으로 일부 권한을 부여한 후에) 사적으로 여러가지 AWS 테스트도 한 경우도 있었습니다. 또는 퇴사자가 AWS Market Place에 들어가서 이런 저런 App들을 구매하면 모든 비용은 최초에 AWS에 등록된 카드 소유자 혹은 MSP의 월 요금에 그대로 나오게 됩니다. 마치 애플 앱스토어에서 우리 자녀들이 이런 저런 앱을 사고 제 카드에서 $$ 결제 되듯이요.

이를 위해서는 AWS Root 사용자 (Administrator)의 master권한을 대표님이 가지고 계시고, IAM이라는 사용자 계정을 생성하고 필요한 기능과 권한만 세부적으로 담당별로 역할 지정할 수 있습니다.

말씀드린 바와 같이 루트 사용자는 조직의 대표가 보유하되, 모든 직원은 IAM 사용자를 만들어 루트사용자가 모든 권한을 제어하도록 설정해야 합니다.

또한 Root Account를 #MFA (Multi-Factor Authentication)를 사용하여 자신의 모바일이나 이메일에서 인증 받고 수신된 특수 문자를 AWS Console에 입력하여 로그인하는 것을 권장드립니다.

모바일을 이용한 MFA 인증 방식

루트 계정 (Root Account)

AWS를 AWS Homepage에서 처음 회원 가입하면 계정(Account)이 생성된다. 최초 생성된 계정은 Root account 사용자로 해당 AWS에 대한 절대 권한을 갖는다. 강력한 권한을 갖는 만큼 안전하게 관리해야 하므로 꼭 필요 한 경우를 제외하고는 Root account 를 사용하지 말고 금고속에 여권과 같이 잘 모셔 두는 게 오히려 낫습니다.

AWS Console 로그인 화면 – Root Account 혹은 IAM user로 로그인할 수 있다

IAM (Identity and Access Management)

Root account를 금고속에 모셔두었다면 이에 해당하는 유사한 역할을 특정 IAM에 부여할 수 있다. 우리는 보통 double이라는 개념으로 VIP를 숨기는 경우를 볼 수 있습니다. (북한의 김정은도 Double이 10명 이상 있다고 하죠?)

영화 The Devil’s Double 에서는 이라크의 진짜 후세인 (Root Account)이 자신을 암살하려는 조직이 있음을 인지하고 자기와 똑같이 생긴 일반인 Latif Yahia를 Uday Hussein (IAM)에 동일한 이름과 유사한 역할을 부여하고 대외 활동을 하게 지시하게 됩니다.

영화 The Devil's Double (2011)의 Dominic Cooper의 후세인(IAM) 역할 (Role)

IAM은 사용자나 일반 사용자의 경우 AWS IAM 서비스를 이용해 역할과 권한을 부여할 수 있습니다.

또한 IAM은 AWS 리소스에 접근하는 주체를 인증하고 특정한 권한을 부여하며, 접근을 제어합니다.

IAM 서비스는 아래와 같이 나눌 수 있습니다.

 사용자 (User): AWS를 사용하는 개별 이용자.

 그룹 (Group): 사용자의 집합. 일반적으로 역할별로 그룹을 만들어 사용한다. 각 사용자는 여러 개의 그룹에 속할 수도 있다.

 역할 (Role): 흔히 모자라고 비유된다. 모자는 대개 그 사람의 직업과 역할 (군인, 경찰, 요리사,….)을 상징하는 의미인데 IAM은 이 역할에 따라 리소스를 사용할 수 있다. 단 해당 역향을 이용하기 위해서는 임시 토큰을 받아야만 리소스를 사용할 수 있다.

 정책 (Policy): IAM 사용자가 주여진 역할을 수행하기 위해서는 일종의 업무 허가 지시서가 필요하다. 클라우드에서는 이에 대한 지시서가 리소스에 대한 기술을 규칙으로 Json형태로 명시되어 있다.

현재 저희 회사 AWS계정은 몇 개나 되며 어떻게 사용되고 있나요?

AWS는 루트 사용자가 AWS console 접속(브라우저로 접속)하여 계정관리를 손쉽게 할 수 있습니다. 효율적인 계정 관리와 보안을 위해서는 아래 4가지 서비스를 모두 구성하실 필요가 있습니다.

 AWS IAM

 AWS Organization

 AWS Config

 AWS CloudTrail

 AWS Access Adviser

AWS Organization

만일 회사내에 클라우드 사용 규모가 크거나 각 부서별로 클라우드의 운영과 비용 관리를 별도로 하고 싶으시다면 복수 계정을 사용할 수 있습니다. (참고로 AWS는 계정 단위로 비용을 청구하고 있습니다.)

이때 계정을 여러 개 사용할 경우 ‘AWS Organizations’ 서비스를 이용해 통합 관리할 수 있습니다. AWS Organizations는 여러 계정을 묶어서 그룹화해 관리하는 서비스로 OU(Organization Unit)이라는 개념을 통해 여러 계정을 개념적으로 묶어 관리할 수 있습니다. 마치 회사 조직도에서 부서별로 그룹핑하여 거기에 맞는 권한을 주는 것과 유사합니다.

AWS Organization 구조

AWS Organization은 위와 같이 각 부서별 분리가 가능하고 하위 계정간의 서비스 제어 정책(SCP)을 적용해 중앙 관리가 가능하며, 비용 측면에서 각 계정에서 발생한 사용료를 통합 결제할 수 있습니다. 그리고 계정별로 많이 쓰는 AWS 서비스는 CSP나 MSP를 통해 할인도 받을 수 있습니다.

AWS Config

AWS Config는 Rule생성을 통해 AWS IAM (유저 및 권한) 및 인프라에 대한 보안 관리를 도와줍니다. 즉, Rule대로 사용들의 Rule을 생성하고 Rule을 제대로 준수하고 있는지 지속적으로 모니터링과 추적을 하고 S3에 저장, CloudWatch에서 경고, SNS를 통해 메일로 알림 혹은 Dashboard로 업데이트해 줍니다.

조직내에 너무 많은 룰들이 존재하면 보안 담당자가 컨트롤하기 번거로워 AWS는 자체 혹은 기타 컴플라이언스에 맞춰 Template Rule이 약 190개 있습니다. 물론 사용자가 Custom Rule도 만들 수 있는데요. 특히 Lambda를 이용하여 Custom Script를 개발하여 Custom Rule도 만들 수 있습니다.

AWS Config에서 Rule 생성 (선택)하기

AWS는 최근에는 KIMS (Korea Information Security Management System: KISA 주관)에서 권고하는 보안룰도 Template Rule로 이용하실 수 있습니다.

AWS-KISMS 정보 : https://aws.amazon.com/compliance/k-isms/

AWS CloudTrail

AWS에서는 최소 권한의 원칙이 있습니다. Root 계정을 제외한 모든 계정과 IAM에는 각 역할별 최소한의 권한만 부여하면 향후 보안 사고가 뜻밖에 발생시 원인 파악과 피해를 최소화할 수 있습니다.

예를들어 ‘AWS CloudTrail 서비스를 이용해 각 계정별, IAM 사용자별 언제, 어디서, 무엇을 했는지에 대한 로그 정보를 트랙킹할 수 있습니다.

AWS CloudTrail 사용 예시

위와 같이 CloudTrail은 각 사용자가 AWS의 서비스 EC2, RDS, Storage등에서 활동한 내역 (API 호출)을 트래킹하여 지속적인 로그 파일로 저장합니다.

마지막으로 AWS Access Adviser를 활용해 사용하지 않는 계정이나 IAM을 찾아서 이를 권한 제어, 삭제등을 할 수 있습니다. 예를들어 한 유저가 최근 접속 기록과 서비스 접근 기록이 없다면 이를 휴면 계정으로 일시정시 혹은 삭제하여 조직내 계정을 최소화로 운영할 수 있습니다.