하이브리드 환경에서 기업 사용자 인증

이 문서는 ID 관리 솔루션을 Google Cloud로 확장하여 기업 사용자가 하이브리드 컴퓨팅 환경에서 인증하고 서비스를 소비할 수 있도록 하는 방법을 설명하는 문서 시리즈 중 첫 번째 문서입니다.

시리즈는 다음과 같이 구성됩니다.

소개

사용자 계정을 관리하고 애플리케이션과 컴퓨팅 리소스에 대한 직원 액세스를 제어하는 것은 기업 IT 부서의 중요한 책임입니다. 대부분 기업들은 일관성과 관리 효율성을 유지하기 위해 ID 관리를 중앙화하여 통합 시스템을 사용해 ID를 관리합니다. 이러한 목적으로 기업들이 가장 많이 사용하는 것이 Microsoft Active Directory Domain Services(AD DS)입니다.

하이브리드 전략의 일환으로 IT 환경을 Google Cloud로 확장할 경우 ID를 단일 지점에서 관리하는 것이 이상적입니다. 통합 ID 관리 시스템은 계정 및 액세스 제어를 관리하는 데 따른 업무 부담을 최소화합니다. 또한 사용자와 애플리케이션이 하이브리드 환경에서 안전하게 인증을 받는 데도 매우 효과적입니다.

본 문서에서는 Google Cloud를 ID 관리 시스템과 통합할 수 있는 방법에 대해서 알아보겠습니다. 또한 현재 요건에 가장 적합한 접근 방식을 선택하는 데도 유용할 것입니다.

대부분의 논의 내용이 Google Workspace에도 적용되지만 이 문서에서는 Cloud ID에만 중점을 둡니다.

하이브리드 ID 관리의 요구사항 평가

ID 관리 시스템을 Google Cloud로 가장 효과적으로 확장할 수 있는 방법은 몇 가지 요인에 따라 결정됩니다.

  • 조직의 ID 풀
  • 기업 ID에 대한 인증 서비스를 제공하는 데 사용되는 ID 공급업체
  • 기업 사용자가 Google Cloud에서 액세스할 수 있도록 하려는 리소스와 애플리케이션
  • 비즈니스 연속성 요구사항

다음 섹션에서는 이러한 각 요소에 대해 설명합니다.

ID

Google Cloud와 ID 관리 시스템을 통합할 때 살펴봐야 할 첫 번째 요인은 ID를 관리하고 ID 유형을 구분하는 방법입니다. 대부분 조직에서 사용되는 ID 유형은 다음과 같습니다.

  1. 기업 ID는 직원용으로 관리하는 ID입니다. 이러한 ID는 워크스테이션에 로그인하거나, 이메일에 액세스하거나, 기업 애플리케이션을 사용하는 데 사용됩니다.
  2. 외부 ID는 기업 리소스에 액세스할 때 권한이 필요한 계약업체 또는 파트너 같은 직원이 아닌 사람용으로 관리하는 ID입니다.
  3. 게스트 ID는 기업 리소스에 대한 액세스가 필요한 고객 또는 파트너 같은 사용자가 관리하는 ID입니다.
  4. 고객 ID는 웹사이트 또는 고객 대면 애플리케이션과 상호작용할 목적으로 사용자를 대신해 관리하는 ID입니다.
  5. 애플리케이션 ID는 애플리케이션이 다른 애플리케이션 또는 기본 플랫폼과 상호작용할 수 있도록 관리하는 ID입니다.

기업 ID는 단일 ID 풀을 형성하는 경우가 많습니다. 이때는 각 직원마다 ID가 하나씩 할당되며, 모든 ID가 동일한 시스템에서 동일하게 관리됩니다. 하지만 항상 그런 것은 아닙니다. 예를 들어 합병 또는 인수의 결과로 기업 ID 풀이 다수가 되어 각각 다른 시스템에서 다르게 관리되기도 합니다. 기술적으로 봤을 때, 이 말은 다수의 LDAP 소스, Active Directory 포레스트 또는 Azure AD 테넌트를 Google Cloud와 통합해야 할 수도 있다는 것을 의미합니다.

