Определение уровня защищенности персональных данных. Акт определения уровня защищенности пдн при их обработке в испдн

15 мая 2013 года Минюст наконец-то зарегистрировал приказ ФСТЭК № 21 от 18 февраля 2013 «Об утверждении Состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных».

Почему же «долгожданный»? Да потому, что с момента выхода постановления Правительства РФ № 1119 (1 ноября 2012 года) любые вопросы по технической защите персональных данных оказались в неопределенно-подвешенном состоянии. Получилось так: новым постановлением отменены старые классы информационных систем персональных данных (ИСПДн) и введено понятие «Уровни защищенности ИСПДн», но как и чем защищаться в каждом конкретном случае как раз и должен был нам рассказать новый приказ ФСТЭК, который мы ждали «каких-то» полгода.

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

В этой статье я постараюсь простым языком проанализировать новый документ ФСТЭК России, взвесить его плюсы и минусы, а также постараться ответить на вопрос «что же теперь делать операторам персональных данных?».

Что из себя представляет документ в целом

В целом, это действительно шаг вперед в плане законотворчества в сфере защиты персональных данных. Наконец-то в списке мер мы увидели упоминание мобильных устройств и средств виртуализации, чего раньше законодатели тщательно старались избегать. Наконец-то нет обязаловки как в прошлом приказе: «Если у тебя ИСПДн 1 класса, тебе нужно потратить n денег на средства защиты информации, если 2 класса, то n-m денег, а если 3 класса, то n-m-k денег.».

Сейчас ситуация такая: у нас есть 15 групп различных технических и организационных мер, в каждой группе от 2 до 20 различных мер, напротив каждой меры отмечено, является ли эта мера базовой (я буду их называть далее условно обязательными) для определенного уровня защищенности (если стоит плюс, то мера базовая, если нет - компенсирующая). Тут нужно заметить, что в перечне есть немало мер, которые могут быть только компенсирующими, то есть не отмечены плюсом ни для одного из четырех уровней защищенности.

Оператор персональных данных действует по следующему алгоритму:
- определяет уровень защищенности своей ИСПДн согласно ПП 1119;
- выбирает все меры, которые отмечены плюсом для выбранного уровня защищенности (базовые меры);
- убирает из полученного списка меры, которые связаны с технологиями, не используемыми в ИСПДн (например, убираем меры для защиты виртуальной инфраструктуры, если средства виртуализации не используются);
- смотрит на полученный список мер и сравнивает с актуальными угрозами в модели угроз, если выбранными мерами нейтрализуются не все актуальные угрозы, добавляет в список компенсирующие меры, необходимые для нейтрализации всех оставшихся угроз;
- добавляет к полученному списку меры, определенные в других нормативных актах (например в ПП № 1119 есть небольшое количестве мер, а также есть общие требования в ФЗ-152), после чего получает итоговый список мер, которые нужно выполнить;
- выполняет меры из окончательного списка…

Вроде бы все просто: определяем уровень защищенности, рисуем модель угроз, выбираем и уточняем меры из нового приказа ФСТЭК, выполняем эти меры и у нас комар носа не подточит. Но…

Ложка дегтя

Собственно здесь начинается критика как нового документа, так и остального законодательства в целом.

Проблемы у 21 приказа ФСТЭК в целом такие же как и у многих других законодательных документов - использование размытых формулировок, возможность двоякого толкования текста, отсутствие пояснений там, где они жизненно необходимы.

Понять как тщательно готовился документ и сколько раз его перечитывали и редактировали за эти полгода можно уже по тому факту, что после четвертого пункта в приказе сразу идет шестой… Ну ладно, это придирки, а что есть по существу?

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

Едем дальше. Пункт 3 говорит нам о том, что меры по обеспечению безопасности ПДн должны быть направлены на нейтрализацию актуальных угроз безопасности. С другой стороны ФЗ-152 говорит нам о том, что организационные и технические меры применяются для выполнения требований по защите ПДн. Так все-таки, есть у нас свобода или очередная обязаловка? Опять необходимо разъяснение.

