Niezawodność, bezpieczeństwo i utrzymanie

Co jest kopiowane, gdzie leży kopia i ile trwa powrót do pracy.

• Co i gdzie jest kopiowane - spis system po systemie: serwery i maszyny wirtualne, bazy danych, dyski sieciowe, poczta i pliki w Microsoft 365, konfiguracje urządzeń sieciowych i firewalli - a kopia leży tam, gdzie oryginał nie pociągnie jej za sobą.
• Microsoft 365 nie robi kopii zapasowych za Ciebie - retencja i kosz chronią przed skasowanym mailem, ale nie pomogą, gdy ktoś przejmie konto, gdy synchronizacja wciągnie do chmury pliki zaszyfrowane przez ransomware albo gdy odbierzesz licencję osobie, która odeszła. Tam, gdzie dane są tego warte, dokładamy kopię całego tenanta.
• Cele odtworzenia w prostych słowach (RTO i RPO) - dla każdego systemu ustalamy, jak długo może nie działać i ile danych wolno stracić, a z tych dwóch liczb wynika harmonogram kopii i to, co trzeba zdublować.
• Narzędzia - Azure Backup do zasobów w Azure, Proxmox Backup Server do klastrów Proxmox, Veeam do VMware i środowisk mieszanych, a do Microsoft 365 kopia całego tenanta; wybór zależy od tego, co masz.
• Testy odtwarzania - zaplanowane i zapisane: cały serwer albo skrzynkę przywracamy w osobnym środowisku, mierzymy czas i stratę danych, porównujemy oba wyniki z ustalonymi celami i poprawiamy procedurę tam, gdzie któregoś z nich nie osiągnęła.
• Procedury odtwarzania po awarii - kolejność przywracania, kto co robi, gdzie są hasła i jak dotrzeć do producentów - trzymane tam, gdzie przetrwają awarię, którą opisują.

Kopia na tym samym sprzęcie, na tych samych hasłach albo w tej samej lokalizacji co oryginał nie jest zabezpieczeniem, tylko drugim egzemplarzem. Ransomware zaszyfruje jedno i drugie tej samej nocy.

Nic, co prowadzimy na SLA, nie pracuje bez monitoringu.

• Nasz monitoring w cenie - każdy system, który prowadzimy na SLA, jest objęty naszym nadzorem od pierwszego dnia pracy: dostępność, błędy, zużycie zasobów, wyniki zadań i wygasanie certyfikatów, a alerty trafiają do inżyniera na dyżurze.
• Twój monitoring, jeśli go masz - ten nadzór opieramy na narzędziach, które już masz i za które płacisz, a własne dodajemy tylko tam, gdzie ich brakuje: system objęty SLA musimy widzieć i reagować na podstawie alertów i danych, nie domysłów. Korzystamy z Azure Monitor w Azure, CloudWatch w AWS, Grafana albo Zabbix do pomiarów, Graylog albo Elastic do logów, Splunk czy Datadog, jeśli już masz je opłacone. Logi i zdarzenia z przełączników, routerów, firewalli i z hiperwizorów, na których działają maszyny wirtualne, zbieramy do tego samego miejsca co resztę.
• Czego pilnujemy - dostępność z zewnątrz, kończące się zasoby i wygasające certyfikaty od środka, wyniki zadań kopii zapasowych, nieudane logowania i zmiany uprawnień, a do tego rzeczy ważne dla Twojej firmy: nocne zadanie się skończyło, zamówienia przechodzą. Pilnujemy też, czy wynik ma sens: zadanie, które zgłasza sukces, a zwraca pustkę albo liczbę nie do uwierzenia, to awaria, której sam nie zauważysz.
• Alerty, które coś znaczą - progi ustawione osobno dla każdego systemu, tak żeby alert był wezwaniem do działania; co odzywa się bez potrzeby, dostrajamy albo kasujemy.
• Kto reaguje i jak szybko - czasy reakcji i naprawy według poziomu krytyczności, wpisane do SLA.
• Jak długo trzymamy logi - dość długo, żeby zbadać incydent zauważony po tygodniach, i dość krótko, żeby zmieścić się w zasadach retencji danych osobowych; obie granice ustalamy z góry.

Kanał alertów, którego nikt nie czyta, jest gorszy niż brak monitoringu, bo wszyscy wierzą, że ktoś patrzy.

Wszystko, co masz, ma swoją datę końca wsparcia - przełącznik, hiperwizor, baza danych, wersja Windowsa, framework pod Twoją aplikacją, certyfikat na domenie i sama domena. Prowadzimy tę listę i działamy, zanim któraś z tych dat nadejdzie.

