SEC03-BP03 긴급 액세스 프로세스 설정 - 보안 요소
구현 지침 리소스

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

SEC03-BP03 긴급 액세스 프로세스 설정

중앙 집중식 ID 제공업체에 문제가 발생할 경우 예상치 못한 상황에서 워크로드에 긴급 액세스할 수 있는 프로세스를 만드세요.

긴급 상황을 초래할 수 있는 다양한 장애 모드에 대한 프로세스를 설계해야 합니다. 예를 들어, 정상적인 상황에서는 인력 사용자가 중앙 집중식 자격 증명 공급자(SEC02-BP04)를 사용하여 클라우드에 페더레이션하여 워크로드를 관리합니다. 그러나 중앙 집중식 ID 제공업체에 장애가 발생하거나 클라우드에서의 페더레이션 구성이 수정되면 직원이 클라우드로 페더레이션하지 못할 수 있습니다. 긴급 액세스 프로세스를 통해 권한 있는 관리자는 대체 수단(예: 대체 형태의 페더레이션 또는 직접 사용자 액세스)을 통해 클라우드 리소스에 액세스하여 페더레이션 구성 또는 워크로드 관련 문제를 해결할 수 있습니다. 긴급 액세스 프로세스는 일반 페더레이션 메커니즘이 복원될 때까지 사용됩니다.

원하는 성과:

  • 긴급 상황으로 간주되는 장애 모드를 정의하고 문서화했습니다. 일반적인 상황과 사용자가 워크로드를 관리하기 위해 사용하는 시스템을 고려하세요. 이러한 각 종속성이 어떻게 실패하여 긴급 상황을 초래할 수 있는지 생각해 보세요. 장애 가능성을 최소화하기 위해 장애 모드를 식별하고 보다 탄력적인 시스템을 설계하는 데 유용한 신뢰성 원칙의 질문 및 모범 사례를 찾아볼 수 있습니다.

  • 장애를 긴급 상황으로 확인하기 위해 따라야 하는 단계를 문서화했습니다. 예를 들어 ID 관리자에게 기본 및 대기 ID 제공업체의 상태를 확인하고 둘 다 사용할 수 없는 경우 ID 제공업체 장애에 대한 긴급 이벤트를 선언하도록 요청할 수 있습니다.

  • 각 유형의 긴급 또는 장애 모드에 맞는 긴급 액세스 프로세스를 정의했습니다. 구체적으로 설명하면 모든 유형의 긴급 상황에서 일반 프로세스를 과도하게 사용하려는 사용자의 유혹을 줄일 수 있습니다. 긴급 액세스 프로세스는 각 프로세스를 사용해야 하는 상황과 반대로 프로세스를 사용하지 않아야 하는 상황을 설명하고 적용될 수 있는 대체 프로세스를 가리킵니다.

  • 프로세스는 빠르고 효율적으로 따를 수 있는 상세한 지침과 플레이북과 함께 잘 문서화되어 있습니다. 긴급 상황은 사용자에게 스트레스를 주는 시간이 될 수 있고 사용자들이 극심한 시간 압박을 받을 수 있다는 점을 기억하세요. 따라서 프로세스를 최대한 단순하게 설계하세요.

일반적인 안티 패턴:

  • 긴급 액세스 절차가 제대로 문서화되고 테스트되지 않습니다. 사용자는 긴급 상황에 대비하지 않고 긴급 상황 발생 시 즉흥적인 프로세스를 따릅니다.

  • 긴급 액세스 프로세스는 일반 액세스 메커니즘과 동일한 시스템(예: 중앙 집중식 ID 제공업체)을 기반으로 합니다. 즉, 이러한 시스템에 장애가 발생하면 정상 액세스 메커니즘과 긴급 액세스 메커니즘에 모두 영향을 미치고 장애 복구 능력이 저하될 수 있습니다.

  • 긴급 액세스 프로세스는 비응급 상황에서 사용됩니다. 예를 들어, 사용자는 파이프라인을 통해 변경 사항을 제출하는 것보다 직접 변경하는 것이 더 쉽기 때문에 긴급 액세스 프로세스를 자주 오용합니다.

  • 긴급 액세스 프로세스는 프로세스를 감사하기에 충분한 로그를 생성하지 않거나 프로세스의 오용 가능성에 대해 경고할 수 있도록 로그를 모니터링하지 않습니다.

