Унифицированная архитектура OPC была спроектирована, чтобы поддержать безопасные, аутентифицируемые связи между серверами UA OPC и клиентами. Несобственнические протоколы промышленного стандарта используются, чтобы достигнуть безопасности в коммуникации UA OPC. Безопасность в UA OPC обеспечивается с помощью трех механизмов:
Сообщения, переданные между клиентом и сервером UA OPC, могут быть отправлены в одном из трех Режимов безопасности сообщения:
None: Никакая безопасность. Сообщения отправляются в открытом тексте.
Sign: Сообщения подписываются отправителем, чтобы аутентифицировать источник сообщения. Однако сообщения не зашифрованы.
SignAndEncrypt: Сообщения подписываются отправителем, чтобы аутентифицировать источник сообщения, и шифруются, чтобы гарантировать конфиденциальность.
Шифрование и подписание сообщений выполняются с помощью схем Asymmetric Cryptography промышленного стандарта. Политика безопасности Канала задает определенную схему использовать в шифровании и подписании. Для списка в настоящее время поддерживаемой Политики безопасности Канала в OPC Toolbox™ введите следующую команду в MATLAB:
enumeration opc.ua.ChannelSecurityPoliciesПри подготовке безопасного соединения между Клиентом UA OPC и Сервером UA OPC, каждая из сторон обменивается Сертификатами Экземпляра приложения, которые используются, чтобы зашифровать и подписать сообщения, отправленные между сторонами. Эти сертификаты могут опционально проверяться по доверительному списку сертификатов, обеспеченному системными администраторами для каждого приложения, чтобы гарантировать, что связи установлены с правильным сервером от правильного клиента. OPC Toolbox в настоящее время принимает сертификаты сервера автоматически, когда связь устанавливается. Для получения дополнительной информации см. управление Сертификатом UA OPC.
Аутентификация пользователя может использоваться сервером, чтобы ограничить доступ к функциям сервера на основе определенного пользователя, устанавливающего связь. OPC Toolbox поддерживает следующие опции аутентификации пользователя:
Anonymous: Имя пользователя не обеспечивается. Некоторые серверы не могут допускать аутентификацию анонимного пользователя.
Username: Комбинация имени пользователя и пароля аутентифицирует определенного пользователя, устанавливающего связь.
Certificate: Пользовательский Сертификат (в стандарте X509) используется, чтобы аутентифицировать пользователя. Открытый ключ сертификата должен быть предварительно совместно использован с сервером, и при установлении связи, которую пользователь должен обеспечить открытому ключу, закрытому ключу, и пароль раньше защищал закрытый ключ. Очиститесь (passwordless) закрытые ключи не поддержаны OPC Toolbox.
Серверы обычно поддерживают больше чем одну модель обеспечения безопасности для клиентов, чтобы использовать при соединении с сервером. Поддерживаемые модели обеспечения безопасности, что сервер поддержки описан через конечные точки, доступные с сервера. Каждая конечная точка задает одну Политику безопасности Канала, допустимые Режимы безопасности сообщения и Типы аутентификации поддерживаемого пользователя. Чтобы использовать ту определенную конечную точку, клиент устанавливает связь с конечной точкой, которую перечисляет URL, обеспеченный в конечных точках, и задает Режим безопасности сообщения, чтобы использовать.
Вы запрашиваете доступные конечные точки сервера с помощью opcuaserverinfo, или путем построения клиента UA OPC с opcua. Если вы создаете клиент UA OPC, можно установить модель обеспечения безопасности использовать в той связи с помощью setSecurityModel. Вы передаете удостоверения пользователя, когда вы связываете с сервером с помощью connect функция.