Обезличивание персональных данных и data masking

Роскомнадзор выпустил методические рекомендации по исполнению приказа №996 "Об утверждении требований и методов по обезличиванию персональных данных". Затем правда, документ с сайта удалили, но благодаря Алексею Лукацкому он сохранился здесь. Внесу и я свои 5 копеек в обсуждение обезличивания ПДн. 

A long time ago in a galaxy far, far away....

Случилось это давным-давно, в параллельной вселенной, на одной прекрасной зеленой планете, в одной не менее прекрасной стране (назовем ее, условно, страна X). У жителей страны X, все было в принципе прекрасно. 

Но жизнь их слегка омрачало то, что они находились в рабстве у коварных племен Опсосов. Было так: племена Опсосов предоставляли жителям страны Х услуги сотовой связи, а взамен нагло требовали с них оплату еловыми шишками. Если жителю казалось, что плата чересчур высока и он пытался уйти от одного Опсоса к другому, то у него отбирали номер мобильного телефона (что неизбежно приводило к социальной изоляции и страданиям). И таким образом бедолага вынужден были платить своему Опсосу веки вечные. И называлось это мобильным рабством. Так они и жили, пока однажды не появились рыцари света и добра, которые решили положить рабству конец. И таки положили конец.
Долго ли, коротко, но Опсосов заставили предоставить абонентам услугу по сохранению номера. Дело оставалось за малым - такую систему создать, которая бы позволила переносить номера и данные жителей страны Х между Опсосами. Да вот только в стране Х программистов не было. Совсем. Так уж получилось. А посему решено было просто воспользоваться последней разработкой соседей с прилегающих территорий, которые быстро изготовили и внедрили нужную чудо-систему.

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

Что же было сделано в данной ситуации? А ничего. Рыцари света и добра провозгласили отмену рабства. Опсосы на страницах СМИ начали публично отпускать рабов на волю (при этом таинственно подмигивая и рекомендуя отложить заявки напопозже). Что было дальше мне неведомо, ибо я проснулся. Проснулся и понял - слава богу, был это только сон, и не было такого на самом деле нигде и никогда. Тем более у нас.

Но мораль все же есть. Большие и важные задачи, оказывается можно решать и без  Надежных_Заклинаний и сертифицированных артефактов.  Правда не всем. И не всегда. Ведь закон — что дышло: куда повернёшь — туда и вышло.

Проект документа ФСТЭК по мерам защиты ГИС - первое впечатление

ФСТЭК выпустил любопытный проект документа под названием «МЕРЫ ЗАЩИТЫ ИНФОРМАЦИИ В ГОСУДАРСТВЕННЫХ ИНФОРМАЦИОННЫХ СИСТЕМАХ».

Первое впечатление – ниже.

Сфера действия

Документ описывает методы реализации организационных и технических мер защиты информации, перечисленных в приказе ФСТЭК № 17.

Видимо документ планируется к применению в информационных системах, защищаемых в соответствии с требованиями приказа ФСТЭК № 17.

Для защиты информации (в том числе персональных данных) в прочих информационных системах данный документ также может применяться.

Документ представляет интерес для технических специалистов операторов, а также для системных интеграторов, работающих в гос. секторе.

Меры защиты

Состав мер защиты в проекте документа идентичен составу мер из 17 приказа ФСТЭК.

Для каждой меры приводятся требования к реализации и требования к усилению.

Требования к реализации описывают то, каким образом реализуется мера в целом. Например, для меры ИАФ.1 (Идентификация и аутентификация пользователей, являющихся сотрудниками оператора) приводится описание того, кто именно подразумевается под «сотрудниками» оператора, а также перечисляются возможные способы аутентификации (пароль, аппаратные средства, биометрия, многофакторная аутентификация).

Требования по усилению дополнительно детализируют содержание меры. Например, требование 1а по усилению ИАФ.1, требует использования аутентификации на основе пароля длиной не менее 6 символов, с алфавитом не менее 30 символов и максимальным количеством неуспешных попыток ввода от 3 до 10. Необходимые "усиления" меры зависят от класса защищенности системы. Например, для системы 3 класса защищенности мера ИАФ.1 обязательна и применяется с "усилением" 1б.

Мера защиты информации	Класс защищенности информационной системы
	4	3	2	1
