소개

AWS는 보안을 최우선으로 생각합니다. AWS 고객은 보안에 가장 민감한 조직의 요구를 지원하도록 구축된 데이터 센터와 네트워크 아키텍처의 이점을 누릴 수 있습니다. AWS는 공동 책임 모델을 채택하고 있습니다. 즉, AWS가 클라우드의 보안을 관리하고, 고객이 클라우드 내 보안을 책임집니다. 이는 보안 목표 달성에 도움이 되는 다양한 도구와 서비스에 대한 액세스를 포함하여 보안 구현을 완벽하게 제어할 수 있음을 의미합니다. 이러한 기능은 AWS 클라우드에서 실행되는 애플리케이션의 보안 기준을 설정하는 데 도움이 됩니다.

잘못된 구성이나 외부 요인 변경 등으로 인해 기준에서 벗어나는 경우 대응하고 조사해야 합니다. 이를 성공적으로 수행하려면 AWS 환경 내 보안 인시던트 대응의 기본 개념과 보안 문제가 발생하기 전에 클라우드 팀을 준비, 교육 및 훈련하기 위한 요구 사항을 파악해야 합니다. 사용할 수 있는 제어와 기능을 파악하고, 잠재적 문제를 해결하기 위한 주제 예시를 검토하고, 자동화를 사용하여 대응 속도와 일관성을 개선하는 해결 방법을 식별하는 것이 중요합니다. 또한 이러한 요구 사항을 충족하기 위해 보안 인시던트 대응 프로그램 구축과 관련된 규정 준수 및 규제 요구 사항을 이해해야 합니다.

보안 인시던트 대응은 복잡할 수 있으므로 핵심 보안 서비스부터 시작하여 기본 탐지 및 대응 기능을 구축한 다음 플레이북을 개발하여 반복 및 개선을 위한 인시던트 대응 메커니즘의 초기 라이브러리를 생성하는 등 반복적인 접근 방식을 구현하는 것이 좋습니다.

시작하기 전에

AWS에서 보안 이벤트에 대한 인시던트 대응에 대해 알아보기 전에 AWS 보안 및 인시던트 대응을 위한 관련 표준 및 프레임워크를 숙지하세요. 이러한 기반은 이 가이드에 제시된 개념과 모범 사례를 이해하는 데 도움이 됩니다.

AWS 보안 표준 및 프레임워크

먼저 보안, 자격 증명 및 규정 준수 모범 사례, 보안 요소 - AWS Well-Architected Framework 및 보안 관점: AWS Cloud Adoption Framework(AWS CAF)의 개요 백서를 검토하는 것이 좋습니다.

AWS CAF는 클라우드로 전환하는 조직의 여러 부서 간 조정을 지원하는 지침을 제공합니다. AWS 클라우드 기반 IT 시스템 구축과 관련된 몇 가지 중점 영역(관점)으로 나뉩니다. 보안 관점에서는 워크스트림 전반에서 보안 프로그램을 구현하는 방법을 설명하며, 그 중 하나가 인시던트 대응입니다. 이 문서는 고객이 효과적이고 효율적인 보안 인시던트 대응 프로그램과 역량을 구축할 수 있도록 지원하기 위해 고객과 협력한 경험의 산물입니다.

산업 인시던트 대응 표준 및 프레임워크

이 백서는 NIST(국립표준기술연구소)에서 만든 Computer Security Incident Handling Guide SP 800-61 r2의 인시던트 대응 표준 및 모범 사례를 따릅니다. NIST에서 소개하는 개념을 읽고 이해하는 것은 유용한 전제 조건입니다. 이 NIST 가이드의 개념과 모범 사례는 이 백서의 AWS 기술에 적용됩니다. 그러나 온프레미스 인시던트 시나리오는 이 가이드의 범위를 벗어납니다.

AWS 인시던트 대응 개요

먼저 클라우드에서 보안 운영과 인시던트 대응이 어떻게 다른지 이해하는 것이 중요합니다. AWS에서 효과적인 대응 기능을 구축하려면 기존 온프레미스 대응과의 편차와 이러한 편차가 인시던트 대응 프로그램에 미치는 영향을 이해해야 합니다. 이러한 각 차이점과 핵심 AWS 인시던트 대응 설계 원칙은 이 섹션에 자세히 설명되어 있습니다.

AWS 인시던트 대응 측면

조직 내 모든 AWS 사용자는 보안 인시던트 대응 프로세스에 대한 기본적인 이해가 있어야 하며 보안 직원은 보안 문제에 대응하는 방법을 이해해야 합니다. 교육, 훈련 및 경험은 성공적인 클라우드 인시던트 대응 프로그램에 필수적이며 발생 가능한 보안 인시던트를 처리하기 전에 미리 구현하는 것이 이상적입니다. 클라우드에서의 성공적인 인시던트 대응 프로그램은 준비, 운영, 인시던트 사후 활동에 기반합니다.

