Всем знакома ситуация, когда регулятор, в лице ФСБ, требует использования только сертифицированных СКЗИ. Например, в действующих методических рекомендациях по защите ПДн именно это и написано. При отсутствии же сертифицированного решения рекомендуется задуматься о разработке новой СКЗИ и подаче его на сертификацию. Но всегда ли возможен выбор только между двумя этими сценариями?
Сел я на досуге и составил списочек из сценариев, когда сертифицированных решений нет и не будет в обозримом будущем. Вот этот список:
- Работа представительств иностранных компаний в России. Они действуют в рамках корпоративных стандартов и применяют западные СКЗИ. Экспорт же отечественных СКЗИ невозможен по той причине, что ради одной страны западная компания не будет менять свои стандарты и не будет экспортировать отечественные СКЗИ во все страны, где западная компания представлена.
- Коммерческое IP-телевидение (устройства STB не поддерживают и не будут ГОСТы, т.к. они производятся за пределами России и поставляются в сотни стран мира).
- IP-видеонаблюдение, которое также не поддерживает отечественные криптоалгоритмы.
- Синхронизация основного и резервного центров обработки данных на скоростях свыше 1 Гбит/сек. Сегодня не редкость скорости 10 Гбит/сек и даже 40 Гбит/сек.
- Магистральное шифрование, которое сегодня обычно проходит на скоростях свыше 10 Гбит/сек.
- Стандарт беспроводной связи 802.11i, в котором на уровне стандартизующих организаций прописан иной криптоалгоритм.
- Стандарты мобильной связи 2.5G, 3G, а также LTE и Wi-Max, где также на уровне стандартов прописаны не ГОСТ.
- Чиповые смарткарты для платежных систем Visa и MasterCard.
- Шифрование в смартфонах, iPhone и т.п.
- Доступ к российским Интернет-банкам с компьютера в Интернет-кафе на заграничном отдыхе (на нем нет никакого российского криптопровайдера).
- Доступ из-за границы к любой российской платежной системе (Assist, ChronoPay, Яндекс.Деньги, Рапида и т.д.), а также к любой иной системе электронной коммерции (заказ билетов, заказ книг в Интернет-магазинах и т.п.).
- Защищенная электронная Web-почта по протоколу HTTPS.
- Шифрование в протоколе FibreChannel при записе на ленточку в центре обработке данных.
- Шифрование в протоколе FibreChannel при передаче данных внутри центра обработки данных или между разными центрами.
- Обмен с международными организациями российских федеральных органов исполнительной власти — МВД, ФТС, ФНС и т.д.
- Аутсорсинг
- Новая модель SaaS (Cloud Computing), когда вся обработка осуществляется через Интернет и, возможно, где-то за границей. По такому принципу работают многие переводческие компании.
- Доступ к российскому фондовому рынку из зарубежа.
- Поддержка АСУ ТП. Когда западные поставщики АСУ ТП решений для нефтянки, энергетики, промышленности и т.п. продают свои решения (Emersson, Rockwell, Siemens, Yokogawa и т.д.), то одним из условий является удаленная техническая поддержка (через Интернет или модем). И поддержка эта, как правило, оказывается из-за границы, опять же по западным криптоалгоритмам.
Хочу отметить, что речь не идет об исключениях, не попадающих под лицензирование согласно ПП-957 или согласно правилам ввоза шифровальных средств. Исключения — это всего лишь набор ситуаций, облегчающих лицензирование и ввоз, но не использование.
Алексей, не всё так тяжко
1) можно построить в россии сеть на сертифицированных решениях, плюс стандартный ipsec туннель зарубеж. Последний, конечно, ставит под сомнение всю схему…
2) Если будет спрос на STB с ГОСТом, будет и предложение.
3) см. 2)
4-5) Проблема. С кадрами, умеющими разрабатывать чипы, в стране туго…
6-9) а в каком законе говорится, что на территории России иные криптоалгоритмы в принципе запрещены? Я нарушаю закон, если у меня в браузере сейчас url начинается с https://www.blogger.com ?
10) интернет-банки на платформе ibank2 (производитель бифит) используют ГОСТ и содержат криптопровайдер в самом java апплете. Так что в любом интернет-кафе любой страны, где есть на компьютере стандартная sun java, будет ГОСТ
ну и т.д.
можно еще добавить следующее:
1. если стандарт 802.11i не предполагает ГОСТ, то почему не использовать инкапсуляцию пакетов в протоколы с ГОСТом
2. по магистралям с шириной канала 1Гб/с и выше, можно попробовать использовать криптошлюзы с ГОСТом в кластерном исполнении
2Mikhail, Alexander:
а вы из какого регулятора? 😀
pushkinist
Я, из регулятора? побойтесь бога! 😉
Alexander
кластер из "писюков" для шифрования по ГОСТу — это даже как-то не спортивно…
В поддержку высказавшихся — мне тоже показалось, что Лукацкий лукавит. Нет возможности и времени разбираться, на мой взгляд в половине случаев реализация возможна и сейчас, а в остальных возможна в принципе. Никогда не говори никогда! Особенно такой пункт, как "аутсорсинг". 🙂 Алексей, для кого Вы это писали?
господа возражающие, лол.
вы насколько в быту и в работе обычно сталкиваетесь с сертифицированной криптографией?
судя по вашим постам предположу, что не сталкиваетесь, да?
"интернет-банки на платформе ibank2 (производитель бифит) используют ГОСТ и содержат криптопровайдер в самом java апплете. Так что в любом интернет-кафе любой страны, где есть на компьютере стандартная sun java, будет ГОСТ"
для вас гост — синоним сертифицированности, а это не так.
бифит использует сертифицированные пбзи и скзи агава-с и криптоком, а они не содержатся в жаба-аплете, а копируются в ось.
плюс у него есть несертифицированное средство, реализующее гост, которое не копируется в ось.
но оно, как вы могли прочесть пару слов назад — несертифицированное.
хотя вообще я думаю, что Алексей Лукацкий говоря о ДБО скорее имел в виду реализации ДБО не на ЭЦП, потому что в ДБО вопросы использования сертифицированных средств накладываются требованиями цб по асп и законом об эцп.
согласно цб, дбо для юрлиц возможен только при таком асп, под которое подходит только эцп, а согласно фз об эцп проверка эцп возможна только сертифицированными средствами.
в случае же реализаций ДБО для физлиц можно использовать не ЭЦП, следовательно вопрос касается SSL/TLS и сертифицированных криптопровайдеров, а здесь проблемы с их наличием у пользователей и распространением среди пользователей.
ну так вот использование сертифицированных скзи везде где только можно создаст ситуацию при которой практически все поголовно будут нарушать законодательство в части распространения, учета и использования скзи.
распространение должно производиться под роспись в получении и с внесением записей в журнал. вариант же с распространением через инет не вариант ибо следуя требованиям законодательства это вызовет рекурсию: при передаче надо обеспечить целостность и подлинность скзи, а удаленно это можно сделать используя эцп, только вот эцп должно быть сертифицированное, то есть принимающая сторона изначально должна иметь сертифицированные скзи для проверки подлинности сертифицированных скзи.
плюс работа отечественных компаний с клиентами-нерезидентами породит эпичный гемор.
"2) Если будет спрос на STB с ГОСТом, будет и предложение."
дак надо чтоб этот гост сертифицирован был.
и по поводу спроса: ну вот есть спрос на высокопроизводительные сертифицированные решения с гостом, вот только предложений чето не ахти.
"кластер из криптошлюзов" — гениальная идея 😀
Господа ИТшники пишут такие ответы, когда я выставляю им требования ФСТЭК. Им в обратку идут ответы как у Mikhail и Alexander. Но никакого движени в сторону выполнения требований нет. Поэтому пршлось вынести эту проблему повыше и теперь бизнес решает, что ему критично, а что нет. Вопрос обычно упирается в деньги, которые могут быть инвестированы в бизнес-процессы.
ну и что в итоге бизнес решает?
как история заканчивается-то?
подскажите, вопрос по моему по теме,
есть требования 58 приказа ФСТЭК "предотварщение возможности отрицания полученных/переданных ПДн", есть WEB сервер на которой собираются запросы/ответы, существует ли какое то сретифицированоое ЭЦП-шное средство для реализации этих требований.
подписываются ЭЦП ответы сервера (без участия человека)
я так понимаю подразумевается ЭЦП. ЭЦП выдается на Пользователя? а подписывать необходимо сервером? как такое реализовать?
2 TeePee я бы не советовал это требование 58 приказа воспринимать с т.з. реализации ЭЦП. Лучше попытайтесь его реализовать стандартными средствами идентификации/аутентификации/регистрации. По идентификатору и записям в журналах также можно доказать "получение/передачу ПДн". Возможно по записям на сетевом оборудовании о сетевых сессиях (если идет удаленный доступ).
логи на сетевом оборудовании находятся у одного оператора,
возможность изменения логов существует, речь идет о взаимодействии ИС различных операторов.
Как мне обязать стороннего, ленгитимно допущенного оператора, без применения ЭЦП, верить моим логам
Mikhail: Ну зарубеж — это тоже проблема, которую надо решать. По 6-9 — у вас передаются персданные. По требованиям ФСБ вы обязаны использовать сертифицированные СКЗИ. А СКЗИ не на ГОСТ никогда не будут сертифицированы.
Alexander: Инкапсуляцию где? На точке доступа это нереализуемо. Перед каждой ставить по криптошлюзу? А с клиентами что делать? Интел пока не встроил к себе ГОСТ и не сертифицировал (и НИКОГДА не сертифицирует) это решение.
Алексею Т.: Попробуйте разберитесь 😉 И потом можо подисскутировать. Ни в одном из рассмотренных мной случаев сертифицированные СКЗИ не применимы ни сейчас, ни в блжайшем будущем. Вариант с кластером я даже не рассматриваю. Представьте, что у вас синхронизация с резервным ЦОДом на 40 Гбит/сек. 40+1 криптошлюхов ставить?
еще прикол в том что если брать трансграничную передачу, то мы из россии можем передавать данные в страны с "адекватной защитой пдн", а в обратную сторону процесс невозможен.
то есть несмотря на все потуги в области защиты персональных данных мы получается не можем обеспечить такую же "адекватную" защиту персональных данных иностранным субъектам, потому что скорее всего при передаче будут использовать средства не обеспечивающие должной защиты с точки зрения наших регуляторов
это не бред ли?
2 pushkinist.
Бизнес решает что ему выгоднее: заплатить штраф или выполнить требования. А проблема защиты информации это совсем другой вопрос, который ближе к КТ и надежности.
Проблема по моему в том, что ИТ служба, когда видит требования сразу ищет варианты, чтобы их не выполнять совсем, так как 100% их выполнение не достижимо.
2 Алексей Лукацкий
Вы как-то еще не упомянули, что при синхронизации ЦОД-РЦОД большая часть трафика совсем даже не IP 😉
Так что предложение с кластером из VPN шлюзов придется дополнить предложением переводить взаимодействие между СХД с FC на какой-нибудь iSCSI или еще что похуже — куда пошлют такого предлагателя примерно понятно (я уж молчу про дополнительный latency от шлюзов).
Ну а про беспроводку — всем сертифицированного клиента на рабочую станцию и вперед 🙂 IPSec поверх wi-fi.
Mikhail:
Кластер с балансировкой нагрузки и поддержкой многоядерности. Что Вас смущает?
Алексей Лукацкий:
Криптошлюзы на клиентах — это перебор. Хватит какого-нибудь софтварного решения. За точками (или группой точек) хоть по криптошлюзу. Но это уже детали.
В данном случае, если речь в целесообразности применения каких-либо решений, то это второй вопрос. Мы же с Вами говорим об имеющихся(потенциальных) сертифицированных СКЗИ.
amt2001
ну про балансировку — это ещё как повезёт.
Не нравится именно кластер из софтовых устройств.
Ну может, положим, одна железка перелопатить гиг. А нужно 40 гиг. Вы поставите пару стоек орущего оборудования, жрущего дофига киловатт и потом будете неизвестным способом балансировать трафик? Да, расскажите, как будете балансировать на 40 устройств шифрования.
"Бизнес решает что ему выгоднее: заплатить штраф или выполнить требования."
и что, после выплаты штрафа требования не надо будет выполнять?
Mikhail :
Если брать из расчета 1 сервер — 1 Гбит/с, то получается 40 серверов, например, лезвиев. При желании 2-3 шасси с лезвиями влезают в одну стойку.
По софту не готов сказать.
doom: Ну там есть примеры с FC, которые тоже никем из отечественных не поддерживаются (если не использовать конвертеры). Ситуация с iSCSI и другими протоколами аналогичная.
amt2001: Вот организуется у нас скоро выставка СвязьЭкспоком. На эту площадь и при том количестве народа надо около 100-200 точек доступа. И для каждой вы предлагаете поставить криптошлюз? А как быть с Wi-Fi Mesh? Криптошлюз не сможет адекватно работать в такой среде. Я уже не говорю о стоимости решения.
Что же касается кластера, то извините, но 40 отечественных криптошлюхов будет стоить около 200 штук баксов. Это на одном конце. На втором тоже. Плюс резервирование. Очень грамотное решение. А еще их надо научить поддерживать FC или iSCSI или ставить по 40 конвертеров в IP 😉
И каждому иностранцу по 8 сертифицированных криптоядер, т.к. как иначе он сможет подключиться к публичному хотспоту, который может использовать любого из сертифицированных в России криптоядер 😉 Вот бизнес-то попрет 😉
Алексей Лукацкий:
Цель какая? Не думаю что для доступа в публичную сеть через wifi нужны сертифицированные СЗКИ. Если последующий доступ в какой-то закрытый контур, то пожалуйста — ставьте 1 сервер доступа с ГОСТом. Тоже самое и с mesh.
По поводу 8-ми криптоядер — сейчас уже есть криптопровайдеры от разных производителей совместимые между собой. Остается только надеяться на продолжение данной тенденции.
amt2001: Извините, но заранее неизвестно с какой целью будет использоваться хотспот. А вдруг для обработки ПДн?
Что касается криптоядер, то опять же, заранее вы не можете знать, на каком ядре работает хотспот или Интернет-банк или платежная система. А значит вы вынуждены использовать ВСЕ.
pushkinist пишет…
"и что, после выплаты штрафа требования не надо будет выполнять?"
А зачем :). Шутка.
Будут смотреть как далее пороверяющая служба контролирует процесс выполнения, если не сильно хорошо, то могут и не выполнять. Ждать следующей проверки через год, скажем.
Печально конечно, но так.
Хотя я провожу работу по улучшению ситуации, и даже начал встречать понимание со стороны руководства компании, но вот когда дойдет до дела тогда и посмотрим…
Алексей, давно хочу спросить у вас, а токен — это криптосредство?
Если я в чемодане из Европы сотню привезу — меня на таможне повяжут?
Если серьезно, я так и не могу найти ответ, как все-таки правильно ввезти и использовать в РФ иностранные СКЗИ. Немецкий производитель даже слышать не хочет о сертификации или продаже в РФ… 🙁
Про ввоз скоро будет отдельная заметка. А токен будет СКЗИ, если у него на борту криптопроцессор стоит.