このトピックでは、ネットワーク シナリオ用の Identity and Access Management(IAM)権限を構成する方法について説明します。シナリオに応じて企業内のネットワーク関連の機能役割にどのような IAM ロールを付与するかについて、ガイダンスを提供します。このコンテンツは主に、組織のネットワーク タスクを管理するネットワーク管理者と従業員を対象としています。以下で説明するシナリオはすべて、Google Cloud 組織が構成されていることを前提としています。
このドキュメントでは、ネットワークのロールと権限については詳細に説明しません。コンピューティング API とネットワーキング API に関連するロールと権限については、事前定義の Compute Engine Cloud IAM のロールをご覧ください。
単一のチームが組織のセキュリティとネットワークを管理する
このシナリオでは、大規模な組織に、組織全体のセキュリティとネットワークの制御を一元的に管理するチームがあります。デベロッパーには、セキュリティとネットワークの担当チームによって定義されたネットワークやセキュリティの設定を変更する権限はありませんが、共有サブネットで仮想マシンなどのリソースを作成する権限は付与されています。
このような管理を容易にするために、組織は共有 VPC(Virtual Private Cloud)を使用します。共有 VPC を使用すると、関連プロジェクト(サービス プロジェクト)で使用できる RFC 1918 IP 空間の VPC ネットワークを作成できます。関連するプロジェクトを使用しているデベロッパーは、共有 VPC ネットワーク空間に VM インスタンスを作成できます。組織のネットワークとセキュリティの管理者は、サブネットや VPN だけでなく、VPC ネットワークのすべてのプロジェクトで使用可能なファイアウォール ルールを作成できます。
以下の表では、セキュリティ / 管理チームと開発チームに付与する必要がある IAM ロールと、ロールが付与される際のリソースレベルについて説明します。
リソース: | 組織 | |
---|---|---|
役割: | 共有 VPC 管理者 ネットワーク管理者 セキュリティ管理者 |
|
プリンシパル: | セキュリティとネットワーク管理チーム |
リソース: | ホスト プロジェクト | この役割は、共有 VPC が共有しているサブネットを使用するための権限を付与します。 |
---|---|---|
ロール: | ネットワーク ユーザー | |
プリンシパル: | デベロッパー |
リソース: | サービス プロジェクト | この役割は、外部 IP アドレスを使用するための権限を付与します。このアクションを禁止する方法については、以下の注をご覧ください。 |
---|---|---|
ロール: | compute.instanceAdmin | |
プリンシパル: | デベロッパー |
このシナリオでは、3 つの個別の許可ポリシー(組織用、ホスト プロジェクト用、サービス プロジェクト用)が必要です。
最初の許可ポリシーは組織レベルで接続される必要があります。このポリシーは、共有 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"
]
}
]
}
2 番目の許可ポリシーは、ホスト プロジェクトに関連付ける必要があります。このポリシーにより、組織内のデベロッパーは共有 VPC ホスト プロジェクトで共有ネットワークを使用できます。
{
"bindings": [
{
"role": "roles/compute.networkUser",
"members": [
"group:developers@example.com"
]
}
]
}
3 番目の許可ポリシーは、各サービス プロジェクトに関連付ける必要があります。このポリシーにより、プロジェクトを使用しているデベロッパーは、サービス プロジェクト内のインスタンスを管理したり、ホスト プロジェクト内の共有サブネットを使用できます。
すべてのサービス プロジェクトをフォルダに配置し、この特定の許可ポリシーをその階層レベルで設定できます。これにより、そのフォルダに作成されたすべてのプロジェクトは、サービス プロジェクトが作成されたフォルダに設定されている権限を継承できます。
また、デベロッパーにサービス プロジェクトのネットワーク ユーザーのロールを付与する必要もあります。
{
"bindings": [
{
"role": "roles/compute.networkUser",
"members": [
"group:developers@example.com"
]
},
{
"role": "roles/compute.instanceAdmin",
"members": [
"group:developers@example.com"
]
}
]
}
おすすめの方法は、グループを使用してプリンシパルを管理することです。上記の例では、セキュリティとネットワークの制御を管理するユーザーのユーザー ID を sec-net
グループに追加し、デベロッパーを developers
グループに追加します。機能を実行できるユーザーを変更する必要がある場合は、グループ メンバーシップを調整するだけでよく、許可ポリシーを更新する必要はありません。
独立したネットワーク チームとセキュリティ チーム
このシナリオでは、大規模な組織に一元管理を行う 2 つのチームがあります。一方はセキュリティ制御を管理し、もう一方は組織全体の他のすべてのネットワーク リソースを管理します。デベロッパーには、セキュリティとネットワークの担当チームによって定義されたネットワークやセキュリティの設定を変更する権限はありませんが、共有サブネットで仮想マシンなどのリソースを作成する権限は付与されています。
最初のシナリオと同様に、共有 VPC が使用され、ネットワーク、セキュリティ、デベロッパーの 3 つのグループに対して適切な権限が構成されます。
以下の表では、セキュリティ / 管理チームと開発チームに付与する必要がある IAM ロールと、ロールが付与される際のリソースレベルについて説明します。
リソース: | 組織 | |
---|---|---|
役割: | 共有 VPC 管理者 ネットワーク管理者 |
|
プリンシパル: | ネットワーク管理チーム |
リソース: | 組織 | |
---|---|---|
役割: | セキュリティ管理者 組織管理者 |
|
プリンシパル: | セキュリティ チーム |
リソース: | ホスト プロジェクト | この役割は、共有 VPC が共有しているサブネットを使用するための権限を付与します。 |
---|---|---|
ロール: | ネットワーク ユーザー | |
プリンシパル: | デベロッパー |
リソース: | サービス プロジェクト | この役割は、外部 IP アドレスを使用するための権限を付与します。このアクションを禁止する方法については、以下の注をご覧ください。 |
---|---|---|
ロール: | compute.instanceAdmin | |
プリンシパル: | デベロッパー |
このシナリオでは、3 つの個別の許可ポリシー(組織用、ホスト プロジェクト用、サービス プロジェクト用)が必要です。
最初の許可ポリシーは組織レベルで接続される必要があります。このポリシーは、共有 VPC ホスト プロジェクトとすべてのネットワーク リソースを管理するのに必要なロールをネットワーク チームに付与します。これには、サービス プロジェクトをホスト プロジェクトに関連付ける権限が含まれます。また、ネットワーク管理者ロールによりネットワーク チームはファイアウォール ルールを表示できますが、変更はできません。また、セキュリティ チームに、許可ポリシーの設定と、組織内のすべてのプロジェクトのファイアウォール ルールと 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"
]
}
]
}
2 番目の許可ポリシーは、ホスト プロジェクトに関連付けられる必要があります。この許可ポリシーにより、組織内のデベロッパーは共有 VPC ホスト プロジェクトの共有ネットワークを使用できます。
{
"bindings": [
{
"role": "roles/compute.networkUser",
"members": [
"group:developers@example.com"
]
}
]
}
3 番目の許可ポリシーは、各サービス プロジェクトに関連付ける必要があります。このポリシーにより、プロジェクトを使用しているデベロッパーは、サービス プロジェクト内のインスタンスを管理したり、ホスト プロジェクト内の共有サブネットを使用できます。
すべてのサービス プロジェクトをフォルダに配置し、この特定の許可ポリシーをその階層レベルで設定できます。これにより、そのフォルダに作成されたすべてのプロジェクトは、サービス プロジェクトが作成されたフォルダに設定されている権限を継承できます。
{
"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"
]
}
]
}