다수의 풀을 통합할 경우 Google Cloud와 통합하는 데 따른 복잡성이 커집니다. 따라서 다음과 같은 사항을 평가해야 합니다.

  • 모든 ID 풀이 Google Cloud에 액세스해야 하나요, 아니면 일부 하위 집합만 액세스해야 하나요?
  • 모든 ID 풀이 Google Cloud의 동일한 조직에 액세스해야 하나요, 아니면 각각 다른 조직에 액세스해야 하나요?
  • 예를 들어 Active Directory 포레스트 사이에 포레스트 간 트러스트를 만들어 풀 수를 줄일 수 있는 옵션이 있나요?

외부 ID는 종종 기업 ID와 유사하게 처리되지만 다음 경우는 예외입니다.

  • 계정이 한시적으로 유효한 경우
  • 기본적으로 적은 수의 권한이 부여되는 경우
  • 별도의 LDAP 디렉터리, Active Directory 포레스트 또는 Azure AD 테넌트에서 관리하는 경우

외부 ID와 달리 게스트 ID는 다른 사용자가 관리합니다. Google Workspace같은 SaaS 애플리케이션에서 게스트 ID를 사용하면 고객이나 파트너를 대신해 외부 ID를 관리할 필요가 없습니다. 따라서 온프레미스 환경에서는 게스트 ID를 사용하는 경우가 거의 없습니다.

본 문서에서는 기업 ID와 외부 ID를 중심으로 설명합니다.

Google Ads 같은 서비스를 사용하였다면 일부 직원은 기업 ID에 연결되지 않은 Google 계정을 이미 가지고 있을 수도 있으며, 이는 ID가 2개라는 것을 의미합니다. 이때는 ID를 통합하는 것이 좋습니다.

ID 공급업체

두 번째로 살펴봐야 할 요인은 ID 공급업체입니다. ID 공급업체(IdP)란 워크로드에 인증 서비스를 제공하여 결과적으로 사용자 인증 여부를 결정하는 시스템을 말합니다.

IdP는 인증 서비스를 제공하는 것 외에도 ID를 직접 관리합니다. 하지만 항상 그렇지는 않습니다. ID가 별도의 인적 자원 시스템에서 프로비저닝되는 경우도 있기 때문입니다.

가장 많이 사용되는 ID 공급업체는 다음과 같습니다.

  • Active Directory(AD DS)
  • Azure Active Directory(Azure AD)
  • IDaaS 공급업체(ForgeRock, Okta, Ping Identity 등)
  • 기타 LDAP 디렉터리(Active Directory Lightweight Directory Services(AD LDS) 포함)

시스템을 하나만 사용하기 보다는 다양한 사용자 풀을 관리하거나, 외부 계정을 처리하거나, 동일한 사용자 풀에 다른 인증 서비스를 제공할 목적으로 여러 시스템을 사용하기도 합니다. 다수의 IdP를 사용해 동일한 풀을 관리하는 예는 다음과 같습니다.

  • Active Directory와 Azure AD의 페더레이션
  • Active Directory와 IDaaS 공급업체(ForgeRock, Okta 또는 Ping Identity)의 페더레이션
  • Active Directory와 AD LDS 복제본의 페더레이션

Google Cloud에서 IdP를 사용하려면 두 가지 기본 접근 방식을 따를 수 있습니다.

  • ID 공급업체와 Cloud ID의 페더레이션: Cloud ID와 페더레이션할 경우 Google이 또 하나의 IdP로 기업 사용자에게 제공되어 Google Cloud에서 배포되는 애플리케이션을 이용할 수 있습니다. 또한 사용자마다 일일이 Google ID를 관리하지 않고 페더레이션 관계에 따라 ID를 자동으로 관리할 수 있습니다. 이 관계는 IdP가 계속해서 정보 소스로 남는 데 있어서도 도움이 됩니다.
  • ID 공급업체를 Google Cloud로 확장: 직접 연결하거나 Google Cloud에 IdP의 복제본을 유지해서 Google Cloud에 배포된 애플리케이션이 IdP를 재사용하도록 할 수 있습니다.

