설명
조직이 관리하지 않는 개인 계정에 업무 권한을 부여하면 계정 회수나 인증 정책을 일관되게 적용하기 어려울 수 있습니다. 이메일 도메인만으로 관리 여부나 MFA 적용을 판단할 수 없으며, 승인된 외부 협업 계정도 있을 수 있습니다.
잠재적 영향
- 퇴사나 협업 종료 후 권한이 남을 수 있습니다.
- 인증과 복구 절차가 조직 기준에 맞지 않으면 계정 침해 대응이 어려워질 수 있습니다.
해결 방법
- 조직에서 관리하는 업무 계정을 우선 사용하고 수명 주기, MFA 및 복구 정책을 확인하세요. 외부 계정에는 소유자와 만료·검토 절차를 지정하세요.
- 필요한 최소 역할만 부여하고 불필요한 멤버를 제거하세요. 계정이나 그룹을 바꾼 뒤 실제 접근과 기존 권한 회수를 확인하세요.
예시
프로젝트와 이메일을 실제 승인된 값으로 바꾸세요. example.com 주소 자체가 관리 계정을 보장하지 않으며 roles/editor도 여전히 광범위합니다. 이 바인딩이 관리하는 역할의 다른 필수 멤버는 보존하세요.
변경 전
hcl
resource "google_project_iam_binding" "example" {
project = "your-project-id"
role = "roles/editor"
members = [
"user:jane@gmail.com",
]
}
변경 후
hcl
resource "google_project_iam_binding" "example" {
project = "your-project-id"
role = "roles/editor"
members = [
"user:jane@example.com",
]
}
설명:
- 변경 전: 개인 이메일 도메인의 사용자에게 Editor 역할을 부여합니다. 관리 정책의 적용 여부를 확인해야 합니다.
- 변경 후: 이메일 도메인을 바꿉니다. 실제 조직 관리, 인증 통제 및 역할 최소화까지 보장하는 변경은 아닙니다.