• Rytm aktualizacji - systemy operacyjne, hiperwizory, firmware, urządzenia sieciowe i aplikacje Microsoft 365 według harmonogramu, z uzgodnionymi oknami aktualizacji i z opisaną z góry procedurą na wypadek krytycznej luki.
• Pilnowanie końca wsparcia - sprzęt, oprogramowanie, licencje i umowy serwisowe w jednym spisie, a decyzję o przedłużeniu albo wymianie podejmujemy z Tobą na miesiące przed terminem, żeby dało się ją zaplanować w budżecie.
• Domeny i certyfikaty - spisane, odnawiane automatycznie tam, gdzie system na to pozwala, i pilnowane ręcznie tam, gdzie nie pozwala. Wygasły certyfikat kładzie system, któremu poza tym nic nie dolega.
• Przećwiczone podniesienia wersji - duże zmiany wersji hiperwizorów, baz danych i frameworków najpierw w osobnym środowisku, z przetestowaną drogą powrotu i ze spisem funkcji, które producent usuwa, zanim cokolwiek dotknie systemu, na którym firma pracuje. O zależnościach w aplikacjach, które budujemy, piszemy w Inżynierii aplikacji i systemów.
• Zależności, których nie kontrolujesz - cudze API, źródła danych, integracje z systemami kontrahentów, urządzenia na hali: wchodzą do tego samego spisu co reszta, a gdy któraś przestanie działać, znajduje to nasz monitoring, a nie Twój telefon. Po stronie dostawców zwykle nikt nie ogłasza z wyprzedzeniem ani daty końca wsparcia, ani nadchodzących zmian.
• Zarządzanie lukami bezpieczeństwa - śledzimy komunikaty producentów z Twojego spisu, oceniamy zagrożenie po Twojej rzeczywistej konfiguracji, a nie po tym, jak groźnie brzmi nagłówek, i planujemy poprawki według realnego ryzyka.

„Działa, to nie ruszaj” sprawdza się dokładnie do dnia, w którym całą resztę kładzie ten jeden element, którego nikt nie aktualizował.

W firmach, które pracują w Microsoft 365, w tenancie jest wszystko: konta, poczta, pliki, spotkania i urządzenia. Większości tych środowisk nikt nie ruszał od dnia uruchomienia. Praktyka wokół kont, urządzeń i uprawnień jest ta sama niezależnie od dostawcy; tę sekcję opieramy na Microsofcie, bo tu możemy wskazać konkretne narzędzia.

• Projekt i uporządkowanie tenanta - role i grupy odwzorowujące to, jak firma naprawdę pracuje; odziedziczony tenant przeglądamy konto po koncie i grupa po grupie, a co usunąć, co zarchiwizować, a co zostawić, decydujemy razem z Tobą.
• Poczta - Exchange Online konfigurowany PowerShellem, a nie klikaniem: skrzynki współdzielone, reguły przepływu poczty, retencja i uwierzytelnianie nadawcy (SPF, DKIM, DMARC), żeby Twoja poczta docierała, a Twojej domeny nie dało się użyć do podszywania się pod Ciebie.
• Teams i SharePoint - zespoły i witryny zgodne ze strukturą grup; domyślne reguły udostępniania ustalone, a nie zostawione szeroko otwarte; migracje z Google Workspace albo z serwera plików wliczone we wdrożenie.
• Urządzenia - laptopy i telefony zarejestrowane w Intune: wymuszone szyfrowanie, kontrolowane aktualizacje, zgubione urządzenie czyszczone zdalnie, a nowy laptop konfiguruje się sam, gdy pracownik pierwszy raz go włączy.
• Ochrona danych - etykiety poufności i ochrona przed wyciekiem (Purview) dla treści, które nie mogą opuścić firmy; retencja ustalona świadomie dla każdego rodzaju danych.
• Zasady logowania - uwierzytelnianie wieloskładnikowe dla wszystkich, Conditional Access blokujący logowania z miejsc, w których Twoich ludzi nigdy nie ma, osobne konta administracyjne i Defender for Business tam, gdzie licencja go obejmuje.
• Licencje dobrane do potrzeb - Business Premium wystarcza większości firm poniżej 300 stanowisk; E3 albo E5 wtedy, gdy wymaga tego funkcja, z której naprawdę skorzystasz - i nazwiemy tę funkcję.

W tenancie, w którym każdy jest administratorem globalnym, jedno wyłudzone hasło daje władzę nad wszystkim.

Podział sieci na strefy i zabezpieczanie urządzeń sieciowych opisujemy w Sieciach i łączności w przedsiębiorstwie, zabezpieczanie samych serwerów i to, co dostępne z internetu, w Chmurze i inżynierii platform, a kontrolę dostępu i zapis, kto co zrobił w aplikacji, w Inżynierii aplikacji i systemów. Ta sekcja dotyczy standardu wspólnego dla nich wszystkich i nawyku trzymania się go.

