Классификация ИСПДн по приказу ФСТЭК №58: как это работает на практике

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

Что вообще такое классификация ИСПДн

Приказ ФСТЭК №58 требует от оператора присвоить каждой информационной системе, обрабатывающей персональные данные, класс защищённости: К1, К2, К3 или К4. Класс определяет, какой набор технических и организационных мер нужно внедрить. К1 - самый жёсткий, К4 - минимальный.

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

• Xпд1 - специальные категории: данные о расовой и национальной принадлежности, политических взглядах, религиозных убеждениях, состоянии здоровья, интимной жизни.
• Xпд2 - иные персональные данные: всё, что позволяет идентифицировать человека и получить о нём дополнительные сведения (ФИО + должность + зарплата, например).
• Xпд3 - только ФИО: системы, где других данных нет.
• Xпд4 - обезличенные или общедоступные данные.

Количество субъектов - пороги: до 1 000 человек, от 1 000 до 100 000, свыше 100 000. Пересечение категории и численности даёт класс.

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

Как проводили классификацию

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

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

По 1С:Зарплата всё сошлось. ФИО, паспортные данные, СНИЛС, размер зарплаты - это Xпд2. Количество сотрудников у клиента - около восьмидесяти. Попадаем в К2. Это ожидаемо, и клиент это сам выставил правильно.

По 1С:Торговля - К3. Там только ФИО покупателей для накладных и актов, ничего сверх того. Xпд3, количество контрагентов - в районе нескольких сотен. К3.

По Excel-базе покупателей - пересмотрели. В первичной классификации клиента её не было вообще. Добавили: Xпд2 (ФИО + телефон + дата рождения + паспортные данные для части записей), количество субъектов - несколько сотен. К3. Это нужно закрывать.

Сюрприз с CRM

CRM у клиента - самописная система на Access, сделанная несколько лет назад под задачи отдела продаж. Хранит контакты клиентов, историю взаимодействия, сделки. Мы её посмотрели как Xпд2 и уже собирались поставить К3 - пока не залезли в структуру базы детальнее.

В таблице контактов нашлось поле notes - свободный текст, куда менеджеры вписывали всё что считали нужным. Выгрузили несколько записей наугад. Среди типичного «звонил, не отвечал» и «интересует поставка до конца квартала» обнаружилось несколько записей вроде «на больничном, перезвонить в апреле» и «не может встречаться, проблемы со здоровьем».

Это Xпд1. Данные о состоянии здоровья, пусть и в виде вольных заметок менеджеров.

Технически CRM обрабатывает специальные категории персональных данных. По методике классификации - это К1, независимо от числа субъектов. Можно долго спорить о том, насколько запись «на больничном» является «данными о состоянии здоровья» в юридическом смысле, но рисковать с такой трактовкой мы не рекомендовали.

Клиент был искренне удивлён. Никто не принимал решения «будем хранить медицинские данные». Менеджеры просто писали в свободное поле то, что казалось полезным для работы. Система накапливала это годами.

Что означает К1 на практике

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

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

Мы предложили два пути. Первый - расчистить поле notes: выгрузить все записи, убрать упоминания о здоровье, закрыть это поле для свободного ввода или ввести явный запрет в регламенте. Если система фактически не обрабатывает Xпд1 - она не К1. Второй - честно классифицировать как К1 и разрабатывать план приведения к требованиям, понимая, что это проект не на один месяц.

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

Что вынесли из этой классификации

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

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

Классификацию по всем системам зафиксировали в акте, подписали у директора. Это обязательный документ для аудита соответствия 152-ФЗ. До конца года нужно ещё выстроить технические меры под каждый класс - это отдельная работа, которую продолжаем.

Интересно, что второй клиент, которому мы делали классификацию параллельно, - производственная компания. Там неожиданностей не было, но объём систем больше. Расскажем отдельно.