Konto serwisowe w enova365 — co naprawdę znaczy „tylko do odczytu”

Najszybciej, jak dostałem działające dane dostępowe do produkcyjnej enova365, było to samo popołudnie. Najwolniej — pięć tygodni. Ta sama klasa pracy, ten sam zakres tylko do odczytu, porównywalne firmy. Różnicy nie zrobiła polityka bezpieczeństwa, tylko wolne miejsce w licencji.

Ta rozpiętość to praktyczna wersja pytania, wokół którego ta seria krąży od dawna. Pisząc o czasie wdrożenia nazwałem to opóźnieniem dostępu: dni od umówiliśmy się do konektor ma działające dane tylko do odczytu na produkcji, i lepszy predyktor daty startu niż typ ERP, zakres i wielkość portfela razem wzięte. Ten tekst jest o tym, co siedzi pod tą liczbą w jednym konkretnym systemie.

„Tylko do odczytu” znaczy trzy różne rzeczy, a używa się ich zamiennie

Zacznijmy stąd, bo prawie każdy spór o bezpieczeństwo integracji, jaki widziałem, okazywał się tym nieporozumieniem w garniturze.

Pierwsze znaczenie to prawa do obiektów: co operator może zrobić z danym rodzajem danych. Odczytać dokument sprzedaży, zmienić go, usunąć. To ta warstwa, którą wszyscy mają w głowie, mówiąc „uprawnienia”.

Drugie to ograniczenia na poziomie rekordów: które rekordy operator w ogóle widzi. Można mieć prawo odczytu faktur w ogólności i jednocześnie być zawężonym do jednej jednostki organizacyjnej. Prawa odpowiadają na pytanie co, ograniczenia na pytanie które — a integracja potrafi przejść pierwszy test i po cichu ominąć sens drugiego.

Trzeciego nie ma w modelu uprawnień w ogóle. To warstwa transportu. Integracja czytająca przez WebAPI loguje się jako operator, więc dziedziczy obie warstwy powyżej. Integracja czytająca z repliki SQL nie dziedziczy żadnej, bo połączenie do bazy nie ma pojęcia, że model uprawnień ERP istnieje. Obie na spotkaniu nazwiecie odczytem. Jedna szanuje każde skonfigurowane ograniczenie, druga widzi tabelę z płacami.

Powiem to wprost, bo ten fragment zwykle się przeskakuje. Odczyt to nie to samo co brak ryzyka. Operator z szerokim prawem odczytu w kilku modułach widzi wynagrodzenia, a połączenie do repliki z szerokimi prawami widzi je na pewno. Jeśli Wasza opowieść o ochronie danych brzmi „przecież to tylko czyta”, to nie macie opowieści o ochronie danych.

Licencja jest lepszą granicą niż drzewko uprawnień

To jest ta część, która za pierwszym razem mnie zaskoczyła, a dziś wokół niej projektuję.

Drzewko uprawnień to konfiguracja. Każdy administrator i każdy konsultant partnera z dostępem może je poszerzyć we wtorek po południu, a zmiana sama się nie zgłosi — dokładnie ten sam mechanizm co dryf pól własnych z tekstu o polach własnych. To, co dziś zawęzicie, za pół roku może po cichu wyglądać inaczej.

Z licencją tak nie jest. To, jakie moduły obejmuje licencja operatora, jest faktem handlowym, egzekwowanym poza ekranami konfiguracji, a poszerzenie wymaga, żeby ktoś coś kupił. To czyni ją jedyną granicą w instalacji, której nie da się po cichu poluzować od środka.

Stąd ruch nieoczywisty: kupcie integracji najmniejszy zakres modułów, który wykona pracę, a nie najwygodniejszy. Jeśli agent pracuje w Handlu, licencja niesięgająca modułu kadrowo-płacowego jest mocniejszą gwarancją niż jakikolwiek ptaszek do odhaczenia — i przeżyje rotację ludzi, aktualizacje oraz uczynne przekonfigurowanie.

Jedno zastrzeżenie, istotne: warunki licencyjne w enova365 różnią się w zależności od umowy, typu licencji i wersji, łącznie z tym, czy sesja WebAPI zajmuje miejsce tak jak zwykłe logowanie. W każdej instalacji, z jaką pracowałem, zachowywała się jak logowanie i potrzebowała własnego zapasu — ale sprawdźcie własny plik licencji z partnerem, zamiast ufać ogólnej regule. To zresztą pierwszy punkt listy poniżej.

Skąd naprawdę bierze się opóźnienie dostępu

Decydują cztery pytania i wszystkie cztery można zadać pierwszego dnia, zanim ktokolwiek narysuje architekturę.

Czyja jest licencja i czy jest w niej wolne miejsce na moduły, których integracja potrzebuje? Jeśli nie ma, wniosek o dostęp właśnie zamienił się w zakup — z ofertą i akceptacją — a Wasze jednodniowe zadanie stoi teraz w czyimś kalendarzu zakupowym. To jedno pytanie tłumaczy większość różnicy między popołudniem a pięcioma tygodniami.

Kto może założyć operatora? W sporej części instalacji odpowiedzią jest partner, a nie klient, niezależnie od tego, co klient sądzi. Do kroku, który wszyscy uważali za wewnętrzny, wchodzi trzecia firma.

Czy jest baza testowa i czy to świeża kopia produkcji? Nieaktualna kopia jest gorsza niż żadna, bo daje pewne wyniki na temat schematu, który zdążył się zmienić. Jeśli ma więcej niż kilka miesięcy, zaplanujcie, że część rzeczy odkryjecie późno.