그 밖의 나머지 ID 관리 요인에 따라 위의 두 접근 방식을 결합하여 하이브리드 사용 시나리오를 지원해야 하는 경우도 있습니다.

리소스

세 번째로 살펴봐야 할 요인은 기업 사용자에게 액세스 권한을 부여할 Google Cloud 리소스입니다. 여기에는 Google Cloud 자체도 포함됩니다. 따라서 Cloud Console, gcloud 명령줄 도구, API를 사용해 전담 팀이 Google Cloud를 관리할 수 있도록 허용해야 합니다.

그 밖의 리소스는 다음과 같습니다.

위의 리소스는 Google을 ID 공급업체로 사용해야 하는 경우, 사용할 수 있는 경우 또는 사용할 수 없는 경우에 따라 다릅니다. 다음 섹션부터는 이러한 세 가지 경우에 대해서 알아보겠습니다.

Google을 IdP로 사용해야 하는 리소스

Google을 IdP로 사용해야 하는 리소스로는 Cloud Console, gcloud 도구, IAP를 통해 보호되는 애플리케이션, 기타 Google 도구 및 서비스가 있습니다. 기업 사용자에게 이러한 리소스에 대한 액세스 권한을 부여하려면 먼저 각 사용자마다 Google ID를 프로비저닝해야 합니다.

Google ID를 따로 관리할 경우 ID 통합 관리라는 아이디어를 역행하게 됩니다. 따라서 사용자에게 리소스에 대한 액세스 권한을 부여한다는 말은 IdP를 Google Cloud와 페더레이션해야 한다는 것을 의미합니다.

IdP를 Google Cloud와 페더레이션한 후에는 사용자 인증 수단이 다른 애플리케이션을 포함해 더욱 많은 리소스에서 Google을 IdP로 사용하는 것을 고려하세요.

Google을 IdP로 사용할 수 있는 리소스

Google을 IdP로 사용할 수 있지만 현재 그렇게 하지 않는 리소스는 다음과 같습니다.

  • 기업 사용자를 대상으로 Google Cloud에 배포하려는 신규 애플리케이션
  • 기업 사용자를 대상으로 리프트 앤 시프트 방식 또는 개선 및 이동 방식을 통해 Google Cloud로 마이그레이션하려는 기존 애플리케이션

이러한 애플리케이션이 Google을 IdP로 사용할지는 인증 및 승인에 사용되는 프로토콜에 따라 결정됩니다.

웹 싱글 사인온(SSO) 프로토콜

Google은 인증, 승인, 싱글 사인온(SSO)을 처리할 목적으로 몇 가지 업계 표준 프로토콜을 지원합니다. 지원되는 프로토콜은 다음과 같습니다.

  • OAuth 2.0: 모바일 클라이언트, 팻 클라이언트, 기타 비-브라우저 애플리케이션에 적용됩니다.
  • OpenID Connect 1.0(OIDC): 브라우저 기반 애플리케이션에 적용됩니다.
  • SAML 2.0: 제3자 애플리케이션의 통합에 적용됩니다.

애플리케이션을 배포할 계획이라면 OAuth 2.0 또는 OIDC를 우선적으로 선택하는 것이 좋습니다. 두 프로토콜은 널리 사용되고 있을 뿐만 아니라 테스트를 성공적으로 마친 여러 가지 라이브러리와 도구가 제공되기 때문입니다. 또한 두 프로토콜의 사용은 Google을 IdP로 선택하여 사용하는 동시에 필요에 따라 ID 공급업체를 유연하게 전환할 수 있다는 것을 의미합니다.

