Безопасность данных и конфиденциальность при внедрении EWA

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

> Примечание: Это справочная структура по управлению, техническим аспектам и операционной деятельности. Определение конкретных юридических обязательств зависит от роли каждой стороны, типа данных, целей обработки, потоков передачи данных и фактической модели внедрения. Компаниям рекомендуется привлечь юридический отдел, департамент информационной безопасности и HR-службу для совместного анализа перед началом использования.

> Глоссарий терминов: EWA (доступ к заработанной плате) · HRIS (кадровая информационная система) · ERP (планирование ресурсов предприятия) · payroll (расчет заработной платы) · API (программный интерфейс приложения) · SFTP (безопасная передача файлов) · token (токен, заменяющий исходные данные) · MFA (многофакторная аутентификация) · OTP (одноразовый пароль) · idempotency (идемпотентность, защита от повторных транзакций) · webhook/callback (автоматические уведомления между системами) · log (журнал событий) · SOC (центр мониторинга информационной безопасности) · go-live (запуск в промышленную эксплуатацию) · playbook (план реагирования на инциденты) · OWASP ASVS/MASVS (стандарты тестирования безопасности веб/мобильных приложений) · backup (резервное копирование).

Почему данные EWA требуют повышенного уровня защиты?

EWA — Earned Wage Access — позволяет сотрудникам получать часть уже заработанной платы до наступления установленного дня выплаты. Чтобы определить право сотрудника на получение средств и доступный лимит, система обычно объединяет несколько доменов данных:

• идентификационную информацию и статус занятости;

• подразделение, должность или группу выплаты заработной платы;

• данные учета рабочего времени и статус их утверждения;

• уровень заработной платы, расчетный период и сопутствующие корректировки;

• реквизиты банковского счета или платежную информацию;

• историю запросов, суммы, время и результаты транзакций;

• данные устройств, сеансы входа и журналы для предотвращения мошенничества.

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

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

1. Картографирование данных перед выбором решения по безопасности

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

Для каждого потока профиль должен давать ответы на следующие вопросы:

1. Какие данные передаются?

2. Для какой цели служат данные?

3. Какая система является источником эталонных данных?

4. Какая сторона определяет цели и способы обработки?

5. Какая сторона осуществляет обработку по соглашению?

6. Передаются ли данные через API, файлы или вводятся вручную?

7. Где и как долго хранятся данные?

8. Кто имеет права на просмотр, изменение, экспорт или удаление?

9. Передаются ли данные субпоставщикам или за пределы определенной зоны?

10. Что происходит при увольнении сотрудника или прекращении действия договора об оказании услуг?

Образец реестра данных

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

2. Сбор исключительно необходимых данных

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

Компания должна оценить каждое поле данных по четырем критериям:

• Будет ли EWA корректно выполнять свои функции без этого поля?

• Можно ли заменить полные данные справочным кодом, токеном или маскированными данными?

• Требуется ли постоянное хранение или достаточно использования в рамках одной сессии?

• Можно ли снизить детализацию или сократить срок хранения?

Три основных метода

Маскирование данных: отображение только части информации, например последних четырех цифр банковского счета.

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

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

Минимизация не означает нехватку данных для контроля. Системе по-прежнему необходимы ID транзакции, версия источника, временные метки и журналы для предотвращения дублирования выплат и проведения сверок.

3. Разграничение ролей и ответственности между сторонами

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

Матрица ответственности должна четко определять:

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

4. Строгая аутентификация без неудобств для сотрудников

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

Для сотрудников

• верификация личности при активации учетной записи;

• использование механизмов аутентификации, соответствующих уровню риска транзакции;

• требование усиленной проверки при смене устройства, платежных реквизитов или при обнаружении подозрительной активности;

• ограничение количества попыток ввода и обнаружение попыток подбора;

• отказ от использования легко угадываемых секретных вопросов;

• уведомления о новых входах в систему, изменении важных данных или проведении транзакций;

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

Для администраторов и операционного персонала

• обязательная многофакторная аутентификация (MFA);

• приоритет централизованного входа и индивидуальных учетных записей;

• запрет на использование общих административных аккаунтов;

• ограничение входа по устройству, сети или критериям риска при необходимости;

• предоставление прав с ограничением по времени для специальных задач;

• полная фиксация действий по просмотру, изменению, экспорту данных и изменению конфигураций.

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

5. Ролевой контроль доступа и принцип наименьших привилегий

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

Для операций с высоким уровнем риска следует применять разделение обязанностей или двухэтапное утверждение, например:

• изменение реквизитов получателя средств;

• разблокировка аккаунтов с признаками мошенничества;

• исправление уже завершенных транзакций;

• массовый экспорт данных;

• изменение правил лимитов;

• предоставление административных привилегий;

• удаление логов или данных транзакций.

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

6. Шифрование данных и управление ключами

Шифрование должно применяться как при передаче данных, так и при их хранении, однако простого «включения шифрования» недостаточно.

Компаниям необходимо проверить:

• зашифрованы ли соединения между приложениями, API, SFTP и системами управления;

