https://www.redhat.com/en/blog/what-about-root-passwords

If you’ve walked long enough into your enterprise identity management journey you might reach this question: How will root passwords be managed? Having centralized user and group IDs, your access policies—Host Based Access Control (HBAC) and Role Based Access Control (RBAC)—in Red Hat Identity Management (IdM) or any similar solution might still leave root passwords unmanaged.

Consider the below PCI-DSS requirements for example. How would you apply that on root?

8.2.4 Change user passwords/passphrases at least once every 90 days.

8.2.6 Set passwords/passphrases for first-time use and upon reset to a unique value for each user, and change immediately after the first use.

In this post, we’ll cover some approaches to manage root passwords efficiently, on a large scale.

Privileged Access Management (PAM)

The concept of managing privileged accounts, such as root, is a thing among operating systems. There is a wide range of commercial products to help with that. Many of them are cross platform products—they help manage different types of operating systems.

Privileged accounts are those accounts you most definitely never want to lose control over.

The National Institute of Standards and Technology (NIST) issues regular publications around security standards, guidelines and recommended security controls. One of them, publication 800-53 (NIST 800-53) deals with Security and Privacy Controls for Information Systems and Organizations. We will not delve into 800-53 here, but if we summarize the strategy to manage privileged accounts we’ll get:

Identify and classify: while root is the obvious privileged account, your organization might have other accounts to look after.
Develop explicit policies for privileged accounts: Privileged accounts require a seperate set of policies. Clearly define these policies and the 5Ws (What, Why, When, Where, and Who) aspects of these policies. For example, who is allowed access to root, and under which circumstances (when).
Monitor and record privileged accounts sessions: All activities on privileged accounts should be recorded to enforce proper behavior and in some situations, such as with PCI-DSS, it is a compliance requirement.
Track and alert on user’s behavior: Since we’re monitoring, might as well get alerts on anomalies. Define your organization's baseline and set alerts for what’s out of the baseline.
Principle of least privilege: Allow users to escalate privilege (sudo) only for the commands that they need to handle their day-to-day operations.
Review and audit: Regularly review the generated reports for privileged accounts to identify anomalies. Once again, this might be a compliance requirement as well.

In this post we will be focusing only on managing root passwords, on a scale, with technologies available already within Red Hat Enterprise Linux.

Public cloud versus on-premise

Public clouds’ approach is to lock privileged accounts like root and offload access to another user with ssh-key authentication. Below are examples from Amazon Elastic Compute Cloud (Amazon EC2), Google Cloud Platform (GCP), and Microsoft Azure

Amazon EC2