데이터브릭스 Unity Catalog의 시스템 테이블을 사용하여 레이크하우스 보안 모니터링 개선
레이크하우스가 데이터 중심 조직에서 점점 더 중요해짐에 따라 예상치 못한 이벤트, 운영 중단, 보안 사고로 인해 예상치 못한 새로운 방식으로 운영이 중단될 수 있는 위험도 커지고 있습니다. 데이터브릭스는 고객이 이러한 새로운 위협에 대비하고 이전과는 전혀 다른 방식으로 레이크하우스에 대한 가시성을 확보할 수 있도록 몇 가지 주요 통합 가시성 기능을 제공합니다.
보안 관점에서 볼 때, 조직이 현대 사회에 적응하는 방법은 Zero Trust Architecture (ZTA) 모델을 따라 "절대 신뢰하지 말고 항상 확인하라"는 원칙을 따르는 것입니다. 이 블로그에서는 데이터브릭스 레이크하우스 플랫폼에서 ZTA를 시작하는 방법을 보여드리고, 일련의 SQL 쿼리와 알림을 자동으로 생성하는 데이터브릭스 노트북을 공유할 것입니다. 평소 이런 종류의 작업을 위해 Terraform을 사용하시는 분들도 여기에서 코드를 확인하시기 바랍니다.
시스템 테이블이란?
시스템 테이블은 Delta Lake가 지원하고 Unity Catalog가 관리하는 중앙 집중식 운영 데이터 저장소 역할을 합니다. 시스템 테이블은 모든 언어로 쿼리할 수 있으므로 BI부터 AI, 심지어 생성형 AI에 이르기까지 다양한 사용 사례에 활용할 수 있습니다. 시스템 테이블을 기반으로 고객들이 구현하기 시작한 가장 일반적인 사용 사례는 다음과 같습니다:
- 이용 분석
- 사용량/비용 예측
- 효율성 분석
- 보안 및 규정 준수 감사
- SLO(서비스 수준 목표) 분석 및 보고
- 실행가능한 DataOps
- 데이터 품질 모니터링 및 보고
다양한 스키마를 사용할 수 있지만, 이 블로그에서는 주로 system.access.audit
테이블에 초점을 맞추고, 더 구체적으로 이 테이블을 사용하여 데이터브릭의 제로 트러스트 아키텍처를 보강하는 방법에 대해 설명하겠습니다.
Audit Logs
system.access.audit
테이블은 데이터브릭스 레이크하우스 플랫폼에서 발생하는 모든 중요한 이벤트에 대한 기록 시스템 역할을 합니다. 이 테이블을 활용할 수 있는 몇 가지 사용 사례는 다음과 같습니다:
- 보안 및 법률 준수
- 감사 분석
- 사용 제한 정책(AUP) 모니터링 및 조사
- 보안 및 사고 대응팀(SIRT, Security and Incident Response Team) 조사
- 포렌식 분석
- 장애 조사 및 사후 분석
- 침해 지표 (IoC, Indicators of Compromise) 탐지
- 공격 지표(IoA, Indicators of Attack) 탐지
- 위협 모델링
- 위협 헌팅 (Threat hunting)
과거에는 이러한 종류의 로그를 분석하기 위해 고객이 클라우드 스토리지를 설정하고, 클라우드 보안주체(Principal)와 정책을 구성한 다음, 데이터를 처리하고 준비하기 위해 ETL 파이프라인을 구축하고 예약해야 했습니다. 이제 시스템 테이블이 발표되면서 고객은 옵트인만 하면 필요한 모든 데이터를 자동으로 사용할 수 있게 됩니다. 지원되는 모든 클라우드에서 정확 히 동일하게 작동하는 점도 큰 장점입니다.
시스템 테이블을 이용하여 레이크하우스에서 "Never Trust, Always Verify" 구현
제로 트러스트 아키텍처(ZTA)의 주요 개념은 다음과 같습니다:
- 사용자 및 액세스에 대한 지속적인 확인
- 가장 권한이 높은 사용자 및 서비스 계정 식별
- 데이터 흐름 매핑
- 최소 권한 원칙에 따라 액세스 권한 할당
- 무엇보다 중요한 모니터링
이 블로그에서는 주로 모니터링의 중요성에 초점을 맞추겠지만, 데이터 중심 조직이 제로 트러스트 아키텍처를 구현하는데 Unity Catalog의 다양한 기능이 어떻게 도움이 되는지 간략히 언급할 필요가 있습니다:
- 사용자 및 액세스에 대한 지속적인 검증:
- Unity Catalog는 모든 요청에 대해 권한을 검증하여 권한이 부여된 사용자에게 수명이 짧고 범위가 축소된 토큰을 부여합니다.
- Unity Catalog의 ID 액세스 관리는 첫 번째 사전 예방적 방어선을 제공하지만, "절대 신뢰하지 말고 항상 확인하라"는 원칙을 지키기 위해서는 이를 소급 모니터링(retrospective monitoring)과 결합해야 합니다. 액세스 관리만으로는 잘못 구성된 권한이나 정책을 감지하고 해결할 수 없으며, 조직 내에서 누군가가 퇴사하거나 역할을 변경할 때 발생하는 권한 이동에 대해서도 마찬가지입니다.
- 가장 권한이 높은 사용자와 서비스 계정을 식별:
- Unity Catalog에 기본 제공되는
system.information_schema
는 누가 어떤 보안 항목에 액세스할 수 있는지에 대한 중앙 집중식 뷰를 제공하여, 관리자가 가장 권한이 높은 사용자를 쉽게 식별할 수 있도록 합니다. information_schema
는 현재 뷰를 제공하지만, 이를system.access.audit
와 결합하여 시간 경과에 따른 권한/부여/취소를 모니터링할 수 있습니다.
- Unity Catalog에 기본 제공되는
- 데이터 흐름 매핑:
- 최소 권한 원칙에 따라 액세스 권한을 할당:
- Unity Catalog의 통합 인터페이스를 사용하면 데이터와 AI 자산에 대한 액세스 정책 관리가 크게 간소화되며, 모든 클라우드 또는 데이터 플랫폼에 일관되게 정책을 적용할 수 있습니다.
- 더욱이, 시스템 테이블은 기본적으로 최소 권한 원칙을 따릅니다!
무엇보다 중요한 모니터링
효과적인 모니터링은 효과적인 제로 트러스트 아키텍처의 핵심 기반 중 하나입니다. 사람들은 효과적인 모니터링을 위해 필요한 로그를 캡처하고 조사나 사고가 발생했을 때만 쿼리하는 것으로 충분하다고 생각하는 함정에 빠지기 쉽습니다. 하지만 "절대 신뢰하지 말고 항상 확인하라"는 원칙에 부합하려면 그보다 더 적극적인 자세를 취해야 합니다. 다행히 Databricks SQL을 사용하면 system.access.audit
테이블에 대한 SQL 쿼리를 쉽게 작성한 다음 자동으로 실행되도록 예약하여 잠재적으로 의심스러운 이벤트를 즉시 알려줄 수 있습니다.
Quickstart 노트북
Databricks workspace에 repo를 복제하고(AWS 와 Azure 설명서 참조) create_queries_and_alerts 노트북을 실행합니다. 자동으로 생성되는 40개 이상의 쿼리 및 알림의 몇 가지 예는 다음과 같습니다:
쿼리 / 알림 이름 | 쿼리 / 알림 설명 |
---|---|
Repeated Failed Login Attempts | 지난 24시간 이내에 60분 동안 로그인 시도가 반복적으로 실패한 경우. |
Data Downloads from the Control Plane | 노트북, Databricks SQL, Unity Catalog 볼륨, MLflow에서 결과를 다운로드하는 횟수가 많거나, 지난 24시간 이내에 쿼리 결과를 포함할 수 있는 형식으로 노트북을 내보내는 횟수가 많음. |
IP Access List Failures | 지난 24시간 이내에 신뢰할 수 없는 IP 주소에서 계정 또는 워크스페이스에 액세스하려는 모든 시도 |
Databricks Access to Customer Workspaces | 지난 24시간 이내에 데이터브릭스 지원 프로세스를 통해 워크스페이스에 로그인한 모든 횟수. 이 액세스는 지원 티켓에 연결되며, 워크스페이스 구성에 따라 해당 액세스를 비활성화할 수도 있습니다. |
Destructive Activities | 지난 24시간 동안 60분 동안 삭제 이벤트 수가 많은 경우 |
Potential Privilege Escalation | 지난 24시간 동안 60분 동안 권한 변경 횟수가 많은 경우. |
Repeated Access to Secrets | 지난 24시간 동안 60분 동안 secrets에 액세스하려는 시도를 반복한 횟수가 많은 경우. 자격 증명을 도용하려는 시도를 감지하는 데 사용될 수 있습니다. |
Repeated Unauthorized Data Access Requests | 지난 24시간 동안 60분 동안 Unity Catalog 객체들에 대한 무단 액세스가 반복적으로 시도된 경우. 반복적인 요청 실패는 권한 에스컬레이션, 데이터 유출 시도 또는 공격자가 무차별 암호 대입을 통해 데이터에 액세스하려는 시도일 수 있습니다. |
Antivirus Scan Infected Files Detected | 지난 24시간 이내에 호스트에서 발견된 모든 감염된 파일을 탐지. 보안 및 규정 준수 강화 애드온을 사용하는 고객에 해당 |
Suspicious Host Activity | 지난 24시간 이내에 행동 기반 보안 모니터링 에이전트가 플래그가 지정된 의심스러운 이벤트를 탐지. 보안 및 규정 준수 강화 애드온을 사용하는 고객에 해당. |
노트북을 실행한 후 하단으로 스크롤하면 각 SQL 쿼리와 알림에 대한 링크가 있는 HTML 표가 표시됩니다:
알림을 테스트하려면 링크를 따라 새로 고침을 선택하면 됩니다. 알림이 발생되지 않았다면 왼쪽 상단에 녹색으로 OK가 표시됩니다:
알림이 일어난 경우에는 알림을 발생시킨 모든 이벤트를 표로 정리한 이메일이 발송됩니다. 알림이 일정에 따라 실행되도록 설정하려면 편집을 선택한 다음 새로고침을 선택하고 알림을 실행할 빈도를 선택하면 됩니다:
이메일 주소, Slack 채널 또는 MS Teams 등의 알림 대상을 추가하는 것을 포함하여, 필요에 따라 알림을 추가로 커스터마이즈할 수 있습니다. 모든 옵션에 대한 자세한 내용은 AWS 와 Azure용 설명서를 참조하세요.
고급 사용 사례
지금까지 살펴본 모니터링 및 탐지 사용 사례는 비교적 간단하지만, 시스템 테이블은 모든 언어로 쿼리할 수 있기 때문에 기본적으로 옵션의 한계가 없습니다! 다음 아이디어를 고려해 보세요:
- 이전 블로그에서 설명한 것처럼, 노트북의 커맨드에 대한 정적 분석을 수행해 하드코딩된 secrets, 자격 증명 유출 등 의심스러운 행동이나 잘못된 관행을 감지할 수 있습니다.
- 시스템 테이블의 데이터를 HR 시스템과 같은 추가 데이터 소스와 결합해, 예를 들어 휴가 중이거나 안식년 중이거나 퇴사한 것으로 표시되었지만 예기치 않은 활동을 발견했을 때 자동으로 플래그를 지정할 수 있습니다.
system.information_schema
와 같은 데이터와 결합하여, 가장 권한이 높은 사용자에게 초점을 맞추도록 모니터링을 조정할 수 있습니다.- 시스템 테이블의 데이터를 지리적 위치 데이터 집합과 결합하여 액세스 및 데이터 이동 제한 요구 사항에 대한 규정 준수를 모니터링할 수 있습니다. 어떤 모습일지 예시를 보려면
geolocation_function_and_queries.sql
노트북을 살펴보세요:
- 자세한 감사 로그에 대한 LLM 모델을 미세 조정하여 조직의 코딩 관행에 맞는 코딩 도우미를 제공할 수 있습니다.
- 시스템 테이블과
system.information_schema
데이터의 조합에 대해 LLM 모델을 미세 조정하여 데이터 팀과 비즈니스 사용자 모두에게 자연어로 데이터에 대한 질문에 대한 답변을 제공할 수 있습니다. - 비정상적인 이벤트를 감지하도록 비지도 학습 모델을 학습시킬 수 있습니다.
결론
감사 로깅에 대한 마지막 블로그 이후 1년 동안, 데이터브릭스 레이크하우스 플랫폼과 세상은 크게 변했습니다. 그 당시에는 실행 가능한 인사이트를 도출하는 방법에 대해 생각하기도 전에, 필요한 데이터에 액세스하는 것만으로도 여러 단계를 거쳐야 했습니다. 이제 시스템 테이블 덕분에 버튼 클릭 한 번으로 필요한 모든 데이터에 액세스할 수 있습니다. 제로 트러스트 아키텍처(또는 Never Trust, Always Verify)는 시스템 테이블을 통해 구현할 수 있는 수많은 사용 사례 중 하나일 뿐입니다. 지금 바로 AWS 와 Azure 용 문서를 확인하여 데이터브릭스 계정에 시스템 테이블을 활성화하세요!