Bir geliştirici makinesini kilitlemek değerinden daha fazla çaba mudur? [kapalı]

Bir geliştirme ekibi için bir geliştirici ve BT yöneticisi / desteğinde çalıştıktan sonra, tamamen kilitli olandan tamamen olmayana kadar birçok farklı ortam türüyle karşılaştım. Sınırlı destek deneyimimde, daha az kilitli bir makine ile desteklemenin daha az çaba olduğunu düşünüyorum ve kesinlikle bunun daha kolay olduğunu hissettim, ancak elbette bu önyargı olabilir. BT destek perspektifinden görünümün ne olduğunu bilmek istiyorum, kilitli olmayan makineleri olan geliştiricileri desteklemek gerçekten zor mu?

Bir geliştirici makinesini kilitlememenin en büyük sorunu, geliştirdikleri herhangi bir yazılımın tam yönetici ayrıcalıklarının çalışmasını gerektirmesidir. Geliştiricilerin erişimi, çalıştırılması gereken ortamla aynı olmalıdır. "Kendini destekleyebilecek" veya "kendiliğinden yüklenebilir" olmaları gerekiyorsa, onlara yönetici yaparken kullanmaları gereken Bruce.admin gibi başka bir yönetici hesabı verin. ama her gün kullanılmıyor.

Tıpkı tuzlarına değecek iyi bir UNIX yöneticisi gibi, günlük yönetici olmayan işleri için bir kök hesap kullanmaz.

Çoğu geliştirici teknik olarak bilgili ve ne yaptığını biliyor. Çoğu zaman birçok uzman uygulama yüklemeleri gerekir, bunu yapmak için izin almak zorunda kalırlar ve BT'yi aşağı indirip eklerler, özellikle her iki taraf için de büyük şirketlerde çok sinir bozucu olabilirler.

En iyi sonucu veren şeylerin, makinelerine yazılım yükleme konusunda istediklerini yapmalarına izin verdiğini buldum, ancak desteklemediğimiz bir şeyle ilgili sorun yaşarlarsa, kendi başlarına. Çoğu geliştirici bundan memnun ve yine de kendi makinelerine bakmayı tercih ediyor.

Sadece IE ve açık kelimeyi kullanmak için muhasebede birini kilitlemek iyidir, ancak 4 farklı türde tarayıcı yüklemesi gereken ve bir sorunu çözmek için hızlı bir şekilde bir uygulama yüklemeniz gereken bir geliştirici, rahatsız edici olabilir.

Deneyimlerim, çok fazla teknik bilgiye sahip olan, bu nedenle geliştirme dükkanları, BT tedarikçileri vb., Çalışanlarına güvenen ve ne kurmak istediklerine karar vermelerine izin veren şirketlerin çok daha mutlu ve daha az rahatsız edici olmasıdır

Geliştirici makinelerini kilitlemenin yararları hakkında canlı bir tartışma için bu Stackoverflow yayınına bakın . (Feragat: Kabul edilen cevabı yazdım).

Sistem yöneticisi açısından, üretim sistemlerine erişim hassastır ve işlerini yapmak için buna ihtiyaç duyan insanlara bu erişimi kısıtlamalısınız (bu, uygulama için katman-3 destek sorumluluklarına sahip geliştiricileri içerebilir). Bir geliştirme bilgisayarı veya geliştirme sunucusu üzerindeki yerel yönetici hakları, üretim sistemlerinizin güvenliğinden önemli ölçüde ödün vermez.

Gerekirse makineleri yeniden oluşturmak için kullanabileceğiniz bir görüntü oluşturun. SQL Server geliştirici sürümünü, Visual Studio, Cygwin ve MikTex'i ve diğer birçok uygulamayı elle yüklemek oldukça zaman alıcıdır. Bu büyük uygulamaların yüklü olduğu bir görüntü, makineleri çok fazla yeniden görüntülemeniz gerekiyorsa makul derecede değerli olacaktır.

Geliştirme perspektifinden bakıldığında, makineyle ilgili çoğu sorunu çözebileceğimi ve genellikle oldukça nadir durumlarda ağ destek personelinden yardıma ihtiyacım olduğunu düşünüyorum. Aşırı kısıtlayıcı ortamlar, geliştiricilerin kendilerini mükemmel bir şekilde yapabildikleri işleri yapmak için sahte dev destek trafiği oluşturma eğilimindedir.

Geliştiricilerin çok fazla yönetici çalışmasına ihtiyaç duydukları başka bir yer, geliştirme ortamlarını barındıran veritabanı sunucularındadır. Çoğu geliştirici rutin DBA görevlerini kolayca öğrenebilir ve yine de bunun hakkında çalışma bilgisi edinmelidir (prensip olarak IMHO). Geliştirme sunucularındaki aşırı kısıtlayıcı yönetici erişim ilkeleri birçok yönden ayağa kalkabilir.

Bir çizik geliştirme ağı, düzenlenebilirse oldukça iyi bir fikirdir - gerekirse bunu üretim sunucularınızdan güvenlik duvarı yapabilirsiniz.

• Geliştiriciler bir üretim ortamının yapısını kolayca çoğaltabildiklerinde, entegrasyon testinin kasnaklardan atlanmadan sentezlenebileceği bir dağıtım testi kültürünü teşvik eder. Bu, üretim sürümü ve dağıtımının kalitesini artırma eğiliminde olacaktır.

• Bir üretim ortamını taklit edebilmek aynı zamanda üretim dağıtımı ve destek konularında farkındalık yaratır. Geliştirme personelini, bir uygulamanın üretimde nasıl desteklenebileceğini düşünmeye teşvik eder, bu da muhtemelen bu düşünceyle inşa edilmiş mimarileri teşvik edecektir.

• Bu ağda bir etki alanı denetleyicisi varsa, ana etki alanı denetleyicinize ve hesaplarına güvenmesi için bir güven ilişkisi kurabilirsiniz. Bu güven ilişkisinin karşılıklı olması gerekmez, bu nedenle üretim ağı altyapınızın güvenliğinden ödün vermez. Bu, güvenilmeyen bir geliştirme ağına sahip olmanıza izin verebilir, ancak geliştiricilerin Exchange hesapları veya dosya sunucuları gibi etki alanı kimliği doğrulanmış kaynaklara erişmesine izin verebilir.

• Geliştiricilerin, kasnaklardan atlamak zorunda kalmadan, deney için makul miktarda kapsama sahip olmasını istiyorsunuz. Bu çalışmanın yoluna siyasi engeller koymak, politik olarak uygun ancak uzun vadeli (ve genellikle tanınmayan) teknik borç üreten sıva çözümlerini yapıştırma eğilimindedir. Bir sistem yöneticisi veya destek analisti olarak, tahmin edin parçaları kimin alacağını ...

Bunun bir unix veya linux ortamında çok daha az sorun olduğunu ekleyeceğim; kullanıcılar kendi ortamlarını oldukça yoğun bir şekilde özelleştirebilirler .profile. Kendi /home/bloggsj/bindizininizdeki şeyleri kalbinizin zevkine göre derleyebilir ve yükleyebilirsiniz . Unix altında root erişimi gerektiren birkaç şey olmasına rağmen, 'Yerel yönetici hakları' çoğunlukla bir Windows sorunudur.

Şimdiye kadar gördüğüm en mantıklı seçenek (her iki tarafta da var -ve hala am-) sadece kilitsiz şeyler ve desteklenmiyor . Onlara özgürlük verin ve eğer batırırlarsa, elde edebilecekleri tek şey standart bir imajla yeniden sonuçlanmaktır .... Bu durumda, onları bir tür "güvenilmeyen" ağa koymanın iyi bir plan olduğunu düşünüyorum.

Geliştirici masaüstlerini kilitleme (olmayan) duygusu kadar: Ben eminim ki tüm kilitleme sadece üretkenliği yine de engeller, dahası, makul yetenekli herhangi bir geliştirici kolayca delikleri bulacaksınız ....

Cevap gerçekten: basit bir evet ya da hayır cevabı yoktur. Ancak güvenlik en azından geliştirici kullanıcılarınız için en az herkes kadar önemlidir.

Bir yandan, evet devs teknik olarak daha anlayışlı olma eğilimindedir. Öte yandan, onlarınki genellikle stresli bir iştir ve dev kilometre taşları, kendi sistemini güvenli bir ortam olarak sürdürmek için gereken ekstra bakımdan öncelikli olacaktır. bu onların günlük görevlerinin açık bir düşüncesidir.

Geliştiricilere sistemlerine tam ve serbest erişim sağlayacaksanız, aşağıdaki ek önlemleri gerçekten dikkate almalısınız:

• Normal geliştirici olmayan kullanım için, normal kullanıcı sistemleri kadar kilitli olan başka bir sistem sağlayın.
  • Tam erişimli geliştirme makinelerini, yalnızca geliştirme kaynaklarına erişimi olan özel bir VLAN'a yerleştirin.
• Etkilenen bir sistemin kod tabanını tehlikeye atmasını engelleyecek bir şey olup olmadığını sorun. Bir arka kapı makine, kötü niyetli bir hacker'ın elinde malign kodu kontrol edebilir veya kod tabanını silebilir mi? Bu riski azaltmak için uygun adımları atın.
• Benzer şekilde, geliştiricilerin erişebildiği sistemlerde tutulan iş verilerini koruyan bir şey olup olmadığını sorun.
• Dev sistemlerinin yazılım envanteri ve güvenlik denetimini düzenli olarak yapın.
  • Ne çalıştırdıklarına dair bir fikir edinin ve dev sistem yeniden dağıtım görüntülerinizi oluşturmak için bu bilgileri kullanın.
  • Er ya da geç dikkatsiz olan ve açıkça tehlikeli ya da tamamen işle ilgili olmayan şeyleri yükleyen bir geliştiriciniz olacak. Bu olduğunda hızlı bir şekilde uyarı göndererek, geliştirici topluluğunun evet, birisinin izlediğini ve makul standartlar dahilinde kalma sorumluluğu olduğunu bilmesini sağlayacaksınız.
• Düzenli olarak kötü amaçlı yazılım taraması yapıyor musunuz? Bazı durumlarda, devs haklı olarak erişimli AV sistemleri (her zaman açık olan, her dosya erişiminde her zaman taranan AV sistemleri) tarafından alınan performans vergisinden haklı olarak şikayet edecektir. Her gece tarama stratejisine geçmek ve / veya erişim taramanızda dosya / klasör dışlamaları oluşturmak tercih edilebilir. Ancak, hariç tutulan dosyaların başka bir şekilde tarandığından emin olun.
  • Yönetici özellikli geliştiricileriniz tüm AV taramalarını kapatabilir mi? Bunu nasıl saptar ve düzeltirsiniz?

Dev sistemlerini kilitleyecekseniz, aşağıdakileri göz önünde bulundurmalısınız:

• Destek taleplerine hızla cevap verebilecek destek kapasiteniz var mı? Geliştiricilerinizin ortalama ödeme oranını düşünün ve daha hızlı bir yanıt süresi SLA'sını hak edip etmediklerini sorun. 60k $ / yıl çalışanlardan gelen destek taleplerini yerine getirirken 120 bin $ 'lık devinizi (bir milyon dolarlık projenin anahtarı) bekletmek muhtemelen mantıklı değildir.
• Geliştiricilerinize hangi destek taleplerini sunacağınız ve vermeyeceğiniz konusunda açık ve net bir politikanız var mı? Desteğin keyfi olduğunu hissetmeye başlarlarsa , sonunda acıyı hissedeceksiniz.

Her iki durumda da, geliştiricilerin özel bir durum olduğunu ve bir tür ekstra desteğe ihtiyaçları olduğunu kabul etmelisiniz. Bunun için bütçe oluşturmuyorsanız, sorunlar şu anda iltihaplanıyor ... veya gelecekte olacak.

Bir yan not olarak, sistem yöneticileri ile çok benzer argümanlar olduğunu gördüm. En az iki farklı işte sistem yöneticilerinin kendileri sistemleri kilitlemeleri veya en azından iki oturum açma (biri root / admin privs; biri olmayan) kullanmaları önerildiğinde oldukça acımasız bir şekilde tartıştığını gördüm. Birçok sistem yöneticisi, herhangi bir şekilde kilitlenmemesi gerektiğini hissettiler ve bu tür önlemlere karşı gayretle tartıştılar. Er ya da geç bazı kilitlenme önleyici yöneticilerin bir güvenlik olayı olur ve örnek hepimiz üzerinde eğitimsel bir etkiye sahip olur.

Eskiden yönetici privs ile çalışan sistem yöneticilerinden biriydim. Çift hesaplarda değişiklik yaptığımda ve sadece ihtiyaç duyduğumda yükseldiğimde, ilk birkaç ay boyunca oldukça sinir bozucu olduğunu itiraf ediyorum. Ancak buluttaki gümüş kaplama, normal hesabım kullanıcılara koyduğum kısıtlamaların altında yaşadığında, yönettiğim sistemlerin güvenliği hakkında çok daha fazla şey öğrendim. Beni daha iyi bir yönetici yaptı! Aynı şeyin geliştiriciler için de geçerli olduğundan şüpheleniyorum. Neyse ki Windows dünyasında, artık sınırlı bir kullanıcı olarak çalışmayı ve yalnızca gerektiğinde yükseltmeyi kolaylaştıran UAC'ye sahibiz.

