임시 승격 액세스 개요

민감한 리소스를 보호하는 한 가지 방법은 이에 대한 액세스를 제한하는 것입니다. 그러나 민감한 리소스에 대한 액세스를 제한하면 해당 리소스에 가끔 액세스해야 하는 사용자에게 방해가 될 수 있습니다. 예를 들어 사고 해결을 위해 사용자가 민감한 리소스에 긴급하게 액세스해야 할 수 있습니다.

이러한 상황에서는 사용자가 일시적으로 리소스에 액세스할 수 있는 권한을 부여하는 것이 좋습니다. 또한 감사 효과를 높이기 위해 사용자가 리소스에 액세스해야 하는 근거를 기록하는 것이 좋습니다.

Google Cloud에서는 이러한 종류의 일시적으로 승격된 액세스를 관리할 수 있는 몇 가지 방법이 있습니다.

Google 그룹스

일시적으로 승격된 액세스를 관리하는 한 가지 방법은 Google 그룹에 민감한 리소스에 대한 액세스 권한을 부여하고 이 그룹에서 사용자를 추가 및 삭제하여 액세스 권한을 제어하는 것입니다.

일시적으로 승격된 액세스 권한을 위해 Google 그룹을 설정하려면 먼 그룹을 만들고, 일시적으로 사용자에게 부여하려는 역할을 부여합니다. 또한 거부 정책을 사용할 때는 예기치 않은 거부가 일어나지 않도록 관련 거부 규칙으로부터 그룹을 제외시키는 것이 좋습니다.

그룹을 설정한 후에는 사용자를 추가 및 삭제하여 액세스 권한을 수정할 수 있습니다. Google 그룹스 API를 사용할 때는 멤버십 만료를 사용해서 그룹에 사용자를 일시적으로 추가할 수 있습니다.

사용자가 민감한 리소스에 액세스해야 하는 근거를 기록하려면 자체 운영 프로세스 및 툴을 정의해야 합니다.

예를 들어 Compute Engine 리소스에 대한 긴급 액세스를 관리하기 위해서는 emergency-compute-access@example.com이라는 그룹을 만들고 여기에 Compute Admin 역할(roles/compute.admin)을 부여하면 됩니다. 사용자에게 컴퓨팅 리소스에 대해 긴급한 관리 액세스 권한이 필요하면 이러한 사용자를 emergency-compute-access@example.com 그룹에 추가하면 됩니다. 긴급 상황이 해결되면 그룹에서 사용자를 삭제할 수 있습니다.

IAM 조건

IAM 조건을 사용하면 Google Cloud 리소스에 대해 만료되는 액세스 권한을 사용자에게 부여할 수 있습니다. 자세한 내용은 임시 액세스 구성을 참조하세요.

사용자가 민감한 리소스에 액세스해야 하는 근거를 기록하려면 자체 운영 프로세스 및 툴을 정의해야 합니다.

만료된 역할 바인딩은 허용 정책에서 자동으로 삭제되지 않습니다. 허용 정책이 허용 정책의 최대 크기를 초과하지 않도록 하려면 만료된 역할 바인딩을 주기적으로 삭제하는 것이 좋습니다.

거부 정책은 시간 기반의 조건을 지원하지 않습니다. 따라서 거부 정책의 조건을 사용해서 사용자를 거부 규칙에서 일시적으로 제외시킬 수 없습니다.

적시 권한 부여된 액세스

적시 액세스는 IAM 조건을 사용해서 Google Cloud 리소스에 대해 적시 권한 액세스를 사용자에게 부여하는 오픈소스 애플리케이션입니다. 이 애플리케이션은 App Engine 또는 Cloud Run에서 실행되도록 설계되었습니다.

이 애플리케이션은 조건부 역할 바인딩을 수동으로 추가하는 것에 비해 다음과 같은 이점이 있습니다.

  • 사용자가 적시 액세스로 활성화할 수 있는 역할을 검색할 수 있습니다.
  • 액세스 권한을 얻으려면 사용자가 근거를 제공해야 합니다.
  • 애플리케이션이 새 바인딩을 만드는 대신 기존의 조건부 바인딩을 대체하여, IAM 허용 정책 크기를 유지 관리하는 데 도움이 됩니다.

적시 액세스에 대한 자세한 내용은 프로젝트에 대한 적시 권한 액세스 관리를 참조하세요.

서비스 계정 가장

사용자 또는 다른 서비스 계정과 같은 인증된 주 구성원이 서비스 계정의 권한을 얻기 위해 서비스 계정으로 인증될 때 이를 서비스 계정을 가장한다고 부릅니다. 서비스 계정을 가장하면 서비스 계정이 액세스할 수 있는 무엇이든 인증된 주 구성원이 액세스할 수 있습니다. 적절한 권한을 사용해서 인증된 주 구성원만 서비스 계정을 가장할 수 있습니다.

임시 승격 액세스를 위해 서비스 계정을 설정하려면 서비스 계정을 만들고, 사용자에게 임시로 부여하려는 역할을 이 계정에 부여합니다. 또한 거부 정책을 사용할 때는 예기치 않은 거부가 일어나지 않도록 관련 거부 규칙으로부터 제외되는 서비스 계정을 추가하는 것이 좋습니다.

서비스 계정을 설정한 후에는 서비스 계정 가장을 허용하여 사용자에게 임시로 승격된 액세스를 부여할 수 있습니다. 사용자의 서비스 계정 가장을 허용하는 방법은 몇 가지가 있습니다.

  • 서비스 계정에 대해 단기 사용자 인증 정보를 생성하도록 허용하는 역할을 사용자에게 부여합니다. 그러면 사용자가 단기 사용자 인증 정보를 사용해서 서비스 계정을 가장할 수 있습니다.

    • 사용자가 서비스 계정에 대해 단기 OpenID Connect(OIDC) ID 토큰을 만들 수 있게 하려면 서비스 계정 OpenID Connect ID 토큰 생성자 역할(roles/iam.serviceAccountOpenIdTokenCreator)을 부여합니다.

    • 사용자가 다음 유형의 서비스 계정 사용자 인증 정보를 생성할 수 있도록 서비스 계정 토큰 생성자 역할(roles/iam.serviceAccountTokenCreator)을 부여합니다.

      • Google API로 인증하는 데 사용할 수 있는 OAuth 2.0 액세스 토큰
      • OIDC ID 토큰
      • 서명된 JSON 웹 토큰(JWT) 및 바이너리 blob

    사용자에게 이러한 역할 중 하나를 부여하면 언제든지 서비스 계정을 가장하여 자체 액세스를 승격할 수 있습니다. 하지만 민감한 리소스를 의도치 않게 액세스하거나 수정할 가능성이 낮습니다.

    서비스 계정을 가장하는 방법은 서비스 계정 가장 사용을 참조하세요.

  • 인증을 수행하고 근거를 제공한 후 서비스 계정에 대해 단기 사용자 인증 정보를 사용자에게 제공하는 토큰 브로커 서비스를 만듭니다. 그러면 사용자가 단기 사용자 인증 정보를 사용해서 서비스 계정을 가장할 수 있습니다.

    이 방법을 사용하면 사용자의 서비스 계정 가장을 허용할 시간을 결정할 수 있습니다.

    단기 사용자 인증 정보를 만드는 방법을 알아보려면 서비스 계정에 단기 사용자 인증 정보 만들기를 참조하세요.

서비스 계정 가장에 대한 자세한 내용은 서비스 계정 가장을 참조하세요.

다음 단계