本文說明建議的 VPC Service Controls 部署架構。本文適用於網路管理員、安全架構師和雲端營運專業人員，他們在 Trusted Cloud by S3NS 上執行及運作大規模的正式版部署作業，並希望降低敏感資料遺失的風險。
由於 VPC Service Controls 保護機制會影響雲端服務功能，建議您事先規劃啟用 VPC Service Controls，並在架構設計期間考量 VPC Service Controls。請務必盡可能簡化 VPC Service Controls 設計。建議您避免使用多個重疊範圍、安全範圍網路專案或非軍事區安全範圍，以及複雜存取層級的安全範圍設計。
使用常見的統一週邊
相較於使用多個區隔的周邊，單一大型周邊 (稱為通用統一週邊) 可提供最有效的資料外洩防護。
此外，統一的常見安全防護範圍可降低管理負擔，有助於負責建立及維護安全防護範圍的團隊。由於範圍內的服務和網路資源可自由通訊，並具備必要的 IAM 和網路控制項權限，因此負責範圍管理的團隊主要會關注南北向存取，也就是從網際網路存取範圍內資源的行為。
如果機構使用多個較小的邊界，邊界管理團隊除了要管理來自機構外部的南北向流量，還必須投入資源管理機構邊界之間的東西向流量。視機構規模和周邊範圍數量而定，這項額外負擔可能相當可觀。建議您在服務範圍中加入額外的安全控管措施和最佳做法，例如確保虛擬私有雲網路中的資源不會直接連出網際網路。
服務範圍並非用來取代或減少 IAM 控制項的需求。定義存取控制項時，建議您確保遵循最低權限原則，並套用 IAM 最佳做法。
詳情請參閱「建立服務安全防護範圍」。
在單一機構中使用多個安全範圍
某些用途可能需要為機構設定多個安全防護範圍。舉例來說，處理醫療照護資料的機構可能需要一個高信任度、未經過模糊處理的資料周邊，以及另一個低階、去識別化資料周邊，方便與外部實體共用資料，同時保護高信任度資料。
如果貴機構想遵守 PCI DSS 等標準，可能需要為受監管資料建立獨立的周邊防護。
如果貴機構的主要用途是資料共用，建議使用多個周邊。如果您產生並分享較低層級的資料 (例如去識別化的病患健康資料)，可以使用獨立的周邊設備，方便與外部實體共用資料。詳情請參閱安全資料交換的參考模式。
此外，如果您使用機構來代管獨立的第三方租戶 (例如合作夥伴或客戶)，請考慮為每個租戶定義周邊範圍。 Trusted Cloud by S3NS 如果您認為從這些租戶之一到另一個租戶的資料移動是外洩行為，建議您實作個別的周邊防禦措施。
perimeter 設計
建議您在建立範圍時啟用所有受保護的服務，這有助於降低作業複雜度，並盡量減少潛在的外洩向量。因為未受保護的 API 會增加可能的資料外洩途徑，如果貴機構選擇保護某個 API 而不是另一個，就應進行審查並提出理由。
所有新專案都應通過以下章節所述的審查和資格程序。將所有符合資格條件的專案納入範圍。
確認周邊任何虛擬私有雲都沒有通往私人 VIP 的路徑。如果您允許網路路徑連往 private.googleapis.com，VPC Service Controls 就無法防範內部人員竊取資料。如必須允許存取不支援的服務，請嘗試將不支援的服務使用作業隔離到個別專案，或將整個工作負載移出範圍。
查看及評估專案
一般企業有許多專案，代表工作負載和高階建構，例如控制平面、資料湖泊、業務單位和生命週期階段。除了將這些專案和元件整理到資料夾中，我們建議您將這些專案和元件歸類為位於虛擬私有雲服務範圍內或外。如要進行資格評估，請思考以下問題：
是否有元件硬性依附於VPC Service Controls 不支援的服務？
VPC Service Controls 的強制執行方式明確，因此這類依附元件可能無法在範圍內運作。建議您修改工作負載，將不支援服務的需求隔離到個別專案，或將工作負載完全移出範圍。
是否有不含機密資料，且不會取用其他專案機密資料的元件？
如果上述任何問題的答案為「是」，建議您不要將專案納入範圍。如「允許清單設計」主題所述，您可以解決這個問題。不過，我們建議您盡量簡化周邊裝置。