엔터프라이즈 AI 프로젝트에는 고통스러운 진실이 있습니다: 많은 팀이 모델 품질에 집착하고 책임성을 무시합니다. 에이전트가 프로덕션 데이터를 쓰거나 읽을 때, 첫 번째 사고 검토 질문은 “답변이 좋았나요?“가 아닙니다. “누가 실제로 이것을 했나요?“입니다.
원문: https://devblogs.microsoft.com/azure-sql/sql-mcp-server-obo-auth/
이것이 Data API builder 2.0과 SQL MCP Server의 OBO 지원이 처음보다 더 큰 이유입니다. 사용자 이름/비밀번호 및 관리 아이덴티티 접근법은 여전히 운영상 작동하지만, 둘 다 아이덴티티를 서비스 경계로 붕괴시킵니다. 로그에는 앱이나 미들웨어가 표시되지만, 인간 요청 출처는 표시되지 않습니다. 그것은 단순한 자동화에는 허용 가능하지만, 규제된 에이전틱 워크플로에는 허용되지 않습니다.
OBO를 사용하면 SQL은 도구 호스트 아이덴티티가 아닌 위임된 사용자 컨텍스트를 인증합니다. 이는 근본적으로 더 나은 감사 모델을 제공합니다: 사용자 보안 주체, 작업, 문장 컨텍스트, 미들티어 앱 식별자가 함께 표시됩니다. MCP 도구와 DAB 엔티티 권한의 제어 표면을 잃지 않으면서 추적 가능성을 얻습니다.
내 의견은 확고합니다: 에이전트가 민감한 SQL 데이터에 접근할 수 있다면, OBO는 선택적 강화 작업이 아닌 기본 아키텍처여야 합니다. 설정이 더 복잡하지만, 아이덴티티 부채는 항상 나중에 지불되며, 보통 보안 사고, 규정 준수 감사, 또는 경영진 에스컬레이션 중에 지불됩니다.
실용적인 구현 가이드
- 최소 “WhoAmI” 뷰와 통합 테스트의 자동화된 검사로 아이덴티티 흐름을 검증하는 것부터 시작하세요. SQL 보안 주체가 로그인한 사용자와 일치하지 않으면, 출시 전에 중단하고 수정하세요.
- SQLSecurityAuditEvents에 대한 Log Analytics 쿼리를 SOC 대시보드에 연결하고 OBO 경로를 통해 시작된 고위험 작업에 대해 경고하세요.
- RBAC와 DAB 권한을 정렬하여 사용자 수준 아이덴티티와 작업 수준 권한 부여가 종단간 일관되도록 하세요.
발표에서 미묘하지만 중요한 설계 포인트 하나는 캐시 동작입니다. DAB는 사용자 위임 인증이 활성화되면 응답 캐싱을 명시적으로 차단합니다. 그 트레이드오프는 올바릅니다. 사용자 범위 결과를 유출할 수 있는 성능 트릭은 멀티 테넌트 또는 규제된 환경에서 가치가 없습니다.
SQL MCP Server와 OBO는 성숙한 패턴의 시작입니다: 통제된 운영자로서의 에이전트, 책임 있는 보안 주체로서의 사용자, 감사 가능한 시스템으로서의 데이터 플레인. 아키텍처가 “누가 이것을 했나요?“를 자신있게 대답할 수 없다면, 데모가 아무리 정교해도 프로덕션 준비가 된 AI가 아닙니다.
