Сфера государственного IT нередко становится предметом для шуток и критики. Однако нельзя отрицать, что за последние годы работа по развитию информационного общества и в частности работа по повышению доступности государственных электронных услуг принесла результаты.
В РФ созданы следующие элементы системы электронного правительства:
2008 г. – сеть многофункциональных центров предоставления услуг (МФЦ);
2009 г. – единый портал предоставления государственных и муниципальных услуг (ЕПГУ), региональных порталов и порталов муниципалитетов (ЕПГУ), связанных с системой межведомственного электронного взаимодействия (СМЭВ);
2011 г. – система открытого правительства;
2013 г. – интегрированное правительство (МФЦ + ЕПГУ + СМЭВ).
Государственные органы заинтересованы в высококвалифицированных кадрах, снижении рисков и затрат, объединении усилий с частным сектором в предоставлении услуг. Возможно, вы IT-специалист, задумывающийся о работе в Департаменте информационных технологий своего города, или сотрудник IT-компании с частной формой собственности, которая хотела бы оказывать свои услуги государственным организациям. Что нужно знать и к чему быть готовым для такой работы?
Мы, со своей стороны, предлагаем облачную инфраструктуру для размещения в них государственных информационных систем и имеем опыт реализации таких проектов.
Наиболее актуальным для государственных заказчиков является вопрос соответствия требованиям законодательства. Целью этой статьи является повышение осведомленности специалистов в вопросах работы в сфере государственного IT. Эта статья посвящена одному из основных нормативных правовых актов в сфере обеспечения безопасности информации в Государственных и Муниципальных Информационных Системах — 17-ому приказу ФСТЭК.
Во время принятия, во время внесения изменений в Приказ от 11 февраля 2013 г. N 17 «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах» было сломано немало копий.
Напомню, последняя версия данного приказа сейчас в редакции от 15 февраля 2017 г. Но будем справедливы, большинство претензий относились к Приложению №2 данного приказа, а именно к составу мер защиты. Изначальные вопросы о применении мер были сняты после выхода методического документа от 11 февраля 2014 г. «Меры защиты информации в государственных информационных системах», который ответил «как» реализовывать требования Приказа.
Нам же хотелось бы рассмотреть основные постулаты 17-го приказа, не переходя к вариантам реализации и применения конкретных мер защиты.
Итак, приступим к теоретическому созданию нашей информационной системы, учитывая требования приказа №17.
Здесь сразу следует заметить, что
«В документе не рассматриваются требования о защите информации, связанные с применением криптографических методов защиты информации и шифровальных (криптографических) средств защиты информации».Вот и мы криптографию рассматривать не будем.
Для простоты восприятия, рекомендую пример утечки из статьи «И так сойдёт… или как данные 14 миллионов россиян оказались у меня в руках». Воспринимать «сухие» нормы законодательства будет гораздо легче, если думать о чем-то более конкретном. Посмотрим, чем нам поможет приказ №17 в данной ситуации.
Опуская несущественные и банальные части Приказа, переходим к его второму разделу, а именно к пункту номер 9. Начинаем создание защиты с назначения «виноватых»:
«Для обеспечения защиты информации, содержащейся в информационной системе, оператором назначается структурное подразделение или должностное лицо (работник), ответственные за защиту информации»Кто-то же должен принимать решения и нести ответственность за различные ляпы разработки, приводящие к утечкам. Приказ так же уточняет, что данное ответственное лицо должно принимать участие во всех этапах жизненного цикла информационной системы, что в общем-то вполне логично. Процитируем пункт 12.
«Защита информации, содержащейся в информационной системе, является составной частью работ по созданию и эксплуатации информационной системы и обеспечивается на всех стадиях (этапах) ее создания, в ходе эксплуатации и вывода из эксплуатации…»Мероприятия по защите сводятся к следующим пунктам:
- формирование требований к защите информации, содержащейся в информационной системе;
- разработка системы защиты информации информационной системы;
- внедрение системы защиты информации информационной системы;
- аттестация информационной системы по требованиям защиты информации (далее — аттестация информационной системы) и ввод ее в действие;
- обеспечение защиты информации в ходе эксплуатации аттестованной информационной системы;
- обеспечение защиты информации при выводе из эксплуатации аттестованной информационной системы или после принятия решения об окончании обработки информации.
Формирование требований
Данный этап, впрочем, как и остальные этапы, делятся на несколько подэтапов, но попробуем все это изложить более лаконично.
Формирование требований начинается с принятия решения о том, что нашу информационную систему необходимо защищать. После того как мы приняли такое решение, мы должны провести классификацию данной системы, а для этого понять цель создания системы, обследовать обрабатываемую информацию в ИС, а так же понять, под действие каких нормативно-правовых актов подпадает наша информационная система.
Кроме того, что ИС является государственной и подпадает под действие 17-го приказа, она так же может являться информационной системой общего пользования, а значит, на нее распространяется и действие иных НПА. В частности, наверно уже всеми забытый Приказ ФСБ РФ N 416, ФСТЭК РФ N 489 от 31.08.2010 «Об утверждении Требований о защите информации, содержащейся в информационных системах общего пользования».
Нормы данного приказа в данной статье мы опустим. Но хотелось бы заметить, что сведение требований различных документов к единому знаменателю, иногда чуть ли не противоречащих друг другу – это отдельная тема при работе с нашим законодательством.
Выяснив все вышеперечисленное, нам необходимо классифицировать нашу ИС и перейти к моделированию угроз. В актуальной редакции Приказа осталось три класса ГИС из четырех в первой его редакции, но нам это никак не помешает. Классификация довольно хорошо описана и с этим трудностей возникнуть не должно. На что следует обратить внимание, так это на следующий текст:
«Класс защищенности определяется для информационной системы в целом и, при необходимости, для ее отдельных сегментов»Таким образом, мы можем разбить нашу информационную систему на составные части и классифицировать каждую из них по отдельности. Например, отдельно классифицировать сервера информационной системы и ее рабочие места.
В дальнейшем, соответственно, к каждому из сегментов будет применяться свой набор мер защиты, что весьма удобно. Так же необходимо помнить, что класс ГИС величина не постоянная и может меняться в зависимости от обстоятельств (изменение масштаба ИС, значимости обрабатываемой информации и т.п.).
Моделирование угроз, сама по себе тема довольно обширная, поэтому здесь ограничимся упоминанием данного этапа. Для подробного его рассмотрения целесообразно направить вас к нашей предыдущей статье «О моделировании угроз».
Непосредственно требования к системе защиты определяются в зависимости от класса защищенности информационной системы и угроз безопасности информации, которые мы определили на предыдущих этапах. Данные требования включаются в ТЗ на создание системы защиты.
Как нам говорит Приказ, они должны включать в себя следующее:
- цель и задачи обеспечения защиты информации в информационной системе;
- класс защищенности информационной системы;
- перечень нормативных правовых актов, методических документов и национальных стандартов, которым должна соответствовать информационная система;
- перечень объектов защиты информационной системы;
- требования к мерам и средствам защиты информации, применяемым в информационной системе;
- стадии (этапы работ) создания системы защиты информационной системы;
- требования к поставляемым техническим средствам, программному обеспечению, средствам защиты информации;
- функции заказчика и оператора по обеспечению защиты информации в информационной системе;
- требования к защите средств и систем, обеспечивающих функционирование информационной системы (обеспечивающей инфраструктуре);
- требования к защите информации при информационном взаимодействии с иными информационными системами и информационно-телекоммуникационными сетями, в том числе с информационными системами уполномоченного лица, а также при применении вычислительных ресурсов (мощностей), предоставляемых уполномоченным лицом для обработки информации.
Как видите, в данных пунктах перечислено все то, что мы должны были определить на предыдущих этапах. Так что, если ранее мы прошли все пункты добросовестно, то проблем с наполнением ТЗ возникнуть не должно.
Разработка системы защиты информации
Система защиты разрабатывается в соответствии с ТЗ сформированным ранее. Разработка включает в себя три больших этапа:
- непосредственно проектирование;
- разработка эксплуатационной документации;
- макетирование и тестирование.
Как видите, три довольно продолжительных по времени и трудозатратам этапа. Этап разработки на самом деле очень важен и позволяет избежать большинства возникающих проблем на последующих этапах.
К сожалению, многие не уделяют должного внимания данному этапу, и подталкивает их к этому множество факторов. Так уж построена работа в огромном количестве контор средней руки. Серьезное выполнение всех трех пунктов характерно в основном только для крупных организаций и проектов. А потому не удивляют утечки из систем, при разработке которых данные этапы были проигнорированы или выполнены «спустя рукава». Немного поясню, как это происходит при таком подходе.
Когда мы говорим о государственных информационных системах, то с большой вероятностью можем утверждать, что хозяином данных систем является госучреждение со всеми вытекающими. Вспомним о госзакупках, ограниченности бюджета, прибавим вероятность, что за окном осень, отыграть и сдать проект необходимо до конца нового года и получим… Получим как минимум 70-ти процентную вероятность, что фактически времени хватит только на проектирование. В процессе «макетирования и тестирования», ага, кто-бы еще финансы заложил на макет, допилится эксплуатационная документация. Тестирование сведется к проверке, что система не рухнет при установке средств защиты. Ну и на выходе — ожидаемый результат: работает и ладно!
Это то, как не должно быть. А если такое случается, то возможность утечек не должна после удивлять.
Из трех пунктов, хотелось бы заострить внимание на проектировании. Итак, на этапе проектирования:
- определяются типы субъектов доступа и объектов доступа, являющихся объектами защиты;
- определяются методы управления доступом, типы доступа и правила разграничения доступа субъектов доступа к объектам доступа;
- выбираются меры защиты информации, подлежащие реализации в системе защиты информации информационной системы;
- определяются виды и типы средств защиты информации, обеспечивающие реализацию технических мер защиты информации;
- определяется структура системы защиты информации, включая состав и места размещения ее элементов;
- осуществляется выбор средств защиты информации, сертифицированных на соответствие требованиям по безопасности информации, с учетом их стоимости, совместимости с информационными технологиями и техническими средствами, функций безопасности этих средств и особенностей их реализации, а также класса защищенности информационной системы;
- определяются требования к параметрам настройки программного обеспечения, включая программное обеспечение средств защиты информации, обеспечивающие реализацию мер защиты информации, а также устранение возможных уязвимостей информационной системы, приводящих к возникновению угроз безопасности информации;
- определяются меры защиты информации при информационном взаимодействии с иными информационными системами и информационно-телекоммуникационными сетями, в том числе с информационными системами уполномоченного лица, а также при применении вычислительных ресурсов, предоставляемых уполномоченным лицом для обработки информации.
Все вышеперечисленное оформляется в виде технического проекта или подобного документа. Финальный вариант технического проекта — только после этапа макетирования и тестирования. Приказ позволяет по результатам тестирования вносить изменения в технический проект.
Внедрение системы защиты
Итак, система защиты разработана, протестирована и готова к внедрению. Внедрение системы защиты включает:
- установку и настройку средств защиты информации;
- разработку документов, определяющих правила и процедуры, реализуемые оператором для обеспечения защиты информации;
- внедрение организационных мер защиты информации;
- предварительные испытания системы защиты информации;
- опытную эксплуатацию системы защиты информации;
- анализ уязвимостей информационной системы и принятие мер защиты информации по их устранению;
- приемочные испытания системы защиты информации информационной системы.
Установка и настройка средств защиты, производится на основе ранее разработанной документации.
Разрабатываемые на данном этапе документы уточняют правила и процедуры по различным аспектам эксплуатации создаваемой системы (реагирование на инциденты, управление конфигурацией, мониторинг и т.п.).
Внедрение организационных мер включает в себя так же контроль возможности их выполнения и полноту охвата. По сути, на этом этапе отслеживаются конфликты между внедряемыми мерами и существующими бизнес-процессами.
После установки средств защиты и внедрения организационных мер защиты проводятся предварительные испытания и начинается этап опытной эксплуатации.
Во время опытной эксплуатации проводится очень важный этап — анализ уязвимостей. По результатам данного анализа могут корректироваться как модель угроз, так и принятые технические решения. В последней редакции Приказа добавлено, что
«По результатам анализа уязвимостей должно быть подтверждено, что в информационной системе отсутствуют уязвимости, содержащиеся в банке данных угроз безопасности информации ФСТЭК России, а также в иных источниках, или их использование (эксплуатация) нарушителем невозможно».Как ясно из названия – именно на этом этапе проверяется состояние так называемой «реальной безопасности» и от квалификации проверяющих напрямую зависит результат.
После проведения проверок и корректировки (при необходимости) применяемых решений приступаем к приемочным испытаниям.
Аттестация информационной системы
После успешного проведения приемочных испытаний можно приступать к Аттестации.
Аттестация есть аттестация, что-то уточнить тут сложно, поэтому просто перечислю методы проверок (испытаний), при аттестационных испытаниях:
- экспертно-документальный метод, предусматривающий проверку соответствия системы защиты информации информационной системы установленным требованиям по защите информации, на основе оценки эксплуатационной документации, организационно-распорядительных документов по защите информации, а также условий функционирования информационной системы;
- анализ уязвимостей информационной системы, в том числе вызванных неправильной настройкой (конфигурированием) программного обеспечения и средств защиты информации;
- испытания системы защиты информации путем осуществления попыток несанкционированного доступа (воздействия) к информационной системе в обход ее системы защиты информации.
Поднимая вопрос про аттестацию хотелось бы обратить внимание на следующий текст Приказа:
«Допускается аттестация информационной системы на основе результатов аттестационных испытаний выделенного набора сегментов информационной системы, реализующих полную технологию обработки информации.Таким образом, при наличии, допустим, сотни типовых рабочих мест, Приказ позволяет провести аттестацию не всей сотни, а например 3-5 рабочих мест. При условии полного соответствия применяемых средств и мер защиты, действие сертификата может распространяться на рабочие места не прошедшие полный процесс аттестации. Для таких рабочих мест целесообразно ограничится инспекционным контролем, подтверждающим соответствие конфигурации таких рабочих мест эталонным образцам, прошедшим аттестацию.
В этом случае распространение аттестата соответствия на другие сегменты информационной системы осуществляется при условии их соответствия сегментам информационной системы, прошедшим аттестационные испытания».
Успешно пройдя аттестационные испытания можно приступать к вводу системы в эксплуатацию. Важное замечание здесь следующее:
«В случае, если информационная система создается на базе центра обработки данных уполномоченного лица, такой центр обработки данных должен быть аттестован по классу защищенности не ниже класса защищенности, установленного для создаваемой информационной системы.»Т.е., если вы планируете разместить свою систему, например, на площадке облачного провайдера, то необходимо убедиться, что его инфраструктура аттестована по классу, соответствующему вашей ИС.
Обеспечение защиты информации в ходе эксплуатации
В ходе эксплуатации введенной в действие ИС возникают задачи, связанные как с поддержкой работоспособности, так и с поддержанием в актуальном состоянии системы защиты.
Эксплуатация в общем виде включает в себя четыре этапа:
- управление (администрирование) системой защиты информации информационной системы;
- выявление инцидентов и реагирование на них;
- управление конфигурацией аттестованной информационной системы и ее системы защиты информации;
- контроль (мониторинг) за обеспечением уровня защищенности информации, содержащейся в информационной системе.
На данном этапе довольно проблематично выделить отдельные какие-то моменты, т.к. общие этапы выделены, а детали сильно разнятся от конфигурации конкретной ИС. Казалось бы, на этом можно и закончить, но, на самом деле, ещё рано. Одним из важных этапов в жизненном цикле любой ИС является вывод из эксплуатации.
Обеспечение защиты информации при выводе из эксплуатации
Вывод из эксплуатации информационной системы, согласно Приказа, включает в себя два этапа:
- архивирование информации, содержащейся в информационной системе;
- уничтожение (стирание) данных и остаточной информации с машинных носителей информации и (или) уничтожение машинных носителей информации.
Здесь стоит заметить, что если производите стирание, а не физическое уничтожение носителей, то делать это стоит сертифицированными средствами, гарантирующими уничтожение информации. Конечно же, при этом должны оформляться все необходимые акты, согласно разработанной ранее эксплуатационной документации.
Другие статьи нашего корпоративного блога
Государство и IT
→ «Государство в Облаках» и один пример ГИС из нашей практики
→ FAQ по теме интеграции с ЕСИА
→ О моделировании угроз
→ Детям — мороженое, информационной системе — бэкап
→ Как работает блокировка доступа к страницам, распространяющим запрещенный контент (теперь РКН проверяет и поисковики)
Защита прав субъектов персональных данных
→ “Cтрашилка” о GDPR
→ Проверки и планы Роскомнадзора на 2018 год
→ Кто в медицине ИСПДн в соответствие с законом приводил, тот в цирке не смеётся
→ Ошибки операторов ПДн, связанные с кадровой работой
→ Краткий FAQ о Федеральном законе N 242-ФЗ
