DB & Server Access Control concepts

Available in VPC

This page explains why you need DB & Server Access Control, its architecture, how it works, and key terms to help you understand and use the service.

Why you need DB & Server Access Control

In modern cloud environments, access control for databases and servers determines an organization's security level. In particular, various regulations such as the Personal Information Protection Act, ISMS-P, and Electronic Financial Supervision Regulations require management of access permissions and storage of access records as essential requirements. DB & Server Access Control technically implements the principle of least privilege by centrally controlling all access through a proxy. In addition, it stores session records and task history for each user to provide the evidence required for audits and regulatory compliance. This enables users to proactively block security risks that may arise from insider threats, abuse of privileges, and inadequate management of partner accounts. As a result, DB & Server Access Control is not merely a security feature, but essential infrastructure that supports an organization's internal control system and regulatory compliance.

• Regulatory compliance: A centralized access control system that meets the requirements of regulated sectors, such as government, finance, and healthcare, as well as internal security standards at large enterprises.
• Internal control: Prevent security incidents caused by insiders and manage access permissions for former employees and partner companies.
• Audit support: Manage evidence and ensure traceability of access records and task execution history by user and resource.

Service architecture

The DB & Server Access Control service centralizes access paths by requiring users to pass through a proxy server instead of accessing servers or databases directly. It controls access permissions at a single point and provides auditing capabilities by logging the activity of users connected through the dedicated client.

The diagram above shows the DB & Server Access Control workflow from the administrator and user perspectives. The admin configures the proxy server and access control targets in the NAVER Cloud Platform console. The user installs the dedicated client and, after authentication, accesses the target resource via the proxy server. All access and task history that takes place during this process is logged. The key components present in this flow are as follows:

• NAVER Cloud Platform console: A management page where administrators deploy proxy servers, register access control targets, and configure access permissions, logging, and masking.
• Dedicated client: An agent program installed on your PC (Windows or macOS). You log in with a sub account from Sub Account, and the client serves as an entry point that forwards all your connection traffic to the proxy server. Since access that does not go through the client is blocked, it is an essential element for implementing access control.
• Proxy server: A gateway server automatically deployed to a private subnet in your VPC. It relays connections between the user and the target resource, verifies access permissions, and logs executed commands and results. It also periodically retrieves access policies through a management network operated directly by NAVER Cloud Platform.
• Target resource (access control target): A personal information processing system subject to access control and logging. Targets are Cloud DB (MySQL, MSSQL, PostgreSQL, MongoDB, Redis), Server (Linux), and DBMS installed directly on the server.
• Integrated services: Access and task history logs are sent to Cloud Log Analytics for storage and viewing. Configuration changes made in the console are recorded in Cloud Activity Tracer. Use of Object Storage is recommended for the long-term preservation of logs.

How it works

This section explains how DB & Server Access Control works by describing its core principles and step-by-step flow. Understanding this process helps you configure and use the service in the console according to the recommended workflow.

Core principles

The core principles are as follows:

• All access passes through the proxy server
  If users can access target resources directly, they can bypass access control and logging. Remove rules that allow direct user access from the target resource's Access Control Group (ACG) and Network ACL, and add rules that allow access only from the proxy server. This configuration creates a structure in which all access is controlled and recorded. If the ACG is not configured, users can bypass the proxy, so this is a prerequisite for using the service.
• Access permissions are managed via Sub Account policies
  The service utilizes the user-defined policies of Sub Account without requiring a separate permission system. When an administrator defines access control target permissions in a policy and assigns it to a sub account, the proxy server checks the policy at login to allow or deny access.
• Execution history is collected in the proxy server
  While relaying connections, the proxy server collects the commands and queries users execute and their results, and sends them to Cloud Log Analytics without changing the target resource settings. Personal information in the results can be masked before transfer.

Step-by-step workflow

The step-by-step flow is as follows:

Environment configuration (administrator)

The administrator configures the environment through the following steps:

1. When subscribing to DB & Server Access Control, select a VPC, subnet, and server specifications to create a proxy server.
2. In the target resource's ACG and Network ACL, block direct user access and allow access from the proxy server.
3. Register the access control target as a server target or DB target, and configure the logging scope and masking settings.
4. Define target access permissions in a Sub Account user-defined policy and assign it to a sub account.

Access and logging (user)

Users connect via the client and their usage history is logged through the following steps:

1. The user installs the dedicated client on their PC and logs in with a sub account.
2. The client receives and displays a list of resources the user has access permissions to from the proxy server.
3. When the user requests access using a connection tool (terminal, DB client, etc.), traffic is forwarded to the proxy server via the client.
4. The proxy server relays the connection to the target resource after verifying access permissions.
5. Executed commands, queries, and results are logged and transferred to Cloud Log Analytics (with personal information masking applied if necessary).
6. Transmitted logs are audited and viewed in Cloud Log Analytics and can be retained long-term via Object Storage.