Най-добри практики за безопасно съхраняване на API ключове

Снимка на Жозе Фонтано

В миналото видях много хора да използват Git хранилища, за да съхраняват чувствителна информация, свързана с техните проекти.

Напоследък виждам някои хора да обявяват, че съхраняват API ключове в личните си хранилища на GitHub. Пиша тази статия, защото хората трябва да разбират рисковете от съхраняването на API ключовете с вашия код.

Тази статия не е предназначена да бъде постоянно решение на проблемите, които може да имате при съхранение на API ключове. Вместо това е моят собствен анализ на проблема и моите предложения как да го отстраня.

И така, какъв точно е проблемът със съхранението на чувствителна информация в близост до вашия код в Git хранилище?

Защо не трябва да съхранявате API ключове в хранилища на Git

Съхраняването на API ключове или всяка друга чувствителна информация в git хранилище е нещо, което трябва да се избягва на всяка цена. Дори ако хранилището е частно, не трябва да го виждате като безопасно място за съхраняване на чувствителна информация.

Нека започнем с разглеждане защо е лоша идея да съхранявате API ключове в обществени git хранилища.

По своята същност обществено git хранилище може да получи достъп от всеки.

С други думи, всеки с интернет връзка има достъп до съдържанието на обществено хранилище на git. Не само това, но те също могат да преглеждат целия код в хранилището и евентуално дори да го стартират. Ако съхранявате API ключ в обществено хранилище, публикувате на открито, така че всеки да може да го види.

Неотдавнашно търсене на client_secret в GitHub разкри, че има повече от една 30 000 поръчки, които потенциално разкриват ключ и тайна на API. В някои случаи вие само копирате и поставяте кода за незабавен достъп до API.

Този проблем става толкова важен, че някои компании инвестират в ресурси, за да се уверят, че няма изтичащи ключове и тайни на API.

Миналата година Slack започна да търси открити токени на API и ги обезсилва проактивно. Това действие предотвратява злонамерен достъп до акаунти на Slack, но не може да намери всички изтеглени маркери.

Така че, това се случва в обществени хранилища на Git. Ами частните? Защо това е проблем?

Частните Git хранилища, хоствани на услуги като GitHub, GitLab и Bitbucket, са изложени на различен вид риск. Когато интегрирате приложение на трета страна с една от споменатите услуги, може да отваряте личните си хранилища за тези трети страни. Тези приложения ще могат да имат достъп до вашите частни хранилища и да четат информацията, съдържаща се в тях.

Макар че само по себе си не създава риск, представете си дали някое от тези приложения стане уязвимо за нападателите. Чрез получаване на неоторизиран достъп до някое от тези приложения на трети страни, нападателите могат да получат достъп до вашите чувствителни данни, включително API ключове и секрети.

И така, къде трябва да се съхраняват API ключовете?

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

Git-дистанционно gcrypt

Първото решение ви позволява да криптирате цяло Git хранилище. git-remote-gcrypt прави това чрез добавяне на функционалност към отдалечените помощници на Git, така че да има нов криптиран транспортен слой. Потребителите трябва само да настроят ново криптирано дистанционно и да натиснат код в него.

Прочетете, ако търсите по-фино решение, което ви позволява да криптирате отделни файлове.

Git-тайна

git-secret е инструмент, който работи на вашата локална машина и криптира конкретни файлове, преди да ги избутате в хранилището си. Зад кулисите, git-secret е скрипт с черупки, който използва GNU Privacy Guard (GPG) за криптиране и дешифриране на файлове, които може да имат чувствителна информация.

Git-крипта

Друго решение е git-crypt. Той е много подобен на git-secret по начина на работа, но има някои интересни разлики.

Първото нещо, което трябва да забележите при git-crypt, е, че това е двоичен изпълним файл, а не скрипт с черупки, както е git-secret. Това, че сте двоичен изпълним файл, означава, че за да го използвате, първо трябва да го компилирате или трябва да намерите двоична дистрибуция за вашата машина.

Ако използвате Mac, имате късмет, тъй като HomeBrew предлага готов за инсталиране пакет с git-crypt. Всичко, което трябва да направите, е да стартирате brew инсталирайте git-crypt на терминал.

Черна кутия

BlackBox е инструмент, създаден от Stack Overflow. Това е компанията, която стои зад популярните Q&A общности, като самия Stack Overflow, Server Fault и Super User. BlackBox е здрав инструмент, тъй като работи с Git, както и с други системи за контрол на версии като Mercurial и Subversion.

Той също така поддържа криптирането на малки низове и не само цели файлове. Това прави, когато работи с Puppet и използва Hiera на Puppet, инструмент за търсене на ключ-стойност за конфигурационни данни.

Възможността за криптиране и декриптиране на отделни низове прави BlackBox чудесно решение за осигуряване на API ключове и тайни.

Конфигурация на Heroku и конфигуриране на варианти

Ако работите с Heroku, не трябва да съхранявате никаква чувствителна информация като API ключове и секрети във вашите хранилища на Git. Heroku предлага решение, което ви позволява да задавате конфигурационни променливи.

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

Dokku, решение с отворен код като Heroku, предлага същите възможности.

Докер тайни

В края на спектъра от възможни решения са тайните на Докер. Това решение беше въведено от Докер през февруари 2017 г. То придобива популярност оттогава.

Докер тайните ви позволяват да дефинирате криптирани променливи и ги прави достъпни за конкретни услуги по време на изпълнение. Тайните са кодирани както по време на транзит, така и в покой.

Този подход прави Docker Secrets идеалното решение за съхраняване и използване на API ключове и тайни по защитен и криптиран начин.

резюме

Досега вече трябва да сте наясно с опасностите от съхраняването на чувствителна информация като API ключове и секрети в публични и частни Git хранилища.

Разбирането на потенциалните начини, по които могат да бъдат изложени вашите хранилища, е от ключово значение за оценка и смекчаване на рисковете, свързани с течове на информация.

Тази статия също предлага няколко различни решения, които ви позволяват да шифровате API ключове и секрети, така че да можете безопасно да използвате вашите кодови хранилища.

Сигурен съм, че има още решения, които могат да ви помогнат да постигнете същите резултати.