„Dostawa urządzenia zabezpieczającego aplikacje WWW(Firewall Aplikacyjny) wraz z usługą wdrożenia”
| Publication date | 2016-09-20 |
| End date | 2016-09-29 09:45:00 |
| Instytucja | Centrum Usług Informatycznych we Wrocławiu |
| Miejscowość | Wrocław |
| Województwo | dolnośląskie |
| Branża |
|
Szczegóły |
|
| Numer ogłoszenia | 310873 / 2016 |
| Document type | ZP-400 |
| Cpv code | 324200003, 722650000 |
| Adres strony internetowej siwz | |
Przedmiot zamówienia
| 1. 1.Celem zamówienia jest zakup systemu Web Aplication Firewall, wdrożenie go w infrastrukturze zamawiającego oraz szkolenia z administracji systemem. Zadaniem systemu " Web Aplication Firewall" ma być monitorowanie całej aktywności użytkowników względem aplikacji internetowych będących w posiadaniu Urzędu Miasta Wrocław. System ma za zadanie chronić te aplikację i dane przed cyberatakami. 2.Zamówienie obejmuje: 1) Wdrożenie rozwiązania w infrastrukturze zamawiającego uwzględniając wszystkie aplikacje będące w posiadaniu Zamawiającego (jest to około 40 adresów URL), dostarczenie dokumentacji technicznej z wdrożenia zawierającej schematy połączeń oraz konfiguracji zabezpieczeń aplikacji. 2) Zapewnienie ciągłości poprawnego działania "Web Aplication firewall". 3) Zapewnienie Wsparcia technicznego producenta sprzętu/ maszyny wirtualnej dla systemu "Web Aplication firewall" w okresie trwania umowy. 4) Zapewnienie opieki serwisowej w zakresie rozwiązywania problemów, aktualizacji oraz konfiguracji systemu. 5) Zapewnienie Wsparcia Wykonawcy oraz producenta oprogramowania dla wdrożonego systemu. 6) Wymagane jest potwierdzenie przez producenta bądź dostawce oprogramowania poniżej opisanych „kluczowych elementów systemu”. 3. Kluczowe elementy które musi posiadac system: 1) Wszystkie elementy systemu zabezpieczeń muszą być dostarczone przez jednego producenta w formie gotowych maszyn virtualnych działających w środowisku ESX/ESXi 2) System musi działać w następujących trybach pracy: Transparent Bridge (inline warstwa 2 ISO/OSI), Transparent Reverse Proxy – tj praca w trybie proxy nie wymagająca korzystania z nowych adresów IP, Reverse Proxy oraz Sniffing przy czym musi istnieć możliwość działania w trybie Transparent Bridge oraz Transparent Reverse Proxy w obrębie tych samych chronionych aplikacji. 3) Moduły wykonawcze muszą mieć możliwość pracy w trybie High Availability (HA), powinny zawierać mechanizm ochrony typu Stateful Firewall oraz weryfikować zgodność komunikacji sieciowej ze standardem protokołu tcp/ip, opisanym w RFC. 4) System musi mieć wydajność analizy protokołu http/https na poziomie 500Mbps. 5) Uwierzytelnianie użytkowników oferowanego rozwiązania musi być możliwe za pomocą integracji z Active Directory, LDAP w celu uzyskania dodatkowych informacji w logach na temat użytkownika. Obsługiwane muszą być nie mniej niż następujące metody uwierzytelnienia: formularze html, certyfikat cyfrowy, kerberos, NTLM. 6) Całość konfiguracji oraz repozytorium logów musi być przechowywane na centralnym serwerze zarządzania. 7) System powinien na podstawie analizy obserwowanego ruchu zbudować odzwierciedlenie całej struktury aplikacji, składającej się z katalogów, URLi, metod dostępu, parametrów, typów wartości oraz długości ciągów znaków wprowadzanych przez użytkowników w poszczególnych formatkach a w szczególności powinien umożliwiać naukę formularzy, służących do logowania się użytkowników do aplikacji Web. 8) System powinien zagwarantować wysoki poziom ochrony serwerów Web oraz serwerów aplikacyjnych ( uwzględniając elementy XML oraz akcje SOAP) przed różnego typu atakami, a także powinien monitorować poprawne zachowanie chronionej aplikacji, a wszelkie próby wyjścia poza to poprawne zachowanie powinien blokować. Wymagane są sygnatury dla nie mniej niż : sieci, aplikacji Web, zapytań Web. 9) Monitorowanie i kontrolowanie w czasie rzeczywistym wszystkich operacji wykonywanych przez użytkowników. Rozwiązanie musi posiadać możliwość rejestrowania naruszeń bezpieczeństwa oraz udostępniać administratorom co najmniej następujące informacje o zdarzeniach: nazwa użytkownika aplikacyjnego (jeżeli klient zalogował się w systemie przez aplikację Web) , dodatkowe atrybuty użytkownika z zewnętrznych repozytoriów jak baza danych czy LDAP oraz zapytanie HTTP przesłane do serwera aplikacji Web. 10) Musi istnieć możliwość rejestrowania kodu źródłowego strony zwracanej klientowi przez aplikację Web, dostępnego bezpośrednio z interfejsu GUI serwera zarządzającego. 11) System powinien posiadać GUI dostępne przez przeglądarkę internetową w celu zoptymalizowania pracy, eliminacji konieczności instalacji dodatkowego oprogramowania na stacji administratora a także scentralizować zarządzanie całością rozwiązania. 12) Samoczynne uczenie się "normalnych" zachowań aplikacji umożliwiając przegląd zestawienia zachowań użytkowników z informacją o zagrożeniach. 13) Kontrolowanie dostępu do danych wrażliwych występujących w aplikacjach , które system ma chronić. 14) Przyśpieszenie procesów reagowania na incydenty naruszenia bezpieczeństwa oraz procesów śledczych dzięki zastosowaniu technik analitycznych. 15) Automatyczne uczenie się struktury danej aplikacji webowej oraz zachowań użytkowników, profil aplikacji Web musi być budowany w sposób automatyczny poprzez analizę ruchu sieciowego. Musi istnieć możliwość automatycznej aktualizacji profilu w przypadku wystąpienia zmiany w strukturze aplikacji. 16) System musi posiadać możliwość sprawdzenia, które z wykorzystywanych pól aplikacji są typu „read-only” i nie mogą być zmieniane przez klientów. 17) Wykrywanie ruchu sieciowego pochodzącego z potencjalnie niebezpiecznych źródeł w tym sieci TOR- ukrywania źródła ataku, szkodliwe adresy IP z których wielokrotnie zaatakowano inne strony Internetowe. 18) Tworzenie wirtualnych poprawek dla aplikacji poprzez integrację ze skanerem podatności. 19) Musi istnieć możliwość tworzenia własnych raportów, zarówno w formie tekstowej jak i reprezentacji graficznej bezpośrednio z centralnego serwera zarządzającego oraz możliwość cyklicznego wysyłania raportów wiadomością e-mail. Rozwiązanie musi posiadać funkcję wysyłania informacji o zdarzeniach: poprzez protokół SNMP. System musi posiadać możliwość wygenerowania gotowych raporty dotyczących: alarmów bezpieczeństwa, zdarzeń systemowych, zmian w profilach aplikacji, ostrzeżeń, ataków, prób włamań. 20) Tworzenie tzw. "białej listy" akceptowanych zachowań użytkownika (profilowanie chronionych aplikacji), nie może dodawać do profilu informacji pochodzących z przeprowadzanych ataków. 21) Automatyczne wykrywanie niepożądanych atrybutów, niezgodnych z protokołem HTTP. 22) System powinien analizować słabe punkty zgłaszane przynajmniej przez Bugtraq, CVE, Snort. 23) Powienien posiadać ochronę przed botami. 24) Umożliwiać zaimplementowanie CAPTCHA oraz posiadać możliwość wirtualnego "patchowania" aplikacji. 25) Powinien posiadać możliwość geolokalizacji adresów IP – położenie geograficzne będące źródłem ataków i blokady dostępu. 26) System w przypadku ataku powinien umożliwić: blokowanie pakietu oraz źródła ataku w postaci adresu IP, nazwy użytkownika lub sesji (jeżeli użytkownik uwierzytelnił się w systemie). 27) Musi istnieć możliwość uruchomienia skryptu shell w przypadku wykrycia incydentu. 28) Wykrywanie phishingowych adresów URL – fałszywe strony internetowe (adresy URL) używane podczas ataków phishingowych. 29) Wykrywanie adresów IP znanych, aktywnych spamerów, adresów atakujących (serwis reputacyjny, udostępniający listy niebezpiecznych adresów IP. 30) Wykryć adresy z których wykonywane są krytyczne incydenty SQL Injection oraz Remote File Inclusion, anonimowe proxy maskujące tożsamość użytkowników oraz adresy IP znane ze spamowania na forach internetowych. Baza adresów IP musi być pogrupowana według zagrożeń a także automatycznie aktualizowana. 31) Rozwiązanie musi posiadać reguły dotyczące identyfikacji incydentów typu web scraping poprzez zliczanie ilości odwołań do serwisu, oraz identyfikację ataków z sieci Bot dzięki wykorzystaniu skryptów java wykonywanych w przeglądarce klienta. 32) Ochrona przed atakami CSRF bez modyfikacji ruchu HTTP. 33) 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. 34) Powinien posiadać możliwość integracji z systemem SIEM (syslog) - ManageEngine Eventlog Analyzer. 35) Powinien posiadać możliwość zarządzania prawami użytkowników dla plików przechowywanych na serwerach oraz sieciowych pamięciach masowych nie ograniczając przy tym wydajności i dostępności serwera plików, sygnalizować lub blokować żądania dostępu naruszające politykę korporacyjną dotyczącą bezpieczeństwa plików. 36) System powinien posiadać możliwość rozwoju funkcjonalności o ochronę bazy danych. 37) Tworzenie wirtualnych poprawek dla aplikacji poprzez integrację ze skanerami podatności. 38) System powinien klasyfikować wagę, typ zagrożenia i oznaczać go np. kolorem (system powinien korzystać z bazy podatności, prób ataków producenta). W przypadku znanych ataków system powinien automatycznie blokować zagrożenie. |
Dodatkowe informacje
| Biuletyn | 2016 |
| Nazwa | Centrum Usług Informatycznych we Wrocławiu |
| Ulica | ul. Namysłowska |
| Nr domu | 8 |
| Miejscowosc | Wrocław |
| Kod poczt | 50304 |
| Wojewodztwo | dolnośląskie |
| Tel | 71 777 90 23 |
| Internet | bip.cui.wroclaw.pl |
| Adres strony url | htp://bip.cui.wroclaw.pl |
| Regon | 2228736100000 |
| E mail | piotr.schmidt@cui.wroclaw.pl |
| Czy obowiazkowa | Tak |
| Zamieszczanie obowiazkowe | Tak |
| Dotyczy | 1 |
| Rodzaj zam | administracja samorządowa |
| Czy zamieszczona bedzie specyfikacja | Tak |
| Zamieszczona bedzie specyfikacja | bip.cui.wroclaw.pl |
| Czy wymagane przeslanie ofert | Tak |
| Wymagane przeslanie ofert inny | Oferta pwinna być złożona w formie pisemnej pod rgorem niewazności |
| Czy podzielone na czesci | Nie |
| Dopuszczone wymagane przeslanie ofert adres | Sekcja Zamówień i Kontroli, CentrumUsług Informatycznych we Wrocławiu, ul.Namysłowska 8, IVp, 50-3024 Wrocław |
| Numer referencyjny | CUI/ZP/PN/18/2016 |
| Rodz zam | D |
| Okres2c | 31/10/2016 |
| Czy przewiduje udzielenie zamowien 67 | Nie |
| Czas | O |
| Czy zdolnosc techniczna wymaga wykonawcow | Nie |
| Czy zamawiajacy przewiduje wykluczenie | Nie |
| Czy oswiadczenie niepodleganiu wykluczenia | Tak |
| Wykaz dokumentow zaswiadczen | Nie dotyczy |
| Zakresie warunkow udzialu | Nie dotyczy |
| Zakresie kryteriow selekcji | Nie dotyczy |
| Inne dokumenty niewymienione | B) Wykonawcy wspólnie ubiegający się o udzielenie zamówienia (spółka cywilna, konsorcjum) 1. Wykonawcy mogą wspólnie ubiegać się o udzielenie zamówienia (spółka cywilna, konsorcjum) - art. 23 ust. 1 ustawy Pzp. W takim przypadku Wykonawcy ponoszą solidarną odpowiedzialność za wykonanie umowy. 2. W przypadku składania oferty przez Wykonawców wspólnie ubiegających się o udzielenie zamówienia, Wykonawcy ustanawiają pełnomocnika do reprezentowania ich w postępowaniu o udzielenie zamówienia albo reprezentowania w postępowaniu i zawarcia umowy w sprawie zamówienia publicznego, oraz załączają do oferty - pełnomocnictwo do reprezentowania Wykonawców w postępowaniu o udzielenie zamówienia albo reprezentowania w postępowaniu i zawarcia umowy w sprawie zamówienia publicznego. 3. W przypadku wspólnego ubiegania się o zamówienie przez Wykonawców, oświadczenia własne (w formie oryginału) składa każdy z Wykonawców wspólnie ubiegających się o zamówienie. Dokumenty te potwierdzają spełnianie warunków udziału w postępowaniu oraz brak podstaw wykluczenia w zakresie, w którym każdy z Wykonawców wykazuje spełnianie warunków udziału w postępowaniu oraz brak podstaw wykluczenia. 4. W przypadku Wykonawców wspólnie ubiegających się o udzielenie zamówienia kopie dokumentów dotyczące każdego z tych Wykonawców są poświadczane za zgodność z oryginałem przez tego Wykonawcę, którego dany dokument dotyczy, chyba że inny podmiot ustanowił do tych czynności pełnomocnika. C) Wykonawcę mającego siedzibę lub miejsce zamieszkania poza terytorium Rzeczypospolitej Polskiej Wykonawcę mającego siedzibę lub miejsce zamieszkania poza terytorium Rzeczypospolitej Polskiej obowiązują przepisy określone w Rozporządzeniu Ministra Rozwoju z dnia 26 lipca 2016r. w sprawie rodzajów dokumentów, jakich może żądać zamawiający od wykonawcy w postępowaniu o udzielenie zamówienia (Dz.U. z 2016r. poz. 1126). 1. Jeżeli Wykonawca ma siedzibę lub miejsce zamieszkania poza terytorium Rzeczypospolitej Polskiej, zamiast dokumentów: 1) informacji z Krajowego Rejestru Karnego, o której mowa w §5 pkt 1 Rozporządzenia - składa informację z odpowiedniego rejestru albo, w przypadku braku takiego rejestru, inny równoważny dokument wydany przez właściwy organ sądowy lub administracyjny kraju, w którym wykonawca ma siedzibę lub miejsce zamieszkania lub miejsce zamieszkania ma osoba, której dotyczy informacja albo dokument, w zakresie określonym w art. 24 ust. 1 pkt 13, 14 i 21 ustawy Pzp, dokument nie może byś wystawiony wcześniej niż na 6 miesięcy przed upływem terminu składania ofert, 2) zaświadczeń właściwego naczelnika urzędu skarbowego albo właściwej terytorialnie jednostki organizacyjnej ZUS lub KRUS - składa dokument lub dokumenty wystawione w kraju, w którym wykonawca ma siedzibę lub miejsce zamieszkania, potwierdzające odpowiednio, że nie zalega z opłacaniem podatków, opłat, składek na ubezpieczenie społeczne lub zdrowotne albo że zawarł porozumienie z właściwym organem w sprawie spłat tych należności wraz z ewentualnymi odsetkami lub grzywnami, w szczególności uzyskał przewidziane prawem zwolnienie, odroczenie lub rozłożenie na raty zaległych płatności lub wstrzymanie w całości wykonania decyzji właściwego organu, dokument nie może byś wystawiony wcześniej niż na 3 miesiące przed upływem terminu składania ofert. 2. Jeżeli w kraju, w którym wykonawca ma siedzibę lub miejsce zamieszkania lub miejsce zamieszkania ma osoba, której dokument dotyczy, nie wydaje się dokumentów, o których mowa w pkt 1, zastępuje się je dokumentem zawierającym odpowiednio oświadczenie wykonawcy, ze wskazaniem osoby albo osób uprawnionych do jego reprezentacji, lub oświadczenie osoby, której dokument miał dotyczyć, złożone przed notariuszem lub przed organem sądowym, administracyjnym albo organem samorządu zawodowego lub gospodarczego właściwym ze względu na siedzibę lub miejsce zamieszkania wykonawcy lub miejsce zamieszkania tej osoby. 3. Wykonawca mający siedzibę na terytorium Rzeczypospolitej Polskiej, w odniesieniu do osoby mającej miejsce zamieszkania poza terytorium Rzeczypospolitej Polskiej, której dotyczy dokument wskazany w § 5 pkt 1 Rozporządzenia, składa dokument, o którym mowa w § 7 ust. 1 pkt 1, w zakresie określonym w art. 24 ust. 1 pkt 14 i 21 ustawy Pzp. Jeżeli w kraju, w którym miejsce zamieszkania ma osoba, której dokument miał dotyczyć, nie wydaje się takich dokumentów, zastępuje się go dokumentem zawierającym oświadczenie tej osoby złożonym przed notariuszem lub przed organem sądowym, administracyjnym albo organem samorządu zawodowego lub gospodarczego właściwym ze względu na miejsce zamieszkania tej osoby. Przepis § 7 ust. 2 Rozporządzenia zdanie pierwsze stosuje się. D) Grupa kapitałowa Wykonawca, w terminie 3 dni od dnia zamieszczenia na stronie internetowej informacji, o której mowa w art. 86 ust. 5 ustawy Pzp, przekazuje Zamawiającemu oświadczenie o przynależności lub braku przynależności do tej samej grupy kapitałowej, o której mowa w ust. 1 pkt 23 ustawy Pzp. Wraz ze złożeniem oświadczenia, Wykonawca może przedstawić dowody, że powiązania z innym wykonawcą nie prowadzą do zakłócenia konkurencji w postępowaniu o udzielenie zamówienia (art. 24 ust. 11 ustawy Pzp). W przypadku, w którym Wykonawca nie złoży oświadczenia o przynależności lub braku przynależności do tej samej grupy kapitałowej, o której mowa w ust. 1 pkt 23 ustawy Pzp, Zamawiający wezwie do uzupełnienie tego dokumentu. Oświadczenie o przynależności lub braku przynależności do tej samej grupy kapitałowej, o której mowa w ust. 1 pkt 23 ustawy Pzp należy złożyć w formie oryginału. Nie złożenie oświadczenia o przynależności lub braku przynależności do tej samej grupy kapitałowej, o której mowa w ust. 1 pkt 23 ustawy Pzp, spowoduje wykluczenie Wykonawcy z postępowania. Stosowne oświadczenie Wykonawca może dołączyć do oferty. E) Procedura samooczyszczenia się Wykonawcy Wykonawca, który podlega wykluczeniu na podstawie art. 24 ust. 1 pkt 13 i 14 oraz 16-20 ustawy Pzp, może przedstawić dowody na to, że podjęte przez niego środki są wystarczające do wykazania jego rzetelności, w szczególności udowodnić naprawienie szkody wyrządzonej przestępstwem lub przestępstwem skarbowym, zadośćuczynienie pieniężne za doznaną krzywdę lub naprawienie szkody, wyczerpujące wyjaśnienie stanu faktycznego oraz współpracę z organami ścigania oraz podjęcie konkretnych środków technicznych, organizacyjnych i kadrowych, które są odpowiednie dla zapobiegania dalszym przestępstwom lub przestępstwom skarbowym lub nieprawidłowemu postępowaniu Wykonawcy. Procedury samooczyszczenia się Wykonawcy nie stosuje się, jeżeli wobec Wykonawcy, będącego podmiotem zbiorowym, orzeczono prawomocnym wyrokiem sądu zakaz ubiegania się o udzielenie zamówienia oraz nie upłynął określony w tym wyroku okres obowiązywania tego zakazu. Wykonawca nie podlega wykluczeniu, jeżeli Zamawiający, uwzględniając wagę i szczególne okoliczności czynu wykonawcy, uzna za wystarczające dowody o których mowa w zdaniu pierwszym powyżej. W przypadkach, o których mowa w art. 24 ust. 1 pkt 19 ustawy Pzp, przed wykluczeniem Wykonawcy, Zamawiający zapewnia temu Wykonawcy możliwość udowodnienia, że jego udział w przygotowaniu postępowania o udzielenie zamówienia nie zakłóci konkurencji. Wykonawca nie podlega wykluczeniu, jeżeli Zamawiający, uwzględniając wagę i szczególne okoliczności czynu wykonawcy, uzna za wystarczające dowody o których mowa w zdaniu pierwszym powyżej.W przypadkach, o których mowa w art. 24 ust. 1 pkt 19 ustawy Pzp, przed wykluczeniem Wykonawcy, Zamawiający zapewnia temu Wykonawcy możliwość udowodnienia, że jego udział w przygotowaniu postępowania o udzielenie zamówienia nie zakłóci konkurencji. |
| Wykaz potwierdzenie okolicznosci | Nie dotyczy |
| Czy wadium | Nie |
| Czy przewiduje udzielenie zaliczek | Nie |
| Czy dopuszcza zlozenie katalogow elektronicznych | Nie |
| Czy wymaga zlozenie katalogow elektronicznych | Nie |
| Czy wymaga zlozenie oferty wariantowej | Nie |
| Czy dopuszcza zlozenie oferty wariantowej | Nie |
| Czy dopuszcza zlozenie oferty wariantowej zasadniczej | Nie |
| Kod trybu | PN |
| Czy ograniczenie liczby uczestnikow | Nie |
| Czy obejmuje ustanowienie | Nie |
| Czy pobranie umowy ramowej dynamicznego katalogow | Nie |
| Czy umowy ramowej dynamicznego katalogow | Nie |
| Czy zmiana umowy | Tak |
| Zmiana umowy | Zamawiający dopuszcza możliwość zmiany umowy w sytuacjach, o których mowa w art. 144 ust. 1 ustawy Pzp, tzn: 1) Zamawiający dopuszcza możliwość zmiany umowy m.in. w następujących sytuacjach: zachodzi konieczność zmiany harmonogramu lub terminu końcowego wykonania przedmiotu zamówienia, w przypadku, gdy nie można było tego przewidzieć w chwili podpisania umowy; b) niezbędna jest zmiana sposobu wykonania zobowiązania, o ile zmiana taka jest korzystna dla Zamawiającego lub jest konieczna w celu prawidłowego wykonania umowy; c) jeżeli nastąpi zmiana powszechnie obowiązujących przepisów prawa w zakresie mającym wpływ na realizację przedmiotu zamówienia, a w szczególności w przypadku ustawowej zmiany podatku VAT; d) zachodzi konieczność zmiany w zakresie podwykonawstwa, za uprzednią zgodą zamawiającego: możliwe jest powierzenie podwykonawcom innego zakresu części zamówienia niż wskazany w ofercie Wykonawcy, a także możliwa jest zmiana podwykonawcy na etapie realizacji zamówienia, o ile nie jest to sprzeczne z postanowieniami SIWZ; e) możliwa jest korzystna dla Zamawiającego zmiana terminu i sposobu płatności za realizację przedmiotu zamówienia. 2) zmiany dotyczą realizacji dodatkowych zamówień od dotychczasowego Wykonawcy, nieobjętych zamówieniem podstawowym, o ile stały się niezbędne i zostały spełnione łącznie następujące warunki: a) zmiana Wykonawcy nie może zostać dokonana z powodów ekonomicznych lub technicznych, w szczególności dotyczących zamienności lub interoperacyjności sprzętu, usług lub instalacji, zamówionych w ramach zamówienia podstawowego, b) zmiana Wykonawcy spowodowałaby istotną niedogodność lub znaczne zwiększenie kosztów dla Zamawiającego, c) wartość każdej kolejnej zmiany nie przekracza 50% wartości zamówienia określonej pierwotnie w umowie; 3) zostały spełnione łącznie następujące warunki: a) konieczność zmiany umowy spowodowana jest okolicznościami, których Zamawiający, działając z należytą starannością, nie mógł przewidzieć, b) wartość zmiany nie przekracza 50% wartości zamówienia określonej pierwotnie w umowie; 4) Wykonawcę, któremu Zamawiający udzielił zamówienia, ma zastąpić nowy Wykonawca: a) w wyniku połączenia, podziału, przekształcenia, upadłości, restrukturyzacji lub nabycia dotychczasowego wykonawcy lub jego przedsiębiorstwa, o ile nowy wykonawca spełnia warunki udziału w postępowaniu, nie zachodzą wobec niego podstawy wykluczenia oraz nie pociąga to za sobą innych istotnych zmian umowy, b) w wyniku przejęcia przez Zamawiającego zobowiązań Wykonawcy względem jego podwykonawców; 5) zmiany, niezależnie od ich wartości, nie są istotne, 6) łączna wartość zmian jest mniejsza niż kwoty określone w przepisach wydanych na podstawie art. 11 ust. 8 i jest mniejsza od 10% wartości zamówienia określonej pierwotnie w umowie w przypadku zamówień na usługi lub dostawy albo, w przypadku zamówień na roboty budowlane - jest mniejsza od 15% wartości zamówienia określonej pierwotnie w umowie. Zmianą istotną postanowień umowy będzie zmiana, która: 1) zmienia ogólny charakter umowy, w stosunku do charakteru umowy lub umowy ramowej w pierwotnym brzmieniu; 2) nie zmienia ogólnego charakteru umowy i zachodzi co najmniej jedna z następujących okoliczności: a) zmiana wprowadza warunki, które, gdyby były postawione w postępowaniu o udzielenie zamówienia, to w tym postępowaniu wzięliby lub mogliby wziąć udział inni Wykonawcy lub przyjęto by oferty innej treści, b) zmiana narusza równowagę ekonomiczną umowy na korzyść Wykonawcy w sposób nieprzewidziany pierwotnie w umowie, c) zmiana znacznie rozszerza lub zmniejsza zakres świadczeń i zobowiązań wynikający z umowy, d) polega na zastąpieniu Wykonawcy, któremu Zamawiający udzielił zamówienia, nowym Wykonawcą, w przypadkach innych niż wymienione w pkt 4 powyżej. Przewidziane powyżej okoliczności stanowiące podstawę zmian do umowy, stanowią uprawnienie Zamawiającego nie zaś jego obowiązek wprowadzenia takich zmian. Wszelkie zmiany i uzupełnienia umowy wymagają formy pisemnej pod rygorem nieważności za zgodą obu stron. Wszelkie zmiany muszą być dokonywane z zachowaniem przepisu art. 140 ust. 1 i art. 140 ust. 3 ustawy Pzp stanowiącego, że umowa podlega unieważnieniu w części wykraczającej poza określenie przedmiotu zamówienia zawartego w SIWZ, z uwzględnieniem art. 144 ustawy Pzp. Ustala się, iż nie stanowi zmiany umowy w rozumieniu art. 144 ustawy Pzp: 1) zmiana nr rachunku bankowego, 2) zmiana danych teleadresowych. Zaistnienie okoliczności, o których mowa w niniejszym punkcie wymaga jedynie niezwłocznego pisemnego zawiadomienia drugiej Strony. |
| Kryt 0 | Cena |
| Kryt 0p | 60 |
| Czy aukcja | Nie |
| Data skl | 29/09/2016 |
| Godz skl | 09:45 |
| Termin | on |
| Okres liczba dni | 30 |
| Zastosowanie procedury pzp | Nie |
| IV 3 1 Przewidziane jest zastrzezenie | Nie |
| IV 3 1 Przewidziany podzial | Nie |
| IV 3 3 PodzialNegocjacji | Nie |
| IV 6 2 SkrocenieTerminu | Nie |
| IV 6 5 | Nie |
| Czy uniewaznienie | Tak |