Дисклеймер

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

2. Конечно же, не все аттестованные облака являются «аттестованными» в кавычках. Но если вы потенциальный клиент, есть нюансы, на которые необходимо обратить внимание.

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

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

Небольшая предыстория

Идея расписать подробнее о возможных подводных камнях в аттестованных ЦОД появилась еще в 2019 году, после прочтения этой статьи.

Там автор, описывает варианты, когда «аттестованность ЦОД» может быть не тем, что хотел бы видеть клиент такого ЦОДа. Совсем не повторяться у меня не получится, но я постараюсь более глубоко описать те примеры, заострить внимание на самом процессе аттестации и проанализировать роль регулятора в этих вопросах.

Подтолкнула же меня к написанию статьи именно сейчас другая статья от коллег. У меня там в комментариях немного пригорело от различных странностей и несоответствий, но в этой статье я не буду повторять те свои комментарии, просто вдруг стало понятно, что нужно рассказать о своем видении проблематики аттестованных ЦОД. Насчет той статьи рад, что некоторые мои замечания были приняты, какие-то породили дискуссию. Самое главное понимать, что там были претензии к самой статье, а не к облачным ЦОД в целом.

А катализатором стала ситуация у одного из наших клиентов. Там тоже серверная часть одного из сервисов переехала в облако. Как это иногда бывает в государственных структурах, одна более крупная организация может заказать какие-то работы для своей подведомстевенной структуры. Так случилось и здесь. Правда головная организация организовала это все в обход IT-шников и безопасников своего подведа и когда те посмотрели, что было закуплено, схватились за голову. Выяснилось, что:

• ЦОД находится на другом конце страны, что противоречило изначальной концепции сервиса;

• облачный провайдер отказывается предоставлять документы по аттестации своего ЦОД;

• соединение клиентов с сервером осуществляется без использования сертифицированных криптографических средств.

Тут я понял – ну точно пора писать эту статью.

Описание проблемы

Сейчас все больше организаций как коммерческих, так и государственных приходят к выводу, что им экономически нецелесообразно содержать собственную IT-инфраструктуру и задумываются о переезде в облако. Но у многих таких организаций возникает вопрос защищенности этих облаков, поскольку зачастую информационные системы (далее – ИС), которые они хотят передать провайдерам то и дело попадают под какие-нибудь требования в части защиты информации. Самый распространенный пример – информационные системы персональных данных (далее – ИСПДн), попадающие под требования 152-ФЗ. На втором месте по распространённости государственные информационные системы (далее – ГИС), попадающие под требования 149-ФЗ (а точнее – 17 приказа ФСТЭК).

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

И, казалось бы, да что тут вообще может пойти не так? Да много чего:

1. Сама концепция аттестации не идеальна.

2. Нечеткость регуляторных требований.

3. Некорректный подход к аттестации облачного провайдера.

4. Некорректный подход к аттестации лицензиата ФСТЭК на работы по ТЗКИ.

5. Практическое отсутствие контроля со стороны регулятора.

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

Что такое аттестация и почему она сама по себе не гарантирует защиту данных в аттестованной системе

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

Посмотрите на полное название процедуры: «аттестация по требованиям безопасности информации». То есть для некоторой ИС есть, в зависимости от ее класса или уровня защищенности и актуальных угроз безопасности, некий набор требований. А аттестация по сути это проход по чек-листу. Есть требование наличия парольной политики? Есть. Есть парольная политика? Есть. Чек. Есть требование наличия на внешнем периметре сертифицированного межсетевого экрана? Есть. Есть такой межсетевой экран? Есть. Чек.

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

Вот вам яркий пример. Один из самых адекватных регуляторов в сфере ИБ – ФСТЭК России. Они медленно, но верно движутся от так называемой «бумажной» безопасности к практической. Одним из таких движений было изменение в 17 приказе ФСТЭК, который выдвигает требования по информационной безопасности к ГИС. По 17 приказу, для всех ГИС обязательна аттестация. В 2017 году ФСТЭК обязала в ходе аттестационных испытаний проводить сканирование на наличие уязвимостей и выявленные дыры устранять.

