На днях давал разъяснения специалисту одного из кировских учреждений по поводу тех или иных способов организации защищенного взаимодействия подведомственных учреждений.
В общем-то ситуация обычная, когда Заказчик, выбирая решения (а в итоге и политику) в данной области, получает реплики (взгляды на строительство) из нескольких источников. Источники эти могут быть различной степени компетентности и погруженности в вопрос защиты информации. Одним нужно ехать, другим шашечки, а третьим бюджетную экономию.
Зачастую выходит так, что никому из них не нужно всё вместе. Хотя ИБ - это как раз ВСЁ ВМЕСТЕ.
Ну так вот одна из реплик из другого региона в противовес политике строительства защищенной сети на базе одного из распространенных на рынке сертифицированных VPN-решений уровня KC2-KC3 была такая, если выразить кратко: "А мы сделали всё на базе КриптоПро CSP и это встало значительно дешевле!". Причем конечно же реплики такие воспринимаются, как авторитетные. За уверенностью коллег часто кажется, что эта позиция прошла и надзорные проверки и за ней многолетняя практика, опыт, специалисты, компетентное обозрение вопросов ИБ и т.п... Ну так весомо кажется.
Но что сделали коллеги на самом деле, говоря об экономии? Они реализовали защищенный веб-сервис на базе технологии TLS. Благо сертифицированная версия содержит в документации такой сценарий для веб-сервера Microsoft IIS. Единственное, КриптоПро для сервера стоит существенно дороже, что нужно учитывать, а вот, например, ViPNet CSP что для клиента, что для сервера одинаково бесплатен. Ну это вопрос уже другой.
Основной вопрос для меня состоял в том, как разъяснить коллеге, что оппоненты из другого региона сделали далеко не всё. Чтобы подтвердить это, они не сделали главного - не провели оценку соответствия. Ну потому что если её сделать, то всё станет ясно, а сравнение затрат не станет таким однозначным.
Это вытекает из самой фразы, т.к. организация защищенного контура никогда не ограничивается только одним криптопровайдером, тем более уровня KC1. К слову сказать, KC1 означает, что шифровалка умеет шифровать и более ничего. Да, сеансы браузера шифруются, но защищены ли криптоключи? Выполнен ли весь требуемый для безопасности комплекс мер, в т.ч. орг.мер?
Вообще установку одной шифровалки мы обычно оцениваем в 10-20% от всех мер. И если Вы даже её поставили, выполнив только "запустить, далее, далее, далее, ок", то это всего лишь говорит о том, что ничто не изменилось в политике, которая была до этого: "скомпилировалось да и ладно".
Продолжение следует...
В общем-то ситуация обычная, когда Заказчик, выбирая решения (а в итоге и политику) в данной области, получает реплики (взгляды на строительство) из нескольких источников. Источники эти могут быть различной степени компетентности и погруженности в вопрос защиты информации. Одним нужно ехать, другим шашечки, а третьим бюджетную экономию.
Зачастую выходит так, что никому из них не нужно всё вместе. Хотя ИБ - это как раз ВСЁ ВМЕСТЕ.
Ну так вот одна из реплик из другого региона в противовес политике строительства защищенной сети на базе одного из распространенных на рынке сертифицированных VPN-решений уровня KC2-KC3 была такая, если выразить кратко: "А мы сделали всё на базе КриптоПро CSP и это встало значительно дешевле!". Причем конечно же реплики такие воспринимаются, как авторитетные. За уверенностью коллег часто кажется, что эта позиция прошла и надзорные проверки и за ней многолетняя практика, опыт, специалисты, компетентное обозрение вопросов ИБ и т.п... Ну так весомо кажется.
Но что сделали коллеги на самом деле, говоря об экономии? Они реализовали защищенный веб-сервис на базе технологии TLS. Благо сертифицированная версия содержит в документации такой сценарий для веб-сервера Microsoft IIS. Единственное, КриптоПро для сервера стоит существенно дороже, что нужно учитывать, а вот, например, ViPNet CSP что для клиента, что для сервера одинаково бесплатен. Ну это вопрос уже другой.
Основной вопрос для меня состоял в том, как разъяснить коллеге, что оппоненты из другого региона сделали далеко не всё. Чтобы подтвердить это, они не сделали главного - не провели оценку соответствия. Ну потому что если её сделать, то всё станет ясно, а сравнение затрат не станет таким однозначным.
Это вытекает из самой фразы, т.к. организация защищенного контура никогда не ограничивается только одним криптопровайдером, тем более уровня KC1. К слову сказать, KC1 означает, что шифровалка умеет шифровать и более ничего. Да, сеансы браузера шифруются, но защищены ли криптоключи? Выполнен ли весь требуемый для безопасности комплекс мер, в т.ч. орг.мер?
Вообще установку одной шифровалки мы обычно оцениваем в 10-20% от всех мер. И если Вы даже её поставили, выполнив только "запустить, далее, далее, далее, ок", то это всего лишь говорит о том, что ничто не изменилось в политике, которая была до этого: "скомпилировалось да и ладно".
Продолжение следует...
Сереж, как-то не очень понятно. Если речь идет об оценке соответствия относительно использованных в системе СКЗИ, то никакой другой кроме использования сертифицированных в ФСБ (или получивших положительное заключение по результатам оценки влияния при встраивание в ПО) нет. Ты пишешь, что они не провели оценку соответствия. Оценку соответствия чего, СКЗИ или системы? Если первого, то это не дело оператора (если только они что-то свое не разработали), если второго, то надо просто провести проверку шифрования TLS-соединений в рамках аттестационных испытаний, для указанного криптопровайдера это сделать не проблема.
ОтветитьУдалитьПо поводу КС1, в совокупности с внедренными орг.мерами СКЗИ данного класса для организации защищенного канала связи достаточно, и это действительно дешевле, чего чаще всего и хотят операторы. Говорить о технической защите ключей имеет смысл, только если эта угроза актуальна и орг.мер для противодействия ей недостаточно, а это чаще всего не так. Если передача конфиденциалки идет только через http, весь трафик туннелировать смысла нет.
Миша, спасибо за комментарий :)
ОтветитьУдалить1. Оценка соответствия - обязательное мероприятие, предусмотренное ФЗ-152. Так что и в части СКЗИ это тоже обязанность оператора.
2. KC1 в совокупности с оргмерами. Вот это интересный момент. Первое. По формуляру кроме оргмер значится антивирус сертифицированный, сейфы, защита от НСД по ФСТЭК. Так что если суммировать имея в виду, что это ГИС ПДн, а не просто ИСПДн. Второе. Когда у тебя не одно юрлицо, а сотни юрлиц? Ладно в одном юрлице это сделать.
3. Http-сервис. Если бы был только он один. А если их много и разных, да еще Web-серверы разных производителей, в т.ч. какие-то самопальные? Вот в обсуждаемом мной ведомстве именно так. Вот поди по встраивай крипту в эти разные TLS. А там кой где и TLS-то устаревший с уязвимостями.
Т.е. всегда за казалось бы простыми утверждениями, как оказывается, может стоять клубок систем и проблем в них заложенных.
1. По 152-ФЗ оператор должен только использовать средства защиты, прошедшие оценку соответствия, но это не значит, что данную оценку обязательно должен проводить оператор. Более того, если оператор подпадает под ПКЗ-2005, то в части СКЗИ оценкой соответствия занимается только ФСБ.
Удалить2. Не согласен с аргументами. Сейф, орг.меры, сертифицированный антивирус ты должен использовать и в случае применения, как ты говоришь, одного из распространенный средств построения VPN-решений (это обязательные условия для любого СКЗИ). Исключением и то только в части антивируса может быть криптошлюз или терминал, но они стоят столько, что может быть выгоднее использовать клиентские решения.
3. А кто мешает поставить на входе IIS c криптопро в режиме реверсного прокси и дальше раскидывать потоки по всем веб-серверам?
1. Конечно, может оператор, а может и лицензиат, а может и орган по сертификации. По части СКЗИ согласен только в части корректности встраивания и определения требований, вписанных в правила пользования. Однако что из того выполнил оператор при внедрении - это его забота, а не ФСБ.
Удалить2. Потому и следует сопоставлять эти решения.
3. А если не только веб серверы, а еще и другие протоколы в сети ходят? Есть еще проблема - ряд производителей свой продукт пишут под FireFox, Opera, YandexБраузер, IE. Мало кто из них думает о корректности встраивания КриптоПро в этот браузер. Ну а что реверсные прокси? Назови имеющие сертификаты ФСБ, да такие, чтобы не испортили Web-приложение - там же ведь изменения в код веб-страниц и скриптов на лету нужно вносить? Я пытал CheckPoint и других - у всех где-то там зависло по части встраивания криптопро, причем давно уже это тянется. Работать то оно работает, но если идти до конца в части оценки соответсвтия - то не тут то было. Подскажи, если знаешь.
1. Не может и не должен оператор заниматься оценкой соответствия СКЗИ в случае попадания под ПКЗ-2005. Это могут делать только специализированные лаборатории с соответствующей лицензией ФСБ под контролем 8 центра.
Удалить2. Да, сопоставлять, но при этом не аргументировать наличием тех условий, которые на самом деле необходимо выполнять при применении любых СКЗИ. Это уже спекуляции ))
3. Если не только Http, то есть еще такой продукт КриптоПро ipsec, он любой трафик туннелирует и ставится на обычную Windows службу удаленного доступа. По поводу браузеров, надо смотреть что у заказчика - легально использовать только IE и IIS, это не является встраиванием. У тебя будет, допустим, КриптоПро CSP с IIS, связка которых сертифицирована ФСБ и на IIS модуль обратного прокси (который не должен иметь никакого сертификата ФСБ, поскольку функций шифрования не выполняет, а просто выполняет смену адреса конечного сайта).
1. Еще раз повторюсь. Я даже еще одну статейку написал, в ней более четко. Ты говоришь про оценку соответсвтия самого средства защиты - это 8й центр ФСБ, а я про оценку соответствия всех принятых мер - это оператор.
Удалить2. Об том и речь. Когда сравнишь, выяснишь плюсы и минусы, то выбор будет объективным. А если думать, что поставил КриптоПро и не выполнил обязательных мер к нему, то это значительно дешевле, то вот это даже не спекуляция, а от некомпетентности.
3. КриптоПро IPSec очень старый, если не изменяет аж под версию 3.0 и WinXP?. А новый ожидается...
Обратный прокси: а зачем ты мне его предложил, если проблема встраивания в полный рост во все вебсервера остаётся? Освежу про изменение адреса, т.к. по моей памяти TLS вообще говоря, как средство избежания подмены сетевых узлов и внедрения агентов между узлами, пакеты подписывает, включая и IP, что означает, что IP ты изменить не можешь. А если меняешь, значит должен шифровать прямо на этом прокси.
А есть еще одна проблема - статический нат, да еще и на нестандартные порты.
1. Тогда мы говорим об оценке эффективности относительно ИС. Тоже не вижу аргументации, ее надо делать как для варианта использования криптопровайдера, так и для VPN-решения. Технически проверить утсановку защищенного канала и в том и другом случае никаких проблем не создает.
Удалить2. Так даже с антивирусами в большинстве случаев при организации клиентского удаленного доступа все равно получается дешевле и проще в эксплуатации.
3. По поводу криптопро ipsec информацию надо уточнять, сейчас навскидку не помню.
По поводу обратного прокси. Откуда проблема встраивания во все сервера! Почитай про технологию reverse proxy, это редирект на прикладном уровне, про NAT и IP ты не туда пошёл. Тебе его надо организовать только на входном IIS, причем эта функция у тебя шифрование использовать не будет, поэтому ни о каком встраивании речи нет.
1. Как ни назови. Эффективность - это когда эффект должен быть от мер, а соответствие - все ли требования правил пользования оператор выполнил. В любом случае, я заключаю, что ни того, ни другого сделано не было или системы сравниваются разного пошиба.
Удалить2. Да не в этом дело, Миша. Нужно сравнивать решения для конкретной своей системы и своих задач, а не прикладывать то, что было у кого-то, к себе. Крипта+ Антивирус - это не полный набор мер.
3. Если есть крипта, то встраивать её нужно.
Сережа, пост по моему мнению составлен некорректно. Объективной аргументации в нем не увидел. Все проблемы, которые ты описываешь, это проблемы использования любой СКЗИ, а не варианта с криптопровайдером.
УдалитьПо поводу п.3 ты неправ. Вопрос о встраивании крипты решается ТОЛЬКО для того ПО, взаимодействие которого с СКЗИ задекларировано и используется. В противном случае ты должен был бы проводить оценку влияния на СКЗИ всего софта на компе, включая какой-нибудь Winamp, блокнот и т.п.
Вот и я говорю, что смотря как смотреть :)
УдалитьВ пункте 3 вопрос стоял о TLS.
Организацией TLS-соединений занимается браузер с криптопровайдером на стороне клиента и IIS с крипровайдером на стороне площадки где хостятся серверы. После установки защищенного канала происходит установка открытых соединений между IIS и конкретными сайтами площадки за счет модуля обратного прокси на IIS. Между этими узлами никакого шифрования нет, и оно не нужно, нет смысла шифровать соединений внутри одной площадки.
УдалитьМиша, понял. Спасибо за совет :)
Удалить