1 / 31

Ignition’s Security Features: Protecting Your System Using Roles, Zones, and TLS Encryption

Learn how to use Ignition’s security features to protect your system, including roles, zones, TLS encryption, and user sources. Explore existing features and upcoming enhancements.

reichert
Télécharger la présentation

Ignition’s Security Features: Protecting Your System Using Roles, Zones, and TLS Encryption

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. How to Use Ignition’s Security Features Kent Melville Sales Engineer / Inductive Automation

  2. What We’ve Already Said Steps for Protecting Your Ignition System – ICC 2017 (Carl Gould) Open and Secure SCADA: Efficient and Economical Control, Without the Risk – Webinar (Travis Cox and Chris Harlow - Bedrock Automation) Ignition Hardening Guide (Website) Java Security and Ignition (White Paper)

  3. Introduction Today’s Focus: • The Application: Ignition’s Security Features

  4. Table of Contents Existing Features Upcoming Features Q/A Security Panel

  5. Existing Features Roles Zones TLS Encryption User Sources Active Directory 7.9.4

  6. Roles Operator Which is the username and which is the role? JSMITH

  7. Roles Operator Not a username Which is the username and which is the role? JSMITH

  8. Zones Roles care about WHO. Zones care about WHERE.

  9. TLS Encryption Enable SSL – Get a Cert • Certificate Authority • Self-signed Cert • Third Party services (Let’s Encrypt) OPC UA Client Gateway Network

  10. User Sources Where to manage your users and roles: • Option #1 - Internal Authentication - Users and roles are stored internally to Ignition.  • Option #2 - Database Authentication - Users and roles are stored in a SQL database. Managing users is done via direct interaction with the database.

  11. Active Directory Integration • Option #3 - Active Directory Authentication - Users are managed by Active Directory. Users are authenticated through the LDAP protocol.  • Where are the roles managed? • Active Directory Groups • Internal Ignition • Database

  12. 7.9.4 Changes Client Permissions • For upgrades from previous versions all are disabled • For fresh installs all are Enabled

  13. 7.9.4 Changes Named Queries are defined and run at the gateway but can be referenced from the project. They accept parameters to be dynamic but prevent the client from running arbitrary queries.

  14. Upcoming Features System Commissioning Federated Identities Multi-Factor Authentication Security Levels

  15. System Commissioning

  16. Terminology Authentication - the process of verifying a user’s identity. Authorization - the process of determining who should have access to what, or who should be able to undertake what actions. 7.9 • Authentication: Internal Ignition User Source or AD • Authorization: Roles and Zones 8.0 • Authentication: ? • Authorization: ?

  17. Federated Identities Authentication in Ignition 8 is done through Federated Identity Providers (often shortened to IdP). What is a Federated Identity? Federal State State State

  18. Federated Identities Ignition 8 will include three different IdP types out of the box: Ignition IdP • Legacy User Sources OpenID-Connect IdP SAML IdP

  19. Federated Identites Benefits • Web Single Sign On (SSO) - Better UX and more Secure • Single Source of Record for Identity Data • Simplified Provisioning and De-Provisioning

  20. Multi-Factor Authentication Passwords (or any one factor of authentication) alone are generally insufficient in protecting modern digital identity systems Multi-factor authentication (MFA) Two-factor authentication (2FA) is a subset of MFA where exactly 2 mechanisms are used to prove one’s identity

  21. Multi-Factor Authentication The three most common types of identity proofing mechanisms are: • What you know • Typically a password or passphrase • What you have • Badge which you can scan • A software or hardware based one-time-password (OTP) generator • A device such as a smartphone which is capable of receiving authentication requests • What you are (biometrics) • Fingerprint • Facial or Voice Recognition • Retina scan

  22. Security Levels Next up - Authorization. Introducing Security Levels… A platform-level construct aimed to make the permission modeling inside Ignition more convenient, portable Introduce a stand-alone permission modeling system for use within Ignition, regardless of how identity was established Put another way: security levels allow Ignition to have its own authorization system, independent of the authentication system being used.

  23. Security Levels Security Levels will look a lot like roles: • User • Operator • LineA • LineB • Supervisor

  24. Security Levels There are two “special” security levels defined by the platform • Public • All users are always granted the Public security level, even if they are not authenticated • Demo Project is almost entirely using the Public security level. • Authenticated • If a session has authenticated against the configured IdP successfully, they will have the “Authenticated” security level

  25. Security Levels If the IdP used did provide “role” information, the roles provided will be added as child security levels underneath “Authenticated” • Public • Authenticated • A • B The legacy role information underneath Authenticated provides a way to bridge this new method of permission modeling with the role-based permission modeling from Ignition 7

  26. Security Architecture Gateway: User Sources Vision Client: User Sources Designer: User Sources Perspective: Federated Identities and Security Levels

  27. Demo

  28. Kent Melville Sales Engineer Software Developer Joel Specht Cyber Security Risk Officer Jason Waits

More Related