Geliştiriciler için Windows İzinleri?

Fortune 500 şirketinde Ar-Ge'de Windows yazılım geliştiricisi olarak çalışıyorum. Kurumsal BT şu anda şirket çapında bir Win7 dağıtımı için çalışıyor ve bunun bir parçası olarak, tüm kutulardaki (dev iş istasyonlarımız dahil) yönetici haklarını tamamen kilitlemek istiyorlar.

Geçişi olabildiğince pürüzsüz hale getirmek için onlarla çalışmakla görevlendirildim. Şanslıyım.

Dışarıda kullanabileceğim yayınlanmış veya saygın başka kaynaklar olup olmadığını bilmek istiyorum:

1. kumda bir çizgi çizmek için nerede olduğunu bulmak
2. Konumumu geri al.

Şahsen benim görüşüm, Ar-Ge olduğumuz ve işimizin 'kutunun dışında' olan şeyleri yapmaktır. Bu nedenle yönetici haklarına ihtiyacımız var. Ancak, kariyerime Windows Yöneticisi olarak başladıktan sonra, hedeflerinin ve neyi başarmaları gerektiğinin farkındayım. Anlamak ve yedeklemek için ihtiyacım olan şey, ortamı hem BT hem de Ar-Ge ile birlikte yaşayabilecek ve işlerini verimli bir şekilde yapmaya devam edecek şekilde inşa etmenin bir yoludur.

Yerel yönetici haklarına sahip geliştirme sanal makineleri kesinlikle çok yardımcı olacaktır, ancak birçok özel donanımla arayüz kurduğumuzdan her durumda değil.

Bu değişiklikleri iten CIO kesinlikle geliştirme süreci hakkında sınırlı bilgiye sahip 'saf BT' tür bir adam, bu yüzden böyle biriyle paylaşmak için uygun olacak bazı referanslara ihtiyacım var.

Çok fazla kişisel görüş toplamak istemiyorum (birçoğu zaten burada paylaşıldı ), üst yönetime güçlü bir dava açmak için kullanmak için beyaz sayfalara, dergi makalelerine, bilimsel çalışmalara vb. İhtiyacım var.

Özellikle Windows 7'ye gideceğiniz için, kendi kutularınızda yönetici olmak için zorlamalısınız. Geliştiricilerin yönetici olmasını önlemek için iki gerçekten iyi neden var:

• diğer herkesin yönetici olmasını engellemenin aynı nedeni, kötü amaçlı yazılımın çalışması durumunda gerçekten korkunç şeyler yapmamasıdır.
• bu nedenle yalnızca yönetici sizseniz çalışan uygulamalar yazmazlar

UAC ile, bunların hiçbiri gerçekleşmeyecektir, çünkü başlattığınız uygulamalar kasıtlı olarak istemedikçe yönetici olarak çalışmaz. Bu nedenle, bir yönetici hesabınız olmasına izin verme riski çok düşüktür.

Bazı patronların üçüncü bir nedeni var - oyun veya yetkisiz araçlar yüklemenizi istemiyorum. Bu nedenin esasını tartışmadan, genellikle dizginsiz kaldığını gözlemleyeceğim. Yazdığınız öğeleri yüklemek, IIS'yi yapılandırmak, makinenizi çeşitli test türleri için yeniden yapılandırmak (örneğin ana makine dosyanızı düzenlemek) ve yönetici erişiminden kaçınmanın iki "gerçek" nedeni artık Windows 7 için geçerli değildir. Bu nedenle, yönetici olmalısınız.

Dürüst olmak gerekirse, bu zor bir dava olacak. Üst yönetim kararını verdikten sonra onları değiştirmelerini sağlamak oldukça zordur. Makinenizde daha fazla ayrıcalığa izin verdiyse, başka biri bu planın önlemek için tasarlandığı eylemlere erişebilir ve bunları gerçekleştirebilir.

Bunlar yardımcı olabilir:

• http://www.slate.com/id/2226279/pagenum/all/
• /server/232416/should-dev-be-admin-on-their-computer
• http://avecto.com/blog/2010/09/the-pros-and-cons-of-windows-7-application-control-with-applocker/

Not: İyi şanslar!

Seçeneklerden biri, yönetici erişimine izin veren test iş istasyonları istemektir.

Başka bir seçenek de söyledikleri gibi yapmaktır. Bir sonraki proje ortaya çıktığında, hiçbir ilerleme kaydetmeyeceksiniz çünkü her küçük değişiklik için BT'ye gitmeniz gerekiyor. Bunu proje liderine açıklayın, hemen yönetici haklarını ayarlayacaktır.

Üçüncü bir seçenek, departmanınızın Win7 geçiş projesinde temsil edilip edilmediğini kontrol etmektir. Öyleyse temsilcinizle görüşün ve bölümünüzün ihtiyaç listesine yönetici hakları ekleyip ekleyemeyeceğini sorun.

Dördüncü seçenek ticaret yapmaktır. Geçiş projesi genellikle Win7 için yazılımlarını güncellemek için geliştirilmeye ihtiyaç duyar. Yeni ortamda yönetici haklarına destekleyici bir tutum koymak mümkün olabilir.

Yerel bir yönetici olmadan gelişmeye çalışmayı hayal edemiyorum, ancak ihtiyaçların geliştirme görevlerine ve geliştirme sürecinin ve araç zincirinin işyerinizde ne kadar standartlaştırıldığına bağlı olarak değişeceğini düşünüyorum.

