Не так давно Uber пришлось выплатить компенсацию в размере 148 миллионов долларов за утечку данных, в результате которой были раскрыты данные около 57 миллионов водителей.
Виновник?
Жестко закодированный секрет, опубликованный в открытом доступе для использования любым злоумышленником.
Фон
Сегодня миллионы разработчиков программного обеспечения хранят свои секреты (то есть учетные данные, такие как ключи доступа и токены для служб, используемых программами) в файлах .env.
Для тех, кто не знаком с этим вопросом, файлы .env были представлены в 2012 году как часть решения жестко запрограммированной секретной проблемы, упомянутой во вступительном абзаце выше.
Вместо того, чтобы отправлять секреты вместе со своей кодовой базой в облако, разработчики теперь могут отправлять свою кодовую базу в облако и хранить свои секреты отдельно на своих машинах в формате ключ-значение в файлах .env; это разделение снизило риск того, что злоумышленники получат доступ к конфиденциальным учетным данным в облаке.
Чтобы запускать программы, разработчикам теперь нужно было просто загрузить свою последнюю кодовую базу из облака и внедрить секреты, содержащиеся в их локальных файлах .env, в извлеченный код.
Если только команда разработчиков не является небольшой и «разрозненной», не особо заботящейся о DevOps, она обычно поддерживает несколько «сред» для своей кодовой базы, чтобы убедиться, что изменения тщательно протестированы перед отправкой в производство для взаимодействия с конечными пользователями. В случае нескольких сред разработчики могут использовать несколько файлов .env для хранения учетных данных, по одному для каждой такой среды (например, один файл .env для хранения ключей базы данных разработки, а другой — для ключей рабочей базы данных).
Подводя итог, файлы .env содержат учетные данные в формате ключ-значение для служб, используемых программой, которую они создают. Они предназначены для локального хранения, а не для загрузки в репозитории кода онлайн для всеобщего ознакомления. Каждый разработчик в команде обычно имеет один или несколько файлов .env для каждой среды.
Применение
В этом разделе мы рассмотрим, как использовать файл .env в базовом проекте, предполагая, что вы используете Node.js и git для управления версиями; это должно применяться и к другим языкам. Не стесняйтесь пропустить этот раздел, если вас не интересуют технические аспекты использования файла .env.
Для начала перейдите в корень папки вашего проекта и создайте пустой файл .env, содержащий учетные данные, которые вы хотите внедрить в свою кодовую базу. Это может выглядеть примерно так:
SECRET_1=”924a137562fc4833be60250e8d7c1568" SECRET_2=”cb5000d27c3047e59350cc751ec3f0c6"
Затем вы захотите игнорировать файл .env от фиксации в git. Если вы еще этого не сделали, создайте файл .gitignore. Это должно выглядеть так:
.env
Теперь, чтобы внедрить секреты в свой проект, вы можете использовать популярный модуль, такой как dotenv; он проанализирует файл .env и сделает ваши секреты доступными в вашей кодовой базе под объектом процесса. Идем дальше и устанавливаем модуль:
npm install dotenv --save
Импортируйте модуль в верхней части стартового скрипта для вашей кодовой базы:
require(‘dotenv’).config()
Вот и все — теперь вы можете получить доступ к секретам в любом месте вашей кодовой базы:
process.env.SECRET_1 // injects the value of SECRET_1 into your code
Большой. Вы успешно добавили в свой проект файл .env с некоторыми секретами и получили доступ к этим секретам в своей кодовой базе. Кроме того, когда вы отправляете свой код через git, ваши секреты останутся на вашем компьютере. Если у вас есть какие-либо вопросы, не стесняйтесь писать мне по электронной почте [email protected].
Проблемы впереди
Несмотря на простоту и мощь, файлы .env могут создавать проблемы при неправильном управлении в контексте более крупной команды.
Представьте себе, что вам нужно распространять и отслеживать сотни ключей для вашей команды разработчиков программного обеспечения; в нашем предыдущем стартапе под названием Auledge, в котором, кстати, было только 3 разработчика программного обеспечения, работающие над 3 репозиториями кода, мы обнаружили, что работаем с 40+ ключами и уже увязли в этом.
На упрощенном уровне между Бобом и Алисой может произойти следующее:
- Боб может добавить ключ API в свой локальный файл .env и забыть сообщить Алисе, чтобы она добавила его в свой; это стоило Алисе 15 минут в будущем на отладку, почему ее код дает сбой, только чтобы понять, что это из-за отсутствующего ключа API.
- Алиса может попросить Боба отправить ей ключ API, чтобы она могла добавить его в свой файл .env, после чего Боб может отправить его по тексту или по электронной почте; это теперь без необходимости подвергает их организацию риску того, что злоумышленники, такие как Алиса, ждут именно того, чтобы перехватить ключ API.
К сожалению, эти проблемы распространены и даже имеют название: тайное разрастание.
Как бы проблематично это ни было, секретное разрастание файлов .env остается огромной проблемой, не имеющей решения по умолчанию для разработчиков по всему миру.
В последние годы многие компании пытались решить эту проблему. HashiCorp Vault — это продукт, который надежно хранит секреты для крупных предприятий; это, однако, слишком дорого, громоздко и, откровенно говоря, излишне, чтобы настроить его для среднего разработчика, которому просто нужен быстрый и безопасный способ хранения этих секретов.
Существуют более простые решения, такие как Doppler и новое dotenv-vault, но им часто не хватает инфраструктуры безопасности, необходимой для массового внедрения.
Решение
Что необходимо, так это простое в использовании, безопасное и универсальное решение против разрастания секретов.
Нам нужны команды, чтобы иметь возможность синхронизировать и управлять множеством файлов .env, которые бродят вокруг их рабочей силы разработчиков, таким образом, чтобы это было доступно для всех, а не только для крупных корпораций, у которых могут быть выделенные люди и средства для оплаты дорогих и сложных решений.
В Infisical мы решаем проблему разрастания секретов по-другому, сосредоточившись на одновременной простоте и безопасности; мы думаем, что правильное решение — это то, которое можно настроить за считанные минуты и которое будет настолько безопасным, что даже мы не сможем прочитать чьи-либо секреты.
Наш секрет заключается в том, чтобы предложить знакомый git-подобный интерфейс с командами push/pull со сквозным шифрованием (E2EE) для синхронизации и управления файлами .env.
Станьте компонуемым: создавайте приложения быстрее, как Lego
Bit – это инструмент с открытым исходным кодом для модульного и совместного создания приложений. Перейдите на компоновку, чтобы поставлять быстрее, более последовательно и легко масштабировать.
Создавайте приложения, страницы, пользовательский опыт и пользовательские интерфейсы как автономные компоненты. Используйте их, чтобы быстрее создавать новые приложения и возможности. Используйте любой фреймворк и инструмент в своем рабочем процессе. Делитесь, повторно используйте и сотрудничайте, чтобы строить вместе.
Помогите своей команде:
→ Совместное использование кода и повторное использование
→ Монорепо
