AWS 전문가를 위한 Google Cloud: 관리

2017년 3월 17일 업데이트됨

Amazon과 Google이 각각의 클라우드 환경에서 제공하는 관리 서비스를 비교합니다. IAM(ID 및 액세스 관리)에 대한 AWS(Amazon Web Services) 구현에 이미 익숙한 사용자의 경우, 이 문서는 Google Cloud Identity and Access Management에 대한 포괄적인 소개를 제공합니다. Google Cloud 및 AWS는 유사한 IAM 솔루션을 제공합니다. 이러한 도구를 사용하면 데이터 및 애플리케이션을 포함하여 클라우드 리소스에 대한 권한 설정을 만들고 관리할 수 있습니다.

AWS와 Google Cloud 모두 사용자, 그룹, 애플리케이션에 권한을 부여할 수 있습니다. 이러한 권한은 해당 권한이 부여된 항목이 개발자의 클라우드 리소스에 대해 명확하게 정의된 액세스 권한을 갖도록 허용합니다.

다음 표에서는 AWS와 Google Cloud의 각 용어 및 개념을 일반적으로 비교해서 보여줍니다.

개념 AWS Google Cloud
프로그래매틱 ID IAM 역할 및 인스턴스 프로필 Cloud IAM 서비스 계정
사용자 ID IAM에서 관리. 외부 ID 관리 시스템에 통합된 ID. Cloud IAM 외부에서 관리. 외부 ID 관리 시스템에 통합된 ID.
정책 권한이 명시적으로 나열된 문서. 바인딩 목록. 바인딩은 구성원 목록을 역할에 연결합니다.
정책 연결 IAM 사용자 또는 그룹이나 리소스에 연결된 정책. 리소스에 연결된 정책.

정책 평가 기본적으로 거부. 기본적으로 거부.
권한 수집 정책 역할
미리 정의된 권한 집합 관리되는 정책 미리 정의된 역할
IAM 호출 감사 AWS CloudTrail 감사 로깅
버전 관리 아니요

리소스 관리 및 캡슐화

이 섹션에서는 각 클라우드 공급업체가 리소스를 관리하는 방법을 이해할 수 있습니다.

AWS의 여러 계정

AWS에서는 각 팀에 대해 여러 계정을 설정하는 것이 가장 좋습니다. 그런 다음 각 계정에 권한 및 정책을 할당할 수 있습니다. 통합 청구를 설정하고 AWS 조직을 구현하면 여러 AWS 계정을 관리하는 복잡성을 줄일 수 있습니다.

Google Cloud에서 프로젝트 및 정책 구성

Google Cloud는 조직, 폴더, 프로젝트와 같이 다른 Google Cloud 리소스를 그룹화하고 계층별로 구성할 수 있는 컨테이너 리소스를 제공합니다(예: Pub/Sub 항목 및 Compute Engine VM(가상 머신) 인스턴스). 이러한 계층별 조직을 사용하면 액세스 제어 및 구성 설정과 같은 리소스의 일반 측면을 관리할 수 있습니다.

모든 Google Cloud 리소스는 프로젝트 리소스에 속하며, 개별 Google 계정이 여러 프로젝트를 관리할 수 있습니다. 프로젝트를 개별적으로 관리할 수 있습니다. 유사한 프로젝트나 관련된 프로젝트를 폴더로 그룹화하여 관리할 수 있습니다. 또한 폴더와 프로젝트 모두 조직 리소스 아래에서 관리할 수도 있습니다.

다음 다이어그램은 Google Cloud에서의 여러 리소스 및 해당 계층별 조직 예시를 보여줍니다. 대부분의 Google Cloud 리소스와 상호작용하려면 모든 요청에 대해 프로젝트 식별 정보를 제공해야 합니다.

Google Cloud 리소스 계층 구조의 예시

정책 상속

AWS에서는 리소스에 직접 적용되는 리소스 기반 권한을 지정하거나 지정된 리소스에 대해 수행할 수 있는 특정 작업에 대한 권한을 지정할 수 있습니다. 권한 지정 방식은 서비스에 따라 달라집니다.

Google Cloud의 IAM 정책 상속은 리소스 조직으로 보완됩니다. Google Cloud에서는 리소스가 계층적으로 구성되므로 조직 노드에서 아래로 흐르는 IAM 정책을 설정할 수 있습니다. 조직 전체 IAM 정책을 설정하려는 경우 조직 리소스에 이 정책을 할당할 수 있습니다. 여러 팀 및 프로젝트 간에 정책을 설정하려면 Google Cloud 폴더를 사용해서 이를 수행할 수 있습니다. 그런 다음 프로젝트 수준에서 권한을 할당하고 마지막으로 보다 세부적인 제어를 위해 해당 프로젝트 내의 리소스 수준에서 권한을 할당할 수 있습니다.

