Aby zaktualizować czy nie zaktualizować?

Od momentu rozpoczęcia pracy w miejscu, w którym teraz pracuję, walczę z szefem i współpracownikami o aktualizację systemów.

Oczywiście całkowicie się zgadzam, że jakakolwiek aktualizacja (oprogramowanie układowe, system operacyjny lub aplikacja) nie powinna być stosowana niedbale, gdy tylko się pojawi, ale głęboko wierzę, że powinien istnieć przynajmniej jakiś powód, aby sprzedawca ją wydał; a najczęstszą przyczyną jest zwykle jakiś błąd ... ustalające, które być może nie jesteś przeżywa teraz, ale mógłby być to wkrótce, jeśli nie nadążyć.

Jest to szczególnie prawdziwe w przypadku poprawek bezpieczeństwa; na przykład, gdyby ktoś po prostu zastosował łatkę, która była już dostępna od miesięcy , niesławny SQL Slammerrobak byłby nieszkodliwy.

Jestem za testowaniem i oceną aktualizacji przed ich wdrożeniem; ale zdecydowanie nie zgadzam się z podejściem do zarządzania systemami „jeśli nie jest zepsute, to go nie dotykaj”, a to naprawdę boli mnie, gdy znajduję produkcyjne systemy Windows 2003 SP1 lub ESX 3.5 Update 2, a jedyną odpowiedzią, jaką mogę uzyskać, jest: „działa, nie chcemy go łamać”.

Co o tym myślisz?
Jakie masz zasady?
A jaka jest polityka Twojej firmy , jeśli nie pasuje do Twojej?

Co z aktualizacjami oprogramowania układowego (BIOS, pamięć itp.)?
Co z głównymi aktualizacjami systemu operacyjnego (dodatków Service Pack)?
Co z drobnymi aktualizacjami systemu operacyjnego?
Co z aktualizacjami aplikacji?

Moim głównym zainteresowaniem jest oczywiście aktualizacja serwerów, ponieważ zarządzanie łatkami klienta jest zwykle prostsze, a istnieją dobrze znane narzędzia i najlepsze praktyki do obsługi tego.

Przy określaniu strategii łatania bezpieczeństwo i zwinność powinny być zrównoważone ze stabilnością i czasem pracy. Twoje podejście do wypychania powinno być zgodne z „Ok, ale musisz wiedzieć, że jesteśmy teraz narażeni na ryzyko naruszenia bezpieczeństwa tych serwerów i kradzieży naszych danych lub spowodowania, że ​​serwery przestaną działać” oraz „W porządku, ale musisz wiedzieć, że ma to wpływ na obsługę tego systemu przez naszych dostawców i przyszłe możliwości interakcji tego systemu z nowymi systemami”.

Wbrew długoterminowej mentalności „nie zepsuć się, nie aktualizuj”, powinieneś wyjaśnić, że:

• Migracja niezakończonego starszego systemu, który jest daleko w tyle, do nowoczesnego systemu jest znacznie droższym i bolesniejszym procesem niż stopniowa aktualizacja tego systemu z czasem.
• Doświadczony i wykwalifikowany personel IT aktywnie poszukuje nowych technologii i firm, które stale rozwijają swoje systemy IT. Obrót, utrata możliwości i utrata wiedzy powodują, że firmy tracą bardzo zaangażowany, kreatywny personel IT ze względu na stagnację systemów i zniechęcenie do pracy. Zatem pozostały ci tylko „lifers”.

Mam nadzieję, że dzięki temu zyskasz przewagę i powodzenia w przekonywaniu wszystkich do poważnego traktowania. Jak zawsze ustal papierową ścieżkę, która dowodzi, że zorientowałeś się w zarządzaniu podejmowanym ryzykiem.

To jest niekończąca się debata i rozsądni ludzie się nie zgodzą. Jeśli mówisz o komputerach użytkowników, zgadzam się, że muszą zostać zaktualizowane. Jeśli mówisz o serwerach, rozważ osobne zasady dla serwerów, które mają dostęp do Internetu i tych, które nie. Nie wiem o twoich serwerach, ale w moim środowisku może 10% naszych serwerów ma porty otwarte na Internet. Te serwery internetowe mają najwyższy priorytet, jeśli chodzi o poprawki bezpieczeństwa. Serwery, które nie mają dostępu do Internetu, mają niższy priorytet.

Guru bezpieczeństwa będą argumentować, że takie podejście jest problematyczne, ponieważ jeśli haker kiedykolwiek dostanie się do twojej sieci, niezałatane serwery pozwolą na przeszukiwanie luk w sieci jak pożar i jest to rozsądny argument. Mimo to, jeśli trzymasz te serwery z dostępem do Internetu zamknięte i odpowiednio skonfigurujesz zaporę ogniową, aby otwierać tylko te porty, które są absolutnie potrzebne, myślę, że to podejście działa i może być często stosowane do uspokajania menedżerów, którzy boją się łatek.

Jeśli polegasz tylko na Windows Update dla poprawek (nie wspomniałeś, z którego systemu operacyjnego korzystasz, ale jestem głównie facetem z Windows, więc to moja referencja), spójrz na faktyczne poprawki, które są wydawane co miesiąc . Mam kilka serwerów, które jeśli uruchomię na nich Windows Update, powiedzą mi, że potrzebuję ponad 50 łatek, ale jeśli przewinię te łatki i sprawdzę każdy z nich, stwierdzę, że 90% elementów będących łatkami nie jest zabezpieczeniem powiązane, ale naprawiające błędy, które wpływają na usługi, których nie uruchamiam na tym urządzeniu. W większych środowiskach, w których korzystasz z systemu zarządzania poprawkami, często przeglądane są wszystkie wydawane treści i przeszkadza tylko to, co jest absolutnie konieczne, a zwykle stanowi to około 10% wydanych przez firmę Microsoft.

