Почему вам следует перейти на Connext DDS Secure

«Безопасность должна быть встроенной, а не привинченной». Истинный. Вы это слышали. Я тоже это слышал. Фактически, поскольку Интернет вещей быстро становится реальностью, эта фраза повторяется так много раз, что меня беспокоит, что она станет клише, создающим ощущение срочности без реальной силы. Но почему с самого начала часто прибегают к безопасности? Поможет ли понимание причин этого избежать? Я надеюсь, что это так. Существует множество причин, от экономических до нормативных, образовательных и технических, которые я не могу подробно описать в этом сообщении в блоге (дополнительные сведения см. В IISF).

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

Отчасти задача инженерной безопасности заключается в разработке архитектур, обеспечивающих приемлемую защиту от угроз безопасности, возникающих в результате ошибок, случайностей или злого умысла, при минимальных накладных расходах на бизнес-функции и производительность системы. Это звучит легко, но на практике этого довольно сложно достичь, особенно по мере того, как системы становятся более сложными и взаимозависимыми, а над их реализацией работают более крупные и разнообразные группы людей. В частности, для систем IIoT меры безопасности следует продумывать с учетом более широких ограничений взаимодействия, производительности, масштабируемости, отказоустойчивости, безопасности и соответствия в средах, где угрозы безопасности и связанные с ними риски меняются довольно быстро. Эти соображения активно обсуждались и учитывались при разработке Спецификации безопасности DDS и Connext® DDS Secure RTI.

Если вы уже являетесь пользователем DDS или оцениваете DDS, чтобы стать им, вам обязательно стоит рассмотреть RTI Connext DDS Secure. Далее я расскажу, как Connext DDS Secure позволяет создавать конфигурации безопасности, которые позволяют архитекторам и инженерам находить правильный баланс между безопасностью и производительностью, исходя из рисков безопасности и требований к производительности. Я также приведу пример исследовательского проекта, который направлен на безопасную интеграцию клинической среды для значительного улучшения результатов лечения пациентов.

Подходит ли DDS Security для вашего случая использования?

Инженеры RTI обычно используют практическое правило, чтобы увидеть, действительно ли имеет смысл создавать архитектуру клиентской системы на основе DDS или им лучше использовать другую структуру подключения (подробное техническое обсуждение этого вопроса см. В IICF). В целом, если ответ хотя бы на три из следующих пяти вопросов - «да», DDS будет наиболее подходящей структурой для системы среди других существующих структур связи:

1. Если ваша система на короткое время перестанет работать, это большая проблема?
2. Вы говорили "миллисекунду" или "микросекунду" за последние две недели?
3. У вас более 10 инженеров-программистов?
4. Вы отправляете данные во множество мест, а не только в одно (например, в облако или базу данных)?
5. Вы внедряете новую архитектуру IIoT?

Если ваш ответ на вопрос 1 утвердительный, у вас строгие требования к доступности и отказоустойчивости. DDS уже предоставляет функции, которые в значительной степени помогают удовлетворить эти требования, включая полностью одноранговую работу (что означает отсутствие каких-либо единичных точек отказа) и несколько соответствующих параметров, включая политику владения, долговечности, живучести и крайнего срока QoS. Кроме того, DDS Security позволяет разделить домены DDS, аутентифицировать участников DDS, разрешить им публиковать или подписываться на темы DDS и аутентифицировать сообщения DDS до того, как данные будут переданы от промежуточного программного обеспечения к приложениям более высокого уровня. Эти функции позволяют предотвратить и / или значительно уменьшить влияние некоторых классов атак типа «отказ в обслуживании» (DOS). Эти функции в сочетании с надлежащими мерами контроля доступа на уровне сети, ОС и приложений обеспечат более надежную защиту от потенциальных DoS-атак в системах на основе DDS.

