Address Commander Security Model Best Practices (Part 1)

Address Commander is an IP address management (IPAM) solution that allows you to improve workflows, automate common processes, and gain a clear picture of your IP resources. The ability to centralize all IP address management poses security concerns — such as who can access what information — that Address Commander can help you address. You will need to consider how to divide user types and arrange the layout of IP space to ensure data integrity as well as efficiency. This document aims to establish best practices for setting up effective security containers in Address Commander so that you can restrict who views which IP resources on your network. Part 1 will establish the user types and IP layout options, while Part 2 will focus on security implications and use cases.

User Types

There are three types of users in Address Commander with different levels of access, ownership and restrictions. Below is a short introduction about the security aspects of each user type. For more information, please see the user guide.

Administrators

Administrators cannot be restricted by Role, access control list (ACL), or Subnet Service Type. Further, they can view and manipulate any object in the system. Essentially, security does not apply to these users, but auditing still does.

Customer Service Representatives (CSRs)

CSRs are subject to Role, Subnet Service Type, and ACL restrictions. A CSR user has read access to all objects, even though they may not be able to manipulate them.

Entity User

Entity users — such as business (enterprise) customers — can only view and act on the resources of the entity that they (or a child entity) are associated with. It is important to note that entity users can act on any of the resources associated to the entity, regardless of the subnet group or subnet service type association. Entity users are not subject to ACL restrictions. Hierarchical ownership within an entity means that an entity user of a parent entity can view and modify any resources associated to its descendant entities.

IP Space Layout Factors

The first step is to decide how your aggregations will be partitioned, for example by:

  • Services or applications of the space (data blocks, VOIP blocks, loopbacks, point-to-point, etc.)
  • Organization (based on geography, departmental etc.)
  • Consumers of the IP space (customers, subscribers etc.).

Once you have decided on your IP layout, one of the main security considerations will be how to restrict user access in certain areas. Address Commander has three IP containers, each with different security concerns and applications.

1. Services (Subnet Service types)

IP address space is often planned in terms how the IP resource will be used, rather than by region. Some service types may have special restrictions, so that only some CSRs can administer that type of space, regardless of the region that they administer. For example, you may only want the VoIP administration team to be able to assign out VoIP IP ranges.

2. Regions

The IP resources for services that do not have such a stringent requirements for administration can be left to the regional administrators to partition and allocate in their areas as required. The regional administrators then allocate their resources to the edge customers that require the resource. Once this is achieved, the edge customers can then modify the resources they have been allocated to accurately reflect how they are using the resources.

3. Roles

Roles refer to which users can perform which actions in Address Commander. Roles are not particular to a specific resource, but a specific resource type. For example, this could include the ability to subdivide a subnet but not to delete a subnet.

CSRs cannot own anything in Address Commander. This means that although they can see everything system-wide, they can only manipulate resources within their own ACL, subject to the actions allowed by their associated Role.

Click here for Part 2 of this series, which will explain the security implications and use cases for these subnets.

  • Share: