선택사항: 요청에 일부 주 구성원 집합의 승인이 필요한지와 해당 주 구성원이 승인에 대한 근거를 제공해야 하는지 여부입니다.
선택사항: 권한 부여 및 대기 중인 승인과 같은 중요한 이벤트에 대한 알림을 받을 추가 이해관계자입니다.
사용 권한에 요청자로 추가된 주 구성원은 해당 사용 권한에 대해 권한 부여를 요청할 수 있습니다.
성공하면 권한 부여 기간이 끝날 때까지 사용 권한에 나열된 역할이 부여되고 그 후에는 Privileged Access Manager에서 역할을 취소합니다.
사용 사례
Privileged Access Manager를 효과적으로 사용하려면 먼저 조직의 니즈를 해결할 수 있는 특정 사용 사례와 시나리오를 파악합니다. 이러한 사용 사례와 필수 요구사항 및 제어를 기반으로 Privileged Access Manager 사용 권한을 조정합니다. 여기에는 필요한 사유 및 승인과 함께 관련 사용자, 역할, 리소스, 기간을 매핑하는 것이 포함됩니다.
Privileged Access Manager는 영구 권한이 아닌 임시 권한을 부여하기 위한 일반적인 권장사항으로 사용될 수 있지만 다음과 같이 일부 시나리오에서는 일반적으로 사용될 수 있습니다.
긴급 액세스 권한 부여: 일부 긴급 구조원이 승인을 기다릴 필요 없이 중요한 태스크를 수행하도록 허용합니다. 추가 컨텍스트를 얻기 위해 긴급 액세스 권한이 필요한 이유에 대한 근거를 요구할 수 있습니다.
민감한 리소스에 대한 액세스 권한 제어: 승인 및 비즈니스 근거를 요구하여 민감한 리소스에 대한 액세스 권한을 엄격하게 제어합니다. Privileged Access Manager는 이 액세스 권한이 사용된 방식을 감사하는 데도 사용될 수 있습니다(예: 사용자에게 부여된 역할이 활성화된 시점, 해당 시간에 액세스할 수 있었던 리소스, 액세스 권한 근거, 승인한 사람).
예를 들어 Privileged Access Manager를 사용하여 다음을 수행할 수 있습니다.
문제 해결 또는 배포를 위해 개발자에게 프로덕션 환경에 대한 임시 액세스 권한을 부여합니다.
특정 태스크를 위해 지원 엔지니어에게 민감한 고객 데이터에 대한 액세스 권한을 부여합니다.
유지보수 또는 구성 변경을 위해 데이터베이스 관리자에게 승격된 권한을 부여합니다.
서비스 계정 보호 지원: 서비스 계정에 역할을 영구 부여하는 대신 서비스 계정이 자동화된 태스크에 필요한 경우에만 역할을 자체 승격하고 수임하도록 허용합니다.
계약업체 및 외부 인력에 대한 액세스 권한 관리: 계약업체 또는 외부 인력에게 리소스에 대한 한시적인 임시 액세스 권한을 부여합니다(승인 및 근거 필요).
기능 및 제한사항
다음 섹션에서는 Privileged Access Manager의 다양한 기능과 제한사항을 설명합니다.
지원되는 리소스
Privileged Access Manager는 프로젝트, 폴더, 조직에 대한 사용 권한을 만들고 권한 부여를 요청할 수 있습니다.
프로젝트, 폴더 또는 조직 내 리소스의 하위 집합에 대한 액세스 권한을 제한하려면 IAM 조건을 사용 권한에 추가하면 됩니다.
Privileged Access Manager는 허용 정책 역할 바인딩에서 지원되는 모든 조건 속성을 지원합니다.
지원되는 역할
Privileged Access Manager는 사전 정의된 역할, 커스텀 역할, 관리자, 작성자, 리더 기본 역할을 지원합니다. Privileged Access Manager는 기존 기본 역할(소유자, 편집자, 뷰어)을 지원하지 않습니다.
Privileged Access Manager는 리소스의 IAM 정책에서 역할 바인딩을 추가 및 삭제하여 임시 액세스 권한을 관리합니다. 이러한 역할 바인딩이 Privileged Access Manager 이외에서 수정되면 Privileged Access Manager가 예상대로 작동하지 않을 수 있습니다.
이 문제를 방지하려면 다음을 수행하는 것이 좋습니다.
Privileged Access Manager에서 관리하는 역할 바인딩을 수동으로 수정하지 마세요.
Terraform을 사용하여 IAM 정책을 관리하는 경우 신뢰할 수 있는 리소스 대신 신뢰할 수 없는 리소스를 사용해야 합니다. 이렇게 하면 선언적 IAM 정책 구성에 역할 바인딩이 없더라도 Terraform에서 Privileged Access Manager 역할 바인딩을 재정의하지 않습니다.
알림
Privileged Access Manager는 다음 섹션에 설명된 대로 Privileged Access Manager에서 발생하는 다양한 이벤트를 알릴 수 있습니다.
이메일 알림
Privileged Access Manager는 사용 권한 및 권한 부여 변경사항에 대한 이메일 알림을 관련 이해관계자에게 전송합니다. 수신자는 다음과 같습니다.
사용 권한에서 수동으로 구성된 이메일 주소:Google Cloud 콘솔을 사용하는 경우 이러한 이메일 주소는 사용 권한의 추가 알림 섹션에 있는 사용 가능한 사용 권한에 대한 알림 필드에 표시됩니다. gcloud CLI 또는 REST API를 사용하는 경우 이러한 이메일 주소는 requesterEmailRecipients 필드에 표시됩니다.
사용 권한 부여 승인자:
사용 권한에서 승인자로 지정된 Cloud ID 사용자 및 그룹의 이메일 주소입니다.
사용 권한에서 수동으로 구성된 이메일 주소:Google Cloud 콘솔을 사용하는 경우 이러한 이메일 주소는 사용 권한의 추가 알림 섹션에 있는 권한 부여에서 승인을 대기 중일 때 알림 필드에 표시됩니다. gcloud CLI 또는 REST API를 사용하는 경우 이러한 이메일 주소는 승인 워크플로 단계의 approverEmailRecipients 필드에 표시됩니다.
사용 권한 관리자:
사용 권한에서 수동으로 구성된 이메일 주소:Google Cloud 콘솔을 사용하는 경우 이러한 이메일 주소는 사용 권한의 추가 알림 섹션에 있는 액세스 권한이 부여되면 알림 필드에 표시됩니다. gcloud CLI 또는 REST API를 사용하는 경우 이러한 이메일 주소는 adminEmailRecipients 필드에 표시됩니다.
권한 부여 요청자:
권한 부여 요청자가 Cloud ID 사용자인 경우 권한 부여 요청자의 이메일 주소입니다.
권한 부여를 요청하는 동안에 요청자가 추가한 이메일 주소: Google Cloud 콘솔을 사용하는 경우 이러한 이메일 주소는 이 권한 부여에 대한 업데이트를 받을 이메일 주소 필드에 표시됩니다. gcloud CLI 또는 REST API를 사용하는 경우 이러한 이메일 주소는 additionalEmailRecipients 필드에 표시됩니다.
Privileged Access Manager는 다음 이벤트에 대한 이메일을 이러한 이메일 주소로 전송합니다.
수신자
이벤트
자격 요건을 충족하는 사용 권한 요청자
사용 권한이 생성되고 사용할 수 있게 되는 경우
사용 권한 부여 승인자
권한 부여가 요청되었으며 승인이 필요한 경우
권한 부여 요청자
권한 부여가 활성화되거나 활성화되지 않는 경우
권한 부여가 종료된 경우
권한 부여가 거부된 경우
권한 부여가 만료되는 경우(24시간 이내에 승인 또는 거부되지 않음)
권한 부여가 취소된 경우
사용 권한 관리자
권한 부여가 활성화되거나 활성화되지 않는 경우
권한 부여가 종료된 경우
Pub/Sub 알림
Privileged Access Manager는 Cloud 애셋 인벤토리와 통합됩니다.
Cloud 애셋 인벤토리 피드 기능을 사용하여 Pub/Sub를 통해 모든 권한 변경사항에 대한 알림을 수신할 수 있습니다. 권한 부여에 사용할 수 있는 애셋 유형은 privilegedaccessmanager.googleapis.com/Grant입니다.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-09-04(UTC)"],[[["\u003cp\u003ePrivileged Access Manager (PAM) allows for temporary privilege elevation for specific users, with detailed audit logs showing who accessed what and when.\u003c/p\u003e\n"],["\u003cp\u003ePAM uses entitlements to define who can request temporary access, what roles are granted, the duration of the access, and whether approvals or justifications are needed.\u003c/p\u003e\n"],["\u003cp\u003ePAM is useful in various scenarios, including granting emergency access, controlling access to sensitive resources, securing service accounts, and managing access for contractors.\u003c/p\u003e\n"],["\u003cp\u003ePAM supports various resources, roles, and identities, and it automatically manages the temporary addition and removal of role bindings in IAM policies.\u003c/p\u003e\n"],["\u003cp\u003ePAM sends email notifications to relevant stakeholders about entitlement and grant changes, and integrates with Cloud Asset Inventory to provide notifications about all grant changes through Pub/Sub.\u003c/p\u003e\n"]]],[],null,["# Privileged Access Manager overview\n\nYou can use Privileged Access Manager (PAM) to control just-in-time temporary privilege\nelevation for select principals, and to [view audit logs](/iam/docs/pam-audit-entitlement-events)\nafterwards to find out who had access to what and when.\n\nTo allow temporary elevation, you [create an *entitlement*](/iam/docs/pam-create-entitlements)\nin Privileged Access Manager, and add the following attributes to it:\n\n- A set of principals who are allowed to request a grant against the\n entitlement.\n\n- Whether a justification is required for that grant.\n\n- A set of [roles](/iam/docs/roles-overview) to temporarily grant.\n [IAM conditions](/iam/docs/conditions-overview) can be set on\n the roles.\n\n- The maximum duration a grant can last.\n\n- Optional: Whether requests need [approval from a select set of principals](/iam/docs/pam-approve-deny-grants),\n and whether those principals need to justify their approval.\n\n- Optional: Additional stakeholders to be notified about important events,\n such as grants and pending approvals.\n\nA principal that's been added as a requester to an entitlement can\n[request a grant against that entitlement](/iam/docs/pam-request-temporary-elevated-access).\nIf successful, they are granted the roles listed in the entitlement\nuntil the end of the grant duration, after which the roles are revoked by\nPrivileged Access Manager.\n\nUse cases\n---------\n\nTo effectively use Privileged Access Manager, start by identifying specific use cases\nand scenarios where it can address your organization's needs. Tailor your\nPrivileged Access Manager entitlements based on these use cases and necessary\nrequirements and controls. This involves mapping out the users, roles,\nresources, and durations involved, along with any necessary justifications and\napprovals.\n\nWhile Privileged Access Manager can be used as a general best practice to grant\ntemporary rather than permanent privileges, here are some scenarios where it may\nbe commonly used:\n\n- **Grant emergency access**: Allow select emergency responders to perform critical\n tasks without having to wait for approval. You can mandate justifications for\n additional context on why the emergency access is needed.\n\n- **Control access to sensitive resources**: Tightly control access to sensitive\n resources, requiring approvals and business justifications. Privileged Access Manager\n can also be used to audit how this access was used---for example, when\n granted roles were active for a user, which resources were accessible during\n that time, the justification for access, and who approved it.\n\n For example, you can use Privileged Access Manager to do the following:\n - Give developers temporary access to production environments for\n troubleshooting or deployments.\n\n - Give support engineers access to sensitive customer data for specific\n tasks.\n\n - Give database administrators elevated privileges for maintenance or\n configuration changes.\n\n- **Help secure service accounts**: Instead of permanently granting roles to\n service accounts, allow service accounts to self-elevate and assume roles only\n when needed for automated tasks.\n\n- **Manage access for contractors and extended workforce**: Grant contractors or\n members of the extended workforce temporary, time-bound access to resources,\n with approvals and justifications required.\n\nCapabilities and limitations\n----------------------------\n\nThe following sections describe the different capabilities and limitations of\nPrivileged Access Manager.\n\n### Supported resources\n\nPrivileged Access Manager supports creating entitlements and requesting grants for\nprojects, folders, and organizations.\n\nIf you want to limit access to a subset of resources within a project, folder,\nor organization, you can add [IAM\nConditions](/iam/docs/conditions-overview) to the entitlement.\nPrivileged Access Manager supports all condition attributes that are supported\nin allow policy role bindings.\n| **Note:** In Privileged Access Manager entitlements, using conditions that check the [tags](/iam/docs/tags-access-control#control-access) for a resource is in [preview](/products#product-launch-stages).\n\n### Supported roles\n\nPrivileged Access Manager supports [predefined roles](/iam/docs/roles-overview#predefined),\n[custom roles](/iam/docs/roles-overview#custom), and the Admin, Writer, and\nReader [Basic roles](/iam/docs/roles-overview#basic). Privileged Access Manager\ndoesn't support [legacy basic roles](/iam/docs/roles-overview#legacy-basic)\n(Owner, Editor, and Viewer).\n\n### Supported identities\n\nPrivileged Access Manager supports all types of identities, including\n[Cloud Identity](/identity/docs),\n[Workforce Identity Federation](/iam/docs/workforce-identity-federation),\nand [Workload Identity Federation](/iam/docs/workload-identity-federation).\n\n### Audit logging\n\nPrivileged Access Manager events, such as creation of entitlements, requisition or\nreview of grants, are logged to [Cloud Audit Logs](/logging/docs/audit). For\na complete list of events that Privileged Access Manager generates logs for,\nsee the [Privileged Access Manager audit logging\ndocumentation](/iam/docs/audit-logging/audit-logging-pam). To learn\nhow to view these logs, see [Audit entitlement and grant events in\nPrivileged Access Manager](/iam/docs/pam-audit-entitlement-events).\n\n### Grant retention\n\nGrants are automatically deleted from Privileged Access Manager\n30 days after they are denied, revoked, or have expired\nor ended. Logs for grants are kept in Cloud Audit Logs for the\n[log retention duration of the `_Required` bucket](/logging/quotas#logs_retention_periods).\nTo learn how to view these logs, see\n[Audit entitlement and grant events in Privileged Access Manager](/iam/docs/pam-audit-entitlement-events).\n\n### Privileged Access Manager and IAM policy modifications\n\nPrivileged Access Manager manages temporary access by adding and removing\n[role bindings](/iam/docs/allow-policies#structure) from resources' IAM\npolicies. If these role bindings are modified by something other than\nPrivileged Access Manager, then Privileged Access Manager might not work as expected.\n\nTo avoid this issue, we recommend doing the following:\n\n- Don't manually modify role bindings that are managed by Privileged Access Manager.\n- If you use [Terraform](https://www.terraform.io/) to manage your IAM policies, ensure that you're using [non-authoritative resources](https://registry.terraform.io/providers/hashicorp/google/latest/docs/resources/google_project_iam) instead of authoritative resources. This ensures that Terraform won't override Privileged Access Manager role bindings, even if they aren't in the declarative IAM policy configuration.\n\nNotifications\n-------------\n\nPrivileged Access Manager can notify you about various events happening in\nPrivileged Access Manager as described in the following sections.\n\n### Email notifications\n\nPrivileged Access Manager sends emails notifications to the relevant stakeholders\nfor an entitlement and grant changes. The sets of recipients are as follows:\n\n- **Eligible requesters of an entitlement**:\n\n - Email addresses of Cloud Identity users and [groups](/identity/docs/groups) specified as requesters in the entitlement\n - Manually configured email addresses in the entitlement: When using Google Cloud console, these email addresses are listed in the **Notify about an eligible entitlement** field in the **Additional notifications** section of the entitlement. When using the gcloud CLI or the REST API, these email addresses are listed in the `requesterEmailRecipients` field.\n- **Grant approvers for an entitlement**:\n\n - Email addresses of Cloud Identity users and groups specified as approvers in the entitlement.\n - Manually configured email addresses in the entitlement: When using the Google Cloud console, these email addresses are listed in the **Notify when a grant is pending approval** field in the **Additional notifications** section of the entitlement. When using the gcloud CLI or the REST API, these email addresses are listed in the `approverEmailRecipients` field of the approval workflow steps.\n- **Administrator of the entitlement**:\n\n - Manually configured email addresses in the entitlement: When using the Google Cloud console, these email addresses are listed in the **Notify when access is granted** field in the **Additional notifications** section of the entitlement. When using the gcloud CLI or the REST API, these email addresses are listed in the `adminEmailRecipients` field.\n- **Requester of a grant**:\n\n - Email address of the grant requester if they are a Cloud Identity user.\n - Additional email addresses added by the requester while requesting the grant: When using Google Cloud console, these email addresses are listed in the **Email addresses to receive updates about this grant** field. When using gcloud CLI or the REST API, these email addresses are listed in the `additionalEmailRecipients` field.\n\nPrivileged Access Manager sends emails to these email addresses for the following\nevents:\n\n### Pub/Sub notifications\n\nPrivileged Access Manager is integrated with [Cloud Asset Inventory](/asset-inventory/docs/overview).\nYou can use [Cloud Asset Inventory feeds](/asset-inventory/docs/monitoring-asset-changes)\nfeature to receive notifications about all grant changes through\nPub/Sub. The asset type to use for grants is\n`privilegedaccessmanager.googleapis.com/Grant`.\n\nWhat's next\n-----------\n\n- [Privileged Access Manager permissions and setup](/iam/docs/pam-permissions-and-setup)"]]
