Dataproc 및 Google Cloud에는 데이터 보안을 도와주는 여러 가지 기능이 포함되어 있습니다. 이 가이드에서는 Hadoop의 보안 원리를 설명하고 이 원리가 Google Cloud에 어떻게 적용되는지 살펴봄으로써 Google Cloud 배포 시의 보안 설계를 안내합니다.
개요
온프레미스 Hadoop 배포의 일반적인 보안 모델 및 메커니즘은 클라우드에서 제공하는 보안 모델 및 메커니즘과는 다릅니다. 따라서 Hadoop 보안에 대해 이해하면 Google Cloud에 배포할 때 보안을 더 효과적으로 설계할 수 있습니다.
Google Cloud에 Hadoop을 배포할 때는 Google이 관리하는 클러스터(Dataproc) 또는 사용자 관리 클러스터(Compute Engine의 Hadoop)를 사용하는 2가지 방법이 있습니다. 이 가이드의 내용 및 기술 안내는 두 배포 형태 모두에 적용됩니다. 이 가이드에서는 각 유형의 배포에 적용되는 개념이나 절차를 언급할 때 각각 Dataproc/Hadoop이라는 용어를 사용합니다. 이 가이드는 Dataproc에 배포할 때와 Compute Engine의 Hadoop에 배포할 때 차이가 있는 몇 가지 경우에 대해 소개합니다.
일반적인 온프레미스 Hadoop 보안
다음 다이어그램은 일반적인 온프레미스 Hadoop 인프라와 관련 보안 방식을 보여줍니다. 기본 Hadoop 구성요소의 구성요소 간 상호작용 및 사용자 관리 시스템과의 상호작용 방식에 주목하세요.
Hadoop 보안은 전반적으로 다음과 같은 4가지 요소를 기반으로 합니다.
- 인증: LDAP 또는 Active Directory와 통합된 Kerberos를 통해 제공됩니다.
- 승인: HDFS 및 Apache Sentry 또는 Apache Ranger 등의 보안 제품을 통해 제공됩니다. 이러한 보안 제품을 통해 사용자가 Hadoop 리소스에 대한 올바른 액세스 권한을 보유할 수 있습니다.
- 암호화: 네트워크 암호화 및 HDFS 암호화를 통해 제공되며 전송 중인 데이터 및 미사용 데이터를 모두 보호합니다.
- 감사: 공급업체에서 제공하는 Cloudera Navigator 등의 제품을 통해 제공됩니다.
사용자 계정 관점에서 봤을 때 Hadoop은 자체적으로 사용자 및 그룹 구조를 가지고 ID를 관리하며 데몬을 실행합니다. 예를 들어 Hadoop HDFS 및 YARN 데몬은 보안 모드의 Hadoop의 설명대로 Unix 사용자 hdfs 및 yarn으로 실행됩니다.
Hadoop 사용자는 보통 Linux 시스템 사용자 또는 Active Directory/LDAP 사용자에서 매핑됩니다. Active Directory 사용자 및 그룹은 Centrify 또는 RedHat SSSD 등의 도구를 통해 동기화됩니다.
Hadoop 온프레미스 인증
보안 시스템에서는 사용자와 서비스가 시스템에 자신을 증명해야 합니다. Hadoop 보안 모드는 인증에 Kerberos를 사용합니다. 대부분의 Hadoop 구성요소는 Kerberos를 사용해 인증하도록 설계되어 있습니다. Kerberos는 일반적으로 Active Directory 또는 LDAP 호환 시스템 등의 엔터프라이즈 인증 시스템에서 구현됩니다.
Kerberos의 principal
Kerberos에서는 사용자를 principal이라고 합니다. Hadoop 배포 환경에는 사용자 principal 및 서비스 principal이 존재합니다. 사용자 principal은 일반적으로 Active Directory 또는 다른 사용자 관리 시스템에서 KDC(Key Distribution Center)로 동기화됩니다. 사용자 principal 하나가 실제 사용자 한 명을 나타냅니다. 서비스 principal은 서버마다 서비스별로 다르므로 각 서버의 서비스마다 해당 서비스를 나타내는 고유의 principal이 하나씩 존재합니다.
Keytab 파일
keytab 파일에는 Kerberos principal과 키가 포함되어 있습니다. 대화형 도구를 사용하거나 비밀번호를 입력할 필요 없이 사용자 및 서비스가 keytab을 사용해 Hadoop 서비스를 인증할 수 있습니다. Hadoop에서는 각 노드의 서비스마다 서비스 principal이 생성됩니다. 이러한 principal은 Hadoop 노드의 keytab 파일에 저장됩니다.
SPNEGO
웹브라우저를 사용해 Kerberos를 적용한 클러스터에 액세스하는 경우 브라우저가 Kerberos 키 전달 방법을 인식하고 있어야 합니다. 이를 위해 웹 애플리케이션에서 Kerberos를 사용하는 방법을 제공하는 SPNEGO(Simple and Protected GSS-API Negotiation Mechanism)가 사용됩니다.
통합
Hadoop은 사용자 인증은 물론 서비스 인증을 위해서도 Kerberos와 통합됩니다. 모든 노드의 Hadoop 서비스는 인증에 사용하는 자체 Kerberos principal을 가집니다. 서비스에는 보통 서버에 저장된 keytab 파일이 있으며 여기에 임의의 비밀번호가 포함되어 있습니다.
서비스와 상호작용하기 위해서는 일반적으로 사용자가 kinit 명령어나 Centrify 또는 SSSD를 통해 Kerberos 티켓을 얻어야 합니다.
Hadoop 온프레미스 승인
ID가 확인된 후에는 승인 시스템에서 사용자 또는 서비스의 액세스 유형을 확인합니다. Hadoop에서는 Apache Sentry, Apache Ranger 등의 몇몇 오픈소스 프로젝트를 사용해 승인을 제공합니다.
Apache Sentry 및 Apache Ranger
Apache Sentry 및 Apache Ranger는 Hadoop 클러스터에서 사용되는 일반적인 승인 메커니즘입니다. Hadoop의 구성요소는 Sentry 또는 Ranger에 자체 플러그인을 구현해 Sentry 또는 Ranger에서 ID 액세스를 확인하거나 거부할 경우의 행동을 지정합니다. Sentry 및 Ranger는 Kerberos, LDAP, AD 등의 인증 시스템을 사용합니다. Hadoop의 그룹 매핑 메커니즘에 따라 Sentry 또는 Ranger가 Hadoop 생태계의 다른 구성요소에 표시되는 것과 동일한 그룹 매핑을 확인하게 됩니다.
HDFS 권한 및 ACL
HDFS에서는 사용자에게 파일 액세스 권한이 있는지 판단하기 위해 POSIX와 유사한 권한 시스템을 액세스제어 목록(ACL)과 함께 사용합니다. 각 파일 및 디렉터리가 소유자 및 그룹과 연결됩니다. 해당 구조에는 수퍼유저가 소유한 루트 폴더가 있습니다. 구조의 각 수준마다 암호화, 소유권, 권한, 확장 ACL(facl)이 다를 수 있습니다.
다음 다이어그램과 같이 보통은 디렉터리 수준에서 액세스 요구에 따라 특정 그룹에 권한이 부여됩니다. 액세스 패턴은 서로 다른 역할로 식별되며 Active Directory 그룹에 매핑됩니다. 단일 데이터 세트에 속한 객체는 일반적으로 특정 그룹에 대한 권한이 있는 계층에 상주하며 다양한 데이터 카테고리에 대한 여러 디렉터리를 보유합니다.
예를 들어 stg 디렉터리는 재무 데이터의 스테이징 영역입니다. stg 폴더에는 fin-loader 그룹의 읽기 및 쓰기 권한이 있습니다. 이 스테이징 영역에서 ETL 파이프라인을 나타내는 다른 애플리케이션 계정 그룹 fin-etl은 이 디렉터리에 대한 읽기 전용 액세스 권한을 가집니다. ETL 파이프라인에서는 데이터를 처리한 후 제공되는 app 디렉터리에 저장합니다. 이 액세스 패턴을 사용하기 위해 app 디렉터리가 ETL 데이터 작성에 사용되는 ID인 fin-etl 그룹의 읽기/쓰기 액세스 권한과 결과 데이터를 사용하는 fin-reader 그룹의 읽기 전용 액세스 권한을 가집니다.
Hadoop 온프레미스 암호화
Hadoop에서는 미사용 데이터 및 전송 중인 데이터를 암호화하는 방법을 제공합니다. 미사용 데이터를 암호화할 때는 자바 기반의 키 암호화 또는 공급업체가 제공하는 암호화 솔루션을 사용해 HDFS를 암호화하면 됩니다. HDFS는 암호화 영역을 지원하므로 서로 다른 키를 사용해 다양한 파일을 암호화할 수 있습니다. 각 암호화 영역은 영역이 생성될 때 지정되는 단일 암호화 영역 키와 연결됩니다.
암호화 영역 내의 각 파일에는 고유한 데이터 암호화 키(DEK)가 있습니다. DEK는 HDFS에서 직접 처리되지 않습니다. HDFS는 암호화된 데이터 암호화 키(EDEK)만 처리합니다. 클라이언트에서는 EDEK를 복호화한 다음 얻은 DEK를 사용해 데이터를 읽고 씁니다. HDFS 데이터 노드에서는 단순히 암호화된 바이트 스트림을 확인합니다.
Hadoop 노드 간 데이터 전송은 전송 레이어 보안(TLS)을 사용해 암호화할 수 있습니다. Hadoop의 두 구성요소 간에 통신이 이루어질 때 TLS에서 암호화와 인증을 제공합니다. 일반적으로 Hadoop은 구성요소 간의 TLS를 위해 내부 CA 서명 인증서를 사용합니다.
Hadoop 온프레미스 감사
감사는 보안에서 중요한 요소입니다. 감사를 통해 의심스러운 활동을 찾아내고 리소스에 액세스한 사용자 기록을 볼 수 있습니다. 보통은 Hadoop 감사 추적 등의 데이터 관리 목적으로 Cloudera Navigator 및 기타 타사 도구를 사용합니다. 이러한 도구는 Hadoop 데이터 저장소의 데이터 및 해당 데이터를 사용한 계산에 대한 가시성과 제어를 제공합니다. 데이터 감사로 시스템 내의 모든 활동에 대한 변경 불가능한 완전한 기록을 캡처할 수 있습니다.
Google Cloud의 Hadoop
전통적인 온프레미스 Hadoop 환경에서는 Hadoop 보안의 4가지 요소(인증, 승인, 암호화, 감사)가 다양한 구성요소에 의해 통합되고 처리됩니다. Google Cloud에서는 Dataproc 및 Compute Engine의 Hadoop 외부에 있는 다른 Google Cloud 구성요소에 의해 처리됩니다.
Google Cloud 리소스는 웹 기반 인터페이스인 Google Cloud 콘솔을 사용해 관리할 수 있습니다. 명령줄 사용에 익숙한 경우 더 빠르고 편리한 Google Cloud CLI를 사용할 수도 있습니다. 로컬 컴퓨터에 gcloud CLI를 설치하거나 Cloud Shell의 인스턴스를 사용해 gcloud 명령어를 실행하면 됩니다.
Hadoop Google Cloud 인증
Google Cloud에는 서비스 계정과 사용자 계정이라는 두 가지 유형의 Google ID가 있습니다. 대부분의 Google API는 Google ID를 사용한 인증을 요구합니다. 인증 없이 작동(API 키 사용)하는 Google Cloud API도 몇 개 있지만 모든 API는 서비스 계정을 인증해서 사용하는 것이 좋습니다.
서비스 계정은 비공개 키를 사용해 ID를 설정합니다. 사용자 계정은 OAUTH 2.0 프로토콜을 사용해 최종 사용자를 인증합니다. 자세한 내용은 인증 개요를 참조하세요.
Hadoop Google Cloud 승인
Google Cloud는 인증된 ID의 리소스 집합에 대한 권한을 지정하는 여러 가지 방법을 제공합니다.
IAM
Google Cloud에서는 어떤 사용자(주 구성원)가 어떤 리소스에 대한 어떤 액세스 권한(역할)을 갖는지 정의하여 액세스 제어를 관리할 수 있는 Identity and Access Management(IAM)를 제공합니다.
IAM을 사용하면 Google Cloud 리소스에 대한 액세스 권한을 부여하고 다른 리소스에 대한 무단 액세스를 방지할 수 있습니다. IAM으로 최소 권한의 보안 원칙을 구현하여 최소한의 필요한 리소스 액세스 권한만 부여할 수 있습니다.
서비스 계정
서비스 계정은 개별 최종 사용자가 아닌 애플리케이션 또는 가상 머신에 속하는 특별한 유형의 Google 계정입니다. 애플리케이션에서 서비스 계정 사용자 인증 정보를 사용하면 다른 Cloud API에 자신을 인증할 수 있습니다. 또한 각 인스턴스에 할당된 서비스 계정에 따라 인스턴스와 주고받는 트래픽을 허용하거나 거부하는 방화벽 규칙도 만들 수 있습니다.
Dataproc 클러스터는 Compute Engine VM 위에 구축됩니다. Dataproc 클러스터를 만들 때 커스텀 서비스 계정을 할당하면 이 계정이 클러스터의 모든 VM에 할당됩니다. 그러면 클러스터에서 Google Cloud 리소스에 대한 정밀한 액세스 및 제어가 가능해집니다. 서비스 계정을 지정하지 않으면 Dataproc VM에서 기본 Google 관리 Compute Engine 서비스 계정을 사용합니다. 이 계정에는 기본적으로 폭넓은 프로젝트 편집자 역할이 있어 광범위한 권한이 부여됩니다. 프로덕션 환경에서는 Dataproc 클러스터를 만들 때 기본 서비스 계정을 사용하지 않는 것이 좋습니다.
서비스 계정 권한
Dataproc/Hadoop 클러스터에 커스텀 서비스 계정을 할당하면 클러스터의 VM 인스턴스에 부여된 액세스 범위와 서비스 계정에 부여된 IAM 역할의 조합에 따라 서비스 계정의 액세스 수준이 결정됩니다. 커스텀 서비스 계정을 사용하여 인스턴스를 설정하려면 액세스 범위와 IAM 역할을 모두 구성해야 합니다. 기본적으로 이 메커니즘은 다음과 같이 적용됩니다.
- 액세스 범위를 통해 인스턴스의 액세스 권한을 승인합니다.
- IAM에서 인스턴스가 사용하는 서비스 계정에 부여된 역할로만 액세스 권한을 제한합니다.
- 액세스 범위와 IAM 역할이 교차하는 권한이 해당 인스턴스의 최종 권한이 됩니다.
Google Cloud 콘솔에서 Dataproc 클러스터 또는 Compute Engine 인스턴스를 만들 때 인스턴스의 액세스 범위를 선택합니다.
Dataproc 클러스터 또는 Compute Engine 인스턴스에는 기본 액세스 허용 설정과 함께 사용하도록 정의된 액세스 범위 집합이 있습니다.
선택 가능한 많은 액세스 범위가 존재하지만 새 VM 인스턴스 또는 클러스터를 만들 때 모든 Cloud API에 대한 전체 액세스 허용(콘솔에서) 또는 https://www.googleapis.com/auth/cloud-platform 액세스 범위(Google Cloud CLI 사용 시)를 설정하는 것이 좋습니다. 이렇게 설정한 범위에서는 모든 Google Cloud 서비스에 대한 액세스 권한이 승인됩니다. 범위를 설정한 후 IAM 역할을 클러스터 서비스 계정에 할당하여 액세스 권한을 제한하는 것이 좋습니다.
이 계정은 Google Cloud 액세스 범위에 관계없이 이 세 가지 역할 이외의 작업을 수행할 수 없습니다. 자세한 내용은 서비스 계정 권한 문서를 참조하세요.
IAM과 Apache Sentry 및 Apache Ranger의 비교
IAM은 Apache Sentry 및 Apache Ranger와 비슷한 역할을 합니다. IAM은 역할을 통해 액세스 권한을 정의합니다. 다른 Google Cloud 구성요소에 대한 액세스 권한이 이러한 역할로 정의되며 서비스 계정과 연결됩니다. 동일한 서비스 계정을 사용하는 모든 인스턴스가 다른 Google Cloud 리소스에 대해 같은 액세스 권한을 보유한다는 의미입니다. 이 인스턴스에 액세스할 수 있는 사용자는 누구나 서비스 계정과 동일한 Google Cloud 리소스 액세스 권한도 갖게 됩니다.
Dataproc 클러스터 및 Compute Engine 인스턴스에는 Google 사용자 및 그룹을 Linux 사용자 및 그룹에 매핑하는 메커니즘이 없습니다. 하지만 Linux 사용자 및 그룹을 만들 수는 있습니다. Dataproc 클러스터 또는 Compute Engine VM 내에서 HDFS 권한과 Hadoop 사용자 및 그룹 매핑이 그대로 적용됩니다. 이 매핑을 사용하면 HDFS에 대한 액세스 권한을 제한하거나 YARN 큐를 사용해 리소스 할당을 적용할 수 있습니다.
Dataproc 클러스터 또는 Compute Engine VM의 애플리케이션에서 Cloud Storage 또는 BigQuery와 같은 외부 리소스에 액세스해야 하는 경우 애플리케이션이 클러스터의 VM에 할당한 서비스 계정의 ID로 인증됩니다. 이후 IAM을 사용하여 애플리케이션에 필요한 최소 수준의 액세스 권한을 클러스터의 커스텀 서비스 계정에 부여하면 됩니다.
Cloud Storage 권한
Dataproc은 스토리지 시스템으로 Cloud Storage를 사용합니다. Dataproc은 로컬 HDFS 시스템도 제공하지만 Dataproc 클러스터를 삭제하면 HDFS를 사용할 수 없게 됩니다. 애플리케이션의 HDFS 의존도가 높지 않다면 Cloud Storage를 사용해 Google Cloud를 최대한 활용하는 것이 좋습니다.
Cloud Storage에는 스토리지 계층 구조가 없습니다. 디렉터리 구조는 파일 시스템의 구조와 비슷합니다. POSIX 유사 권한도 없습니다. IAM 사용자 계정 및 서비스 계정을 통한 액세스 제어는 버킷 수준에서 설정할 수 있습니다. Linux 사용자를 기반으로 한 권한은 적용되지 않습니다.
Hadoop Google Cloud 암호화
몇 가지 예외는 있지만 Google Cloud 서비스에서는 다양한 암호화 방법을 사용해 고객의 미사용 콘텐츠 및 전송 중인 콘텐츠를 암호화합니다. 암호화는 자동으로 이루어지므로 고객이 별도의 조치를 취하지 않아도 됩니다.
예를 들어 영구 디스크에 저장된 새 데이터는 256비트 고급 암호화 표준(AES-256)으로 암호화되며 각 암호화 키는 정기적으로 순환되는 루트(마스터) 키 모음으로 암호화됩니다. Google Cloud는 Gmail 및 Google의 사내 데이터를 비롯한 여러 Google 프로덕션 서비스에서 사용되는 것과 동일한 암호화 및 키 관리 정책, 암호화 라이브러리, 신뢰할 수 있는 루트를 사용하고 있습니다.
(대부분의 온프레미스 Hadoop 구현과 달리) 암호화는 Google Cloud의 기본 기능이기 때문에 자체 암호화 키를 사용하려는 경우가 아니라면 암호화 구현을 걱정할 필요가 없습니다. Google Cloud에서는 고객 관리 암호화 키 솔루션과 고객 제공 암호화 키 솔루션도 제공합니다. 암호화 키를 직접 관리하거나 온프레미스 환경에 암호화 키를 저장하는 것도 가능합니다.
자세한 내용은 저장 데이터 암호화 및 전송 중인 데이터 암호화를 참조하세요.
Hadoop Google Cloud 감사
Cloud 감사 로그에서는 각 프로젝트 및 조직의 몇 가지 로그 유형을 유지관리할 수 있습니다. Google Cloud 서비스에서 감사 로그 항목을 이 로그에 작성하여 Google Cloud 프로젝트에서 '누가, 언제, 어디서, 무엇을 했는지' 파악할 수 있습니다.
감사 로그와 감사 로그 작성 서비스에 대한 자세한 내용은 Cloud 감사 로그를 참조하세요.
마이그레이션 프로세스
Google Cloud에서 Hadoop 작업을 안전하고 효율적으로 실행하려면 이 섹션에 나온 프로세스를 따르세요.
이 섹션에서는 Google Cloud 환경을 설정한 것으로 가정합니다. 여기에는 Google Workspace에서 사용자 및 그룹 만들기가 포함됩니다. 이 사용자 및 그룹은 수동으로 관리되거나 Active Directory와 동기화되며 모든 구성을 완료하여 Google Cloud가 사용자 인증과 관련해 정상적으로 작동한다고 가정합니다.
ID 관리자 결정
대부분의 Google 고객은 Cloud ID를 사용해 ID를 관리합니다. 하지만 Google Cloud ID와 별도로 기업 ID를 관리하는 고객도 있습니다. 이러한 경우 POSIX 및 SSH 권한으로 클라우드 리소스에 대한 최종 사용자 액세스 권한을 지정합니다.
독립적인 ID 시스템을 사용하는 경우 먼저 Google Cloud 서비스 계정 키를 만들어 다운로드합니다. 그런 다음 다운로드한 서비스 계정 키 파일에 적절한 POSIX 스타일의 액세스 권한을 부여해 온프레미스 POSIX 및 SSH 보안 모델을 Google Cloud 모델과 연결하면 됩니다. 이러한 키 파일에 대한 온프레미스 ID의 액세스를 허용하거나 거부합니다.
이 같은 방법을 사용하면 자체 ID 관리 시스템에서 감사 기능을 담당하게 됩니다. 감사 추적을 제공하려면 에지 노드에서 사용자 로그인의 SSH 로그(서비스 계정 키 파일 포함)를 사용하거나 보다 강력하고 명확한 키 저장소 메커니즘을 선택해 사용자로부터 서비스 계정 사용자 인증 정보를 가져오면 됩니다. 이 경우 키 저장소 계층에서 '서비스 계정 명의 도용'이 감사 로그로 기록됩니다.
단일 데이터 프로젝트 또는 여러 데이터 프로젝트의 사용 여부 결정
조직에 데이터가 많을 경우 데이터를 여러 개의 Cloud Storage 버킷으로 나눌 수 있습니다. 여러 프로젝트에 이러한 데이터 버킷을 배포하는 방법에 대해서도 생각해 봐야 합니다. Google Cloud를 시작할 때 소량의 데이터를 이전하고 시간이 지나 워크로드 및 애플리케이션을 이전함에 따라 이전하는 데이터 양을 늘리고 싶을 수도 있습니다.
한 프로젝트에 모든 데이터 버킷을 두면 편할 것이라 생각할 수도 있지만 일반적으로 좋은 방법이 아닙니다. 데이터 액세스를 관리하려면 버킷에 대한 IAM 역할을 가진 평면화된 디렉터리 구조를 사용하세요. 버킷이 늘어나면 관리가 힘들어질 수 있습니다.
재무 부서의 프로젝트, 법무 부서의 프로젝트 등 각 조직의 전용 프로젝트에 데이터를 저장하는 것도 방법입니다. 이 경우 각 부서에서 자체 권한을 독립적으로 관리합니다.
데이터를 처리하는 중에 임시 버킷의 액세스 또는 생성이 필요할 수도 있습니다. 데이터 과학자가 자신이 소유하지 않은 프로세스에서 생성된 데이터에 액세스하는 등 신뢰할 수 있는 경계 곳곳으로 처리가 분할될 수도 있습니다.
다음 다이어그램에서는 단일 데이터 프로젝트 및 여러 데이터 프로젝트의 Cloud Storage에서 일반적인 데이터 구성을 보여줍니다.
조직에 가장 적합한 방식을 결정할 때 고려해야 할 주요사항은 다음과 같습니다.
단일 데이터 프로젝트 사용:
- 버킷 수가 많지 않은 한, 모든 버킷을 쉽게 관리할 수 있습니다.
- 권한 부여는 주로 관리자 그룹의 구성원이 수행합니다.
여러 데이터 프로젝트 사용:
- 프로젝트 소유자에게 관리 책임을 위임하는 것이 더 쉽습니다.
- 조직마다 권한 부여 프로세스가 다를 때 유용한 방식입니다. 예를 들어 마케팅 부서 프로젝트와 법무 부서 프로젝트의 권한 부여 프로세스가 다를 수 있습니다.
애플리케이션 식별 및 서비스 계정 생성
Dataproc/Hadoop 클러스터가 Cloud Storage 등의 다른 Google Cloud 리소스와 상호작용하는 경우 Dataproc/Hadoop에서 실행될 모든 애플리케이션과 필요한 액세스 권한을 파악해야 합니다. 예를 들어 캘리포니아의 재무 데이터를 financial-ca 버킷에 채우는 ETL 작업이 있다고 가정해 보겠습니다. 이 ETL 작업은 버킷에 대한 읽기 및 쓰기 액세스 권한이 필요합니다. Hadoop을 사용할 애플리케이션을 식별한 후 이러한 애플리케이션 각각의 서비스 계정을 만들면 됩니다.
이 액세스 권한은 Dataproc 클러스터 또는 Compute Engine의 Hadoop 내부에 있는 Linux 사용자에게는 영향을 미치지 않는다는 점을 잊지 마세요.
서비스 계정에 대한 자세한 내용은 서비스 계정 생성 및 관리를 참조하세요.
서비스 계정에 권한 부여
각 애플리케이션이 여러 Cloud Storage 버킷에 대해 어떤 액세스를 필요로 하는지 알고 있는 경우에는 관련 애플리케이션 서비스 계정에 권한을 설정할 수 있습니다. BigQuery 또는 Bigtable 등의 다른 Google Cloud 구성요소에 액세스해야 하는 애플리케이션의 경우 서비스 계정을 사용해 이러한 구성요소에 권한을 부여할 수도 있습니다.
예를 들어 operation-ca-etl을 ETL 애플리케이션으로 지정하여 캘리포니아의 마케팅 및 판매 데이터를 조합해 재무 부서 데이터 버킷에 보고서를 작성할 수 있는 권한을 부여하는 방식으로 작업 보고서를 생성할 수 있습니다. 이러한 경우 자체 부서에 대한 읽기 및 쓰기 액세스 권한을 갖도록 marketing-report-ca 및 sales-report-ca 애플리케이션을 설정하면 됩니다. 다음 다이어그램에서는 이 같은 설정을 보여줍니다.
최소 권한 원칙을 따라야 합니다. 각 사용자 또는 서비스 계정에 작업에 필요한 최소한의 권한만 제공하는 것이 이 원칙의 내용입니다. Google Cloud의 기본 권한은 사용 편의성을 제공하고 설정 시간을 단축하도록 최적화되어 있습니다. 보안 및 규정 준수 검토를 통과할 가능성이 높은 Hadoop 인프라를 구축하려면 권한을 더욱 제한적으로 설계해야 합니다. 초기에 노력을 기울여 이러한 전략을 문서화해 놓으면 규정을 준수하는 안전한 파이프라인을 제공할 수 있을 뿐만 아니라 보안 및 규정 준수팀에서 아키텍처를 검토할 때에도 도움이 됩니다.
클러스터 만들기
액세스 권한의 계획 및 구성 후, 생성한 서비스 계정을 사용해 Dataproc 클러스터 또는 Compute Engine의 Hadoop을 만들 수 있습니다. 각 클러스터는 해당 서비스 계정에 부여된 권한을 기반으로 다른 Google Cloud 구성요소에 액세스할 수 있습니다. Google Cloud 액세스 권한에 대한 올바른 액세스 범위를 제공한 후 서비스 계정 액세스 권한으로 조정해야 합니다. 특히 Compute Engine의 Hadoop에서 액세스 문제가 발생하면 이 권한을 확인하세요.
특정 서비스 계정으로 Dataproc 클러스터를 만들려면 다음 gcloud 명령어를 사용합니다.
gcloud dataproc clusters create [CLUSTER_NAME] \
--service-account=[SERVICE_ACCOUNT_NAME]@[PROJECT+_ID].iam.gserviceaccount.com \
--scopes=scope[, ...]
다음과 같은 이유로 기본 Compute Engine 서비스 계정은 사용하지 않는 것이 좋습니다.
- 여러 클러스터 및 Compute Engine VM에서 기본 Compute Engine 서비스 계정을 사용하면 감사가 어려워집니다.
- 기본 Compute Engine 서비스 계정의 프로젝트 설정이 다를 수 있습니다. 즉, 클러스터에 필요한 것보다 많은 권한을 가질 수도 있습니다.
- 기본 Compute Engine 서비스 계정을 변경할 경우 클러스터 및 클러스터에서 실행되는 애플리케이션이 의도치 않은 영향을 받거나 중단될 수 있습니다.
클러스터별 IAM 권한 설정
한 프로젝트에 많은 클러스터를 배치하면 클러스터를 편하게 관리할 수는 있지만 액세스를 보호하는 데에는 최선의 방법이 아닙니다. 예를 들어 프로젝트 A에 클러스터 1과 2가 있는 경우 사용자가 클러스터 1에서 작업하기 위한 권한은 적절하지만 클러스터 2에 대한 권한이 너무 많을 수 있습니다. 더 심각한 문제는 액세스하면 안 되는데도 이 프로젝트에 존재한다는 이유로 클러스터 2에 대한 액세스 권한을 갖게 될 수 있다는 것입니다.
프로젝트에 많은 클러스터가 포함된 경우 다음 그림과 같이 클러스터에 대한 액세스가 복잡해질 수 있습니다.
클러스터를 더 작은 프로젝트로 그룹화한 후 클러스터마다 IAM을 개별적으로 구성하면 액세스를 보다 정밀하게 제어할 수 있습니다. 그러면 사용자가 자신을 대상으로 한 클러스터의 액세스 권한을 보유하게 되고 다른 클러스터에 대한 액세스는 제한됩니다.
클러스터 액세스 제한
서비스 계정을 사용해 액세스 권한을 설정하면 Dataproc/Hadoop 및 다른 Google Cloud 구성요소 간의 상호작용이 보호됩니다. 하지만 Dataproc/Hadoop에 액세스할 수 있는 사용자를 완전히 제어하지는 못합니다. 예를 들어 클러스터에 있는 사용자에게 Dataproc/Hadoop 클러스터 노드의 IP 주소가 있다면 여전히 SSH를 사용해 클러스터에 연결(일부의 경우)하거나 작업을 제출할 수 있습니다. 온프레미스 환경에서는 시스템 관리자가 일반적으로 서브넷, 방화벽 규칙, Linux 인증, 기타 전략을 사용해 Hadoop 클러스터에 대한 액세스를 제한합니다.
Dataproc/Compute Engine의 Hadoop을 실행할 때 Google Workspace 또는 Google Cloud 인증 수준에서 액세스를 제한할 수 있는 방법은 다양합니다. 그러나 이 가이드에서는 Google Cloud 구성요소 수준의 액세스에 초점을 맞추고 있습니다.
OS 로그인을 사용한 SSH 로그인 제한
온프레미스 환경에서 사용자가 Hadoop 노드에 연결하지 못하도록 제한하려면 경계 액세스 제어, Linux 수준 SSH 액세스, sudoer 파일을 설정해야 합니다.
Google Cloud의 경우 다음 프로세스를 사용하면 Compute Engine 인스턴스 연결에 대한 사용자 수준의 SSH 제한을 구성할 수 있습니다.
- 프로젝트 또는 개별 인스턴스에 OS 로그인 기능을 사용 설정합니다.
- 자신 및 다른 주 구성원에 필요한 IAM 역할을 부여합니다.
- 선택적으로 자신 및 다른 주 구성원에 대해 사용자 계정에 커스텀 SSH 키를 추가합니다. 또는 인스턴스에 연결할 때 Compute Engine에서 자동으로 키를 생성할 수도 있습니다.
프로젝트에서 1개 이상의 인스턴스에 OS 로그인을 사용 설정하면 이 인스턴스는 프로젝트 또는 조직에 필요한 IAM 역할이 있는 사용자 계정의 연결만 허용합니다.
예를 들어 다음 프로세스에 따라 사용자에게 인스턴스 액세스 권한을 부여할 수 있습니다.
사용자에게 필요한 인스턴스 액세스 역할을 부여합니다. 사용자에게 다음과 같은 역할이 있어야 합니다.
iam.serviceAccountUser역할다음 로그인 역할 중 하나:
- 관리자 권한을 부여하지 않는
compute.osLogin역할 - 관리자 권한을 부여하는
compute.osAdminLogin역할
- 관리자 권한을 부여하지 않는
조직 외부의 Google ID가 인스턴스에 액세스하도록 허용하려는 조직 관리자는 조직 수준에서 외부 ID에
compute.osLoginExternalUser역할을 부여합니다. 그런 다음 프로젝트 또는 조직 수준에서 외부 ID에compute.osLogin또는compute.osAdminLogin역할도 부여해야 합니다.
필요한 역할을 구성한 후 Compute Engine 도구를 사용해 인스턴스에 연결합니다. Compute Engine에서 자동으로 SSH 키를 생성해 사용자 계정과 연결합니다.
OS 로그인 기능에 대한 자세한 내용은 OS 로그인을 사용하여 인스턴스 액세스 관리를 참조하세요.
방화벽 규칙을 사용한 네트워크 액세스 제한
Google Cloud에서 서비스 계정을 사용해 인그레스 또는 이그레스 트래픽을 필터링하는 방화벽 규칙을 만들 수도 있습니다. 이러한 방식은 다음과 같은 환경에서 특히 효과적입니다.
- Hadoop에 액세스해야 하는 사용자 또는 애플리케이션이 광범위해 IP 기반의 규칙을 만들기가 어렵습니다.
- 임시 Hadoop 클러스터 또는 클라이언트 VM을 실행 중이어서 IP 주소가 자주 변경됩니다.
방화벽 규칙을 서비스 계정과 함께 사용하면 특정한 서비스 계정만 허용하도록 특정 Dataproc/Hadoop 클러스터의 액세스 권한을 설정할 수 있습니다. 그러면 해당 서비스 계정으로 실행되는 VM만 지정된 수준의 클러스터 액세스 권한을 갖게 됩니다.
다음 다이어그램에서는 서비스 계정을 사용해 액세스를 제한하는 프로세스를 보여줍니다. dataproc-app-1, dataproc-1, dataproc-2, app-1-client가 모두 서비스 계정입니다. 방화벽 규칙에 따라 dataproc-app-1에서 dataproc-1 및 dataproc-2에 액세스할 수 있고 app-1-client를 사용하는 클라이언트에서 dataproc-1에 액세스할 수 있습니다. 스토리지의 경우 Cloud Storage 액세스 및 권한이 방화벽 규칙 대신 서비스 계정에 대한 Cloud Storage 권한으로 제한됩니다.
이 구성에서 설정된 방화벽 규칙은 다음과 같습니다.
| 규칙 이름 | 설정 |
|---|---|
dp1 |
대상: dataproc-1소스: [IP 범위] 소스 SA: dataproc-app-1[포트] 허용 |
dp2 |
대상: dataproc-2소스: [IP 범위] 소스 SA: dataproc-app-2[포트] 허용 |
dp2-2 |
대상: dataproc-2소스: [IP 범위] 소스 SA: dataproc-app-1[포트] 허용 |
app-1-client |
대상: dataproc-1소스: [IP 범위] 소스 SA: app-1-client[포트] 허용 |
서비스 계정과 함께 사용하는 방화벽 규칙에 대한 자세한 내용은 서비스 계정별 소스 및 대상 필터링을 참조하세요.
의도치 않게 열린 방화벽 포트 확인
적절한 방화벽 규칙의 마련은 클러스터에서 실행되는 웹 기반 사용자 인터페이스를 노출할 때도 중요합니다. 이러한 인터페이스에 연결하는 인터넷에 열려 있는 방화벽 포트가 없어야 합니다. 열린 포트와 부적절하게 구성된 방화벽 규칙이 사용되면 승인되지 않은 사용자가 임의 코드를 실행할 수 있습니다.
예를 들어 Apache Hadoop YARN은 YARN 웹 인터페이스와 동일한 포트를 공유하는 REST API를 제공합니다. 기본적으로 YARN 웹 인터페이스에 액세스할 수 있는 사용자는 애플리케이션을 만들고 작업을 제출할 수 있으며 Cloud Storage 작업을 수행할 수도 있습니다.
Dataproc 네트워킹 구성을 검토하고 SSH 터널을 생성하여 클러스터 컨트롤러에 대한 보안 연결을 설정합니다. 서비스 계정과 함께 사용하는 방화벽 규칙에 대한 자세한 내용은 서비스 계정별 소스 및 대상 필터링을 참조하세요.
멀티 테넌트 클러스터의 경우
일반적으로 애플리케이션마다 별도의 Dataproc/Hadoop 클러스터를 실행하는 것이 좋습니다. 하지만 멀티 테넌트 클러스터를 사용해야 하는 경우 보안 요구사항을 위반하지 않으려면 Dataproc/Hadoop 클러스터 내에 Linux 사용자 및 그룹을 만든 후 YARN 큐를 통해 승인 및 리소스 할당을 제공하면 됩니다. Google 사용자와 Linux 사용자 간에 직접 매핑이 이루어지지 않으므로 인증을 구현해야 합니다. 클러스터에서 Kerberos를 사용하면 클러스터 범위 내에서 인증 수준을 강화할 수 있습니다.
데이터 과학자 등의 사용자들이 Hadoop 클러스터를 사용해 데이터를 탐색하고 모델을 빌드하는 경우가 있습니다. 이러한 상황에서는 동일한 데이터 액세스 권한을 공유하는 사용자를 그룹화하고 전용 Dataproc/Hadoop 클러스터를 하나 만드는 것이 좋습니다. 그러면 해당 데이터에 대한 액세스 권한이 있는 그룹에 사용자를 추가할 수 있습니다. Linux 사용자를 기반으로 클러스터 리소스도 할당할 수 있습니다.