이 모범 사례 확립의 이점:

  • 잘 문서화되고 테스트를 거친 긴급 액세스 프로세스를 갖추면 사용자가 긴급 상황에 대응하고 해결하는 데 걸리는 시간을 줄일 수 있습니다. 이를 통해 가동 중지 시간이 줄어들고 고객에게 제공하는 서비스의 가용성이 향상될 수 있습니다.

  • 각 긴급 액세스 요청을 추적하고, 프로세스를 긴급 상황이 아닌 이벤트에 악용하려는 무단 시도를 감지하고 경고를 보낼 수 있습니다.

이 모범 사례가 확립되지 않을 경우 노출되는 위험 수준: 중간

구현 가이드

이 섹션에서는 에 배포된 워크로드와 관련된 여러 장애 모드에 대한 긴급 액세스 프로세스를 생성하는 지침을 제공합니다. 모든 장애 모드에 적용되는 일반적인 지침 AWS부터 시작하여 장애 모드 유형에 따른 특정 지침을 따릅니다.

모든 장애 모드에 대한 공통 지침

장애 모드에 대한 긴급 액세스 프로세스를 설계할 때는 다음 사항을 고려하세요.

  • 프로세스의 사전 조건과 전제 조건, 즉 프로세스를 사용해야 하는 시기와 사용하지 말아야 하는 경우를 문서화하세요. 장애 모드를 자세히 설명하고 다른 관련 시스템의 상태와 같은 가정을 문서화하는 데 도움이 됩니다. 예를 들어 장애 모드 2의 프로세스는 자격 증명 공급자를 사용할 수 있지만 의 구성 AWS 이 수정되거나 만료되었다고 가정합니다.

  • 긴급 액세스 프로세스(SEC10-BP05)에 필요한 리소스를 미리 생성합니다. 예를 들어 IAM 사용자 및 역할과 모든 워크로드 계정의 교차 계정 IAM 역할을 AWS 계정 사용하여 긴급 액세스를 미리 생성합니다. 이를 통해 긴급 상황 발생 시 이러한 리소스가 준비되어 있고 사용할 수 있는지 확인할 수 있습니다. 리소스를 미리 생성하면 비상 시 사용할 수 없는 제어 영역APIs( AWS 리소스 생성 및 수정에 사용됨)에 대한 AWS 종속성이 없습니다. 또한 IAM 리소스를 미리 생성하면 최종 일관성으로 인한 잠재적 지연을 설명할 필요가 없습니다.

  • 인시던트 관리 계획(SEC10-BP02)의 일부로 긴급 액세스 프로세스를 포함합니다. 긴급 상황이 어떻게 추적되고 동료 팀, 경영진 그리고 해당하는 경우 외부 고객 및 비즈니스 파트너와 같은 조직 내 다른 사람에게 전달되는지 문서화하세요.

  • 기존 서비스 요청 워크플로 시스템(있는 경우)에서 긴급 액세스 요청 프로세스를 정의하세요. 일반적으로 이러한 워크플로우 시스템에서는 접수 양식을 만들어 요청에 대한 정보를 수집하고, 워크플로의 각 단계를 통해 요청을 추적하며, 자동 승인 단계와 수동 승인 단계를 모두 추가할 수 있습니다. 각 요청을 인시던트 관리 시스템에서 추적되는 해당 긴급 이벤트와 연관시키세요. 긴급 액세스를 위한 통일된 시스템을 구축하면 단일 시스템에서 이러한 요청을 추적하고, 사용 추세를 분석하며, 프로세스를 개선할 수 있습니다.

  • 긴급 액세스 프로세스는 승인된 사용자만 시작할 수 있고 필요에 따라 사용자의 동료 또는 경영진의 승인이 필요한지 확인하세요. 승인 절차는 업무 시간 내외에서 모두 효과적으로 운영되어야 합니다. 1차 승인자를 사용할 수 없고 승인될 때까지 관리망에 에스컬레이션되는 경우 승인 요청을 2차 승인자가 허용할 수 있는 방법을 정의합니다.

  • 프로세스에서 긴급 액세스 시도 성공 및 실패 모두에 대한 자세한 감사 로그 및 이벤트를 생성하는지 확인합니다. 요청 프로세스와 긴급 액세스 메커니즘을 모두 모니터링하여 오용 또는 무단 액세스를 탐지합니다. 활동을 인시던트 관리 시스템의 진행 중인 긴급 이벤트와 연관시키고 예상 시간 외에 조치가 발생할 경우 경보를 보냅니다. 예를 들어 정상 운영 환경에서는 절대 사용해서는 안 되므로 긴급 액세스 AWS 계정활동을 모니터링하고 경고해야 합니다.

  • 긴급 액세스 프로세스를 정기적으로 테스트하여 단계가 명확한지 확인하고 올바른 액세스 수준을 빠르고 효율적으로 부여하세요. 긴급 액세스 프로세스는 인시던트 대응 시뮬레이션(SEC10-BP07) 및 재해 복구 테스트(REL13-BP03)의 일부로 테스트해야 합니다.

