[데이터넷] 개인정보 유출과 같은 보안 사고를 예방하기 위해 아마존웹서비스(AWS)는 자체 보안 서비스 외에도 다양한 파트너사의 보안 솔루션을 이용할 수 있는 방안을 제공한다. 그러나 이것만으로는 충분하지 않으며, 고객도 보안을 위한 공동 책임이라는 것을 인식하고, 다양한 모범 사례와 대응 방안 등을 참조해 보안 설정을 강화할 필요가 있다.

아마존 VPC(Amazon Virtual Private Cloud)는 AWS 네트워크 구조에서 가장 기본이 되는 구성 요소 중 하나다. VPC는 외부 및 다른 AWS 사용자와 논리적으로 격리된 안전한 클라우드 이용 공간을 뜻하며, AWS 사용자는 VPC 내에 다양한 구성 요소를 배치해 자신만의 클라우드 이용 공간을 구성할 수 있다.

EC2 인스턴스와 로드 밸런서를 이용해 웹서비스를 구성하거나 AWS의 관리형 데이터베이스 서비스인 아마존 RDS를 이용해 데이터베이스를 구성할 수도 있다. AWS 관리자는 VPC를 생성하는 단계에 내·외부 위협으로부터 중요 자산을 보호할 수 있도록 계층화된 보안체계를 구성하는 것이 바람직하다. AWS는 다양한 VPC 내의 자원을 보호하기 위한 다양한 보안 서비스를 제공하고 있으며, AWS 관리자는 이와 같은 AWS 보안서비스를 이용해 안전한 서비스 이용 환경을 구성할 수 있다.

다음은 AWS 환경에서 VPC 내의 중요 서비스를 보호하고 접근을 제어하기 위해 사용할 수 있는 주요 서비스들이다.

• AWS 실드(AWS Shield)

AWS 실드 서비스는 인터넷에서 유입되는 다양한 디도스(DDoS) 공격을 차단하는 서비스로 무료 버전인 실드 스탠다드(Shield Standard)와 유료 서비스인 실드 어드밴스드(Shield Advanced)로 제공된다. 실드 스탠다드는 레이어 3, 4 영역에서 발생하는 디도스 공격을 탐지/차단하는 기능을 제공하며, 실드 어드밴스드는 레이어 7 영역에서 발생하는 공격까지 탐지/차단하는 기능을 제공한다.

• AWS 네트워크 파이어월(AWS Network Firewall)

AWS에서 제공하는 관리형 네트워크 방화벽 및 침입 탐지/차단 서비스인 AWS 네트워크 파이어월은 스테이트리스 엔진(Stateless Engine)과 스테이트풀 엔진(Stateful Engine)을 통해 사용자에게 5Tuples(출발지 IP, 출발지 Port, 목적지 IP, 목적지 Port, 프로토콜) 기반 트래픽 허용/차단 기능을 제공하거나 도메인 주소 기반의 트래픽 허용 차단을 제공한다. 또 수리카타 엔진(Suricata Engine)이 포함돼 있어 수리카타 규칙을 이용해 트래픽에 포함된 특정 패턴을 기준으로 침입을 탐지/차단하는 기능을 제공한다.

• NACL(Network Access Control List)

NACL은 서브넷 레벨에서 동작하는 네트워크 보안 기능으로, 서브넷에 유입되는 트래픽 검사를 수행해 관리자가 설정한 트래픽에 대한 접근 제어를 적용한다. NACL은 관리자가 지정한 규칙 순서에 따라 규칙을 검사하며, 매칭된 트래픽을 허용하거나 차단하도록 구성할 수 있다.

• 보안 그룹(Security Group)

보안 그룹은 탄력적 네트워크 인터페이스(Elastic Network Interface, ENI) 레벨에서 동작하는 네트워크 보안 기능이다. NACL과 달리 규칙별로 검사 순서를 지정할 수 없으며, 매칭된 트래픽을 차단하도록 설정할 수 없다. 보안 그룹은 허용 규칙만을 추가해 사용할 수 있으며 규칙에 매칭되지 않은 모든 트래픽은 차단한다.

AWS 관리자는 이러한 AWS 보안 서비스를 통해 접근 제어를 구성해 외부의 위협으로부터 안전한 서비스 환경을 구현할 수 있다. 안전한 네트워크 보호체계를 구축하기 위해서는 하나의 보안 서비스를 통해 모든 접근 제어를 구성하는 것보다 각 계층별로 안전한 보안 설정을 적용해 계층화된 접근 제어 체계를 구성하는 것이 바람직하다.

[그림] 은 AWS 보안 서비스를 이용해 계층화된 네트워크 접근 제어를 구성한 개념도다. 이처럼 AWS 실드, AWS 네트워크 파이어월, NACL, 보안 그룹 등을 이용해 계층화된 네트워크 보호체계를 구성하면 외부에서 유입되는 디도스 공격이나 알려진 공격, 의심스러운 트래픽으로부터 안전한 AWS 서비스를 구성할 수 있다.

