Безопасный переезд базы 1С с персональными данными в облако

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

В этой статье я хочу поделиться с вами своими мыслями по “безопасному” переносу базы 1С в облако. Во всех организациях, где я работала, вопрос о переносе баз 1С в облако не стоял - и я, и админы, и программисты предпочитали располагать 1С в одной из стоек, надежно запертой за несколькими дверями в нашей серверной. Однако, недавно я наткнулась на горячий спор по теме безопасности решения о переносе данных в облако и не смогла промолчать.

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

Это сокращения, повсеместно используемые безопасниками в общении между собой. Мне было удобнее писать статью как я привыкла и раскрыть эти понятия тут.

Прежде, чем мы приступим, позвольте маленький тест на понимание Вами понятия ПДн:

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

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

Что проверяют ФСТЭК и РКН?

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

1. Вы должны соблюдать только те законы, которые к вам относятся. Многие админы, работавшие в своё время на закрытых объектах по привычке городят баррикады там, где они не к месту. Например: аттестуют рабочие места в коммерческих структурах, выполняют требования 17 приказа работая в частной конторе и смешивают “коктейль Молотова” из требований СТР и защите криптографии там, где сидят обычные менеджеры.

В данном случае:

• 17 приказ обязателен к выполнению в госструктурах, но для защиты ПДн в коммерческих организациях есть “свой” приказ (21-й).
• Требования СТР нужны только для защиты государственной тайны.
• Требования к помещениям с криптографией относятся к любому виду тайны, которой у вас может и не быть. Кроме того, выполнение требований по защите помещений с криптографией очень дороги в исполнении, поэтому лучше сделать 1-2 защищаемых помещения на всю организацию, а не защищать всё здание.

Регулятор вас за это не накажет, но вот руководитель явно не будет в восторге от разбазаривания казенных средств.

2. Вы сами определяете, как сильно вам нужно защищаться. Поскольку обязанность   составлять модель угроз лежит на вас - то вы можете сказать: “Я не буду выполнять это требование приказа, поскольку угрозы, которую перекрывает данное требование у меня нет". И регулятор в зависимости от ваших обоснований с вами может внезапно и согласиться. Увы, так можно сделать не со всеми требованиями 21 приказа.

Рассмотрим типовую для многих организаций ситуацию:

Вы - коммерческая организация с количеством сотрудников до 100 человек. У вас есть база 1С:Бухгалтерии / 1С:ЗУП / 1С:УТ. Там, как правило, содержится информация о текущих сотрудниках и персональные данные других субъектов (соискатели, уволившиеся сотрудники, клиенты-физ.лица и прочее). В 99% случаев вы обрабатываете иные ПДн - не являющиеся биометрией, общедоступными или специальными (раса, религия, политические убеждения, интимная жизнь и состояние здоровья), вам соответствуют угрозы 3-го типа (за вами не следит иностранная разведка =), и у вас менее 100 000 уникальных записей ПДн в базе. У вас есть согласия на обработку ПДн или договоры с физ.лицами, вы включены в реестр операторов персональных данных и имеете необходимый минимум документов (политика обработки ПДн, разделение систем на ИСПДн и их классификация, модель угроз, матрица доступа и куча приказов: о назначении ответственного за контроль за обработкой ПДн; помещений, где обрабатываются ПДн; список лиц имеющих к ним доступ и т.д. - всё это перечислено в законах и приказах). В таких условиях уровень защищенности вашей ИСПДн с 1С будет 4. По типам угроз, классификации ПДн и уровням защищенности свериться можно с постановлением Правительства 1119.

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

Если ранее вы попадали под условия обработки без уведомления РКН (152-ФЗ ст.22 ч.2), например, вы обрабатываете ПДн только ваших сотрудников, то с переездом в облако вам придется написать уведомление в РКН о включении в реестр операторов ПДн и обзавестись формальным ответственным и необходимой документацией.

А какова вероятность, что меня поймают за хвост, если я не подам уведомление об обработке ПДн?

Тут все зависит от вашего везения. Даже если кто-нибудь напишет жалобу на вас в РКН, то не факт, что они инициируют проверку по этому факту - им нужны доказательства неправомерной обработки данных именно вашей организацией. Если такие доказательства у (предположим!) обиженного физ.лица будут, то скорее всего вам выпишут предписание о постановке на учет. Вы в течении 30 дней (с момента получения предписания) встаете на учет и пишете ответ, что предписание выполнено. Если РКН найдет доказательства того, что вы незаконно обрабатываете ПДн не первый год, то, за несвоевременное уведомление РКН, вам грозит еще и штраф по ст. 13.12 ч.6 КоАП (для юр.лиц штраф от 10-15 т.р.), который вы обязаны выплатить в течении 60 дней со дня его наложения. После устранения всех замечаний и выплаты штрафа спим спокойно до следующей жалобы или ближайшие 3 года - это период каникул от плановых проверок.

Что нужно сделать при переходе в облако?

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

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

Вы, как основной оператор, должны заморочится тем, как именно субоператор защищает ваши данные (он обязан это делать в любом случае - 152-ФЗ ст. 6 ч.3). Потому что проверка у субоператора ударит по вам обоим, а у субоператора больше прав показать пальцем в вашу сторону и сказать “Это он не проконтролировал!”, поскольку ответственность за невыполнение требований понесет оператор (152-ФЗ ст. 6 ч.5). Так что, если “облачный” провайдер не защищает ПДн вообще, то он не должен быть в списке возможных кандидатов на размещение ваших баз 1С.

