Geliştiricilerin bilgisayarlarında yönetici izinleri varsa

Geliştiricilerin bilgisayarlarında yönetici izinleri olmalı mı veya onlara güçlü kullanıcı erişimi sağlıyor mu?

Bazı yorumlar:

• Yüklenmesi gereken yeni bir uygulama denemek isterse, sanal bir makinede deneyebilir ve daha sonra ağ yöneticisini kendileri için yüklemesini sağlayabilirler. Bunun işe yarayacağını düşünüyor musunuz?
• Bir geliştiricinin bilgisayarında yönetici izinleri gerektirecek bir şey yapması gerekiyor mu?

5 geliştiriciden oluşan ekibiz ve web uygulamaları geliştiriyoruz

Cevap Evet'. Geliştiricilerin öğeleri test etmek, yazılım yüklemek (başka bir şey değilse, geliştirdikleri her şeyin kurulum sürecini test etmek için) sistem yapılandırmalarıyla uğraşmaları, kayıt defteri hakkında konuşmaları ve yönetici ayrıcalıkları olmadan düzgün çalışmayacak yazılımları çalıştırmaları gerekir (sadece birkaç öğeyi listelemek için). Yönetim ayrıcalıklarının yapılmasını gerektiren geliştirme çalışmalarının ayrılmaz bir çok görevi vardır.

Geliştirme personelinin üretim sistemlerine kök erişimi olması gerekmediğini göz önünde bulundurarak, yerel bir bilgisayardaki yönetici hakları üretim sistemlerinin güvenliğinden önemli ölçüde ödün vermez. İşlerini yapması gereken personel için yerel PC'lere yönetici erişimini kısıtlamanın neredeyse hiçbir meşru operasyonel nedeni yoktur.

Ancak, idari erişim sağlamanın en önemli nedeni, güvenliği ihlal edilmiş veya ikinci sınıf bir geliştirme ortamı oluşturmanın geliştirme personelinize bir mesaj göndermesidir:

'İşinize o kadar az değer veriyoruz ki, işinizi iyi bir sebep olmadan yapma yeteneğinizden önemli ölçüde taviz vermeye hazırız. Aslında, bunu kendi kıçımızı örtmek, küçük bürokrasinin kaprislerine yalvarmak ya da rahatsız edemeyeceğimiz için mutluyuz. Bu sadece en iyi durum. En kötü durum, size işinizi nasıl yapacağınızı ve ne yaptığınızı ya da yapmanıza gerek olmadığını anlatmak için bunu perogatif olarak gören kontrol düşkünleri olduğumuzdur. Verdiğiniz şeyleri yapın ve hiç bir işiniz olduğu için minnettar olun. '

Genel olarak, geliştirme personeli için ikinci sınıf (temelde kusurlu olsun) bir çalışma ortamı sağlamak, personelinizi kızdırmanın doğal sonuçları için bir reçetedir - yetkili kişileri alamama, yüksek personel cirosu, kötü moral ve düşük kaliteli teslimat. Bunu yapmak için yolunuzdan çıkmak - özellikle bürokratik heves için aşırı bir pandering varsa - sadece sorumsuzdur.

Personel cironuzun sadece personel değiştirme maliyetlerine yol açmayacağını unutmayın. Personel cirosunun en ciddi maliyeti, etrafta dolaşanların çoğunun daha iyi bir iş bulamayan deadwood olacağıdır. Zamanla bu, etkilenen bölümlerin yeteneklerini azaltır. Endüstriniz yeterince yakınsa, kendinizi ün kazanmış bulabilirsiniz.

Unutulmaması gereken bir nokta, yönetimsel ayrıcalıkların Unix-Oid veya anabilgisayar sistemlerinde geliştirme için Windows'da olduğundan çok daha az sorun olduğudur. Bu platformlarda bir kullanıcı, sistem genelinde izinlere ihtiyaç duymadan kendi etki alanında çok daha fazlasını yapabilir. Muhtemelen geliştiriciler için hala kök veya sudo erişimi isteyeceksiniz, ancak buna sahip olmamanız daha az sıklıkta ayağa kalkacaktır. Bu esneklik, Bilgisayar Bilimleri okullarında unix'ten türetilmiş işletim sistemlerinin devam eden popülerliğinin önemli fakat daha az bilinen bir nedenidir.

Geliştiriciler, kullandıkları makinenin tam ve tam kontrolüne sahip olmalıdır. Çoğu hata ayıklama aracı, oluşturdukları uygulamanın çalışma zamanına bağlanmak için yönetici izinleri gerektirir.

Ayrıca, devs sık sık yeni şeyler indirip dener. Bir ağ yöneticisinin gelip onlar için bir şey yüklemesi gibi ek adımlar eklemek, sadece geliştiriciyi sinirlendirir ve ağ ops kişisi için hayatı cehenneme çevirir.

Bununla birlikte, ağda değil, THEIR kutusunda bir yönetici olmalılar.

Evet ve hayır.

Evet, sistem desteğini rahatsız eden çok zaman kazandırır.

Hayır, kullanıcılarınız buna sahip değil, bu yüzden güvenmeyin.

Yönetici izinleriyle geliştiririz ve olmadan test ederiz. Hangi doğru çalışıyor.

Yerel yönetici evet, yukarıda belirtilen tüm nedenlerden dolayı. Ağ yöneticisi no, çünkü kaçınılmaz olarak ağ yönetimi görevlerine çekileceklerdir çünkü "yapabilirler". Geliştiriciler gelişiyor olmalı. Ağ yönetimi tamamen farklı bir iştir.

Geliştiricilerin normalde ortalama bir kişinin yapamayacağı şeyleri yapması gerekir ve normalde yönetici hesapları olmalıdır. Onları beceriksiz çemberlerden atlatmak zamanlarını boşa harcar ve onları demoralize eder. Yüksek güvenlikli durumlarda istisnalar olabilir, ancak bir yönetici hesabına sahip birine güvenemiyorsanız, kodlarına güvenemeyeceğinizden emin olabilirsiniz.

Ayrıca, kullanıcılarıyla aynı izne sahip kullanılabilir bir hesaba sahip olmalıdırlar (kullanıcı havuzunun farklı izin durumları varsa birden fazla hesap). Aksi takdirde, havalı bir şey geliştirebilir, dağıtabilir ve ardından kullanıcılar için işe yaramayacağını görebilirler.

Ayrıca bilgisayarları yönetici hesaplarıyla yıkamanın çok fazla yolu var (evet, yaptım). BT departmanı, geliştiricinin bilgisayarını hızlı bir şekilde düzeltemezlerse yeniden görüntüleyecekleri bir politikaya ihtiyaç duyar. Anlaştığım bir yerde, yönetici hesabımı almak için bu politikanın bir kopyasını imzalamak zorunda kaldım.

Bu oldukça Windows'a özgü bir cevap. Linux ve diğer Unix-y sistemlerinde, geliştiriciler yalnızca kullanıcı hesaplarıyla daha fazla uğraşırlar, genellikle test için başka bir hesaba ihtiyaç duymazlar (sudo'yu seçebilecekleri bir hesapları varsa, ne zaman kullandıklarını bilirler sudo, ancak aynı grup izinlerine sahip olanlara ihtiyaç duyabilirler) ve işletim sistemine inanılmaz miktarda hasar verebilir, bu nedenle aynı BT politikası gereklidir.

Evet, Half-Life 1 (ve ilgili tüm modlar: counter-strike, yenilgi günü, vb.) Windows NT, 2000, XP, vb. .

Ve ne tür bir geliştirici Counter Strike'ı öğle yemeğinde oynamıyor? (kesinlikle berbat bir tane)

Makinede yönetici hakları olmadan gelişmek zorunda kalmanın acısına katlandığımda cevabım sadece evet olabilir, bu çok önemli.