데이터 암호화
개인정보를 안전하게 보호해 사고를 미연에 방지하는 것이 보안적인 관점에서는 가장 이상적이다. 하지만 현실적으로는 적절한 접근 제어와 보안조치를 수행했음에도 불구하고 알려지지 않은 위협이나 새롭게 발생되는 제로데이 공격 등으로 인해 개인정보가 유출되는 사고가 발생할 수 있다.

그럴 경우에 대비하기 위해 개인정보를 암호화해 보관하는 방법을 선택할 수 있다. 개인정보를 암호화해 보관한다면 만일의 경우 데이터가 탈취된다고 하더라도 공격자는 암호 키를 획득하지 못해 개인정보에 대한 접근이 불가능하고, 결과적으로 데이터 유출로 인한 피해를 최소화할 수 있다.

AWS는 개인정보의 암호화를 위하여 AWS KMS(AWS Key Management Service)라는 키 관리 서비스를 제공하고 있다. AWS 사용자는 KMS를 이용해 암호 키를 발급받아 데이터를 암호화하는데 사용할 수 있으며, KMS 서비스와 통합된 AWS 서비스에서 데이터를 암호화할 때 KMS에서 발급한 암호 키를 사용하도록 설정할 수 있다.

AWS에서의 암호화는 데이터를 암호화하는 주체에 따라 사용자 측 암호화(Client Side Encryption)와 서버 측 암호화(Server Side Encryption)로 나눌 수 있다.

사용자 측 암호화는 데이터를 AWS 서비스나 기타 저장소에 저장하기 전에 사용자 측에서 암호화하는 것을 말하며, KMS를 이용하는 환경이라면 AWS에서 제공하는 AWS 암호화 SDK를 이용해 봉투암호화를 구성하면 안전하고 편리한 암호 키 관리 환경을 구성할 수 있다.

서버 측 암호화는 사용자 측에서 전달된 데이터를 각종 저장 서비스(아마존 S3, 아마존 EBS 등)나 아마존 다이나모DB와 같은 관리형 데이터베이스에서 저장 후 암호화하는 것을 의미한다. 서버 측 암호화는 각 서비스별로 암호화에 사용할 수 있는 암호 키를 선택할 수 있으며, 각 서비스가 자체적으로 관리하는 암호 키를 사용해 암호화하거나 KMS에서 제공하는 암호 키를 이용해 암호화하는 옵션을 제공한다.

AWS 서비스에서 제공하는 서버 측 암호화는 현재 권고되는 안전한 암호화 알고리즘인 AES-256 알고리즘을 통해 암호화된다. 따라서 AWS 서비스에 개인정보를 저장하는 경우라면 규정 준수 및 안전한 보관을 위해 각 서비스에서 제공하는 암호화 옵션을 활성화하기를 권고한다.

개인정보 유출 사례 분석·대응 방법
각종 매체를 통해 소개되는 개인정보 유출 사례를 살펴보면 대부분 관리자의 부주의나 실수에 의해 발생된 경우가 많다는 것을 알 수 있다. 물론 경우에 따라 고도로 숙련된 해커의 지속적인 공격에 의해 개인정보가 탈취되는 경우도 있지만, AWS에서 제공하거나 업계에서 통용되는 보안 모범 사례를 적용했다면 이를 예방하거나 피해를 최소화할 수 있다.

가장 빈번하게 발생하는 개인정보 유출 사례와 더불어 각 사례를 예방하거나 사고 발생 후 조치할 수 있는 대응 방안에 대해 살펴보자.

가장 빈번하게 발생하는 보안사고 유형 중의 하나로 AWS 서비스 접근 권한이 부여된 AWS 접근 키/비밀 키 등을 소스코드에 하드코딩해 사용하다가 해당 키 값들이 유출돼 발생하는 개인정보 유출 사고 유형이다.

일반적으로 많이 사용되는 깃허브(Github)와 같은 코드 저장소들은 공개/비공개와 같은 옵션을 제공해 조직이 사용하는 소스코드의 공개 수준을 선택할 수 있도록 하고 있다. 보안 사고가 발생하는 유형을 보면 AWS 암호 키/비밀 키가 저장된 코드 저장소를 비공개로 사용하다가 관리자의 실수에 의해 공개로 전환되거나 AWS 접근 키/비밀 키가 하드코딩된 소스코드가 실수로 공개 코드 저장소에 저장되는 경우가 많은 것을 볼 수 있다.

이처럼 관리자 혹은 개발자의 실수에 의해 AWS 접근 키/비밀 키가 공개 코드 저장소에 저장되게 되면 공격자는 아주 빠른 속도로 해당 AWS 접근 키/비밀 키를 습득하게 된다. 이후 해당 AWS 접근 키/비밀 키를 이용해 각종 AWS 저장 서비스에 접근을 시도하고, 결과적으로 개인정보를 탈취한다.

