Czy zablokowanie maszyny programisty jest większym wysiłkiem niż jest warte? [Zamknięte]

Pracując jako programista oraz w dziale administracyjnym / wsparcia IT dla zespołu programistów, natknąłem się na wiele różnych rodzajów środowiska, od całkowicie zablokowanego do całkowicie nie-pełnego. W moim ograniczonym doświadczeniu w zakresie wsparcia uważam, że mniej wysiłku wymagało wsparcie przy mniej zablokowanej maszynie i na pewno czułem, że było to łatwiejsze, ale oczywiście może to być stronnicze. Chciałbym wiedzieć, jaki jest widok z punktu widzenia wsparcia IT, czy naprawdę trudniej jest wspierać programistów, którzy nie mają zablokowanych komputerów?

Największym problemem związanym z nie blokowaniem komputera programisty jest to, że każde oprogramowanie, które opracuje, będzie wymagało pełnych uprawnień administratora. Dostęp programistów powinien być taki sam, jak środowiska, w którym będą musieli działać. Jeśli muszą być „samoobsługowe” lub „samoinstalowalne”, daj im kolejne konto administratora, np. Bruce.admin, z którego muszą korzystać podczas administrowania rzeczy, ale nie używane z dnia na dzień.

Podobnie jak żaden przyzwoity administrator UNIX warty swojej soli nigdy nie użyje konta root do codziennej pracy bez administratora.

Większość programistów jest technicznie mądra i wie, co robią. Często muszą instalować wiele specjalistycznych aplikacji, muszą uzyskać do tego pozwolenie, a IT zejść i dodać, że może to być bardzo frustrujące, szczególnie w większych firmach, dla obu stron.

Przekonałem się, że to, co działa najlepiej, pozwala im robić, co chcą, jeśli chodzi o instalowanie oprogramowania na swoich komputerach, ale jeśli mają problemy z czymś, czego nie obsługujemy, to są sami. Większość programistów jest z tego zadowolona i mimo to woli opiekować się własną maszyną.

Zablokowanie kogoś w księgowości, aby korzystało tylko z IE i otwartego słowa, jest w porządku, ale jeśli programista, który musi zainstalować 4 różne typy przeglądarek i musi szybko zainstalować aplikację, aby rozwiązać problem, może to być denerwujące.

Moje doświadczenie polega na tym, że firmy posiadające dużą wiedzę techniczną, więc sklepy deweloperskie, dostawcy IT itp., Które ufają swoim pracownikom i pozwalają im decydować, co chcą zainstalować, są znacznie szczęśliwsze i mniej kłopotają się IT

Zobacz publikację Stackoverflow, aby wziąć udział w ożywionej debacie na temat zalet blokowania maszyn programistów. (Uwaga: Napisałem zaakceptowaną odpowiedź).

Z perspektywy sysadmin dostęp do systemów produkcyjnych jest wrażliwy i powinieneś ograniczyć taki dostęp do osób, które potrzebują go do wykonania swojej pracy (może to obejmować programistów, którzy mają obowiązki wsparcia aplikacji w warstwie 3). Lokalne uprawnienia administratora do komputera programistycznego lub serwera programistycznego nie wpływają znacząco na bezpieczeństwo systemów produkcyjnych.

Zrób obraz, którego możesz użyć do przebudowania komputerów, jeśli to konieczne. Ręczne instalowanie wersji deweloperskiej SQL Server, Visual Studio, Cygwin i MikTex oraz szeregu innych aplikacji jest dość czasochłonne. Obraz z zainstalowanymi dużymi aplikacjami będzie dość wartościowy, jeśli będziesz musiał bardzo często ponownie wyobrażać sobie maszyny.

Z perspektywy programistycznej stwierdzam, że mogę rozwiązać większość problemów z maszyną i zazwyczaj potrzebuję pomocy od personelu wsparcia sieci w dość rzadkich przypadkach. Zbyt restrykcyjne środowiska zwykle generują fałszywy ruch związany z obsługą programistów w celu wykonania pracy, którą programiści są w stanie wykonać sami.

Innym miejscem, w którym programiści często wymagają dużo pracy administracyjnej, są serwery baz danych obsługujące środowiska programistyczne. Większość programistów jest w stanie łatwo nauczyć się rutynowych zadań DBA i i tak powinna uzyskać praktyczną wiedzę na ten temat (w zasadzie IMHO). Nadmiernie restrykcyjne zasady dostępu administratora na serwerach programistycznych mogą stać się stopami na wiele sposobów.

