Ignition 8.1
Ignition 7.9
Ignition 7.8
Sepasoft - MES Modules
Cirrus Link - MQTT Modules
Inductive University
Ignition Demo Project
Knowledge Base Articles
Forum
IA Support
SDK Documentation
SDK Examples
You're currently browsing the Ignition 8.0 docs. Click here to view the latest docs.
A Security Zone is a list of Gateways, Computers, or IP addresses that are defined and grouped together. This group now becomes a zone on the Gateway Network, which can have additional policies and restrictions placed on it. While Users and Roles restrict access to specific functions within the Gateway like making certain controls read-only for certain users and read/write for others, Security Zones provide this functionality to the Gateway Network, limiting locations instead of people to be read-only for specific actions. This allows for greater control over the type of information that is passing over the network, improving security and helping to keep different areas of the business separate, while still allowing them to interconnect.
Sometimes, in addition to knowing who the user is, it is important to know their location. An operator may have permissions to turn on a machine from an HMI, but if the operator is logged into a project on a different Gateway in the network that has remote access to those Tags, it might not be a good idea to let the operator write to those Tags from a remote location. The operator can't see if the physical machine is clear to run.
This is where Security Zones come in. While Security Zones themselves don't define the security, they instead define an area of the Gateway Network, breaking up Gateways and network locations into manageable zones that can then have a Security Policy set on them. Once there are zones defined, a Security Policy can be assigned to each zone, and a priority of zones can be set in the event that more than one zone applies in a given situation.
When using zone-based security in a project, the project stores the name of the security zone as a string. This means that if you were to modify the name of the zone in the Gateway, the zone-based security in your project will not update to reflect the new name, and instead will try searching for a zone with the original name. Be very careful when modifying the names of security zones.
When setting up a new Security Zone, it is a good idea to setup a Gateway Network first if you haven't already. While Security Zones can be defined and used without a connected Gateway, they work best when used in conjunction with other Gateways on a Gateway Network.
Security Zones are defined under the Config tab of the Gateway Webpage by going to Security > Security Zones.
There is a special zone called Default. It is always present and can't be modified, and will be used if an incoming connection does not match any of the other defined zones.
Selecting the Create new Security Zone link brings up a new page where the Security Zone can be defined.
Besides the name and description, there are two major sections here: Identifiers and Qualifiers. These are two forms of checks that need to happen before an incoming connection gets placed in a Security Zone.
The identifiers are how incoming connections are distinguished between different zones. While there are a few different ways to define the incoming connection, it only needs to match one of them to match this zone.
Many incoming connections can be defined using any of the three identifiers, or even multiple at once. As mentioned before, an incoming connection only needs to match one of the identifiers for it to be accepted.
When identifying a Gateway through a proxy Gateway, the IP Address should be using the IP of the proxy, but the Gateway name should use the name of the Gateway we are trying to identify.
After first being identified as part of a particular Security Zone, the connection then must check the Qualifiers. With the Qualifiers, the incoming connection needs to fit in with all of the properties before it is fully placed into the Security Zone.
Require Secure Connection - If this is true, only connections that are made over a secure channel will be accepted.
A Security Zone is only able to check connections made to the Gateway the zone is defined on. This means that connections through a proxy Gateway may not be secure.
As mentioned above, a connection must pass all of the qualifier checks before being accepted into a Security Zone. So if Require Secure Connection was checked, and Allow Client Scope was not, any requests coming from Clients would be rejected even if they are secure, and the same goes for any non-secure connections coming from sources other than a Client.
Requests can be a part of more than one zone, depending on how the zones are setup. This can be useful for making a whole section of IP addresses read only, but a specific Gateway in that IP address range may be listed specifically in another zone, which can be given read/write access. Any connection which does not fall into one of the zones will be placed in the Default zone.
After entering all the information on the Security Zone page, click Create New Security Zone. The page will refresh and you will see a green banner stating that your new Security Zone was successfully created.
After creating some Security Zones, a Security Policy can then be defined for each zone. This can be found by going to the Config section of the Gateway Webpage and navigating to Security > Service Security. At first, none of the zones will have a policy defined, and the Default zone will be at the top. Editing any of them will bring up the Security Policy definition page for that zone. The Security Policy has four sections: Alarm Notification, Alarm Status, History Provider Access, and Tag Access. They work together to define how the local Gateway gives access to incoming Gateway connections. All four sections also have the ability to completely block access to specific services with the Service Access setting in each section. Setting that to deny will deny the zone access to that particular information, regardless of what the rest of the options are set to.
It is important to realize that if you have a single Gateway, limiting access of certain clients to certain Tags is still done in the individual Tags.
Alarm Status - The Allow Acknowledge setting will allow the Gateways that fall within the zone to acknowledge alarms on the local Gateway. The Allow Shelving setting will allow the Gateways that fall within the zone to Shelve alarms on the local Gateway. IE: Other Gateways can shelve alarms on this Gateway. For this Gateway to shelve alarms on others, this must be set on the remote Gateway.
History Provider Access - The History Provider Access has two different settings. First, it has a Default Access Profile. This is the default access rights for Tag History. Second, there will be a setting for each History Provider setup on the local Gateway. In the image below, there is an "Access Level: 'New Connection" that can be set that corresponds to the History Provider that was created when a database was connected. It can be set to Query and Storage, which will allow connections in the current zone to both run queries and store Tag History against the Tag History provider, Query Only, which will only allow the zone to query out history data, but not store it, and No Access, which will completely block access to that History Provider. The final setting is Inherited, which will inherit the Default Profile Access rights. Any new history providers will automatically get added to the Security Policy set at inherited so it may be beneficial to set the Default Profile Access to be either Read Only or No Access so that a recently added history provider does not accidentally get storage rights when it should not.
The Default Access Profile should not be set to Inherited. This also goes for the Default Provider Access Level in the Tag Access section.
Tag Access - The Tag Access section also has a few different settings. The Default Provider Access Level, which works the same as the History Provider Default Access Profile. It sets the default access rights for realtime providers. It will then have a setting for each provider configured in the local Gateway, as well as an additional one for system Tags. These can be set to ReadWriteEdit, which will allow connections in the current zone to read, write to, and edit the Tags in that provider, ReadWrite, which allows the zone to read and write to Tags, and ReadOnly, which only allows the zone to read the Tags. It also can be set to None, which will prevent the zone from interacting with the Tag Provider altogether, and Inherited, which will again inherit the access rights set in the Default Provider Access Level. Any new Tag Providers will automatically get added to the Security Policy with Inherited access rights. The Trust Remote Roles setting will allow similarly named roles on other Gateways to access Tags with role specific security on them.
The Impersonation Role Name field allows you to specify a role name to use when writing to a Tag from an incoming Gateway Network connection (from the selected Zone). This replaces the Trust Remote Roles setting, which is only available in 8.0.0 to 8.0.2. Note that you must use this role if you are configuring Tag Security.
While the Default zone may not have a custom Security Policy defined, it does default to not include any notification pipelines, allow alarm acknowledgment, query only history access, and read only Tag access. This means that if a remote Tag Provider is setup on a remote Gateway, and the local Gateway has not changed the default security settings, the remote Gateway will have read only access to the Tag History Provider. This can be changed by editing the Default zone's Security Policy to fit a different preference, or creating new Security Zones with custom security policies. Once a Security Policy has been defined on a zone, it will automatically jump to the top of the list. A new option will also become available that will clear the policy from the zone.
Once a Security Policy has been defined for two or more zones, a new option appears on the Service Security page to move the zones up and down the list. This allows a priority to be set on the Security Zones, since a connection can apply to multiple zones. For example, say Zone 2 dictates that all requests coming from a range of IP addresses have query only history access, and read write access to Tags. Zone 1 includes specific Gateways, one of which is also contained in Zone 2, that will have query and storage history access and read write edit access to Tags. When a request comes in from a connection, it first determines which Security Zones it belongs to. The request then starts at the top of the Service Security list and goes down until it finds the first zone that it is in, and uses the access rights of that zone. In our example, we want to make sure Zone 1 is above Zone 2, so that the Gateway that is in both Zone 1 and Zone 2 gets the full access rights afforded to it by the Security Policy of Zone 1 instead of getting the limited access rights from Zone 2.
Related Topics ...