Далее. Шестой пункт гласит о том, что раз в 3 года оператор самостоятельно или с привлечением сторонних организаций должен проводить оценку эффективности реализованных мер защиты ПДн. Тут получилось как с оценкой вреда субъекту персональных данных в 152-ФЗ. Получается, что оценку провести нужно, а какой-либо методики проведения такой оценки нет. А может быть оценка эффективности является заменой аттестации информационной системы? Тогда почему оператор может проводить ее самостоятельно, не имея лицензии на ТЗКИ?

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

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

То есть вот как, просто сказать проверяющему «Мы тут с мужиками прикинули и решили, что внедрять сертифицированные СЗИ это слишком дорого и поставили бесплатный китайский антивирус» не получится. Нужно показывать какие-то бумажки, обосновывающие применение иных мер, а не базовых. Как обосновать? Мне пока на ум приходит только проведение процедуры анализа рисков по ISO 27001, что, в случае найма для этих целей сторонней организации, само по себе может влететь в копеечку. К тому же, еще не факт, что анализ рисков покажет, что внедрять сертифицированные СЗИ экономически нецелесообразно…

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

В то же время, первая же мера, условно обязательная для всех уровней защищенности, звучит так: «Идентификация и аутентификация пользователей, являющихся работниками оператора». Понятно, что эта мера может быть реализована и штатными средствами любой ОС. И вроде как четвертый пункт не обязывает применять тот же Secret Net или Dallas Lock, но где гарантия, что не придет проверяющий и не скажет «Вы все не так поняли, тут должно стоять сертифицированное СЗИ, вот вам предписание»? Кто и как определяет - для нейтрализации конкретной угрозы необходимо ли сертифицированное СЗИ или можно обойтись без него? Почему нельзя написать прямым текстом, что применение сертифицированных СЗИ не обязательно, или обязательно в каких-то конкретных случаях?

Ну и формулировка самих мер иногда очень интересна. Вот например условно-обязательная мера защиты сред виртуализации для уровней защищенности от третьего и выше:
«Разбиение виртуальной инфраструктуры на сегменты для обработки персональных данных отдельным пользователем и/или группой пользователей».

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

Я очень надеюсь, что когда-нибудь представители ФСТЭК все же дадут официальные разъяснения по поводу спорных вопросов.

Вместо резюме

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

Что же делать операторам сейчас?

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

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

Постановление правительства № 1119 от 01.11.2012 "Требования к защите персональных данных при их обработке в информационных системах персональных данных" устанавливает 4 уровня защищенности персональных данных, которые определяются видом ИСПДн, типом актуальных угроз и количеством субъектов ПДн, обрабатываемых в информационной системе (см. таблица 1).

Таблица 1

Виды ИСПДн

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

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

ИСПДн-О – ИСПДн обрабатывающая общедоступные Пдн.

ИСПДн-И – ИСПДн обрабатывающая иные категории ПДн

В этом же Постановлении установлено три типа угроз Пдн:

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

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

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

Определение типа угроз безопасности, актуальных для информационной системы, производится оператором ПДн с учетом оценки возможного вреда, который может быть причинен субъектам персональных данных. От типа угрозы будет зависеть не только требуемый уровень защищенности ИСПДн, но и класс используемых для ее защиты СЗИ, и прежде всего, обязательное прохождение СЗИ контроля отсутствия недекларированных возможностей (НДВ).

