이 문서에서는 Google Cloud 리소스에 대한 연속적인 액세스를 유지하는 데 도움이 되는 권장사항을 제공합니다. 비즈니스 연속성은 서비스 중단이나 재해와 같은 중단 상황에서도 조직이 필수 운영을 유지할 수 있도록 하는 것을 목표로 합니다. 여기에는 중요 서비스와 인프라를 사용할 수 없는 경우에도 직원이 계속 액세스할 수 있도록 보장하는 것이 포함됩니다.
이 문서는 Identity and Access Management(IAM)와 Google Cloud보안 액세스 유지보수를 담당하는 보안 또는 안정성 전문가를 대상으로 합니다. 또한 이 문서에서는 사용자가 Cloud ID, Google Workspace, IAM 관리에 이미 익숙하다고 가정합니다.
서비스 중단에 대비하고 지속적인 액세스를 보장하기 위해 이 문서에서는 구현할 수 있는 다음 권장 단계를 다음과 같이 설명합니다. 모든 단계를 수행할 수도 있고 일부만 수행할 수도 있지만, 아래 순서대로 구현하는 것이 좋습니다.
긴급 액세스 설정:Google Cloud 리소스에 대한 최후의 액세스 권한을 사용 설정합니다.
모든Google Cloud 조직에 대해 개별 비즈니스 연속성 요구사항과 관계없이 긴급 액세스를 설정하는 것이 좋습니다.
중요 사용자에 대한 인증 대안 제공: 조직이 싱글 사인온(SSO)을 사용하는 경우 외부 ID 공급업체(IdP)에 중단이 발생하면 직원의 인증 및Google Cloud사용 능력에 영향을 받을 수 있습니다.
조직 전체에 대한 IdP 중단의 영향을 줄이기 위해, 비즈니스 핵심 사용자에게 계속해서 Google Cloud 리소스에 액세스할 수 있도록 인증 대안을 제공하세요.
백업 IdP 사용: IdP 중단 시 모든 사용자가 Google Cloud리소스에 액세스할 수 있도록 대체 IdP를 유지 관리할 수 있습니다.
대체 IdP는 중단 영향을 최소화하는 데 도움이 되지만, 모든 조직에 비용 효율적인 옵션은 아닐 수 있습니다.
다음 섹션에서는 이러한 권장 단계와 권장사항을 설명합니다.
긴급 액세스 설정
긴급 액세스의 목적은Google Cloud 리소스에 대한 최후의 액세스를 가능하게 하고, 액세스를 완전히 상실하는 상황을 방지하는 것입니다.
긴급 액세스 사용자는 다음과 같은 속성을 가집니다.
- Cloud ID 또는 Google Workspace 계정에서 만든 사용자입니다.
- 최고 관리자 권한을 가지고 있으며, 이는 Cloud ID, Google Workspace 또는Google Cloud 리소스에 영향을 주는 잘못된 구성을 해결할 수 있을 만큼 충분한 액세스를 제공합니다.
- 조직 내 특정 직원과 연결되지 않으며 일반 사용자 계정에 적용되는 Joiner, Mover, Leaver(JML) 수명 주기에서 제외됩니다.
- SSO 예외 대상입니다.
다음 섹션에서는 긴급 액세스 사용자를 관리하고 보호할 때 따라야 할 권장사항을 설명합니다.
각 환경에 대해 긴급 액세스 사용자 만들기
프로덕션 워크로드가 호스팅되는 Google Cloud 환경에서는 긴급 액세스가 매우 중요합니다. 테스트 또는 스테이징 목적에 사용되는 Google Cloud 환경에서도 액세스를 잃으면 여전히 업무에 지장을 줄 수 있습니다.
모든 Google Cloud 환경에서 지속적인 액세스를 보장하려면, 각 환경마다 Cloud ID 또는 Google Workspace에 긴급 액세스 사용자를 만들고 유지 관리해야 합니다.
긴급 액세스 중복성 보장
단일 긴급 액세스 사용자만 두면 단일 장애점이 됩니다. 이런 경우 보안 키가 손상되거나 비밀번호를 분실하거나 계정이 정지되면 해당 계정에 대한 액세스가 중단될 수 있습니다. 이러한 위험을 완화하려면 각 Cloud ID 또는 Google Workspace 계정에 대해 둘 이상의 비상 액세스 사용자를 만들면 됩니다.
긴급 액세스 사용자는 높은 수준의 권한을 가지므로, 너무 많이 만들지 마세요. 대부분의 조직에서는 Cloud ID 또는 Google Workspace 계정마다 최소 2명, 최대 5명의 긴급 액세스 사용자를 두는 것이 좋습니다.
긴급 액세스 사용자를 위한 별도의 조직 단위 사용
긴급 액세스 사용자는 특별한 구성이 필요하며 다른 사용자 계정에 적용되는 JML 수명 주기의 대상이 아닙니다.
긴급 액세스 사용자를 일반 사용자 계정과 분리하려면 긴급 액세스 사용자 전용 조직 단위(OU)를 사용하세요. 별도의 OU를 사용하면 긴급 사용자에게만 커스텀 구성을 적용할 수 있습니다.
2단계 인증에 FIDO 보안 키 사용
2단계 인증에는 Fast IDentity Online(FIDO) 보안 키를 사용하세요.
긴급 액세스 사용자는 Cloud ID 또는 Google Workspace 계정에서 높은 권한을 가진 사용자이므로, 반드시 2단계 인증으로 보호해야 합니다.
Cloud Identity 및 Google Workspace가 지원하는 여러 2단계 인증 방법 중에서 FIDO 보안 키를 사용하는 것이 좋습니다. 이 방법은 피싱 공격을 막아주고 강력한 보안을 제공합니다. 모든 긴급 액세스 사용자가 2단계 인증에 FIDO 보안 키를 사용하도록 하려면 다음 단계를 따르세요.
- 긴급 액세스 사용자가 속한 OU에서 2단계 인증을 구성하고, 인증 방법으로 보안 키만 허용합니다.
- 모든 긴급 액세스 사용자에 대해 2단계 인증을 사용 설정합니다.
- 각 긴급 액세스 사용자마다 FIDO 보안 키를 2개 이상 등록합니다.
각 사용자에게 여러 개의 키를 등록하면 보안 키가 손상되어 액세스 권한을 잃는 위험을 줄일 수 있습니다. 또한 긴급 상황에서 사용자가 최소한 하나의 키에는 액세스할 수 있을 가능성을 높일 수 있습니다.
여러 긴급 액세스 사용자가 동일한 보안 키 집합을 함께 사용하는 것도 허용됩니다. 하지만 각 긴급 액세스 사용자마다 서로 다른 보안 키를 사용하는 것이 좋습니다.
사용자 인증 정보와 보안 키 보호를 위한 물리적 보안 통제 사용
긴급 액세스 사용자의 사용자 인증 정보와 보안 키를 보관할 때는 강력한 보호와 긴급 상황 시 가용성 사이의 균형을 유지해야 합니다.
- 승인되지 않은 사람이 긴급 액세스 사용자 인증 정보에 액세스하지 못하도록 하세요. 긴급 액세스 사용자는 이러한 사용자 인증 정보를 긴급 상황에서만 사용해야 합니다.
- 긴급 상황에서 승인된 사람이 지체 없이 사용자 인증 정보에 액세스할 수 있도록 하세요.
소프트웨어 기반 비밀번호 관리자에만 의존하지 않는 것이 좋습니다. 대신 긴급 액세스 사용자의 사용자 인증 정보와 보안 키를 보호하기 위해 물리적 보안 통제 수단을 사용하는 것이 더 좋습니다.
적용할 물리적 보안 통제를 선택할 때는 다음 사항을 고려하세요.
- 가용성 향상:
- 여러 사무실의 보안 금고 등 여러 물리적 위치에 비밀번호 사본을 보관합니다.
- 각 긴급 액세스 사용자에 대해 여러 개의 보안 키를 등록하고 관련된 사무실 위치마다 하나씩 키를 보관합니다.
- 보안 강화: 비밀번호와 보안 키를 서로 다른 장소에 보관합니다.
비밀번호 순환 자동화 지양
긴급 액세스 사용자의 비밀번호 순환을 자동화하면 유용해 보일 수 있습니다. 하지만 이러한 자동화는 보안 침해 위험을 높일 수 있습니다. 긴급 액세스 사용자는 최고 관리자 권한을 가지고 있습니다. 최고 관리자 사용자의 비밀번호를 순환하려면 자동화 도구나 스크립트도 최고 관리자 권한을 가져야 합니다. 이러한 요구사항에 따라 해당 도구가 공격자에게 매력적인 표적이 될 수 있습니다.
전반적인 보안 상황을 약화시키지 않으려면 자동화를 사용하여 비밀번호를 순환하지 마세요.
안전한 비밀번호 사용
긴급 액세스 사용자를 보호하려면 길고 안전한 비밀번호를 사용하도록 하세요. 최소한의 비밀번호 복잡성을 보장하려면 앞서 설명한 것처럼 전용 OU를 사용하고 비밀번호 요구사항을 구현하세요.
비밀번호를 수동으로 순환하지 않는 한 모든 긴급 액세스 사용자에 대해 비밀번호 만료 기능은 사용 중지하세요.
액세스 정책에서 긴급 액세스 사용자 제외
긴급 상황에서는 컨텍스트 인식 액세스 정책 때문에 긴급 액세스 사용자조차 특정 리소스에 액세스하지 못하는 상황이 발생할 수 있습니다. 이러한 위험을 완화하려면 액세스 정책의 모든 액세스 수준에서 최소한 한 명 이상의 긴급 액세스 사용자를 제외하세요.
이러한 예외를 두면 최소한 한 명 이상의 긴급 액세스 사용자가 항상 리소스에 지속적으로 액세스하도록 보장할 수 있습니다. 긴급 상황이나 컨텍스트 인식 액세스 정책이 잘못 구성된 경우에도 이러한 긴급 액세스 사용자는 액세스 권한을 유지할 수 있습니다.
긴급 액세스 사용자 이벤트에 대한 알림 설정
긴급 상황이 아닌데 긴급 액세스 사용자가 활동을 하면, 이는 의심스러운 행위일 가능성이 높습니다. 긴급 액세스 사용자 활동과 관련된 이벤트에 대해 알림을 받으려면 Google 관리 콘솔에서 보고 규칙을 만드세요. 보고 규칙을 만들 때는 다음과 같은 조건을 설정할 수 있습니다.
- 데이터 소스: 사용자 로그 이벤트
조건 작성 도구 탭의 속성: 속성과 연산자를 사용하여 긴급 액세스 사용자가 속한 OU와 이벤트를 필터링하는 조건을 만듭니다.
예를 들어 속성과 연산자를 설정하여 다음 조건문과 유사한 필터를 만들 수 있습니다.
Actor organizational unit Is /Privileged AND (Event Is Successful login OR Event Is Failed login OR Event Is Account password change)기준점: 매 1시간마다, 개수가 0보다 클 때
작업: 이메일 알림 전송
이메일 수신자: 보안팀의 관련 구성원이 포함된 그룹을 선택합니다.
중요한 사용자에 대한 인증 대안 제공
조직에서 SSO를 사용해 직원들이 Google 서비스에 인증하도록 한다면, 서드 파티 IdP의 가용성이 중요해집니다. IdP가 중단되면 직원들이 필수 도구와 리소스에 액세스하지 못할 수 있습니다.
긴급 액세스는 연속적인 관리 액세스를 보장하는 데는 도움이 되지만, IdP 중단 시 직원들의 필요까지 충족하지는 못합니다.
IdP 중단이 미칠 수 있는 영향을 줄이려면 Cloud ID 또는 Google Workspace 계정에서 중요 사용자에게 인증 대안을 제공하도록 구성할 수 있습니다. 다음과 같은 대체 계획을 사용할 수 있습니다.
- 정상 운영 시: 사용자가 SSO를 통해 인증하도록 허용합니다.
- IdP 중단 시: 중요 사용자에 대해서만 SSO를 선택적으로 사용 중지하고, 미리 프로비저닝해 둔 Google 로그인 사용자 인증 정보를 사용해 인증하도록 합니다.
다음 섹션에서는 외부 IdP 중단 시 중요 사용자가 인증할 수 있도록 할 때의 권장사항에 대해 설명합니다.
권한 있는 사용자에게 집중
중요 사용자가 IdP 중단 중에 인증하려면 다음과 같은 유효한 Google 로그인 사용자 인증 정보가 있어야 합니다.
- 보안 키를 사용한 비밀번호 기반 2단계 인증
- 패스키
일반적으로 SSO를 사용하는 사용자에게 Google 로그인 사용자 인증 정보를 프로비저닝하면 다음과 같은 방식으로 운영 오버헤드와 사용자 불편이 증가할 수 있습니다.
- 사용하는 IdP에 따라 사용자 비밀번호를 자동으로 동기화하지 못할 수 있습니다. 따라서 사용자가 직접 비밀번호를 설정하도록 요청해야 할 수 있습니다.
- 사용자에게 패스키 등록이나 2단계 인증 등록을 요청해야 할 수 있습니다. 이는 일반적으로 SSO 사용자에게 요구되지 않는 단계입니다.
Google 서비스에 끊김 없는 액세스가 주는 이점과 추가적인 오버헤드 간의 균형을 맞추려면 권한 있는 사용자와 비즈니스상 중요한 사용자에 집중하세요. 이 사용자들은 끊김 없는 액세스의 혜택을 크게 받을 가능성이 높으며 전체 사용자 기반에서는 이러한 이점이 일부에 불과할 수 있습니다.
사후 SSO 인증을 사용 설정하는 기회 활용
권한 있는 사용자에게 대체 인증을 프로비저닝하면 의도하지 않게 오버헤드가 늘어날 수 있습니다. 이러한 오버헤드를 상쇄하기 위해 해당 사용자에게 사후 SSO 인증을 사용 설정할 수도 있습니다.
기본적으로 사용자를 위해 SSO를 설정하면 2단계 인증을 수행할 필요가 없습니다. 이는 편리하지만, IdP가 침해되었을 때 사후 SSO 인증이 사용 설정되지 않은 사용자가 사용자 인증 정보 위조 공격의 대상이 될 수 있습니다.
사후 SSO 인증은 사용자가 SSO를 시도할 때마다 반드시 2단계 인증을 수행하도록 하여, IdP 보안 침해가 가져올 수 있는 잠재적 영향을 완화하는 데 도움이 됩니다. 권한 있는 사용자에게 Google 로그인 사용자 인증 정보를 프로비저닝하는 경우 사후 SSO 인증을 통해 추가적인 오버헤드 없이 해당 사용자 계정의 보안 상황을 강화할 수 있습니다.
권한 있는 사용자를 위한 별도의 OU 사용
외부 IdP 중단 중에 인증할 수 있는 권한 있는 사용자에게는 특별한 구성이 필요합니다. 이 구성은 일반 사용자 및 긴급 액세스 사용자의 구성과 다릅니다.
권한 있는 사용자를 이러한 다른 사용자 계정과 분리하려면 권한 있는 사용자를 위한 전용 OU를 사용하세요. 별도의 OU를 사용하면 사후 SSO 인증과 같은 커스텀 정책을 권한 사용자들에게만 적용할 수 있습니다.
또한 별도의 OU를 사용하면 IdP 중단 시 권한 있는 사용자에 대해서만 SSO를 선택적으로 사용 중지할 수 있습니다. OU의 SSO를 사용 중지하려면 SSO 프로필 할당을 수정하면 됩니다.
백업 IdP 사용
IdP 중단 중 중요 사용자에게 인증 대안을 제공하면 조직에 미치는 IdP 중단의 영향을 줄일 수 있습니다. 하지만 이러한 완화 전략만으로는 전체 운영 능력을 유지하기에 충분하지 않을 수 있습니다. 여전히 많은 사용자가 필수 애플리케이션과 서비스에 액세스하지 못할 수 있습니다.
IdP 중단의 잠재적 영향을 더욱 줄이려면 백업 IdP로 장애 조치를 할 수 있습니다. 다음과 같은 백업 계획을 사용할 수 있습니다.
- 정상 운영 시: 사용자가 SSO와 기본 IdP를 통해 인증하도록 허용합니다.
- IdP 중단 시: Cloud ID 또는 Google Workspace 계정의 SSO 구성을 변경하여 백업 IdP로 전환합니다.
백업 IdP는 동일한 벤더일 필요는 없습니다. 백업 IdP를 만들 때는 기본 IdP의 구성과 일치하는 구성을 사용해야 합니다. 또한 백업 IdP가 모든 사용자가 Google 서비스에 인증하고 액세스할 수 있도록 하려면, 백업 IdP는 기본 IdP 사용자 기반의 최신 사본을 사용해야 합니다.
백업 IdP는 포괄적인 긴급 액세스를 제공하는 데 도움이 될 수 있습니다. 하지만 백업 IdP가 초래할 수 있는 추가 위험과 이러한 장점을 함께 고려해야 합니다. 잠재적인 위험에는 다음이 포함됩니다.
- 백업 IdP의 보안이 기본 IdP보다 약한 경우 장애 조치 중 전체 Google Cloud 환경의 보안 상황이 약화될 수 있습니다.
- 기본 IdP와 백업 IdP가 SAML 어설션을 발급하는 방식이 다르면, 사용자들이 스푸핑 공격 위험에 노출될 수 있습니다.
다음 섹션에서는 백업 IdP를 사용해 긴급 액세스를 제공할 때 권장되는 권장사항에 대해 설명합니다.
백업 IdP를 위한 별도의 SAML 프로필 만들기
Cloud ID 및 Google Workspace에서는 여러 개의 SAML 프로필을 만들 수 있습니다. 각 SAML 프로필은 서로 다른 SAML IdP를 참조할 수 있습니다.
백업 IdP로 장애 조치할 때 필요한 작업을 최소화하려면 사전에 백업 IdP용 SAML 프로필을 준비하세요.
- 기본 IdP와 백업 IdP 각각에 대해 별도의 SAML 프로필을 만듭니다.
- 정상 운영 시에는 SSO 프로필 할당을 구성하여 기본 IdP의 SAML 프로필만 할당합니다.
- IdP 중단 시에는 SSO 프로필 할당을 수정하여 백업 IdP의 SAML 프로필을 사용합니다. 개별 SAML 프로필 설정을 변경하지 마세요.
기존 온프레미스 IdP 사용
백업 용도로 추가 IdP를 별도로 프로비저닝할 필요는 없습니다. 대신, 기존 온프레미스 IdP를 이 목적으로 활용할 수 있는지 확인하세요. 예를 들어 조직에서 Active Directory를 ID의 권한 소스로 사용하고, 동시에 Active Directory Federation Services(AD FS)를 SSO에 사용하고 있을 수 있습니다. 이 경우, AD FS를 백업 IdP로 사용할 수 있습니다.
이러한 재사용 방식은 비용과 유지보수 오버헤드를 줄이는 데 도움이 됩니다.
필요한 부하를 처리하도록 백업 IdP 준비
인증을 백업 IdP로 전환하면 백업 IdP는 기본 IdP가 평소 처리하던 모든 인증 요청을 처리해야 합니다.
백업 IdP를 배포하고 규모를 산정할 때는 예상 요청 수가 다음 요소들에 따라 달라진다는 점을 유의하세요.
- Cloud ID 또는 Google Workspace 계정의 사용자 수
- 구성된 Google Cloud 세션 길이
예를 들어 세션 길이가 8~24시간 사이로 설정되어 있다면, 직원들이 하루 업무를 시작하는 아침 시간대에 인증 요청이 급증할 수 있습니다.
주기적으로 장애 조치 절차 테스트
SSO 장애 조치 프로세스가 안정적으로 작동하도록 하려면 해당 절차를 주기적으로 확인해야 합니다. 장애 조치 절차를 테스트할 때는 다음을 수행하세요.
- 하나 이상의 OU 또는 그룹의 SSO 프로필 할당을 수동으로 수정하여 백업 IdP를 사용하도록 합니다.
- 백업 IdP로의 SSO가 예상대로 작동하는지 확인합니다.
- 서명 인증서가 최신 상태인지 확인합니다.
다음 단계
- 관리자 계정을 위한 보안 권장사항 검토
- Google Cloud 를 외부 ID 공급업체와 제휴하기 위한 권장사항 자세히 알아보기
- 그 밖의 참조 아키텍처, 다이어그램, 튜토리얼, 권장사항을 알아보려면 Cloud 아키텍처 센터를 확인하세요.
참여자
작성자: 요하네스 파싱 | 클라우드 솔루션 설계자
기타 참여자: 이도 플라토브 | 클라우드 솔루션 설계자