Sieć programowania scratch jest całkiem dobrym pomysłem, jeśli można ją zaaranżować - w razie potrzeby można ją zaporować z serwerów produkcyjnych.

• Gdy programiści mogą z łatwością powielać strukturę środowiska produkcyjnego, promuje kulturę testów wdrażania, w których test integracji można zsyntetyzować bez przeskakiwania. Sprzyja to poprawie jakości wydania i wdrożenia produkcyjnego.

• Możliwość emulacji środowiska produkcyjnego podnosi również świadomość problemów związanych z wdrażaniem produkcji i wsparciem. Zachęca pracowników programistów do zastanowienia się, w jaki sposób aplikacja może być wspierana w środowisku produkcyjnym, co prawdopodobnie zachęci architekturę zbudowaną z myślą o tym.

• Jeśli ta sieć ma kontroler domeny, możesz ustanowić relację zaufania, która ufa głównemu kontrolerowi domeny i jego kontom. Ta relacja zaufania nie musi być wzajemna, więc nie zagraża bezpieczeństwu infrastruktury sieci produkcyjnej. Dzięki temu możesz mieć niezaufaną sieć programistyczną, ale nadal umożliwia programistom dostęp do zasobów uwierzytelnionych w domenie, takich jak konta Exchange lub serwery plików.

• Chcesz, aby programiści mieli rozsądny zakres eksperymentów bez konieczności przeskakiwania przez obręcze. Umieszczanie przeszkód politycznych na ścieżce tej pracy ma tendencję do zachęcania do naklejania gipsowych rozwiązań, które są politycznie celowe, ale generują długofalowy (i często nierozpoznany) dług techniczny. Jako administrator systemu lub analityk wsparcia zgadnij, kto może odebrać elementy ...

Dodam, że jest to o wiele mniej problem w środowisku unixowym lub linuxowym; użytkownicy mogą dość mocno dostosować własne środowisko ze swojego .profile. Możesz kompilować i instalować rzeczy we własnym /home/bloggsj/binkatalogu zgodnie z radością twojego serca. „Lokalne prawa administratora” to głównie problem z systemem Windows, chociaż wciąż jest kilka rzeczy, które wymagają dostępu do roota w Uniksie.

Najbardziej sensowną opcją, jaką kiedykolwiek widziałem (byłem po obu stronach - i nadal jestem -), jest po prostu odblokowanie rzeczy, a także nieobsługiwane . Daj im swobodę, a jeśli się spieprzą, wszystko, co mogą dostać, to odpoczynek ze standardowym wizerunkiem .... W tej sytuacji uważam, że dobrym pomysłem jest umieszczenie ich w jakiejś formie „niezaufanej” sieci.

Jeśli chodzi o (nie) sens blokowania pulpitów programistów: jestem prawie pewien, że wszystkie te blokady tylko ograniczają produktywność, ponadto każdy rozsądnie wykwalifikowany programista z łatwością znajdzie dziury ...

Odpowiedź jest naprawdę: nie ma prostej odpowiedzi tak lub nie. Ale bezpieczeństwo jest co najmniej tak samo ważne dla użytkowników programistów, jak i dla wszystkich innych.

Z jednej strony, tak, deweloperzy są zazwyczaj bardziej doświadczeni technicznie. Z drugiej strony ich praca jest często stresująca, a ich kamienie milowe deweloperów mogą mieć pierwszeństwo przed dodatkową opieką wymaganą do utrzymania własnego systemu jako bezpiecznego środowiska. Nie jest to krytyka programistów; jest to bezpośrednie uwzględnienie ich codziennych obowiązków.

Jeśli zamierzasz zapewnić programistom pełny, nieograniczony dostęp do ich systemów, powinieneś naprawdę rozważyć następujące dodatkowe środki:

• Zapewnij inny system, zablokowany tak samo, jak normalne systemy użytkownika są zablokowane, do normalnego użytku przez programistów.
  • Umieszczają swoje maszyny deweloperskie z pełnym dostępem w specjalnej sieci VLAN, z dostępem tylko do zasobów programistycznych.
