1.0 Introduction
This article describes the steps required to configure and provide network-based IP access control to the Fortanix-Data-Security-Manager (DSM) users.
2.0 IP Policy (Network-based Access Controls)
In controlled-network environments (not the Internet), network-based access controls are used as a defensive in-depth mechanism to allow access to only certain functionality from certain origins.
Fortanix DSM allows you to control the following:
Principal Types: Fortanix DSM allows specific security principals from a particular origin. It supports the following two types of authenticated principals:
User
Application (apps)
API Classes: Fortanix DSM divides all APIs into disjoint API classes. The API classes do not intersect.
The following API classes are supported:
EKMS
KMIP
HEALTH
UNAUTHUSER
OTHER
An origin is defined as a non-empty set of IP subnets.
For an API to be ultimately allowed, the request must match the most specific policy item that applies to it. The request is allowed if and only if the policy item specifies that both the request's principal and the request's API class are allowed.
The whole policy is a list of policy items. One policy item must contain exactly the default origin 0.0.0.0/0. Except for the policy item with the default origin, each policy item's origin is a strict subset of another policy item in the policy.
3.0 IP Policy Validity Requirements
The requirements on policy items and their origins work to ensure that a policy's items can be arranged in a tree-like structure with the following properties:
A node contains the policy item. This policy applies to all origins in the node’s origin that are not members of a child node's origin.
Every node with a parent must have its origin be a subset of its parent node’s origin.
Nodes with a common parent must define disjoint origins.
The root node is the policy item containing exactly the default origin 0.0.0.0/0.
3.1 IP Policy Example
Restricting apps to a subnet:
"policy_items": [
{
"origins": [ "0.0.0.0/0" ],
"principals": { "users": true, "apps": false },
"api_classes": { "other": true, "kmip": true, "ekms": true, "health": true, "unauth_user": true }
},
{
"origins": [ "10.1.0.0/16", "10.3.0.0/16" ],
"principals": { "users": false, "apps": true },
"api_classes": { "other": true, "kmip": true, "ekms": true, "health": true, "unauth_user": false }
}
]
With this configuration, users cannot use the cluster from the subnets 10.1.0.0/16 and 10.3.0.0/16. They will still be able to see the index page, but they will not be able to authenticate or even view their authentication options.
4.0 Add a New IP Policy
A Fortanix DSM system administrator can restrict which types of IP addresses are allowed for all the IP policies in the account.
Perform the following steps to create an account-level IP policy:
Navigate to the System Administration → Settings tab in the Fortanix DSM user interface (UI).
In the Account Settings page, click the IP POLICY tab.
The root node policy item containing the default origin (0.0.0.0/0) appears. Here, the default policy effectively means that there is no filtering based on IP.
It also displays a Policy Expiration Date field. By default, this field is set to Never Expires, which keeps the policy active indefinitely. To enforce time-bound access, users can edit this field and specify an expiration date. For more information, refer to Section 5.3: Update Policy Expiration Date.
Figure 1: Default IP policy
Click the overflow menu
corresponding to the default origin.
Select the ADD POLICY ITEM option from the menu.
In the ADD POLICY ITEM form, you can restrict some functionalities originating from the configured IP addresses. Enter the following details:
Type the CIDRs that you want to restrict, separated by commas.
Select the Principals that you want to allow.
Select the API classes that you want to allow.
Figure 2: Add a new IP policy
Click SAVE to save the policy settings.
5.0 Manage the IP Policy
This section describes how to edit, delete, and update the expiration date of an IP policy in the Fortanix DSM UI.
5.1 Edit an Existing IP Policy
Perform the following to edit a policy item:
Click the overflow menu
corresponding to the newly added origin.
Select the EDIT POLICY ITEM option from the menu.
Figure 3: Edit an IP policy
In the EDIT POLICY ITEM form, modify the required Principals and API classes. You can also edit the CIDRs.
Click SAVE to save the policy settings.
5.2 Delete an Existing IP Policy
Perform the following to delete a policy item:
Click the overflow menu
corresponding to the newly added origin.
Select the DELETE POLICY ITEM(S) option from the menu.
Figure 4: Delete an IP policy
On the DELETE POLICY ITEM(S) confirmation form, click DELETE to delete the policy setting.
5.3 Update IP Policy Expiration Date
If you misconfigure the cluster, it may become unusable. The cluster can also become inaccessible if you do not allow access from the pod subnet. To recover access, set an optional expiration date when creating a new IP policy. When the policy expires, the system reverts to the default policy, which allows unrestricted IP access.
Perform the following steps to add an expiry date to the newly created IP policies:
Click the edit icon for the Policy Expiration Date field.
Figure 5: Add expiry date
Update the expiry date setting for the policy.
Click SAVE to save the expiry date.
Figure 6: Set expiry date
After the policy expires, the user can do one of the following:
Edit the default policy and create a new configuration.
Restore the previous configuration and set a new expiry date.