이 문서에서는 사용해야 하는 Cloud ID 또는 Google Workspace 계정 수, Google Cloud 조직 수, 결제 계정 수를 결정하기 위한 권장사항을 설명합니다. 이 문서에서는 보안 및 조직 요구사항을 충족하는 설계를 식별하는 방법을 안내합니다.
Google Cloud에서 ID 및 액세스 관리는 다음 두 가지 요소를 기반으로 합니다.
Cloud ID 및 Google Workspace 계정은 사용자 및 그룹의 컨테이너입니다. 따라서 이러한 계정은 회사 사용자를 인증하고 Google Cloud 리소스에 대한 액세스를 관리하는 데 중요한 역할을 합니다. Cloud ID 또는 Google Workspace 계정은 개별 사용자 계정이 아닌 사용자 디렉터리를 나타냅니다. 개별 사용자 계정을 사용자 또는 사용자 계정이라고 합니다.
조직은 Google Cloud 내의 프로젝트 및 리소스의 컨테이너입니다. 조직을 사용하면 리소스를 계층적으로 구조화할 수 있으며 중앙에서 효율적으로 리소스를 관리하는 데 중요한 역할을 합니다.
이 문서는 주로 기업 환경을 설정하는 고객을 대상으로 합니다.
Cloud ID 및 Google Workspace 계정
Google Workspace는 클라우드 기반 공동작업 및 생산성 앱 통합 제품군입니다. 여기에는 사용자, 그룹, 인증을 관리할 수 있는 도구가 포함되어 있습니다.
Cloud ID는 Google Workspace 기능의 하위 집합입니다. Google Workspace와 마찬가지로 Cloud ID를 사용하면 사용자, 그룹, 인증을 관리할 수 있지만 Google Workspace의 모든 공동작업 및 생산성 기능은 포함되지 않습니다.
Cloud ID 및 Google Workspace는 공통의 기술 플랫폼을 공유하며 동일한 API 및 관리 도구 모음을 사용합니다. 두 제품은 사용자 및 그룹의 컨테이너로서의 계정 개념을 공유합니다. 이 컨테이너는 example.com과 같은 도메인 이름으로 식별됩니다. 사용자, 그룹, 인증을 관리하기 위해 두 제품을 동일한 제품으로 간주할 수 있습니다.
단일 계정으로 Cloud ID와 Google Workspace 결합
Cloud ID 및 Google Workspace는 공통의 플랫폼을 공유하므로 단일 계정으로 제품에 대한 액세스를 결합할 수 있습니다.
이미 Google Workspace 계정을 관리하고 있고 더 많은 사용자가 Google Cloud를 사용할 수 있도록 하려면 모든 사용자에게 Google Workspace 라이선스를 할당하지 않는 것이 좋습니다. 이 경우 기존 계정에 Cloud Identity Free를 추가합니다. 그런 다음 추가 비용 없이 더 많은 사용자를 참여시킨 후 Google Workspace 라이선스를 할당하여 Google Workspace에 액세스할 수 있는 사용자를 결정할 수 있습니다.
마찬가지로 이미 Cloud Identity Free 또는 프리미엄 계정을 관리하고 있는 경우 특정 사용자에게 Google Workspace를 사용할 수 있는 권한을 부여할 수 있습니다. 이러한 사용자에 대해 별도의 Google Workspace 계정을 만드는 대신 기존 Cloud ID 계정에 Google Workspace를 추가할 수 있습니다. 선택한 사용자에게 Google Workspace 라이선스를 할당하면 사용자는 생산성 및 공동작업 앱을 사용할 수 있습니다.
가능한 한 적은 수의 계정을 사용하지만 필요한 만큼 사용
사용자가 Google Workspace를 사용하여 공동작업하도록 하고 관리 오버헤드를 최소화하려면 단일 Cloud ID 또는 Google Workspace 계정을 통해 모든 사용자를 관리하고 각 개별 사용자에게 단일 사용자 계정을 제공하는 것이 가장 좋습니다. 이 접근방식은 비밀번호 정책, 싱글 사인온(SSO), 2단계 인증과 같은 설정이 모든 사용자에게 일관되게 적용되도록 합니다.
단일 Cloud ID 또는 Google Workspace 계정을 사용할 때의 이점에도 불구하고 여러 계정을 사용하여 유연성과 관리 자율성을 확보할 수 있습니다. 사용할 Cloud ID 또는 Google Workspace 계정 수를 결정할 때 여러 계정을 사용하도록 제안하는 모든 요구사항을 고려하세요. 그런 다음 요구사항을 충족하는 가장 적은 수의 Cloud ID 또는 Google Workspace 계정을 사용하세요.
스테이징 및 프로덕션에 별도의 계정 사용
Cloud ID 및 Google Workspace에서 구성할 수 있는 대부분의 설정에서 각 설정을 적용할 범위를 선택할 수 있습니다. 예를 들어 데이터의 지리적 위치를 사용자, 그룹, 조직 단위별로 지정할 수 있습니다. 새 구성을 적용하려는 경우 처음에는 작은 범위(예: 사용자)를 선택하고 구성이 기대치를 충족하는지 확인할 수 있습니다. 구성을 확인한 후 큰 그룹 또는 조직 단위에 동일한 설정을 적용할 수 있습니다.
대부분의 설정과 달리 Cloud ID 또는 Google Workspace 계정을 외부 ID 공급업체(IdP)와 통합하면 다음과 같은 전역적인 영향을 미칩니다.
- 싱글 사인온(SSO) 사용 설정은 최고 관리자를 제외한 모든 사용자에게 적용되는 전역 설정입니다.
- 외부 IdP에 따라 사용자 프로비저닝을 설정해도 전역적인 영향을 미칩니다. 외부 IdP가 실수로 잘못 구성되는 경우 사용자가 의도치 않게 수정, 정지 또는 삭제될 수 있습니다.
이러한 위험을 완화하기 위해 별도의 스테이징 Cloud ID 또는 Google Workspace 계정과 프로덕션 Cloud ID 또는 Google Workspace 계정이 있어야 합니다.
- 프로덕션 계정에 동일한 변경사항을 적용하기 전에 스테이징 계정을 사용하여 위험한 구성 변경사항을 확인합니다.
- 다른 관리자와 함께 구성 변경사항을 확인하는 데 사용할 수 있는 스테이징 계정에서 몇 가지 테스트 사용자를 만듭니다. 하지만 사용자에게 스테이징 계정에 대한 액세스 권한을 부여하지 마세요.
외부 IdP에 별도의 스테이징 인스턴스 및 프로덕션 인스턴스가 있는 경우 다음 단계를 따르세요.
- 스테이징 Cloud ID 또는 Google Workspace 계정을 스테이징 IdP 인스턴스와 통합합니다.
- 프로덕션 Cloud ID 또는 Google Workspace 계정을 프로덕션 IdP 인스턴스와 통합합니다.
예를 들어 Active Directory와 페더레이션을 설정하고 테스트를 위해 별도의 Active Directory 포리스트가 있다고 가정해 보겠습니다. 이 경우 스테이징 Cloud ID 또는 Google Workspace 계정을 스테이징 포리스트와 통합하고 프로덕션 Cloud ID 또는 Google Workspace 계정을 기본 포리스트와 통합합니다. 다음 다이어그램과 같이 DNS 도메인, 사용자, 그룹의 동일한 매핑 방법을 포리스트/계정 쌍에 적용합니다.
프로덕션 및 스테이징 Active Directory 포리스트와 도메인은 스테이징 및 프로덕션에 동일한 도메인 매핑 방법을 적용할 수 없는 DNS 도메인을 사용할 수 있습니다. 이 경우 스테이징 포리스트에 더 많은 사용자 기본 이름(UPN) 서픽스 도메인을 등록하는 것이 좋습니다.
마찬가지로 Azure Active Directory와 페더레이션을 설정하려는 경우 다음 방법을 사용하는 것이 가장 좋습니다.
- 스테이징 Cloud ID 또는 Google Workspace 계정을 스테이징 Azure Active Directory 테넌트와 통합합니다.
- 프로덕션 Cloud ID 또는 Google Workspace 계정을 기본 Azure Active Directory 테넌트와 통합합니다.
DNS 도메인, 사용자, 그룹의 동일한 매핑 방법을 테넌트/계정 쌍에 적용합니다.
프로덕션 및 스테이징 Azure Active Directory 테넌트는 스테이징 및 프로덕션에 동일한 도메인 매핑 방법을 적용할 수 없는 DNS 도메인을 사용할 수 있습니다. 이 경우 스테이징 테넌트에 도메인을 추가하는 것이 좋습니다.
Cloud ID와 Google Workspace 계정 간에 분리된 DNS 도메인 사용
example.com과 같은 도메인을 Cloud ID 또는 Google Workspace 계정에 처음 추가하는 경우 도메인 소유권을 확인해야 합니다.
도메인을 추가하고 인증한 후에는 각 하위 도메인을 개별적으로 확인하지 않고도 marketing.example.com 및 finance.example.com과 같은 하위 도메인을 추가할 수 있습니다.
그러나 각 하위 도메인을 확인하지 않고 추가하는 경우 이미 이 하위 도메인을 사용하는 다른 Cloud ID 또는 Google Workspace 계정이 있으면 충돌이 발생할 수 있습니다. 이러한 충돌을 방지하려면 각 계정에 대해 분리된 도메인을 사용하는 것이 좋습니다. 예를 들어 두 개의 Cloud ID 또는 Google Workspace 계정이 필요한 경우 한 도메인이 다른 도메인의 하위 도메인인 두 도메인을 사용하지 않아야 합니다. 대신 다른 도메인의 하위 도메인이 아닌 두 도메인을 사용합니다. 이 방법은 기본 도메인 및 보조 도메인에 적용됩니다.
Google Workspace와 Google Cloud 분리 금지
이미 Google Workspace를 사용하고 있다면 Google Workspace 계정의 일부 사용자에게 관리 작업을 수행할 수 있는 최고 관리자 권한이 부여되었을 수 있습니다.
최고 관리자 권한이 있는 사용자에게는 조직 노드의 ID 및 액세스 관리(IAM) 정책을 수정할 수 있는 권한이 암시적으로 부여됩니다. 이 권한을 통해 최고 관리자는 조직 관리자 역할 또는 Google Cloud 조직의 다른 역할을 자신에게 할당할 수 있습니다. 또한 최고 관리자에게 Cloud ID 또는 Google Workspace 계정에 대한 액세스 권한이 있으면 사용자가 계정, 연결된 Google Cloud 조직, 모든 리소스를 삭제할 수 있습니다. 따라서 최고 관리자에게 조직 내의 모든 리소스에 대한 전체 액세스 권한이 있다고 가정해야 합니다.
최고 관리자가 조직 관리자라는 사실은 기존 Google Workspace 관리자가 Google Cloud 조직 관리를 담당하는 사용자와 다른 사용자인 경우 보안 문제가 될 수 있습니다. 이 경우 Google Workspace 최고 관리자의 액세스 권한을 Google Cloud 리소스로 제한하기 위해 Google Cloud를 전담하는 별도의 Cloud ID 계정을 만들 수 있습니다. Google Workspace와 Google Cloud를 분리하면 의도하지 않은 결과가 발생할 수 있습니다.
예를 들어 Cloud ID 계정에서 별도의 사용자를 만든 다음 Google Cloud 조직 사용자에 대한 액세스 권한을 Cloud ID 계정으로 제한할 수 있습니다. 이렇게 하면 Google Cloud 배포와 Google Workspace가 완전히 격리됩니다. 하지만 사용자를 복제하면 사용자 환경과 관리 오버헤드 모두에 부정적인 영향을 미칩니다. 또한 Cloud ID에서 사용하는 도메인은 Google Workspace에 사용된 도메인과 달라야 하고 이메일 라우팅에 적합하지 않으므로 Google Cloud에서 보낸 알림 이메일을 받을 수 없습니다.
대신 Google Cloud 조직의 Google Workspace 계정에서 사용자를 참조하는 경우 Google Workspace와 Google Cloud 간의 격리가 약화됩니다.
Google Workspace 최고 관리자는 도메인 전체 위임을 사용하여 동일한 Google Workspace 계정의 모든 사용자를 가장할 수 있습니다. 악의적인 최고 관리자는 승격된 권한을 사용하여 Google Cloud에 다시 액세스할 수 있습니다.
별도의 계정을 사용하는 것보다 더 효과적인 방법은 Google Workspace 관리자와 Google Cloud 관리자 간의 책임을 분리하여 최고 관리자 수를 줄이는 것입니다.
Google Workspace에서 대부분의 관리 업무에는 최고 관리자 권한이 필요하지 않습니다. 최고 관리자 권한 대신 기본 제공 관리자 역할 또는 커스텀 관리자 역할을 사용하여 Google Workspace 관리자에게 업무를 수행하는 데 필요한 권한을 부여합니다.
최고 관리자 수를 최소한으로 유지하고 일상적인 사용을 억제합니다.
감사 기능을 사용하여 관리자 간의 의심스러운 활동을 감지합니다.
싱글 사인온(SSO) 사용시 외부 IdP 보호
Cloud ID 및 Google Workspace를 사용하면 Active Directory, Azure Active Directory, Okta와 같은 외부 IdP로 싱글 사인온(SSO)을 설정할 수 있습니다. 싱글 사인온(SSO)이 사용 설정된 경우 Cloud ID 및 Google Workspace는 외부 IdP를 신뢰하여 Google을 대신하여 사용자를 인증합니다.
싱글 사인온(SSO)을 사용 설정하면 다음과 같은 몇 가지 이점이 있습니다.
- 사용자는 기존 사용자 인증 정보를 사용하여 Google 서비스에 로그인할 수 있습니다.
- 사용자에게 이미 기존 로그인 세션이 있는 경우 비밀번호를 다시 입력할 필요가 없습니다.
- 애플리케이션과 모든 Google 서비스에 일관된 다단계 인증 정책을 적용할 수 있습니다.
하지만 싱글 사인온(SSO)을 사용 설정하면 위험에 노출됩니다. 싱글 사인온(SSO)을 사용 설정하고 사용자를 인증해야 하는 경우 Cloud ID 또는 Google Workspace에서 사용자를 외부 IdP로 리디렉션합니다. 사용자를 인증한 후 IdP는 사용자 ID를 명시하는 SAML 어설션을 Google에 반환합니다. SAML 어설션에 서명이 있어야 합니다. 따라서 Google에서는 SAML 어설션의 신뢰성을 확인하고 올바른 ID 공급업체가 사용되었는지 확인할 수 있습니다. 하지만 Cloud ID 또는 Google Workspace에서 IdP가 올바른 인증 결정을 내리고 사용자 ID를 올바르게 명시했는지 확인할 수 있는 방법은 없습니다.
싱글 사인온(SSO)을 사용 설정하면 Google 배포의 전반적인 보안과 무결성이 IdP의 보안과 무결성에 따라 결정됩니다. 다음 중 하나라도 보호되지 않은 상태로 구성된 경우 Cloud ID 또는 Google Workspace 계정과 계정에서 관리하는 사용자를 활용하는 모든 리소스가 위험에 노출될 수 있습니다.
- IdP 자체
- 제공업체가 실행 중인 머신
- 제공업체가 사용자 정보를 가져오는 사용자 데이터베이스
- 제공업체가 활용하는 다른 시스템
싱글 사인온(SSO)이 보안 상태에서 취약한 링크가 되지 않도록 하려면 IdP와 IdP가 활용하는 모든 시스템을 안전하게 구성해야 합니다.
- IdP 또는 제공업체가 활용하는 모든 시스템에 대한 관리 액세스 권한이 있는 사용자 수를 제한합니다.
- 사용자에게 Cloud ID 또는 Google Workspace에서 최고 관리자 권한을 부여하지 않는 시스템에 대한 관리 액세스 권한을 부여하지 마세요.
- 외부 IdP에 적용되는 보안 제어가 확실치 않은 경우 싱글 사인온(SSO)을 사용하지 마세요.
DNS 영역에 대한 보안 액세스
Cloud ID 및 Google Workspace 계정은 기본 DNS 도메인 이름으로 식별됩니다. 새 Cloud ID 또는 Google Workspace 계정을 만들면 해당 DNS 영역에 특별한 DNS 레코드를 만들어 DNS 도메인의 소유권을 확인해야 합니다.
DNS의 중요성과 Google 배포의 전반적인 보안에 미치는 영향은 가입 절차 이후까지 확대 적용됩니다.
Google Workspace는 이메일 라우팅에 DNS MX 레코드를 사용합니다. 공격자는 이러한 MX 레코드를 수정하여 이메일을 다른 서버로 라우팅하고 민감한 정보에 액세스할 수 있습니다.
공격자가 DNS 영역에 레코드를 추가할 수 있는 경우 최고 관리자의 비밀번호를 재설정하고 계정에 액세스할 수 있습니다.
DNS가 보안 상태에서 취약한 링크가 되지 않도록 하려면 DNS 서버를 안전하게 구성해야 합니다.
Cloud ID 또는 Google Workspace에 사용된 기본 도메인을 관리하는 DNS 서버에 대한 관리 액세스 권한이 있는 사용자 수를 제한합니다.
사용자에게 Cloud ID 또는 Google Workspace에서 최고 관리자 권한을 부여하지 않는 DNS 서버에 대한 관리 액세스 권한을 부여하지 마세요.
기존 DNS 인프라로 충족되지 않는 보안 요구사항이 있는 워크로드를 Google Cloud에 배포하려면 별도의 DNS 서버 또는 관리형 DNS 서비스를 사용하는 새 DNS 도메인을 해당 워크로드에 등록하는 것이 좋습니다.
BigQuery로 감사 로그 내보내기
Cloud ID 및 Google Workspace는 여러 감사 로그를 유지관리하여 Cloud ID 또는 G Suite 계정의 보안과 관련된 구성 변경사항 및 기타 활동을 추적합니다. 다음 표에는 이러한 감사 로그가 요약되어 있습니다.
| 로그 | 캡처된 활동 |
|---|---|
| 관리 | Google 관리 콘솔에서 수행되는 작업 |
| 로그인 | 도메인에 대한 로그인 완료, 로그인 실패, 의심스러운 로그인 시도 |
| 토큰 | 타사 모바일 또는 웹 애플리케이션에 대한 액세스를 승인하거나 취소하는 인스턴스 |
| 그룹스 | 그룹 및 그룹 멤버십 변경 |
이러한 감사 로그는 관리 콘솔 또는 Reports API를 통해 액세스할 수 있습니다. 대부분의 감사 로그에서는 데이터가 6개월 동안 보관됩니다.
규제 대상 업종에서 운영하는 경우 6개월 동안 감사 데이터를 보관하는 것만으로는 충분하지 않을 수 있습니다. 데이터를 장기간 보관하려면 BigQuery로 내보내도록 감사 로그를 구성합니다.
내보낸 감사 로그에 대한 무단 액세스 위험을 제한하려면 BigQuery 데이터 세트에 전용 Google Cloud 프로젝트를 사용합니다. 감사 데이터를 조작하거나 삭제하지 못하도록 안전하게 유지하려면 최소한의 권한으로 프로젝트 및 데이터 세트에 대한 액세스 권한을 부여하세요.
Cloud ID 및 Google Workspace 감사 로그는 Cloud 감사 로그를 보완합니다. BigQuery를 사용하여 Cloud 감사 로그 및 기타 애플리케이션별 감사 로그를 수집하는 경우 사용자가 Google Cloud 또는 애플리케이션에서 수행한 활동과 로그인 이벤트의 상관관계를 지정할 수 있습니다. 여러 소스에서 감사 데이터의 상관관계를 지정할 수 있으면 의심스러운 활동을 감지하고 분석하는 데 도움이 됩니다.
BigQuery 내보내기를 설정하려면 Google Workspace Enterprise 라이선스가 필요합니다. 기본 감사 로그를 설정하면 Google Workspace 라이선스가 없는 사용자를 포함한 모든 사용자에게 로그가 내보내집니다. 드라이브 및 모바일 감사 로그와 같은 특정 로그는 Google Workspace Business 라이선스가 있는 사용자에게만 내보내집니다.
대부분의 사용자에게 Cloud ID Free를 사용하는 경우 기존 Cloud ID 계정에 Google Workspace Enterprise를 추가하고 선택한 관리자를 위한 Google Workspace 라이선스를 구매하여 BigQuery로 내보낼 수 있습니다.
조직
조직을 사용하면 조직 노드가 루트인 프로젝트 및 폴더의 계층 구조로 리소스를 구성할 수 있습니다. 조직은 Cloud ID 또는 Google Workspace 계정과 연결되며 연결된 계정의 기본 도메인 이름에서 이름을 가져옵니다. Cloud ID 또는 Google Workspace 계정의 사용자가 첫 번째 프로젝트를 만들면 조직이 자동으로 생성됩니다.
각 Cloud ID 또는 Google Workspace 계정에는 하나의 조직만 있을 수 있습니다. 실제로 해당 계정이 없으면 조직을 만들 수 없습니다. 이러한 종속성에도 불구하고 여러 계정의 사용자에게 단일 조직의 리소스에 대한 액세스 권한을 부여 할 수 있습니다.
다른 Cloud ID 또는 Google Workspace 계정의 사용자를 참조할 수 있는 유연성을 통해 계정과 조직을 취급하는 방법을 분리할 수 있습니다. 사용자를 관리하는 데 필요한 Cloud ID 또는 Google Workspace 계정 수에 대한 결정을 리소스를 관리하는 데 필요한 조직 수에 대한 결정과 분리할 수 있습니다.
생성하는 조직의 수와 그 목적은 보안 상태, 팀 및 부서의 자율성, 관리의 일관성 및 효율성에 큰 영향을 미칠 수 있습니다.
다음 섹션에서는 사용할 조직 수를 결정하기 위한 권장사항을 설명합니다.
가능한 한 적은 수의 조직을 사용하지만 필요한 만큼 사용
조직의 리소스 계층 구조를 사용하면 상속을 활용하여 IAM 정책 및 조직 정책을 관리하는 노력을 줄일 수 있습니다. 폴더 또는 조직 수준에서 정책을 구성하면 정책이 리소스의 하위 계층 구조에 일관되게 적용되고 구성 작업이 반복되지 않습니다. 관리 오버헤드를 최소화하려면 가능한 적은 수의 조직을 사용하는 것이 좋습니다.
반면 여러 조직을 사용하여 유연성과 관리 자율성을 강화할 수 있습니다. 다음 섹션에서는 이러한 추가 유연성 또는 자율성을 요구할 수 있는 경우를 설명합니다.
어떤 경우든 사용할 조직 수를 결정할 때 여러 조직을 사용하도록 제안하는 모든 요구사항을 고려하세요. 그런 다음 요구사항을 충족하는 가장 적은 수의 조직을 사용하세요.
조직을 사용하여 관리 권한 설명
리소스 계층 구조 내에서 리소스, 프로젝트, 폴더 수준에서 권한을 부여할 수 있습니다. 사용자에게 권한을 부여할 수 있는 최종 수준은 조직입니다.
조직 수준에서 조직 관리자 역할이 할당된 사용자는 조직, 리소스, IAM 정책을 완전히 제어할 수 있습니다. 조직 관리자는 조직 내의 모든 리소스를 제어할 수 있으며 다른 사용자에게 관리 액세스 권한을 위임할 수 있습니다.
하지만 조직 관리자의 권한은 조직에 한정되어 조직이 관리 권한의 최종 범위가 됩니다.
- 조직 관리자는 명시적으로 권한을 부여하지 않는 한 다른 조직의 리소스에 액세스할 수 없습니다.
- 조직 외부의 사용자는 해당 조직의 조직 관리자로부터 제어 권한을 가져올 수 없습니다.
사용할 수 있는 적절한 조직 수는 회사의 독립적인 관리자 그룹 수에 따라 다릅니다.
- 회사가 기능으로 구성되어 있는 경우 모든 Google Cloud 배포를 총괄하는 단일 부서가 있을 수 있습니다.
- 회사가 여러 부서로 구성되어 있거나 자율적으로 운영되는 여러 자회사를 소유하고 있는 경우 담당하는 단일 부서가 없을 수 있습니다.
단일 부서에서 Google Cloud 배포를 담당하는 경우 단일 Google Cloud 조직 노드를 사용하는 것이 가장 좋습니다. 조직 내에서 폴더를 사용하여 리소스를 구조화하고 다른 팀 및 부서에 다양한 수준의 액세스 권한을 부여합니다.
여러 독립 부서를 처리하는 경우 단일 조직을 사용하여 중앙에서 관리하려고 하면 다음과 같은 문제가 발생할 수 있습니다.
- 조직을 관리할 단일 부서를 지정하는 경우 다른 부서의 저항에 직면할 수 있습니다.
- 여러 팀 또는 부서가 단일 조직을 공동 소유하도록 허용하면 일관된 리소스 계층 구조를 유지하고 리소스 전체에서 IAM 정책 및 조직 정책을 일관되게 사용하기 어려울 수 있습니다.
이러한 문제를 방지하려면 여러 조직을 사용하고 각 조직에 별도의 폴더 구조를 만드세요. 별도의 조직을 사용하면 여러 관리자 그룹 사이에 경계를 설정하여 관리 권한을 설명할 수 있습니다.
별도의 스테이징 조직 사용
일관성을 유지하고 반복적인 구성 작업을 방지하려면 프로젝트를 폴더 계층 구조로 구성하고 IAM 정책 및 조직 정책을 폴더 또는 조직 수준에서 적용합니다.
여러 프로젝트 및 리소스에 적용되는 정책이 있으면 단점이 있습니다. 정책 자체 또는 정책이 적용되는 리소스 계층 구조를 변경하면 광범위하게 의도하지 않은 영향을 미칠 수 있습니다. 이러한 위험을 완화하려면 정책 변경사항을 기본 조직에 적용하기 전에 테스트하는 것이 좋습니다.
별도의 스테이징 조직을 만드는 것이 좋습니다. 이 조직은 액세스 수준 및 정책과 같이 조직 전체에 영향을 미칠 수 있는 기타 구성이나 리소스 계층 구조 변경사항, IAM 정책, 조직 정책을 테스트하는 데 도움이 됩니다.
스테이징 조직에서 수행된 테스트 또는 실험의 결과가 프로덕션 조직에도 적용되도록 하려면 프로젝트 수가 적은 경우에만 기본 조직과 동일한 폴더 구조를 사용하도록 스테이징 조직을 구성합니다. 언제든지 스테이징 조직의 IAM 및 조직 정책이 프로덕션 조직의 정책과 일치하거나 프로덕션 조직에 적용할 다음 버전의 정책을 반영해야 합니다.
다음 다이어그램과 같이 스테이징 Cloud ID 또는 Google Workspace 계정을 스테이징 조직의 기반으로 사용합니다. 스테이징 계정(또는 스테이징 계정이 통합된 외부 IdP)을 사용하여 프로덕션 Cloud ID 또는 Google Workspace 계정에서 사용하는 그룹을 미러링하는 전용 테스트 사용자 및 그룹 구조를 만듭니다. 그런 다음 이러한 전용 테스트 사용자 및 그룹을 사용하면 기존 사용자에게 영향을 주지 않고 IAM 정책을 테스트할 수 있습니다.
별도의 테스트 조직 사용 방지
Google Cloud에 배포하려는 프로덕션 워크로드마다 개발팀과 DevOps팀이 새 출시 버전을 검증하는 데 사용할 수 있는 테스트 환경이 하나 이상 필요할 수 있습니다.
보안 측면에서 테스트되지 않은 출시 버전이 실수로 프로덕션 워크로드에 영향을 미치지 않도록 하려면 테스트 환경을 프로덕션 환경과 완전히 구분합니다. 마찬가지로 두 환경 유형은 IAM 정책에 대한 요구사항이 다릅니다. 예를 들어 개발자와 테스터에게 필요한 유연성을 부여하기 위해 테스트 환경의 보안 요구사항이 프로덕션 환경의 보안 요구사항보다 훨씬 낮을 수 있습니다.
다음 다이어그램과 같이 구성 관점에서 테스트 환경을 프로덕션 환경과 최대한 유사하게 유지합니다. 모든 불일치는 테스트 환경에서 제대로 작동하는 배포가 프로덕션 환경에 배포될 때 실패할 위험을 증가시킵니다.
환경을 격리한 상태에서 일관성을 유지하려면 동일한 조직 내의 폴더를 사용하여 테스트 환경과 프로덕션 환경을 관리합니다.
- 조직 수준에서 또는 공통된 상위 폴더를 사용하여 여러 환경에서 공통적인 IAM 정책 또는 조직 정책을 적용합니다.
- 개별 폴더를 사용하여 여러 유형의 환경 간에 서로 다른 IAM 정책 및 조직 정책을 관리합니다.
테스트 환경을 관리하기 위해 스테이징 조직을 사용하지 마세요. 테스트 환경은 개발팀과 DevOps팀의 생산성에 매우 중요합니다. 스테이징 환경에서 이러한 환경을 관리하면 스테이징 조직을 사용하여 정책 변경사항을 실험하고 테스트하는 기능이 제한됩니다. 이러한 변경사항으로 인해 팀의 작업이 중단될 수 있습니다. 즉, 스테이징 조직을 사용하여 테스트 환경을 관리하는 경우 스테이징 조직의 목적이 약화됩니다.
실험에 별도의 조직 사용
Google Cloud를 최대한 활용하려면 개발팀, DevOps팀, 운영팀이 플랫폼을 숙지하도록 한 후 가이드를 실행하여 사용 경험을 확장합니다. 새로운 기능 및 서비스에 대한 실험을 진행하도록 유도하세요.
이러한 유형의 실험용 활동을 지원하려면 별도의 조직을 샌드박스 환경으로 사용합니다. 별도의 조직을 사용하면 프로덕션 조직에서 사용하는 모든 정책, 구성, 자동화가 실험을 방해하지 않을 수 있습니다.
실험에 스테이징 조직을 사용하지 않도록 합니다. 스테이징 환경은 프로덕션 조직과 유사한 IAM 및 조직 정책을 사용해야 합니다. 따라서 스테이징 환경에는 프로덕션 환경과 동일한 제한사항이 적용될 수 있습니다. 동시에 실험을 허용하기 위해 정책을 완화하면 스테이징 조직의 목적이 약화됩니다.
실험용 조직이 제대로 구성되지 않거나 과도한 비용이 발생하거나 보안 위험의 대상이 되지 않도록 하려면 팀에서 조직을 사용할 수 있는 방법과 조직을 유지관리할 책임이 있는 담당자를 정의하는 가이드라인을 발행합니다. 또한 특정 일수 후에 리소스 또는 전체 프로젝트를 자동으로 삭제하도록 자동화를 설정하는 것이 좋습니다.
다음 다이어그램과 같이 실험용 조직을 만들 때 먼저 전용 Cloud ID 계정을 만듭니다. 그런 다음 기본 Cloud ID 또는 Google Workspace 계정의 기존 사용자를 사용하여 사용자에게 실험용 조직에 대한 액세스 권한을 부여합니다.
추가 Cloud ID 계정을 관리하려면 Cloud ID 계정에 최고 관리자 계정이 하나 이상 있어야 합니다. 이러한 최고 관리자 계정을 보호하는 방법에 대한 자세한 내용은 최고 관리자 계정 권장사항을 참조하세요.
도메인 제한 공유를 사용하여 트러스트 관계 시행
IAM 정책을 사용하면 유효한 Google ID를 구성원으로 추가할 수 있습니다. 즉, 리소스, 프로젝트, 폴더, 조직의 IAM 정책을 수정할 때 다음과 같은 다양한 소스의 구성원을 추가할 수 있습니다.
- 조직이 연결된 Cloud ID 또는 Google Workspace 계정의 사용자와 같은 조직의 서비스 계정
- 다른 Cloud ID 또는 Google Workspace 계정의 사용자
- 다른 조직의 서비스 계정
- 일반 사용자 계정(회사 이메일 주소를 사용하는
gmail.com사용자 및 일반 계정 포함)
여러 소스의 사용자를 참조할 수 있으면 제휴사나 다른 회사와 공동작업해야 하는 시나리오 및 프로젝트에 유용합니다. 대부분의 경우 신뢰할 수 있는 소스의 구성원만 허용하도록 IAM 정책을 제한하는 것이 가장 좋습니다.
도메인 제한 공유를 사용하여 IAM 정책에 구성원을 추가할 수 있는 신뢰할 수 있는 Cloud ID 또는 Google Workspace 계정을 정의합니다. 이 조직 정책을 모든 프로젝트에 적용되도록 조직 수준에서 정의하거나 특정 프로젝트를 제외할 수 있도록 리소스 계층 구조의 상단 근처에 있는 폴더에서 정의합니다.
별도의 Cloud ID 또는 Google Workspace 계정 및 조직을 사용하여 스테이징, 프로덕션, 실험 환경을 분리하는 경우 도메인 제한 공유 정책을 사용하여 다음 표에 나열된 분리를 적용합니다.
| 조직 | 신뢰할 수 있는 Cloud ID 또는 Google Workspace 계정 |
|---|---|
| 스테이징 | 스테이징 |
| 프로덕션 | 프로덕션 |
| 실험 | 프로덕션 |
조직에 중립 도메인 이름 사용
조직은 example.com과 같은 DNS 도메인 이름으로 식별됩니다. 도메인 이름은 연결된 Cloud ID 또는 Google Workspace 계정의 기본 도메인 이름에서 파생됩니다.
회사 전체에서 사용되는 표준 DNS 도메인 이름이 있는 경우 해당 도메인을 프로덕션 Cloud ID 또는 Google Workspace 계정의 기본 도메인으로 사용합니다. 표준 DNS 이름을 사용하면 직원이 조직 노드의 이름을 쉽게 인식할 수 있습니다.
회사에 여러 자회사로 구성되어 있거나 다양한 브랜드를 소유하고 있는 경우 표준 도메인 이름이 없을 수 있습니다. 기존 도메인 중 하나를 임의로 선택하는 대신 Google Cloud 전용으로 사용되는 중립적인 새 DNS 도메인을 등록하는 것이 좋습니다. 중립적인 DNS 이름을 사용하면 클라우드 도입에 부정적인 영향을 미칠 수 있는 회사 내 특정 브랜드, 자회사, 부서의 환경설정을 표현할 수 없습니다. 사용자 ID 및 싱글 사인온(SSO)에 사용할 수 있도록 다른 브랜드별 도메인을 보조 도메인으로 추가합니다.
Google Cloud 조직에서 결제 계정 사용
결제 계정은 특정 Google Cloud 리소스에 대한 비용을 지불하는 사용자를 정의합니다. 결제 계정이 Google Cloud 조직 외부에 있을 수 있지만 일반적으로 조직과 연결됩니다.
결제 계정이 조직과 연결되면 조직의 하위 리소스로 간주되며 조직 내에 정의된 IAM 정책이 적용됩니다. 이것이 의미하는 가장 중요한 점은 결제 IAM 역할을 사용하여 계정을 관리하거나 사용할 수 있는 사용자 또는 그룹을 정의할 수 있다는 것입니다.
Billing Account User 역할이 부여된 사용자는 프로젝트를 결제 계정에 연결하여 리소스가 이 계정에 청구되도록 할 수 있습니다.
프로젝트를 결제 계정에 연결하는 것은 동일한 조직 내에서 뿐만 아니라 조직 전반에서 작동합니다.
여러 조직을 사용하는 경우 조직 전반에서 결제 계정을 사용할 수 있다는 사실을 활용할 수 있습니다. 이렇게 하면 필요한 조직 수에 관계없이 필요한 결제 계정 수를 결정할 수 있습니다.
적절한 결제 계정 수는 통화, 결제 프로필, 필요한 별도의 인보이스 수와 같은 상업 또는 계약 요구사항에 따라 다릅니다. 계정 및 조직과 마찬가지로 복잡성을 최소화하려면 요구사항을 충족하는 가장 적은 수의 결제 계정을 사용합니다.
여러 조직 전반에서 발생한 비용을 세분화하려면 결제 데이터를 BigQuery로 내보내도록 결제 계정을 구성합니다.
BigQuery로 내보낸 각 레코드에는 프로젝트 이름과 ID뿐만 아니라 프로젝트가 연결된 조직의 ID도 포함됩니다(project.ancestry_numbers 필드).
다음 단계
- 새 Cloud ID 계정 만들기
- Google Cloud를 통해 하이브리드 환경에서 기업 사용자를 인증하는 방법과 공통 패턴 알아보기
- Google Cloud와 외부 ID 공급업체의 페더레이션을 위한 권장사항 검토
- Google Cloud를 Active Directory 또는 Azure Active Directory와 페더레이션하는 방법 알아보기
- ID 및 액세스 관리 권장사항 검토