Построение архитектуры при интеграции алгоритмов шифрования в приложении для финансового учета
Привет! Меня зовут Алексей, я — разработчик. Здесь я расскажу о недавнем кейсе, в рамках которого мы реализовали нетипичное решение для обеспечения безопасной обработки данных. А также, сколько времени ушло на выбор оптимального архитектурного решения, и почему мы остановились на сложном в реализации методе шифрования.
Утечка данных 150 тыс. клиентов Совкомбанка, слив исходного кода Госуслуг, потеря данных более 8 млн. пользователей сервисов доставки еды — мне продолжать? Кажется, всё это — достаточно веские причины, чтобы задуматься о безопасности. Говоря о приложениях для финансового учета, вопрос сохранности данных стоит ребром.
Читать далееИсточник: Хабрахабр
Похожие новости
- Быстрый старт в маскировании данных PostgreSQL с инструментом pg_anon
- [Перевод] Свой среди чужих: насколько токсична рабочая среда безопасника?
- [Перевод] Обход двухфакторной аутентификации в публичной баг-баунти программе: путь к $6000
- Кратко про XHTTP для VLESS: что, зачем и как
- [Перевод] Как я нашёл уязвимость в ядре Linux при помощи модели o3
- SelfCoerce для локального повышения привилегий на Windows 10
- Теория мертвого 2GIS
- Постквантовые криптостандарты США на алгоритмы электронной подписи на основе хеш-функций с сохранением состояния
- Новые возможности менеджера секретов Deckhouse Stronghold: пространства имён, резервные копии и репликация данных
- [Перевод] Single Sign-On c OpenAM и OpenIG: практические примеры реализации