Comments 22
Давайте зайдём с другой стороны: а что должно быть вместо реального токена, ключа и т.п.? — всё равно в тестах, описании, комментах будет тестовый, отозванный токен, либо его имитация вида ABCD-1234-EF56.
Выносить ключи и токены из кода в конфиги, которые подкладывать вручную в bin.
В репозитории конфиг держать без чувствительной информации, заменив токены пустыми строками, например.
Всегда было интересно, а кто где хранит боевые ключи и токены до их подкладывания вручную? Есть какие-то общие решения или каждый изобретает свой велосипед?
Кажется, нам нужен токен-репозиторий. Нужно только решить, где хранить ключи от него.
В нашем проекте они хранятся в приватном репозитории. В коде можно встретить такое:
Соответственно, если кто-то посторонний хочет собирать сам, он должен создать у себя локально нужную структуру каталогов и положить токен в secret_key.h:
#include "../../../miranda-private-keys/Dropbox/secret_key.h"
…
data.AppendFormat("&client_id=%s&client_secret=%s", DROPBOX_APP_KEY, DROPBOX_API_SECRET);
Соответственно, если кто-то посторонний хочет собирать сам, он должен создать у себя локально нужную структуру каталогов и положить токен в secret_key.h:
#define DROPBOX_API_SECRET «abcdefghijklm»
Можно маунтить директорию с шифрованием. Ключи один раз положил потом просто маунт
Мы обычно их Environment variable выносим.
Если приложение работает в Kubernetes, то можно использовать средства хранения ключей, предоставляемые платформой — Kubernetes Secrets. При этом в репозиториях ключи не хранятся от слова совсем, и один и тот же код, запускаясь в разных средах (dev, staging, prod — кто во что горазд), будет видеть разные ключи в специальном каталоге, видимом из их контейнера.
Если нужно всё по-серьёзному, с аудитом доступа к ключам, то можно использовать Google Cloud Key Management Service. Тогда собственно секреты хранятся на серверах клиентов (Google их даже не знает), но зашифрованными ключами, хранящимися в Google. Такое вот комбо.
Если нужно всё по-серьёзному, с аудитом доступа к ключам, то можно использовать Google Cloud Key Management Service. Тогда собственно секреты хранятся на серверах клиентов (Google их даже не знает), но зашифрованными ключами, хранящимися в Google. Такое вот комбо.
Мы vault используем
Мы vault используем
Для AWS есть pre-commit hook — нужно просто не лениться и поставить github.com/awslabs/git-secrets
Если open-source приложение устанавливается на компьютер или другое устройство клиента, то какой смысл держать API key в тайне?
а 81% так и не были удалены в течении срока наблюденияЧто не обязательно свидетельствует о их уязвимости — отсутствие реакции может быть обусловлено тем что:
1) Ключ изначально был не рабочим (отозван, просто случайный набор букв для примера)
2) Рабочий ключ поменяли после сообщения, а старый просто оставили в репозитории.
3) Это ключ для демо-доступа, который и должен быть всем доступен
Меня удивляют люди, публикующие свой приватный ключ.
Недавно я объяснил то, что должно быть понятно без пояснений:
Как можно не понимать столь самоочевидные вещи?!
Недавно я объяснил то, что должно быть понятно без пояснений:
Полагаю, вам понятен смысл слов «приватный разговор» и «публичное заявление»: содержание приватного разговора не должно стать известно посторонним, содержание же публичного заявления должно стать известно широкому кругу людей. Разница между приватным ключом и публичным ключом такая же: приватный ключ следует спрятать и не показывать никому, а публичный ключ можно опубликовать (эти слова не случайно однокоренные).
Как можно не понимать столь самоочевидные вещи?!
Уверен вы иногда вслух произносите конфиденциальную информацию, подразумевая что рядом стоящие ничего не понимают о чём идёт речь
Меня удивляет то, что это удивляет других. Ведь теория всегда ясна и понятна. На то она и теория.
Но есть ещё практика. И там есть такая штука, которая называется «человеческий фактор», «человеческая ошибка» и банальное «забыл».
Уверен, что многие ключи вышли «в свет» именно по этой причине. Например, если бы этот автор в момент публикации увидел вопрос «are you sure you want to publish your private key?», то он с уверенностью ответил бы отказом.
Но есть ещё практика. И там есть такая штука, которая называется «человеческий фактор», «человеческая ошибка» и банальное «забыл».
Уверен, что многие ключи вышли «в свет» именно по этой причине. Например, если бы этот автор в момент публикации увидел вопрос «are you sure you want to publish your private key?», то он с уверенностью ответил бы отказом.
UFO just landed and posted this here
Sign up to leave a comment.
Они просканировали GitHub