# 대응 자동화를 위한 옵션
<a name="options-for-automating-response"></a>

 엔터프라이즈 구현과 조직 구조 간에 균형을 이루는 것이 중요합니다. *그림 4*는 AWS 구현의 각 자동화된 대응 옵션이 지닌 기술적 속성의 차이를 방사형 차트와 함께 보여 줍니다. 차트에서 기술적 속성이 차트 중앙에서 멀어질수록 해당 자동화된 대응에 대한 기술적 속성의 강도가 커집니다. 예를 들어, AWS Lambda는 더 빠른 속도를 제공하고 기술적 스킬이 덜 필요합니다. AWS Fargate는 더 많은 유연성을 제공하고 유지 관리 및 기술적 스킬이 덜 필요합니다. *표 1*은 이러한 자동화 옵션에 대한 개요와 각 자동화 옵션의 기술적 속성에 대한 요약을 제공합니다. 

![자동화된 대응 방식에서 기술적 속성의 차이](http://docs.aws.amazon.com/ko_kr/whitepapers/latest/aws-security-incident-response-guide/images/image6.png)


* 그림 4: 자동화된 대응 방식 전반의 기술적 속성의 차이 *

* 표 1: 자동화된 대응 옵션 *


|  AWS 서비스 또는 기능  |  설명  |  속성 요약\*  | 
| --- | --- | --- | 
|  AWS Lambda  |  AWS Lambda만 사용하며, 조직의 엔터프라이즈 언어를 사용하는 시스템  |  속도 <br /> 유연성 <br /> 유지 관리 <br /> 기술 세트  | 
|  AWS Step Functions  |  AWS Step Functions, Lambda 및 SSM Agent를 사용하는 시스템  |  속도 <br /> 유연성 <br /> 유지 관리 <br /> 기술 세트  | 
|  AWS Config 규칙을 사용한 자동 문제 해결  |  환경을 평가한 후 승인된 사양으로 다시 푸시하는 일련의 AWS Config 규칙 및 자동 문제 해결 세트  |  유지 관리 및 기술 세트 <br /> 속도 및 유연성  | 
|  [SSM Agent](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent.html)  |  환경 및 내부 시스템의 많은 부분을 검토하고 수정하는 자동화 규칙 및 문서 세트  |  유지 관리 및 기술 세트 <br /> 속도 <br /> 유연성  | 
|  AWS Fargate  |  Amazon CloudWatch 및 기타 시스템의 오픈 소스 Step Functions 코드와 이벤트를 사용하여 탐지 및 문제 해결을 수행하는 AWS Fargate 시스템  |  유연성 <br /> 속도 <br /> 유지 관리 및 기술 세트  | 
|  Amazon EC2  |  전체 인스턴스에서 실행되는 시스템으로, AWS Fargate 옵션과 유사  |  유연성 <br /> 속도 <br /> 유지 관리 <br /> 기술 세트  | 

 \* 속성은 각 서비스 또는 기능에 대해 내림차순으로 나열됩니다. 예를 들어, AWS Lambda는 더 빠른 속도를 제공하고 기술적 스킬이 덜 필요합니다. AWS Fargate는 더 많은 유연성을 제공하며 유지 관리 및 기술적 스킬이 덜 필요합니다. 

 AWS 환경에서 이러한 자동화 옵션을 고려할 때 중앙 집중화 및 스캔 기간(초당 이벤트 수[EPS])도 고려해야 합니다. 

 *중앙 집중화*는 조직의 모든 탐지 및 문제 해결을 수행하는 중앙 계정을 의미합니다. 이 접근 방식은 즉시 사용할 수 있는 최선의 선택처럼 보일 수 있으며 현재 모범 사례입니다. 그러나 일부 상황에서는 이러한 접근 방식에서 벗어나야 하며, 그 시점을 파악하는 것은 하위 계정을 처리하는 방법에 따라 달라집니다. [AWS Organizations의 다중 계정 프레임워크](https://aws.amazon.com/blogs/mt/best-practices-for-organizational-units-with-aws-organizations/) 또는 [AWS Control Tower](https://aws.amazon.com/controltower/)의 Security Tooling 계정 접근 방식을 활용하여 시작하는 것이 좋습니다. 

* 표 2: 중앙 집중화의 장단점 *


|   |  중앙 집중식  |  탈중앙화  | 
| --- | --- | --- | 
|  장점  |  간단한 구성 관리 <br /> 대응을 취소하거나 수정할 수 없음  |  단순한 아키텍처 <br /> 더 빠른 초기 설정  | 
|  단점  |  아키텍처의 복잡성 증가 <br /> 계정 및 리소스 온보딩/오프보딩  |  관리해야 할 리소스의 증가 <br /> 소프트웨어 기준을 유지 관리하기가 어려움  | 

 이러한 구현에 대한 비용 비교는 최상의 옵션을 결정하는 데 있어 기업의 의사 결정을 주도할 수도 있습니다. 초당 이벤트 수(EPS)는 비용을 가장 잘 예측하기 위해 사용하는 지표입니다. 결국 중앙 집중식 또는 탈중앙화 접근 방식을 사용하는 것이 훨씬 쉽고 저렴할 수 있습니다. 하지만 계정에서 해당 비용을 구체적으로 평가하는 방법을 검토하는 것은 불가능합니다. 이러한 이벤트를 이벤트에 대응할 중앙 계정으로 보낼 때는 EPS를 고려해야 합니다. EPS가 높을수록 이러한 이벤트를 중앙 집중식 계정으로 보내는 데 드는 비용이 증가합니다.