Управление закрытыми ключами с помощью систем контроля версий

VPS | Amber | Комментировать запись

Системы контроля версий (VCS) являются неотъемлемой частью большинства современных технологий разработки программного обеспечения. Системы типа Git, Mercurial, Bazaar, Perforce, CVS и Subversion позволяют разработчикам сохранять снапшоты истории проектов (что улучшает совместную работу над кодом), вернуться к предыдущим состояниям, восстановить случайные изменения кода и управлять несколькими версиями кодовой базы. Эти инструменты позволяют нескольким разработчикам совместно работать над одним и тем же проектом.

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

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

Проверка конфиденциальных данных в репозитории Git

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

Сканирование проектов

Если вы точно знаете, какое значение нужно найти в проекте, вы можете использовать функцию поиска VCS, чтобы проверить, присутствует ли оно в файлах. Например, с помощью git можно найти определенный пароль:

git grep my_secret $(git rev-list –all)

Эта команда проверит весь проект на наличие этой строки.

Для более широкого поиска секретных данных существует ряд специализированных инструментов. Такие инструменты, как gitrob, могут просканировать каждый репозиторий организации GitHub и найти имена файлов, которые указаны в предопределенном списке. Проект git-secrets может локально сканировать репозитории на наличие определенных закрытых ключей (как в путях файлов, так и в контенте). Инструмент truffleHog ищет в репозиториях строки с высокой энтропией, которые, вероятно, будут сгенерированными секретными ключами. Чтобы объединить некоторые из этих функций в один инструмент, был разработан git-all-secrets; он реализует все вышеупомянутые функции в едином интерфейсе.

Стратегии смягчения

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

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

В любом случае вы должны поменять свои скомпрометированные учетные данные. Для этого вы можете полностью удалить эти данные или файл из своей истории VCS. Это особенно важно для конфиденциальных данных, которые нельзя изменить, и для любых пользовательских данных, которые были непреднамеренно раскрыты в коде. Чтобы удалить данные из репозиториев, нужно перезаписать историю VCS и удалить файл из предыдущих коммитов. Это можно сделать с помощью встроенных команд git или специальных инструментов. Важно отметить, что даже если вы удалите всю запись данных из репозитория, любой, кто ранее скопировал базу кода, все равно сможет получить доступ к конфиденциальным данным. Помните об этом при оценке степени воздействия на код.

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

Защита конфиденциальных данных с помощью VCS

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

Игнорирование секретных файлов

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

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

Хуки VCS

Большинство современных реализаций VCS включают так называемые «хуки» для выполнения сценариев до или после определенных действий в репозитории. Эта функция может использоваться для выполнения сценария, который проверит обновляемый код на наличие секретных данных. Ранее упомянутый инструмент git-secrets имеет возможность устанавливать хуки pre-commit, которые реализуют автоматическую проверку типа контента. Вы можете добавить свои собственные сценарии, чтобы определить, какие шаблоны нужно защитить.

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

Добавление файлов в промежуточную область

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

Хранение зашифрованных конфиденциальных данных в репозитории

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

Инструменты шифрования

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

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

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

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

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

Преимущества

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

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

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

Недостатки

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

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

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

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

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

Управление секретными данными с помощью систем контроля версий

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

Реализация

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

Аналогичным образом, система хранения «ключ-значение» Puppet Hiera может использовать Hiera eyaml для безопасного управления секретными данными конкретных компонентов инфраструктуры. В отличие от других систем, Hiera eyaml знает синтаксис и структуру YAML (это формат сериализации данных, который использует Hiera), что позволяет шифровать только конфиденциальные данные, а не весь файл. Это позволяет работать с файлами, которые содержат зашифрованные данные, используя обычные инструменты для выполнения большинства задач. По мере подключения новых серверов команды могут внедрять шифрование GPG, чтобы легко управлять доступом.

Saltstack использует Pillars для хранения данных, предназначенных для определенных машин. Чтобы защитить эти элементы, пользователи могут зашифровать значения YAML с помощью GPG, а затем настроить рендеринг GPG, чтобы позволить Salt расшифровать значения. Подобно Hiera eyaml, эта система поддерживает шифрование только конфиденциальных данных, а не полного файла, что позволяет другим функциям работать правильно.

Ansible включает Ansible Vault, систему шифрования и инструмент командной строки для шифрования конфиденциальных файлов YAML в структуре плейбуков. Затем Ansible может расшифровывать секретные файлы во время выполнения, чтобы объединить секретные и несекретные данные, необходимые для выполнения текущих задач. Ansible vault шифрует весь файл, а не только секретные значения, поэтому при редактировании инструменты дешифрования не должны отображать точную информацию об изменении. Однако в Ansible 2.3 в файлах можно шифровать отдельные переменные, а пользователи могут выбрать, как они хотят шифровать конфиденциальные значения.

Преимущества

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

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

Недостатки

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

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

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

Внешние сервисы управления секретными данными

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

Реализация

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

Его ключевые функции:

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

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

Keywhiz – это еще один специализированный сервис, используемый для обеспечения общей безопасности конфиденциальных данных. Как и Vault, Keywhiz предоставляет API, которые клиенты и пользователи могут использовать для хранения и доступа к данным. Одна уникальная особенность Keywhiz – это возможность раскрывать секретные данные с помощью FUSE, виртуальной файловой системы, которую клиенты могут монтировать для доступа к конфиденциальным данным в виде псевдофайлов. Этот механизм позволяет различным типам программ получать доступ к необходимым им данным без помощи агента или оболочки, также это позволяет администраторам блокировать доступ, используя обычные привилегии файловой системы Unix.

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

Преимущества

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

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

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

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

Недостатки

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

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

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

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

Заключение

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

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