Но раньше такого требования не было. И что вы думаете? При переаттестации ранее аттестованных ИС начали вылезать древние уязвимости с рейтингом CVSS 9-10. Но как так-то, ведь ИС уже была аттестована, разве не должны были быть эти уязвимости устранены при прошлой аттестации? А вот не обязательно.

Дело в том, что в целом требования анализа уязвимостей в 17 приказе конечно же есть и они были до внесения изменений. Но там оно звучало примерно так – должен проводиться анализ уязвимостей с определенной периодичностью, которую устанавливает оператор ГИС. Таким образом, часто вопрос анализа уязвимостей решался на аттестации так: в документах описаны процессы и периодичность анализа уязвимостей, а так же в наличии есть сертифицированный сканер. Ну, в целом требование выполняется. Чек.

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

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

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

Давайте на этом перейдем к пункту №2.

Требования регулятора

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

Пример возьму из методического документа ФСТЭК «Меры защиты информации в ГИС», так как там меры расписаны более подробно.

Вот, например, неоспоримо важная и полезная мера ОДТ.4, которая говорит нам о необходимости бэкапов, вот как ее описание выглядит в расширенном описании:

Требования к реализации ОДТ.4: Оператором должно обеспечиваться периодическое резервное копирование информации на резервные машинные носители информации, предусматривающее:

резервное копирование информации на резервные машинные носители информации с установленной оператором периодичностью;

разработку перечня информации (типов информации), подлежащей периодическому резервному копированию на резервные машинные носители информации;

регистрацию событий, связанных с резервным копированием информации на резервные машинные носители информации;

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

Правила и процедуры резервного копирования информации регламентируются в организационно-распорядительных документах оператора по защите информации.

Обратите внимание на выделенные жирным места. Последний кусок под копирку повторяется почти под каждой мерой: «Правила и процедуры X регламентируются в организационно-распорядительных документах...». В целом тут нет ничего криминального. ФСТЭК не может предусмотреть возможности всех операторов ГИС. И, наверное, правильно, что нет четких норм, ведь кому-то просто необходимо бэкапиться несколько раз в сутки, а кому-то и раз в неделю подойдет. Но что может означать такой подход для клиента облачного ЦОД?

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

В этой статье коллега обозначал возможный «творческий» подход к реализации требования по мониторингу событий безопасности и реагированию на инциденты. И таких примеров можно привести много. Основная идея этой части статьи – сами требования написаны так, что их можно как бы выполнить, но по факту это будет полная ерунда. Давайте на этой грустной ноте перейдем к пунктам 3 и 4.

Что аттестовано и как

Автор статьи приводит пример, когда может быть аттестован старенький компьютер на Windows XP без подключения к сети. Но названа такая конструкция может быть «ИС Облачный ЦОД». Это конечно маловероятный утрированный пример, но вполне возможный. А самое смешное, что аттестующая организация может здесь выступать не соучастником такого злодейства, а стать заложником ситуации. Вот, например, выдуманный, но основанный на реальных событиях диалог:

Провайдер (П): Здравствуйте! Нам нужно аттестовать 1 компьютер без интернета, сколько это будет стоить?

Аттестующая организация (А): А что за компьютер, для чего применяется, почему без интернета, по какому классу/уровню защищенности нужно аттестовать?

П: Да так, документы с грифом «ДСП» локально набираем и на принтере печатаем, нужно по классу 1Г аттестовать.

А: Понятно, средства защиты есть?

П: Да.

А: Ок, аттестация и прочие сопутствующие работы будут стоить Х рублей.

П: Хорошо, нас устраивает, когда приступаем?

А: Да хоть завтра.

П: Отлично.

