Как стать автором
Обновить
6
0

Пользователь

Отправить сообщение

Клиент собирал кастомную инсталляцию на базе tower серверов, которая не соответствовала "vSAN Compatibility Guide"

В нашем случае под бекапы установлены виртуальные криптошлюзы. Шириной канала, как и объемом передаваемых данных, конечно, можно и нужно управлять. Хочу отметить, что большинство наших клиентов не делает полный бекап каждый день. Ежедневные “дельты”, как правило, не большие по объемам и могут легко быть переданы.
Конечно, если появляется новый клиент с вопросами миграции (что потребует большой объем передачи данных), для такой задачи может быть развернут дополнительный виртуальный шлюз на время миграции. При этом мы и получаем плюсы использования виртуального шлюза – быстро развернул под задачу, использовал, и как только стал не нужен – выключил. При этом оплата, в отличие от ПАК только за лицензию на тот месяц или два что выполнялась миграция. Такой подход всем приятен;)
В защищенном сегменте Облака #CloudMTC на уровне технических средств мера ЗИ реализуется организационно-режимными мероприятиями и применением АПМДЗ на уровне платы расширения. Сожалею, но технические детали продукта не смогу привести из-за ограничений в политиках.
По требованиям регулятора для ГИС в качестве СЗИ необходимо рассматривать только сертифицированные решения, что очевидно. С другой стороны, на текущий момент нет действующего документа, определяющего требования к классу используемых криптосредств. Для ряда клиентов (в случаях повышенных требованиях описанных частных моделях нарушителя) мы можем рассмотреть использование необходимых ПАК с более высоким классом, чем КС1.
1. Я о том и говорил, что показывают либо титульник, либо титульник + 1 страницу, а самое интересное в аттестате дальше — в приложении. Там и список собственно железа, которое было аттестовано с серийными номерами и список аттестованного ПО, и список применяемых сертифицированных СЗИ. Понятно, что это не те сведения, которые стоит вывешивать в открытый доступ, но, надеюсь, вы их предоставляете клиентам по запросу.


Да, вы правы, в открытый доступ подробное описание не публикуют. Это внутренние документы. Но по первым двум страницам аттестата (публичной части) можно многое прочесть. Это мы и описали в нашем материале. Остальные документы — по запросу и только клиенту.

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


Отлично, буду рад видеть клиентов :)

3. Протокол конечно не публичный документ, но есть ситуации, когда его нужно показывать. Мы, например, практически не занимались аттестацией коммерческих облаков, но были кейсы когда нам нужно было аттестовать ГИС, переехавшую в такое облако. По 17 приказу ГИС все равно нужно аттестовывать отдельно, но можно использовать результаты аттестации инфраструктуры ЦОД. Так вот, в нашем понимании, ЦОД должен нам предоставить эти результаты и ряд других внутренних ИБ-документов, чтобы мы могли убедиться, что ЦОД аттестован по нужному классу, что физически наша ГИС будет хоститься именно на аттестованном железе, что у применяемых в ЦОД СЗИ не истекли сроки сертификатов (или срок оказываемой техподдержки), что в списках сотрудников ЦОД, физически допущенных к железу нашей ГИС нет уволенных сотрудников и т. д. Но мы часто сталкивались или с затягиванием сроков предоставления документов или с отказом в их предоставлении.


Согласен с Вашим замечанием. При работе с ГИС или ИС, подключенной к ГИС, в Облаке или стороннем ЦОД много сложнее, чем просто разместить ИСПДн клиента. Клиенту при работе с ГИС всегда нужна аттестация его ИС, которая от части базируется на нашем Облачном Сервисе и соответственно аттестате (ссылается на аттестат, на МУ и т.д.). Для такого случая мы предлагаем клиенту два документа “Разделение ответственности...» и “Выписка из Модели Угроз…”. Эти документы публичные для нашего клиента. Документы подписаны со стороны аттестатора, который выполнял аттестацию нашего Облачного сервиса, что позволяет говорить, что мы не сами себе описание придумали.
Полностью поддерживаю Ваши слова: очень важно соблюдение актуального состоянии от документов на ЦОД и Облачный Сервис и до СЗИ и списков сотрудников – важный процесс. Для нас, как для провайдера это еще и вопрос репутации. Тут у многих бывает так, что в чужом глазу соломину видеть, в своём — бревна не замечать. Поэтому мы выбрали простой путь: проводим ежегодный контроль внешней компанией-аттестатором.
Рады, что Вы прочитали и подробно прокомментировали наш материал. Отлично, когда сухой материал про ИСПДн, ГИС и регуляцию вызывает такой живой интерес. Понимаю, что Вы хорошо погружены в тему ПДн и регуляции. По Вашим комментариям:

1. Во-первых, вы во всей статье как-то умалчиваете, что когда оператор ПДн размещает ПДн своих клиентов в облаке он по сути передает их другому лицу — владельцу облака. И в большинстве случаев он должен брать с субъектов ПДн на это согласие. Во-вторых, вы так пишете как будто оператор ПДн при законной передаче персданных третьим лицам должен бегать по этим третьим лицам и проверять все ли в порядке у них с защищенностью. А третьи лица могут расслабиться. Нет, закон говорит, что третьи лица тоже должны принимать меры и они тоже несут ответственность, правда не перед субъектом ПДн, а перед операторм ПДн.


Где же здесь противоречие? Оператор ПДн несет ответственность перед субъектом ПДн? Несет. В этой связи важно ли оператору ПДн помимо формальной юридической процедуры – оформления поручения на обработку ПДн с провайдером, убедиться в добросовестности этого провайдера? Изучить его репутацию? Ознакомиться с репутацией компании-лицензиата, которая проводила оценку эффективности (или аттестацию)? Думаю, что ответ очевиден. Репутационные риски никто не отменял. При передаче данных на обработку третьему лицу по поручению сам оператор не перестает быть оператором и с него не снимается никакая ответственность. В отличии от GDPR у нас нет в законодательстве разграничений между data processor и data controller. Оба лица будут операторами ПДн, только один из них отвечает перед самими субъектами ПДн, а второй по договору перед первым.

2. Можно пример требования именно изоляции? Вот смотрю сейчас 21 приказ ФСТЭК, управление информационными потоками — вижу, защищенный удаленный доступ — вижу, защиту периметра — вижу. А изоляция это какое конкретно требование?


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

3. Эээ, а при оценке эффективности оператор ПДн разве не должен также определить УЗ, разработать модель угроз и исходя из актуальных угроз и своего УЗ выбрать перечень мер для реализации? Вы же сами дальше пишете, что ОЭ от аттестации отличается тем, что не нужно привлекать лицензиата и что финальные документы могут делаться в свободной форме. Это так, но это не означает, что сами мероприятия по защите ПДн как-то отличаются от того, собираетесь ли вы в итоге проводить аттестацию или ОЭ! Да и на соответствие требованиям какому загадочному ГОСТ? Требования по защите информации установлены в методических документах ФСТЭК.


Полностью согласен с Вашим рассуждением. Оператор сам вправе выбирать провайдера, у которого есть ОЭ или у которого есть аттестат. При этом наличие Аттестата соответствия все-таки более регламентированная процедура и проводится в соответствии с ГОСТ 0043-003-2012 и ГОСТ 0043-004-2013. В соответствии с этими же ГОСТ есть порядок разрешения споров с привлечением регулятора, в отличии от ОЭ. Таким образом, наличие Аттестата ФСТЭК России является дополнительной гарантией.

4. Я уже выше написал — разграничение зон ответственности уже четко установлено законом.


Установлено, верно, но уровень абстракции достаточно высок. Так, например, при модели IaaS клиент провайдера, размещая свои ИС на инфраструктуре ЦОД, должен применять дополнительные организационно-технические меры по защите своих систем и тут крайне важно понимать, какие требования закрывает провайдер, а какие должен закрывать клиент, чтобы ничего не пропустить. Мы как провайдер по запросу предоставляем такой документ своим клиентам, и он при этом пользуется достаточно высоким спросом.

5. Это как? Возьмем определение «персональные данные» из 152-ФЗ и дадим свое «расплывчатое»? Что это за бред и как это понимать? То, что отчетные документы по ОЭ могут делаться в свободной форме это значит, что нет четких требований к их оформлению и содержанию, как например к документу «Программа и методики аттестационных испытаний», требования к которому установлены ГОСТ РО 0043-004-2013 «Защита информации. Аттестация объектов информатизации. Программа и методики аттестационных испытаний». А не то, что можно вертеть на одном месте термины и определения из законодательства


Опять-таки это следствие от необходимости руководствоваться упомянутыми выше ГОСТ – процедура и содержание документов более строго регламентировано.

6. Да как бы не «проблематично», а «невозможно». Пункт 17.6 приказа ФСТЭК №17


