Passwordstate has comprehensive auditing, with over 120 different Audit Events. These events detail when password credentials and other information has been accessed, by whom, when and much more. For a comprehensive list of events please refer to https://www.clickstudios.com.au/about/compliance-reporting.aspx.
When you scale out your Passwordstate implementation to include High Availability, in either an Active / Passive or Active / Active design, the storing of Auditing information subtly changes. Add to this, requirements for Syslog or SIEM (Security Information and Event Management) integration and knowing where auditing is stored and being accessed from can become a little confusing for those new to Passwordstate.
Passwordstate High Availability
Passwordstate supports 2 types of HA (High Availability), Active / Passive and Active / Active. Both have their use cases and the type of HA implementation you decide on will very much depend on your organization’s business requirements, risk appetite and budget. When implementing Passwordstate HA you’ll require our HA license, even if you intend on using Virtual Server Replication technologies for your implementation.
The image below is a simple logical view of the 2 types of HA that Passwordstate can be implemented with. In both of the diagrams the databases are installed on the webservers to maintain simplicity.
Active / Passive Implementations: This design on the left hand side provides an Active Primary instance of Passwordstate and a Passive Secondary instance. Your users are serviced from the Primary instance and your secondary instance is effectively on standby. Replication of SQL data occurs from your Primary instance to the database on the Secondary instance. Any auditing data from your Secondary instance is posted back to your Primary instances API every few minutes and subsequently inserted into the Primary’s database.
In the event your Primary instance is unavailable, you would normally point users to the Secondary instance where they can access their data as read only. No credentials can be changed by users while using the Secondary instance. All access to credentials is logged into a local audit database, and once the Primary Instance resumes normal operation, these audit entries are synchronized back with the Primary instance.
Active / Active Implementations: This design provides an Active Primary instance of Passwordstate and an Active Secondary instance. Your users are serviced from either the Primary instance or your Secondary instance. Both instances support full read & write operations. Your users are typically directed to an appropriate instance via a load balancer. Replication of SQL data occurs both ways, i.e., data initially written to your Primary instance is replicated to the database on the Secondary instance and data initially written to the Secondary instance is replicated to your Primary instance.
In the event your Primary or Secondary instance is unavailable, your load balancers should be configured to direct all Passwordstate traffic to the instance that remains operating. All access to credentials is logged as normal. If the Primary instance isn’t available the Secondary instance will synchronize its database and auditing data back to the Primary Instance once it resumes normal operation. When both instances are running normally the Secondary instance will synchronize its database and auditing data back to the Primary Instance on a regular basis.
Syslog and SIEM Integration
Passwordstate provides the ability to feed your audit entries directly into your Syslog or SIEM solution. It does this via specifying the Server details including name, port number, date format and specifying the type of protocol to use.
The setting can be configured under Administration->System Settings-proxy and syslog servers as shown below,
Once configured all audit entries are initially sent from your Primary instance. In a HA environment, regardless of your configuration (Active / Passive or Active / Active), the audit entries are sent only from your Primary instance. This has all the audit events for your Primary and Secondary instances as described earlier.
After the initial forwarding of all audit entries, the Passwordstate Windows Service on your Primary instance will monitor for new audit entries and send these through to your Syslog server every couple of minutes.
If you’d like to share your feedback please send it through to support@clickstudios.com.au.