POC – Private “Update for Business” – Automatyczny Maintenance

POC – Private “Update for Business” – Automatyczny Maintenance

Spis treści projektu:

1. POC – Private “Update for Business” – Intro

2. POC – Private “Update for Business” – Komputery i Grupy

3. POC – Private “Update for Business” – Inwentaryzacja klientów

4. POC – Private “Update for Business” – Inwentaryzacja poprawek

5. POC – Private “Update for Business” – Automatyczna akceptacja poprawek

6. POC – Private “Update for Business” – Automatyczny Maintenance


Z naszym projektem Private “Update for Business” zbliżamy się wielkimi krokami do końca. Pozostały nam właściwie jedynie do obsłużenia zadania Maintenance’owe – żeby nasze rozwiązanie działało długi czas stabilnie, wydajnie i bez problemów 🙂

OK Zaczynamy.

Nasze zadania Maintenance’owe może podzielić na kilka głównych zadań:

1. Maintenance (Re-Indexacja) bazy danych WSUS’a

2. Odrzucanie starych, przeterminowanych i zastąpionych nowszymi wersjami poprawek

3. Czyszczenie WSUS’a z niepotrzebnych danych

 

AD.1.

Tutaj najlepiej skorzystać z „gotowca” bo nie ma co odkrywać Ameryki na nowo 🙂 Są świetnie działające skrypty – więc z nich korzystajmy: WSUS Maintenance

Żeby mieć logowanie tego, co wykonał skrypt do pliku wystarczy ww. skrypt SQL’a zapisać do pliku np: ‚C:\scripts\DB_Maintenance\WSUSSBMaintenance.sql’ oraz w Powershellu dopisać parę linijek:

a teraz Skrypt Powershell’owy przypisać do harmonogramu zadań, żeby wykonywał się cyklicznie.

 

Ad.2.

A)

Jak zwykle w tym Projekcie zaczynamy od SQL’a 🙂 Odpytujemy bazę danych o zwrócenie nam poprawek, które mają status przestarzałych:

a potem przechodzimy do Powershell’a:

Dla każdej poprawki sprawdzamy, czy jest już odrzucona, a jeśli nie to ją odrzucamy.

Przypisujemy zadanie do harmonogramu zadań żeby wykonywało się cyklicznie np raz w tygodniu.

 

B)

Podobnie postępujemy dla poprawek, które zostały już zastąpione nowszymi wersjami. Najpierw wyłuskujemy je z bazy WSUS’a:

A następnie z pomocą Powershell’a odrzucamy:

Oraz ponownie przypisujemy nasz skrypt do harmonogramu zadań 😉

 

Ad.3 .

Skoro odrzuciliśmy już wszystkie niepotrzebne poprawki to pora na pozbycie się niepotrzebnych metadanych WSUS’a i zwolnić trochę miejsca na dyskach 🙂

Tym razem będziemy wykorzystywać samego Powershell’a bez pomocy SQL’a i to w One-line’rze  to Tygryski lubią najbardziej 😉

 

Żeby całość miała logiczny sens proponuje wykonywać w kolejności Pkt. 2 -> Pkt. 3 -> Pkt.1 i można cieszyć się w pełni zautomatyzowanym systemem dystrybucji poprawek na zasadach zbieżnych do Updates for Business. Tym samym nasz zakładany cel został osiągnięty.

2 thoughts on “POC – Private “Update for Business” – Automatyczny Maintenance

    1. Szybko instalować to można na prywatnym PC – nie w środowiskach produkcyjnych, gdzie systemy są po to żeby zarabiać pieniądze – tam każda minuta przestoju to wymierna strata dla organizacji…
      Oczywiście w przypadku realnych zagrożeń czas testów poprawek ulega diametralnemu skróceniu – ale chyba nikt poważny nie zdecyduje się instalować poprawek na krytycznych środowiskach produkcyjnych bez wcześniejszego testowania tylko dlatego, że są Security… Tym bardziej, że wiele z tych dziur jest czysto teoretycznych i nigdy (albo nigdy dotychczas) nie zostało wykorzystanych, a poprawki powodują awarię innych komponentów systemu czy aplikacji.

      Złota zasada – co nagle to po diable i najpierw testować – później wykonywać.

      Jest też inny aspekt dziur bezpieczeństwa i poprawek – przy ocenie każdej trzeba brać pod uwagę jaka jest szansa że wystąpi w Twojej organizacji biorąc pod uwagę inne warstwy zabezpieczeń, to jakie dodatkowe warunku muszą być spełnione żeby atak się udał, czy ktoś już wykorzystał podobny atak itp. itd.
      Sumarycznie zawsze sprowadza się do Kalkulacji:
      1. Ile mogę stracić pieniędzy jeśli luka zostanie u mnie wykorzystana.
      2. Ile stracę pieniędzy w przypadku nieprawidłowego działania systemu biorąc pod uwagę że czas przywrócenia do stanu sprzed poprawki wyniesie X czasu
      3. Ile w tym czasie moje systemy zarabiają pieniędzy.
      W zależności, czy 3 > (1+2) lub na odwrót 3 < (1+2) czas testów przed produkcyjnym wdrożeniem ulega co najwyżej proporcjonalnym zmianom.

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *