이 섹션에서는 Cloud ID를 사용하여 직원이 Google Cloud서비스에 액세스할 때 사용하는 ID를 관리하는 방법을 소개합니다.
외부 ID 공급업체를 정보 소스로 사용
기존 ID 공급업체가 있다면, Cloud ID 계정을 해당 공급업체와 페더레이션(연동)하는 것이 좋습니다. 이렇게 하면 기존의 계정 관리 프로세스가 Google Cloud 및 기타 Google 서비스에도 일관되게 적용됩니다.
기존 ID 공급업체가 없는 경우에는, Cloud ID 내에서 직접 사용자 계정을 만들 수 있습니다.
다음 다이어그램은 ID 페더레이션 및 싱글 사인온(SSO)을 간략하게 보여줍니다. 온프레미스 환경의 Microsoft Active Directory를 예시 ID 공급업체로 사용했습니다.
이 다이어그램은 다음 권장사항을 설명합니다.
- 사용자 ID는 온프레미스 환경의 Active Directory 도메인에서 관리되며, 해당 도메인은 Cloud ID와 페더레이션되어 있습니다. Active Directory는 Google Cloud 디렉터리 동기화를 사용하여 Cloud ID에 ID를 프로비저닝합니다.
- 사용자가 Google 서비스에 로그인하려고 시도하면, SAML 싱글 사인온(SSO)을 위해 외부 ID 공급업체로 리디렉션됩니다. 사용자는 기존 사용자 인증 정보를 사용하여 인증됩니다. 비밀번호는 Cloud ID와 동기화되지 않습니다.
다음 표에는 다양한 ID 공급업체 설정 가이드에 대한 링크가 포함되어 있습니다.
| ID 공급업체 | 가이드 |
|---|---|
| Active Directory | |
| Microsoft Entra ID(이전 Azure AD) | |
| 기타 외부 ID 공급업체(예: Ping 또는 Okta) |
ID 공급업체에서 피싱 방지 인증 메커니즘(예: Titan 보안 키)을 사용하여 다중 인증(MFA)을 강제하도록 하는 것이 가장 좋습니다.
Cloud ID에 대한 권장 설정은 이 청사진의 Terraform 코드에 자동으로 포함되지 않습니다. Terraform 코드를 배포하는 것 외에도 구성해야 하는 권장 보안 설정은 Cloud ID 관리 제어를 참조하세요.
액세스 제어를 위한 그룹 구성
주 구성원은 리소스에 액세스 권한을 부여할 수 있는 ID를 의미합니다. 주 구성원에는 사용자용 Google 계정, Google 그룹, Google Workspace 계정, Cloud ID 도메인, 서비스 계정 등이 포함됩니다. 일부 서비스에서는 Google 계정으로 인증한 모든 사용자 또는 인터넷의 모든 사용자에게 액세스 권한을 부여할 수도 있습니다. 어떤 주 구성원이 Google Cloud 서비스를 사용하려면 Identity and Access Management(IAM) 내에서 역할을 부여해야 합니다.
IAM 역할을 대규모로 관리하려면, 직무와 액세스 필요성에 따라 사용자를 그룹으로 묶고, 그 그룹에 IAM 역할을 부여하는 것이 좋습니다. 그룹 생성 및 멤버십 관리를 위해서는 기존 ID 공급업체의 프로세스를 사용하여 그룹에 사용자를 추가하는 것이 좋습니다.
개별 사용자에게 직접 IAM 역할을 부여하는 것은 권장하지 않습니다. 이러한 개별 할당은 권한 관리 및 감사를 복잡하게 만들 수 있기 때문입니다.
이 청사진은 기초 리소스에 대해 조회 권한을 가진 그룹과 역할을 구성합니다. 청사진의 모든 리소스는 기초 파이프라인을 통해 배포하고, 이 파이프라인 외부에서 기초 리소스를 수정할 수 있는 권한을 사용자나 그룹에 부여하지 않는 것이 좋습니다.
다음 표는 청사진에서 기초 리소스를 조회하기 위해 구성된 그룹을 보여줍니다.
| 이름 | 설명 | 역할 | 범위 |
|---|---|---|---|
grp-gcp-org-admin@example.com | 조직 수준에서 IAM 역할을 부여할 수 있는 권한이 높은 관리자 그룹입니다. 다른 모든 역할에 액세스할 수 있습니다. 일상적인 용도로는 이 권한이 권장되지 않습니다. | 조직 관리자 | 조직 |
grp-gcp-billing-admin@example.com |
Cloud Billing 계정을 수정할 수 있는 권한이 높은 관리자 그룹입니다. 일상적인 용도로는 이 권한이 권장되지 않습니다. | 결제 계정 관리자 | 조직 |
grp-gcp-billing-viewer@example.com | 모든 프로젝트의 지출을 확인하고 분석하는 역할을 담당하는 팀입니다. | 결제 계정 뷰어 | 조직 |
| BigQuery 사용자 | 결제 프로젝트 | ||
grp-gcp-audit-viewer@example.com |
보안 관련 로그를 감사하는 역할을 담당하는 팀입니다. | 로깅 프로젝트 | |
grp-gcp-security-reviewer@example.com |
클라우드 보안 검토를 담당하는 팀입니다. | 보안 검토자 | 조직 |
grp-gcp-network-viewer@example.com |
네트워크 구성을 조회하고 유지관리하는 역할을 담당하는 팀입니다. | Compute 네트워크 뷰어 | 조직 |
grp-gcp-scc-admin@example.com |
Security Command Center를 구성하는 역할을 담당하는 팀입니다. | 보안 센터 관리자 편집자 | 조직 |
grp-gcp-secrets-admin@example.com |
애플리케이션에서 사용하는 사용자 인증 정보 및 기타 보안 비밀을 관리, 저장, 감사하는 역할을 담당하는 팀입니다. | Secret Manager 관리 | 보안 비밀 프로젝트 |
grp-gcp-kms-admin@example.com |
규정 준수 요구사항을 충족하기 위해 암호화 키 관리 정책을 적용하는 역할을 담당하는 팀입니다. | Cloud KMS 뷰어 | kms 프로젝트 |
기초 인프라를 기반으로 자체 워크로드를 구축할 때, 각 워크로드의 액세스 요구사항에 따라 추가 그룹을 만들고 IAM 역할을 부여하게 됩니다.
기본 역할(소유자, 편집자, 뷰어 등)은 사용하지 말고 사전 정의된 역할을 사용하는 것이 좋습니다. 기본 역할은 권한이 과도하게 부여되어 있으며, 잠재적인 보안 위험이 존재합니다. 특히 소유자 및 편집자 역할은 권한 에스컬레이션이나 측면 이동을 유발할 수 있고, 뷰어 역할은 모든 데이터를 읽을 수 있는 액세스 권한을 포함합니다. IAM 역할에 대한 권장사항은 안전하게 IAM 사용을 참조하세요.
최고 관리자 계정
Cloud ID의 최고 관리자 계정을 보유한 사용자는 조직의 SSO 설정을 우회하여 Cloud ID에 직접 인증할 수 있습니다. 이 예외는 의도적으로 설계된 기능으로, SSO 설정 오류나 서비스 중단이 발생했을 때도 최고 관리자가 Cloud ID 콘솔에 액세스할 수 있도록 하기 위한 것입니다. 그러나, 이는 최고 관리자 계정에 추가적인 보호 조치가 필요하다는 뜻이기도 합니다.
최고 관리자 계정을 보호하려면, 항상 Cloud ID에서 보안 키를 사용한 2단계 인증을 강제로 적용하는 것이 좋습니다. 자세한 내용은 관리자 계정을 위한 보안 권장사항을 참조하세요.
일반 사용자 계정 관련 문제
Cloud ID 또는 Google Workspace를 사용하기 전에 Google Cloud를 도입한 경우, 조직의 직원들이 이미 기업 이메일 주소로 일반 계정을 생성해, Google Marketing Platform이나 YouTube 등 다른 Google 서비스를 사용하고 있을 수도 있습니다. 일반 계정은 해당 계정을 만든 개인이 직접 소유하고 관리하는 계정입니다. 이러한 계정은 조직의 관리 하에 있지 않으며, 개인 데이터와 회사 데이터가 혼합되어 있을 가능성이 있기 때문에, 조직은 이러한 계정을 회사 계정과 어떻게 통합할지 결정해야 합니다.
Google Cloud온보딩 과정의 일부로, 기존 일반 사용자 계정을 통합하는 것이 좋습니다. 아직 모든 사용자 계정에 Google Workspace를 사용하지 않는다면, 일반 계정에 대한 액세스를 차단하는 것이 좋습니다.
Cloud ID의 관리 제어
Cloud ID에는 청사진의 Terraform 코드로는 자동 설정되지 않는 여러 관리 제어 기능이 있습니다. 이러한 권장사항 보안 제어 기능은 기초 인프라를 구축하는 초기에 반드시 적용하는 것이 좋습니다.
| 제어 기능 | 설명 |
|---|---|
| 2단계 인증 배포 | 사용자 계정은 피싱, 소셜 엔지니어링, 비밀번호 스프레이, 기타 다양한 위협에 의해 손상될 수 있습니다. 2단계 인증은 이러한 위협을 완화하는 데 도움이 됩니다. 조직 내 모든 사용자 계정에 대해 Titan 보안 키 또는 FIDO U2F(CTAP1) 표준 기반의 피싱 방지용 키와 같은 수단을 사용하여 2단계 인증을 강제로 적용하는 것이 좋습니다. |
| Google Cloud 서비스의 세션 길이 설정 | 개발자 워크스테이션에 저장된 지속적 OAuth 토큰은 유출될 경우 보안 위험이 될 수 있습니다. 이 위험을 줄이기 위해, 보안 키를 사용하여 16시간마다 재인증을 요구하는 정책을 설정하는 것이 좋습니다. |
| Google 서비스의 세션 길이 설정 | (Google Workspace 고객 전용)
Google 서비스 전반에 걸쳐 유지되는 지속적인 웹 세션은 노출될 경우 보안 위험이 될 수 있습니다. 따라서 웹 세션의 최대 지속 시간을 설정하고, 이 설정이 SSO 제공업체의 세션 길이 정책과 일치하도록 조정하는 것이 좋습니다. |
| Google Cloud 서비스와 Cloud ID의 데이터 공유 | Google Workspace 또는 Cloud ID의 관리자 활동 감사 로그는 기본적으로 관리 콘솔에서 별도로 관리되며, 조직의 다른 Google Cloud 로그 환경과 분리되어 있습니다. 이러한 로그에는 사용자 로그인 이벤트 등 Google Cloud 환경 보안에 유용한 정보가 포함됩니다. 따라서 Cloud ID의 감사 로그를Google Cloud 환경에 공유하여 중앙에서 관리하는 것이 좋습니다. |
| 사후 SSO 인증 설정 | 이 청사진은 외부 ID 공급업체와 SSO가 이미 설정되어 있다고 가정합니다. 이때, Google의 로그인 위험 분석을 기반으로 추가 제어 레이어를 사용 설정하는 것이 좋습니다. 이 설정을 적용하면 Google에서 사용자 로그인 시도가 의심스럽다고 판단될 경우, 사용자에게 추가적인 위험 기반 본인 확인 요청이 표시됩니다. |
| 일반 사용자 계정 관련 문제 해결 | 조직 도메인 내 유효한 이메일 주소를 가진 사용자가 Google 계정을 보유하지 않은 경우, 관리되지 않는 일반 계정을 새로 만들 수 있습니다. 이러한 계정에는 기업 데이터가 포함될 수 있지만, 조직의 계정 수명 주기 관리 프로세스에 포함되지 않습니다. 모든 사용자 계정이 조직이 관리하는 계정이 되도록 조치를 취하는 것이 좋습니다. |
| 최고 관리자 계정의 계정 복구 사용 중지 | 신규 고객의 경우, 최고 관리자 계정의 자체 복구는 기본적으로 사용 중지되어 있습니다. (기존 고객은 해당 설정이 사용 설정되어 있을 수 있습니다.) 이 설정을 사용 중지하면 휴대폰 및 이메일 탈취, 소셜 엔지니어링 공격 등을 통해 공격자가 사용자 환경에 대해 최고 관리자 권한을 획득할 수 있는 위험을 줄일 수 있습니다. 또한 최고 관리자가 계정 액세스 권한을 잃었을 때 조직 내 다른 최고 관리자에게 연락하여 지원을 요청하는 내부 절차를 마련하고, 모든 최고 관리자가 지원팀을 통한 복구 프로세스를 숙지해야 합니다. |
| 사용자의 비밀번호 요구사항 적용 및 모니터링 | 대부분의 경우, 사용자 비밀번호는 외부 ID 공급업체를 통해 관리되지만, 최고 관리자 계정은 SSO를 우회하며 Cloud ID에 로그인할 때 반드시 비밀번호를 사용해야 합니다. Cloud ID에 비밀번호로 로그인하는 모든 사용자(특히 최고 관리자 계정)에 대해 비밀번호 재사용을 금지하고 비밀번호 강도를 모니터링하세요. |
| 그룹 사용에 대한 조직 전체 정책 설정 | 기본적으로 Cloud ID에서는 외부 사용자 계정도 그룹에 추가할 수 있습니다. 그룹 소유자가 외부 사용자를 추가할 수 없도록 공유 설정을 구성하는 것이 좋습니다. 이 제한은 최고 관리자 계정 또는 그룹 관리자 권한을 가진 기타 위임 관리자에게는 적용되지 않습니다. ID 공급업체의 페더레이션은 관리자 권한으로 실행되므로, 그룹 공유 설정이 이 그룹 동기화에는 적용되지 않습니다. 따라서 ID 공급업체와 동기화 메커니즘에서 도메인 외부 사용자가 그룹에 추가되지 않도록 하는 제어를 검토하거나 그룹 제한을 적용하는 것이 좋습니다. |
다음 단계
- 조직 구조(이 시리즈의 다음 문서) 읽어보기