API anahtarları gibi gizli bilgilerin kaynak kontrolünün dışında tutulması stratejisi?

Kullanıcıların Twitter, Google, vb. OAuth kimlik bilgilerini kullanarak giriş yapmalarına izin verecek bir web sitesinde çalışıyorum. çeşitli vücut parçalarına karşı rehinlerle korumak için. Anahtarım susturulursa, parça yanmış.

API anahtarının, çalışma zamanında kimlik doğrulama isteklerini gerçekleştirmek için kullanıldığı için kaynağımla seyahat etmesi gerekiyor. Benim durumumda, anahtar uygulama içinde bir yapılandırma dosyasında veya kodun içinde bulunmalıdır. Tek bir makineden oluşturup yayınladığımda sorun değil. Bununla birlikte, karışıma kaynak kontrolü attığımızda işler daha da karmaşıklaşıyor.

Ucuz bir piç olduğum için bulutta veya GitHub gibi TFS gibi ücretsiz kaynak kontrol hizmetlerini kullanmayı tercih ederim. Bu bana hafif bir bilmece bırakır:

API anahtarlarım kodumdayken ve kodum halka açık bir depoda olduğunda vücudumu nasıl koruyabilirim?

Bununla başa çıkmanın birkaç yolunu düşünebilirim, ancak hiçbiri tatmin edici değil.

• Tüm özel bilgileri koddan kaldırabilir ve dağıtımdan sonra yeniden düzenleyebilirim. Bu, uygulanacak ciddi bir acı olacaktır (birçok yolu ayrıntılandırmam) ve bir seçenek değildir.
• Şifreleyebilirim. Ancak şifresini çözmem gerektiğinden, kaynağı olan herkes bunun nasıl yapıldığını çözebilir. Anlamsız.
• Özel kaynak kontrolü için ödeme yapabilirim. Lol j / k para harcamak? Lütfen.
• Hassas özellikleri kaynağımın geri kalanından ayırmak için dil özelliklerini kullanabilir ve bu nedenle kaynak denetiminde tutabilirim. Şimdi ne yapıyorum, ama yanlışlıkla gizli dosyayı kontrol ederek kolayca berbat olabilir.

Gelişme, hata ayıklama ve konuşlandırma yoluyla sorunsuzca çalışacak ve aynı zamanda kusursuz davranacak özel ürünlerimi dünya ile paylaşmamamı (anlık görüntü dışında) da garanti etmenin gerçekten garantili bir yolunu arıyorum. Bu tamamen gerçekçi değil. Peki gerçekçi olarak ne yapabilirim?

_{Teknik detaylar: VS2012, C # 4.5, kaynak kontrolü ya TF servisi veya GitHub olacak. Şu anda, hassas tuşları kaynak kontrolüne eklenmeyecek ayrı bir .cs dosyasında bölmek için kısmi bir sınıf kullanıyor. GitHub, .gitignore'un kısmi sınıf dosyasının teslim edilmediğinden emin olmak için kullanılabileceği gibi bir avantaja sahip olabileceğini düşünüyorum, ancak bunu daha önce berbat ettim. "Ah, ortak bir sorun, bunu nasıl yaptığınız" umuduyla, ancak "sahip olabileceği kadar emmez" için yetinmek zorunda kalabilirim: /}

Gizli bilgilerinizi kodunuza koymayın. Başlangıçta kodunuzla okunan bir yapılandırma dosyasına yerleştirin. Yapılandırma dosyaları "fabrika varsayılanları" olmadıkça sürüm kontrolüne alınmamalı ve özel bilgileri içermemelidir.

Bunun nasıl yapıldığını öğrenmek için Sürüm kontrolü ve kişisel yapılandırma dosyası sorusuna da bakın .

Tüm özel / korumalı anahtarları sistem ortamı değişkenleri olarak koyabilirsiniz. Yapılandırma dosyanız şöyle görünecek:

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

Bu davaları böyle ele alıyoruz ve hiçbir şey koda girmiyor. Farklı özellik dosyaları ve profilleri ile birlikte çok iyi çalışıyor. Farklı ortamlar için farklı özellik dosyaları kullanıyoruz. Yerel geliştirme ortamımızda, yerel kurulumu kolaylaştırmak için geliştirme anahtarlarını özellik dosyalarına koyarız:

private.key=A_DEVELOPMENT_LONG_KEY

Saf Git yolu

• .gitignore özel veri içeren dosya
• Hangi değiştirmek, yerel bir şube kullanın TEMPLATEileDATA
• (Yerel) filtrenin komut dosyasının çift yönlü değiştirme gerçekleştirdiği lekeli / temiz filtreler kullanın TEMPLATE<->DATA

Mercurial yol

• Yerine kukla kod, üst üste MQ-yama (ler) TEMPLATEile DATA(changesets kamuya açıktır, yama özeldir)
• Özel tasarlanmış anahtar kelimelere sahip anahtar kelime uzantısı (yalnızca çalışma dizininizde genişletilmiş )

SCM-agnostik yol

• Anahtar kelimeleri değiştirme işleminin bir parçası olarak kullanın.

Sırları sonra işlediğim şifreli dosyalara koydum. Parola sistemi başlatıldığında verilir veya işlemediğim küçük bir dosyada saklanır. Emacs'in bu şifreli dosyaları neşeyle yönetmesi çok güzel. Örneğin, emacs init dosyası şunları içerir: (sadece "gizlis.el.gpg" yükle) çalışır - editöre başladığımda bu nadir görülen durumların şifresini ister. Birisinin şifreyi kırması konusunda endişelenmiyorum.

Bu çok Android / Gradle özgüdür, ancak içinde gradle.propertiesbulunduğunuz global dosyanızdaki anahtarları tanımlayabilirsiniz user home/.gradle/. Bu, buildType veya flavor'a bağlı olarak farklı özellikleri kullanabildiğinizden, yani dev için API ve sürüm için farklı olanlardan da yararlanabileceğiniz için de kullanışlıdır.

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"
            }
        }