ИАФ.1	+	+	+	+
Усиление ИАФ.1	1а	1б	1в, 2, 3, 4	1г, 2, 3, 4, 5

Таким образом, из класса защищенности системы вытекает не только набор мер защиты, но еще и способ реализации каждой меры. 

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

Дальше, в лес

Лично у меня после первого прочтения возникло несколько вопросов.

Во-первых, для всех классов защищенности кроме 4-го, запрещен удаленный доступ при помощи учетных записей администраторов для администрирования информационной системы и СЗИ (см. п.3 на стр. 36 в УПД.13).

Как удаленно администрировать, например, сетевое оборудование? Как действовать в случае, когда админу из дома необходимо срочно что-либо настроить?

Во-вторых, в требованиях по защите информации при передаче (см. ЗИС.3 на стр. 119) сказано, что «защита информации обеспечивается путем защиты каналов связи от несанкционированного физического доступа (подключения) к ним и (или) применения в соответствии с законодательством Российской Федерации средств криптографической защиты информации».

Хорошо, что обозначена альтернатива использованию криптографии.

Но, к сожалению, не расписаны возможные меры защиты канала от НСД.

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

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

Получается, что нужно строить для защищаемых систем физически выделенные сегменты сети на отдельном оборудовании? Трактовка данного требования не очевидна.

Что в итоге

Проект документа ФСТЭК мне определенно нравится, особенно на контрасте с последним проектом приказа ФСБ.

Документ вышел достаточно объемным (165 страниц) и производит сильное впечатление. Требования сформулированы понятном для IT-шника языке. Практически нет двусмысленных трактовок. Документ требует вдумчивого и глубокого анализа со стороны специалистов в различных областях. 

ФСТЭК предлагает заинтересованным лицам рассмотреть проект  документа и направить предложения по нему на адрес электронной почты project@fstec.ru. 

Форма для предложений и замечаний есть в конце информационного сообщения ФСТЭК.

Защита персональных данных 2013

На прошлой неделе удалось побывать на конференции «Защита персональных данных 2013», проводимой по инициативе Роскомнадзора. Краткий отчет ниже. 

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

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

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

Далее было время обеда. Правда "обеда" в гастрономическом смысле, к сожалению, не было. Зато из окна Экспоцентра открывался неплохой вид.

После обеда началось собственно то, ради чего я поехал в Москву. Доклады разделились на тематические заседания:

Тематическое заседание №1 "Защита персональных данных: организационные и технологические аспекты"
Тематическое заседание №2 "Перспективы развития законодательства в области персональных данных"

Тематическое заседание №3 "Защищенная среда для электронного бизнеса"

Тематическое заседание №4 "Подготовка кадров в области информационной безопасности"

Первое и второе заседания шли параллельно. Третье и четвертое тоже шли параллельно. 

Я пошел на заседание, посвященное организационным и технологическим аспектам защиты ПДн, где ожидались выступления регуляторов.

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

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

Далее выступал представитель ФСБ с докладом о «вопросах использования криптографических средств защиты информации». Нам рассказали о сфере контроля ФСБ (гос. органы), наиболее частых замечаниях при проверках и о рычагах воздействия на недобросовестных операторов. Ничего принципиально нового из доклада я не извлек. Однако общение после доклада получилось интересным.

Наболевший вопрос о металлических решетках на окнах (см. Проект приказа ФСБ):
- Как нам реализовать данное требование для офисной «стекляшки»?
- А зачем Вы засунули систему 1 уровня защищенности в офисную «стекляшку»?
Что ж, логично :). Системы наивысшего уровня защищенности с актуальными угрозами 1-го и 2-го типов должны встречаться крайне редко и, вероятнее всего, не у коммерческих структур. 

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

Удалось также побывать еще на двух докладах. Доклад представителя Mircosoft, посвященный их внутренней реализации процесса реагирования на инциденты, был крайне интересным и ( субъективно) оказался лучшим докладом на конференции.

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

Подводя итоги.
Считаю, что 20 минут для доклада на серьезную тему - недостаточно.
Иностранный опыт защиты перс. данных? Вопросы обучения специалистов по ИБ? Наверное, эти проблемы просто выше моего уровня. Лучше бы организаторы отказались от первой части (с иностранными гостями), но зато бы поставили все интересные послеобеденные доклады по очереди, а не параллельно. 

