Безопасный дизайн для IIoT

Безопасность для промышленного IoT (IIoT) представляет собой фундаментальную проблему проектирования. С одной стороны, промышленные системы не были задуманы с учетом подключения к Интернету. С другой стороны, компании теперь признают ценность подключения к своим промышленным системам, часто через Интернет. Возникает вопрос: как поддерживать высокий уровень безопасности для критически важной системы, предоставляя удаленный доступ к данным?

IIoT требует нового подхода к проектированию для обеспечения безопасности. Большинство промышленных систем управления предназначено для работы в безопасном периметре. Охраняемые брандмауэрами, DMZ (демилитаризованная зона, ДМЗ), а иногда и воздушными зазорами, периметр гарантирует, что никто не сможет получить доступ к сети завода извне. Промышленные протоколы, такие как, например OPC, позволяют производственным системам обмениваться данными в пределах этой сети. Но что, если кто-то, скажем, из ИТ-отдела, захочет использовать OPC соединение за пределами завода? При традиционном подходе построения промышленной системы для этого необходимо открыть порт брандмауэра в сети завода, который подвергает предприятие атаке, что создает серьезную проблему безопасности.

Некоторые предлагают использовать VPN (виртуальную частную сеть) для решения этой проблемы, но это создает другие проблемы. Использование VPN расширяет периметр безопасности, включая внешнюю ИТ-сеть, которая расширяет зону атаки. Хуже того, любой хакер, который попадает в VPN, получает доступ ко всем сетевым системам. Так были как раз произведены атаки на энергосистему в Украине и цепочку поставок со складов для магазинов в США. В обоих случаях злоумышленники смогли получить доступ ко всей сети через VPN.

Клемен Вастерс (Clemens Vasters), разработчик из Microsoft, объясняет ограничения дизайна VPN для IoT в документе под названием «Интернет вещей»: является ли VPN ложным другом? Он сказал: «VPN обеспечивает виртуальное и частное (изолированное) сетевое пространство. Защищенные туннели - это механизм для достижения надлежащим образом защищенного пути в этом пространстве, но пространство само по себе не обеспечивается вообще. Это действительно особенность, что установленное пространство VPN полностью прозрачно для всего протокола и трафика выше уровня канала. "

Источником проблемы является способ создания промышленных систем: модель клиент / сервер. В этой модели сервер подключен к источнику данных (например, к датчику или клапану), а клиентская программа (например, система HMI или SCADA) запрашивает данные от имени пользователя. Все стандартные промышленные протоколы соответствуют этой модели клиент / сервер, в которой сервер всегда является авторитетным поставщиком данных, и клиент всегда инициирует соединение. Но когда клиенту необходимо подключиться к защищенной сети, он должен иметь открытый порт брандмауэра.

Более эффективный дизайн - это сделать все серверные соединения исходящими. Вместо того, чтобы открывать порт брандмауэра или использовать VPN, специально разработанное промежуточное программное обеспечение может изменить динамику соединения. В локальной заводской сети программа промежуточного ПО подключается к серверу традиционным способом и получает данные. В то же время это промежуточное ПО способно выполнять исходящее соединение с соответствующей программой, выполняемой на стороне клиента. И на этой стороне клиентская программа подключается к промежуточному программному обеспечению для доступа к данным с сервера. Таким образом, клиент и сервер делают локальные соединения, которые легче конфигурируются и более безопасны, чем сетевые соединения.

Данной подход оставляет все порты брандмауэра закрыты на стороне сервера, но при этом выделяет клиентскую сторону. Чтобы обеспечить безопасность, как на сервере, так и на стороне клиента, одно и то же промежуточное ПО также может быть установлено на защищенной DMZ, чтобы действовать как посредник между сервером и клиентскими системами. Серверные и клиентские программы промежуточного ПО теперь только делают исходящие подключения к промежуточному ПО DMZ.

Кроме того, программа промежуточного ПО может работать на сервере облачных вычислений. Или, для максимальной гибкости, как DMZ, так и облачная служба могут работать одновременно, как гибридное облачное решение.

Ключевым принципом разработки здесь является возможность устанавливать только исходящие соединения, сохраняя все порты брандмауэра закрытыми. И тем не менее, для этого необходимо другое фундаментальное изменение отношения клиент / сервер. Помимо создания исходящих соединений промежуточное ПО должно быть способным действовать как надежный и «авторитетный» источник данных в каждой точке сети.

Под «авторитетным» подразумевается, что он может предоставить правильную информацию в случае отключения сети и повторного подключения. Клиент должен знать, когда сеть отключена, и данные таким образом ненадежны. И когда сеть восстановится, клиент должен получить правильные данные из авторитетного источника. Промежуточное ПО должно иметь возможность устанавливать и поддерживать «авторитет» независимо от того, выполняет ли он исходящие соединения или принимает входящие соединения.

Вкратце, подход, обеспечения безопасности на этапе проектирования системы, основанный на безопасном обращении к IIoT, позволяет настраивать полномочия данных, а также исходящие или входящие соединения. В традиционном дизайне клиент всегда инициировал соединение, и сервер всегда был авторитетным источником данных. Но эта модель не подходит для Интернета. Самая лучшая модель безопасности для IIoT держит все порты брандмауэра закрытыми, разрешая только исходящие соединения с сервера или клиента, сохраняя при этом данные достоверного источника отдельно от источника данных для пользователя.

Об авторе:

Боб Макливрид (Bob McIlvride) - директор по коммуникациям в Skkynet Cloud Systems, Inc., мировой лидер в области информационных систем в режиме реального времени. Он работает профессиональным техническим писателем в секторе управления производственными процессами более 15 лет и с ним можно связаться по адресу: bob.mcilvride@skkynet.com .