Požadavky na Řízení přístupu. 1. Dodavatel bere na vědomí, že přístup k datům, informacím či zařízením souvisejícím s předmětem Dohody, resp. Objednávky je možné povolit pouze konkrétním fyzickým osobám / zaměstnancům Dodavatele / poddodavatele Dodavatele zaevidované, a to na základě požadavku Dodavatele na přístup. 2. Dodavatel bere na vědomí, že přidělení oprávnění zaměstnanci Dodavatele musí být řízeno zásadou tzv. „potřeba vědět“ (need-to-know principle) a není nárokové. 3. Dodavatel se zavazuje, že udělený přístup nesmí být sdílen více zaměstnanci Dodavatele nebo poddodavatele Dodavatele. 4. Dodavatel se zavazuje, že nebude instalovat a používat žádné nástroje, které nebyly předem písemně odsouhlaseny Zadavatelem. 5. Dodavatel se zavazuje, že nebude vyvíjet, kompilovat a šířit v jakékoliv části technologického nebo komunikačního systému programový kód, který má za cíl nelegální ovládnutí, narušení, nebo diskreditaci technologického nebo komunikačního systému nebo nelegální získání dat a informací. Dodavatel bere na vědomí, že přístup do interní sítě Zadavatele a/nebo k technologickým a komunikačním systémům Zadavatele bude realizován výhradně s využitím zařízení Zadavatele. 6. Dodavatel se zavazuje zajistit, aby osoby podílející se na poskytování plnění Zadavateli, kteří přistupují do interní sítě a/nebo technologického nebo komunikačního systému chránili autentizační prostředky a údaje k systémům Zadavateli. Dodavatel bere na vědomí, že v případě neúspěšných pokusů o autentizaci uživatele může být příslušný účet zablokován a řešen jako bezpečnostní incident ve smyslu příslušné řídící dokumentace a mohou být uplatněny příslušné postupy zvládání bezpečnostního incidentu (např. okamžité zrušení přístupu k informačním aktivům fyzických osob externího subjektu platí pro Dodavatele, pokud byl s takovou řídící dokumentací Zadavatele seznámen). 7. Dodavatel bere na vědomí, že postup zvládání bezpečnostního incidentu či skutečnosti vzniklé v důsledku porušení Bezpečnostních požadavků nebude posuzována jako okolnost vylučující odpovědnost Dodavatele za prodlení s řádným a včasným plněním předmětu Dohody, resp. Objednávky a nebude důvodem k jakékoli náhradě případné újmy Dodavateli či jiné osobě ze strany Dodavatele. Ostatní ustanovení ohledně odpovědnosti Dodavatele za prodlení obsažená v Dohodě nejsou tímto ustanovením dotčena.
Appears in 1 contract
Samples: Framework Agreement
Požadavky na Řízení přístupu. 1. a) Dodavatel bere na vědomí, že přístup k datům, informacím či zařízením souvisejícím s předmětem Dohody, resp. Objednávky Smlouvy je možné povolit pouze konkrétním fyzickým osobám / zaměstnancům fyzické identitě zaměstnance Dodavatele / poddodavatele Dodavatele zaevidovanézaevidované v registru Objednatele, a to na základě požadavku Dodavatele na přístup.
2. b) Dodavatel bere na vědomí, že přidělení oprávnění zaměstnanci Dodavatele musí být řízeno zásadou tzv. „potřeba vědět“ vědět (need-to-know principle) )“ a není nárokové.. 28 z 30
3. c) Dodavatel se zavazuje, že udělený přístup nesmí být sdílen více zaměstnanci Dodavatele nebo poddodavatele Dodavatele.
4. d) Dodavatel se zavazuje, že nebude instalovat a používat žádné nástroje, které nebyly předem písemně odsouhlaseny ZadavatelemObjednatelem a jejichž užívání by mohlo ohrozit kybernetickou bezpečnost.
5. e) Dodavatel se zavazuje, že nebude vyvíjet, kompilovat a šířit v jakékoliv části technologického nebo komunikačního systému programový kód, který má za cíl nelegální ovládnutí, narušení, nebo diskreditaci technologického nebo komunikačního systému nebo nelegální získání dat a informací. Dodavatel bere na vědomí, že přístup do interní sítě Zadavatele a/nebo k technologickým a komunikačním systémům Zadavatele bude realizován výhradně s z využitím zařízení ZadavateleObjednatele.
6. f) Dodavatel se zavazuje zajistit, aby osoby podílející se na poskytování plnění ZadavateliObjednateli, kteří přistupují do interní sítě a/nebo technologického nebo komunikačního systému chránili autentizační prostředky a údaje k systémům ZadavateliObjednatele. Dodavatel bere na vědomí, že v případě neúspěšných pokusů o autentizaci uživatele může být příslušný účet zablokován a řešen jako bezpečnostní incident ve smyslu příslušné řídící dokumentace a mohou být uplatněny příslušné postupy zvládání bezpečnostního incidentu (např. okamžité zrušení přístupu k informačním aktivům fyzických osob externího subjektu platí pro Dodavatele, pokud byl s takovou řídící dokumentací Zadavatele Objednatele seznámen).
7. g) Dodavatel bere na vědomí, že postup zvládání bezpečnostního incidentu či skutečnosti vzniklé skutečnost vzniklá v důsledku porušení Bezpečnostních požadavků nebude posuzována jako okolnost vylučující odpovědnost Dodavatele za prodlení s řádným a včasným plněním předmětu Dohody, resp. Objednávky Smlouvy a nebude důvodem k jakékoli náhradě případné újmy Dodavateli či jiné osobě ze strany DodavateleObjednatele. Ostatní ustanovení ohledně odpovědnosti Dodavatele za prodlení obsažená v Dohodě Smlouvě nejsou tímto ustanovením dotčena.
Appears in 1 contract
Samples: Kupní a Licenční Smlouva
Požadavky na Řízení přístupu. 1Všem uživatelům mohou být přidělena pouze taková oprávnění, která potřebují k vykonávání svých pracovních povinností. Dodavatel bere na vědomíPři přidělování uživatelských práv platí zásada „co není povoleno, že přístup k datůmje zakázáno“. Administrátor je oprávněn přidělit uživateli oprávnění, informacím či zařízením souvisejícím pokud jsou splněny tyto podmínky: ◼ přidělení uživatelského oprávnění bylo schváleno správcem IS v souladu s předmětem Dohodypřílohou č. 5 BPI MD, resp. Objednávky je možné povolit pouze konkrétním fyzickým osobám / zaměstnancům Dodavatele / poddodavatele Dodavatele zaevidované◼ nastavení umožňuje jednoznačné určení zodpovědnosti za prováděné operace, ◼ o přidělování a to na základě požadavku Dodavatele na přístup.
2. Dodavatel bere na vědomívyužívání přístupových práv jsou vedeny auditní záznamy (logy) v souladu s požadavky této přílohy BPI MD, že přidělení oprávnění zaměstnanci Dodavatele ◼ pokud jsou pro řízení přístupu použity biometrické prostředky, musí být řízeno zásadou tzvpoužity v souladu s platnou legislativou. Administrátoři jsou povinni alespoň 1x měsíčně kontrolovat přístupová oprávnění. Případné zjištěné „potřeba vědětnon-compliance“ (need-to-know principle) a není nárokové.
3. Dodavatel se zavazuje, že udělený přístup nesmí být sdílen více zaměstnanci Dodavatele nebo poddodavatele Dodavatele.
4. Dodavatel se zavazuje, že nebude instalovat a používat žádné nástroje, které nebyly předem písemně odsouhlaseny Zadavatelem.
5. Dodavatel se zavazuje, že nebude vyvíjet, kompilovat a šířit v jakékoliv části technologického nebo komunikačního systému programový kód, který má za cíl nelegální ovládnutí, narušení, nebo diskreditaci technologického nebo komunikačního systému nebo nelegální získání dat a informací. Dodavatel bere na vědomí, že přístup do interní sítě Zadavatele a/nebo k technologickým a komunikačním systémům Zadavatele bude realizován výhradně s využitím zařízení Zadavatele.
6. Dodavatel se zavazuje zajistit, aby osoby podílející se na poskytování plnění Zadavateli, kteří přistupují do interní sítě a/nebo technologického nebo komunikačního systému chránili autentizační prostředky a údaje k systémům Zadavateli. Dodavatel bere na vědomí, že v případě neúspěšných pokusů o autentizaci uživatele může být příslušný účet zablokován a řešen jako bezpečnostní incident ve smyslu příslušné řídící dokumentace a mohou být uplatněny příslušné postupy zvládání bezpečnostního incidentu stavy (např. okamžité existence účtu zaměstnance, který již na MD nepracuje) musí administrátoři neprodleně řešit. Součástí této kontroly musí být dále identifikace dlouhodobě nevyužívaných účtů (účet nebyl použit déle než 120 dní). Dlouhodobě nevyužívané standardní uživatelské účty musí být zrušeny, nebo dočasně zneplatněny. Možnost zrušení nebo potřebu ponechání aktivních dlouhodobě nevyužívaných technologických účtů musí administrátorovi odsouhlasit správce IS. Pro potřeby přístupů dodavatelů za účelem podpory nebo řešení problémů (neplatí pro externisty v rolích administrátorů systémů, na ty se vztahují stejné požadavky jako na zaměstnance MD ve stejných rolích) mohou být vytvořeny účty, pomocí kterých mohou zaměstnanci dodavatele přistupovat k systémům. Tyto účty musí splňovat požadavky uvedené v ČÁSTI IV, Kapitole 3 („Správa a řízení přístupu uživatelů“). Pokud je nutné vytvořit pro potřeby podpory účet, který bude sdílen více pracovníky jednoho dodavatele, musí takový účet splnit tyto podmínky: ◼ s dodavatelem je podepsána platná smlouva, ◼ jsou dodržena všechna ustanovení této přílohy BPI MD, ◼ účet je implicitně (defaultně) zablokován a odblokovává se pouze pro dobu nezbytnou k informačním aktivům fyzických osob externího subjektu platí vyžádanému zákroku, ◼ uživatelské účty nesmějí být sdíleny více dodavateli. Při konfiguraci systému musí administrátor nastavit politiku pro Dodavateleuživatelská hesla, která bude kontrolovat dodržování požadavků Vyhlášky o kybernetické bezpečnosti (Správa a ověřování identit). Pokud dojde k uzamčení účtu z důvodu velkého počtu neúspěšných přihlášení, musí být účet uzamčen minimálně 30 minut nebo do zásahu administrátora. Administrátor IS komunikujícího s Internetem a sdílejícího autentizaci s důvěryhodnými systémy ve vnitřní síti, které slouží mj. i pro autentizaci (např. AD), je povinen zajistit, že při dosažení nejvyššího povoleného počtu neúspěšných přihlášení bude pouze blokováno další přihlášení, nikoliv však uzamčení účtu na úrovni důvěryhodných autentizačních služeb ve vnitřní síti. Je povoleno použití stejných hesel k serverům patřícím ke stejné službě a zároveň zpracovávajícím informace stejné klasifikace. Hesla se nesmějí v systému vyskytovat v otevřené (nešifrované) podobě. Administrátoři jsou povinni používat pro šifrování hesel nejsilnější algoritmus, který je v distribuci systému dostupný, pokud byl s takovou řídící dokumentací Zadavatele seznámento negativně neovlivní chod systému, přičemž mohou využít i silnější algoritmy dodávané mimo standardní distribuci systému. Je-li to technicky možné, jsou administrátoři povinni umožnit (případně upřednostnit) silnou autentizaci – např. použití interních autentizačních služeb nebo jednorázových hesel zasílaných odděleným komunikačním kanálem. V případě použití jednorázového hesla, musí být toto heslo generováno off-line (nezávisle na komunikačním kanálu použitém k přihlašování) k tomu určeným zařízením, nebo musí být uživateli doručeno bezpečným kanálem fyzicky odděleným od komunikačního kanálu použitého k přihlašování a musí splňovat následující parametry: ◼ maximální doba platnosti OTP od jeho vydání nebo zaslání: 5 minut, nebo vyžádání nového OTP (co nastane dříve), ◼ minimální délka: 11 znaků (z množiny 0-9), nebo 7 znaků (z množiny a-z + 0-9).
7. Dodavatel bere na vědomí, že postup zvládání bezpečnostního incidentu či skutečnosti vzniklé v důsledku porušení Bezpečnostních požadavků nebude posuzována jako okolnost vylučující odpovědnost Dodavatele za prodlení s řádným a včasným plněním předmětu Dohody, resp. Objednávky a nebude důvodem k jakékoli náhradě případné újmy Dodavateli či jiné osobě ze strany Dodavatele. Ostatní ustanovení ohledně odpovědnosti Dodavatele za prodlení obsažená v Dohodě nejsou tímto ustanovením dotčena.
Appears in 1 contract
Samples: Smlouva O Poskytování Služeb
Požadavky na Řízení přístupu. 1. Dodavatel bere na vědomí, že přístup k datům, informacím či zařízením souvisejícím s předmětem Dohody, resp. Objednávky Smlouvy je možné povolit pouze konkrétním fyzickým osobám / zaměstnancům Dodavatele / poddodavatele Dodavatele zaevidované, a to na základě požadavku Dodavatele na přístup.
2. Dodavatel bere na vědomí, že přidělení oprávnění zaměstnanci Dodavatele musí být řízeno zásadou tzv. „potřeba vědět“ (need-to-know principle) a není nárokové.
3. Dodavatel se zavazuje, že udělený přístup nesmí být sdílen více zaměstnanci Dodavatele nebo poddodavatele Dodavatele.
4. Dodavatel se zavazuje, že nebude instalovat a používat žádné nástroje, které nebyly předem písemně odsouhlaseny Zadavatelem.
5. Dodavatel se zavazuje, že nebude vyvíjet, kompilovat a šířit v jakékoliv části technologického nebo komunikačního systému programový kód, který má za cíl nelegální ovládnutí, narušení, nebo diskreditaci technologického nebo komunikačního systému nebo nelegální získání dat a informací. Dodavatel bere na vědomí, že přístup do interní sítě Zadavatele a/nebo k technologickým a komunikačním systémům Zadavatele bude realizován výhradně s využitím zařízení Zadavatele.
6. Dodavatel se zavazuje zajistit, aby osoby podílející se na poskytování plnění Zadavateli, kteří přistupují do interní sítě a/nebo technologického nebo komunikačního systému chránili autentizační prostředky a údaje k systémům Zadavateli. Dodavatel bere na vědomí, že v případě neúspěšných pokusů o autentizaci uživatele může být příslušný účet zablokován a řešen jako bezpečnostní incident ve smyslu příslušné řídící dokumentace a mohou být uplatněny příslušné postupy zvládání bezpečnostního incidentu (např. okamžité zrušení přístupu k informačním aktivům fyzických osob externího subjektu platí pro Dodavatele, pokud byl s takovou řídící dokumentací Zadavatele seznámen).
7. Dodavatel bere na vědomí, že postup zvládání bezpečnostního incidentu či skutečnosti vzniklé v důsledku porušení Bezpečnostních požadavků nebude posuzována jako okolnost vylučující odpovědnost Dodavatele za prodlení s řádným a včasným plněním předmětu Dohody, resp. Objednávky Smlouvy a nebude důvodem k jakékoli náhradě případné újmy Dodavateli či jiné osobě ze strany Dodavatele. Ostatní ustanovení ohledně odpovědnosti Dodavatele za prodlení obsažená v Dohodě Smlouvě nejsou tímto ustanovením dotčena.
Appears in 1 contract
Samples: Rámcová Dohoda