Available in VPC
The security configuration for compliance response outlines the scope of services provided by a fully managed cloud database service and explains the steps users need to take to set the appropriate cloud security level for various compliance responses. The key points are as follows:
- Service support scope and management and responsibility entities
- Operating system security policies
- Database security setting
Provided services
The fully managed cloud database services that support security configuration for compliance are as follows:
This feature is not available in the Classic environment. If security configuration for compliance is required, consider migrating to the VPC environment.
| Services | Region (zone) | Platform |
|---|---|---|
| Cloud DB for MySQL | Korea (KR-1, KR-2), Singapore (SGN-4, SGN-5), Japan (JPN-4, JPN-5) | VPC |
| Cloud DB for Cache | Korea (KR-1, KR-2), Singapore (SGN-4, SGN-5), Japan (JPN-4, JPN-5) | VPC |
| Cloud DB for MSSQL | Korea (KR-1, KR-2), Singapore (SGN-4, SGN-5), Japan (JPN-4, JPN-5) | VPC |
| Cloud DB for MongoDB | Korea (KR-1, KR-2), Singapore (SGN-4, SGN-5), Japan (JPN-4, JPN-5) | VPC |
| Cloud DB for PostgreSQL | Korea (KR-1, KR-2), Singapore (SGN-4, SGN-5), Japan (JPN-4, JPN-5) | VPC |
For detailed usage of each service, see Cloud DB for MySQL user guide, Cloud DB for Cache user guide, Cloud DB for MSSQL user guide, Cloud DB for MongoDB user guide, Cloud DB for PostgreSQL user guide.
Service support scope and management and responsibility entities
Fully managed cloud database services fall under the platform-as-a-service (PaaS) model, which provides an environment for the development, deployment, operation, and management of software, including applications. In the PaaS model, servers, networks, storage, and software, which correspond to the cloud infrastructure, are provided as a platform, allowing users to develop, deploy, operate, and manage applications without the need to configure the infrastructure and software themselves. NAVER Cloud Platform is making its best efforts to fulfill its responsibilities as a cloud service provider, and it offers products that allow users to select separate security services to help effectively protect their areas of responsibility.
The globally recognized cloud security services provided by NAVER Cloud Platform ensure the safety of your resources by fulfilling responsibilities within the service support scope handled by NAVER Cloud Platform. When using fully managed cloud database services, the division of management and responsibility between NAVER Cloud Platform and the customer is outlined in the table below. The service support scope refers to the management and responsibility boundaries for each layer.
| Cloud Layer | Fully managed cloud database |
|---|---|
| Data | Customer |
| Applications | Customer |
| Operation Systems(OS) | NAVER Cloud Platform |
| Virtual Machines | NAVER Cloud Platform |
| Hypervisors | NAVER Cloud Platform |
| Processing and Memory | NAVER Cloud Platform |
| Data Storage(hard drivers, removable disks, backups, etc.) | NAVER Cloud Platform |
| Network(Interfaces and devices, communications infrastructure) | NAVER Cloud Platform |
| Physical Facilities / Data Centers | NAVER Cloud Platform |
Operating system security policies
The fully managed cloud database service, as a PaaS model, places the responsibility for the operating system (OS) domain under the cloud service provider's scope. The operating systems for fully managed cloud database services use the same server images provided by NAVER Cloud Platform. NAVER Cloud Platform ensures that the operating systems are kept up to date by providing server images with improved security vulnerability patches annually.
When first creating a service, users can utilize the latest server image provided by NAVER Cloud Platform.
NAVER Cloud Platform provides features to upgrade the operating system to the latest version in line with the server image update schedule. For existing clusters, you can upgrade the operating system of your clusters in accordance with the server image update schedule. The console allows users to check the operating system information for each service and determine whether it can be upgraded to the latest version.
The following is the operating system information for each service:
| Services | Operating system | Server generation | Details |
|---|---|---|---|
| Cloud DB for MySQL | Linux | G2, G3 | Rocky 8.10 |
| Cloud DB for Cache | Linux | G2, G3 | Rocky 8.10 |
| Cloud DB for MSSQL | Windows | G2 | Windows Server 2016 (64-bit) |
| Windows | G3 | Windows Server 2019 (64-bit) | |
| Cloud DB for MongoDB | Linux | G2, G3 | Rocky 8.10 |
| Cloud DB for PostgreSQL | Linux | G2, G3 | Rocky 8.10 |
Linux security policy
Cloud DB for MySQL, Cloud DB for Cache, Cloud DB for MongoDB, and Cloud DB for PostgreSQL are services based on the Linux operating system. The operating systems of these services are identical to the Rocky 8.10 server images provided by NAVER Cloud Platform.
NAVER Cloud Platform regularly updates its server images, and details about update schedules and information for each operating system can be found in the portal's Notices.
Fully managed cloud database services offer feature that allows operating system upgrades to the latest version according to the server image update schedule. For detailed instructions on how to upgrade the operating system of your cluster, see operating system management section of Cloud DB for MySQL user guide, Cloud DB for Cache user guide, Cloud DB for MongoDB user guide, Cloud DB for PostgreSQL user guide.
Windows security policies
Cloud DB for MSSQL is a service based on the Windows operating system. The operating systems of these services are identical to the Windows Server 2016 (64-bit), Windows Server 2019 (64-bit) server images provided by NAVER Cloud Platform.
NAVER Cloud Platform regularly updates its server images, and details about update schedules and information for each operating system can be found in the portal's Notices.
Fully managed cloud database services offer feature that allows operating system upgrades to the latest version according to the server image update schedule. For detailed instructions on upgrading the operating system of your cluster, refer to the operating system management feature in the Cloud DB for MSSQL user guide.
Databases security configuration
Fully managed cloud database services operate under the PaaS model, where database configuration and patch management fall under your responsibility. NAVER Cloud Platform provides security configuration features and guides to help you effectively protect your areas of responsibility. If compliance response is required when using fully managed cloud database services, appropriate database security configuration must be applied.
To set database security configuration for each service: These are based on the vulnerability inspection diagnostic criteria and remediation methods outlined in the Cloud Security Assurance Program (CSAP) CCE standards published by the Korea Internet & Security Agency (KISA). Refer to them for compliance response.
Cloud DB for MySQL
| Diagnosed item | Category | Item name | Item description | Solution |
|---|---|---|---|---|
| DY-01 | Manage account | Remove unnecessary account | If there are unnecessary accounts in the database, such as unauthorized accounts, accounts of former employees, or test accounts that are not practically used for operations, there is a risk that unauthorized individuals may easily access the database to view, delete, or edit data. |
|
| DY-02 | Manage account | Restricting the use of weak passwords | If passwords are identical to account names or use default passwords, there is a significant risk of unauthorized access to the database. Such access could lead to serious incidents, including deletion or modification of the database. |
|
| DY-03 | Security configuration | Restrict the use of the grant permissions to other users option. | Users who receive permissions with the grant option can grant those permissions to other users. Therefore, granting permissions for other objects should be restricted to DBA only. |
|
| DY-04 | Security configuration | Access permissions for DB user account information table | If general users are allowed access to the mysql.user table, they can view the user accounts and passwords registered in the DB. |
|
| DY-05 | Security configuration | Restrict server operation with root privileges. | Root privileges are the highest level of authority in the database and should only be used restrictively by a small number of administrators. | The daemon is not running with root privileges, which is considered secure. |
| DY-06 | Security configuration | Configuration file access permission | Configuration files, being critical MY-SQL files, must have restricted access permissions to prevent potential system failures caused by unauthorized changes. | The configuration file access permissions are set to 640 or lower, which is considered secure. |
| DY-07 | Security configuration | Using secure encryption algorithm | SHA-1 has been identified as a vulnerable algorithm and is no longer secure. Therefore, encryption algorithms of SHA-256 or higher must be used. |
|
| DY-08 | Patch and log management | Enable logging | Enabling the logging feature allows for auditing user statements, permissions, and objects. Additionally, log data can be analyzed to ensure accurate diagnostics in the event of security incidents or system failures. |
|
| DY-09 | Patch and log management | Apply the latest patch. | Security incidents caused by bugs or known vulnerabilities can occur; therefore, it is essential to regularly apply the latest patches to eliminate vulnerabilities. |
|
Cloud DB for Cache
As of January 22, 2026, the Valkey DBMS has been released. Cloud DB for Cache supports the same level of database security settings for Valkey as for Redis.
| Diagnosed item | Category | Item name | Item description | Solution |
|---|---|---|---|---|
| DR-01 | Security configuration | Redis authentication password settings | If a Redis password is not set, any user accessing the server can also access the database, posing a risk of database compromise and information leakage. | - The authentication password setting is disabled because Cloud DB for Cache supports the cluster type. - To use the authentication password setting feature, you need to use Cloud DB for Cache in a public cloud environment. |
| DR-02 | Security configuration | Binding settings | If access is not restricted to authorized IP, there is a risk of unauthorized users accessing the database. | - Cloud DB for Cache does not use Binding settings. Instead, users can control accessible IP through the ACG configuration feature, which serves as an alternative. |
| DR-03 | Security configuration | Slave read only mode settings | In a master and slave environment, the read only feature must be enabled on the slave to prevent modifications to resources on the master. | - Set replica-read-only as yes. |
| DR-04 | Security configuration | Rename-command settings | In shared environments, it is not possible to rename dangerous commands. To prevent unauthorized users from altering the environment or using commands that pose risks to data, dangerous commands should be disabled or restricted. | - Cloud DB for Cache cannot execute the config command. |
| DR-05 | Directory and file permissions management | Data directory access permission settings | If general users can create, delete, or modify arbitrary files in the Redis installation directory, it may lead to issues such as deletion of critical files or backdoor insertion. | - Set to 750, which is considered secure. |
| DR-06 | Directory and file permissions management | Configuration files access permission settings | If configuration files have others permissions, there is a risk that unauthorized users could access the files to make changes, potentially causing service disruptions. Additionally, such access could allow attackers to obtain information from the configuration files to use in secondary attacks. | - Set to 600, which is considered secure. |
| DR-07 | Patch and log management | Enable logging | Logs should be analyzed regularly to determine whether any intrusions have occurred. Suspicious intrusion attempts should be analyzed, and systematic log management tasks—such as blocking access to the affected equipment in advance—should be performed. | - slowlog-log-slower-than is set to 10000, which is considered secure. - Set log level to notice. |
| DR-08 | Patch and log management | Apply the latest patch. | If the latest patches are not applied, the database is at risk of exposure to well-known vulnerabilities. | - NAVER Cloud Platform regularly provides the latest versions. - You can perform minor version upgrades using the DB Engine Upgrade feature. |
Cloud DB for MSSQL
| Diagnosed item | Category | Item name | Item description | Solution |
|---|---|---|---|---|
| DS-01 | Manage account | Remove unnecessary account | If there are unnecessary accounts in the database, such as unauthorized accounts, accounts of former employees, or test accounts that are not practically used for operations, there is a risk that unauthorized individuals may easily access the database to view, delete, or edit data. | - Some accounts are created by the service itself to provide features including monitoring, backup, and failover, requiring exception handling (rdsadmin, agent). - You can manage other settings through SSMS. |
| DS-02 | Manage account | SYSADMIN privilege restriction | The sysadmin (System administrators) role is designed for users who require full administrative privileges over the sql Server and its databases. Members of this role can perform any task on the sql Server. If unauthorized users are added as members of this role, there is a significant risk of direct attacks on the database. | - Some accounts are created by the service itself to provide features including monitoring, backup, and failover, requiring exception handling (rdsadmin, agent). - You can manage other settings through SSMS. |
| DS-03 | Manage account | SA account password management | The sa account is a default account created during the installation of MS-SQL and has sysadmin privileges. If this account does not have a password, malicious users could exploit it to gain full access to the database and perform any operations. | - The SA account is Disabled. |
| DS-04 | Manage account | Limit the use of guest account | The guest account is a special login account that allows all SQL users to access the database with guest permissions. Since it permits unauthorized users to access the database, the guest account permissions must be removed from the database. | - There are no unnecessary guest permissions in the database. |
| DS-05 | Security configuration | Registry Procedure Permissions restriction | Using registry extended stored procedures allows access to the Windows registry. The registry contains configuration information for SQL and may include passwords for remote or local systems. This poses a risk of malicious users damaging the server and database or gaining unauthorized access to the Windows registry. | - Procedures are restricted in the system extended stored procedure restriction list, which is considered secure. |
| DS-06 | Security configuration | Restrict the use of xp_cmdshell | Among the extended procedures provided by MS-SQL for server maintenance, specific procedures frequently exploited in hacking attempts must be removed. In particular, xp_cmdshell is commonly used in hacking tools, especially those originating from China. If not necessary, it must be removed. | - xp_cmdshell is restricted, which is considered secure. |
| DS-07 | Patch and log management | Enable logging | Audit logs must be configured to comply with the audit logging policies defined by the organization. Additionally, the database must establish backup policies for data, logs, and applications. | - Enable Audit in the audit settings management section. - Logs can be viewed on the Monitoring screen. |
| DS-08 | Patch and log management | Apply the latest patch. | If critical security patches for the database are not installed, the database may be exposed to vulnerabilities, posing a risk of attackers damaging the database or gaining unauthorized access. | - NAVER Cloud Platform regularly provides the latest versions. - You can perform upgrades using the MSSQL Engine Upgrade feature. |
Cloud DB for MongoDB
| Diagnosed item | Category | Item name | Item description | Solution |
|---|---|---|---|---|
| MG-01 | Manage account | Remove unnecessary databases and tables | If unused databases (collections) exist, they may be exposed to known vulnerabilities due to poor management. | - Some databases are created by the service itself to provide management features including monitoring, backup, and failover, requiring exception handling (admin, config, local). |
| MG-02 | Manage account | Remove unnecessary account | If unused database accounts exist, they may pose a risk of unauthorized access due to poor management. | - Some accounts are created by the service itself to provide features including monitoring, backup, and failover, requiring exception handling (cdb_admin, agent). - For other accounts created directly by you, management and control can be done through DB Service details > DB user management. |
| MG-03 | Manage account | Use authentication options when running the daemon. | If the MongoDB daemon mongod is executed without enabling authentication options, it allows access without authentication, posing a risk of unauthorized users accessing the database and performing malicious actions. | - Authentication options are enabled when running the daemon, which is considered secure. |
| MG-04 | Manage account | Administrator account creation status | If no administrator account exists, there is a risk of unauthorized access to the database or arbitrary termination of the database server. | - An administrator account has been created, which is considered secure. |
| MG-05 | Access control and service management | Permissions management for key executable and configuration files. | Executable files should be owned by a dedicated account or administrator to prevent damage to the entire system. Additionally, read, write, and execute permissions for others must be removed to protect against unauthorized execution and data theft. | - Permissions for key executable and configuration files are set to 750 or lower, which is considered secure. |
| MG-06 | Access control and service management | Http interface access control | If access restrictions are not configured for the http interface, anyone can monitor MongoDB through the interface, potentially using the gathered information for secondary attacks. | - An authentication prompt is activated when accessing the interface, which is considered secure. |
| MG-07 | Access control and service management | Database access restriction settings | If access restrictions are not configured, unauthorized users may gain access to the database and perform brute force attacks to acquire DBA privileges, posing a risk of database manipulation. | - Accessible IP can be controlled using the ACG configuration feature, providing an alternative solution. |
| MG-08 | Patch and log management | Application of the latest security patches and vendor recommendations for the database. | If critical security patches for the database are not installed, the database may be exposed to its inherent vulnerabilities, increasing the risk of attackers damaging the database or gaining unauthorized access. | - NAVER Cloud Platform regularly provides the latest versions. - You can perform upgrades using the MongoDB Engine Upgrade feature. |
| MG-09 | Patch and log management | Database access, modification, deletion, audit logs, and backup | Audit logs must be configured to comply with the audit logging policies defined by the organization. Additionally, the database must establish backup policies for data, logs, and applications. | - The Enterprise Edition of Cloud DB for MongoDB provides an audit feature. - Audit graph charts can be viewed on the monitoring screen. |
Cloud DB for PostgreSQL
| Diagnosed item | Category | Item name | Item description | Solution |
|---|---|---|---|---|
| DP-01 | Security configuration | Remove unnecessary account | If there are unnecessary accounts in the database, such as unauthorized accounts, accounts of former employees, or test accounts that are not practically used for operations, there is a risk that unauthorized individuals may easily access the database to view, delete, or edit data. | - Some accounts are created by the service itself to provide features including monitoring, backup, and failover, requiring exception handling (pgautofailover_monitor, pgautofailover_replicator). - For other accounts created directly by you, management and control can be done through DB Service details > DB user management. |
| DP-02 | Security configuration | Restricting the use of weak passwords | If passwords lack complexity or are null, unauthorized users may easily access the database. This can lead to serious security incidents, such as database deletion or modification. | – Enter 8 to 20 characters using at least 1 English letter, number, and special character. - Install passwordcheck from DB Service details > Extension management. |
| DP-03 | Security configuration | Remove unnecessary permission | In PostgreSQL, permissions can be configured for accounts. If an account is assigned superuser privileges, it can bypass all permissions and perform any tasks. Additionally, accounts with the create role privilege can create new accounts and assign permissions. If unnecessary accounts are granted superuser or create role privileges, there is a risk of unauthorized users accessing the database to create or delete accounts, view, delete, or edit data. | - Some accounts are created by the service itself to provide features including monitoring, backup, and failover, requiring exception handling (pgautofailover_monitor, pgautofailover_replicator). - For other accounts created directly by you, management and control can be done through DB Service details > DB user management. |
| DP-04 | Security configuration | Restrict usage of the public schema | When DB is created in PostgreSQL, a public schema is generated by default. If tables are created without specifying a different schema, they are placed in the public schema, which is accessible by all objects. This poses risks such as information leakage and resource exhaustion. | - You can directly revoke permissions and create a new schema for migration through public schema management. |
| DP-05 | Security configuration | IP access restriction settings | If access is not restricted to authorized IP, there is a risk of unauthorized users accessing the database. | - Accessible IP can be controlled using the ACG configuration feature, providing an alternative solution. |
| DP-06 | Security configuration | Secure authentication method configuration | PostgreSQL supports various authentication methods, but some, such as trust and password, are not secure. With trust authentication, access is allowed without a password or other authentication. When using password authentication, passwords are transmitted in plain text, making them vulnerable to exposure through sniffing attacks. | - The system is configured to use SHA-256 for authentication, which is considered secure. |
| DP-07 | Security configuration | Using secure encryption algorithm | SHA-1 has been identified as vulnerable, and algorithms lower than SHA-1 are no longer considered secure. Therefore, encryption algorithms of SHA-256 or higher must be used. | - The system is good as it is configured with a secure encryption algorithm using SHA-256 for authentication. |
| DP-08 | Directory and file permissions management | Data directory permission settings | If general users can create, delete, or modify arbitrary files in the PostgreSQL data directory, it may lead to issues such as the deletion of critical files or backdoor insertion. | - The permissions for the data directory are set to 700, which is considered secure. |
| DP-09 | Directory and file permissions management | Environment configuration file permission settings | If one of PostgreSQL's critical files, the configuration file, is modified by unauthorized users, it may cause system failures. | - The configuration file permissions are set to 600, which is considered secure. |
| DP-10 | Patch and log management | Enable logging | Logs should be analyzed regularly to determine whether any intrusions have occurred. Suspicious intrusion attempts should be analyzed, and systematic log management tasks—such as blocking access to the affected equipment in advance—should be performed. | - You can configure log_statement, log_connections, and log_disconnections in DB Service details > DB Config management. - Logs can be viewed on the Monitoring screen. |
| DP-11 | Patch and log management | Apply the latest patch. | If the latest patches are not applied, the database is at risk of exposure to well-known vulnerabilities. | - NAVER Cloud Platform regularly provides the latest versions. - You can perform upgrades using the version upgrade feature. |
Database version management policy
Fully managed cloud database services provide upper minor versions of the major versions currently supported, considering the release schedule of the latest versions for each DB engine and the impact of changes. Additionally, technical support for errors or failures caused by maintaining outdated versions will be discontinued after a certain period in alignment with the End of Life schedule. Therefore, it is recommended to always maintain the latest version by using the DB engine upgrade feature provided for each service.
The following is the DB version information provided for each service as of 2025: Note that the actual DB versions and schedules provided may change depending on the operational policy and the impact of changes for each DB engine.
| Services | Major version | Versions provided | Latest version release | End of Life Date | Fade out | Suspend support |
|---|---|---|---|---|---|---|
| Cloud DB for MySQL | MySQL 8.0 | MySQL 8.0.42 MySQL 8.0.40 MySQL 8.0.36 MySQL 8.0.34 |
April 2026 | April 30, 2026 | - | - |
| MySQL 8.4 | MySQL 8.4.6 | January, June, and November 2026 | April 30, 2032 | - | - | |
| Cloud DB for Cache | Redis 5.0 | Redis 5.0.14 | - | April 27, 2022 | September 18, 2025 | April 23, 2026 |
| Redis 7.0 | Redis 7.0.15 Redis 7.0.13 |
- | July 29, 2024 | September 18, 2025 | April 23, 2026 | |
| Redis 7.2 | Redis 7.2.11 Redis 7.2.8 Redis 7.2.6 |
- | February 28, 2026 | - | - | |
| Valkey 7.2 | Valkey 7.2.11 | January, June 2026 | April 16, 2027 | - | - | |
| Cloud DB for MSSQL | SQL Server 2019 | SQL Server 2019 15.0.4440.1 SQL Server 2019 15.0.4410.1 SQL Server 2019 15.0.4395.2 SQL Server 2019 15.0.4355.3 SQL Server 2019 15.0.4326.1 SQL Server 2019 15.0.4298.1 SQL Server 2019 15.0.4198.2 SQL Server 2019 15.0.2000.5 |
January, June 2026 | January 08, 2030 | - | - |
| Cloud DB for MongoDB | MongoDB 5.0 | MongoDB 5.0.25 MongoDB 5.0.19 |
- | October 31, 2024 | November 20, 2025 | June 25, 2026 |
| MongoDB 6.0 | MongoDB 6.0.27 MongoDB 6.0.19 MongoDB 6.0.15 |
January 2026 | July 31, 2025 | September 17, 2026 | - | |
| MongoDB 7.0 | MongoDB 7.0.28 MongoDB 7.0.24 MongoDB 7.0.19 |
January 2026 | August 31, 2026 | - | - | |
| MongoDB 8.0 | - | June 2026 | October 31, 2029 | - | - | |
| Cloud DB for PostgreSQL | PostgreSQL 13 | PostgreSQL 13.21 PostgreSQL 13.18 PostgreSQL 13.15 PostgreSQL 13.13 PostgreSQL 13.10 PostgreSQL 13.7 PostgreSQL 13.3 |
- | November 13, 2025 | November 24, 2026 | - |
| PostgreSQL 14 | PostgreSQL 14.20 PostgreSQL 14.18 PostgreSQL 14.13 |
January, June 2026 | November 12, 2026 | - | - | |
| PostgreSQL 15 | PostgreSQL 15.15 | January, June 2026 | November 11, 2027 | - | - |
- If the end of life date has passed or is approaching for a DB version, new minor versions will no longer be released. It is recommended to use the latest available higher version.
- To ensure stable service operations, NAVER Cloud Platform stops selling a version 12 months after its End of Life date, allowing users sufficient time to verify and upgrade their DB engines. Once a version is discontinued for sale, it will no longer be possible to create new clusters using that version. However, existing clusters can still be used until they are decommissioned.
- End of Support is applied 6 months after the version is discontinued for sale. After this, no technical support will be provided for errors or issues caused by maintaining the version, and service credits based on the Service Level Agreement (SLA) will not be issued.
- When a version is discontinued for sale or support, announcements will be posted in the portal and individual users will be notified.
Check FAQs first.
You can have your questions answered quickly by referring to the answers in the FAQs before reading the user guides. If your questions are not resolved in the FAQs, see user guides to find the information you want.
Q. You need the results of the CCE vulnerability script for the database area of the cluster in use.
A. Fully managed cloud database services do not allow users access to the operating system in order to provide quality services guaranteed by the terms of service and Service Level Agreements (SLA). Instead of running the CCE vulnerability script by accessing the operating system, follow the Database security configuration guide, take the appropriate actions for the cluster in use, and submit proof of the actions taken.
Q. You need the results of the CCE vulnerability script for the OS area of the cluster in use.
A. According to the cloud shared responsibility model, the security of the operating system for fully managed cloud database services falls under the responsibility of the cloud service provider. The service provider regularly undergoes security checks by a certification body to ensure proper security configuration are applied. Therefore, proceed with the certification evaluation excluding the OS area of the cluster in use.
For more information, see Cloud shared responsibility model and security architecture and security guide on the portal.
Q. I need the results of the CVE vulnerability script for the cluster in use.
A. According to the cloud shared responsibility model, the security of the operating system for fully managed cloud database services falls under the responsibility of the cloud service provider. The service provider regularly undergoes security checks by a certification body to ensure proper security configuration are applied. Therefore, proceed with the certification evaluation excluding the OS area of the cluster in use.
For more information, see Cloud shared responsibility model and security architecture and security guide on the portal.
Q. Can I get evidence that the database security check items have been applied to my cluster?
A. For database security check items, we do not provide individual proof by accessing the running server. Follow the Database security configuration guide to take appropriate actions on your cluster and submit the actions taken as evidence.
Q. How do you address security vulnerabilities in the OS area of the cluster in use?
A. NAVER Cloud Platform provides server images with improved vulnerabilities every year to keep the operating system updated with the latest version.
NAVER Cloud Platform provides features to upgrade the operating system to the latest version in line with the server image update schedule. For existing clusters, you can upgrade the operating system of your clusters according to the server image update schedule and submit proof of the upgrade.
Q. You need to upgrade the DB engine of the cluster in use to the latest version.
A. NAVER Cloud Platform provides the latest version of DB engines twice a year. For subscribed clusters, you can upgrade to the latest version using the DB engine upgrade feature for each service.
Q. You need the schedule for the latest version of DB engines provided by the fully managed cloud database service.
A. Refer to the Database version management policy However, the actual provided schedule may change depending on the operational policy and impact of changes for each DB engine.
Q. Can you configure password management policies in the fully managed cloud database service?
A. For all services, when creating them for the first time, you must enter a password between 8 and 20 characters that includes at least one English letter, one number, and one special character.
For Cloud DB for MySQL, password management policies can be configured through DB Service details > password plugin settings.
For Cloud DB for PostgreSQL, password management policies can be set by installing passwordcheck in DB Service details > Extension management.
Q. What encryption algorithms are provided by the fully managed cloud database service?
A. All services support the SHA-256 encryption algorithm.
For Cloud DB for MySQL, SHA-256 is provided starting with MySQL 8.0, and you can change the authentication plugin to SHA-256 through DB Server details > DB Config management.
Q. What settings are required for offsite backups?
A. Cloud DB for MySQL, Cloud DB for MSSQL, and Cloud DB for PostgreSQL offer the multi-zone option. When creating a high-availability cluster for Cloud DB for MySQL or Cloud DB for PostgreSQL with the multi-zone option set to Y, backups are stored in the zone where the secondary server is located, placing the master server and backups in different zones. For the Cloud DB for MSSQL service, when creating a high-availability cluster, backups are stored in the zone where the principal server is located.
All services also provide a feature Send to Object Storage. You can store the downloaded backup files in a bucket wherever you choose.
Q. Does the fully managed cloud database service provide audit logs?
A. All services provide audit logs, and the conditions for each service are as follows:
| Services | Setup method | View method |
|---|---|---|
| Cloud DB for MySQL | Enable DB Service details > Audit Plugin settings. Enable general log as ON under **DB Server details ** > DB Config management. |
Logs can be viewed on the Monitoring screen. |
| Cloud DB for Cache | Automatically set whether to record slow queries and log levels when first created. | Logs can be viewed on the Monitoring screen. |
| Cloud DB for MSSQL | Enable Audit in the audit settings management section. | Logs can be viewed on the Monitoring screen. |
| Cloud DB for MongoDB | Audit feature is automatically provided upon initial creation with the Enterprise Edition. | Logs can be viewed on the Monitoring screen. |
| Cloud DB for PostgreSQL | log_statement can be configured in DB Service details > DB Config management. | Logs can be viewed on the Monitoring screen. |
Q. Can I modify the default ACG policy to set database access restrictions?
A: The default outbound ACG policy for Cloud DB for Cache and Cloud DB for MongoDB services allows ports 1 to 65535. This is because synchronization between the primary and secondary servers may not proceed normally. However, if you need additional access control, you can modify the policy to allow only the ports specified by the user for DB communication purposes.
For Cloud DB for MySQL, Cloud DB for MSSQL, and Cloud DB for PostgreSQL, the default outbound ACG policy specifies a single port.
Q. Does the service provide encrypted communication (SSL/TLS)?
A. NAVER Cloud Platform recommends selecting a private subnet during initial creation.
If a public subnet is selected based on user requirements, encrypted communication can be set up using NAVER Cloud Platform's SSL VPN or IPsec VPN services. For more information, see SSL VPN and IPsec VPN.
Q. CentOS 7 reached its End of Life (EoL) on June 30, 2024. How should services using Linux OS respond?
A. NAVER Cloud Platform ensures that the operating systems are kept up to date by providing server images with improved security vulnerability patches annually.
As of October 17, 2024, the operating system for Cloud DB for MySQL, Cloud DB for Cache, Cloud DB for MongoDB, and Cloud DB for PostgreSQL is the same as the Rocky 8.10 server image provided by NAVER Cloud Platform. After October 17, 2024, newly created DB Server will use the latest version of the server image provided by NAVER Cloud Platform.
NAVER Cloud Platform provides features to upgrade the operating system to the latest version in line with the server image update schedule. If you're still using a CentOS 7-based Cloud DB for MySQL, Cloud DB for Cache, Cloud DB for MongoDB, or Cloud DB for PostgreSQL created before October 17, 2024, use this upgrade feature to bring your cluster's operating system up to date.
Q. The latest DB version is not visible in the DB engine upgrade screen for each service.
A. NAVER Cloud Platform provides Rocky 8.10 operating systems for clusters created after October 17, 2024, and the latest DB versions are only available on the Rocky 8.10 operating system. If the creation date of the currently operating cluster is before that, you will not be able to perform a DB engine upgrade to the latest version in the upgrade screen.
NAVER Cloud Platform provides features to upgrade the operating system to the latest version in line with the server image update schedule. You can check the operating system version of your cluster in the operating system management screen and upgrade it to the latest version. After updating the operating system to the latest version, proceed with the DB version upgrade.