Patrząc dziś na projekt modernizacji infrastruktury sieciowej w OTTO, dochodzę do wniosku, że jedna z najważniejszych decyzji została podjęta jeszcze zanim zaczęliśmy rozmawiać o konkretnych produktach, rozwiązaniach czy dostawcach. Postanowiliśmy dać sobie czas.

Projekt rozpoczęliśmy blisko dwa lata temu, ponieważ chcieliśmy dokładnie zrozumieć zarówno własne potrzeby, jak i możliwości rynku. Zależało nam na tym, aby nie wybierać rozwiązania na podstawie materiałów marketingowych czy pojedynczych prezentacji handlowych, ale oprzeć decyzję na realnej wiedzy, doświadczeniach innych organizacji oraz praktycznych testach.

Pierwszym etapem były webinary, konferencje, warsztaty techniczne oraz liczne rozmowy z producentami i integratorami. Chcieliśmy poznać najnowsze trendy w obszarze infrastruktury sieciowej i bezpieczeństwa, a także zrozumieć, w jakim kierunku rozwija się rynek. Za każdym razem, gdy jakieś rozwiązanie wydawało się interesujące, rozpoczynaliśmy rozmowy z partnerem wdrożeniowym. Bardzo szybko okazało się, że sam produkt jest tylko jednym z elementów całej układanki.

Równie ważne było zrozumienie, czy partner dysponuje odpowiednimi kompetencjami, odpowiednio dużym zespołem i możliwością świadczenia usług w modelu 24/7. Dla naszej organizacji jest to aspekt kluczowy. Biznes funkcjonuje przez całą dobę, natomiast nasz dział ICT, podobnie jak w wielu innych firmach, nie jest na tyle liczny, aby samodzielnie zapewniać pełne wsparcie przez siedem dni w tygodniu i dwadzieścia cztery godziny na dobę. Od początku wiedzieliśmy więc, że potrzebujemy nie tylko technologii, ale również partnera, który będzie w stanie wspierać nas wtedy, gdy będzie to naprawdę potrzebne.

W trakcie analiz rozmawialiśmy z wieloma producentami i poznawaliśmy bardzo różne podejścia do budowy nowoczesnej infrastruktury. Pod uwagę braliśmy rozwiązania takich vendorów jak Palo Alto Networks, Cisco, Cisco Meraki, Check Point, Juniper czy Fortinet. Analizowaliśmy również ofertę HPE Aruba, Extreme Networks oraz Alcatel-Lucent Enterprise, a także rozwiązania stricte SASE, takie jak Cato Networks czy Zscaler.

Zdobyte informacje weryfikowaliśmy na wiele sposobów. Korzystaliśmy z raportów Gartnera, analiz rynkowych i materiałów dostępnych w internecie. Największą wartość miały jednak rozmowy z klientami korzystającymi z tych rozwiązań. To właśnie podczas konferencji i wydarzeń branżowych można usłyszeć historie z prawdziwych wdrożeń, poznać mocne strony poszczególnych technologii, ale również dowiedzieć się o wyzwaniach, które nie zawsze pojawiają się w prezentacjach sprzedażowych. Dla mnie osobiście był to najcenniejszy element całego procesu, ponieważ pozwalał spojrzeć na rozwiązania przez pryzmat codziennej eksploatacji, a nie tylko teoretycznych możliwości.

Już na tym etapie zaczęła krystalizować się nasza wizja docelowej architektury bezpieczeństwa. Od początku zakładaliśmy podejście Zero Trust. Przyjęliśmy założenie, że nie należy ufać nikomu wyłącznie dlatego, że znajduje się wewnątrz naszej sieci lub pracuje z jednej z naszych lokalizacji. Początkowo uznaliśmy nawet, że w takim modelu wdrożenie technologii NAC może nie być konieczne. Skoro każdy użytkownik i każde urządzenie mają być weryfikowane niezależnie od miejsca połączenia, wydawało się, że dodatkowa kontrola dostępu do sieci nie przyniesie istotnych korzyści, generując jednocześnie dodatkowe koszty licencyjne i operacyjne.

W miarę pogłębiania analiz zmieniliśmy jednak zdanie. Ostatecznie podjęliśmy decyzję o powrocie do koncepcji NAC jako kolejnej warstwy ochrony. Nadal pozostaliśmy wierni filozofii Zero Trust i użytkownik pracujący z biura nie uzyskuje większych uprawnień niż osoba pracująca zdalnie z domu. Uzyskaliśmy jednak dodatkowy mechanizm umożliwiający wcześniejsze wykrywanie zagrożeń oraz ograniczenie ryzyka jeszcze przed dopuszczeniem urządzenia do komunikacji w sieci.

