Announcing the Saviynt Knowledge Exchange unifying the Saviynt forums, documentation, training,
and more in a single search tool across platforms. Read the announcement here.
No ratings
abhisheknair
Saviynt Employee
Saviynt Employee

Short Description:

While you prepare for your foundation deployment for an Identity Governance solution, please look at the standard set of guardrails and tested patterns to secure the implementation.

Application Version

All versions

Detailed Best Practice

In the scenario where the customer is preparing to go live with the foundation release, it is common for the focus to primarily be on the functional aspects of the solution, often overlooking the implementation of crucial security boundaries. This document aims to address this gap by highlighting the key security aspects that must be considered for a secure and successful go-live of the foundation release.

  1. Institute a Design Review Board Process
    • From the beginning of the program, a DRB process has to be instituted which should have representation from the Customer, Partner and Saviynt team members. DRB should approve the foundation design and any other critical patterns.
  2. Institute a Defect analysis process
    • While the preparation of foundation release is in progress, confirm the process and templates of defect analysis after go-live. This should include the process of creating tickets by end users, triage the tickets internally, contact Saviynt for product queries etc.
  3. Add thresholds on Provisioning jobs – Reference
    • The default value is 5000. Take special care for remove access and delete account task types.
  4. Check the threshold for user import in external config properties file.
    • Any user import which doesn’t have a birth right threshold configurable, it uses a default threshold configured in external configuration properties file. Follow this document to validate this value.
  5. Make sure approvals are configured for rules.
    • Rules are very important configurations in EIC and a minor change in any rule can create production issues if these changes are not reviewed and approved. Make sure you have approval workflow configured for rules (Global Config > Identity Access Rules > Rule Add Workflow)
  6. Make sure approvals are configured for roles.
    • Same as the rules, any role changes without a proper review and approval can create issues with user’s access. Always configure approval for any role changes.
  7. Review the SAV roles and ensure only adequate access is provided for all administration teams.
    • Note that for specific access, you need to have the ROLE_ADMIN sav role. For example, if you want to see all the tasks under Pending Tasks or Completed tasks, either you need to have the ROLE_ADMIN access or you need to be in a SAV Role that is added to the connection of the application. Same with the access to see all roles or rules.
    • Configure ARS process for ROLE_ADMIN access.
  8. Review Control Center reports.
    • Before Go Live, review the Control Center reports and educate the customer how to use those to check regular production metrics.
  9. Add email templates at the connections.
    • These emails will be sent when there is an issue with the jobs for a connection. Please refer this for more details.
  10. Saviynt to approve Go/NoGo for all medium to high complexity changes.
    • After the initial Go Live, it is recommended to get the Saviynt sign off for any major design additions.
  11. Session timeouts
    • In the global configuration, set http.session.timeout to a value less than 30 minutes. Keeping this value to a higher number can create performance issues with the usage of API calls

Key Benefit (Quantitative/qualitative)

  • Improved support posture

Reference documentation

https://docs.saviyntcloud.com/bundle/EIC-Admin-v2021x/page/Content/Chapter02-Identity-Repository/Cre...

https://docs.saviyntcloud.com/bundle/EIC-Admin-v2020x/page/Content/Chapter06-EIC-Configurations/Crea...

https://docs.saviyntcloud.com/bundle/KBAs/page/Content/Technical-rules-are-not-triggered-for-grantin...

Version history
Last update:
‎06/05/2023 10:39 AM
Updated by:
Contributors