Azure Change Automation Behavior

When working with Azure Change Automation, the following limitations exist in SecureChange and SecureCloud:

  • Enable or Disable in Designer optimization does not affect how SecureCloud adds the requested traffic to Azure's NSG.

  • When resolving network objects that are sent to SecureCloud for provisioning, TOS ignores NAT translation which might occur on a path, and resolves the object to an IP address as defined on the device.

  • New revisions from Azure are available automatically in the Compare and Rule Viewer features in SecureTrack. New revision authorization, map revision to admin, and ticket (by metadata), and map Azure rule to ticket need to be processed manually as external changes.

  • Provisioning relies on data received from Designer the last time that Designer validated changes. If there have been changes since Designer last ran, you need to run Designer again before running Provisioning.

  • You must monitor your Azure subscription in SecureCloud and define sufficient access in your Azure subscription. The credentials used when adding the Azure account in SecureCloud must have the Network Contributor role in addition to the Reader role - see Azure Permissions in the SecureCloud KC.

SecureTrack Object Resolving to SecureCloud

For Network Objects

  • Azure and SecureCloud support IPv4 hosts and IPv4 networks.

  • Designer and Provisioning will fail for Azure VNET if the Access Request includes one of the network objects listed below. This includes network objects in an on-prem device, added by an API or manually entered:

    • Only IPv6 (hosts, networks, or ranges)
    • IPv4 ranges
    • Groups which contain only IPv6 objects.

  • If an Access Request includes a source or destination with both IPv4 and IPv6 objects, Designer and Provisioning will run, but will only process the IPv4 elements. The IPv6 elements will be ignored.

  • If a network object contains both IPv4 and IPv6 addresses, TOS will ignore the IPv6 addresses and send only the IPv4 addresses to SecureCloud. This includes the following types of object:

    • Mixed groups which contain both IPv4 and IPv6 objects

    • Dual stack objects
    • FQDN or DNS which are resolved to both IPv4 and IPv6 addresses
    • User zones (for LDAP groups) which contain both IPv4 and IPv6 networks.

  • Groups which contain IPv4 ranges are invalid and will cause Azure Designer or Provisioning to fail.

For Service Objects

  • SecureCloud and Azure support TCP, UDP, and ICMP protocols

  • Access Requests cannot include SCTP or IP protocol numbers

Using Designer and Provisioning for SecureCloud and Azure Devices

Azure Network Security Groups (NSGs)

  • If the Access Request is for a transparent load balancer, SecureChange cannot open the NSGs in a VM behind the load balancer.

  • If SecureChange cannot find the NSG for a specific Access Request in Azure VNET, it will not process the Access Request.
  • If there is an NSG on the asset and on the subnet, SecureChange will modify only the asset NSG

Implementing Access Requests:

  • SecureCloud will not create new subnets or create new NSGs\ASGs

  • SecureCloud will not implement correlation between Access Requests

  • If there is a Deny rule (regardless of intersection) SecureChange will put new rules above it

  • SecureChange will not process NSG rules with service tags

  • If an Access Request service is ICMP type X, SecureChange will implement it as ICMP ANY.

  • The Source port range is always considered as ANY

  • If an Access Request has been partially implemented, SecureCloud will not remove the implemented traffic, it will implement the Access Request as is.

  • When editing an existing rule, SecureCloud will not change the rule's description
  • Each Access Request can only implement one rule. SecureCloud implements rules in the order that the Access Requests are submitted

  • New rules will be identical to the Access Request, regardless of the NSG direction

Application Security Groups (ASG)

  • ASG and IP do not intersect

  • You cannot edit ASGs in SecureChange

  • If an ASG is part of an Access Request in the same VNET, SecureChange uses it as it is listed

  • If the Source in an Access Request is an ASG which has a VM from VNET1 attached to it, and the Destination ASG or IP belongs to at least one VM from VNET2, the rule on the incoming NSG will have IPs as a Source and not the ASG listed as the source in the Access Request

  • If the Source in an Access Request is an ASG from a different subscription to the incoming NSG that needs to be open, the Source listed in the rule will be the IPs of the ASG as defined in the on-prem device.

Scale and Performance

  • We recommend a maximum of 50 Access Requests of up to 15 elements in the source, destination, and service fields.

  • The maximum payload size of provisioning command from SecureChangeto SecureCloud is 1Mb. If a ticket includes many Access Requests which combined payload of more than 1Mb, you should divide the ticket into multiple smaller tickets with fewer Access Requests in each ticket.