28.04.2010

Когда сертифицированных СКЗИ попросту нет ;-(

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

Сел я на досуге и составил списочек из сценариев, когда сертифицированных решений нет и не будет в обозримом будущем. Вот этот список:
  1. Работа представительств иностранных компаний в России. Они действуют в рамках корпоративных стандартов и применяют западные СКЗИ. Экспорт же отечественных СКЗИ невозможен по той причине, что ради одной страны западная компания не будет менять свои стандарты и не будет экспортировать отечественные СКЗИ во все страны, где западная компания представлена.
  2. Коммерческое IP-телевидение (устройства STB не поддерживают и не будут ГОСТы, т.к. они производятся за пределами России и поставляются в сотни стран мира).
  3. IP-видеонаблюдение, которое также не поддерживает отечественные криптоалгоритмы.
  4. Синхронизация основного и резервного центров обработки данных на скоростях свыше 1 Гбит/сек. Сегодня не редкость скорости 10 Гбит/сек и даже 40 Гбит/сек.
  5. Магистральное шифрование, которое сегодня обычно проходит на скоростях свыше 10 Гбит/сек.
  6. Стандарт беспроводной связи 802.11i, в котором на уровне стандартизующих организаций прописан иной криптоалгоритм.
  7. Стандарты мобильной связи 2.5G, 3G, а также LTE и Wi-Max, где также на уровне стандартов прописаны не ГОСТ.
  8. Чиповые смарткарты для платежных систем Visa и MasterCard.
  9. Шифрование в смартфонах, iPhone и т.п.
  10. Доступ к российским Интернет-банкам с компьютера в Интернет-кафе на заграничном отдыхе (на нем нет никакого российского криптопровайдера).
  11. Доступ из-за границы к любой российской платежной системе (Assist, ChronoPay, Яндекс.Деньги, Рапида и т.д.), а также к любой иной системе электронной коммерции (заказ билетов, заказ книг в Интернет-магазинах и т.п.).
  12. Защищенная электронная Web-почта по протоколу HTTPS.
  13. Шифрование в протоколе FibreChannel при записе на ленточку в центре обработке данных.
  14. Шифрование в протоколе FibreChannel при передаче данных внутри центра обработки данных или между разными центрами.
  15. Обмен с международными организациями российских федеральных органов исполнительной власти - МВД, ФТС, ФНС и т.д.
  16. Аутсорсинг
  17. Новая модель SaaS (Cloud Computing), когда вся обработка осуществляется через Интернет и, возможно, где-то за границей. По такому принципу работают многие переводческие компании.
  18. Доступ к российскому фондовому рынку из зарубежа.
  19. Поддержка АСУ ТП. Когда западные поставщики АСУ ТП решений для нефтянки, энергетики, промышленности и т.п. продают свои решения (Emersson, Rockwell, Siemens, Yokogawa и т.д.), то одним из условий является удаленная техническая поддержка (через Интернет или модем). И поддержка эта, как правило, оказывается из-за границы, опять же по западным криптоалгоритмам.

Хочу отметить, что речь не идет об исключениях, не попадающих под лицензирование согласно ПП-957 или согласно правилам ввоза шифровальных средств. Исключения - это всего лишь набор ситуаций, облегчающих лицензирование и ввоз, но не использование.

25 коммент.:

Mikhail комментирует...

Алексей, не всё так тяжко

1) можно построить в россии сеть на сертифицированных решениях, плюс стандартный ipsec туннель зарубеж. Последний, конечно, ставит под сомнение всю схему...
2) Если будет спрос на STB с ГОСТом, будет и предложение.
3) см. 2)
4-5) Проблема. С кадрами, умеющими разрабатывать чипы, в стране туго...
6-9) а в каком законе говорится, что на территории России иные криптоалгоритмы в принципе запрещены? Я нарушаю закон, если у меня в браузере сейчас url начинается с https://www.blogger.com ?
10) интернет-банки на платформе ibank2 (производитель бифит) используют ГОСТ и содержат криптопровайдер в самом java апплете. Так что в любом интернет-кафе любой страны, где есть на компьютере стандартная sun java, будет ГОСТ

ну и т.д.

Alexander комментирует...

можно еще добавить следующее:
1. если стандарт 802.11i не предполагает ГОСТ, то почему не использовать инкапсуляцию пакетов в протоколы с ГОСТом
2. по магистралям с шириной канала 1Гб/с и выше, можно попробовать использовать криптошлюзы с ГОСТом в кластерном исполнении

pushkinist комментирует...

2Mikhail, Alexander:
а вы из какого регулятора? :D

Mikhail комментирует...

pushkinist
Я, из регулятора? побойтесь бога! ;)

Alexander
кластер из "писюков" для шифрования по ГОСТу - это даже как-то не спортивно...

Алексей Т. комментирует...

