Оптимальные методы безопасного моделирования
Настройка безопасной модели в ThingWorx является одним из наиболее важных этапов в разработке моделей, чтобы обеспечивать пользователям правильный доступ к активам в модели с учетом требований безопасности на каждом шаге по этому пути. Важным аспектом этого процесса является управление безопасностью Edge. В ThingWorx необходимо настроить детализированные разрешения для удаленных вещей, выполнив следующие действия.
• Создание уникальных пользователей, которые представляют удаленные вещи.
• Назначение пользователям правильной организации.
• Создание уникальных ключей приложения в уникальном контексте пользователя.
 |
Если в приложении используется функциональность выгрузки файлов, пользователям должны предоставляться надлежащие права доступа для выгрузки любого типа файлового содержимого в систему. Не гарантируется, что выгружаемые файлы безопасны, а входные данные поступают от доверенных пользователей.
|
Информация в этом разделе содержит советы, чего не следует делать при настройке безопасности в модели, а также оптимальные методы максимально безопасной настройки модели.
Управление безопасностью Edge
Управление безопасностью Edge является важным аспектом обеспечения безопасности модели с начала построения модели до безопасного развертывания. Edge является барьером между средой моделирования в ThingWorx (Composer) и внешними источниками данных. Существует множество способов управления безопасностью Edge в ThingWorx, в том числе использование соединений TLS/SSL для связи между вещью Edge и платформой. Использование TLS/SSL обеспечивает следующие возможности:
◦ Проверка сервера удаленными вещами с помощью сертификатов.
◦ Шифрование трафика с помощью TLS.
◦ Ключи приложений аутентифицируют удаленные вещи для платформы, а контекст пользователя, связанный с ключом приложения, ограничивает доступ в пределах платформы.
Нерекомендуемые методы
Хотя существуют шаги, с помощью которых можно сделать Edge максимально безопасным, некоторые методы могут понизить уровень общей безопасности системы. К этим методам относятся следующие:
• Выключать SSL не рекомендуется. Даже в сотовой связи некоторые сети имеют известные дефекты в архитектуре безопасности.
• Использование сертификатов с известными уязвимыми хэшами.
◦ Не используйте MD5, SHA1 и т. д. Используйте только рекомендуемые NIST.
◦ Не используйте самоподписанные сертификаты за пределами разработки.
• Использование одного и того же ключа приложения для нескольких устройств. Аутентификация соединений выполняется с помощью ключей приложений. Если ключи приложения не будут уникальными для устройств, будет трудно выявлять подключения с олицетворением или злонамеренные подключениям.
• Использование ключей приложения с широкими разрешениями. Это может привести к предоставлению активам прав доступа, которые они не должны иметь.
Рекомендуемые действия
• Использование доверенного центра сертификации.
• Использование авторизации с сертификатом клиента - взаимный TLS.
|
|
Ответственным за внедрение этой технологии является ваш системный интегратор. Подробности реализации см. в Руководстве пользователей C SDK.
|
• Использование ключей приложений. При настройке ключей приложения и пользователей ThingWorx всегда предоставляйте минимальные права. Назначение ключу приложения участника группы администраторов не является оптимальным методом.
Настройка модели
Для полной безопасности приложения всегда рекомендуется применять следующие принципы безопасности:
• Предоставление минимальных прав.
• Эшелонированная защита.
• Безопасные значения по умолчанию.
1. Настройка организации
Первым шагом при построении безопасной модели для устройств Edge должно быть правильное задание видимости сущностей с помощью опции Организация. Организации могут предоставить настройки видимости в масштабе всей системы для пользователей с надлежащим доступом к приложению.
2. Настройка групп пользователей
Настройте группы пользователей, чтобы развернуть средства управления доступом на основе ролей пользователя.
|
|
ThingWorx предоставляет несколько предопределенных групп пользователей. Дополнительные сведения см. в разделе Группы пользователей.
|
3. Настройка пользователей
Пользователи обеспечивают детализированный доступ к данным. После настройки организаций и групп пользователей должен быть создан один пользователь для каждой уникально разрешенной сущности на платформе. С точки зрения Edge это означает создание одного пользователя для каждого устройства Edge, которое будет подключено к платформе.
4. Настройка ключей приложения
Ключи приложения используются для того, чтобы получить безопасный доступ к платформе, и связываются с контекстом пользователя, чтобы определить разрешения. Для каждого устройства Edge, которое будет подключено, должен быть создан один ключ приложения. Должно существовать соотношение 1:1 для ключей приложения и пользователей или устройств.
5. Настройка удаленных вещей: видимость, разрешения времени конструирования и времени выполнения
После создания удаленной вещи первым контекстом безопасности, который следует задать, является видимость. Видимость оказывает влияние на организации и подразделения.
Затем следует задать разрешения времени конструирования. Разрешения времени конструирования должны предоставляться только доверенным пользователям, которые должны изменять поведение и модель в приложении. Обычно это означает, что пользователь или устройство не будут иметь разрешение времени конструирования, т. к. устройству не должно быть доступно самостоятельное изменение своего поведения.
Наконец, задайте таким образом разрешения времени выполнения для пользователя, который представляет устройство, чтобы устройство могло функционально способствовать работе приложения. Разрешения времени выполнения важны для детализации. Как минимум установите разрешения времени выполнения так, чтобы пользователь мог только получать доступ к вещи. При необходимости более тонкую детализацию можно задать в свойствах.
Дополнительные советы по настройке модели
• Рекомендуется в производственной среде удалять все разрешения времени конструирования во избежание возможного ухудшения качества важных бизнес-приложений. Все конструкции должны быть реализованы и проверены в изолирующем контексте, а затем развертываться в производственной среде только после успешной проверки приложения.
• Пользователи, ключи приложения и удаленные вещи могут создаваться программно, но любые сервисы, создаваемые для реализации этой возможности, должны строго контролироваться в модели безопасности приложения и удовлетворять правилам, описанным в предыдущем разделе.
• Если существуют две вещи Edge, соединяющиеся через один и тот же EMS или SDK, невозможно назначить один ключ приложения каждой вещи Edge. Если модель разрешения для этих устройств должна быть разделена, рекомендуется, чтобы они связывались через отдельные SDK, чтобы обеспечить отдельные контексты безопасности для каждой конечной точки соединения.
• Если существуют приложения, для которых требуется несколько источников данных для удаленных вещей или если несколько пользователей обращаются к разным источникам данных одной и той же вещи из веб-приложения, то разрешения времени выполнения могут задаваться для отдельных свойств и сервисов.
• При работе с любым объектом типа хранилища данных (вики, блоги, таблицы данных, потоки и потоки значений) рекомендуется предоставлять разрешения на выполнение сервиса для сервиса GetDefaultDataPersistenceProviderName подсистемы платформы. Чтобы создавать новые вещи типа хранилища данных, для пользователя должен быть видимым по крайней мере один поставщик хранилища данных в системе.