Delta Sharing을 위한 보안 모범 사례

 

데이터 레이크하우스를 통해 데이터 관리 아키텍처를 통합하고 사일로를 제거하며 모든 사용 사례에 대해 공통 플랫폼을 활용할 수 있었습니다. 단일 플랫폼에서 데이터 웨어하우징 및 AI 사용 사례를 통합하는 것은 조직에 있어 큰 발전이지만, 일단 그 단계를 밟고 나면 다음 질문은 "수신자가 액세스하는 데 사용하는 클라이언트, 도구 또는 플랫폼에 관계없이 해당 데이터를 간단하고 안전하게 공유하려면 어떻게 해야 하는가?"입니다. 다행히 레이크하우스에도 이 질문에 대한 답이 있습니다. 바로 Delta Sharing을 통한 데이터 공유입니다.

Delta Sharing

Delta Sharing은 데이터가 상주하는 플랫폼에 관계없이 실시간으로 조직 내부 및 조직 간에 데이터를 안전하게 공유할 수 있는 세계 최초의 개방형 프로토콜입니다. 이는 레이크하우스 아키텍처의 개방성을 위한 핵심 구성 요소이며, 이전에는 불가능했던 방식으로 데이터 팀 및 액세스 패턴을 구성할 수 있게 해주는 핵심 요소입니다. 예를 들어 데이터 메시와 같은 방식입니다.

설계부터 안전하게

Delta Sharing은 처음부터 보안을 염두에 두고 구축되었으며, 오픈 소스 버전 또는 관리형 버전을 사용하든 관계없이 다음 기능을 즉시 활용할 수 있습니다.

• 클라이언트에서 서버 및 스토리지 계정까지의 엔드투엔드 TLS 암호화
• 데이터 액세스에 사용되는 사전 서명된 URL과 같은 짧은 수명 주기 자격 증명
• Unity Catalog를 통한 공유 데이터 세트에 대한 액세스 관리, 추적 및 감사 용이

이 블로그의 일부로 공유할 모범 사례는 추가적인 것으로, 고객이 위험 프로필 및 데이터 민감도에 따라 적절한 보안 제어를 정렬할 수 있도록 합니다.

보안 모범 사례

민감한 데이터를 공유하기 위해 Delta Sharing을 사용하는 것에 대한 모범 사례 권장 사항은 다음과 같습니다.

1. 요구 사항에 따라 오픈 소스 버전과 관리형 버전 평가
2. 모든 메타스토어에 대해 적절한 수신자 토큰 수명 설정
3. 자격 증명 로테이션 프로세스 수립
4. 공유, 수신자 및 파티션에 대한 적절한 세분성 수준 고려
5. IP 액세스 목록 구성
6. Databricks 감사 로깅 구성
7. 스토리지 계정에 대한 네트워크 제한 구성
8. 스토리지 계정에 대한 로깅 구성

1. 오픈 소스 버전과 관리형 버전을 요구 사항에 따라 평가

앞서 설명했듯이 Delta Sharing은 처음부터 보안을 최우선으로 고려하여 구축되었습니다. 그러나 관리형 버전을 사용하는 데는 이점이 있습니다.

• Databricks의 Delta Sharing은 Unity Catalog에서 제공되며, 이를 통해 한 곳에서 중앙 집중식으로 서로 다른 사용자 집합 간의 모든 데이터 세트에 대한 세분화된 액세스를 제공할 수 있습니다. 오픈 소스 버전의 경우 다양한 데이터 액세스 권한이 있는 데이터 세트를 여러 공유 서버에 분리해야 하며, 해당 서버 및 기본 스토리지 계정에 액세스 제한을 적용해야 합니다. 배포 편의를 위해 오픈 소스 버전과 함께 docker 이미지가 제공되지만, 대기업에 걸쳐 배포를 확장하는 것은 이를 관리하는 팀에 상당한 오버헤드를 발생시킬 수 있다는 점에 유의해야 합니다.
• Databricks 레이크하우스 플랫폼의 나머지 부분과 마찬가지로 Unity Catalog는 관리형 서비스로 제공됩니다. 서비스의 가용성, 가동 시간 및 유지 관리에 대해 걱정할 필요가 없습니다. 저희가 대신 걱정해 드리기 때문입니다.
• Unity Catalog를 사용하면 즉시 포괄적인 감사 로깅 기능을 구성할 수 있습니다.
• 데이터 소유자는 SQL 구문을 사용하여 공유를 관리할 수 있습니다. 또한 공유를 관리하기 위한 REST API도 제공됩니다. 익숙한 SQL 구문을 사용하면 데이터 공유 방식이 단순화되어 관리 부담이 줄어듭니다.
• 오픈 소스 버전을 사용하면 데이터 공유 구성, 인프라 및 관리를 책임져야 하지만, 관리형 버전에서는 이 모든 기능이 즉시 제공됩니다.

