it-swarm-tr.com

Geliştiricilere kendi bilgisayarlarına yönetici hakları verme riskleri

Dahili BT departmanımı yeni geliştirici ekibime kendi bilgisayarlarımıza yönetici hakları vermeye ikna etmem gerekiyor. Bunun ağ için bir güvenlik riski oluşturacağını düşünüyorlar. Herkes bunun neden olacağını açıklayabilir mi? Riskler nelerdir? BT departmanları genellikle bilgisayarlarına yazılım yükleme becerisine ihtiyaç duyan geliştiriciler için ne yapar?.

Bu soru Haftanın BT Güvenlik Sorus idi.
Daha fazla ayrıntı için 8 Haziran 2012 blog girişi veya kendinizinkini gönderin Haftanın Sorusu.

78
carolineggordon

Çalıştığım her yerde (sözleşme geliştiricisi olarak) geliştiricilere masaüstlerinde yerel yönetici hakları verilir.

Nedenleri:

1) Geliştiriciler araç setleri genellikle çok düzenli olarak güncellenir. Grafik kütüphaneleri, kod yardımcıları, görsel stüdyo güncellemeleri; neredeyse haftalık olarak yüklenmesi gereken güncellemeler çıkıyor. Masaüstü desteği genellikle tüm dev makinelerinde güncellenmiş yazılımı yüklemek için her hafta 20 bilet almaktan çok yorulur, böylece geliştiricilere bunu kendileri yapma hakları verir.

2) Hata ayıklama/Test araçlarının çalışabilmesi için bazen yönetici haklarına sahip olmaları gerekir. Yönetici erişiminin olmaması, geliştiricilerin hata ayıklama kodunu yapamayacakları anlamına gelir. Yöneticiler bundan hoşlanmaz.

3) Geliştirici güvenlik konusunda daha bilinçli olma eğilimindedir ve bu nedenle tehlikeli kötü amaçlı yazılım çalıştırma/yükleme olasılığı daha düşüktür. Açıkçası, yine de olur, ancak tüm geliştiricilerin hepsinde, işlerini yapabilmek için genellikle daha yüksek düzeyde erişime sahip oldukları güvenilebilir.

63
Alan Barber

Bu kısmen geliştirme ekibinin geliştirmesi beklenen yazılım türüne bağlıdır. Bazı yazılım türlerini yönetici hakları olmadan geliştirmek diğerlerine göre daha kolaydır.

Örneğin, çok fazla yönetici hakkına ihtiyaç duymadan, hepsi yerel olarak kurulan (ve genellikle 8080 numaralı bağlantı noktasında test edilen) Maven eserleriyle Eclipse'in beğenilerini kullanarak adil bir web tabanlı Java geliştirme) yapabilirsiniz (belirli bağlantı noktalarını açmanız gerekebilir) Donanıma daha yakın erişilmesi gereken araçlar geliştirmek yönetici hakları olmadan imkansız olabilir. Bu, web geliştirme için bile, bir test makinesini sıfırdan yeniden oluşturabilmek için iyi bir uygulamadır ( genellikle bir VM).

Bu güvenle ilgili ise (yani geliştirici ekibinizin bazı üyelerinin kötü niyetli niyetleri olabilir), yine de başınız belada demektir. Belirli hakları onaylayan/onaylamayan sistem yöneticilerinin, yazdıkları kodun ayrıntılı olarak ne yaptığını kontrol edebilmeleri olası değildir. Bu, dev ekibinize üretim hizmetlerinize sınırsız erişim vermeniz gerektiği veya elbette ihtiyaç duyduklarından daha fazla makinede yönetici erişimine sahip olması gerektiği anlamına gelmez. Riskleri azaltmak için mekanizmalara sahip olmak iyidir, ancak kuruluşunuzun çalışması için temel bir güven düzeyine ihtiyacınız olacaktır. Geliştirici ekibini ayrı bir fiziksel ağa yerleştirmek, güven sorunlarını ve olası hataları azaltmak için ilk adımdır.

Yönetici erişimine sahip birine sahip olmanın tipik bir riski, ağdaki paketleri yakalayabilmektir. Bu, geliştirilen şeyin doğasına bağlı olarak kabul etmek zorunda kalabileceğiniz bir risktir. Wireshark gibi araçlar bazen geliştirme için yararlı olabilir. Kuruluşunuzda bile, BT veya BT dışı çalışanlar mümkünse SSL/TLS etkinleştirilmiş hizmetleri kullanmalıdır, bu gizli dinleme ve MITM saldırılarına karşı yardımcı olacaktır.