• Zapytaj co, jeśli cokolwiek powstrzymałoby zainfekowany system przed zagrożeniem dla bazy kodów. Czy maszyna z backdoor'em mogłaby sprawdzić złośliwy kod lub wyczyścić bazę kodów w rękach wrogiego hakera? Podejmij odpowiednie kroki w celu ograniczenia tego ryzyka.
• Podobnie zapytaj, co, jeśli cokolwiek chroni dane biznesowe przechowywane w systemach, do których mają dostęp deweloperzy.
• Regularnie przeprowadzaj inwentaryzację oprogramowania i audyt bezpieczeństwa systemów deweloperskich.
  • Dowiedz się, jakie są uruchomione i wykorzystaj te informacje, aby zbudować obrazy przeniesienia systemu deweloperskiego.
  • Wcześniej czy później będziesz mieć dewelopera, który robi się nieostrożny i instaluje rzeczy, które są wyraźnie niebezpieczne lub całkowicie niezwiązane z pracą. Wysyłając ostrzeżenia szybko, gdy to się stanie, poinformujesz społeczność deweloperów, że tak, ktoś ogląda i jest odpowiedzialny za zachowanie rozsądnych standardów.
• Czy regularnie przeprowadzasz skanowanie w poszukiwaniu złośliwego oprogramowania? W niektórych przypadkach deweloperzy słusznie narzekają na podatek od wydajności nakładany przez systemy AV z dostępem (te systemy AV, które są zawsze włączone, zawsze skanują przy każdym dostępie do plików). Zaleca się przejście na strategię skanowania nocnego i / lub tworzenie wykluczeń plików / folderów podczas skanowania podczas uzyskiwania dostępu. Upewnij się jednak, że wykluczone pliki są skanowane w inny sposób.
  • Czy Twoi administratorzy mogą wyłączyć wszystkie skanowanie AV? Jak możesz to wykryć i naprawić?

Jeśli zamierzasz zablokować systemy deweloperskie, powinieneś rozważyć następujące kwestie:

• Czy masz zdolność do szybkiego odpowiadania na ich prośby? Zastanów się nad średnią stopą wypłat twoich twórców i zapytaj, czy zasługują na szybszą umowę SLA z czasem odpowiedzi. Prawdopodobnie nie ma sensu utrzymywanie 120 000 USD na koncie dewelopera (który jest kluczem do projektu o wartości wielu milionów dolarów) podczas oczekiwania na wsparcie od pracowników w wysokości 60 000 USD rocznie.
• Czy masz jasną i jednoznaczną politykę dotyczącą tego, jakie prośby o wsparcie zrobisz, a czego nie obsłużysz dla swoich programistów? Jeśli zaczną się wrażenie, że wsparcie jest arbitralne, to będzie w końcu odczuwać ból.

Tak czy inaczej, musisz przyznać, że programiści są specjalnym przypadkiem i potrzebują dodatkowego wsparcia. Jeśli nie zamierzasz przeznaczyć na to budżetu, problemy prawdopodobnie będą się teraz narastać ... lub będą w przyszłości.

Na marginesie, widziałem bardzo podobne argumenty toczące się z sysadminami. Przy co najmniej dwóch różnych zadaniach, które widziałem, sysadmini kłócili się dość ostro, gdy zasugerowano, że sami powinni mieć zablokowane systemy lub przynajmniej użyć dwóch loginów (jedno z uprawnieniami root / admin, drugie bez). Wielu sysadminów uważało, że nie powinno się ich w żaden sposób zamykać i usilnie argumentowało przeciwko takim środkom. Wcześniej czy później jakiś niechętny administrator miałby incydent bezpieczeństwa, a przykład miałby wpływ edukacyjny na nas wszystkich.

Byłem jednym z tych administratorów, którzy cały czas biegali z administratorami. Kiedy dokonałem zmiany na podwójne konta i tylko podwyższałem w razie potrzeby, przyznaję, że było to dość frustrujące przez pierwsze kilka miesięcy. Ale srebrną podszewką w chmurze było to, że dowiedziałem się znacznie więcej o bezpieczeństwie systemów, którymi administrowałem, kiedy moje normalne konto działało pod tymi samymi ograniczeniami, które nakładałem na użytkowników. To uczyniło mnie lepszym administratorem! Podejrzewam, że to samo dotyczy programistów. I na szczęście w świecie Windows mamy teraz UAC, co ułatwia uruchamianie jako ograniczony użytkownik i podnoszenie tylko w razie potrzeby.

Osobiście nie uważam, że ktokolwiek powinien być ponad jakąś formą praktyk bezpieczeństwa. Wszyscy (w tym sysadmini, deweloperzy, w tym kierownictwo wyższego szczebla) powinni podlegać wystarczającym procedurom bezpieczeństwa i nadzorowi, aby utrzymać ich na nogach. Powiedzieć inaczej to powiedzieć, że systemy i dane firmowe nie są warte wysiłku w celu ochrony.