Kesinlikle! Geceleri film indirmek için indirme yöneticisini başka nasıl yükleyebilirim?

Bazen geliştiricilerin bazı fikirleri test etmek için gerçekten bir şeyler yüklemeleri veya sistemde bir şeyleri değiştirmeleri gerekir. Bir şeyi her değiştirmeniz gerektiğinde yöneticiyi aramanız gerekirse imkansız olacaktır.

Ayrıca, bazı yöneticilerin küçük şeylerin bile günlük olarak onlara bağımlı olmasını sağlamak için mümkün olan her şeyi sıkılaştırmaya meyilli olduğunu gözlemledim, böylece ... ne, işlerini güvence altına alıyorlar? diğer kullanıcıları öfkelenerek? Cevap yok. Ancak burada sağduyu görülmez.

Bilgisayarımda son kez bir sorun vardı, sistemi geri yükleme, yönetici ile takımda bazı önerilerde bulunma konusunda aktif bir rol aldım ya da düşündüm ... Yönetici çok kızgın oldu ve beni öğretmeye çalışmakla suçladı onu veya kuralları yeniden tanımlayın. Sanırım o diğer meslektaşları arasında odamızda o serin görmedim sadece onun egosu oldu.

Cevap, geliştiricilerin 2 makineye sahip olması gerektiği!

• Kurumsal antivirüs yazılımı yüklenmiş ancak otomatik sıfırlama ilkesi ile gerektiğinde geliştirici tarafından yapılandırılabilir, yönetici hakları ve yeterli güç, bellek, ekran boyutu ve taşınabilirlik ve ADMIN ayrıcalıklarına sahip bir geliştirme.

• Kurumsal yüke, politikalara, yönetici olmayan kullanıcı ayrıcalıklarına, vb. Sahip kurumsal bir uygulama ... Bazı geliştiriciler, yönetici ayrıcalıklarıyla tüm birim testlerini yapma alışkanlığına sahip olduklarından, geliştirici bunu birim test sürümü modu uygulamaları için kullanabilir.

Soruyu ters çevirirseniz, cevaplamanın daha kolay hale geldiğini düşünüyorum; yönetici izinlerini geliştiricilerden kaldırmalı mıyız? Kazanç nedir?

Ama aslında, cevabın bağlamınıza, çevrenize bağlı olduğunu düşünüyorum. Küçük bir girişimin ISO sertifikalı devlet kurumuna farklı bir cevabı olacaktır.

Evet, ancak daha sınırlı bir ortamda yazılım çalıştırırken kullanıcılarının karşılaşacakları sınırlamaların farkında olmaları gerekir. Geliştiricilerin sınırlı kaynakları ve izinleri olan "tipik" ortamlara kolay erişimi olmalıdır. Geçmişte, bu "tipik" sistemlerden birine (genellikle kendi iş istasyonumdaki bir VM) derlemeleri kurulum sürecinin bir parçası olarak dahil ettim, böylece yazılımın sonunda nasıl çalıştığına dair hızlı bir fikir edinebilirdim kullanıcının makinesi.

Programcılar ayrıca yönetici olmayan kullanıcılar için yazılım yazma zor ve hızlı kurallarını bilmek sorumluluğuna sahiptir. Hangi sistem kaynaklarına her zaman erişmelerine izin verildiğini (veya yasaklandıklarını) tam olarak bilmelidirler. Bu kaynakları elde etmek için kullanılan API'leri bilmelidirler.

"Makinemde çalışır" asla bir mazeret değildir!

