25.6.13

Почему я не завидую ФСТЭК: аттестация облачного оператора ГИС

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

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

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


Идем дальше. Разработку системы защиты по 17-му приказу организует... тоже заказчик ГИС. А на практике это делает облачный провайдер. Опять коллизия ;-( Или мы слово "организует" трактуем как "может делегировать"? Но что если то, как и какие меры и средства защиты выбрал оператор ГИС отличается от понимания заказчика? Кто должен отступить со своих позиций? По идее облачный провайдер, но делать он это врядли будет. Особенно такой, как Ростелеком. Все-таки эффект масштаба имеет значение и одно дело поменять средство или меру защиту в рамках одного муниципального образования и совсем другое - в рамках целого региона или страны.

Кто организует внедрение системы защиты? Опять обладатель информации, т.е. заказчик. Но кто ж его пустит на облачную инфраструктуру, за которую отвечает провайдер? Правда,  в п.16 написано, что к внедрению привлекается оператор ИС, в случае если он определен таковым в соответствии с законодательством РФ. А что значит определен? Кем определен? А если не определен?

Аттестацию у нас проводит или заказчик или оператор ГИС. Тут все как бы и просто, а как бы и нет. Давайте обратимся к новоиспеченному ГОСТу РО 0043-003-2012 по аттестации. В нем говорится, что заявителем аттестации может быть только владелец аттестуемого объекта информатизации. А кто является владельцем в ситуации, когда защищаемая информация находится у одного лица (госоргана), облачная инфраструктура принадлежит другому лицу, а приложения, обрабатывающие защищаемую информацию, вообще третьему? С точки зрения здравого смысла, владельцем должен быть тот, кому принадлежит информация - ведь только он знает ее ценность и может принимать решение об аттестации. Но на практике все наоборот - аттестацию затевают владельцы ЦОДов, которые сдают их потом в аренду различным заказчикам. А т.к. аттестовать "по максимуму" невыгодно (затраты могут и не окупиться), то большинство облачных/аутсорсинговых провайдеров аттестуют "в среднем по больнице", тем самым ставя в неловкое положение своих заказчиков, которым может либо не хватить уровня аттестации, либо наоборот - часть мероприятий будет излишней.

Но допустим вопрос с владельцем мы как-то решили. Но в 6.5.1 ГОСТа говорится о том, что при аттестации проверяется правильность классификации информационных систем. А проверить это можно только контактируя с заказчиком ГИС. А если владельцем объекта информатизации числится облачный провайдер? Трехсторонний договор заключать? А как действовать ФСТЭКу в рамках госконтроля и надзора? Ведь приходят они в госорган, а у того нет ни данных, ни средств защиты, ни информационных систем. Все у облачного провайдера. А тот вообще коммерческая организация. Где прописана процедура трансляции требований заказчика ГИС в сторону оператора ГИС? А где прописана процедура трехсторонних взаимоотношений между ФСТЭК, заказчиком и оператором ГИС? В новом ГОСТе по аттестации этого точно нет.

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


Что у нас получается? А то, что приказ 17-й сложно реализуем (а иногда и вовсем нереализуем) в случае перехода к хранению информации в облачных информационных системах, которые достаточно активно применяются в государственных органах в последнее время.

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


14 коммент.:

Tomas комментирует...

Алексей, рецепт - IaaS. Что сейчас дорого, на мой взгляд, так это строить свои серверные, согласовывать с пожарниками и т.д. (для 30 стоек серверная, оснащенная всем необходимым стоит ~10 млн.руб.). Для уже существующих ГИС существуют уже сервера - их можно перевести к облачному провайдеру, а потом постепенно переходить и более глубоко в облако, и тогда защита будет строиться вместе с АС. Оборудование стареет быстро, можно сделать переходный период. Администрировать можно всегда самим, все зависит от условий договора. А можно просто контролировать каждый шаг, через SIEM, например. Вариантов куча, а Вы опять "о нерешаемых проблемах". Кстати, есть не только облако Ростелекома.

Tomas комментирует...

И еще, Вы говорите, что участвовали в разработке приказов ФСТЭК (постоянно пишите, что ФСТЭК молодец, наконечто свершилось), а тут явная критика - поясните...

Евгений комментирует...

Вообще-то про слона правильный подход, зачем им сейчас делать про облака требования, еще не до конца понимая как это работает и в чем подводные камни - чтобы опять родить нежизнеспособные требования?

И кстати, из опыта работы могу сказать, что если есть какие-то обязательные требования по защите, смысл делать модель угроз есть постольку, поскольку это написано сделать. Эффективного ее применения не получится.

ЗЫ. Если Почта России возьмется за государственные облака, то облачным технологиям при построении ГИС будет "мелкий пушной зверек" :) Они со своей основной деятельностью то не могут справиться...

Evgline комментирует...

Алексей, извиняюсь что не по теме, но всё же хотел спросить. Какова судьба перенесённого курса КП62 который Вы читаете в "Информзащита"
Спасибо!

Evgline комментирует...

Алексей, извиняюсь что не по теме, но всё же хотел спросить. Какова судьба перенесённого курса КП62 который Вы читаете в "Информзащита"
Спасибо!

Алексей Лукацкий комментирует...

Tomas, я и в разработке ФЗ-152 принимал участие. И в ПП-1119. Только вот я их тоже критикую ;-)

Алексей Лукацкий комментирует...

Evgline, а что такое КП62?

Evgline комментирует...

Защита информации в НПС

Evgline комментирует...

Просто сотрудники учебного центра ничего внятного объяснить не могут, ни на какой срок перенесли, ни будет ли вообще этот курс проводиться в ближайшее время... тишина да и только

Алексей Лукацкий комментирует...

Возможно конец августа. Но ввиду неопределенности с моим отпуском, я не могу дать ответ в УЦ.

Evgline комментирует...

Печально... Значит придётся делать возврат денег. Спасибо за информацию.

Анонимный комментирует...

Не вижу проблемы аттестации ГИС. Каждая ИС аттестуется отдельно с учетом протоколов взаимодействия...

Tomas комментирует...

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

Анонимный комментирует...

А можете пальцем ткнуть? Плиз!