Databricks에서 자격 증명 기반 공격 감지하기

Databricks에서는 데이터가 가장 가치 있는 자산임을 잘 알고 있습니다. Databricks는 수많은 고객과 협력하여 보안, 개인 정보 보호, 규정 요구 사항을 충족하는 적절한 기능으로 Databricks Data + AI Platform을 안전하게 배포해 왔습니다.

현대의 사이버 공격은 항상 경계가 무너지면서 시작되지 않으며, 유효한 로그인으로 시작됩니다. 공격자가 유출된 세션 쿠키, 개인용 액세스 토큰(PAT) 또는 서비스 주체 자격 증명을 획득하면 초기 침해는 이미 완료된 것입니다. 그 순간부터 공격자의 유일한 목표는 침해된 사용자나 서비스인 것처럼 위장하여 그 속에 섞여 활동하는 것입니다.

하지만 열쇠가 있다고 해서 건물의 구조를 아는 것은 아닙니다. 침입자가 출입증을 훔쳐 보안 구역에 들어간다고 상상해 보세요. 회전문은 통과했을지 몰라도, 경비원을 지나쳐야 하고, 어떤 층에 접근할 수 있는지 알아내야 하며, 금고가 어디에 있는지 찾아내야 합니다. 공격자에게는 실제 임직원이 가진 깊고 지역화된 맥락이 없기 때문에 결국 행동에서 이상 징후가 드러나게 됩니다. 이러한 불규칙성을 찾아내는 것이 바로 공격을 탐지하는 방법입니다.

이 게시물에서는 자격 증명 기반 공격이 Databricks 플랫폼에서 어떻게 전개되는지, Databricks 상세 감사 로그와 Genie를 사용하여 ID의 행동 변화를 감지하는 방법, 침해가 확인된 후 대응하는 방법, 그리고 도난당한 자격 증명이 애초에 할 수 있는 일을 제한하는 제어 기능이 무엇인지 살펴봅니다.

자격 증명 기반 공격을 추적하기 위한 모델

정당한 자격 증명을 통해 접근 권한을 설정할 때, 보안 전문가와 마찬가지로 공격자 역시 ID의 예상되는 행동에서 너무 크게 벗어나면 언제든지 접근 권한이 취소될 수 있음을 이해합니다. 공격자는 한 세트의 자격 증명을 검증하여 환경을 매핑한 후, 다른 세트의 자격 증명을 검색하여 정찰 활동과 연관되지 않은 새로운 ID나 워크스페이스를 통해 돌아오는 비선형적 공격 시퀀싱에 의존합니다. 또한 공격자는 지속성을 설정하지 않고 정보를 수집하거나, 목표를 마무리하기 전에 Databricks 플랫폼으로 다시 들어올 방법을 마련할 수 있습니다.

실제 사례

잘못 설정된 CI/CD 로그에서 개인용 액세스 토큰이 복사된 데이터 엔지니어를 생각해 보세요. 몇 분 안에 이 토큰은 새로운 IP에서 사용되어 이 엔지니어가 한 번도 해본 적 없는 워크스페이스 전반의 시크릿 범위, 카탈로그, 레포를 나열합니다. 서비스 주체 자격 증명을 담고 있는 시크릿이 읽힙니다. 한 시간 후, 엔지니어가 아니라 해당 서비스 주체가 함수를 생성하고, 자신을 관리자 그룹에 추가하며, 몇 가지 초기화 스크립트를 내보냅니다. 이러한 각 이벤트는 평소의 플랫폼 사용처럼 보일 수 있지만, 종합해 보면 하나의 침해가 공격 체인을 따라 이동하고 있음을 보여줍니다.

Databricks에서는 자격 증명 기반 공격과 관련하여 비선형적 이벤트 시퀀싱이 발생할 것으로 예상하며, 개별 이벤트를 관련 없는 이벤트로 취급하는 대신 이 모델을 사용하여 개별벤트를 하나의 조사로 연결합니다.

