Защита пользовательских данных в приложениях

Регулярно мы встречаем новости, что в том или ином сервисе произошла утечка и пользовательские данные доступны в даркнете/телеграме/где_то_еще. Не так давно была утечка из сервиса 23andMe, основанного женой Сергея Брина и я решил написать пост на основе личного опыта защиты данных. Сразу скажу, что поскольку мой основной стек технологий - Ruby on Rails, то и ссылки я давал на соответствующие библиотеки/сервисы, но вы (я уверен) сможете найти подходящие инструменты для того стека, с которым вы работаете.

1. Шифрование данных в БД. Несмотря на то, что в rails есть свой инструмент, работающий из коробки - ActiveRecord Encryption, но лично я предпочитаю сторонние библиотеки от Andrew Kane - lockbox и blind_index, позволяющие не только данные в БД шифровать, но и загружаемые файлы.
2. Настройки аутентификации. Для rails-приложений самым распространенным решением для аутентификации является devise (гусары, являющиеся фанатами bcrypt, sorcery и других решений, молчать!), поэтому можно добавить дополнительный функционал проверки паролей (запрет использования ранее установленных паролей, напоминание о смене пароля спустя некоторое время и другие) с помощью devise_security.
3. Pwned. Еще одним популярным инструментом является проверка пароля на наличие его в утечках с помощью сервиса HaveIBeenPwned, поэтому конечно же есть соответствующие библиотеки - devise-pwned_password и pwned (для тех, кто не использует devise).
4. Для того, чтобы избежать brute force я использую rack-attack от команды Kickstarter, но судя по всему - в rails8 будет доступен аналогичный функционал из коробки.
5. Еще одним инструментом борьбы с brute force я бы назвал грамотно настроенный fail2ban, блокирующий на уровне firewall любителей перебирать пароли или ищущих что-то типа /wp-admin на вашем сервере (особенно когда у вас нет вордпресса)
6. Раз уж я упомянул любителей сканировать продукты на предмет уязвимостей, то вот еще пара полезных инструментов. brakeman - сканер уязвимостей и bundler_audit - сканер уязвимостей в зависимостях.
7. Разумеется, имеет смысл мониторить все попытки получения доступа к сервису — как успешные, так и не очень. В этом может помочь authrail от ранее упомянутого Andrew Kane - вообще мега-продуктивный товарищ, если посмотреть на его github-аккаунт.
8. Чтобы скрыть видимость столбцов БД, содержащих различные данные, которые не стоит разглашать — есть отличная библиотека hypershield, она скрывает всё, что encrypted, password, token и secret и не только их :)
9. Стоит обратить внимание на 2FA (двух-факторную аутентификацию) и Passkeys как дополнительные способы защиты доступа к приложению.
10. Ну и конечно же не забываем про человеческий фактор — при увольнении человека удаляем все его доступы в систему, меняем ключи к сервисам, к которым он имел доступ и внимательно следим за возможными утечками и происходящим в логах.
    

Если вы сочтёте эту информацию полезной, то welcome в мой телеграм канал @angry_beard и блог https://alec-c4.com. Также буду рад помочь вам личной консультацией на Solvery.