本主題說明如何為網路情境設定 Identity and Access Management (IAM) 權限。並說明在這些情境中，您應該為公司與網路相關的職務角色授予哪些 IAM 角色。這項內容的主要對象是網路管理員，以及負責管理機構網路工作的員工。以下情境都假設已設定機構。 Google Cloud
本文並未詳細說明網路角色與權限。 如要進一步瞭解與運算及網路 API 相關的角色與權限，請參閱「預先定義的 Compute Engine 身分與存取權管理角色」。
單一團隊管理機構的安全和網路
在本情境中，某大型機構設有一個中央團隊，負責管理整個機構的安全和網路控制。開發人員沒有權限變更由安全及網路團隊定義的任何網路或安全設定，但是他們擁有建立資源 (例如共用子網路中的虛擬機器) 的權限。
為了促進作業，機構採用了共用 VPC (虛擬私人雲端)。共用 VPC 可建立 RFC 1918 IP 空間的 VPC 網路，供相關聯的專案 (服務專案) 使用。運用相關聯專案的開發人員就能在共用 VPC 網路空間中建立 VM 執行個體。機構的網路及安全管理員則可建立子網路、VPN 和防火牆規則，提供 VPC 網路中的所有專案使用。
下表說明需要授予安全與管理團隊和開發團隊的 IAM 角色，以及授予角色的資源層級。
| 資源： | 機構 | |
|---|---|---|
| 角色： | 共用 VPC 管理員 網路管理員 安全管理員 |
|
| 主體： | 安全與網路管理團隊 |
| 資源： | 託管專案 | 這個角色授予權限以使用共用 VPC 的共用子網路。 |
|---|---|---|
| 角色： | 網路使用者 | |
| 主體： | 開發人員 |
| 資源： | 服務專案 | 請注意，這個角色授予使用外部 IP 位址的權限。如需如何避免這項動作的指引，請參閱下方附註。 |
|---|---|---|
| 角色： | compute.instanceAdmin | |
| 主體： | 開發人員 |
在本情境中，您需要三項獨立的允許政策：一項適用於機構，一項適用於主專案，一項適用於服務專案。
第一個允許政策必須在機構層級附加，以向網路與安全團隊授予管理共用 VPC 託管專案所需的角色。這包含了將服務專案與託管專案建立關聯的功能。此外，也可讓網路與安全團隊管理機構內所有專案的網路與安全資源。
{
"bindings": [
{
"role": "roles/compute.xpnAdmin",
"members": [
"group:sec-net@example.com"
]
},
{
"role":"roles/compute.networkAdmin",
"members": [
"group:sec-net@example.com"
]
},
{
"role": "roles/compute.securityAdmin",
"members": [
"group:sec-net@example.com"
]
}
]
}
第二個允許政策必須與主專案建立關聯，並授權機構中的開發人員使用共用虛擬私有雲主專案中的共用網路。
{
"bindings": [
{
"role": "roles/compute.networkUser",
"members": [
"group:developers@example.com"
]
}
]
}
第三項允許政策必須與每個服務專案建立關聯。這讓開發人員運用專案來管理服務專案中的執行個體，並可操作託管專案內的共用子網路。
您可以將所有服務專案放在資料夾中，並在該階層層級設定這項特定的允許政策。這樣一來，在該資料夾中建立的所有專案，都會沿用在建立服務專案的資料夾中設定的權限。
您還需要向開發人員授予服務專案中的網路使用者角色。
{
"bindings": [
{
"role": "roles/compute.networkUser",
"members": [
"group:developers@example.com"
]
},
{
"role": "roles/compute.instanceAdmin",
"members": [
"group:developers@example.com"
]
}
]
}
使用群組管理主體是最佳做法。在上述範例中，您會將管理安全性與網路控制項的使用者 ID 新增至 sec-net 群組，並將開發人員新增至 developers 群組。如要修改可執行這項功能的使用者，只要調整群組成員資格即可，無須更新允許政策。
獨立的網路和安全團隊
在本情境中，某大型機構設有兩個中央團隊：一個團隊負責管理安全控制；另一個團隊管理整個機構的所有其他網路資源。開發人員沒有權限變更由安全及網路團隊定義的任何網路或安全設定，但是他們擁有建立資源 (例如共用子網路中的虛擬機器) 的權限。
與第一個情境相同，您會使用共用 VPC，並為網路、安全和開發人員這三個群組設定適當的權限。
下表說明需要授予安全與管理團隊和開發團隊的 IAM 角色，以及授予角色的資源層級。
| 資源： | 機構 | |
|---|---|---|
| 角色： | 共用虛擬私有雲管理員 網路管理員 |
|
| 主體： | 網路管理團隊 |
| 資源： | 機構 | |
|---|---|---|
| 角色： | 安全管理員 機構管理員 |
|
| 主體： | 安全團隊 |
| 資源： | 託管專案 | 這個角色授予權限以使用共用 VPC 的共用子網路。 |
|---|---|---|
| 角色： | 網路使用者 | |
| 主體： | 開發人員 |
| 資源： | 服務專案 | 請注意，這個角色授予使用外部 IP 位址的權限。如需如何避免這項動作的指引，請參閱下方附註。 |
|---|---|---|
| 角色： | compute.instanceAdmin | |
| 主體： | 開發人員 |
在本情境中，您需要三項獨立的允許政策：一項適用於機構，一項適用於主專案，一項適用於服務專案。
第一個允許政策必須在機構層級附加，以向網路團隊授予管理共用虛擬私有雲主專案和所有網路資源所需的角色。包括將服務專案與主專案建立關聯。網路管理員角色也可讓網路團隊查看防火牆規則，但是無法加以修改。這個角色還能讓安全團隊在機構的所有專案中，設定允許政策及管理防火牆規則與 SSL 憑證。
{
"bindings": [
{
"role": "roles/compute.xpnAdmin",
"members": [
"group:networks@example.com"
]
},
{
"role": "roles/compute.networkAdmin",
"members": [
"group:networks@example.com"
]
},
{
"role": "roles/compute.securityAdmin",
"members": [
"group:security@example.com"
]
},
{
"role": "roles/resourcemanager.organizationAdmin",
"members": [
"group:security@example.com"
]
}
]
}
第二個允許政策必須與主專案建立關聯。這項允許政策可讓機構中的開發人員使用共用虛擬私有雲主專案中的共用網路。
{
"bindings": [
{
"role": "roles/compute.networkUser",
"members": [
"group:developers@example.com"
]
}
]
}
第三項允許政策必須與每個服務專案建立關聯。這讓開發人員運用專案來管理服務專案中的執行個體，並可操作託管專案內的共用子網路。
您可以將所有服務專案放在資料夾中，並在該階層層級設定這項特定的允許政策。這樣一來，在該資料夾中建立的所有專案，都會沿用在建立服務專案的資料夾中設定的權限。
{
"bindings": [
{
"role": "roles/compute.networkUser",
"members": [
"group:developers@example.com"
]
},
{
"role": "roles/compute.instanceAdmin",
"members": [
"group:developers@example.com"
]
}
]
}
每個團隊都可以管理自己的網路
數位原生公司希望開發團隊具備自主工作能力。這些工作者並未籌組中央 IT 管理團隊，而是信任自己的團隊可以全方位地管理所屬專案。
儘管如此，他們同樣希望能夠實施一些寬鬆的控制措施，以在團隊發展和產品正式發行的過程中採用較為正式的設定。
如要實作這種情境，每個開發團隊都會分配到自己的資料夾。這個結構可確保資料夾中建立的個別專案會繼承適當權限，同時允許各團隊獨立作業。各團隊為自家資源設定允許政策時，仍應遵循最低權限原則。
即使最初是相同的團隊成員管理專案中的網路資源和實際資源，針對邏輯職責分別建立群組也是最佳做法。
本方法有助於限制以下兩種員工對資源的存取權限：需要這些資源的臨時員工，或是必須事先訓練才能修改網路資源的新進員工。此外，您也可以變更資源的存取權，不必在每次人事異動時修改允許政策。
| 資源： | 資料夾 | 服務帳戶可用於建立及擁有專案。 |
|---|---|---|
| 角色： | 專案建立者 資料夾管理員 |
|
| 主體： | 開發團隊主管 服務帳戶 |
| 資源： | 資料夾 | |
|---|---|---|
| 角色： | 網路管理員 安全性管理員 |
|
| 主體： | 網路與安全團隊 |
| 資源： | 資料夾 | 這些角色可讓開發人員全面管理 BigQuery 和 Compute Engine。 |
|---|---|---|
| 角色： | 執行個體管理員 BigQuery 管理員 |
|
| 主體： | 開發人員 |
這需要在每個團隊已分配的資料夾中繫結允許政策。
{
"bindings": [
{
"role": "roles/resourcemanager.foldersAdmin",
"members": [
"group:devteamleads01@example.com",
"serviceAccount:dev01-project-creator@shared-resources-proj.iam.gserviceaccount.com"
]
},
{
"role":"roles/resourcemanager.projectCreator",
"members": [
"group:devteamleads01@example.com",
"serviceAccount:dev01-project-creator@shared-resources-proj.iam.gserviceaccount.com"
]
},
{
"role": "roles/compute.securityAdmin",
"members": [
"group:net-sec-dev01@example.com"
]
},
{
"role": "roles/compute.networkAdmin",
"members": [
"group:net-sec-dev01@example.com"
]
},
{
"role": "roles/compute.instanceAdmin",
"members": [
"group:dev01@example.com"
]
},
{
"role": "roles/bigquery.admin",
"members": [
"group:dev01@example.com"
]
}
]
}