На какие аспекты безопасности обратить внимание при выборе провайдера?

1. Провайдер зарегистрирован в реестре операторов, осуществляющих обработку персональных данных. Например, Selectel, КРОК, Cloud4Y там есть:

   

   

   

   Если провайдера-кандидата там нет, возникают вопросы - как они защищают персональные данные и защищают ли их вообще? Скорее всего никак.

2. Политика в отношении обработки ПДн должна быть на сайте в свободном доступе - мелочь, которая показывает исполнительность оператора.

3. Очень желательно, чтобы ЦОД располагался на территории РФ и данные из него не утекали за рубеж.

Многие недопонимают 152-ФЗ 12 ст. - трансграничную передачу данных. На самом деле с рядом оговорок передавать ПДн субъектов заграницу можно.

*данные взяты из раздела “часто задаваемые вопросы” с сайта РКН

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

Что касается хранения ПДн, то это описано в 152-ФЗ ст. 18 ч. 5: храним ПДн в России, если вы не дип.сотрудник, журналист или писатель, например. Но вам ничто не мешает безнаказанно скопировать какой-то объем вашей базы за рубеж, при условии хранения всей базы с ПДн в России, поскольку в явном виде законом это не запрещено.

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

А как же мне оценить всех провайдеров-кандидатов?

В тестовом периоде на 3-5-14 дней не заключается никаких договоров с провайдером облачных услуг. Но на сайте каждого облачного хостинга есть хоть какая-то публичная оферта, в которой слегонца затрагивается тема неразглашения полученных данных и берется обязанность с потенциального клиента “не пакостить”. Достаточно ли этого с точки зрения РКН? Нет. Они всегда просят больше конкретики. Отсюда у вас три варианта развития тестирования:

1. Неправильный. Делать вид, что вы никого не тестировали, но протестировать по полной с боевой базой.
2. Приемлемый. Тестировать с тестовой базой или базой не содержащей конфиденциальной информации. В этом случае тестирование может быть не показательным.
3. Идеальный. Заключить отдельное соглашение о сотрудничестве/взаимодействии/ неразглашении и тестировать боевую базу открыто.

Я определился с конкретным провайдером - что дальше?

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

Уязвимость - слабое место в системе

Угроза - что-то, что может проделать дыру на месте уязвимости

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

1. Принадлежность ПДн. Они всё ещё должны принадлежать вам. А провайдер - субоператор - обязуется их защищать. Бывает, что субоператор в договоре “переписывает” на себя принадлежность всех ваших данных и пользуется ими на своё усмотрение.
2. Должен быть предусмотрен момент удаления всех ваших данных при отказе от услуг оператора. По умолчанию, это делается в срок до 30 календарных дней после расторжения договора, но желательно прописать это отдельно с уведомлением вас об удалении (прислать копию акта уничтожения с синей печатью).

Этими действиями вы очерчиваете в более явном виде круг ответственности оператора и субоператора.

А что ж делать с защитой вне бумаги?

Все зависит от вашей модели угроз и желания действительно обезопасить свои данные. В защите ПДн в облаках, как безопасник, я вижу в основном минусы:

1. Невозможность рулить критическими уязвимостями, поскольку хостовая (иногда и виртуальная) машина вам неподвластна.
2. Потолок масштабируемости - что делать при переезде, теневой миграции виртуалок между хостами и т.д.
3. Момент оплаты реализуемых мер защиты на стороне провайдера. Я в своё время запнулась о то, что провайдеры так строят диалог, что готовы выполнить любой каприз за наши деньги. А это неплохая прибавка в цене к ежемесячному платежу.
4.  Возможное низкое качество предоставляемых услуг в отсутствии понимающих в безопасности людей. Ниже - пример такой неприятной ситуации.

У нас в городе есть несколько очень крупных организаций, имеющих лицензию на оказание услуг в сфере ИБ. Вольных безопасников немного - на всех желающих не хватает. Однажды мне на проверку принесли тех.проект системы защиты. После предыдущего клиента исправили только титульный лист, даже адрес помещения не поменяли. Я написала книжку замечаний и отправила приятелю. Ему сказали, что перепутали файлы и обещали дослать через две недели - мол, сотрудник ушел в отпуск и доступа к его файлам ни у кого нет. Когда же позвонила я (неформально), объяснение было другим - они всё равно бы ничего не заметили, ведь своего безопасника у них нет и не будет.

Так ответственность за неисполнение требований по защите ИСПДн есть?

В случае с ПДн вы вряд ли уйдете дальше административной ответственности. Все цены за ваши возможные косяки расписаны в главе 13 КоАП РФ. Больше всего в случае невыполнения каких-либо требований по ПДн штрафуют по статьям 13.11, 13.12, 13.14. Размеры штрафов зависят от очень многих факторов - иногда можно обойтись предупреждением (например, за неопубликованную политику по обработке ПДн), а иногда можно "попасть" на миллионы (например, как Twitter и Facebook за хранение ПДн только за рубежом) .

Надеюсь мои размышления на счет “бумажной” безопасности облаков с 1С хоть немного расставили точки над i в голове читателей. Если нет - спрашивайте, постараюсь ответить.

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