Security Architecture
Network Segmentation​
Network segmentation is a powerful technique for securing an Ignition Architecture. Inductive Automation recommends adhering to proven strategies and standards such as ISA 62443 “zones and conduits”, “Zero Trust”, NIST or ISO standards, or other industry accepted approaches.
Consumers of each class of traffic should communicate with Ignition Gateways, but not with other types of consumers. For example, Ignition communicates with PLCs, Ignition communicates with databases, users communicate with Ignition, and Ignition gateways communicate with each other. The principle of least privilege suggests that users, PLCs, and databases should not be able to communicate with each other directly.
Network segmentation can be applied externally to Ignition using standard IT and OT technology such as routers, switches, firewalls, and load balancers. Ignition Gateways can communicate securely with each other using HTTPS with 2-way trust based on certificates over port 8060 (definable) via the Gateway Network. Secure communication is also possible using MQTT.
One Server, Multiple Networks​
The Ignition Gateway supports dual-NIC servers, and can act as a bridge between multiple networks, or communicate with multiple sites over a corporate WAN. Since clients talk to databases and PLCs through the Gateway, clients can be launched from both a corporate network and an isolated control network, and provide full access to both. Built-in security settings can restrict project access to users on different networks, either by restricting certain things in a project, or denying access to a whole project based on user role and network location.
Best Practices​
Start with the Ignition Security Hardening Guide and the Server Sizing and Architecture Guide for an overview on how to implement Security Architecture.
Security Engineering​
Security Engineering is required for non-standard applications and Enterprise Integration. The ISA 62443 series of standards is a great starting point to determine the level of security required to meet your risk needs. The NIST Cybersecurity Framework (CSF) is another option.
Be especially careful with high access or risk environments, such as Internet accessible Gateways, or Operational Technology (OT) environments with high safety requirements.
Separate Architectures​
Using a single Ignition system to perform distinct functions increases risk. Consider separating Ignition architectures and security providers (e.g. Identity Providers, databases, etc) when:
- Dealing with multiple different application types (“use cases”)
- Dealing with different types of sensitive data (e.g. Personally Identifiable Information, banking, versus organizational trade secrets)
Stateless Services​
Frontend Ignition Gateways host “stateless” services with visualization modules such as Perspective, Vision, and Reporting. Using application load balancers can protect Ignition, create redundancy, and scale performance. Any number of identically configured Gateways may be used to scale out. Configure the load balancer to favor persistent connections (“sticky sessions”).
Remote providers allow access to data. Consider “read only” Gateway Network connections if needed.
Stateful Services​
Ignition I/O Gateways are used for machine-to-machine communication and are usually segmented from Internet connections and user remote access. These Gateways host tag systems, PLC connections, database connections, historians, etc, which are considered to be “stateful”. Ignition I/O Gateways are best protected with Ignition redundancy or redundant systems implemented below Ignition. End users should not need to communicate directly with I/O Gateways.
Ignition I/O Gateways should be scaled out by adding additional Gateways. I/O gateways should host distinct content from each other. For example, “Gateway A” might connect to PLC 1 and PLC2, while “Gateway B” connects to PLC3. Both support Ignition redundancy.
Scaling is often separated by geographic location or process function. Consider using Ignition Edge Gateways close to the data source. Utilizing Store and Forward from Edge Gateways to a central Gateway or database mitigates the effects of a network outage.