Secure deployment considerations
When you deploy the IBM® Verify Identity Access appliance, consider the following points.
- The Verify Identity Access embedded user registry should only be used in the following scenarios:
- Proof of Technology deployments
- Deployments with a low number of Verify Identity Access users (< 5000)
- When using federated directories with the Verify Identity Access basic user feature
- Choose the suitable Verify Identity Access user authentication mode for your environment.
- Use basic user for all scenarios unless GSO lock-box, user based ACLs, or account-valid/password-valid features are required.
- Only use the full user model if basic user is not suitable. Basic user only supports minimal mode.
- The appliance has management and application interfaces. Network separation between the management and application interfaces must be maintained.
- Any Verify Identity Access web reverse proxies that are hosted in the corporate DMZ network zone should be configured as restricted nodes.
- The Verify Identity Access appliance that hosts the Policy Server component should be hosted in a secure network zone and not exposed to the internet.
- If the embedded user registry is used, it should be hosted on the same appliance as the Security Verify Identity Access Policy Server in a secure network zone. The embedded user registry port (636) should not be routable from the internet.
- Verify Identity Access clustering is recommended to provide a highly available solution. Two Verify Identity Access appliances performing the primary and secondary roles respectively should be used. These should be hosted in the secure network zone with Verify Identity Access runtime replication enabled.
- If advanced authentication/authorization is required, the Verify Identity Access authentication service in the Advanced Access Control (AAC) component should be used. This should be hosted on the Verify Identity Access primary and secondary appliances in the secure network zone. This service should not be routable from the internet.
- Second factor or multi-factor authentication should be considered to increase assurance of user identity.
- Enable Network Time Protocol (NTP) on all appliances to synchronize the time correctly. This is to ensure that the appliance works correctly with distributed components.
- Do not use self-signed certificates for any public facing services. Always obtain certificates issued by an appropriate certificate authority.
- All non-TLS communication should be disabled:
- Only use port 636 for LDAP communication.
- Only use HTTPS 443 application interfaces.
- Only use TLS for junction communication.
- Enable the Verify Identity Access Web Application Firewall (WAF) feature on all appliances hosting the Verify Identity Access reverse proxy.
- Session affinity should be enabled between all Verify Identity Access components for performance and scalability reasons.
- The Verify Identity Access Distributed Session Cache (DSC) or failover cookie should be used to provide a highly available solution across multiple reverse proxy instances.
- If the DSC is deployed, it should be hosted in the secure network zone.
- Configure the reverse proxy cookie jar feature to prevent application cookies from being returned to clients unnecessarily.
- Connection pooling for junctions should be enabled to optimize performance of the solution. This capability is disabled by default.
- FIPS should be enabled if appropriate.
- Enable these security headers in the reverse proxy configuration:
- strict-transport-security
- content-security-policy
- Minimize access to unauthenticated resources using standard Verify Identity Access ACL policy.
- Host the Verify Identity Access runtime database on an external Database. This database is used for federation and/or AAC features. The runtime database should be hosted in a secure network zone and should not be routable from the internet.
- Use a highly available solution for the external Verify Identity Access runtime database. This service is critical to Verify Identity Access operation.
- Best practice is to use the Verify Identity Access REST APIs for automated deployment to allow:
- Rapid recovery
- Consistent and repeatable deployment configuration
- Don’t use Basic Authentication (BA) for authentication to Verify Identity Access REST APIs when automating deployment and management of the Verify Identity Access appliance. Certificate authentication should be used.
- Standard network security guidelines should be applied. Network access and administrative credentials to the appliance should only be available to authorized administrators on appropriate networks.
- Minimize on-board storage of logs by configuring remote syslog to store log and audit archives in a protected network zone. A separate logging server/service should be used to store logs.
- An appropriate patch process should be implemented to:
- Subscribe to, and monitor IBM support site for Verify Identity Access appliance patches
- Apply all patches promptly when released
- Set the sps.setCookiesAsSecure parameter to
Secureto flag the cookies set by Verify Identity Access. - Encrypt configuration snapshot for container deployments. Snapshot encryption is enabled by
setting the
CONFIG_SNAPSHOT_SECRETSenvironment variable. - Enable TLS Certificate validation for container deployments when the configuration service is
used to download configuration snapshot file. Certificate verification is enabled by setting the
CONFIG_SERVICE_TLS_CACERTenvironment variable.