On This Page
Access Requests
Overview
You can change rules defined on your network devices' security policies by opening a SecureChange access request ticket. In each ticket you request to open or close traffic between your desired source and destination. You can also open tickets to document changes that were already made. Access Requests can be basic, with changes to hosts, subnets, or ranges over services and ports, or advanced, with changes to NAT addresses, LDAP groups, network and service objects / groups imported from the devices, or the internet object.
A service/application identity is used to connect sources and destinations, such as Facebook Apps (NG applications/application aware). See Tufin Predefined Application Identities for a full list.
You can perform the following actions via access request:
-
Accept: Request to allow the specified traffic connectivity in the security policies deployed on the network.
-
Remove: Request to decommission the specified traffic from the security policies deployed on the network.
-
Drop: The Drop action is only used for documenting changes manually made to the device.
For access requests that are initiated from SecureApp, see Requests from SecureApp.
Using Topology Intelligence
Topology mode provides recommendations based on topology intelligence. You can activate or deactivate topology mode for each access request.
If your request is created based on a workflow that has topology disabled, topology is disabled for all access requests. See Configuring Workflow Properties.
You cannot use topology for access requests that include: ANY, class A network, Internet, non-continuous mask, IPv6
-
When topology is enabled, SecureChange finds the devices and subpolicies that are relevant to the access request and lets the Designer suggest firewall changes with the correct IP addresses.
For NAT environments, NAT translations will be accounted for in the calculations.Activating topology allows you to utilize TOS Aurora's suite of automatic tools, such as Risk Analysis, Designer or Verifier to help you implement the changes listed in a request.
-
- When topology is disabled (non topology mode), you must manually choose the devices and subpolicies that are relevant to the access request and specify the correct IP addresses. Designer will calculate the rule changes required on the policies you selected. We recommend using non topology mode when the topology map is not yet fully constructed. Using access requests in topology mode with an incomplete topology may give incorrect results.
For NAT environments, NAT translations will be accounted for in the calculations. You may need to create one access request with an IP address before NAT and another access request with an IP address after NAT. The topology setting can be changed in any step but access request details that are not supported for topology are lost when you change the setting.
Creating a Change Request
-
If you want use to use topology intelligence, make sure topology mode is active. See Using Topology Mode.
-
Select the target where you want to apply the traffic connection.
To select the target, you can enter a value directly in the access request or use the Advanced Options to select values:
-
Enter a value - Click the plus :
- For Check Point devices, enter the management and gateway or policy name. For example:
CP_Mgmt/Gateway
orCP_Mgmt/Policy
- For all other devices, enter the device name. For example:
ASA
- For ANY target, enter:
ANY
(Not supported for topology)
- For Check Point devices, enter the management and gateway or policy name. For example:
-
Select from a list or get a suggested target - See Advanced Options.
-
-
Enter the Source, Destination, and Service/AppID to build the access request traffic connection.
You have the following options:
-
Enter a value - See Text Formats for Access Requests. For each column, click the plus and enter a value. To add an additional entry in any column, click the plus . To remove an entry, point to the entry and click delete .
If you use NAT in your network, the IP addresses of the source and destination must be from the perspective of the source. For example, for a source with IP address 10.1.1.1 and a destination with IP address 192.168.1.1, if there is a device in between that translates both addresses to the 172.16.1.0 network, the access request must have the 10.1.1.1 address of the source and the 172.16.1.0 address of the destination.
- Select objects - See Advanced Options.
- Type or paste text - Click Settings > Advanced Options and type or paste into the text editor field for Users, Source, Destination, Service or Applications. See Text Formats for Access Requests. Click Apply to add your entries to the traffic flow, and click OK to go back to the Access Request. To remove an entry, point to the entry in the Access Request table and click delete .
-
Paste from Excel -
Copy a row of cells from a Microsoft Excel spreadsheet or any set of tab-delimited text, and paste into the text editor field.
When you click OK or Apply, the traffic details are added to the access request. Each additional row of cells is added to the ticket as additional access request.
The text must have 3 columns in the order of Source, Destination, Service, Action (optional), and Comment (optional). You can include multiple values in a single cell delimited with a semi-colon (;).
For example:
The text must have 3 columns in the order of Source, Destination, Service, Action (optional), and Comment (optional) in any of the text formats listed above. You can include multiple values in a single cell delimited with a semi-colon (;).
For example:
In this example, if the access request already has ASA/LAN_2 in the source, ASA/MCI_Zone in the destination, and TCP 443 in the service, then the result of importing the cells is:
-
- Click Submit.
The request appears in My Requests list.