SECRET SERVER FEATURE: Enhanced Auditing, Reporting, and Compliance
Meet regulatory requirements and demonstrate compliance
Overview of Approval Workflow:
What’s the challenge?
Given the critical nature of some systems and data, or compliance mandates that require segregation of duties for privileged access, IT teams commonly seek to restrict certain parts of their IT environment.
Many users require only limited or temporary access to privileged accounts. For example, third-party contractors may only need access for a specific project. These users should be able to access a privileged account only if they have a legitimate reason. They should lose their access once the reason is no longer valid.
With so many moving parts, it is typically a challenge to maintain oversight over the various users, and enforce accountability for keeping access levels up to date.
Why it's important
Trusted internal users should be aware of all third-party and temporary access so they can make sure privileged user activities are appropriate and privileges aren’t being misused. Substantial vulnerabilities exist in the organization if there are over-privileged users or credentials that should have been expired.
How approval workflow solves it
Approval workflow increases visibility and oversight for all privileged accounts, especially those accessed sporadically for special projects and by third parties.
Requiring two different users to complete a task helps prevent abuse of privilege. Enforcing approval steps and auditing who requested access and who approved it are key security controls to reduce risk.
Secret Server provides multiple options to implement approval workflows that fit your organization’s IT security policies, systems, and organizational structure.
Request Access
Requiring access approval and ticket validation for privileged credentials is a best security practice. Rather than granting users immediate access to resources, you can implement workflow rules that require them to request access for specific activities over a fixed time period. Until their request is approved by a responsible internal party, users won’t be able to access secrets.
Access can be requested ad hoc or in advance if a user knows they’ll need a credential, for example during a maintenance window.
Approval notifications can be configured to include company-specific policy information.
All requests, approvals, and denials are fully audited for reporting and compliance.
Secret Server’s workflows require that a user is granted approval to access a password or Secret. Once the control is applied, users must request access for a set amount of time and cannot use the Secret until approved.
This can be tied into ticket systems such as ServiceNow or BMC to ensure that the user has a valid change or incident number that they are responding to. Requiring approval with a reason maintains accountability and guarantees that approvers know why a user needs access.
Require Comment
IT Admins may not always be aware of the privileged access needs across the organization. To streamline the approval workflow, and remove the need to follow up on each request, you may require users to explain their need for the access and how they intend to use it, by adding a “comment” to the request. This option gives you fine-grained control of what the user must enter when Require Comment is enabled and ticket system integration is turned on. This allows IT organizations to stay productive, and efficiently meet the ongoing needs of the business
“Require Comment” helps approvers understand the context behind the request so they can make an informed decision. If users aren’t able to provide a legitimate reason that matches your criteria, you can prevent them from gaining access.
Many Secret Server customers rely on the Require Comment feature to enter a tracking number generated by a central change control or task system, providing additional visibility and background for future audits.
Native Ticket System Integration
Secret Server’s Approval Workflow features can be integrated with enterprise ticketing systems such as ServiceNow or BMC to ensure requests include valid change order or incident numbers. You can add multiple ticket systems to Secret Server by simply clicking New Ticket System as well as make a specific ticket system the default system used by Secret Server with just a click on the system link to Set as Default.
After the Ticket System is enabled in Secret Server, a user is able to enter a Ticket Number on the Comment screen or the Request Access screen. Ticket number validation can be included in an approval request or can be a standalone workflow. The Ticket Number will also appear in the audit log and can be queried in reports for easier management and better visibility.
For more information on Ticket Systems Secret Server integrates with, please visit the Delinea Integrations Center
Check Out
Secret Server’s Check Out feature forces accountability by granting exclusive access to a single user with a One Time Password (OTP). OTP, also known as one-time pin or dynamic password, is a password that is valid for only one login session or transaction. OTPs avoid a number of risks associated with traditional, static passwords, while also provide the critical privileged access that certain users require to perform a specific task or function.
After ‘Check In,’ Secret Server automatically performs a random password change on the remote machine. No other user can access a secret while it’s checked out. This requirement establishes direct accountability for a machine that’s accessed during a specific time period.
Check Out ensures that Secret Server is used for all password changes and generates a complete audit trail of password use.
Advanced scripting capabilities allow Check Out to integrate with PowerShell hooks that can run before and after a secret is checked out. These hooks can be used for custom checks or actions to ensure environments are ready, or validate that specific conditions are met, before a user can access a secret.
DoubleLock
DoubleLock provides an additional grouping of privilege to grant select individuals access to highly sensitive data. This feature elevates your privilege security to a higher level. Typically, this feature is used for a company’s most sensitive data, such as banking account numbers, credit card or Social Security numbers, and other critical financial or personal identifying information.
DoubleLock encrypts secrets with a key accessible only with an additional password that’s unique to each user. Without the password, users can’t access the secret, regardless of permission settings or physical access to a machine. Secrets cannot be decrypted even if Secret Server is compromised, or even when someone is accidentally granted permissions to a Secret based on AD group membership.
DoubleLocked secrets can’t be decrypted even if the server and all its data are compromised, or if someone is accidentally granted permissions based on their Active Directory group membership.
DoubleLock provides additional privilege grouping to grant select individuals access to highly sensitive data.
Private/public key encryption enables you to securely share access to DoubleLock between users if desired.