В поддержку высказавшихся - мне тоже показалось, что Лукацкий лукавит. Нет возможности и времени разбираться, на мой взгляд в половине случаев реализация возможна и сейчас, а в остальных возможна в принципе. Никогда не говори никогда! Особенно такой пункт, как "аутсорсинг". :-) Алексей, для кого Вы это писали?

pushkinist комментирует...

господа возражающие, лол.
вы насколько в быту и в работе обычно сталкиваетесь с сертифицированной криптографией?
судя по вашим постам предположу, что не сталкиваетесь, да?

"интернет-банки на платформе ibank2 (производитель бифит) используют ГОСТ и содержат криптопровайдер в самом java апплете. Так что в любом интернет-кафе любой страны, где есть на компьютере стандартная sun java, будет ГОСТ"
для вас гост - синоним сертифицированности, а это не так.
бифит использует сертифицированные пбзи и скзи агава-с и криптоком, а они не содержатся в жаба-аплете, а копируются в ось.
плюс у него есть несертифицированное средство, реализующее гост, которое не копируется в ось.
но оно, как вы могли прочесть пару слов назад - несертифицированное.

хотя вообще я думаю, что Алексей Лукацкий говоря о ДБО скорее имел в виду реализации ДБО не на ЭЦП, потому что в ДБО вопросы использования сертифицированных средств накладываются требованиями цб по асп и законом об эцп.
согласно цб, дбо для юрлиц возможен только при таком асп, под которое подходит только эцп, а согласно фз об эцп проверка эцп возможна только сертифицированными средствами.
в случае же реализаций ДБО для физлиц можно использовать не ЭЦП, следовательно вопрос касается SSL/TLS и сертифицированных криптопровайдеров, а здесь проблемы с их наличием у пользователей и распространением среди пользователей.

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

плюс работа отечественных компаний с клиентами-нерезидентами породит эпичный гемор.

"2) Если будет спрос на STB с ГОСТом, будет и предложение."
дак надо чтоб этот гост сертифицирован был.
и по поводу спроса: ну вот есть спрос на высокопроизводительные сертифицированные решения с гостом, вот только предложений чето не ахти.
"кластер из криптошлюзов" - гениальная идея :D

Korwin комментирует...

Господа ИТшники пишут такие ответы, когда я выставляю им требования ФСТЭК. Им в обратку идут ответы как у Mikhail и Alexander. Но никакого движени в сторону выполнения требований нет. Поэтому пршлось вынести эту проблему повыше и теперь бизнес решает, что ему критично, а что нет. Вопрос обычно упирается в деньги, которые могут быть инвестированы в бизнес-процессы.

pushkinist комментирует...

ну и что в итоге бизнес решает?
как история заканчивается-то?

TeePee комментирует...

подскажите, вопрос по моему по теме,
есть требования 58 приказа ФСТЭК "предотварщение возможности отрицания полученных/переданных ПДн", есть WEB сервер на которой собираются запросы/ответы, существует ли какое то сретифицированоое ЭЦП-шное средство для реализации этих требований.
подписываются ЭЦП ответы сервера (без участия человека)
я так понимаю подразумевается ЭЦП. ЭЦП выдается на Пользователя? а подписывать необходимо сервером? как такое реализовать?

Алексей Т. комментирует...

2 TeePee я бы не советовал это требование 58 приказа воспринимать с т.з. реализации ЭЦП. Лучше попытайтесь его реализовать стандартными средствами идентификации/аутентификации/регистрации. По идентификатору и записям в журналах также можно доказать "получение/передачу ПДн". Возможно по записям на сетевом оборудовании о сетевых сессиях (если идет удаленный доступ).

TeePee комментирует...

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

Алексей Лукацкий комментирует...

Mikhail: Ну зарубеж - это тоже проблема, которую надо решать. По 6-9 - у вас передаются персданные. По требованиям ФСБ вы обязаны использовать сертифицированные СКЗИ. А СКЗИ не на ГОСТ никогда не будут сертифицированы.

Alexander: Инкапсуляцию где? На точке доступа это нереализуемо. Перед каждой ставить по криптошлюзу? А с клиентами что делать? Интел пока не встроил к себе ГОСТ и не сертифицировал (и НИКОГДА не сертифицирует) это решение.

Алексею Т.: Попробуйте разберитесь ;-) И потом можо подисскутировать. Ни в одном из рассмотренных мной случаев сертифицированные СКЗИ не применимы ни сейчас, ни в блжайшем будущем. Вариант с кластером я даже не рассматриваю. Представьте, что у вас синхронизация с резервным ЦОДом на 40 Гбит/сек. 40+1 криптошлюхов ставить?

pushkinist комментирует...

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

Korwin комментирует...

2 pushkinist.
Бизнес решает что ему выгоднее: заплатить штраф или выполнить требования. А проблема защиты информации это совсем другой вопрос, который ближе к КТ и надежности.
Проблема по моему в том, что ИТ служба, когда видит требования сразу ищет варианты, чтобы их не выполнять совсем, так как 100% их выполнение не достижимо.

