STIGhubSTIGhub
STIGhub— A free STIG search and compliance tool·STIGs updated 2 hours ago
Powered by Pylon·Privacy·Terms·Feedback·© 2026 Beacon Cloud Solutions, Inc.
← Back to MariaDB Enterprise Server Security Technical Implementation Guide

V-286236

CAT II (Medium)

MariaDB must protect nonlocal maintenance sessions by separating the maintenance session from other network sessions with the system by logically separated communications paths.

Rule ID

SV-286236r1292221_rule

STIG

MariaDB Enterprise Server Security Technical Implementation Guide

Version

V1R1

CCIs

CCI-004192

Discussion

Nonlocal maintenance and diagnostic activities are conducted by individuals who communicate through either an external or internal network. Communications paths can be logically separated using encryption.

Check Content

Verify which network interface MariaDB is listening on. As a DBA, run:

SHOW GLOBAL VARIABLES LIKE 'bind_address';

Confirm MariaDB is bound to a specific interface or management network address and not to all interfaces (0.0.0.0) unless network controls enforce separation.

If MariaDB listens on all interfaces without network-level separation controls, this is a finding.

Verify remote administrative access restrictions. Check configured accounts that can access MariaDB remotely:

SELECT user, host FROM mysql.user;

Confirm administrative accounts (e.g., root, DBAs) are restricted to localhost, management network ranges, and bastion or administrative hosts.

If administrative accounts allow unrestricted remote access (e.g., %), this is a finding.

Verify secure transport is enforced for remote maintenance sessions by running:

SHOW GLOBAL VARIABLES LIKE 'require_secure_transport';

Expected result:
require_secure_transport = ON

If secure transport is not required for remote connections, this is a finding.

Verify network architecture documentation confirms that database administration occurs through a logically separated management network or administrative access path (e.g., bastion host, VPN, management VLAN, or private network).

If administrative access shares the same communication path as general application traffic without logical separation, this is a finding.

Fix Text

Configure MariaDB to protect nonlocal maintenance sessions by separating the maintenance session from other network sessions with the system by logically separated communications paths. Protecting nonlocal MariaDB maintenance sessions involves separating them from other network sessions, ensuring enhanced security. This separation can be achieved through either physically or logically separated communication paths, coupled with robust authentication.

1. Implement multi-factor authentication (MFA) or Public Key Infrastructure (PKI) with certificates protected by passwords, passphrases, or biometrics. 

2. Use separate network interfaces on the MariaDB server for maintenance traffic, routing it through a distinct physical network segment or VLAN.

Implement a dedicated, isolated network specifically for maintenance and administrative tasks, ensuring no other application traffic traverses this network.

Logically Separated Communications Paths:
a. Establish secure VPN tunnels for remote maintenance sessions, encrypting all traffic and isolating it from the general network.

b. Configure MariaDB to enforce SSL/TLS encryption for all maintenance connections, ensuring data confidentiality and integrity. Enable SSL in the MariaDB configuration file ("my.cnf or my.ini") and configure client applications to use SSL.

c. Implement strict firewall rules on the MariaDB server and network infrastructure to restrict access to the MariaDB port (default 3306) only from authorized maintenance hosts or subnets. This limits the attack surface for unauthorized connections.

d. Define specific roles with limited privileges for maintenance tasks, granting only the necessary permissions to perform maintenance activities and preventing over-privileging of user accounts.

To verify if MariaDB has implemented Role-Based Access Control (RBAC), check for Active Roles for a current user: 

SELECT CURRENT_ROLE();

To view the grants associated with a specific user: 

SHOW GRANTS FOR 'username'@'host';

To view the grants associated with a specific role: 

SHOW GRANTS FOR 'rolename';

The output of these "SHOW GRANTS" commands will reveal if privileges are directly assigned or if they are granted through roles, indicating RBAC implementation.

When roles are used, they often need to be activated. If users are explicitly setting roles upon connection or within sessions using "SET ROLE", it signifies the use of RBAC.