Под которым понимаются, дополнительные требования ФСТЭК России к проверке программных и программно-аппаратных продуктов, реализующих функции защиты информации на отсутствие умышленных или иных недекларированных возможностей. На практике это исследование исходного текста программ на предмет отсутствия в нем "программных закладок", "троянских коней" и других вредоносных кодов. До недавнего времени данные требования предъявлялись лишь к СЗИ, используемых в системах защиты автоматизированных систем, обрабатывающих государственную тайну. С выходом документов ФСТЭК по защите персональных данных указанные требования распространяются и на СЗИ, применяемые в ИСПДн 1 и 2 уровня защиты. Руководящий документ "Защита от несанкционированного доступа к информации. Часть 1. Программное обеспечение средств защиты информации. Классификация по уровню контроля отсутствия недекларированных возможностей" (РД НДВ) устанавливает четыре уровня контроля отсутствия недекларированных возможностей. Каждый уровень характеризуется определенной минимальной совокупностью требований. Для ПО, используемого при защите информации, отнесенной к государственной тайне, должен быть обеспечен уровень контроля не ниже третьего. Для защиты ПДн и государственных информационных систем, не обрабатывающих государственную тайну, достаточно четвертого уровня контроля.

В предыдущих документах ФСТЭК жестко определял, что для ИСПДн первого класса (К1) необходимы СЗИ прошедшие контроль НДВ. В действующих сегодня требованиях оператор сам вправе определять тип угроз, а соответственно определять – существует угроза НДВ или нет.

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

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

УК РФ

Документ проанализирован в 1 вопросе.

Под уровнем исходной защищенности информационной системы персональных данных (ИСПДн) понимается обобщенный показатель, зависящий от технических и эксплуатационных характеристик ИСПДн, а именно:

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

Определяется уровень исходной защищенности ИСПДн (Y₁) в соответствии с Методикой определения актуальных угроз безопасности персональных данных при их обработке в информационных системах персональных данных, утвержденных ФСТЭК России в 2008 году. Уровень исходной защищенности ИСПДн (Y₁) применяется для оценки возможности реализации угроз безопасности персональных данных и .

ФСТЭК России выделило 3 (три) уровня исходной защищенности ИСПДн (Y₁):

• высокий;
• средний;
• низкий.

Таблица 1. Показатель исходного уровня защищенности ИСПДн

Правила определения исходного уровня защищенности ИСПДн

Исходная уровень защищенности ИСПДн определяется следующим образом.

1. ИСПДн имеет высокий уровень исходной защищенности, если не менее 70% характеристик ИСПДн соответствуют уровню «высокий» (суммируются положительные решения по первому столбцу, соответствующему высокому уровню защищенности), а остальные – среднему уровню защищенности (положительные решения по второму столбцу).

Таблица 2. Условия определения высокого уровня исходной защищенности

2. ИСПДн имеет средний уровень исходной защищенности, если не выполняются условия по пункту 1 и не менее 70% характеристик ИСПДн соответствуют уровню не ниже «средний» (берется отношение суммы положительные решений по второму столбцу, соответствующему среднему уровню защищенности, к общему количеству решений), а остальные – низкому уровню защищенности.

Таблица 3. Условия определения среднего уровня исходной защищенности

3. ИСПДн имеет низкую степень исходной защищенности, если не выполняются условия по пунктам 1 и 2.

Таблица 4. Условия определения низкого уровня исходной защищенности

При составлении перечня актуальных угроз безопасности персональных данных каждой степени исходного уровня защищенности ИСПДн ставится в соответствие числовой коэффициент Y₁, а именно:

• 0 – для высокой степени исходной защищенности;
• 5 – для средней степени исходной защищенности;
• 10 – для низкой степени исходной защищенности.

Пример определения уровня исходной защищенности ИСПДн

Таблица 5. Исходная степень защищенности автоматизированного рабочего места пользователя

Итак, начнем с самого начала. Попробуем понять откуда «растут ноги»?

26 января 2007 г. вступил в силу Федеральный закон № 152-ФЗ «О персональных данных», который определил необходимость защиты персональных данных субъектов (далее ПДн) в целях зашиты прав и свобод человека и гражданина. За невыполнение требований данного закона предусмотрена административная и уголовная ответственность как для юридических, так и физических лиц (сотрудников и руководителей организаций), а деятельность самой организации может быть приостановлена по требованию Роскомнадзора. Таким образом, операторы информационных систем персональных данных (далее ИСПДн) обязаны защищать переданные им ПДн от угроз, реализация которых может повлечь за собой ущерб владельцам этих данных.

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

