This article provides key considerations, best practices, and requirements to plan your Axis Security deployment and achieve the best results.
Companies use authentication services in the form of Identity Providers (IdPs) to allow users to access the resources they need in a secure manner. IdPs provide a way to manage access by adding or removing privileges.
Before you deploy Axis Security, consider the following:
Authentication Planning Checklist
IdP: Which Identity Provider (IdP) will you be using to manage and authenticate users? Axis Security allows you to use SAML as your method of authentication
Merging IdPs: Will you be using more than one IdP? Are you planning to merge identities together from another source now or over time? This can help decide on the optimal configuration for your needs.
Existing Groups: Are there existing groups in the IdP that dictate application or network access already? This can help with the transition to Axis Security.
For more information about identity management, click here
Connectors provide a secure and authenticated interface between a customer’s network and the Atmos Cloud. Connectors are deployed on network segments that can access secured applications and the Atmos Cloud simultaneously. For more information about connectors, click Connector Information Notification
Before you deploy your connectors, consider the following:
Connector Planning Checklist
Number of data centers:
Type of connector deployment:
We provide templates/OVAs for these platforms, though you can install connector software on supported Linux servers on any infrastructure beyond what we have templates for.
Number of Connectors: (High availability): How many connectors are deploying per connector zone?
Important: Axis recommends 2 or more connectors for each deployed connector zone. A cluster of at least 2 connectors provides continuous connectivity in the case where one connector goes offline for planned or unplanned reasons. Since the Axis Security Cloud intelligently manages traffic r-direction and load-balancing, as long as at least 1 connector is online and reachable, access to applications will be preserved.
An application is a resource specified by a domain name, a local domain name, or an IP address, defined on a standard set of ports, managed, and accessed through the Atmos Cloud. For more information about applications, click here.
Before you configure your applications, consider the following when deploying your applications and gather the following information:
Application Planning Checklist
Applications: What applications will you be using?
For example, Jira, Microsoft Office 360, SSH Range, or Network Range. This is important because you need to map all these applications to the associated connectors.
Atmos Agent: Are you going to use the Atmos Agent to access some or all of the applications?
If you are using the Atmos Agent, consider the following:
Application Type: some applications can only be accessed using the Atmos Agent.
Click here for a feature comparison: Atmos Agent versus Atmos Air (Agentless).
A good practice for naming an application is to specify the server name associated with the application. For example, server1 RDP.
This is useful for helping you more easily manage your applications in the Management Console and for checking if the server associated with the application is operational.
For configurations with a large number of application definitions, consider using a naming convention that is easy to search against. For example, if the SSH servers in a Dev environment are given a name containing “devssh”, then using the search function, it’s possible to easily filter for all of the applications related to your “devssh” hosts.
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.
See also Best Practices for Configuring a Policy.
When you define a rule, identity, or identity group, check the spelling.
A good practice for naming a connector zone is to specify the connector zone’s location or its main use. For example, USA_3rdpartyaccess.
Create application tags with meaningful names. Good examples for naming application tags are HR Applications, Company-wide apps, and Production DevOps Access. A bad example is HTTP. For more information, see the Application Tags section in the Best Practices for Configuring a Policy.
Axis Security highly recommends using application tags to group users, group applications by use case, or map applications.
If you are currently using Active Directory on your network, you might need to configure the Active Directory application to access resources.
The Atmos Agent requires additional firewall rules. To learn more, see Atmos Agent Device Prerequisites.
Updated about 2 months ago