Pages - Menu

Страницы

28.4.10

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

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

Сел я на досуге и составил списочек из сценариев, когда сертифицированных решений нет и не будет в обозримом будущем. Вот этот список:
  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 комментариев:

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

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

    ну и т.д.

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

    ОтветитьУдалить
  3. 2Mikhail, Alexander:
    а вы из какого регулятора? :D

    ОтветитьУдалить
  4. pushkinist
    Я, из регулятора? побойтесь бога! ;)

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

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

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

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

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

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

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

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

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

    ОтветитьУдалить
  8. ну и что в итоге бизнес решает?
    как история заканчивается-то?

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

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

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

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

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

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

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

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

    ОтветитьУдалить
  15. 2 Алексей Лукацкий

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

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

    ОтветитьУдалить
  16. Mikhail:

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

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

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

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

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

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

    ОтветитьУдалить
  19. Mikhail :

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    ОтветитьУдалить

Примечание. Отправлять комментарии могут только участники этого блога.