DB & Server Access Control concepts

Available in VPC

This guide explains the necessity of the service, service structure, operation methods, and key terms to help you understand and easily utilize DB & Server Access Control.

Necessity of DB & Server Access Control

In modern cloud environments, access control to databases and servers will soon determine the level of corporate security. 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 internal security standards of large enterprises, including regulated industries such as the public sector, finance, and healthcare.
• Internal control: Prevent security incidents caused by insiders and manage access permissions for former employees and partner companies.
• Audit response: Secure evidence management and tracking of access records and task execution history by user and resource.

Service structure

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 of contact and provides auditing capabilities by logging the execution history of users connected via a dedicated client.

The concept map above illustrates the usage flow of DB & Server Access Control from the perspectives of an admin and a user. 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 screen where administrators configure proxy server deployment, access control target registration, access permissions, logging, and masking.
• Dedicated client: An agent program installed on the user's PC (Windows, macOS). Users log in with Sub Account and the client acts as an entry point that forwards all user access 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 that is automatically deployed to the private subnet of the customer VPC. It relays connections between the user and the target resource, verifies access permissions, and logs executed commands and results. At this time, it performs the role of periodically receiving access policies in conjunction with the management network directly managed 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.
• Linked products: Access and task history logs are transferred to Cloud Log Analytics for storage and viewing, and configuration history performed in the console is 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 helps you configure and utilize services in the console according to recommended scenarios.

Core principles

The core principles are as follows:

• All access passes through a single proxy server.
  If users can directly access target resources, it makes access control and logging impossible. Therefore, you must remove users' direct access rules from the target resource's Access Control Group (ACG) and Network ACL, and add only the rules to allow access to 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 permissions for access control targets as a policy and links it to a sub-account, the proxy server checks the policy at time of login to allow or deny access.
• Execution history is collected in the proxy server
  Without changing the settings of the target resource, the service collects commands, queries, and results executed by the user during the proxy server relay process and transfers them to the Cloud Log Analytics service. At this time, personal information that may be included in results can be masked before transference.

Step-by-step flow

The step-by-step flow is as follows:

Environment configuration (administrator)

The administrator configures the environment through the following steps:

1. While subscribing to the DB & Server Access Control service, create a proxy server by selecting VPC, Subnet, and server specifications.
2. Block direct user access and allow proxy server access in the target resource's ACG/Network ACL.
3. Register the access control target as a server target or DB target, and configure the logging scope and masking settings.
4. Connect to the sub-account by defining target access permissions with Sub Account user-defined policies.

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 sent 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.