Sistem yöneticisi olarak, iş istasyonlarında yerel yönetici haklarına sahip geliştiriciler için çalışıyorum. Mümkün olduğunda, standart bir 'kullanıcı' düzeyinde hesapla çoğu şeyi yapmak ve daha sonra değişiklik yapmak, uygulama yüklemek vb. İçin başka bir 'yönetici' hesabı kullanmak kötü bir fikir değildir.Genellikle giriş yapmadan bile istediğinizi gerçekleştirmek için sudo veya runas yapabilirsiniz. dışarı. Ayrıca, son kullanıcıların üretime salıverirken atlaması gereken güvenlik sorununu bize hatırlatmakta fayda var.

Bir yan notta, [düzgün] bir sisteme veya VM'ye sahip olmanız da tavsiye edilir, böylece işleri düzgün bir şekilde test edebilir ve sistem ayarlaması nedeniyle "sistemimde iyi görünüyor / çalışıyor" senaryosuna giremezsiniz.

Güçlü Kullanıcı Yok

Her şeyden önce, Power User temel olarak bir yöneticidir - dolayısıyla bir kullanıcıyı Power User ile " sınırlamak " sistemde herhangi bir güvenlik artışı sağlamaz - yönetici de olabilirsiniz.

Etkileşimli olarak normal kullanıcı olarak oturum açın

İkincisi, elbette bir geliştiricinin geliştirici makinesine (ve sunucularına ve ikinci kutularına vb.) Yönetici erişimine ihtiyacı vardır, ancak elbette hiç kimse normal geliştirme veya test sırasında etkileşimli olarak yönetici olarak oturum açmamalıdır. Bu ve çoğu uygulama için normal bir kullanıcı hesabı kullanın.

Yönetici olarak [herhangi bir tarayıcı, eklenti, anlık mesajlaşma, E-posta istemcisi vb. Ekleyin] cidden çalıştırmak istemezsiniz.

Gereksinim duyduğunuzda kök erişiminiz olsa bile normalde Linux kutunuzda root olarak oturum açmazsınız.

Ayrı bir kişisel yönetici hesabı kullanın

Geliştiriciye, makinesine ayrı ayrı bir kişisel yönetici hesabı (tercihen etki alanı hesabı) sağlayın; bu, diğer geliştirici / test sunucularında ve kişinin yönetici erişimine ihtiyaç duyduğu kutularda da geçerli bir yöneticidir.

İstemi istemek veya istemek ve yalnızca ihtiyaç duyulduğunda görevler ve işlemler için yönetici kimlik bilgilerini girmek için "farklı çalıştır" ve Vista + UAC'de kullanın. Akıllı kartlı veya benzeri PKI, kimlik bilgilerini sık sık girme zorluğunu büyük ölçüde azaltabilir.

Herkes mutlu (ya da?;)

Ardından erişimi denetleyin. Bu şekilde izlenebilirlik ve şu anda erişmeniz gereken belirli bir geliştirici / test sunucusunda terminal hizmetleri oturumlarını kimin kullandığını öğrenmenin kolay bir yolu var ...

Kesinlikle yerel yönetici ayrıcalıkları gerektirmeyecek geliştirme çalışmaları vardır - dağıtımın ayrı bir sunucuya veya sanal makineye karşı test edildiği ve cassini'nin veya yerel hata ayıklama için kullanılan her şeyin normal bir kullanıcı olarak iyi çalıştığı birçok web geliştirme gibi.

Öncelikle * nix dünyasında ve standart modelde çalışıyorum, geliştiricilerin gerektiğinde yönetici ayrıcalıklarına tırmanabilme ( sudoveya aracılığıyla su) yeteneğine sahip normal, ayrıcalıklı olmayan bir kullanıcı hesabında çalışması .

Eşdeğer Windows düzenlemesinin ne olacağından emin değilim, ancak bu benim deneyimime göre ideal kurulum:

• Bir yandan, isteğe bağlı yönetici haklarına sahip olmak, geliştiriciye gerektiğinde iş istasyonu üzerinde tam güç verir.