Если вы ответили на вопрос 2 «да», скорее всего, у вас есть значительные потребности в реальном времени. В таких случаях вам может потребоваться точная настройка безопасности вашей системы DDS на основе требований к рискам и производительности. Например, вас может не заботить то, что показания датчика температуры в общественном месте зашифрованы и передаются конфиденциально, но вы, вероятно, заботитесь о подлинности этих показаний. DDS Security позволяет вам определять и применять такие конфигурации, не внося никаких изменений в код вашего приложения.

Положительный ответ на вопрос 3, вероятно, означает, что вы хотите минимизировать стоимость взаимодействия между группами разработчиков программного обеспечения, каждая из которых работает над различными аспектами довольно большого программного проекта. Дизайн DDS, ориентированный на данные, позволяет командам разработчиков программного обеспечения согласовывать, какие данные (то есть типы и темы) должны быть распределены и как (то есть с какими настройками QoS), без необходимости обязательно предоставлять API обработки данных. Аналогичным образом, конфигурации безопасности DDS для встроенных подключаемых модулей (например, файлов управления доменом и разрешений участников) позволяют определять политики безопасности для распространения данных. Эти явные политики создаются на основе ваших моделей данных и того, как вы хотите защитить домены DDS. Эти политики могут быть независимо проверены инженерами по безопасности и системными архитекторами и скорректированы на основе анализа рисков и требований к производительности без внесения изменений в код приложения.

Положительный ответ на вопрос 4, вероятно, означает, что вы хотите наилучшим образом использовать многоадресную рассылку для более эффективной доставки данных. В отличие от популярных решений транспортного уровня, таких как TLS / DTLS, которые не могут использовать преимущества многоадресной рассылки, DDS Security имеет встроенную поддержку многоадресной рассылки, позволяющую более оптимизировать производительность доставки данных.

Если ваш ответ на вопрос 5 положительный, у вас есть шанс повысить безопасность, не беспокоясь о том, что придется иметь дело с устаревшим кодом. В то же время у вас, вероятно, есть масштабируемость, функциональная совместимость и отсутствие привязки к поставщику в вашем списке требований. DDS - одна из основных технологий подключения для IIoT (дополнительные сведения см. В IICF), основанная на общедоступном наборе спецификаций. Кроме того, DDS Security использует подключаемую архитектуру со стандартизованными API для аутентификации, авторизации, криптографии, тегирования данных и регистрации. Эти функции, вместе с поддержкой явных и детализированных политик безопасности для распределения данных, делают DDS сильным кандидатом на роль систем IIoT следующего поколения, позволяющих проектировать безопасность, а не закреплять ее на архитектуре вашей системы.

Все это звучит интересно, но кто-нибудь использует DDS Security? Ответ однозначный:да. RTI Connext DDS Secure уже протестирован и используется рядом наших коммерческих и государственных заказчиков. Мы отразили отзывы, полученные от этих первых пользователей, в нашей линейке продуктов. В случаях, когда необходимы дальнейшие разъяснения или обновления Спецификации безопасности DDS, мы обращаемся к сообществу DDS с целью дальнейшего улучшения стандарта.

Пример:DDS Security для безопасной совместимости медицинских устройств

Интересный пример, демонстрирующий преимущества DDS и DDS Security, проявляется в контексте интегрированных клинических сред (ICE). Структура ICE, как определено стандартом ASTM F2761-09, обеспечивает подход для интеграции разнородных медицинских устройств и координации их действий для автоматизации клинических рабочих процессов. С точки зрения высокого уровня, идея ICE заключается в том, чтобы позволить медицинским устройствам, которые соответствуют стандарту ICE, либо изначально, либо с использованием вторичного адаптера, взаимодействовать с другими ICE-совместимыми устройствами независимо от производителя. Если все сделано правильно, этот подход может существенно улучшить безопасность пациентов. Известные примеры включают перевод пациентов из операционной в отделения интенсивной терапии (ICU) или уменьшение количества ложных тревог в системах обезболивания, контролируемого пациентом (PCA). В обоих этих примерах обмен данными между поставщиками между устройствами значительно снижает коли

[1] [2] 下一页