ID

클라우드 리소스에 액세스하기 위해 사용되는 ID는 두 그룹으로 나뉩니다.

  • 최종 사용자 ID는 일반적인 회사 로그인 ID로 표시됩니다. AWS의 경우, 최종 사용자는 IAM 계정을 사용하여 표시할 수도 있습니다.
  • 프로그래매틱 ID는 애플리케이션 코드가 클라우드 리소스에 액세스할 수 있게 해줍니다.

AWS의 최종 사용자 ID

AWS는 생성된 모든 계정의 요구 사항인 루트 계정을 관리합니다. AWS는 AWS 계정의 루트 액세스 키를 보호하는 데 도움이 되는 권장사항 목록을 제공합니다.

AWS 리소스에 액세스를 허용하려면 AWS 내에서 생성되는 ID인 IAM 사용자를 설정하거나 회사 디렉토리에서 통합을 설정하면 됩니다. 타사 ID 공급업체를 사용할 수 있습니다. AWS에서 사용할 타사 ID 공급업체를 구성할 때는 IAM 역할을 만든 후 해당 역할에 대한 권한을 정의해야 합니다. 통합 사용자가 AWS에 로그인하면 사용자가 역할에 연결되고, 해당 역할에 정의된 권한이 부여됩니다.

Google Cloud의 최종 사용자 액세스

Google Cloud에서는 프로젝트 소유권을 할당하기 위한 두 가지 기본 옵션이 있습니다.

  • 프로젝트의 리소스에 대해 전체 액세스 권한이 있는 하나 이상의 소유자를 사용해서 프로젝트를 만들 수 있습니다.
  • 명시적 소유자가 없는 프로젝트를 만들 수 있습니다. 이 접근 방식은 프로젝트가 조직의 일부이고, 모든 프로젝트가 해당 조직에서 소유되도록 하려는 경우에 유용할 수 있습니다.

Cloud IAM에서는 개발자가 최종 사용자 ID를 관리할 수 없습니다. 그 대신, 개발자가 다른 방식을 통해 만들고 관리하는 사용자에게 액세스 권한을 부여할 수 있습니다. Cloud IAM을 사용할 때는 기본적으로 다음 유형의 ID에 액세스 권한을 부여할 수 있습니다.

  • Google 계정
  • 서비스 계정
  • Google 그룹스
  • G Suite 도메인

Google 그룹스를 사용하면 사용자 모음에 액세스 정책을 편리하게 적용할 수 있습니다. 개별 사용자 또는 서비스 계정에 대해 한 번에 하나씩 액세스 제어 권한을 부여하거나 변경하는 대신 전체 그룹에 대해 액세스 제어 권한을 한 번에 부여하고 변경할 수 있습니다. 또한 사용자를 추가하거나 삭제하도록 Cloud IAM 정책을 업데이트하는 대신 Google 그룹에서 구성원을 쉽게 추가하거나 삭제할 수 있습니다.

아직 G Suite 도메인을 사용하여 사용자 관리를 하지 않는 경우, Active Directory와 같은 많이 사용되는 여러 사용자 디렉토리에서 기존 운영 사용자 하위 집합을 통합할 수 있습니다. 이 접근 방식을 사용하면 기존 회사 ID를 사용할 수 있습니다. 먼저 Google에서 도메인 이름을 확인해야 합니다.

다음 표에서는 사용자를 Google Cloud에 통합하는 방법을 나열하고 설명합니다.

통합 기술 설명
클라우드 디렉토리 동기화 대부분의 상용 및 엔터프라이즈 LDAP 디렉토리 서비스에서 작동하는 Google 제공 도구입니다. 클라우드 디렉터리 동기화를 사용하면 사용자, 그룹, 직원이 아닌 사용자 연락처를 추가, 수정, 삭제하고, LDAP 쿼리를 사용해서 Google Cloud 도메인의 데이터를 LDAP 디렉터리 서버와 동기화할 수 있습니다. LDAP 디렉토리 서버의 데이터는 수정되거나 손상되지 않습니다.
타사 ID 커넥터 ID를 제공하는 ID 공급업체와의 고유 커넥터입니다. Google Cloud에 프로비저닝된 도메인에 ID 공급업체를 직접 연결합니다. 예를 들면 다음과 같습니다.

  • Ping Federate
  • Okta
  • CA Siteminder
  • Azure AD
  • OpenIAM
  • Auth0
  • Oracle IAM
