Bir web sitesinin gizli değerlerini çevre değişkenleri olarak koymanın avantajları nelerdir?


24

Https://12factor.net/config adresindeki devops kuralları, web sitesi sırlarını (veritabanı şifreleri, api anahtarları vb.) Çevre değişkenlerine koymanızı önerir. Sürüm kontrolü tarafından göz ardı edilen metin dosyalarını (JSON, XML, YAML, INI veya benzeri) kullanmak yerine ne gibi avantajları var?

Bir konfigürasyon dosyasını sırlarla kopyalamak, ortam değişkenlerini .bash_profile ve web sunucusu konfigürasyonunda kullanmaktan çok daha kolay buluyorum. Bir şey mi özledim?


1
Teoride bir dosyayı okumak hafızadan daha kolaydır, böylece saldırı yüzeyini daha büyük ve karmaşıklığın daha küçük olduğunu düşünebilirsiniz.
Florin Asăvoaie

Dev ops adamımın kural kuralı, ortam değişkenlerinde ayarların saklanmasının sadece liman işçisi ortamlarında yapılması en iyisi olduğudur. Konteyner VM'leri dışında, 12factor.net'in diğer tüm noktalarını ve config dosyalarının kullanımını onaylar / tercih eder. Hiçbirimiz düzenli sunucu dağıtımlarında ortam değişkenlerinin güvensiz doğasını sevmedik.
Corey Ogburn,

Yanıtlar:


21

Yazar birazcık ayrık olmasına rağmen akıl yürütmelerini listeler. Bunların birincil argümanı, bir yapılandırma dosyasını yanlışlıkla kontrol etmenin kolay olduğu ve yapılandırma dosyalarının farklı biçimlerde olduğu ve sistemin etrafına dağılmış olabileceğidir (üçü de, kimlik belirteçleri ve kimlik bilgileri gibi güvenlikle ilgili yapılandırma için en iyi sıradan argümanlardır).

Kendi tecrübelerime göre, esas olarak, aşağıdaki avantaj ve dezavantajları olan aşağıdaki üç seçeneğe sahipsiniz:

Verileri config dosyalarında saklayın.

Bu yaklaşımı uygularken, onları ideal olarak havuzun kendisinden izole etmeli ve uygulamanın içinde bulunduğu alanın dışında olduklarından emin olmalısınız.

Avantajları:

  • Özellikle genel sistem güvenliğini artırmak için SELinux veya AppArmor gibi şeyler kullanıyorsanız, erişimi yalıtmak ve kontrol etmek çok kolaydır.
  • Teknik olmayan kullanıcılar için değiştirilmesi genellikle kolaydır (bu, yayınlanmış yazılımlar için bir avantajdır, ancak kuruluşunuza özgü yazılımlar için zorunlu değildir).
  • Büyük sunucu gruplarında yönetmesi kolaydır. Yapılandırma dağıtımı için her türlü araç var.
  • Kullanılan tam yapılandırmanın ne olduğunu doğrulamak oldukça kolaydır.
  • İyi yazılmış bir uygulama için, genellikle yapılandırma dosyasını güncelleyerek ve ardından uygulamaya belirli bir sinyal göndererek (genellikle SIGHUP) servisi kesmeden yapılandırmayı değiştirebilirsiniz.

Dezavantajları:

  • Verileri güvende tutmak için doğru planlama gereklidir.
  • Farklı biçimler öğrenmek zorunda kalabilirsiniz (bu günlerde endişelenmeniz gereken sadece bir avuç var ve genelde benzer bir sözdizimi var).
  • Kesin depolama konumları uygulamada kodlanmış olabilir ve bu da konuşlandırmanın potansiyel olarak sorunlu olmasını sağlar.
  • Config dosyalarının ayrıştırılması problemli olabilir.

Verileri ortam değişkenlerinde saklayın.

Genellikle bu, başlangıç ​​betiğindeki ortam değişkenlerinin ve değerlerin bir listesini alarak yapılır, ancak bazı durumlarda bunları programın adından önce komut satırında belirtebilir.

Avantajları:

  • Bir config dosyasını ayrıştırmaya kıyasla, bir ortam değişkeninden bir değer çıkarmak, hemen hemen her programlama dilinde önemsizdir.
  • Yanlışlıkla yapılandırmayı yayınlamaktan endişelenmenize gerek yok.
  • Bu uygulama alışılmadık olduğundan ve uygulamanızı hackleyen çoğu insan derhal çevre değişkenlerine bakmayı düşünmeyeceklerinden dolayı, gizlilikten bir dereceye kadar güvenlik elde edersiniz.
  • Erişim, uygulamanın kendisi tarafından kontrol edilebilir (çocuk işlemlerine başladığında, hassas bilgileri kaldırmak için çevreyi kolayca ovalayabilir).