자격 증명 기반 공격의 6단계

공격자가 Databricks와 같은 PaaS(Platform-as-a-Service) 환경에서 손상된 자격 증명을 활용할 때, 그 활동은 6단계로 그룹화할 수 있습니다. 단, 곧바로 일직선으로 진행되는 경우는 거의 없습니다. 아래의 각 단계는 공격자가 무엇을 하려고 하는지, 그리고 Databricks 감사 로깅 테이블에서 무엇을 찾아야 하는지 설명합니다. 이 가이드를 시작점으로 삼고 환경의 일반적인 자동화에 맞게 조정하세요.

참고: 이벤트는 service_name.action_name 형식으로 기록되며, 예시로는 secrets.getSecret이(가) 있습니다.

1. 공격자가 유효한 자격 증명으로 접근 권한 획득

로그인 자체는 평소와 다름없어 보이는 경우가 많습니다. 자격 증명이 진짜이기 때문에 적법한 소유자와 마찬가지로 인증이 성공합니다. 하지만 로그인 후 몇 분 동안 ID가 수행하는 작업은 일반적인 활동과 크게 다른 경우가 많으며, 대응 팀은 이러한 변화를 감지할 수 있습니다. 데이터 엔지니어 사례에서 도난당한 토큰은 성공적으로 인증되며, 로그인 시 유일한 차이점은 엔지니어가 사용한 적이 없는 소스 IP라는 점입니다. 그 뒤에 이어지는 활동이 눈에 띄는 부분입니다.

공격자 목표: 도난당한 브라우저 세션, 재생된 PAT 또는 서비스 주체 자격 증명 등 유효한 자격 증명으로 워크스페이스에 접근하고, 제어 기능이 허용하도록 설계된 활동 속에 섞여 들어갑니다.

확인해야 할 사항:

• 인증 이벤트를 타임라인의 시작점으로 사용하세요. 로그인만으로는 알람을 울리기에 부족한 경우가 많지만, user_identity, source_ip_address, user_agent, sessionId, request_id 및 workspace_id을(를) 통해 자격 증명이 다음에 수행하는 작업을 추적할 수 있습니다.
• 익숙하지 않은 클라이언트에서 짧은 간격으로 연속해서 도착한 뒤 다른 소스 IP에서 동일한 토큰을 사용하는 accounts.tokenLogin 이벤트를 플래그 지정합니다. 이 패턴은 누군가 도난당한 토큰을 테스트하고 있음을 나타낼 수 있으며, requestParams.tokenId을(를) 통해 이러한 이벤트를 동일한 토큰에 연결할 수 있습니다.
• 예상되는 네트워크에서 예상치 못한 유저 에이전트로 생성된 서비스 주체 OAuth 토큰, 특히 새로운 소스 IP의 활동이 1분 이내에 이어지는 경우 플래그 지정합니다.

2. 공격자의 환경 매핑

다음으로, 공격자는 접근 권한이 취소되기 전에 자격 증명이 도달할 수 있는 범위를 파악해야 합니다. 결과적으로 손상된 ID는 평소의 활동에서 벗어나 몇 초 안에 데이터, 시크릿, 코드, 네트워크 제어 항목을 나열하는 작업을 수행할 수 있습니다. 이 정찰 작업은 보통 여러 서비스에 걸쳐 동시에 진행되며 사용자가 UI를 탐색하는 것보다 빠르게 이동합니다. 시나리오에서 이 단계는 토큰이 사용된 지 몇 분 만에 시크릿 범위, 카탈로그, 레포를 나열하는 호출이 급증하는 것으로, 이는 엔지니어가 이전에 한 번도 수행한 적이 없는 활동입니다.

공격자 목표: 접근 권한이 취소되기 전에 환경 내부로 더 깊이 들어갈 경로를 계획하기 위해 접근 가능한 데이터, 자격 증명, 저장소, 가드레일의 맵을 작성합니다.

확인해야 할 사항:

• 단일 ID가 워크스페이스 및 계정 플레인에서 secrets.listScopes / listSecrets, unityCatalog.listMetastores / listCatalogs / listSchemas / listExternalLocations / listStorageCredentials, repos.listRepos 및 계정 수준 accountsManager.listWorkspaceConfigurations / listNetworkConfigurations / listStorageConfigurations과(와) 같이 빠른 목록 호출을 수행하는지 확인합니다. 예를 들어 1분 이내에 5개 이상의 서로 다른 검색 API가 호출되는 경우는 사용자가 플랫폼을 탐색하는 것으로 보기 어렵습니다.
• 활동을 ID의 기준선과 비교하세요. 기존 ID가 수행하는 최초의 시크릿 열거 또는 비즈니스 쿼리에서 접근 제어 및 구성 스키마에 대한 SHOW TABLES(으)로 전환되는 SQL 세션은 단순히 호출 횟수가 많은 것보다 더 큰 의미를 가집니다. 상세 감사 로깅이 활성화된 경우 commandSubmit은(는) commandText에 쿼리를 보존합니다.
• 검색 시 실패한 요청도 포함하세요. ID의 첫 번째 IpAccessDenied을(를) 조사하고, 특히 accounts.oidcTokenAuthorization이(가) 뒤따르거나 워크스페이스 간에 반복되는 경우를 주의 깊게 살펴보세요. 이 경우 권한 부여는 성공했지만 요청이 차단된 네트워크에서 온 것으로, 신뢰할 수 없는 위치에서 자격 증명이 재생된 가장 초기 기록인 경우가 많습니다.

3. 공격자의 추가 자격 증명 수집

자격 증명 수집에는 보통 여러 단계가 소요됩니다. 공격자는 시크릿 범위를 나열하고, 그 안의 시크릿을 나열한 다음, 유용해 보이는 시크릿을 읽습니다. 검색한 값을 통해 공격자는 다르며 종종 권한이 더 높은 ID로 돌아올 수 있습니다. 이러한 이유로 의심스러운 ID가 읽은 모든 시크릿은 추적할 가치가 있습니다. 데이터 엔지니어 예시에서 공격자는 서비스 주체 자격 증명을 담고 있는 시크릿을 읽습니다. 그 시점부터 조사는 엔지니어와 서비스 주체라는 두 가지 ID를 모두 추적해야 합니다.

공격자 목표: 초기 거점을 새로운 ID에 따른 환경 전체 접근 권한으로 업그레이드하는 토큰, API 키 또는 서비스 주체 시크릿을 가져옵니다.

확인해야 할 사항:

• 호출 진행 상황에 대한 경고입니다. secrets.listScopes 단독으로는 흔하게 발생하며 노이즈가 생깁니다. 하지만 listScopes 뒤에 listSecrets 및 getSecret이 이어지고, 여러 범위에 걸쳐 짧은 시간 동안 반복되면 정보 수집(harvesting)을 의미합니다. listSecrets은(는) 범위를 기록하고, getSecret은(는) 범위와 키를 모두 기록합니다.
• 거부된 읽기 요청을 나중의 성공적인 요청과 상호 연관시켜 분석하세요. 엄격하게 제어되는 범위에서 거부된 getSecret 이후, 제한이 적은 범위에서 동일하거나 관련된 키를 성공적으로 읽었다면 해당 ID가 액세스할 수 있는 복사본을 찾고 있음을 나타냅니다.
• Secrets API 외에도 컴퓨팅 측면의 액세스를 모니터링하세요. 상세 감사 로깅이 활성화된 경우, 노트북 submitCommand 및 Databricks SQL commandSubmit 이벤트에서 비밀 유틸리티를 호출하거나 자격 증명이 포함된 경로에 대해 read_files()을(를) 실행하는 코드가 나타날 수 있습니다. 제출된 텍스트는 실행된 내용을 보여주지만, 값이 반환되었음을 확정하지는 않는다는 점을 명심하세요.
• 각 비밀 읽기 작업을 새로운 accounts.tokenLogin, 처음 발견되는 서비스 주체 활동, 변경된 IP 또는 사용자 에이전트, 또는 generateTemporaryTableCredential / generateTemporaryVolumeCredential 호출 등 후속 작업과 연결하세요. 대응 과정에서 해당 ID가 도달할 수 있었던 모든 자격 증명을 교체하고, 저장된 위치뿐만 아니라 각 자격 증명이 사용된 위치도 확인하세요.