Kodda buna benzer

String myAPI = BuildConfig.GOOGLE_VERIFICATION_API_KEY;

Bu anahtarı uygulamanızla dağıtmanız veya kaynak kod deposunda saklamanız gerekmiyor. Bu soru bunun nasıl yapılacağını soruyor ve normalde yapılan şey bu değil.

Mobil Web Uygulaması

Android / iPhone için, uygulama ilk çalıştırıldığında cihaz KEY'i kendi web servisinizden istemelidir. Anahtar daha sonra güvenli bir yerde saklanır. Anahtarın yayıncı tarafından değiştirilmesi veya iptal edilmesi gerekir. Web servisiniz yeni bir anahtar yayınlayabilir.

Barındırılan Web Uygulaması

Yazılımınızın lisansını kullanan müşterilerin, yazılımı ilk kez yapılandırırken anahtarı manuel olarak girmeleri gerekir. Herkese aynı anahtar, farklı anahtarlar verebilir veya kendi anahtarlarına sahip olabilirsiniz.

Yayınlanan Kaynak Kod

Kaynak kodunuzu genel bir depoda saklayabilirsiniz, ancak ANAHTAR değil. Dosyanın konfigürasyonunda satırları * yer anahtarını buraya * ekleyin . Bir geliştirici kaynak kodunuzu kullandığında, sample.cfgdosyanın bir kopyasını çıkarır ve kendi anahtarını ekler.

Eğer tutmuyorum config.cfgdepoda geliştirme veya üretim için kullanılan dosya.

Her sunucu için değişen gizli şeyler için ortam değişkenlerini kullanın.

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

Bunları nasıl kullanacağınız dile bağlıdır.

Bence bu, herkesin bir noktada sorun yaşadığı bir konu.

İşte kullandığım, sizin için işe yarayabilecek bir iş akışı. Bir bükülme ile .gitignore kullanır:

1. Tüm yapılandırma dosyaları özel bir klasöre gider (örnek yapılandırma dosyaları ile - isteğe bağlı)
2. Tüm konfigürasyon dosyaları .gitignore'a dahil edilmiştir, böylece herkese açık olmazlar
3. Özel bir kutuda bir gitolit sunucusu (veya favori git sunucunuz) kurun
4. Özel sunucudaki tüm config dosyalarıyla bir repo ekle
5. Yapılandırma dosyalarını ana depodaki özel klasöre kopyalamak için bir komut dosyası ekleyin (isteğe bağlı)

Artık config repo'yu herhangi bir geliştirme ve dağıtım sistemine kopyalayabilirsiniz. Dosyaları doğru klasöre kopyalamak için betiği çalıştırmanız yeterlidir.

