[데이터넷] 클라우드를 이용하지 않는 기업을 찾는 것이 더 어려울 정도로 대부분의 사람들에게 익숙한 환경이 됐다. 하지만 기업 담당자들은 자원 공유, 서비스화 등 클라우드가 가진 특성 때문에 보안을 고민하지 않을 수 없다.

대부분의 기업 클라우드 보안 사고는 권한 관리 실패로 인해 발생한다. 안랩의 보안 특화 클라우드 관리 서비스 ‘안랩 클라우드(AhnLab Cloud)’는 수년에 걸친 보안 솔루션 및 서비스 경험을 통해 클라우드 보안 요소 중 ‘식별’과 ‘접근 제어’를 필수적인 보안 요소로 고려하고 있다. 또 사용자와 클라우드 리소스를 정확하게 식별하고 각 서비스에 대한 접근 권한 관리에 초점을 두어 고객사 환경에 적합한 클라우드 환경을 제안 및 구성한다.

클라우드 내부서 발생한 문제, 사용자 책임

클라우드에서 리소스를 생성할 경우, 당장 눈 앞에 보이지 않고 서비스에 대한 워크로드도 모두 클라우드에서 구성되며 접속은 원격으로 이뤄진다. 아무리 클라우드 리소스가 잘 구성돼 있고 문제없이 동작하고 있다고 해도 보안을 고려하지 않는다면 늘 불안 요소를 안고 있게 된다.

클라우드 서비스 사업자(CSP)가 제시하는 책임 공유 모델(Shared Responsibility Model)에서도 확인할 수 있듯, 클라우드 내부 사용에 대한 관리는 사용자의 몫이자 책임이다. 따라서 외부자에 대한 경계뿐만 아니라 내부자의 악의적인 행위나 실수에 의한 보안 사고를 스스로 방지해야 한다. 이를 위해서는 사용자별 역할과 책임에 맞는 최소 권한만 부여하는 것이 클라우드 보안의 첫 걸음이라 할 수 있다.

클라우드를 사용할 때는 반드시 각 사용자 업무 특성에 맞는 권한을 부여해야 한다. 예를 들어 클라우드 환경에 개발 시스템과 운영 시스템이 구성돼 있다고 하면, 개발자는 개발 시스템, 운영자는 운영 시스템에만 접근이 가능하도록 권한을 부여해 각자의 업무와 역할에 맞는 접근 제어를 구현해야 한다.

기업의 서비스를 구성하는 시스템을 관리하고 운영하기 위해서는 ‘조직’과 ‘사람’이 필요하다. 그리고, 조직과 사람이 역할에 맞는 업무를 부여받아 수행을 할 때 시스템에 접속하기 위해서는 ‘계정’이 필요하다. 사람은 계정을 통해 업무에 부합하는 시스템에 접근해 일을 하게 된다. 따라서 계정을 각 사용자의 업무에 맞게 정확하게 분리하고 꼭 필요한 최소 권한만 부여하는 것이 보안 관리 체계의 기본 요소이자 가장 중요한 요소라 할 수 있다.

IAM으로 역할·권한 통제해야

전 세계적으로 가장 많이 사용되는 클라우드 서비스 중 하나인 AWS의 접근 통제 방안을 예로 들어 보면, AWS에 처음 회원 가입하면 계정(Account)이 생성된다. 이 때 발급되는 ‘User’는 ‘Root User’로 해당 계정에 대한 모든 권한을 갖는다. 강력한 권한을 갖는 만큼 안전하게 관리해야 하므로 꼭 필요한 경우를 제외하고는 Root User를 사용하지 않을 것을 권고한다. 일반 사용자의 경우 ‘AWS IAM(Identity and Access Management)’ 서비스를 이용해 역할과 권한을 부여할 수 있다.