• 공격에 사용된 취약점
  - 자격증명의 부적절한 관리
  - 부적절한 코드 저장소 접근 제어
• 대응 방안
  - 유출된 접근 키 비활성화 혹은 삭제 후 교체
  - 클라우드 트레일 로그로 유촐된 접근 키를 통해 호출된 API 이력 파악 후 피해 범위 조사
  - 소스코드에서 접근 키/비밀 키 삭제
  - 공개 코드 저장소를 비공개로 전환
• 예방 위한 모범 사례
  - AWS 접근 키/비밀 키 하드코딩 금지
  - 환경 변수, 매개변수 스토어, AWS 시크릿 매니저 등 사용
  - 코드 저장소에 소스코드 저장 전 AWS 접근 키/비밀 키 포함 여부 스캔

공격자가 피싱이나 해킹 등 다양한 방법으로 아마존 S3에 대한 접속 권한(ID/PW 혹은 접근 키/비밀 키)을 획득한 후 해외에서 S3 버킷에 접근해 저장된 개인정보를 탈취하는 유형의 보안 사고다.

• 공격에 사용된 취약점
  - 부적절한 개인정보 저장소 접근 제어
• 대응 방안
  - 유출된 IAM 사용자 암호 교체 및 MFA 설정 적용
  - 유출된 접근 키 비활성화 혹은 삭제 후 교체
  - 클라우드 트레일 로그 확인 후 해당 접근 키를 통해 호출된 API 이력 파악
  - S3 버킷 정책을 수정해 지정된 IP 외 다른 IP에서 접근할 수 없도록 차단
• 예방 위한 모범 사례
  - IAM 사용자에 대한 MFA 적용
  - 지정된 IP 이외 IP에서 접근할 수 없도록 설정 S3 버킷 정책 설정

공개 액세스로 설정된 S3 버킷에 개인정보를 저장해 개인정보가 유출되는 사고 유형이다. S3버킷은 버킷 정책을 통해 해당 버킷에 접근할 수 있는 보안주체를 IAM 사용자 혹은 역할을 기준으로 제한하거나 특정 AWS 계정 및 AWS 서비스 등으로 제한할 수 있다.

예외적으로 필요한 경우에 공개 액세스로 설정해 누구나 접근할 수 있는 버킷으로 설정할 수도 있다. S3 버킷이 공개 액세스로 설정된 상태에서 해당 버킷에 개인정보와 같은 중요 정보를 저장하게 되면 공격자들이 별도 권한 탈취 과정 없이 손쉽게 개인정보를 탈취할 수 있다.

• 공격에 사용된 취약점
  - 부적절한 개인정보 저장소 접근 제어
• 대응 방안
  - 공개 액세스로 설정된 S3 버킷을 비공개로 전환
  - 클라우드 트레일 로그 확인 후 버킷을 공개 액세스로 전환 설정한 IAM 자격 증명 파악
• 예방 위한 모범 사례
  - 계정 레벨의 S3 블록 공개 액세스 활성화
  - 필요한 경우 예외적으로 버킷 레벨의 S3 블록 공개 액세스 활성화

개인정보를 포함한 각종 데이터는 공격자가 노리는 궁극적인 목표다. 따라서 우리는 취약한 자원 환경을 사전에 파악하고 위협을 식별해 개인정보가 유출될 수 있는 위험을 미연에 방지해야 한다. 그리고 이 목적을 달성하기 위해서는 보안, 개발, 영업, 관리 등 조직의 모든 구성원들이 보안을 최우선 순위에 둬야 한다.

보안은 AWS에서 최우선 순위다. 이를 위해 AWS는 우수한 보안인력을 통해 업계 최고 수준의 보안을 유지하고자 최선의 노력을 다하고 있다. 하지만 AWS의 노력만으로는 모든 개인정보 유출과 같은 보안 사고를 예방할 수 없다.

결국 AWS에서의 보안은 AWS와 AWS 서비스를 사용하는 고객과의 공동 책임이다. 이에 AWS는 다양한 보안 서비스를 제공하고 있으며, AWS 마켓플레이스를 통해 AWS에서 제공하지 못하는 다양한 파트너사의 보안 솔루션을 이용할 수 있는 방안도 제공하고 있다.

고객은 AWS 보안 서비스, 파트너 보안 솔루션 등을 이용해 개인정보를 안전하게 보호할 수 있으며, 2회에 걸쳐 소개한 ‘AWS 서비스에 대한 보안 설정 모범 사례’, ‘접근 제어’, ‘암호화’, ‘개인정보 유출 사례 분석’을 참고해 보안 설정을 강화함으로써 개인정보 유출 사고 위험을 경감할 수 있다.