IAM 개요

컬렉션을 사용해 정리하기 내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.

이 페이지에서는 Google Cloud의 Identity and Access Management(IAM) 시스템이 작동하는 방식과 이를 사용하여 Google Cloud에서 액세스를 관리하는 방법을 설명합니다.

IAM은Google Cloud에 대해 세밀하게 조정된 승인을 관리하기 위한 도구입니다. 즉, 누가 어떤 리소스에 대해 무엇을 수행할 수 있는지 제어할 수 있습니다.

Google Cloud의 액세스 권한

Google Cloud 의 모든 작업에는 특정 권한이 필요합니다. 누군가 Google Cloud에서 VM 인스턴스 만들기 또는 데이터 세트 보기와 같은 작업을 수행하려고 시도할 때 IAM은 먼저 해당 사용자에게 필요한 권한이 있는지 확인합니다. 권한이 없으면 IAM이 사용자의 작업 수행을 방지합니다.

IAM에서 사용자에게 권한을 부여할 때는 다음 세 가지 구성요소가 포함됩니다.

• 주 구성원: 권한을 부여하려는 사람 또는 시스템의 ID입니다.
• 역할: 주 구성원에 제공하려는 권한 모음입니다.
• 리소스: 주 구성원이 액세스하도록 허용하려는 Google Cloud 리소스입니다.

주 구성원에게 리소스 액세스 권한을 부여하려면 해당 리소스에 대한 역할을 부여합니다. 이러한 역할은 허용 정책을 사용하여 부여할 수 있습니다.

다음 섹션에서 이러한 개념을 보다 자세히 설명합니다.

주 구성원

Google Cloud 에서는 주 구성원에 대한 액세스를 제어합니다. 주 구성원은 Google Cloud에 인증된 하나 이상의 ID를 나타냅니다.

이전에는 주 구성원을 구성원이라고 불렀습니다. 일부 API에서는 여전히 이 용어가 사용됩니다.

IAM에는 다양한 유형의 주 구성원이 있지만 대략적으로 두 가지 카테고리로 나눌 수 있습니다.

• 사람 사용자: 일부 IAM 주 구성원 유형은 사람 사용자를 나타냅니다. 이러한 주 구성원 유형은Google Cloud 리소스에 대한 직원 액세스를 관리하는 데 사용됩니다.

  사람 사용자를 나타내는 주 구성원 유형에는 Google 계정, Google 그룹, 직원 ID 풀의 제휴 ID가 포함됩니다.

• 워크로드: 일부 IAM 주 구성원 유형은 워크로드를 나타냅니다. 이러한 주 구성원 유형은Google Cloud 리소스에 대한 워크로드 액세스를 관리할 때 사용합니다.

  워크로드를 나타내는 주 구성원 유형에는 워크로드 아이덴티티 풀의 서비스 계정 및 제휴 ID가 포함됩니다.

주 구성원에 대한 자세한 내용은 IAM 주 구성원을 참조하세요.

권한 및 역할

권한은 리소스에 대해 허용되는 작업을 결정합니다. IAM에서 권한은 일반적으로 service.resource.verb 형식으로 표시됩니다. 권한은 종종 REST API 메서드와 일대일로 연결됩니다. 예를 들어 resourcemanager.projects.list 권한을 사용하면 Resource Manager 프로젝트를 나열할 수 있습니다.

주 구성원에는 권한을 직접 부여할 수 없습니다. 대신 역할을 부여하여 주 구성원에 권한을 부여합니다.

역할은 권한 모음입니다. 주 구성원에 역할을 부여하면 해당 역할의 모든 권한을 주 구성원에 부여하게 됩니다.

역할에는 세 가지 유형이 있습니다.

• 사전 정의된 역할: Google Cloud 서비스에서 관리되는 역할입니다. 이러한 역할에는 주어진 각 서비스에 대해 일반적인 태스크를 수행하는 데 필요한 권한이 포함되어 있습니다. 예를 들어 Pub/Sub 게시자 역할(roles/pubsub.publisher)은 Pub/Sub 주제에 메시지를 게시하기 위한 액세스 권한을 제공합니다.

• 커스텀 역할: 사용자가 만든 역할에 지정한 권한만 포함됩니다. 이러한 역할의 권한은 완벽하게 제어할 수 있습니다. 하지만 사전 정의된 역할보다 유지보수 부담이 크고 프로젝트 및 조직에 포함할 수 있는 커스텀 역할 수에 한도가 있습니다.

• 기본 역할:Google Cloud 서비스에 대해 포괄적인 액세스 권한을 제공하는 광범위한 역할입니다. 이러한 역할은 테스트 목적에 유용할 수 있지만 프로덕션 환경에서 사용하지 않아야 합니다.