• защищены ли базы данных, резервные копии, области хранения файлов и логи;

• хранятся ли ключи шифрования отдельно от самих данных;

• кто имеет право использовать, ротировать или отзыветь ключи;

• фиксируется ли активность доступа к ключам;

• как обрабатывается утеря или компрометация ключей;

• остаются ли экспортированные в CSV/Excel данные вне защищенной зоны.

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

7. Защита API и интеграционных потоков

API между системами учета рабочего времени, расчета зарплаты, EWA и платежными шлюзами — это пути передачи как данных, так и бизнес-команд (подробнее в разделе Интеграция EWA с учетом рабочего времени, расчетом зарплаты и ERP). Важные меры контроля включают:

• аутентификацию вызывающей системы и разграничение прав для каждой функции;

• проверку структуры, типов и ограничений входных данных;

• ограничение частоты запросов (rate limiting) и обнаружение аномального поведения;

• версионирование API и контролируемый процесс изменений;

• цифровую подпись или механизмы проверки webhook/callback;

• защиту от повторных запросов (replay attacks) с использованием временных меток, nonce или соответствующих ключей;

• idempotency_key (ключ идемпотентности) для команд создания транзакций;

• correlation_id для сквозного отслеживания между системами;

• коды ошибок, которые не раскрывают внутренние детали;

• контроль повторных попыток (retry), особенно когда результат перевода средств не определен.

При использовании пакетных файлов (batch) необходимо контролировать выделенный SFTP-аккаунт, шифрование файлов при необходимости, контрольные суммы (checksum), наименования пакетов, порядок обработки, дубликаты записей, файлы с частичными ошибками и сроки удаления файлов из промежуточной зоны.

Стандарт OWASP Application Security Verification Standard может использоваться в качестве основы для проектирования и тестирования средств защиты веб-приложений. Для мобильных приложений специализированным справочником требований к аутентификации, хранению, сети, коду и конфиденциальности является OWASP MASVS.

8. Журналы аудита: достаточность для расследования без превращения в источник утечки

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

Что следует фиксировать

• проверенные идентификаторы пользователей или администраторов;

• совершенные действия и объекты воздействия;

• стандартизированное время и часовой пояс;

• IP-адреса или признаки устройств согласно политике;

• статус успеха/неудачи и коды причин;

• transactionid, correlationid и версии данных;

• изменения прав, конфигураций, лимитов и реквизитов получения выплат;

• операции массового экспорта данных;

• события блокировки учетных записей или обнаружения аномалий.

Чего не следует записывать в исходном виде

• пароли, OTP и ключи доступа;

• полные номера счетов или удостоверений личности;

• содержимое запросов/ответов, содержащее полные кадровые досье;

• не аннулированные токены сессий;

• данные, не служащие целям мониторинга или расследования.

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

9. Управление устройствами, приложениями и сеансами

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

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

• вход с нового устройства;

• смена номера телефона;

• устройства с root/jailbreak правами или признаками вмешательства;

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

• вход одной учетной записи из разных локаций за короткий промежуток времени;

• запрос на получение средств сразу после смены платежной информации;

• длительные сеансы или повторное использование токенов.

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

10. Обнаружение мошенничества с соблюдением конфиденциальности

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

Некоторые бизнес-индикаторы могут включать:

• смену реквизитов для выплат с немедленным совершением транзакции;

• множественные неудачные попытки аутентификации;

• повторяющиеся запросы с аналогичным содержанием;

• транзакции, превышающие правила лимитов;

• аномальные изменения данных по отработанному времени перед транзакцией;

• слишком частую ручную поддержку одного аккаунта;

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

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

11. Резервное копирование, высокая доступность и восстановимость

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

Компаниям следует требовать:

• резервного копирования в соответствии с важностью каждого типа данных;

• шифрования и разделения прав доступа к резервным копиям;

• изолированных копий для ограничения влияния вирусов-вымогателей (ransomware);

• проверки возможности восстановления, а не только успешного создания бэкапов;

• согласованных сторонами целевых показателей времени восстановления (RTO) и точки восстановления (RPO);

• резервной архитектуры для критически важных компонентов;

• альтернативных операционных процедур при сбоях платформы EWA или платежных каналов;

• сохранения статуса транзакций с неопределенным результатом после восстановления системы.

Целевые показатели времени не должны рекламироваться в виде цифр до проведения измерений и официальных соглашений об уровне обслуживания (SLA).

12. Управление поставщиками и цепочкой поставок

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

Вопросы, которые следует задать до подписания договора

(См. также полный набор критериев в разделе Чек-лист выбора поставщика EWA.)

1. Какие именно группы данных обрабатывает поставщик?

2. Где хранятся данные и резервные копии?

3. Имеют ли субпоставщики доступ к данным?

4. Существует ли механизм предварительного уведомления о смене субпоставщиков?

5. По каким процедурам сотрудники поставщика обращаются к данным?

6. Применяются ли шифрование, управление ключами, MFA и изоляция сред?

7. С какими охватом и периодичностью проводятся тесты на проникновение (penetration testing)?

8. Как классифицируются и устраняются уязвимости?

