STIGViewer Support

MongoDB must be configured to restrict the use of administrator access to authorized IP addresses.

Overview

Finding IDVersionRule IDIA ControlsSeverity
V-285312MD7X-00-003350SV-285312r1211022_ruleCCI-000382medium
Description
MongoDB will use Authentication Restrictions to enforce network-based separation of admin users from application users on the same port. With Authentication Restrictions, the database can be configured to specify a list of IP addresses and CIDR ranges from which a user is allowed to connect to the server or from which the server can accept users. Authentication Restrictions addresses the following: - Network-Based Separation: Admin users are restricted to connecting only from designated admin networks/IPs, while application users are restricted to the application subnet. - Unauthorized Access Mitigation: Even if credentials are compromised, connections are blocked from unauthorized networks at the authentication level, leaving no chance for bypass.
STIGDate
MongoDB Enterprise Advanced 7.x Security Technical Implementation Guide2026-05-23

Related Frameworks

1 mapping across 5 frameworks
SCF0 mappings

No source states a mapping between these directly.

Also reachable in 3 hops (2) derived by us, not asserted by any source

Each of these is a route we composed by chaining published mappings. No publisher states a relationship between the two endpoints.

CFG-01Configuration Management Program
1.00
CFG-03Least Functionality
1.00
NIST 800-530 mappings

No source states a mapping between these directly.

Also reachable in 2 hops (33) derived by us, not asserted by any source

Each of these is a route we composed by chaining published mappings. No publisher states a relationship between the two endpoints.

AC-17(1)Monitoring and Control
1.00
AC-17(2)Protection of Confidentiality and Integrity Using Encryption
1.00
AC-17(9)Disconnect or Disable Access
1.00
AC-2(1)Automated System Account Management
1.00
AC-2(4)Automated Audit Actions
1.00
AC-3Access Enforcement
1.00
AC-4Information Flow Enforcement
1.00
AC-6(8)Privilege Levels for Code Execution
1.00
AC-6(9)Log Use of Privileged Functions
1.00
AU-12Audit Record Generation
1.00

+23 more (top 10 by confidence shown)

NIST 800-1710 mappings

No source states a mapping between these directly.

Also reachable in 3 hops (1) derived by us, not asserted by any source

Each of these is a route we composed by chaining published mappings. No publisher states a relationship between the two endpoints.

3.4.6
1.00
CCI1 mapping
NIST CSF 2.00 mappings

No source states a mapping between these directly.

Also reachable in 3 hops (2) derived by us, not asserted by any source

Each of these is a route we composed by chaining published mappings. No publisher states a relationship between the two endpoints.

Who does this work

5 NICE work roles and 5 EC-Council certifications.

This is an inference across published mappings, not a single claim by anyone. This check maps to a control, which maps to a Cybersecurity Framework outcome, which NIST assigns to the work roles below. EC-Council separately maps its certifications to those same roles.

A certification prepares someone for a role. It is not evidence that a holder is qualified, and neither NIST nor EC-Council has stated that any certification here addresses this check.

Work-role assignments published by NIST (NICE Framework Components 2.2.0 and the CSF 2.0 OLIR crosswalk). Certification mappings published by EC-Council.

Details

Check Text (C-285312r1211022_chk)

To verify administrative access is logically separated and restricted to authorized management networks: 1. Review the organization-defined administrative roles. These administrative roles include, but are not limited to root, clusterAdmin, dbAdminAnyDatabase, userAdminAnyDatabase, dbAdmin, userAdmin, and dbOwner. 2. Review all users within the admin database to identify those assigned any of the administrative roles defined above. 3. For each identified administrative user, check for the presence of the authenticationRestrictions field. Verify that a clientSource is defined to restrict access to authorized management networks. Example script: // Define admin roles const adminRoles = new Set(["root", "clusterAdmin", "dbAdminAnyDatabase", "userAdminAnyDatabase", "dbAdmin", "userAdmin", "dbOwner", "<your_custom_admin_role>"]); // Check all users under 'admin' and filter for admin roles const admins = db.getSiblingDB("admin").system.users.find().toArray() .filter(u => u.roles.some(r => adminRoles.has(r.role))) .map(u => { const restr = u.authenticationRestrictions || []; const clientIPs = restr.flatMap(r => r.clientSource || []); const serverIPs = restr.flatMap(r => r.serverAddress || []); return { "User": u.user, "DB": u.db, "Admin Roles": u.roles.filter(r => adminRoles.has(r.role)).map(r => r.role).join(", "), "Client IPs": clientIPs.length ? clientIPs.join(", ") : "ANY (Unrestricted)", "Server Address": serverIPs.length ? serverIPs.join(", ") : "ANY (Unrestricted)" }; }); console.table(admins); If an administrative user does not have an authenticationRestrictions field defined, or if the clientSource is not restricted to a valid, organization-defined management network, this is a finding. If the local policy requires interface-specific isolation and the Server Address is not defined or is not restricted to the server's management interface IP, this is a finding. In the absence of approved documentation, assume localhost (127.0.0.1) is the only approved address. Example output: (note that user0 is compliant while user1 is not) (index) User DB Admin Roles Client IPs Server Address 0 'user0' 'admin' 'root' '127.0.0.1' '127.0.0.1' 1 'user1' 'admin' 'root' 'ANY (Unrestricted)' 'ANY (Unrestricted)'

Fix Text (F-89787r1211021_fix)

For all administrative users that do not have network restrictions configured, use the following command: use admin db.updateUser( "<username>", { authenticationRestrictions: [ { clientSource: [ "<ip_or_cidr>", serverAddress: ["<ip_or_cidr>"] } ] }) Run the following command to set to local host: use admin db.updateUser("<username>", { authenticationRestrictions: [ { clientSource: ["127.0.0.1"], serverAddress: ["127.0.0.1"] } ] }) More information can be found here: https://www.mongodb.com/docs/manual/reference/command/createUser/#authentication-restrictions