Moim argumentem jest to, że ta debata na temat „łatania czy nie łatania” sugeruje, że musisz być po jednej lub drugiej stronie, kiedy tak naprawdę jest to ogromny szary obszar.

Mogę mówić tylko o serwerach, ale mamy system „Kwartalna aktualizacja”, w czterech wcześniej ustalonych i ogłoszonych datach rocznie zbieramy prośby o aktualizację, stosujemy je w naszym środowisku referencyjnym, uruchamiamy je przez miesiąc, aby przetestować stabilność i jeśli dobrze się wprowadzi w ciągu kolejnych n dni / tygodni. Ponadto stosujemy zasady aktualizacji awaryjnych, w których jesteśmy w stanie wdrożyć w celach informacyjnych, przetestować i wdrożyć pilne aktualizacje w ciągu jednego lub dwóch dni, jeśli ich nasilenie jest takie - chociaż zostało to użyte 2/3 razy w ciągu ostatniego 4 lata lub więcej.

To podwójne podejście zapewnia, że ​​nasze serwery są rozsądnie, ale nie głupio, aktualne, że aktualizacje są prowadzone przez ekspertów merytorycznych (tj. Oprogramowanie układowe, sterowniki, system operacyjny, personel aplikacji), a nie dostawców, ale umożliwia także szybkie naprawy, jeśli wymagany. Oczywiście, że mamy szczęście, że mamy bardzo niewiele różnych modeli sprzętu w całej firmie (<10 wariantów serwerów) oraz spore i aktualne platformy referencyjne do testowania.

Pracowałem w różnych firmach, które miały zasady w całym kontinuum od „stosuj łatki JAK NAJSZYBCIEJ, nie obchodzi nas, czy zepsują coś, co pracujemy - wycofamy je wtedy” do „nic nie zostanie zastosowane bez dwóch tygodni testowania ”. Obie skrajności (i punkty pośrednie) są w porządku, o ile Firma rozumie kompromisy .

To ważna kwestia: nie ma właściwej lub złej konkretnej odpowiedzi na to pytanie; jest to kwestia równowagi między stabilnością a bezpieczeństwem lub funkcjami w danym środowisku . Jeśli Twój łańcuch zarządzania rozumie, że opóźnianie poprawek do testowania może uczynić je bardziej podatnymi na złośliwe oprogramowanie, to dobrze. Podobnie, jeśli rozumieją, że stosowanie poprawek, gdy tylko będą dostępne, może nie działać, a nawet zepsuć określoną konfigurację systemu, to również jest w porządku. Istnieją problemy, gdy te kompromisy nie są zrozumiane.

Uważam, że najlepszy kurs jest prawie klapsa w środku dwóch skrajności. np. dlaczego tak desperacko chcesz uaktualnić ESX, jeśli nie ma uzasadnionego powodu, by uszkodzić działające systemy? Jasne, że może być podatny na ataki, jeśli jest dostępny publicznie, ale nie powinno być sposobu, aby można było uzyskać do niego bezpośredni dostęp spoza sieci, więc jakie jest ryzyko? Czy są jakieś błędy lub brak funkcji, które faktycznie przedstawiają powód do aktualizacji?

Aktualizacja przez wzgląd na to, co jest naprawdę to, co proponuje pan ( „ale mogłaby być wkrótce doświadcza”), nawet gdy nie jesteś twierdząc, jest absurdalne i niebezpieczna droga do podróży. O ile nie możesz podać rzeczywistego powodu, w przeciwieństwie do jakiegoś teoretycznie możliwego powodu, nigdy nie przekonasz innych, jeśli sprzeciwiają się one ulepszeniu.

Jeśli uważasz, że istnieje prawdziwy powód, aby przeprowadzić aktualizację, powinieneś udokumentować zarówno zalety, jak i wady, a zawsze są wady i przedstawić je tym, którzy znajdują się wyżej. Właściwie udokumentowane, że opór powinien być niewielki. Jeśli nie możesz przedstawić przekonującego argumentu, usiądź wygodnie i zastanów się nad tym poważnie.

Edytować

Pomyślałem, że powinienem jasno powiedzieć, że widzę ogromną różnicę między stosowaniem wymaganych poprawek bezpieczeństwa i stabilności w porównaniu do przeprowadzania aktualizacji oprogramowania lub systemu operacyjnego. Pierwsze wdrażam po odpowiednich testach. To ostatnie robię tylko wtedy, gdy istnieje realna korzyść.

Aktualizacje zabezpieczeń są wysyłane do serwera pomostowego, a następnie produkcyjne po tym, jak wykażą, że nie wysadzają w powietrze. Chyba, że ​​jest naprawdę nieprzyjemny alarm (który trafiłem kilka razy :(), w takim przypadku PRODUKCJA TERAZ. Inne aktualizacje tylko w razie potrzeby, po spędzeniu czasu w inscenizacji.

Myślę, że pierwszą rzeczą do zrobienia jest „sklasyfikowanie” aktualizacji według ważności i opracowanie harmonogramu łatek na podstawie klasyfikacji. Bez wątpienia poprawki bezpieczeństwa zerowego muszą być zastosowane od razu; podczas gdy dodatek Service Pack może poczekać po dokładnych ocenach.