Introduction The need for privileged accounts is common to most information systems. These accounts are necessary to perform scheduled configuration and maintenance tasks, as well as supervening tasks such as the recovery of a hardware or software failure or the restoration of a backup. Due precisely to the need to use these accounts in an unplanned manner, their management must combine security, procedures and flexibility. In order to effectively manage these accounts, the Soffid product has the necessary logic to:

• Identify accounts
• Classify them according to the level of risk and its scheme of use.
• Distribution and assignment to responsible users.
• Automatic and planned password change process.
• Passwords delivery process to authorized users.
• Automatic injection of passwords, when this injection applies and makes sense

Types of accounts Soffid manages three types of accounts:

• User account. They are assigned to a single user, who is solely responsible for their management.
• Shared accounts They can be used by more than one person. Soffid allows several people to be using that account simultaneously.
• Especially privileged accounts. They can be used by more than one person, but the tool will ensure that only one person can be using the account at any time.

The classification of an account as especially privileged, allows to identify at all times who has made any change in the system, because knowing the moment in which the change has occurred we can identify unequivocally who was in possession of the credentials at any time. Integration mechanisms Soffid integrates with managed systems from two perspectives:

• From the server’s perspective, managing the accounts and permissions of the target system
• From the client’s perspective, automating access and login.

From the server’s perspective, Soffid will connect to the target system to collect existing accounts, create new ones or disable old ones. Additionally, you can change passwords when requested by account owners. The connection to the managed systems can be done in two different ways: with or without a local agent. The agentless connection is easier and faster to configure, while it does not require the installation of software on managed systems. However, the safety of this mechanism has some weaknesses: A privileged account must be created so that the tool can connect remotely to manage the rest of the privileged accounts. If the password for this account is deactivated or lost, none of the system accounts can be managed. Windows, or SSH communications protocols in the case of Linux do not offer 100% effective authentication and encryption mechanisms. For this reason, when the security requirements are high, agents must be installed in each of the managed nodes, increasing the security of the system as a whole. From the security and authentication point of view, communication between the main sync-server and the managed node sync-server is using TLS mutual authentication and encryption.