A Policy is a collection of rules which provide granular access to your applications depending on a range of parameters. For example, access can be defined based on the destination application groups of the requester.
This section describes the best practices and key considerations for configuring a policy.
Before you create a policy, configure:
- Identity Provider or Axis Identity Provider Axis IdP
The Identity Provider option is located at the Settings-> Identity Providers screen.
The Axis Identity Provider option is located at the Settings-> Axis IdP screen.
- Policy Identities.
This option is located at the Policy-> Identities screen.
Using Conditions, you can add additional criteria such as Device Trust, Source (IP range and geolocation), and time range. To learn more, click here.
This section contains the following topics:
- How are Rules Evaluated?
- Rule Names and Description
- Naming Application and Identity Tags
- Grouping Applications to a Rule
- Testing Rules with the Axis IdP
- Keeping the Default Rule Setting to Always Block
- Unable to Find Atmos Agent Posture Criteria
Related Topics : Adding Policy Rules
Before you create a policy, we recommend that you identify:
- What applications your users are trying to connect to.
- Who are your users.
- Use this information to create your user and application groups.
In general, rules are ordered in importance, with the lowest number (1) having the highest priority. If you have rules that overlap; for example, a SSH Range Application rule and Network Range Application rule, place the SSH Range Application rule above the Network Range rule.
Create rules with meaningful names and descriptions. Although the description for the rule is optional, we highly recommend that you include a description that accurately describes the rule (how it is being applied); for example, 3rd Party access for IOT in France.
Tip: When you define a rule, identity, or identity group, check the spelling.
Create application and identity tags with meaningful names.
Good examples for naming application tags are HR Applications, Company-wide apps, and Production DevOps Access. We suggest not to use tags such as HTTP.
The tag is associated with more than one application. Associating one tag to one application is redundant because policies can be set for individual applications.
A good example for naming an identity tag is Sales Team, Product Team, Tel Aviv office, or New York office.
After you define an application, you can associate a single application to a rule; however, the best practice is to group applications to a rule using the application tags because it is easier to administer and scale at the Settings-> Application Settings-> New Tags screen.
You can test your rules using the Axis identity provider (IdP) to ensure that you are getting the expected results.
To test your rules using the Axis IdP:
- Create and test a rule that blocks access to a user and user group.
- Create and test a rule that allows access to a user and user group.
For additional security, the best practice is to configure all the Conditions.
For additional granular access, configure and apply the following profiles if applicable.
The default rule on the bottom of the rule list is always set to block.
Always keep the Default rule setting to block.
In some cases, if you want to apply the same rule to both Windows and MacOS operating systems (OS), you can select the Windows and Mac options at the Policy-> Rules-> Edit Rule -> Conditions > Device Trust > Atmos Agent Posture screen.
When you select both OS, the system will only display the criteria (Firewall, Disk Encryption, File Path) that are relevant for both operating systems. In this case, you will not see a condition such as Registry because it is Windows-specific.
If you are looking for a criterion (condition) but can’t find it for a specific operating system(OS), it is probably because you selected the criteria for both operating systems.
Updated about 1 year ago