Devs admin erişimi vermiyorken (gerçekten ihtiyaç duymadıkları sürece) birkaç dezavantajı düşünebilirim:

  • Kuruluşunuzdaki geliştiriciler ve sistem yöneticileri arasında bir "onlar vs bize" kültürü oluşturabilir. Bu zaten birçok yerde var, ancak genellikle iyi bir şey değil. Her takımın diğerini bir acı olarak görmesi muhtemeldir. Güvenlik tamamen teknik bir sorun değil, aynı zamanda insan etkileşimi. İyi insan iletişiminin sadece güvenlik açısından değil, genel olarak kuruluşunuzun genel hedeflerine yardımcı olması gerektiğini düşünüyorum. (Her zaman yüzü olmayan bir bilete cevap vermek yerine sorunları çözmek için ihtiyaç duyduğum sistem yöneticilerine yüz yüze konuşarak sonra daha iyi çözümler bulabildim.)

  • İnsan doğası öyledir ki, insanlar sınırlı olduğunda yaratıcı olurlar, ancak her zaman doğru şekilde olmazlar. Geliştiricilerin, kuruluş içinde kendilerine yüklenen sınırlamaları aşmak için adil bir çaba harcadıklarını (ve genellikle başarılı olduklarını) görebilirsiniz. Bunun yerine yaratıcılıklarını ne yapmaları gerektiği konusunda kullanmalılar.

  • BT sistemleri karmaşıktır ve hata ayıklama karanlık bir sanattır. Ürününüzde XYZ a.b.c_13 ve a.b.c_24 kitaplıklarında hata ayıklamanız gerekirse, geliştiricilerin her sürümü yükleyip kaldırabilmeleri gerekebilir; bu da yönetici erişimi gerektirebilir. Sürüm numaralarına bağlı olan hataları takip etmek zaten rahatsız edici. Bir bilet yükseltmeniz ve bir başkasının doğru sürümü kurması/kaldırması için beklemeniz (belki saat veya günler) bunu bir kabus haline getirir: "onlara karşı bize" kültürel sorununu artıracak ve daha da önemlisi, organizasyon için daha fazla. Bunu bir risk/maliyet değerlendirme perspektifinden düşünebilirsiniz.

28
Bruno

Risk, erişimin artan bir fonksiyonudur

BT ekibindeki meslektaşlarınızın korkusunu açıklayan basit bir risk hesaplama kuralı vardır. Herhangi bir işletim sistemine ne kadar çok erişiminiz olursa, herhangi bir hatanın veya saldırının etkisi de o kadar yüksek olur.
Örneğin, meslektaşlarınızdan biri, standart bir kimlik avı saldırısı nedeniyle Bob'a saldırıldığını varsayarsak, Bob hesabı siber suçlular tarafından kullanılabilir ve birkaç dakika içinde Internet'te satılır. Bob hesabının yönetici ayrıcalıkları varsa, bu hesap SPAM'ı İnternet'te büyük ölçekte göndermek için, daha sonra kimlik avı saldırılarına sahip diğer hesapları büyük ölçekte çalmak için kullanılacaktır ve çok hızlı bir şekilde (dakikalar içinde) ağ (bu Bob hesabı bir yönetici olduğu için mümkündür) Bob'un PC'sinin toplam uzaktan kontrolüne izin verir (ssh, VNC, VPN... gibi araçlar aracılığıyla) . Dahili bir bilgisayardan, ayrıcalıklı bir hesaptan başlatılan bu saldırı, herhangi bir güvenlik duvarını kırabilir, herhangi bir anti-virüs, anti-spam korumasını durdurabilir.

Kötülük içeride.

En iyi ağ yöneticileriniz, sistem yöneticileriniz veya güvenlik yöneticileriniz bile bu bozuk bilgisayarı aylarca çıplak bırakabilir (bkz. Stuxnet).

Yanlış risk azaltma

Geliştirici meslektaşlarınız üzerinde çalıştıkları işletim sistemini yönetmekte ve bilgisayara fiziksel erişime sahipse, riskteki bu fark boştur.

Herhangi bir işletim sistemindeki herhangi bir mühendis
kendisine yönetici erişimi verebilir
bilgisayara fiziksel erişimi varsa.

Herhangi bir işletim sisteminde yönetici erişimini engellemek, yönetici ayrıcalıkları ile normal kullanıcı ayrıcalıkları arasında fark oluşturamayan kullanıcılar için geçerli bir risk azaltma yaklaşımıdır. İşte geliştirici ekip arkadaşlarınıza soracağım ve risk bilincine göre hareket edeceğim kilit soru:

