In today’s blog, we’ll take a closer look at Policies in Border0 and how they can help administrators control who should have access to your services and under what conditions. We’ll also look at the real-time & continuous authorization features in Border0 and explain why this differs from most solutions today.
In today’s blog, we’ll take a closer look at Policies in Border0 and how they can help administrators control who should have access to your services and under what conditions. We’ll also look at the real-time & continuous authorization features in Border0 and explain why this differs from most solutions today.
In today’s world, It’s no longer just enough to provide access to resources such as SSH to servers or a database just because you’re on the VPN. What we really need in a modern infrastructure stack is fine-grained access control based on the user's identity and various other pieces of context. We use that to determine who should have access to your servers.
In order to express who should have access to these resources, we need a policy language. Using this language, we should be able to express exactly who (i.e., SSO identity) should have access to what resources, under which conditions, and context.
Checkout the demo on Border0 Policies.
The Border0 policy language was designed from scratch to be easy to use, intuitive, flexible, and granular. High level, the border0 Policy language has two sections: Actions and Conditions.
Conditions allow users to express conditions and context under which certain “actions” should be allowed.
Policies can be managed using the Portal, CLI, or API. The screenshot below shows the portal editor in the Border0 Portal. The portal provides both a visual editor and a JSON policy editor, making it easy to switch back and forth and intuitive to use for everyone.
Let’s look at an example Border0 policy. First, we’ll look at the conditions section. The example below shows the various options available for conditions.
Conditions allow administrators to define the conditions, such as Who should have access, When, and from Where (think of them as the three W’s). Let’s dive in a bit more.
Who: This has everything to do with the user's identity; here, we use the user’s email as the main key to identify the user. Most SSO providers support this, and we’ll use this to build evaluation rules. We can either match on a list of specific email addresses or domains (i.e., border0.com, which means anyone that authenticates with a border0.com email address).
Where: The where section allows administrators to define conditions about where the user is visiting from. This could be a list of IP addresses or a specific country. It also allows administrators to specifically prevent access to users from a particular country.
When: In the when section, we can define under what time conditions a user is allowed access. As an administrator, you can define a date range and a time of day definition. For example, you could define a rule where a contractor only has access from 9 am to 5 pm and only between March 1st, 2023, and April 1st, 2023.
Now let’s assume all conditions in the policy match. In that case, the policy evaluator returns all the actions the user is allowed to perform. This today indicates the type of services the user has access to, for example, ssh, http, database, tls, or * for all services.
👩💻 If you think of this as a programming language, then you can think of actions as the return values for the policy evaluator.
The final step is to link your policy to a service. This can be done from the portal, the CLI, the connector, or, for the automation fans, using the API. Services can have multiple policies, with the policy engine evaluating all relevant policies to determine access based on the combined list of actions. I.e., the policy engine will evaluate all relevant policies and collect the list of allowed actions. After evaluating all policies, decide whether access is allowed based on the final, combined list of actions.
💡 Pro tip: If a policy is an “org-wide” policy, it will automatically apply to all services in your organization. Although not required, having a default org-wide policy with your default access settings is a good practice. This way, any newly created services will automatically have a policy.
We want to make working with policies as easy as possible, so we’ve added tools and visibility into policy evaluation results to the portal. Let’s look at the Border0 policy tester first; this will make it easy for you to test your policies.
The policy tester can be found in the portal after you select a specific policy under “Actions” and then “Tester”.
The example above demonstrates the Policy tester. In the first test, we test with an email address (identity) allowed by the policy and an IP address geo-located to Canada. After we hit test, we can see that the policy validation is successful, as indicated by the green color, and it returns the allowed actions for this user.
In the second test, we change the email address to andree@evilcorp.com, and an IP address geo-located to India. We can now see that the policy validation failed, and we can see exactly why in the “Failed by” section. This is useful, as we can now tune the policy to ensure it works as expected.
Another useful tool is to look at policy evaluation results for each session through the Border0 platform from the “Session logs” page. Simply click on “Authorization Results” in the Actions column.
.gif)
The recording above shows how, in this case, the policy allows access to the service from 00:00 UTC until (not inclusive) 22:44 UTC. By inspecting the “evaluation results” from the Session logs page, we can see that a session was allowed at 22:43 UTC. Then, when we tried again a minute later, we observed how the “evaluation results” reported that the access request was denied because it was outside of the provisioned time window.
Everything in Border0 is real-time, which means when you make a policy change, such as removing or adding an identity from the policy, the update is immediately synced across our global infrastructure. This ensures that access rules remain up-to-date and secure at all times.
But that’s not all! Border0 continuously evaluates each connection through the platform to determine whether access should still be allowed. This is unique as the typical approach is that access evaluation is only done when the user is authenticated or visits the service for the first time. At that time when access is granted, it’s typically valid for the duration of a session. This can be problematic because a policy can change, conditions and context may change, etc. We believe it’s important to be able to react to these changes in real-time. This approach adds an extra layer of security to your resources and allows you to react in real-time to context changes or push out policy changes without having to wait for a session to time out.
ℹ️ In the example earlier, we looked at a policy that allowed SSH access between 00:00 and 22:44 UTC. We saw how a user was connecting at 22:43 and allowed in. Due to our continuous authorization support, this user’s session would have been automatically disconnected at 22:44. This is a simple example of continuous authorization in action.
In this post, we introduced Border0 Policies and outlined how it provides a flexible and powerful way to control access to your organization's resources. By offering identity-based access control, context-aware conditions, and real-time updates, Border0 Policies empower administrators to create and maintain secure access rules that are tailored to their specific needs. We also saw how the Border0 portal provides the tools and insights for testing your policies and seeing how the policy evaluation results for each session. This makes it easy for administrators to work with the Border0 Policies.
Border0's real-time and continuous authorization feature sets us apart from existing technologies, offering a level of security and flexibility rarely seen in the access management space. By moving away from the limitations of one-time authorization, Border0 empowers you to maintain complete control and visibility over your resources and enforce access policies in real-time.
So, why not leave the limitations of traditional ACLs and firewall rules behind? Embrace the flexibility and control offered by Border0 policies and experience a new era of access management. Give it a try and see the benefits of Border0 for yourself by signing up for our free, fully-functional community edition here.