Безопасность – ШБР 2024

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

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

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

• Упоминается, что пользователь может добавлять кастомные заголовки и данные, что может привести к ошибкам в логике сервиса.  

• В микросервисной архитектуре важно минимизировать поверхность атаки, поэтому стоит задуматься о том, какие данные действительно нужно хранить и можно ли их уменьшить.  

• Рекомендуется использовать объектное хранилище данных, такое как стрибакет, для хранения аватарок, документов и контента пользователя.  

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

• Также стоит учитывать безопасность при хранении персональных данных, таких как номера телефонов и почты.  

• Секреты - это любая информация, необходимая для получения доступа, например, строки, пароли, токены, приватные ключи.  

• Не стоит хранить секреты в исходниках, так как они могут быть доступны в истории git.  

• Для хранения секретов можно использовать различные сервисы, такие как фолт или губернатор.  

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

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

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

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

• Использование карантина для обновления библиотек может помочь избежать проблем с безопасностью.  

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

• Важно уметь доносить риски до бизнеса и находить баланс между безопасностью и удобством использования.  

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

• Аутентификация может быть сложной проблемой, особенно в микросервисной архитектуре.  

• Рекомендуется использовать сложные пароли, хранить их в зашифрованном виде и использовать алгоритмы хэширования, такие как Argon2, для усложнения подбора паролей.  

• Защита от перебора может быть реализована по-разному, но есть недостатки, такие как блокировка аккаунта после определенного количества неверных попыток.  

• Антифрод может помочь в таких случаях, блокируя айпи-адрес, который слишком часто пытается войти с неправильными паролями.  

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

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

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

• Рекомендуется использовать аутентификацию и проверку прав доступа для обеспечения безопасности.  

• В видео обсуждается защита данных в API, где автор рассматривает пример с заказом пиццы.  

• Он объясняет, что если внешний пользователь подставит другой идентификатор, то это может привести к проблемам.  

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

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

• Автор также предлагает использовать декораторы для проверки прав доступа и ограничения количества запросов.  

• В видео также обсуждается ограничение количества запросов, чтобы предотвратить выгрузку всей пользовательской базы.  

• Автор предлагает использовать не инкрементальные идентификаторы, которые генерируются в большую длинную строку, что усложняет задачу злоумышленнику.  

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

• Автор предупреждает о проблемах с утечкой ключей, если они передаются в URL или в заголовках.  

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

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

• При стейтманс, данные пользователя не могут быть использованы для выполнения запросов, что повышает безопасность.  

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

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

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

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

• Длина и разнообразие символов в пароле не являются ключевыми факторами безопасности, важнее энтропия.  

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