HR хранит резюме и анкеты кандидатов: персональные данные и свой сервер

MAATRIX

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

Что на самом деле лежит в папке «Резюме»

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

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

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

Как это обычно хранится на практике

В большинстве компаний, где нет своей ATS (Applicant Tracking System) или бюджета на неё, база кандидатов вырастает стихийно из трёх источников:

• Почтовый ящик рекрутера — резюме приходят на personal или общий hr@ и остаются там годами, потому что удалять «на всякий случай» жалко.
• Общая облачная папка — Google Диск, Яндекс Диск, Dropbox, куда несколько сотрудников скидывают файлы кандидатов, обычно без единой структуры и без разграничения, кто что видит.
• Таблица-реестр — Excel или Google Таблица со списком кандидатов, статусами и ссылками на резюме, которая тоже открыта «всей команде для удобства».

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

Что может пойти не так — конкретно, а не абстрактно

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

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

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

Свой сервер как альтернатива: что это меняет

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

На практике это означает несколько конкретных вещей:

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

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

Как устроить это технически

Для HR-отдела не обязательно строить сложную инфраструктуру — задача решается за один-два вечера настройки на арендованном сервере. Вот рабочая схема, которую можно взять за основу.

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

/hr-storage
  /vacancies
    /2026-backend-developer
      /candidates
        /ivanov-i-i
          resume.pdf
          notes.md
        /petrova-a-s
          resume.pdf
          test-task.zip
  /archive
    /rejected-2025
    /rejected-2026

Права на уровне групп в Nextcloud настраиваются так, что рекрутер видит только свои активные вакансии, а HR-директор или руководитель отдела — весь раздел целиком:

occ group:add hr-recruiters
occ group:add hr-managers
occ files:scan --all
occ sharing:list-shares --path=/hr-storage/vacancies

Шифрование диска. На уровне сервера имеет смысл настроить шифрование раздела с данными (например, через LUKS на Linux), чтобы даже физический доступ к диску без ключа не давал прочитать содержимое. Это не отменяет разграничение прав внутри приложения — это дополнительный уровень защиты на случай кражи оборудования или изъятия диска. С тем, что именно защищает шифрование диска, а что нет, стоит разобраться отдельно — мы писали об этом в статье про то, что реально защищает шифрование диска.

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

borg init --encryption=repokey /mnt/backup-storage/hr-repo
borg create --stats --compression zstd \
  /mnt/backup-storage/hr-repo::hr-{now:%Y-%m-%d} \
  /hr-storage

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

Кто и как получает доступ

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

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

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

Сравнение подходов

Ниже — сравнение общей облачной папки общего назначения и своего сервера под управлением HR/IT по тем параметрам, которые реально имеют значение для базы кандидатов.

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

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