doom комментирует...

2 Алексей Лукацкий

Вы как-то еще не упомянули, что при синхронизации ЦОД-РЦОД большая часть трафика совсем даже не IP ;)
Так что предложение с кластером из VPN шлюзов придется дополнить предложением переводить взаимодействие между СХД с FC на какой-нибудь iSCSI или еще что похуже - куда пошлют такого предлагателя примерно понятно (я уж молчу про дополнительный latency от шлюзов).

Ну а про беспроводку - всем сертифицированного клиента на рабочую станцию и вперед :) IPSec поверх wi-fi.

amt2001 комментирует...

Mikhail:

Кластер с балансировкой нагрузки и поддержкой многоядерности. Что Вас смущает?

Алексей Лукацкий:
Криптошлюзы на клиентах - это перебор. Хватит какого-нибудь софтварного решения. За точками (или группой точек) хоть по криптошлюзу. Но это уже детали.

В данном случае, если речь в целесообразности применения каких-либо решений, то это второй вопрос. Мы же с Вами говорим об имеющихся(потенциальных) сертифицированных СКЗИ.

Mikhail комментирует...

amt2001
ну про балансировку - это ещё как повезёт.
Не нравится именно кластер из софтовых устройств.
Ну может, положим, одна железка перелопатить гиг. А нужно 40 гиг. Вы поставите пару стоек орущего оборудования, жрущего дофига киловатт и потом будете неизвестным способом балансировать трафик? Да, расскажите, как будете балансировать на 40 устройств шифрования.

pushkinist комментирует...

"Бизнес решает что ему выгоднее: заплатить штраф или выполнить требования."

и что, после выплаты штрафа требования не надо будет выполнять?

amt2001 комментирует...

Mikhail :

Если брать из расчета 1 сервер - 1 Гбит/с, то получается 40 серверов, например, лезвиев. При желании 2-3 шасси с лезвиями влезают в одну стойку.
По софту не готов сказать.

Алексей Лукацкий комментирует...

doom: Ну там есть примеры с FC, которые тоже никем из отечественных не поддерживаются (если не использовать конвертеры). Ситуация с iSCSI и другими протоколами аналогичная.

amt2001: Вот организуется у нас скоро выставка СвязьЭкспоком. На эту площадь и при том количестве народа надо около 100-200 точек доступа. И для каждой вы предлагаете поставить криптошлюз? А как быть с Wi-Fi Mesh? Криптошлюз не сможет адекватно работать в такой среде. Я уже не говорю о стоимости решения.

Что же касается кластера, то извините, но 40 отечественных криптошлюхов будет стоить около 200 штук баксов. Это на одном конце. На втором тоже. Плюс резервирование. Очень грамотное решение. А еще их надо научить поддерживать FC или iSCSI или ставить по 40 конвертеров в IP ;-)

И каждому иностранцу по 8 сертифицированных криптоядер, т.к. как иначе он сможет подключиться к публичному хотспоту, который может использовать любого из сертифицированных в России криптоядер ;-) Вот бизнес-то попрет ;-)

amt2001 комментирует...

Алексей Лукацкий:
Цель какая? Не думаю что для доступа в публичную сеть через wifi нужны сертифицированные СЗКИ. Если последующий доступ в какой-то закрытый контур, то пожалуйста - ставьте 1 сервер доступа с ГОСТом. Тоже самое и с mesh.

По поводу 8-ми криптоядер - сейчас уже есть криптопровайдеры от разных производителей совместимые между собой. Остается только надеяться на продолжение данной тенденции.

Алексей Лукацкий комментирует...

amt2001: Извините, но заранее неизвестно с какой целью будет использоваться хотспот. А вдруг для обработки ПДн?

Что касается криптоядер, то опять же, заранее вы не можете знать, на каком ядре работает хотспот или Интернет-банк или платежная система. А значит вы вынуждены использовать ВСЕ.

Korwin комментирует...

pushkinist пишет...
"и что, после выплаты штрафа требования не надо будет выполнять?"

А зачем :). Шутка.
Будут смотреть как далее пороверяющая служба контролирует процесс выполнения, если не сильно хорошо, то могут и не выполнять. Ждать следующей проверки через год, скажем.
Печально конечно, но так.
Хотя я провожу работу по улучшению ситуации, и даже начал встречать понимание со стороны руководства компании, но вот когда дойдет до дела тогда и посмотрим...

Roman комментирует...

Алексей, давно хочу спросить у вас, а токен - это криптосредство?
Если я в чемодане из Европы сотню привезу - меня на таможне повяжут?

Если серьезно, я так и не могу найти ответ, как все-таки правильно ввезти и использовать в РФ иностранные СКЗИ. Немецкий производитель даже слышать не хочет о сертификации или продаже в РФ... :-(

Алексей Лукацкий комментирует...

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