실패 모드 1: 페더레이션에 사용되는 ID 공급자 AWS 를 사용할 수 없음

SEC02-BP04 중앙 집중식 자격 증명 공급자 에 의존하는 에 설명된 대로, 중앙 집중식 자격 증명 공급자를 사용하여 인력 사용자에게 에 대한 액세스 권한을 부여하도록 페더레이션하는 것이 좋습니다 AWS 계정. IAM Identity Center를 사용하여 AWS 조직의 여러 AWS 계정 에 페더레이션하거나 를 사용하여 개별 AWS 계정 에 페더레이션할 수 있습니다IAM. 두 경우 모두, 직원이 Single Sign On을 위해 AWS 로그인 엔드포인트로 리디렉션되기 전에 중앙 집중식 ID 제공업체를 통해 인증합니다.

드문 경우지만 중앙 집중식 ID 제공업체를 사용할 수 없는 경우 직원은 AWS 계정 에 페더레이션하거나 워크로드를 관리할 수 없습니다. 이 긴급 상황에서는 소수의 관리자가 에 액세스하여 중앙 집중식 자격 증명 공급자가 다시 온라인 상태가 될 때까지 기다릴 수 없는 중요한 작업을 AWS 계정 수행할 수 있는 긴급 액세스 프로세스를 제공할 수 있습니다. 예를 들어 자격 증명 공급자를 4시간 동안 사용할 수 없으며, 이 기간 동안 고객 트래픽의 예상치 못한 급증을 처리하려면 프로덕션 계정에서 Amazon EC2 Auto Scaling 그룹의 상한을 수정해야 합니다. 비상 관리자는 비상 액세스 프로세스를 따라 특정 프로덕션에 액세스 AWS 계정 하고 필요한 변경을 수행해야 합니다.

비상 액세스 프로세스는 비상 액세스에만 AWS 계정 사용되고 비상 액세스 프로세스를 지원하는 AWS 리소스(예: IAM 역할 및 IAM 사용자)가 있는 미리 생성된 비상 액세스에 의존합니다. 정상적으로 운영되는 동안에는 아무도 긴급 액세스 계정에 접속해서는 안 되며 이 계정의 오용을 모니터링하고 경고해야 합니다(자세한 내용은 이전 공통 지침 섹션 참조).

긴급 액세스 계정에는 긴급 액세스가 필요한 의 교차 계정 IAM 역할을 수임할 수 AWS 계정 있는 권한이 있는 긴급 액세스 역할이 있습니다. 이러한 IAM 역할은 미리 생성되고 비상 계정의 IAM 역할을 신뢰하는 신뢰 정책으로 구성됩니다.