Şahsen ben kimsenin bir çeşit güvenlik uygulamasının üzerinde olması gerektiğini düşünmüyorum. Herkes (sistem yöneticileri, geliştiriciler, üst yönetim dahil), onları ayakta tutmak için yeterli güvenlik prosedürlerine ve gözetimine tabi olmalıdır. Aksini söylemek, şirket sistemlerinin ve verilerinin koruma çabasına değmeyeceğini söylemek demektir.

Haydi başka bir yol açalım. Mark Russinovich bir rootkit tarafından alınabiliyorsa , herkes yapabilir!

Birkaç geliştiricinizin olduğu yerde, onlara geliştirme sunucuları verme yaklaşımı bir olasılıktır, ancak geliştiricilerin tüm bir katına sahipseniz, onlara herhangi bir yönetici hakkı vermekten çok fazlayım.

Sorun şu ki, her biri yaptıklarını yapan, genellikle güvenlik bilincine sahip olmayan ve sadece uygulamalarının çalışmasını isteyen geliştiricilerin bir katıyla sonuçlanacaksınız. Ardından, "Geliştirme aşamasını tamamladık, lütfen geliştirme ortamımızı test, ön ürün ve ürün üzerine çoğaltın" isteğiyle karşılaşacaksınız.

Ayrıca rastgele önemsiz (kötü paketlenmiş yazılım) yükleme alışkanlığına girerler ve daha sonra diğer katmanlardaki düzinelerce sunucuya kurmanız için size yetki verirler.

Politikayı oldukça basit hale getiriyorum:

• Geliştiriciler, geliştirme ortamı için - her zaman - kök erişim elde edemezler.
• Geliştiriciler, geliştirici öncesi VMware sunucularına root erişimi sağlar, ancak HİÇBİR destek.
• Geliştiriciler, uygulamalarının çalışacağı işletim sistemi dağıtımına ait RPM paketleri veya OR, FHS ve LSB ile uyumlu RPM paketleri sağlamalıdır.
• Hiçbir uygulaması hiçbir koşulda root olarak çalışamaz
• Uygulama kullanıcısına suveya sudouygulama kullanıcısına erişimi olmayacaktır - kabuk erişimine sahip olmaya kilitlenecektir. (Bu muhasebe / denetim içindir).
• Ayrıcalıklı erişim ile çalışması gereken tüm komutların açıkça istenmesi ve onaylanması gerekir - bu sırada sudoersdosyaya eklenir .
  • Bu komutların / komut dosyalarının hiçbiri onlar tarafından yazılamaz.
  • Bu komutların hiçbir komut dosyası (doğrudan veya dolaylı olarak) referansı yazılamaz.

Her şeyden önce, projeyi teste ve sunucuların üzerine taşıma zamanı geldiğinde neye izin verileceğini ve nelere izin verilmeyeceğini düşünmelerini sağlayın.

Geliştiricilerin makinelerini kilitlemek, değerinden daha fazla çaba gerektirir. İdari haklar olmadan hemen hemen hiçbir şey yapamayacağınız için üretkenliğe ciddi zarar verir. Tabii ki, sonunda sistem berbat olacak, ama kesinlikle BT deponuz geliştirmede kullanılan tüm bu üçüncü taraf araçları için destek sağlamıyor mu?

Bu nedenle, Vincent De Baere'nin önerdiği gibi, en iyi eylem şekli sistemi bir görüntüden geri yüklemek olacaktır, elbette, ortam bundan sonra geri yüklenmelidir, ancak bu BT'nin sorunu olmamalıdır. Eğer N olursa, söz konusu kişiyi bir tür "kara listeye" koyabilir ve evet, bir süre idari haklarını bırakabilirsiniz.

Her iki durumda da, ortam, virüslü (veya dağınık) bir makinenin başka hiçbir makineyi etkilememesini veya spam veya başka bir şey göndermemesini sağlayacak şekilde kurulmalıdır (tamam, şimdi Sadece bariz şeyler söylüyorum, üzgünüm).