SAML, OAuth 2.0 또는 OIDC를 사용하는 애플리케이션이 있을 경우 코드를 거의 또는 전혀 변경하지 않고도 Google을 ID 공급업체로 사용하도록 전환할 수 있어야 합니다.

LDAP

인증 및 승인에 가장 많이, 그리고 다양하게 사용되는 프로토콜 중 하나가 Lightweight Directory Access Protocol(LDAP)입니다. 애플리케이션이 인증 및 승인에 LDAP를 사용할 수 있는 방법은 많습니다. 그중에서 가장 많이 사용되는 두 가지 시나리오는 다음과 같습니다.

  1. 인증 및 사용자 정보 쿼리를 위한 LDAP 사용: 이 시나리오에서는 애플리케이션이 싱글 사인온(SSO)을 사용하지 않습니다. 대신에 사용자 이름과 비밀번호를 묻는 로그인 양식을 사용자에게 표시한 후 입력된 사용자 인증 정보를 사용해 LDAP bind 작업을 시도합니다. 시도에 성공하면 유효한 사용자 인증 정보로 간주합니다. 디렉터리에서 이름, 그룹 멤버십 등 사용자 정보를 추가로 쿼리하여 액세스를 승인하는 데 사용하기도 합니다.

  2. 인증을 위한 SAML 사용과 사용자 정보 쿼리를 위한 LDAP 사용: 이 시나리오에서는 애플리케이션이 싱글 사인온(SSO) 프로토콜을 사용해 사용자를 인증합니다. 이를 위해 종종 SAML이 사용됩니다. 사용자 인증을 마치면 애플리케이션이 LDAP 서버를 사용해 이름, 그룹 멤버십 같은 사용자 정보를 추가로 쿼리합니다.

두 시나리오에서 가장 큰 차이점은 첫 번째 시나리오에서는 애플리케이션과 LDAP 서버가 사용자 인증 정보를 검증하려면 사용자의 비밀번호에 대한 액세스 권한이 필요하다는 사실입니다. 하지만 두 번째 시나리오에서는 애플리케이션과 서버가 사용자 비밀번호에 액세스할 필요가 없습니다. 애플리케이션이 전용 서비스 사용자를 통해 LDAP 쿼리를 수행할 수 있기 때문입니다.

보안 LDAP에서는 LDAP 프로토콜을 사용해 Cloud ID의 사용자 및 그룹 정보에 액세스할 수 있습니다. Google이 기본 IdP인 경우에는 보안 LDAP를 통해 두 시나리오를 모두 지원할 수 있습니다. 하지만 Cloud ID를 외부 IdP와 통합하면 Cloud ID가 사용자 비밀번호의 복사본을 관리하지 않습니다. 그 결과, 두 번째 시나리오에서만 보안 LDAP를 사용할 수 있습니다.

Kerberos 및 NTLM

Windows 기반 워크로드를 Google Cloud로 마이그레이션할 계획이라면 일부 애플리케이션은 표준 프로토콜이 아닌 Windows 통합 인증(IWA)을 사용할 수 있습니다. Microsoft IIS에서 실행되는 ASP.NET 기반 애플리케이션의 경우 일반적으로 IWA를 선택합니다. IWA가 인기 있는 이유는 도메인 사용자 인증 정보를 사용해 Windows 워크스테이션에 로그인한 사용자를 대상으로 매끄러운 싱글 사인온(SSO)이 가능하다는 데 있습니다.

IWA는 NTLM 또는 Kerberos에 의존합니다. 또한 동일한 Active Directory 도메인 또는 트러스팅 도메인에 조인하려면 사용자의 워크스테이션과 애플리케이션이 실행되는 서버가 필요합니다.

NTLM과 Kerberos에 의존하는 데 따른 한 가지 결과는 IWA를 사용하는 애플리케이션이 Google을 IdP로 사용할 수 없다는 것입니다. 하지만 애플리케이션을 리팩토링하여 OIDC를 사용할 수는 있습니다. OIDC는 도메인 조인을 위해 사용자의 워크스테이션이나 서버를 요구하지 않습니다. 따라서 리팩토링은 배포를 간소화하여 대체 배포 옵션을 추구하는 데 유용합니다.