이러한 각 측면을 이해하려면 다음 설명을 고려하세요.

이 가이드에서 이러한 각 측면을 살펴보고 자세히 설명합니다. 다음 다이어그램에서는 이러한 측면의 흐름을 보여줍니다. 흐름은 앞서 언급한 NIST 인시던트 대응 수명 주기와 일치하지만 탐지 및 분석, 방지, 근절 및 복구를 포함하는 작업을 수행합니다.

AWS 인시던트 대응 원칙 및 설계 목표

NIST SP 800-61 Computer Security Incident Handling Guide에 정의된 일반적인 인시던트 대응 프로세스와 메커니즘은 타당하지만, 클라우드 환경에서 보안 인시던트에 대응하는 것과 관련된 구체적인 설계 목표를 고려하는 것이 좋습니다.

이러한 설계 목표는 인시던트 대응과 위협 탐지를 모두 수행할 수 있는지 아키텍처 구현을 검토하도록 상기시켜줍니다. 클라우드 구현을 계획할 때는 포렌식에 기반하여 타당한 대응 방법론을 사용하여 인시던트에 대응하는 방안을 생각해 보세요. 경우에 따라 이러한 대응 태스크를 위해 특별히 설정된 조직, 계정 및 도구가 여러 개 있을 수 있습니다. 이러한 도구와 기능은 배포 파이프라인을 통해 인시던트 대응 담당자가 사용할 수 있도록 해야 합니다. 더 큰 위험을 초래할 수 있으므로 정적이어서는 안 됩니다.

클라우드 보안 인시던트 영역

AWS 환경에서 보안 이벤트에 효과적으로 대비하고 대응하려면 일반적인 클라우드 보안 인시던트 유형을 이해해야 합니다. 고객의 책임하에 보안 인시던트가 발생할 수 있는 세 가지 영역은 서비스, 인프라, 애플리케이션입니다. 영역마다 다른 지식, 도구 및 대응 프로세스가 필요합니다. 다음 영역을 고려하세요.

이러한 영역에서는 AWS 계정, 리소스 또는 데이터에 대해 조치를 취할 수 있는 행위자를 고려하세요. 내부 또는 외부에 관계없이 위험 프레임워크를 사용하여 조직에 대한 구체적인 위험을 파악하고 그에 따라 대비하세요. 또한 인시던트 대응 계획과 신중한 아키텍처 구축에 도움이 될 수 있는 위협 모델을 개발해야 합니다.

AWS에서 인시던트 대응의 주요 차이점

인시던트 대응은 온프레미스 또는 클라우드에서 사이버 보안 전략의 필수적인 부분입니다. 최소 권한, 심층 방어 등의 보안 원칙은 온프레미스와 클라우드 모두에서 데이터의 기밀성, 무결성 및 가용성을 보호하기 위한 것입니다. 로그 보존, 위협 모델링에서 파생된 알림 선택, 플레이북 개발, 보안 정보 및 이벤트 관리(SIEM) 통합 등 이러한 보안 원칙을 뒷받침하는 여러 인시던 대응 패턴도 마찬가지입니다. 고객이 클라우드에서 이러한 패턴을 설계하고 엔지니어링하기 시작할 때부터 차이가 시작됩니다. 다음은 AWS에서 인시던트 대응의 주요 차이입니다.

차이 1: 공동 책임으로서의 보안

보안과 규정 준수에 대한 책임은 AWS와 고객이 공유합니다. 이 공동 책임 모델은 고객의 운영 부담을 덜어줍니다. 호스트 운영 체제 및 가상화 계층부터 서비스 운영 시설의 물리적 보안에 이르는 구성 요소를 AWS에서 운영, 관리 및 제어하기 때문입니다. 공동 책임 모델에 대한 자세한 내용은 공동 책임 모델 설명서를 참조하세요.

클라우드에서 공동 책임이 변경되면 인시던트 대응 옵션도 변경됩니다. 이러한 상충 관계를 계획 및 이해하고 거버넌스 요구 사항에 맞추는 것은 인시던트 대응의 중요한 단계입니다.

AWS와의 직접적인 관계 외에도 특정 책임 모델에서 책임을 지는 다른 엔터티가 있을 수 있습니다. 예를 들어 운영의 일부 측면을 책임지는 내부 조직 단위가 있을 수 있습니다. 일부 클라우드 기술을 개발, 관리 또는 운영하는 다른 당사자와 관계를 맺고 있을 수도 있습니다.

운영 모델에 맞는 적절한 인시던트 대응 계획과 적절한 플레이북을 생성하고 테스트하는 것이 매우 중요합니다.

차이 2: 클라우드 서비스 영역