В итоге после заключения договора аттестующая организация узнает, что все, в общем-то, так, как и было обозначено по телефону, но есть маленькая проблемка – заказчик назвал это компьютер в своих внутренних документах «ИС Облачный ЦОД», а на все возражения говорит «Ну а че такого?». И ведь действительно, оператор ИС волен называть свою информационную систему как захочет. Здесь еще нужно отметить, что класс защиты 1Г это тот еще исторический рудимент. Он определяется из руководящего документа РД АС, который сильно морально устарел, но официально не отменен. Выполнить требования к классу 1Г, особенно если компьютер отключен от сетей связи, проще, чем по самым низким критериям для ГИС или ИСПДн. Зато на вопрос от потенциального клиента, аттестован ли их облачный ЦОД, такой провайдер может показать титульный лист, где будет красоваться «Аттестат соответствия требованиям по безопасности информации ИС Облачный ЦОД».

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

Здесь я вижу только два стопроцентных варианта:

1. Возможен у небольших провайдеров – когда весь ЦОД на 100% аттестован. Тогда просто нет функции «запустить вон ту ИС на неаттестованных серверах».

2. Вариант экзотический, но совсем не выдуманный, так как один из наших клиентов так и поступил. У ЦОД арендуется только базовая инфраструктура: физическая серверная стойка, внешние коммуникации, обеспечение бесперебойного питания, защита периметра, криптошлюз. Серверы клиент ставит свои и аттестует их отдельно. Стойка закрывается на лопату, физический доступ к серверам имеют только сотрудники клиента.

У больших провайдеров можно даже задаваться не вопросом «на какой стойке крутится сейчас моя ИС?», а «в какой части страны сейчас крутится моя ИС?».

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

Почему ФСТЭК не выявит и не накажет всех облачных провайдеров с некорректно аттестованными ЦОД?

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

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

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

Чем мне, как клиенту, грозит, если ЦОД аттестован как-то не так?

Допустим, вы так или иначе решили переехать в облачный ЦОД, провайдер вызывает у вас доверие, но где-то внутри все равно мучает вопрос: «А вдруг там что-то не так с аттестацией? Что мне за это будет?». И здесь есть 2 прямо противоположных ответа.

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

Совсем другое дело, если это ГИС.

Вот что по этому поводу говорится в 17 приказе ФСТЭК:

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

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

(в ред. Приказа ФСТЭК России от 28.05.2019 N 106)

При аттестации информационной системы должны используются результаты аттестации общей инфраструктуры оператора информационной системы.

(п. 17.6 введен Приказом ФСТЭК России от 15.02.2017 N 27)

Пометки о том, когда были введены эти пункты, оставил специально, чтобы было понимание, что данные изменения были введены относительно недавно.

Итак, что мы здесь видим? Если коротко: то, что вы перевозите серверную часть своей ГИС в аттестованный ЦОД, это еще не значит, что на этом вопросы аттестации полностью закрыты. Остальная часть системы – рабочие места, места администраторов тоже должны быть аттестованы. При аттестации остальной части ГИС используются результаты аттестации ЦОД.

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

Что же делать, как же быть

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

Давайте подведем итог, на что нужно обратить внимание при выборе облачного провайдера.

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

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

3. Спросите о возможности ознакомиться с приложением к аттестату и посмотрите на реакцию провайдера. Обратите внимание, что отказ выслать вам сканы приложения к аттестату и протоколов испытаний это вполне нормальная реакция, так как такие документы часто грифуются. Но если вам отказывают в ознакомлении с этими документами в офисе провайдера – уже повод задуматься.

4. Если получили доступ к приложению аттестата, обратите внимание на перечень аттестованных технических средств. Если провайдер заявляет, что у него сотни клиентов уже в аттестованном сегменте, а в аттестате указано 2-3 не самых мощных физических сервера кластера виртуализации – подвод задуматься.

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

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

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

На этом пока все, если остались вопросы или есть желание поделиться своим опытом, добро пожаловать в комментарии.