IWA를 사용했을 때 원활하게 제공되는 싱글 사인온(SSO) 경험을 고려했을 때 IWA가 아닌 OIDC 사용은 사용자 경험이라는 측면에서 퇴보하는 것처럼 보일 수도 있습니다. 하지만 사용자가 AD FS 또는 Azure AD에 원활하게 로그인할 수 있다면 반드시 그런 것도 아닙니다.

  • Google Cloud를 Active Directory 및 AD FS와 페더레이션하면 AD FS에 구성된 인증 방법이 모두 적용됩니다. AD FS에서 IWA를 허용하도록 구성하면 도메인 사용자 인증 정보를 사용해 Windows 워크스테이션에 로그인한 사용자가 Google을 IdP로 사용하는 애플리케이션에서도 원활하게 인증을 받을 수 있습니다.
  • Google Cloud를 Azure AD와 페더레이션하면 Azure AD Seamless SSO 기능을 사용하여 동일한 효과를 기대할 수 있습니다.

다음 다이어그램은 Cloud ID, AD FS, IWA를 사용해 웹 애플리케이션에서 원활한 싱글 사인온(SSO)을 구현하는 방법을 간략하게 나타낸 예시입니다.

Cloud ID, AD FS, IWA를 사용해 웹 애플리케이션에서 원활한 싱글 사인온(SSO)을 구현하는 방법

  1. 브라우저에서 웹브라우저를 사용해 보호할 페이지를 요청합니다.
  2. 웹 애플리케이션이 OIDC(OIDC 인증 흐름)를 사용해 로그인을 시작합니다. 이 흐름은 브라우저를 Google 로그인 엔드포인트로 리디렉션합니다.
  3. Google 로그인 엔드포인트는 이메일 주소를 묻는 Google 로그인 페이지를 사용자에게 표시합니다.
  4. 사용자가 자신의 기업 이메일 주소를 입력합니다.
  5. Google 로그인 엔드포인트는 이메일 주소를 근거로 Cloud ID 계정을 찾아 SSO를 사용하도록 구성되어 있는 것을 인식합니다. 그런 다음 로그인 엔드포인트가 AD FS로 SAML 로그인을 시작합니다.
  6. IWA를 사용하도록 구성되어 있는 AD FS가 브라우저에게 Kerberos 티켓을 요구합니다. 그러면 브라우저가 기본 Windows 운영체제에게 적합한 티켓을 가져오도록 요청합니다.
  7. 적합한 티켓이 캐싱되어 있지 않으면 Windows가 Active Directory 키 배포 센터(KDC)에게 사용자가 Windows에 로그인하면서 가져온 허용 티켓(TGT)에 따라 적합한 서비스 티켓을 발급하도록 요청합니다.
  8. 브라우저가 새롭게 가져온 티켓을 AD FS에 제출합니다.
  9. AD FS가 암호화 서명을 확인하여 티켓을 검증한 후 티켓에서 사용자 ID를 추출하여 SAML 티켓을 Google 로그인 엔드포인트에 발급합니다.
  10. Google 로그인 엔드포인트가 SAML 토큰에서 인증 정보를 사용해 OIDC 로그인을 마친 후 OpenID Connect 토큰을 웹 애플리케이션에 발급합니다.
  11. 사용자가 인증되면 보호되는 페이지를 사용자에게 반환할 수 있습니다.

SSH 공개 키 인증

Google Cloud에서 Linux 가상 머신(VM)을 실행할 계획이라면 이러한 가상 머신에 대한 SSH 액세스가 필요할 가능성이 높습니다. 이때 가장 많이 사용되는 SSH 인증 방법은 공개 키 인증입니다.

