Опыт внедрения криптошлюзов ViPNet в ЕРИС

[tenhi_shadow]

Насколько я помню, (сталкивался с этим в ЛПУ), все эти ЗТКИ стоят, типа работают, никто за ними не смотрят и самое главное… никакой траффик через них не ходит.
Стоят они для видимости, деньги «уплочены» и всё отлично.

[pavel_kirillov]

Спасибо, за Ваш комментарий. Вы думаете, я эти графики сам рисовал? :) это скриншоты из системы мониторинга. В общем, уверяю Вас, оборудование работает и трафик ходит через него. Если у вас будет возможность столкнуться с ЛПУ в Москве еще раз, можете убедиться в том, что оборудование стоит и работает.

[tenhi_shadow]

не критикую статью, вас. Всё вполне здраво. В фактах не сомневаюсь.
Просто говорю, что в регионах(на момент года 2013-14) было именно так, что эти стойки тупо стояли без дела. Линк какой-то держали, но не использовались по факту.

[SchmeL]

использовали VipNET только, чтобы соответствовать законодательству. Перед ним или после него стояло обычное шифрование и настроено было так, что если VipNEt умрет, то пользователи ничего не заметят. Вообще эти перепиленные OpenSSL библиотеки и OpenVPN клиенты с поддержкой ГОСТа, имхо совсем не безопасные. За обновления надо платить, а можно и не обновлять, а сертификаты от ФСБ — это просто фантики.

[iborzenkov]

Так это очевидно из первых строк — страшные российские аббревиатуры значат что это все было прикручено исключительно из-за фантиков а теперь на хабре пытаются натянуть сову на глобус и никто в здравом уме этого делать не будет.

[pavel_kirillov]

согласен с Вами, что в первую очередь данное оборудование используется для выполнения требований законодательства. Данной статьей я как раз хотел донести информацию, что не нужно после него ставить дополнительное шифрование и ждать что ViPNet помрет:) графики я как раз привел, чтоб была возможность убедиться, что это оборудование работает. Если у Вас есть какие-то вопросы по работе оборудования, то я готов на них ответить.

[pavel_kirillov]

Это печально

[Naves]

Гораздо интересней на чем собрали DICOM хранилище, софт и железо.
Уже несколько лет интересует вопрос, что же потом происходит с данными, тк реквизиты пациентов на рентгенах заводят как попало, каждый аппарат придумывает свой костыль для работы с киррилицей, если вообще ее поддерживает. Если аппарат поддерживает юникод, то все равно включают его редко.
В итоге в БД сервера скапливается просто огромная база каких-то снимков непонятных пациентов. Остаётся только окончательно анонимизировать изображения и отправлять забугор для обучения нейронных сетей и сбора половозрастной статистики.
По поводу графиков, а есть такие же за год только для серверов хранения, какой там уже объём?

[pavel_kirillov]

Задал вопрос разработчикам, надеюсь, они ответят

[imbasoft]

единый архив диагностических изображений

Интересно, как данный факт способствует защите персональных данных? Скорее на оборот…
но это вопрос не к автору.

Дальше после взаимодействия с вендорами Заказчиком было принято финальное решение в пользу ViPNet. Оставим финальный выбор за скобками данной статьи

Жаль самое интересное.

Странно, но графики нагрузки по ЦПУ (Рис. 3 и Рис. 5) на HW50 и HW1000 не бьются, хотя по идеи должны. И еще, что HW50 делают с 18:00 до 02:00 и особенно в 02:00 большой всплеск.

Есть мнение что в кабинетах, с точки зрения ИБ, было бы более безопасно гасить канал на ночь.

[Night_Snake]

рентген-кабинеты работают, порой, круглосуточно

[pavel_kirillov]

Этот факт очень даже способствует защите персональных данных. Если Вы сталкивались с медицинскими организациями, то наверно знаете, что у них нет в штате выделенного специалиста по информационной безопасности, там в основном ИТ-специалисты широкого профиля. То есть обеспечить высокий уровень безопасности проблематично (патчменеджмент, антивирусная защита, учет железа и софта хотя бы). Когда же все централизовано, это повышает требования по ИБ, но гораздо проще найти нескольких сотрудников в центр и обеспечить нужный уровень, чем искать для каждой ЛПУ.

[imbasoft]

Так то оно так, но я более чем уверен, что данные в кэше (а может и не только) остаются и ренген кабинете, что в итогое приводит к +1 ИСПДн

[pavel_kirillov]

Локально ничего не хранится, там тонкий клиент стоит, поэтому большое внимание уделяется задержкам в канале, все сразу в ЦОД передается, но компьютеры в радиологическом кабинете оборудованы средствами защиты информации (СЗИ от НСД, Антивирус и тд)

[imbasoft]

порой

