클라우드 컴퓨팅 - 네이버 클라우드, DB & Server Access Control(DSAC)

https://www.navercorp.com/media/pressReleasesDetail?seq=10034680

2026.9.22
[네이버클라우드, DB·서버 접근제어 통합 보안 서비스 출시 “개인정보보호법 준수 부담 낮춘다”]

네이버클라우드가 출시한 'DB & Server Access Control(DSAC)'은 기업의 데이터베이스와 서버 접근을 통합 관리하는 클라우드 네이티브 보안 서비스입니다. 이 서비스는 외부 보안 솔루션 설치 없이 콘솔에서 즉시 사용 가능한 SaaS 방식을 채택하여, 기업들이 복잡한 구축 과정 없이도 개인정보보호법 등 법적 규제를 손쉽게 준수하도록 돕습니다. 특히 모든 접속 경로를 단일 관문으로 통제하고 작업 이력을 자동으로 기록하며 민감 정보를 마스킹 처리하는 기능을 통해, 보안 인력이 부족한 기업도 합리적인 비용으로 데이터 안전성을 확보할 수 있게 설계되었습니다. 결과적으로 기술적 진입 장벽을 낮추어 다양한 규모의 기업이 내부 보안 위협에 선제적으로 대응하도록 지원하는 것이 이 서비스의 핵심 목적입니다.

 

Agent 보안의 통제지점이 모델에서 데이터 경계로 이동

 

네이버클라우드는 2026년 9월 22일 DB·서버 접근제어 SaaS DSAC(DB & Server Access Control) 출시를 공식 발표했습니다.[1]

확인된 기능은 다음과 같습니다.

• 고객 VPC 내 Proxy 서버를 자동 생성하여 서버·DB 접속 경로를 단일 관문으로 통제
• 사용자별 서버·DB 접근권한 세분화
• 서버·DB 작업이력 자동 기록, 감사 및 장기 보관
• 주민등록번호·카드정보 등 민감정보의 저장 시 마스킹
• 업무시간 외 접속·대량 조회 등의 이상징후 실시간 탐지
• 별도 솔루션 구축 없이 콘솔에서 사용하는 SaaS형 제공[1]

규제 보존기간 검증 결과

항목	검증 결과	판단
접속기록 1년 이상 보관	개인정보 안전성 확보조치 기준 제8조의 기본 요건과 부합	확인
고유식별정보·민감정보·5만 명 이상 처리 시 접속기록 2년 이상	현행 안전성 확보조치 기준에 명시	중요 보완
접근권한 변경이력 3년 이상	네이버클라우드 보도자료에는 법적 의무로 제시됨	법령 조문 단위 재확인 필요

 

[보완 필요: 규제 적용범위] “접속기록 1년”만을 기준으로 설계하면 부족합니다. 현행 기준상 고유식별정보·민감정보를 처리하거나 정보주체 5만 명 이상을 처리하는 시스템은 최소 2년 보관 대상입니다. 특히 공공·금융·교육 AI 서비스는 이 강화 요건에 해당할 가능성이 높습니다.[2]

 

핵심 인사이트: Agent 보안의 통제지점이 모델에서 데이터 경계로 이동

DSAC의 의미는 단순한 DB 접근제어 SaaS 출시보다, AI Agent가 데이터에 도달하는 마지막 경로를 통제하는 Cloud-native enforcement layer가 등장했다는 데 있습니다.

 

기존에는 다음 구조가 주류였습니다.

사용자 → 애플리케이션 → DB
관리자 → Bastion/서버 → DB

 

Agent 환경에서는 호출 주체가 늘어납니다.

사용자 → Agent → Tool/MCP → 서버·DB
시스템 Agent → RAG 검색·SQL 실행 → 민감 DB

 

이때 “Agent가 안전한가”만으로는 통제가 완료되지 않습니다. 감사·책임추적을 위해 아래 4개 식별자가 하나의 로그 체인으로 결합돼야 합니다.

통제 축	반드시 남겨야 할 식별정보	DSAC 연계 의미
Identity	최종 사용자, 서비스 계정, Agent ID, 워크로드 ID	“누가” 요청했는가
Permission	역할, 승인권한, 일시권한, 정책 버전	“어떤 권한으로” 실행됐는가
Data Access	대상 DB·테이블·컬럼, 조회조건, 실행 SQL, 반환 건수	“무슨 데이터에” 접근했는가
Audit	접속·작업·권한변경 시각, 정책판정, 마스킹 여부, 이상징후·대응결과	사후 설명·조사가 가능한가

 

공공·금융 Agent 적용 시 요구되는 확장

DSAC는 위 4축 중 Permission–Data Access–Audit의 강한 기반이 될 수 있습니다. 다만 Agent 환경에서 실효성을 얻으려면 다음을 별도 설계해야 합니다.

1. Agent 전용 비인간 ID(Non-human Identity) 분리 Agent가 사람의 공용 DB 계정이나 관리자 계정을 재사용하면 귀속성과 책임성이 붕괴합니다. Agent별 서비스 ID, 목적·업무 범위, 만료시각을 관리해야 합니다.

1. 최종 사용자 위임관계(Delegation) 로그화 “Agent가 조회했다”는 기록만으로는 불충분합니다. 최종 사용자 → Agent → Tool/MCP → DB 세션의 위임 사슬과 승인 근거가 함께 보존돼야 합니다.

1. 행·열 수준 정책 및 동적 마스킹 검증 DSAC의 민감정보 마스킹 기능은 유용하지만, RAG·Agent의 경우 프롬프트나 검색 결과를 통한 재식별·대량 유출 위험도 고려해야 합니다. 단순 DB 컬럼 마스킹을 넘어, 업무·사용자·Agent 목적별 반환 범위를 통제할 필요가 있습니다.

1. 대량·연쇄 조회를 Agent 이상행위로 정의 사람 기준의 “야간 접속”·“대량 조회” 규칙만으로는 부족합니다. Agent에는 짧은 시간의 다중 테이블 조인, 평소와 다른 데이터 도메인 횡단, 토큰·반환량 급증, 반복 실패 후 권한상승 시도 등을 별도 탐지 규칙으로 정의해야 합니다.

1. 정책결정 로그와 DB 작업로그의 상호연계 DSAC가 DB 접속·작업을 기록하더라도, 상위 Agent 플랫폼의 정책판단 로그가 분리되면 “왜 그 조회가 허용되었는가”를 설명할 수 없습니다. Agent 정책엔진·MCP Gateway·DSAC·SIEM 로그에 공통 Correlation ID를 적용해야 합니다.

 

결론: DSAC는 “DB 접근제어 제품”이라기보다, Agent 시대의 Identity–Permission–Data Access–Audit 참조구조에서 데이터 접근 실행·감사 계층을 SaaS로 제공한 사례로 볼 수 있습니다. 다만 공공·금융 Agent에 적용하려면 Agent의 권한 위임 및 정책판정 정보를 DSAC의 접속·작업 로그와 결합해야 하며, 그렇지 않으면 “DB에서 무엇을 했는가”는 남아도 “누구의 업무 목적과 승인으로 Agent가 수행했는가”는 증명하기 어렵습니다.

 

Sources:
[1] https://www.navercorp.com/media/pressReleasesDetail?seq=10034680
[2] https://law.go.kr/LSW//admRulInfoP.do?admRulSeq=2100000265956&chrClsCd=010201