Hala tüm GitHub şekerlerini alıyorsunuz, kodunuzu dünyayla paylaşıyorsunuz ve hassas veriler hiçbir zaman ana depoda değil, bu yüzden halka açılmıyorlar. Hala herhangi bir dağıtım sisteminden yalnızca bir çekip kopardılar.

Özel git sunucusu için 15 $ / yıllık bir kutu kullanıyorum, ancak cheapskate şartı uyarınca evde bir tane de ayarlayabilirsiniz ;-)

Not: Git alt modülünü de kullanabilirsiniz ( http://git-scm.com/docs/git-submodule ), ancak komutları her zaman unutuyorum, çok hızlı ve kirli kurallar!

Şifrelemeyi kullanın, ancak başlangıçta, konsolda bir şifre olarak, yalnızca işlemin kullanıcısını okuyabileceğiniz bir dosyada veya Mac OS anahtar zinciri veya Windows anahtar deposu gibi sistem tarafından sağlanan bir anahtar deposundan bir ana anahtar sağlayın.

Sürekli teslimat için bir yere kaydedilmiş çeşitli anahtarlar isteyeceksiniz. Yapılandırma koddan ayrı tutulmalıdır, ancak revizyon kontrolü altında tutulması çok mantıklıdır.

3 Henüz belirtilmeyen stratejiler (?)

Check-in veya VCS kontrolünde kancada ön kontrol

• yüksek entropiye sahip dizeleri aramak, example - detector -secrets
• regex iyi bilinen API anahtar kalıplarını araştırıyor. AWS'nin AKIA * anahtarları bir örnektir, git-secrets buna dayanan bir araçtır. Ayrıca sürekli atama ile 'şifre' gibi değişken isimler.
• bilinen sırları araştırın - sırlarınızı biliyorsunuz, onlar için metin arayın. Ya da bir araç kullanın, bu kavram kanıtını yazdım .

Daha önce bahsedilen stratejiler

• kaynak ağacın dışındaki dosyada sakla
• kaynak ağacında bulundurun, ancak VCS'ye bunu görmezden gelmesini söyleyin
• ortam değişkenleri, verilerin kaynak ağacın dışında depolanmasındaki bir varyasyondur.
• sadece geliştiricilere değerli sırları verme

Özel bilgileri kaynak kontrolünüzden uzak tutun. Dağıtım için yüklü olmayan bir varsayılan oluşturun ve VCS'nizin gerçek olanı yoksaymasını sağlayın. Yükleme işleminiz (kılavuz, yapılandırma / derleme veya sihirbaz) yeni dosyanın oluşturulmasını ve doldurulmasını işlemelidir. İsteğe bağlı olarak yalnızca gerekli kullanıcının (web sunucusu?) Okuyabilmesini sağlamak için dosya üzerindeki izinleri değiştirin.

Yararları:

• Geliştirme kuruluşu varsayılmıyor mu == üretim varlığı
• Tüm ortak çalışanların / kod gözden geçirenlerin güvenilir olduğunu varsaymaz
• Sürüm kontrolünün dışında tutarak kolay hataları önleyin
• KG / yapı için özel konfigürasyon ile kurulumları otomatikleştirmek

Zaten bunu yapıyorsanız ve yanlışlıkla kontrol ediyorsanız, projenize ekleyin .gitignore. Bu tekrar yapmayı imkansız hale getirir.

Orada olan özel depoları sağlamak etrafında serbest Git ana bol. Asla kimlik bilgilerinizi sürümlendirmemelisiniz, ancak ucuz ve özel repolarınız olabilir. ^ _ ^

OAuth anahtarının herhangi bir yerde ham veri olarak saklanması yerine, neden bazı şifreleme algoritmalarıyla dizgiyi çalıştırmıyorsunuz ve tuzlu bir karma olarak saklamıyorsunuz? Sonra çalışma zamanında geri yüklemek için bir yapılandırma dosyası kullanın. Bu şekilde, anahtar bir geliştirme kutusunda veya sunucunun kendisinde depolanmış olsun, hiçbir yerde depolanmaz.

Sunucunuz otomatik olarak istek üzerine yeni bir tuzlu ve karma API anahtarı oluşturacak şekilde bir API bile oluşturabilirsiniz, böylece ekibiniz bile OAuth kaynağını göremez.

Düzenleme: Belki Stanford Javascript Kripto Kütüphanesi deneyin, bazı oldukça güvenli simetrik şifreleme / şifre çözme için izin verir.