[00:00] In this lesson, we'll discuss security zones and show how to configure a security policy in the gateway. A security zone is a list of gateways, computers, or IP addresses that are defined and grouped together. In the same way that users and roles restrict access to specific functions within a gateway for users, security zones provide this functionality to gateways in the gateway network. Functions are restricted to specific zones based on security policies. I've set up an Ignition environment to illustrate these ideas. I have two Ignition gateways, a local gateway and a remote gateway, connected via the gateway network. I currently have my designer open to a project in my remote gateway, and I'm looking at tags in a remote provider that's pointing to my "Site A" provider on the local gateway. If I try to write to this "WriteableBoolean1" tag, I'll get an error message saying the access was denied. This is because the default security policies for security zones restrict access to read only. In order to change this, I'll need to head to the gateway webpage of my local gateway, which houses the provider I just tried to write to.

[01:07] I'll need to go to the security zones page, which I can do by navigating to platform > security > zones. You can see there are two security zones that exist on this gateway. One is "default", which is automatically created and cannot be modified. It acts as a catchall if an incoming connection doesn't fall into any other zones. Then, I've created a custom zone here called "Zone 1". If I were to create any other security zones, I can set their priorities, which controls which one will be checked first. Custom zones with higher priorities will show up first in the list, and incoming connections will be checked against them first and then go down the list until they're routed into a zone. Again, If they don't fall into any custom zone, they'll fall back to the default zone. I'll click the three dots next to Zone 1 and go to edit to show its settings. At the top here I can configure its priority, and then there are two sets of settings that can control which gateways will fall into the zone, the identifiers and the qualifiers.

[02:03] The identifiers include things like IP addresses, host names, or gateway names. Each of these accept comma separated lists and allow for wildcards as well. Beyond that, you can also provide IP address ranges that the gateways can fall into. I've configured an IP address range that looks for IP addresses that start with 10.20, than anything between 0 and 10, and finally, the wild card symbol is used so that any number may appear in the last octet. Beyond this, I've also added "RemoteGateway" as a specific gateway name identifier. A gateway only needs to match a single identifier to be considered for this zone. "RemoteGateway" is the name of my remote gateway, so it'll fall into the security zone. Before being fully accepted, the gateway must match with all of the qualifier settings. These settings let us do things like require that the incoming connection is made over a secure channel, or that the connection is direct as opposed to routing through a proxy gateway. Then we can decide whether or not to allow connections from specific scopes, such as from clients, from designers, or the gateway scope.

[03:04] If the incoming connection matches all these qualifiers, it'll be placed into the security zone. Once the security zone is set up, the policy can be managed by clicking the three dots menu next to the zone and clicking manage policy. The policy allows us to configure the access for each of the subsystems within our gateway. There are settings for the alarm journal, alarm notifications, alarm status, audit log, diagnostic services, history providers, secret providers, and tag services. In order to allow my remote gateway to write to the tags on this gateway, I'll need to configure the settings for tag access. There's a general access level for the service, which is set to allow, and then there are access levels for each of the tag providers. By default, the general access level is set to read only, and then each of the providers are set to inherit its level of access. My remote provider is connected to the Site A provider on this local gateway. I can override its access level via this dropdown here. I can set it to "ReadWrite" and then leave the other access levels alone so that only this provider allows read write access, and the others are still set to read only.

[04:08] Again, this is a policy defined for the Zone 1 security policy, so it only affects machines that fall into that zone. I'll save my changes here and head back to my designer. Now. If I try writing to the WriteableBoolean1 tag, I no longer see the access denied message and the tag value updates. By creating a custom security zone that only accepts incoming connections from certain machines, I was able to configure a security policy that allows for remote tag writes from my remote gateway. You can expand this on your end to create as many security zones as you need to control the service access levels of all of the gateways on your gateway network.