4. 공격자가 실행 가능한 경로를 찾습니다.

일단 액세스가 설정되면 공격자는 자신의 코드를 실행할 방법을 찾습니다. Databricks에서는 이 작업이 주로 UDF(사용자 정의 함수)와 작업을 통해 이루어집니다. 함수는 페이로드를 평범해 보이는 코드 안에 감싸 반복해서 호출할 수 있게 만들고, 작업은 다양한 컴퓨팅 환경에서 예약에 따라 해당 코드를 실행할 수 있습니다. 따라서 탐지를 위한 핵심 질문은 ID가 이전에 수행하지 않은 작업을 시작했는가 하는 점입니다. 데이터 엔지니어의 사례로 돌아가서, 비밀이 읽힌 지 한 시간 후에 서비스 주체가 함수를 생성합니다. 엔지니어가 아닌 서비스 주체가 이 작업을 수행하므로, 엔지니어의 활동만 범위로 지정한 검색으로는 이를 놓치게 됩니다.

공격자의 목표: 하나의 컴퓨팅 경로가 차단되었을 때의 대체 경로를 포함하여, 페이로드를 실행할 수 있는 안정적이고 재사용 가능한 방법을 구축합니다.

확인해야 할 사항:

• 함수 생성 이력이 없는 ID, IP 또는 카탈로그에서 발생한 createFunction 이벤트를 우선적으로 확인하세요. 특히 짧은 시간 동안 여러 개가 나타날 경우 주의해야 합니다. 함수 정의를 확인할 수 있는 경우, 프로세스를 실행하거나, 코드를 동적으로 평가하거나, 인스턴스 메타데이터에 액세스하거나, 아웃바운드 네트워크 연결을 열거나, 클라우드 스토리지에 쓰는 코드를 플래그 지정하세요. 또한 함수 간의 참조를 추적하세요. 무해해 보이는 래퍼가 고위험 UDF를 호출할 수 있기 때문입니다. function_info의 system.access.audit은(는) 계정 관리자와 databricks_pii_access을(를) 제외하고 마스킹되므로, 감사 데이터를 함수 인벤토리와 함께 살펴보세요.
• ID, IP, 작업 또는 실행 ID별로 Jobs 경로를 추적하세요. 일반적인 순서는 importNotebook, changeJobAcl, Jobs create, runNow, getRunOutput 순입니다. 이러한 이벤트는 노트북 본문을 거의 보존하지 않으므로, 노트북 버전과 작업 구성을 함께 보관하세요. 단일 소스에서의 반복적인 가져오기 및 실행 활동은 어느 한쪽의 작업보다 더 강력한 신호입니다.
• 장애 발생 후 컴퓨팅을 전환하는 ID를 찾으세요. 예를 들어 클러스터 생성 실패 또는 submitRun 직후에 startWarehouse이(가) 발생하거나 다른 컴퓨팅에서 새 작업이 실행되는 것은 공격자가 차단된 경로를 우회하려 함을 나타낼 수 있습니다. 응답 코드와 이벤트 사이의 짧은 간격이 이 시퀀스를 일반적인 오류와 구분해 줍니다. 서버레스 컴퓨팅은 흔히 사용되는 대체 경로입니다.

5. 공격자가 지속성을 확보합니다.