• Öte yandan, Windows yazılımı, yönetici olmayan bir kullanıcı için birçok programın çalışmadığı noktaya kadar, tüm kullanıcıların yönetici haklarına sahip olduğunu varsaymak için uzun ve uzun bir geçmişe sahiptir. Windows'un güvenlik sorunlarının birçoğu, bilgisayarı güvenle kullanabilmek için tüm kullanıcıların yönetici olması gereken doğrudan bu örtük gereksinimden kaynaklanır. Bu değişmelidir ve yazılımınızın yönetici olmayan kullanıcılar için çalışmasını sağlamanın en etkili yolu, geliştiricilerinizin kendilerini yönetici olmayan kullanıcılar olarak çalıştırmasıdır.

[özür ingilizce anadilim değil, elimden gelenin en iyisini yapıyor :)]

Kişisel deneyim (ben bir c ++ / SQL geliştiricisiyim):

Önceki işimde windows makinemin yöneticisi olarak çalışıyordum. Üretim ortamı veritabanları da dahil olmak üzere veritabanlarında dbo (dba değil) haklarına sahiptim. Bu çılgın yüksek haklara sahip 8 kişi ile 2 buçuk yılda ... hiç sorun yaşamadık. Aslında db'yi manuel olarak güncelleyerek birçok sorunu çözdük. Sıcak düzeltmeler ve geliştiriciler için gerçekten çok hızlı yapabiliriz.

Şimdi iş değiştirdim. Windows makinemin yöneticisi olmayı başardım (çok ağlıyorum). Ancak dev sunucusu, ssh kullanarak bağlandığımız kırmızı bir şapka sunucusudur. Qt yüklemeye çalışmak bir işkence, Kota sınırları, alan sınırları, yürütme ve yazma haklarıydı. Sonunda vazgeçtik ve yöneticiden bizim için yapmasını istedik. 2 hafta sonra hala hiçbir şey kurulmadı. Gazete okumada ve alt + tab isabetinde çok hızlı oluyorum.

Yönetici haklarını istedim, çünkü sadece yazılımımın geliştiricisi bu makineyi kullanıyordu.

-> Cevap: "Eğer süreçler varsa ne istersen yapmamalısın. Prod bir kez iyi çalıştırmak zorunda".

-> Teknik olmayan bir yöneticiye açıklamaya çalışmak: "Üretimde veya UAT ortamlarında hiçbir şekilde yönetici haklarına sahip olmayacağım. Ama geliştirici makinem farklı. Yazılımlar yerine sandalye kuracak olsaydım, yapabileceğimi söyler misin? Atölyemde istediğim araçları koymuyorum, çünkü atölyemin sandalyenin kullanılacağı yere benzemesi gerekiyor mu? Uat'a çalıştırılabilir bir paket veriyorum Bunları oluşturmak için kullandığım kütüphaneler ve araçlar son kullanıcı veya görünmez paketi yükleyen ahbap. "

Bugün hala bekliyorum. Bir çözüm buldum, geliştirici bir ortam açtım, en sevdiğiniz çevrimiçi hakime gidin, kendinize meydan okuyun. birisi ekranınıza baktığında, sizi programlamayı görecek. ;)

Buna iki şekilde cevap verebilirsiniz. Evet ve hayır, ya da duruma göre değişir. - Daha belirsiz olabilir miyim ...

İşlerini yapmaları gerekip gerekmediğine bağlıdır. Eğer öyleyse, onlara bilgisayarları üzerinden idari yetkiler verir. Değilse yapmayın. Tüm yazılım geliştirme işlemleri için bir mühendis yönetici haklarına sahip değildir.

Evet ve hayır görüşlerinize bağlıdır. Bazı mühendisler bilgisayarlarını etki alanları olarak görürler ve etki alanlarının kurallarıdır. Diğerleri sorumluluğu istemiyor.

Yönetici haklarının olmadığı bir şirkette çalıştım ve yönetici hakları gerektiren bir şey yapmam gerektiğinde yardım masasını aramam gerekti ve yeniden başlatılıncaya kadar geçici yönetici hakları verdiler. Bu bazen bir acıydı, ama ben de öyle davrandım. Bilgisayarımda yönetici haklarına sahip olduğum yerlerde de çalıştım. Bu işletim sistemi hosed ve bilgisayarımı yardım masasına almak ve onları sabit sürücüyü yeniden görüntü almak zorunda kaldı bazı yazılım dışında zaman harikaydı.

Şahsen bir mühendisin bilgisayarlarında yönetici haklarına sahip olması gerektiğini hissediyorum, ancak bunu bozarlarsa yeni bir temel görüntünün yeniden yüklenebileceğini ve orijinal taban çizgisinden bu yana yapılan her şeyi kaybedeceklerini anlayarak. Ancak bir şirketteki herkesin bilgisayarlarında yönetici haklarına sahip olması gerektiğine inanmıyorum. Muhasebe, idari asistanlar ve diğer departmanların bu haklara sahip olmaları gerçekten gerekli değildir, bu nedenle verilmemelidirler.

ht tp: //msdn.microsoft.com/tr-tr/library/aa302367.aspx

Deneyimlerime göre, biz (kodlayıcılar) ve onlar (güvenlik) arasında bir uzlaşma her zaman gereklidir. Kabul ediyorum (nefret etmeme rağmen), yukarıdaki Microsoft makalesinde hak var. Yıllardır programcı olduğum için, sadece farklı bir hata ayıklayıcı kurmak için gereken acıyı yaşadım, sadece rahatsız edemediğim için. Beni işimi nasıl yapacağım konusunda yaratıcı düşünmeye zorladı. Güvenlik ekibimizle (ve birkaç tartışmayla) yıllarca mücadele ettikten sonra, masaüstüm de dahil olmak üzere tüm alanları güvence altına almak zorunda olduklarını anlıyorum. Bana en basit Quicktime uygulamasında bile ortaya çıkan günlük güvenlik açıklarını gösterdiler. Ciddi bir güvenlik sorununa neden olabileceğim hızlı bir yardımcı program yüklemek veya yerel IIS'mde ince ayar yapmak istediğimde sinirlenmelerini görebiliyorum. Başka bir geliştiricinin konserve olduğunu görene kadar bunu tam olarak anlamadım. Hata ayıklamaya çalışıyordu ve Symantec'i yalnızca yüzlerce insana virüs bulaştırmak (ve sonra vermek) için kapattı. Dağınıktı. Olanlar hakkında "secheads" (güvenlik görevlileri) biriyle konuşurken, sadece "Sana söylemiştim ..." demek istediğini görebiliyordum.

Bizim sechead'larımızın (en azından benim) sadece şirketimizi korumak istediğini öğrendim. İyi haber şu ki, bir uzlaşma bulduk ve güvenli ağımızla işimi halledebilirim ve secheads havalı!

İnanç

Pentesterlerin veya bazı yetenekli kötü niyetli kullanıcıların alan adınızın güvenliğini ihlal etmesini istiyorsanız.

yani Düşük düzeyli hesabın güvenliğini ihlal et> Nerede bulun admin -> Mimikatz -> İzinleri yükselt -> Alan adı yöneticisi.

Yani hayır, normal kullanıcılar yönetici olmamalıdır.

Ayrıca Microsoft, UAC'nin bir güvenlik sınırı olmadığını söyledi, bu yüzden kullanmayın. UAC'nin çeşitli gerçek dünya baypasları mevcuttur.

İş rollerinin bir parçası olarak yöneticiye ihtiyaçları varsa, yalnızca genel kullanım veya internet erişimi için değil, yalnızca yazılım yüklemek için kullanılan ayrı etki alanı yerel yönetici kullanıcı hesaplarını verin (yalnızca kendi makinelerinde yönetici izinleriyle). Bunun daha katı bir şifre politikası olmalıdır (örneğin minimum 15 karakter uzunluğu). Bunun için Runas işlevselliği kullanılmalıdır.