Kısmen, hangi ortamda çalıştığınıza bağlı olabilir (örneğin, Windows'a karşı Linux); ancak, bir Windows ortamını varsayarsak, genellikle değerinden daha fazla sorun olur, çünkü orada bazı geliştirme yazılımları çalışmak için yükseltilmiş izinlere sahip olmanızı gerektirir. Örneğin, Visual Studio'nun Yönetici izinleri gerektirdiği bilinmektedir , bu nedenle, birisinin işlerinin gerekli bir kısmı için çemberlerden atlamasını sağlama avantajını görmüyorum.

Ancak, şirket en iyi bahsinizin kilitlenmesini gerektiriyorsa, tüm geliştiricilere kendi sistemlerinde çılgınlaşabilecekleri sanal makineler verecek gibi görünüyor. dünyalar (örn. kısıtlayıcı normal masaüstü ve tamamen özelleştirilebilir bir ortam).

Güncelleme - Şeylerin Windows tarafında, kayda değer bir miktar var, görünüşe göre Yönetici hakları gerektiren Visual Studio biraz tarihli ve şimdi gerekli izinleri (PDF dosyası) ayarlamanın açık yolları var . Bununla birlikte, bu seçeneğimi, kendim de dahil, tanıdığım çoğu geliştiricinin sadece Visual Studio'nun ötesinde ek araçlar kullanma eğiliminde olduğunu ve hepsinin izinler açısından neye ihtiyaç duyduğunu bilmek zor olduğunu tahmin etmiyorum.

Kısıtlı bir masaüstünde sanal makineler kullanma fikrine katılıyorum.

Aksi gerekmedikçe, en iyi kurulumun herkes için ücretsiz vm ile sınırlı bir linux masaüstü olduğunu hissediyorum. Linux benim için yükü azaltıyor, bir vm sadece istedikleri her türlü işletim sistemi değil, aynı zamanda anlık görüntülere veya yedeklere de geri yüklenebilir ve genellikle farklı kurulumlara ihtiyaç duyulmadığında dünya biraz daha parlak görünür destek.

Ben (bir geliştirici olarak) makinelerimi tam olarak kontrol etmeyi tercih ederim, yani; gerektiğinde yönetici olarak çalışıyor.

Geliştiricilere bilgisayarlarına tam erişim izni verilmeden önce özel eğitim verebilirsiniz. Onlar için bazı kurallar belirleyin ve belki de en iyi uygulamaları takip ettiklerini görmek için arada bir denetim yapabilirsiniz.

Çoğunlukla BT altyapısı hakkında BT yöneticisi / BT desteği görünümünden, güvenlikle ilgili konulardan ve yükseltilmiş haklarla neden geliştirilmemesinden daha fazla bilgi almaları gerekir. (ve bundan nasıl emin olacağınızdan emin olun ...)

" Bilgisayarlar hakkında bilmemiz gereken her şeyi bildiğimizi söylediğimizde körü körüne güvenmeyin " ;-)

Bunları hala ağ oluşturma, alan adı ve hesap öğeleri, geliştirici olmayan araçların yazılım yüklemeleri vb. İle desteklemeniz gerekir.

Benim deneyimim, sadece kilitli bir makineye ihtiyaç duyan insanlar ve yönetici erişimine ihtiyaç duyan diğer (geliştiriciler, bilim adamları) arasında eşit olarak bölünmüş bir kullanıcı nüfusu ile. Üst düzey insanlar çok sayıda farklı yazılım kullandılar, bazıları şirket içi, bazıları değil, ama birçoğunun yöneticinin çalışması gerekiyordu ve işleri çok fazla paket kullanmasını gerektiriyordu, bu yüzden insanların yapmasına izin vermek en mantıklıydı kendileri.

Aşağıdaki süreçlerle sonuçlandık:

• Standart imajımız temel araçlara sahipti: Windows, Office, Anti-virüs, Acrobat, birkaç yardımcı program.
• Çok sayıda ağ disk alanı sağladık: her şeyin ağda depolanabilmesi için yeterli. Tek istisna hakkında yerel kalmak zorunda işlem içi video dosyaları oldu.
• Personel (amirlerine danışarak) iki seçeneğe sahipti: BT, bilgisayarlarını sürdürdü, tüm kurulumları ve yapılandırmayı yaptı VEYA bunu kendileri yapmak için yönetici erişimine sahip olabilirler. Her iki durumda da, tüm veriler ağa yedeklendi.
• Eğer BT sistemi koruduysa ve öldüyse, kurmamız için ihtiyaç duydukları ekstra yazılımı eklemek de dahil olmak üzere, bulunduğu duruma geri getirirdik.
• Yönetici erişimi olsaydı ve sistem ölürse, bir göz atacak ve düzeltmeye çalışacaktık, ancak taahhüdümüz onları standart görüntüye geri döndürmekti ve oradan almak zorunda kalacaklardı. Herhangi bir yerel veriye sahip olsaydı, önce bunu çıkarmaya çalışırdık, ancak SLA'mız onları mümkün olan en kısa sürede çalışan, standart bir bilgisayar haline getirmekti.
• Anti-virüs ve kötü amaçlı yazılımdan koruma yazılımını güncel tutmak için Windows güncellemelerinin çalıştığından emin olmak için yönetici erişimi olmayan herkes gerekliydi.

Yönetici erişimi olan herkesi "güvenilmeyen" bir vlana koymak isterdik, ama buna hiç ulaşamadık.