코드를 실행할 수 있게 된 후, 공격자는 원래 자격 증명이 취소된 후에도 다시 돌아올 수 있도록 조치합니다. 일반적인 지속성 확보 방법으로는 액세스 권한 부여, 새로 생성된 토큰, 그룹 및 워크스페이스 멤버십 변경, 제어 영역 편집 등이 있습니다. 가장 유용한 신호는 낯선 ID나 실행 컨텍스트에 의해 이루어진 민감한 변경입니다. 예를 들어, 작업 내부에서 이루어진 권한 변경은 관리자가 콘솔에서 동일한 변경을 수행한 것보다 더 면밀히 검토해야 합니다. 시나리오의 다음 단계에서 서비스 주체는 자신을 관리자 그룹에 추가합니다. 엔지니어의 토큰이 취소되더라도 해당 그룹 멤버십 덕분에 공격자의 액세스 권한이 유지됩니다.

공격자의 목표: 손상된 자격 증명이 취소되어도 유지되는 지속적이고 독립적인 액세스 경로를 생성합니다.

확인해야 할 사항:

• 비밀 범위의 putAcl, updatePermissionAssignment, addPrincipalToGroup 또는 setAdmin과(와) 같이 예상치 못한 컨텍스트에서 발생한 권한 및 ID 부여에 대해 경고합니다. 서비스 주체가 다른 ID에 액세스 권한을 부여하거나 짧은 시간 동안 여러 할당이 발생할 때 특히 주의를 기울이세요.
• 보안 제어를 변경하려는 시도가 실패하더라도 높은 심각도로 취급하세요. 여기에는 setSetting / deleteSetting, IP 액세스 목록 편집, createPrivateAccessSettings이(가) 포함됩니다. 제어가 실제로 우회되었는지 결론을 내리기 전에 요청된 변경 사항, 응답 및 소스를 검토하세요. 또한 예상되는 IdP 외의 소스에서 발생한 SCIM 그룹 변경 사항도 검토하세요.
• 낯선 소스에서 발생하거나 작업 실행 중에 호출된 generateDbToken을(를) 플래그 지정하세요. 결과로 생성되는 각 토큰은 취소해야 하는 별도의 자격 증명입니다.
• 스스로 계속 실행되는 워크로드를 주시하세요. 제어 영역 이벤트를 run_by, run_as 및 예상 실행 창과 상호 연관시키세요. 공격자의 대화형 활동이 중단된 후에도 작업이 그룹, 권한 또는 설정을 계속 수정하는 경우 자체적으로 액세스를 유지하고 있는 것일 수 있습니다. 작업을 종료하기 전에 작업 정의와 아티팩트를 보존하세요.

6. 공격자가 데이터를 수집하고 액세스 흔적을 지웁니다.

데이터 수집은 몇 가지 타겟팅된 내보내기만큼 작을 수 있으며, 정리 작업에는 단순히 파일을 삭제하는 것 이상의 작업이 포함될 수 있습니다. 타겟팅된 내보내기, 임시 자격 증명 요청, 수명이 짧은 도구 제거, 활동을 재구성하기 어렵게 만드는 난독화된 명령을 주의 깊게 살펴보세요. 이러한 이벤트 중 어느 하나는 일상적으로 보일 수 있으므로, 개별 내보내기나 삭제 자체보다는 그 주변의 시퀀스가 더 중요합니다. 마지막으로, 시나리오의 서비스 주체가 소수의 초기화 스크립트를 내보냅니다. 그 자체로는 작은 내보내기입니다. 하지만 비밀 읽기 및 동일한 서비스 주체의 새 함수 생성에 이어 발생하므로, 동일한 침해 사고의 일부로 조사해야 합니다.

공격자의 목표: 중요한 데이터를 가져가고 가장 명백한 도구 흔적은 지우면서 조용한 액세스는 유지합니다.

확인해야 할 사항:

