使用 VPC Service Controls 時，如果建立或修改了 service perimeter，可能很難判斷對環境的影響。透過模擬測試模式，即可進一步瞭解在現有環境中啟用 VPC Service Controls 和變更 perimeter 的影響。
啟用模擬測試模式時，系統不會拒絕違反 perimeter 政策的要求，只會記錄下來。使用模擬測試模式，不必禁止存取資源，即可測試 perimeter 設定和追蹤服務用量。常見用途包括：
判斷變更現有 service perimeter 的影響。
預覽新 service perimeter 的影響。
監控 service perimeter 外部向受保護服務發出的要求。例如，您可以掌握向特定服務發出的要求來源，或組織內非預期服務使用情形。
在開發環境中，建立與正式環境類似的 perimeter 架構，即可在將變更推送至正式環境前，找出並緩解 service perimeter 引發的問題。
您可僅在模擬測試模式下執行 service perimeter，也可以混合強制執行和模擬測試模式。
模擬測試模式的優點
使用模擬測試模式，可建立新的 service perimeter 或變更多個現有 perimeter，不會影響到現有環境。違反新 perimeter 設定的要求也不會遭到封鎖。此外，即便部分服務沒有和 VPC Service Controls 整合，也能掌握環境中 perimeter 的影響。
您可以分析 VPC Service Controls 記錄中的遭拒項目，變更設定來修正潛在問題，然後強制執行新的安全措施。
如果無法解決 perimeter 設定問題，可以保留 perimeter 模擬測試設定，並追蹤記錄中是否有非預期的拒絕存取要求，這可能表示有資料外洩風險。不過，對 perimeter 的要求不會遭拒。
模擬測試模式概念
模擬測試模式的作用是對 perimeter 設定進行第二次評估。根據預設，所有 service perimeter 的強制執行模式設定都會沿用到模擬測試模式設定，而且可以修改或刪除，不會影響 service perimeter 運作。
由於模擬測試模式會沿用強制執行模式的設定，因此每個步驟的兩種設定都必須有效。具體來說，專案只能在強制執行設定中加入一個 perimeter，並在模擬測試設定中加入另一個。因此，跨多個 perimeter 變更 (例如在 perimeter 之間移動專案) 必須依適當順序排序。
只有在下列兩項條件都符合時，模擬測試模式才會記錄要求：
perimeter 模擬測試或強制執行設定尚未拒絕要求。
要求違反 perimeter 的模擬測試設定。
例如，如果相同的模擬測試和強制模式設定限制了 Cloud Storage bucket，強制執行模式就會封鎖並記錄對 Cloud Storage bucket 的所有要求。模擬測試模式記錄違規情形時，只會將與強制執行模式不同之處記下來。
在模擬測試模式政策檢查的稽核記錄中，metadata.dryRun 欄位值會設為 True。詳情請參閱「稽核記錄內容」。
您也可以建立僅包含模擬測試設定的 perimeter，即可模擬環境中新 enforced perimeter 的影響。
如要評估 service perimeter 的模擬測試設定，請將 service perimeter 設定的 useExplicitDryRunSpec 欄位設為 True。
詳情請參閱「accessPolicies.servicePerimeters」。
政策語意
下一節將說明強制執行模式和模擬測試模式之間的政策關係，以及強制執行作業的解決順序。
唯一成員限制
Google Cloud 專案只能用於一個強制執行設定和一個模擬測試設定，但這兩個設定不一定要對應同一個 perimeter。這樣一來，就能測試在不同 perimeter 中移動專案的影響，不用停用專案現有安全措施。
範例
專案 corp-storage 目前由 perimeter PA 的強制執行設定保護。您想測試將 corp-storage 移至 perimeter PB 的影響。
PA 的模擬測試設定尚未修改，因此會沿用強制執行設定的 corp-storage。
如要測試影響，請先從 PA 的模擬測試設定中移除 corp-storage，然後將專案新增至 PB 的模擬測試設定。
之所以要先移除 corp-storage，是因為專案一次只能用於一個模擬測試設定中。
確認將 corp-storage 從 PA 遷移至 PB 不會造成安全問題後，您決定強制執行變更。
對 PA 和 PB perimeter 強制執行變更有兩種方式：
從 PA 的強制執行設定手動移除
corp-storage，然後將專案新增至 PB 的強制執行設定。corp-storage一次只能用於一個強制執行設定，因此必須依照此順序執行步驟。或者
使用
gcloud指令列工具或 Access Context Manager API，強制執行所有模擬測試設定。這項操作會套用至 perimeter 所有已修改的模擬測試設定，因此請與貴組織中修改了 perimeter 模擬測試設定的其他成員協調。PA 的模擬測試設定已排除corp-storage，因此不需要採取其他步驟。
perimeter 的強制執行設定會先作用
只有在 perimeter 的強制執行設定允許要求，但模擬測試設定拒絕時，才會留下違反模擬測試政策的記錄。如果強制執行設定拒絕要求，但模擬測試設定允許，就不會記錄。
存取層級沒有對應的模擬測試模式
雖然可以為 perimeter 建立模擬測試設定，但存取層級沒有模擬測試設定。因此，如要測試存取層級變更對模擬測試設定的影響，您必須：
建立存取層級，反映要對現有存取層級進行的變更。
將新的存取層級套用至 perimeter 的模擬測試設定。
模擬測試模式不會危害安全性
變更 perimeter 的模擬測試設定，例如在 perimeter 中新增專案或存取層級，或是變更 perimeter 內受保護或網路可存取的服務，都不會影響 perimeter 的實際執行效果。
例如，假設您有一個屬於 service perimeter PA 的專案。如果將該專案新增至另一個 perimeter 的模擬測試設定，專案實際套用的安全措施不會有變動。專案會一如預期，繼續受到 perimeter PA 強制執行設定的保護。
模擬測試動作和設定狀態
使用模擬測試功能時可以：
建立僅包含模擬測試設定的 perimeter
更新現有 perimeter 的模擬測試設定
將新專案移至現有 perimeter
在 perimeter 之間移動專案
刪除 perimeter 的模擬測試設定
根據在模擬測試模式中採取的動作，perimeter 可能處於下列設定狀態：
Inherited from enforced (繼承強制執行的設定)：enforced perimeter 預設狀態。在此狀態下，對 perimeter 強制執行設定所做的任何變更，也會套用至模擬測試設定。
Modified (已修改)：perimeter 的模擬測試設定已經過檢視或變更，然後儲存。在此狀態下，對 perimeter 強制執行設定的變更不會套用至模擬測試設定。
New (新)：perimeter 只有模擬測試設定。即使模擬測試設定有變動，只要 perimeter 沒有強制執行設定，狀態就會一直顯示「New」(新)。
Deleted (已刪除)：perimeter 的模擬測試設定已刪除。在替 perimeter 建立新的模擬測試設定，或復原刪除項目前，這個狀態會維持不變。在此狀態下，對 perimeter 強制執行設定的變更不會套用至模擬測試設定。
模擬測試模式的限制
模擬測試模式僅適用於 perimeter，無法協助您瞭解限制 Google Cloud API 存取受限或私人 VIP 的影響。建議先確認受限 VIP 支援所有要使用的服務，再設定 restricted.googleapis.com 網域。
如果不確定受限 VIP 是否支援現有環境中使用的 API，建議使用私人 VIP。您仍可對支援的服務強制執行 perimeter 安全措施。不過，如果使用私人 VIP，網路中的實體就能存取不安全的服務 (VPC Service Controls 不支援的服務)，例如消費者版 Gmail 和雲端硬碟。這點可能會遭到利用，讓網路中受感染的程式碼、惡意軟體或使用者得以竊取資料。