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.
FREE: Service Account Security For Dummies
Local account provisioningIn 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
Shared account password management
Application to application password management
PASSWORD=$(dzdo /usr/sbin/cgetaccount --silent "$REMOTE_CPS_RESOURCE_NAME/$CPS_USER" 2>> $LOG_FILE)
sshpass -d 300 scp -o StrictHostKeyChecking=no $SCP_USER@$SCP_HOST:"$SCP_FILE_SRC" "$SCP_FILE_DST" 300<<
<"$SCP_PASSWORD" >> $LOG_FILE 2>&1