• 내보내기 횟수보다는 각 내보내기의 컨텍스트를 살펴보세요. workspaceExport은(는) 경로, 형식 및 직접 다운로드 여부를 기록합니다. 낯선 ID에 의한 내보내기, 비정상적인 경로로의 내보내기 또는 비정상적인 형식의 내보내기, 이전에 보이지 않던 네트워크에서의 내보내기, 혹은 비밀 액세스나 새로운 실행 이후에 발생하는 내보내기를 우선적으로 처리하세요. 초기화 스크립트의 작고 타겟팅된 내보내기는 대량의 수명이 짧은 객체에 대한 기록을 유지하세요. 한 세션에서 동일한 함수에 대한 createFunction 뒤의 deleteFunction, 또는 반복되는 생성, 삭제, 재생성 주기는 증거를 인멸하려는 시도를 나타낼 수 있습니다. 무엇이든 되돌리기 전에 정의와 타이밍을 보존하세요. 살아남은 객체는 대개 삭제된 객체보다 그럴듯한 이름을 갖게 됩니다.
• 임시 자격 증명 및 데이터 읽기 버스트(generateTemporaryTableCredential, generateTemporaryVolumeCredential, Delta Sharing, 클라우드 스토리지 읽기)를 이전 정찰 활동과 연결하세요. 인코딩되거나 스크립트화된 명령어는 그 자체로 경보를 울리기에는 너무 흔하므로, 낯선 사용자 에이전트, 자동화 같은 타이밍, 비밀 액세스 또는 새로운 함수와 연관시켜 분석하세요.

Genie을 사용하여 자격 증명 기반 공격 조사하기

자격 증명 기반 공격 체인을 가이드로 삼아, 모든 쿼리를 처음부터 작성하지 않고도 Genie가 공격 단계를 거치도록 지시할 수 있습니다. 이 게시물의 모든 탐지는 이미 보유하고 있는 텔레메트리에서 실행됩니다. Databricks는 제어 평면 활동을 system.access.audit 시스템 테이블에 기록합니다.

시작하려면 Detection App을 설치하세요. 이 앱은 Databricks 감사 로깅을 위한 Genie 에이전트를 추가합니다. 다음 두 가지 방법으로 Genie One에서 사용할 수 있습니다:

• "user@example.com이 어제 어떤 노트북을 내보냈나요?"와 같이 평소 쓰는 말로 질문하세요. Genie가 사용자를 위해 SQL을 작성하고 실행합니다.
• 기본 제공 탐지 기능을 사용하세요. Detection App Genie 에이전트는 토큰 오용부터 관리자 권한 부여까지 30개가 넘는 탐지 기능을 포함하고 있습니다. "지난주에 누가 개인용 액세스 토큰을 만들었나요?"라고 물어보면 Genie가 새 SQL을 작성하는 대신 일치하는 탐지를 실행합니다. "지난 90일 동안 침해를 당했나요?"와 같은 목표를 제시하면 탐지를 하나씩 차례대로 처리합니다.

두 가지 한계를 염두에 두세요. 첫째, 결과가 비어 있다고 해서 아무 일도 일어나지 않은 것은 아닙니다. 이벤트가 시간 창을 벗어났거나 자세한 감사 로깅이 비활성화되어 있을 수 있습니다. 둘째, 감사 로그는 무언가가 변경되었고 누가 변경했는지 기록하지만, 대개 이전 값이나 새 값은 기록하지 않습니다.

탐지에서 대응으로

헌팅을 통해 일반적인 패턴에 맞지 않는 ID가 드러나면, 공격자가 여전히 어떤 액세스 권한을 가지고 있는지로 초점이 이동합니다. 자격 증명 기반 공격은 비선형적이므로, 찾은 첫 번째 액세스가 유일한 액세스인 경우는 드뭅니다. 데이터 엔지니어 예시에서 엔지니어의 토큰을 취소하더라도 서비스 주체의 자격 증명, 관리자 그룹 멤버십, 그리고 생성한 함수는 그대로 남아 있게 됩니다. 완벽한 대응은 원래의 자격 증명뿐만 아니라 공격자가 그 후에 생성한 모든 경로(권한 부여, 토큰, 함수, 그리고 사용자가 비활성화된 후에도 계속 실행되는 작업 포함)를 제거합니다.