Google 앱 API 사용자 및 그룹 관리에 대한 프로그래매틱 제어 권한을 조직에 부여합니다.

그 다음, 이메일 주소 형식으로 ID를 Google 그룹스에 추가하여 Google Cloud 리소스에 대한 액세스 권한을 부여할 수 있습니다.

AWS의 프로그래매틱 ID

AWS에서는 AWS 컴퓨팅 리소스에서 실행되지 않는 애플리케이션에서 AWS API를 호출하려는 경우 IAM 사용자를 만듭니다. 그런 다음 적합한 키를 다운로드하고 이를 앱에 사용해서 AWS API를 호출합니다.

EC2 인스턴스에서 프로그래매틱 ID를 사용하려면 인스턴스에 연결된 인스턴스 프로필도 만들어야 합니다. 이 프로필에는 IAM 역할이 포함되며, 인스턴스에서 실행되는 애플리케이션에 역할의 사용자 인증 정보를 제공할 수 있습니다.

IAM 역할을 통해 IAM 사용자, 그룹, EC2 또는 모바일 장치에서 실행될 수 있는 애플리케이션이 해당 역할에 정의된 권한을 가정할 수 있습니다. 임시 사용자 인증 정보가 생성되고 해당 역할을 맡고 있는 항목에 제공됩니다.

또한 IAM 사용자는 IAM 역할을 사용하여 특정 역할로 전환하고 콘솔을 사용할 때 해당 역할의 권한을 일시적으로 사용할 수 있습니다. 이 경우, 사용자는 자신의 원래 권한을 포기하고 해당 역할에 할당된 권한을 갖습니다. 사용자가 역할을 종료하면 해당 권한을 포기합니다.

Google Cloud의 프로그래매틱 ID

Google Cloud에서 서비스 계정은 애플리케이션이 Google 서비스에 프로그래매틱 방식으로 액세스하는 데 사용할 수 있는 특수한 Google 계정입니다. 이 계정은 개별 최종 사용자가 아닌 개발자의 애플리케이션 또는 Compute Engine 인스턴스에 속합니다.

서비스 계정에는 Google에서 인증을 수행하는 데 사용되는 서비스 계정 키 쌍이 포함될 수 있습니다. 서비스 계정 키는 Google에서 생성되는 공개-비공개 키 쌍입니다. 사용자에게는 비공개 키가 제공되고 Google은 공개 키를 보유합니다.

Google Cloud Console, Cloud Identity and Access Management API, gcloud 명령줄 도구를 사용해서 Google Cloud 프로젝트에서 커스텀 서비스 계정을 만들 수 있습니다.

Google Cloud 컴퓨팅 서비스에서 실행되는 애플리케이션에서만 서비스 계정을 사용하려는 경우, Google Cloud 관리 키를 사용할 수 있으므로 비공개 키를 다운로드할 필요가 없습니다.

Cloud IAM 서비스 계정의 기능 중 하나는 이를 리소스 또는 ID로 취급할 수 있다는 것입니다. 서비스 계정에는 ID가 포함되며, 프로젝트와 같은 리소스에 액세스할 수 있도록 역할에 권한을 부여함으로써 권한을 제공합니다.

서비스 계정을 리소스로 취급할 경우, 다른 Google Cloud 리소스와 마찬가지로 해당 서비스 계정에 액세스하기 위한 권한을 사용자에게 부여할 수 있습니다. 서비스 계정에 액세스하도록 사용자에게 소유자, 편집자, 뷰어, serviceAccountUser 미정의 역할을 부여할 수 있습니다. 서비스 계정에 대해 serviceAccountUser인 사용자는 해당 서비스 계정이 액세스할 수 있는 것과 동일한 권한을 사용하여 모든 리소스에 액세스할 수 있습니다. 이것은 이전 섹션에서 설명한 IAM 역할 사용과 비슷한 기능입니다.

서비스 계정 키는 개발자가 관리하는 사용자 관리 키이거나 Google Cloud가 관리하는 Google Cloud 관리 키일 수 있습니다.

Cloud Console, Cloud IAM API, gcloud 명령줄 도구를 사용하여 사용자 관리 키를 만들고 관리할 수 있습니다. 개발자는 키를 안전하게 유지하고 이를 순환 사용해야 합니다.

Google Cloud 관리 키는 App Engine 및 Compute Engine과 같은 서비스에서 사용됩니다. Google Cloud 관리 키는 개발자가 명시적으로 만들거나 다운로드할 수 없습니다. 이러한 키는 Google에서 관리되며, 개발자를 위해 하루에 한 번씩 순환됩니다.