앞에서 언급한 싱글 사인온(SSO) 프로토콜과 달리 SSH 공개 키 인증은 인증 여부를 결정하기 위해 중앙 IdP를 이용하지 않습니다. 대신 인증 결정이 분산되어 각 가상 머신마다 승인된 로컬 공개 키 세트에 따라 인증을 처리합니다.

분산된 SSH 공개 키 인증과 중앙 ID 관리 사이의 차이는 아래 세 가지 프로비저닝 작업을 중앙 IdP에서 관리하는 사용자 계정의 수명 주기와 연결하여 해결할 수 있습니다.

  • 사용자를 만들거나 처음으로 SSH를 사용하려고 할 때 키 쌍을 만드는 작업
  • 사용자의 공개 키를 사용자가 액세스할 수 있는 머신으로 프로비저닝하는 작업
  • 계정이 액세스 취소되거나, 중지되거나, 삭제되어 사용자의 공개 키 프로비저닝을 해제하는 작업

차이를 해결하기 위해 커스텀 도구를 사용하지 않고 Linux 게스트 환경을 Linux VM에 설치할 수 있습니다. 게스트 환경에는 사용자 계정 및 SSH 키 관리를 Cloud IAM에 따라 자동화하는 스크립트 및 데몬 집합이 포함됩니다. 이러한 환경을 사용하면 Cloud ID가 Linux 인스턴스의 IdP가 될 수 있습니다.

Google을 IdP로 사용할 수 없는 리소스

일부 리소스는 Google을 IdP로 직접 사용할 수 없습니다. 하지만 아래 두 접근 방식을 결합하면 이러한 리소스도 Google Cloud에서 실행할 수 있습니다.

리소스가 Google IdP에서 지원되지 않는 프로토콜을 이용하는 경우에는 해당 리소스가 Google을 IdP로 사용할 수 없습니다. 지원되지 않는 프로토콜은 다음과 같습니다.

  • 인증용 LDAP: 보안 LDAP를 사용할 경우 Cloud ID에서 LDAP를 통해 사용자 정보를 쿼리하는 데 용이하지만 Cloud ID는 외부 IdP와 페더레이션할 때 인증 용도로 LDAP 사용을 지원하지 않습니다.

    애플리케이션에서 인증 용도로 LDAP를 사용하도록 하려면 온프레미스 LDAP 디렉터리를 노출 또는 복제하거나, Active Directory를 Google Cloud로 확장할 수 있습니다.

  • WS-트러스트, WS-페더레이션: 특히 AD FS를 사용하는 경우에도 여전히 WS-트러스트 또는 WS-페더레이션을 이용해 토큰 기반 인증을 처리할 수 있습니다. 관련 애플리케이션을 변경해 SAML 또는 OpenID Connect를 사용할 수 없다면 온프레미스 AD FS를 Google Cloud에 노출시켜 애플리케이션에서 AD FS를 직접 사용할 수 있도록 하는 것이 가장 좋습니다.

  • AD FS 클레임이 포함된 OpenID Connect: AD FS와 Google은 OpenID Connect를 지원합니다. AD FS를 OpenID Connect 공급업체로 사용하였다면 Google에서 지원하지 않는 AD FS 클레임을 일부 이용하고 있을지도 모릅니다. 이 경우 온프레미스 AD FS를 Google Cloud에 노출하여 관련 애플리케이션이 AD FS를 직접 사용하도록 하는 방법을 고려하세요.

  • Kerberos, NTLM: 일부 애플리케이션이 인증 용도로 Kerberos 또는 NTLM을 사용하고 있다면 OpenID Connect 또는 SAML을 사용하도록 수정해야 할 수도 있습니다. 이것이 어렵다면 해당 애플리케이션을 도메인에 조인된 Windows 서버에 배포한 후 온프레미스 Active Directory를 Google Cloud에 노출하거나 복제할 수 있습니다.

  • Windows 가상 머신: Windows 워크로드를 Google Cloud에서 실행할 경우 Remote Desktop Protocol(RDP), Remote Desktop Gateway를 통하거나 다른 수단으로 Windows VM에 로그인할 수 있어야 합니다. 임의 사용자에게 VM이 만들어진 Google Cloud 프로젝트에 대한 쓰기 액세스 권한이 있다면 Google Cloud는 해당 사용자가 사용자 및 비밀번호를 생성할 수 있도록 허용합니다. 따라서 VM의 로컬 Security Account Manager(SAM) 데이터베이스에 계정을 만들 수 있습니다. 중요한 점은 이러한 Windows SAM 계정은 Google 계정에 연결되지 않아 동일한 계정 수명 주기가 적용되지 않는다는 것입니다. 따라서 사용자의 Google 계정을 일시 정지하거나 삭제하더라도 Windows SAM 계정은 영향을 받지 않아 VM에 대한 액세스 권한을 계속해서 부여할 수 있습니다.

    이러한 가상 머신에 대한 로그인이 필요한 Windows VM 및 사용자 수가 많지 않다면 사용자가 Windows 사용자 계정과 비밀번호를 생성할 수 있도록 허용해도 좋습니다. 하지만 대규모 Windows 서버를 관리하고 있다면 온프레미스 Active Directory를 Google Cloud로 확장하여 각 서버를 도메인에 조인하는 방법이 더욱 효과적일 수 있습니다. 또한 네트워크 수준 인증을 이용한다면 서버의 도메인 조인은 필수입니다.

