Protected Systems are applications, services, or infrastructure that you want to protect with SGNL. In other guides, we’ve explored implementation and management specifics for types of Protected Systems, however in this guide, we’ll explore Best Practices associated with any system you might onboard to SGNL. This guide will discuss default and recommended settings for the Protected System, as well as managing and maintaining Authentication Tokens that have been granted to your Protected System.
This guide is not intended to be an exhaustive list of security best practices associated with protecting access within a system, but instead intended to be used in conjunction with your organization policies, available security services (such as Key Management/Secret Storage, SIEM/Logging solutions, etc), and internal security expertise.
There are no formal prerequisites for this guide, however it’s recommended that you:
When you onboard a new Protected System to SGNL, one of the first decisions you will need to make is the “Default Decision” that SGNL will issue if there are no applicable policies for a Protected System. SGNL takes a security-first approach to default settings, and the Default Decision is no different. If you proceed with the default configuration for a Protected System, SGNL will select “Deny” as the Default Decision.
This configuration means that when a Protected System requests SGNL make an Access Evaluation, if none of your organizational Policies explicitly allow the principal, the Access Evaluation will result in a Deny decision.
SGNL recommends maintaining this default configuration, specifically to default all requests not explicitly allowed by policy to deliver a Deny decision. There are some circumstances where you may choose to change this default, including testing/development, debugging on non-production workloads, and audit-only use-cases.
Before your Protected System can start making requests to the SGNL Access Service, it needs to have an Authentication Token issued for it. Authentication Tokens are generated and managed from the “Authentication” tab of your Protected System.
When generating a token, SGNL will make the token available via the SGNL Console only one time. Be sure to extract the token from the SGNL Console at that moment and store the Token securely. Ideally, you will generate this token and store it directly in a Key Management Service or Vault that your Protected System can access in order to make requests to the SGNL Access Service.
Avoid saving this token outside of a secure storage location that is accessible by systems other than your Protected System.
After the token has been shown once in the SGNL Console, it will never be accessible to SGNL Administrators via the Console or APIs ever again. Authentication Tokens are encrypted at rest and never exposed to Users, Systems, or API clients following the initial issuance.
If you lose your token between issuing the credential and storing it securely in your Protected System, SGNL recommends revoking the credential and issuing a new one.
SGNL ensures that Authentication Tokens are scoped only to the Protected System they are issued for and can only be used against the SGNL Access API in order to make Access Decisions. Authentication Tokens cannot be used for the SGNL Control Plane, and are only granted privileges to make Access Decisions.
Even though these tokens are scoped with extremely limited and fine-grained permissions (i.e. to call the Access API), SGNL relies on the care of SGNL Administrators not to share Authentication Tokens between Protected Systems.
We’ve made SGNL Authentication Tokens simple to manage and maintain, and depending on Organizational policy, we may recommend SGNL/Protected Systems Administrators issue multiple Authentication Tokens for a single Protected System – particularly for Systems that have many components that are managed by different administrators/developers or used by multiple parts of the business.
A single Protected System can be issued as many Authentication Tokens as are needed. SGNL does not enforce a limit on the number of Authentication Tokens, nor the expiry of a given token.
Whilst limits are not enforced, SGNL recommends that Administrators rotate Authentication Tokens at least once a year. The process to rotate Authentication Tokens is straightforward, can be programmatically initiated, and is designed to cause no interruption to service and authentication decisions.
Rotating Authentication Tokens more frequently than a year is dependent on the needs of your organization and mitigating factors associated with Key Storage and Protected System security hygiene.
Protected Systems in SGNL can have multiple versions of the same policy applied in different states. Simulated policies do not contribute to an overall access decision, instead providing granular logging as Matched policies in the SGNL Access Log.
Prior to enforcing any new Policy Version within SGNL, deploy the Policy as simulated for a period of time, in order to gain assurances that the Policy will not negatively impact the decisions being received by your Protected System.
Simulated Policies can be evaluated and compared to other Policy Versions in SGNL Policy Lens, giving you a complete view of the expected impact resulting from the enforcement of a new Policy Version.
Remember that Policy Versions are immutable, and are applied explicitly to each Protected System. This means that a Policy Version can quickly be rolled-back in the event that a new Policy Version does cause issues to a specific Protected System in your environment.
Every Access Decision and Synchronization are logged in the SGNL Access Logs. Whether you are debugging Policy Decisions, monitoring Access Decisions for a specific set of Principals or Assets, or understanding the flow of data from Business System – monitoring the SGNL Access Logs for your Protected System will provide necessary context to make decisions as to changes you need to make in the SGNL platform.
SGNL Access Logs can be exported to SIEM and Logging platforms to provide a holistic view of your app, infrastructure, or service ecosystem.