Ujmijmy to inaczej. Jeśli Mark Russinovich może zostać przejęty przez rootkita , każdy może!

Jeśli masz kilku programistów, podejście do nadania im serwerów programistycznych jest możliwe, ale jeśli masz całe piętro programistów, jestem zdecydowanie przeciwny przyznaniu im jakichkolwiek praw administracyjnych.

Problem polega na tym, że skończysz z całym piętrem programistów, z których każdy robi to, co robią, zwykle większość nie jest nawet świadoma bezpieczeństwa i po prostu chce, aby ich aplikacja działała. Następnie zostaniesz zapytany: „Zakończyliśmy fazę rozwoju, prosimy zreplikować nasze środowisko programistyczne na test, pre-prod i prod”.

Mają też zwyczaj instalowania losowych śmieci (źle spakowane oprogramowanie), a następnie delegują cię do zainstalowania go na kilkunastu serwerach na innych poziomach.

Sprawiam, że polityka jest bardzo prosta:

• Deweloperzy NIE uzyskują dostępu do roota - nigdy - dla środowiska programistycznego.
• Programiści mają dostęp do roota do wcześniej przygotowanych serwerów VMware, ale NIE ma wsparcia.
• Programiści muszą albo dostarczyć pakiety RPM należące do dystrybucji systemu operacyjnego, na której będzie działać ich aplikacja, lub pakiety RPM zgodne z FHS i LSB.
• Żadna z ich aplikacji nie może w żadnym wypadku działać jako root
• Nie będzie miał dostępu do suani sudodo użytkownika aplikacji - co zostanie zablokowane na brak dostępu do powłoki. (Dotyczy księgowości / audytu).
• Wszelkie polecenia, które muszą być uruchomione z uprzywilejowanym dostępem, będą musiały zostać wyraźnie zażądane i zatwierdzone - w tym czasie zostaną dodane do sudoerspliku.
  • Żadne z tych poleceń / skryptów nie będzie przez nich zapisywalne.
  • Żadne odniesienia do skryptu (bezpośrednio lub pośrednio) przez te polecenia nie będą przez nich zapisywane.

To przede wszystkim sprawi, że będą myśleć o tym, co będzie i nie będzie dozwolone, gdy przyjdzie czas na przeniesienie projektu na test i na serwery.

Blokowanie maszyn programistów wymaga więcej wysiłku niż jest to warte. Poważnie szkodzi to produktywności, ponieważ nie można zrobić prawie nic bez uprawnień administracyjnych. Oczywiście w końcu system zostanie popsuty, ale na pewno Twój dział IT nie zapewnia wsparcia dla wszystkich narzędzi innych firm, które są używane w programowaniu?

Tak więc, jak zasugerował Vincent De Baere, najlepszym rozwiązaniem byłoby przywrócenie systemu z obrazu, oczywiście środowisko musi zostać przywrócone, ale to nie powinno być problemem IT. Jeśli zdarzy się to N razy, możesz umieścić tę osobę na „czarnej liście” i tak, porzucić uprawnienia administracyjne.