Normal kullanıcı hesaplarının yönetici olduğu her ortam, bir güvenlik felaketinin reçetesidir.

Vay be, bu soru kesinlikle bazı ilginç cevaplara açılacak. Cevapta kullanılan oft teklif - 'Bağımlı' :)

Küçük şirketlerde bu sadece pragmatik olma meselesi olabilir. Geliştiricilerin de teknik olarak en usta olmaları muhtemeldir, bu yüzden kendi makinelerini yönetmeleri mantıklıdır.

Şahsen ben gerektiğinde kullanılabilecek "yönetici hesabı" hayranıyım - yani "Farklı Çalıştır .." (Bu yaklaşımın daha sonra UAC ile çok benzer olduğunu fark ettim).

Masaüstü yazılımı geliştiriyorsanız, geliştiricilerin son kullanıcılarının deneyimleyeceği sınırlar dahilinde çalışması kötü bir fikir değildir - sınırlı veya kısıtlı haklar. Yazılımı sınırlı haklar altında oluşturursanız, hedef kullanıcılarınızın aynı izin kümesi verildiğinde karşılaştığı sorunları yaşamanız iyi bir olasılıktır.

Söyledikten sonra, iyi bir test laboratuvarınız ve / veya iyi bir KG ekibiniz varsa, bu özellikle tartışmalı bir nokta olabilir - özellikle de yarım iyi bir ALM uygulamanız varsa.

Sonunda - UAC olmadan gelişiyorum, çünkü kendime ve becerilerime güveniyorum. Takım ortamında, oy kullanmak isterdim. Daha büyük organizasyonlarda bu özgürlüğe sahip olmayabilirsiniz .. Enterprise Admins genellikle son söz :)

Şirketimde, geliştiriciler, mühendisler ve patronum (şirketin sahibi) yerel yönetici ayrıcalığına sahip. Patronumun da bu şekilde giden otobüse çarpmak (veya çıkmak) durumunda ağ yöneticisi ayrıcalığı vardır. Diğer herkes kilitlenir.

Sysadmin olarak, bu kurulum zaman zaman, özellikle onaylanmamış yazılım yüklendiğinde bana biraz keder verdi. Ancak, bir geliştirici geçmişinden geldiğimde, güç kullanıcılarının çevreleri üzerinde daha fazla kontrole sahip olma ihtiyacını anlıyorum ve bu nedenle, zaman zaman karşılaşabilecekleri tuhaflık veya sorunlara katlanmaya hazırım. Her durumda iş istasyonlarının rutin yedeklemelerini yapıyorum.

Bu arada, patronla diğer insanlardan daha fazla şeylerle uğraşmaktan daha fazla sorun yaşadım. Eski bir soru gibi, "Bir fil nerede oturuyor? İstediği her yerde!" Ama aslında "yedek" sistem yöneticisi olduğu küçük bir firmada fazla seçenek yok.

Geliştirici becerilerine ve danışman olup olmadığına bağlıdır.

Tecrübeli ve güvenilir bir geliştiricinin, üretkenliğine zarar vermediği sürece bilgisayarıyla istediği her şeyi yapma hakkına sahip olması mantıklıdır.

Windows XP'de hiç kimse günlük kullanım için yönetici hesabı kullanmamalı ve en az UAC etkinleştirilmiş bir yönetici olmanız gerekiyorsa Vista'da. Özellikle Internet Explorer ile web'e göz atan web geliştiricileri ve diğer geliştiriciler.

Yapabileceğiniz şey, geliştiricilerin normal kullanıcı hesaplarını kullanmalarıdır, ancak onlara gerektiğinde kullanabilmeleri için bilgisayarlarında yönetici olan ikinci bir hesap verin (Farklı Çalıştır). Web geliştirme dediğini biliyorum, ancak Windows geliştirme için yazılımınız yönetici olarak değil, normal bir kullanıcı hesabı kullanılarak test edilmelidir.