네트워킹 관련 직무에서 IAM 역할

이 주제에서는 네트워킹 시나리오에서 ID 및 액세스 관리(IAM) 권한을 구성하는 방법을 보여줍니다. 이는 시나리오에서 회사의 네트워킹 관련 직무에 어떤 IAM 역할을 부여해야 하는지에 대한 안내를 제공합니다. 이 문서의 내용은 주로 네트워크 관리자 및 조직의 네트워킹 작업을 관리하는 직원을 대상으로 합니다. 아래에 설명된 시나리오는 모두 Google Cloud 조직이 구성되었다고 가정합니다.

이 문서에서는 네트워킹 역할 및 권한에 대해 자세히 설명하지 않습니다. 컴퓨팅 및 네트워킹 API과 관련된 역할 및 권한에 관한 자세한 내용은 사전 정의된 Compute Engine IAM 역할을 참조하세요.

단일 팀에서 조직의 보안 및 네트워크 관리

이 시나리오에서는 대규모 조직의 중앙 팀이 조직 전체의 보안 및 네트워킹 제어를 관리합니다. 개발자에게는 보안 및 네트워크팀이 정의한 네트워크 또는 보안 설정을 변경할 권한이 없지만 공유 서브넷의 가상 머신과 같은 리소스를 만드는 권한이 부여됩니다.

이를 위해 조직은 공유 VPC(가상 사설 클라우드)를 사용합니다. 공유 VPC를 사용하면 RFC 1918 IP 공간의 VPC 네트워크를 만들어서 관련 프로젝트(서비스 프로젝트)에서 사용할 수 있습니다. 관련 프로젝트를 사용하는 개발자는 공유 VPC 네트워크 공간에서 가상 머신 인스턴스를 만들 수 있습니다. 조직의 네트워크 및 보안 관리자는 서브넷, VPN, 방화벽 규칙을 생성하여 VPC 네트워크의 모든 프로젝트에서 사용할 수 있도록 합니다.

아래 표에는 보안팀, 관리팀, 개발팀에 부여해야 하는 IAM 역할과 역할이 부여되는 리소스 수준이 나와 있습니다.

이 시나리오의 경우 조직용, 호스트 프로젝트용, 서비스 프로젝트용의 세 가지 허용 정책이 필요합니다.

조직 수준에서 연결되어야 하는 첫 번째 허용 정책은 네트워크 및 보안팀에 공유 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"
      ]
    }
  ]
}

두 번째 허용 정책은 호스트 프로젝트와 연결되어야 하며, 조직의 개발자가 공유 VPC 호스트 프로젝트의 공유 네트워크를 사용할 수 있도록 합니다.

{
  "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 호스트 프로젝트를 관리하고 모든 네트워크 리소스를 관리하는 데 필요한 역할을 네트워크팀에 부여합니다. 여기에는 서비스 프로젝트를 호스트 프로젝트에 연결할 수 있는 기능을 포함합니다. 네트워크 관리자 역할은 또한 네트워크팀에게 방화벽 규칙을 볼 수는 있지만 수정은 불가능한 권한을 부여합니다. 또한 보안팀에 허용 정책을 설정하고 조직 내 모든 프로젝트의 방화벽 규칙 및 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"
        ]
    }
  ]
}

두 번째 허용 정책은 호스트 프로젝트와 연결되어야 합니다. 이 허용 정책을 통해 조직의 개발자가 공유 VPC 호스트 프로젝트에서 공유 네트워크를 사용할 수 있습니다.

{
  "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 관리팀이 없으며 팀에게 담당 프로젝트의 모든 요소를 관리하도록 합니다.

그럼에도 불구하고 한편으로는 비교적 엄격하지 않은 제어 장치를 두어 성장과 더불어 제품이 일반적으로 사용 가능해진(GA) 후에 보다 공식화된 체계를 도입할 수 있기를 원합니다.

이 시나리오를 구현하기 위해 각 개발자팀에 자체 폴더가 할당됩니다. 이 구조를 사용하면 각 팀이 독립적으로 작업할 수 있도록 허용하면서 폴더 아래에 생성된 개별 프로젝트에 적절한 권한이 상속됩니다. 각 팀은 자체 리소스에 허용 정책을 설정할 때도 최소 권한의 원칙을 따라야 합니다.

초기에는 동일한 팀 구성원이 프로젝트의 네트워크 리소스와 실제 리소스를 관리하더라도 논리적으로 업무를 분장하는 별도의 그룹을 만드는 것이 좋습니다.

이러한 접근 방식을 통해 임시 직원에게 필요한 리소스 또는 네트워크 리소스를 수정하기 전에 교육을 필요로 하는 신규 직원에게 필요한 리소스에 대한 액세스를 쉽게 제한할 수 있습니다. 또한 직원이 바뀔 때마다 허용 정책을 수정하지 않고도 리소스에 액세스할 수 있는 사용자를 변경할 수 있습니다.

이를 위해 각 팀의 할당된 폴더에 연결된 허용 정책이 필요합니다.

{
  "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"
        ]
    }
  ]
}