AWS IAM이란 AWS 리소스에 대한 접근을 안전하게 제어할 수 있는 서비스다. 이 서비스를 통해 클라우드 리소스에 접근하는 주체를 인증하고 권한을 부여해 접근 제어를 할 수 있다. IAM이라는 이름에서도 알 수 있듯, ‘아이덴티티(Identity)’는 AWS로 요청을 할 수 있는 보안 주체를 의미하며 ‘접근 관리(Access Management)’는 해당 보안 주체들이 리소스에 대해 어떤 일을 할 수 있는지에 대한 권한을 의미한다.

AWS IAM 서비스의 세부 항목에 대해 좀 더 살펴보자. IAM 서비스는 ▲사용자(User) ▲그룹(Group) ▲정책(Policy) ▲역할(Role)로 나눌 수 있다. User는 AWS를 사용하는 개별 이용자를 말하고 Group은 User를 모아 놓은 것으로 일반적으로 역할 별로 Group을 만들어 사용한다. 또한 각 User는 여러 개의 Group에 속할 수도 있다.

Policy는 클라우드 리소스에 대한 권한을 Json 형식으로 기술한 규칙으로, 특정 Group이나 User에 Policy를 적용해 업무 용도에 따라 정책을 정의할 수 있다. Policy는 AWS 서비스와 리소스에 대한 ‘인가’ 기능을 제공하는데 ▲Effect ▲Principal ▲Action ▲Resource ▲Condition의 요소로 이루어져 있다.

Policy의 각 구성 요소를 간단히 살펴보면, Effect는 명시된 정책에 대한 ‘허용’ 또는 ‘거부’를 정의하는 항목이다. Principal은 ‘누가’, Action은 ‘무엇을’, Resource는 ‘적용할 대상’, Condition은 ‘적용되는 조건’에 해당하는 항목이다. 이처럼 Policy의 다양한 구성 요소를 적절히 조합하면 정책을 상세하게 수립할 수 있다.

실제 업무나 역할 별로 Policy를 연결해 사용할 경우, User에 직접 Policy를 부여하는 것보다 Group 단위로 권한을 관리할 것을 권장한다. Group 단위로 권한을 관리하면, 담당 인력이 변경돼도 별도 Policy 수정 없이 Group 내에서 변경된 인력에 대한 User만 수정(생성 혹은 삭제)하면 되므로 관리가 용이하고 실수를 줄일 수 있다.

Role은 특정 서비스나 User에게 임시 권한을 부여할 때 사용하는데, Role을 이용해 임시 토큰을 발행 받아 정해진 리소스를 이용할 수 있는 권한을 부여할 수 있다.

지속적인 계정 감사 통해 권한·역할 관리

AWS 리소스에 대한 작업을 요청할 수 있는 보안 주체는 IAM User와 IAM Role로 구분할 수 있다. User는 상시 자격, Role은 임시 자격을 가진다. 만약 User가 가진 접근 키(Access Key)나 비밀 키(Secret Key)가 유출된다면 이는 User의 모든 권한을 탈취당하는 것과 다름이 없다. 따라서 각별히 주의해 관리해야 한다.

이에 반해 Role은 Assume Role이라는 신뢰 관계를 통해 타계정에 User를 만들지 않고도 접근할 수 있다. Role은 별도 키 없이 임시 토큰으로 접근하는 개념이기 때문에 운영 상황에 따라 Role을 잘 활용한다면 보안 상 이점을 가질 수 있다.

IAM 보안 주체가 각 리소스에 접근하는 과정을 살펴보면, 최초에 누구인지 확인하는 신원 ‘인증’ 절차를 거친 후 Policy를 통해 권한을 확인한다. 적절한 권한을 가지고 있는 것으로 확인되면 ‘인가’를 받아 해당 리소스에 접근이 가능하다. 더불어 ‘AWS 클라우드트레일(AWS CloudTrail)’ 서비스를 이용해 앞서 인증과 인가를 받은 보안 주체가 언제, 무엇을, 어떻게 했는지 모든 API 요청의 처리 내역을 로깅해 계정 활동을 추적하고 관리 감독할 수 있다.

