DB & Server Access Control 개념

VPC 환경에서 이용 가능합니다.

DB & Server Access Control 서비스를 이해하여 쉽게 활용할 수 있도록 도입 필요성, 서비스 구조, 작동 방식, 핵심 용어에 대해 설명합니다.

DB & Server Access Control 필요성

현대의 클라우드 환경에서는 데이터베이스와 서버에 대한 접근 통제가 곧 기업의 보안 수준을 결정합니다. 특히 개인정보보호법, ISMS-P, 전자금융감독규정 등 다양한 규제에서는 접근 권한 관리와 접속 기록 보관을 필수 요건으로 요구하고 있습니다. DB & Server Access Control 서비스는 모든 접근을 Proxy를 통해 중앙에서 통제함으로써 최소 권한 원칙을 기술적으로 구현합니다. 또한, 사용자별 세션 기록과 작업 이력을 저장하여 감사 및 규제 대응에 필요한 증적을 제공합니다. 이를 통해 내부자 위협, 권한 오남용, 협력사 계정 관리 미흡 등으로 발생할 수 있는 보안 리스크를 사전에 차단할 수 있습니다. 결과적으로 DB & Server Access Control 서비스는 단순한 보안 기능이 아닌 조직의 내부 통제 체계와 규제 준수를 지원하는 필수 인프라입니다.

• 규제 준수: 공공, 금융, 의료와 같은 규제 산업군을 포함하여 대기업 자체 보안 기준에 부합하는 중앙 집중형 접근 통제 체계
• 내부 통제: 내부자에 의한 보안 사고 방지 및 퇴사자, 협력사의 접속 권한 관리
• 감사 대응: 사용자, 리소스별 접속 기록과 작업 수행 이력에 대한 증적 관리 및 추적 확보

서비스 구조

DB & Server Access Control 서비스는 사용자가 서버 또는 데이터베이스에 직접 접근하는 대신 프록시 서버를 반드시 경유하도록 접근 경로를 일원화합니다. 단일 경유 지점에서 접근 권한을 제어하고, 전용 Client를 통해 접속한 사용자의 수행 이력을 로깅하여 감사 기능을 제공합니다.

위 개념도는 DB & Server Access Control 서비스의 이용 흐름을 관리자(Admin)와 사용자(User) 관점으로 나타냅니다. 관리자(Admin)는 네이버 클라우드 플랫폼 콘솔에서 프록시 서버와 접근제어 타깃을 설정합니다. 사용자(User)는 전용 Client를 설치하고, 인증 후 프록시 서버를 경유하여 대상 리소스에 접속하게 됩니다. 이 과정에서 발생하는 모든 접속 및 작업 이력이 로깅됩니다. 이러한 흐름에 등장하는 주요 구성 요소는 다음과 같습니다.

• 네이버 클라우드 플랫폼 콘솔: 관리자가 프록시 서버 배포, 접근제어 타깃 등록, 접근 권한·로깅·마스킹을 설정하는 관리 화면
• 전용 Client: 사용자 PC(Windows, macOS)에 설치하는 에이전트 프로그램으로, Sub Account(서브 계정)로 로그인하며 사용자의 모든 접속 트래픽을 프록시 서버로 전달하는 진입점 역할. Client를 거치지 않은 접근은 차단되므로, 접근 제어가 적용되기 위한 필수 요소
• 프록시 서버: 고객 VPC의 Private Subnet에 자동으로 배포되는 게이트웨이 서버. 사용자와 대상 리소스 사이에서 접속을 중계하고 접근 권한을 확인하며, 수행된 명령어와 결괏값을 로깅. 이때 네이버 클라우드 플랫폼이 직접 관리하는 관리망과 연계하여 접근 정책을 주기적으로 받아 오는 역할 수행
• 대상 리소스(접근제어 대상): 접근 제어 및 로깅의 대상이 되는 개인정보처리시스템으로, Cloud DB(MySQL, MSSQL, PostgreSQL, MongoDB, Redis), Server(Linux), Server에 직접 설치한 DBMS가 대상
• 연계 상품: 접속 및 작업 이력 로그는 Cloud Log Analytics로 전송되어 보존·조회되며, 콘솔에서 수행한 설정 이력은 Cloud Activity Tracer에 기록. 로그의 장기 보존을 위해 Object Storage 이용 권장

작동 방식

DB & Server Access Control 서비스의 작동 방식을 핵심 원리와 단계별 흐름으로 설명합니다. 이를 이해하면 콘솔에서 권장 시나리오대로 서비스를 구성하고 활용하는 데 도움이 됩니다.

핵심 원리

핵심 원리는 다음과 같습니다.

• 모든 접근은 프록시 서버를 단일 경유
  사용자가 대상 리소스로 직접 접근할 수 있으면 접근 제어와 로깅이 무력화됩니다. 따라서 대상 리소스의 ACG(Access Control Group) 및 Network ACL에서 사용자의 직접 접근 규칙을 제거하고 프록시 서버에 대한 접근 허용 규칙만 추가해야 합니다. 이러한 구성을 통해 모든 접근이 통제·기록되는 구조가 완성됩니다. ACG 설정이 누락되면 사용자가 프록시를 우회할 수 있으므로 이는 서비스 이용의 전제 조건입니다.
• 접근 권한은 Sub Account 정책으로 관리
  별도의 권한 체계를 두지 않고 Sub Account의 사용자 정의 정책을 활용합니다. 관리자가 접근제어 타깃에 대한 권한을 정책으로 정의해 서브 계정에 연결하면, 프록시 서버가 로그인 시점에 정책을 확인하여 접근을 허용하거나 거부합니다.
• 수행 이력은 프록시 서버에서 수집
  대상 리소스의 설정을 변경하지 않고, 프록시 서버가 중계하는 과정에서 사용자가 수행한 명령어, 쿼리와 결괏값을 수집하여 Cloud Log Analytics 서비스로 전송합니다. 이때 결과값에 포함될 수 있는 개인정보는 전송 전에 마스킹 처리할 수 있습니다.

단계별 흐름

단계별 흐름은 다음과 같습니다.

환경 구성(관리자)

관리자가 환경을 구성하는 흐름은 다음과 같습니다.

1. DB & Server Access Control 서비스를 이용 신청 중 VPC, Subnet, 서버 사양을 선택하여 프록시 서버 생성
2. 대상 리소스의 ACG/Network ACL에서 사용자의 직접 접근은 차단하고 프록시 서버 접근 허용
3. 접근 제어 대상을 서버 타깃 또는 DB 타깃으로 등록하고, 로깅 범위와 마스킹 설정
4. Sub Account 사용자 정의 정책으로 Target 접근 권한을 정의하여 서브 계정에 연결

접속 및 로깅(사용자)

사용자가 Client를 통해 접속하고, 사용자의 사용 이력이 로깅되는 흐름은 다음과 같습니다.

1. 사용자가 PC에 전용 Client를 설치하고 서브 계정으로 로그인
2. Client가 프록시 서버로부터 접근 권한이 있는 리소스 목록을 받아 표시
3. 사용자가 접속 도구(터미널, DB 클라이언트 등)로 접속을 요청하면 트래픽이 Client를 통해 프록시 서버로 전달
4. 프록시 서버가 접근 권한을 확인한 뒤 대상 리소스로의 접속을 중계
5. 수행한 명령어, 쿼리와 결괏값이 로깅되어 Cloud Log Analytics 서비스로 전송 (필요시 개인정보 마스킹 적용)
6. 전송된 로그는 Cloud Log Analytics 서비스에서 감사 및 조회하며, Object Storage를 통해 장기 보존 가능