СОИБ. Проектирование. Сертифицированный защищенный удаленный доступ (Remote VPN) часть 1
Сразу хочу отметить исходные условия:
·
вопросы необходимости сертификации СКЗИ в
данной статье не рассматриваются;
·
постоянно возникают задачи из всего спектра
существующих средств построения VPN
быстро
выбрать те, которые походят под ограничивающие
условия у Заказчика (а уже потом из тех, которые в принципе будут работать
делать сравнение по функциям)
·
функциональные возможности средств защиты удаленного
доступа в данной заметке не рассматриваются
·
основными ограничивающими условиями для защищенного
удаленного доступа являются – типы устройств с которых должен осуществляться доступ,
используемые операционные системы и требуемый класс криптографической защиты (КС1,
КС2, КС3). По этим условиям легко проводить объективное сравнение – все они
приведены в формулярах на СКЗИ
·
речь идет о защите удаленного доступа типовых
пользователей крупной и средней компании (то есть не единичного АРМ, а
ноутбуков с разными ОС и желательно планшетов)
Вариант
КС2.
Начну с выводов: если речь идет
о ноутбуках, то решения фактически отсутствуют. С планшетами ситуация ещё
хуже.
Обоснование: в формулярах на все СКЗИ в исполнении КС2
указывается необходимость использование средств защиты от несанкционированного
доступа из следующего перечня:
·
Программно-аппаратный комплекс с физическим
датчиком случайных чисел "Соболь"
·
Аппаратно-программный модуль доверенной
загрузки универсальный КРИПТОН-ЗАМОК/У
·
Программно-аппаратное средство
"Аккорд-АМДЗ"
·
Специальный загрузочный носитель - СЗН
"МАРШ!-USB"
Возьмем, к примеру, Аккорд-АМДЗ.
Единственными моделями в принципе подходящими для ноутбуков являются варианты Mini
PCI Express и Mini PCI Express half-size. Но и в нем поддерживаются далеко не все
модели BIOS и
аппаратных платформ на ноутбуках. Переченьмоделей, протестированных производителем, невелик. Перед каждым проектом нужно собирать подробный
перечень моделей и отправлять производителю + время на тестирование + не всего
оно возможно.
Например, у нашего пользователя
есть довольно популярный MacBook Air . Куда там ставить Mini PCI Express? Его и открывать то нельзя. Аесли откроем – увидим что свободного слота там нет. Да и операционная система OS X Lion этого
ноутбука так-же не поддерживается.
Соболь – ситуация аналогична Аккорду,
толь ещё хуже, потому что модель Mini PCI Express только появилась и даже не
сертифицирована ФСБ.
Криптон – вообще только PCI Express и для ноутбуков не подходит.
Загрузочный носитель МАРШ! – вроде подходит для всех ноутбуков,
поддерживающих загрузку с USB. Но какие
он поддерживает ОС – Fedora и AltLinux? А где же наш Windows 7 Корпоративный (про OS X молчу)? Пересаживать всех пользователей на Linux? Нет – руководство заказчика на это не пойдет
(ведь они же первые используют удаленный доступ с ноутбуков).
У Вас возникает вопрос – а кто вообще
требует КС2/КС3 для удаленного доступа? Кому
пришла в голову такая глупость?
Во-первых, такая ситуация возникает,
когда пишется модель нарушителя по ФСБ сразу для всей области защиты. КС1 – это
нарушитель Н1. Н1 – это нарушитель не имеющий физического доступа к средствам
обработки организации. Н2 – отличается
от Н1 тем что может получить физический доступ к средствам обработки
организации. Чтобы обосновать Н1, нам фактически придется обосновать что все
сотрудники являются доверенными лицами. Если по-честному, то после такого
сильного утверждения применять средства защиты внутри организации вообще не
требуется.
Во-вторых, требуемый класс защиты часто
спускается отраслевым регулятором или вышестоящей организацией. В регионе такую
ситуацию можно наблюдать регулярно.
В-третьих КС2 или даже КС3 может
потребоваться в соответствии с будущими документами ФСБ по защите ПДн. По
версии Алексея Лукацкого эти требования будут выглядеть так. И КС2 и выше там
вполне могут быть.
PS: К чему была эта часть? Коллеги, внимательно выставляйте требования к классам защиты. КС2 для удаленного доступа быть не должно.
PPS: Следует продолжение по КС1, ссылки на формуляры и таблица сравнения.
Комментарии
По ОС - информация получена от производителя:
"На данный момент мы устанавливаем на МАРШ! ОС Fedora 16, так же завершается процесс тестирования МАРШ! с предустановленной ОС Windows Embeded.
Есть успешный опыт использования МАРШ! с сертифицированной ОС AltLinux."
Даже мне есть разница под какой ОС работать.
Не говоря уже об обычных пользователей, у которых есть привычное им рабочее место, все документы под рукой и т.п.
По RDP у заказчика работают далеко не все приложения.
Я считаю что МАРШ и аналоги надо использовать только для специфических задач.
2.Но все же если вернуться к сути замечания про используемую ОС, а не заниматься софистикой, то представим на секунду стандартную модель работы пользователя через МАРШ, например медицинского работника. Что ему нужно? Подключиться к УЭК, сам сервер в Москве, точка подключения vipnet координатор предположим в местном УЗО. Пользователь получает марш, втыкает его на АРМ, загружается с него, и тут вопрос: именно в момент загрузки пользователя смутит, что загружаемая ОС не покажет название WINDOWS, или после загрузки, когда канал поднялся, и пользователю открылся Firefox с доступом к единственной страничке сервера медицинской системы УЭК?
3.Вышел патч уязвимости. Наверно у Вас больше опыта, но все же предположу, в данной модели мы будем иметь 2 типа уязвимостей: 1, это уязвимость поставщика vpn(в нашем случае vipnet) 2 уязвимость связанная с НДВ и как следствие НСД при локальном доступе к МАРШ. Ведь за удаленный доступ в некотором роде будет отвечать МСЭ vipnet, соответственно данный класс будет относится к уязвимости первого типа нашего примера. Поэтому, для устранения уязвимости нам действительно понадобится :
1 обновить нашу сеть vipnet
2 обновить ПО на устройствах МАРЩ.
Если Вы теоретик, то сразу после выхода обновления, Вы начнете защищать вашу уязвимую сеть vipnet.
На практике же, пользователи, за частую экономят на технической поддержке, обновлять сеть будут только в случае расширения либо крайней необходимости. А это будет делать сторонняя организация, на основании отдельного договора. В рамках этого договора и будут проведены обновления на МАРШ.
Если уязвим МАРШ
Мы же помним как работает vipnet, связи там с серверами, с кем может работать пользователь, возможное наложение ограничения лицензий на туннелируемые адреса и так далее. Тем не менее разберем векторы уязвимостей устройства доверенной загрузки в упрощенной форме:
1) уязвимость связанная с аутентификацией на устройстве
2) уязвимость связанная с модификацией областей памяти устройства(на сколько помню их от 4 и выше может быть).
3) возможно что то забыл, или фантазия плохая:)
Итого, при наличии уязвимости первого типа, при загрузке, мы получим доступ к единственному удаленному серверу, через единственно установленный web браузер без права его модификации, и без знания пароля доступа к опять же удаленной сертифицированной системе. Ну а что, ддосить сервер от имени определенного пользователя VPN наверно "безопасно и анонимно"
При наличии уязвимости второго типа, предполагаю, должен быть не правильно реализованный механизм контроля целостности. Хотя вдруг и там все подменили. Только любая атака имеет цель, в данном случае мы упремся к тому, что целью будет либо реализация уязвимости первого типа, либо получение доступа к АРМ, в который воткнут МАРШ, к которому доступ можно получить и без МАРШ. В итоге мы пришли к уязвимости только первого типа, расширенной возможностью модификации установленного ПО на МАРШ, но которая ограничена рамками анонимности и защищенности атакуемой целевой системы.
Зы, не ставлю целью защищать только МАРШ. По моему мнению, у нас в России, всего несколько организаций которые реально занимаются производством СЗИ, и делают свои продукты именно для защиты, а не маркетинга. Причем для защиты в условиях требований регуляторов, что за частую сложно, как в силу не завершенности самих требований, так и в силу ряда противоречий с другими требованиями смежных регуляторов. Если возникает вопрос, то его надо решать. При обращении в САПР, мне никогда не отказывали в помощи. Если Вы утверждаете, что Вы обратились за помощью, и на Вас забили, мне самому было бы полезно знать о данном случае. Ведь мы выбираем используемые СЗИ в своих проектах и по фактору адекватности технической поддержки тоже.
А об обычных сотрудниках, которые хотят работать за своим рабочим ноутбуком удаленно (из дома, гостиницы, из офиса партнера)
Им нужно иметь возможность писать электронную почту, работать с общими папками, работать с локальными документами и конечно запускать множество приложений, не все из которых работают по web.
Конечно свисток с линуксом для этого не подойдет.
А про уязвимости и обновления ты не совсем понял.
Речь шла о том, что если мы накатим в МАРШ! 10 приложений и раздадим пользователям, то это ПО устареет через несколько месяцев.
Придется регулярно забирать у пользователей свистки на обслуживания.
И что ? Обращаемся в техподдержку - а оттуда тишина .....
К сожалению, в технической поддержке ОКБ САПР подобного обращения не зарегистрировано.
Если вас не затруднит, уточните, пожалуйста, на какой e-mail Вы отправляли запрос.
Если нужно локальное хранилище, то в МАРШ!е (в образе) можно в качестве одного из внешних устройств поддержать флешку СЕКРЕТ. Любые другие локальные хранилища - не рекомендуется, может быть дыра.