과도하게 부여된 권한을 삭제하는 것으로 시작합니다. 많은 주 구성원이 편집자와 같이 높은 권한이 있는 역할을 갖고 있으므로 처음에는 권장사항이 다수 나타날 수 있습니다. 프로젝트 또는 조직의 모든 권장사항에 대처하여 모든 주 구성원이 적절한 역할을 갖도록 합니다.
이 초기 삭제를 수행할 때는 다음 유형의 권장사항을 우선적으로 따릅니다.
서비스 계정의 권한을 축소하는 권장사항
기본적으로 모든 기본 서비스 계정에는 프로젝트에 대한 높은 권한이 있는 편집자 역할이 부여됩니다. 개발자가 관리하는 다른 서비스 계정에도 높은 권한이 있는 역할이 부여되었을 수 있습니다. 과도한 권한이 있는 서비스 계정을 포함하여 과도하게 부여된 권한은 모두 보안 위험을 증가시키므로 초기 삭제 시 과도한 권한이 있는 서비스 계정을 우선적으로 처리하는 것이 좋습니다.
권한 에스컬레이션을 방지하기 위한 권장사항 주 구성원이 서비스 계정(iam.serviceAccounts.actAs)으로 작업을 수행하거나 리소스의 허용 정책을 가져오거나 설정할 수 있게 해주는 역할은 주 구성원이 자신의 권한을 승격시킬 수 있는 가능성이 있습니다. 이러한 역할과 관련된 권장사항을 우선 처리합니다.
측면 이동을 줄여주는 권장사항. 측면 이동은 한 프로젝트의 서비스 계정에 다른 프로젝트의 서비스 계정을 가장할 수 있는 권한이 있는 경우입니다. 이러한 권한은 주 구성원에 의도하지 않은 리소스 액세스 권한을 부여하는 프로젝트 간의 일련의 가장을 일으킬 수 있습니다. 의도하지 않은 액세스를 줄이려면 측면 이동 통계와 연관된 권장사항을 우선적용합니다.
우선순위 수준이 높은 권장사항 IAM 권장사항에는 연결된 역할 binding에 따라 자동으로 우선순위 수준이 할당됩니다. 과도하게 부여된 권한을 빠르게 줄이려면 높은 우선순위 수준으로 권장사항의 우선순위를 지정합니다.
한 프로젝트에서 과도한 권한을 부여받은 주 구성원이 발견되면 다른 프로젝트에도 이 주 구성원과 관련된 권장사항이 있는지 확인합니다. 한 프로젝트에서 과도한 권한이 있는 역할을 부여받은 주 구성원이 있으면 다른 프로젝트에서도 과도한 권한을 부여받았을 가능성이 있습니다. 여러 프로젝트에서 주 구성원에 대한 권장사항을 검토하여 전역에서 주 구성원의 액세스 권한을 적절한 수준으로 축소합니다.
초기 삭제 후에는 정기적으로 권장사항을 확인합니다. 최소 1주일에 1번 이상 권장사항을 확인하는 것이 좋습니다. 일반적으로 이러한 확인에 걸리는 시간은 초기 삭제 시보다 훨씬 적습니다. 마지막 삭제 또는 확인 후에 발생한 변경사항에 대한 권장사항만 처리하면 되기 때문입니다.
정기적으로 권한을 확인하면 각 확인에 필요한 작업이 줄어들고 비활성 사용자를 사전에 파악하여 삭제할 수 있을 뿐만 아니라 활성 사용자의 권한 범위를 계속 축소할 수 있습니다.
권장사항을 보다 효율적으로 관리하기 위해 권장사항 적용 프로세스를 자동화할 수 있습니다. 자동화를 사용하는 경우 다음 사항에 유의하세요.
추천자는 액세스에 브레이킹 체인지를 유발하지 않는 권장사항을 제공합니다. 예를 들어 주 구성원이 지난 90일 동안 수동적 또는 능동적으로 사용한 권한을 제외하는 역할은 권장되지 않습니다. 또한 머신러닝을 사용하여 사용자에게 필요할 수 있는 다른 권한을 파악합니다.
하지만 제공되는 권장사항이 액세스에 브레이킹 체인지를 유발하지 않는다고 보장할 수 없으며 권장사항이 적용되면 주 구성원이 필요한 리소스에 액세스하지 못하게 될 수도 있습니다. IAM 추천자 작동 방식을 살펴보고 자신에게 맞는 자동화 수준이 어느 정도인지 판단하는 것이 좋습니다. 예를 들어 대부분의 권장사항이 자동으로 적용되지만 권한을 특정 수만큼 추가 또는 삭제하거나 특정 역할을 부여 또는 취소하는 권장사항을 수동으로 검토할 수 있습니다.
권장사항을 자동화할 때 권장사항이 어떤 리소스에 적용되는지 식별하는 것이 좋습니다. 리소스를 식별하려면 operation.resource 필드를 사용합니다. name 필드와 같은 다른 필드는 권장사항이 적용되는 리소스를 항상 나타내지는 않습니다.
[[["이해하기 쉬움","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)"],[],[],null,["# Role recommendations best practices\n\nWe recommend the following best practices for managing role recommendations.\n\nFor more information about role recommendations, see the\n[role recommendation overview](/policy-intelligence/docs/role-recommendations-overview).\n\nGetting started with recommendations\n------------------------------------\n\nThe following best practices can help you get started with role recommendations.\n\n- **Begin with an initial cleanup of over-granted permissions.** Initially, you\n might see a very large number of recommendations, especially if many\n principals have highly permissive roles like Editor. Take the time to address\n all recommendations in your project or organization to ensure that all of your\n principals have the appropriate roles.\n\n When doing this initial cleanup, prioritize the following types of\n recommendations:\n - **Recommendations that reduce permissions for service accounts.**\n By default, all [default service accounts](/iam/docs/service-account-types#default) are\n granted the highly permissive Editor role on projects. Other\n service accounts that you manage might also have been granted highly\n permissive roles. All over-granted permissions increase your security\n risk, including overly privileged service accounts, so we recommend\n prioritizing overly privileged service accounts during your\n initial cleanup.\n\n - **Recommendations that help prevent privilege escalation.** Roles that\n let principals act as a service account (`iam.serviceAccounts.actAs`)\n or get or set the allow policy for a resource can potentially let a\n principal escalate their own privilege. Prioritize recommendations\n relating to these roles.\n\n - **Recommendations that reduce lateral movement.** Lateral movement is when\n a service account in one project has permission to impersonate a service\n account in another project. This permission can result in a chain of\n impersonations across projects that gives principals unintended access to\n resources. To mitigate this unintended access, prioritize recommendations\n that are associated with [lateral movement\n insights](/policy-intelligence/docs/role-recommendations-overview#lateral-movement-insights).\n\n - **Recommendations with a high priority level.** IAM\n recommendations are automatically assigned priority levels based on the\n role bindings they're associated with. Prioritize recommendations with\n a high priority level to quickly reduce over-granted permissions.\n\n To learn how a recommendation's priority is determined, see\n [Recommendation priority](/policy-intelligence/docs/role-recommendations-overview#priority).\n - **When you find an over-privileged principal in one project, check other\n projects for recommendations involving that principal.** If a principal\n has been granted an overly permissive role in one project, it is possible\n that they have been granted overly permissive roles in other projects as\n well. Review recommendations for the principal across multiple projects to\n globally reduce the principal's access to the appropriate level.\n\n- After the initial cleanup, **check your recommendations regularly.** We\n recommend that you check your recommendations at least once a week. This check\n will usually take much less time than the initial cleanup, because you will\n only need to address recommendations for changes that have occurred since the\n last cleanup or check.\n\n Regularly checking permissions reduces the work required for each check, and\n can help you proactively identify and remove inactive users, as well as\n continue to downscope permissions for active users.\n\nBest practices for working with recommendations\n-----------------------------------------------\n\nIf you use the [Recommender API](/recommender/docs/reference/rest) or the\n[`recommender` commands for the gcloud CLI](/sdk/gcloud/reference/recommender) to\nmanage recommendations, make sure to update the state of recommendations that\nyou apply. This allows you to keep track of your recommendations and ensures\nthat the changes you make appear in your [recommendations logs](/policy-intelligence/docs/review-apply-role-recommendations#logs).\n\nBest practices for applying recommendations automatically\n---------------------------------------------------------\n\nTo manage your recommendations more efficiently, you might want to automate the\nprocess of applying recommendations. If you decide to use automation, keep the\nfollowing points in mind.\n\nRecommender tries to provide recommendations that will not\ncause breaking changes in access. For example, we will never recommend a role\nthat excludes permissions that a principal has used,\n[passively or actively](/policy-intelligence/docs/role-recommendations-overview#permissions-used), in the last\n90 days. We also use [machine learning](/policy-intelligence/docs/role-recommendations-overview#ml) to\nidentify other permissions that the user is likely to need.\n\nHowever, we cannot guarantee that our recommendations will never cause breaking\nchanges in access---it is possible that applying a recommendation will\nresult in a principal being unable to access a resource that they need. We\nrecommend reviewing\n[How the IAM recommender works](/policy-intelligence/docs/role-recommendations-overview#how-recommender-works) and\ndeciding how much automation you are comfortable with. For example, you might\ndecide to apply most recommendations automatically, but require a manual review\nfor recommendations that add or remove a certain number of permissions, or that\ninvolve granting or revoking a specific role.\n\nWhen automating recommendations, you might want to identify which resource a\nrecommendation is for. To identify the resource, use the `operation.resource`\nfield. Other fields, such as the `name` field, will not always represent the\nresource that the recommendation is for.\n\nWhat's next\n-----------\n\n- Understand [role recommendations](/policy-intelligence/docs/role-recommendations-overview).\n- Learn the steps for [reviewing and applying recommendations](/policy-intelligence/docs/review-apply-role-recommendations).\n- Find out how to [export data for IAM recommendations](/policy-intelligence/docs/export-role-recommendations-data)."]]
