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

записи сотрудника ночью или попытку доступа к недавно удаленной учетной записи. Уровень детализации будет зависеть от вашей организации и от данных, за которые вы отвечаете.

12.7. Безопасная разработка

Компаниям, занимающимся разработкой и внедрением ПО, особенно важно обеспечить безопасность:

• исходного кода, который они разрабатывают;

• процесса сборки и внедрения ПО.

12.7.1. Создание безопасного исходного кода

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

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

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

В зависимости от языка программирования низкое качество кода влияет на продукт по-разному. В языках, которые требуют от разработчика ручного управления памятью, риск атак с использованием переполнения буфера выше, чем в языках с автоматическим управлением памятью. Другой пример – печально известные «SQL-инъекции», когда один оператор SQL может быть преобразован в несколько операторов путем подстановки в него специально подобранного значения.

SQL-ИНЪЕКЦИЯ: ЧТО ЭТО ТАКОЕ

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

stmt = "SELECT id, email FROM table X WHERE name='" + inputFromUser + "'";

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

Что, если в поле ввода на сайте вместо слова noah ввести "2'; TRUNC X; " и отправить этот запрос в API? В результате будет собрана строка, содержащая две отдельных команды SQL, которые будут выполняться одна за другой (при условии, что библиотека для работы СУБД разрешает это, а в большинстве случаев она разрешает). Первая команда SQL выберет записи, в которых поле «имя» имеет значение 2; это не вызовет никаких проблем. Однако вторая команда, "TRUNC X", удалит все строки таблицы X. После некоторого количества проб и ошибок злоумышленник может устроить хаос в вашей базе данных.

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

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

Вы можете снизить риски, обучая свою команду программистов, внедряя стандарты разработки и проводя внимательное ревью кода. Инструменты контроля качества кода (такие как SonarQube) могут выявлять некоторые типовые проблемы и постоянно совершенствуются, но никогда не заменят взгляд опытного человека.

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

Взлом Log4j, конец 2021 г.

В современном мире, где все переплетено и взаимосвязано, сочетание функций разных систем может создать уязвимости даже без явных ошибок разработчиков, и ничто не иллюстрирует эту проблему лучше, чем история с популярной библиотекой журналирования Log4j. Компания Tenable, специализирующаяся на кибербезопасности, назвала ее «самой большой и самой критичной уязвимостью за последнее десятилетие». Сторонний пользователь мог запустить на уязвимых машинах произвольный код путем простой записи в журнал специально сформированной строки; так работала библиотека, которая фиксировала в журналах поисковые запросы, пользовательский ввод или сообщения из чата. И этот функционал был заложен в нее разработчиками, но никто не подумал, что ее будут использовать для обработки небезопасных строк – вот непредвиденные последствия лучших намерений.

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

12.7.2. Защита процесса сборки

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

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

Если пайплайн сборки не защищен, кто-нибудь может внести в него небольшие изменения. Точно так же, если доступ к вашей системе контроля версий не ограничен надлежащим образом или вы используете небезопасный менеджер зависимостей (например, Maven или npm, где не фиксируется конкретная версия библиотек), то вы рискуете задеплоить код, не зная, что на самом деле у него внутри.

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

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

12.8. «Нас атакуют»

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

• Атака с целью вызвать отказ вашей системы.

• Скачивание данных.

• Удаление или шифрование данных.

• Несанкционированный вход в систему.

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

12.8.1. Аварийное отключение

Вместо того чтобы дожидаться атаки и только после ее начала решать, что делать, заранее пройдитесь по всей вашей системе и продумайте способы реагирования, или аварийные выключатели (kill switch). Это цифровые версии переборок на корабле, которые предназначены не только для обеспечения жесткости, но еще и для герметизации и изоляции, чтобы одна пробоина в корпусе не могла затопить весь корабль. (Если переборки спроектированы неправильно, они создадут больше проблем, чем решат, как это было в случае с RMS Titanic – и, раз уж мы заговорили об этом, в фильме «Титаник» на плоту хватило бы места для двоих!)

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

Утечка данных как из пожарного шланга

У одного из клиентов, с которыми мы работали, была интеграция со сторонним платежным сервисом. Часть интеграции заключалась в том, что API клиента получал уведомление об успешном завершении платежа. Используя