Предложения по Проекту приказа ФСБ.

В прошедшие выходные попытался исполнить свой гражданский долг и сформулировал предложения по Проекту приказа ФСБ.

Думаю всем очевидно, что концепция документа уже не изменится и ничего существенного авторы менять не станут. Поэтому я сосредоточился на том, чтобы попытаься внести в Проект хотя бы некоторые маленькие оговорки, которые могли бы облегчить жизнь. Всего получилось не густо - 3 предложения.

Предложение №1

В пункт 9 раздела II внести следующее уточнение:
«При разработке совокупности предположений о возможностях, которые могут использоваться при создании способов, подготовке и проведении атак, необходимо учитывать, что привилегированные пользователи информационной системы (члены группы администраторов), которые назначаются из числа особо доверенных лиц и осуществляют техническое обслуживание криптосредств и СФ, как правило, исключаются из числа потенциальных нарушителей».

Это уточнение необходимо для того, чтобы исключить из числа потенциальных нарушителей хотя бы администраторов СКЗИ. Администраторы СКЗИ вполне могут иметь опыт разработки и анализа СКЗИ (например, высшее образование в области ИБ, опыт работы в организации-лицензиате ФСБ России). Поэтому если мы будем рассматривать их как источник угрозы, то вполне определенно попадаем на СКЗИ КВ1 (см. пункт 13 проекта).

Предложение №2

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

Это уточнение необходимо для того, чтобы исключить из числа потенциальных нарушителей легальных пользователей ИСПДн.

Пользователь ИСПДн естественно в рамках предоставленных ему полномочий имеет санкционированный доступ и к защищаемой информации и к СВТ.

Допустим, на СВТ пользователя реализовано СКЗИ (например, установлен VPN-клиент). Если мы пользователя рассматриваем как потенциального нарушителя, то в соответствии с пунктом 12 требуется СКЗИ класса КС3.  Но есть ли в этом смысл? Если пользователь и так имеет легальный доступ к данным, то как СКЗИ КС3 может ему помешать совершить нарушение?

Кстати, в моих предложениях нет ничего нового. Эти же формулировки уже были в Методических рекомендациях.

Предложение №3

Пункт 6 изложить в следующем виде:
«Для выполнения требования, указанного в подпункте «а» пункта 5 настоящего документа, необходимо обеспечение режима, препятствующего возможности неконтролируемого проникновения или пребывания в Помещениях, где располагаются программно-аппаратные СКЗИ, лиц, не имеющих права доступа в Помещения, которое достигается путем:
а) оснащения Помещений, в которых располагаются программно-аппаратные СКЗИ, входными дверьми с замками, обеспечения постоянного закрытия дверей Помещений на замок и их открытия только для санкционированного прохода, а также опечатывания Помещений по окончании рабочего дня;
б) утверждения правил доступа в Помещения, в которых располагаются программно-аппаратные СКЗИ, сотрудников и посетителей в рабочее и нерабочее время;
в) утверждения перечня сотрудников, имеющих право вскрывать Помещения в нештатных ситуациях, в которых располагаются программно-аппаратные СКЗИ, а также порядка вскрытия Помещений в таких ситуациях.

Пункт 26 изложить в следующем виде:
«Для выполнения требования, указанного в подпункте «а» пункта 5 настоящего документа, для обеспечения 1 уровня защищенности необходимо:
а) оборудовать окна Помещений, в которых располагаются программно-аппаратные СКЗИ, расположенные на первых и (или) последних этажах зданий, а также окна Помещений, в которых располагаются программно-аппаратные СКЗИ, находящиеся около пожарных лестниц и других мест, откуда возможно проникновение в Помещения посторонних лиц, металлическими решетками или ставнями, охранной сигнализацией или другими средствами, препятствующими неконтролируемому проникновению посторонних лиц в помещения;
б) оборудовать окна и двери Помещений, в которых располагаются программно-аппаратные СКЗИ, металлическими решетками, охранной сигнализацией или другими средствами, препятствующими неконтролируемому проникновению посторонних лиц в помещения.

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