1.2. СЭД и ПДн: есть ли взаимосвязь?

Имеет СЭД отношение к проблеме обеспечения защиты ПДн?

Ответ – да. Если СЭД содержит в своем составе справочники сотрудников предприятия и контрагентов, и эти данные хранятся в системе таким образом, что может быть определен конкретный субъект, это означает, что она содержит ПДн. Плюс в СЭД также могут храниться и обрабатываться различные анкеты, характеристики, персональные дела, истории болезней и т.д. – а эти документы в том числе относятся к определенной категории ПДн. Ситуация «усугубляется», если компания ориентирована на работу с физическими лицами и СЭД вовлечена в сферу их обслуживания. Это касается органов государственной власти, где ведется непосредственная работа с населением; медицинские и образовательные учреждения; телекоммуникационные компании; кредитные организации и т.д. – операторы ПДн.

Отметим, что в законе прямо не указываются какими конкретными средствами и методами обеспечения безопасности ПДн должен пользоваться оператор. До 1 июля 2011 года мы руководствовались постановлениями правительства РФ за номерами 781, 512 и 687, так называемых "приказом Трех" и приказом ФСТЭК № 58. После чего был принят 261-ФЗ и "Старая" часть 3 ст. 19 "растеклась" по нескольким частям нового закона, изменившись до неузнаваемости.

Вот мы с вами впервые столкнулись с термином «Уровень защищенности ПДн». Что это и с чем его «едят»?

1.3. Определение уровня защищенности ПДн

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

● 1 группа - специальные категории ПДн , к которым относятся информация о национальной и расовой принадлежности субъекта, о религиозных, философских либо политических убеждениях, информацию о здоровье и интимной жизни субъекта;

● 2 группа - биометрические ПДн , то есть данные, характеризующие биологические или физиологические особенности субъекта, например фотография или отпечатки пальцев;

● 3 группа - общедоступные ПДн , то есть сведения о субъекте, полный и неограниченный доступ к которым предоставлен самим субъектом;

● 4 группа - иные категории ПДн , не представленные в трех предыдущих группах.

По форме отношений между вашей организацией и субъектами обработка подразделяется на 2 вида:

● обработка персональных данных работников (субъектов, с которыми ваша организация связана трудовыми отношениями);

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

По количеству субъектов, ПДн которых обрабатываются, нормативным актом определены лишь 2 категории:

● менее 100 000 субъектов;

● более 100 000 субъектов;

И наконец, типы актуальных угроз:

● угрозы 1-го типа связанны с наличием недекларированных (недокументированных) возможностей в системном ПО, используемом в ИСПДн;

● угрозы 2-го типа связанны с наличием недекларированных возможностей в прикладном ПО, используемом в ИСПДн;

● угрозы 3-го типа не связаны с наличием недекларированных возможностей в программном обеспечении, используемом в ИСПДн.

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

Установив исходные данные, для конкретной ИСПДн определяется уровень защищенности ПДн в соответствии со следующей таблицей:

Таблица 1. Определение уровня защищенности ПДн

1.4. Сертифицированный продукт: нужен или нет.

Подведем итоги в рамках первой части нашего исследования.

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

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

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

2. Виды работ. Перечень ИСПДн

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

2.1. Перечень требований к ИСПДн

Прежде всего давайте разберемся, какие требования должны соблюдаться?

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

Таблица 2. Перечень требований, предъявляемый к ИСПДн

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

Если Заказчик предполагает, что все ПДн и конфиденциальная информация будет присутствовать только в СЭД, то безусловно, потребуется установка именно сертифицированного продукта. А если у Заказчика предполагается построение целого контура, где в том числе будет интегрирована СЭД, тогда нужна сертификация не на СЭД, а на сами средства защиты, которые будут защищать выделенный контур.

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

2.2. Проекты ИСПДн. Виды работ

Виды работ по ИСПДн можно выделить следующие:

Таблица 3. Возможные виды работ по ИСПДн

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

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

