Application and service accounts: Half protected is half not

Cyber attackers tend to focus on end users to get into an environment, traversing the network and systems. These attackers hunt for accounts with access to sensitive data—their target. While the ultimate “keys to the kingdom” are administrative accounts such as Local Administrator and highly-privileged IT user accounts, non-user accounts such as those used by applications and services also need to be protected. If you’re only securing end user and privileged user accounts, you leave half of the accounts in your environment—application and service accounts—at risk of being compromised.

There are several trends affecting a growing number of applications authenticating to other applications or services for the successful completion of a task:

• Modern multi-tiered web applications. The web layer must authenticate to the computer layer, which authenticates to the database where data is stored.
  
  
• Clustered solutions such as Big Data environments. NoSQL and Hadoop require services running on nodes that must authenticate with other nodes in the Big Data cluster. This includes service accounts such as hdfs, hbase, hive, impala, mapred, yarn, zookeeper, etc.

Additionally, the configuration of a new server with all the requisite agents can be cumbersome and in many cases, applications or agents will require a service account to be provisioned on each system. For example, you may require several accounts such as Splunk or ArcSight Logger and Nagios to exist so that you can monitor the system logs and performance, you may also need another account to enable a central management tool to login and perform management functions. Then there are applications such as Oracle database that require a local service account for the process to run.

The rights or privileges that these types of accounts require, whether access to remote systems (Hadoop service accounts and file transfer batch job scripts) or to control access to sensitive local data (Oracle or HDFS account), present as much if not more risk if a cyberattack were successful in taking over these accounts. Attackers know IT likes to automate the management of servers or file transfers, so they look for these accounts because typically they will allow the attacker to move laterally to other servers within the data center.

Organizations need to make sure to enforce strong password management as well as access controls for these accounts to reduce their identity-related risk. Delinea has introduced several new features that integrate with existing capabilities to provide a complete solution for managing these non-human service accounts.

• Local Account Provisioning – Centralizes the management of local accounts and groups within Delinea Server Suite Zones.
  
  
• Shared Account Password Management – Provisioned local accounts are automatically added to Centrify Privilege Service for password management.
  
  
• Application to Application Password Management – Delinea provides a secure model for enabling scripts to checkout a password for a service account.
  
  
• Local Account Discovery – Delinea Deployment Manager discovers computers and their existing local accounts on Linux and Unix systems.

 

Local account provisioning

In 2016, Server Suite introduced the new capability for Local Account Provisioning:

• local accounts can be created, updated, disabled, and removed from /etc/passwd
• local groups can be created, updated, removed and membership can be managed

 

Now that local accounts can be centrally managed and created locally, we need to provide full lifecycle management and integrate with password management systems. To address this, Server Suite 2016 provides a call-out to enable an external script to take action upon local account creation or deletion. As an example, as a new local account is added, the sample script provided is designed to integrate with Privilege Service in order to add this new account so that its password can be managed, periodically rotated, and available for authorized checkout.

 

 

In this diagram, the Administrator defined the local accounts in the Delinea Access Manager console, then the Delinea Server Suite Agent created the local account in /etc/password and called a script that used the Delinea Privilege Service CLI toolkit to add the account so that its password can be managed. Now all the local accounts are centrally managed and their passwords are managed as well.

 

 

 

 

Once the local account has been registered with Delinea Privilege Service and it is managing the password, we can now grant permissions on these accounts so that other apps or scripts can call the Delinea CLI to request the current password for an account in order to use the password to log in.  In order to control access, we grant the client computer's Active Directory account with checkout permission for the specific account, then the client application account must also be given privileges via sudo or dzdo in order to run the CLI to request checkout for the application account password.

 

 

 Now that the environment is set up to manage the password for the service account, you can replace the password within your scripts with a CLI call from the script to request to check out the password. Once the checkout timeout expires the system will rotate the password to ensure that it is protected.

PASSWORD=$(dzdo /usr/sbin/cgetaccount --silent "$REMOTE_CPS_RESOURCE_NAME/$CPS_USER" 2>> $LOG_FILE)

In this example script (I didn't show all of it, but the sample is provided with the Delinea CLI Toolkit in the samples directory) you can see that you only need to call the cgetaccount command via dzdo or sudo in order to check out the password, then just feed it in where it was previously hard-coded such as here we use sshpass to feed the password into scp for the file transfer operation.

 

Additionally, if you already have several computers with local accounts where you need to have Delinea take over management of the password, you can easily use Delinea Deployment Manager along with some simple custom scripting that uses the Delinea CLI toolkit as a way to enable admins to select specific local accounts, then run the script which will add the account to Privilege Service where it can take over management of the password.

 

 

Delinea provides a complete application account identity lifecycle that combines Local Account Provisioning, Shared Account Password Management, and Application to Application Password Management capabilities in a single integrated solution.

 

You can get started today with a free trial of Delinea Products. or contact your Delinea account team.