작업 공간 침해가 의심되는 경우 대응 담당자는 다음을 수행해야 합니다:

1. ID 비활성화하기. 계정 수준에서 사용자를 비활성화하여 모든 작업 공간을 차단합니다. 사용자의 브라우저 세션을 종료하는 API는 없지만 비활성화를 통해 차단할 수 있습니다. 서비스 주의 경우, OAuth 시크릿을 삭제하고 계정 SCIM API를 사용하여 비활성화하세요. 서비스 주체가 이미 가지고 있는 OAuth 토큰은 최대 1시간 동안 유효합니다.
2. 개인용 액세스 토큰 취소하기. 사용자를 비활성화해도 토큰이 삭제되지는 않으며, 사용자가 다시 활성화되면 토큰이 다시 작동합니다. 토큰 관리 API 또는 계정 콘솔의 토큰 보고서를 사용하세요.
3. 필요한 것을 저장한 후 컴퓨팅 중지하기. 작업 정의와 노트북 버전을 먼저 내보내세요. 그런 다음 작업 실행을 취소하고, 클러스터를 종료하며, SQL 웨어하우스를 중지하세요. 서버리스의 경우 실행이나 구문을 취소하세요. 사용자를 비활성화해도 이미 실행 중인 컴퓨팅은 중지되지 않습니다.
4. 행위자가 읽은 모든 시크릿 순환하기. 원본에서 변경한 다음 저장된 값을 업데이트하세요. 공격자가 진입하는 데 사용한 자격 증명도 순환하세요.
5. 행위자가 생성한 지속성 되돌리기. 시크릿 범위 ACL, 작업 공간 할당, 그룹 멤버십을 제거하세요. 함수를 삭제(Drop)하고 권한 부여를 취소하세요. 자체 기록을 바탕으로 컨텍스트 기반 수신(ingress) 정책(여전히 사용하는 경우 IP 액세스 리스트 포함)을 복원하세요.
6. init 스크립트 및 클라우드 스토리지의 ETL 코드와 같이 Databricks 외부에 ID가 변경할 수 있는 코드를 확인하세요.
7. 중지되었는지 확인하기. 행위자의 활동을 검색해 보세요. 자세한 감사 로깅이 꺼져 있었다면 켜세요. 명령어 텍스트는 켜져 있는 동안에만 기록됩니다.

자격 증명 기반 공격 예방하기

다시 오피스 빌딩 이야기로 돌아가서, 컨텍스트 기반 수신은 회전문 통과 자격을 결정하고, 최소 권한은 사원증으로 열 수 있는 층을 결정합니다. 조기 탐지는 대응 시간을 벌어주지만, 예방 제어는 도난당한 자격 증명이 할 수 있는 일을 제한합니다. 아래의 제어는 공격자에게서 빼앗는 항목별로 그룹화되어 있으며, 대략 공격 체인이 차단되는 순서대로 나열되어 있습니다.

도난당한 자격 증명 차단하기

자격 증명 재사용에 대한 가장 강력한 예방 제어는 컨텍스트 기반 수신 제어입니다. 단일 네트워크 경계에 의존하는 대신 요청을 하는 사람, 요청의 출처, 요청의 용도를 평가합니다. 이는 더 많은 조직이 VPN에서 벗어날 때 특히 유용합니다. 기반으로 삼을 기업 네트워크가 없더라도 도난당한 토큰이 소유자가 실제로 사용하는 컨텍스트 내에서만 작동하도록 제한할 수 있습니다. 예를 들어, 권한이 있는 서비스 주체는 신뢰할 수 있는 네트워크의 API 요청으로 제한하는 동시에 일반 사용자에게는 다른 정책을 적용할 수 있습니다.

