本文介紹最佳做法，協助您決定要使用多少個 Cloud Identity 或 Google Workspace 帳戶、機構和帳單帳戶。 Google Cloud 這份文件提供相關指引，協助您找出符合安全性與機構需求的設計。
在 Google Cloud中，身分與存取權管理以兩大支柱為基礎：
Cloud Identity 和 Google Workspace 帳戶是使用者和群組的容器。因此，這些帳戶是驗證公司使用者身分，以及管理Google Cloud 資源存取權的重要工具。Cloud Identity 或 Google Workspace 帳戶代表使用者目錄，而非個別使用者帳戶。個別使用者帳戶稱為「使用者」或「使用者帳戶」。
機構是 Google Cloud內專案和資源的容器。機構可讓資源以階層方式架構，是集中且有效管理資源的關鍵。
本文主要適用於設定企業環境的客戶。
Cloud Identity 和 Google Workspace 帳戶
Google Workspace 是一套整合式雲端原生協作和生產力應用程式。包括可管理使用者、群組和驗證的工具。
Cloud Identity 提供部分 Google Workspace 功能。與 Google Workspace 相同，Cloud Identity 可讓您管理使用者、群組和驗證，但不包含 Google Workspace 的所有協作和生產力功能。
Cloud Identity 和 Google Workspace 共用技術平台，並使用同一組 API 和管理工具。這些產品都採用帳戶的概念，將使用者和群組視為容器。這個容器是以網域名稱 (例如 example.com) 識別。就管理使用者、群組和驗證而言，這兩項產品可視為同等。
在單一帳戶中合併 Cloud Identity 和 Google Workspace
由於 Cloud Identity 和 Google Workspace 共用平台，您可以在單一帳戶中同時存取這兩項產品。
如果您已管理 Google Workspace 帳戶，並想讓更多使用者使用 Google Cloud，可能不想為所有使用者指派 Google Workspace 授權。在這種情況下，請為現有帳戶新增 Cloud Identity Free。這樣一來，您就能讓更多使用者加入，不必支付額外費用，並透過指派 Google Workspace 授權，決定哪些使用者應有權存取 Google Workspace。
同樣地，如果您已管理 Cloud Identity 免費或進階版帳戶，可能想授予特定使用者使用 Google Workspace 的權利。您不必為這些使用者建立個別的 Google Workspace 帳戶，而是可以在現有的 Cloud Identity 帳戶中新增 Google Workspace。為所選使用者指派 Google Workspace 授權後，他們就能使用生產力和協作應用程式。
盡量減少帳戶數量，但仍須滿足需求
如要讓使用者透過 Google Workspace 協作，並盡量減少管理負擔，建議您透過單一 Cloud Identity 或 Google Workspace 帳戶管理所有使用者，並為每位使用者提供單一使用者帳戶。這種做法有助於確保所有使用者都適用相同的設定，例如密碼政策、單一登入和兩步驟驗證。
雖然使用單一 Cloud Identity 或 Google Workspace 帳戶有上述優點，但使用多個帳戶可享有彈性，並獲得管理自主權。決定要使用多少個 Cloud Identity 或 Google Workspace 帳戶時，請考量所有建議使用多個帳戶的需求。然後使用最少數量的 Cloud Identity 或 Google Workspace 帳戶，滿足您的需求。
為測試和正式環境使用不同帳戶
在 Cloud Identity 和 Google Workspace 中設定大多數設定時，您可以選擇各項設定的適用範圍，例如依使用者、群組或機構單位指定資料的地理位置。如果您打算套用新設定，可以先選擇小範圍 (例如依使用者)，然後確認設定是否符合預期。確認設定無誤後，您就可以將相同設定套用至更多群組或機構單位。
與大多數設定不同，將 Cloud Identity 或 Google Workspace 帳戶與外部身分識別提供者 (IdP) 整合，會對全域造成影響：
- 啟用單一登入是全域設定，適用於超級管理員以外的所有使用者。
- 視外部 IdP 而定，設定使用者佈建功能也可能對全域造成影響。外部 IdP 的設定錯誤可能會導致使用者遭到修改、停權或刪除。
為降低這些風險，請使用不同的 Cloud Identity 或 Google Workspace 帳戶進行測試和正式發布：
- 使用測試帳戶驗證任何有風險的設定變更，再將相同變更套用至正式版帳戶。
- 在預先發布帳戶中建立幾個測試使用者，您和其他管理員可以透過這些使用者驗證設定變更。但請勿授予使用者存取預先發布帳戶的權限。
如果外部 IdP 有個別的暫存和正式版執行個體，請按照下列步驟操作：
- 將 Cloud Identity 或 Google Workspace 測試帳戶與測試 IdP 執行個體整合。
- 將正式版 Cloud Identity 或 Google Workspace 帳戶與正式版 IdP 執行個體整合。
舉例來說，假設您打算設定與 Active Directory 的同盟，並為了測試目的而使用個別的 Active Directory 樹系。在這種情況下，您需要將測試 Cloud Identity 或 Google Workspace 帳戶與測試樹系整合，並將正式 Cloud Identity 或 Google Workspace 帳戶與主要樹系整合。針對兩個樹系/帳戶組合，對 DNS 網域、使用者和群組套用相同的對應方法，如下圖所示：
您的正式版和測試版 Active Directory 樹系和網域可能使用 DNS 網域，因此您無法對測試版和正式版套用相同的網域對應方法。在這種情況下，建議您在暫存樹系中註冊更多使用者主要名稱 (UPN) 後置字串網域。
同樣地，如果您打算與 Azure Active Directory 建立聯盟關係，建議採取下列做法：
- 將暫存 Cloud Identity 或 Google Workspace 帳戶與暫存 Azure Active Directory 租戶整合。
- 將正式版 Cloud Identity 或 Google Workspace 帳戶與主要 Azure Active Directory 租戶整合。
對兩個房客/帳戶組合套用相同的對應方法，以對應 DNS 網域、使用者和群組：
您的正式版和預先發布版 Azure Active Directory 租戶可能使用 DNS 網域，因此您無法對預先發布版和正式版套用相同的網域對應方法。在這種情況下，請考慮在預先發布的租戶中新增額外網域。
在 Cloud Identity 和 Google Workspace 帳戶之間使用不相交的 DNS 網域
首次將網域 (例如 example.com) 新增至 Cloud Identity 或 Google Workspace 帳戶時，您需要驗證網域擁有權。新增並驗證網域後，即可新增子網域 (例如 marketing.example.com 和 finance.example.com)，不必逐一驗證。
不過，如果您新增子網域時未逐一驗證，且另一個 Cloud Identity 或 Google Workspace 帳戶已使用該子網域，就可能發生衝突。為避免這類衝突，建議為每個帳戶使用不相交的網域。舉例來說，如果您需要兩個 Cloud Identity 或 Google Workspace 帳戶，請盡量避免使用兩個網域，其中一個網域是另一個網域的子網域。請改用兩個不屬於其他網域子網域的網域。這項做法適用於主網域和次要網域。
不要拆分 Google Workspace 和 Google Cloud
如果您已使用 Google Workspace，Google Workspace 帳戶中的部分使用者可能已獲授超級管理員權限，可執行管理工作。
系統會隱含授予具備超級管理員權限的使用者，修改機構節點身分與存取權管理 (IAM) 政策的權限。有了這項權限，超級管理員就能為自己指派機構管理員角色，或 Google Cloud 機構中的任何其他角色。如果使用者擁有 Cloud Identity 或 Google Workspace 帳戶的超級管理員存取權，就能刪除該帳戶、相關聯的機構，以及所有資源。 Google Cloud因此，您必須假設超級管理員有權存取機構中的所有資源。
如果現有的 Google Workspace 管理員與負責管理Google Cloud 機構的使用者不同，超級管理員同時也是機構管理員，可能會造成安全疑慮。在這種情況下，您可能會決定建立專用的 Cloud Identity 帳戶，以限制 Google Workspace 超級管理員對資源的存取權。 Google CloudGoogle Cloud 分開使用 Google Workspace 和Google Cloud 可能會導致多項意想不到的後果。
舉例來說，您可以在 Cloud Identity 帳戶中建立個別使用者，然後限制機構使用者存取 Cloud Identity 帳戶。 Google Cloud 這樣可確保部署作業和 Google Workspace 完全隔離。 Google Cloud 不過，重複建立使用者會對使用者體驗和管理負擔造成負面影響。此外，您也無法接收 Google Cloud傳送的任何通知電子郵件，因為 Cloud Identity 使用的網域必須與 Google Workspace 使用的網域不同，因此不適合用於轉送電子郵件。
如果您改為參照貴機構 Google Workspace 帳戶中的使用者，就會破壞 Google Workspace 與 Google Cloud之間的隔離：Google Cloud
Google Workspace 超級管理員可以使用網域範圍的委派，模擬同一 Google Workspace 帳戶中的任何使用者。惡意超級管理員可能會利用提升的權限，重新取得Google Cloud的存取權。
與其使用不同的帳戶，更有效的方法是區分 Google Workspace 和管理員之間的責任，以減少超級管理員人數： Google Cloud
在 Google Workspace 中，大多數管理工作都不需要超級管理員權限。使用預先建立的管理員角色或自訂管理員角色，取代超級管理員權限，授予 Google Workspace 管理員執行職務所需的權限。
只保留最少數量的超級管理員使用者，並避免日常使用。
善用稽核功能，偵測管理員使用者是否有可疑活動。
使用單一登入時保護外部 IdP
您可以使用 Cloud Identity 和 Google Workspace，透過 Active Directory、Azure Active Directory 或 Okta 等外部 IdP 設定單一登入。啟用單一登入後，Cloud Identity 和 Google Workspace 會信任外部 IdP，由該服務代表 Google 驗證使用者。
啟用單一登入功能有以下優點：
- 使用者可以透過現有憑證登入 Google 服務。
- 如果使用者已有現有的登入工作階段，就不必再次輸入密碼。
- 您可以在應用程式和所有 Google 服務中套用一致的多重驗證政策。
但啟用單一登入功能也會帶來風險。啟用單一登入後，如果使用者需要通過驗證，Cloud Identity 或 Google Workspace 會將使用者重新導向至外部 IdP。驗證使用者後，IdP 會將聲明使用者身分的 SAML 聲明傳回給 Google。SAML 聲明已簽署。因此，Google 可以驗證 SAML 聲明的真實性，並確認使用的識別資訊提供者正確無誤。不過，Cloud Identity 或 Google Workspace 無法驗證 IdP 是否做出正確的驗證決策，以及是否正確聲明使用者身分。
如果啟用單一登入，Google 部署作業的整體安全性和完整性，就會取決於 IdP 的安全性和完整性。如果下列任一項目設定不安全，您的 Cloud Identity 或 Google Workspace 帳戶，以及所有依賴該帳戶管理使用者的資源，都會面臨風險：
- IdP 本身
- 供應商執行的機器
- 供應商從中取得使用者資訊的使用者資料庫
- 供應商依賴的任何其他系統
為避免單一登入成為安全防護的弱點，請確保 IdP 和所有相關系統都已安全設定：
- 限制具有 IdP 管理員存取權的使用者人數，或限制存取供應商所依賴的任何系統。
- 請勿授予任何使用者這些系統的管理存取權，否則您也必須在 Cloud Identity 或 Google Workspace 中授予超級管理員權限。
- 如果您不確定外部 IdP 的安全控管措施，請勿使用單一登入。
安全存取 DNS 區域
Cloud Identity 和 Google Workspace 帳戶是透過主要 DNS 網域名稱識別。建立新的 Cloud Identity 或 Google Workspace 帳戶時，您必須在對應的 DNS 區域中建立特殊的 DNS 記錄，藉此驗證 DNS 網域的擁有權。
DNS 的重要性及其對 Google 部署作業整體安全性的影響，不僅限於註冊程序：
Google Workspace 依賴 DNS MX 記錄轉送電子郵件。如果攻擊者修改這些 MX 記錄，可能會將電子郵件轉送至其他伺服器，並存取機密資訊。
如果攻擊者能夠在 DNS 區域中新增記錄，他們可能就能重設超級管理員使用者的密碼，並取得帳戶存取權。
為避免 DNS 成為安全防護的弱點，請確保 DNS 伺服器已安全設定：
限制可存取 DNS 伺服器的使用者人數，該伺服器用於管理 Cloud Identity 或 Google Workspace 的主網域。
請勿將 DNS 伺服器的管理存取權授予任何使用者，除非您也願意在 Cloud Identity 或 Google Workspace 中授予超級管理員權限。
如果您打算在 Google Cloud 部署工作負載，但現有的 DNS 基礎架構無法滿足安全性需求，請考慮為該工作負載註冊新的 DNS 網域，並使用個別的 DNS 伺服器或代管 DNS 服務。
將稽核記錄匯出至 BigQuery
Cloud Identity 和 Google Workspace 會維護多個稽核記錄，追蹤設定變更和其他可能與 Cloud Identity 或 Google Workspace 帳戶安全相關的活動。下表摘要說明這些稽核記錄。
| 記錄 | 擷取的活動 |
|---|---|
| 管理員 | 在 Google 管理控制台中執行的動作 |
| 登入 | 網域中成功、失敗和可疑的登入嘗試 |
| 權杖 | 授權或撤銷第三方行動或網頁應用程式存取權的例項 |
| 群組 | 群組和群組成員資格的異動 |
您可以透過管理控制台或 Reports API 存取這些稽核記錄。大多數稽核記錄的資料會保留 6 個月。
如果您在受監管產業中營運，保留稽核資料 6 個月可能不夠。如要保留資料更長時間，請設定將稽核記錄匯出至 BigQuery。
為降低未經授權存取匯出稽核記錄的風險，請為 BigQuery 資料集使用專屬 Google Cloud 專案。為防止稽核資料遭到竄改或刪除，請根據最低權限原則授予專案和資料集存取權。
Cloud Identity 和 Google Workspace 稽核記錄是 Cloud Audit Logs 記錄的補充資訊。如果您也使用 BigQuery 收集 Cloud 稽核記錄和其他應用程式專屬稽核記錄，就能將登入事件與使用者在 Google Cloud 或應用程式中執行的活動建立關聯。關聯多個來源的稽核資料，有助於偵測及分析可疑活動。
設定 BigQuery 匯出作業需要 Google Workspace Enterprise 授權。設定主要稽核記錄後，系統會為所有使用者匯出記錄，包括沒有 Google Workspace 授權的使用者。如果使用者具備 Google Workspace Business 授權，系統會匯出特定記錄，例如雲端硬碟和行動裝置稽核記錄。
如果大部分使用者都使用 Cloud Identity Free，您還是可以匯出至 BigQuery，方法是在現有 Cloud Identity 帳戶中新增 Google Workspace Enterprise，並為選定的一組管理員購買 Google Workspace 授權。
組織
機構可讓您將資源整理到專案和資料夾的階層中，機構節點則是根節點。機構會與 Cloud Identity 或 Google Workspace 帳戶建立關聯，並從相關聯帳戶的主網域名稱衍生出機構名稱。當 Cloud Identity 或 Google Workspace 帳戶的使用者建立第一個專案時，系統會自動建立機構。
每個 Cloud Identity 或 Google Workspace 帳戶只能有一個機構。事實上，您必須先建立帳戶，才能建立機構。雖然有這項依附關係，您還是可以授予使用者存取單一機構中資源的權限，方法如下：
您可以彈性參照不同 Cloud Identity 或 Google Workspace 帳戶的使用者，區分帳戶和機構的處理方式。您可以分開決定要管理使用者需要多少個 Cloud Identity 或 Google Workspace 帳戶，以及要管理資源需要多少個機構。
您建立的機構數量及其用途，可能會對安全狀態、團隊和部門的自主性，以及管理作業的一致性和效率造成深遠影響。
下列各節將說明決定要使用多少個機構的最佳做法。
盡量減少機構數量，但仍須滿足需求
機構的資源階層可讓您善用繼承功能，減少管理 IAM 政策和機構政策的工作量。在資料夾或機構層級設定政策，可確保政策一致套用至資源的子階層，並避免重複設定。為盡量減少管理負擔，最好盡量減少使用機構。
相較之下，使用多個機構可獲得額外的彈性和管理自主權。以下各節說明您可能需要這類額外彈性或自主性的情況。
無論如何，決定要使用多少個機構時，請考量所有建議使用多個機構的需求。然後使用最少數量的機構，滿足您的需求。
使用機構劃分管理授權
在資源階層中，您可以在資源、專案或資料夾層級授予權限。您可以授予使用者權限的最高層級是機構。
在機構層級獲派機構管理員角色的使用者，可以完全掌控機構、機構資源和 IAM 政策。機構管理員可以控管機構內的任何資源，並將管理員存取權委派給任何其他使用者。
不過，機構管理員的權限僅限於機構，因此機構是管理權限的最終範圍：
- 除非明確授予權限，否則機構管理員無法存取其他機構的任何資源。
- 機構外部使用者無法奪取該機構的機構管理員控制權。
要使用的機構數量取決於貴公司的獨立管理員使用者群組數量：
- 如果貴公司是依職能劃分，可能會有單一部門負責監督所有部署作業。 Google Cloud
- 如果貴公司是依部門劃分，或擁有許多自主經營的子公司，可能就沒有單一部門負責。
如果單一部門負責監督部署作業，建議使用單一機構節點。 Google CloudGoogle Cloud 在機構內，您可以使用資料夾架構資源，並授予其他團隊和部門不同層級的存取權。
如果您要處理多個獨立部門，嘗試使用單一機構集中管理可能會造成摩擦：
- 如果指派單一部門管理機構，其他部門可能會反對。
- 如果允許多個團隊或部門共同擁有單一機構，可能難以維持一致的資源階層，也難以確保資源一致使用 IAM 政策和機構政策。
為避免這類摩擦，請使用多個機構，並在每個機構中建立個別的資料夾結構。使用不同的機構可劃分不同管理員使用者群組的界線，藉此劃定管理權限。
使用獨立的預先發布機構
為確保一致性並避免重複設定，請將專案整理成資料夾階層，並在資料夾或機構層級套用 IAM 政策和機構政策。
如果政策適用於多個專案和資源，可能會造成負面影響。變更政策本身或政策適用的資源階層，可能會導致影響深遠的非預期後果。為降低這項風險，建議您先測試政策變更，再套用至主要機構。
建議您建立獨立的測試機構。這個機構可協助您測試資源階層變更、IAM 政策、機構政策或其他可能影響整個機構的設定，例如存取層級和政策。
為確保在預先發布機構中進行的測試或實驗結果也適用於正式版機構，請將預先發布機構設定為與主要機構使用相同的資料夾結構，但只包含少數專案。在任何時間點，預先發布機構中的 IAM 和機構政策，都應與實際工作機構的政策相符，或是反映您打算套用至實際工作機構的下一個政策版本。
如下圖所示，您可以使用暫存 Cloud Identity 或 Google Workspace 帳戶做為暫存機構的基礎。您可以使用暫存帳戶 (或與暫存帳戶整合的外部 IdP)，建立專屬測試使用者和群組結構，並將其鏡像到正式版 Cloud Identity 或 Google Workspace 帳戶中使用的群組。接著，您可以使用這些專屬測試使用者和群組測試 IAM 政策，而不影響現有使用者。
避免使用獨立的測試機構
您可能需要一或多個測試環境，供開發和 DevOps 團隊驗證新版本，以便在 Google Cloud上部署每個實際工作負載。
從安全性的角度來看，為避免未經測試的版本意外影響實際工作環境工作負載，您需要將測試環境與實際工作環境徹底分開。同樣地，這兩種環境對 IAM 政策的要求也不同。舉例來說，為了讓開發人員和測試人員享有充分彈性，測試環境的安全規定可能比正式環境寬鬆許多。
如下圖所示，從設定的角度來看，您希望測試環境盡可能與實際工作環境相似。任何差異都會增加風險，導致在測試環境中正常運作的部署作業，部署到實際工作環境時會失敗。
如要兼顧環境隔離和一致性，請在同一機構內使用資料夾管理測試和實際工作環境：
- 在機構層級 (或使用通用父項資料夾)，套用環境通用的任何 IAM 政策或機構政策。
- 使用個別資料夾管理不同環境類型之間的 IAM 政策和機構政策。
請勿使用「預先發布機構」管理測試環境。測試環境對開發和開發運作團隊的生產力至關重要。在測試環境中管理這類環境，會限制您使用測試機構進行實驗和測試政策變更的能力，因為任何這類變更都可能中斷這些團隊的工作。簡而言之，如果您使用暫存機構管理測試環境，就會破壞暫存機構的用途。
使用獨立機構進行實驗
如要充分發揮 Google Cloud的價值，請讓開發、開發運作和營運團隊熟悉這個平台，並執行教學課程，擴展使用經驗。鼓勵他們嘗試新功能和服務。
請使用獨立機構做為沙箱環境，支援這類實驗活動。使用獨立機構可確保實驗不受任何政策、設定或自動化作業影響，這些項目是您在正式機構中使用的。
請避免使用測試機構進行實驗。預先發布環境應使用與實際工作機構類似的 IAM 和機構政策。因此，測試環境可能與正式環境受到相同的限制。但放寬政策以允許實驗，會破壞預先發布機構的宗旨。
為避免實驗性機構變得雜亂無章、產生過多費用或造成安全風險，請發布指南，定義團隊使用機構的方式，以及負責維護機構的人員。此外，您也可以考慮設定自動化功能，在特定天數後自動刪除資源，甚至是整個專案。
如下圖所示，建立機構進行實驗時，您首先要建立專屬的 Cloud Identity 帳戶。然後使用主要 Cloud Identity 或 Google Workspace 帳戶中的現有使用者，授予使用者存取實驗性機構的權限。
如要管理額外的 Cloud Identity 帳戶，您必須在 Cloud Identity 帳戶中擁有至少一個超級管理員使用者帳戶。如要瞭解如何保護這些超級管理員使用者帳戶，請參閱超級管理員帳戶最佳做法。
使用網域限制共用功能，強制執行信任關係
您可以使用 IAM 政策，將任何有效的 Google 身分新增為成員。也就是說，當您編輯資源、專案、資料夾或機構的身分與存取權管理政策時，可以從不同來源新增成員，包括：
- 與機構相關聯的 Cloud Identity 或 Google Workspace 帳戶使用者，以及來自同一機構的服務帳戶
- 其他 Cloud Identity 或 Google Workspace 帳戶的使用者
- 其他機構的服務帳戶
- 消費者使用者帳戶，包括
gmail.com使用者和使用公司電子郵件地址的消費者帳戶
如果需要與聯盟或其他公司合作，能夠參照不同來源的使用者會很有幫助。在其他大多數情況下，最好限制 IAM 政策，只允許來自信任來源的成員。
使用網域限制共用，定義一組受信任的 Cloud Identity 或 Google Workspace 帳戶，允許成員從這些帳戶新增至 IAM 政策。您可以在機構層級定義這項機構政策 (適用於所有專案)，也可以在資源階層頂端附近的資料夾定義這項政策 (允許特定專案獲得豁免)。
如果您使用不同的 Cloud Identity 或 Google Workspace 帳戶和機構，來區隔暫存、正式和實驗環境，請使用網域限制共用政策，強制執行下列表格所列的區隔：
| 機構 | 受信任的 Cloud Identity 或 Google Workspace 帳戶 |
|---|---|
| 預備 | 預備 |
| 生產 | 生產 |
| 實驗 | 生產 |
為機構使用中性網域名稱
機構的識別依據為 DNS 網域名稱，例如 example.com。網域名稱是從相關聯的 Cloud Identity 或 Google Workspace 帳戶主網域名稱衍生而來。
如果公司使用標準 DNS 網域名稱，請將該網域設為正式版 Cloud Identity 或 Google Workspace 帳戶的主網域。使用標準 DNS 名稱可確保員工能輕鬆辨識機構節點的名稱。
如果貴公司有多個子公司或擁有各種不同品牌，可能沒有標準網域名稱。請勿隨意挑選現有網域，建議註冊新的 DNS 網域，專供 Google Cloud使用。使用中性 DNS 名稱可避免偏好公司內的特定品牌、子公司或部門，這可能會對雲端採用造成負面影響。將其他品牌專屬網域新增為次要網域，以便用於使用者 ID 和單一登入。
跨機構使用帳單帳戶 Google Cloud
帳單帳戶會定義特定資源組合的費用由誰支付 Google Cloud 。雖然帳單帳戶可以存在於機構外部，但通常會與機構相關聯。 Google Cloud
帳單帳戶與機構建立關聯後，會視為機構的子資源，並受機構內定義的 IAM 政策約束。最重要的是，這表示您可以使用帳單 IAM 角色，定義哪些使用者或群組可以管理或使用帳戶。
獲得 Billing Account User 角色的使用者可以將專案連結至帳單帳戶，讓資源費用計入該帳戶。專案可以連結至同一個機構的帳單帳戶，也可以連結至其他機構的帳單帳戶。
如果您使用多個機構，可以善用帳單帳戶可跨機構使用的優點。您可以決定需要多少個帳單帳戶，而不受機構數量限制。
帳單帳戶的正確數量完全取決於您的商業或合約需求，例如幣別、付款資料，以及您需要的個別月結單數量。如同帳戶和機構，為了盡量減少複雜度，您應使用最少數量的帳單帳戶，以滿足需求。
如要細分多個機構累積的費用，請將帳單帳戶設定為將帳單資料匯出至 BigQuery。匯出至 BigQuery 的每筆記錄不僅包含專案名稱和 ID，也包含專案所屬機構的 ID (位於 project.ancestry_numbers 欄位)。
後續步驟
- 建立新的 Cloud Identity 帳戶
- 瞭解如何使用 Google Cloud 在混合環境中驗證企業使用者，以及常見模式。
- 請參閱連結外部身分識別提供者的最佳做法 Google Cloud 。
- 瞭解如何連結 Google Cloud Active Directory 或 Azure Active Directory。