Skip to main content
Version: 8.1

Service Security

Service Security​

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. Selecting Edit for 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 prevent zone access to that particular information, regardless of what the rest of the options are set to.

note

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.

  • ​

    New in 8.0.7
    Alarm Journal Access - Alarm Journal Access has two main settings associated with it. The Default Profile Access is the default access rights for the Alarm Journal service. There will be an additional setting for each Alarm Journal configured on the local Gateway. As an example, the image below shows an "Access Level: 'MyJournal'" setting which corresponds to the configured Alarm Journal named "MyJournal". This setting can be set to Inherited which will cause this specific Alarm Journal to inherit the access rights set in the Default Provider Access Level. It can also be set to No Access to block query and storage to this specific Alarm Journal. Setting it to Query Only will allow users to only query data from this Alarm Journal without any storing capability. In contrast, the Query and Storage option allows users to store and query data from this Alarm Journal. It is important to note that every time a new Alarm Journal is created in the local Gateway, a new setting for this journal will be added to this Security Policy and it will automatically default to inherited.

  • Alarm Notification - The Accessible Pipeline Filter setting is a list of Pipelines in the current Gateway that other connections can use for alarm notification. Pipelines must be entered in the format "project_name/pipeline_name". The list is a comma separated list, and it can make use of the (*) wildcard. This setting is an inclusionary list not an exclusionary list, meaning that if there are no pipelines listed here, then all of them will be available.

  • 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.

  • ​

    New in 8.0.7
    Audit Log Access - Audit Log Access has two main settings associated with it. The Default Profile Access is the default access rights for the Audit Profile service. There will be an additional setting for each Audit Profile configured on the local Gateway. Similar to the Alarm Journal Access, the image below will show an "Access Level: 'MyProfile'" setting which in this case corresponds to the configured Audit Profile named "MyProfile". This setting can be set to Inherited which will cause this specific Audit Profile to inherit the access rights set in the Default Provider Access Level. It can also be set to No Access to block query and storage to this specific Audit Profile. Setting it to Query Only will allow users to only query data from this Audit Profile without any storage ability. In contrast, the Query and Storage option allows users to store and query data from this Audit Profile. Just like with Alarm Journals, it is important to note that every time a new Audit Profile is created in the local Gateway, a new setting for this profile will be added to this Security Policy and it will automatically default to inherited.

  • 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 set up on the local Gateway. In the image below, there is an "Access Level: 'DB'" 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.

    note

    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 sets the default access rights for realtime Tag providers.

    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). Finally, the Tag Access section will then have a setting for each Tag 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.

    ​
    New in 8.1.2
    As of 8.1.2, the Trust Remote Security Levels setting allows users to opt into trusting the Security Levels of remote Gateway users when remote Gateways read, write, and subscribe to local Tags. If checked, security levels passed from the remote Gateway will be used for determining access to Tags on the local Gateway. If unchecked, or if the remote Gateway is on a version which does not support this feature, the remote Gateway's security zones and the impersonation role will be used as the security levels.

Default Security Zone​

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 set up 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.

Setting Zone Priority​

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.

Last updated on by ia-sshamgar