"Size izin verilirse nelere dikkat edeceksiniz?
işletim sisteminizde yönetici ayrıcalığı? "

Riskten haberdar olacak kadar iyi iseler, istedikleri erişimi elde edecek kadar iyi olurlar. O zaman bu yönetici erişimini reddetme riskinde bir azalma olmaz. Dikkat: Kolayca alabilecekleri bir erişimi reddederseniz şirketiniz için bir teminat riski vardır: bunu kirli bir şekilde yapacaklar, kanun kaçağı gibi davranacaklar, herhangi bir yardım isteyemeyecekler, Herhangi bir aksilikle karşılaşmak zorunda kalacaksınız.

10
dan

Onlara iş istasyonlarına ve istedikleri her şeye Yerel yönetici hakları veriyorsunuz. Geliştirme ortamı her zaman ana ağdan izole edilir. Geliştirme ortamındaki hiçbir şeyin ana ağa zarar vermeyeceğinden emin olmak için ihtiyaç duydukları kurulumu sağladığınızdan emin olmak BT'nin görevidir. Bunu yapmak için ihtiyacınız olan ekipmanı/yazılımı satın almak üzere önceden planlayın ve yönetim ile birlikte çalışın.

8
wrb

Önceki cevaplarda ve yorumlarda belirtilmeyen birkaç şey, en az ayrıcalık altında çalışan geliştiriciler için bir tartışma olacaktır:

  1. Çalıştığınız sektöre bağlı olarak, çalışanların iş istasyonlarında yüksek ayrıcalıklara sahip olmalarını kısıtlayan yasal veya düzenleyici nedenler olabilir. Geliştiricilere yönetici erişimine izin vermek, kuruluşu uyumsuzluk riski altına sokabilir.

  2. Bileşenler yükseltilmiş ayrıcalıklarla geliştirildiğinde, bu ayrıcalıklara sahip olmayan diğer ortamlara dağıtım sırasında hata riski olabilir. Geliştiriciler, başka ortamlarda bulunmayan yerel makinelerine istemeden yükseltilmiş veya kitaplık ekleyebilir ve bileşenlerin bu kitaplıkların belirli sürümlerine bağımlılıkları olabilir. Ayrıca, bileşenlerin başka ortamlarda çalışacağı kullanıcı hesapları, yükseltilmiş ayrıcalıklarla çalışan geliştirici tarafından üstlenilen gerekli veritabanına veya diğer erişime sahip olmayabilir. Bunun geçmişte birçok kez olduğunu gördüm. Bazen dağıtımın neden başarısız olduğu açıktır, bazen değil ve anlayabilinceye kadar her şeyi geri almanız gerekir.

  3. Geliştiriciler açık kaynaklı araçlar veya kütüphaneler kurar ve bunları geliştirme amacıyla kullanırlarsa, ürettikleri yazılımın nihayetinde, özellikle "copyleft" koşullarının lisansın bir parçası olduğu durumlarda, kasıtsız lisans kısıtlamaları olabilir. Açık kaynak araçlarını veya kitaplıklarını kullanmakta yanlış bir şey yoktur, sadece kasıtlı olmalıdır. Teslimatta, artık tüm kaynak kodunuzu topluluğa geri göndermeniz gerektiğini öğrenmek istemezsiniz, çünkü geliştiricileriniz, lisanslarından önce gerçekten okumadıkları katı copyleft terimlerine sahip bazı açık kaynaklı bileşenler kullandılar yükledi.

Yaptığım bir şey, geliştiricilerin en az ayrıcalık altında çalışmasını sağlamak, ancak belirli bir süre için yükseltilmiş ayrıcalıklar talep etmelerine izin vermektir. Daha sonra, kaydettiği ve izlediği yükseltilmiş ayrıcalıklar için bu "yangın çağrısı" isteği ve istenen sürenin sonunda otomatik olarak sıfırlanır.

8
Todd Dill

Cevaplayacak birkaç sorunuz var.

  1. Bu geliştiricilerin günlük olarak kullanması gereken uygulamalar yönetici ayrıcalıkları gerektirir ve bu uygulamaları kurmanın herhangi bir yolu var mı?
  2. Bu geliştiricilerin önemsiz günlük görevleri yerine getirmek için yönetici ayrıcalıklarına ihtiyacı olan nedenler nelerdir ve bundan kaçınmanın bir yolu var mı?
  3. Bu geliştirici makineler internete bağlı mı?