긴급 액세스 프로세스는 다음 방법 중 하나를 사용할 수 있습니다.

  • 연결된 강력한 암호 및 MFA 토큰을 사용하여 긴급 액세스 계정에서 긴급 관리자를 위한 IAM 사용자 세트를 미리 생성할 수 있습니다. 이러한 IAM 사용자는 긴급 액세스가 필요한 에 대한 교차 계정 액세스를 허용하는 IAM 역할을 수임할 AWS 계정 수 있는 권한이 있습니다. 가능한 한 적은 수의 사용자를 생성하고 각 사용자를 한 명의 긴급 관리자에게 할당하는 것이 좋습니다. 비상 시 비상 관리자 사용자는 암호와 MFA 토큰 코드를 사용하여 비상 액세스 계정에 로그인하고, 비상 계정의 비상 액세스 IAM 역할로 전환한 다음, 마지막으로 워크로드 계정의 비상 액세스 IAM 역할로 전환하여 비상 변경 작업을 수행합니다. 이 접근 방식의 장점은 각 IAM 사용자가 한 명의 긴급 관리자에게 할당되고 CloudTrail 이벤트를 검토하여 어떤 사용자가 로그인했는지 알 수 있다는 것입니다. 단점은 연결된 장기 암호 및 MFA 토큰을 사용하여 여러 IAM 사용자를 유지해야 한다는 것입니다.

  • 비상 액세스 AWS 계정 루트 사용자를 사용하여 비상 액세스 계정에 로그인하고, 비상 액세스 IAM 역할을 맡으며, 워크로드 계정에서 교차 계정 역할을 맡을 수 있습니다. 루트 사용자에 대해 강력한 암호와 여러 MFA 토큰을 설정하는 것이 좋습니다. 또한 강력한 인증 및 권한을 적용하는 안전한 엔터프라이즈 자격 증명 저장소에 암호와 MFA 토큰을 저장하는 것이 좋습니다. 암호 및 MFA 토큰 재설정 요소를 보호해야 합니다. 계정의 이메일 주소를 클라우드 보안 관리자가 모니터링하는 이메일 배포 목록으로 설정하고 계정의 전화번호를 보안 관리자가 모니터링하는 공유 전화번호로 설정합니다. 이 접근 방식의 장점은 한 세트의 루트 사용자 자격 증명을 관리할 수 있다는 것입니다. 단점은 공유 사용자이기 때문에 여러 관리자가 루트 사용자로 로그인할 수 있다는 것입니다. 엔터프라이즈 볼트 로그 이벤트를 감사하여 루트 사용자 암호를 체크아웃한 관리자를 식별해야 합니다.

실패 모드 2: 의 ID 공급자 구성 AWS 이 수정되었거나 만료되었습니다.

인력 사용자가 에 페더레이션할 수 있도록 외부 IAM 자격 증명 공급자를 사용하여 Identity Center를 구성하거나 IAM 자격 증명 공급자(SEC02-BP04)를 생성할 AWS 계정수 있습니다. 일반적으로 자격 증명 공급자가 제공한 SAML 메타데이터 XML 문서를 가져와서 이러한 문서를 구성합니다. 메타데이터 XML 문서에는 자격 증명 공급자가 어SAML설션에 서명하는 데 사용하는 프라이빗 키에 해당하는 X.509 인증서가 포함되어 있습니다.

AWS면의 이러한 구성은 관리자가 실수로 수정하거나 삭제할 수 있습니다. 또 다른 시나리오에서는 로 가져온 X.509 인증서가 만료될 AWS 수 있으며 새 인증서가 XML 포함된 새 메타데이터가 아직 로 가져오지 않았습니다 AWS. 두 시나리오 모두 인력 사용자의 페더레이션 AWS 을 로 중단하여 긴급 상황이 발생할 수 있습니다.

이러한 비상 상황에서는 ID 관리자에게 AWS 에 대한 액세스 권한을 제공하여 페더레이션 문제를 해결할 수 있습니다. 예를 들어 자격 증명 관리자는 긴급 액세스 프로세스를 사용하여 긴급 액세스 에 로그인하고 AWS 계정, Identity Center 관리자 계정의 역할로 전환하고, 자격 증명 공급자에서 최신 SAML 메타데이터 XML 문서를 가져와 외부 자격 증명 공급자 구성을 업데이트하여 페더레이션을 다시 활성화합니다. 페더레이션이 수정되면 인력 사용자는 계속해서 일반 운영 프로세스를 사용하여 워크로드 계정에 페더레이션합니다.