Deneyimlerime göre, bazı kritik sorunları hızlı bir şekilde prototiplemek veya gidermek için genellikle çeşitli geliştirme araçlarını (bazen garip saatlerde) yüklemesi gereken kıdemli geliştirme personeli vardır. Kurulum, hata ayıklama, hizmetlerle çalışma vb.Için neredeyse kesinlikle yerel yönetici erişimine ihtiyaç duyarlar.

Araç setiniz oldukça sabitse ve geliştirdikleri / hata ayıklama / dağıtmalarına bağlı olarak, kalan personel onsuz alabilir. Benim önerim, en üst düzey kıdemli üst düzey personelinizin küçük bir setini bir araya getirmek, sorunu ve seçeneklerini açıklamak ve bunları değerlendirmek için birkaç gün sürmelerini ve ardından ne tür bir erişim olduğunu belirlemek için bir planlama toplantısı yapmak olacaktır. personel olmalıdır.

Saf bir BT perspektifinden ve bir gelişim perspektifinden, birçok şirket sorunu şu şekilde çözer:

Tüm geliştirme kutularını ayrı bir ağa yerleştirin. Geliştirme ağı tamamen yalıtılmış olabilir (internet yok ve intranet yok). Bu durumda, geliştiricilerin e-posta ve resmi iletişim için kullanılan ayrı bir şirket kutusu vardır - yani hem internete hem de intranete erişim. Bazı IDE'ler (Eclipse gibi) ve diğer geliştirme araçları, güncellemeleri ve eklentileri almak için İnternet'e canlı bir bağlantınız olduğunu varsayarken, bu çözümün kendi zorlukları vardır. Geliştirme araçlarının büyük çoğunluğu yalıtılmış ağların var olduğunu biliyor.

Bu yaklaşımın bir başka varyasyonu, dev ağın bir alt ağda bulunmasıdır. Sıkı bir DMZ güvenlik duvarı üzerinden internete ve intranete dolaylı erişiminiz var, ancak yine de geliştiricilerin yerel yönetici erişimi var.

Geliştiricilere iki hesap vermeyi düşünün.

Birincisi, tüm günlük işler (yazılım geliştirme dahil) için kullanılacak olan normal ayrıcalıklı olmayan bir kullanıcı hesabıdır. Diğeri, yalnızca belirli makinelerde yönetici ayrıcalıklarına sahip olan bir yerel yönetici hesabıdır. Sadece gerçekten bir şey kurarken veya makine ayarlarını değiştirirken gereklidir.

İnternet proxy sunucusu, e-posta ve benzeri günlük hizmetlerin yalnızca normal hesabı tanıdığından emin olun, böylece geliştiriciler yerel yöneticiyi her zaman kullanamaz. Yönetici ayrıcalıkları gerektiğinde, UAC açılır ve geliştiriciye devam etmek için yerel yönetici oturum açma ayrıntılarını girme şansı sunar.

Yazılım geliştirme, kelimenin tam anlamıyla bir bilgisayarın diğer her kullanımından temelde farklı bir canavardır ve bu şekilde ele alınması gerekir.

Kendi kodunuzu yazma ve daha da önemlisi hata ayıklamada kod yürütmenizi izleme yeteneği, bilgisayarınızda başka bir bağlamda yerel güvenlik için büyük bir risk oluşturabilecek izinlere sahip olmanızı gerektirir . Ses ısırığı şeklinde yeniden yazıldı:

Yazılım geliştirme için gereken izinler tipik kullanıcılar için uygun değildir.

İşinizi yapabilmek için yerel yönetici olmanız gerekir. Ancak yerel yönetici olarak ve güvenlik politikasını atlatarak, teorik olarak ağın geri kalanı için bir risk oluşturuyorsunuz. Dolayısıyla bu kaygının da giderilmesi gerekiyor. Güvenlik açısından kritik şirketlerin bu sorunu çözme şekli, iki basit kural uygulamaktır:

1. Programcılar geliştirme makinelerinde yerel yönetici erişimine sahiptir.
2. Geliştirme makineleri şirket ağına bağlı değildir.

İkinci kuralın nasıl yürüdüğü BT departmanına bağlıdır. Bazen geliştirme makinesi kendi içinde veya dışında ağ olmadan izole edilir (birkaç Savunma müteahhitinde görülür) ve bazen makine internet erişimine izin vermek için bir "Misafir" veya "DMZ" ağına bağlanır (yamaları indirme, belgelere erişme) vb.) şirket ağını gereksiz risk altına sokmadan.

Şimdi, bununla ilgili resmi bir kaynak bulacak mısınız? Sanırım bu resmi olarak kimi gördüğünüze bağlı . Bu konudaki görüş temel olarak oybirliği ile alınmıştır. Ancak nadiren ifade edildiği çok iyi anlaşılmıştır. Biraz sormak gibi: " Arabamın park freni olmalı mı? " Konuyla ilgili konuşan yetkili kaynaklar bulamayacaksınız çünkü yapacak daha iyi şeyleri var ve herkes bu cevabı zaten biliyor.

Sanal bir ortam kullanabilir misiniz?

Grafik ağır şeyler yapmıyorsanız, MSVC'yi vmware veya virtualbox'ta çalıştırmak iyidir (eğer çok fazla koçunuz varsa) sanal ortamda yönetici olabilirsiniz ve 'onların' kurulumu kilitlidir