Z dziennika architekta - IdP, OTP, odpowiedzialność i profile cz. 2

Kontynuując temat OTP oraz odpowiedzialności za procesy wewnątrz systemów IT, chciałem opisać jak ostatecznie podszedłem do tego wstępnej implementacji mechanizmu w systemie, jakie widzę dalej przeszkody, z czego one wynikają i jak planuję to dalej rozwijać w aktualnej formie.

Stan systemu na wersję 4.135.

Pomijając sam fakt, że wersja wygląda jak wygląda - nieforemna, nietypowa - to dodatkowo release’y działają na zasadzie rewizji. W związku z tym, niekażda wersja systemu (jego backendu głównie) właściwie coś zmienia, czasem do kwestia debugowania w trakcie tworzenia kolejnego release’a. Istotne jest po prostu to, że jest. To pomaga mi śledzić co, się mogło zmienić i czy aktualnie to, co jest podgrane powinno zawierać jakąś zmianę z racji tego, że zautomatyzowany deployment z opcją rollbacku powoduje, że mogę wrócić do nie tylko poprzedniej wersji, ale i starszej, jeśli to konieczne.

W związku z tym, aktualna wersja to faktycznie 4.135, ale to realnie po prostu ostatni stabilny build pipeline’a, który realizuje wsparcie dla OTP (w changelogu to jest de facto zakres od 4.106 do 4.135). Wyjściowy stan dla aktualnego “LTSa” (w moim podejściu oznacza to, że taka wersja może sobie siedzieć dłużej na serwerze i jest wersją do której będę rollbackował w razie nieudanej podgrywki nowego feature’a) zawiera wstępną, ale w miarę poprawną implementację 2FA opartą na OTP generowanym z użyciem soli i ziarna czasu (jeszcze bez ziarna startowego użytkownika), kontrolowaną przez flagę w profilu użytkownika, który jest zarządzany przez odrębny system niż samo IdP. Sam OTP dociera do użytkownika z włączonym “wsparciem” OTP poprzez maila (to ten element wstępności implementacji), który jest zarządzany przez IdP. Docelowo całością i konfiguracji OTP, i maila itd będzie zarządzał tylko IdP, ale jak wspominałem w poprzedniej części - musiałem zdecydować się na tymczasowe rozwiązanie, które będzie jednocześnie w miarę bezpieczne, ale także elastyczne.

Flow autoryzacji jest oczywiście prosty i standardowy - wpierw IdP potwierdza, że login i hasło zgadzają się ze stanem faktycznym. Jeśli wszystko się zgadza, a użytkownik w profilu ma skonfigurowane OTP, system generuje, zapisuje w odpowiednim miejscu w Redisie, a front-end przełącza się na odpowiedni widok, prosząc użytkownika o sprawdzenie maila i podanie kodu. Jeśli kod się zgadza, uzyskujemy token autoryzacyjny JWT w cookies, jeśli nie - otrzymujemy odpowiedź odmowną. Mamy 3 próby, a kod jest na razie ważny 10 minut.

Co jeszcze jest do zrobienia?

W przypadku tego konkretnego mechanizmu do zabezpieczenia jest sam dostęp do serwera konsoli cloudu, który na ten moment jest słabym ogniwem systemu. Na pewno, gdyby mój sprzęt (switche L2) wspierały 802.1q to chociaż to bym skonfigurował, aby były odrębne VLANy, ale niestety nie wspierają, więc wszystkie hosty widzą się wzajemnie. Zatem czeka mnie na pewno implementacja niepowiązanego z IdP, prostego mechanizmu weryfikacji hosta (najpewniej forma bazująca na mTLS), a także pełny tunel TLS zamiast plain text komunikacji. Prosty RBAC również nie powiązany z IdP również będzie wymagany. Ten wymóg separacji od IdP jest celowy, gdyż “cloud console server” ma być komponentem dostępnym do LOM (Lights-Out Management) zdalnie. Dodatkowo, już teraz trzeba dodać generowanie kodu OTP używając wpierw soli oraz sekretu unikalnego dla użytkownika. Ten sam secret może być potem wykorzystywany do generowania kodów OTP pod aplikacje Google Authenticator i Microsoft Authenticator. W związku z tym, że cloud console server ma swój protokół tekstowy, nie ma też żadnych klientów dla niego, co oznacza, że po dodaniu TLS, nie da się używać zwykłego telneta, aby “gadać” z nim. Tutaj pojawia się kolejna kwestia dodania prostego klienta CLI oraz dodanie szyfrowania do komunikacji między backend cloudu, a samym serwerem. W ramach samego serwera należy również uwzględnić podział komend, które są komendami protokołu, a więc muszą mieć ograniczony wpływ na konfigurację i działanie serwera oraz na takie, które można wykonać tylko lokalnie, przez socket, a więc typowo administracyjne. A wszystko to, to dosłownie wyłącznie zarys tego, co chcę i uważam za konieczne zanim uznam, że mechanizm jest w miarę sensownie rozwiązany, a i tak ostatecznie pójdzie do pełnego refactoru przy zmianie komunikacji z IdP. Docelowo jest również gdzieś ta zmiana na poziomie samej sieci i wyposażenie się w switch zarządzalny, który wspiera 802.1q…

A inne feature’y?

W moim systemie są planowane również inne feature’y, głównie powiązane z powolnym przebudowywaniem systemu w coś, co mógłbym nazwać DMS - Data Management System. Nigdy co prawda nie planowałem, aby był on tym, ani tym bardziej by był rozbudowany jak Doxis lub odpowiednie moduły SAP, ale wystarczy, że będzie spełniał potrzbey moje i moich najbliższych, z docelowym “otworzeniem” tego na świat w ramach produktu on-premise dla małych i średnich firm. W ramach rozwoju w kierunku DMS potrzebuję ujednolicić API i rozbudować je o dodatkowe opcje, jednocześnie dążąc do tego by uzyskać również moduł skryptowania oraz oparty na nim moduł modelowania procesów. Na ten moment potrzebuję dodać rozwiązanie pozwalające na dodawanie AI workflows z użyciem dowolnego setupu kompatybilnego z OpenAI API, a następnie rozwinąć Pika Note o dodatkowe funkcje AI-based, funkcje dot. załączników czy współdzielenia notatek (znów, dodatkowe tematy z obszaru cybersec się szykują), a także dodanie prostego supportu do podglądu i edycji plików CSV i XLSX oraz otwierania plików tekstowych jako notatka. Podsumowując, zostańcie ze mną po więcej tego, jak zmagam się z własnym systemem