공동 책임 모델

AWS에서 애플리케이션을 실행 중이라면 누군가 결국 애플리케이션 보안에 대해 어느 정도 책임을 부담해야 합니다. A. 고객일까요?, B. AWS일까요 정답은 C. 모두입니다. 전체 애플리케이션의 보안을 위해서는 고객과 AWS가 함께 노력해야 합니다. 자, 훌륭한 보안 관리자가 두 곳의 회사가 동일한 객체를 보호할 수 없다고 말하거나, 귀사에는 사실상 보안 조치가 없고 제안 사항이 있다고 가정합시다. 동의합니다. 그래서 AWS에는 공동 책임 모델이란 것이 있습니다. 당사는 애플리케이션 스택을 전체적으로 살펴본 후 여러 부분으로 나눕니다. 그 중 일부는 AWS에게 100% 책임이 있습니다. 다른 부분은 고객에게 100% 책임이 있습니다. 이러한 책임 분산을 이해하는 것이 고객과 AWS의 상호작용에 속합니다. 스택이 어떻게 작동하는지 간단히 살펴봅시다. 먼저 물리적 계층에서 스택의 맨 아래부터 시작합니다. 이것은 철과 콘크리트입니다. 이것은 철조망 울타리입니다. 어떤 사람은 주차장을 관리해야 합니다. 또 어떤 사람은 실제 디바이스를 관리해야 합니다. 이것이 AWS입니다. 저희 AWS는 데이터 센터 둘러보기를 제공하지 않습니다. 물리적 측면을 보호하는 조치의 일환으로, 어떠한 접근도 허용하지 않습니다. 물리적 보호를 제공할 뿐 아니라, AWS는 시스템 보안을 위해 설계된 독점적인 네트워킹 프로토콜인 AWS 네트워크를 실행하므로 가상 프라이빗 클라우드(VPC)와 같은 요소가 트래픽 보호에 맞게 정해진 속도와 규모로 작동할 수 있습니다. AWS는 트래픽을 어떻게 보호할까요? 이 역시, 보안상의 이유로 말씀 드리지 않습니다. 이쯤에서 여러분은 제가 많은 사실을 숨기고 있다고 말할 수도 있습니다. 물론, 여러분에게는 저희가 무엇을 하는지 말씀 드릴 수 없지만 감사자에게는 아주 구체적으로 밝혔습니다. AWS.amazon.com/compliance 페이지만 방문하셔도 여러 독립 감사 기관에서 당사 네트워크 스택 또는 물리적 요소를 검토했고, 정기적으로 검토한다는 사실을 알 수 있습니다. 우리 네트워크가 안전하다고 할 때는 진행 과정을 설명할 수 있는 믿을 만한 Amazon 외부 조직에서 검토를 했다는 아주 정확한 정보를 제공하기 위해서입니다. 네트워크 외에 하이퍼바이저도 있습니다. 이번에는 AWS 하이퍼바이저가 zen 기반 하이퍼바이저를 사용한다는 사실을 공개합니다. 그렇긴 해도 하이퍼바이저에 많은 변화를 주어 하이퍼바이저에 대한 보안을 강화하고 확장성을 높였기 때문에 수백만 고객이 데이터 유출 걱정 없이 동시에 접속할 수 있습니다. 하이퍼바이저 외에도 EC2를 실행 중이라면 탄력적 Amazon Elastic Compute Cloud에서 게스트 운영 체제와 하이퍼바이저를 분리하는 마법의 구분 선이 있습니다. 이 경우 고객은 이 운영 체제를 선택합니다. Linux와 Windows 중에서 원하는 것을 선택하고 실행 중인 애플리케이션을 선택합니다. 이 선 위에서 AWS의 가시성은 제로입니다. 고객의 운영 체제에서 어떤 일이 일어나고 있는지 알아낼 방법은 없습니다. AWS는 고객의 애플리케이션을 알 수 없고 따라서 사용자 데이터에 대해서도 전혀 모릅니다. 이러한 콘텐츠가 사용자의 액세스 키 보안 키 조합, 암호화 방법으로 보호되는 완전히 보호되는 콘텐츠입니다. 원한다고해도 그 내용을 읽을 수도 없습니다. 실제로 클라우드에 대한 오해 중 하나는, AWS가 과거 몇몇 이메일 공급자처럼 마케팅 용도로 사용자의 정보를 추적하고 있다는 것입니다. 사용자 정보를 원하는 Amazon.com 마케팅 매니저가 있다 하더라도 그리고 권한이 있다 하더라도 정보가 구조화된 방식 때문에 접근할 수 없습니다. 한마디로, 읽을 수가 없습니다. 따라서 AWS는 이 선 아래에 있는 모든 것에 대해 100% 책임이 있고, 선 위의 내용에 대해서는 고객이 100% 책임을 집니다. 고객이 책임을 다할 때 AWS도 책임을 다할 수 있습니다. 이처럼 서로 협력해야 안전한 애플리케이션 환경이 만들어집니다.