자주 묻는 질문(FAQ)

Cloud IAM(Identity and Access Management)을 사용하면서 만날 수 있는 일반적인 문제에 대해 알아봅니다.

Google Cloud IAM 소개

Google Cloud IAM(Identity and Access Management)이란 무엇인가요?

Cloud IAM을 사용하면 Google Cloud Platform 리소스에 대한 권한을 만들고 관리할 수 있습니다. GCP 서비스의 액세스 제어를 단일 시스템으로 통합하고 일관된 작업 집합을 제공합니다. 개념에 대한 개요는 IAM 개요를 참조하세요.

Cloud IAM이 왜 필요한가요?

Cloud IAM으로 최소 권한의 보안 원칙을 적용하여 필요한 리소스에 대한 액세스 권한만 부여하고 다른 리소스에 대한 무단 액세스를 방지할 수 있습니다. 또한 Cloud IAM을 통해 업무 구분에 대한 규정을 준수할 수 있습니다.

어떤 Google Cloud Platform 서비스에서 Cloud IAM을 지원하나요?

모든 GCP 서비스는 Cloud IAM을 사용하여 승인된 ID를 통한 액세스만 허용합니다. 또한 일부 서비스는 해당 서비스에 맞는 IAM 역할을 제공하거나 리소스 수준의 액세스 권한 부여를 지원합니다. IAM 지원에 대한 자세한 내용은 IAM 개요를 참조하세요.

Cloud IAM을 사용하려면 어떻게 해야 하나요?

Cloud IAM을 처음 사용하려는 경우 IAM 빠른 시작을 읽어보세요.

Cloud IAM 정책을 사용하여 내 애플리케이션의 인증과 승인을 모두 관리할 수 있나요?

IAM를 사용하여 GCP 리소스에 대한 승인을 관리하세요. 사용자 인증 관리는 LDAP, Google 그룹스 등 현재 사용하는 방식을 그대로 사용하세요. IAM으로 Google 계정, 서비스 계정, Google 그룹, Cloud ID, G Suite 도메인에 액세스 권한을 부여할 수 있습니다.

역할 및 정책

역할과 정책은 서로 어떤 관계인가요?

권한은 리소스에 대해 허용되는 작업을 결정합니다. IAM에서는 compute.instances.get과 같이 <service>.<resource>.<verb> 형식으로 권한을 표현합니다. 역할이란 권한의 모음입니다. 사용자에게 직접 권한을 할당할 수는 없으며, 대신 역할을 부여해야 합니다. 사용자에게 역할을 부여하면 해당 역할에 포함된 모든 권한이 부여됩니다.

IAM을 사용하면 IAM 정책을 설정하여 누가(사용자) 어떤 리소스에 대해 무슨(역할) 권한을 갖는지를 제어할 수 있습니다. 리소스의 IAM 정책은 리소스의 구성원에게 부여되는 역할의 전체 목록입니다.

권한, 역할, 정책에 대한 자세한 내용은 IAM 개요를 참조하세요.

기본 역할과 사전 정의된 역할의 차이점은 무엇인가요?

기본 역할은 기존에 사용하던 소유자, 편집자, 뷰어 역할입니다. IAM이 제공하는 사전 정의된 역할을 사용하면 기본 역할보다 세밀하게 액세스 권한을 관리할 수 있습니다. 가능하면 사전 정의된 역할을 ID에 부여하여 리소스에 액세스하기 위해 필요한 최소한의 액세스 권한만 제공하시기 바랍니다.

기본 역할은 언제 사용하나요?

다음과 같은 경우에 기본 역할을 사용하세요.

  • GCP 서비스가 사전 정의된 역할을 제공하지 않는 경우. 사용 가능한 모든 사전 정의된 역할 목록을 보려면 사전 정의된 역할 표를 참조하세요.

  • 프로젝트와 관련하여 더 광범위한 권한을 부여하려는 경우. 개발 또는 테스트 환경에서 권한을 부여할 때 이러한 경우가 많습니다.

  • 구성원이 프로젝트의 권한을 수정하도록 허용하려는 경우. 프로젝트의 다른 사용자에게 액세스 권한을 부여할 권한은 소유자에게만 있으므로 소유자 역할을 부여해야 합니다.

  • 팀원들의 권한을 세분화할 필요가 없는 소규모 팀에서 일하는 경우

