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

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

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

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

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

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

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

리소스: 조직
역할: 공유 VPC 관리자
네트워크 관리자
보안 관리자
구성원: 보안 및 네트워크 관리팀
리소스: 호스트 프로젝트 이 역할은 공유 VPC가 공유한 서브넷을 사용할 수 있는 권한을 부여합니다.
역할: 네트워크 사용자
구성원: 개발자
리소스: 서비스 프로젝트 이 역할은 외부 IP 주소 사용 권한을 허용합니다. 이러한 작업을 방지하는 방법은 아래를 참조하세요.
역할: compute.instanceAdmin
구성원: 개발자

이 시나리오의 경우 서로 다른 수준의 계층구조에서 다양한 프로젝트에 정책이 연결되어 있으므로 세 가지의 별도 IAM 정책이 필요합니다.

조직 수준에서 연결해야 하는 첫 번째 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"
      ]
    }
  ]
}

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

{
  "bindings": [
    {
      "role": "roles/compute.networkUser",
      "members": [
        "group:developers@example.com"
      ]
    }
  ]
}

세 번째 IAM 정책은 각 서비스 프로젝트와 연결되어야 합니다. 이를 통해 프로젝트를 사용하는 개발자는 서비스 프로젝트의 인스턴스를 관리하고 호스트 프로젝트의 공유 서브넷을 사용할 수 있습니다.

모든 서비스 프로젝트를 폴더에 배치하고 계층구조의 해당 수준에서 이러한 특정 정책을 설정할 수 있습니다. 따라서 해당 폴더에서 생성된 모든 프로젝트가 서비스 프로젝트가 생성된 폴더에 설정된 권한을 상속할 수 있습니다.

또한 개발자에게 서비스 프로젝트의 네트워크 사용자 역할을 부여해야 합니다.

{
  "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 관리자
네트워크 관리자
구성원: 네트워크 관리팀
리소스: 조직
역할: 보안 관리자
조직 관리자
구성원: 보안팀
리소스: 호스트 프로젝트 이 역할은 공유 VPC가 공유한 서브넷을 사용할 수 있는 권한을 부여합니다.
역할: 네트워크 사용자
구성원: 개발자
리소스: 서비스 프로젝트 이 역할은 외부 IP 주소 사용 권한을 허용합니다. 이러한 작업을 방지하는 방법은 아래를 참조하세요.
역할: compute.instanceAdmin
구성원: 개발자

이 시나리오의 경우 서로 다른 수준의 계층구조에서 다양한 프로젝트에 정책이 연결되어 있으므로 세 가지의 별도 IAM 정책이 필요합니다.

조직 수준에 연결되는 첫 번째 IAM 정책은 공유 VPC 호스트 프로젝트를 관리하고 모든 네트워크 소스를 관리하는 네트워크팀 권한을 부여하는 것입니다. 여기에는 서비스 프로젝트를 호스트 프로젝트에 연결할 수 있는 기능을 포함합니다. 네트워크 관리자 역할은 또한 네트워크팀에게 방화벽 규칙을 조회할 수 있지만 수정은 불가능한 권한을 부여합니다. 또한 보안팀에 IAM 정책을 설정하고 조직 내 모든 프로젝트의 방화벽 규칙 및 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"
        ]
    }
  ]
}

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

{
  "bindings": [
    {
      "role": "roles/compute.networkUser",
      "members": [
        "group:developers@example.com"
        ]
    }
  ]
}

세 번째 IAM 정책은 각 서비스 프로젝트와 연결되어야 합니다. 이를 통해 프로젝트를 사용하는 개발자는 서비스 프로젝트의 인스턴스를 관리하고 호스트 프로젝트의 공유 서브넷을 사용할 수 있습니다.

모든 서비스 프로젝트를 폴더에 배치하고 계층구조의 해당 수준에서 이러한 특정 정책을 설정할 수 있습니다. 따라서 해당 폴더에서 생성된 모든 프로젝트가 서비스 프로젝트가 생성된 폴더에 설정된 권한을 상속할 수 있습니다.

{
  "bindings": [
    {
      "role": "roles/compute.networkUser",
      "members": [
        "group:developers@example.com"
        ]
      },
      {
        "role": "roles/compute.instanceAdmin",
        "members": [
          "group:developers@example.com"
          ]
      }
    ]
}

각 팀에서 자체 네트워크 관리 가능

디지털 네이티브가 개발팀이 자체적으로 작업할 수 있는 권한을 부여하고 싶어합니다. 이들은 중앙 IT 관리팀이 없으며 팀에게 담당 프로젝트의 모든 요소를 관리하도록 합니다.

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

이 시나리오를 충족하기 위해 각 개발자 팀에 폴더를 각각 할당하여 해당 폴더 하위에 생성된 개별 프로젝트가 적절한 권한을 상속받도록 합니다. 각 팀은 각 프로젝트 내에서 연결된 네트워크를 자체적으로 관리할 수 있습니다. 프로세스 및 IAM 정책을 구현하여 이러한 자체 팀 내에서도 처음부터 최소한의 권한이 적용되도록 하면 팀이 긴밀하게 협력하기 시작할 때 마찰이 발생하지 않도록 할 수 있습니다.

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

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

리소스: 폴더 서비스 계정을 사용하여 프로젝트를 만들고 소유할 수 있습니다.
역할: 프로젝트 생성자
폴더 관리자
구성원: 개발 팀장
서비스 계정
리소스: 폴더
역할: 네트워크 관리자

보안 관리자

구성원: 네트워크 및 보안팀
리소스: 폴더 이러한 역할은 개발자가 BigQuery 및 Compute Engine의 모든 요소를 관리하도록 합니다.
역할: 인스턴스 관리자
BigQuery 관리자
구성원: 개발자

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

{
  "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"
        ]
    }
  ]
}
이 페이지가 도움이 되었나요? 평가를 부탁드립니다.

다음에 대한 의견 보내기...

Cloud ID 및 액세스 관리 문서