Tak czy inaczej, środowisko powinno być skonfigurowane w taki sposób, aby upewnić się, że zainfekowana (lub w inny sposób pomieszana) maszyna w ogóle nie wpłynie na żadne inne maszyny lub, powiedzmy, nie wysyła spamu lub czegoś (ok, teraz Przepraszam, mówię tylko oczywiste rzeczy.

Cóż, może częściowo zależeć od środowiska, w którym pracujesz (np. Linux kontra Windows); jednak przy założeniu, że środowisko Windows jest zwykle bardziej kłopotliwe, niż warte tego, ponieważ niektóre oprogramowanie programistyczne wymaga podwyższonych uprawnień do pracy. Na przykład wiadomo , że Visual Studio wymaga uprawnień administratora , dlatego nie widzę korzyści w zmuszaniu kogoś do przeskakiwania przez obręcze dla wymaganej części ich pracy.

Jednakże, jeśli firma wymaga, aby sprawy zostały zamknięte, twój najlepszy zakład prawdopodobnie zapewni wszystkim programistom maszyny wirtualne w ich systemach, w których mogą oszaleć. Chociaż niektórym może się to nie podobać, prawdopodobnie zapewni ci to, co najlepsze z obu światy (np. restrykcyjny zwykły pulpit i w pełni konfigurowalne środowisko).

Aktualizacja - po stronie systemu Windows warto zwrócić uwagę, najwyraźniej program Visual Studio wymagający uprawnień administratora jest nieco przestarzały i istnieją teraz wyraźne sposoby ustawiania wymaganych uprawnień (plik PDF). Jednak nie sądzę, aby zmieniało to moją opcję tak bardzo, że większość programistów, których znam, łącznie ze mną, ma tendencję do korzystania z dodatkowych narzędzi poza Visual Studio, a wiedza o tym, czego wszyscy potrzebują w zakresie uprawnień, może być trudna do przewidzenia.

Zgadzam się z koncepcją używania maszyn wirtualnych na ograniczonym komputerze stacjonarnym

O ile nie jest to wymagane inaczej, uważam, że najlepszą konfiguracją jest ograniczony komputer z linuksem i darmowym vm na górze. Linux dla mnie zmniejsza koszty ogólne, vm może być nie tylko tym, czego chcą do cholery, ale także przywrócone do migawek lub kopii zapasowych, i ogólnie świat wygląda nieco jaśniej, gdy nie ma całej masy różnych konfiguracji wymagających wsparcie.

Ja (jako sam deweloper) wolę mieć pełną kontrolę nad moją maszyną, co oznacza; działający jako administrator w razie potrzeby.

Możesz zapewnić specjalne szkolenie dla programistów, zanim uzyskają pełny dostęp do ich komputerów. Ustaw dla nich pewne zasady, a być może możesz raz na jakiś czas przeprowadzić audyt, aby sprawdzić, czy przestrzegają najlepszych praktyk.

Przeważnie będą musieli dowiedzieć się więcej o infrastrukturze IT z widoku administratora IT / wsparcia IT, kwestii związanych z bezpieczeństwem, a także dlaczego nie rozwijać się z podwyższonymi uprawnieniami. (i jak się upewnić, że nie ...)

„Nie ślepo nam ufaj, gdy powiemy ci, że wiemy wszystko, co musimy wiedzieć o komputerach” ;-)

Nadal będziesz musiał wspierać ich przy tworzeniu sieci, domen i kont, instalacjach oprogramowania narzędzi innych niż deweloperskie itp.

Moje doświadczenie dotyczy populacji użytkowników, która była równomiernie podzielona między osoby, które potrzebowały tylko zablokowanej maszyny, i inne (programiści, naukowcy), którzy potrzebowali dostępu administratora. Ludzie z wyższej półki używali wielu różnych programów, niektóre wewnętrzne, niektóre nie, ale wiele z nich wymagało uruchomienia przez administratora, a ich praca wymagała od nich korzystania z wielu pakietów, więc najrozsądniej było pozwolić ludziom to zrobić to sami.

Skończyliśmy z następującymi procesami:

• Nasz standardowy obraz miał podstawowe narzędzia: Windows, Office, antywirusowe, Acrobat, kilka narzędzi.
• Zapewniliśmy dużo miejsca na dysku sieciowym: wystarczająco, aby wszystko mogło być przechowywane w sieci. Jedynym wyjątkiem były pliki wideo w trakcie przetwarzania, które musiały pozostać lokalne.
• Personel (w porozumieniu ze swoimi przełożonymi) miał dwie możliwości: albo IT utrzymał komputer, wykonując wszystkie instalacje i konfigurację, albo mogliby mieć dostęp administratora, aby zrobić to sami. W obu przypadkach utworzono kopię zapasową wszystkich danych w sieci.
• Jeśli dział IT utrzymałby system i przestał działać, przywrócilibyśmy go do stanu, w którym był, w tym dodając dodatkowe potrzebne oprogramowanie, które zainstalowaliśmy.
• Gdyby mieli dostęp administratora, a system zginął, spojrzeliśmy i spróbujemy to naprawić, ale naszym zobowiązaniem było przywrócenie ich do standardowego obrazu i musieliby go stamtąd zabrać. Gdyby mieli jakieś dane lokalne, najpierw spróbowalibyśmy je usunąć, ale nasza umowa SLA polegała na jak najszybszym udostępnieniu im działającego, standardowego komputera.
• Każdy, kto miał dostęp do administratora, musiał wiedzieć, jak upewnić się, że aktualizacje systemu Windows działają, aby aktualizować program antywirusowy i anty-malware.

Chcielibyśmy umieścić wszystkich ludzi z dostępem administracyjnym na „niezaufanym” vlan, ale nigdy tego nie dostaliśmy.