역할 및 권한에 대한 자세한 내용은 역할 및 권한을 참조하세요.

리소스

대부분의 Google Cloud 서비스에는 자체 리소스가 포함되어 있습니다. 예를 들어 Compute Engine에는 인스턴스, 디스크, 서브네트워크와 같은 리소스가 포함됩니다.

IAM에서는 리소스에 대한 역할을 부여합니다. 주 구성원에 리소스에 대한 역할을 부여한다는 것은 주 구성원이 해당 역할의 권한을 이용해서 리소스에 액세스할 수 있음을 의미합니다.

Google Cloud 리소스의 일부에 대해 역할을 부여할 수 있습니다. 역할을 부여할 수 있는 전체 리소스 목록은 허용 정책을 허용하는 리소스 유형을 참조하세요.

Google Cloud 에는 또한 프로젝트, 폴더, 조직을 포함한 여러 컨테이너 리소스가 포함됩니다. 주 구성원에 컨테이너 리소스에 대한 역할을 부여하면 주 구성원이 컨테이너 리소스 그리고 해당 컨테이너에 있는 리소스에 액세스할 수 있습니다. 이 기능을 사용하면 단일 역할 부여를 통해 직접 역할을 부여할 수 없는 리소스를 포함하여 여러 리소스에 대한 액세스 권한을 주 구성원에게 제공할 수 있습니다. 자세한 내용은 이 페이지에서 정책 상속을 참조하세요.

허용 정책

허용 정책을 사용하여 주 구성원에게 역할을 부여합니다. 이전에는 이러한 정책을 IAM 정책이라고 불렀습니다.

허용 정책은 Google Cloud리소스에 연결된 YAML 또는 JSON 객체입니다.

다음 다이어그램은 허용 정책의 구성 방법을 보여줍니다.

각 허용 정책에는 해당 역할이 부여된 주 구성원과 IAM 역할을 연결하는 역할 바인딩 목록이 포함되어 있습니다.

인증된 주 구성원이 리소스 액세스를 시도하면 IAM이 해당 리소스의 허용 정책을 검사하여 주 구성원에게 필요한 권한이 있는지 확인합니다. 주 구성원이 필요한 권한이 있는 역할을 포함하는 역할 바인딩에 있으면 리소스 액세스가 허용됩니다.

허용 정책 예시를 보고 구조에 대해 알아보려면 허용 정책 이해를 참조하세요.

정책 상속

Google Cloud 에는 프로젝트, 폴더, 조직과 같이 부모-자식 계층 구조로 리소스를 구성할 수 있는 컨테이너 리소스가 포함되어 있습니다. 이러한 계층 구조를 리소스 계층 구조라고 부릅니다.

Google Cloud 리소스 계층 구조는 다음과 같이 구성됩니다.

• 조직은 계층 구조의 루트 노드입니다.
• 폴더는 조직 또는 다른 폴더의 하위 요소입니다.
• 프로젝트는 조직 또는 폴더의 하위 요소입니다.
• 각 서비스의 리소스는 프로젝트의 하위 요소입니다.

다음 다이어그램은 Google Cloud 리소스 계층 구조의 예시입니다.

컨테이너 리소스에 허용 정책을 설정하면 허용 정책이 해당 컨테이너의 모든 리소스에 적용됩니다. 이 개념을 정책 상속이라고 부릅니다. 하위 요소 리소스가 상위 요소 리소스의 허용 정책을 실제로 상속하기 때문입니다.

정책 상속의 의미는 다음과 같습니다.

• 단일 역할 바인딩을 사용하여 여러 리소스에 대한 액세스 권한을 부여할 수 있습니다. 컨테이너의 모든 리소스에 대한 액세스 권한을 주 구성원에 부여하려면 컨테이너의 리소스 대신 컨테이너의 역할을 부여합니다.

  예를 들어 보안 관리자가 조직 내 모든 리소스에 대한 허용 정책을 관리하도록 하려면 조직에 대해 보안 관리자 역할(roles/iam.securityAdmin)을 부여할 수 있습니다.

• 자체 허용 정책이 없는 리소스에 대해 액세스 권한을 부여할 수 있습니다. 모든 리소스에서 허용 정책이 허용되지는 않지만 모든 리소스가 상위 요소의 허용 정책을 상속합니다. 자체 허용 정책을 가질 수 없는 리소스에 대한 액세스 권한을 주 구성원에 부여하려면 리소스 상위 요소 중 하나에 대한 역할을 부여합니다.

  예를 들어 어떤 사용자에게 로그 버킷에 로그를 기록하는 권한을 부여한다고 가정해 보세요. 로그 버킷에는 자체 허용 정책이 없으므로, 누군가에게 이 권한을 부여하려면 로그 버킷이 포함된 프로젝트에 대해 로그 버킷 작성자 역할(roles/logging.bucketWriter)을 부여하면 됩니다.