또한, ‘Access Advisor’를 활용해 미사용 권한을 탐지하고 이를 계정 감사 활동의 일부로 활용할 수 있다. Access Advisor는 IAM에서 제공하는 기능으로 User나 Role이 최대 1년 동안 권한을 어떻게 사용했는지 확인할 수 있다.

예를 들어 어떤 User가 최근 접속 기록과 서비스 접근 기록이 없다면 보안 관점에서 해당 사용자는 이 권한이 필요 없다는 뜻으로 해석해 권한 수정이 필요하다고 판단할 수 있다. 이처럼 계정에 대한 여러가지 감사 활동을 통해 권한과 역할을 지속적으로 관리하고 개선점을 찾아 나가며 최소 권한의 원칙을 준수할 것을 권고한다.

여러 계정 사용 시 통합 관리 기능 필수

지금까지 하나의 Account 내에 클라우드 리소스를 생성하고 그 리소스에 여러 사용자가 접근할 경우의 계정과 권한 관리 방안에 대해 살펴봤다. 다만, 클라우드 사용 규모가 크고 비용 관리가 중요한 경우에는 여러 개의 Account를 사용해야 한다.

AWS는 리소스의 가용성을 보장하고 필요 이상으로 프로비저닝 하는 것을 방지하기 위해, 각 계정에서 최대로 이용할 수 있는 서비스 한도를 정해 놓았다. 그리고 AWS 사용료 청구의 최소 단위는 ‘Account’이기 때문에 여러 부서 다수의 사용자가 AWS에 접근해 업무를 수행해야 한다면, 예산 및 비용 관리 관점에서도 Account를 나누어 사용하는 것이 좋다.

계정을 여러 개 사용할 경우 ‘AWS Organizations’ 서비스를 이용해 통합 관리할 수 있다. AWS Organizations는 여러 계정을 그룹화해 관리하는 서비스로 OU(Organization Unit)이라는 개념을 통해 여러 계정을 개념적으로 묶어 관리할 수 있는데, 이는 윈도우 폴더와 유사하다고 이해하면 쉽다. 하나의 폴더 안에 여러 폴더나 파일이 있는 것처럼 OU 안에 여러 계정을 배치하거나 하위에 다른 OU를 생성할 수도 있다.

이렇게 구성하면 운영 측면에서 하위 계정들에 서비스 제어 정책(SCP)을 적용해 중앙 관리가 가능하며, 비용 측면에서 각 계정에서 발생한 사용료를 통합 결제할 수 있고 각 계정 별 세부 사용료 확인도 가능하다. 중앙 관리가 용이하고, 통합 결제를 통한 할인 혜택의 장점도 있기 때문에 여러 계정을 사용하는 환경에서는 AWS Organizations 서비스를 적절히 사용하는 것이 좋다.

환경별 계정 분리 사용하는 것이 효과적

이제 실제로 기업 환경에서 AWS를 이용할 때, 보안을 고려해 클라우드 아키텍처를 구성하고 각 사용자의 계정과 권한을 관리하는 방안에 대해 알아보자. 크게 3단계로 나누어 계정 분리, 네트워크 설계, 서비스 적용의 단계로 살펴본다.

AWS에서 보안, 운영, 개발 등 환경을 분리하는 방법은 굉장히 다양하다. 환경 별로 Account를 분할할 수 있고, VPC(Virtual Private Cloud)를 분할할 수도 있으며, 나아가서는 서브넷(Subnet) 단위로 분할할 수도 있다. 어느 방식을 선택할지는 시스템 규모나 특성에 따라서 다르고 각 방식 모두 장단점이 존재한다. 하지만 추후 서비스의 확장성을 고려하고 운영과 비용 관리 측면에서의 장점을 극대화하기 위해서는 환경별로 Account를 분할하는 것이 가장 효과적인 구성이라 할 수 있다.

이처럼 환경 별로 Account를 모두 분리해서 사용하는 것은 초기 설정이 조금 복잡할 수 있다. 하지만, 운영 측면에서 권한 관리를 간결하게 할 수 있고 비용 관리 측면에서도 통합 결제 기능과 볼륨 할인 등 여러가지 장점이 존재하기 때문에 장기적인 관점에서는 가장 좋은 구성 방안이 될 수 있다.