커스텀 역할을 직접 정의할 수 있나요?

IAM 커스텀 역할은 현재 베타 출시 버전으로 제공됩니다.

리소스에 부여된 역할을 어떻게 확인할 수 있나요?

GCP 콘솔, getIamPolicy() 메소드 또는 gcloud 명령줄 도구를 사용하여 리소스에 부여된 역할을 확인할 수 있습니다. 자세한 내용은 프로젝트 구성원에 대한 액세스 권한 부여, 변경, 취소를 참조하세요.

Cloud IAM 정책은 어떤 내용인가요?

IAM 정책은 바인딩 목록으로 구성되는 정책 객체로 표현됩니다. 바인딩은 구성원 목록을 역할에 연결합니다. 코드로 표현하면 다음 코드 예와 같습니다.

{
  "bindings": [
   {
     "role": "roles/owner",
     "members": [
       "user:alice@example.com",
       "group:admins@example.com",
       "domain:google.com",
       "serviceAccount:my-other-app@appspot.gserviceaccount.com"]
      },
      {
        "role": "roles/compute.networkViewer",
        "members": ["user:bob@example.com"]
      }
    ]
}

위 정책 예에서는 alice@example.com, admins@example.com, google.com, my-other-app@appspot.gserviceaccount.com에 소유자 역할을, bob@example.com에 네트워크 뷰어 역할을 할당합니다.

Cloud IAM 정책을 만들고 관리하는 방법은 무엇인가요?

Google Cloud Platform 콘솔, gcloud 도구, IAM 메소드를 사용하여 IAM 정책을 만들고 관리할 수 있습니다. 자세한 내용은 프로젝트 구성원에 대한 액세스 권한 부여, 변경, 취소를 참조하세요.

프로젝트의 Cloud IAM 정책을 확인하는 방법은 무엇인가요?

GCP 콘솔, project.getIamPolicy() 메소드 또는 gcloud 도구를 사용하여 프로젝트의 IAM 정책을 확인할 수 있습니다. 자세한 내용은 프로젝트 구성원에 대한 액세스 권한 부여, 변경, 취소를 참조하세요.

조직 수준 정책을 확인하는 방법은 무엇인가요?

GCP 콘솔, organization.getIamPolicy() 메소드 또는 gcloud 도구를 사용하여 조직 수준 정책을 확인할 수 있습니다. 조직 수준 정책을 확인하는 방법은 조직 액세스 제어를 참조하세요.

정책을 어떻게 업데이트하나요?

개발자 콘솔, API, gcloud 도구를 사용하여 정책을 업데이트할 수 있습니다. 자세한 내용은 프로젝트 구성원에 대한 액세스 권한 부여, 변경, 취소를 참조하세요.

정책의 크기 한도는 얼마나 되나요?

각 정책은 모든 바인딩을 합산하여 최대 1,500명의 members를 포함할 수 있습니다.

Cloud IAM 정책을 몇 개까지 만들 수 있나요?

조직 수준, 프로젝트 수준, 리소스 수준 등 자신의 수준에서 IAM 정책을 지원하는 모든 리소스는 정책을 하나만 가질 수 있습니다. 단일 정책은 모든 바인딩을 합산하여 최대 1,500명의 구성원을 포함할 수 있습니다.

정책 관련 문제를 어떻게 해결하나요?

testIamPermissions() 메소드를 사용하여 특정 리소스에 대해 호출자가 갖는 권한을 확인할 수 있습니다. 이 메소드는 리소스 이름과 권한 집합을 매개변수로 취하고, 호출자가 갖는 권한만 포함하는 부분집합을 반환합니다.

