SGNL leverages business context from Data Sources in order to make just-in-time access decisions. In any organization, there will be times when an Administrator, Support User, or Audit/Compliance Specialist will need to understand why a specific access decision was made.
SGNL provides various capabilities to support the troubleshooting of Access Decisions, many of these will be discussed in this article.
You can have any number of Policy versions assigned to a protected integration and different policies may affect various principals, assets, and actions differently.
It’s important to think about the order by which access decisions are made:
There may be times where you have only Simulated policies assigned to an Integration. Simulated policies will never impact the Access Decision returned by the SGNL Access Service. They will however provide logging and auditing events that can be used to assess the impact of a policy being applied to an integration.
Simulated policies can also be useful for debugging and troubleshooting to understand individual impacts of policies.
SGNL Policy Lens is the most straightforward way to understand why a given Access Decision has been made in one of the systems that have been configured to use SGNL to provide access control.
To get started with Policy Lens, select it from the left navigation menu, and select the Protected Integration you’re investigating.
Enter the Principal ID of the user you are investigating, using the format detailed below the Principal ID field (in this case, userPrincipalName).
Enter either (or both) the Action and the Asset ID that you are interested in investigating, and select Evaluate.
From this view, you can see the policy versions that are impacting access decisions in your integration and, if necessary, investigate further into the logic behind the policy.
Policy Lens also allows you to create multiple search queries in a single view, enabling you to compare and contrast different access requests to determine how different policies affect different principals, actions, or even different assets.
SGNL event logs provide granular information about events that happen in your SGNL environment.
SGNL Event Logs are broken up into Access Events and Synchronization Events, both of which can impact the Access Decisions that SGNL returns.
Access Events describe the access decisions and simulated access decisions that are occurring across integrations protected by SGNL.
Decisions in the Access Service are the responses that SGNL is handing back to your protected integrations. From here, you’re able to look for anomalies, understand trends, and troubleshoot an individual user’s access result.
In addition to access decisions, you’re also able to look at the results of any policies you may have simulated for a given integration.
By selecting ‘Match’ in the Logs filters, you can see Policy Versions that are simulated in your environment and understand what the result of their evaluation might have been.
In order to make access decisions, SGNL’s policy engine evaluates data in the SGNL graph. This data is populated by the various data sources that are synchronizing business context. Events relating to the successful start and completion of synchronization runs are stored in the SGNL event logs.
At times, synchronization may become interrupted between your Data Sources and SGNL - resulting in changes in your Data Source not being reflected in the SGNL Graph, and consequently not being considered in Access Decisions.
When SGNL detects an issue with synchronization, an event is raised in the Event Logs detailing Ingestion Failure and helpful debugging information.
You can use this data to understand a) whether synchronization is working and b) whether to expect issues when evaluating entities in the SGNL graph - enabling visibility into the state of connectivity and additional debugging/remediation.