Стадии проектирования СЗПДн можно разделить на следующие 5 этапов, которые рассмотрим подробнее:

Таблица 4. Этапы проектирование СЗПДн

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

(4,88 - оценили 8 чел.)

В данном посте хотелось бы осветить такой документ, как Акт определения уровня защищенности ПДн при их обработке в ИСПДн . Это, если можно так сказать, перерождение Акта классификации ИСПДн . Основной камень преткновения, который я встретил, это не совсем понятная картина в том, что является законодательным инструментом в написании данного акта. Дело в том, что ранее этот акт классификации ИСПДн писался на основании приказа ФСТЭК России, ФСБ России, Мининформсвязи России от 13 февраля 2008 г. № 55/86/20 «Об утверждении порядка проведения классификации информационных систем персональных данных», который и утверждает порядок классификации. Но издан этот приказ в соответствии с пунктом 6 Постановления Правительства №781 от 17 ноября 2007 г., которое утратило силу в связи с выходом Постановления Правительства № 1119 от 1 ноября 2012. Таким образом, приказ действующий, а вышестоящий документ – нет. В свою очередь в ПП 1119 нет привязки к категории ИСПДн, однако есть привязка к уровню защищенности персональных данных, который должен быть обеспечен при их обработке в ИСПДн.

Итак начать нужно с названия документа: «Акт определения уровня защищенности персональных данных при их обработке в информационной системе персональных данных «**********» Его я подсмотрел у Андрея Прозорова и оно меня целиком и полностью устроило. Надо отметить, что Андрей и по акту помог некоторыми комментариями, за что ему отдельное «Спасибо!» («Спасибо» лишним не бывает, Андрей улыбается;)).

Определяем состав комиссии. У меня в документе это реализовано таблицей, однако можно и текстом. Как говорится, на вкус и цвет все фломастеры разные.

После пишем, на основании какого документа мы определяем, какой уровень защищенности нам необходимо обеспечить. Естественно, это ПП 1119. Однако есть мнение, что т.к. приказ №55/86/20 еще не утратил силу, то указать желательно и его. Привычка регулятора может сыграть злую шутку. У меня текст следующий:

«Комиссия, рассмотрев исходные данные информационной системы персональных данных (ИСПДн) «********»в соответствии с Постановлением Правительства Российской Федерации №1119 от 1 ноября 2012 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных» и учетом приказа ФСТЭК России, ФСБ России, Мининформсвязи России от 13 февраля 2008 г. № 55/86/20 «Об утверждении порядка проведения классификации информационных систем персональных данных», определила:»

1. Категории персональных данных, обрабатываемых в информационной системе . Здесь, согласно ПП 1119 у нас есть 4 варианта: иные, общедоступные, биометрические, специальные. Также рекомендую по тексту расписать, что подразумевается под каждой категорией ПДн.
2. Объём обрабатываемых персональных данных . Здесь все просто, либо менее 100 000, либо более 100 000.
3. Угрозы, актуальные для информационной системы . Опять таки, типы угроз расписаны в ПП 1119. И также по тексту описываем, какие угрозы к какому типу относятся. Желательно описать, почему именно этот тип угроз, либо сослаться на модель угроз.
4. Тип субъектов персональных данных, обрабатываемых в информационной системе . Тоже все просто. Это либо только сотрудники оператора, либо нет. Также лучше пояснить, что значит «сотрудники оператора». Вам не сложно, а у регулятора меньше поводов зацепиться.
5. К специальной или типовой относится ИСПДН . Здесь также лучше расписать, по каким критериям происходит отнесение. Только это уже берется не из ПП 1119, а из «трехглавого» приказа №55/86/20.
6. Структуру ИСПДн (автономная, локальная, распределенная)
7. Имеются ли подключения ИСПДн к сетям общего пользования
8. Режим обработки ПДн в ИСПДн (однопользовательский или многопользовательский)
9. Имеется ли разграничение доступа
10. Территориальное расположение ИСПДн (Целиком в пределах РФ или нет)