W ramach przygotowań aktywnie uczestniczyliśmy również w warsztatach typu hands-on. Były to między innymi szkolenia Fortinet Fast Track, warsztaty organizowane przez Cisco oraz spotkania prowadzone przez innych producentów. Takie doświadczenia pozwalają dużo lepiej zrozumieć technologię niż nawet najbardziej szczegółowa prezentacja. Dopiero samodzielna praca z rozwiązaniem pokazuje jego rzeczywiste możliwości, ograniczenia i sposób działania.

Po zakończeniu etapu analiz przyszedł czas na to, co osobiście uważam za najważniejszy element całego procesu, czyli Proof of Concept. Chcąc zapewnić wszystkim uczestnikom identyczne warunki, przygotowałem szczegółowy dokument RFI, który z czasem przekształcił się w pełnoprawne RFP. Dokument liczył 41 stron i zawierał dokładny opis naszego środowiska, lokalizacji, adresacji sieciowej, parametrów wykorzystania łączy internetowych, przepustowości, wymagań biznesowych oraz docelowej architektury, którą chcieliśmy osiągnąć.

Dokument był na bieżąco aktualizowany wraz z pojawianiem się nowych pytań od dostawców. Dzięki temu każda firma otrzymywała ten sam zestaw informacji i mogła przygotować rozwiązanie w oparciu o identyczne założenia. Następnie zaprosiliśmy do współpracy czterech partnerów, którzy przedstawili cztery różne koncepcje realizacji projektu.

Od samego początku wszyscy wiedzieli, że uczestniczą w równoległym procesie, a konkurencyjni partnerzy realizują dokładnie takie same zadania. Każdy otrzymał identyczny zakres wymagań oraz ten sam czas na przygotowanie i przeprowadzenie testów.

Rezultaty okazały się niezwykle wartościowe. Jeden z dostawców nie był w stanie zakończyć POC w wyznaczonym terminie. Nawet po jego wydłużeniu nie udało się zrealizować wszystkich założeń, mimo że teoretycznie rozwiązanie powinno było spełniać postawione wymagania. W innym przypadku partner już w trakcie testów zaproponował zmianę pierwotnie rekomendowanej technologii. Nie odebraliśmy tego jako problemu. Wręcz przeciwnie. Był to dowód uczciwego podejścia oraz gotowości do szukania najlepszego rozwiązania dla klienta zamiast forsowania wcześniejszych założeń za wszelką cenę.

To właśnie w tym momencie utwierdziłem się w przekonaniu, jak ogromne znaczenie ma dobrze przeprowadzony POC. Znacznie lepiej odkryć ograniczenia lub problemy podczas kontrolowanych testów niż dopiero po podpisaniu umowy, zakupie sprzętu i rozpoczęciu wdrożenia produkcyjnego.

Największym zaskoczeniem całego projektu było jednak coś zupełnie innego. Na końcu tej dwuletniej drogi najważniejsza nie okazała się technologia. Najważniejsi okazali się ludzie. Podczas tego procesu poznałem wielu świetnych specjalistów, ekspertów i architektów, którzy dzielili się wiedzą jeszcze wtedy, gdy nie mieli żadnej gwarancji późniejszej współpracy. Dzięki temu mogłem zobaczyć, jak działają w praktyce, jak rozwiązują problemy, jak komunikują się z klientem i jak reagują na wyzwania pojawiające się w trakcie projektu.

Ostatecznie do finałowego etapu dotarły dwa rozwiązania i dwóch bardzo mocnych partnerów. Z każdym z nich byłbym gotowy budować współpracę przez kolejne lata. Niestety wybrać można było tylko jednego. Choć jestem przekonany, że podjęliśmy właściwą decyzję, to nadal odczuwam pewien niedosyt związany z ilością czasu, pracy i zaangażowania, jakie włożyły pozostałe firmy oraz producenci. Nie znalazłem jednak lepszego sposobu na realizację tak strategicznego projektu. Jeśli infrastruktura ma wspierać biznes przez kolejne lata, to dokładna i uczciwa weryfikacja przed zakupem nie jest stratą czasu. Jest inwestycją.

Najważniejsza lekcja, jaką wyniosłem z tego projektu, jest prosta. Technologię można kupić. Partnerstwo trzeba zbudować. A to właśnie ludzie, ich wiedza, zaangażowanie i gotowość do wspólnego rozwiązywania problemów mają największą wartość wtedy, gdy zaczynają pojawiać się prawdziwe wyzwania.