Czy instalacja jest w ogóle osiągalna stamtąd, gdzie ma działać integracja? Maszyny on-premise widoczne tylko przez VPN są normą i nie ma w tym nic złego, ale robota z routingiem jest realna i należy do planu, a nie do rubryki „niespodzianki”.

Zadanie tych czterech pytań nie skróci opóźnienia przy pierwszym projekcie. Pozwoli za to poznać jego rozmiar, zanim obiecacie datę — i o to chodzi. A jeśli jesteście po stronie kupującego: dostawca, który zadaje te cztery pytania na pierwszej rozmowie, mówi Wam, że robił to już wcześniej.

Minimalne uprawnienia z obserwacji, nie ze specyfikacji

Nikt nie potrafi z góry rozpisać, czego integracja potrzebuje. Ani Wy, ani partner, ani osoba, która robiła poprzednią. Wymyślona lista będzie w większości miejsc za szeroka i zabraknie w niej dokładnie tej jednej rzeczy, która zatrzyma zadanie o dwudziestej trzeciej.

Więc przestańcie specyfikować i zacznijcie obserwować. Załóżcie operatora prawie bez uprawnień. Wskażcie mu bazę testową. Uruchomcie integrację. Zbierzcie każdą odmowę. Nadajcie dokładnie te prawa i uruchomcie ponownie.

Dwie rundy zwykle wystarczają, a całość mieści się w jednym dniu. Na koniec macie dwa artefakty: zestaw uprawnień minimalny dlatego, że został wyprowadzony, a nie zgadnięty, oraz spisaną listę tego, czego ta integracja dotyka — czyli dokument, którego przegląd bezpieczeństwa i tak by od Was zażądał.

Zachowajcie listę odmów. Kiedy ta sama integracja będzie w marcu potrzebowała nowej możliwości, różnica względem tej listy jest wnioskiem o zmianę.

Jedno konto na jedną integrację, bo produktem jest ślad audytowy

Tekst o odpowiedzialności stawiał tezę, że wdrożenie nigdy nie przenosi ryzyka — produkuje dowód. W enova365 ten dowód jest konkretny: dokumenty niosą operatora, który je utworzył albo zmienił, i to tam mieszka odpowiedź na pytanie kto to zrobił.

Czyli uruchomienie agenta na współdzielonym koncie nie jest drobnym uchybieniem higienicznym. To skasowanie tego, co mieliście dostarczyć. Jeśli agent loguje się jako Administrator, jego działania są nieodróżnialne od działań wszystkich ludzi, którzy kiedykolwiek używali tego loginu, a żadna ilość logowania po Waszej stronie nie naprawi zapisu po stronie ERP.

Reguły są krótkie. Jedno konto na jedną integrację, nazwane od niej, żeby ktoś czytający historię dokumentu za rok wiedział, co go dotknęło. Nikt nigdy nie loguje się nim ręcznie. A kiedy ten sam system awansuje z czytania do zapisu — granica między poziomem trzecim a czwartym z tamtego tekstu — dajcie mu drugie, osobne konto, zamiast poszerzać pierwsze. Zasięg ewentualnej awarii zostaje ograniczony, a historia odróżnia agenta, który coś zaproponował, od agenta, który coś zapisał.

Co to psuje pół roku później

Dwie rzeczy i widziałem obie.

Pierwsza to rotacja haseł. Ktoś robi przegląd bezpieczeństwa, hasła operatorów zostają zmienione, nikt nie pamięta, że na tej liście jest konto integracyjne, i konektor przestaje się uwierzytelniać — po cichu, bez żadnego alarmu. To ta sama awaria, którą opisywałem wczoraj przy harmonogramie, i lekarstwo jest to samo: integracja sama tego nie zauważy, więc musi to zrobić heartbeat poza enova365. Do tego wpiszcie konta serwisowe do samego kalendarza rotacji, z właścicielem. Problemem nie jest rotacja, tylko rotacja, która pomija jedno konto.

Druga to aktualizacja wersji albo migracja serwera, po której uprawnienia wracają zmienione, a integracja albo psuje się głośno, albo — znacznie gorzej — po cichu zaczyna widzieć mniej niż wcześniej. Zadanie, które nagle nic nie znajduje, wygląda dokładnie jak spokojny tydzień. Dlatego podsumowanie uruchomienia ma raportować, co obejrzało, a nie tylko co znalazło.

Od czego zacząłbym w poniedziałek

Otwórzcie listę operatorów i odpowiedzcie na jedno pytanie: które z nich są ludźmi, a które systemami? W większości instalacji ta druga grupa nie jest oznaczona, a bywa, że nie jest znana. Nazwijcie je, zapiszcie, do czego każde służy, i zaznaczcie te współdzielone z człowiekiem. Godzina roboty, a zwykle znajduje się przy okazji przynajmniej jedno konto, którego nikt nie umie wytłumaczyć.

Potem dla najważniejszej integracji przejdźcie cztery pytania o dostęp i zróbcie przebieg obserwacyjny. Dzień pracy, a znika najczęstsza przyczyna obsuwy w takich projektach — nie budowa, tylko czekanie.

Chcecie drugą opinię? Przyślijcie zakres modułów, którego Waszym zdaniem potrzebuje integracja, a powiem Wam, które z czterech pytań będzie u Was wąskim gardłem. Pół godziny, bez opłat — napiszcie do mnie. Szerzej o tym, jak to wygląda od strony usług: integracja enova365 z AI oraz agenci AI dla firm.