이러한 이유로 두 버전을 모두 평가하고 요구 사항에 따라 결정을 내릴 것을 권장합니다. 설정 및 사용 편의성, 즉시 사용 가능한 거버넌스 및 감사, 아웃소싱된 서비스 관리가 중요하다면 관리형 버전이 올바른 선택이 될 것입니다.

2. 모든 메타스토어에 대해 적절한 수신자 토큰 수명 설정

Delta Sharing을 활성화할 때 수신자 자격 증명에 대한 토큰 수명을 구성합니다. 토큰 수명을 0으로 설정하면 수신자 토큰이 만료되지 않습니다.

적절한 토큰 수명을 설정하는 것은 규제, 규정 준수 및 평판 측면에서 매우 중요합니다. 만료되지 않는 토큰은 큰 위험이므로, 모범 사례로 짧은 수명의 토큰을 사용하는 것이 좋습니다. 수명이 잘못 설정된 토큰의 사용을 조사하는 것보다 수명이 만료된 수신자에게 새 토큰을 부여하는 것이 훨씬 쉽습니다.

적절한 초, 분, 시간 또는 일 후에 토큰이 만료되도록 구성하는 방법에 대한 문서를 참조하십시오(AWS, Azure).

3. 자격 증명 로테이션 프로세스 수립

기존 토큰 만료, 자격 증명이 손상되었을 수 있다는 우려, 또는 토큰 수명을 수정하여 해당 만료 시간을 존중하는 새 자격 증명을 발급하려는 경우 등 자격 증명을 로테이션하려는 데에는 여러 가지 이유가 있습니다.

이러한 요청이 예측 가능하고 시기적절하게 처리되도록 하려면, 가급적이면 확립된 SLA와 함께 프로세스를 수립하는 것이 중요합니다. 이는 IT 서비스 관리 프로세스에 잘 통합될 수 있으며, 해당 메타스토어의 지정된 데이터 소유자, 데이터 관리자 또는 DBA가 적절한 작업을 완료합니다.

자격 증명을 로테이션하는 방법에 대한 문서를 참조하십시오(AWS, Azure). 특히:

• 자격 증명을 즉시 로테이션해야 하는 경우 --existing-token-expire-in-seconds를 0으로 설정하면 기존 토큰이 즉시 만료됩니다.
• Databricks는 자격 증명이 손상되었을 수 있다는 우려가 있을 때 다음과 같은 조치를 권장합니다.
  1. 수신자의 공유 액세스 권한을 취소합니다.
  2. 수신자를 로테이션하고 --existing-token-expire-in-seconds를 0으로 설정하여 기존 토큰이 즉시 만료되도록 합니다.
  3. 새 활성화 링크를 보안 채널을 통해 대상 수신자에게 공유하세요.
  4. 활성화 URL에 액세스한 후, 수신자에게 다시 공유 액세스 권한을 부여하세요.

4. 공유, 수신자 및 파티션에 대한 적절한 세분화 수준 고려

Databricks의 관리형 버전에서는 각 공유에 하나 이상의 테이블이 포함될 수 있으며, 여러 데이터 세트에 대한 액세스를 관리하기 위한 세분화된 컨트롤을 사용하여 하나 이상의 수신자와 연결될 수 있습니다. 이를 통해 단독으로 오픈 소스를 사용하는 것보다 훨씬 어려운 방식으로 여러 데이터 세트에 대한 세분화된 액세스를 제공할 수 있습니다. 또한 테이블의 일부만 공유에 추가하기 위해 파티션 사양을 제공함으로써 이보다 한 단계 더 나아갈 수 있습니다(AWS, Azure의 파티션 사양에 대한 설명서 참조).

이러한 기능을 활용하여 공유 및 수신자를 구현하는 것이 좋습니다. 최소 권한 원칙을 따르도록 하여, 수신자 자격 증명이 손상될 경우 가능한 가장 적은 수의 데이터 세트 또는 가장 작은 데이터 하위 집합과 연결되도록 하세요.

5. IP 액세스 목록 구성

