Персональные данные сотрудников на корпоративном сервере

MAATRIX

Когда речь заходит о персональных данных, почти весь разговор крутится вокруг клиентов сайта: форма регистрации, корзина, CRM. При этом в шкафу с кадровыми делами и в базе HR-системы лежит куда более чувствительный набор данных — паспорта, СНИЛС, сведения о больничных, а иногда и отпечатки пальцев сотрудников, — и он подпадает под те же требования защиты, только про него почти никто не вспоминает, пока не случится проверка или утечка. Важная оговорка сразу. Этот материал — обзорный разбор, какие категории данных сотрудников чувствительны и какие технические следствия это создаёт для инфраструктуры. Это не юридическая консультация: конкретный перечень обрабатываемых данных, основания для их сбора, форма согласий и сроки хранения в вашей компании — вопрос к юристу или HR-специалисту, знакомому именно с вашими кадровыми процессами. Ниже — ориентир для разговора с ними и для технического планирования, а не готовое решение.

Работодатель — тоже оператор персональных данных

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

Разница в восприятии обычно чисто психологическая: данные клиента воспринимаются как «внешние» и потенциально рискованные (клиент — чужой человек, может пожаловаться, обратиться в суд), а данные сотрудника — как «свои», внутренние, вроде бы под естественным контролем компании. С точки зрения закона это разделение не имеет значения: если данные позволяют идентифицировать конкретного человека, они являются персональными данными независимо от того, состоит этот человек в трудовых отношениях с оператором или просто оформил заказ на сайте.

Практическое следствие: если в компании уже выстроен процесс для персональных данных клиентов — есть политика обработки, назначен ответственный, продуманы согласия, — этот же процесс, скорее всего, должен охватывать и кадровый контур. На практике часто оказывается, что клиентский контур проработан (потому что про него напоминает 152-ФЗ и штрафы за сайты), а кадровый — нет, просто потому что HR-система исторически воспринималась как внутренний рабочий инструмент, а не как «система обработки ПДн». Общие принципы законодательства о защите персональных данных разбираются в статье что считается персональными данными — там же можно свериться, какие конкретно поля в кадровой карточке точно попадают под определение, а какие — спорны.

Базовый набор: паспорт, ИНН, СНИЛС

Стандартная кадровая карточка сотрудника в HR-системе или в личном деле почти всегда содержит:

• Паспортные данные (серия, номер, дата и место выдачи, адрес регистрации).
• ИНН.
• СНИЛС.
• Данные о семейном положении, иждивенцах (для вычетов и льгот).
• Банковские реквизиты для перечисления зарплаты.
• Сведения об образовании, предыдущих местах работы, воинском учёте.

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

Отдельный практический нюанс — банковские реквизиты. Формально это не всегда относится к «специальным категориям», но по чувствительности они сопоставимы с финансовыми данными клиентов, и типичная ошибка — хранить их в открытом виде в той же таблице, где лежат общие сведения о сотруднике (должность, стаж), без отдельного контроля доступа именно к платёжному блоку.

Данные о здоровье: больничные и не только

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

По общей практике законодательства о персональных данных сведения о здоровье относятся к специальной категории данных, для которой действует более строгий режим обработки: как правило, требуется отдельное согласие сотрудника именно на обработку данных о здоровье (отдельно от общего согласия на обработку персональных данных при трудоустройстве), и объём хранимых сведений должен быть минимально необходимым — то есть системе, как правило, достаточно знать факт и период нетрудоспособности, а не диагноз, если он не требуется напрямую для конкретной цели обработки. Точный объём сведений, который вправе фиксировать конкретная компания, и форма согласия — вопрос к юристу или к HR, знакомому с медицинской документацией; здесь разбираем только то, что это отдельная категория, требующая повышенного внимания, а не общий кадровый факт вроде даты приёма на работу.

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

Биометрия на проходной и в системе доступа

Если в офисе стоит система контроля доступа по отпечатку пальца или распознаванию лица — на входной двери, на турникете, в системе учёта рабочего времени, — компания обрабатывает биометрические персональные данные сотрудников. Это отдельная, ещё более узкая категория, чем данные о здоровье: по общей практике для обработки биометрических данных требуется отдельное письменное согласие сотрудника, оформленное именно под эту цель, а не «зашитое» общей строчкой в трудовом договоре про обработку персональных данных вообще.

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

Технически стоит обратить внимание на несколько вещей отдельно от юридической стороны:

• Где физически хранится база биометрических шаблонов — на контроллере СКУД в серверной, в облаке производителя оборудования, или локально на самом терминале у двери. Часто это отдельная система, никак не связанная с общей ИТ-инфраструктурой, и про неё просто забывают, когда проводят инвентаризацию систем с персональными данными.
• Кто имеет административный доступ к этой базе — нередко это подрядчик, обслуживающий СКУД по договору, у которого остался доступ «по старой памяти» уже после завершения работ.
• Как происходит удаление биометрического шаблона при увольнении сотрудника — на практике эта база реже попадает в общий процесс оффбординга, чем учётная запись в почте или в HR-системе.

Где физически лежат данные и кто имеет к ним доступ внутри компании

Кадровая база — это, как правило, часть той же инфраструктуры, что и остальные корпоративные системы: HR-модуль в 1С или отдельном SaaS-сервисе, файлы отсканированных документов на файловом сервере, переписка по кадровым вопросам в корпоративной почте. С точки зрения локализации персональных данных россиян действует то же требование, что и для клиентских данных: первичное хранение и обработка данных граждан России должны идти через базы, физически расположенные на территории России, — здесь нет отдельного исключения для того, что это данные не клиентов, а сотрудников. Общий механизм этого требования и то, как он влияет на архитектуру сервера, разобран в статье 152-ФЗ: где законно держать сервер с персональными данными — стоит свериться с ней при выборе, где физически размещать HR-контур, если часть инфраструктуры компании работает за рубежом.

Отдельный вопрос — не внешние угрозы, а доступ внутри самой компании. Стандартная ошибка: HR-система развёрнута на общем сервере, где системный администратор (или несколько человек с ролью sudo/root) технически видит содержимое базы целиком, хотя по своей функции ему нужен доступ только к работоспособности сервиса, а не к содержимому кадровых карточек. То же касается руководителей отделов, у которых в некоторых компаниях по инерции есть доступ «посмотреть личное дело» сотрудника из другого отдела, хотя это не требуется их прямыми обязанностями.

Практический принцип здесь такой же, как при разграничении доступа к любой чувствительной системе: минимально необходимые права для каждой роли, отдельные учётные записи вместо общего логина «HR», и журналирование обращений к персональным данным — кто, когда и к какой карточке обращался. Общие технические приёмы разграничения доступа на сервере без раздачи полного root каждому, кто работает с системой, разобраны в статье как раздать доступ команде без выдачи root — те же принципы (отдельные пользователи, ограниченный sudo, группы доступа) применимы и к серверу, где крутится HR-система, а не только к обычному продовому окружению разработки.

Сколько хранить данные уволенных сотрудников

Отдельная и часто упускаемая практическая тема — что происходит с персональными данными после увольнения сотрудника. Интуитивно кажется логичным держать личное дело «на всякий случай» бессрочно — вдруг понадобится справка, вдруг будет трудовой спор, вдруг налоговая проверка. На практике у разных категорий кадровых документов есть свои, обычно вполне конкретные сроки хранения (для одних документов — несколько лет, для других, включая часть кадровых, — существенно дольше в силу отдельных требований архивного законодательства), и хранение сверх установленного срока — это тоже нарушение принципа «не дольше, чем необходимо для целей обработки», просто с другой стороны: не «слишком мало», а «слишком долго без основания».

Точные сроки хранения для конкретных видов документов (личное дело, расчётные листы, документы воинского учёта, материалы медосмотров) — вопрос к HR-специалисту и к внутренней номенклатуре дел компании, а не техническая деталь, которую можно решить только настройками сервера. Но техническая сторона вопроса всё равно требует внимания:

• Учётная запись уволенного сотрудника в корпоративных системах (почта, HR-портал, VPN, система доступа) должна быть закрыта или переведена в архивный режим в разумный срок после увольнения, а не оставаться активной «по забывчивости» — это отдельная тема от хранения самих кадровых данных, но напрямую с ней связанная: активная учётная запись — это лишняя точка доступа к данным, которые уже пора либо архивировать, либо удалять по истечении срока.
• Если HR-система хранит данные уволенных сотрудников в той же таблице, что и текущих, стоит предусмотреть механизм пометки записи как архивной с последующим удалением по истечении установленного срока, а не полагаться на то, что кто-то вручную вспомнит почистить базу через несколько лет.
• Резервные копии — отдельная проблема: если основная запись в HR-системе удалена по истечении срока, а бэкапы за все годы существования компании хранятся бессрочно на отдельном хранилище, персональные данные фактически продолжают существовать, просто не в основной базе. Политику ротации и удаления старых бэкапов стоит согласовывать с теми же сроками хранения, а не держать архив резервных копий отдельно и бессрочно «на всякий случай».

Частые вопросы