가용성

마지막으로 살펴봐야 할 요인은 가용성입니다. 사용자 인증 기능은 대부분 워크로드에서 중요할 가능성이 높기 때문에 IdP 사용 중단은 광범위하게 영향을 미칠 수 있습니다. 적절한 가용성을 보장하기 위한 올바른 접근 방법은 원하는 Google Cloud 사용 방법과 하이브리드 전략에 대한 Google Cloud의 적합성에 따라 달라집니다.

분산 워크로드

각 컴퓨팅 환경의 고유 기능을 이용하려면 하이브리드 다중 클라우드 방식을 사용해 워크로드를 각 환경으로 분산시킬 수 있습니다. 이러한 환경들은 서로 워크로드 가용성에 중요한 종속 항목을 가질 수 있습니다. 종속 항목으로는 VPN 터널 또는 상호 연결, 서로 통신하는 애플리케이션 또는 컴퓨팅 환경을 넘어 데이터에 액세스하는 시스템 등이 포함될 수 있습니다.

외부 IdP를 Google Cloud와 페더레이션하거나 확장할 때는 외부 IdP를 비롯해 인증에 필요한 기타 시스템의 가용성이 다른 중요한 종속 항목의 가용성을 충족하거나 초과하도록 해야 합니다. 이러한 요구사항은 외부 IdP와 종속 항목을 이중화하여 배포하고 이중화 네트워크 연결을 유지할 수 있어야 한다는 것을 의미합니다.

중복 워크로드

비즈니스 연속성을 유지할 목적으로 Google Cloud를 사용할 경우 Google Cloud의 워크로드는 컴퓨팅 환경에서 실행되는 일부 워크로드를 미러링합니다. 이렇게 설정하는 목적은 장애 발생 시 한쪽 컴퓨팅 환경이 나머지 환경의 역할을 대체할 수 있도록 하기 위해서입니다. 따라서 이러한 환경 간 모든 종속 항목을 살펴봐야 합니다.

Google Cloud가 온프레미스 환경에서 실행되는 외부 IdP를 이용하도록 하면 종속 항목이 만들어집니다. 이러한 종속 항목은 Google Cloud를 컴퓨팅 환경의 독립적인 복사본으로 사용하려는 본래의 의도를 훼손할 수 있습니다.

따라서 온프레미스 컴퓨팅 환경이 중단되거나 Google Cloud와 온프레미스 네트워크 사이의 연결이 중단되었을 때 Google Cloud 기반 워크로드가 전혀 영향을 받지 않도록 하려면 IdP를 Google Cloud로 복제하는 것이 좋습니다.

다음 단계