Cудя по логам работы канала это не так :)

[Vinni37]

Интересно Вы конечно оправдали выбор ViPNet. Искусственно ввели двух игроков, использование которых заведомо невозможно, они же кроме как СКЗИ нужно еще и МЭ. А так как:

Не предполагалась установка дополнительного ПО на компьютеры радиологического кабинета, потому что зачастую для взаимодействия с радиологическим оборудованием требуются очень специфические и старые версии операционных систем и специального программного обеспечения

то от сюда Тыц следует что только ПАКи подходят.

[pavel_kirillov]

спасибо за Ваш комментарий. Не совсем так, в самих радиологических кабинетах нет выхода в интернет (то есть не обязательно, чтоб там был МЭ класса 4А, может быть и 4Б или 4В, то есть софт), поэтому наша задача состоит в организации защищенных каналов связи до ЦОД, МЭ 4А может в ЦОДе стоять. А уже из ЦОД может быть выход в интернет, например. Программные СКЗИ действительно рассматривались, но они не показали себя с лучшей стороны в данной конкретной задаче.

[Vinni37]

Логика регулятора в данном вопросе очень проста.
1) Есть выход сети за пределы контролируемой зоны, значит будьте любезны МЭ, если у вас сеть то железный МЭ, если единичный АРМ или сервер можно софтовым обойтись (привет ФСТЭК)
2) Если за пределы КЗ вы передаете конф. инф. то будьте любезны шифровать (привет ФСБ)
Так что наличие/отсутствие интернета ни о чем не говорит.

[pavel_kirillov]

1) Есть выход сети за пределы контролируемой зоны, значит будьте любезны МЭ, если у вас сеть то железный МЭ, если единичный АРМ или сервер можно софтовым обойтись (привет ФСТЭК)
это оценочное суждение, если Вы сможете привести конкретные цитаты из нормативки, я готов с Вами согласиться=)

[Vinni37]

Пожалуйста
СТРК

5.8. Защита информации при межсетевом взаимодействии
5.8.1. Положения данного подраздела относятся к взаимодействию локальных сетей, ни одна из которых не имеет выхода в сети общего пользования типа Internet.

5.8.2. Взаимодействие ЛВС с другими вычислительными сетями должно контролироваться с точки зрения защиты информации. Коммуникационное оборудование и все соединения с локальными периферийными устройствами ЛВС должны располагаться в пределах КЗ.

5.8.3. При конфигурировании коммуникационного оборудования (маршрутизаторов, концентраторов, мостов и мультиплексоров) и прокладке кабельной системы ЛВС рекомендуется учитывать разделение трафика по отдельным сетевым фрагментам на производственной основе и видам деятельности предприятия.

5.8.4. Подключение ЛВС к другой автоматизированной системе (локальной или неоднородной вычислительной сети) иного класса защищенности должно осуществляться с использованием МЭ, требования к которому определяются РД Гостехкомиссии России «Средства вычислительной техники. Межсетевые экраны. Защита от несанкционированного доступа к информации. Показатели защищенности от несанкционированного доступа к информации».

5.8.5. Для защиты конфиденциальной информации при ее передаче по каналам связи из одной АС в другую необходимо использовать:

· в АС класса 1Г — МЭ не ниже класса 4;

· в АС класса 1Д и 2Б, 3Б — МЭ класса 5 или выше.

Если каналы связи выходят за пределы КЗ, необходимо использовать защищенные каналы связи, защищенные волоконно-оптические линии связи либо сертифицированные криптографические средства защиты.

P.S. Текстовка взята из гугла, но смысл на сколько я помню не менялся с того времени как читал оригинал.

[pavel_kirillov]

Не очень понял, как этот тезис помогает подтвердить то, что написано выше.
Во-первых, статус СТР-К сейчас под большим вопросом, его сейчас мало кто применяет, в основном 17 и 21 приказ ФСТЭК.
Во-вторых, выходит за пределы КЗ и что? Когда писался СТР-К нового РД на МЭ еще не было. Защищенный канал до ЦОД, там стоит МЭ, на котором ACL для всех объектов. А до ЦОД — криптография, эти площадки ходят в интернет через ЦОД, если ходят вообще.

[imbasoft]

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

А с чем проблемы-то были?

[pavel_kirillov]

магпро — он создает большие задержки в канале, что в данном случае было непозволительно
криптопро — задержек особо не создавал, но плохо масштабируемый продукт и производитель больше не развивает решение (к сожалению)

[Naves]

Даже не знаю где спросить, поэтому спрошу здесь, а вот такая схема подключения криптошлюза вообще правильная?

схема

[000-Vladimir-000]

@pavel_kirillov можете подробнее написать про мониторинг ПАК ViPNet Coordinator HW1000? Какую систему мониторинга использовали, какие настройки выполнялись?