권한 기여

Google Cloud와 AWS에서는 역할정책이라는 용어가 모두 사용되지만, 사용법이 약간 다릅니다. AWS IAM과 Cloud IAM에서는 이러한 차이로 인해 두 가지를 올바르게 비교하지 못할 수 있습니다. 권한 모음은 Google Cloud에서 역할이라고 부르지만, AWS에서는 이를 정책이라고 부릅니다.

AWS 권한 예

AWS에서는 권한을 정책 정의에 있는 작업, 리소스, 효과로 지정합니다. 예를 들어 다른 사람이 계정(리소스)에서 모든 버킷(작업)을 나열하도록 허용하는(효과) AWS 정책은 다음과 같을 수 있습니다.

{
  "Version": "2012-10-17",
  "Statement": {
  "Effect": "Allow",
  "Action": "s3:ListAllMyBuckets",
  "Resource": "*"
  }
}

여러 사용자, 그룹, 역할에 연결할 수 있는 독립형 AWS IAM 정책을 관리되는 정책이라고 부릅니다. 관리되는 정책은 AWS에서 생성되고 관리되는 AWS 관리 정책이거나 개발자가 자신의 AWS 계정에서 만들고 관리하는 고객 관리 정책일 수 있습니다.

Google Cloud 권한 예시

Google Cloud는 미리 정의된 역할 우선 방식을 사용합니다. 즉, 프로젝트의 모든 버킷을 나열하는 것과 같은 일반적인 사용 사례에서는 간단하게 뷰어 역할을 사용하면 됩니다. 그런 다음 이 역할을 사용자 또는 그룹에 할당해야 합니다. 사용자 또는 그룹을 역할에 연결하는 결과 문서를 정책이라고 부릅니다. 정책 정의는 다음 예와 비슷합니다.

{
  "bindings": [
      {
     "role": "roles/viewer",
     "members": ["group:gcs-viewers@example.com"]
   }
  ]
}

AWS 정책

AWS에서는 정책을 ID에 연결하는 것 외에도 리소스에 정책을 연결할 수 있습니다. 리소스에 연결하는 정책의 경우, 정책 내에서 리소스에 액세스할 수 있는 ID 또는 역할을 포함해야 합니다.

대부분의 경우 AWS는 관리되는 정책을 사용하도록 권장합니다. 관리되는 정책과 인라인 정책 사이의 선택을 위한 권장 사항은 AWS 문서에서 설명합니다.

Google Cloud 정책

이제 iam-gcs-access.json,이라는 JSON 파일에 선언된 Google Cloud 정책을 살펴보겠습니다. 이 정책은 사용자 그룹에 viewer 역할을 부여하고 서비스 계정에 objectCreator 역할을 부여합니다. 애플리케이션은 서비스 계정을 사용하여 프로젝트에 있는 버킷에 객체를 추가합니다. 다음 예에서는 단일 정책에서 여러 개의 구성원-역할 바인딩을 만드는 방법을 보여줍니다.

{
    "bindings": [
    {
        "members": [
            "group:gcs-viewers@example.com"
        ],
        "role": "roles/viewer"
    },
    {
        "members": [
            "serviceAccount:123456789012-compute@developer.gserviceaccount.com"
        ],
        "role": "roles/storage.objectCreator"
    },
    ],
    "etag": "BwUjMhCsNvY=",
    "version": 1
}

그런 다음 이 정책을 리소스(프로젝트)에 연결할 수 있습니다. Cloud Console에서 gcloud 도구의 set-iam-policy 명령어 또는 API를 사용해서 프로젝트에 정책을 할당합니다. 이 예시에서 gcloud 명령어는 다음과 같습니다.

gcloud projects set-iam-policy [PROJECT_ID] iam-gcs-access.json

여기서 [PROJECT_ID]는 Google Cloud 프로젝트 ID를 나타냅니다.

이 방법은 AWS의 정책 내에서 리소스에 액세스할 수 있는 ID 또는 역할을 포함하는 방법과 비슷합니다.

Google Cloud에서 정책 관리

개발자는 자신의 코드와 마찬가지로 정책을 취급해야 합니다. 즉, 해당 클라우드 환경을 정의하기 위해 사용하는 나머지 애셋과 함께 버전 제어 시스템에 정책을 보관해야 합니다. 정책을 업데이트할 경우에는 새 버전을 만듭니다.

