Azure HDInsight의 엔터프라이즈 보안 일반 정보 및 지침

아티클
02/23/2024

보안 HDInsight 클러스터를 배포할 때 배포 및 클러스터 관리를 보다 용이하게 하는 몇 가지 모범 사례가 있습니다. 몇 가지 일반적인 정보와 지침은 여기에 설명되어 있습니다.

보안 클러스터 사용

권장

동시에 여러 사용자가 클러스터를 사용합니다.
사용자는 동일한 데이터에 대한 다양한 수준의 액세스 권한을 가집니다.

필요하지 않음

자동 작업만 실행하게 되며(예: 단일 사용자 계정) 표준 클러스터로 충분합니다.
표준 클러스터를 사용하여 데이터 가져오기를 수행하고, 사용자가 분석 작업을 실행할 수 있는 다른 보안 클러스터에서 동일한 스토리지 계정을 사용할 수 있습니다.

로컬 계정 사용

공유 사용자 계정 또는 로컬 계정을 사용하는 경우 해당 계정을 사용하여 구성 또는 서비스를 변경한 사람을 식별하기 어렵습니다.
사용자가 더 이상 조직의 일부가 아니면 로컬 계정을 사용하는 데 문제가 있을 수 있습니다.

Ranger

정책

기본적으로 Ranger는 정책으로 거부를 사용합니다.
권한 부여를 사용하도록 설정한 서비스를 통해 데이터 액세스를 수행하는 경우:
- Ranger 권한 부여 플러그 인이 사용되며 요청 컨텍스트가 제공됩니다.
- Ranger는 서비스에 대해 구성된 정책을 적용합니다. Ranger 정책이 실패하면 파일 시스템에 대한 액세스 확인이 지연됩니다. MapReduce와 같은 일부 서비스는 요청을 제출하는 동일한 사용자가 해당 파일/폴더를 소유하고 있는지만 확인합니다. Hive와 같은 서비스는 소유권 일치 또는 적절한 파일 시스템 권한(rwx)을 확인합니다.
Hive의 경우 사용자는 만들기/업데이트/삭제 권한을 수행할 수 있는 권한을 보유하는 것 외에도 스토리지의 디렉터리 및 모든 하위 디렉터리에 대한 rwx 권한이 있어야 합니다.
정책을 개인 대신 그룹(권장)에 적용할 수 있습니다.
Ranger 권한 부여자는 각 요청에 대해 해당 서비스에 대한 모든 Ranger 정책을 평가합니다. 이 평가는 작업이나 쿼리를 수락하는 데 걸리는 시간에 영향을 미칠 수 있습니다.

스토리지 액세스

스토리지 유형이 WASB인 경우에는 OAuth 토큰은 관련이 없습니다.
Ranger가 권한 부여를 수행하는 경우 관리 ID를 사용하여 스토리지 액세스가 발생합니다.
Ranger가 권한 부여를 수행하지 않은 경우 스토리지 액세스는 사용자의 OAuth 토큰을 사용하여 수행됩니다.

계층적 네임스페이스

계층적 네임스페이스를 사용하도록 설정하지 않은 경우:

상속된 사용 권한이 없습니다.
작동하는 유일한 파일 시스템 권한은 Azure Portal에서 직접 사용자에게 할당되는 스토리지 데이터 XXXX Azure 역할입니다.

기본 HDFS 사용 권한

기본적으로 사용자는 HDFS의 / 폴더에 대한 액세스 권한이 없습니다(성공적인 액세스를 위해서는 스토리지 Blob 소유자 역할에 속해야 함).
mapreduce 및 기타 작업을 위한 스테이징 디렉터리의 경우 사용자 특정 디렉터리가 만들어지고 sticky _wx 권한이 제공됩니다. 사용자는 아래에 파일과 폴더를 만들 수 있지만 다른 항목은 볼 수 없습니다.

URL 인증

URL 인증을 사용하도록 설정한 경우:

구성에는 URL 인증에 포함된 접두사(예: adl://)가 포함됩니다.
이 URL에 대한 액세스 권한이 있는 경우 Ranger는 사용자가 허용 목록에 있는지 확인합니다.
Ranger는 세분화된 정책을 확인하지 않습니다.

Ranger 감사 로그 관리

Ranger 감사 로그가 hn0 헤드 노드에서 너무 많은 디스크 공간을 소비하지 않도록, 로그를 유지할 일 수를 변경할 수 있습니다.

Ambari UI에 로그인합니다.
서비스>Ranger>Configs>고급>고급 ranger-solr-configuration으로 이동합니다.
'최대 보존 일수'를 7일 이하로 변경합니다.
변경 내용이 적용되려면 영향을 받는 구성 요소 저장 및 다시 시작을 선택합니다.

사용자 지정 Ranger DB 사용

Ranger 메타데이터의 고가용성을 위해 ESP 클러스터와 함께 사용할 외부 Ranger DB를 배포하는 것이 좋습니다. 이렇게 하면 클러스터를 사용할 수 없는 경우에도 정책을 사용할 수 있습니다. 외부 데이터베이스는 고객 관리형이므로 DB 크기를 조정하고 여러 ESP 클러스터에서 데이터베이스를 공유하는 기능도 있습니다. Azure Portal, Azure Resource Manager, Azure CLI 등을 사용하여 ESP 클러스터 만들기 프로세스 중에 외부 Ranger DB를 지정할 수 있습니다.

Ranger 사용자 동기화를 매일 실행하도록 설정

HDInsight ESP 클러스터는 Ranger가 AD 사용자를 매시간 자동으로 동기화하도록 구성됩니다. Ranger 동기화는 사용자 동기화이며 AD 인스턴스에 추가 부하를 유발할 수 있습니다. 따라서 Ranger 사용자 동기화 간격을 24시간으로 변경하는 것이 좋습니다.

Ambari UI에 로그인합니다.
서비스>Ranger>Configs>고급>ranger-ugsync-site로 이동합니다.
ranger.usersync.sleeptimeinmillisbetweensynccycle 속성을 86400000(밀리초 단위로 24시간)으로 설정합니다.
변경 내용이 적용되려면 영향을 받는 구성 요소 저장 및 다시 시작을 선택합니다.

리소스 그룹

클러스터 리소스 간을 구분할 수 있도록 각 클러스터에 대해 새 리소스 그룹을 사용합니다.

NSG, 방화벽 및 내부 게이트웨이

NSG(네트워크 보안 그룹)를 사용하여 가상 네트워크를 잠급니다.
방화벽을 사용하여 아웃바운드 액세스 정책을 처리합니다.
퍼블릭 인터넷에 열려 있지 않은 내부 게이트웨이를 사용합니다.

Microsoft Entra ID

Microsoft Entra ID(Microsoft Entra ID)는 Microsoft의 클라우드 기반 ID 및 액세스 관리 서비스입니다.

정책

IP 주소 기반 정책을 사용하여 조건부 액세스 정책을 사용하지 않도록 설정합니다. 이렇게 하려면 클러스터가 배포되는 VNET에서 서비스 엔드포인트를 사용하도록 설정해야 합니다. MFA에 외부 서비스(Microsoft Entra ID 이외)를 사용하는 경우 IP 주소 기반 정책이 작동하지 않습니다.
AllowCloudPasswordValidation 정책은 페더레이션된 사용자에 대해 필요합니다. HDInsight는 사용자 이름/암호를 직접 사용하여 Microsoft Entra ID에서 토큰을 가져오기 때문에 모든 페더레이션된 사용자에 대해 이 정책을 사용하도록 설정해야 합니다.
신뢰할 수 있는 IP를 사용하는 조건부 액세스 무시가 필요한 경우 서비스 엔드포인트를 사용하도록 설정합니다.

Groups

항상 그룹을 사용하여 클러스터를 배포합니다.
Microsoft Entra ID를 사용하여 그룹 멤버 자격을 관리합니다(클러스터의 개별 서비스를 관리하는 것보다 더 간편함).

사용자 계정

각 시나리오에 고유한 사용자 계정을 사용합니다. 예를 들어, 가져오기를 위해 한 계정을 사용하고, 쿼리 또는 다른 처리 작업을 위해 다른 계정을 사용합니다.
개별 정책 대신 그룹 기반 Ranger 정책을 사용합니다.
더 이상 클러스터에 대한 액세스 권한이 없는 사용자를 관리하는 방법에 대한 계획을 세워야 합니다.

Microsoft Entra Domain Services

Microsoft Entra Domain Services는 Windows Server Active Directory와 완전히 호환되는 도메인 조인, 그룹 정책, LDAP(Lightweight Directory Access Protocol) 및 Kerberos/NTLM 인증과 같은 관리되는 도메인 서비스를 제공합니다.

보안 클러스터가 도메인에 가입하려면 Microsoft Entra Domain Services가 필요합니다. HDInsight는 너무 많은 오류 요소, 자격 증명 공유, DNS 권한 등을 도입하므로 온-프레미스 도메인 컨트롤러 또는 사용자 지정 도메인 컨트롤러에 종속되지 않습니다. 자세한 내용은 Microsoft Entra Domain Services FAQ를 참조하세요.

올바른 Microsoft Entra Domain Services SKU 선택

관리되는 도메인을 만들 때 다양한 수준의 성능 및 기능을 제공하는 다양한 SKU 중에서 선택할 수 있습니다. 인증 요청에 Microsoft Entra Domain Services 인스턴스를 사용할 ESP 클러스터 및 기타 애플리케이션의 양은 조직에 적합한 SKU를 결정합니다. 관리되는 도메인에서 높은 CPU가 표시되거나 비즈니스 요구 사항이 변경되는 경우 SKU를 업그레이드할 수 있습니다.

Microsoft Entra Domain Services 인스턴스

.onmicrosoft.com domain을 사용하여 인스턴스를 만듭니다. 이러한 방식으로 도메인을 지원하는 DNS 서버는 많지 않을 것입니다.
LDAPS에 대한 자체 서명된 인증서를 만들고 Microsoft Entra Domain Services에 업로드합니다.
클러스터를 배포하는 데 피어링된 가상 네트워크를 사용합니다. HDInsight ESP 클러스터를 배포하는 많은 팀이 있는 경우에 유용합니다. 이렇게 하면 도메인 컨트롤러를 사용하여 가상 네트워크에서 포트(NSG)를 열 필요가 없습니다.
가상 네트워크에 대한 DNS를 적절히 구성합니다. Microsoft Entra Domain Services 도메인 이름은 hosts 파일 항목 없이 확인되어야 합니다.
아웃바운드 트래픽을 제한하는 경우 HDInsight의 방화벽 지원을 확인하세요.

Microsoft Entra Domain Services 복제본 세트 고려

Microsoft Entra Domain Services 관리되는 도메인을 만들 때 고유한 네임스페이스를 정의하고 두 개의 DC(도메인 컨트롤러)를 선택한 Azure 지역에 배포합니다. 이 DC 배포를 복제본 세트라고 합니다. 복제본 세트를 추가하면 복원력이 제공되고 Azure HDInsight 클러스터에 중요한 인증 서비스의 가용성이 보장됩니다.

범위가 지정된 사용자/그룹 동기화 구성

ESP 클러스터에 대해 Microsoft Entra Domain Services를 사용하도록 설정하면 Microsoft Entra ID 또는 범위가 지정된 그룹 및 해당 구성원의 모든 사용자 및 그룹을 동기화하도록 선택할 수 있습니다. 최상의 성능을 위해 "범위 지정" 동기화를 선택하는 것이 좋습니다.

범위가 지정된 동기화는 다른 그룹 선택 항목으로 수정하거나 필요한 경우 "모든" 사용자 및 그룹으로 변환할 수 있습니다. Microsoft Entra Domain Services 인스턴스를 삭제하고 다시 만들지 않으면 동기화 유형을 "모두"에서 "범위가 지정됨"으로 변경할 수 없습니다.

Microsoft Entra ID에서 Microsoft Entra Domain Services로 동기화된 속성

Microsoft Entra Connect는 온-프레미스에서 Microsoft Entra ID로 동기화됩니다.
Microsoft Entra Domain Services는 Microsoft Entra ID에서 동기화됩니다.

Microsoft Entra Domain Services는 Microsoft Entra ID의 개체를 주기적으로 동기화합니다. Azure Portal의 Microsoft Entra Domain Services 블레이드에 동기화 상태가 표시됩니다. 동기화의 각 스테이지에서 고유한 속성이 충돌하고 이름이 바뀔 수 있습니다. Microsoft Entra ID에서 Microsoft Entra Domain Services로의 속성 매핑에 주의하세요.

자세한 내용은 Microsoft Entra UserPrincipalName 채우기 및 Microsoft Entra Domain Services 동기화 작동 방식을 참조하세요.

암호 해시 동기화

암호는 다른 개체 유형과 다르게 동기화됩니다. 되돌릴 수 없는 암호 해시만 Microsoft Entra ID 및 Microsoft Entra Domain Services에서 동기화됩니다.
온-프레미스에서 Microsoft Entra ID로 AD Connect를 통해 사용하도록 설정해야 합니다.
Microsoft Entra Domain Services 동기화에 대한 Microsoft Entra ID는 자동입니다(대기 시간은 20분 미만).
암호 해시는 암호가 변경된 경우에만 동기화됩니다. 암호 해시 동기화를 사용하도록 설정하면 기존 암호는 복구 불가능하게 저장되므로 자동으로 동기화되지 않습니다. 암호를 변경하면 암호 해시가 동기화됩니다.

매일 실행되도록 Ambari LDAP 동기화 설정

새 LDAP 사용자를 Ambari에 동기화하는 프로세스는 매시간 실행되도록 자동으로 구성됩니다. 매시간 실행하면 클러스터의 헤드 노드 및 AD 인스턴스에 과도한 부하가 발생할 수 있습니다. 성능 개선을 위해, Ambari LDAP 동기화를 실행하는 /opt/startup_scripts/start_ambari_ldap_sync.py 스크립트를 하루에 한 번 실행하는 것이 좋습니다. 이 스크립트는 crontab 작업을 통해 실행되며 클러스터 헤드 노드의 "/etc/cron.hourly/" 디렉터리에 저장됩니다.

하루에 한 번 실행하려면 다음 단계를 수행합니다.

ssh에서 hn0으로
스크립트를 cron daily 폴더: sudo mv /etc/cron.hourly/ambarildapsync /etc/cron.daily/ambarildapsync로 이동합니다.
crontab 작업: sudo service cron reload의 변경 사항을 적용합니다.
ssh에서 hn1로, 1-3단계 반복

필요한 경우 Ambari REST API를 사용하여 새 사용자 및 그룹을 즉시 수동으로 동기화할 수 있습니다.

컴퓨터 개체 위치

각 클러스터는 단일 OU와 연결됩니다. 내부 사용자는 OU에 프로비저닝됩니다. 모든 노드는 동일한 OU의 도메인에 조인됩니다.

Active Directory 관리 도구

Windows Server VM에 Active Directory 관리 도구를 설치하는 방법에 대한 단계는 관리 도구 설치를 참조하세요.

문제 해결

클러스터 만들기가 반복적으로 실패합니다.

가장 일반적인 이유는 다음과 같습니다.

DNS 구성이 올바르지 않습니다. 클러스터 노드의 도메인 조인이 실패합니다.
NSG가 너무 제한적이어서 도메인 조인을 방지합니다.
관리 ID에 충분한 권한이 없습니다.
클러스터 이름의 처음 6자가 고유하지 않습니다(다른 라이브 클러스터 또는 삭제된 클러스터를 사용하는 경우).

인증 설정 및 구성

UPN(사용자 계정 이름)

모든 서비스에 대해 소문자를 사용하세요. UPN은 ESP 클러스터에서 대/소문자를 구분하지 않습니다.
UPN 접두사는 Microsoft Entra Domain Services의 SAMAccountName과 일치해야 합니다. 메일 필드와 일치하지 않아도 됩니다.

Ambari 구성의 LDAP 속성

HDInsight 클러스터 구성에 영향을 주는 Ambari 속성의 전체 목록은 AMBARI LDAP 인증 설정을 참조하세요.

도메인 사용자 keytab 생성

ESP 클러스터 만들기 프로세스 중에 모든 서비스 keytab이 자동으로 생성됩니다. 클러스터와 다른 서비스 및/또는 인증이 필요한 작업 간에 보안 통신을 사용하도록 설정하려면 도메인 사용자 이름에 대한 keytab을 생성할 수 있습니다.

클러스터 VM 중 하나에서 ktutil을 사용하여 Kerberos keytab을 만듭니다.


ktutil
ktutil: addent -password -p <username>@<DOMAIN.COM> -k 1 -e aes256-cts-hmac-sha1-96
Password for <username>@<DOMAIN.COM>: <password>
ktutil: wkt <username>.keytab
ktutil: q

TenantName 및 DomainName이 다른 경우 -s 옵션을 사용하여 SALT 값을 추가해야 합니다. Kerberos keytab을 만들 때 적절한 SALT 값을 확인하려면 HDInsight FAQ 페이지를 확인합니다.

LDAP 인증서 갱신

HDInsight는 ESP(Enterprise Security Package)를 사용하여 클러스터에 사용하는 관리 ID에 대한 인증서를 자동으로 갱신합니다. 그러나 Microsoft Entra Domain Services 및 ADLS Gen2에 다른 관리 ID를 사용하는 경우 갱신 프로세스가 실패할 수 있는 제한 사항이 있습니다. 인증서를 성공적으로 갱신할 수 있는지 확인하려면 아래 2가지 권장 사항을 따릅니다.

ADLS Gen2 및 Microsoft Entra Domain Services 클러스터에 대해 서로 다른 관리 ID를 사용하는 경우, 둘 다 스토리지 blob 데이터 소유자 및 HDInsight 도메인 서비스 참여자 역할을 할당해야 합니다.
HDInsight 클러스터에는 인증서 업데이트 및 기타 유지 관리를 위해 공용 IP가 필요하므로 클러스터에서 공용 IP를 거부하는 모든 정책을 제거해야 합니다.

Share via