기본적으로 공유에 액세스하는 데 필요한 모든 것은 유효한 Delta Sharing 자격 증명 파일입니다. 따라서 네트워크 수준에서 자격 증명이 사용될 수 있는 위치를 제한하여 자격 증명이 손상될 가능성을 최소화하는 것이 중요합니다.

Delta Sharing IP 액세스 목록(AWS, Azure의 설명서 참조)을 구성하여 수신자 액세스를 신뢰할 수 있는 IP 주소(예: 회사 VPN의 공용 IP)로 제한하세요.

IP 액세스 목록과 액세스 토큰을 결합하면 무단 액세스 위험이 상당히 줄어듭니다. 누군가가 무단으로 데이터에 액세스하려면 토큰 사본을 획득하고 동일한 승인된 네트워크에 있어야 하는데, 이는 토큰 자체를 획득하는 것보다 훨씬 어렵습니다.

6. Databricks 감사 로깅 구성

Databricks Lakehouse Platform에서 발생하는 모든 활동, Delta Sharing 관련 활동을 포함한 감사 로그는 귀하의 권위 있는 기록입니다. 따라서 각 클라우드에 대해 Databricks 감사 로그를 구성하고(AWS, Azure의 설명서 참조) 해당 로그를 처리하고 중요한 이벤트를 모니터링/경고하는 자동화된 파이프라인을 설정하는 것이 좋습니다.

이 주제에 대한 자세한 내용과 Delta Live Tables 파이프라인 설정, Databricks SQL 경고 구성, 다음과 같은 중요한 질문에 답하기 위한 SQL 쿼리 실행에 필요한 모든 코드를 포함하여 당사의 동반 블로그인 감사 로그로 Databricks Lakehouse Platform 모니터링을 확인해 보세요.

• 가장 인기 있는 Delta 공유는 무엇인가요?
• 어느 국가에서 Delta 공유에 액세스하고 있나요?
• IP 액세스 목록 제한이 적용되지 않은 상태로 Delta 공유 수신자가 생성되고 있나요?
• 신뢰할 수 있는 IP 주소 범위를 벗어난 IP 액세스 목록 제한으로 Delta 공유 수신자가 생성되고 있나요?
• Delta 공유 액세스 시도가 IP 액세스 목록 제한을 실패하고 있나요?
• Delta 공유 액세스 시도가 반복적으로 인증에 실패하고 있나요?

7. 스토리지 계정에 대한 네트워크 제한 구성

공유 서버에서 델타 공유 요청이 성공적으로 인증되면, 짧은 수명의 자격 증명 배열이 생성되어 클라이언트에 반환됩니다. 그런 다음 클라이언트는 이러한 URL을 사용하여 클라우드 공급자로부터 직접 관련 파일에 액세스합니다. 이 설계는 서버를 통해 결과를 스트리밍하지 않고도 대역폭에서 병렬로 전송이 가능하다는 것을 의미합니다. 또한 보안 관점에서 볼 때, 데이터 자체가 누구나 어디서든 액세스할 수 있는 스토리지 계정에 호스팅되는 경우, 수신자 수준에서 공유를 보호하는 것이 무의미하므로 스토리지 계정에 대해 공유 수신자와 유사한 네트워크 제한을 구현하는 것이 좋습니다.

Azure

Azure에서는 Databricks가 Unity Catalog를 대신하여 기본 스토리지 계정에 액세스하기 위해 관리 ID(현재 공개 미리 보기)를 사용하는 것을 권장합니다. 그런 다음 고객은 스토리지 방화벽을 구성하여 신뢰할 수 있는 프라이빗 엔드포인트, 가상 네트워크 또는 델타 공유 클라이언트가 데이터에 액세스하는 데 사용할 수 있는 공용 IP 범위로만 액세스를 제한할 수 있습니다. 자세한 내용은 Databricks 담당자에게 문의하세요.

중요 참고: 다시 한번, 적용할 네트워크 수준 제한을 결정할 때 잠재적인 모든 사용 사례를 고려하는 것이 중요합니다. 예를 들어, 델타 공유를 통한 데이터 액세스 외에도 하나 이상의 Databricks 작업 공간에서 데이터에 액세스해야 할 가능성이 높으므로, 해당 작업 공간에서 사용하는 관련 신뢰할 수 있는 프라이빗 엔드포인트, 가상 네트워크 또는 공용 IP 범위에서 액세스를 허용해야 합니다.

AWS