• Jeden standard konfiguracji - spisany standard dla każdego rodzaju systemu: tenanta, serwera, komputera, urządzenia sieciowego. Nakładamy go przy budowie i sprawdzamy według harmonogramu - odchylenia od niego znajdujemy my, zanim znajdzie je ktoś inny.
• Ochrona komputerów i serwerów - Defender for Business albo produkt, na który już masz licencję, wdrożony i raportujący, z alertami wpiętymi w ten sam dyżur co wszystko inne.
• Dostęp administracyjny - panele zarządzania dostępne tylko z wydzielonej sieci albo przez VPN, a tam, gdzie nie masz własnego sprzętu, panele dostawcy chmury na osobnym koncie z uwierzytelnianiem wieloskładnikowym; konta fabryczne i lokalne wyłączone.
• Gotowość na incydent - do kogo dzwonić, co odciąć najpierw, jak zabezpieczyć ślady i od kiedy biegną 72 godziny, które RODO daje na zgłoszenie naruszenia - spisane, zanim będzie potrzebne.

Standardy rozjeżdżają się w chwili, w której ktoś potrzebuje wyjątku „tylko na dziś”. Wyjątek musi mieć datę ważności.

Wszystko, co budujemy, ma dokumentację. Ta sekcja opisuje to, co dzieje się później: co robimy, gdy to my prowadzimy system, i co dostajesz, gdy prowadzi go kto inny.

• Przejęcie środowiska - po poprzednim dostawcy albo po administratorze, który odszedł: dostępy odzyskane i wydane na nowo, hasła zmienione, spis odtworzony, a dostęp poprzedniego dostawcy odebrany z pisemnym potwierdzeniem.
• Dokumentacja powykonawcza - schemat sieci, spis, konfiguracje, miejsce, w którym leżą hasła, i instrukcja do każdego rutynowego zadania, utrzymywane na bieżąco przy każdej zmianie, a nie nadrabiane na końcu jako osobne zadanie.
• Zapis zmian - co się zmieniło, kto to zrobił, kiedy i po co, razem z drogą powrotu - żeby incydent sprzed trzech miesięcy dało się powiązać ze zmianą, która go wywołała.
• Obsługa incydentów - poziomy krytyczności określone w umowie, czasy reakcji i naprawy dla każdego z nich, informacje w ustalonym rytmie aż do zamknięcia sprawy i pisemna notatka po incydencie z przyczyną i naprawą - również wtedy, gdy przyczyną byliśmy my.
• Wdrożenie użytkowników i szkolenia - nowe narzędzia wprowadzane ze spotkaniami dla tych, którzy będą z nich korzystać, i z krótkimi instrukcjami na piśmie. System, z którego ludzie nie umieją korzystać, jest obchodzony, a obejście to miejsce, w którym wyciekają dane.
• Przekazanie - gdy przejmujesz system albo przenosisz go do innego dostawcy, dostajesz komplet dokumentacji, repozytoria z kodem, prawa administratora przeniesione na Ciebie i nasze dostępy usunięte w dniu, który wyznaczysz, z pisemnym potwierdzeniem.

Umowa serwisowa, która nie określa poziomów krytyczności i czasów reakcji, jest obietnicą odebrania telefonu i niczym więcej.

Jesteśmy inżynierami, nie prawnikami: wdrażamy i dokumentujemy środki techniczne i organizacyjne, których wymagają Twoje obowiązki, a resztą zajmujemy się razem z Twoim prawnikiem albo inspektorem ochrony danych.

• RODO - spis systemów, w których znajdują się dane osobowe, i tego, po co tam są; dostęp ograniczony do osób, które go potrzebują; szyfrowanie danych przesyłanych i przechowywanych; retencja, która kasuje w terminie; logi pokazujące, kto do czego sięgał; i opisana wyżej procedura incydentu. O ochronie danych osobowych wbudowanej w sam model danych piszemy w Platformach danych i automatyzacji.
• NIS2 - unijne wymagania cyberbezpieczeństwa, które obejmują kolejne branże; tam, gdzie Cię dotyczą: analiza ryzyka, gotowość do zgłaszania incydentów, rejestr dostawców i plan ciągłości działania przygotowane od strony technicznej, żeby obowiązki wypełniały systemy i procedury, które naprawdę istnieją.
• Ankiety od ubezpieczycieli i klientów - ankietę bezpieczeństwa przy polisie cyber albo od dużego klienta wypełniamy na podstawie dokumentacji, która istnieje, a braki, które przy tym wyjdą, zamieniamy w plan z datami.
• Czego nie robimy - testów penetracyjnych, audytów ISO 27001 i SOC 2 ani certyfikacji. Przygotowujemy środowisko i dokumentację tak, żeby audytor albo tester, którego wynajmiesz, zastał porządek, a to, co znajdzie, naprawiamy.

Polityka bezpieczeństwa, której Twoje systemy nie egzekwują, w audycie działa przeciwko Tobie.