Soru risklerin ne olduğu değil, soru (sadece cevaplayabileceğiniz) olmalıdır, geliştiricilerin bir yönetici hesabına sahip olmalarının nedenleri nelerdir. Onları bir "güçlü kullanıcı" hesabı ile tamamlayabilir ve onlara tam olarak ihtiyaç duydukları şeyi yapma olanağı verebilir, ancak ağınıza zarar verme yeteneklerini sınırlayabilirsiniz.

Bu makineler internete bağlıysa .... o zaman bir şey çalıştırma ve bu makinelere herhangi bir şey kurma yetenekleri nedeniyle büyük miktarda risk getireceksiniz. Bu geliştiriciler iyi geliştiricilerdir, güvenlik uzmanları değildirler, sadece ağı kötü amaçlı yazılımlara maruz bırakan bir hata ne zaman yapacakları sorusudur.

Örneğin, Google'a bir göz atın. Bir Google çalışanı, MSN Messenger penceresinde bulunan bir bağlantıyı tıklar, Microsoft tarafından önceden düzeltilmiş bir istismardan yararlanan ve tüm ağa bulaşan kötü amaçlı yazılım indirir.

Bağlantıya tıklayarak Google çalışanını eklemeliyim ki, bu soru ile ilgisi yoktu, işaret etmek gerekirse, insanlar bir hata yapacak, bu yüzden exposerinizi sınırlandırın.

4
Ramhound

Geliştiricilere bilgisayarlarını kurma yeteneği sağlama ile ilişkili güvenlik riskleri çoktur. İşte neden itiraz ediyorum (sys yöneticisi olarak)

1) En iyi güvenlik uygulamalarının potansiyel ihlali - 8 güvenlik kuralından biri en az ayrıcalık kuralıdır - çalışanlara sadece görevlerini tamamlamak için ihtiyaç duydukları şeye erişim izni verin. Birisi bana geliştiricilerinin işlerini yapmak için yazılım yüklemek için yönetici erişimine ihtiyaç duyduğunu söylerse, "Neden bir personelim onlar için yükleyemiyor?" Yazılım yüklemek için merkezi bir noktaya sahip olmak, bir BT departmanının hangi makinede hangi yazılımın olduğunu tam olarak bilmesini sağlar.

2) Yasal Sebepler - Belki de geliştiricilerinizden takdire şayan bir Etik Değerlerden daha azı vardır ve korsan yazılım yüklemeye karar verir. Bu yazılım muhtemelen kötü amaçlı yazılımlarla dolu değil, aynı zamanda bilgisayarınızda korsan yazılımlarla yakalanmanız durumunda solucanlar için dava açabilirsiniz. Bir BT departmanı bu bilgisayarlardan sorumlu olarak kabul edilir ve bu nedenle onları denetlemekten ve lisanslamanın her yazılım parçasının Hizmet Koşullarına uygun olmasını sağlamaktan sorumludur. Geliştiriciler için kendi yazılımlarını kurabilmeleri ve BT departmanını rahatsız etmemeleri uygun olsa da, BT departmanı için çok daha fazla iş yaratırsınız.

3) İstemeden Kötü Amaçlı Yazılım kurulum - daha önce belirtilmiş, ancak bu yeterince masum olabilir. Kötü amaçlı yazılım yükleyebilmeleri için kullanıcı ayrıcalıklarının yükseltilmesi, virüslü bir PDF e-posta veya indirme yoluyla sürücü yoluyla açarak kötü amaçlı yazılımlara karşı savunmasız kalmasını sağlar. yazılım yüklemek, kötü amaçlı yazılım tehdidini azaltmaya yardımcı olacaktır.

4) Kötü amaçlı etkinlik - 2. noktaya benzer, ancak geliştiricilerinizden birinin arka kapı kurmayacağını veya ağınızda bilerek başka bir güvenlik tehdidi açmayacağını söyleyelim. Feshedilmeleri veya patronları onları kızdırmaları durumunda, kaç BT uzmanının intikam almak için bunu yaptığını şaşıracaksınız.

Sonuçta, buna karşı tavsiye etmek gerekir. İnsanlar, yazılım yüklemek için BT'yi her zaman rahatsız etmelerini önlemek için zamandan tasarruf edeceğini iddia edebilirken, "kullanıcıların kendi yazılımlarını yüklemelerine izin vererek oluşturulan güvenlik deliklerini düzeltmekten daha az zaman alır" . Bunun IS gerekli olduğu düşünülürse, gerçekten dış dünyaya doğrudan erişimi olmayan bir ağa konulmalıdır.

4
DKNUCKLES

Çözüm, etki alanına bağlı olmayan bir sanal makine yüklemektir. Oldukça bir güçlük olacak, ancak politikalar tarafından tamamen sakatlanmaktan daha iyi.

2
Louis Somers