IAM 역할의 효과를 검증할 수 있습니다. 예를 들어 사용자는 액세스 권한을 부여받지 않은 GCP 콘솔 페이지에 액세스할 수 없습니다. 가령, 로그 뷰어 역할만 부여받은 사용자가 App Engine 페이지에 액세스하려고 하면 다음과 같은 오류 메시지가 표시됩니다.

선택한 리소스에서 작업을 수행할 수 있는 권한이 없습니다.

ID

어떤 ID에 Cloud IAM 역할을 부여할 수 있나요?

Cloud IAM으로 다음과 같은 유형의 ID에 액세스 권한을 부여할 수 있습니다.

  • Google 계정
  • 서비스 계정
  • Google 그룹
  • G Suite 또는 Cloud ID 도메인

Cloud IAM와 함께 Google 그룹을 사용할 수 있나요?

일반적으로는 그렇지만, 소유자 역할은 예외입니다. 그룹과 프로젝트가 반드시 같은 조직에 속해야만 그룹에 프로젝트의 소유자 역할을 할당할 수 있습니다. 그룹은 조직이 없는 프로젝트 또는 다른 조직에 속한 프로젝트의 소유자가 될 수 없습니다.

이외의 경우에는 가급적 개별 사용자 대신 Google 그룹에 역할을 부여하는 것이 좋습니다. 사용자를 추가하거나 삭제할 때 여러 Cloud IAM 정책을 업데이트하기보다 Google 그룹에서 구성원을 추가 및 삭제하는 것이 더 쉽습니다. 특정 작업을 허용하기 위해 여러 역할을 부여해야 하는 경우 Google 그룹을 만들고, 해당 그룹에 역할을 부여하고, 사용자 또는 다른 그룹을 해당 그룹에 추가하면 됩니다.

Cloud IAM으로 사용자를 만들고 관리할 수 있나요?

아니요. Cloud ID 또는 G Suite로 사용자를 만들고 관리할 수 있습니다. LDAP, Google 그룹스 등 현재 사용하는 방식으로 사용자를 관리해도 무방합니다. LDAP로 사용자를 관리하는 경우 Google 클라우드 디렉토리 동기화를 사용하여 Google 도메인의 데이터를 동기화해야 합니다. 어떠한 방법으로 사용자를 관리하든, Google 그룹스 등을 활용하여 IAM 정책의 역할에 사용자를 연결함으로써 리소스에 대한 액세스를 허용해야 합니다.

Cloud IAM 리소스에 대한 사용자 액세스를 중지하는 방법은 무엇인가요?

Google 그룹을 통해 사용자에게 IAM 역할을 부여한 경우 사용자를 그룹에서 삭제하면 해당 사용자는 그룹에 부여된 액세스 권한을 더 이상 갖지 않습니다. 그룹을 사용하지 않았다면 정책을 검토하여 개별 사용자에게 액세스 권한이 부여된 위치를 찾고, 해당 부분을 정책에서 삭제하고, 정책을 업데이트해야 합니다. Google 그룹을 사용하여 액세스 권한을 부여하면 개별 사용자의 액세스 권한을 취소하기 위해 모든 정책을 업데이트할 필요가 없으므로 작업이 쉬워집니다. 자세한 내용은 프로젝트 구성원에 대한 액세스 권한 부여, 변경, 취소를 참조하세요.

참고: 변경사항이 전파되어 적용되는 데 최대 80초가 걸릴 수 있습니다.

권한을 부여한 직후에 사용자가 리소스에 액세스할 수 없거나, 권한을 삭제한 후에도 계속 액세스할 수 있는데 왜 그런가요?

요청이 제출된 후 역할 업데이트가 전파되는 데 최대 80초가 걸릴 수 있습니다.

조직에 속하지 않은 사용자에게 프로젝트의 리소스에 대한 권한을 부여하려면 어떻게 해야 하나요?

Google 그룹을 사용하면 조직에 속하지 않은 사용자를 그룹에 추가하고 해당 그룹을 역할에 연결할 수 있습니다. 단, Google 그룹에는 로그인 사용자 인증 정보가 없으므로 Google 그룹으로 ID를 설정하여 리소스에 대한 액세스를 요청할 수는 없습니다.

