Zlecenie 12783966 - Przedłużenie subskrypcji systemu zabezpieczającego bazy...

ty Monitoring - DAM w oparciu o implementację systemu IMPERVA DAM. Subskrypcja na system kończy się 17.12.2026 r.
System DAM / System
1. Wykonawca dostarczy licencje ograniczone czasowo systemu IMPERVA DAM, ważne od 18.12.2026 r. przez 12 miesięcy (subskrypcje) lub dostarczy i wdroży rozwiązanie równoważne.
2. Liczba subskrypcji Systemu - 8 szt.
3. Funkcjonalna równoważność zaoferowanego rozwiązania:
1) Wykonawca dostarczy licencje czasowe (subskrypcja) na 12 miesiące dla systemu zapewniającego monitoring dostępu do baz danych (ang. Database Activity Monitoring) zwany dalej System / System DAM. System będzie licencjonowany per serwer bazodanowy, rozumiany jako instancja systemu operacyjnego, na której zainstalowany został silnik bazodanowy. Zamawiający może zainstalować dowolną liczbę modułów wykonawczych oraz centralnego komponentu zarządzającego w ramach wykupionej liczby serwerów bazodanowych. W celu zwiększenia wydajności oraz niezawodności Zamawiający może łączyć moduły wykonawcze w klastry. System DAM musi monitorować bazy danych zainstalowane on- site, w chmurze AWS, AZURE, GPC. Wymagane środowiska bazodanowe do monitorowania:
silnik bazodanowy
Microsoft SQL Server 2019
MS SQL Server Standard
Microsoft SQL Server 2014
MS SQL Server Express
Oracle 11g
Oracle 12.1.0.2
PostgreSQL
MariaDB
2) Minimalna liczba licencji Systemu - 8 szt.
3) System DAM musi składać się z:
a. centralnego komponentu zarządzającego,
b. modułu wykonawczego analizującego ruch SQL,
c. modułu analizującego, za pomocą algorytmów machine learning (User Behawior Analyzer), zapisane logi z ruchu SQL monitorowanych baz danych,
d. modułu wizualizującego dane, który z logów Systemu DAM umożliwia generowanie wykresów, raportowanie, tworzenie oraz wykonywanie grupy działań i ich argumentów (playbooks), przeglądanie, analizowanie, filtrowanie zebranych danych, tworzenie polityk bezpieczeństwa (reguł) służących do wykrywania niezgodnych działań użytkowników bazodanowych. Moduł ten musi w pełni integrować się z centralnym komponentem zarządzającym Systemu DAM w celu wymiany informacji o danych, które w Systemie DAM zostały sklasyfikowane jako wrażliwie. Moduł wizualizujący dane jako część System DAM musi mieć funkcjonalność podłączenia się do monitorowanych baz danych w celu pobrania logów z natywnych tabel audytowych bazy danych. Pobrane logi muszą zostać przekazane w celu dalszej analizy do modułu analizującego za pomocą algorytmów machine learning z pkt 3 lit c).
e. oprogramowania do monitorowania ruchu SQL instalowanego na serwerze bazodanowym, zwanym dalej Agentem Bazodanowym
4) Wszystkie elementy Systemu DAM z pkt 3 muszą zostać dostarczone jako gotowe maszyny wirtualne (ang. Virtual appliance) dla minimum: VMWare. Rozwiązanie musi zapewnić możliwość migracji modułów wykonawczych z systemu wirtualnego na fizyczne appliance bez konieczności wykupywania dodatkowych licencji, a jedynie poprzez dokupienie fizycznych platform sprzętowych z oferty Producenta oferowanego rozwiązania (tzw. SPARE appliance). Serwery spare appliance nie są przedmiotem niniejszego zamówienia, jednakże producent rozwiązania musi zapewnić możliwość użycia ich w przyszłości. Zamawiający dopuszcza ewentualną możliwość instalacji komponentów DAM w środowisku RedHat 8.x.
5) W celu możliwości rozszerzenia Systemu DAM o fizyczne elementy wymaga się, aby element Systemu DAM z pkt 3 lit. B). był dostępny w ofercie Producenta jako fizyczny serwer (Appliance) z zainstalowanym Systemem DAM.
6) Wszystkie zamawiane elementy Systemu DAM muszą być dostarczone przez jednego Producenta.
7) System musi zawierać licencję na moduł zarządzający, który może stanowić centralny moduł zarządczy dla wielu pojedynczych systemów zarządczych,
8) Wymagane jest wsparcie techniczne producenta na wszystkie elementy Systemu DAM, ważne przez 24 miesiące od daty dostarczenia licencji, obejmujące pomoc w przypadku awarii, obsługę problemów technicznych w trybie 24x7 oraz dostęp do aktualizacji oprogramowania oraz dokumentacji technicznej. Zamawiający dopuszcza licencję typu subskrypcja.
9) Rozwiązanie musi zapewnić funkcjonalność klasy UBA (User Behawior Analyzer) będącego elementem dostarczanego systemu i pochodzącym od tego samego producenta. System UBA musi z wykorzystaniem mechanizmów sztucznej inteligencji i nauczania maszynowego analizować logi pochodzące z Systemu DAM zapewniając w ten sposób realizacje poniższych scenariuszy detekcji i raportowania anomalii i incydentów:
a. dostępu do bazy danych w niestandardowych dla jego pracy godzinach,
b. używanie przez użytkownika bazodanowego (p.. administratora baz danych lub innego) kont serwisowych (np. tych, które wykorzystywane są przez aplikacje),
c. użytkownik bazodanowy przeglądał rekordy bazodanowe wprowadzone przez innych użytkowników bazodanowych,
d. inna ilość błędnych logowań do konta bazodanowego niż standardowa ilość,
e. użytkownik bazodanowy przeglądał w krótkim czasie rekordy z wielu baz danych,
f. przeglądanie przez użytkownika bazodanowego bardzo wielu danych sklasyfikowanych jako wrażliwe (sensitive),
g. użytkownik bazodanowy korzysta z danych, które powinny być osiągalne tylko poprzez aplikacj- - użytkownika serwisowego (aplikacyjnego),
h. użytkownik bazodanowy wykonał polecenia SQL, których sposób i cel wykonania jest podejrzany,
i. użytkownik bazodanowy przeszukał bazę danych za pomocą dynamicznego SQL w sposób nieprawidłowy.
10) Moduł analizujący zachowania użytkowników musi dokonywać analizy poprzez porównanie normalnego zachowania użytkowników bazodanowych w oparciu o obserwowane modele zachowań, specyficzne dla danej grupy użytkowników, dla całości organizacji, dla wybranych grup. Moduł musi dokonywać tej analizy w sposób automatyczny, prezentując wyniki analizy w formie incydentów i anomalii zachowań poszczególnych użytkowników bazodanowych.
11) Moduł analizujący zachowania użytkowników musi zapewnić możliwość odróżnienia i określenia kto pracuje z Systemem oraz z jakich danych korzysta:
a. użytkowni ka/pracowni ka/adm i ni stratora,
b. użytkownika aplikacyjnego,
c. użytkownika uprzywilejowanego,
d. metadanych,
e. danych krytycznych dla firmy.
12) System monitorowania baz danych (DAM) musi posiadać następujące funkcje:
a. Aktywne wyszukiwanie i klasyfikacja usług bazodanowych w sieci klienta.
b. Wyszukiwanie i klasyfikacja informacji w bazach danych. Klasyfikacja odbywać się musi zarówno poprzez wykorzystanie wbudowanych wzorców danych (jak dane personalne, dane finansowe, identyfikatory bankowe, dane medyczne etc.) jak i przez definiowanie własnych wyrażeń. Definicja uwzględniać musi nazwy tabel, kolumn oraz rekordy w tabelach przy użyciu wyrażeń regularnych. Musi istnieć możliwość wykorzystania wykrytych informacji przy definiowaniu reguł monitorowania.
c. Testowanie podatności systemów bazodanowych, przy uwzględnieniu analizy podatności systemu operacyjnego oraz baz danych na znane typy ataków, błędy konfiguracyjne, brak aktualizacji oprogramowania, weryfikacja zabezpieczenia kont użytkowników bazodanowych. Rozwiązanie musi posiadać funkcję uwierzytelnienia w systemie operacyjnym oraz w bazie danych w celu wykonania powyższych testów. Uwierzytelnienie w systemie operacyjnym obsługiwać powinno nie mniej niż protokoły SSH oraz NTLM. W proponowanym rozwiązaniu zawarta musi być licencja na testowanie podatności nie mniej niż 200 instancji bazodanowych.
d. Rozwiązanie musi zawierać co najmniej 1000 wstępnie zdefiniowanych testów oceny podatności na bazy danych, które obejmują następujące kategorie:
i. kontrola dostępu,
ii. audyt,
iii. uwierzytelnianie i zarządzanie użytkownikami,
iv. ogólne informacje o bazie danych,
v. wewnętrzne testy,
vi. znane ataki oparte na CVE,
vii. licencjonowanie,
viii. integralność systemu operacyjnego,
ix. kontrola zasobów,
x. wrażliwe wykrywanie danych.
e. Rozwiązanie musi mieć przygotowane testy podatności zgodne ze standardem CIS i DISA STIG dla minimum baz danych ORACLE, MSSQL, MySQL
f. Monitorowanie dostępu do informacji (ang. Database Activity Monitoring, zwany dalej DAM) w bazach danych (z uwzględnieniem języków DCL, DML, DDL, TCL, procedur składowanych). Definiowanie polityki monitorowania musi uwzględniać nie mniej niż następujące kryteria: użytkownik bazodanowy i/lub aplikacyjny, tabele, kolumny, typ danych, schemat bazy danych, ilość wystąpień, dostęp do danych wrażliwych (zdefiniowanych poprzez system wykrywania danych z pkt 11.b)
g. Dodawanie informacji o użytkowniku wykonującym operacje bazodanowe (np. imię i nazwisko) poprzez pobieranie danych z zewnętrznych systemów (wymagana jest w tym celu integracja z Active Directory, serwerów LDAP, pobranie danych z pliku oraz z baz danych przy wykorzystaniu zapytań SQL).
h. System DAM musi mieć możliwość pobierania danych z tablic natywnego audytu oraz zdarzań (events) baz danych SQL
i. W przypadku gromadzenia zdarzeń zebranych za pomocą Agenta bazodanowego rozwiązanie musi obsługiwać funkcję przechowywania i przekazywania danych lub równoważną funkcjonalność zaprojektowaną w celu zapobiegania utracie zdarzeń (logów) z powodu niedostępności centralnej platformy.
j. System DAM musi integrować się z narzędziami typu Privilige Access Management, w celu pobierania dynamicznych danych uwierzytelniających.
13) System ochrony baz danych musi posiadać następujące funkcje:
a. Definiowanie reguł dostępu użytkowników do poszczególnych baz danych na poziomie sieciowym (pkt 11 lit. a).
b. Definiowanie reguł dostępu użytkowników bazodanowych do poszczególnych obiektów w bazie danych poprzez automatyczne tworzenie (na podstawie analizy ruchu sieciowego) listy użytkowników oraz listy zapytań SQL, jakie użytkownik może wykonać w odniesieniu do obiektów baz danych.
c. Musi istnieć możliwość definiowania oddzielnych reguł dostępu w odniesieniu do tabel z danymi wrażliwymi, sklasyfikowanymi przez moduł opisany w pkt pkt 11 lit. b.
d. System musi posiadać dodatkowo możliwość automatycznego tworzenia list: źródłowych adresów IP, nazw aplikacji klienckich oraz nazw systemu operacyjnego, z których użytkownik ma dostęp do zasobów. Na podstawie powyższych list definiowane są reguły polityki bezpieczeństwa.
e. System musi posiadać możliwość zdefiniowania bardzo szczegółowych reguł monitoringu dostępu do danych, zapewniajnc jednocześnie odpowiedni poziom ochrony dla całości ruchu do bazy z uwzględnieniem języków w DCL, DML, DDL, TCL, procedur składowanych.
f. Tworzenie list tabel, do których poszczególni użytkownicy bazodanowi nie mogą mieć dostępu. Musi istnieć również możliwość definiowania dni tygodnia oraz godzin, w jakich dany użytkownik może nawiązać połączenie z bazą danych.
g. W logach dotyczących zarejestrowanych naruszeń / anomalii wymagane są, co najmniej następujące informacje: nazwa użytkownika bazodanowego, dodatkowe dane o użytkowniku pochodzące z zewnętrznych systemów (moduł opisany w pkt 11 lit. g, źródłowy adres IP, pełne zapytanie SQL wykonane przez użytkownika.
h. Możliwość zablokowania ruchu wykorzystującego podatności wykryte w bazach danych poprzez moduł opisany w pkt 11 lit. c.
14) System DAM musi wykrywać komendy wykonywane na systemie zarządzania bazą danych
(poza silnikiem SQL) jak np. Export Direct w DB Oracle
15) System DAM musi archiwizować logi jak również przechowywać je w module wizualizującym dane przez minimum rok. Archiwizowane logi dotyczące aktywności użytkowników bazodanowych muszą być natywne zapisywane w postaci zaszyfrowanej i skompresowanej. Archiwizowane logi muszą być podpisywane za pomocą certyfikatu.
16) Musi istnieć możliwość zmiany wszystkich haseł użytkowników oferowanego Systemu DAM - w GUI, w systemie operacyjnym.
17) Rozwiązanie musi posiadać funkcję wysyłania informacji o zdarzeniach poprzez protokół SNMP, syslog, SIEM, wiadomość e-mail oraz uruchomienia skryptu jednocześnie ustawianymi per konkretna polityka bezpieczeństwa.
18) System musi posiadać gotowe szablony raportów dotyczące:
a. alarmów bezpieczeństwa,
b. zdarzeń systemowych,
c. zmian w profilach baz danych,
d. monitorowania aktywności użytkowników na bazach,
e. wykonanych testów podatności systemów, klasyfikacji usług oraz informacji w bazach danych,
f. zgodności z wymaganiami regulacji, m.in.: PCI, SOX.
19) Musi istnieć możliwość wykorzystania informacji z zewnętrznych źródeł (opisanych w pkt 11 lit. g) w raportach.
20) Musi istnieć możliwość tworzenia własnych raportów, zarówno w formie tekstowej jak i reprezentacji graficznej, a także automatycznego, cyklicznego wysyłania raportów drogą e-mail. Raporty muszą być generowane w standardach PDF, XLSX, CSV,
21) Producent musi zapewnić aktualizację systemu, uwzględniając co najmniej: sygnatury ataków, listę reguł polityki bezpieczeństwa oraz monitorowania aktywności użytkowników na bazach danych, listę testów podatności baz danych oraz listę raportów.
22) System musi monitorować oraz zabezpieczać, co najmniej następujące systemy baz danych: Oracle, MSSQL, MySQL, Sybase, Informix, IBM DB2 (LUW), Netezza, Teradata, MariaDB, MySQL, PostgreSQL, MongoDB, Percona MySQL, Azure Maria DB, Azure PostgreSQL, Google Cloud MySQL, Amazon Aurora MySQL, Amazon Aurora PostgreSQL, Amazon RDS for Microsoft SQL Server. Jako zabezpieczenie rozumiane jest zarówno monitorowanie aktywności (audyt) jak i aktywna ochrona bazy danych w tym blokowanie niepożądanych aktywności (DataBase Firewall) w tym analiza behawioralna całości ruchu bazodanowego obserwowanego na poziomie sieciowym nawet niepoddanego monitorowaniu. Blokowanie ruchu SQL wymagane jest w środowiskach bazodanowych, gdzie System DAM monitoruje ruch za pomocą Agenta bazodanowego lub modułu wykonawczego w konfiguracji L2 In-line Bridge.
23) AgentW cenie zakupionego systemu dostarczonych powinno być niemniej niż ilości potrzebna do ochrony 8 serwerów bazodanowych AgentAgenta Bazodanowego. Wspierane muszą być następujące systemy operacyjne: AIX, HP-UX, RedHat, SUSE, CentOS, ORACLE UEK, Solaris, Windows Server, Ubuntu. AgentAgent Bazodanowy monitoruje ruch SQL i wysyła logi do modułu wykonawczego:: wszystkie logi, lub wyłącznie logi z lokalnej aktywności użytkowników bazodanowych, lub wyłącznie logi pochodzące z połączeń sieciowych. Moduł wykonawczy musi posiadać możliwości weryfikacji stanu działania AAgenta.
24) Agent musi posiadać możliwość pracy w trybach sniffing oraz inline. Jako sniffing rozumiany jest tryb pracy bez opóźnień z możliwością terminacji sesji w przypadku wykrycia nadużycia. Tryb inline rozumiany jest jako wstrzymywanie ruchu od użytkownika do systemu bazodanowego, przesyłanie ruchu do jednostki wykonawczej oraz oczekiwanie na decyzję czy zapytanie jest zgodne z polityką bezpieczeństwa. Agent musi posiadać możliwość blokowania ruchu w przypadku wykrycia incydentu.
25) Agent musi wykrywać nowo zdefiniowane interfejsy bazy danych i automatycznie dodawać je do reguł monitorowania.
26) W konfiguracji Agenta musi być możliwość definiowania reguł, zgodnie z którymi AAgent wybierać będzie ruch, który ma był wysyłany do modułu wykonawczego monitorowania i ochrony baz danych.
27) Agent musi posiadać możliwość kompresji ruchu przesyłanego do modułów wykonawczych.
28) Moduły wykonawcze muszą mieć możliwość zbudowania dwóch typów klastrów n1:
a. Moduły wykonawcze muszą posiadać możliwość łączenia w klaster n1. Wielu Agentów komunikuje się z klastrem. Główny serwer węzła (Master) ma zadane loadbalancera. Do budowy klastra nie może być użyta zewnętrzna infrastruktura np. wydzielony loadbalancer firm trzecich.
b. W przypadku gdy baza danych generuje bardzo duże obciążenie, więcej niż moduł wykonawczy może obsłużyć to moduły wykonawcze muszą posiadać możliwość łączenia się w klaster n1, gdzie tylko jeden Agent komunikuje się z klasterem w celu rozłożenia obciążenia na wiele węzłów klastra, które generuje baza danych.
29) Serwer zarządzający oferowanego rozwiązania musi być dostępny poprzez interfejs przeglądarki Web w celu eliminacji konieczności instalacji dodatkowego oprogramowania na stacji administratora.
30) Wymagane jest zarządzanie zorientowane zadaniowo. Oznacza to, że musi istnieć mechanizm informowania administratora o wykonaniu/nie wykonaniu na czas zadania zleconego innym użytkownikom Systemu.
31) Aktualizacja Systemu musi być dostępna zarówno poprzez ręczne pobranie zawartości ze strony producenta jak i automatycznie, poprzez zdefiniowanie terminów wykonania procedury aktualizacji.
32) Wszystkie elementy centralnego komponentu zarządzającego muszą być dostarczone przez tego samego producenta co moduły wykonawcze oraz w formie gotowych maszyn wirtualnych (ang. virtual appliance) działających w środowisku ESX/ESXi.
33) Rozwiązanie musi zostać dostarczone w formie kompletnego rozwiązania tj. nie może wymagać do działania żadnego oprogramowania firm trzecich np. zewnętrznych baz danych.
34) Uwierzytelnianie użytkowników oferowanego rozwiązania musi być możliwe za pomocą:
a. użytkownika lokalnego,
b. protokołu RADIUS,
c. poprzez integracji z Active Directory.
35) Serwer zarządzający musi posiadać wbudowany mechanizm RBAC który umożliwia integrację z Active Directory poprzez przypisanie roli w zależności od przynależności do określonej grupy w Active Directory.
36) Całość konfiguracji oraz repozytorium logów musi być przechowywane na centralnym serwerze zarządzania lub module wizualizującego dane.
37) Komponent zarządzający musi wyświetlać w czasie rzeczywistym logi na jednej planszy (dashboard):
a. zdarzenia z ruchu bazodanowego, które łamią polityki bezpieczeństwa (securitylogs),
b. zdarzenia z działania Systemu DAM (system events np. logowanie/wylogowanie użytkowników, dodanie/usunięcie polityki bezpieczeństwa lub audytu, problemy z modułem wykonawczym (np. przeciążenie, uszkodzenie dysku), brak prawidłowej komunikacji z Agentem itp.).
38) System DAM musi zapewnić możliwość pracy w trybach:
a. transparent In-line (warstwa 2 ISO/OSI),
b. SPAN,
c. AAgent (program instalowany na serwerze baz danych, który przesyła kopię ruchu bazodanowego do modułu wykonawczego w celu wykonania analizy). Agent nie wykonuje analizy ruchu bazodanowego,
d. pobieranie zdarzeń oraz logów audytowych z natywnych tablic audytowych systemu bazodanowego.
39) System DAM musi mieć otwarte REST API, które umożliwia konfigurację rozwiązania oraz pobieranie danych.
40) Fizyczny serwer, jeśli będzie wymagany - Appliance modułu wykonawczego musi mieć minimum karty sieciowe (IGbps RJ45 minimum 16 szt. lub 10Gbps SFP SR minimum 4 sztuki, 1 szt. RJ45 do sieci zarządzającej oraz 1 szt. RJ45 do podłączenia sieci LAN lub wydzielenia do podłączenia Agenta bazodanowego), które wyposażone są w fizyczny bypass. W przypadku awarii urządzenia bypass w zależności od konfiguracji musi przepuszczać ruch sieciowy bez sprawdzania lub zablokować ruch całkowicie. Minimalna wydajność monitorowania ruch SQL to 10.000TPS. Serwer musi być wyposażony w kartę zdalnego administrowania (IPMI) oraz kartę wspierającą rozszyfrowywanie ruchu SSL/TLS.
41) Oferent musi dostarczyć w ramach oferty 2 dniowe (2x8h) szkolenie dla minimum 10 administratorów, szkolenia musza być poprowadzone w języku polskim w formule zdalnej lub on-site (w siedzibie Zamawiającego lub Wykonawcy), zakres szkolenia:
a. Instalacja i podstawowa konfiguracja
b. Konfigurowanie zasad audytu
c. Konfigurowanie skanowania w poszukiwaniu poufnych danych
d. Najlepsze praktyki dotyczące zasad zabezpieczeń
e. Zasady tworzenia raportów
f. Definiowanie reguł dostępowych do baz danych
g. Logowanie zdarzeń
Usługa wdrożeniowa przy rozwiązaniu równoważnym
42) Usługa wdrożeniowa będzie polegała na zaprojektowaniu, wdrożeniu i serwisowaniu Systemu DAM:
a. dokument - Projekt wdrożenia,
b. instalacja Systemu DAM i konfiguracja 8 Agentów na serwerach bazodanowych,
c. wspólne przygotowanie polityk audytowych, bezpieczeństwa dla 5 wybranych baz danych,
d. wspólne skanowanie i klasyfikacja danych wrażliwych dla 5 wybranych baz danych,
e. skanowanie konfiguracji serwerów bazodanowych (np. CIS, DISA),
f. zasilenie logami z Systemu DAM moduł machine learning oraz moduł wizualizujący dane,
g. profile bazodanowe - wspólne porządkowanie profili, likwidacja false-positive dla 5 wybranych baz danych,
h. analiza wykrytych zdarzeń,
i. usprawnienie pracy zainstalowanych Agentów,
j. podłączenie i monitorowanie baz danych w środowisku chmurowym,
k. Przygotowanie dokumentów:
i. dokumentacja powdrożeniowa,
ii. procedury eksploatacyjne,
iii. instrukcje techniczne.
Wsparcie techniczne Producenta Systemu DAM będzie obejmować:
a. konsultacje telefoniczne, email, dostępie do portalu obsługi klienta celem rozwiązania problemów napotkanych podczas eksploatacji Systemu, pomocy w zastosowaniu rozwiązań konfiguracyjnych urządzenia, w czasie 24 miesięcy od dnia podpisania umowy,
b. dostęp do asysty technicznej 24x7x365. Liczba autoryzowanych kontaktów z asystą techniczną producenta Systemu - nieograniczona,
c. możliwość zgłaszania problemów z Systemem w trybie 24 godziny 7.00 dni w tygodniu,
d. dostęp do inżynierów wsparcia i serwisu przez następujące kanały komunikacyjne: poczta elektroniczna, portal internetowy, telefon,
e. uaktualnienia/aktualizacje Oprogramowania zwiększające efektywność oraz rozwiązujące problemy z Systemem,
f. uaktualnienia/aktualizacje Oprogramowania rozszerzające funkcjonalność związane z efektywnością Systemu i jego dostosowaniem do zmieniających się technologii,
g. elektroniczny dostęp do dokumentacji producenta,
h. elektroniczny dostęp do bazy wiedzy,
i. elektroniczny dostęp do portalu pozwalającego na wymianę doświadczeń i wiedzy z innymi użytkownikami,
j. elektroniczny dostęp do portalu pozwalającego na pobranie nowych wersji Oprogramowania oraz poprawek,
k. jeżeli Wykonawca nie jest producentem Oprogramowania, Wykonawca nie ponosi odpowiedzialności z tytułu opóźnień, które są niezależne od Wykonawcy i wynikają z potrzeby przygotowania przez producenta rozwiązania odpowiedniej poprawki - w tej sytuacji czas przewidziany Umową dla danego świadczenia jest liczony od momentu opublikowania przez producenta stosownej poprawki. Do czasu wydania przez producenta Oprogramowania poprawki Wykonawca podejmie działania minimalizujące skutki problemów technicznych, których usunięcie nastąpi z chwilą implementacji poprawki przygotowanej przez producenta Oprogramowania.
Asysta techniczna Wykonawcy w zakresie funkcjonowania Systemu DAM:
a. wymiar: minimum 2 godzin miesięcznie. Niewykorzystane godziny konsultacyjne przechodzą na kolejne miesiące,
b. dostępność: dni robocze od 7.30 do 15.30 z wyjątkiem dni świątecznych i ustawowo wolnych od pracy,
c. Miejsce: siedziba Zamawiającego lub w uzgodnieniu z Zamawiającym zdalnie,
d. realizacja zadań wynikających z zakresu umowy, w tym m.in.:
i. usuwania błędów krytycznych, poważnych i niskiej kategorii,
ii. monitoringu i zapewnienia dostępności systemu,
iii. reagowania na incydenty bezpieczeństwa,
iv. aktualizacji i wsparcia technicznego
e. Czas naprawy awarii jest to maksymalny czas naprawy (przywrócenia sprawności Systemu), tzn. czas liczony od chwili zgłoszenia awarii do momentu usunięcia awarii potwierdzonej diagnostyką lub testem.
f. Naprawa awarii powinna być realizowana zgodnie z czasami podanymi poniżej:
i. Błąd Krytyczny (P1): Błąd powodujący całkowitą niedostępność systemu lub uniemożliwiający korzystanie z jego podstawowych funkcji. Przykładem jest awaria skutkująca brakiem możliwości logowania użytkowników lub realizacji kluczowych procesów. Reakcja w ciągu... godziny.
ii. Błąd Poważny (P2): Błąd ograniczający funkcjonalność systemu, nie zatrzymujący jednak jego działania. Przykład: spowolnienie kluczowych funkcji. Reakcja w ciągu.. godzin.
iii. Błąd Niskiej Kategorii (P3): Drobny błąd o charakterze kosmetycznym lub niskim wpływie na funkcjonalność, np. literówki lub błędy graficzne. Reakcja w ciągu.. godzin.
g. Jeżeli z jakichś przyczyn usunięcie awarii nie będzie możliwe, Wykonawca zobowiązany jest do wymiany i dostarczenia na czas trwania naprawy dokładnie identycznego elementu Systemu, który uległ awarii.
h. Zgłoszenia będą przyjmowane pod numerem tel, pocztą elektroniczną e-mail:,
lub w formie elektronicznej, w internetowym systemie wsparcia Wykonawcy.
i. Wdrożenie, asysta techniczna i świadczenie usług konsultacyjnych muszą być świadczone przez zespół składający się, z co najmniej dwóch inżynierów (inżynier 1 i inżynier 2) Wykonawcy, z których każdy posiada doświadczenie w zakresie zaprojektowania, wdrożenia i serwisowania oferowanego systemów DAM oraz obowiązujący certyfikat producenta oferowanego systemu DAM potwierdzający kompetencje i wiedzę techniczną.
Wykonawca oświadcza, że jest autoryzowanym partnerem Producenta systemu, upoważniającym do sprzedaży produktów na terenie Unii Europejskiej. W celu potwierdzenia należy przedłożyć certyfikat partnerstwa lub oświadczenie producenta.