비용·관리 복잡성 낮추기 위한 계정 분할

환경 별로 Account를 분할하는 것이 운영과 비용 관리 측면에서 왜 효율적인지 알아보자. 예를 들어 회사에 보안, 운영, 개발 환경이 존재하고, 각 환경을 계정으로 분리해 사용한다고 가정해본다. 특정 임직원이 운영 환경과 개발 환경에 대해서는 모든 작업을 허가하고 보안 환경은 참조 권한만 필요하다면, 아래 그림과 같이 각 환경 별 Account에 개별 User를 생성하고 권한에 맞게 간결한 정책을 부여해 관리할 수 있다. 이렇게 하면 Account와 시스템이 새롭게 추가되더라도 그에 맞는 User를 생성하고, 최소한의 권한을 부여해 관리할 수 있다.

만약 환경 별로 Account를 분리하지 않고 VPC를 분할해 구성했다면, 해당 User에게 부여할 정책을 리소스 별로 세세하게 만들어줘야 한다. 이 경우, 정책의 복잡성이 증가해 실수가 발생할 위험이 있고, 관리 측면에서도 어려움이 따른다. 따라서 최대한 Account를 세분화해 설계하는 것이 잠재적인 실수를 최소화하는 가장 이상적인 방법이라 할 수 있다.

이제 환경 별로 Account를 분리하는 것이 비용 관점에서 어떤 장점을 갖는지 알아보자. 환경 별로 Account를 분리하면 보안, 운영, 개발 각 팀에서 Account을 별도로 사용하고, 앞서 소개한 AWS Organizations 서비스로 각 계정에서 발생한 사용료를 하나의 Master Account로 통합해 결제하게 된다. 기본적으로 AWS 사용료는 Account 단위로 청구되기 때문에 하나의 Account 안에 여러 서비스가 존재하는 경우, 각 서비스마다 발생하는 비용을 산정하기 쉽지 않다.

따라서 서비스 종류마다 Account를 나눠 놓으면, Account 당 청구서 1개가 발행되므로 단순하고 정확하게 관리할 수 있다. 또한 볼륨 할인도 Account 단위가 아닌 통합 결제 Account를 대상으로 적용할 수 있고, Account 간 크레딧이나 예약 인스턴스(Reserved Instances: RI) 공유 등 여러 경제적 이점이 있다.

앞선 내용들을 종합해보면, 가장 먼저 결제를 위한 Master Account를 생성하고, 같은 속성을 가진 서비스 별로 Account를 생성한다. 그리고 앞서 생성한 Master Account에 링크시켜 비용을 통합 관리할 수 있도록 한다. 그리고 하나의 서비스 안에 다수 사용자의 업무 및 역할이 연관돼 있을 시, 다시 역할 별로 Account를 분리한다. 이를테면, 하나의 서비스를 운영할 때에도 역할 별로 운영, QA, 개발 등 업무 구분이 있을 것이고 이 경우 업무 별로 Account를 모두 분리해 사용해야 한다는 것이다.

Account를 모두 분리했으면 실제 임직원의 업무 별로 User와 Group을 생성하고, 서비스 성격에 맞게 정책을 부여해 담당 업무 별로 최소 권한의 원칙에 따라 상세하게 권한을 관리한다. 이와 같은 절차로 계정 체계를 수립하고 각 사용자 별 권한을 알맞게 잘 부여했다면, 계정 활동 감사를 통한 보안 강화를 위해 AWS CloudTrail을 활성화한다. 또, 서비스 제어 정책(SCP)을 OU 또는 Account 별로 적용해 권한을 제한할 수 있다.

서비스 리전 선택 후 VPC·서브넷 구성

다음으로, 각 계정 내에서 네트워크를 설계하는 절차와 보안 영역 별 서비스 구성 절차를 차례로 살펴보자.

