안녕하세요,
베스핀글로벌 GCP Support팀입니다.
이번 아티클에서는 주제로 "조직 내 여러 팀이 서로의 인스턴스에 액세스 할 수 없도록 조치하는 방안"을 다루고자 합니다.
팀별 프로젝트 분리
팀별 리소스를 구분하는 가장 간편한 방법은 팀마다 다른 프로젝트를 사용하여 서로 다른 프로젝트로 액세스할 수 없도록 설정하는 것 입니다.
아래 이미지와 같이 조직 아래의 팀별로 별도의 프로젝트를 두어 팀별 사용자(alice@example.com)에게는 해당 프로젝트에만 접근할 수 있도록 프로젝트 레벨의 권한만을 부여합니다.
전체를 관리하는 관리자 계정(bob@example.com)에는 조직 레벨의 권한을 부여하여 모든 프로젝트 리소스에 접근할 수 있게 합니다.
추가적인 권장사항은 아래와 같습니다.
1. 조직 규모에 따라 프로젝트 구분 여부를 결정하는 것이 효율적입니다. . 스타트업은 조직 리소스가 없는 수평적인 리소스 계층 구조로 시작할 수 있지만, 점차 프로젝트에서 공동 작업하는 사람들과 프로젝트 수가 증가하게 되면 조직 리소스를 갖추는 것이 합리적일 수 있습니다
2. 가능하면 개별 사용자가 아닌 Google 그룹에 역할을 부여합니다. 이렇게 하면 개별 사용자에 대해 허용 정책을 업데이트하는 것보다 Google 그룹의 구성원을 관리하기가 더욱 쉽습니다.
3. 리소스에 필요한 액세스 권한만을 부여하는 최소 권한의 보안 원칙을 사용하여 IAM 역할을 부여합니다.
4. 모든 프로젝트에서 주 구성원 최소 2명 이상에 소유자 역할(roles/owner)이 있는지 확인합니다. 또는 주 구성원이 최소 2명 이상 포함된 Google 그룹에 소유자 역할을 부여합니다. 이 방법을 사용하면 주 구성원 중 한 명이 퇴사하더라도 프로젝트를 계속 관리할 수 있습니다.
프로젝트 내에서 구분
별도 프로젝트를 두기 어려운 상황에서는 프로젝트 레벨의 권한 부여 시 IAM 조건을 설정하여 제한적인 권한을 부여합니다.
예를 들어 "dev" 팀 소속 사용자에게 Compute Engine VM에 Login 할 수 있는 권한을 가진 Compute OS Login 권한을 부여할 때, "team : dev" tag가 있는 리소스에 대해서만 접근할 수 있도록 권한을 제한적으로 부여할 수 있습니다.
만약 운영 상의 이유로 개별 사용자에게 권한을 부여하기 어렵다면, 팀별로 제한된 권한을 가진 Service Account 계정을 생성하여 사용할 수도 있습니다.
※ Service Account 사용 시에는 Service Account Key 유실 시 큰 보안 위험을 초래할 수 있기 때문에 사용자 인증 정보와 같은 대안을 사용하거나 키 순환을 통해 관리를 철저히 하시기 바랍니다.
참조링크
[1] 액세스 제어에 리소스 계층 구조 사용
https://cloud.google.com/iam/docs/resource-hierarchy-access-control
[2] IAM Condition - 태그 및 조건부 액세스
https://cloud.google.com/iam/docs/tags-access-control
관련 문의사항이 있으시면 Support Portal에 문의해 주시기 바랍니다.
감사합니다.