В итоге, чтобы не брать на себя выполнение предлагаемых требований по обеспечению безопасности помещений, Операторы могут начать избегать использования СКЗИ даже в тех случаях, когда это действительно необходимо. Результат будет обратный: уровень реальной защищенности снизится.

Поэтому требования по защите более логично предъявлять только к тем помещениям, где находятся СКЗИ.

Далее, в современных условиях компоненты системы (и СКЗИ) могут располагаться не только в контролируемых Оператором помещениях. Компоненты могут располагаться:
- в помещениях, которые относятся к общественным местам;
- на мобильных СВТ, которые часто меняют местоположение;
- на открытом пространстве.

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

А в контролируемых Оператором серверных помещениях установлены, как правило, только программно-аппаратные комплексы. Поэтому и требования по защите лучше предъявлять только к тем помещениям, где располагаются программно-аппаратные СКЗИ.

Проект приказа ФСБ по защите ПДн с использованием средств криптографической защиты

Вчера был опубликован проект приказа ФСБ по защите персональных данных с использованием криптосредств.

Попробую провести краткий анализ этого документа.

Сначала отмечу самые важные, на мой взгляд, моменты:

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


Требования, содержащиеся в приказе, можно разбить на следующие 4 группы:
а) требования по защите помещений;
б) требования по защите носителей персональных данных;
в) требования по регламентации и контролю доступа к ПДн, ведению электронного журнала;
г) требования к классу используемых СКЗИ.

Требования а), б), в) явно зависят от Уровня защищенности (УЗ), определённого согласно ПП 1119.  Эти требования включают в себя, например, оборудование помещений металлическими решетками и сигнализацией (для УЗ 1), поэкземплярный учет и хранение носителей ПДн в сейфах, необходимость ведения электронного журнала сообщений, назначение ответственных лиц... В общем и так далее. Подробнее со всеми требованиями можно ознакомится посмотрев на таблицу в конце поста.

Остановимся отдельно на определении класса СКЗИ.

Определение класса СКЗИ

Класс СКЗИ зависит от двух факторов:
- от предполагаемых возможностей нарушителя;
- от наличия актуальных угроз НДВ (см ПП 1119).

Предполагаемые возможности нарушителей описываются в разделах 10-16 Приказа. В целом, содержание этих разделов во многом идентично предыдущим Методическим рекомендациям.

Выбор класса СКЗИ теперь стал более прозрачным, но это не значит, что жить стало легче.

Обратим внимание на подпункт а) пункта 12: «СКЗИ класса КС3 применяются для нейтрализации атак, при создании способов, подготовке и проведении которых используются возможности из числа перечисленных в пунктах 10 и 11 настоящего документа и не менее одной из следующих дополнительных возможностей:… доступ к СВТ, на которых реализованы СКЗИ и СФ».

Очевидно, что доступ к "СВТ, на которых реализовано СКЗИ", могут иметь пользователи системы, не говоря уже об админах. Исходя из данного пункта получается, что если на компьютере пользователя установлен VPN-клиент и пользователь рассматривается как потенциальный нарушитель, то согласно данным требованиям к VPN-клиенту предъявляются требования КС3.



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

То есть, большинство систем, независимо от УЗ, попадут под использование КС3 как минимум.

Но это еще не все...

Для уровней защищенности с 3 по 1, заявлена привязка требуемого класса СКЗИ к наличию актуальных угроз НДВ:

Для УЗ 3 требуются:
- СКЗИ класса КВ2 и выше в случаях, когда для информационной системы актуальны угрозы 2 типа;
- СКЗИ класса КС1 и выше в случаях, когда для информационной системы актуальны угрозы 3 типа.

Для УЗ 2 требуются:
- СКЗИ класса КВ2 и выше в случаях, когда для информационной системы актуальны угрозы 1 и 2 типа;
- СКЗИ класса КС1 и выше в случаях, когда для информационной системы актуальны угрозы 3 типа.

Для УЗ 1 требуются:
- СКЗИ класса КА1 в случаях, когда для информационной системы актуальны угрозы 1 типа;
- СКЗИ класса КВ2 и выше в случаях, когда для информационной системы актуальны угрозы 2 типа.

Если мы признаем актуальными угрозы 1 и 2 типа (угрозы наличия НДВ ), то попадем на СКЗИ класса КВ.