• 또한 리소스에 액세스할 수 있는 사람을 이해하기 위해서는 리소스에 영향을 주는 모든 허용 정책을 확인해야 합니다. 리소스에 액세스할 수 있는 주 구성원의 전체 목록을 보려면 리소스의 허용 정책 및 리소스 상위 요소의 허용 정책을 확인해야 합니다. 이러한 모든 정책을 유효 허용 정책이라고 부릅니다.

허용 정책의 정책 상속에 대한 자세한 내용은 액세스 제어를 위한 리소스 계층 구조 사용을 참조하세요.

고급 액세스 제어

허용 정책 외에도 IAM은 누가 어떤 리소스에 액세스할 수 있는지 세부적으로 제어하는 다음과 같은 액세스 제어 메커니즘을 제공합니다.

• 추가 정책 유형: IAM은 허용 정책 외에도 다음과 같은 정책 유형을 제공합니다.

  • 거부 정책: 거부 정책은 권한이 포함된 역할이 부여된 경우에도 주 구성원이 특정 권한을 사용하지 못하도록 방지합니다.

  • 주 구성원 액세스 경계(PAB) 정책: 주 구성원 액세스 경계 정책은 주 구성원에게 액세스 자격이 있는 리소스를 정의하고 적용합니다. 주 구성원은 자신에게 액세스 자격이 없는 리소스에 대해서는 해당 리소스에 대한 권한이 부여되었더라도 액세스할 수 없습니다.

  이러한 정책에 대한 자세한 내용은 정책 유형을 참조하세요.

• IAM 조건: IAM 조건을 사용하면 속성 기반의 조건부 액세스 제어를 정의하고 적용할 수 있습니다. 다양한 정책 유형에서 조건을 사용할 수 있습니다. 예를 들어 조건이 충족된 경우에만 역할이 부여되도록 보장하기 위해 허용 정책에서 역할 바인딩에 조건을 추가할 수 있습니다.

  요청의 리소스 그리고 요청 시간과 같은 속성에 따라 조건을 작성할 수 있습니다.

  IAM 조건에 대한 자세한 내용은 IAM 조건 개요를 참조하세요.

• Privileged Access Manager(PAM): Privileged Access Manager를 사용하면 주 구성원이 리소스에 대해 감사 가능한 임시 액세스 권한을 요청하고 권한을 부여 받도록 할 수 있습니다. 예를 들어 IAM 역할을 영구적으로 부여하지 않고도 주 구성원이 민감한 리소스를 보려고 할 때마다 액세스를 요청하도록 설정할 수 있습니다.

  또한 주 구성원이 액세스를 요청할 때 근거를 제공하거나 승인을 받을 필요가 있는지 여부를 구성할 수 있습니다.

  Privileged Access Manager에 대한 자세한 내용은 Privileged Access Manager 개요를 참조하세요.

IAM API의 일관성 모델

IAM API는 eventual consistency를 갖게 됩니다. 즉, IAM API로 데이터를 쓴 후 즉시 데이터를 읽으면 읽기 작업에서 이전 버전의 데이터를 반환할 수 있습니다. 또한 변경사항이 액세스 검사에 영향을 주는 데 시간이 걸릴 수 있습니다.

이 일관성 모델은 IAM API의 작동 방식에 영향을 줍니다. 예를 들어 서비스 계정을 만든 다음 다른 요청에서 해당 서비스 계정을 즉시 참조하는 경우 IAM API에서 서비스 계정을 찾을 수 없다고 표시될 수 있습니다. 이는 작업이 eventual consistency를 가지기 때문에 발생합니다. 새 서비스 계정이 읽기 요청에 표시되는 데 다소 시간이 걸릴 수 있습니다.

다음 단계

• Google Cloud의 ID를 구성하는 방법은 Google Cloud의 ID 관리를 참조하세요.
• 주 구성원에 대한 IAM 역할 부여, 변경, 취소 방법은 프로젝트, 폴더, 조직에 대한 액세스 관리를 참조하세요.
• 사용 가능한 IAM 역할 목록은 사전 정의된 역할을 참조하세요.
• 가장 적합한 사전 정의된 역할을 선택하는 데 도움이 필요하면 사전 정의된 역할 선택을 참조하세요.
• IAM에서 사용 가능한 정책 유형에 대한 자세한 내용은 정책 유형을 참조하세요.