9. Каковы сроки уведомления об инцидентах и контактные лица для координации?

10. Каким образом при расторжении договора данные и копии возвращаются или удаляются?

11. Каковы доказательства завершения полного удаления?

12. Каковы права компании на проверку, аудит или получение независимых отчетов?

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

13. Тестирование безопасности до и после запуска (go-live)

Единственного тестирования перед запуском недостаточно на протяжении всего жизненного цикла продукта (связано с 90-дневным планом пилотного внедрения EWA). Подходящая программа может включать:

• анализ архитектуры и модели угроз;

• проверку исходного кода и зависимых библиотек;

• сканирование уязвимостей приложений, серверов и конфигураций;

• тестирование API, веб- и мобильных приложений;

• тестирование разграничения прав по ролям;

• тестирование процедур восстановления учетных записей;

• тестирование на защиту от повторных транзакций и поддельных callback-ов;

• независимое тестирование на проникновение до запуска и после масштабных изменений;

• учения по реагированию на инциденты и восстановлению;

• мониторинг устранения уязвимостей до предоставления доказательств их закрытия.

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

14. Процедура реагирования на инциденты безопасности данных EWA

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

План реагирования (playbook) должен определять:

• что считать инцидентом и его уровень серьезности;

• кто имеет полномочия блокировать аккаунты, останавливать API или приостанавливать выплаты;

• способы сохранения логов, снимков систем (скриншотов/дампов) и доказательств транзакций;

• методы определения затронутых данных, пользователей и временных интервалов;

• контактных лиц по юридическим вопросам, HR, коммуникациям, безопасности и со стороны поставщика;

• основания, содержание и сроки уведомления компетентных органов или пострадавших лиц;

• критерии возобновления работы сервиса;

• план поддержки сотрудников в случае ошибочных транзакций;

• отчет о первопричинах (root cause analysis) и меры по предотвращению повторения.

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

15. Жизненный цикл данных: от создания до безопасного удаления

Каждой группе данных требуется собственный график хранения. «Хранить вечно на случай необходимости проверки» обычно увеличивает риски, не создавая дополнительной ценности.

Политика должна охватывать:

• данные, используемые в основной системе;

• резервные копии;

• промежуточные файлы;

• данные, экспортированные на пользовательские ПК;

• системные логи и логи безопасности;

• тестовые данные;

• данные у субпоставщиков;

• тикеты поддержки и вложения;

• данные уволенных сотрудников;

• данные после завершения действия договора оказания услуг.

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

16. Нормативно-правовая база Вьетнама, требующая внимания

На момент подготовки настоящей статьи Закон о защите персональных данных № 91/2025/QH15 был принят 26 июня 2025 года и вступил в силу 1 января 2026 года. Постановление № 356/2025/NĐ-CP, принятое 31 декабря 2025 года и вступившее в силу 1 января 2026 года, детально регламентирует исполнение ряда статей и мер реализации Закона.

Кроме того, в зависимости от бизнес-процессов компаниям необходимо учитывать Закон об электронной коммерции и электронных транзакциях № 20/2023/QH15, вступивший в силу 1 июля 2024 года; Постановление № 52/2024/NĐ-CP о безналичных расчетах и другие профильные нормативные акты.

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

17. Чек-лист безопасности перед утверждением внедрения EWA

Управление и правовые вопросы

• [ ] Назначен владелец программы EWA и ответственное лицо за информационную безопасность.

• [ ] Составлена карта данных и перечень систем/поставщиков, получающих данные.

• [ ] Определены роли, цели и ответственность сторон за обработку.

• [ ] Проверены уведомления, условия и механизмы реализации прав сотрудников.

• [ ] Установлены сроки хранения и процедуры удаления для каждой группы данных.

• [ ] Договор регламентирует инциденты, субпоставщиков, проверки и завершение услуг.

Идентификация и контроль доступа

• [ ] Сотрудники проходят верификацию при активации и изменении чувствительных данных.

• [ ] Администраторы обязаны использовать MFA и индивидуальные учетные записи.

• [ ] Права выдаются в соответствии с ролями, организационным периметром и обязанностями.

• [ ] Операции с высоким риском требуют двухэтапного утверждения или разделения обязанностей.

• [ ] Права регулярно пересматриваются и аннулируются при переходе на другую работу/увольнении.

Данные и интеграция

• [ ] Передаются только действительно необходимые поля.

• [ ] Конфиденциальные данные токенизируются или маскируются, где это возможно.

• [ ] Соединения и хранимые данные зашифрованы.

• [ ] Ключи и секреты управляются отдельно от исходного кода.

• [ ] API/webhook имеют аутентификацию, защиту от повторов и лимиты нагрузки.

• [ ] Транзакции обладают идемпотентностью и возможностью сквозного отслеживания.

Автор: Nguyen Tan Loc — специалист Стратегического департамента, ООО «Компания по обеспечению кадровыми ресурсами Nhan Kiet».

Консультация по решениям Lương Ngày для бизнеса: Горячая линия 0937.022.655 · Электронная почта info@nhankiet.vn · Lương Ngày для бизнеса