Настоящий CTO: думай как технический директор - Алан Уильямсон

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

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

12.1. Внесение исправлений

В программных продуктах, независимо от того, кто их разрабатывал, всегда присутствуют ошибки. Эти ошибки не преднамеренные, они возникают из-за того, что какой-то фрагмент недостаточно хорошо продумали или протестировали. Ошибки могут быть как безобидными – что-то не совсем правильно отображается – так и способными вызвать катастрофические последствия (в зависимости от проекта). Как только об ошибке станет известно, кто-нибудь обязательно придумает способ, как ее использовать, чтобы получить незаконное преимущество или выгоду, причинить ущерб или просто похвастаться.

Большинство проблем безопасности возникает по следующим причинам:

• Код некачественно разработан/протестирован.

• У обычной функции появился непредвиденный побочный эффект (как случилось, например, в конце 2021 года с библиотекой для логирования Apache Log4j, ниже мы расскажем об этом более подробно).

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

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

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

• планировать обновления.

12.1.1. Определение наличия исправлений

Для начала необходимо составить список всего ПО (включая библиотеки), которое используется в компании, с информацией о версиях. Этот список понадобится во многих случаях, его важность и работу и ним мы обсуждали в главе о документации. Если не следить за актуальностью этого списка, можно легко пропустить критическое обновление: вы не обратите на него внимания, думая, что оно к вам не относится.

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

Заметки с полей

Общеизвестные риски безопасности и уязвимости (Common Vulnerabilities and Exposures, CVE) https://www.cve.org/

CVE, онлайн-база данных всех известных уязвимостей, поддерживается с 1999 года, и каждый квартал в ней регистрируется около 5000 уязвимостей. Каждой из них присваивается номер CVE, по которому можно узнать подробное описание, уязвимые версии ПО и ссылки на решение, если оно есть. Этот ресурс – своего рода Википедия нарушений безопасности, и часто, когда вы читаете о проблеме в публичных источниках, вы видите ее номер CVE, по которому можно ознакомиться с техническими подробностями в этой БД. Хорошим вспомогательным сайтом является https://www.opencve.io/: на нем есть функции фильтрации обновлений и подписки на них.

Настройте автоматическое получение обновлений, чтобы их наличие не приходилось постоянно проверять. Будьте внимательны: периодически проверяйте, что ваша подписка работает. Параметры рассылок и уведомлений со временем могут меняться.

Хотя это обязанность вашего специалиста по информационной безопасности (Chief Information Security Officer, CISO), поощряйте других членов команды тоже следить за уязвимостями. Сигнальный огонь Гондора (во «Властелине колец») мог увидеть всего один человек, этого уже достаточно, чтобы забить тревогу.

12.1.2. Планирование

Узнать, какие обновления нужно установить, – это обычно легкая часть. Теперь нужно решить, когда это делать. Есть соблазн проигнорировать какие-то обновления как не относящиеся к вам. Это большая ошибка. Возьмите за правило устанавливать обновления, даже мелкие, часто, по крайней мере ежемесячно: это может повлиять на текущую работу, но защитит вас в долгосрочной перспективе. В идеале у вас должна быть возможность выполнять сине-зеленый деплой (см. главу 9), чтобы упростить тестирование исправлений/обновлений перед внедрением.

Обновления, особенно из проверенных источников, в 99 % случаев будут работать без сбоев. Но, каким бы высоким ни был этот показатель, не рассчитывайте на полное отсутствие проблем. Тестируйте, тестируйте и еще раз тестируйте. Используйте для проверки исправлений серверы для разработки или стейдж или, по крайней мере, выкладывайте обновления вместе с релизами вашего ПО. Так ваши тестировщики смогут обнаружить любые отклонения в поведении.

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

12.1.3. Особые случаи

Такое оборудование, как принтеры, сканеры и телевизоры, обычно не относится к компетенции технического директора, однако для него тоже нужно постоянно проверять наличие обновлений безопасности. Современные продукты (например, Google Chromecast/Nest) регулярно обновляются автоматически. Однако не все производители настолько прилежны. Сетевые маршрутизаторы и коммутаторы здесь требуют особого внимания, и способ получения информации об обновлениях для них не всегда очевиден.

Для некоторых устройств приходится вручную заходить в консоль управления и проверять наличие обновлений. Этим действием нельзя пренебрегать, и оно должно входить в обязанности сотрудников, ответственных за ИТ. Заведите привычку регистрировать такие проверки в общем журнале или отдельных журналах для каждого устройства. Любое устройство, подключенное к интернету, необходимо рассматривать как часть продакшена и уделять должное внимание его безопасности и управлению паролями, даже если оно не вызывает никакого беспокойства. Любое устройство в сети может быть атаковано. Если у устройства есть IP-адрес – оно является потенциальной угрозой.

ПРИМЕЧАНИЕ

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

12.2. Тестирование на проникновение

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

Как только тест на проникновение завершен, он уже устарел. Методы взлома постоянно совершенствуются, и нельзя считать себя неуязвимым только потому, что вы прошли тест. Кроме того, как только вы выпустили новый релиз вашего ПО – результаты всех предыдущих тестов на проникновение становятся неактуальными. Почему? Потому что вы не знаете, есть ли в новом релизе новая уязвимость или незащищенное место. Поэтому тестирование на проникновение необходимо проводить не разово или время от времени, а непрерывно и сделать его неотъемлемой частью вашего процесса непрерывной интеграции и деплоя.

Хороший тест на проникновение должен исследовать все уровни доступа. Самый очевидный из них – это доступ снаружи. Но к чему могут получить доступ или что могут испортить ваши сотрудники, имеющие расширенные права? Это следующие уровни тестирования безопасности, которые часто упускают из виду.

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

12.3. Социальная инженерия

Скорее всего, вы