우선 네트워크를 설계하는 방법은 어떤 기능 단위로 구성할지에 따라, VPC나 서브넷 구성 방법을 다양하게 선택할 수 있다. 네트워크 설계 시, 가장 먼저 리전을 선택하고 서비스 성격에 맞는 네트워크 구성을 설계해 VPC, 서브넷 순서로 네트워크 영역을 구성한다.

다음으로, 설계한 네트워크 간 연계를 구성한다. 서로 다른 서브넷을 라우팅 테이블을 이용해 연결을 구성할 수 있고, ‘VPC 피어링’으로 서로 다른 VPC의 연결을 구성할 수도 있다. 이 밖에 ‘VPC 엔드포인트’를 이용해 엔드포인트를 지원하는 서비스와 프라이빗한 연결 구성도 가능하다. 이와 같이 각 연계 방안의 기능과 제약 사항을 파악해 용도에 맞는 연계 구성을 할 수 있다.

Account 내부 네트워크 간 연계를 모두 마친 후에는 외부 네트워크와의 통신 구간 설계가 필요하다. 이 과정에서는 인터넷 연결을 위한 ‘인터넷 게이트웨이’, 프라이빗 서브넷(Private Subnet)에서 인터넷과 통신하기 위한 ‘NAT(Network Address Translation) 게이트웨이’, 프라이빗한 외부 연결을 위한 VPN 및 전용선(Direct Connect) 서비스 등을 이용할 수 있다.

내·외부 네트워크 통신 구성까지 모두 마친 후에는 서비스 연속성과 가용성을 고려해 로드 밸런싱을 설계하고, 네트워크 트래픽을 다루는 여러 ISV 솔루션들을 손쉽게 효율적으로 관리해주는 ‘게이트웨이 로드밸런서(GWLB) 서비스 등을 활용할 수도 있다.

네트워크의 구역과 연계 설계 등 모든 프레임을 다 구성한 이후에는 실제 네트워크 트래픽을 제어할 수 있도록 서브넷팅과 라우팅, 시큐리티 그룹(Security Group)과 NACL(Network Access Control List) 등을 충분히 활용해 네트워크 트래픽 필터링을 통한 접근 제어를 설계하면 된다.

비즈니스 요구 맞춰 서비스 배치

서비스 특성을 고려한 계정 분리와 권한 설정 그리고 네트워크 설계까지 모두 마쳤으면 이제 클라우드 아키텍처 구성을 위한 큰 프레임은 모두 완성됐다. 이제 이 완성된 프레임을 기반으로 각 요구사항에 맞는 서비스를 배치하면 풀 아키텍처를 완성할 수 있다.

비즈니스 요구사항이나 컴플라이언스 항목에 맞춰 인증 및 권한 관리, 접근 통제, 암호화 및 키 관리, 인프라 및 데이터 보호, 위험탐지 및 규정준수, 시스템 및 서비스 운영 관리 등 각 보안 영역 별 항목에 대응하는 서비스와 솔루션을 아키텍처 프레임 안에 배치 구성한다.

각 영역 별로 알맞은 서비스를 배치하고 보안 설정까지 모두 완료하면, 보안을 고려한 클라우드 아키텍처 구성을 모두 마치게 된다.

클라우드 보안 컨설팅부터 운영까지 지원

안랩 클라우드는 최초 클라우드 도입하는 시점부터 현황 분석을 통해 Account 분리, 네트워크 설계, 그리고 서비스 배치의 모든 과정 속 모든 요소에 보안을 고려해 진행한다는 점에서 기존 MSP와 차별화된다. 고객의 업무를 파악하고 시스템 사용 및 관리 현황을 상세하게 분석함으로써 고객사 환경에 최적화된 클라우드 환경을 제안하고 가장 안전한 클라우드 환경을 제공하고 있다.

고객은 안랩이라는 단 하나의 컨택 포인트로 클라우드 보안 컨설팅부터 아키텍처 설계, 구축, 운영 그리고 클라우드 보안까지 모두 해결해 클라우드를 안전하고 편리하게 사용할 수 있다.

<최광호 안랩 클라우드사업본부장>