# 사고 대응
<a name="a-incident-response"></a>

**Topics**
+ [SEC 10  인시던트를 어떻게 예상하고 대응하며 어떻게 사후 복구합니까?](w2aac19b7c15b5.md)

# SEC 10  인시던트를 어떻게 예상하고 대응하며 어떻게 사후 복구합니까?
<a name="w2aac19b7c15b5"></a>

조직의 업무 중단을 최소화할 수 있도록 보안 인시던트를 제때 효과적으로 조사 및 대응하고 사후 복구하려면 철저한 준비가 필요합니다.

**Topics**
+ [SEC10-BP01 주요 직원과 외부 리소스 파악](sec_incident_response_identify_personnel.md)
+ [SEC10-BP02 인시던트 관리 계획 개발](sec_incident_response_develop_management_plans.md)
+ [SEC10-BP03 포렌식 역량 확보](sec_incident_response_prepare_forensic.md)
+ [SEC10-BP04 억제 기능 자동화](sec_incident_response_auto_contain.md)
+ [SEC10-BP05 액세스 권한 사전 프로비저닝](sec_incident_response_pre_provision_access.md)
+ [SEC10-BP06 도구 사전 배포](sec_incident_response_pre_deploy_tools.md)
+ [SEC10-BP07 게임 데이 진행](sec_incident_response_run_game_days.md)

# SEC10-BP01 주요 직원과 외부 리소스 파악
<a name="sec_incident_response_identify_personnel"></a>

 조직이 인시던트에 대응하는 데 도움이 될 수 있는 내/외부 직원, 리소스, 법적 의무를 파악합니다. 

클라우드에서 인시던트 대응 방식을 다른 팀(예: 법률 자문, 리더십, 비즈니스 이해관계자, AWS Support Services 등)과 함께 정의할 때는 주요 직원, 이해관계자 및 관련 연락처를 파악해야 합니다. 종속성을 줄이고 응답 시간을 단축하려면 사용하는 서비스에 대해 팀, 전문 보안팀, 응답자를 교육하고 실습 기회를 제공해야 합니다.

외부의 전문 지식 그리고 대응 능력을 강화할 수 있는 다른 관점을 제공할 수 있는 외부 AWS 보안 파트너를 찾는 것이 좋습니다. 신뢰할 수 있는 보안 파트너는 익숙하지 않은 잠재적 위험 또는 위협을 식별하는 데 도움을 줄 수 있습니다.

 **이 모범 사례를 정립하지 않을 경우 노출되는 위험의 수준:** 높음 

## 구현 가이드
<a name="implementation-guidance"></a>
+  조직의 주요 직원 파악: 인시던트 대응 및 인시던트 이후의 복구에 참여해야 하는 조직 내의 직원 연락처 목록을 유지 관리합니다. 
+  외부 파트너 파악: 필요한 경우 인시던트 대응 및 인시던트 이후의 복구를 지원할 수 있는 외부 파트너와 협력합니다. 

## 리소스
<a name="resources"></a>

 **관련 문서:** 
+  [AWS 인시던트 대응 안내서](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html) 

 **관련 동영상:** 