클라우드 서비스에 존재하는 보안 책임의 차이로 인해 보안 인시던트에 대한 새로운 영역인 서비스 영역이 도입되었습니다.이는 앞서 인시던트 영역 섹션에서 설명했습니다. 서비스 영역은 고객의 AWS 계정, IAM 권한, 리소스 메타데이터, 결제 및 기타 영역을 포괄합니다. 이 영역은 대응 방식에 따라 인시던트 대응이 달라집니다. 서비스 영역 내의 대응은 일반적으로 기존 호스트 기반 및 네트워크 기반 대응이 아닌 API 직접 호출을 검토하고 실행하는 방식으로 이루어집니다. 서비스 영역에서는 영향을 받는 리소스의 운영 체제와 상호 작용하지 않습니다.

다음 다이어그램은 아키텍처 안티 패턴을 기반으로 하는 서비스 영역의 보안 이벤트 예를 보여줍니다. 이 경우 권한이 없는 사용자는 IAM 사용자의 장기 보안 자격 증명을 얻습니다. IAM 사용자는 Amazon Simple Storage Service(Amazon S3) 버킷에서 객체를 검색할 수 있는 IAM 정책을 가지고 있습니다. 이 보안 이벤트에 대응하려면 AWS API를 사용하여 AWS CloudTrail 및 Amazon S3 액세스 로그와 같은 AWS 로그를 분석합니다. 또한 AWS API를 사용하여 인시던트를 격리하고 복구합니다.

차이 3: 인프라 프로비저닝을 위한 API

또 다른 차이는 온디맨드 셀프 서비스의 클라우드 특성에서 비롯됩니다. 주요 시설 고객은 전 세계 여러 지역에서 제공되는 퍼블릭 및 프라이빗 엔드포인트를 통해 RESTful API를 사용하여 AWS 클라우드와 상호 작용합니다. 고객은 AWS 자격 증명을 사용하여 이러한 API에 액세스할 수 있습니다. 온프레미스 액세스 제어와 달리, 이러한 자격 증명은 네트워크 또는 Microsoft Active Directory 도메인에 반드시 구속되지 않습니다. 자격 증명은 대신 AWS 계정 내의 IAM 위탁자와 연결됩니다. 이러한 API 엔드포인트는 회사 네트워크 외부에서 액세스할 수 있으므로 예상 네트워크 또는 지역 외부에서 자격 증명이 사용되는 인시던트에 대응할 때 이해해야 할 중요한 사항입니다.

AWS의 API 기반 특성으로 인해 보안 이벤트에 대응하는 데 중요한 로그 소스는 AWS 계정에서 이루어진 관리 API 직접 호출을 추적하고 API 직접 호출의 소스 위치에 대한 정보를 찾을 수 있는 AWS CloudTrail입니다.

차이 4: 클라우드의 동적 특성

클라우드는 동적이므로 리소스를 빠르게 생성하고 삭제할 수 있습니다. 오토 스케일링을 사용하면 트래픽 증가에 따라 리소스를 스핀 업하고 스핀 다운할 수 있습니다. 수명이 짧은 인프라와 빠른 변경으로 인해 조사 중인 리소스가 더 이상 존재하지 않거나 수정되었을 수 있습니다. AWS 리소스의 임시 특성과 AWS 리소스 생성 및 삭제를 추적하는 방법을 이해하는 것이 인시던트 분석에 중요합니다. AWS Config를 사용하여 AWS 리소스의 구성 기록을 추적할 수 있습니다.

차이 5: 데이터 액세스

클라우드에서는 데이터 액세스도 다릅니다. 보안 조사에 필요한 데이터를 수집하기 위해 서버에 연결할 수 없습니다. 데이터는 유선 및 API 직접 호출을 통해 수집됩니다. 이러한 변화에 대비하려면 API를 통해 데이터를 수집하는 방법을 연습하고 이해해야 하며, 효과적인 수집 및 액세스를 위해 적절한 스토리지를 확인해야 합니다.

차이 6: 자동화의 중요성

고객이 클라우드 채택의 이점을 완전히 실현하려면 운영 전략에 자동화가 포함되어야 합니다. 코드형 인프라(IaC)는 AWS CloudFormation이나 타사 솔루션과 같은 기본 IaC 서비스에서 지원하는 코드를 사용하여 AWS 서비스를 배포, 구성, 재구성 및 폐기하는 매우 효율적인 자동화 환경의 패턴입니다. 이를 통해 인시던트 대응 구현이 고도로 자동화되며, 특히 증거를 처리할 때 인적 실수를 방지하는 데 유리합니다. 자동화는 온프레미스에서 사용되지만 AWS 클라우드에서는 더 간단하고 필수적입니다.

이러한 차이 해소

이러한 차이를 해소하려면 다음 섹션에 설명된 단계에 따라 사람, 프로세스 및 기술 전반의 인시던트 대응 프로그램이 잘 준비되었는지 확인합니다.