• 작업 공간 요청과 계정 요청 모두에 정책을 적용하세요. 작업 공간 정책은 계정 콘솔이나 계정 수준 API를 다루지 않습니다.
• 드라이런(dry-run) 모드로 시작하세요. system.access.inbound_network에서 거부 및 드라이런 위반 사항을 검토하고, 권한이 있는 서비스 주체를 먼저 보호한 후, 적법한 자동화 및 파트너 통합을 고려한 후에 적용을 시행하세요.
• 서버리스 및 비공개 연결 워크플로는 별도의 정책 규칙을 따르므로 광범위한 적용 전에 테스트하세요. 예외 사항을 문서화하고 사용량을 모니터링하세요.
• IP 액세스 리스트를 추가 레이어로 취급하세요. 둘 다 적용되는 경우 요청이 양쪽 모두를 통과해야 합니다. 여전히 사용하는 경우 작업 공간 및 계정 콘솔 리스트를 구성하세요.

수집된 자격 증명 가치 낮추기

• 서비스 주체 자격 증명, 통합 자격 증명, 개인용 액세스 토큰에 대한 만료 및 순환 요구 사항을 설정하고, 더 이상 사용되지 않는 자격 증명은 폐기하세요. 휴면 자격 증명은 몇 달 동안 침해 사실을 눈치채지 못할 수 있기 때문에 공격자들에게 특히 매력적입니다.
• 시크릿 범위에 최소 권한을 적용하세요. ACL이 다른 범위에 강력한 자격 증명 복사본을 저장하지 말고, 값을 검색할 수 있는 사람뿐만 아니라 범위 내용을 나열할 수 있는 사람도 검토하세요.

자격 증명이 실행하거나 변경할 수 있는 작업 제한하기

• 임팩트가 큰 작업을 제한하세요. UDF 생성, 시크릿 범위 ACL 변경, 작업 공간 권한 변경, 작업 관리, 수신 정책 변경을 승인된 ID와 제어되는 자동화로만 제한하세요.
• 관리 경로와 연산 경로를 분리하세요. 일반 작업 런타임은 계정 및 네트워크 제어를 수정할 수 없어야 하며, 그러한 시도가 있을 경우 경고가 생성되어야 합니다.
• 클라우드 실행 환경을 보호하세요. 가능한 경우 강화된 메타데이터 서비스 구성을 사용하고, 워크로드가 자격 증명 엔드포인트나 승인되지 않은 목적지에 자유롭게 접근하지 못하도록 연산에서의 외부 트래픽을 제한하세요.
• 계정 ID를 관리하고, 워크스페이스 액세스를 할당하며, 작업을 생성할 수 있는 ID를 제한하세요.

증거 보관

• 잠재적인 보안 침해에 대비해 조사에 바로 활용할 수 있는 텔레메트리를 보관하세요.
• 공격을 재구성할 수 있도록 감사 로그, 노트북 및 작업 버전 기록, UDF 정의 및 종속성, 권한 변경 기록, 클라우드 스토리지 쓰기 이벤트, 컨텍스트 기반 수신 거부 로그를 충분히 오래 보관하세요.

기억하세요, 탈취된 자격 증명의 피해 범위는 거기에 부여된 권한 크기만큼만 위험합니다. 다음 조치를 통해 노출을 줄이고 비정상적인 활동을 추적해 보세요.

• Databricks 보안 모범 사례를 검토하여 워크스페이스와 계정을 안전하게 보호하세요.
• 상세 감사 로깅을 켜고 컨텍스트 기반 수신 제어를 설정하여 두 영역 모두 보호되도록 하세요.
• Detection App을 배포하여 위협 탐지를 시작하고 Genie에게 첫 번째 질문을 던져보세요: "지난 90일 동안 침해를 당했나요?"

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