

ЧТО ТАКОЕ СЕКРЕТ?
ГОСТ Р 56939-2024 под секретами определяет «данные, которые могут использоваться для обеспечения аутентификации и/или целостности и/или конфиденциальности информации (пароли, цифровые сертификаты и т. п.)».
Секреты могут быть представлены также и иными данными, например платёжными: номерами карт, счетов, пинами и прочим. Подобную «живую» информацию хранить в коде, конфигурационных файлах или фикстурах совершенно нежелательно.
ПОЧЕМУ ЭТО ВАЖНО
Исходные коды приложений находятся под стражей специалистов по безопасности. Тем не менее приложения, собранные из этих кодов, регулярно разворачиваются на сторонние площадки или публикуются (очевидный пример — мобильные приложения), а сами исходные коды хранятся на рабочей технике разработчиков. Угроза внутреннего злоумышленника и утечки исходных кодов сохраняется актуальной для любой организации.
Наличие чувствительной информации в приложении может позволить злоумышленнику использовать её для получения доступов в целях кражи персональных данных, поддержания цепочки взломов, фишинга, распространения вредоносного ПО или иных целей.
Одним из примеров реализации подобного вида атаки является декомпиляция мобильных приложений из публичных площадок с целью извлечения доступов к его публикации, размещённых разработчиками по неосторожности, что позволяет подменить оригинальное приложение приложением с полезной нагрузкой. Аналогичным образом получаются доступы к API используемых сервисов, SMS-шлюзам, ключам доступа к платёжным сервисам, которые случайно забыла разработка.
СТАТИСТИКА
Показательной является статистика открытого кода из свежего отчёта The State of Secrets Sprawl 2024:
К сожалению, ревью кода и средства идентификации секретов в коде до публикации изменений применяются не всеми и совершить подобную ошибку случайного добавления может каждый.
ПОСТРОЕНИЕ БАЗОВЫХ ПРОЦЕССОВ РАБОТЫ С СЕКРЕТАМИ
Важно контролировать, чтобы секреты не попадали в исходные коды приложений, хранились и обрабатывались соответствующим образом.
Во-первых, должно быть организовано пространство хранения и предоставления секретов смежным приложениям. Для этого есть специальные системы управления секретами («паролешницы»), например открытый Vault.
Во-вторых, следует настроить блокирующую проверку секретов на стороне разработки. Это могут быть такие открытые и «лёгкие» статические анализаторы, как GitLeaks, TruffleHog, DeepSecrets или иные, которые уже устоялись в экспертной практике и позволяют легко настраивать правила анализа. Независимо от уровня применяемого инструмента следует приготовиться к разбору ложноположительных срабатываний, если не предлагается специальных механизмов интеллектуального анализа. К примеру, наша лаборатория показала, что можно натренировать модель машинного обучения, которая с ходу идентифицирует 50–70% ложноположительных срабатываний. А если проводить дообучение этой модели на контекстных данных проектов, то результат стремится к 90–95%, что существенно экономит время специалистов РБПО на разбор срабатываний.
В-третьих, если всё-таки утекло или возникли подозрения, то должна быть разработана чёткая процедура отзыва и инвалидации утёкших секретов. Не говоря уже о том, что секреты должны ротироваться и вообще подчиняться определённой ролевой модели использования.
Безусловно, всё, что вы придумаете и настроите, должно быть закреплено в регламенте по работе с секретами. Или наоборот, но регламент должен работать, а не лежать.
ВЫВОДЫ
Можно разработчику сильно не доказывать, что секреты в коде — это неправильная инженерная культура. Ошибки совершают все. Но правильный процесс и инструментарий для контроля секретов должны быть реализованы.
Отправляя данную форму вы соглашаетесь с политикой конфиденциальности персональных данных
Отправляя данную форму вы соглашаетесь с политикой конфиденциальности персональных данных