Microsoft przedstawił 20 października rozszerzenie oferty Sovereign Cloud. Wśród opisanych możliwości są zewnętrzne zarządzanie kluczami oraz praca w środowisku odłączonym; ich status dostępności jest różny. Dla zarządu oceniającego zależność od dostawcy to powód, by zażądać osobnych dowodów dla każdej obietnicy.
Wyobraź sobie odbiór budynku, którego właściciel dostaje komplet kluczy, ale instrukcja uruchomienia wentylacji pozostaje u wykonawcy. To analogia do pytania o samodzielność usługi cyfrowej. Klucz daje określone uprawnienie; nie odpowiada jeszcze na pytanie, czy organizacja umie wykonać potrzebną pracę bez pomocy z zewnątrz. Przy ocenie chmury proponujemy zacząć od jednej czynności biznesowej, choćby przyjęcia zamówienia albo odczytania dokumentacji. Dopiero potem sprawdzać, jakie dane, konta, narzędzia i decyzje są potrzebne do jej wykonania. Rozmowa prowadzona w takiej kolejności utrudnia zastąpienie dowodu działania samą nazwą pakietu. Pozwala też odróżnić kontrolę nad wybranym elementem od samodzielności całej usługi.
Jeden komunikat Microsoftu, trzy różne etapy dostępności
Według komunikatu Microsoftu z 20 października zewnętrzne zarządzanie kluczami w Azure Managed HSM jest ogólnie dostępne. Klucz główny może pozostać w sprzęcie klienta lub zaufanej strony trzeciej. Przejście z pracy połączonej do odłączonej w Sovereign Private Cloud wchodzi natomiast do public preview. Sovereign Control Panel ma trafić do public preview podczas Ignite.
Z tego rozróżnienia wyprowadzamy prostą zasadę zakupową: każda pozycja oferty powinna mieć własny warunek odbioru. W tabeli oceny proponujemy cztery pola: potrzebna funkcja, dostępny wariant, potwierdzenie dostawcy i wynik próby. Sam wpis „Sovereign Cloud” byłby zbyt ogólny, by stwierdzić, czego zamawiający faktycznie może użyć w swoim środowisku. Dokument powinien również wskazywać datę, na którą potwierdzono dostępność.
W naszej propozycji funkcja testowa może być przedmiotem pilotażu, jeśli firma świadomie tak zdecyduje. Wymaga jednak osobnego właściciela i kryterium zakończenia próby. Właściciel procesu powinien wiedzieć, czy odbiera gotową usługę, czy sprawdza możliwość przyszłego wdrożenia. Bez tego dwa zespoły mogą inaczej rozumieć dokument, pod którym składają podpisy.
Własny klucz potrzebuje właściciela i instrukcji odzyskania
Azure Managed HSM jest w tym komunikacie konkretnym punktem zaczepienia dla rozmowy o kontroli. Nasza rekomendacja dotyczy sposobu jej odbioru, a nie oceny konkretnej instalacji Microsoftu: poproś o wskazanie osób uprawnionych do wydania, zablokowania oraz odzyskania klucza. Następnie ustal, kto rozstrzyga spór między potrzebą utrzymania usługi a koniecznością odcięcia dostępu.
Proponujemy zapisać te decyzje na jednej stronie. Powinna ona wskazywać zastępstwo na czas nieobecności, miejsce przechowywania instrukcji i osobę zatwierdzającą powrót do normalnej pracy. Proponujemy zaplanować próbę odzyskania w uzgodnionym środowisku testowym. Jej wynikiem ma być dowód wykonania czynności przez wyznaczony zespół, z odnotowanym czasem i trudnościami. Nie sugerujemy eksperymentowania na kluczach obsługujących rzeczywistych klientów.
Własny klucz daje kontrolę operacyjną wtedy, gdy wiadomo, kto podejmuje decyzję o jego użyciu.
Taki odbiór daje zarządowi materiał do oceny kosztu samodzielności. W proponowanym rachunku powinny znaleźć się utrzymanie kompetencji, zastępstwa oraz ćwiczenia. Porównanie ograniczone do ceny infrastruktury ominęłoby pracę, którą organizacja postanowiła wykonywać we własnym zakresie. Nie wyliczamy tu oszczędności ani premii za bezpieczeństwo: wymagałyby danych konkretnego wdrożenia.
Próba odłączenia zaczyna się od definicji działającej usługi
Zapowiedź Sovereign Private Cloud skłania do postawienia pytania odbiorowego: jaki wynik uznamy za działanie bez połączenia? Nasza propozycja brzmi: wybierz jeden proces, opisz jego początek i koniec, a następnie uzgodnij mierzalny warunek powodzenia. Sam start maszyny nie powinien zamykać zadania, jeśli pracownik potrzebuje jeszcze zalogować się i odczytać dane.
Przed próbą sugerujemy sporządzić listę zależności tego procesu. Właściciel testu powinien zapytać o tożsamość użytkownika, dostęp do dokumentacji, pobieranie konfiguracji i narzędzia administratora. To lista kontrolna redakcji, a nie stwierdzenie braków w produktach Microsoftu. Każda odpowiedź powinna odnosić się do badanego środowiska. Niewiadomą lepiej zapisać jako zadanie do sprawdzenia niż zastępować zapewnieniem zaczerpniętym z prezentacji.
W uzgodnionym scenariuszu powinien znaleźć się również powrót do pracy z połączeniem. Proponujemy określić, kto porówna stan danych, zatwierdzi wynik oraz zamknie ewentualne rozbieżności. Kryterium odbioru może obejmować poprawne wykonanie jednej reprezentatywnej operacji po powrocie. Dokładny zakres musi ustalić właściciel procesu wraz z administratorem; nie znamy warunków technicznych środowiska czytelnika.
Test samodzielności usługi powinien kończyć się wynikiem biznesowym, który potrafi ocenić jej właściciel.
Polski zamawiający potrzebuje własnego scenariusza zależności
W polskiej firmie lub instytucji proponujemy rozpatrywać suwerenność jako pytanie zakupowe o konkretną usługę. Co organizacja chce móc zrobić, jeżeli zmienią się warunki współpracy z dostawcą? Właściciel procesu powinien wybrać scenariusz, który rzeczywiście ma znaczenie dla jego działalności, i wskazać dopuszczalny czas ograniczenia pracy. Nie przypisujemy nazwie Sovereign Cloud automatycznej zgodności z polskimi wymaganiami prawnymi.
Przy porównywaniu ofert rekomendujemy przekazać wszystkim wykonawcom ten sam opis operacji do wykonania. Odpowiedź powinna oddzielać to, co wykonawca potwierdza obecnie, od planowanego rozwoju. Zamawiający może wtedy oceniać podobne rezultaty, nawet jeśli dostawcy używają różnych nazw handlowych. Pomocny będzie protokół z dowodami, do którego zespół wróci przy przedłużaniu umowy.
Zarząd powinien też rozstrzygnąć, kto ponosi koszt utrzymania zdolności sprawdzonej podczas odbioru. W naszej ocenie jednorazowa demonstracja jest początkiem takiej decyzji. Proponujemy wyznaczyć termin ponownego przeglądu po zmianie sposobu logowania lub konfiguracji usługi i osobę, która zdecyduje o kolejnej próbie. Bez tego odpowiedzialność łatwo rozmyć między zakupami, administracją i właścicielem procesu.
Co z tym zrobić w poniedziałek
- W 30 minut rozdziel obietnice oferty. Dla jednej rozważanej usługi zapisz funkcje dostępne, testowe i zapowiedziane, wraz z datą potwierdzenia.
- W 30 minut wskaż właściciela kluczy. Ustal osobę decydującą o blokadzie, jej zastępstwo oraz miejsce instrukcji odzyskania; brak odpowiedzi zapisz jako zadanie.
- W 30 minut opisz próbę samodzielności. Wybierz jedną operację biznesową, oczekiwany wynik i osobę odbierającą test w uzgodnionym środowisku.
Kontrolę nad usługą można kupić tylko w takim zakresie, jaki organizacja umie nazwać i odebrać. Deklaracja dostawcy rozpoczyna rozmowę; wynik próby daje podstawę do decyzji o zależności, którą firma świadomie akceptuje.
Źródła
Redakcja cyberinsight.pl.