Dezavantajları

  • Çoğu UNIX sisteminde, bir işlemin ortam değişkenlerine erişmek oldukça kolaydır. Bazı sistemler bunu azaltmanın yollarını sağlar ( örneğin, LInux'taki hidepidbağlama seçeneği /proc), ancak bunlar varsayılan olarak etkin değildir ve sürece sahip olan kullanıcının saldırılarına karşı koruma sağlamaz.
  • Yukarıda belirtilen güvenlik sorununu doğru kullanırsanız, bir şeylerin tam olarak kullandığı ayarları görmek önemsizdir.
  • Uygulamaya, alt süreçler ortaya çıktığında çevreyi ovma konusunda güvenmelisiniz, aksi takdirde bilgi sızdırır.
  • Uygulamayı tamamen yeniden başlatmadan konfigürasyonu kolayca değiştiremezsiniz.

Verileri iletmek için komut satırı değişkenlerini kullanın.

Cidden, her ne pahasına olursa olsun, bu kaçının, güvenli değil ve kıçını korumak için bir acı.

Avantajları:

  • Çoğu dilde ortam değişkenlerinden ayrıştırılması daha da kolaydır.
  • Alt işlemler otomatik olarak verileri devralmaz.
  • Uygulamayı geliştirirken belirli yapılandırmaları hızlı bir şekilde test etmek için kolay bir yol sağlar.

Dezavantajları:

  • Çevre değişkenleri gibi, çoğu sistemde başka bir işlemin komut satırını okumak kolaydır.
  • Yapılandırmayı güncellemek çok sıkıcı.
  • Yapılandırmanın ne kadar süreceği konusunda katı bir sınır koyar (bazen 1024 karakter kadar düşük).

1
Önemsiz olmayan bir nokta, bir sunucunun katılımsız (yeniden) önyüklemesi, manuel olarak herhangi bir şifre vermek zorunda kalmadan, sonunda disk için bir yerde oldukları
PlasmaHH

7
Çoğu UNIX sisteminde, önemli ayrıcalıklara ihtiyaç duymadan, hemen hemen tüm süreç ortam değişkenlerini okuyabilirsiniz. - Bunu genişletebilir misin? / Proc / #### / environ dosyası yalnızca sahibi tarafından okunur, bu nedenle root olmanız veya sudo olması gerekir.
rrauenza

Sanırım bu env yapılandırma trendinin bir kısmı da standart bir kap kullandığınız ve env değişkenlerini kabın içine geçirerek yapılandırdığınız docker gibi şeylerden kaynaklanıyor.
rrauenza

@ rrauenza Bir işlemi hesaba göre çok iyi bir iş yapmadığınız sürece önemli bir ayrıcalık değildir ve aslında siz sahibi değilseniz CAP_SYS_ADMIN yeteneğine (dolaylı olarak sahip olduğu) ihtiyacınız vardır. Ayrıca, ortam değişkeniyle ilgili olarak, muhtemelen haklısınız, ancak Docker ile bile marjinal bir tasarım.
Austin Hemmelgarn

3
@Rrauenza'nın yaptığı noktaya katılıyorum. Cevap her yerde oldukça güzel, ancak herhangi bir önemli ayrıcalıklara ihtiyaç duymadan, herhangi bir süreç ortam değişkenini tam olarak nasıl okuyabileceğiniz konusunda netlik istiyorum . " Ve aslında sadece CAP_SYS_ADMIN yeteneğine ihtiyaç duyuyorsun (o da kök kökü var) ..." peki, kötü niyetli bir ajanın kök ayrıcalıkları varsa, daha fazla tartışma gereksiz ve CAP_SYS_ADMIN de kök ayrıcalık olabilir (bkz. Man7.org/linux /man-pages/man7/capabilities.7.html , CAP_SYS_ADMIN ve çekirdek geliştiricilere verilen notlar )
Nubarke

13

Ortam değişkenleri, web sunucusunun her alt işlemiyle miras alınır. Sunucuya bağlanan her oturum ve bunlar tarafından oluşturulan her program. Sırlar bu işlemlerin tümüne otomatik olarak açıklanacak.

Sırları metin dosyalarında tutarsanız, bunların sunucu işlemi tarafından okunabilir olması ve bu nedenle potansiyel olarak her alt işlem tarafından da okunması gerekir. Ancak en azından programlar gidip bulmalı; otomatik olarak sağlanmazlar. Ayrıca bazı alt işlemlerin farklı hesaplar altında çalıştırılmasını ve sırların yalnızca bu hesaplar tarafından okunabilir olmasını sağlayabilirsiniz. Örneğin, suEXEC bunu Apache'de yapar.


1
"Bu sunucuya bağlanan her oturum" yanıltıcı bir ifadedir. Sunucuya bir http oturumu açamaz ve ortam değişkenlerine erişemezsiniz, ne de root erişiminiz olmadıkça veya web sunucusu işlemine sahip olmadığınız sürece, o sunucudaki bir kabukta oturum açamaz ve bunları alamazsınız.
Segfault

Aksi takdirde aktif adımlar atmazsanız, web sunucusu tarafından oluşturulan her işlem kendi ortamını devralır. Bir HTML sayfasının bu bilgileri kullanma özelliği yoktur, ancak bir komut dosyası kullanır.
Andrew Schulman

Doğru olsa da, bu cevap, özellikle dönem oturumlarıyla ilgili bazı düzeltmeler / imtiyazlar ile yapılabilir . İlk olarak, dış müşterilere bilgi ifşa etme olasılıkları önermek için çevre değişkenlerinin kullanımını kötü bir ışık altında boyadığı görülüyor. Ayrıca, suexec ile karşılaştırılabilir bir imtiyaz, sınırlı bir env-vars ayarı için örneğin bir işlem başına env-vars (a la MYVAR=foo /path/to/some/executable) ayarlanması , bir işlemin ilerlemesini sınırlar - ve sadece çocuklar için çocuk süreçlerinin çevresi.
shalomb

2

Çevre değişkenleri veya dosyalar söz konusu olduğunda yapılacak güvenlikle ilgili bazı ticari işlemler olsa bile, güvenliğin bu öneri için ana itici güç olduğunu sanmıyorum. 12factor.net'in yazarlarının ayrıca Heroku PaaS'ın (ya da??) Geliştiricileri olduğunu da unutmayın. Herkesin çevre değişkenlerini kullanmalarını sağlamak muhtemelen gelişimlerini biraz kolaylaştırmıştır. Farklı yapılandırma dosya formatları ve konumlarında çok fazla çeşitlilik var ve hepsini desteklemesi zor olacaktı. Çevre değişkenleri karşılaştırıldığında kolaydır.

Yapılan konuşmaların bazılarını tahmin etmek çok fazla hayal gücü gerektirmez.

Geliştirici A: "Ah, bu gizli yapılandırma dosyası kullanıcı Arabirimi çok fazla dağınık! Gerçekten de json, xml ve csv arasında geçiş yapan bir açılan pencereye ihtiyacımız var mı?"

Geliştirici B: "Uygulama konfigürasyonu için yalnızca herkes çevre değişkenleri kullandıysa, hayat çok büyük olurdu."

Geliştirici A: "Aslında bunu yapmak için güvenlikle ilgili bazı olası nedenler var. Ortam değişkenleri muhtemelen yanlışlıkla kaynak kontrolüne alınmayacak."

Geliştirici B: "Ortam değişkenlerini, arka plan programı başlatan bir komut dosyasıyla veya bir yapılandırma dosyasıyla ayarlamıyor musunuz?"

Geliştirici A: "Heroku'da değil! Onları kullanıcı arayüzüne girmelerini sağlayacağız."

Geliştirici B: "Bakın, 12factor.net için alan adı uyarım şimdi başladı." 1


1 : kaynak: tamamlandı.


1

TL; DR

Yapılandırma dosyaları yerine ortam değişkenlerini kullanmanın birkaç nedeni vardır, ancak gözden kaçırılması gereken en yaygın iki tanesi bant dışı yapılandırma ve sunucular, uygulamalar veya kurumsal roller arasındaki gelişmiş ayrımın fayda değeridir . Tüm olası nedenlerin ayrıntılı bir listesini sunmak yerine, cevabımdaki sadece bu iki konuyu ele alıyorum ve onların güvenlik etkilerine hafifçe değiniyorum.

Bant Dışı Yapılandırma: Sırları Kaynak Koddan Ayırma

Tüm sırlarınızı bir yapılandırma dosyasında saklarsanız, bu sırları her sunucuya dağıtmanız gerekir. Bu, ya kodunuzun yanı sıra sırları revizyon kontrolünde kontrol etmek ya da sırlar için tamamen ayrı bir depo ya da dağıtım mekanizmasına sahip olmak anlamına gelir.

Sırlarını şifrelemek bunun için gerçekten yardımcı olmuyor. Tek yapmanız gereken, sorunu bir çıkarmaya itmek. Çünkü şimdi de anahtar yönetimi ve dağıtımı konusunda endişelenmeniz gerekiyor!

Kısacası, ortam değişkenleri, gelişimi işlemlerden ayırmak istediğinizde sunucu başına veya uygulama başına verileri kaynak kodun dışına taşımak için bir yaklaşımdır. Bu, özellikle kaynak kodunu yayınladıysanız önemlidir!

Ayrımı Geliştirin: Sunucular, Uygulamalar ve Roller

Sırlarınızı saklamak için kesinlikle bir yapılandırma dosyanız olsa da, sırları kaynak kodunda saklarsanız, bir özgüllük sorununuz olur. Her bir sır için ayrı bir şubeniz veya deponuz var mı? Doğru sır setinin doğru sunuculara ulaşmasını nasıl sağlıyorsunuz? Veya her yerde aynı (ya da hepsini tek bir dosyada okuyorsanız okunabilir) olan "sırları" ile güvenliği azaltıyorsunuz ve bu nedenle herhangi bir sistemin güvenlik kontrolleri başarısız olursa daha büyük bir risk oluşturuyor musunuz?

Her sunucuda veya her uygulama için benzersiz sırlara sahip olmak istiyorsanız, ortam değişkenleri çok sayıda dosyayı yönetme sorununu ortadan kaldırır. Yeni bir sunucu, uygulama veya rol eklerseniz, yeni dosyalar oluşturmanız veya eskilerini güncellemeniz gerekmez: söz konusu sistemin ortamını güncellemeniz yeterlidir.

Güvenlik Üzerine Düşüncelerin Ayrılması

Çekirdek / bellek / dosya güvenliğinin kapsamlı bir araştırması bu cevabın kapsamı dışında kalsa da, uygun şekilde uygulanan, sistem başına ortam değişkenlerinin "şifrelenmiş" sırlardan daha az güvenli olmadığına dikkat çekmek gerekir. Her iki durumda da, hedef sisteminin hala bellekte deşifre sırrı tutmak zorundadır bazı onu kullanmak için nokta.

Ayrıca, belirli bir düğümde değerler geçici bellekte saklandığında, çevrimdışı kopyalanabilecek ve saldırıya uğrayabilecek diskte bir dosya bulunmadığını belirtmekte fayda vardır. Bu genellikle hafıza içi sırlara yönelik bir avantaj olarak kabul edilir, ancak kesin değildir.

Çevre değişkenleri ve diğer sır-yönetim tekniklerine ilişkin sorun, güvenlik ve kullanılabilirlik takasları için mutlak olanlardan çok daha fazla. Kilometreniz değişebilir.


2
Bu ikna edici değil, çünkü yapılandırma dosyaları için bahsettiğiniz tüm olumsuzluklar çevre değişkenleri için de geçerli. Çevre değişkenleri olan yapılandırma verileri. Büyülü bir şekilde kendilerini ayarlamazlar. Her bir sisteme dağıtılmalıdır ve bunları ayarlamak için bir tür yapılandırma mekanizması kullanılmalıdır.
jpaugh

@jpaugh Hasır bir adam tartışması yapıyorsun ve asla söylemediğim bir şeye saldırıyorsun. Ele aldığım konular bant dışı yapılandırma ve veri ayrımı. Açıkça belirtildiği gibi, bunları istediğiniz gibi yapabilirsiniz. İsterseniz, sırlarınızı GitHub’a kodunuzun yanında kamuya açık olarak gönderebilirsiniz, ancak bu genel durumda kesinlikle görünmezdir. Ancak sadece sen için takaslar gerekli belirleyebilir senin sistemin belirli bir tehdit modeli içinde düzgün çalışması için.
CodeGnome

2
Tüm puanlarınız doğrudur, ancak diğer tüm yapılandırma verilerindeki kadar çevre değişkenleri için de geçerlidir. Ortam değişkenlerini dosyalarda saklarsanız, bunları işleyebilirsiniz; ve eğer bunları bant dışı gönderirseniz, bir dosya içinde yapmak onları yazmaktan daha kolaydır. Ancak bunları yazmayı tercih ediyorsanız, neden bunun yerine bir JSON nesnesi yazıp stdin'de okumuyorsunuz? Bu aslında komut satırından daha güvenli.
jpaugh

1

Şahsen, bunların kabuk tarafından başlatılan tüm işlemler tarafından .bashrcgörülebilmesi için çevresel değişkenlerin ayarlanmasını tavsiye etmem , ancak alanlarını / denetleyici düzeyine (init / rc script, systemd config) ayarlamak, böylece kapsamları gereken yerle sınırlı olacak şekilde ayarlamanızı tavsiye etmem. .

Ayrı ekiplerin operasyonları yönettiği yerlerde, ortam değişkenleri, yapılandırma dosyalarını / formatlarını bilmek ve / veya içeriklerinin yönetimine başvurmak zorunda kalmadan uygulama ortamını uygulama ortamını ayarlamak için kolay bir arayüz sağlar. Bu, özellikle operasyon ekiplerinin operasyonel ihtiyaçlara (dağıtım kolaylığı, ölçeklenebilirlik, güvenlik vb.) Dayanarak dağıtım sistemini (OS, denetleyici süreçleri) seçebileceği çok dilli / çoklu çerçeve ayarlarında geçerlidir.

Başka bir husus CI / CD boru hatları - kod farklı ortamlardan geçerken(yani dev, test / qa, evreleme, üretim) çevresel özellikler (dağıtım bölgeleri, veritabanı bağlantı bilgileri, kimlik bilgileri, IP adresleri, etki alanı adları, vb.) en iyi şekilde atanmış yapılandırma yönetimi araçları / çerçeveleri tarafından belirlenir ve uygulama tarafından tüketilir. çevreden süreçler (KURU, bir kere yaz, her yerde moda koş). Geleneksel olarak geliştiricilerin bu operasyonel kaygıları yönetme eğiliminde oldukları yerlerde, kodun yanı sıra yapılandırma dosyalarını veya şablonlarını da kontrol etme eğilimi gösterirler ve daha sonra operasyonel gereksinimler değiştiğinde geçici çözümler ve diğer karmaşıklıklar ekleyebilirler (örneğin, yeni ortamlar / dağıtım / siteler gerçekleştiğinde, ölçeklenebilirlik / güvenlik) Tartmak

  • Env-vars, ölçekte konfigürasyon / karmaşıklığı kolaylaştırır.
  • Env-vars, operasyonel yapılandırmayı , uygulamanın kodla ilgili olmayan yönlerinden sorumlu olan ekiple birlikte (standart değilse de) bağlayıcı olmayan şekilde operasyonel yapılandırmayı yerleştirir .
  • Env-vars, uygulamayı destekleyen ana / denetleyici işlemlerinin (örneğin, tanrı, monit, denetleyici, svinvinit, sistem vb.) Değiştirilmesini ve hatta operasyonel gereksinimler olarak kesinlikle dağıtım sistemini (işletim sistemleri, konteyner görüntüleri vb.) Desteklemektedir. evrim geçirmekte / değişim. Günümüzde her dil çerçevesi bir dizi işlem çalışma süresine sahipken, bunlar operasyonel olarak daha düşük olma eğilimindedir, geliştirme ortamları için daha uygun olma ve / veya çok dilli / çok çerçeveli üretim ortamlarındaki karmaşıklığı artırma eğilimindedir.

Üretim için, ben bir in env-vars uygulamayı ayarı desteklerken EnvironmentFile gibi /etc/default/myapplication.confbu yapılandırma yönetimi tarafından dağıtılan ve yalnızca tarafından okunabilir ayarlanır rootböyle systemdözel bir altında uygulamayı spawn (veya bu konuda başka bir şey) Deprivileged sistem kullanıcısı bir de özel grup . İçin özel kullanıcı grupları ile Destekli opsve sudo- bu dosyalar varsayılan olarak dünya tarafından okunamaz durumda. Bu, Dev + Ops'un tüm iyiliğini destekleyen 12 faktörü ile uyumludur ve geliştiricilerin / test edicilerin dev / qa / test ortamlarında kendi EnvironmentFiles öğelerini düşürmelerine izin verirken, iyi bir güvenlik avantajına sahiptir.


0

Bir geliştiricinin bakış açısından, config verilerini ortam değişkenlerinde saklamak, farklı ortamlar arasındaki (geliştirme, KG ve üretim) dağıtımları kolaylaştırır ve geliştiricilerin yanlış config dosyasını dağıtma konusunda endişelenmelerine gerek kalmaz.

Azure web uygulamaları bu modeli kullanma seçeneği sunar ve çok iyi çalışır.

Buna ek olarak, potansiyel olarak hassas verileri kaynak kontrolünün dışında tutar. Bu dosyaları kaynak kontrolünden yok saymak gerçekten mümkün değil (en azından .NET'te) çünkü bu dosyalarda çok sayıda gerekli boyler konfigürasyonu da mevcut.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.