W artykule zebrano zasady i standardy dotyczące dostarczania tzw. bramki podpisu chmurowego do EZD RP. Mają one zastosowanie dla oprogramowania wdrażanego w ramach usługi SaaS EZD RP prowadzonej w chmurze NASK. Mogą być także stosowane przez podmioty zarządzające instalacjami EZD RP w modelu on-premise lub chmurze prywatnej.
Poniższe wytyczne są integralną częścią onboardingu integratora oraz wymaganym elementem weryfikacji technicznej i bezpieczeństwa dostarczanego oprogramowania.
Ogólne wytyczne
Dostarczane oprogramowanie (bramka podpisu chmurowego) musi być zgodne ze specyfikacją integracji opisaną w artykule Integracja z modułem Dostawcy podpisów chmurowych.
Integratorzy są zobowiązani do projektowania, rozwijania i testowania wszystkich komponentów oprogramowania zgodnie z uznawanymi najlepszymi praktykami branżowymi i obowiązującymi standardami bezpieczeństwa. Wymagane działania obejmują m.in.:
- integrację zabezpieczeń od początkowych faz projektowania aplikacji;
- użycie odpowiednich algorytmów szyfrowania do ochrony danych przechowywanych i przesyłanych;
- zapewnienie, że oprogramowanie jest regularnie aktualizowane oraz że znane luki bezpieczeństwa są łatane;
- przeprowadzanie testów penetracyjnych i audytów bezpieczeństwa.
W celu zapewnienia płynnej integracji i obsługi oprogramowania, od integratorów wymaga się dostarczenia dokumentacji technicznej, która obejmuje:
- instrukcję instalacji i konfiguracji – opis kroków niezbędnych do prawidłowego wdrożenia i konfiguracji oprogramowania;
- przewodnik użytkownika – informacje niezbędne do efektywnego korzystania z oprogramowania.
Aby zapewnić ciągłość współpracy i bezpieczeństwo, oczekuje się, że integratorzy będą śledzić ogłoszenia dotyczące nowych wersji i aktualizacji modułu podpisu chmurowego, co pozwoli dostosowywać swoje oprogramowanie. Jednocześnie NASK zobowiązuje się do:
- zapewnienia kompatybilności wersji – utrzymania zgodności naszych aktualizacji z wcześniej udostępnioną specyfikacją API, aby nie zakłócać istniejących integracji.
- komunikowania zmian – przekazywania z odpowiednim wyprzedzeniem informacji o wszelkich zmianach w specyfikacji API, które mogą wpłynąć na integracje.
Wymagane jest, aby oprogramowanie funkcjonowało w trybie multitenant, czyli obsługiwało wiele podmiotów w ramach jednej instancji.
Dostępność obrazów oprogramowania
Oprogramowanie (bramka podpisu chmurowego) jest uruchamiane w środowisku Kubernetes, z zarządzaniem realizowanym poprzez Rancher. Wymagania dotyczące publikacji obrazów oprogramowania obejmują:
- publiczne repozytorium obrazów – integratorzy powinni udostępniać obrazy oprogramowania w publicznie dostępnym repozytorium, takim jak Docker Hub, Google Container Registry lub inne podobne, zapewniając łatwy dostęp dla użytkowników końcowych (NASK, inne podmioty wdrażające EZD RP;
- standardy nazewnictwa – obrazy muszą stosować jasne i spójne konwencje nazewnictwa, ułatwiające identyfikację i zarządzanie wersjami;
- autoryzacja repozytorium – repozytorium może implementować mechanizmy autoryzacji takie jak login i hasło (/tokeny) lub ograniczeń sieciowych (IP whitelist);
- bezpieczeństwo obrazów – obrazy oprogramowania muszą być regularnie skanowane pod kątem podatności za pomocą narzędzi takich jak Prisma, Azure Security Center, Clair i innych, w celu identyfikacji i naprawy znanych zagrożeń bezpieczeństwa przed ich udostępnieniem;
- notyfikacje o aktualizacjach – użytkownicy końcowi (NASK, inne podmioty wdrażające EZD RP) powinni być informowani o dostępnych aktualizacjach obrazów oprogramowania, w tym o nowych funkcjach, poprawkach bezpieczeństwa i usprawnieniach wydajnościowych.
Bramka podpisu chmurowego musi być dostarczana w formie Helm chart, aby ułatwić jej wdrożenie. Helm charts są standardem w zarządzaniu pakietami w ekosystemie Kubernetes. Dodatkowe wymagania:
- struktura i dokumentacja – Helm chart powinien być zorganizowany i zawierać dokumentację, opisującą jego strukturę, zależności oraz parametry konfiguracyjne;
- zasady nazewnictwa – należy stosować spójne i jednoznaczne zasady nazewnictwa dla chartów oraz ich wersji, ułatwiające zarządzanie pakietami;
- wersjonowanie chartów – należy stosować semantyczne wersjonowanie (SemVer) dla Helm charts, co ułatwia idenyfikację wersji i zarządzanie zależnościami;
- zarządzanie zależnościami – Helm charts powinny precyzyjnie definiować zależności zewnętrzne (obrazy kontenerów, biblioteki, inne wykresy – charts) wraz z ich wersjami, aby zapewnić kompatybilność i uniknąć konfliktów.
Dodatkowo wymagana jest kompatybilność dostarczanego oprogramowania z wymaganiami systemu EZD RP dotyczącymi następujących elementów:
- relacyjne bazy danych – w przypadku wykorzystania baz danych oprogramowanie musi być kompatybilne z relacyjnymi bazami danych PostgreSQL oraz MS SQL;
- systemy kolejkowe i buforujące dane – w przypadku wykorzystania tych elementów wymagane jest wsparcie dla systemów Redis oraz RabbitMQ;
- usługa składowania plików – jeśli oprogramowanie wykorzystuje tę usługę, musi być kompatybilne z usługami składowania plików oferującymi udziały sieciowe NFS lub repozytorium obiektowe zgodne z protokołem S3.
Weryfikacja oprogramowania
Proces weryfikacji bramki podpisu chmurowego obejmuje trzy etapy: weryfikację techniczną, sprawdzenie zgodności oprogramowania z licencjami oraz proces onboardingu.
Weryfikacja techniczna
Proces regularnego skanowania podatności w dostarczanych obrazach oprogramowania zostanie wprowadzony przez NASK w celu zapewnienia ciągłego monitorowania bezpieczeństwa. W przypadku identyfikacji krytycznych podatności lub wykorzystania przestarzałych technologii, oczekuje się, że integratorzy dostarczą zaktualizowaną wersję w ciągu 30 dni od otrzymania informacji o wykryciu podatności. Po tym terminie wersje oprogramowania z istniejącymi podatnościami zostaną wyłączone.
Wymagania dotyczące licencji i oświadczenia o braku wad prawnych
Aby zapewnić zgodność prawną dostarczanego oprogramowania oraz uniknąć potencjalnych roszczeń prawnych od stron trzecich, wymagane jest, aby oprogramowanie było dostarczane wraz z pełnym zestawem odpowiednich licencji, obejmujących zarówno samo oprogramowanie, jak i wszystkie jego zależności. Dostawcy są zobowiązani do przedstawienia oświadczenia, w którym potwierdzają, że:
- dostarczone oprogramowanie oraz wszystkie zawarte w nim biblioteki i zależności są objęte licencjami umożliwiającymi ich wykorzystanie w ramach ekosystemu EZD RP bez dodatkowych opłat lub ograniczeń;
- oprogramowanie nie narusza praw własności intelektualnej, patentów, znaków towarowych lub innych praw własnościowych stron trzecich;
- dostawca posiada wszystkie niezbędne prawa i zgody do udostępnienia oprogramowania w ramach ekosystemu EZD RP, a dostarczone oprogramowanie jest wolne od jakichkolwiek wad prawnych, które mogłyby skutkować roszczeniami czy dodatkowymi kosztami.
Dodatkowo dostawcy zobowiązani są do bieżącego monitorowania i aktualizacji swoich licencji oraz zależności oprogramowania, aby zapewnić ciągłą zgodność z wymogami prawnymi oraz reagować na ewentualne zmiany w przepisach dotyczących praw autorskich i licencjonowania.
W razie wystąpienia roszczeń prawnych związanych z dostarczonym oprogramowaniem, integrator będzie odpowiedzialny za wszelkie wynikające z tego tytułu koszty, w tym koszty obrony prawnej, odszkodowania oraz inne opłaty związane z roszczeniami stron trzecich.
Proces onboardingu
Proces dostarczania oprogramowania został zaprojektowany w taki sposób, aby zapewnić płynność i efektywność onboardingu. Składa się on z następujących etapów:
- rejestracja integratora na Piaskownicy EZD RP – dostawcy bramki podpisu chmurowego muszą posiadać konto na środowisku tzw. Piaskownicy API EZD RP;
- przekazanie dokumentacji technicznej – dostarczana jest dokumentacja oprogramowania (instrukcja wdrożenia);
- weryfikacja zgodności z zasadami – wewnętrzny zespół dokonuje przeglądu dostarczonych materiałów, aby ocenić zgodność oprogramowania z zasadami dotyczącymi bezpieczeństwa, jakości i kompatybilności;
- testowanie integracji – oprogramowanie jest instalowane w środowisku testowym (Piaskownica EZD RP), aby przeprowadzić testy integracyjne i użytkownika końcowego;
- adresowanie znalezionych problemów – w przypadku wykrycia problemów, dostawcy są zobowiązani do ich rozwiązania i przesłania aktualizacji do ponownej weryfikacji;
- akceptacja i publikacja – po pomyślnej weryfikacji i testach, oprogramowanie zostaje zaakceptowane do wdrożenia i udostępnione użytkownikom końcowym (na środowisku produkcyjnym); informacja o zgodności dostarczanego oprogramowania zostanie umieszczona w Portalu EZD RP na stronie zawierającej listę oprogramowania zintegrowanego z EZD RP.