이전 장애 모드 1에 설명된 접근 방식에 따라 긴급 액세스 프로세스를 만들 수 있습니다. ID 관리자에게 Identity Center 관리자 계정에만 액세스하고 해당 계정의 Identity Center에서 작업을 수행할 수 있는 최소 권한 권한을 부여할 수 있습니다.

장애 모드 3: Identity Center 중단

드물지만 IAM Identity Center 또는 AWS 리전 중단이 발생할 경우 에 대한 임시 액세스를 제공하는 데 사용할 수 있는 구성을 설정하는 것이 좋습니다 AWS Management Console.

긴급 액세스 프로세스는 ID 공급자의 직접 페더레이션을 긴급 계정IAM의 로 사용합니다. 프로세스 및 설계 고려 사항에 대한 자세한 내용은 Set up emergency access to the AWS Management Console을 참조하세요.

구현 단계

모든 장애 모드에 대한 공통 단계

  • 긴급 액세스 프로세스 AWS 계정 전용 을 생성합니다. IAM 역할 또는 IAM 사용자, 선택적으로 IAM 자격 증명 공급자와 같이 계정에 필요한 IAM 리소스를 미리 생성합니다. 또한 긴급 액세스 계정의 해당 IAM 역할과 신뢰 관계가 AWS 계정 있는 워크로드에서 교차 계정 IAM 역할을 미리 생성합니다. AWS CloudFormation StackSets 와 AWS Organizations를 사용하여 조직의 멤버 계정에 이러한 리소스를 생성할 수 있습니다.

  • 멤버 에서 교차 계정 IAM 역할의 삭제 및 수정을 거부하려면 서비스 제어 정책(SCPs)을 생성합니다 AWS Organizations AWS 계정.

  • CloudTrail 긴급 액세스를 활성화 AWS 계정 하고 로그 컬렉션 의 중앙 S3 버킷으로 추적 이벤트를 전송합니다 AWS 계정. 를 사용하여 AWS Control Tower AWS 다중 계정 환경을 설정하고 관리하는 경우 AWS Control Tower 또는 에 등록하는 모든 계정 AWS Control Tower 은 기본적으로 CloudTrail 활성화되어 전용 로그 아카이브 의 S3 버킷으로 전송됩니다 AWS 계정.

  • 콘솔 로그인 및 긴급 IAM 역할별 활동에 일치하는 EventBridge 규칙을 생성하여 긴급 액세스 계정의 API 활동을 모니터링합니다. 인시던트 관리 시스템에서 추적되는 진행 중인 긴급 이벤트 외부에서 활동이 발생하는 경우 보안 운영 센터에 알림을 보냅니다.

장애 모드 1의 추가 단계: 페더레이션에 사용되는 ID 공급자 AWS 를 사용할 수 없으며 장애 모드 2: 의 ID 공급자 구성 AWS 이 수정되었거나 만료되었습니다.

  • 긴급 액세스를 위해 선택한 메커니즘에 따라 리소스를 미리 생성하세요.

    • IAM 사용자 사용: 강력한 암호와 연결된 MFA 디바이스를 사용하여 IAM 사용자를 미리 생성합니다.

    • 긴급 계정 루트 사용자 사용: 강력한 암호로 루트 사용자를 구성하고 엔터프라이즈 자격 증명 저장소에 암호를 저장합니다. 여러 물리적 MFA 디바이스를 루트 사용자와 연결하고 비상 관리자 팀의 구성원이 빠르게 액세스할 수 있는 위치에 디바이스를 저장합니다.

장애 모드 3: Identity Center 중단의 추가 단계

  • 에 대한 긴급 액세스 설정 AWS Management Console의 에 설명된 대로 긴급 액세스 에서 IAM 자격 증명 공급자를 AWS 계정생성하여 자격 증명 공급자의 직접 SAML 페더레이션을 활성화합니다.

  • IdP에 구성원 없이 긴급 운영 그룹을 만드세요.

  • 비상 액세스 계정에서 비상 작업 그룹에 해당하는 IAM 역할을 생성합니다.

리소스

관련 Well-Architected 모범 사례:

관련 문서:

관련 비디오:

관련 예제: