거부 정책에 대한 정책 시뮬레이터를 사용하면 변경사항을 커밋하기 전에 IAM 거부 정책 변경사항이 주 구성원 액세스에 어떠한 영향을 미치는지 확인할 수 있습니다. 정책 시뮬레이터를 사용하면 변경사항으로 인해 주 구성원에게 필요한 액세스 권한이 손실되지 않도록 할 수 있습니다.
이 기능은 거부 정책만 평가합니다. 다른 정책 유형을 시뮬레이션하는 방법을 알아보려면 다음을 참고하세요.
조직이 90일 이상 존재하지 않으면 정책 시뮬레이터는 조직 생성 이후의 모든 액세스 로그를 검색합니다.
시뮬레이션과 관련된 액세스 로그를 결정합니다. 관련 액세스 로그는 권한을 사용하여 리소스에 액세스하려는 주 구성원의 가장 최근 시도를 나타내는 모든 액세스 로그입니다.
관련 액세스 로그마다 현재 거부 정책과 제안된 변경사항이 시도된 액세스를 허용하는지 확인합니다. 이 프로세스를 액세스 시도 재생이라고 합니다.
각 액세스 로그에 대해 리플레이의 액세스 상태를 액세스 로그의 액세스 상태와 비교합니다. 그런 다음 정책 시뮬레이터는 액세스 로그에서 차단되지 않았지만 재생에서 차단된 이전 액세스 시도를 보고합니다. 액세스 변경사항이라고 하는 이러한 차이점은 시도 시점에 시뮬레이션된 거부 정책이 적용되었다면 차단되었을 액세스 시도를 보여줍니다.
다시보기 기간
재생 기간은 시뮬레이션을 실행할 때 정책 시뮬레이터가 액세스 로그를 가져오는 기간입니다. 재생 기간의 첫날 이전 또는 재생 기간의 마지막 날 이후에 발생하는 액세스 로그는 시뮬레이션에 포함되지 않습니다.
일반적으로 리플레이 기간의 마지막 날은 시뮬레이션 전날입니다. 하지만 일부 경우에는 리플레이 기간의 마지막 날이 시뮬레이션 시작일로부터 최대 10일 전일 수 있습니다. 리플레이 기간의 마지막 날 이후에 발생하는 액세스 로그는 시뮬레이션에 포함되지 않습니다.
다시보기 기간은 90일입니다. 조직이 90일 이상 존재하지 않으면 정책 시뮬레이터는 조직 생성 이후의 모든 액세스 시도를 검색합니다.
재생 창도 eventual consistency를 가집니다. 즉, 시뮬레이션을 실행할 때 일부 데이터가 다른 데이터보다 최신일 수 있습니다. 하지만 결국 모든 데이터의 업데이트 빈도가 동일해집니다.
정책 시뮬레이터 결과
정책 시뮬레이터는 거부 정책에 대한 제안된 변경사항의 영향을 액세스 변경사항 목록으로 보고합니다. 거부 정책의 경우 정책 시뮬레이터가 보고하는 액세스 변경사항 유형은 액세스 취소됨 액세스 변경사항뿐입니다.
다음이 참인 경우 정책 시뮬레이터는 액세스가 취소되었다고 보고합니다.
주 구성원이 리소스에 액세스하려고 시도한 가장 최근 시도가 성공했습니다.
제안된 변경사항 또는 다른 거부 정책으로 인해 주 구성원의 리소스 액세스가 차단됨
액세스 변경사항마다 정책 시뮬레이터는 다음 정보도 보고합니다.
액세스 시도와 관련된 주 구성원, 리소스, 권한입니다.
주 구성원이 리소스에 액세스하기 위해 권한을 사용하려고 시도한 리플레이 기간의 일수입니다. 이 합계에는 가장 최근 액세스 시도와 결과가 동일한 액세스 시도만 포함됩니다.
가장 최근 액세스 시도 날짜입니다.
오류
다음 오류로 인해 시뮬레이션이 실패할 수 있습니다.
최대 동시 시뮬레이션 수 초과: 사용자가 이미 진행 중인 시뮬레이션이 10개 있습니다. 이는 사용자가 진행할 수 있는 최대 시뮬레이션 수입니다. 이 문제를 해결하려면 진행 중인 시뮬레이션 중 하나가 완료될 때까지 기다린 후 시뮬레이션을 다시 실행해 보세요.
시간 초과: 시뮬레이션을 실행하는 데 너무 오래 걸려 시간 초과되었습니다. 이 문제를 해결하려면 시뮬레이션을 다시 실행해 보세요.
잘못된 시뮬레이션 구성: 제안된 거부 정책이 잘못되었습니다. 예를 들어 제안된 정책에 잘못된 조건 표현식이 있습니다. 이 문제를 해결하려면 정책을 수정한 후 다시 시도하세요.
권한 거부됨: 시뮬레이션을 실행할 권한이 없습니다. 이 문제를 해결하려면 필수 역할이 부여되었는지 확인하고 다시 시도하세요.
지원되는 주 구성원 유형
거부 정책의 정책 시뮬레이터는 다음 유형의 주 구성원의 액세스 로그만 검토합니다.
Google Workspace 계정
서비스 계정
서비스 에이전트
거부 정책을 시뮬레이션할 때 정책 시뮬레이터는 워크로드 아이덴티티 풀의 제휴 ID를 기반으로 하는 ID를 비롯한 다른 주 구성원 유형의 액세스 로그를 검토하지 않습니다. 따라서 정책 시뮬레이터는 정책 또는 바인딩에 제안된 변경사항이 해당 주 구성원의 액세스에 영향을 미치는지 보고하지 않습니다.
[[["이해하기 쉬움","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,["# Policy Simulator for deny policies\n\n| **Preview**\n|\n|\n| This feature is subject to the \"Pre-GA Offerings Terms\" in the General Service Terms section\n| of the [Service Specific Terms](/terms/service-terms#1).\n|\n| Pre-GA features are available \"as is\" and might have limited support.\n|\n| For more information, see the\n| [launch stage descriptions](/products#product-launch-stages).\n\n\u003cbr /\u003e\n\nPolicy Simulator for deny policies lets you see how a change to an\nIAM [deny policy](/iam/docs/deny-overview) might affect a principal's\naccess before you commit to making the change. You can use\nPolicy Simulator to ensure that the changes you're making won't cause a\nprincipal to lose access that they need.\n\nThis feature only evaluates deny policies. To learn how to simulate other policy\ntypes, see the following:\n\n- [Policy Simulator for organization policies](/policy-intelligence/docs/test-organization-policies)\n- [Policy Simulator for allow policies](/policy-intelligence/docs/iam-simulator-overview)\n- [Policy Simulator for principal access boundary policies](/policy-intelligence/docs/pab-simulator-overview)\n\nHow Policy Simulator for deny policies works\n--------------------------------------------\n\nPolicy Simulator for deny policies helps you determine whether a change\nto a deny policy will block access that your principals are using.\n\nWhen you run a simulation for a deny policy, Policy Simulator does the\nfollowing:\n\n1. Retrieves access logs for the organization that were generated during the\n [replay period](#replay-period). The replay period is 90 days.\n\n If the organization has not existed for more than\n 90 days, then Policy Simulator retrieves all\n access logs since the organization was created.\n2. Determines which access logs are relevant to the simulation. Relevant access\n logs are all access logs that represent a principal's most recent attempt to\n use a permission to access a resource.\n\n3. For each relevant access log, determines whether the current\n deny policies, along with the proposed changes,\n would permit the attempted access. This process is called *replaying* the\n access attempts.\n\n4. For each access log, compares the access state from the replay with the\n access state in the access logs. Then, Policy Simulator reports any\n historical access attempts that weren't blocked in the access log, but were\n blocked in the replay. These differences, which are called\n *access changes*, show which access attempts would have been blocked if the\n simulated deny policy had been in place at the time of the attempt.\n\n | **Note:** The access state in an access log might not reflect the current access state. In these cases, Policy Simulator always compares the results of the replay to the result from the access log, *not* to the current access state.\n\n### Replay period\n\nThe replay period is the time period that Policy Simulator gets access\nlogs for when running a simulation. Access logs that occur before the first day\nof the replay period or after the last day of the replay period aren't included\nin the simulation.\n\nTypically, the last day of the replay period is\n1 day prior to the simulation. However, in\nsome cases, the last day of the replay period can be up to\nup to 10 days prior to the simulation. Access logs\nthat occur after the last day of the replay period aren't included in the\nsimulation.\n\nThe replay period is 90 days. If the organization has not existed\nfor more than 90 days, then Policy Simulator retrieves all\naccess attempts since the organization was created.\n\nThe replay window is also [eventually consistent](https://en.wikipedia.org/wiki/Eventual_consistency). This\nmeans that, when you run a simulation, some data might be fresher than other\ndata. However, eventually, all the data will have the same freshness.\n\nPolicy Simulator results\n------------------------\n\nPolicy Simulator reports the impact of a proposed change to a\ndeny policy as a list of *access changes* . For deny policies, the only type of\naccess change that Policy Simulator reports is the **Access revoked**\naccess change.\n\nPolicy Simulator reports that access is revoked if the following are\ntrue:\n\n- The principal's most recent attempt to access the resource was successful\n- The proposed changes or another deny policy block the principal's access to the resource\n\nFor each access change, Policy Simulator also reports the following\ninformation:\n\n- The principal, resource, and permission involved in the access attempt.\n- The number of days during the replay period that the principal tried to use the permission to access the resource. This total includes only the access attempts that have the same result as the most recent access attempt.\n- The date of the most recent access attempt.\n\nErrors\n------\n\nThe following errors can cause a simulation to fail:\n\n- **Maximum concurrent simulations exceeded**: The user already has 10 in-progress simulations, which is the maximum number of in-progress simulations that a user can have. To resolve, wait for one of the in-progress simulations to complete, then try running the simulation again.\n- **Timeout**: The simulation took too long to run and timed out. To resolve, try running the simulation again.\n- **Invalid simulation construction**: The proposed deny policy is invalid. For example, the proposed policy has an invalid condition expression. To resolve, correct the policy and try again.\n- **Permission denied** : You don't have permission to run a simulation. To resolve, ensure that you're granted the [required roles](/policy-intelligence/docs/simulate-deny-policies#required-roles) and try again.\n\nSupported principal types\n-------------------------\n\nPolicy Simulator for deny policies only reviews access\nlogs for the following types of principals:\n\n- Google Workspace Accounts\n- Service accounts\n- Service agents\n\nWhen simulating deny policies, Policy Simulator doesn't review access\nlogs for any other principal types, including those based on federated\nidentities in a workload identity pool. As a result, Policy Simulator\ndoesn't report whether the proposed changes to your policies or bindings affect\nthose principals' access.\n\nWhat's next\n-----------\n\n- Learn how to [simulate a change to a deny policy](/policy-intelligence/docs/simulate-deny-policies).\n- Explore other [Policy Intelligence tools](/policy-intelligence/docs/overview)."]]
