Service Security
Security Policies​
After creating some Security Zones, a Security Policy can then be defined for each zone. This can be found by going to the Platform 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. Clicking the three dot menu and selecting Edit for any of listed zone will bring up the Security Policy definition panel for that zone. The Security Policy has the following sections:
- Alarm Journal Access
- Alarm Notification
- Alarm Status
- Audit Log Access
- History Provider Access
- Tag Access
These sections work together to define how the local Gateway gives access to incoming Gateway connections. All sections have the ability to completely block access to specific services with the Service Access setting. Setting this to deny will prevent zone access to that particular information, regardless of how the rest of the options are set.
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 Journal Access Properties​
| Properties | Description |
|---|---|
| Service Access | Enables Alarm Journal access when set to Allow. |
| Default Profile Access | The default access rights for the Alarm Journal service. |
| Access Level | By default this setting will be 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. 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. |
Alarm Notification Properties​
| Property | Description |
|---|---|
| Service Access | Enables Alarm Notification access when set to Allow. |
| Access Pipeline Filter | 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 Properties​
| Property | Description |
|---|---|
| Service Access | Enables Alarm Status access when set to Allow. |
| Allow Acknowledge | Allows Gateways that fall within the zone to acknowledge alarms on the local Gateway. |
| Allow Shelving | Allow Gateways that fall within the zone to shelve alarms on the local Gateway. For this Gateway to shelve alarms on other Gateways, this must be checked on every remote Gateway. |
Audit Log Access Properties​
| Property | Description |
|---|---|
| Service Access | Enables Audit Log access when set to Allow. |
| Default Profile Access | The default access rights for the Audit Profile service. |
| Access Level | By default this setting will 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. 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. |
History Provider Access Properties​
| Property | Description |
|---|---|
| Service Access | Enables History Provider access when set to Allow. |
| Default Profile Access | The default access rights for Tag History. It is not recommended to set the Default Access Profile to Inherited since all new History Providers will automatically get added to the Security Policy with an Access Level setting of inherited. Instead, it may be beneficial to set the Default Profile Access to be either Read Only or No Access so that an added History Provider does not accidentally get storage rights. |
| Access Level | By default this setting will be set to Inherited, which will inherit the Default Profile Access rights. If set to Query and Storage, connections in the current zone can both run queries and store against the Tag History Provider. Query Only will only allow the zone to query out history data, but not store it. No Access will completely block access to the History Provider. |
Tag Access Properties​
| Property | Description |
|---|---|
| Service Access | Enables Tag Provider access when set to Allow. |
| Default Profile Access Level | Sets the default access rights for realtime Tag Providers. It is not recommended to set the Default Access Profile to Inherited. |
| Trust Remote Security Levels | 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, the remote Gateway's Security Zones and the impersonation role will be used as the Security Levels. |
| Impersonation Role Name | Allows you to specify a role name to use when writing to a tag from an incoming Gateway Network connection (from the selected zone). |
| Access Level | An Access Level setting will exist for each Tag Provider configured in the local Gateway, as well as an additional one for System tags. By default the level is set to Inherited, which will inherit the access rights set in the Default Provider Access Level. Other level settings include 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 allows the zone to only read the tags. It also can be set to None, which will prevent the zone from interacting with the Tag Provider altogether. |
Default Security Zone​
While the Default zone may not have a custom Security Policy defined, it is configured to allow Alarm Acknowledgment, query only for History Provider Access, read only for Tag Access, and not to include Notification Pipelines. 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 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.
Setting Zone Priority​
When Security Policies have been defined for two or more zones, new options appear on the Service Security page when the three dot menu is expanded 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. Requests from a connection, first determine which Security Zones they belongs to by starting at the top of the Service Security list and working down until finding the first zone they are in. Then, they use the access rights of that zone.
For example, say there is a custom 1 and custom 2 zone configured. Custom 1 includes specific Gateways, one of which is also contained in custom 2, that will have query and storage history access and read write edit access to tags. Custom 2 dictates all requests coming from a range of IP addresses have query only history access, and read write access to tags. We would want to make sure custom 1 is above custom 2 in priority, so that the Gateway in both custom 1 and custom 2 gets the full access rights afforded to it by the Security Policy of custom 1, instead of getting the limited access rights from custom 2.
