기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
SEC10-BP05 프로비저닝 전 액세스
인시던트 대응자가 에 사전 프로비저닝된 올바른 액세스 권한을 가지고 AWS 있는지 확인하여 조사에서 복구까지 걸리는 시간을 줄입니다.
일반적인 안티 패턴:
-
인시던트 대응을 위해 루트 계정을 사용합니다.
-
기존 계정을 변경합니다.
-
IAM 권한 상승을 제공할 just-in-time 때 권한을 직접 조작합니다.
이 모범 사례가 확립되지 않을 경우 노출되는 위험 수준: 중간
구현 가이드
AWS 에서는 임시 자격 증명 및 just-in-time 권한 에스컬레이션 메커니즘을 위해 가능한 경우 장기 자격 증명에 대한 의존도를 줄이거나 제거할 것을 권장합니다. 장기 자격 증명은 보안 위험에 노출되기 쉽고, 운영 오버헤드가 증가합니다. 대부분의 관리 작업과 인시던트 대응 작업의 경우 관리 액세스를 위한 임시 에스컬레이션
대부분의 인시던트 대응 시나리오에서는 임시 권한 승격을 사용하는 것이 좋습니다. 이를 위한 올바른 방법은 AWS Security Token Service 및 세션 정책을 사용하여 액세스의 범위를 지정하는 것입니다.
페더레이션형 ID를 사용할 수 없는 시나리오는 다음과 같습니다.
-
ID 제공업체(idP)의 침해로 인한 중단.
-
잘못된 구성 또는 인적 오류로 인한 페더레이션 액세스 관리 시스템의 손상.
-
분산 서비스 거부(DDoS) 이벤트 또는 시스템 사용 불가 렌더링과 같은 악성 활동입니다.
위의 사례에서는 긴급 break glass 액세스를 구성하여 인시던트에 대한 조사 및 적시 수정이 이루어지도록 해야 합니다. 적절한 권한이 있는 사용자, 그룹 또는 역할을 사용하여 작업을 수행하고 AWS 리소스에 액세스하는 것이 좋습니다. 루트 사용자 자격 증명이 필요한 작업에서만 루트 사용자를 사용합니다. 인시던트 대응 담당자가 AWS 및 기타 관련 시스템에 대한 액세스 수준이 올바른지 확인하려면 전용 계정을 미리 프로비저닝하는 것이 좋습니다. 계정에는 권한이 있는 액세스가 필요하며, 엄격하게 제어 및 모니터링해야 합니다. 계정은 필요한 작업을 수행하기 위한 가장 최소한의 권한만으로 구축해야 하며, 액세스의 수준은 인시던트 관리 계획의 일부로 생성된 플레이북을 기준으로 해야 합니다.
모범 사례는 목적별 전용 사용자 및 역할을 사용하는 것입니다. IAM 정책 추가를 통해 사용자 또는 역할 액세스를 일시적으로 에스컬레이션하면 사용자가 인시던트 중에 어떤 액세스 권한을 가졌는지 불분명하게 만들고 에스컬레이션된 권한이 취소되지 않을 위험이 있습니다.
최대한 많은 수의 실패 시나리오에서 액세스를 얻을 수 있는지 확인할 수 있도록 가능한 많은 종속성을 제거하는 것이 중요합니다. 이를 지원하려면 플레이북을 생성하여 인시던트 대응 사용자가 전용 보안 계정의 사용자로 생성되고 기존 페더레이션 또는 Single Sign-On(SSO) 솔루션을 통해 관리되지 않는지 확인합니다. 각 개별 대응 담당자는 자신만의 명명된 계정을 가지고 있어야 합니다. 계정 구성은 강력한 암호 정책 및 다중 인증()을 적용해야 합니다MFA. 인시던트 대응 플레이북에 에 대한 액세스만 필요한 경우 AWS Management Console사용자는 액세스 키를 구성하지 않아야 하며 액세스 키를 생성할 수 없도록 명시적으로 허용해야 합니다. 이는 의 AWS 보안 모범 사례에 언급된 정책 IAM 또는 서비스 제어 정책(SCPs)으로 구성할 수 있습니다AWS Organizations SCPs. 사용자는 다른 계정에서 인시던트 대응 역할을 수임할 수 있는 기능 외에 다른 권한이 없어야 합니다.
인시던트 과정에서 조사, 개선 조치 또는 복구 활동을 지원하기 위해 기타 내부 또는 외부 인력에게 액세스 권한을 부여해야 할 수 있습니다. 이 경우, 이전에 언급한 플레이북 메커니즘을 사용해야 하며, 인시던트가 완료된 후 모든 추가 액세스 권한이 즉시 취소되었는지 확인할 수 있는 프로세스가 반드시 있어야 합니다.
인시던트 대응 역할의 사용을 적절하게 모니터링하고 감사할 수 있는지 확인하려면 이 목적으로 생성된 IAM 계정을 개인 간에 공유하지 않고 특정 작업에 필요하지 않은 한 AWS 계정 루트 사용자 를 사용하지 않는 것이 중요합니다. 루트 사용자가 필요한 경우(예: 특정 계정에 IAM 액세스할 수 없음) 사용 가능한 플레이북이 있는 별도의 프로세스를 사용하여 루트 사용자 로그인 자격 증명 및 MFA 토큰의 가용성을 확인합니다.
인시던트 대응 역할에 대한 IAM 정책을 구성하려면 IAM Access Analyzer를 사용하여 AWS CloudTrail 로그를 기반으로 정책을 생성하는 것이 좋습니다. 이를 위해서는 비프로덕션 계정에서 인시던트 대응 역할에 대한 관리자 액세스 권한을 부여하고 플레이북에 따라 실행해야 합니다. 완료되면 수행된 작업만 허용하는 정책을 생성할 수 있습니다. 그 후 이 정책은 모든 계정의 모든 인시던트 대응 역할에 적용할 수 있습니다. 관리 및 감사가 더 용이하도록 각 플레이북에 대해 별도의 IAM 정책을 생성할 수 있습니다. 플레이북에 포함할 수 있는 예로는 랜섬웨어, 데이터 침해, 프로덕션 액세스의 손실 및 기타 시나리오에 대한 대응 계획이 있을 수 있습니다.
인시던트 응답 계정을 사용하여 IAM 다른 에서 전용 인시던트 응답 역할을 AWS 계정 수임합니다. 이러한 역할은 보안 계정의 사용자만 수임할 수 있도록 구성해야 하며, 신뢰 관계에서는 호출 보안 주체가 를 사용하여 인증해야 합니다MFA. 역할은 엄격한 범위의 IAM 정책을 사용하여 액세스를 제어해야 합니다. 이러한 역할에 대한 모든 AssumeRole 요청이 로그인 CloudTrail 되어 있고 경고가 켜져 있으며 이러한 역할을 사용하여 수행된 모든 작업이 기록되어 있는지 확인합니다.
CloudTrail 로그에서 쉽게 찾을 수 있도록 IAM 계정과 IAM 역할의 이름을 명확하게 지정하는 것이 좋습니다. 예를 들어 IAM 계정 <USER_ID>-BREAK-GLASSBREAK-GLASS-ROLE.
CloudTrail 는 AWS 계정의 API 활동을 기록하는 데 사용되며 인시던트 대응 역할 사용에 대한 알림을 구성하는AssumeRole 이벤트에 filter-to-filter 대한 Amazon CloudWatch
{ $.eventName = "AssumeRole" && $.requestParameters.roleArn = "<INCIDENT_RESPONSE_ROLE_ARN>" && $.userIdentity.invokedBy NOT EXISTS && $.eventType != "AwsServiceEvent" }
인시던트 대응 역할은 높은 수준의 액세스 권한을 가질 가능성이 높기 때문에, 이러한 알림은 광범위한 그룹에 전달되고 신속하게 조치되는 것이 중요합니다.
인시던트가 발생하는 동안 대응 담당자가 에서 직접 보호하지 않는 시스템에 액세스해야 할 수 있습니다IAM. 여기에는 Amazon Elastic Compute Cloud 인스턴스, Amazon Relational Database Service 데이터베이스 또는 software-as-a-service (SaaS ) 플랫폼이 포함될 수 있습니다. SSH 또는 와 같은 기본 프로토콜을 사용하는 대신 Amazon EC2 인스턴스에 대한 모든 관리 액세스에 RDP AWS Systems Manager Session Manager 를 사용하는 것이 좋습니다. 이 액세스는 보안 및 감사 대상IAM인 를 사용하여 제어할 수 있습니다. AWS Systems Manager Run Command 문서를 사용하여 플레이북의 일부를 자동화함으로써 사용자 오류를 줄이고 복구 시간을 단축할 수도 있습니다. 데이터베이스 및 타사 도구에 액세스하려면 에 액세스 자격 증명을 저장 AWS Secrets Manager 하고 인시던트 대응자 역할에 대한 액세스 권한을 부여하는 것이 좋습니다.
마지막으로, 사고 대응 IAM 계정의 관리를 조이너, 무버 및 리브러 프로세스에 추가하고 정기적으로 검토 및 테스트하여 의도한 액세스만 허용되는지 확인해야 합니다.
리소스
관련 문서:
관련 비디오:
관련 예제:
