Стратегія для збереження секретної інформації, такої як ключі API, поза контролем джерела?

Я працюю над веб-сайтом, який дозволить користувачам входити в систему за допомогою облікових даних OAuth, подібних до Twitter, Google тощо. Для цього мені потрібно зареєструватися у цих різних провайдерів і отримати супер секретний ключ API, який у мене є захищати заставою від різних частин тіла. Якщо мій ключ зірветься, частина розірветься.

Ключ API повинен подорожувати з моїм джерелом, оскільки він використовується під час виконання для виконання запитів аутентифікації. У моєму випадку ключ повинен існувати в програмі у файлі конфігурації або в самому коді. Це не проблема, коли я створюю і публікую з однієї машини. Однак, коли ми кидаємо контроль джерел у суміш, справи ускладнюються.

Оскільки я дешевий ублюдок, я вважаю за краще скористатися послугами безкоштовного контролю джерел, такими як TFS у хмарі або GitHub. Це залишає у мене невелику головоломку:

Як я можу зберегти своє тіло недоторканим, коли в моєму коді є ключі API, а мій код доступний у загальнодоступному сховищі?

Я можу придумати кілька способів вирішити це, але жоден із них не задовольняє.

• Я міг видалити всю приватну інформацію з коду та відредагувати її назад після розгортання. Це було б дуже сильним болем (я не буду деталізувати багато способів), і це не варіант.
• Я міг би це зашифрувати. Але оскільки я маю це розшифрувати, кожен із джерелом міг зрозуміти, як це зробити. Безглуздо.
• Я міг би заплатити за контроль над приватними джерелами. LOL j / k витрачати гроші? Будь ласка.
• Я можу використовувати мовні функції для відокремлення чутливої ​​інформації від решти мого джерела і тому зберігати її від контролю джерела. Це я зараз роблю, але це можна було легко викрутити, помилково перевіривши в секретному файлі.

Я дійсно шукаю гарантований спосіб переконатися, що я не поділяюсь з приватними особами зі своїм світом (за винятком Snapchat), який буде працювати безперебійно через розробку, налагодження та розгортання, а також бути надійним. Це абсолютно нереально. То що реально я можу зробити?

_{Технічні деталі: VS2012, C # 4.5, управління джерелом буде або TF-послугою, або GitHub. В даний час використовується частковий клас для розділення чутливих клавіш на окремий файл .cs, який не буде додано до керування джерелом. Я думаю, що GitHub може мати перевагу, оскільки .gitignore може бути використаний, щоб переконатися, що файл часткового класу не зареєстрований, але я це вже накрутив. Я сподіваюся на "о, поширене питання, ось як ви це робите", але, можливо, мені доведеться вирішити "те, що не смокче стільки, скільки може",: /}

Не вкладайте у свій код секретну інформацію. Помістіть його у файл конфігурації, який читається вашим кодом при запуску. Файли конфігурації не повинні ставитись на контроль версій, якщо вони не є "заводськими налаштуваннями", і тоді вони не повинні мати приватної інформації.

Дивіться також питання управління версіями та особистий файл конфігурації, як зробити це добре.

Ви можете розмістити всі приватні / захищені ключі як змінні системного середовища. Ваш файл конфігурації виглядатиме так:

private.key=#{systemEnvironment['PRIVATE_KEY']}

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

private.key=A_DEVELOPMENT_LONG_KEY

Pure Git шлях

• .gitignore включений файл із приватними даними
• Використовуйте місцевого відділення, в якому ви замінюєте TEMPLATEзDATA
• Використовуйте фільтри розмазання / очищення, в яких сценарій (локального) фільтра виконує двосторонню заміну TEMPLATE<->DATA

Меркурійський шлях

• MQ-патч (а) на верхній частині манекена коду, який замінить TEMPLATEз DATA(ревізій є відкритими, пластир приватний)
• Розширення ключових слів зі спеціально розробленими ключовими словами (розширено лише у вашому робочому каталозі )

СКМ-агностический спосіб

• Замініть ключові слова як частину процесу складання / розгортання

Я вкладаю секрети в зашифровані файли (файли), які я потім фіксую. Фраза пропуску надається під час запуску системи або вона зберігається у невеликому файлі, який я не ввожу. Приємно, що Emacs весело керує цими зашифрованими файлами. Наприклад, файл emacs init включає: (завантажувати "secrets.el.gpg"), який просто працює - підказуючи мені пароль для тих рідкісних занять, коли я запускаю редактор. Я не переживаю за те, щоб хтось порушив шифрування.

Це дуже специфічно для Android / Gradle, але ви можете визначити ключі у вашому глобальному gradle.propertiesфайлі, розташованому в user home/.gradle/. Це також корисно, оскільки ви можете використовувати різні властивості залежно від buildType або смаку, тобто API для розробника та інший для випуску.

gradle.properties

MY_PRIVATE_API_KEY=12356abcefg

build.gradle

buildTypes {
        debug{
            buildConfigField("String", "GOOGLE_VERIFICATION_API_KEY", "\"" + MY_PRIVATE_API_KEY +"\"")
            minifyEnabled false
            applicationIdSuffix ".debug"
            }
        }

У коді ви посилаєтесь так

String myAPI = BuildConfig.GOOGLE_VERIFICATION_API_KEY;

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

Мобільний веб-додаток

Для Android / iPhone пристрій повинен запитувати КЛЮЧ у власної веб-служби під час першого запуску програми. Потім ключ зберігається у безпечному місці. Якщо ключ буде змінений або скасований видавцем. Ваша веб-служба може опублікувати новий ключ.

Розміщений веб-додаток

Клієнти, які використовують ліцензію вашого програмного забезпечення, повинні будуть вводити ключ вручну під час першої настройки програми. Ви можете дати всім один і той же ключ, різні ключі або вони отримають свої.

Опублікований вихідний код

Ви зберігаєте свій вихідний код у загальнодоступному сховищі, але не в KEY. У конфігурації файлу ви додаєте сюди рядки * клавіша місця * . Коли розробник використовує ваш вихідний код, він робить копію sample.cfgфайлу і додає свій власний ключ.

Ви не зберігаєте свій config.cfgфайл, який використовується для розробки або виробництва у сховищі.

Використовуйте змінні середовища для секретних речей, які змінюються для кожного сервера.

http://en.wikipedia.org/wiki/Environment_variable

Як їх використовувати, залежить мова.

Я думаю, це питання, з яким у когось виникли проблеми.

Ось я використав робочий процес, який може працювати для вас. Він використовує .gitignore з поворотом:

1. Всі файли конфігурації переходять у спеціальну папку (без конфігураційних файлів без вибірки - необов'язково)
2. Усі файли конфігурації включені у .gitignore, щоб вони не оприлюднили
3. Налаштуйте сервер gitolite (або ваш улюблений сервер git) на приватній коробці
4. Додайте репо з усіма конфігураційними файлами на приватному сервері
5. Додайте скрипт для копіювання конфігураційних файлів у спеціальну папку в основній репортажі (необов’язково)

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

Ви все ще отримуєте всі цукерки GitHub, діліться своїм кодом зі світом, і конфіденційні дані ніколи не є головним репо, тому вони не публікуються. Вони все ще є лише потягом та копією від будь-якої системи розгортання.

Я використовую коробку 15 $ на рік для приватного сервера git, але ви також можете налаштувати його вдома, відповідно до вимоги chepskate ;-)

PS: Ви також можете використовувати підмодуль git ( http://git-scm.com/docs/git-submodule ), але я завжди забуваю команди, тому швидкі та брудні правила!

Використовуйте шифрування, але вкажіть головний ключ при запуску, як пароль на консолі, у файлі, який може читати лише користувач процесу, або з наданого системою сховища ключів, як брелок Mac OS або Windows Key Store.

Для безперервної доставки вам потрібно буде десь записати різні ключі. Конфігурація має бути відмежована від коду, але має сенс тримати її під контролем редагування.

3 стратегії, ще не згадані (?)

Під час заїзду або попередньої реєстрації VCS у гачку

• пошук рядків з високою ентропією, приклад- виявлення-секрети
• regex пошук добре відомих ключових шаблонів API. Приклади клавіш AKIA * AWS - приклад, git-secrets - це один із інструментів, заснований на цьому. Також імена змінних на зразок "пароль" з постійним призначенням.
• шукати відомі секрети - ви знаєте свої секрети, шукайте їх текст. Або скористайтеся інструментом, я написав це підтвердження концепції .

Стратегії, вже згадані

• зберігати у файлі поза вихідного дерева
• є у вихідному дереві, але скажіть VCS ігнорувати його
• змінні середовища - це варіація зберігання даних поза деревом-джерелом
• просто не дайте цінних секретів розробникам

Не тримайте приватну інформацію поза контролем джерела. Створіть для завантаження не завантажений за замовчуванням і нехай ваш VCS ігнорує справжній. Ваш процес встановлення (будь то керівництво, налаштування / збирання чи майстер) повинен керувати створенням та заповненням нового файлу. Необов’язково змінюйте дозволи на файл, щоб переконатися, що його може прочитати лише потрібний користувач (веб-сервер?)

Переваги:

• Не передбачає, що організація розвитку == виробнича особа
• Не передбачає, що всі співпрацівники / рецензенти коду довіряють
• Запобігайте легким помилкам, не допускаючи контролю версій
• Легко автоматизувати встановлення з власною конфігурацією для QA / build

Якщо ви вже робите це і випадково перевіряєте це, додайте його до свого проекту .gitignore. Це зробить неможливим знову.

Навколо є багато безкоштовних хостів Git, які надають приватні сховища. Хоча вам ніколи не слід вносити версії своїх облікових даних, ви можете бути дешевими і мати приватні репости теж. ^ _ ^

Замість того, щоб ключ OAuth зберігався як вихідні дані скрізь, чому б не запустити рядок через якийсь алгоритм шифрування і не зберегти його як солений хеш? Потім використовуйте файл конфігурації, щоб відновити його під час виконання. Таким чином ключ ніде не зберігається, чи він зберігається у вікні розробки, чи на самому сервері.

Ви навіть можете створити API таким чином, що ваш сервер автоматично генерує новий засолений і хешований ключ API на основі запиту, таким чином навіть ваша команда не може бачити джерело OAuth.

Редагувати: Можливо, спробуйте Бібліотеку криптовалют Стенфорда , це дозволяє зробити досить безпечне симетричне шифрування / дешифрування.