Напомню, что может ожидать счастливых обладателей СКЗИ КВ:
- необходимость заказывать у ФСБ ключевые блокноты (компакт-диски), требуемые для работы СКЗИ. Срок изготовление ключей – пол года. Срок жизни набора ключей – год J;
- невозможность удаленного администрирования СКЗИ. Да, кстати, ключевые блокноты также можно развертывать только локально;
- при подключении СКЗИ - использование «оптической развязки» - «медь-оптика-медь» (для защиты от наводок).

Вывод: если в финальном релизе Приказа ничего не изменится, то, возможно, всем придется запасаться СКЗИ класса КС3. Ну или вообще избегать использования криптографии (что маловероятно).

В заключение, обещанная таблица с требованиями

17 приказ ФСТЭК. Часть 2 – FW, IDS, VPN

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

Сразу оговорюсь, что моя трактовка перечисленных мер совершенно не претендует на единственно верную. Это лишь предположения, основанные на личном опыте и на изучении NIST 800-53 «Security and Privacy Controls for Federal Information Systems and Organizations», из которого, судя по всему, черпали вдохновение разработчики 17 приказа.

Требования 17 приказа можно условно разделить на те, которые целесообразнее закрыть программно-техническими средствами и те, которые можно закрыть организационными  мерами.

В составе гипотетической проектируемой системы защиты выделим следующие программно-технические комплексы:

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

К организационным мерам отнесем разработку документов (далее цитата из приказа) «определяющих правила и процедуры, реализуемые оператором для обеспечения защиты информации в информационной системе в ходе ее эксплуатации (далее – организационно-распорядительные документы по защите информации)». То есть это политики, процедуры, регламенты и т. п. документация

Далее посмотрим, каким образом перечисленные выше комплексы будут реализовывать меры предложенные в 17 приказе. В этой части речь пойдет о межсетевом экранировании, обнаружении вторжений и защите каналов связи. Для удобства, описание представлено в виде таблиц.

Комплекс межсетевого экранирования

Условное обозначение	Наименование меры	Метод реализации
ЗИС.17	Разбиение информационной системы на сегменты (сегментирование информационной системы) и обеспечение защиты периметров сегментов информационной системы	Сегментируем сеть на VLAN’ы и терминируем их на межсетевом экране. Серверы каждой из систем, содержащей конфидент, желательно «посадить» в свой собственный VLAN. Отдельный VLAN(ы) используем для рабочих станций пользователей. Обратим внимание, что про физическое разделение сегментов ничего не сказано.
УПД.3	Управление (фильтрация, маршрутизация, контроль соединений, однонаправленная передача и иные способы управления) информационными потоками между устройствами, сегментами информационной системы, а также между информационными системами
ЗИС.23	Защита периметра (физических и (или) логических границ) информационной системы при ее взаимодействии с иными информационными системами и информационно-телекоммуникационными сетями	Эта мера может реализовываться тем же межсетевым экраном, который отвечает за сегментацию систем (см. предыдущий пункт). Однако часто на периметре сети, в точке ее подключения к сетям связи общего пользования (ССОП) используется отдельный МЭ. Ниже будет сказано о преимуществах такой схемы.
УПД.16	Управление взаимодействием с информационными системами сторонних организаций (внешние информационные системы)
ОЦЛ.4	Обнаружение и реагирование на поступление в информационную систему незапрашиваемых электронных сообщений (писем, документов) и иной информации, не относящихся к функционированию информационной системы (защита от спама)	Сейчас на рынке присутствуют межсетевые экраны со встроенной функцией защиты от спама, что позволяет закрыть данное требование в рамках комплекса МЭ.
ЗИС.22	Защита информационной системы от угроз безопасности информации, направленных на отказ в обслуживании информационной систем	Возвращаемся к преимуществам схемы с двумя межсетевыми экранами. Как отдельный МЭ на периметре сети может помочь в защите от DOS? Естественно при помощи него можно попытаться отфильтровать нежелательный трафик. Во-вторых, в том случае если периметровый МЭ заDOSят, то корпоративные системы, обслуживаемые «внутренним» МЭ продолжат работу и будут доступны для внутренних пользователей из ЛВС.  В качестве альтернативы использованию МЭ можно рассмотреть сервисы защиты от DOS-атак.
ЗСВ.4	Управление (фильтрация, маршрутизация, контроль соединения, однонаправленная передача) потоками информации между компонентами виртуальной инфраструктуры, а также по периметру виртуальной инфраструктуры	Как минимум, речь о том, чтобы распределить виртуальные машины, как и физические серверы, по разным VLAN’ам и разграничивать доступ между ними посредством межсетевого экрана. Однако, можно посмотреть на данное требование более широко и попытаться реализовать фильтрацию на уровне гипервизора. В частности, к таким решениям относятся vShield и Cisco VSG.
ЗСВ.10	Разбиение виртуальной инфраструктуры на сегменты (сегментирование виртуальной инфраструктуры) для обработки информации отдельным пользователем и (или) группой пользователей