AWS에는 앞에서 설명한 두 가지 유형의 정책이 포함되지만, Google Cloud에는 한 가지 유형의 정책만 포함되며, 개발자가 적합한 버전 제어 시스템을 사용해서 정책을 유연하게 관리할 수 있습니다. Google Cloud는 Google Cloud에서 호스팅되는 모든 기능을 갖춘 비공개 Git 저장소인 Cloud Source Repositories를 제공합니다.

GitHub 또는 Bitbucket에 저장소가 이미 있으면 이를 자신의 Cloud Source Repositories에 연결할 수 있습니다. 연결된 저장소 및 Cloud Source Repositories는 자동으로 동기화된 상태로 유지됩니다. Cloud Source Repositories는 또한 Cloud Console에서 저장소 파일에 대한 변경 사항을 찾아보고, 확인, 편집, 커밋하기 위해 사용할 수 있는 소스 편집기를 제공합니다.

현재 버전의 제어 솔루션을 사용하고자 하는 경우 Google Cloud에서 가능합니다.

권한 테스트 및 확인

AWS를 사용할 때는 신규 및 기존 정책을 테스트하고 검증할 수 있게 해주는 IAM 정책 시뮬레이터를 사용하고 사용자, 그룹, 리소스에 대해 설정된 정책을 확인할 수 있습니다.

Google Cloud에서는 get-iam-policy gcloud 명령어를 사용하여 정책 정의를 반환할 수 있습니다.

gcloud projects get-iam-policy [PROJECT_ID]

반환된 정의를 사용하여 리소스에 연결된 정책을 확인할 수 있습니다. 또한 Cloud Console을 사용하여 특정 리소스로 이동하고 권한을 확인할 수 있습니다.

ID에 할당된 권한을 확인하려면 Cloud Console에서 ID를 선택하고 해당 ID가 연결된 역할을 보면 됩니다. 또한 해당 ID로 로그인하거나 동일 권한이 있는 테스트 ID로 로그인하여 Cloud Console을 통해 ID가 액세스할 수 있는 대상을 확인할 수 있습니다.

권한 전파

AWS에서는 모든 정책이 평가됩니다. 정책이 정의된 순서는 분명한 영향을 주지 않습니다. 최종 결과는 '허용됨' 또는 '거부됨'이 됩니다. 명시적 거부를 사용함으로써 넓은 리소스 집합에 대한 액세스를 허용할 수 있는 포괄적인 정책을 재정의할 수 있습니다. 이에 대해서는 요청이 계정 내에서 허용 또는 거부되는지 여부 확인에서 자세히 설명합니다.

Google Cloud에서는 해당 리소스에 설정된 정책과 상위 항목에서 상속된 정책이 통합되어 리소스에 대한 실제 정책으로 적용됩니다. 역할은 동심원 형태로 겹쳐지기 때문에 동일 사용자에게 여러 역할을 부여하면 가장 넓은 역할의 권한이 사용자에게 부여됩니다. 몇 가지 시나리오 예는 액세스 제어에 리소스 계층 구조 사용에서 확인할 수 있습니다.

IAM 감사

IAM 작업 감사를 위해 Amazon은 계정에 대한 AWS API 호출을 기록하는 AWS CloudTrail을 제공합니다. CloudTrail은 사용자가 지정한 Amazon S3 계정에 다음 로그를 전송합니다.

Google Cloud는 관리자 활동 및 데이터 액세스를 기록하는 Cloud 감사 로그를 제공합니다. Google Cloud 서비스에서 이러한 두 가지 스트림을 생성하고, Google Cloud 프로젝트 내에서 '누가, 언제, 어디서, 무엇을 했는가'에 대한 질문에 답할 수 있도록 지원합니다.

개별 감사 로그 항목이 지정된 기간 동안 Google Cloud의 작업 모음에 보관되므로, 최근 활동을 대시보드 보기에서 한눈에 확인할 수 있습니다. 이러한 항목은 지정된 기간이 지난 후 Google Cloud 작업 제품군에서 삭제됩니다. Cloud Logging 할당량 정책에는 로그 항목이 보존되는 기간이 기술되어 있습니다. 다른 방식으로는 감사 로그를 삭제하거나 수정할 수 없습니다.

Logging IAM 역할을 사용하면 프로젝트 또는 조직에서 로깅 관련 리소스로만 액세스를 제한할 수 있습니다.

보관 기간을 늘리려면 Cloud Storage 버킷, BigQuery 데이터세트, Pub/Sub 주제를 사용하거나 이러한 세 가지 방식을 임의로 조합하여 감사 로그 항목 내보내기를 수행하면 됩니다.

다음 단계

AWS 전문가를 위한 다른 Google Cloud 문서를 확인하세요.