조직에 속하지 않은 사용자를 IAM 정책에 직접 추가할 수도 있습니다. 그러나 이러한 방법이 회사의 정책에 맞는지 관리자에게 확인해야 합니다.

인스턴스에 액세스할 수 있는 사용자를 제한하는 방법은 무엇인가요?

인스턴스에 액세스할 수 있는 사용자를 제한하려면 Google 그룹을 사용하여 ID를 역할에 연결합니다. 이러한 바인딩은 인스턴스가 실행될 프로젝트 수준에서 적용되는 정책의 일부로서 표현됩니다. Google 계정(예: your-user@yourdomain.com)으로 식별되는 사용자가 IAM 정책에서 연결된 그룹에 속하지 않는 경우 해당 사용자는 정책이 적용되는 리소스에 액세스할 수 없습니다.

Cloud IAM에서 다단계 인증(MFA)을 사용하는 방법은 무엇인가요?

개별 사용자가 MFA를 사용하는 경우 해당 인증 방식을 준용해야 합니다. 즉, ID 시스템을 직접 만들었다면 MFA를 지원해야 합니다. G Suite 계정의 경우 사용자가 스스로 사용 설정해야 합니다. G Suite 관리형 사용자 인증 정보의 경우 G Suite 도구를 통해 MFA를 사용 설정할 수 있습니다.

서비스 계정과 Cloud IAM 사용자는 서로 어떻게 다른가요?

서비스 계정은 애플리케이션에서 Google 서비스에 프로그래매틱으로 액세스하는 데 사용할 수 있는 특수한 Google 계정입니다. 이 계정은 개별 최종 사용자가 아니라 애플리케이션 또는 가상 머신(VM)에 속합니다. 애플리케이션은 서비스 계정을 사용하여 Google API 서비스를 호출하므로 사용자가 직접 관여하지 않습니다.

서비스 계정

프로젝트 하나에 서비스 계정을 최대 몇 개까지 만들 수 있나요?

프로젝트 하나에 서비스 계정을 100개까지 만들 수 있습니다. 프로젝트에서 100개를 초과하는 서비스 계정을 만들어야 하는 경우 계정 관리자에게 문의하세요.

Cloud IAM을 사용하여 서비스 계정 키를 순환하는 방법은 무엇인가요?

GCP 관리 키는 매일 순환됩니다. 사용자가 관리하는 키를 순환하려는 경우 IAM 서비스 계정 API를 사용하면 서비스 계정 키가 자동으로 순환됩니다. 키를 순환하려면 새 키를 만들고 애플리케이션에서 새 키를 사용하도록 전환한 후 이전 키를 삭제합니다. serviceAccount.keys().create() 메소드와 serviceAccount.keys().delete() 메소드를 함께 사용하면 순환을 자동화할 수 있습니다.

누가 프로젝트에 서비스 계정을 만들 수 있는지를 어떻게 제어하나요?

소유자 및 편집자 역할에는 프로젝트에 서비스 계정을 만들 권한이 있습니다. 사용자에게 서비스 계정을 만들 권한을 부여하려면 소유자 또는 편집자 역할을 부여하면 됩니다.

조직에 속하는 서비스 계정을 만들 수 있나요?

현재는 프로젝트에 속하는 서비스 계정만 만들 수 있으며, 조직에 바로 속하는 서비스 계정은 만들 수 없습니다. 그러나 조직 수준에서 IAM 권한을 부여하면 해당 조직에 속하는 프로젝트 및 프로젝트에 속하는 서비스 계정에서 차례로 권한을 상속합니다.

네트워크 및 방화벽 규칙을 전담하여 관리하는 팀이 있습니다. 개발팀이 인스턴스를 관리할 수 있지만 네트워크 또는 방화벽은 변경할 수 없도록 업무 구분을 유지하고 싶은데 어떻게 해야 하나요?