На рынке достаточно решений, обеспечивающих выполнения всех требуемых функций. К сожалению, отечественные решения пока отстают по потребительским характеристикам от западных продуктов. Такие решения, как правило, построены на базе криптошлюзов, а сертификат МЭ прилагается скорее как «бонус». Поэтому в качестве МЭ целесообразно рассмотреть сертифицированные продукты западных вендоров.

Комплекс обнаружения вторжений

Здесь все достаточно просто. Закрывает требования СОВ.1 и СОВ.2. Обратим внимание на слово «обнаружение». Как я понимаю, ставить IDS в разрыв («inline») не требуется. В целях экономии можно зеркалировать на IDS только трафик сегментов с защищаемыми системами. Помним о сертификации.

Комплекс защиты каналов связи

Может закрыть ЗИС.3, УПД.13, ИАФ.6. Для защиты каналов связи используется технология VPN. В зависимости от архитектуры защищаемых систем, архитектура VPN может быть как «site2site» так и «remote access».

Условное обозначение	Наименование меры	Метод реализации
ЗИС.3	Обеспечение защиты информации от раскрытия, модификации и навязывания (ввода ложной информации) при ее передаче (подготовке к передаче) по каналам связи, имеющим выход за пределы контролируемой зоны, в том числе беспроводным каналам связи	Здесь вся соль в понятии «контролируемой зоны». Контролируемая зона – пространство, в пределах которого осуществляется контроль за пребыванием и действиями лиц и (или) транспортных средств. Что подразумевает собой как минимум доступ по пропускам, видеонаблюдение, защищаемые серверные и кроссовые помещения. Если канал связи (например, ЛВС объекта) проходит в пределах контролируемой зоны, то шифрование не требуется. Действительно, избыточно шифровать данные, передаваемые между разными стойками внутри ЦОДа. Для таких объектов, достаточно поставить на границе ЛВС VPN-шлюз и шифровать трафик, передаваемый вовне (за пределы охраняемой зоны). Если же у нас нет уверенности, что каналы связи проходят по контролируемой территории (то есть имеется возможность подключиться к каналу связи и снять передаваемую информацию), то следует шифровать трафик, начиная с рабочей станции пользователя (ставить VPN-клиент).
УПД.13	Реализация защищенного удаленного доступа субъектов доступа к объектам доступа через внешние информационно-телекоммуникационные сети	Для организации удаленного доступа пользователей используется remote access VPN.
ИАФ.6	Идентификация и аутентификация пользователей, не являющихся работниками оператора (внешних пользователей)	Если внешние пользователи «ходят» через VPN, то таким образом решается технический вопрос с их идентификацией и аутентификацией. С организационной точки зрения, предоставление удаленного доступа внешним пользователям должно надлежащим образом регламентироваться.

Кратко скажем о сертификации. Дело в том, что VPN-решения используют шифрование и соответственно являются криптосредствами. Криптография находится в ведении ФСБ и проходит по отдельной системе сертификации. Западные VPN-решения, даже при использовании отечественного криптоядра, сертификата ФСБ на криптосредства не имеют. Поэтому здесь, в отличии от комплекса межсетевого экранирования, мы практически ограничены в выборе отечественными решениями (S-Terra, Континент, ViPNet и др.). Этот набор слегка разбавляет Stonesoft. Тема сертификации и выбора криптосредств обширна и достойна отдельной статьи.

В следующей части продолжим разбор требований 17 приказа.