이제 GA: 사용자 대행 권한 부여로 권한 인식형 Databricks Apps 구축하기

Databricks Apps를 사용하면 개발자가 대화형 대시보드와 운영 도구부터 맞춤형 AI 에이전트에 이르기까지 데이터 및 AI 애플리케이션을 Databricks 플랫폼에서 직접 빌드하고 배포할 수 있습니다.

이제 정식 출시(GA)된 사용자 대행(OBO) 인증을 사용하면 애플리케이션 코드에 데이터 거버넌스 규칙을 다시 구현하지 않고도 개인화되고 권한을 인식하는 경험을 제공하는 앱을 빌드할 수 있습니다. 앱이 OBO를 사용하여 지원되는 Databricks API를 호출하면 로그인한 사용자의 ID를 사용하여 작동합니다. Unity Catalog는 행 필터 및 열 마스크를 포함하여 해당 사용자의 기존 데이터 권한을 적용하고, API 범위는 앱이 사용자를 대신하여 수행할 수 있는 작업을 제한합니다. 앱은 공유 구성 읽기 또는 애플리케이션 메트릭 쓰기와 같이 앱 소유 작업에 전용 서비스 주체(service principal)를 계속 사용할 수 있습니다.

예를 들어, 영업 인사이트 어시스턴트는 앱에 광범위한 SQL 또는 작업 공간 관리 권한을 부여하지 않고도 영업 담당자가 액세스할 수 있도록 권한이 부여된 계정과 필드만 사용하여 질문에 답변할 수 있습니다.

각 작업을 제어하는 ID부터 시작하기

앱을 설계할 때 다음 질문을 던져보세요. 이 특정 작업을 제어해야 하는 권한은 누구의 권한인가요?

Databricks Apps는 앱 인증과 사용자 인증이라는 두 가지 상호 보완적인 인증 모델을 지원합니다. 앱 인증은 앱의 전용 서비스 주체를 사용하며, 앱 소유 작업이나 모든 사용자에게 동일한 결과를 반환해야 하는 경험에 적합합니다. 사용자 인증은 해당 사용자의 권한이 작업을 제어해야 할 때 로그인한 사용자의 ID를 사용합니다. 대부분의 프로덕션 앱은 두 모델을 모두 사용할 수 있으며, 각 요청 경로에 적합한 ID를 선택합니다. 다음 문서를 참조하세요. Databricks 앱에서 인증 구성하기.

다음과 같은 질문에 답변하는 앱을 예로 들어 보겠습니다. 이번 분기에 내 계정의 실적은 어떠하며, 변화의 원인은 무엇인가? 이 앱은 다음을 수행해야 합니다.

• 요청하는 사용자로 영업 및 고객 데이터를 쿼리합니다.
• 행 수준 필터 및 열 마스크를 포함한 Unity Catalog 권한을 준수합니다.
• 읽기 전용 분석을 반환합니다.
• 필요에 따라 결과를 요약하기 위해 별도의 서비스를 호출합니다.
• 데이터 수정 또는 SQL 리소스 관리를 피합니다.

이는 사용자 인증에 자연스럽게 부합합니다. 앱은 요청하는 사용자의 전달된 액세스 토큰을 SQL 커넥터에 전달하고, Databricks는 해당 사용자의 기존 웨어하우스 및 Unity Catalog 권한을 사용하여 쿼리를 평가합니다. 지역 관리자는 자신의 지역에 있는 계정만 볼 수 있고, 전국 책임자는 모든 지역을 볼 수 있으며, 앱이 코드에서 이러한 규칙을 다시 생성할 필요가 없습니다. 관리자가 Unity Catalog 정책을 업데이트하면 이후의 앱 요청에 해당 변경 사항이 반영됩니다. 

사용자의 권한에 따라 쿼리가 반환할 수 있는 데이터가 결정됩니다. 다음 설계 결정 사항은 전달된 사용자 토큰을 사용하여 앱이 사용자를 대신해 수행할 수 있도록 허용되는 작업이 무엇인지 정의하는 것입니다.

작업에 부합하는 가장 좁은 API 범위 사용하기

영업 인사이트 어시스턴트는 읽기 전용 쿼리를 실행해야 합니다. 리소스를 관리하거나 다른 SQL 작업을 수행하기 위해 광범위한 SQL 액세스가 필요하지 않습니다. 따라서 더 넓은 범위의 sql 대신 sql:restricted-query를 요청해야 합니다. 

