SEC06-BP03 Reduce manual management and interactive access
Use automation to perform deployment, configuration, maintenance, and investigative tasks wherever possible. Consider manual access to compute resources in cases of emergency procedures or in safe (sandbox) environments, when automation is not available.
Desired outcome: Programmatic scripts and automation documents (runbooks) capture authorized actions on your compute resources. These runbooks are initiated either automatically, through change detection systems, or manually, when human judgment is required. Direct access to compute resources is only made available in emergency situations when automation is not available. All manual activities are logged and incorporated into a review process to continually improve your automation capabilities.
Common anti-patterns:
-
Interactive access to Amazon EC2 instances with protocols such as SSH or RDP.
-
Maintaining individual user logins such as
/etc/passwdor Windows local users. -
Sharing a password or private key to access an instance among multiple users.
-
Manually installing software and creating or updating configuration files.
-
Manually updating or patching software.
-
Logging into an instance to troubleshoot problems.
Benefits of establishing this best practice: Performing actions with automation helps you to reduce the operational risk of unintended changes and misconfigurations. Removing the use of Secure Shell (SSH) and Remote Desktop Protocol (RDP) for interactive access reduces the scope of access to your compute resources. This takes away a common path for unauthorized actions. Capturing your compute resource management tasks in automation documents and programmatic scripts provides a mechanism to define and audit the full scope of authorized activities at a fine-grained level of detail.
Level of risk exposed if this best practice is not established: Medium
Implementation guidance
Logging into an instance is a classic approach to system administration. After installing the server operating system, users would typically log in manually to configure the system and install the desired software. During the server's lifetime, users might log in to perform software updates, apply patches, change configurations, and troubleshoot problems.
Manual access poses a number of risks, however. It requires a server that listens for requests, such as an SSH or RDP service, that can provide a potential path to unauthorized access. It also increases the risk of human error associated with performing manual steps. These can result in workload incidents, data corruption or destruction, or other security issues. Human access also requires protections against the sharing of credentials, creating additional management overhead.
To mitigate these risks, you can implement an agent-based remote
access solution, such as
AWS Systems Manager
Systems Manager gives you fine-grained control over how you can interact with
your managed instances. You define the automations to run, who can
run them, and when they can run. Systems Manager can apply patches, install
software, and make configuration changes without interactive
access to the instance. Systems Manager can also provide access to a remote
shell and log every command invoked, and its output, during the
session to logs and
Amazon S3
Implementation steps
-
Install AWS Systems Manager Agent (SSM Agent) on your Amazon EC2 instances. Check to see if SSM Agent is included and started automatically as part of your base AMI configuration.
-
Verify that the IAM Roles associated with your EC2 instance profiles include the
AmazonSSMManagedInstanceCoremanaged IAM policy. -
Disable SSH, RDP, and other remote access services running on your instances. You can do this by running scripts configured in the user data section of your launch templates or by building customized AMIs with tools such as EC2 Image Builder.
-
Verify that the security group ingress rules applicable to your EC2 instances do not permit access on port 22/tcp (SSH) or port 3389/tcp (RDP). Implement detection and alerting on misconfigured security groups using services such as AWS Config.
-
Define appropriate automations, runbooks, and run commands in Systems Manager. Use IAM policies to define who can perform these actions and the conditions under which they are permitted. Test these automations thoroughly in a non-production environment. Invoke these automations when necessary, instead of interactively accessing the instance.
-
Use AWS Systems Manager Session Manager to provide interactive access to instances when necessary. Turn on session activity logging to maintain an audit trail in Amazon CloudWatch Logs or Amazon S3
.
Resources
Related best practices:
Related examples:
Related tools:
Related videos:
