Rivalry2

HTML Diff

0 added 0 removed

Original 2026-01-01

Modified 2026-02-21

1 <a>#статьи</a>

2 <ul><li>5 июл 2022</li>

3 <li>0</li>

4 </ul><h2>Типичные ошибки безопасности в разработке ПО - и как с ними справиться</h2>

5 Где дают слабину IT-компании, чем опасен Open Source и как SRE-инженерам дружить с безопасниками.

6 Иллюстрация: Катя Павловская для Skillbox Media

7 Журналист, коммерческий автор и редактор. Пишет про IT, цифровой маркетинг и бизнес. Сайт:<a>darovska.com</a>.

8 Head of Security в <a>ManyChat</a>Armenia. Любит спорт - в частности, баскетбол и горный трекинг.

9 Типичные ошибки безопасности в разработке ПО со временем меняются. Организация<a>OWASP</a>, которая существует с 2001 года, отслеживает тренды и актуальные ошибки в разработке сайтов и приложений, в том числе мобильных. Раз в несколько лет она проводит исследование и публикует материалы с новыми актуальными ошибками. Последнее обновление<a>OWASP Top 10</a>было в 2021 году.

10 Сейчас в топе такие угрозы безопасности:

11 <ul><li>неправильная реализация систем аутентификации и авторизации;</li>

12 <li>ошибки конфигурации компонентов приложения;</li>

13 <li>атаки server-side request forgery, когда через внешний сервер идёт атака на внутреннюю инфраструктуру.</li>

14 </ul>Различные виды инъекций всегда были в топе, а сейчас их популярность немного снизилась, потому что многие фреймворки из коробки реализуют защиту от них. Встроенные механизмы защиты просто не дают разработчикам совершать подобные ошибки.

15 Эти ошибки и подробные рекомендации по их устранению публикуются в комьюнити OWASP.

16 Хакеры, как и все люди, движутся по пути наименьшего сопротивления. Если они видят незакрытую админку с паролем сотрудника из последней утечки какого-нибудь онлайн-сервиса, они этим воспользуются, ведь многие сотрудники переиспользуют пароли. А такой взлом гораздо проще, чем поиск сложных уязвимостей в ходе многомесячных исследований кода.

17 Чтобы отразить базовую, ненаправленную атаку, когда злоумышленник не владеет большим количеством ресурсов для нападения на вашу компанию, зачастую будет достаточно соблюдения элементарных правил кибергигиены:

18 <ul><li>использовать VPN для доступа к критичным сервисам;</li>

19 <li>использовать агенты<a>EDR</a>на рабочих станциях и серверах;</li>

20 <li>установить антивирусы и средства защиты на компьютерах;</li>

21 <li>использовать антиспам-системы, которые помогают фильтровать фишинговые письма;</li>

22 <li>настроить MFA (multi-factor authentication) для доступа к критичным системам и админкам;</li>

23 <li>своевременно устанавливать патчи для разных элементов системы - ОС, приложений, серверного ПО;</li>

24 <li>сканировать системы на известные уязвимости;</li>

25 <li>обновлять сторонние опенсорс-библиотеки, когда для них появляются исправления уязвимостей.</li>

26 </ul>Многие корпорации тратят миллионы долларов на безопасность, но при этом не выполняют простых правил кибергигиены. Об этом свидетельствуют последние инциденты - например, в Microsoft в 2019 году ошибка в конфигурации сервера без пароля<a>привела к утечке</a>огромного количества данных из облачной системы.

27 Фото: Drazen Zigic / ShutterstockКогда компании забывают обучать сотрудников правилам безопасности, самый простой и дешёвый путь вторжения - фишинговая атака. Провести её можно за 30 минут: создаётся форма, которая напоминает личный кабинет, и быстро рассылаются письма со ссылкой на неё. А дальше - чем больше компания, тем выше вероятность, что кто-то из пользователей введёт в эту форму свой логин и пароль.

28 IT-инфраструктура - основа всего технического стека, поэтому отдел безопасности очень плотно взаимодействует с подразделением, которое занимается инфраструктурой.

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

30 Kubernetes, операционные системы, сетевое оборудование, облачные провайдеры - сейчас во все компоненты IT-инфраструктуры заложено огромное количество встроенных механизмов безопасности, и чаще всего это довольно сложные сущности - гораздо сложнее кнопок "Вкл" и "Выкл". Так что в них тоже нужно серьёзно вникать, разбираться, как они работают, - чтобы понимать пользу и негативные последствия включения каждого механизма.

31 Например, если сайт поддерживает старый протокол TLS 1.0, мы можем довольно легко его отключить, но нужно понимать, что для какого-то процента клиентов со старыми операционными системами наш сайт перестанет работать.

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

33 Так что и в большой, и в маленькой инфраструктуре IT-специалист должен дружить с безопасностью. Хотя в большой компании могут быть тысячи серверов, а в компании поменьше - десятки, но и там и там будут ресурсы, которые нужно защищать.

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

35 Я работаю в ManyChat - это относительно небольшая международная компания. До ManyChat я работал в корпорации с 70 тысячами сотрудников и поэтому хорошо понимаю разницу в подходах к безопасности.

36 У SaaS-компаний чёткий фокус на облачные решения, внутреннюю инфраструктуру и бизнес-системы. Есть множество облачных средств защиты, которые довольно быстро внедряются. Иногда они даже эффективнее и безопаснее внутренних, потому что ими пользуется большее число клиентов. Также в SaaS-компаниях сильнее упор на безопасную разработку и анализ кода.

37 Фото: Andrey_Popov / ShutterstockВ больших организациях все системы стараются сделать внутренними, в крайнем случае используют CRED-облака. У такого подхода своя специфика в части выстраивания систем защиты. Часто они и вовсе отдают R&D-отделы либо в дочерние организации, либо на аутсорс. Сейчас этот тренд постепенно уходит, но тем не менее часто разработку не рассматривают как основную деятельность.

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

39 И в маленькой компании вклад безопасников может быть куда серьёзнее. Например, когда "Фейсбук"* покупал WhatsApp, в том было всего 50 сотрудников и несколько сотен серверов, но они обслуживали миллионы клиентов. Если мы делаем антифрод-систему, то она и в большой, и в небольшой компании может защищать миллионы клиентов - в зависимости от специфики.

40 Сейчас без опенсорса не развивается практически ни один продукт. Он используется всюду: и в критичных, и в коммерческих системах - в том же Chrome куча свободных библиотек и различных внешних компонентов. А ведь все эти библиотеки взаимосвязаны и могут иметь уязвимости.

41 И на самом деле, с безопасностью открытых библиотек постоянно возникают проблемы. Есть даже регулярно обновляемые списки "опасных" библиотек - их публикуют вендоры, которые занимаются безопасностью опенсорсных либ. Воздействия, скрытые в таких библиотеках, делятся на два вида:

42 <ul><li>Лозунги.Например, вывести сообщение всем пользователям поверх всех окон.</li>

43 <li>Вредительство.Например, удалить данные, когда библиотека видит, что её скачивают с определённых IP-адресов.</li>

44 </ul>Чтобы внести изменения в опенсорсный продукт, достаточно закоммитить несколько строчек кода. Отследить их гораздо сложнее, потому что опенсорса в зависимостях почти у каждого IT-решения сейчас очень много. Например, React подключает много различных внешних библиотек, как, впрочем, и другие фреймворки.

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

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

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

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

49 Но иногда и в опенсорсном ПО, которое разрабатывается по двадцать лет, всё равно находят серьёзные уязвимости. Например, так случилось несколько лет назад с опенсорс-библиотекой OpenSSL: она разрабатывалась десятилетиями, но в ней всё равно нашли критичные уязвимости, несмотря на огромное комьюнити разработчиков.

50 Плохой практикой также считаетсяsecurity by obscurity, когда безопасность достигается за счёт того, что информация о том, как реализована система безопасности, не предоставляется.

51 Если мы используем операционную систему, но не имеем доступа к исходному коду, то не знаем, как в ней реализованы механизмы безопасности. В этом плане опенсорс лучше. Но нужно соблюдать правила безопасности:

52 <ul><li>не обновляться сразу до последней версии;</li>

53 <li>не делать автообновлений;</li>

54 <li>использовать инструменты software composition analysis - типа Snyk, Black Duck и других.</li>

55 </ul>* Решением суда запрещена "деятельность компании Meta Platforms Inc. по реализации продуктов - социальных сетей Facebook и Instagram на территории Российской Федерации по основаниям осуществления экстремистской деятельности".

56 <a>Бесплатный курс по Python ➞Мини-курс для новичков и для опытных кодеров. 4 крутых проекта в портфолио, живое общение со спикером. Кликните и узнайте, чему можно научиться на курсе. Смотреть программу</a>