AWS에서는 Databricks가 S3 버킷에 대한 액세스를 제한하기 위해 S3 버킷 정책을 사용하는 것을 권장합니다. 예를 들어, 다음 Deny 문은 신뢰할 수 있는 IP 주소 및 VPC에 대한 액세스를 제한하는 데 사용될 수 있습니다.

중요 참고: 적용할 네트워크 수준 제한을 결정할 때 잠재적인 모든 사용 사례를 고려하는 것이 중요합니다. 예를 들어:

• 관리형 버전을 사용하는 경우, 사전 서명된 URL은 Unity Catalog에서 생성되므로 해당 지역의 Databricks 제어 영역 NAT IP에서 액세스를 허용해야 합니다.
• 하나 이상의 Databricks 작업 공간에서 데이터에 액세스해야 할 가능성이 높으므로, 기본 S3 버킷이 동일한 지역에 있고 VPC 엔드포인트를 사용하여 S3에 연결하거나 데이터 영역 트래픽이 확인되는 공용 IP 주소(예: NAT 게이트웨이를 통해)를 사용하는 경우 관련 VPC ID에서 액세스를 허용해야 합니다.
• 회사 네트워크 내에서 연결이 끊어지는 것을 방지하기 위해 Databricks는 항상 회사 VPN의 공용 IP와 같이 하나 이상의 알려진 신뢰할 수 있는 IP 주소에서 액세스를 허용하는 것을 권장합니다. 이는 Deny 조건이 AWS 콘솔 내에서도 적용되기 때문입니다.

네트워크 수준 제한 외에도, Unity Catalog에서 사용하는 IAM 역할에 대한 기본 S3 버킷 액세스를 제한하는 것이 좋습니다. 그 이유는 우리가 보았듯이, Unity Catalog는 AWS IAM/S3에서 제공하는 거친 권한으로는 불가능한 방식으로 데이터에 대한 세분화된 액세스를 제공하기 때문입니다. 따라서 누군가가 S3 버킷에 직접 액세스할 수 있게 되면, 이러한 세분화된 권한을 우회하여 의도한 것보다 더 많은 데이터에 액세스할 수 있습니다.

중요 참고: 위와 마찬가지로, 거부 조건은 AWS 콘솔 내에서도 적용되므로, 소수의 권한 있는 사용자가 AWS UI/API에 액세스하는 데 사용할 수 있는 관리자 역할에 대한 액세스도 허용하는 것이 좋습니다.

8. 스토리지 계정에 대한 로깅 구성

기본 스토리지 계정에 대한 네트워크 수준 제한을 적용하는 것 외에도, 누군가가 이를 우회하려고 시도하는지 모니터링하고 싶을 것입니다. 따라서 Databricks는 다음을 권장합니다:

• AWS에서 S3 서버 액세스 로깅을 설정하고 관련 모니터링 및 경고 설정
• Azure에서 진단 로깅을 설정하고 관련 모니터링 및 경고 설정

결론

레이크하우스는 파편화된 데이터 아키텍처와 액세스 패턴으로 이어졌던 대부분의 데이터 관리 문제를 해결했으며, 조직이 데이터에서 가치를 얻는 데 걸리는 시간을 심각하게 제한했습니다. 이제 데이터 팀이 이러한 문제에서 벗어났으므로, 개방적이지만 안전한 데이터 공유가 다음 개척지가 되었습니다.

Delta Sharing은 데이터가 상주하는 플랫폼에 관계없이 실시간으로 내부 및 조직 간에 데이터를 안전하게 공유하기 위한 세계 최초의 개방형 프로토콜입니다. 그리고 위에서 설명한 모범 사례와 Delta Sharing을 함께 사용하면 조직은 엔터프라이즈 규모에서 사용자와 파트너, 고객과 쉽게 데이터를 안전하게 교환할 수 있습니다.

기존 데이터 마켓플레이스는 데이터 제공업체와 데이터 소비자에게 비즈니스 가치를 극대화하는 데 실패했지만, Databricks Marketplace를 사용하면 Databricks Lakehouse Platform을 활용하여 더 많은 고객에게 도달하고 비용을 절감하며 모든 데이터 제품에서 더 많은 가치를 제공할 수 있습니다.

데이터 제공업체 파트너가 되는 데 관심이 있다면, 문의해 주시면 감사하겠습니다!

(이 글은 AI의 도움을 받아 번역되었습니다. 원문이 궁금하시다면 여기를 클릭해 주세요)