sql:restricted-query를 사용하면 앱이 읽기 전용 SQL 쿼리를 실행할 수 있습니다. 앱이 다른 SQL 작업을 수행하는 것은 허용하지 않습니다. 이를 통해 앱의 제품 동작과 인증 경계가 더 잘 일치하게 됩니다. 즉, 앱은 분석을 위해 거버넌스가 적용된 데이터를 읽을 수 있지만, 사용자의 ID를 광범위한 SQL 작업 자격 증명으로 사용할 수는 없습니다.

앱이 사용자를 대신하여 Genie 또는 Unity Gateway도 호출하는 경우, genie 또는 ai-gateway와 같이 해당하는 범위만 요청하세요. 앱이 실제로 해당 기능을 사용하지 않는 한 files, model-serving 또는 vector-search를 요청하지 마세요. 

범위는 기능의 상한선일 뿐 데이터 액세스 권한을 부여하는 것이 아닙니다. 앱에 적절한 API 범위가 있어야 하며, 사용자에게도 여전히 대상 리소스에 액세스할 수 있는 권한이 있어야 합니다. 다음 문서를 참조하세요. 범위 기반 보안 및 권한 상승.

명시적인 API 범위로 앱 구성하기

Databricks UI 또는 Declarative Automation Bundle에서 사용자 인증을 구성하세요. 

읽기 전용 분석 어시스턴트의 경우 앱은 다음과 같이 선언할 수 있습니다.

참고: API 범위는 앱의 선언된 사용자 인증 구성의 일부입니다. SQL 웨어하우스 또는 Unity Catalog 데이터에 대한 액세스 권한을 부여하지는 않습니다. 요청하는 사용자는 여전히 대상 SQL 웨어하우스를 사용할 수 있어야 하며, 쿼리 중인 데이터에 대해 필요한 Unity Catalog 권한을 가지고 있어야 합니다. 

사용자가 사용자 인증 앱에 처음 액세스할 때, Databricks는 요청된 API 범위에 동의하도록 요청하는 메시지를 표시합니다. 

SQL 커넥터에 사용자 ID 전달하기

Databricks는 현재 사용자의 액세스 토큰을 x-forwarded-access-token HTTP 헤더로 전달합니다. 앱은 사용자 컨텍스트 액세스가 필요한 요청에 대해 해당 토큰을 가져와 SQL 커넥터에 전달해야 합니다.

다음 예제에서는 Flask 및 Python용 Databricks SQL 커넥터를 사용하여 토큰 흐름을 명시적으로 보여줍니다. Databricks AppKit으로 앱을 빌드하는 경우 동일한 인증 원칙을 적용하세요. 즉, 사용자 고유 작업에는 사용자 컨텍스트 클라이언트 또는 요청 시점 ID를 사용하고, 앱 소유 작업은 앱 ID로 유지하세요.

Note: 전달된 토큰은 수명이 짧으며 요청별로 유효합니다. 앱은 각 요청 시 토큰을 읽으며, 요청 간에 또는 세션에 토큰을 저장하지 않습니다. 

앱 권한 부여와의 중요한 차이점은 커넥터가 access_token을 통해 전달된 사용자 토큰을 수신한다는 것입니다.  sql:restricted-query API 범위는 앱이 필요한 읽기 전용 SQL 기능으로 제한하는 반면, Unity Catalog는 해당 사용자가 실제로 액세스할 수 있는 행과 열을 결정합니다. 참조 사용자 권한 부여를 사용한 쿼리.

워크스페이스 관리자가 상한선 설정하기

개발자는 앱에 필요한 API 범위를 지정합니다. 워크스페이스 관리자는 앱 개발자가 워크스페이스의 앱에 추가할 수 있는 API 범위를 제어할 수 있습니다.

이 정책을 통해 팀은 앱이 더 광범위하거나 관련 없는 권한을 요청하지 못하도록 방지하면서 읽기 전용 분석 및 AI 경험을 구축할 수 있습니다. 앱 개발자는 워크스페이스에 구성된 API 범위 경계를 넘어 앱의 권한을 확장할 수 없습니다.

이를 통해 조직은 두 가지 수준의 제어 권한을 가질 수 있습니다:

• 앱은 기능에 필요한 최소한의 API 범위를 선언합니다.
• 워크스페이스 관리자는 해당 워크스페이스의 앱에서 사용할 수 있는 최대한의 API 범위를 정의합니다.

워크스페이스 관리자는 설정 > 개발 > 앱에서 이 허용 목록을 구성합니다. 이 설정은 기본적으로 지원되는 모든 API로 지정되어 있으며, 선택한 API 범위로 좁히거나 None으로 설정하여 사용자 권한 부여를 비활성화할 수 있습니다. 참조 사용자 권한 부여 범위 제한.

계정 관리자는 해당 범위가 워크스페이스 허용 목록에 포함되어 있지 않은 경우에도 범위를 추가할 수 있습니다. 관리자가 나중에 허용된 범위를 제거하더라도 해당 범위로 이미 실행 중인 앱은 계속 실행될 수 있지만, 허용되지 않은 범위가 제거될 때까지는 시작, 배포 또는 업데이트할 수 없습니다.

앱 소유 작업과 사용자 소유 작업 분리하기

유용한 많은 앱에는 두 가지 권한 부여 모델이 모두 필요합니다. 예를 들어 매출 인사이트 어시스턴트는 다음을 사용할 수 있습니다:

• 애플리케이션 메트릭을 기록하거나 공유 구성을 읽기 위한 앱 범위 클라이언트.
• 현재 사용자의 데이터를 쿼리하기 위한 sql:restricted-query가 포함된 사용자 범위 클라이언트.
• 사용자를 대신하여 다른 Databricks 서비스를 호출해야 하는 경우 별도의 사용자 API 범위.

하나의 일반적인 클라이언트를 생성하여 모든 곳에서 재사용하는 대신, 애플리케이션 코드에서 해당 ID 경계를 명시적으로 만드는 것이 좋습니다. 종속성, 이름 및 테스트를 분리하면 앱 자격 증명이 사용자 특정 경로에 사용되거나 백그라운드 작업을 위해 사용자 토큰이 유지되는 것을 방지하는 데 도움이 됩니다.

요청에 사용자 권한 부여가 필요하지만 전달된 토큰이 누락된 경우, 앱의 서비스 주체로 자동으로 전환하지 말고 폐쇄형 실패(fail closed)로 처리하세요. 그렇지 않으면 앱이 유효해 보이지만 다른 권한으로 생성된 응답을 반환할 수 있습니다. 이것이 위의 예시에서 query_as_user가 누락된 헤더를 인라인으로 처리하는 대신 require_user_token으로 시작하는 이유입니다.

에이전트에도 동일한 패턴 적용하기

Databricks Apps에 배포된 맞춤형 에이전트도 동일한 모델을 사용할 수 있습니다. 전달된 사용자 토큰은 활성 사용자 요청 중에만 사용할 수 있으므로, 애플리케이션 시작 시점이 아닌 요청 시점의 invoke 또는 stream 핸들러 내부에서 사용자 범위 워크스페이스 클라이언트를 초기화하세요. 공유 리소스 및 백그라운드 작업에는 앱 권한 부여를 사용하세요. 참조 에이전트 인증.
 

구현 보안 강화하기

• 필요한 최소한의 API 범위만 요청하세요.
• 코드, 테스트 및 종속성 연결에서 앱 소유 클라이언트와 사용자 권한 부여 클라이언트를 분리하여 유지하세요.
• 전달된 액세스 토큰을 출력, 로깅 또는 영구 저장하지 마세요.
• 앱 관리를 신뢰할 수 있는 개발자로 제한하고 권한 부여 관련 변경 사항에 대해 동료 검토를 요구하세요.
• 사용자 토큰을 유지하는 대신 공유 및 백그라운드 작업에는 앱 권한 부여를 사용하세요.
• Unity Catalog 액세스 권한이 다른 사용자로 테스트한 다음, 정책이 변경된 후 해당 테스트를 반복하세요.

시작하기

사용자 대리 권한 부여를 사용하면 동일한 메커니즘을 통해 개인화와 거버넌스를 모두 확보할 수 있습니다. 사용자의 Unity Catalog 권한에 따라 앱이 액세스할 수 있는 데이터가 결정되며, 가장 좁게 일치하는 API 범위에 따라 앱이 사용자를 대신하여 수행할 수 있는 작업이 결정됩니다. 시작하려면 더 많은 리소스와 모범 사례가 포함된 도움말 문서를 확인해 보세요.

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