이 섹션에서는 Cloud ID를 사용하여 직원이 Google Cloud 서비스에 액세스하는 데 사용하는 ID를 관리하는 방법을 설명합니다.
외부 ID 공급업체를 정보 소스로 사용
Cloud ID 계정을 기존 ID 공급업체와 제휴하는 것이 좋습니다. 제휴를 사용하면 기존 계정 관리 프로세스가 Google Cloud 및 다른 Google 서비스에 적용되도록 할 수 있습니다.
기존 ID 공급업체가 없으면 Cloud ID에서 직접 사용자 계정을 만들 수 있습니다.
다음 다이어그램은 ID 제휴 및 싱글 사인온(SSO)을 간략하게 보여줍니다. 온프레미스 환경에 있는 Microsoft Active Directory를 ID 공급업체 예시로 사용합니다.
이 다이어그램은 다음 권장사항을 설명합니다.
- 사용자 ID는 온프레미스 환경에 있고 Cloud ID와 제휴된 Active Directory 도메인에서 관리됩니다. 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) |
Titan 보안 키와 같은 피싱 방지 메커니즘을 사용하여 ID 공급업체에 다중 인증(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-monitoring-users@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 |
애플리케이션에서 사용하는 사용자 인증 정보 및 기타 보안 비밀을 관리, 저장, 감사하는 팀입니다. | 보안 비밀 관리자 관리 | 보안 비밀 프로젝트 |
grp-gcp-kms-admin@example.com |
규정 준수 요구사항을 충족하기 위해 암호화 키 관리를 적용하는 팀입니다. | Cloud KMS 뷰어 | kms 프로젝트 |
기반 위에 자체 워크로드를 빌드하면서 추가 그룹을 만들고 각 워크로드의 액세스 요구사항에 따라 IAM 역할을 부여합니다.
기본 역할(예: 소유자, 편집자, 뷰어)을 피하고 사전 정의된 역할을 대신 사용하는 것이 좋습니다. 기본 역할은 과도한 권한이 있으며 잠재적인 보안 위험을 나타냅니다. 소유자 및 편집자 역할은 권한 에스컬레이션 및 측면 이동으로 이어질 수 있으며, 뷰어 역할에는 모든 데이터를 읽을 수 있는 액세스 권한이 포함됩니다. IAM 역할에 대한 권장사항은 안전하게 IAM 사용을 참조하세요.
최고 관리자 계정
최고 관리자 계정이 있는 Cloud ID 사용자는 조직의 SSO 설정을 우회하고 Cloud ID에 직접 인증합니다. 이 예외는 SSO 구성이 잘못되거나 중단되는 경우에도 최고 관리자가 Cloud ID 콘솔에 액세스할 수 있도록 설계되었습니다. 하지만 최고 관리자 계정에 추가적인 보호 기능을 고려해야 합니다.
최고 관리자 계정을 보호하려면 항상 Cloud ID의 보안 키를 사용하여 2단계 인증을 시행하는 것이 좋습니다. 자세한 내용은 관리자 계정을 위한 보안 권장사항을 참고하세요.
일반 사용자 계정 관련 문제
Google Cloud에 온보딩하기 전에 Cloud ID 또는 Google Workspace를 사용하지 않았다면 조직 직원들이 이미 Google Marketing Platform 또는 YouTube와 같은 다른 Google 서비스에 액세스하기 위해 회사 이메일 ID와 연결되 일반 계정을 사용하고 있을 수 있습니다. 일반 계정은 해당 계정을 만든 사용자가 전적으로 소유하고 관리합니다. 이러한 계정은 조직에서 관리할 수 없고 개인 데이터와 회사 데이터를 모두 포함할 수 있기 때문에 이러한 계정을 다른 회사 계정과 통합할 방법을 결정해야 합니다.
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 공급업체의 세션 길이 제어에 맞게 이 값을 조정하는 것이 좋습니다. |
| Cloud ID의 데이터를 Google Cloud 서비스와 공유 | Google Workspace 또는 Cloud ID의 관리자 활동 감사 로그는 일반적으로 Google Cloud 환경의 로그와 별도로 관리 콘솔에서 관리 및 확인됩니다. 이러한 로그에는 사용자 로그인 이벤트와 같은 Google Cloud 환경과 관련된 정보가 포함됩니다. Cloud ID 감사 로그를 Google Cloud 환경에 공유하여 모든 소스의 로그를 중앙에서 관리하는 것이 좋습니다. |
| 사후 SSO 인증 설정하기 | 이 청사진은 외부 ID 공급업체를 통해 SSO를 설정했다고 가정합니다. Google의 로그인 위험 분석을 기반으로 추가 제어 레이어를 사용 설정하는 것이 좋습니다. 이 설정을 적용한 후 사용자 로그인이 의심스러운 것으로 판단되면 로그인 시 사용자에게 위험 기반 본인 확인 요청이 추가로 표시될 수 있습니다. |
| 일반 사용자 계정 관련 문제 해결 | 도메인에 유효한 이메일 주소가 있지만 Google 계정이 없는 사용자는 관리되지 않는 일반 계정에 가입할 수 있습니다. 이러한 계정에는 회사 데이터가 포함될 수 있지만 계정 수명 주기 관리 프로세스에 의해 제어되지는 않습니다. 모든 사용자 계정이 관리 계정인지 확인하는 단계를 수행하는 것이 좋습니다. |
| 최고 관리자 계정의 계정 복구 사용 중지 | 최고 관리자 계정 자체 복구는 모든 신규 고객에 대해 기본적으로 사용 중지되어 있습니다(기존 고객은 이 설정이 사용 설정되어 있을 수 있음). 이 설정을 사용 중지하면 보안 침해된 전화 및 이메일, 소셜 엔지니어링 공격으로 인해 공격자가 환경에 대한 최고 관리자 권한을 얻을 수 있는 위험을 완화할 수 있습니다. 최고 관리자가 계정 액세스 권한을 상실한 경우 조직 내 다른 최고 관리자에게 연락할 수 있는 내부 프로세스를 계획하고 모든 최고 관리자가 지원 복구 프로세스에 익숙해지도록 합니다. |
| 사용자의 비밀번호 요구사항 시행 및 모니터링하기 | 대부분의 경우 사용자 비밀번호는 외부 ID 공급업체를 통해 관리되지만 최고 관리자 계정은 SSO를 우회하며 비밀번호를 사용하여 Cloud ID에 로그인해야 합니다. 비밀번호 재사용을 사용 중지하고 비밀번호를 사용하여 Cloud ID, 특히 최고 관리자 계정에 로그인하는 사용자의 비밀번호 안전성을 모니터링합니다. |
| 그룹 사용에 대한 조직 전체 정책 설정하기 | 기본적으로 외부 사용자 계정은 Cloud ID의 그룹에 추가할 수 있습니다. 그룹 소유자가 외부 구성원을 추가할 수 없도록 공유 설정을 구성하는 것이 좋습니다. 최고 관리자 계정 또는 그룹스 관리자 권한이 있는 다른 위임된 관리자에게는 이 제한이 적용되지 않습니다. ID 공급업체의 제휴는 관리자 권한으로 실행되므로 그룹 공유 설정이 이 그룹 동기화에 적용되지 않습니다. ID 공급업체 및 동기화 메커니즘의 제어를 검토하여 도메인이 아닌 구성원이 그룹에 추가되지 않았는지 확인하거나 그룹 제한사항을 적용하는 것이 좋습니다. |
다음 단계
- 조직 구조(이 시리즈의 다음 문서) 읽어보기