+  [AWS 환경에서 보안 인시던트 준비 및 대응 ](https://youtu.be/8uiO0Z5meCs)

 **관련 예시:** 

# SEC10-BP02 인시던트 관리 계획 개발
<a name="sec_incident_response_develop_management_plans"></a>

 인시던트에 대응하고, 인시던트 중에 커뮤니케이션하고, 인시던트로부터 복구하는 데 도움이 되는 계획을 수립합니다. 예를 들어 워크로드와 조직에서 발생할 가능성이 가장 큰 시나리오부터 인시던트 대응 계획을 시작할 수 있습니다. 사내외에서 커뮤니케이션 및 에스컬레이션할 방법도 포함해야 합니다. 

 **이 모범 사례가 확립되지 않을 경우 노출되는 위험의 수준:** 높음 

## 구현 가이드
<a name="implementation-guidance"></a>

 인시던트 관리 계획은 보안 인시던트의 잠재적 영향에 대한 대응, 완화 및 복구에 매우 중요합니다. 인시던트 관리 계획은 보안 인시던트를 적시에 파악하고 해결 및 대응하기 위한 구조화된 프로세스입니다. 

 클라우드에는 온프레미스 환경에서 볼 수 있는 수많은 동일한 운영 역할과 요구 사항이 있습니다. 인시던트 관리 계획을 수립할 때는 비즈니스 성과와 규정 준수 요구 사항에 가장 잘 맞는 대응 및 복구 전략을 고려하는 것이 중요합니다. 예를 들어, 미국 내 FedRAMP 규정을 준수하는 AWS에서 워크로드를 운영하는 경우 [NIST SP 800-61 Computer Security Handling Guide(컴퓨터 보안 처리 안내서)](https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-61r2.pdf)를 준수해야 합니다. 이와 유사하게, 유럽 PII(개인 식별 정보) 데이터가 있는 워크로드를 운영하는 경우, [유럽 연합 일반 데이터 보호 규정(GDPR)](https://ec.europa.eu/info/law/law-topic/data-protection/reform/what-does-general-data-protection-regulation-gdpr-govern_en)에 명시된 데이터 레지던스 관련 문제를 보호하고 대응할 수 있는 방법과 같은 시나리오를 고려합니다. 

 AWS에서 운영하는 워크로드에 대한 인시던트 관리 계획을 구축하는 경우, 인시던트 대응에 대한 심층 방어 방식을 구축하기 위해 [AWS 공동 책임 모델](https://aws.amazon.com/compliance/shared-responsibility-model/)로 시작합니다. 이 모델에서 AWS는 클라우드 자체의 보안을 관리하지만 클라우드 내에서 보안을 유지하는 것은 고객의 책임입니다. 즉, 고객은 구현을 선택하는 보안 제어에 대한 제어 권한을 보유하며 이에 대한 책임이 있습니다. 클라우드 중심 인시던트 관리 계획 구축에 대한 핵심 개념 및 기본 지침은 [AWS 보안 인시던트 대응 안내서](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html) 에서 자세히 설명하고 있습니다.

 효과적인 인시던트 관리 계획은 클라우드 운영 목표와 함께 끊임없이 반복되고 항상 최신 상태를 유지해야 합니다. 인시던트 관리 계획을 수립 및 발전시킬 때 아래에서 자세히 설명하는 구현 계획의 사용을 고려해 볼 수 있습니다. 
+  **인시던트 대응 교육 및 훈련:** 정의된 기준선에서 편차가 발생하면(예: 잘못된 배포 또는 잘못된 구성) 이에 대응하고 조사해야 할 수 있습니다. 이를 성공적으로 수행하려면 AWS 환경 내에서 보안 인시던트 대응에 사용할 수 있는 제어 및 기능은 물론, 인시던트 대응에 참여하는 클라우드 팀을 준비, 교육 및 훈련하기 위해 고려해야 하는 프로세스를 이해해야 합니다. 
  +  [플레이북](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ready_to_support_use_playbooks.html) 및 [런북](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ready_to_support_use_runbooks.html) 은 인시던트 대응 방법의 훈련에 일관성을 유지할 수 있는 효과적인 메커니즘입니다. 인시던트 대응 중에 자주 실행되는 절차의 초기 목록을 작성하는 것부터 시작하여, 새로운 절차를 배우거나 사용하면서 이를 계속 반복합니다. 
  +  예정된 [게임 데이](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_incident_response_run_game_days.html)를 통해 플레이북과 런북을 공유합니다. 게임 데이 중에는 제어된 환경에서 인시던트 대응을 시뮬레이션하여 팀이 대응 방법을 기억할 수 있도록 하고, 인시던트 대응에 관여하는 팀이 워크플로를 숙지하고 있는지 확인할 수 있습니다. 시뮬레이션 이벤트의 결과를 검토하여 개선 사항을 파악하고 추가적인 훈련이나 추가 도구의 필요 여부를 결정합니다. 
  +  보안은 모두의 업무로 여겨야 합니다. 워크로드를 일반적으로 운영하는 모든 인력이 참여하여 인시던트 관리 프로세스에 대한 종합적인 지식을 쌓습니다. 여기에는 업무의 모든 측면, 즉 운영, 테스트, 개발, 보안, 비즈니스 운영, 비즈니스 리더가 포함됩니다. 
+  **인시던트 관리 계획을 문서화합니다.** 활성 인시던트에 대한 기록, 조치 수행, 진행 상황 커뮤니케이션, 그리고 알림을 제공하기 위한 도구 및 프로세스를 문서화합니다. 인시던트 관리 계획의 목표는 정상 운영을 가능한 빠르게 복원하고, 비즈니스 영향을 최소화하며, 모든 관련 당사자에게 계속 정보를 제공하는 것입니다. 인시던트의 예로는 네트워크 연결의 손실 또는 저하, 응답하지 않는 프로세스 또는 API, 예약된 작업이 수행되지 않는 경우(패치 작업 실패 등), 애플리케이션 데이터 또는 서비스의 사용 불가, 보안 이벤트로 인한 계획되지 않은 서비스 가동 중지, 보안 인증 유출, 잘못된 구성으로 인한 오류가 포함되며 이에만 국한되지 않습니다. 
  +  워크로드 소유자와 같이 인시던트 해결에 책임이 있는 기본 소유자를 파악합니다. 인시던트를 실행할 사람과 커뮤니케이션 처리 방법에 대한 명확한 지침을 갖춥니다. 인시던트 해결 프로세스에 참여하는 당사자가 외부 공급업체와 같이 둘 이상인 경우 *책임(RACI) 매트릭스*의 구축을 고려하여 인시던트 해결에 필요한 다양한 팀 또는 개인의 역할과 책임을 자세히 설명할 수 있습니다. 

     RACI 매트릭스에서는 다음 내용을 자세히 설명합니다. 
    +  **R:** *책임* 당사자로서 작업을 완료하는 업무를 수행합니다. 
    +  **A:** *담당* 주체 또는 이해 관계자로서 특정 작업을 완료하기 위한 최종 권한이 있습니다. 
    +  **C:** *이사회* 주체로서 일반적으로 주제 전문가이며 의견을 구하는 당사자입니다. 
    +  **I:** *정보 주체* 당사자로서 진행 상황에 대한 알림을 받으며, 작업 또는 결과물의 완료 시에만 해당하는 경우도 있습니다. 
+  **인시던트 분류:** 심각도 및 영향 점수를 기준으로 인시던트를 정의하고 분류하면 인시던트를 분류하고 해결하기 위한 구조화된 접근 방식을 사용할 수 있습니다. 다음 권장 사항은 인시던트를 정량화하기 위한 *영향 해결 긴급 매트릭스* 를 보여줍니다. 예를 들어, 낮은 영향, 낮은 긴급 인시던트는 낮은 심각도 인시던트로 간주됩니다. 
  +  **높음(H):** 비즈니스에 중대한 영향을 미칩니다. AWS 리소스 관련 애플리케이션의 중요한 기능을 사용할 수 없게 됩니다. 프로덕션 시스템에 영향을 미치는 가장 중대한 이벤트에 대해 예약됩니다. 개선 조치가 시간에 민감하게 반응함에 따라 인시던트의 영향은 빠르게 증가합니다. 
  +  **보통(M):** AWS 리소스 관련 비즈니스 서비스 또는 애플리케이션이 어느 정도 영향을 받고 성능이 저하된 상태에서 작동합니다. 서비스 수준 목표(SLO)에 기여하는 애플리케이션이 서비스 수준 계약(SLA) 한도 내에서 영향을 받습니다. 시스템이 저하된 성능으로 작동하며 재무 및 평판에 미치는 영향은 크지 않습니다. 
  +  **낮음(L):** AWS 리소스 관련 비즈니스 서비스 또는 애플리케이션의 중요하지 않은 기능이 영향을 받습니다. 시스템이 저하된 성능으로 작동하며 재무 및 평판에는 최소한의 영향을 미칩니다. 
+  **보안 제어 표준화:** 보안 제어 표준화의 목표는 운영 성과에 관한 일관성, 추적 기능 및 반복성을 확보하는 것입니다. 인시던트 대응에 중요한 다음과 같은 핵심 활동 전반의 표준화를 추진합니다. 
  +  **자격 증명 및 액세스 관리:** 데이터에 대한 액세스를 제어하고, 인적 및 시스템 자격 증명 모두에 대한 권한을 관리하는 메커니즘을 설정합니다. Single Sign-On 및 역할 기반 권한을 가진 연동 보안을 사용하여 액세스 관리를 최적화함으로써 사용자의 자격 증명 및 액세스 관리를 클라우드로 확장합니다. 액세스 관리 표준화를 위한 모범 사례 권장 사항 및 개선 계획은 보안 원칙 백서의 [자격 증명 및 액세스 관리 섹션](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/identity-and-access-management.html) 을 참조하세요. 
  +  **취약성 관리:** 공격자가 시스템을 침해하고 남용하는 데 사용될 가능성이 있는 AWS 환경의 취약점을 식별하기 위한 메커니즘을 설정합니다. 보안 인시던트의 잠재적 영향에 대응하고 이를 완화하기 위한 보안 메커니즘으로서 예방 및 탐지 제어를 모두 구현해야 합니다. 인프라 구축 및 애플리케이션 제공 수명 주기의 일부로 위협 모델링과 같은 프로세스를 표준화합니다.
  +  **구성 관리:** AWS 클라우드의 리소스 배포를 위한 표준 구성을 정의하고 절차를 자동화합니다. 인프라와 리소스 프로비저닝을 표준화하면 오류가 있는 배포로 인한 잘못된 구성 또는 사람의 실수로 인한 잘못된 구성의 위험을 완화하는 데 도움이 됩니다. 이러한 제어를 구현하기 위한 지침 및 개선 계획은 운영 우수성 원칙 백서의 [설계 원리 섹션](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/design-principles.html) 을 참조하세요.
  +  **감사 제어 로깅 및 모니터링:** 실패, 성능 저하 및 보안 문제에 대비하여 리소스를 모니터링하기 위한 메커니즘을 구현합니다. 이러한 제어를 표준화하면 시스템에서 발생하는 활동의 감사 추적을 제공하여 문제를 적시에 분류하고 개선하는 데 도움이 됩니다. 이 제어 구현을 위한 지침은 [SEC04(보안 관련 이벤트를 어떻게 탐지하나요?)](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/detection.html) 의 모범 사례를 통해 제공됩니다.
+  **자동화 사용:** 자동화를 통해 규모에 맞는 적시 인시던트 해결이 가능합니다. AWS는 인시던트 대응 전략의 컨텍스트 내에서 자동화할 수 있는 여러 서비스를 제공합니다. 자동화와 수동 개입 간 적절한 밸런스를 찾는 데 집중합니다. 플레이북과 런북의 인시던트 대응을 구축함으로써 반복 가능한 단계를 자동화할 수 있습니다. AWS Systems Manager Incident Manager와 같은 AWS 서비스를 사용하여 [IT 인시던트를 더 빠르게 해결](https://aws.amazon.com/blogs/aws/resolve-it-incidents-faster-with-incident-manager-a-new-capability-of-aws-systems-manager/)합니다. 또한 [개발자 도구](https://aws.amazon.com/devops/) 를 사용하여 인력 개입 없이도 버전을 제어하고 [Amazon Machine Images (AMI)](https://aws.amazon.com/amis/) 및 코드형 인프라(IaC) 배포를 자동화할 수 있습니다. 해당하는 경우 Amazon GuardDuty, Amazon Inspector, AWS Security Hub CSPM, AWS Config 및 Amazon Macie와 같은 관리형 서비스를 사용하여 탐지 및 규정 준수 평가를 자동화할 수 있습니다. Amazon DevOps Guru와 같은 기계 학습을 통해 탐지 기능을 최적화하여 비정상적인 운영 패턴 문제가 발생하기 전에 이를 탐지할 수 있습니다. 
+  **근본 원인 분석 및 학습된 조치 수행:** 인시던트 사후 대응 검토를 통해 학습된 내용을 캡처하는 메커니즘을 구현합니다. 인시던트의 근본 원인이 더 큰 결함, 설계 결함, 잘못된 구성 또는 재발 가능성을 드러내는 경우 문제로 분류됩니다. 이러한 경우 문제를 분석하고 해결하여 정상 운영의 중단을 최소화합니다. 

## 리소스
<a name="resources"></a>

 **관련 문서:** 
+  [AWS 보안 인시던트 대응 안내서](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html) 
+ [ NIST: 컴퓨터 보안 인시던트 처리 안내서 ](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-61r2.pdf)

 **관련 동영상:** 
+  [AWS의 인시던트 대응 및 포렌식 자동화 ](https://youtu.be/f_EcwmmXkXk)
+ [ 런북, 인시던트 보고서, 인시던트 대응에 대한 DIY 가이드 ](https://www.youtube.com/watch?v=E1NaYN_fJUo)
+ [AWS 환경에서 보안 인시던트 준비 및 대응 ](https://www.youtube.com/watch?v=8uiO0Z5meCs)

 **관련 예시:** 
+  [실습: Jupyter를 사용한 인시던트 대응 플레이북 - AWS IAM](https://www.wellarchitectedlabs.com/Security/300_Incident_Response_Playbook_with_Jupyter-AWS_IAM/README.html) 
+ [ 실습: AWS 콘솔 및 CLI를 사용한 인시던트 대응 ](https://wellarchitectedlabs.com/security/300_labs/300_incident_response_with_aws_console_and_cli/)

# SEC10-BP03 포렌식 역량 확보
<a name="sec_incident_response_prepare_forensic"></a>

 인스던트 대응 담당자가 대응 계획의 어느 시점에 어떻게 포렌식 조사를 실행할지 이해하는 것이 중요합니다. 조직에서는 이 프로세스에서 어떤 증거가 수집되고 어떤 도구가 사용되는지 정의해야 합니다. 외부 전문가, 도구 및 자동화를 비롯하여 적합한 포렌식 역량을 파악하고 확보합니다. 미리 결정해야 할 중요한 사항은 라이브 시스템에서의 데이터 수집 여부입니다. 휘발성 메모리 콘텐츠 또는 액티브 네트워크 연결과 같은 일부 데이터는 시스템의 전원이 꺼지거나 재부팅되면 손실됩니다. 

대응 팀에서는 AWS Systems Manager, Amazon EventBridge, AWS Lambda 등의 도구를 결합하여 운영 체제 및 VPC 트래픽 미러링 내에서 자동으로 포렌식 도구를 실행하여 네트워크 패킷 캡처를 확보함으로써 비영구적인 증거를 수집할 수 있습니다. 맞춤화된 포렌식 워크스테이션과 대응 담당자가 액세스 가능한 도구를 사용할 수 있는 전담 보안 계정에서 로그 분석 또는 디스크 이미지 분석과 같은 다른 활동을 수행합니다.

높은 내구성과 무결성을 제공하는 데이터 스토어에 관련 로그를 주기적으로 전송합니다. 대응 담당자는 이런 로그에 액세스할 수 있어야 합니다. AWS는 로그 조사를 용이하게 하는 Amazon Athena, Amazon OpenSearch Service(OpenSearch Service), Amazon CloudWatch Logs Insights와 같은 도구를 제공합니다. 또한 Amazon Simple Storage Service(Amazon S3) 객체 잠금을 사용하여 증거를 안전하게 보존합니다. 이 서비스는 WORM(Write-Once-Read-Many) 모델을 따르며 일정 기간 동안 객체가 삭제되거나 덮어써지지 않도록 합니다. 포렌식 조사 기법에는 전문가 교육이 필요하므로 외부 전문가의 참여가 필요할 수도 있습니다.

 **이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 보통 

## 구현 가이드
<a name="implementation-guidance"></a>
+  포렌식 기능 파악: 조직의 포렌식 조사 역량, 사용 가능한 도구 및 외부 전문가를 조사합니다. 
+  [인시던트 대응 및 포렌식 자동화 ](https://youtu.be/f_EcwmmXkXk)

## 리소스
<a name="resources"></a>

 **관련 문서:** 
+  [How to automate forensic disk collection in AWS(AWS에서 포렌식 디스크 수집을 자동화하는 방법)](https://aws.amazon.com/blogs/security/how-to-automate-forensic-disk-collection-in-aws/) 

# SEC10-BP04 억제 기능 자동화
<a name="sec_incident_response_auto_contain"></a>

대응 시간과 조직에 대한 영향을 줄일 수 있도록 인시던트 억제 및 복구를 자동화합니다. 

플레이북에서 프로세스와 도구를 생성하고 연습한 후에는 로직을 코드 기반 솔루션으로 해체할 수 있습니다. 그리고 이것은 많은 대응 인력들이 조치를 자동화하고 대응 인력의 편차 또는 추측을 없애기 위한 도구로 사용할 수 있습니다. 이렇게 하면 대응 수명 주기를 가속화할 수 있습니다. 다음 목표는 사람 응답자에 의해서가 아니라 알림 또는 이벤트 자체에서 이 코드가 호출되도록 함으로써 완벽히 자동으로 이루어지는 이벤트 중심의 대응을 생성하는 것입니다. 이러한 프로세스는 보안 시스템에 관련 데이터를 자동으로 추가해야 합니다. 예를 들어, 원치 않는 IP 주소에서 트래픽이 발생한 인시던트의 경우 AWS WAF 차단 목록 또는 Network Firewall 규칙 그룹이 자동으로 채워져 향후 활동을 차단할 수 있습니다.

![\[AWS architecture diagram showing WAF WebACL logs processing and IP address blocking flow between accounts.\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/2022-03-31/framework/images/aws-waf-automate-block.png)


*그림 3: 알려진 악성 IP 주소 차단을 자동화하는 AWS WAF*

이벤트 중심의 대응 시스템을 사용하면 탐지 메커니즘이 대응 메커니즘을 트리거하여 이벤트를 자동으로 해결합니다. 이벤트 중심의 대응 기능을 사용하여 탐지 메커니즘과 대응 메커니즘 간의 시간을 단축할 수 있습니다. 이러한 이벤트 중심의 아키텍처를 생성하기 위해 이벤트에 대한 응답으로 코드를 실행하고 기본 컴퓨팅 리소스를 자동으로 관리하는 서버리스 컴퓨팅 서비스인 AWS Lambda를 사용할 수 있습니다. 예를 들어 AWS CloudTrail 서비스가 활성화된 AWS 계정이 있다고 가정해 보겠습니다. AWS CloudTrail이 비활성화된 경우( `cloudtrail:StopLogging` API 호출을 통해 Amazon EventBridge를 사용하여 특정 `cloudtrail:StopLogging` 이벤트를 모니터링하고 AWS Lambda 함수를 호출하여 `cloudtrail:StartLogging` 을 호출함으로써 로깅을 다시 시작할 수 있습니다. 

 **이 모범 사례를 정립하지 않을 경우 노출되는 위험의 수준:** 보통 

## 구현 가이드
<a name="implementation-guidance"></a>

 억제 기능을 자동화합니다. 

## 리소스
<a name="resources"></a>

 **관련 문서:** 
+ [AWS 인시던트 대응 안내서](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html) 

 **관련 동영상:** 
+  [AWS 환경에서 보안 인시던트 준비 및 대응](https://youtu.be/8uiO0Z5meCs) 

# SEC10-BP05 액세스 권한 사전 프로비저닝
<a name="sec_incident_response_pre_provision_access"></a>

인시던트 응답자에게 AWS에 사전 프로비저닝된 올바른 액세스 권한이 있는지 확인하여 조사 및 복구 시간을 단축할 수 있도록 합니다.

 **일반적인 안티 패턴:** 
+  인시던트 대응을 위해 루트 계정을 사용합니다. 
+  기존 사용자 계정을 변경합니다. 
+  적시 권한 승격을 제공할 때 IAM 권한을 직접 조작합니다. 

 **이 모범 사례가 확립되지 않을 경우 노출되는 위험의 수준:** 보통 

## 구현 가이드
<a name="implementation-guidance"></a>

AWS는 가능한 경우 장기 보안 인증에 대한 의존도를 줄이거나 제거할 것을 권장합니다. 그 대신, 임시 보안 인증 및 *적시* 권한 승격 메커니즘을 사용하는 것이 좋습니다. 장기 보안 인증은 보안 위험에 노출되기 쉽고, 운영 오버헤드가 증가합니다. 따라서 대부분의 관리 작업에서 인시던트 대응 작업 뿐만 아니라 [아이덴티티 페더레이션](https://docs.aws.amazon.com/identity/federation/) 과 함께 [관리 액세스를 위한 임시 승격](https://aws.amazon.com/blogs/security/managing-temporary-elevated-access-to-your-aws-environment/)을 구현하는 것을 권장합니다. 이 모델에서는 사용자가 더 높은 수준의 권한(인시던트 대응 역할 등)을 요청하고, 사용자가 권한 승격에 적합한 경우 요청이 승인자에게 전송됩니다. 요청이 승인되면 사용자는 일련의 임시 [AWS 보안 인증](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-files.html) 을 받아 자신의 작업을 완료하는 데 사용합니다. 이러한 보안 인증이 만료되면 사용자는 새로운 승격 요청을 제출해야 합니다.

 대부분의 인시던트 대응 시나리오에서는 임시 권한 승격을 사용하는 것이 좋습니다. 이를 위한 올바른 방법은 [AWS Security Token Service](https://docs.aws.amazon.com/STS/latest/APIReference/welcome.html) 및 [세션 정책](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session) 을 사용하여 액세스의 범위를 지정하는 것입니다. 

 페더레이션형 ID를 사용할 수 없는 시나리오는 다음과 같습니다. 
+  ID 제공업체(idP)의 침해로 인한 중단 
+  잘못된 구성 또는 인적 오류로 인한 페더레이션 액세스 관리 시스템의 손상 
+  DDoS(분산 서비스 거부) 이벤트 배포 또는 시스템을 사용할 수 없도록 렌더링하는 등의 악의적인 활동 

 위와 같은 사례의 경우, 긴급 *브레이크 글라스* 액세스를 구성하여 인시던트에 대한 조사 및 적시 개선이 이루어지도록 해야 합니다. 또한 [적절한 권한이 있는 IAM 사용자](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#lock-away-credentials) 를 사용하여 작업을 수행하고 AWS 리소스에 액세스하는 것이 좋습니다. 루트 보안 인증은 [루트 사용자 액세스가 필요한 작업](https://docs.aws.amazon.com/accounts/latest/reference/root-user-tasks.html)에 사용합니다. 인시던트 응답자가 AWS 및 기타 관련 시스템에 대한 올바른 수준의 액세스 권한이 있는지 확인할 수 있도록, 전용 사용자 계정을 사전 프로비저닝하는 것이 좋습니다. 사용자 계정에는 권한이 있는 액세스가 필요하며, 엄격하게 제어 및 모니터링해야 합니다. 계정은 필요한 작업을 수행하기 위한 가장 최소한의 권한만으로 구축해야 하며, 액세스의 수준은 인시던트 관리 계획의 일부로 생성된 플레이북을 기준으로 해야 합니다. 

 모범 사례는 목적별 전용 사용자 및 역할을 사용하는 것입니다. IAM 정책 추가를 통해 사용자나 역할 액세스 권한을 임시 승격할 경우 인시던트가 발생하는 동안 사용자의 액세스 대상이 불명확해질 뿐만 아니라 승격된 권한이 취소되지 않는 위험이 발생합니다. 

 최대한 많은 수의 실패 시나리오에서 액세스를 얻을 수 있는지 확인할 수 있도록 가능한 많은 종속성을 제거하는 것이 중요합니다. 이를 지원하기 위해, 인시던트 대응 담당자가 전용 보안 계정에서 AWS Identity and Access Management 사용자로 생성되었는지, 그리고 기존 페더레이션 또는 Single Sign-On(SSO) 솔루션을 통해 관리되고 있지 않은지 확인할 수 있는 플레이북을 생성합니다. 각 개별 대응 담당자는 자신만의 명명된 계정을 가지고 있어야 합니다. 계정 구성은 [강력한 암호 정책](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_passwords_account-policy.html) 및 다중 인증(MFA)을 적용해야 합니다. 인시던트 대응 플레이북에서 AWS Management Console에 대한 액세스 권한만 요구할 경우, 사용자는 구성된 액세스 키를 가지고 있지 않아야 하며 액세스 키 생성이 명시적으로 허용되지 않아야 합니다. 이것은 IAM 정책 또는 서비스 제어 정책(SCP)을 통해서만 구성해야 하며, AWS 보안 모범 사례( [AWS Organizations SCP](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html))를 따를 것을 권장합니다. 사용자는 다른 계정에서 인시던트 대응 역할을 수임할 수 있는 기능 외에 다른 권한이 없어야 합니다. 

 인시던트 과정에서 조사, 개선 조치 또는 복구 활동을 지원하기 위해 기타 내부 또는 외부 인력에게 액세스 권한을 부여해야 할 수 있습니다. 이 경우, 이전에 언급한 플레이북 메커니즘을 사용해야 하며, 인시던트가 완료된 후 모든 추가 액세스 권한이 즉시 취소되었는지 확인할 수 있는 프로세스가 반드시 있어야 합니다. 

 인시던트 대응 역할의 사용이 적절히 모니터링 및 감사되고 있는지 확인할 수 있도록, 이 목적을 위해 생성된 IAM 사용자 계정이 인력 간에 공유되지 않도록 하고, AWS 계정 루트 사용자가 [특정 작업에 필요하지 않다면](https://docs.aws.amazon.com/accounts/latest/reference/root-user-tasks.html)사용되지 않습니다. 루트 사용자가 필요한 경우(예를 들어, 특정 계정에 대한 IAM 액세스를 사용할 수 없는 경우), 사용 가능한 플레이북을 통해 별도의 프로세스를 사용하여 루트 사용자 암호 및 MFA 토큰의 가용성을 확인해야 합니다. 

 인시던트 대응 역할을 위한 IAM 정책을 구성하기 위해 [IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-generation.html) 를 사용하여 AWS CloudTrail 로그를 기반으로 정책을 생성하는 것을 고려해 볼 수 있습니다. 이를 위해서는 비 프로덕션 계정에서 인시던트 대응 역할에 대한 관리자 액세스 권한을 부여하고 플레이북에 따라 실행해야 합니다. 완료되면 수행된 작업만 허용하는 정책을 생성할 수 있습니다. 그 후 이 정책은 모든 계정의 모든 인시던트 대응 역할에 적용할 수 있습니다. 더욱 쉬운 관리 및 감사를 허용할 수 있도록 각 플레이북에 대한 별도의 IAM 정책을 생성할 수 있습니다. 플레이북에 포함할 수 있는 예로는 랜섬웨어, 데이터 침해, 프로덕션 액세스의 손실 및 기타 시나리오에 대한 대응 계획이 있을 수 있습니다. 

 인시던트 대응 사용자 계정을 사용하여 전용 인시던트 대응 [IAM 역할(다른 AWS 계정 계정 내)을 수임합니다](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_aws-accounts.html). 이러한 역할은 보안 계정의 사용자만 수임할 수 있도록 구성되어야 하며, 신뢰 관계에서는 호출하는 보안 주체가 MFA를 사용하여 인증해야 합니다. 역할은 범위가 좁은 IAM 정책을 사용하여 액세스를 제어해야 합니다. 이러한 역할에 대한 모든 `AssumeRole` 요청은 CloudTrail에 로깅되고 알림이 생성되며, 이러한 역할을 사용하여 수행된 모든 작업이 로깅되도록 합니다. 

 IAM 사용자 계정과 IAM 역할의 이름을 모두 명확하게 지정하여 CloudTrail 로그에서 쉽게 찾을 수 있도록 하는 것이 좋습니다. 그 예로는 IAM 계정 `<USER_ID>-BREAK-GLASS` 및 IAM 역할 `BREAK-GLASS-ROLE`이 있습니다. 

 [CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html) 은 AWS 계정의 API 활동을 기록하는 데 사용되며 [인시던트 대응 역할의 사용에 대한 알림을 구성](https://aws.amazon.com/blogs/security/how-to-receive-notifications-when-your-aws-accounts-root-access-keys-are-used/)하는 데 사용해야 합니다. 루트 키 사용 시 알림 구성에 대한 블로그 게시물을 참조하세요. 지침을 수정하여 [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) 지표 필터를 필터로 구성할 수 있으며 이 경우 `AssumeRole` 이벤트에 구성되며 인시던트 대응 IAM 역할과 관련됩니다. 

```
{ $.eventName = "AssumeRole" && $.requestParameters.roleArn = "<INCIDENT_RESPONSE_ROLE_ARN>" && $.userIdentity.invokedBy NOT EXISTS && $.eventType != "AwsServiceEvent" }
```

 인시던트 대응 역할은 높은 수준의 액세스 권한을 가질 가능성이 높기 때문에, 이러한 알림은 광범위한 그룹에 전달되고 신속하게 조치되는 것이 중요합니다. 

 인시던트 발생 시 응답자는 IAM에 의해 직접 보호되지 않는 시스템에 대한 액세스가 필요할 수 있습니다. 여기에는 Amazon Elastic Compute Cloud 인스턴스, Amazon Relational Database Service 데이터베이스 또는 서비스형 소프트웨어(SaaS) 플랫폼이 포함됩니다. SSH 또는 RDP와 같은 기본 프로토콜을 사용하는 것보다는 [AWS Systems Manager Session Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager.html) 를 Amazon EC2 인스턴스에 대한 모든 관리 액세스에 사용하는 것이 좋습니다. 이 액세스는 보안 및 감사 기능이 있는 IAM을 사용하여 제어할 수 있습니다. 또한 [AWS Systems Manager Run Command 문서](https://docs.aws.amazon.com/systems-manager/latest/userguide/execute-remote-commands.html)를 사용하여 플레이북의 일부를 자동화할 수 있으며, 이를 통해 사용자 오류를 줄이고 복구 시간을 개선할 수 있습니다. 데이터베이스 및 서드 파티 도구에 대한 액세스를 위해, AWS Secrets Manager에 액세스 보안 인증을 저장하고 인시던트 응답자 역할에 액세스 권한을 부여하는 것이 좋습니다. 

 마지막으로, 인시던트 대응 IAM 사용자 계정의 관리를 [입사, 전근 및 퇴사 프로세스](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/permissions-management.html) 에 추가하고 정기적으로 검토 및 테스트하여 대상 액세스만 허용되는지 확인해야 합니다. 

## 리소스
<a name="resources"></a>

 **관련 문서:** 
+  [AWS 환경에 대한 임시 승격된 액세스 관리](https://aws.amazon.com/blogs/security/managing-temporary-elevated-access-to-your-aws-environment/) 
+  [AWS 보안 인시던트 대응 안내서 ](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html)
+  [AWS Elastic Disaster Recovery](https://aws.amazon.com/disaster-recovery/) 
+  [AWS Systems Manager Incident Manager](https://docs.aws.amazon.com/incident-manager/latest/userguide/what-is-incident-manager.html) 
+  [IAM 사용자의 계정 암호 정책 설정](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_passwords_account-policy.html) 
+  [AWS에서 다중 인증(MFA) 사용](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa.html) 
+ [ MFA를 통한 크로스 계정 액세스 구성 ](https://aws.amazon.com/blogs/security/how-do-i-protect-cross-account-access-using-mfa-2/)
+ [ IAM Access Analyzer를 사용하여 IAM 정책 생성 ](https://aws.amazon.com/blogs/security/use-iam-access-analyzer-to-generate-iam-policies-based-on-access-activity-found-in-your-organization-trail/)
+ [ 다중 계정 환경에서의 AWS Organizations 서비스 제어 정책 모범 사례 ](https://aws.amazon.com/blogs/industries/best-practices-for-aws-organizations-service-control-policies-in-a-multi-account-environment/)
+ [AWS 계정의 루트 액세스 키가 사용될 때 알림을 받는 방법 ](https://aws.amazon.com/blogs/security/how-to-receive-notifications-when-your-aws-accounts-root-access-keys-are-used/)
+ [ IAM 관리형 정책을 사용하여 세분화된 세션 권한 생성 ](https://aws.amazon.com/blogs/security/create-fine-grained-session-permissions-using-iam-managed-policies/)

 **관련 동영상:** 
+ [AWS의 인시던트 대응 및 포렌식 자동화 ](https://www.youtube.com/watch?v=f_EcwmmXkXk)
+  [런북, 인시던트 보고서, 인시던트 대응에 대한 DIY 가이드](https://youtu.be/E1NaYN_fJUo) 
+ [AWS 환경에서 보안 인시던트 준비 및 대응 ](https://www.youtube.com/watch?v=8uiO0Z5meCs)

 **관련 예시:** 
+ [ 실습: AWS 계정 설정 및 루트 사용자 ](https://www.wellarchitectedlabs.com/security/300_labs/300_incident_response_playbook_with_jupyter-aws_iam/)
+ [ 실습: AWS 콘솔 및 CLI를 사용한 인시던트 대응 ](https://wellarchitectedlabs.com/security/300_labs/300_incident_response_with_aws_console_and_cli/)

# SEC10-BP06 도구 사전 배포
<a name="sec_incident_response_pre_deploy_tools"></a>

 AWS에 사전 배포된 올바른 도구를 보안 담당자에게 제공함으로써 조사부터 복구까지 걸리는 시간을 단축할 수 있도록 합니다. 

보안 엔지니어링 및 운영 기능을 자동화하기 위해 AWS의 포괄적인 API 및 도구 세트를 사용할 수 있습니다. 자격 증명 관리, 네트워크 보안, 데이터 보호, 모니터링 기능을 완전히 자동화하고 이미 사용하고 있는 대중적인 소프트웨어 개발 방법을 사용하여 제공할 수 있습니다. 보안 자동화를 구축하면 직원이 보안 상태를 모니터링하면서 수동으로 이벤트에 대응하는 것이 아니라 시스템이 모니터링 및 검토하고 대응을 시작할 수 있습니다. AWS 서비스 전체에서 검색 가능하며 관련성 있는 로그 데이터를 인시던트 대응 담당자에게 자동으로 제공하는 효과적인 방법 중 하나는 다음을 사용하는 것입니다. [Amazon Detective](https://aws.amazon.com/detective/).

인시던트 대응팀은 같은 방식으로 계속 알림에 대응할 경우 알림에 대한 피로감을 느낄 위험이 있습니다. 시간이 지남에 따라 팀이 알림에 무감각한 상태가 되어 일상적인 상황을 처리하는 데 실수하거나 비정상적인 알림을 놓칠 수 있습니다. 자동화는 반복적이고 일상적인 알림을 처리하는 기능을 사용함으로써 알림에 대한 피로감을 방지하며, 중요하고 특별한 인시던트만 사람이 직접 처리하도록 합니다. Amazon GuardDuty, AWS CloudTrail Insights, Amazon CloudWatch Anomaly Detection과 같은 이상 탐지 시스템을 통합하면 일반적인 임계값 기반 알림의 부담을 줄일 수 있습니다.

프로세스의 단계를 프로그래밍 방식으로 자동화하여 수동 프로세스를 개선할 수 있습니다. 이벤트에 대한 수정 패턴을 정의한 후 해당 패턴을 실행 가능한 로직으로 분해하고 코드를 작성하여 해당 로직을 수행할 수 있습니다. 그런 다음, 응답자가 해당 코드를 실행하여 문제를 해결할 수 있습니다. 시간이 지남에 따라 점점 더 많은 단계를 자동화할 수 있으며, 궁극적으로 일반적인 인시던트의 전체 클래스를 자동으로 처리할 수 있습니다.

Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스의 운영 체제 내에서 실행되는 도구의 경우, Amazon EC2 인스턴스 운영 체제에 설치한 에이전트를 사용하여 원격으로 안전하게 인스턴스를 관리할 수 있도록 해주는 AWS Systems Manager Run Command를 사용하여 평가해야 합니다. 많은 Amazon Machine Image(AMI)에 기본적으로 설치된 Systems Manager Agent(SSM Agent)가 필요합니다. 하지만 일단 인스턴스가 손상되었으면 해당 인스턴스에서 실행 중인 도구 또는 에이전트의 응답은 신뢰할 수 있는 것으로 간주해서는 안 됩니다.

 **이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 낮음 

## 구현 가이드
<a name="implementation-guidance"></a>
+  도구 사전 배포: 인시던트에 적절하게 대응할 수 있도록 보안 담당자가 적절한 도구를 AWS에 사전 배포하도록 합니다. 
  +  [실습: AWS Management Console 및 CLI를 사용한 인시던트 대응 ](https://wellarchitectedlabs.com/Security/300_Incident_Response_with_AWS_Console_and_CLI/README.html)
  + [ Jupyter를 사용한 인시던트 대응 플레이북 - AWS IAM ](https://wellarchitectedlabs.com/Security/300_Incident_Response_Playbook_with_Jupyter-AWS_IAM/README.html)
  +  [AWS 보안 자동화 ](https://github.com/awslabs/aws-security-automation)
+  리소스 태깅 구현: 인시던트 발생 시 리소스를 식별할 수 있도록 조사 중인 리소스의 코드와 같은 정보로 리소스를 태깅합니다. 
  + [AWS 태그 지정 전략 ](https://aws.amazon.com/answers/account-management/aws-tagging-strategies/)

## 리소스
<a name="resources"></a>

 **관련 문서:** 
+  [AWS 인시던트 대응 안내서 ](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html)

 **관련 동영상:** 
+  [ 런북, 인시던트 보고서, 인시던트 대응에 대한 DIY 가이드 ](https://youtu.be/E1NaYN_fJUo)

# SEC10-BP07 게임 데이 진행
<a name="sec_incident_response_run_game_days"></a>

시뮬레이션 또는 연습이라고도 하는 게임 데이는 실제 시나리오에서 인시던트 관리 계획 및 절차를 연습할 수 있는 체계적인 기회를 제공하는 내부 이벤트입니다. 이 이벤트에서는 실제 환경을 모사하는 등 실제 상황에서 사용될 도구와 기법을 동일하게 사용하여 대응 담당자를 훈련시켜야 합니다. 게임 데이는 기본적으로 대응 능력을 준비하고 반복적으로 개선하기 위한 것입니다. 게임 데이 활동을 수행하는 것이 중요한 몇 가지 이유는 다음과 같습니다. 
+ 준비 상태 검증
+ 자신감 향상 – 시뮬레이션 및 교육 담당자를 통한 학습
+ 규정 준수 또는 계약 의무 준수
+ 인증을 위한 아티팩트 생성
+ 민첩성 – 점진적 개선
+ 속도 향상 및 도구 개선
+ 커뮤니케이션 및 에스컬레이션 다듬기
+ 드문 상황이나 예기치 않은 상황에 대한 대처 능력 개발

이러한 이유로 시뮬레이션 활동에 참여하는 동안 파생된 가치는 스트레스 이벤트 발생 시 조직의 실효성을 높입니다. 현실적이고 유리한 시뮬레이션 활동을 개발하는 것은 어려운 연습이 될 수 있습니다. 제대로 파악한 이벤트를 처리하는 절차 또는 자동화를 테스트하는 것도 몇 가지 장점이 있지만, 창의적인 [보안 인시던트 대응 시뮬레이션(SIRS)](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/security-incident-response-simulations.html) 활동에 참여하여 예기치 않은 상황을 테스트하면서 지속해서 개선하는 경우도 그만한 가치가 있습니다.

각자의 환경, 팀, 도구에 맞춤화된 시뮬레이션을 생성합니다. 문제를 찾고 그 문제를 중심으로 시뮬레이션을 설계합니다. 예를 들면 보안 인증 정보 유출, 원치 않는 시스템과 서버의 커뮤니케이션 또는 무단 노출이 야기되는 잘못된 구성 등의 문제가 될 수 있습니다. 조직을 잘 아는 엔지니어를 찾아 시나리오를 만들도록 하고 다른 그룹을 참여시킵니다. 시나리오는 현실적이어야 하며 가치가 있을 만큼 어려워야 합니다. 로깅, 알림, 에스컬레이션, 런북 또는 자동화 실행 등을 직접 체험할 기회를 포함해야 합니다. 시뮬레이션 과정에서 대응 담당자는 기술적, 조직적 역량을 발휘하고 리더가 관여하여 인시던드 관리 역량을 쌓아야 합니다. 시뮬레이션 말미에는 팀의 노력을 인정하고 향후 시뮬레이션에서 반복하고 확대할 수 있는 부분을 찾습니다.

[AWS에서 마련한 인시던트 대응 런북 템플릿을](https://github.com/aws-samples/aws-incident-response-playbooks) 대응 전략 준비뿐만 아니라 시뮬레이션의 기반으로 사용할 수 있습니다. 계획 과정에서 시뮬레이션은 다섯 단계로 나뉠 수 있습니다.

**증거 수집: **이 단계에서 팀은 내부 티켓 시스템, 모니터링 도구에서의 알림, 익명의 제보, 대중의 뉴스 등 다양한 방법으로 알림을 받습니다. 그런 다음 인프라와 애플리케이션 로그를 검토하여 문제의 원인을 판단합니다. 이 단계에서 내부 에스컬레이션이 이루어지고 인시던트 리더십이 관여해야 합니다. 문제의 원인을 찾았으면 인시던트 억제로 넘어갑니다.

**인시던트 억제: **인시던트가 발생했음을 확인하고 문제의 원인을 찾은 상태에서 이제 인시던트를 억제하는 조치를 취합니다. 예를 들면 문제가 발생한 보안 인증 정보를 비활성화하거나 컴퓨팅 리소스를 격리하거나 역할의 권한을 취소합니다.

**인시던트 근절: **인시던트를 억제했으므로 이제 문제 발생의 원인이 된 애플리케이션 또는 인프라 구성의 취약점을 완화해야 합니다. 여기에는 워크로드에 사용되는 모든 보안 인증 정보를 교체하거나 액세스 제어 목록(ACL)을 수정하거나 네트워크 구성을 변경하는 작업이 포함될 수 있습니다.

**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 보통

## 구현 가이드
<a name="implementation-guidance"></a>
+  게임 데이 [진행](https://wa.aws.amazon.com/wat.concept.gameday.en.html): 주요 직원과 관리자가 관여된 서로 다른 위협에 대해 시뮬레이션된 [인시던트](https://wa.aws.amazon.com/wat.concept.incident.en.html) 대응 [이벤트(게임 데이)](https://wa.aws.amazon.com/wat.concept.event.en.html) 를 진행합니다. 
+  교훈 확보: [게임 데이](https://wa.aws.amazon.com/wat.concept.gameday.en.html) 를 통해 얻은 교훈을 피드백 루프에 포함하여 프로세스를 개선합니다. 

## 리소스
<a name="resources"></a>

 **관련 문서:** 
+ [AWS 인시던트 대응 안내서](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html) 
+ [AWS Elastic Disaster Recovery](https://aws.amazon.com/cloudendure-disaster-recovery/) 

 **관련 동영상:** 
+ [ 런북, 인시던트 보고서, 인시던트 대응에 대한 DIY 가이드 ](https://youtu.be/E1NaYN_fJUo)