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

Почему я не завидую ФСТЭК: аттестация облачного оператора ГИС
Про 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-м годах. А пока остается только ждать, когда наши регуляторы станут учитывать те технологии, которые активно продвигаются (навязываются) Минкомсвязью и Правительством.


законодательство cloud ФСТЭК облачная безопасность
Alt text
Обращаем внимание, что все материалы в этом блоге представляют личное мнение их авторов. Редакция SecurityLab.ru не несет ответственности за точность, полноту и достоверность опубликованных данных. Вся информация предоставлена «как есть» и может не соответствовать официальной позиции компании.

Ищем баги вместе! Но не те, что в продакшене...

Разбираем кейсы, делимся опытом, учимся на чужих ошибках

Зафиксируйте уязвимость своих знаний — подпишитесь!