Были не точны в формулировке, принимается

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


Безусловно, речь об отчётных документах, статья на хабре – это все-таки не жестко регламентированный документ, и там, где нет необходимости не стоит заниматься излишним формализмом. По сути же, думаю, что все понятно.

8,9 Нет, не верно, набор требований зависит от установленного УЗ и актуальных угроз безопасности. Здесь по требованиям конечно может быть некая дельта вариативности, но не такая большая как хотелось бы.
Выбор защитных мер как бы регламентирован, а не собирается по желанию левой пятки. Вам плюсики в таблицах с мерами в приложениях к приказам ФСТЭК ни о чем не говорят?


И снова про добропорядочность исполнителей.

10. До 2017 года было так для всех УЗ. Сейчас же в 12 пункте приказа ФСТЭК №21 есть такой текст…


Верно! Но только если принято решение применения сертифицированных СЗИ.

11. Говорю по собственному опыту — из сотен аттестованных объектов только единицы за все годы обратились за услугой периодического контроля.


Как я понимаю, Вы работает в компании, которая специализируется на услугах в области информационной безопасности. И Вам, вероятно, известно, что периодические контрольные мероприятия компания может выполнять самостоятельно, не привлекая сторонних компаний. Возможно, поэтому Вы видите только подход “получил и забыл”. Вопрос соблюдать правила регуляции или “ездить без билета” – это вопрос репутации компании. Поверьте, но не все “ездят без билета”.

12. Кроме РТК не знаю таких, хотя работали со многими.


Например, облачные провайдеры CloudMTS, ИТ-ГРАД, ДатаЛайн – лицензиаты ФСТЭК и ФСБ. Это можно подчерпнуть из их сайтов. Да, возможно, у небольших компаний нет лицензий. Но это уже выбор клиента: работать или нет с лицензиатами, оценить репутацию Облачного провайдера, где предстоит размещать свою ИСПДн или ГИС. Помимо этого, не ясно как компании без лицензии предоставляют своим клиентам услуги по ИБ, а то что это происходит (факт оказания ИБ-услуг) при модели IaaS, не должен вызывать сомнений.

13. О, вот это интересно! ФСТЭК завел публичный реестр аттестованных объектов??? А ссылочкой не поделитесь?


Да, ссылку не пришлю, реестра нет, речь идет о другом. Клиент может убедиться в легитимности аттестата. На сайте регулятора есть список компаний, которые уполномочены проводить испытания и выдавать аттестат. По аттестату можно понять кто выдал его и т.о. проверить могли его выдать.

14. В лучшем случае вам покажут скан обложки и первую страницу


Это не так. На наш взгляд, сегодня не так все печально. Предполагаю, Вы не будете спорить, что аттестат публичный документ, в отличии, например, от протокола аттестационных испытаний. Очевидно, клиент Облачного провайдера, размещая свою ИСПДн или ГИС, конечно, захочет увидеть аттестат в полном объеме, а не только первую страницу. Да и добропорядочные игроки на рынке не скрывают его, и не показываю из-под полы. Так Облачные провайдеры #CloudMTS и ИТ-ГРАД приводят сканы аттестатов на своих сайтах, вот ссылки cloud.mts.ru/files/%D0%90%D1%82%D1%82%D0%B5%D1%81%D1%82%D0%B0%D1%82_2020-11-30.pdf и www.it-grad.ru/files/licenses/lic-n-09-20.pdf. Предвижу Ваше замечание, что это родственные компании и реклама самих себя. Сразу скажу, что не мы одни такие. Возьмем компанию-конкурента ДатаЛайн. На их сайте аналогично — размещен аттестат www.dtln.ru/files/certificate.pdf. Думаю, что примеров достаточно и замечу, что не только первые страницы во всех приведенных случаях. Возможно, у Вас был только негативный опыт, но сегодня значительное количество игроков публикуют свои аттестаты, не только первые страницы. Да, конечно есть и недобросовестные игроки. Из своего негативного опыта: несколько лет назад мне встречался “фотошоп” аттестата. Это была первая страница. После запроса всего документа компания юлила и не смогла предоставить документ. Называть эту компанию не буду. Замечу, что у них сегодня на сайте можно так же найти скан аттестата.

Конечно, можно продолжить, но Ваш подход сквозит недоверием и минимальным позитивом. Поэтому в заключении остановлюсь на Вашем комментарии:

полно лицензиатов, которые проводят «аттестацию по фотографии» и плевать хотели на свою репутацию


Соглашусь с Вами в одном: далеко не всем компаниям сегодня важна репутация. Возможно, у Вас такой опыт. Но нашим компаниям CloudMTS и ИТ-ГРАД репутация важна, ровно как и коллегам из НАЦ. А если у Вас еще остались сомнения и недоверие, то Вы можете обратиться к нам и взять в тест виртуальные мощности в аттестованном сегменте. Думаю, что при более близком знакомстве у Вас появится больше позитива к аттестованным облачным сервисам.
Рад, что вам материал понравился. Соглашусь, что многие из мифов справедливы для всех ИС с любыми данными, а не только ПНд. Но, с другой стороны, очень мало компаний вывешивают на сайт в публичный доступ аттестаты на свои Облака. Демонстрация первой страницы аттестата вообще клиенту мало что говорит. При этом могут написать, что все Облака аттестованы по уровню УЗ-1/K1. Клиенты часто не в теме деталей и считают, что чем выше уровень или класс защиты, тем лучше. Хотя для 90% наших клиентов УЗ-3 — это необходимо и достаточно, а на что-то большее лучше не смотреть в силу дополнительных обременений. Другие провайдеры играют с «оценкой эффективности» и подменяют ей аттестат. Хотя сами понимают, что аттестат и оценка эффективности – совсем разные вещи, особенно в случае, если клиент предполагает в дальнейшем пройти аттестацию своей ИСПДн.
В текущем материале эта тема не раскрыта. Я обсудил это на вебинаре, можно посмотреть запись. Если говорить кратко, то каждый клиент «ИТ-ГРАД» и #CloudMTS в аттестованном Облаке получает некоторую виртуальную серверную (сегмент или тенант) с набором виртуального железа (vCPU, vRAM, SSD, HDD) и виртуальным маршрутизатором. Для доступа в нее — один или несколько белых IP. Белые IP находятся на сертифицированном МСЭ (программно-аппаратное решение). Трафик с белых IP натируется на виртуальный маршрутизатор в тенанте клиента. Да, если два клиента одного такого аттестованного Облака захотят обменяться трафиком, то это возможно сделать только через внешний МСЭ. Настройками фильтрации на своих белых IP клиенты управляют по заявкам в ТП. В своем тенате на виртуальном маршрутизаторе можно настроить многое клиенту самому (за рядом исключений, например, L2 связь во внешний мир). Если клиенту нужно сделать какие-то сложные сетевые вещи, можно поставить VM с маршрутизатором/FW Cisco и т.п., а если сертифицированный крипто-туннель до его другой локации – VM с криптошлюзом С-Терра. В общем вариантов много ;)
Вы правы. В примере про агентство говорится, что клиент планирует рассчитывать статистику. Речь не идет о создании или хранении всей базы и т.п. Вы правильно пишете, что передавать за границу можно только обезличенные данные, либо передавать, обрабатывать. В примере, вероятно, нечетко прописана цель передачи – обработка данных (расчёт статистики). Пример как раз приведен для того, чтобы показать, как клиенту трудно разобраться в деталях и корректно описать свою ИСПДн, да так, чтобы самого себя не “подвести”. Спасибо, что отметили этот момент.
1) При разворачивании виртуальных серверов под заказчика на них предустанавливаются сертифицированные СЗИ, всякие там секретнеты и т.д.?

Нет. Клиент получает набор виртуального железа (vCPU, vRAM, SSD, HDD и т.п.). Он сам решает, какие ОС и СЗИ в них ему использовать. ИС клиента — это его зона ответственности. Мы как провайдер ему можем только советовать и рекомендовать, но решать, что и как, — вопрос клиента.

2) На первой схеме не совсем понятно, что отводится под ИС заказчика, сегмент справа, что выделен пунктиром?

Да, клиент получает тенант (сегмент) внутри Облака.

3) Виртуальные межсетевые экраны имеют сертификаты (Тип «Б» вроде)?

МСЭ типа «А» — это МСЭ, применяемый на физической границе (периметре) информационной системы или между физическими границами сегментов информационной системы. Именно такое сертифицированное решение применяется для защиты всего Облака. МСЭ типа «Б» — это МСЭ, применяемый на логической границе (периметре) информационной системы или между логическими границами сегментов информационной системы.

Информация

В рейтинге
Не участвует
Работает в
Зарегистрирован
Активность