네트워크 관리자에게는 조직 또는 프로젝트 수준의 Compute 네트워크 관리자 역할을, 개발자에게는 Compute 인스턴스 관리자 역할을 부여합니다. 이렇게 하면 개발자는 인스턴스에 대해 모든 작업을 수행할 수 있지만 프로젝트에 연결된 네트워크 리소스는 변경할 수 없습니다.

조직의 여러 팀이 서로의 인스턴스에 액세스할 수 없도록 조치해야 합니다. 어떻게 하면 될까요?

팀마다 하나씩 두 프로젝트를 만듭니다. 그런 다음 각 프로젝트의 정책을 따로 만들어 어떤 팀이 어떤 프로젝트에, 프로젝트에 포함된 어떤 인스턴스에 액세스할 수 있는지를 제어합니다. 서로 다른 역할을 갖는 서비스 계정을 사용하는 방법도 가능합니다.

인스턴스를 실행하는 데 사용하는 서비스 계정을 변경할 수 있나요?

Compute Engine 인스턴스를 실행하는 서비스 계정은 변경할 수 없습니다. 생성 시에만 서비스 계정을 인스턴스에 연결할 수 있습니다. 그러나 실행 중인 인스턴스에 연결된 서비스 계정에 부여되는 권한은 변경할 수 있으며, 변경사항은 즉시 적용됩니다.

서비스 계정 행위자 역할은 어떠한 경우에 사용하나요?

서비스 계정 행위자 역할은 지원이 중단되었습니다. 서비스 계정으로 작업을 실행해야 하는 경우 서비스 계정 사용자 역할을 사용하세요.

서비스 계정 사용자 역할은 어떠한 경우에 사용하나요?

서비스 계정 사용자는 서비스 계정으로 작업을 실행할 권한을 부여합니다. 사용자는 compute.instanceAdmin 역할과 함께 iam.serviceAccountUser 역할을 부여받은 경우 서비스 계정을 사용하는 Compute Engine 인스턴스를 만들고 관리할 수 있습니다. 서비스 계정의 serviceAccountUsers인 사용자는 서비스 계정이 액세스 권한을 보유한 모든 리소스에 액세스할 수 있습니다.

감사

Cloud IAM 정책을 감사하는 방법은 무엇인가요?

Cloud 감사 로그를 사용하여 IAM 정책의 변경사항을 정기적으로 감사할 수 있습니다. 감사 로그는 30일 동안만 유지되며, 더 오래 보관하려면 로그를 직접 내보내야 합니다.

감사 로그에는 무엇이 기록되나요?

관리자 활동 감사 로그에는 서비스 또는 프로젝트의 구성이나 메타데이터를 수정하는 모든 API 호출 또는 관리 작업에 대한 항목이 포함됩니다. 데이터 액세스 감사 로그에는 다음과 같은 이벤트에 대한 항목이 포함됩니다.

  • 서비스 또는 프로젝트의 구성이나 메타데이터를 읽는 API 호출 또는 관리 작업

  • 서비스가 관리하는 사용자 제공 데이터(예: 데이터베이스 서비스에 저장된 데이터)를 만들거나 수정하거나 읽는 API 호출 또는 관리 작업

  • 프로젝트 수준 setIamPolicy() 메소드가 기록됩니다.

  • 서비스 계정 및 서비스 계정 키가 기록됩니다

감사 로그에 누가 액세스할 수 있는지 제어하는 방법은 무엇인가요?

Stackdriver Logging 규칙을 사용하여 로그에 대한 액세스를 제한할 수 있습니다.

감사 로그를 유지하려면 어떻게 해야 하나요?

개별 감사 로그 항목은 지정된 기간 동안 유지된 후 삭제됩니다. 로그 항목이 보관되는 기간은 Stackdriver Logging 할당량 정책을 참조하세요. 할당량 정책의 한도를 초과하여 로그 항목을 유지하려면 Stackdriver Logging에서 Cloud Storage 버킷 또는 BigQuery로 로그를 내보내세요.

이 페이지가 도움이 되었나요? 평가를 부탁드립니다.

다음에 대한 의견 보내기...

Cloud ID 및 액세스 관리 문서