Bezpečnosť služieb a rozdelenie zodpovednosti

Článok 1

Predmet a účel dokumentu

1. Tento dokument „Bezpečnosť služieb a rozdelenie zodpovednosti“ (ďalej len „Podmienky“) upravuje základné bezpečnostné princípy služieb poskytovaných spoločnosťou WebHouse, s.r.o. (ďalej len „WebHouse“ alebo „Poskytovateľ“) a rozdelenie zodpovednosti medzi Poskytovateľa a Zákazníka.
2. Účelom Podmienok je najmä:
   • vymedziť bezpečnostné povinnosti Poskytovateľa,
   • vymedziť bezpečnostné povinnosti Zákazníka,
   • určiť hranicu medzi infraštruktúrou Poskytovateľa a prostredím spravovaným Zákazníkom,
   • určiť základné pravidlá pri bezpečnostných incidentoch,
   • stanoviť podmienky bezpečnostných zásahov Poskytovateľa,
   • vysvetliť rozdiely medzi bezpečnosťou jednotlivých typov služieb,
   • predchádzať nesprávnemu predpokladu, že poskytovanie hostingovej alebo serverovej služby znamená automatické prevzatie správy a zabezpečenia aplikácií, dát alebo systémov Zákazníka.
3. Tieto Podmienky dopĺňajú najmä:
   • Všeobecné obchodné podmienky,
   • Reklamačný poriadok,
   • Rozsah a podmienky technickej podpory,
   • Ochranu infraštruktúry a siete,
   • Pravidlá férového používania, zneužitia služieb a incidentov,
   • SLA – Garanciu dostupnosti služieb,
   • Pravidlá zálohovania, uchovávania a obnovy dát,
   • Podmienky spracúvania osobných údajov – DPA,
   • osobitné podmienky jednotlivých služieb.

Článok 2

Základný princíp rozdelenia zodpovednosti

1. Bezpečnosť poskytovanej služby je výsledkom bezpečnostných opatrení Poskytovateľa aj Zákazníka.
2. Poskytovateľ zodpovedá za bezpečnosť systémov, infraštruktúry a komponentov, ktoré podľa charakteru objednanej služby spravuje Poskytovateľ.
3. Zákazník zodpovedá za bezpečnosť systémov, aplikácií, účtov, hesiel, dát, konfigurácie a softvéru, ktoré spravuje alebo ovláda Zákazník.
4. Rozsah zodpovednosti Poskytovateľa závisí od typu objednanej služby a od rozsahu technickej správy, ktorú pri tejto službe výslovne prevzal.
5. Pri posudzovaní bezpečnostného incidentu je rozhodujúce najmä to, v ktorej technickej vrstve vznikla jeho príčina a ktorá strana túto vrstvu spravovala.
6. Skutočnosť, že sa následok bezpečnostného incidentu prejaví v službe Poskytovateľa, sama osebe neznamená, že príčina incidentu vznikla v infraštruktúre Poskytovateľa.
7. Rovnako skutočnosť, že incident vznikol v aplikácii alebo účte Zákazníka, nevylučuje zodpovednosť Poskytovateľa za prípadnú samostatnú chybu alebo zraniteľnosť v technickej vrstve, ktorú spravoval Poskytovateľ.
8. Čím väčší rozsah administrátorských oprávnení a kontroly má Zákazník nad konkrétnou službou, tým väčší rozsah bezpečnostnej zodpovednosti spravidla nesie za túto vrstvu.
9. Samotná existencia administrátorského alebo technického prístupu Poskytovateľa k určitému systému neznamená, že Poskytovateľ prevzal jeho správu, bezpečnostný dohľad alebo zodpovednosť za jeho konfiguráciu.
10. Poskytovanie technickej infraštruktúry samo osebe neznamená, že Poskytovateľ preberá správu, bezpečnostný dohľad alebo zodpovednosť za všetok softvér, aplikácie, účty a obsah prevádzkovaný prostredníctvom tejto infraštruktúry.
11. Ak Zákazník prevádzkuje na infraštruktúre Poskytovateľa vlastnú webovú stránku, CMS, aplikáciu, plugin, modul, skript alebo iný softvér, ich umiestnenie na infraštruktúre Poskytovateľa samo osebe nepresúva ich bezpečnostnú správu na Poskytovateľa.
12. Použitie primeraných alebo odporúčaných bezpečnostných opatrení Zákazníkom samo osebe nepresúva zodpovednosť za Zákazníkom spravovanú technickú vrstvu na Poskytovateľa.
13. Ak však Poskytovateľ v rámci managed alebo inej osobitnej služby výslovne prevezme správu konkrétnej technickej vrstvy, zodpovedá za jej bezpečnosť v rozsahu tejto dohodnutej správy.
14. Jednorazová technická pomoc, konzultácia alebo zásah Poskytovateľa do vrstvy spravovanej Zákazníkom neznamená automaticky prevzatie jej ďalšej správy alebo bezpečnostnej zodpovednosti.
15. Všeobecné ustanovenia o zodpovednosti Zákazníka nemožno použiť na vylúčenie zodpovednosti Poskytovateľa za bezpečnosť technickej vrstvy alebo povinnosti, ktorú Poskytovateľ podľa objednanej služby výslovne prevzal.

Článok 3

Vrstvy bezpečnosti

1. Na účely určenia bezpečnostnej zodpovednosti možno poskytovanú službu rozdeliť na jednotlivé technické a prevádzkové vrstvy.

2. Medzi tieto vrstvy patria najmä:

   a) fyzická infraštruktúra,

   b) priestory dátového centra,

   c) fyzická ochrana a kontrola prístupu,

   d) napájanie, záložné napájanie a súvisiaca technická infraštruktúra,

   e) sieťová infraštruktúra,

   f) fyzické servery a úložiská,

   g) virtualizačná platforma,

   h) operačný systém,

   i) systémové služby a systémový softvér,

   j) webový, databázový, e-mailový alebo iný serverový softvér,

   k) hostingová alebo administračná platforma,

   l) používateľské a administrátorské účty,

   m) aplikácie Zákazníka,

   n) CMS, pluginy, moduly, témy a ďalšie aplikačné komponenty,

   o) vlastný alebo upravený zdrojový kód,

   p) databázová štruktúra a aplikačná logika,

   q) databázový obsah,

   r) používateľské heslá, autentifikačné údaje, API kľúče, tokeny a privátne kľúče,

   s) obsah, súbory a ostatné dáta Zákazníka,

   t) zariadenia Zákazníka,

   u) lokálne siete, routery, firewally a ďalšia infraštruktúra Zákazníka,

   v) externé služby a systémy tretích strán.

3. Uvedené členenie je orientačné a jednotlivé vrstvy sa môžu podľa použitej technológie prekrývať, spájať alebo ďalej deliť.
4. Rozhodujúce nie je formálne označenie vrstvy, ale to, kto má podľa konkrétnej služby jej správu, kontrolu a možnosť vykonávať bezpečnostné opatrenia.
5. Zodpovednosť za jednotlivé vrstvy sa určuje podľa typu objednanej služby a rozsahu jej správy.
6. Pri zdieľanom webhostingu spravuje Poskytovateľ spravidla širšiu časť serverovej a hostingovej infraštruktúry, zatiaľ čo Zákazník spravuje najmä svoje aplikácie, účty, obsah a aplikačnú konfiguráciu.
7. Pri nespravovanom virtuálnom alebo dedikovanom serveri môže byť operačný systém, systémové služby, firewall, serverový softvér a aplikácie v správe Zákazníka.
8. Pri managed službe môže Poskytovateľ prevziať správu niektorých vrstiev, ktoré by pri nespravovanej službe inak spravoval Zákazník.
9. Rozsah managed služby sa vždy určuje podľa konkrétne dohodnutých komponentov; samotné označenie služby ako „managed“ neznamená automatickú správu všetkých technických vrstiev.
10. Ak určitú vrstvu spravuje Poskytovateľ, Zákazník nenesie bezpečnostnú zodpovednosť za jej odbornú správu iba preto, že ju používa.
11. Ak určitú vrstvu spravuje Zákazník, samotná skutočnosť, že sa nachádza na infraštruktúre Poskytovateľa, nepresúva jej bezpečnostnú správu na Poskytovateľa.
12. Technická možnosť Poskytovateľa pristúpiť k určitej vrstve alebo do nej vykonať zásah sama osebe neznamená, že túto vrstvu spravuje.
13. Rovnako technická možnosť Zákazníka ovplyvniť určitý parameter nemusí sama osebe znamenať, že preberá správu celej technickej vrstvy Poskytovateľa.
14. Pri bezpečnostnom incidente môže jeho príčina vzniknúť v jednej vrstve a následok sa prejaviť v inej vrstve.
15. Napríklad kompromitácia CMS môže viesť k rozosielaniu e-mailov, zmene databázy alebo poškodeniu súborov, hoci samotná serverová infraštruktúra Poskytovateľa nebola kompromitovaná.
16. Naopak, bezpečnostná chyba v infraštruktúrnej vrstve môže mať následok aj v aplikácii alebo dátach Zákazníka.
17. Pri určovaní zodpovednosti sa preto posudzuje predovšetkým technická príčina incidentu, nie iba miesto, kde sa incident prejavil.
18. Ak sa na vzniku alebo rozsahu incidentu podieľalo viac vrstiev, zodpovednosť jednotlivých strán sa posudzuje podľa ich konkrétnych povinností vo vzťahu k týmto vrstvám.
19. Jednorazový zásah jednej strany do vrstvy spravovanej druhou stranou automaticky nemení dlhodobé rozdelenie zodpovednosti.
20. Konkrétne podmienky služby alebo individuálna dohoda majú pri určení správy jednotlivých vrstiev prednosť pred týmto všeobecným členením.

Článok 4

Zodpovednosť Poskytovateľa

1. Poskytovateľ v rozsahu konkrétnej služby zodpovedá za primerané zabezpečenie technickej infraštruktúry a komponentov, ktoré spravuje.
2. Rozsah bezpečnostnej zodpovednosti Poskytovateľa sa určuje podľa typu objednanej služby a rozsahu správy, ktorú pri tejto službe prevzal.
3. Poskytovateľ zodpovedá najmä za správu a bezpečnostnú údržbu systémových komponentov, ktoré sú súčasťou jeho spravovanej vrstvy.
4. To zahŕňa primeranú inštaláciu bezpečnostných aktualizácií a opráv systémového softvéru, ktorý spravuje Poskytovateľ, s prihliadnutím na ich závažnosť, dostupnosť, kompatibilitu a prevádzkové riziká.
5. Poskytovateľ zodpovedá za primerané riadenie administrátorských oprávnení svojich pracovníkov a ďalších osôb, ktorým umožní administratívny prístup k svojej infraštruktúre.
6. Administrátorský prístup má byť poskytovaný v rozsahu potrebnom na výkon príslušnej činnosti a primerane chránený proti neoprávnenému použitiu.
7. Poskytovateľ zodpovedá za primerané monitorovanie kritických komponentov svojej infraštruktúry podľa charakteru a parametrov poskytovanej služby.
8. Monitoring nemusí znamenať nepretržité sledovanie každej zákazníckej aplikácie, procesu alebo udalosti, pokiaľ takýto monitoring nie je výslovne súčasťou služby.
9. Poskytovateľ zodpovedá za primerané zabezpečenie siete a sieťových komponentov, ktoré má pod svojou správou.
10. To môže zahŕňať najmä primerané používanie firewallov, filtrov, segmentácie, obmedzenia administratívneho prístupu a ďalších ochranných mechanizmov podľa charakteru infraštruktúry.
11. Poskytovateľ zodpovedá za primerané technické oddelenie zákazníckych prostredí tam, kde povaha služby predpokladá zdieľanie spoločnej infraštruktúry.
12. Bezpečnostné opatrenia majú primerane zabraňovať tomu, aby Zákazník získal neoprávnený prístup k dátam, účtom alebo technickému prostrediu iného zákazníka.
13. Poskytovateľ zodpovedá za riešenie bezpečnostných incidentov, ktorých príčina alebo podstatná časť vznikla v technickej vrstve spravovanej Poskytovateľom.
14. Pri bezpečnostnom incidente môže Poskytovateľ vykonať primerané opatrenia potrebné na:

• zastavenie alebo obmedzenie incidentu,
• ochranu infraštruktúry,
• ochranu ostatných zákazníkov,
• obmedzenie ďalšieho šírenia škodlivej aktivity,
• alebo obnovenie bezpečnej prevádzky.

15. Poskytovateľ môže primerané ochranné opatrenie vykonať aj pred úplným určením príčiny incidentu, ak by odklad mohol viesť k ďalšej škode alebo ohrozeniu infraštruktúry.
16. Poskytovateľ zodpovedá za fyzickú bezpečnosť infraštruktúry v rozsahu, v akom ju má pod svojou kontrolou alebo ju zabezpečuje v rámci poskytovanej služby.
17. Ak určitú časť fyzickej alebo technickej infraštruktúry zabezpečuje externý dodávateľ Poskytovateľa ako súčasť služby poskytovanej Zákazníkovi, samotné využitie takéhoto dodávateľa nemení rozsah povinností, ktoré Poskytovateľ voči Zákazníkovi výslovne prevzal.
18. Poskytovateľ zodpovedá za primeranú ochranu autentifikačných, administrátorských a iných bezpečnostne citlivých údajov, ktoré spravuje vo vlastných systémoch.
19. Poskytovateľ zodpovedá za primerané nastavenie a údržbu bezpečnostných mechanizmov, ktoré sú deklarovanou súčasťou konkrétnej služby.
20. Ak Poskytovateľ pri konkrétnej managed službe výslovne prevezme správu operačného systému, firewallu, serverového softvéru, aplikácie alebo inej vrstvy, jeho bezpečnostná zodpovednosť sa rozširuje na túto vrstvu v rozsahu dohodnutej správy.
21. Poskytovateľ nezodpovedá za absolútne zabránenie každému bezpečnostnému incidentu; zodpovedá za plnenie svojich bezpečnostných povinností v rozsahu konkrétnej služby.
22. Samotný vznik bezpečnostného incidentu preto automaticky nepreukazuje porušenie povinnosti Poskytovateľa.
23. Ak však incident vznikol v dôsledku nedostatočného zabezpečenia, nesprávnej konfigurácie, zanedbanej správy alebo iného pochybenia v technickej vrstve, ktorú mal spravovať Poskytovateľ, zodpovednosť sa posudzuje podľa tejto skutočnej príčiny.
24. Všeobecné ustanovenia o zodpovednosti Zákazníka nemožno použiť na vylúčenie zodpovednosti Poskytovateľa za bezpečnostné povinnosti, ktoré podľa konkrétnej služby výslovne prevzal.
25. Konkrétne bezpečnostné parametre, managed rozsah alebo individuálne dohodnuté povinnosti majú pred týmto všeobecným ustanovením prednosť.

Článok 5

Zodpovednosť Zákazníka

1. Zákazník zodpovedá za bezpečnosť všetkých technických vrstiev, aplikácií, účtov, konfigurácií, dát a zariadení, ktoré podľa charakteru objednanej služby spravuje alebo ovláda.
2. Zákazník zodpovedá najmä za výber, nasadenie a používanie svojich aplikácií, CMS systémov, pluginov, tém, modulov, frameworkov a ďalšieho softvéru.
3. Zákazník zodpovedá za primeranú aktualizáciu softvéru, ktorý spravuje, najmä za inštaláciu bezpečnostných aktualizácií CMS, pluginov, tém, knižníc, frameworkov a vlastných aplikácií.
4. Zákazník zodpovedá za bezpečnosť vlastného alebo ním upraveného zdrojového kódu a za odstránenie známych zraniteľností v tomto kóde.
5. Zákazník zodpovedá za bezpečnostnú konfiguráciu aplikácií a systémov, ktorých správu neprevzal Poskytovateľ.
6. Zákazník zodpovedá za správu používateľských a administrátorských účtov vo svojej spravovanej vrstve, najmä za:

• vytváranie účtov,
• prideľovanie primeraných oprávnení,
• pravidelnú kontrolu účtov,
• a rušenie účtov, ktoré už nie sú potrebné.

7. Zákazník zodpovedá za bezpečnosť svojich hesiel, autentifikačných údajov, API kľúčov, tokenov, privátnych kľúčov a ďalších prístupových údajov.
8. Zákazník je povinný primerane chrániť prístupové údaje pred sprístupnením neoprávneným osobám.
9. Zákazník zodpovedá za správu FTP, SFTP, SSH, databázových, aplikačných a ostatných prístupov, ktoré má vo svojej správe.
10. Zákazník zodpovedá za odobratie alebo zmenu prístupov bývalým zamestnancom, externým spolupracovníkom, vývojárom alebo iným osobám, ktoré už nemajú mať prístup k službe alebo dátam.
11. Ak má Zákazník dôvodné podozrenie na kompromitáciu hesla, kľúča alebo iného autentifikačného údaja, je povinný primerane reagovať, najmä jeho zmenou, zneplatnením alebo odobratím.
12. Zákazník zodpovedá za používanie primeraných bezpečnostných mechanizmov dostupných v rámci služby, ak ich použitie patrí do jeho správy.
13. Môže ísť najmä o:

• viacfaktorovú autentifikáciu,
• obmedzenie administrátorských účtov,
• bezpečné heslá,
• správu oprávnení,
• bezpečnostné nastavenia aplikácie,
• alebo iné primerané ochranné mechanizmy.

14. Zákazník zodpovedá za bezpečnosť aplikácií a komponentov tretích strán, ktoré si sám vybral, nainštaloval alebo používa vo svojej spravovanej vrstve.
15. Samotná dostupnosť pluginu, aplikácie alebo iného softvéru na infraštruktúre Poskytovateľa neznamená, že Poskytovateľ preveril jeho bezpečnosť alebo prevzal jeho správu.
16. Zákazník zodpovedá za bezpečnosť svojich koncových zariadení, najmä počítačov, mobilných zariadení a ďalších systémov, z ktorých pristupuje k službám Poskytovateľa.
17. Zákazník zodpovedá za primerané zabezpečenie svojej lokálnej siete, routerov, firewallov, Wi-Fi a ďalších sieťových prvkov, ktoré spravuje.
18. Ak dôjde ku kompromitácii prístupových údajov prostredníctvom zariadenia, siete alebo systému Zákazníka, samotná skutočnosť, že tieto údaje následne umožnili prístup k službe Poskytovateľa, neznamená, že bezpečnostná chyba vznikla v infraštruktúre Poskytovateľa.
19. Zákazník zodpovedá za správnosť bezpečnostne významnej konfigurácie, ktorú vykoná sám alebo prostredníctvom osoby konajúcej v jeho mene.
20. Zákazník zodpovedá za zákonnosť a primeranú ochranu dát, ktoré prostredníctvom služby spracúva, v rozsahu povinností, ktoré podľa právnych predpisov alebo zmluvy patria Zákazníkovi.
21. Zákazník je povinný primerane reagovať na bezpečnostné upozornenia týkajúce sa jeho spravovanej vrstvy, najmä ak Poskytovateľ upozorní na zraniteľný softvér, kompromitovaný účet alebo zistenú škodlivú aktivitu.
22. Poskytnutie bezpečnostného odporúčania, technickej rady alebo jednorazového zásahu Poskytovateľom nepresúva správu príslušnej aplikácie, účtu, zariadenia alebo konfigurácie na Poskytovateľa.
23. Skutočnosť, že Zákazník používa primerané alebo odporúčané bezpečnostné opatrenia, sama osebe neznamená, že Poskytovateľ preberá zodpovednosť za zákazníkom spravovanú technickú vrstvu.
24. Ak však konkrétnu technickú vrstvu alebo bezpečnostnú činnosť výslovne spravuje Poskytovateľ v rámci objednanej služby, zodpovednosť Zákazníka sa v tomto rozsahu primerane neuplatní.
25. Zodpovednosť Zákazníka podľa tohto článku nemožno vykladať tak, že vylučuje zodpovednosť Poskytovateľa za bezpečnostnú chybu alebo nesplnenú povinnosť v technickej vrstve, ktorú mal podľa objednanej služby spravovať Poskytovateľ.

Článok 6

Zdieľaný webhosting

6.1 Zodpovednosť WebHouse

1. Pri zdieľanom webhostingu WebHouse spravidla spravuje najmä:

• fyzickú serverovú infraštruktúru,
• operačný systém servera,
• webový server,
• podporované verzie PHP,
• databázový server,
• hostingovú platformu,
• základné sieťové zabezpečenie,
• oddelenie jednotlivých hostingových účtov,
• systémový softvér poskytovaný ako súčasť platformy.

2. WebHouse zabezpečuje primeranú údržbu, bezpečnostnú správu a aktualizáciu týchto komponentov v rozsahu svojej správy.
3. WebHouse zodpovedá za primerané nastavenie bezpečnostných mechanizmov spoločnej hostingovej platformy a za primerané technické oddelenie jednotlivých zákazníckych účtov.
4. WebHouse zodpovedá za riešenie bezpečnostných chýb a incidentov, ktorých príčina vznikla v ním spravovanej hostingovej, systémovej alebo infraštruktúrnej vrstve.
5. Ak sa bezpečnostný incident prejaví v aplikácii Zákazníka, WebHouse môže preveriť, či jeho príčina nesúvisí s technickou vrstvou spravovanou WebHouse.
6. Samotná kompromitácia jednej webovej stránky alebo jedného hostingového účtu neznamená automaticky kompromitáciu fyzického servera, operačného systému alebo hostingovej platformy WebHouse.
7. Rovnako samotná existencia škodlivého súboru v hostingovom účte nepreukazuje bezpečnostnú chybu infraštruktúry WebHouse.
8. Ak však kompromitácia zákazníckych dát vznikla v dôsledku nedostatočného oddelenia hostingových účtov, chyby systémového softvéru alebo inej bezpečnostnej chyby v spravovanej vrstve WebHouse, zodpovednosť sa posudzuje podľa tejto skutočnej príčiny.
9. WebHouse môže na ochranu spoločnej infraštruktúry uplatňovať bezpečnostné mechanizmy, obmedzenia a filtre primerané charakteru zdieľanej služby.
10. Tieto mechanizmy nemusia predstavovať úplnú ochranu zákazníckej aplikácie pred každým spôsobom napadnutia.

6.2 Zodpovednosť Zákazníka

11. Zákazník zodpovedá za obsah a bezpečnosť dát a aplikácií uložených v jeho hostingovom účte, pokiaľ ich správu výslovne neprevzal WebHouse.
12. Zákazník zodpovedá najmä za:

• súbory uložené v hostingovom účte,
• webové aplikácie,
• CMS,
• WordPress,
• Joomla,
• Drupal,
• PrestaShop,
• Magento,
• pluginy,
• moduly,
• témy,
• vlastné PHP aplikácie,
• JavaScript aplikácie,
• databázové aplikácie,
• konfiguráciu .htaccess,
• aplikačné heslá,
• FTP alebo SFTP účty,
• databázové heslá,
• používateľské účty administrácie webu,
• a ďalšie aplikačné alebo prístupové údaje vo svojej správe.

13. Zákazník zodpovedá za primeranú aktualizáciu a zabezpečenie svojich aplikácií.
14. To zahŕňa najmä pravidelnú inštaláciu bezpečnostných aktualizácií CMS, pluginov, tém, modulov a ďalších aplikačných komponentov.
15. Zákazník zodpovedá za odstránenie alebo deaktiváciu nepoužívaného, zastaraného alebo zraniteľného softvéru vo svojom hostingovom účte.
16. Zákazník zodpovedá za bezpečnosť používateľských a administrátorských účtov svojich aplikácií a za primeranú ochranu hesiel a autentifikačných údajov.
17. Zákazník zodpovedá za bezpečnosť vlastného zdrojového kódu a konfigurácie aplikácie.
18. Ak Zákazník alebo tretia osoba konajúca v jeho mene zmení .htaccess, konfiguráciu aplikácie, prístupové oprávnenia alebo iný parameter zákazníckej vrstvy, zodpovedá za bezpečnostné následky tejto zmeny v rozsahu svojej správy.
19. Zákazník zodpovedá za aplikácie a komponenty tretích strán, ktoré si sám nainštaluje alebo používa.
20. Skutočnosť, že WordPress, plugin, téma alebo iný softvér je možné na hostingu WebHouse prevádzkovať, neznamená, že WebHouse prevzal jeho bezpečnostnú správu alebo garantuje jeho bezchybnosť.
21. Použitie aktualizovaného CMS, bezpečnostného pluginu, silných hesiel alebo iných odporúčaných opatrení samo osebe nepresúva bezpečnostnú zodpovednosť za zákaznícku aplikačnú vrstvu na WebHouse.
22. Ak dôjde ku kompromitácii zákazníckej aplikácie prostredníctvom zraniteľného CMS, pluginu, témy, hesla, účtu alebo vlastného zdrojového kódu, samotná skutočnosť, že aplikácia bola prevádzkovaná na hostingu WebHouse, neznamená zodpovednosť WebHouse za vznik incidentu.
23. Ak bezpečnostný incident vznikne kombináciou chyby zákazníckej aplikácie a chyby v spravovanej vrstve WebHouse, zodpovednosť sa posudzuje podľa skutočného podielu a charakteru jednotlivých príčin.
24. Jednorazová pomoc WebHouse pri diagnostike, čistení, obnove alebo zabezpečení zákazníckej aplikácie neznamená prevzatie jej ďalšej bezpečnostnej správy.
25. Ak konkrétna služba výslovne zahŕňa rozšírenú správu aplikácie, bezpečnostný dohľad alebo inú managed činnosť, zodpovednosť sa v tomto rozsahu riadi podmienkami tejto služby.

Článok 7

WordPress a iné CMS

1. WebHouse poskytovaním webhostingu nepreberá správu WordPressu alebo iného CMS Zákazníka.
2. Ak nie je objednaná samostatná služba správy aplikácie, Zákazník zodpovedá najmä za:
   • aktualizáciu jadra CMS,
   • aktualizáciu pluginov,
   • aktualizáciu tém,
   • odstránenie nepoužívaných pluginov,
   • odstránenie nepoužívaných tém,
   • bezpečnú konfiguráciu administrácie,
   • správu používateľov a ich oprávnení,
   • zabezpečenie prihlasovania,
   • ochranu administrátorských účtov,
   • sledovanie bezpečnostných upozornení výrobcov alebo autorov používaného softvéru.
3. Zákazník zodpovedá aj za výber pluginov, tém a ďalších rozšírení, ktoré do CMS nainštaluje alebo používa.
4. Skutočnosť, že určitý plugin, téma alebo CMS možno technicky prevádzkovať na hostingu WebHouse, neznamená, že WebHouse preveril jeho bezpečnosť, kvalitu alebo vhodnosť.
5. Zákazník by nemal používať softvér, ktorý je zastaraný, dlhodobo neudržiavaný alebo obsahuje známu neodstránenú bezpečnostnú zraniteľnosť.
6. Inštalácia bezpečnostného pluginu alebo iného bezpečnostného nástroja nezaručuje, že aplikácia nebude kompromitovaná.

7. Rovnako ani používanie:

   • aktuálneho PHP,
   • aktuálneho CMS,
   • aktualizovaných pluginov a tém,
   • silného hesla,
   • viacfaktorovej autentifikácie,
   • firewallového pluginu,
   • antivírusového alebo antimalvérového pluginu,
   • obmedzenia počtu pokusov o prihlásenie

   samo osebe nezaručuje absolútnu ochranu aplikácie pred bezpečnostným incidentom.

8. Použitie primeraných alebo odporúčaných bezpečnostných opatrení samo osebe nepresúva zodpovednosť za bezpečnostnú správu CMS alebo jeho komponentov na WebHouse.
9. Bezpečnostný incident môže vzniknúť aj prostredníctvom:
   • doposiaľ neznámej zraniteľnosti,
   • zraniteľného pluginu alebo témy,
   • kompromitovaného administrátorského účtu,
   • odcudzeného hesla alebo tokenu,
   • škodlivého alebo kompromitovaného rozšírenia,
   • chyby vo vlastnom zdrojovom kóde,
   • alebo inej súčasti aplikačnej vrstvy.
10. Samotná kompromitácia WordPressu alebo iného CMS nepreukazuje kompromitáciu servera alebo hostingovej platformy WebHouse.
11. Rovnako nález škodlivého kódu, backdooru alebo zmenených súborov v zákazníckej aplikácii sám osebe nepreukazuje bezpečnostnú chybu infraštruktúry WebHouse.
12. Pri posudzovaní incidentu je rozhodujúca jeho skutočná technická príčina a vrstva, v ktorej vznikla.
13. Ak bola príčinou kompromitácie zraniteľnosť CMS, pluginu, témy, účtu, hesla alebo inej Zákazníkom spravovanej súčasti, zodpovednosť za túto vrstvu nesie Zákazník.
14. Ak však incident vznikol v dôsledku bezpečnostnej chyby v hostingovej alebo systémovej vrstve spravovanej WebHouse, zodpovednosť WebHouse sa posudzuje podľa tejto skutočnej príčiny.
15. WebHouse môže v rámci technickej podpory pomôcť s identifikáciou pravdepodobnej príčiny incidentu alebo so základnou diagnostikou, ak to technické možnosti umožňujú.
16. Takáto diagnostika neznamená prevzatie správy CMS ani povinnosť vykonať kompletné bezpečnostné čistenie alebo audit aplikácie.
17. Odstránenie zisteného škodlivého súboru alebo obnova aplikácie zo zálohy sama osebe nezaručuje, že bola odstránená pôvodná príčina kompromitácie.
18. Po bezpečnostnom incidente je Zákazník zodpovedný za primerané odstránenie príčiny v ním spravovanej vrstve, najmä za aktualizáciu alebo odstránenie zraniteľných komponentov a zmenu kompromitovaných prístupových údajov.
19. WebHouse môže v prípade napadnutého alebo nebezpečného CMS vykonať primerané bezpečnostné opatrenia na ochranu infraštruktúry a ostatných zákazníkov, vrátane dočasného obmedzenia alebo izolácie služby.
20. Takéto opatrenie samo osebe neznamená určenie zodpovednosti za vznik incidentu.
21. Jednorazová pomoc WebHouse pri aktualizácii, diagnostike, obnove alebo zabezpečení CMS neznamená automaticky prevzatie jeho ďalšej správy.
22. Ak si Zákazník objedná službu, ktorá výslovne zahŕňa správu WordPressu alebo iného CMS, rozsah zodpovednosti WebHouse sa riadi podmienkami tejto konkrétnej služby.

Článok 8

Kompromitácia zákazníckej aplikácie

1. Kompromitácia webovej stránky, aplikácie, používateľského účtu alebo iného obsahu prevádzkovaného Zákazníkom sama osebe nepreukazuje bezpečnostné zlyhanie infraštruktúry WebHouse.
2. WebHouse nezodpovedá za škody vzniknuté v dôsledku kompromitácie webovej stránky, aplikácie, používateľského účtu alebo iného obsahu či služby prevádzkovanej Zákazníkom, pokiaľ kompromitácia nevznikla v dôsledku porušenia povinnosti na strane WebHouse.
3. Toto platí aj v prípade, ak Zákazník používal primerané, odporúčané alebo nadštandardné bezpečnostné opatrenia.
4. Používanie bezpečnostných opatrení Zákazníkom samo osebe nepresúva správu ani bezpečnostnú zodpovednosť za zákaznícku aplikačnú vrstvu na WebHouse.
5. Za zabezpečenie, správu, aktualizáciu a obsah dát, aplikácií a softvéru uložených alebo prevádzkovaných v rámci služby zodpovedá Zákazník, pokiaľ nebolo výslovne dohodnuté inak.
6. WebHouse nezodpovedá najmä za kompromitáciu spôsobenú:

• zraniteľnosťou aplikácie,
• zraniteľnosťou CMS,
• zraniteľnosťou pluginu, modulu alebo témy,
• chybou vlastného alebo upraveného zdrojového kódu,
• použitím zastaraného alebo nepodporovaného softvéru,
• nesprávnou konfiguráciou aplikácie,
• odcudzeným alebo zneužitým heslom,
• phishingom alebo sociálnym inžinierstvom,
• malvérom na zariadení Zákazníka,
• zneužitím API kľúča, tokenu alebo privátneho kľúča,
• kompromitovaným FTP, SFTP, SSH, databázovým alebo administrátorským účtom,
• neoprávneným použitím účtu zamestnancom, bývalým zamestnancom, dodávateľom alebo spolupracovníkom,
• bezpečnostnou chybou služby tretej strany,
• alebo zraniteľnosťou komponentu, ktorý WebHouse nespravuje.

7. WebHouse nezodpovedá za kompromitáciu zákazníckej aplikácie iba preto, že táto aplikácia bola prevádzkovaná na infraštruktúre WebHouse.
8. Rovnako samotná existencia škodlivého kódu, backdooru, webshellu, neznámeho administrátorského účtu alebo zmeneného súboru v zákazníckom priestore nepreukazuje kompromitáciu servera alebo hostingovej platformy WebHouse.
9. Pri určovaní zodpovednosti je rozhodujúca skutočná technická príčina incidentu a technická vrstva, v ktorej táto príčina vznikla.
10. Ak bola príčinou kompromitácie zraniteľnosť alebo nesprávna konfigurácia v technickej vrstve spravovanej Zákazníkom, zodpovednosť za túto vrstvu nesie Zákazník.
11. Ak bola príčinou kompromitácie bezpečnostná chyba, nesprávna konfigurácia, zanedbaná správa alebo iné porušenie povinnosti v technickej vrstve spravovanej WebHouse, zodpovednosť sa posudzuje podľa tejto skutočnej príčiny.
12. Ak sa na vzniku alebo rozsahu incidentu podieľali nedostatky na strane Zákazníka aj WebHouse, zodpovednosť sa posudzuje podľa konkrétnych príčin a povinností oboch strán.
13. Samotný fakt, že presný spôsob kompromitácie nemožno spätne jednoznačne určiť, neznamená automaticky zodpovednosť WebHouse.
14. Rovnako nemožnosť presne určiť vektor útoku sama osebe nepreukazuje, že príčinou bola zákaznícka aplikácia.
15. Posúdenie incidentu sa vykonáva podľa dostupných technických informácií, najmä logov, časových údajov, konfigurácie, stavu aplikácie a ďalších relevantných zistení.
16. Dostupnosť historických logov alebo iných technických údajov môže byť obmedzená ich bežnou retenčnou dobou alebo technickými vlastnosťami služby.
17. WebHouse negarantuje, že pri každom bezpečnostnom incidente bude možné spätne jednoznačne určiť:

• presný okamih prvotnej kompromitácie,
• všetky kroky útočníka,
• konkrétnu použitú zraniteľnosť,
• zdroj odcudzenia prístupových údajov,
• alebo identitu útočníka.

18. Zistenie pravdepodobnej príčiny incidentu v rámci technickej podpory nepredstavuje forenzný posudok, pokiaľ nebola takáto služba osobitne dohodnutá.
19. Ak je zákaznícka aplikácia kompromitovaná alebo vykazuje škodlivú aktivitu, WebHouse môže vykonať primerané ochranné opatrenia potrebné na ochranu infraštruktúry a ostatných zákazníkov.
20. Takéto opatrenia môžu zahŕňať najmä:

• dočasné obmedzenie prevádzky aplikácie,
• blokovanie škodlivej komunikácie,
• obmedzenie prístupu,
• izoláciu hostingového účtu alebo jeho časti,
• alebo dočasné pozastavenie služby v nevyhnutnom rozsahu.

21. Vykonanie takéhoto ochranného opatrenia samo osebe neznamená uznanie zodpovednosti WebHouse za vznik incidentu.
22. WebHouse môže Zákazníka upozorniť na zistenú alebo pravdepodobnú zraniteľnosť, škodlivý súbor, kompromitovaný účet alebo inú bezpečnostnú skutočnosť týkajúcu sa jeho aplikácie.
23. Takéto upozornenie neznamená, že WebHouse preberá povinnosť aplikáciu opraviť, aktualizovať, vyčistiť alebo ďalej bezpečnostne spravovať.
24. Po kompromitácii zákazníckej aplikácie zodpovedá Zákazník za odstránenie príčiny incidentu v technickej vrstve, ktorú spravuje.
25. To môže zahŕňať najmä:

• aktualizáciu alebo odstránenie zraniteľného komponentu,
• opravu vlastného zdrojového kódu,
• zmenu kompromitovaných hesiel,
• zneplatnenie API kľúčov alebo tokenov,
• kontrolu používateľských účtov,
• odstránenie neoprávnených prístupov,
• a ďalšie primerané bezpečnostné opatrenia.

26. Samotné odstránenie viditeľného škodlivého súboru alebo kódu nemusí znamenať odstránenie pôvodnej príčiny kompromitácie.
27. Rovnako obnova aplikácie zo zálohy sama osebe nezaručuje, že aplikácia je bezpečná, pretože záloha môže obsahovať rovnakú zraniteľnosť alebo už kompromitované dáta.
28. Ak je príčinou kompromitácie odcudzený prístupový údaj, samotná zmena alebo obnova poškodených súborov nemusí byť dostatočná bez zmeny príslušných prístupových údajov.
29. WebHouse môže pred obnovením plnej prevádzky kompromitovanej služby požadovať primeranú súčinnosť Zákazníka, ak je to potrebné na zabránenie pokračovania alebo opakovania škodlivej aktivity.
30. Jednorazová pomoc WebHouse pri diagnostike, obnove, odstránení škodlivého súboru alebo inom zásahu do zákazníckej aplikácie neznamená prevzatie jej ďalšej správy ani bezpečnostnej zodpovednosti.
31. Ak WebHouse poskytne takúto pomoc bezplatne alebo nad rámec štandardnej služby, nevytvára tým automaticky povinnosť poskytovať rovnaký rozsah pomoci pri ďalšom incidente.
32. Ak si Zákazník objedná službu, ktorá výslovne zahŕňa správu, aktualizáciu, monitoring alebo bezpečnostný dohľad nad aplikáciou, rozsah zodpovednosti WebHouse sa riadi podmienkami tejto konkrétnej služby.
33. Ustanovenia tohto článku nemožno použiť na vylúčenie zodpovednosti WebHouse za bezpečnostnú chybu alebo nesplnenú povinnosť v technickej vrstve, ktorú mal podľa objednanej služby spravovať WebHouse.

Článok 9

Virtuálne servery – VPS

9.1 Nespravovaný VPS

1. Pri nespravovanom VPS WebHouse spravidla zodpovedá najmä za:

• fyzický server,
• virtualizačnú platformu,
• základnú sieťovú konektivitu,
• pridelenie dohodnutých virtuálnych prostriedkov,
• technickú funkčnosť virtuálneho stroja na úrovni virtualizácie.

2. WebHouse zodpovedá za primeranú bezpečnostnú správu a údržbu fyzickej a virtualizačnej vrstvy, ktorú spravuje.
3. Zákazník zodpovedá za celý softvérový obsah VPS, pokiaľ nebolo výslovne dohodnuté inak.
4. Zodpovednosť Zákazníka zahŕňa najmä:

• operačný systém,
• jeho konfiguráciu,
• systémové aktualizácie,
• bezpečnostné aktualizácie,
• SSH,
• firewall operačného systému,
• používateľské a administrátorské účty,
• webový server,
• PHP,
• databázový server,
• mailový server,
• DNS server,
• ostatné systémové služby,
• všetky nainštalované aplikácie,
• bezpečnostné nastavenia,
• prístupové údaje,
• a zálohy, ak nie sú objednané samostatne.

5. Skutočnosť, že virtuálny stroj je na úrovni virtualizačnej platformy spustený a dostupný, neznamená, že operačný systém alebo služby vo vnútri VPS fungujú správne.
6. Ak VPS neodpovedá z dôvodu chyby operačného systému, firewallu, sieťovej konfigurácie, vyčerpania systémových prostriedkov alebo inej konfigurácie vo vnútri VPS, nejde samo osebe o poruchu virtualizačnej platformy WebHouse.
7. WebHouse môže preveriť dostupnosť VPS na úrovni svojej infraštruktúry, stav virtuálneho stroja a základnú sieťovú konektivitu.
8. Takéto preverenie neznamená prevzatie správy operačného systému alebo aplikácií Zákazníka.
9. Zákazník zodpovedá za primerané zabezpečenie nespravovaného VPS proti neoprávnenému prístupu a zneužitiu.
10. Zákazník zodpovedá najmä za:

• pravidelnú inštaláciu bezpečnostných aktualizácií,
• bezpečné nastavenie SSH,
• správu firewallu,
• obmedzenie nepotrebných služieb,
• bezpečnosť používateľských účtov,
• ochranu root a administrátorských prístupov,
• a zabezpečenie nainštalovaných aplikácií.

11. Samotná kompromitácia operačného systému alebo aplikácie v nespravovanom VPS nepreukazuje bezpečnostné zlyhanie fyzickej alebo virtualizačnej infraštruktúry WebHouse.
12. Ak však kompromitácia vznikne v dôsledku bezpečnostnej chyby vo fyzickej, sieťovej alebo virtualizačnej vrstve spravovanej WebHouse, zodpovednosť sa posudzuje podľa tejto skutočnej príčiny.
13. WebHouse nie je pri nespravovanom VPS povinný priebežne sledovať stav operačného systému, aktualizácií, firewallu, služieb alebo aplikácií Zákazníka, pokiaľ takýto monitoring nie je výslovne súčasťou objednanej služby.
14. WebHouse môže Zákazníkovi poskytnúť technické prostriedky na prístup ku konzole, rescue režimu alebo inému spôsobu obnovy prístupu k VPS, ak ich daná platforma podporuje.
15. Poskytnutie takéhoto nástroja neznamená povinnosť WebHouse vykonať samotnú opravu operačného systému.

9.2 Dôsledky root alebo administrátorského prístupu

16. Ak má Zákazník administrátorský alebo root prístup k VPS, má plnú technickú možnosť meniť softvérovú konfiguráciu systému a zodpovedá za zmeny, ktoré prostredníctvom tohto prístupu vykoná on alebo osoba, ktorej prístup poskytol.
17. Zákazník zodpovedá za ochranu root hesla, SSH kľúčov a ostatných administrátorských autentifikačných údajov.
18. Zákazník zodpovedá aj za oprávnenia udelené svojim zamestnancom, administrátorom, dodávateľom alebo iným tretím osobám.
19. WebHouse nie je pri nespravovanom VPS povinný zisťovať alebo opravovať dôsledky:

• nesprávnej konfigurácie,
• odstránenia alebo poškodenia systémových súborov,
• nesprávneho firewallového pravidla,
• nesprávnej sieťovej konfigurácie,
• neúspešnej aktualizácie,
• nekompatibilnej aktualizácie,
• kompromitácie servera,
• poškodenia operačného systému,
• nesprávnej konfigurácie webového, databázového, mailového alebo DNS servera,
• alebo iného zásahu vykonaného v rámci zákazníkom spravovanej vrstvy.

20. Ak Zákazník vlastným zásahom znefunkční SSH alebo sieťovú konektivitu vo vnútri VPS, samotná nedostupnosť servera cez sieť neznamená poruchu infraštruktúry WebHouse.
21. Ak Zákazník zmení alebo odstráni konfiguráciu potrebnú na správnu funkciu operačného systému alebo služieb, zodpovedá za následky tejto zmeny.
22. WebHouse môže na žiadosť Zákazníka poskytnúť pomoc s diagnostikou alebo opravou takéhoto problému ako nadštandardnú službu, ak to technické a kapacitné možnosti umožňujú.
23. Jednorazový administrátorský zásah WebHouse do nespravovaného VPS neznamená, že WebHouse preberá jeho ďalšiu správu alebo bezpečnostnú zodpovednosť.
24. Ak WebHouse vykoná konkrétny zásah na základe dohody so Zákazníkom, zodpovedá za správne vykonanie tohto konkrétneho zásahu.
25. To nemení zodpovednosť Zákazníka za ostatné časti systému, ktoré naďalej zostávajú v jeho správe.

9.3 Managed VPS

26. Ak si Zákazník objedná managed VPS alebo inú službu správy servera, rozsah bezpečnostnej zodpovednosti WebHouse sa rozširuje o komponenty, ktorých správu WebHouse výslovne prevzal.
27. Môže ísť napríklad o:

• operačný systém,
• systémové aktualizácie,
• firewall,
• webový server,
• databázový server,
• PHP,
• alebo ďalšie konkrétne systémové služby.

28. Samotné označenie služby ako managed neznamená automaticky, že WebHouse spravuje všetky aplikácie, webové stránky, CMS, pluginy alebo vlastný zdrojový kód Zákazníka.
29. Rozsah managed správy sa vždy určuje podľa konkrétnych podmienok objednanej služby.
30. Ak má Zákazník pri managed VPS zároveň root alebo administrátorský prístup a vykonáva vlastné zásahy do komponentov spravovaných WebHouse, zodpovednosť za následky takýchto zásahov sa posudzuje podľa ich skutočnej príčiny a rozsahu.
31. Zákazník je povinný zdržať sa zásahov, ktoré by mohli znemožniť alebo podstatne sťažiť plnenie dohodnutej managed správy, ak to vyplýva z podmienok služby.
32. Zodpovednosť Zákazníka za nespravovaný alebo ním zmenený komponent nemožno použiť na vylúčenie zodpovednosti WebHouse za bezpečnostnú chybu v komponentoch, ktoré mal podľa objednanej služby spravovať WebHouse.

Článok 10

Spravované VPS a servery

1. Pri spravovanej službe sa rozsah zodpovednosti WebHouse rozširuje iba na komponenty, činnosti a technické vrstvy, ktoré sú výslovne zahrnuté v rozsahu správy.
2. Rozsah správy sa určuje podľa parametrov konkrétnej služby, prípadnej individuálnej dohody a ďalších osobitných podmienok.
3. Spravovaný server automaticky neznamená, že WebHouse spravuje všetky vrstvy a aplikácie prevádzkované na tomto serveri.
4. Ak nebolo výslovne dohodnuté inak, správa servera automaticky nezahŕňa najmä:

• webové aplikácie,
• WordPress alebo iné CMS,
• pluginy, moduly a témy,
• zákaznícky zdrojový kód,
• aplikačné frameworky,
• databázový obsah,
• aplikačnú logiku,
• používateľské účty aplikácií,
• obsah webových stránok,
• ani služby tretích strán používané aplikáciou.

5. Ak WebHouse v rámci spravovanej služby prevezme správu operačného systému alebo konkrétneho systémového softvéru, zodpovedá v dohodnutom rozsahu aj za jeho primeranú bezpečnostnú údržbu.
6. Môže ísť najmä o:

• bezpečnostné aktualizácie operačného systému,
• správu firewallu,
• správu webového servera,
• správu databázového servera,
• správu PHP,
• správu mailového servera,
• alebo iné výslovne uvedené systémové komponenty.

7. Ak určitý komponent nie je uvedený v rozsahu správy, samotná skutočnosť, že je nainštalovaný na spravovanom serveri, neznamená, že jeho správu prevzal WebHouse.
8. WebHouse zodpovedá za primeranú konfiguráciu a bezpečnostnú správu komponentov, ktoré podľa konkrétnej služby spravuje.
9. Zákazník naďalej zodpovedá za bezpečnosť komponentov a technických vrstiev, ktoré zostávajú v jeho správe.
10. Ak napríklad WebHouse spravuje operačný systém, webový server, PHP a databázový server, ale nespravuje WordPress, za bezpečnostné aktualizácie WordPressu, pluginov a tém naďalej zodpovedá Zákazník.
11. Bezpečnostný incident v zákazníckej aplikácii preto sám osebe neznamená porušenie povinností WebHouse pri správe servera.
12. Ak však incident vznikne v dôsledku bezpečnostnej chyby alebo zanedbanej správy komponentu, ktorý mal podľa objednanej managed služby spravovať WebHouse, zodpovednosť sa posudzuje podľa tejto skutočnej príčiny.
13. Pri spravovanej službe môže byť rozsah oprávnení Zákazníka obmedzený, ak je takéto obmedzenie potrebné na bezpečné a spoľahlivé poskytovanie správy.
14. Ak má Zákazník napriek managed správe root alebo iný administrátorský prístup, je povinný používať ho spôsobom, ktorý nenarúša správu vykonávanú WebHouse.
15. Ak Zákazník vykoná zmenu komponentu spravovaného WebHouse, zodpovedá za následky svojho zásahu v rozsahu, v akom tento zásah problém spôsobil alebo k nemu prispel.
16. Môže ísť najmä o:

• manuálnu zmenu systémovej konfigurácie,
• zmenu firewallu,
• inštaláciu alebo odstránenie systémového balíka,
• zmenu webového alebo databázového servera,
• zásah do oprávnení,
• alebo obídenie bezpečnostného mechanizmu nastaveného WebHouse.

17. Samotná existencia root alebo administrátorského prístupu Zákazníka však automaticky nezbavuje WebHouse zodpovednosti za komponenty, ktorých správu výslovne prevzal.
18. Ak nie je možné spoľahlivo poskytovať managed službu v dôsledku nekompatibilných alebo opakovaných zásahov Zákazníka, WebHouse môže požadovať ich odstránenie alebo obnovu podporovanej konfigurácie.
19. WebHouse môže odmietnuť vykonať požadovanú zmenu v spravovanom komponente, ak by bola v rozpore s bezpečnostnými pravidlami, technickými štandardmi alebo by neprimerane ohrozila stabilitu alebo bezpečnosť servera.
20. Zákazník nemá pri spravovanej službe automatický nárok na zachovanie ľubovoľnej verzie alebo konfigurácie systémového softvéru, ak je jej zmena potrebná z bezpečnostných alebo prevádzkových dôvodov.
21. WebHouse môže pri spravovaných komponentoch používať vlastné štandardizované konfigurácie a bezpečnostné politiky potrebné na ich riadnu správu.
22. Managed služba nepredstavuje garanciu, že na serveri alebo v aplikáciách nikdy nevznikne bezpečnostný incident.
23. WebHouse zodpovedá za riadne plnenie bezpečnostných a administrátorských činností, ktoré v rámci managed služby prevzal, nie za absolútne vylúčenie všetkých možných incidentov.
24. Poskytnutie jednorazovej pomoci s komponentom, ktorý nie je súčasťou managed služby, samo osebe nerozširuje trvalý rozsah správy.
25. Ak je rozsah správy pri konkrétnej službe upravený podrobnejšie, má táto konkrétna úprava prednosť pred všeobecnými ustanoveniami tohto článku.

Článok 11

Dedikované servery

1. Pri dedikovanom serveri závisí rozsah zodpovednosti od toho, či ide o spravovaný alebo nespravovaný server a od konkrétneho rozsahu objednanej služby.
2. Pri nespravovanom dedikovanom serveri WebHouse spravidla zodpovedá najmä za:

• fyzickú dostupnosť servera,
• hardvér podľa podmienok služby,
• napájanie,
• základnú sieťovú konektivitu,
• a ďalšie infraštruktúrne komponenty, ktoré má podľa služby vo svojej správe.

3. WebHouse zodpovedá za primerané riešenie hardvérovej poruchy v rozsahu podmienok konkrétnej služby.
4. Hardvérová porucha sama osebe neznamená, že WebHouse zodpovedá aj za stav operačného systému, aplikácií alebo dát uložených na serveri, pokiaľ ich správu neprevzal.
5. Operačný systém a všetok ďalší softvér pri nespravovanom dedikovanom serveri spravuje Zákazník, pokiaľ nebolo výslovne dohodnuté inak.
6. Zákazník zodpovedá najmä za:

• inštaláciu a konfiguráciu operačného systému,
• systémové a bezpečnostné aktualizácie,
• firewall,
• SSH a administrátorské prístupy,
• používateľské účty,
• webový server,
• databázový server,
• mailový server,
• DNS server,
• PHP a ďalšie runtime prostredia,
• všetky nainštalované aplikácie,
• a bezpečnostné nastavenia softvérovej vrstvy.

7. Zákazník zodpovedá za ochranu root alebo iných administrátorských prístupov k serveru.
8. Ak Zákazník poskytne administrátorský prístup tretej osobe, zodpovedá za jej zásahy v rozsahu svojej správy.
9. Samotná kompromitácia operačného systému alebo aplikácie na nespravovanom dedikovanom serveri nepreukazuje bezpečnostné zlyhanie fyzickej alebo sieťovej infraštruktúry WebHouse.
10. Ak však bezpečnostný incident vznikne v dôsledku chyby hardvéru, siete alebo iného komponentu spravovaného WebHouse, zodpovednosť sa posudzuje podľa tejto skutočnej príčiny.
11. WebHouse nie je pri nespravovanom serveri povinný priebežne sledovať:

• stav operačného systému,
• dostupnosť bezpečnostných aktualizácií,
• konfiguráciu firewallu,
• stav systémových služieb,
• stav aplikácií,
• alebo bezpečnostné incidenty vo vnútri servera,

pokiaľ takáto činnosť nie je súčasťou objednanej služby.

12. Zákazník zodpovedá za to, aby ním používaný operačný systém a softvér bol podporovaný, primerane aktualizovaný a bezpečne nakonfigurovaný.
13. Ak Zákazník používa vlastný alebo neštandardný operačný systém, WebHouse nezodpovedá za jeho kompatibilitu, funkčnosť alebo bezpečnostnú správu, pokiaľ nebolo dohodnuté inak.
14. Poskytnutie IP adresy, sieťového pripojenia alebo fyzického servera neznamená prevzatie bezpečnostného dohľadu nad softvérom prevádzkovaným Zákazníkom.
15. WebHouse môže pri technickom probléme preveriť hardvérový stav servera a základnú sieťovú dostupnosť.
16. Takáto diagnostika neznamená prevzatie správy operačného systému alebo softvéru Zákazníka.
17. Ak sa server javí ako nedostupný, ale príčinou je firewall, poškodený operačný systém, nesprávna sieťová konfigurácia alebo iná softvérová chyba na strane Zákazníka, nejde samo osebe o poruchu infraštruktúry WebHouse.
18. Ak je to technicky možné, WebHouse môže poskytnúť alebo umožniť prístup k rescue režimu, vzdialenej konzole alebo inému nástroju určenému na diagnostiku servera.
19. Poskytnutie takéhoto nástroja neznamená povinnosť WebHouse vykonať samotnú opravu operačného systému alebo dát.
20. Zákazník zodpovedá za zálohovanie dát na dedikovanom serveri, pokiaľ nebola zálohovacia služba objednaná samostatne alebo výslovne zahrnutá v službe.
21. Ak je zálohovanie súčasťou objednanej služby, rozsah zodpovednosti WebHouse sa v tejto oblasti riadi podmienkami konkrétnej zálohovacej služby.
22. Pri spravovanom dedikovanom serveri sa rozsah zodpovednosti WebHouse rozširuje o komponenty, ktorých správu výslovne prevzal.
23. Samotné označenie servera ako spravovaného však neznamená automatickú správu webových aplikácií, CMS, pluginov, vlastného zdrojového kódu alebo obsahu Zákazníka.
24. Ak má Zákazník pri spravovanom serveri administrátorský prístup a zasahuje do komponentov spravovaných WebHouse, zodpovednosť za následky takéhoto zásahu sa posudzuje podľa jeho skutočného vplyvu na vznik problému.
25. Samotná existencia administrátorského prístupu Zákazníka nezbavuje WebHouse zodpovednosti za komponenty, ktorých správu podľa konkrétnej služby výslovne prevzal.
26. Ak WebHouse vykoná jednorazový zásah do nespravovaného servera na žiadosť Zákazníka, neznamená to automaticky prevzatie jeho ďalšej správy.
27. Ak však WebHouse konkrétny zásah vykoná, zodpovedá za jeho správne vykonanie v rozsahu prijatej práce.
28. Konkrétne podmienky správy, výmeny hardvéru, zálohovania, SLA alebo dostupnosti majú pred týmto všeobecným ustanovením prednosť.

Článok 12

Serverhousing

1. Pri serverhousingu Zákazník spravidla vlastní a spravuje svoj server alebo iné umiestnené zariadenie.
2. WebHouse zodpovedá iba za služby a technické vrstvy, ktoré sú výslovne zahrnuté v serverhousingovej službe.
3. Ide najmä o:

• umiestnenie zariadenia,
• napájanie,
• sieťové pripojenie,
• fyzické prostredie v rozsahu poskytovanej služby,
• a prípadne ďalšie výslovne dohodnuté infraštruktúrne služby.

4. WebHouse nezodpovedá za technický stav, životnosť, kompatibilitu alebo bezpečnosť hardvéru vo vlastníctve Zákazníka, pokiaľ nebolo dohodnuté inak.
5. Zákazník zodpovedá najmä za:

• svoj hardvér,
• disky a iné úložiská,
• firmware,
• BIOS alebo obdobné systémové prostredie zariadenia,
• operačný systém,
• systémový softvér,
• aplikácie,
• konfiguráciu,
• používateľské a administrátorské účty,
• dáta,
• zálohovanie,
• a zabezpečenie servera.

6. Zákazník zodpovedá za primeranú údržbu svojho hardvéru a za riešenie jeho porúch, pokiaľ príslušná činnosť nie je výslovne zahrnutá v objednanej službe.
7. Porucha disku, pamäte, napájacieho zdroja, radiča, základnej dosky alebo iného komponentu vo vlastníctve Zákazníka sama osebe nepredstavuje poruchu serverhousingovej služby WebHouse.
8. Ak však k nedostupnosti alebo poškodeniu zariadenia dôjde v dôsledku poruchy napájania, sieťovej infraštruktúry alebo iného komponentu, ktorý je podľa konkrétnej služby v správe WebHouse, zodpovednosť sa posudzuje podľa tejto skutočnej príčiny.
9. Zákazník zodpovedá za bezpečnostnú správu operačného systému, firewallu, sieťovej konfigurácie, serverových služieb a aplikácií prevádzkovaných na svojom zariadení.
10. WebHouse nie je pri bežnom serverhousingu povinný sledovať:

• stav operačného systému,
• dostupnosť bezpečnostných aktualizácií,
• stav diskov alebo RAID,
• konfiguráciu firewallu,
• systémové logy,
• aplikácie,
• ani bezpečnostné udalosti vo vnútri servera,

pokiaľ nebola takáto služba osobitne objednaná.

11. Samotná kompromitácia servera Zákazníka nepreukazuje bezpečnostné zlyhanie siete alebo infraštruktúry WebHouse.
12. Ak však bezpečnostný incident vznikne v dôsledku chyby v technickej vrstve serverhousingu spravovanej WebHouse, zodpovednosť sa posudzuje podľa tejto skutočnej príčiny.
13. Zákazník zodpovedá za ochranu svojich administrátorských prístupov, hesiel, SSH kľúčov a ďalších autentifikačných údajov.
14. Zákazník zodpovedá aj za osoby, ktorým umožní administratívny alebo fyzický prístup k svojmu zariadeniu v rozsahu oprávnení, ktoré im poskytol.
15. Ak WebHouse umožňuje Zákazníkovi alebo jeho poverenej osobe fyzický prístup k zariadeniu, môže tento prístup podliehať bezpečnostným a prevádzkovým pravidlám dátového centra.
16. WebHouse môže z bezpečnostných dôvodov požadovať primerané overenie identity alebo oprávnenia osoby požadujúcej fyzický prístup alebo manipuláciu so zariadením.
17. Ak pracovník WebHouse na žiadosť Zákazníka vykoná jednoduchý fyzický úkon, napríklad reštart zariadenia, kontrolu káblového pripojenia alebo inú dohodnutú „remote hands“ činnosť, neznamená to prevzatie správy zariadenia.
18. Ak WebHouse vykoná konkrétny zásah do zariadenia Zákazníka, zodpovedá za správne vykonanie tohto konkrétneho zásahu v rozsahu prijatej práce.
19. WebHouse nie je povinný vykonať fyzický alebo technický zásah, ktorý by mohol neprimerane ohroziť zariadenie Zákazníka, ostatné zariadenia alebo infraštruktúru dátového centra.
20. WebHouse môže odmietnuť zapojenie alebo prevádzku zariadenia, ktoré nespĺňa technické, elektrické, bezpečnostné alebo prevádzkové požiadavky príslušnej serverhousingovej služby.
21. Zákazník zodpovedá za to, že jeho zariadenie svojimi vlastnosťami a prevádzkou neohrozuje infraštruktúru WebHouse ani zariadenia ostatných zákazníkov.
22. Ak Zákazník požaduje nad rámec serverhousingu monitoring, správu operačného systému, zálohovanie, hardvérový servis alebo inú správu zariadenia, musí byť takáto služba osobitne dohodnutá.
23. Jednorazová pomoc WebHouse pri diagnostike, reštarte, výmene komponentu alebo inom zásahu sama osebe nemení serverhousing na spravovanú službu.
24. Konkrétne podmienky napájania, sieťovej konektivity, fyzického prístupu, remote hands, SLA alebo ďalších služieb majú pred týmto všeobecným ustanovením prednosť.

Článok 13

E-mailové služby

13.1 Zodpovednosť WebHouse

1. Pri spravovanej e-mailovej službe WebHouse zodpovedá za primeranú bezpečnostnú správu mailovej infraštruktúry a komponentov, ktoré sú súčasťou poskytovanej služby.
2. WebHouse zodpovedá najmä za:

• prevádzku svojich mailových serverov,
• systémový softvér spravovaný WebHouse,
• základné bezpečnostné mechanizmy mailovej infraštruktúry,
• technické oddelenie jednotlivých účtov v primeranom rozsahu,
• antispamové alebo antivírusové systémy, ak sú súčasťou služby,
• technické fungovanie autentifikácie poskytovanej službou,
• a ďalšie bezpečnostné mechanizmy výslovne zahrnuté v konkrétnej službe.

3. WebHouse zabezpečuje primeranú aktualizáciu a bezpečnostnú údržbu systémového softvéru mailových serverov, ktorý spravuje.
4. Ak je súčasťou služby antispamová alebo antivírusová ochrana, WebHouse zodpovedá za jej technickú prevádzku v rozsahu konkrétnej služby.
5. Antispamová alebo antivírusová ochrana však nepredstavuje garanciu, že bude zachytená každá nevyžiadaná, podvodná, phishingová alebo škodlivá správa.
6. Rovnako nemožno garantovať, že bezpečnostné filtre nikdy nesprávne vyhodnotia legitímnu správu ako podozrivú alebo nevyžiadanú.
7. WebHouse môže bezpečnostné mechanizmy mailovej infraštruktúry priebežne upravovať, ak je to potrebné na ochranu služby, infraštruktúry alebo ostatných zákazníkov.
8. WebHouse zodpovedá za bezpečnostný incident, ktorý vznikol v dôsledku chyby alebo porušenia povinnosti v mailovej alebo systémovej vrstve, ktorú spravuje WebHouse.
9. Samotné zneužitie e-mailového účtu však nepreukazuje bezpečnostné zlyhanie mailovej infraštruktúry WebHouse.
10. Pri podozrení na kompromitáciu účtu môže WebHouse vykonať primerané ochranné opatrenia, najmä:

• dočasne obmedziť odosielanie správ,
• zablokovať podozrivé prihlásenie,
• vyžiadať zmenu hesla,
• obmedziť kompromitovaný účet,
• alebo vykonať iné primerané opatrenie potrebné na zastavenie zneužitia.

11. Takéto opatrenie samo osebe neznamená určenie zodpovednosti za vznik incidentu.

13.2 Zodpovednosť Zákazníka

12. Zákazník zodpovedá za bezpečnosť e-mailových účtov a autentifikačných údajov, ktoré má vo svojej správe.
13. Zákazník zodpovedá najmä za:

• bezpečnosť hesiel e-mailových účtov,
• používanie primerane silných a unikátnych hesiel,
• správu používateľov,
• rušenie nepotrebných účtov,
• ochranu koncových zariadení,
• bezpečnosť svojho e-mailového klienta,
• ochranu uložených hesiel a autentifikačných tokenov,
• vyhodnocovanie podozrivých správ,
• ochranu pred phishingom a sociálnym inžinierstvom,
• a správnosť pravidiel preposielania alebo filtrovania vytvorených Zákazníkom.

14. Ak služba umožňuje viacfaktorovú autentifikáciu alebo iný doplnkový bezpečnostný mechanizmus, Zákazník zodpovedá za jeho používanie v rozsahu, v akom je jeho aktivácia a správa v dispozícii Zákazníka.
15. Zákazník zodpovedá za ochranu zariadení, z ktorých pristupuje k e-mailovej službe, pred malvérom, neoprávneným prístupom a odcudzením prihlasovacích údajov.
16. Ak dôjde k odcudzeniu e-mailového hesla prostredníctvom phishingu, malvéru, kompromitovaného zariadenia alebo iného systému Zákazníka, samotné následné prihlásenie útočníka k mailovému serveru WebHouse neznamená bezpečnostnú chybu infraštruktúry WebHouse.
17. Ak má Zákazník dôvodné podozrenie na kompromitáciu e-mailového účtu, je povinný primerane reagovať, najmä zmenou hesla a kontrolou nastavení účtu.
18. Po kompromitácii účtu by mal Zákazník preveriť najmä:

• pravidlá automatického preposielania,
• filtre správ,
• automatické odpovede,
• prístupové zariadenia,
• delegované prístupy,
• a ďalšie nastavenia, ktoré mohol útočník zmeniť.

19. Zákazník zodpovedá za pravidlá preposielania, filtrovania alebo automatizácie, ktoré vytvorí sám alebo prostredníctvom osoby konajúcej v jeho mene.
20. Ak Zákazník nastaví automatické preposielanie správ na externú službu, zodpovedá za správnosť cieľovej adresy a za bezpečnostné dôsledky takéhoto nastavenia v rozsahu svojej správy.
21. Zákazník zodpovedá za používateľské rozhodnutia vykonané na základe obsahu prijatého e-mailu, najmä za otvorenie prílohy, zadanie hesla na cudzej stránke, vykonanie platby alebo iný úkon vyvolaný phishingom alebo sociálnym inžinierstvom.
22. Skutočnosť, že phishingová alebo škodlivá správa prešla cez antispamový alebo antivírusový systém WebHouse, sama osebe neznamená porušenie bezpečnostnej povinnosti WebHouse.
23. Rovnako skutočnosť, že legitímna správa bola označená ako spam alebo zadržaná bezpečnostným filtrom, sama osebe neznamená bezpečnostné zlyhanie služby.

13.3 Odosielanie a doručovanie správ

24. WebHouse zodpovedá za technické spracovanie a odosielanie správ v rozsahu svojej mailovej infraštruktúry a parametrov konkrétnej služby.
25. WebHouse nemôže garantovať prijatie alebo ďalšie spracovanie správy mailovým systémom tretej strany.
26. O prijatí, odmietnutí, označení ako spam alebo umiestnení správy do konkrétneho priečinka môže rozhodovať externý mailový systém podľa vlastných pravidiel.
27. Samotné odmietnutie alebo nedoručenie správy externým serverom preto nepreukazuje bezpečnostné alebo technické zlyhanie mailovej služby WebHouse.
28. Ak je však príčinou nedoručenia chyba v mailovej infraštruktúre alebo konfigurácii, ktorú má spravovať WebHouse, zodpovednosť sa posudzuje podľa tejto skutočnej príčiny.
29. WebHouse môže uplatňovať technické a bezpečnostné limity na odosielanie správ s cieľom chrániť reputáciu mailovej infraštruktúry a zabrániť jej zneužívaniu.
30. Ak je účet zneužívaný na rozosielanie spamu, phishingu, malvéru alebo inej škodlivej komunikácie, WebHouse môže jeho odosielanie dočasne obmedziť alebo zablokovať.
31. Zákazník je v takom prípade povinný primerane spolupracovať na odstránení príčiny zneužitia pred obnovením plnej prevádzky účtu.

13.4 Rozdelenie zodpovednosti pri incidente

32. Pri bezpečnostnom incidente e-mailovej služby je rozhodujúca skutočná technická príčina incidentu.
33. Je potrebné rozlišovať najmä medzi:

• kompromitáciou hesla alebo zariadenia Zákazníka,
• zneužitím účtu oprávnenou alebo bývalou oprávnenou osobou,
• phishingom alebo sociálnym inžinierstvom,
• zákazníkom vytvoreným pravidlom preposielania,
• a bezpečnostnou chybou mailovej infraštruktúry WebHouse.

34. Ak bola príčina incidentu v zákazníkom spravovanej vrstve, samotná skutočnosť, že následok incidentu sa prejavil v e-mailovej službe WebHouse, nepresúva zodpovednosť na WebHouse.
35. Ak však incident vznikol v dôsledku bezpečnostnej chyby v mailovej alebo systémovej vrstve spravovanej WebHouse, zodpovednosť sa posudzuje podľa tejto skutočnej príčiny.
36. Poskytnutie technickej pomoci pri kompromitovanom e-mailovom účte neznamená automaticky uznanie zodpovednosti WebHouse za vznik incidentu.
37. Ak konkrétna e-mailová služba obsahuje rozšírenú bezpečnostnú ochranu, archiváciu, managed funkcie alebo iné osobitné bezpečnostné mechanizmy, rozsah zodpovednosti sa riadi podmienkami tejto konkrétnej služby.

Článok 14

Spam, phishing a škodlivé správy

1. Antispamové, antivírusové a iné bezpečnostné systémy slúžia na znižovanie rizika doručenia nevyžiadanej, podvodnej alebo škodlivej komunikácie.
2. Tieto systémy nemôžu garantovať zachytenie každej škodlivej správy ani úplné vylúčenie nesprávneho vyhodnotenia legitímnej komunikácie.
3. WebHouse preto negarantuje, že:

• každý spam bude zachytený,
• každý phishing bude identifikovaný,
• každý škodlivý súbor bude detegovaný,
• každý škodlivý odkaz bude rozpoznaný,
• každá podvodná alebo manipulatívna správa bude zablokovaná,
• legitímna správa nebude výnimočne označená ako nevyžiadaná alebo škodlivá.

4. Skutočnosť, že škodlivá alebo phishingová správa prejde cez bezpečnostný filter, sama osebe neznamená porušenie bezpečnostnej povinnosti WebHouse.
5. Rovnako samotné zadržanie, odmietnutie alebo označenie legitímnej správy ako spamu samo osebe neznamená nesprávne fungovanie služby.
6. Účinnosť antispamových a antivírusových mechanizmov môže závisieť od aktuálnych pravidiel, reputačných databáz, heuristiky, dostupných signatúr a ďalších bezpečnostných mechanizmov.
7. WebHouse môže tieto mechanizmy priebežne meniť alebo upravovať s cieľom reagovať na nové bezpečnostné hrozby, zneužívanie služby alebo zmeny charakteru nevyžiadanej komunikácie.
8. Zákazník je povinný primerane poučiť svojich používateľov o bezpečnom používaní e-mailu.
9. Používatelia by mali najmä venovať primeranú pozornosť:

• neočakávaným prílohám,
• odkazom smerujúcim na prihlasovacie stránky,
• požiadavkám na zadanie hesla,
• neobvyklým platobným pokynom,
• správam požadujúcim zmenu bankového účtu,
• správam vytvárajúcim neobvyklý časový alebo psychologický nátlak,
• a správam vydávajúcim sa za zamestnanca, vedenie spoločnosti alebo známu obchodnú stranu.

10. Zákazník zodpovedá za používateľské rozhodnutia vykonané na základe obsahu prijatej správy, najmä za zadanie hesla na podvodnej stránke, otvorenie škodlivej prílohy alebo vykonanie podvodnej platby, pokiaľ príčina incidentu nevznikla porušením povinnosti na strane WebHouse.
11. Samotná skutočnosť, že podvodná správa používa meno, logo, doménu alebo iné údaje dôveryhodnej osoby alebo spoločnosti, neznamená, že bola odoslaná prostredníctvom kompromitovanej infraštruktúry WebHouse.
12. Pri podozrivej správe je potrebné rozlišovať medzi:

• podvrhnutím identity odosielateľa,
• phishingom,
• kompromitovaným účtom,
• škodlivou prílohou,
• zneužitím domény,
• a bezpečnostným incidentom mailovej infraštruktúry.

13. Ak dôjde ku kompromitácii e-mailového účtu v dôsledku phishingu, odcudzenia hesla alebo kompromitovaného zariadenia Zákazníka, samotné následné použitie tohto účtu na rozosielanie škodlivých správ nepreukazuje bezpečnostné zlyhanie mailovej infraštruktúry WebHouse.
14. Ak však bezpečnostný incident vznikne v dôsledku chyby alebo porušenia povinnosti v mailovej alebo bezpečnostnej vrstve spravovanej WebHouse, zodpovednosť sa posudzuje podľa tejto skutočnej príčiny.
15. WebHouse môže pri zistení spamovej, phishingovej alebo inej škodlivej aktivity primerane obmedziť odosielanie, účet alebo službu, ak je to potrebné na ochranu infraštruktúry, reputácie mailových serverov alebo ostatných zákazníkov.
16. Takéto ochranné opatrenie samo osebe neznamená určenie zodpovednosti za vznik incidentu.
17. Konkrétna e-mailová služba môže obsahovať rozšírené antispamové, antivírusové alebo bezpečnostné mechanizmy; ich rozsah sa riadi parametrami tejto konkrétnej služby.

Článok 15

Heslá

1. Zákazník je povinný používať primerane bezpečné heslá a chrániť ich pred neoprávneným sprístupnením.
2. Heslá nesmú byť:

• zdieľané medzi osobami bez primeraného dôvodu,
• verejne publikované,
• ukladané na verejne prístupných miestach,
• zasielané nezabezpečeným spôsobom, ak existuje bezpečnejší spôsob,
• opakovane používané na viacerých kritických službách, ak tomu možno primerane zabrániť.

3. Zákazník by mal používať odlišné heslá najmä pre:

• administráciu zákazníckeho účtu,
• e-mailové účty,
• FTP alebo SFTP,
• SSH,
• databázy,
• CMS a administráciu webových aplikácií,
• a ďalšie bezpečnostne významné služby.

4. Zákazník zodpovedá za ochranu hesiel osôb, ktorým umožní prístup k svojim službám.
5. Ak je potrebné umožniť prístup viacerým osobám, má sa podľa technických možností uprednostniť vytvorenie samostatných používateľských účtov pred zdieľaním jedného spoločného hesla.
6. Zákazník by mal pri správe väčšieho počtu hesiel používať primerane bezpečný spôsob ich uchovávania, napríklad dôveryhodný správca hesiel.
7. Heslá nemajú byť ukladané v nezašifrovanej podobe na miestach, ku ktorým majú prístup neoprávnené osoby.
8. Ak má Zákazník dôvodné podozrenie, že heslo bolo prezradené, odcudzené, zneužité alebo inak kompromitované, je povinný ho bez zbytočného odkladu zmeniť.
9. Pri kompromitácii účtu môže byť potrebné zmeniť aj ďalšie súvisiace autentifikačné údaje, najmä:

• heslá ďalších účtov, na ktorých bolo použité rovnaké alebo podobné heslo,
• API kľúče,
• tokeny,
• aplikačné heslá,
• alebo iné prístupové údaje.

10. Samotná zmena hesla nemusí postačovať, ak útočník získal aj iný spôsob prístupu, napríklad aktívny token, SSH kľúč, vytvorený administrátorský účet alebo pravidlo automatického preposielania.
11. Zákazník by preto mal po bezpečnostnom incidente primerane preveriť aj ďalšie prístupové mechanizmy a nastavenia dotknutej služby.
12. WebHouse môže v rámci poskytovaných služieb vynucovať primerané bezpečnostné požiadavky na heslá a autentifikáciu.
13. Môže ísť najmä o:

• minimálnu dĺžku hesla,
• požiadavky na jeho kvalitu,
• zákaz niektorých zjavne nebezpečných hesiel,
• blokovanie alebo spomaľovanie opakovaných neúspešných pokusov,
• dočasné blokovanie účtu,
• alebo iné primerané bezpečnostné mechanizmy.

14. WebHouse môže tieto požiadavky primerane meniť v závislosti od vývoja bezpečnostných hrozieb a používaných technológií.
15. Ak služba podporuje viacfaktorovú autentifikáciu, WebHouse môže jej používanie odporúčať alebo pri vybraných citlivých službách primerane vyžadovať, ak to umožňujú podmienky konkrétnej služby.
16. Používanie silného a unikátneho hesla významne znižuje riziko neoprávneného prístupu, ale samo osebe nezaručuje, že účet nebude kompromitovaný.
17. K odcudzeniu alebo zneužitiu hesla môže dôjsť napríklad prostredníctvom:

• phishingu,
• malvéru na zariadení Zákazníka,
• kompromitovaného správcu hesiel,
• neoprávneného prístupu k zariadeniu,
• sociálneho inžinierstva,
• alebo bezpečnostného incidentu inej služby, v ktorej Zákazník použil rovnaké heslo.

18. Samotná skutočnosť, že útočník použil platné heslo na prihlásenie k službe WebHouse, nepreukazuje, že heslo uniklo zo systémov WebHouse.
19. Ak však dôjde ku kompromitácii hesla alebo autentifikačných údajov v dôsledku bezpečnostnej chyby v systéme spravovanom WebHouse, zodpovednosť sa posudzuje podľa tejto skutočnej príčiny.
20. WebHouse môže pri podozrení na kompromitáciu účtu vyžadovať zmenu hesla, reset autentifikačných údajov alebo dočasne obmedziť prístup, ak je to primerane potrebné na ochranu účtu, služby alebo infraštruktúry.
21. Poskytnutie hesla pracovníkovi WebHouse sa má obmedziť iba na prípady, keď je to skutočne potrebné; ak existuje bezpečnejší spôsob, má sa použiť dočasný, obmedzený alebo samostatný prístup.
22. WebHouse nie je oprávnený požadovať od Zákazníka pôvodné heslo k účtu v prípade, ak je možné prístup obnoviť alebo overiť bezpečnejším spôsobom, napríklad resetom hesla.
23. Zákazník zodpovedá za zmenu alebo zrušenie dočasných prístupových údajov poskytnutých tretej osobe po skončení dôvodu ich používania.
24. Konkrétna služba môže obsahovať prísnejšie alebo osobitné pravidlá pre heslá a autentifikáciu; tieto pravidlá majú vo vzťahu k danej službe prednosť.

Článok 16

Viacfaktorová autentifikácia

1. Ak služba umožňuje viacfaktorovú autentifikáciu, WebHouse odporúča jej používanie najmä pre administrátorské, privilegované a iné bezpečnostne významné účty.
2. Viacfaktorová autentifikácia znižuje riziko zneužitia samotného hesla, pretože na prihlásenie vyžaduje ďalší nezávislý autentifikačný prvok.
3. Ak Zákazník viacfaktorovú autentifikáciu nepoužíva napriek tomu, že je pre danú službu dostupná, nesie zvýšené riziko zneužitia prihlasovacích údajov.
4. Dostupnosť viacfaktorovej autentifikácie sama osebe neznamená, že WebHouse zodpovedá za jej aktiváciu na všetkých účtoch Zákazníka, pokiaľ jej zapnutie patrí do správy Zákazníka.
5. Zákazník zodpovedá za primeranú ochranu prostriedkov používaných ako druhý faktor, najmä:

• autentifikačnej aplikácie,
• bezpečnostného kľúča,
• mobilného zariadenia,
• jednorazových kódov,
• recovery kódov,
• alebo iných autentifikačných údajov.

6. Recovery kódy alebo obdobné záložné autentifikačné údaje majú byť uchovávané bezpečne a oddelene od hesla, ak to povaha služby umožňuje.
7. Zákazník zodpovedá za odstránenie alebo zmenu druhého faktora pri strate, odcudzení alebo zmene zariadenia, ak je táto správa v jeho dispozícii.
8. Ak má Zákazník dôvodné podozrenie, že druhý autentifikačný faktor alebo recovery údaje boli kompromitované, je povinný ich primerane zmeniť alebo zneplatniť.
9. Ani viacfaktorová autentifikácia nepredstavuje absolútnu záruku proti kompromitácii účtu.
10. K zneužitiu môže dôjsť napríklad prostredníctvom:

• phishingu zameraného na získanie jednorazového kódu,
• odcudzenia aktívnej relácie,
• kompromitovaného zariadenia,
• zneužitia recovery kódu,
• kompromitácie autentifikačného tokenu,
• alebo iného bezpečnostného incidentu mimo samotného prihlasovacieho mechanizmu.

11. Samotná skutočnosť, že bol účet chránený viacfaktorovou autentifikáciou, nepresúva zodpovednosť za bezpečnostnú správu zákazníckej vrstvy na WebHouse.
12. Rovnako samotná kompromitácia účtu chráneného viacfaktorovou autentifikáciou nepreukazuje bezpečnostné zlyhanie infraštruktúry WebHouse.
13. Ak však kompromitácia vznikne v dôsledku chyby alebo porušenia povinnosti v autentifikačnej vrstve spravovanej WebHouse, zodpovednosť sa posudzuje podľa tejto skutočnej príčiny.
14. WebHouse môže pri vybraných službách alebo bezpečnostne citlivých účtoch používanie viacfaktorovej autentifikácie primerane vyžadovať, ak to vyplýva z podmienok konkrétnej služby alebo z bezpečnostných požiadaviek.
15. Ak WebHouse z bezpečnostných dôvodov vyžaduje viacfaktorovú autentifikáciu, Zákazník je povinný poskytnúť primeranú súčinnosť potrebnú na jej aktiváciu a používanie.
16. WebHouse môže pri strate druhého faktora vyžadovať zvýšené overenie identity alebo oprávnenia Zákazníka pred resetovaním alebo odstránením viacfaktorovej autentifikácie.
17. Takéto zvýšené overenie slúži na ochranu účtu a nemožno ho obísť iba preto, že Zákazník pozná heslo k účtu.
18. Konkrétna služba môže používať odlišný spôsob viacfaktorovej autentifikácie alebo osobitné pravidlá jej obnovy; tieto pravidlá majú vo vzťahu k danej službe prednosť.

Článok 17

FTP, SSH a administrátorské prístupy

1. Zákazník je povinný poskytovať administrátorské a iné privilegované oprávnenia iba osobám, ktoré ich skutočne potrebujú na výkon svojej činnosti.
2. Rozsah oprávnení má byť primeraný účelu, na ktorý bol prístup poskytnutý.
3. Ak technické možnosti umožňujú obmedziť oprávnenia iba na konkrétnu službu, účet, databázu alebo inú časť systému, má sa uprednostniť takýto obmedzený prístup pred poskytovaním širších administrátorských práv.
4. Zákazník by mal podľa technických možností používať samostatné účty pre jednotlivé osoby namiesto zdieľania jedného spoločného administrátorského účtu.
5. Zákazník zodpovedá za ochranu:

• FTP a SFTP hesiel,
• SSH hesiel,
• SSH privátnych kľúčov,
• administrátorských účtov,
• databázových prístupov,
• a ďalších privilegovaných autentifikačných údajov.

6. Pri SSH prístupe sa odporúča používanie bezpečnej autentifikácie a primeraná ochrana privátnych kľúčov pred neoprávneným použitím.
7. Privátny SSH kľúč nesmie byť sprístupnený osobe, ktorá nemá mať príslušný prístup.
8. Zákazník zodpovedá za osoby, ktorým svoje administrátorské alebo technické prístupy poskytne.
9. Osobitne ide najmä o:

• zamestnancov,
• externých administrátorov,
• programátorov,
• agentúry,
• dodávateľov,
• servisných pracovníkov,
• alebo iných spolupracovníkov.

10. Po skončení potreby prístupu je Zákazník povinný príslušný účet, oprávnenie, heslo, SSH kľúč alebo iný prístup primerane zrušiť alebo zneplatniť.
11. Osobitne sa odporúča bezodkladne zrušiť alebo preveriť prístupy:

• bývalých zamestnancov,
• bývalých dodávateľov,
• agentúr,
• programátorov,
• externých administrátorov,
• a osôb, ktorých pracovný alebo zmluvný vzťah so Zákazníkom skončil.

12. Samotná zmena hlavného hesla nemusí postačovať, ak daná osoba mala aj:

• vlastný používateľský účet,
• SSH kľúč,
• API kľúč,
• databázový prístup,
• uložený autentifikačný token,
• alebo iný samostatný spôsob prístupu.

13. Zákazník by preto mal pri ukončení prístupu preveriť všetky relevantné autentifikačné mechanizmy.
14. Ak má Zákazník dôvodné podozrenie na kompromitáciu FTP, SFTP, SSH alebo administrátorského prístupu, je povinný primerane reagovať, najmä:

• zmeniť alebo zneplatniť príslušné heslo,
• odstrániť podozrivý SSH kľúč,
• skontrolovať používateľské účty,
• preveriť vykonané zmeny,
• a podľa okolností zmeniť aj ďalšie súvisiace prístupové údaje.

15. Zákazník zodpovedá za úkony vykonané prostredníctvom jeho platných prístupových údajov v rozsahu, v akom boli tieto údaje pod jeho kontrolou alebo kontrolou osoby, ktorej ich poskytol.
16. Samotná skutočnosť, že bol určitý úkon vykonaný prostredníctvom platného FTP, SSH alebo administrátorského prístupu, nepreukazuje bezpečnostné zlyhanie infraštruktúry WebHouse.
17. Ak útočník použije platné prístupové údaje získané napríklad phishingom, malvérom, kompromitovaným zariadením alebo od osoby, ktorej ich Zákazník poskytol, zodpovednosť sa posudzuje podľa skutočnej príčiny kompromitácie.
18. Ak však k získaniu alebo zneužitiu prístupových údajov dôjde v dôsledku bezpečnostnej chyby alebo porušenia povinnosti v systéme spravovanom WebHouse, zodpovednosť sa posudzuje podľa tejto skutočnej príčiny.
19. WebHouse môže z bezpečnostných dôvodov obmedziť alebo zablokovať prístup, ktorý vykazuje znaky kompromitácie, automatizovaného útoku alebo iného nebezpečného použitia.
20. WebHouse môže pri podozrení na kompromitáciu požadovať reset hesla, výmenu SSH kľúča alebo iné primerané bezpečnostné opatrenie pred obnovením plného prístupu.
21. Takýto bezpečnostný zásah sám osebe neznamená určenie zodpovednosti za vznik incidentu.
22. Ak Zákazník poskytne WebHouse dočasný administrátorský prístup na účely technického zásahu, mal by byť podľa možností:

• časovo obmedzený,
• rozsahom primeraný,
• samostatný od bežného administrátorského účtu,
• a po skončení zásahu zrušený alebo zneplatnený.

23. Jednorazové poskytnutie administrátorského prístupu pracovníkovi WebHouse neznamená automaticky prevzatie ďalšej správy systému zo strany WebHouse.
24. WebHouse zodpovedá za ochranu administrátorských prístupov, ktoré používa vo svojich vlastných systémoch a ktoré má pod svojou správou.
25. Ak konkrétna služba používa osobitné pravidlá pre FTP, SSH, administrátorské oprávnenia alebo vzdialený prístup, majú tieto pravidlá vo vzťahu k danej službe prednosť.

Článok 18

Aktualizácie a podporované technológie

1. Zákazník je povinný používať softvér, ktorý je z hľadiska svojej funkcie a rizika primerane udržiavaný a bezpečný.
2. Používanie nepodporovaného, zastaraného alebo dlhodobo neaktualizovaného softvéru môže predstavovať zvýšené bezpečnostné a prevádzkové riziko.
3. Zákazník zodpovedá za aktualizáciu softvéru, ktorý je v jeho správe, najmä:

• CMS,
• pluginov,
• tém,
• frameworkov,
• knižníc,
• vlastných aplikácií,
• a ďalších aplikačných komponentov.

4. WebHouse zodpovedá za aktualizáciu a bezpečnostnú údržbu technológií a systémového softvéru, ktoré sú podľa konkrétnej služby v jeho správe.
5. WebHouse môže z bezpečnostných, technických alebo prevádzkových dôvodov ukončiť podporu zastaranej technológie.
6. WebHouse môže najmä:

• ukončiť jej štandardnú podporu,
• obmedziť jej dostupnosť,
• presunúť ju do osobitne spoplatneného režimu,
• obmedziť jej použitie na vybrané služby,
• alebo požadovať prechod na podporovanú verziu.

7. Takýto postup môže byť odôvodnený najmä tým, že:

• výrobca alebo autor technológiu prestal podporovať,
• už nie sú dostupné bezpečnostné opravy,
• technológia obsahuje známe bezpečnostné riziká,
• jej ďalšia prevádzka ohrozuje stabilitu alebo bezpečnosť služby,
• alebo jej ďalšia údržba nie je primerane technicky udržateľná.

8. WebHouse nie je povinný dlhodobo prevádzkovať zastaranú alebo bezpečnostne nevhodnú technológiu iba z dôvodu zachovania kompatibility so staršou aplikáciou Zákazníka.
9. Zákazník zodpovedá za kompatibilitu svojej aplikácie s aktuálne podporovaným prostredím služby.
10. Zákazník je povinný primerane prispôsobiť svoju aplikáciu zmenám podporovaných technológií, ak je to potrebné na jej ďalšiu bezpečnú a funkčnú prevádzku.
11. Samotná skutočnosť, že aplikácia Zákazníka prestane po prechode na novšiu podporovanú technológiu fungovať, neznamená automaticky poruchu služby WebHouse.
12. Ak je príčinou nefunkčnosti nekompatibilný, zastaraný alebo nesprávne naprogramovaný softvér Zákazníka, zodpovednosť za jeho úpravu nesie Zákazník.
13. Ak však nefunkčnosť vznikne v dôsledku chyby v technológii alebo konfigurácii, ktorú mal podľa služby spravovať WebHouse, zodpovednosť sa posudzuje podľa tejto skutočnej príčiny.
14. Ak to povaha zmeny a okolnosti umožňujú, WebHouse môže Zákazníka primerane informovať o plánovanom ukončení podpory alebo významnej zmene podporovanej technológie.
15. Rozsah a spôsob informovania môže závisieť od charakteru služby, závažnosti zmeny a bezpečnostného rizika.
16. V prípade závažného alebo bezprostredného bezpečnostného rizika môže byť potrebné technológiu obmedziť alebo deaktivovať aj bez dlhšieho prechodného obdobia, ak je to primerané ochrane infraštruktúry a ostatných zákazníkov.
17. Ukončenie štandardnej podpory technológie nemusí automaticky znamenať jej okamžité technické odstránenie zo všetkých služieb.
18. WebHouse môže podľa technických možností určitú zastaranú technológiu dočasne ponechať dostupnú v obmedzenom alebo osobitne spoplatnenom režime.
19. Takéto dočasné ponechanie technológie neznamená, že WebHouse garantuje jej dlhodobú dostupnosť alebo rovnakú úroveň bezpečnosti ako pri aktuálne podporovanej technológii.
20. Ak Zákazník používa zastaranú technológiu napriek dostupnosti podporovanej alternatívy, nesie zvýšené riziko súvisiace s kompatibilitou a bezpečnosťou svojej aplikácie v rozsahu svojej správy.
21. WebHouse môže odmietnuť aktivovať alebo opätovne sprístupniť zastaranú technológiu, ak by jej použitie predstavovalo neprimerané bezpečnostné alebo prevádzkové riziko.
22. WebHouse nie je povinný oslabovať bezpečnostné mechanizmy svojej infraštruktúry iba preto, aby umožnil prevádzku zastaraného alebo nekompatibilného softvéru Zákazníka.
23. Ak konkrétna služba výslovne garantuje podporu určitej technológie alebo verzie počas konkrétneho obdobia, WebHouse je povinný rešpektovať túto garanciu v dohodnutom rozsahu.
24. Všeobecné ustanovenia o ukončení podpory technológií nemožno použiť na obchádzanie konkrétne dohodnutej povinnosti alebo garancie WebHouse.
25. Konkrétne podporované technológie, verzie, prípadné prechodné obdobia a osobitné režimy môžu byť upravené v technických parametroch alebo osobitných podmienkach jednotlivých služieb.

Článok 19

Zraniteľnosti

1. Zistenie zraniteľnosti v systéme, aplikácii alebo inom komponente neznamená automaticky, že došlo k jej zneužitiu.
2. Samotná existencia zraniteľnosti preto nepreukazuje vznik bezpečnostného incidentu ani kompromitáciu dát.
3. Rovnako zistenie kompromitácie neznamená automaticky, že je možné spoľahlivo určiť:

• spôsob útoku,
• použitú zraniteľnosť,
• presný čas prvotného napadnutia,
• všetky následné kroky útočníka,
• identitu útočníka,
• alebo všetky dotknuté údaje.

4. Možnosť spätne určiť priebeh incidentu závisí najmä od dostupných logov, ich rozsahu a retencie, technického charakteru incidentu a stavu systému po jeho zistení.
5. Skutočnosť, že presný vektor útoku nie je možné jednoznačne určiť, sama osebe nepreukazuje zodpovednosť WebHouse ani Zákazníka.
6. Pri posudzovaní incidentu sa vychádza z dostupných technických zistení a zo skutočnej vrstvy, v ktorej bola zistená príčina alebo bezpečnostný nedostatok.
7. Ak WebHouse zistí kritickú alebo inak závažnú zraniteľnosť vo svojej spravovanej vrstve, môže bezodkladne vykonať primerané opatrenia potrebné na jej odstránenie alebo obmedzenie rizika.
8. Ak WebHouse zistí kritickú zraniteľnosť v aplikácii alebo komponente spravovanom Zákazníkom, môže Zákazníka vyzvať na jej odstránenie alebo vykonať ochranné opatrenia potrebné na ochranu infraštruktúry a ostatných zákazníkov.
9. WebHouse môže pri bezprostrednom bezpečnostnom riziku vykonať primerané opatrenie aj bez predchádzajúceho súhlasu Zákazníka, ak by odklad mohol viesť k:

• napadnutiu infraštruktúry,
• šíreniu škodlivej aktivity,
• neoprávnenému prístupu,
• úniku alebo poškodeniu dát,
• zneužitiu služby,
• alebo ohrozeniu ostatných zákazníkov.

10. Ochranné opatrenie môže podľa povahy rizika zahŕňať najmä:

• dočasné obmedzenie služby,
• zablokovanie konkrétneho prístupu,
• deaktiváciu zraniteľného komponentu,
• izoláciu služby alebo účtu,
• úpravu bezpečnostnej konfigurácie v spravovanej vrstve,
• alebo iné primerané technické opatrenie.

11. Rozsah zásahu má byť primeraný povahe, pravdepodobnosti a možným následkom bezpečnostného rizika.
12. WebHouse môže uprednostniť okamžité obmedzenie rizika pred zachovaním úplnej dostupnosti konkrétnej služby, ak je to nevyhnutné na ochranu infraštruktúry alebo ostatných zákazníkov.
13. Vykonanie preventívneho alebo ochranného opatrenia samo osebe neznamená, že už došlo k zneužitiu zraniteľnosti.
14. Rovnako vykonanie takéhoto opatrenia samo osebe neznamená uznanie zodpovednosti WebHouse za vznik zraniteľnosti alebo incidentu.
15. Ak sa zraniteľnosť nachádza v komponente spravovanom Zákazníkom, Zákazník zodpovedá za jej primerané odstránenie, najmä aktualizáciou, opravou, výmenou alebo deaktiváciou dotknutého komponentu.
16. Ak zraniteľnosť vznikne v technickej vrstve spravovanej WebHouse, WebHouse zodpovedá za primeranú reakciu a nápravu v rozsahu svojich povinností.
17. Dostupnosť bezpečnostnej opravy neznamená vždy možnosť jej okamžitého nasadenia; pri jej aplikácii môže byť potrebné zohľadniť kompatibilitu, stabilitu, spôsob nasadenia a riziko samotnej zmeny.
18. Pri kritickej zraniteľnosti môže WebHouse do času nasadenia opravy použiť aj dočasné kompenzačné opatrenia, ak primerane znižujú riziko jej zneužitia.
19. Ak Zákazník pokračuje v používaní známeho zraniteľného komponentu napriek primeranému upozorneniu a dostupnej možnosti nápravy, nesie zvýšené riziko vyplývajúce z jeho ďalšieho používania v rozsahu svojej správy.
20. Toto ustanovenie nemožno vykladať tak, že samotné oznámenie zraniteľnosti zbavuje WebHouse povinnosti odstrániť alebo primerane riešiť zraniteľnosť v technickej vrstve, ktorú spravuje WebHouse.
21. Ak konkrétna bezpečnostná alebo managed služba obsahuje osobitné podmienky pre monitoring zraniteľností, patch management alebo reakciu na bezpečnostné incidenty, majú tieto podmienky pred týmto všeobecným ustanovením prednosť.

Článok 20

Automatizované bezpečnostné systémy

1. WebHouse môže na ochranu svojej infraštruktúry, služieb a zákazníkov používať automatizované bezpečnostné mechanizmy.
2. Môže ísť najmä o:

• firewall,
• IDS/IPS,
• Fail2Ban alebo obdobné mechanizmy,
• rate limiting,
• antispam,
• antimalware,
• reputačné databázy,
• anti-DDoS mechanizmy,
• automatizovanú izoláciu,
• blokovanie IP adries,
• blokovanie portov,
• obmedzovanie spojení,
• alebo iné automatizované ochranné pravidlá.

3. Automatizované bezpečnostné systémy vyhodnocujú prevádzku podľa technických pravidiel, vzorov správania, reputačných údajov, limitov alebo iných bezpečnostných ukazovateľov.
4. Ich účelom je najmä obmedzenie útokov, zneužívania služieb, automatizovaných pokusov o prienik, škodlivej komunikácie a iných bezpečnostných rizík.
5. Automatizovaný bezpečnostný systém môže v odôvodnených prípadoch dočasne obmedziť aj legitímnu prevádzku.
6. Môže ísť napríklad o:

• dočasné zablokovanie legitímnej IP adresy,
• obmedzenie väčšieho počtu spojení,
• zadržanie legitímnej e-mailovej správy,
• obmedzenie prístupu po opakovaných neúspešných prihláseniach,
• alebo iný obdobný zásah spôsobený bezpečnostným vyhodnotením prevádzky.

7. Samotný výskyt takéhoto false positive prípadu neznamená automaticky nesprávne fungovanie alebo vadu služby.
8. Takéto obmedzenie samo osebe nepredstavuje vadu služby, ak bolo vzhľadom na dostupné informácie primerané bezpečnostnému riziku a vykonané v súlade so zmluvnými podmienkami.
9. WebHouse môže automatizované bezpečnostné pravidlá priebežne meniť, upravovať alebo dopĺňať podľa vývoja bezpečnostných hrozieb a spôsobov zneužívania služieb.
10. WebHouse nie je povinný Zákazníkovi sprístupniť úplnú konfiguráciu, pravidlá, prahové hodnoty alebo detekčné mechanizmy svojich bezpečnostných systémov, ak by ich zverejnenie mohlo znížiť účinnosť ochrany.
11. Ak automatizované opatrenie neprimerane alebo opakovane obmedzuje legitímnu prevádzku, WebHouse môže po preverení upraviť príslušné pravidlo, výnimku alebo spôsob ochrany, ak je to technicky a bezpečnostne vhodné.
12. Zákazník môže pri podozrení na nesprávnu blokáciu požiadať technickú podporu o preverenie príslušného bezpečnostného opatrenia.
13. WebHouse nie je povinný zrušiť bezpečnostné opatrenie iba preto, že obmedzuje požadovanú prevádzku, ak jeho odstránenie predstavuje neprimerané bezpečnostné riziko.
14. WebHouse môže namiesto úplného odstránenia ochrany navrhnúť bezpečnejšie technické riešenie.
15. Automatizované bezpečnostné opatrenie môže byť vykonané bez predchádzajúceho súhlasu Zákazníka, ak je to potrebné na bezodkladnú ochranu infraštruktúry, služby alebo ostatných zákazníkov.
16. Rozsah automatizovaného zásahu má byť primeraný charakteru zisteného alebo predpokladaného bezpečnostného rizika.
17. Ak dôvod blokácie alebo obmedzenia pominie, bezpečnostný mechanizmus môže prístup automaticky alebo po preverení opätovne umožniť podľa charakteru konkrétneho systému.
18. WebHouse môže pri opakovanom alebo závažnom zneužívaní uplatniť dlhšie alebo prísnejšie bezpečnostné obmedzenie, ak je to primerané okolnostiam.
19. Používanie automatizovaných bezpečnostných systémov nepredstavuje garanciu, že bude zachytený každý útok, pokus o prienik, škodlivý súbor alebo iná bezpečnostná hrozba.
20. Samotná skutočnosť, že určitý útok nebol automatizovaným systémom zablokovaný, nepreukazuje porušenie bezpečnostnej povinnosti WebHouse.
21. Ak však bezpečnostný incident vznikne v dôsledku nedostatočného zabezpečenia alebo porušenia povinnosti v technickej vrstve spravovanej WebHouse, zodpovednosť sa posudzuje podľa tejto skutočnej príčiny.
22. Automatizované bezpečnostné opatrenie nemožno použiť na obchádzanie konkrétne dohodnutej povinnosti alebo garancie WebHouse, pokiaľ osobitné bezpečnostné pravidlá neustanovujú oprávnené obmedzenie služby.
23. Podrobnejšie pravidlá bezpečnostných zásahov, obmedzenia alebo pozastavenia služby môžu upravovať ďalšie bezpečnostné alebo prevádzkové podmienky WebHouse.

Článok 21

DDoS a DoS útoky

1. WebHouse môže používať technické a organizačné opatrenia na prevenciu, detekciu a zmierňovanie DDoS alebo DoS útokov.
2. Úplná ochrana pred všetkými typmi, intenzitou a trvaním DDoS alebo DoS útokov nie je garantovaná, pokiaľ konkrétna služba výslovne nestanovuje inak.
3. Pri útoku alebo dôvodnom podozrení na útok môže WebHouse najmä:

• filtrovať prevádzku,
• aplikovať rate limiting,
• zablokovať konkrétne IP adresy alebo zdrojové siete,
• obmedziť alebo blokovať vybrané protokoly alebo porty,
• presmerovať prevádzku,
• aktivovať dostupné anti-DDoS mechanizmy,
• obmedziť počet spojení,
• alebo dočasne izolovať cieľovú službu.

4. Rozsah ochranných opatrení závisí od charakteru útoku, technických možností infraštruktúry a parametrov konkrétnej služby.
5. Ochranné opatrenia nemusia vždy viesť k úplnému zachovaniu dostupnosti napadnutej služby.
6. Pri rozsiahlejšom útoku môže byť technicky nevyhnutné určitú časť prevádzky obmedziť aj za cenu dočasného zhoršenia dostupnosti alebo funkčnosti napadnutej služby.
7. DDoS ochrana môže v niektorých prípadoch zasiahnuť aj legitímnu prevádzku, najmä ak ju nemožno spoľahlivo odlíšiť od útočnej komunikácie.
8. Takéto primerané bezpečnostné obmedzenie samo osebe nepredstavuje vadu služby, ak bolo vykonané na ochranu infraštruktúry, služby alebo ostatných zákazníkov v súlade so zmluvnými podmienkami.
9. Ochrana celej infraštruktúry a ostatných zákazníkov môže mať v prípade rozsiahleho útoku prednosť pred zachovaním plnej dostupnosti jednej napadnutej služby.
10. WebHouse môže pri mimoriadne intenzívnom alebo dlhodobom útoku dočasne uplatniť prísnejšie ochranné opatrenia, ak je to potrebné na zabránenie širšiemu dopadu na infraštruktúru.
11. WebHouse nie je povinný zachovať prístup zo všetkých zdrojových sietí, protokolov alebo geografických oblastí, ak ich dočasné obmedzenie predstavuje primerané opatrenie na zmiernenie útoku.
12. Samotná skutočnosť, že DDoS alebo DoS útok spôsobil dočasnú nedostupnosť alebo zhoršenie služby, automaticky nepreukazuje porušenie bezpečnostnej povinnosti WebHouse.
13. Pri posudzovaní zodpovednosti sa prihliada najmä na charakter útoku, rozsah dohodnutej ochrany a primeranosť opatrení, ktoré mal WebHouse podľa konkrétnej služby vykonať.
14. Ak konkrétna služba výslovne zahŕňa definovanú úroveň DDoS ochrany alebo inú bezpečnostnú garanciu, rozsah povinností WebHouse sa riadi podmienkami tejto služby.
15. Všeobecné ustanovenie o neexistencii absolútnej DDoS ochrany nemožno použiť na obchádzanie konkrétne dohodnutej bezpečnostnej alebo dostupnostnej garancie.
16. Ak je útok spôsobený alebo zosilnený nesprávnou konfiguráciou alebo zneužitím systému spravovaného Zákazníkom, WebHouse môže požadovať primeranú súčinnosť Zákazníka pri odstránení príčiny alebo znížení dopadu incidentu.
17. WebHouse môže po skončení alebo zmiernení útoku ochranné opatrenia primerane upraviť alebo odstrániť podľa aktuálneho bezpečnostného rizika.
18. WebHouse nemusí Zákazníkovi sprístupniť úplné technické detaily anti-DDoS mechanizmov, filtrov alebo detekčných pravidiel, ak by ich zverejnenie mohlo znížiť účinnosť ochrany.
19. Konkrétne parametre anti-DDoS ochrany, ak sú súčasťou služby, môžu byť upravené v technických parametroch, SLA alebo osobitných podmienkach konkrétnej služby.

Článok 22

Bezpečnostné zásahy Poskytovateľa

1. WebHouse je oprávnený vykonať bezodkladný bezpečnostný zásah, ak existuje dôvodné podozrenie, že služba:

• bola kompromitovaná,
• šíri malware,
• rozosiela spam,
• je súčasťou botnetu,
• vykonáva útoky,
• generuje nebezpečnú alebo škodlivú prevádzku,
• slúži na neoprávnené prístupy,
• ohrozuje infraštruktúru WebHouse,
• ohrozuje ostatných zákazníkov,
• alebo ohrozuje tretie osoby.

2. Na vykonanie bezodkladného bezpečnostného zásahu nemusí byť vopred definitívne preukázaná presná príčina incidentu, ak by odklad mohol zvýšiť rozsah škody alebo bezpečnostného rizika.
3. WebHouse môže pri výbere opatrenia vychádzať najmä z:

• monitoringu,
• systémových logov,
• sieťovej prevádzky,
• bezpečnostných upozornení,
• hlásení tretích strán,
• reputačných databáz,
• detekcie škodlivého správania,
• alebo iných primeraných technických podkladov.

4. Bezpečnostný zásah môže zahŕňať najmä:

• zablokovanie alebo obmedzenie sieťovej komunikácie,
• zablokovanie konkrétneho portu,
• zablokovanie IP adresy alebo rozsahu adries,
• aplikovanie rate limitingu,
• pozastavenie webovej stránky,
• obmedzenie alebo deaktiváciu PHP,
• zablokovanie odosielania e-mailov,
• deaktiváciu alebo obmedzenie účtu,
• zablokovanie konkrétneho prístupového mechanizmu,
• izoláciu VPS alebo servera,
• alebo dočasné pozastavenie služby.

5. WebHouse môže podľa technických možností obmedziť zásah iba na tú časť služby, ktorá predstavuje bezpečnostné riziko.
6. Ak však čiastočné obmedzenie nie je technicky možné, dostatočné alebo bezpečné, WebHouse môže obmedziť alebo pozastaviť aj širší rozsah služby.
7. Rozsah bezpečnostného zásahu má byť primeraný povahe, závažnosti a pravdepodobným následkom zisteného alebo dôvodne predpokladaného rizika.
8. WebHouse nie je povinný ponechať nebezpečnú službu v prevádzke iba preto, že bezpečnostný incident ešte nebol úplne zanalyzovaný.
9. Ochrana infraštruktúry, ostatných zákazníkov a tretích osôb môže mať pri bezprostrednom bezpečnostnom riziku prednosť pred nepretržitou dostupnosťou individuálnej služby.
10. Bezpečnostný zásah môže byť vykonaný aj bez predchádzajúceho súhlasu Zákazníka, ak je potrebné konať bezodkladne.
11. Ak to okolnosti umožňujú, WebHouse môže Zákazníka o vykonanom bezpečnostnom zásahu primerane informovať.
12. Nemožnosť kontaktovať Zákazníka alebo získať jeho stanovisko sama osebe nebráni vykonaniu nevyhnutného bezpečnostného opatrenia.
13. Vykonanie bezpečnostného zásahu samo osebe neznamená, že WebHouse definitívne určil príčinu incidentu alebo zodpovednosť za jeho vznik.
14. Rovnako vykonanie ochranného opatrenia nepredstavuje samo osebe uznanie zodpovednosti WebHouse za kompromitáciu služby.
15. Ak sa následne preukáže, že bezpečnostné riziko nevzniklo alebo pominulo, WebHouse môže primerane obnoviť alebo uvoľniť obmedzenú službu.
16. Obnovenie služby môže byť podmienené odstránením alebo primeraným obmedzením príčiny incidentu.
17. Ak sa príčina nachádza v technickej vrstve spravovanej Zákazníkom, WebHouse môže pred obnovením plnej prevádzky požadovať najmä:

• aktualizáciu zraniteľnej aplikácie,
• odstránenie škodlivého kódu,
• odstránenie zraniteľného pluginu alebo komponentu,
• zmenu kompromitovaných hesiel,
• zneplatnenie kompromitovaných kľúčov alebo tokenov,
• opravu nesprávnej konfigurácie,
• alebo iné primerané bezpečnostné opatrenie.

18. WebHouse nie je povinný obnoviť plnú prevádzku služby, pokiaľ existuje dôvodné riziko, že po obnovení bude bezprostredne pokračovať škodlivá alebo nebezpečná aktivita.
19. Ak sa príčina incidentu nachádza v technickej vrstve spravovanej WebHouse, WebHouse zodpovedá za primerané odstránenie alebo zmiernenie tejto príčiny v rozsahu svojich povinností.
20. WebHouse môže pri riešení incidentu vykonať aj dočasné opatrenie, ktoré nezodpovedá konečnému spôsobu nápravy, ak je potrebné najprv zastaviť alebo obmedziť škodlivú aktivitu.
21. Bezpečnostný zásah nemusí znamenať odstránenie pôvodnej príčiny incidentu.
22. Napríklad zablokovanie odosielania e-mailov, izolácia VPS alebo vypnutie webovej stránky môže zastaviť ďalšie škodlivé prejavy, ale nemusí odstrániť kompromitovaný účet, zraniteľnosť aplikácie alebo škodlivý kód.
23. Zákazník je povinný poskytnúť primeranú súčinnosť potrebnú na odstránenie príčiny incidentu v časti služby, ktorú spravuje.
24. Ak Zákazník potrebnú súčinnosť neposkytne, WebHouse môže bezpečnostné obmedzenie ponechať v platnosti, ak jeho odstránenie predstavuje neprimerané riziko.
25. Bezpečnostný zásah môže dočasne ovplyvniť aj legitímnu prevádzku Zákazníka.
26. Takéto obmedzenie samo osebe nepredstavuje vadu služby, ak bolo vzhľadom na dostupné informácie primerané bezpečnostnému riziku a vykonané v súlade so zmluvnými podmienkami.
27. Toto ustanovenie nemožno vykladať tak, že WebHouse nezodpovedá za neprimeraný alebo nesprávne vykonaný bezpečnostný zásah, ak jeho pochybením vznikla Zákazníkovi škoda alebo bola porušená konkrétna povinnosť WebHouse.
28. WebHouse môže pri zásahu uprednostniť technicky bezpečnejší postup pred postupom požadovaným Zákazníkom.
29. WebHouse nie je povinný vykonať pokyn Zákazníka, ktorý by viedol k opätovnému sprístupneniu zjavne kompromitovanej alebo nebezpečnej služby bez primeraného odstránenia rizika.
30. Podrobnejšie pravidlá pozastavenia, obmedzenia alebo obnovenia služby môžu upravovať najmä dokumenty „Ochrana infraštruktúry a siete“ a „Pravidlá férového používania, zneužitia služieb a incidentov“.
31. Ak konkrétna služba obsahuje osobitné bezpečnostné alebo SLA pravidlá, uplatnia sa v príslušnom rozsahu prednostne tieto konkrétne podmienky.

Článok 23

Prednosť ochrany infraštruktúry

1. Ak je to potrebné na zabránenie závažnej škode alebo bezpečnostného incidentu, ochrana:

• infraštruktúry,
• siete,
• ostatných zákazníkov,
• dát,
• tretích osôb

môže mať prednosť pred nepretržitou dostupnosťou individuálnej služby.

2. WebHouse je oprávnený vykonať primerané ochranné opatrenia aj vtedy, ak môžu dočasne obmedziť alebo prerušiť dostupnosť konkrétnej služby.
3. Takéto opatrenie môže byť odôvodnené najmä v prípade, ak pokračovanie prevádzky predstavuje riziko:

• ďalšieho šírenia škodlivej aktivity,
• kompromitácie ďalších systémov,
• poškodenia alebo úniku dát,
• zneužitia sieťovej infraštruktúry,
• narušenia stability spoločnej platformy,
• alebo významného negatívneho dopadu na ostatných zákazníkov.

4. WebHouse pri bezpečnostnom zásahu postupuje primerane okolnostiam, závažnosti a rozsahu rizika.
5. Pri výbere opatrenia môže WebHouse prihliadať najmä na:

• pravdepodobnosť vzniku škody,
• možný rozsah následkov,
• počet dotknutých služieb alebo zákazníkov,
• technickú možnosť izolovať iba konkrétnu časť služby,
• a naliehavosť situácie.

6. Ak je to technicky možné a bezpečné, WebHouse sa usiluje obmedziť zásah iba na časť služby alebo prevádzky, ktorá predstavuje bezpečnostné riziko.
7. Ak čiastočné opatrenie nie je dostatočné alebo technicky možné, môže WebHouse obmedziť alebo pozastaviť aj širší rozsah služby.
8. Ak je to možné bez neprimeraného bezpečnostného alebo prevádzkového rizika, WebHouse sa usiluje minimalizovať rozsah a trvanie obmedzenia.
9. WebHouse nie je povinný zachovať úplnú dostupnosť individuálnej služby, ak by tým vzniklo neprimerané riziko pre spoločnú infraštruktúru alebo ostatných zákazníkov.
10. Ochranné opatrenie môže byť vykonané aj bez predchádzajúceho súhlasu Zákazníka, ak je potrebné konať bezodkladne.
11. Nemožnosť vopred kontaktovať Zákazníka sama osebe nebráni vykonaniu nevyhnutného bezpečnostného zásahu.
12. Samotné vykonanie ochranného opatrenia neznamená automaticky, že bola určená konečná príčina incidentu alebo zodpovednosť za jeho vznik.
13. Ak dôvod bezpečnostného obmedzenia pominie alebo je primerane odstránený, WebHouse môže službu alebo jej dotknutú časť obnoviť.
14. Obnovenie služby môže byť podmienené primeraným odstránením príčiny incidentu alebo vykonaním bezpečnostných opatrení potrebných na zabránenie jeho bezprostrednému opakovaniu.
15. Ak sa príčina incidentu nachádza v technickej vrstve spravovanej Zákazníkom, WebHouse môže požadovať primeranú súčinnosť Zákazníka pred úplným obnovením služby.
16. Ak sa príčina incidentu nachádza v technickej vrstve spravovanej WebHouse, WebHouse zodpovedá za primerané odstránenie alebo obmedzenie tejto príčiny v rozsahu svojich povinností.
17. Dočasné obmedzenie služby vykonané z primeraného bezpečnostného dôvodu samo osebe nepredstavuje vadu služby, ak bolo vykonané v súlade so zmluvnými podmienkami.
18. Toto ustanovenie však nemožno vykladať tak, že WebHouse nezodpovedá za neprimeraný, zjavne nesprávny alebo nesprávne vykonaný bezpečnostný zásah.
19. Rovnako ho nemožno použiť na obchádzanie konkrétnej bezpečnostnej, dostupnostnej alebo SLA povinnosti WebHouse, pokiaľ z príslušných podmienok nevyplýva oprávnenie službu z bezpečnostných dôvodov obmedziť.
20. Ak konkrétna služba alebo bezpečnostný dokument upravuje ochranné zásahy podrobnejšie, použijú sa tieto osobitné pravidlá v príslušnom rozsahu.

Článok 24

Predchádzajúce upozornenie

1. Bezpečnostný zásah nemusí byť Zákazníkovi vopred oznámený, ak je potrebné konať bezodkladne na ochranu infraštruktúry, služby, dát, ostatných zákazníkov alebo tretích osôb.
2. Predchádzajúce upozornenie sa nevyžaduje najmä vtedy, ak:

• incident už prebieha,
• hrozí bezprostredná škoda,
• dochádza k útoku,
• dochádza k šíreniu malvéru,
• dochádza k rozosielaniu spamu alebo inej škodlivej komunikácie,
• služba ohrozuje alebo poškodzuje ostatných zákazníkov,
• dochádza k neoprávnenému prístupu alebo jeho dôvodnému podozreniu,
• alebo by odklad zásahu zvýšil bezpečnostné riziko.

3. WebHouse nie je povinný čakať na súhlas Zákazníka, ak by takéto čakanie mohlo viesť k rozšíreniu incidentu alebo zvýšeniu jeho následkov.
4. Nemožnosť Zákazníka kontaktovať, jeho nedostupnosť alebo oneskorená reakcia nebráni vykonaniu primeraného neodkladného bezpečnostného opatrenia.
5. Ak situácia nevyžaduje okamžitý zásah a predchádzajúce upozornenie je možné bez neprimeraného rizika, WebHouse môže Zákazníka vyzvať na odstránenie problému alebo poskytnutie súčinnosti pred vykonaním obmedzenia.
6. Poskytnutie lehoty na nápravu nie je povinné v prípade bezprostredného alebo závažného bezpečnostného rizika.
7. Ak WebHouse Zákazníkovi poskytne lehotu na nápravu a Zákazník problém v stanovenej primeranej lehote neodstráni, môže WebHouse vykonať potrebné ochranné opatrenie.
8. WebHouse môže Zákazníka o vykonanom bezpečnostnom zásahu informovať po jeho uskutočnení.
9. Následná informácia môže podľa okolností obsahovať najmä:

• identifikáciu dotknutej služby,
• základný dôvod zásahu,
• rozsah vykonaného obmedzenia,
• požadovanú súčinnosť Zákazníka,
• a podmienky potrebné na obnovenie služby.

10. WebHouse nie je povinný v oznámení zverejniť úplné technické detaily bezpečnostného mechanizmu, detekčných pravidiel alebo interných postupov, ak by ich zverejnenie mohlo znížiť bezpečnosť infraštruktúry.
11. WebHouse nemusí poskytnúť informácie, ktorých zverejnenie by mohlo:

• ohroziť vyšetrovanie incidentu,
• uľahčiť ďalšie zneužitie,
• odhaliť citlivé bezpečnostné mechanizmy,
• alebo ohroziť práva či bezpečnosť tretích osôb.

12. Samotná skutočnosť, že bezpečnostný zásah nebol vopred oznámený, neznamená jeho neoprávnenosť, ak boli splnené podmienky pre neodkladný zásah.
13. Vykonanie zásahu bez predchádzajúceho upozornenia samo osebe neznamená, že WebHouse definitívne určil príčinu incidentu alebo zodpovednosť za jeho vznik.
14. Ak sa následne preukáže, že riziko bolo menšie, než sa pôvodne javilo, posudzuje sa primeranosť zásahu podľa informácií, ktoré mal WebHouse primerane k dispozícii v čase rozhodovania.
15. Ak dôvod bezpečnostného obmedzenia pominie alebo je primerane odstránený, WebHouse môže obmedzenie zrušiť alebo upraviť.
16. Ak je na obnovenie služby potrebná súčinnosť Zákazníka, WebHouse môže požadovať jej poskytnutie pred úplným obnovením prevádzky.
17. Toto ustanovenie nemožno vykladať tak, že WebHouse môže bezdôvodne alebo neprimerane obmedzovať službu bez informovania Zákazníka.
18. Rovnako ho nemožno použiť na obchádzanie konkrétnej povinnosti WebHouse informovať Zákazníka, ak takáto povinnosť vyplýva z osobitných podmienok služby, SLA alebo záväzných právnych predpisov.
19. Podrobnejšie pravidlá bezpečnostných zásahov, obmedzenia a obnovy služby môžu upravovať osobitné bezpečnostné alebo prevádzkové podmienky WebHouse.

Článok 25

Obnovenie služby po incidente

1. Služba môže byť obnovená po odstránení alebo primeranom obmedzení príčiny bezpečnostného incidentu.
2. Obnovenie môže byť podmienené najmä:

• odstránením škodlivého obsahu,
• zabezpečením aplikácie,
• zmenou kompromitovaných hesiel,
• zneplatnením kompromitovaných kľúčov alebo tokenov,
• aktualizáciou zraniteľného softvéru,
• odstránením alebo deaktiváciou zraniteľného komponentu,
• opravou nesprávnej konfigurácie,
• alebo prijatím iného primeraného nápravného opatrenia.

3. WebHouse môže pred obnovením služby požadovať od Zákazníka potvrdenie, že požadované bezpečnostné opatrenia boli vykonané.
4. Ak je to vzhľadom na charakter incidentu primerané, WebHouse môže požadovať aj doplňujúce technické informácie potrebné na posúdenie, či bezprostredné bezpečnostné riziko pominulo.
5. WebHouse nie je povinný vykonať úplný bezpečnostný audit zákazníckej aplikácie iba na účely rozhodnutia o obnovení služby.
6. Pri rozhodovaní o obnovení služby môže WebHouse vychádzať z dostupných technických informácií a z primeraného posúdenia aktuálneho rizika.
7. Ak existuje dôvodná obava, že služba zostáva kompromitovaná, zraniteľná alebo inak nebezpečná, WebHouse nie je povinný ju okamžite obnoviť.
8. To platí najmä vtedy, ak by obnovenie mohlo viesť k:

• pokračovaniu útoku,
• ďalšiemu šíreniu malvéru,
• rozosielaniu spamu,
• opätovnému zneužitiu kompromitovaného účtu,
• útokom na iné systémy,
• alebo ohrozeniu infraštruktúry a ostatných zákazníkov.

9. WebHouse môže podľa technických možností obnoviť najprv iba tú časť služby, ktorej prevádzka už nepredstavuje neprimerané bezpečnostné riziko.
10. Ak nie je možné bezpečne obnoviť iba časť služby, môže obmedzenie zostať zachované až do odstránenia podstatnej príčiny incidentu.
11. Ak sa príčina incidentu nachádza v technickej vrstve spravovanej Zákazníkom, Zákazník zodpovedá za vykonanie potrebných nápravných opatrení v tejto vrstve.
12. Ak sa príčina incidentu nachádza v technickej vrstve spravovanej WebHouse, WebHouse zodpovedá za primerané odstránenie alebo obmedzenie tejto príčiny v rozsahu svojich povinností.
13. WebHouse nemôže podmieňovať obnovenie služby odstránením nedostatku na strane Zákazníka, ak skutočná príčina incidentu vznikla výlučne v technickej vrstve spravovanej WebHouse.
14. Obnovenie služby po incidente neznamená automaticky potvrdenie, že aplikácia alebo systém Zákazníka neobsahuje žiadnu ďalšiu zraniteľnosť alebo škodlivý kód.
15. WebHouse preto obnovením služby negarantuje absolútnu bezpečnosť zákazníckej aplikácie, pokiaľ takýto audit alebo bezpečnostná správa nie sú súčasťou osobitne objednanej služby.
16. Obnova webovej stránky alebo dát zo zálohy sama osebe nemusí znamenať odstránenie príčiny incidentu.
17. Ak obnovená verzia obsahuje rovnakú zraniteľnosť, kompromitované prístupové údaje alebo škodlivý obsah, môže dôjsť k opakovaniu incidentu.
18. WebHouse môže preto pred obnovením plnej prevádzky požadovať, aby Zákazník vykonal aj opatrenia potrebné na odstránenie príčiny, nie iba následkov kompromitácie.
19. Ak Zákazník neposkytne primeranú súčinnosť potrebnú na bezpečné obnovenie služby, WebHouse môže príslušné obmedzenie ponechať v platnosti.
20. WebHouse môže po obnovení služby dočasne ponechať primerané bezpečnostné obmedzenia alebo zvýšený monitoring, ak je to potrebné na overenie, že škodlivá aktivita nepokračuje.
21. Ak sa po obnovení služby škodlivá aktivita opakuje, WebHouse môže službu opätovne obmedziť alebo izolovať.
22. Opätovné bezpečnostné obmedzenie nevyžaduje nové predchádzajúce upozornenie, ak je potrebné konať bezodkladne.
23. Samotné obnovenie služby nepredstavuje uznanie zodpovednosti WebHouse za pôvodný bezpečnostný incident.
24. Rovnako skutočnosť, že WebHouse službu dočasne neobnoví z dôvodu pretrvávajúceho primeraného bezpečnostného rizika, sama osebe nepredstavuje vadu služby.
25. Toto ustanovenie nemožno použiť na neodôvodnené predlžovanie obmedzenia služby po tom, čo bezpečnostný dôvod pre obmedzenie pominul.
26. Ak konkrétna služba, SLA alebo bezpečnostné podmienky upravujú obnovu po incidente podrobnejšie, majú tieto osobitné pravidlá v príslušnom rozsahu prednosť.

Článok 26

Čistenie napadnutých webov

1. Odstránenie malvéru, backdoorov, webshellov alebo iného škodlivého kódu zo zákazníckej aplikácie nie je štandardne súčasťou webhostingovej služby, pokiaľ nebolo výslovne dohodnuté inak.
2. WebHouse môže v rámci technickej podpory podľa svojich možností:

• označiť zistené škodlivé alebo podozrivé súbory,
• poskytnúť dostupné technické informácie,
• upozorniť na zistené bezpečnostné riziko,
• odporučiť obnovu zo zálohy,
• odporučiť aktualizáciu aplikácie,
• odporučiť zmenu hesiel alebo iných prístupových údajov,
• alebo odporučiť ďalšie primerané bezpečnostné opatrenia.

3. Takáto pomoc nepredstavuje automaticky kompletný bezpečnostný audit webovej stránky alebo aplikácie.
4. Skutočnosť, že WebHouse označí alebo odstráni jeden alebo viac škodlivých súborov, neznamená, že v aplikácii neexistuje ďalší škodlivý kód alebo iná cesta neoprávneného prístupu.
5. Odstránenie viditeľného škodlivého obsahu samo osebe nemusí odstrániť pôvodnú príčinu kompromitácie.
6. Príčinou incidentu môže zostať najmä:

• zraniteľný plugin,
• zraniteľná téma,
• zastaraný CMS,
• chyba vlastného zdrojového kódu,
• kompromitované heslo,
• odcudzený SSH alebo FTP prístup,
• neoprávnený administrátorský účet,
• alebo iný zraniteľný komponent v správe Zákazníka.

7. Po vyčistení napadnutej aplikácie je preto potrebné primerane odstrániť aj príčinu, ktorá umožnila kompromitáciu, ak je známa alebo ju možno primerane identifikovať.
8. WebHouse nie je v rámci štandardnej webhostingovej služby povinný:

• manuálne analyzovať všetky súbory webovej stránky,
• analyzovať celý zdrojový kód aplikácie,
• opravovať zraniteľný zdrojový kód,
• aktualizovať CMS,
• aktualizovať všetky pluginy alebo témy,
• kontrolovať bezpečnosť všetkých použitých komponentov,
• rekonštruovať celý priebeh útoku,
• zisťovať identitu alebo pôvodcu útoku,
• ani vykonávať forenznú analýzu.

9. WebHouse nie je povinný garantovať, že po vykonanom čistení bol odstránený každý škodlivý súbor, každý backdoor alebo všetky následky kompromitácie, pokiaľ takáto garancia nie je výslovne súčasťou osobitnej služby.
10. Ak sa použije automatizovaný antimalvérový alebo obdobný skenovací nástroj, jeho výsledok nemusí predstavovať úplný zoznam všetkého škodlivého obsahu.
11. Bezpečnostný skener môže určitý škodlivý obsah nezachytiť alebo naopak označiť legitímny súbor ako podozrivý.
12. Samotný výsledok automatizovaného skenu preto nemožno bez ďalšieho považovať za úplný forenzný záver o stave aplikácie.
13. WebHouse môže pri rozsiahlej alebo opakovanej kompromitácii odporučiť kompletnú obnovu aplikácie z dôveryhodného zdroja namiesto manuálneho odstraňovania jednotlivých škodlivých súborov.
14. Obnova zo zálohy však sama osebe nemusí odstrániť bezpečnostnú príčinu incidentu.
15. Ak záloha obsahuje zraniteľnú aplikáciu, kompromitované dáta alebo škodlivý kód, môže po obnove dôjsť k opakovanej kompromitácii.
16. Po obnove zo zálohy môže byť preto potrebné najmä:

• aktualizovať CMS a jeho komponenty,
• odstrániť zraniteľný softvér,
• zmeniť heslá,
• zneplatniť prístupové kľúče alebo tokeny,
• preveriť používateľské účty,
• a opraviť bezpečnostnú konfiguráciu.

17. Ak Zákazník neodstráni príčinu incidentu a služba začne opätovne vykazovať škodlivú aktivitu, WebHouse môže vykonať ďalší bezpečnostný zásah alebo službu znovu obmedziť.
18. WebHouse môže čistenie, detailnú analýzu, obnovu, bezpečnostnú kontrolu alebo inú súvisiacu prácu ponúknuť ako samostatnú alebo spoplatnenú službu.
19. Rozsah takejto práce sa určuje podľa konkrétnej dohody.
20. Ani platená pomoc s odstránením malvéru neznamená automaticky prevzatie trvalej správy alebo bezpečnostného dohľadu nad zákazníckou aplikáciou, pokiaľ nebolo výslovne dohodnuté inak.
21. Jednorazová bezplatná alebo goodwill pomoc WebHouse pri čistení webovej stránky nevytvára nárok na rovnaký rozsah pomoci pri budúcom incidente.
22. Ak WebHouse pri diagnostike alebo čistení zistí pravdepodobnú zraniteľnosť, môže na ňu Zákazníka upozorniť, ale nie je tým automaticky povinný túto zraniteľnosť opraviť, ak patrí do vrstvy spravovanej Zákazníkom.
23. Ak sa však preukáže, že príčina kompromitácie vznikla v technickej vrstve spravovanej WebHouse, nejde v tomto rozsahu o čistenie problému Zákazníka, ale o riešenie bezpečnostného incidentu na strane WebHouse.
24. Ustanovenia tohto článku preto nemožno použiť na prenesenie nákladov alebo zodpovednosti za odstránenie následkov chyby, ktorú spôsobil WebHouse vo svojej spravovanej vrstve.
25. Ak konkrétna služba výslovne zahŕňa monitoring, čistenie malvéru, správu aplikácie alebo inú bezpečnostnú činnosť, uplatní sa rozsah tejto konkrétnej služby.

Článok 27

Obnova zo zálohy po incidente

1. Ak je dostupná vhodná záloha, WebHouse môže podľa podmienok konkrétnej služby umožniť alebo vykonať obnovu dát.
2. Obnova zo zálohy môže slúžiť na návrat aplikácie alebo dát do staršieho stavu, ale sama osebe nepredstavuje úplné odstránenie bezpečnostného incidentu.
3. Obnova staršej zálohy nezaručuje odstránenie bezpečnostnej príčiny incidentu.
4. Záloha môže obsahovať rovnakú zraniteľnosť, chybnú konfiguráciu alebo zastaraný softvér, ktorý umožnil pôvodnú kompromitáciu.
5. Záloha môže obsahovať aj škodlivý kód alebo iné následky kompromitácie, ak bola vytvorená až po vzniku incidentu.
6. Nie vždy je možné presne určiť okamih prvotnej kompromitácie a tým ani jednoznačne určiť posledný bezpečný bod obnovy.
7. WebHouse preto negarantuje, že konkrétna dostupná záloha predstavuje bezpečnostne čistý stav, pokiaľ takáto kontrola nie je výslovne súčasťou osobitnej služby.
8. Výber bodu obnovy sa vykonáva podľa dostupných informácií, technických možností a požiadavky Zákazníka.
9. Ak existuje viac dostupných bodov obnovy, WebHouse môže Zákazníkovi poskytnúť informáciu o ich dostupnosti, ale nie je štandardne povinný vykonať forenznú analýzu s cieľom určiť, ktorý z nich je posledným nekompromitovaným stavom.
10. Obnovenie dát neznamená automaticky odstránenie:

• zraniteľného CMS,
• zraniteľného pluginu alebo témy,
• chyby vlastného zdrojového kódu,
• kompromitovaného hesla,
• odcudzeného SSH alebo FTP prístupu,
• kompromitovaného API kľúča alebo tokenu,
• ani inej pôvodnej príčiny incidentu.

11. Zákazník je preto po obnove povinný primerane zabezpečiť aplikáciu a odstrániť príčinu incidentu v technickej vrstve, ktorú spravuje.
12. Môže ísť najmä o:

• aktualizáciu CMS,
• aktualizáciu alebo odstránenie zraniteľných pluginov a tém,
• opravu vlastného zdrojového kódu,
• zmenu hesiel,
• zneplatnenie SSH kľúčov, API kľúčov alebo tokenov,
• kontrolu používateľských účtov,
• a opravu bezpečnostnej konfigurácie.

13. Ak sa po obnove neodstráni pôvodná príčina incidentu, môže dôjsť k opakovanej kompromitácii aj krátko po obnovení služby.
14. WebHouse môže preto podmieniť opätovné plné sprístupnenie kompromitovanej služby primeraným odstránením známej alebo dôvodne predpokladanej príčiny incidentu.
15. Ak sa po obnove opätovne objaví škodlivá aktivita, WebHouse môže službu znovu obmedziť, izolovať alebo pozastaviť podľa bezpečnostných pravidiel.
16. Obnova zo zálohy môže prepísať novšie dáta vytvorené po okamihu, ku ktorému sa služba obnovuje.
17. Zákazník by mal preto pred obnovou, ak to okolnosti a technické možnosti umožňujú, zvážiť zachovanie novších dát, ktoré nechce stratiť.
18. Rozsah, dostupnosť, retenčná doba a spôsob obnovy záloh sa riadia podmienkami konkrétnej služby a dokumentom „Pravidlá zálohovania, uchovávania a obnovy dát“.
19. Samotná existencia zálohovacej služby neznamená, že je možné obnoviť ľubovoľný historický stav alebo jednotlivý objekt mimo rozsahu a retencie danej služby.
20. Vykonanie obnovy zo zálohy samo osebe neznamená uznanie zodpovednosti WebHouse za vznik bezpečnostného incidentu.
21. Ak je obnova potrebná v dôsledku bezpečnostného incidentu, ktorého príčina vznikla v technickej vrstve spravovanej WebHouse, zodpovednosť za nápravu sa posudzuje podľa tejto skutočnej príčiny.
22. Ustanovenia o zákazníckej zodpovednosti za zabezpečenie aplikácie po obnove nemožno použiť na prenesenie zodpovednosti za incident, ktorý vznikol porušením povinnosti WebHouse.
23. Ak konkrétna služba obsahuje osobitné podmienky obnovy po bezpečnostnom incidente, RPO, RTO alebo iné garancie, majú tieto konkrétne podmienky pred týmto všeobecným ustanovením prednosť.

Článok 28

Zálohy nie sú bezpečnostnou ochranou proti všetkým incidentom

1. Záloha je mechanizmom obnovy dát a sama osebe nenahrádza bezpečnostné opatrenia potrebné na ochranu služby, aplikácie alebo účtov.
2. Existencia zálohy nezabraňuje najmä:

• úniku dát,
• neoprávnenému prístupu,
• zneužitiu používateľského účtu,
• kompromitácii aplikácie alebo servera,
• odcudzeniu hesiel alebo autentifikačných údajov,
• zneužitiu dát,
• poškodeniu reputácie,
• rozosielaniu spamu alebo phishingu,
• ani iným následkom bezpečnostného incidentu.

3. Záloha môže pomôcť obnoviť poškodené alebo zmazané dáta, ale nemusí odstrániť príčinu bezpečnostného incidentu.
4. Ak je napríklad príčinou incidentu zraniteľná aplikácia, kompromitované heslo alebo nesprávna konfigurácia, samotná obnova dát zo zálohy túto príčinu nemusí odstrániť.
5. Záloha preto nenahrádza najmä:

• aktualizáciu softvéru,
• správu zraniteľností,
• bezpečnú konfiguráciu,
• ochranu hesiel a prístupových údajov,
• viacfaktorovú autentifikáciu,
• správu používateľských oprávnení,
• monitoring,
• ani ďalšie primerané bezpečnostné opatrenia.

6. Záloha rovnako nepredstavuje ochranu pred dôsledkami incidentu, ktoré nastali ešte pred jej obnovou, najmä pred únikom alebo neoprávneným použitím dát.
7. Ak útočník získal prístup k dátam, ich následná obnova zo zálohy sama osebe nemení skutočnosť, že mohlo dôjsť k ich neoprávnenému sprístupneniu alebo použitiu.
8. Záloha môže obsahovať rovnakú zraniteľnosť, chybnú konfiguráciu alebo škodlivý obsah ako produkčný systém.
9. Preto ani existencia viacerých bodov obnovy automaticky neznamená, že je medzi nimi dostupný bezpečnostne čistý stav.
10. Prevádzkovateľ citlivých, významných alebo kritických systémov by mal primerane posúdiť potrebu vlastných nezávislých záloh.
11. Pri takomto posúdení by mal zohľadniť najmä:

• hodnotu a kritickosť dát,
• možné následky ich straty,
• požadovanú dobu obnovy,
• potrebnú históriu verzií,
• riziko kompromitácie hlavného systému,
• a potrebu oddelenia záloh od produkčného prostredia.

12. Vlastná nezávislá záloha môže byť vhodná najmä v prípadoch, keď by strata alebo dlhšia nedostupnosť dát mala závažný prevádzkový, ekonomický alebo právny dopad.
13. Povinnosť alebo odporúčanie Zákazníka vytvárať vlastné zálohy však nezbavuje WebHouse povinnosti plniť zálohovanie, ktoré je výslovne zahrnuté v objednanej službe.
14. Ak WebHouse pri konkrétnej službe garantuje určitú frekvenciu zálohovania, retenčnú dobu, RPO, RTO alebo iný parameter obnovy, tieto povinnosti sa posudzujú podľa podmienok danej služby.
15. Všeobecné odporúčanie používať vlastné zálohy nemožno použiť na obchádzanie konkrétnej zálohovacej povinnosti alebo garancie WebHouse.
16. Rozsah, spôsob, frekvencia, retencia a podmienky obnovy záloh sa riadia dokumentom „Pravidlá zálohovania, uchovávania a obnovy dát“ a podmienkami konkrétnej služby.

Článok 29

Logy

1. WebHouse môže vytvárať a uchovávať technické, prevádzkové a bezpečnostné logy v rozsahu potrebnom na prevádzku služieb, diagnostiku, bezpečnosť, riešenie incidentov a plnenie právnych alebo zmluvných povinností.
2. Logy môžu podľa charakteru služby obsahovať najmä:

• IP adresy,
• čas a dátum udalosti,
• identifikáciu služby alebo účtu,
• technické požiadavky,
• systémové udalosti,
• autentifikačné udalosti,
• bezpečnostné udalosti,
• chybové hlásenia,
• informácie o sieťovej komunikácii,
• alebo ďalšie technické údaje potrebné na prevádzku a bezpečnosť služby.

3. Rozsah zaznamenávaných údajov sa môže líšiť podľa konkrétnej služby, technológie a účelu logovania.
4. WebHouse nie je povinný zaznamenávať každú technickú alebo používateľskú udalosť, pokiaľ takáto povinnosť nevyplýva z konkrétnej služby alebo právnych predpisov.
5. Logy nemusia byť uchovávané neobmedzene dlho.
6. Doba ich uchovávania môže závisieť najmä od:

• typu logu,
• technických možností,
• bezpečnostných požiadaviek,
• prevádzkových potrieb,
• kapacity systémov,
• a príslušných právnych alebo zmluvných povinností.

7. Po uplynutí príslušnej retenčnej doby môžu byť logy automaticky vymazané, prepísané alebo agregované.
8. WebHouse negarantuje, že historické logy budú dostupné po uplynutí ich bežnej retenčnej doby.
9. Zákazník by preto nemal predpokladať, že WebHouse bude schopný spätne preveriť ľubovoľne starú udalosť.
10. Ak Zákazník potrebuje preveriť konkrétny bezpečnostný incident, mal by ho oznámiť bez zbytočného odkladu, aby sa zvýšila pravdepodobnosť dostupnosti relevantných technických údajov.
11. Samotná existencia logov neznamená, že bude možné spätne jednoznačne zrekonštruovať celý priebeh bezpečnostného incidentu.
12. WebHouse negarantuje, že bude možné z logov spoľahlivo určiť:

• presný okamih prvotnej kompromitácie,
• všetky kroky útočníka,
• konkrétnu použitú zraniteľnosť,
• pôvod odcudzených prístupových údajov,
• všetky dotknuté dáta,
• alebo identitu osoby, ktorá útok vykonala.

13. Log môže zaznamenať určitú technickú udalosť bez toho, aby jednoznačne vysvetľoval jej príčinu.
14. Napríklad úspešné prihlásenie z určitej IP adresy môže preukazovať použitie prihlasovacích údajov, ale samo osebe nemusí preukazovať, ako boli tieto údaje získané.
15. Rovnako IP adresa zaznamenaná v logu nemusí sama osebe jednoznačne identifikovať konkrétnu fyzickú osobu.
16. Pri vyhodnocovaní bezpečnostného incidentu sa preto logy posudzujú spolu s ďalšími dostupnými technickými informáciami.
17. Logy môžu byť neúplné aj z technických dôvodov, napríklad v dôsledku:

• rotácie alebo retencie,
• výpadku konkrétneho komponentu,
• povahy použitej technológie,
• absencie daného typu logovania,
• alebo skutočnosti, že určitá udalosť prebehla mimo systémov WebHouse.

18. WebHouse nie je povinný uchovávať logy zákazníckych aplikácií, operačných systémov alebo zariadení, ktoré nespravuje.
19. Pri nespravovanom VPS, dedikovanom serveri alebo inom zákazníkom spravovanom systéme zodpovedá Zákazník za nastavenie a uchovávanie logov vo vnútri svojej technickej vrstvy.
20. Ak Zákazník vypne, obmedzí alebo zmení logovanie v systéme, ktorý spravuje, môže tým obmedziť možnosť neskoršej diagnostiky alebo vyšetrovania incidentu.
21. WebHouse môže pri riešení incidentu použiť dostupné logy na identifikáciu zdroja škodlivej aktivity, kompromitovaného účtu, neobvyklej prevádzky alebo inej technickej udalosti.
22. Technické vyhodnotenie logov v rámci bežnej podpory nepredstavuje automaticky forenznú analýzu.
23. Detailná korelácia rozsiahlych logov, rekonštrukcia incidentu alebo vypracovanie odborného forenzného záveru môže byť predmetom samostatnej služby.
24. WebHouse môže z bezpečnostných dôvodov obmedziť rozsah logov alebo interných bezpečnostných údajov poskytovaných Zákazníkovi, ak by ich úplné sprístupnenie mohlo:

• ohroziť bezpečnosť infraštruktúry,
• odhaliť interné bezpečnostné mechanizmy,
• zasiahnuť do práv iných zákazníkov,
• alebo sprístupniť údaje tretích osôb.

25. Ak je možné poskytnúť relevantnú časť logu bez takéhoto rizika, WebHouse ju môže Zákazníkovi sprístupniť podľa charakteru služby a účelu požiadavky.
26. Logy a bezpečnostné záznamy môžu obsahovať osobné údaje alebo iné chránené informácie a ich spracúvanie sa riadi príslušnými právnymi a zmluvnými pravidlami.
27. Samotná absencia záznamu v logu nepreukazuje, že určitá udalosť nenastala, ak daný systém udalosť nezaznamenával alebo príslušný záznam už nie je dostupný.
28. Rovnako samotná existencia konkrétneho záznamu nemusí bez ďalšieho preukazovať príčinu bezpečnostného incidentu alebo zodpovednosť konkrétnej strany.
29. Ak konkrétna služba výslovne garantuje určitý rozsah logovania, retenčnú dobu alebo prístup k logom, WebHouse je povinný túto konkrétnu podmienku dodržať.
30. Všeobecné ustanovenia tohto článku nemožno použiť na obchádzanie konkrétne dohodnutej povinnosti WebHouse týkajúcej sa logovania alebo uchovávania logov.

Článok 30

Forenzná analýza

1. Štandardná hostingová, serverová alebo technická podpora nezahŕňa digitálnu forenznú analýzu, pokiaľ nebolo výslovne dohodnuté inak.
2. Bežná technická diagnostika bezpečnostného incidentu môže zahŕňať preverenie dostupných logov, systémových udalostí, stavu služby alebo iných technických údajov potrebných na určenie pravdepodobnej príčiny problému.
3. Takáto diagnostika však sama osebe nepredstavuje forenznú analýzu ani odborný forenzný posudok.
4. WebHouse negarantuje schopnosť spätne spoľahlivo určiť:

• presný spôsob kompromitácie,
• konkrétnu použitú zraniteľnosť,
• presný čas prvého neoprávneného prístupu,
• všetky vykonané úkony útočníka,
• identitu útočníka,
• všetky dotknuté systémy,
• ani úplný rozsah prípadného úniku alebo zneužitia dát.

5. Možnosť vykonať úspešnú forenznú analýzu závisí najmä od:

• dostupnosti a kvality logov,
• rozsahu ich retencie,
• konfigurácie systému,
• stavu systému po incidente,
• času, ktorý uplynul od incidentu,
• následných zásahov do systému,
• a charakteru samotného útoku.

6. Ak relevantné logy alebo iné technické údaje neexistujú, boli prepísané, odstránené alebo neboli zaznamenávané, nemusí byť možné priebeh incidentu spätne spoľahlivo rekonštruovať.
7. Rovnako následná aktualizácia, obnova zo zálohy, čistenie systému, reinštalácia alebo iný zásah môže zmeniť alebo odstrániť údaje významné pre forenznú analýzu.
8. Ak Zákazník predpokladá potrebu detailného vyšetrovania incidentu, mal by podľa možností zabrániť zbytočným zmenám dotknutého systému a bezodkladne kontaktovať WebHouse alebo príslušného bezpečnostného špecialistu.
9. WebHouse však nie je povinný ponechať kompromitovanú alebo nebezpečnú službu v prevádzke iba z dôvodu zachovania forenzných stôp, ak by tým bola ohrozená infraštruktúra, ostatní zákazníci alebo tretie osoby.
10. Ochrana infraštruktúry a obmedzenie prebiehajúceho incidentu môže mať prednosť pred zachovaním všetkých potenciálnych forenzných údajov.
11. Ak je to technicky možné a primerané okolnostiam, WebHouse môže pri bezpečnostnom zásahu zachovať vybrané dostupné technické údaje, ktoré môžu byť významné pre neskoršie preverenie incidentu.
12. Takýto postup však nie je automaticky súčasťou štandardnej služby a nepredstavuje garanciu úplnosti forenzných dôkazov.
13. Ak Zákazník požaduje digitálnu forenznú analýzu, môže byť predmetom osobitnej dohody alebo samostatne spoplatnenej služby.
14. WebHouse môže vzhľadom na charakter incidentu odporučiť vykonanie analýzy externým špecialistom na digitálnu forenziku alebo kybernetickú bezpečnosť.
15. WebHouse nie je povinný takéhoto externého špecialistu zabezpečiť, pokiaľ nebolo výslovne dohodnuté inak.
16. Ak forenznú analýzu vykonáva externý špecialista, jej rozsah, cena, metódy a výsledky sa riadia dohodou medzi Zákazníkom a príslušným poskytovateľom tejto služby.
17. Ani odborne vykonaná forenzná analýza nemusí vždy viesť k jednoznačnému určeniu pôvodcu, spôsobu alebo úplného rozsahu incidentu.
18. Technické zistenie konkrétnej IP adresy, používateľského účtu alebo autentifikačnej udalosti samo osebe nemusí jednoznačne identifikovať fyzickú osobu, ktorá útok vykonala.
19. Rovnako zistenie určitej zraniteľnosti neznamená automaticky, že práve táto zraniteľnosť bola pri konkrétnom incidente zneužitá.
20. Forenzná analýza môže pracovať aj s pravdepodobnými závermi založenými na dostupných technických dôkazoch, bez možnosti absolútneho potvrdenia každého jednotlivého kroku incidentu.
21. Absencia jednoznačného forenzného záveru sama osebe nepreukazuje zodpovednosť WebHouse ani Zákazníka.
22. Zodpovednosť za bezpečnostný incident sa posudzuje podľa dostupných technických zistení, skutočných povinností jednotlivých strán a technickej vrstvy, v ktorej príčina incidentu vznikla.
23. Ak sa počas bežnej diagnostiky preukáže bezpečnostná chyba v technickej vrstve spravovanej WebHouse, skutočnosť, že nebola vykonaná úplná forenzná analýza, sama osebe nezbavuje WebHouse zodpovednosti za túto chybu.
24. Rovnako nemožnosť jednoznačne určiť celý priebeh útoku neznamená, že WebHouse musí prevziať zodpovednosť za incident, ktorého príčina v jeho spravovanej vrstve nebola preukázaná.
25. Ak konkrétna bezpečnostná, managed alebo incident-response služba výslovne zahŕňa forenznú analýzu alebo uchovávanie forenzných údajov, rozsah povinností WebHouse sa riadi podmienkami tejto konkrétnej služby.

Článok 31

Osobné údaje a bezpečnostný incident

1. Ak bezpečnostný incident zahŕňa osobné údaje, Zákazník zodpovedá za posúdenie svojich povinností ako prevádzkovateľ osobných údajov v rozsahu, v akom túto úlohu podľa príslušných právnych predpisov zastáva.
2. Zákazník zodpovedá najmä za posúdenie, či incident predstavuje porušenie ochrany osobných údajov a či mu v súvislosti s incidentom vznikajú povinnosti voči dozornému orgánu, dotknutým osobám alebo iným subjektom.
3. Ak WebHouse pri poskytovaní služby vystupuje ako sprostredkovateľ osobných údajov a zistí porušenie ochrany osobných údajov týkajúce sa údajov spracúvaných v mene Zákazníka, postupuje podľa príslušnej DPA, zmluvných podmienok a záväzných právnych predpisov.
4. WebHouse poskytne Zákazníkovi v rozsahu svojich povinností a dostupných informácií primeranú súčinnosť potrebnú na posúdenie incidentu.
5. Rozsah takejto súčinnosti závisí najmä od:

• charakteru incidentu,
• rozsahu služby,
• úlohy WebHouse pri spracúvaní osobných údajov,
• dostupných technických informácií,
• a podmienok príslušnej DPA.

6. WebHouse nie je povinný za Zákazníka vykonávať právne posúdenie jeho povinností ako prevádzkovateľa, pokiaľ nebolo výslovne dohodnuté inak.
7. Najmä nie je štandardnou povinnosťou WebHouse rozhodnúť za Zákazníka, či má byť konkrétny incident oznámený dozornému orgánu alebo dotknutým osobám.
8. WebHouse môže Zákazníkovi poskytnúť dostupné technické informácie relevantné pre jeho posúdenie incidentu.
9. Môže ísť najmä o:

• čas zistenia incidentu,
• identifikáciu dotknutej služby,
• dostupné technické logy,
• známy alebo pravdepodobný spôsob incidentu,
• prijaté technické opatrenia,
• a ďalšie dostupné informácie o rozsahu incidentu.

10. Poskytnutie technických informácií WebHouse nepredstavuje právne stanovisko k povinnostiam Zákazníka podľa predpisov o ochrane osobných údajov.
11. Bezpečnostný incident automaticky neznamená porušenie ochrany osobných údajov.
12. Bezpečnostný incident môže napríklad zasiahnuť systém alebo službu bez toho, aby došlo k neoprávnenému prístupu k osobným údajom, ich strate, zmene, zničeniu alebo neoprávnenému sprístupneniu.
13. Naopak, porušenie ochrany osobných údajov môže vzniknúť aj bez technického napadnutia infraštruktúry.
14. Môže ísť napríklad o neoprávnené:

• sprístupnenie údajov,
• odoslanie údajov nesprávnemu príjemcovi,
• zmenu prístupových oprávnení,
• zmazanie údajov,
• alebo inú udalosť týkajúcu sa dôvernosti, integrity alebo dostupnosti osobných údajov.

15. Každé porušenie ochrany osobných údajov preto nemusí byť spôsobené bezpečnostným zlyhaním infraštruktúry WebHouse.
16. Ak napríklad dôjde k úniku údajov prostredníctvom kompromitovanej aplikácie, účtu, hesla alebo zariadenia spravovaného Zákazníkom, samotná existencia porušenia ochrany osobných údajov nepreukazuje bezpečnostné zlyhanie WebHouse.
17. Ak však k porušeniu ochrany osobných údajov dôjde v dôsledku chyby alebo porušenia povinnosti v technickej vrstve spravovanej WebHouse, zodpovednosť sa posudzuje podľa tejto skutočnej príčiny a príslušného zmluvného vzťahu.
18. Pri jednom incidente môžu vzniknúť samostatné povinnosti WebHouse aj Zákazníka podľa ich príslušného postavenia a rozsahu správy jednotlivých technických vrstiev.
19. Zákazník je povinný poskytnúť WebHouse primeranú súčinnosť, ak je potrebná na preverenie incidentu alebo splnenie povinností WebHouse.
20. Ak incident vznikne v zákazníckej aplikácii alebo systéme, WebHouse nemusí mať k dispozícii všetky informácie potrebné na určenie:

• kategórií dotknutých osobných údajov,
• počtu dotknutých osôb,
• obsahu databázy,
• významu jednotlivých údajov,
• ani následkov incidentu pre dotknuté osoby.

21. Posúdenie týchto skutočností preto môže vyžadovať súčinnosť Zákazníka ako subjektu, ktorý pozná obsah a účel spracúvania svojich dát.
22. Samotné zistenie neoprávneného prístupu neznamená automaticky, že je možné presne určiť, ktoré konkrétne osobné údaje útočník zobrazil, skopíroval alebo inak použil.
23. Rovnako absencia technického dôkazu o skopírovaní údajov sama osebe nemusí vždy preukazovať, že k ich neoprávnenému sprístupneniu nemohlo dôjsť.
24. Posúdenie rozsahu incidentu sa vykonáva podľa dostupných technických a ďalších relevantných informácií.
25. WebHouse negarantuje, že bude pri každom incidente možné spätne úplne zrekonštruovať rozsah prístupu k osobným údajom.
26. Ak je to potrebné na obmedzenie incidentu, WebHouse môže vykonať primerané bezpečnostné opatrenia aj pred úplným právnym alebo technickým posúdením incidentu.
27. Takéto opatrenie môže zahŕňať najmä obmedzenie účtu, izoláciu služby, zablokovanie komunikácie alebo iný zásah potrebný na zabránenie ďalšieho neoprávneného prístupu.
28. Technické riešenie incidentu a plnenie povinností podľa predpisov o ochrane osobných údajov sú samostatné procesy a môžu prebiehať súbežne.
29. Obnovenie technickej funkčnosti služby samo osebe neznamená, že boli splnené všetky povinnosti súvisiace s prípadným porušením ochrany osobných údajov.
30. Rovnako oznámenie porušenia ochrany osobných údajov samo osebe neurčuje zodpovednosť za jeho vznik.
31. Podrobnejšie pravidlá spracúvania osobných údajov, bezpečnosti spracúvania, oznamovania incidentov a vzájomnej súčinnosti upravuje najmä príslušná DPA a ďalšia dokumentácia ochrany osobných údajov WebHouse.
32. Ak DPA alebo individuálna dohoda stanovuje konkrétne povinnosti WebHouse pri porušení ochrany osobných údajov, majú tieto konkrétne povinnosti pred týmto všeobecným ustanovením prednosť.
33. Ustanovenia tohto článku nemožno použiť na obmedzenie alebo obchádzanie povinností WebHouse alebo Zákazníka, ktoré im vyplývajú zo záväzných právnych predpisov.

Článok 32

Šifrovanie

1. WebHouse používa alebo podporuje šifrovanie v rozsahu technických možností jednotlivých služieb a v rozsahu technických vrstiev, ktoré spravuje.
2. Rozsah použitého šifrovania závisí od charakteru konkrétnej služby, použitej technológie a dohodnutých bezpečnostných parametrov.
3. Je potrebné rozlišovať najmä medzi:

• šifrovaním komunikácie počas prenosu,
• šifrovaním uložených dát,
• šifrovaním na úrovni aplikácie,
• a šifrovaním alebo ochranou autentifikačných údajov.

4. Použitie šifrovania v jednej technickej vrstve neznamená automaticky, že sú šifrované aj dáta v ostatných vrstvách.
5. WebHouse môže pri komunikácii podporovať alebo používať SSL/TLS alebo iné obdobné mechanizmy na ochranu dát počas prenosu.
6. SSL/TLS chráni komunikáciu v rozsahu príslušného protokolu najmä proti neoprávnenému čítaniu alebo zmene prenášaných dát medzi podporovanými koncovými bodmi.
7. Poskytovanie alebo používanie SSL/TLS certifikátu však samo osebe nechráni:

• aplikáciu pred napadnutím,
• CMS alebo plugin pred zraniteľnosťou,
• databázu pred kompromitáciou,
• používateľský účet pred phishingom,
• heslo pred odcudzením na kompromitovanom zariadení,
• server pred zraniteľnosťou aplikácie,
• ani dáta po ich spracovaní alebo uložení v aplikácii.

8. Skutočnosť, že webová stránka používa HTTPS, preto sama osebe neznamená, že je aplikácia bezpečná alebo že jej obsah nemožno kompromitovať.
9. Zákazník zodpovedá za použitie šifrovania na aplikačnej úrovni, ak to vyžaduje charakter ním spracúvaných dát a ak túto aplikačnú vrstvu spravuje Zákazník.
10. Môže ísť napríklad o šifrovanie:

• citlivých údajov uložených v databáze,
• aplikačných tajomstiev,
• exportov alebo archívov,
• dokumentov,
• záloh vytváraných Zákazníkom,
• alebo iných citlivých dát.

11. WebHouse nie je automaticky povinný šifrovať obsah zákazníckej databázy alebo jednotlivé aplikačné údaje iba preto, že sú uložené na jeho infraštruktúre.
12. Ak konkrétna služba výslovne zahŕňa šifrovanie uložených dát, WebHouse zodpovedá za jeho poskytovanie v rozsahu podmienok tejto služby.
13. Šifrovanie dát uložených na diskovej alebo úložiskovej vrstve nemusí samo osebe chrániť dáta pred kompromitovanou aplikáciou alebo oprávneným procesom, ktorý má k týmto dátam prístup po ich dešifrovaní.
14. Ak útočník kompromituje aplikáciu a získa jej oprávnenie pristupovať k dátam, môže byť schopný pracovať s dátami aj napriek tomu, že sú na úložisku šifrované.
15. Rovnako šifrovanie úložiska nepredstavuje náhradu za:

• riadenie prístupových práv,
• aktualizáciu aplikácií,
• ochranu účtov,
• bezpečnú konfiguráciu,
• alebo ďalšie bezpečnostné opatrenia.

16. Bezpečnosť šifrovania závisí aj od ochrany príslušných kľúčov, hesiel, certifikátov alebo iných tajných údajov.
17. Zákazník zodpovedá za ochranu šifrovacích kľúčov alebo hesiel, ktoré vytvára, vlastní alebo spravuje vo svojej technickej vrstve.
18. WebHouse zodpovedá za primeranú ochranu šifrovacích kľúčov a iných tajných údajov, ktoré spravuje v rámci svojej technickej vrstvy.
19. Ak Zákazník stratí šifrovací kľúč alebo heslo, ktoré spravuje výlučne on, WebHouse nemusí byť schopný obnoviť alebo dešifrovať príslušné dáta.
20. Zákazník by preto mal pri vlastnom šifrovaní primerane zabezpečiť ochranu, uchovávanie a obnovu šifrovacích kľúčov.
21. WebHouse môže z bezpečnostných dôvodov ukončiť podporu zastaraného alebo nedostatočne bezpečného kryptografického protokolu, algoritmu alebo konfigurácie.
22. WebHouse nie je povinný zachovávať podporu zastaraného TLS protokolu, šifrovacej sady alebo iného bezpečnostne nevhodného mechanizmu iba z dôvodu kompatibility so starým softvérom Zákazníka.
23. Zákazník zodpovedá za kompatibilitu svojich aplikácií a zariadení s aktuálne podporovanými bezpečnostnými protokolmi.
24. Ak konkrétna služba umožňuje Zákazníkovi meniť TLS, certifikáty alebo inú bezpečnostnú konfiguráciu, Zákazník zodpovedá za zmeny, ktoré v tejto zákazníkom spravovanej konfigurácii vykoná.
25. Platný SSL/TLS certifikát potvrdzuje technické vlastnosti certifikátu a zabezpečeného spojenia v rozsahu použitého mechanizmu; nepredstavuje potvrdenie dôveryhodnosti, bezpečnosti alebo zákonnosti obsahu konkrétnej webovej stránky.
26. Samotná prítomnosť HTTPS preto nevylučuje phishing, podvodnú webovú stránku alebo kompromitovanú aplikáciu.
27. Šifrovanie môže znižovať riziko neoprávneného sprístupnenia dát, ale nepredstavuje absolútnu ochranu proti všetkým bezpečnostným incidentom.
28. Samotný vznik bezpečnostného incidentu pri použití šifrovania nepreukazuje, že príslušný šifrovací mechanizmus zlyhal.
29. Ak však incident vznikne v dôsledku chyby alebo porušenia povinnosti pri šifrovacom mechanizme, ktorý mal podľa konkrétnej služby spravovať WebHouse, zodpovednosť sa posudzuje podľa tejto skutočnej príčiny.
30. Ak konkrétna služba stanovuje osobitné požiadavky na šifrovanie, správu certifikátov, kryptografické protokoly alebo ochranu uložených dát, majú tieto konkrétne podmienky pred týmto všeobecným ustanovením prednosť.

Článok 33

SSL/TLS certifikáty

1. WebHouse môže podľa podmienok konkrétnej služby poskytovať, vystavovať, automaticky zabezpečovať alebo obnovovať SSL/TLS certifikáty pre domény Zákazníka.
2. Rozsah zodpovednosti WebHouse závisí od toho, či správu certifikátu zabezpečuje WebHouse alebo Zákazník.
3. Ak správu certifikátu zabezpečuje WebHouse, zodpovedá v rozsahu konkrétnej služby najmä za:

• technické nasadenie certifikátu,
• jeho obnovu,
• konfiguráciu na serverovej vrstve, ktorú spravuje,
• a primeranú funkčnosť podporovaného TLS mechanizmu.

4. Automatická obnova certifikátu môže závisieť aj od podmienok, ktoré nie sú výlučne pod kontrolou WebHouse, najmä od:

• správnej DNS konfigurácie,
• smerovania domény na príslušnú službu,
• dostupnosti validačného mechanizmu,
• pravidiel certifikačnej autority,
• alebo zásahov Zákazníka do konfigurácie domény alebo služby.

5. Ak Zákazník zmení DNS, proxy, CDN, webovú konfiguráciu alebo inú časť prostredia spôsobom, ktorý znemožní vydanie alebo obnovu certifikátu, zodpovedá za následky tejto zmeny v rozsahu svojej správy.
6. Ak Zákazník spravuje SSL/TLS certifikát sám, zodpovedá najmä za:

• jeho správne vystavenie,
• inštaláciu,
• obnovu,
• konfiguráciu,
• ochranu privátneho kľúča,
• a sledovanie platnosti certifikátu.

7. Zákazník zodpovedá za správnosť SSL/TLS konfigurácie, ktorú vykonáva alebo ovláda sám.
8. WebHouse nezodpovedá za chybu certifikátu alebo TLS konfigurácie spôsobenú nesprávnym zásahom Zákazníka alebo tretej osoby do zákazníkom spravovanej vrstvy.
9. Ak však chyba vznikne v certifikačnej alebo serverovej vrstve, ktorú mal podľa konkrétnej služby spravovať WebHouse, zodpovednosť sa posudzuje podľa tejto skutočnej príčiny.
10. Platný SSL/TLS certifikát zabezpečuje technické vlastnosti šifrovaného spojenia v rozsahu použitého protokolu, ale nepredstavuje potvrdenie celkovej bezpečnosti webovej stránky alebo aplikácie.
11. Platný SSL/TLS certifikát najmä nepotvrdzuje, že webová stránka:

• je bezpečná,
• nie je napadnutá,
• neobsahuje malware,
• neobsahuje zraniteľný softvér,
• nie je phishingová alebo podvodná,
• ani patrí dôveryhodnému subjektu.

12. HTTPS chráni najmä komunikáciu medzi podporovanými koncovými bodmi, nie samotnú aplikačnú logiku webovej stránky.
13. Kompromitovaná alebo škodlivá webová stránka preto môže používať úplne platný SSL/TLS certifikát.
14. Rovnako prítomnosť HTTPS neznamená, že databáza, používateľské účty, CMS, pluginy alebo serverová aplikácia nemôžu byť kompromitované.
15. SSL/TLS certifikát nechráni Zákazníka alebo jeho používateľov pred phishingom, sociálnym inžinierstvom, škodlivým obsahom alebo zraniteľnosťou aplikácie.
16. WebHouse môže z bezpečnostných dôvodov ukončiť podporu zastaraných TLS protokolov, šifrovacích algoritmov alebo konfigurácií, ktoré už nepovažuje za primerane bezpečné.
17. WebHouse nie je povinný zachovávať podporu zastaraného TLS protokolu alebo šifrovacej sady iba z dôvodu kompatibility so starým softvérom alebo zariadením Zákazníka.
18. Zákazník zodpovedá za kompatibilitu svojich aplikácií a zariadení s aktuálne podporovanými TLS technológiami v rozsahu svojej správy.
19. Privátny kľúč certifikátu je bezpečnostne citlivý údaj a musí byť primerane chránený pred neoprávneným sprístupnením.
20. Ak privátny kľúč spravuje Zákazník, zodpovedá za jeho ochranu a prípadné zneplatnenie alebo výmenu pri podozrení na kompromitáciu.
21. Ak privátny kľúč spravuje WebHouse v rámci konkrétnej služby, WebHouse zodpovedá za jeho primeranú ochranu vo svojej technickej vrstve.
22. Pri podozrení na kompromitáciu privátneho kľúča môže byť potrebné certifikát zneplatniť a vydať nový.
23. WebHouse môže v rámci automatizovanej správy certifikátov vykonať takúto výmenu alebo obnovu bez osobitného súhlasu Zákazníka, ak je to potrebné na zachovanie bezpečnosti alebo funkčnosti služby.
24. Samotné zneplatnenie, výmena alebo obnova certifikátu neznamená, že došlo ku kompromitácii webovej aplikácie.
25. Rovnako kompromitácia webovej aplikácie neznamená automaticky kompromitáciu SSL/TLS certifikátu alebo jeho privátneho kľúča.
26. Pri posudzovaní incidentu je potrebné rozlišovať medzi:

• bezpečnosťou TLS spojenia,
• bezpečnosťou privátneho kľúča,
• konfiguráciou webového servera,
• a bezpečnosťou samotnej zákazníckej aplikácie.

27. Ak konkrétna služba výslovne garantuje automatické vystavenie, obnovu alebo správu SSL/TLS certifikátov, WebHouse zodpovedá za túto činnosť v rozsahu podmienok danej služby.
28. Všeobecné ustanovenia o obmedzeniach SSL/TLS certifikátov nemožno použiť na obchádzanie konkrétnej povinnosti WebHouse týkajúcej sa ich vystavenia, obnovy alebo správy.

Článok 34

DNS a DNSSEC

1. WebHouse zodpovedá za primerané zabezpečenie DNS infraštruktúry, ktorú podľa objednanej služby spravuje.
2. Rozsah zodpovednosti WebHouse závisí najmä od toho, či WebHouse spravuje:

• autoritatívne DNS servery,
• DNS zónu,
• DNSSEC podpisovanie,
• DNSSEC kľúče,
• DS záznamy,
• alebo delegáciu domény.

3. Ak Zákazník používa DNS servery tretej strany, WebHouse za ich bezpečnosť, dostupnosť, konfiguráciu alebo správu nezodpovedá, pokiaľ nebolo výslovne dohodnuté inak.
4. Samotná registrácia domény prostredníctvom WebHouse neznamená, že WebHouse automaticky spravuje aj DNS zónu alebo DNSSEC, ak Zákazník používa externé DNS servery.
5. Ak DNS zónu spravuje WebHouse, zodpovedá za technickú prevádzku svojich DNS serverov a za správne vykonanie DNS zmien, ktoré prijal a vykonal v rámci svojej správy.
6. Zákazník zodpovedá za správnosť DNS údajov, ktoré zadáva alebo požaduje nastaviť, pokiaľ WebHouse neprevzal ich odbornú správu.
7. Nesprávne nastavený DNS záznam môže spôsobiť najmä:

• nedostupnosť webovej stránky,
• nefunkčnosť e-mailu,
• nesprávne smerovanie služby,
• zlyhanie overovania domény,
• alebo iné bezpečnostné či prevádzkové problémy.

8. Ak Zákazník alebo tretia osoba zmení DNS konfiguráciu mimo správy WebHouse, zodpovedá za dôsledky tejto zmeny v rozsahu svojej správy.
9. Pri DNSSEC je zodpovednosť rozdelená podľa toho, kto spravuje jednotlivé časti DNSSEC reťazca.
10. Ide najmä o:

• DNS zónu,
• podpisové kľúče,
• DNSKEY záznamy,
• DS záznamy,
• delegáciu domény,
• a prípadnú automatizáciu medzi registrom, registrátorom a DNS infraštruktúrou.

11. Ak WebHouse zabezpečuje kompletnú správu DNSSEC ako súčasť služby, zodpovedá za správne vykonanie DNSSEC operácií v rozsahu tejto správy.
12. Ak Zákazník spravuje podpisové kľúče alebo DNSSEC konfiguráciu sám, zodpovedá za ich správnosť, ochranu a bezpečné používanie.
13. Ak Zákazník poskytne WebHouse údaje pre vytvorenie DS záznamu, zodpovedá za správnosť týchto údajov, pokiaľ ich WebHouse negeneruje alebo nespravuje ako súčasť služby.
14. WebHouse zodpovedá za správne technické vykonanie požadovanej zmeny DS záznamu, ak túto operáciu podľa objednanej služby zabezpečuje.
15. Nesúlad medzi DNSKEY záznamom v DNS zóne a DS záznamom v nadradenej zóne môže spôsobiť zlyhanie DNSSEC validácie.
16. V dôsledku nesprávnej DNSSEC konfigurácie môže byť doména pre používateľov používajúcich DNSSEC validáciu úplne alebo čiastočne nedostupná, aj keď samotné DNS servery a cieľové služby technicky fungujú.
17. Nesprávny zásah Zákazníka alebo tretej strany do:

• DNSKEY záznamov,
• podpisových kľúčov,
• DS záznamov,
• delegácie,
• alebo DNSSEC konfigurácie

môže preto spôsobiť nedostupnosť domény.

18. Ak Zákazník zmení poskytovateľa DNS, musí byť DNSSEC konfigurácia primerane zosúladená s novou DNS infraštruktúrou.
19. Samotná zmena nameserverov bez správneho vyriešenia DNSSEC môže viesť k zlyhaniu validácie domény.
20. Pri migrácii DNSSEC zabezpečenej domény môže byť potrebné vykonať zmeny v správnom poradí, aby sa minimalizovalo riziko nedostupnosti.
21. Ak Zákazník vykonáva migráciu DNS alebo DNSSEC sám, zodpovedá za správnosť a načasovanie jednotlivých krokov.
22. Ak migráciu výslovne vykonáva WebHouse ako dohodnutú službu, zodpovedá za správne vykonanie krokov, ktoré v rámci tejto služby prevzal.
23. WebHouse môže z bezpečnostných dôvodov meniť alebo obnovovať DNSSEC kľúče, ktoré spravuje, ak je to potrebné na zachovanie bezpečnosti a funkčnosti služby.
24. Pri rotácii DNSSEC kľúčov môže byť potrebná koordinácia DNS zóny, DS záznamov alebo ďalších prvkov DNSSEC reťazca.
25. WebHouse nie je povinný sprístupniť privátne DNSSEC kľúče, ktoré používa na prevádzku svojej spravovanej DNS infraštruktúry, ak to nie je súčasťou konkrétnej služby.
26. Privátne DNSSEC kľúče sú bezpečnostne citlivé údaje a musia byť primerane chránené stranou, ktorá ich spravuje.
27. Samotná aktivácia DNSSEC nepredstavuje absolútnu ochranu domény pred všetkými typmi útokov.
28. DNSSEC je určený najmä na kryptografické overovanie autenticity a integrity DNS odpovedí; nechráni napríklad samotnú webovú aplikáciu, používateľské účty alebo obsah servera pred kompromitáciou.
29. Používanie DNSSEC preto nepresúva zodpovednosť za bezpečnosť ostatných technických vrstiev na WebHouse.
30. WebHouse môže pri zistení nefunkčnej alebo nebezpečnej DNSSEC konfigurácie vykonať alebo navrhnúť primerané opatrenie podľa rozsahu svojej správy.
31. Ak je problém spôsobený konfiguráciou, ktorú spravuje Zákazník alebo externý DNS poskytovateľ, WebHouse môže požadovať súčinnosť Zákazníka alebo vykonanie nápravy na strane tejto tretej osoby.
32. Samotná skutočnosť, že doména prestala fungovať po zmene DNS alebo DNSSEC, nepreukazuje chybu infraštruktúry WebHouse; rozhodujúce je, ktorá konkrétna časť DNS reťazca bola nesprávne nakonfigurovaná alebo zlyhala.
33. Ak však nedostupnosť vznikne v dôsledku nesprávneho zásahu alebo poruchy v DNS alebo DNSSEC vrstve, ktorú mal spravovať WebHouse, zodpovednosť sa posudzuje podľa tejto skutočnej príčiny.
34. Ak konkrétna DNS alebo doménová služba obsahuje osobitné pravidlá pre DNSSEC, správu DS záznamov, automatickú rotáciu kľúčov alebo delegáciu, majú tieto konkrétne podmienky pred týmto všeobecným ustanovením prednosť.

Článok 35

Domény a zákaznícke účty

1. Zákazník je povinný osobitne chrániť zákaznícky účet a ďalšie prístupy, prostredníctvom ktorých je možné vykonávať zmeny s významným dopadom na doménu alebo súvisiace služby.
2. Ide najmä o prístupy umožňujúce:

• meniť DNS,
• meniť nameservery,
• získavať autorizačné alebo transferové kódy,
• meniť kontaktné údaje,
• meniť držiteľa alebo registranta,
• meniť nastavenia DNSSEC,
• vykonávať alebo potvrdzovať transfer domény,
• alebo vykonávať iné citlivé administratívne úkony.

3. Kompromitácia zákazníckeho účtu môže viesť k závažným následkom vrátane:

• presmerovania domény,
• zmeny DNS,
• zmeny MX záznamov,
• presmerovania e-mailovej komunikácie,
• získania autorizačného kódu,
• pokusu o transfer domény,
• zmeny kontaktných údajov,
• alebo iného neoprávneného zásahu do správy domény.

4. Zákazník zodpovedá za ochranu hesla, viacfaktorovej autentifikácie, recovery údajov a ďalších autentifikačných mechanizmov svojho zákazníckeho účtu.
5. Ak služba umožňuje viacfaktorovú autentifikáciu, WebHouse odporúča jej používanie najmä pri účtoch, prostredníctvom ktorých možno spravovať domény alebo iné kritické služby.
6. Zákazník zodpovedá za osoby, ktorým umožní prístup k správe svojho účtu alebo domén.
7. Po skončení oprávnenia zamestnanca, dodávateľa, administrátora alebo inej osoby je Zákazník povinný primerane odobrať jej prístup.
8. Autorizačný alebo transferový kód domény je bezpečnostne citlivý údaj a Zákazník je povinný chrániť ho pred neoprávneným sprístupnením.
9. Zákazník by nemal autorizačný kód poskytovať osobe, ktorá nemá byť oprávnená vykonať alebo pripraviť transfer domény.
10. Samotné získanie autorizačného kódu nemusí automaticky znamenať dokončenie transferu, keďže konkrétne podmienky transferu závisia aj od pravidiel príslušného registra alebo doménovej koncovky.
11. WebHouse môže pri citlivom úkone požadovať dodatočné overenie identity alebo oprávnenia osoby, ktorá úkon požaduje.
12. Dodatočné overenie môže byť primerané najmä pri:

• zmene držiteľa,
• zmene kontaktných údajov,
• vydaní autorizačného kódu,
• transferových operáciách,
• zmene bezpečnostných nastavení,
• alebo inom úkone s významným dopadom na kontrolu nad doménou.

13. Samotná znalosť názvu domény, fakturačných údajov alebo iných verejne či bežne dostupných informácií nemusí postačovať na vykonanie citlivého úkonu.
14. WebHouse môže pri dôvodnom podozrení na kompromitáciu účtu alebo neoprávnenú požiadavku citlivý úkon dočasne pozastaviť alebo odmietnuť, kým nebude primerane overené oprávnenie žiadateľa.
15. Takéto bezpečnostné opatrenie samo osebe nepredstavuje vadu služby, ak bolo vzhľadom na okolnosti primerané.
16. Ak má Zákazník dôvodné podozrenie na kompromitáciu zákazníckeho účtu, je povinný bez zbytočného odkladu primerane reagovať, najmä:

• zmeniť heslo,
• preveriť viacfaktorovú autentifikáciu,
• skontrolovať oprávnené osoby,
• preveriť vykonané zmeny,
• skontrolovať DNS a nameservery,
• a kontaktovať WebHouse, ak mohlo dôjsť k citlivému úkonu.

17. Pri podozrení na kompromitáciu doménového účtu môže byť potrebné preveriť aj stav domény, DNSSEC, transferové nastavenia a kontaktné údaje.
18. Samotná skutočnosť, že neoprávnená osoba vykonala úkon prostredníctvom platných prihlasovacích údajov Zákazníka, nepreukazuje bezpečnostné zlyhanie systémov WebHouse.
19. Ak boli prihlasovacie údaje získané prostredníctvom phishingu, malvéru, kompromitovaného zariadenia alebo osoby, ktorej Zákazník prístup poskytol, zodpovednosť sa posudzuje podľa skutočnej príčiny kompromitácie.
20. Ak však kompromitácia účtu alebo neoprávnený doménový úkon vznikne v dôsledku bezpečnostnej chyby alebo porušenia povinnosti v systéme spravovanom WebHouse, zodpovednosť sa posudzuje podľa tejto skutočnej príčiny.
21. WebHouse môže pri dôvodnom podozrení na zneužitie účtu vykonať primerané bezpečnostné opatrenia, napríklad:

• dočasne obmedziť citlivé operácie,
• vyžadovať zmenu hesla,
• vyžadovať dodatočné overenie,
• alebo zablokovať konkrétny administratívny úkon.

22. WebHouse nie je povinný vykonať pokyn osoby, ktorej oprávnenie na správu domény je sporné alebo nebolo primerane preukázané.
23. Ak o kontrolu nad doménou alebo účtom súčasne žiada viac osôb s protichodnými tvrdeniami, WebHouse môže požadovať ďalšie podklady alebo riešenie podľa pravidiel príslušného registra či právneho postupu.
24. WebHouse nie je povinný v rámci technickej podpory rozhodovať právny spor o vlastníctvo alebo oprávnenie k doméne.
25. Ak Zákazník používa externého registrátora, externé DNS alebo inú tretiu stranu na správu časti doménových služieb, WebHouse nezodpovedá za bezpečnosť účtu alebo systému tejto tretej strany.
26. Skutočnosť, že doména smeruje na službu WebHouse, sama osebe neznamená, že WebHouse spravuje aj registrátorský účet alebo DNS infraštruktúru Zákazníka.
27. Pri doménach môžu byť jednotlivé citlivé operácie obmedzené aj pravidlami príslušného registra, registrátora alebo konkrétnej doménovej koncovky.
28. WebHouse nemôže garantovať vykonanie úkonu, ktorý príslušný register alebo iný nadradený systém odmietne alebo neumožní.
29. Ak však WebHouse podľa služby zodpovedá za správne odoslanie alebo vykonanie doménového úkonu, zodpovedá za správne vykonanie tejto svojej časti procesu.
30. Konkrétne pravidlá transferu, zmeny držiteľa, autorizácie, DNSSEC alebo iných doménových operácií môžu byť upravené osobitnými podmienkami doménových služieb alebo pravidlami príslušného registra.

Článok 36

API a automatizácia

1. Ak služba umožňuje prístup prostredníctvom API, Zákazník zodpovedá za ochranu API kľúčov, tokenov a ďalších autentifikačných údajov, ktoré má vo svojej správe.
2. API kľúče, tokeny, tajomstvá klienta a obdobné údaje sa považujú za citlivé autentifikačné údaje.
3. Zákazník je povinný najmä:

• nepublikovať ich vo verejne dostupných zdrojových kódoch,
• neukladať ich do verejných repozitárov,
• neposkytovať ich neoprávneným osobám,
• nepoužívať ich na nedôveryhodných zariadeniach alebo systémoch,
• primerane ich chrániť pri ukladaní a prenose,
• a zrušiť alebo zmeniť ich pri podozrení na kompromitáciu.

4. Ak technické možnosti API umožňujú vytvoriť kľúč s obmedzenými oprávneniami, Zákazník by mal používať iba rozsah oprávnení potrebný na daný účel.
5. Zákazník by nemal používať jeden vysoko privilegovaný API kľúč pre viac nezávislých aplikácií alebo integrácií, ak je možné vytvoriť samostatné prístupy.
6. Ak je API kľúč používaný iba na čítanie údajov, má sa podľa možností uprednostniť oprávnenie iba na čítanie pred plným administrátorským prístupom.
7. Zákazník zodpovedá za aplikácie, skripty, automatizácie a integrácie, ktorým svoje API údaje poskytne.
8. Ak tretia aplikácia uloží alebo spracúva API kľúč Zákazníka, Zákazník zodpovedá za primerané posúdenie dôveryhodnosti tejto aplikácie.
9. API kľúče by nemali byť ukladané priamo v klientskom JavaScripte, verejnom mobilnom kóde alebo inom prostredí, z ktorého ich môže neoprávnená osoba jednoducho získať.
10. Zákazník by mal podľa technických možností používať bezpečné mechanizmy na uchovávanie tajných údajov, napríklad premenné prostredia, secret management alebo iné vhodné riešenia.
11. Ak má Zákazník dôvodné podozrenie, že API kľúč alebo token bol kompromitovaný, je povinný ho bez zbytočného odkladu zneplatniť alebo nahradiť.
12. Samotná zmena hesla používateľského účtu nemusí automaticky zneplatniť všetky existujúce API kľúče alebo tokeny.
13. Po bezpečnostnom incidente je preto potrebné primerane preveriť aj:

• aktívne API kľúče,
• tokeny,
• OAuth autorizácie,
• webhookové tajomstvá,
• a ďalšie automatizované prístupy.

14. Zákazník zodpovedá za zrušenie API prístupov, ktoré už nepotrebuje alebo ktoré používala osoba či aplikácia, ktorej oprávnenie skončilo.
15. WebHouse môže pri API používať technické bezpečnostné mechanizmy, najmä:

• rate limiting,
• obmedzenie počtu požiadaviek,
• kontrolu oprávnení,
• blokovanie podozrivých požiadaviek,
• časové obmedzenie tokenov,
• alebo iné primerané ochranné opatrenia.

16. WebHouse môže API kľúč alebo token dočasne obmedziť alebo zneplatniť, ak existuje dôvodné podozrenie na jeho kompromitáciu alebo zneužívanie.
17. WebHouse môže pri závažnom zneužití API obmedziť aj konkrétnu integračnú funkciu alebo prístup, ak je to potrebné na ochranu služby alebo infraštruktúry.
18. Samotné použitie platného API kľúča neoprávnenou osobou nepreukazuje bezpečnostné zlyhanie API alebo infraštruktúry WebHouse.
19. Ak bol API kľúč získaný napríklad z verejného repozitára, kompromitovanej aplikácie, zariadenia Zákazníka alebo systému tretej strany, zodpovednosť sa posudzuje podľa skutočnej príčiny kompromitácie.
20. Ak však kompromitácia API údajov vznikne v dôsledku bezpečnostnej chyby alebo porušenia povinnosti v systéme spravovanom WebHouse, zodpovednosť sa posudzuje podľa tejto skutočnej príčiny.
21. Zákazník zodpovedá za správnosť a bezpečnostné dôsledky automatizovaných úkonov, ktoré jeho aplikácia vykonáva prostredníctvom API.
22. Ak chybný skript alebo automatizácia napríklad:

• vymaže dáta,
• zmení DNS,
• vytvorí alebo zruší službu,
• zmení konfiguráciu,
• alebo opakovane vykoná neželanú operáciu,

samotná skutočnosť, že úkon spracovalo API WebHouse, neznamená chybu WebHouse.

23. Ak však API vykoná inú operáciu, než zodpovedá správne zadanej a podporovanej požiadavke, zodpovednosť sa posudzuje podľa skutočnej technickej príčiny.
24. WebHouse môže viesť technické logy API požiadaviek v rozsahu potrebnom na prevádzku, bezpečnosť a diagnostiku služby.
25. Dostupnosť a retenčná doba týchto logov nie sú neobmedzené, pokiaľ konkrétna služba výslovne nestanovuje inak.
26. API nemusí byť určené na neobmedzený počet požiadaviek alebo na ľubovoľný spôsob automatizácie.
27. Zákazník je povinný rešpektovať technické limity, dokumentovaný spôsob používania a bezpečnostné pravidlá API.
28. WebHouse môže pri neprimeranom množstve požiadaviek alebo správaní pripomínajúcom útok automatizovaný prístup primerane obmedziť.
29. Takéto obmedzenie samo osebe nepredstavuje vadu služby, ak bolo primerané ochrane infraštruktúry a v súlade s parametrami API.
30. WebHouse môže bezpečnostné alebo technické požiadavky API primerane meniť, najmä ak je to potrebné z dôvodu bezpečnosti, stability alebo vývoja technológie.
31. Ak zmena API vyžaduje úpravu zákazníckej integrácie, Zákazník zodpovedá za údržbu svojho integračného kódu, pokiaľ nebolo výslovne dohodnuté inak.
32. Ak konkrétna služba garantuje určitú verziu API, kompatibilitu, rozsah funkcií alebo dobu podpory, WebHouse rešpektuje tieto konkrétne podmienky v dohodnutom rozsahu.
33. Všeobecné ustanovenia o API nemožno použiť na obchádzanie konkrétnej bezpečnostnej alebo funkčnej garancie WebHouse.

Článok 37

Externí dodávatelia Zákazníka

1. Zákazník zodpovedá za osoby, ktorým umožní prístup k svojej službe, aplikácii, serveru, zákazníckemu účtu alebo inému systému vo svojej správe.
2. Môže ísť najmä o:

• programátorov,
• webové agentúry,
• marketingové agentúry,
• externých administrátorov,
• zamestnancov,
• dodávateľov,
• servisných pracovníkov,
• alebo iných spolupracovníkov.

3. Zákazník zodpovedá za rozsah oprávnení, ktoré týmto osobám poskytne.
4. Oprávnenia by mali byť podľa technických možností obmedzené iba na rozsah potrebný na vykonanie konkrétnej činnosti.
5. Ak je to možné, Zákazník by mal jednotlivým osobám vytvárať samostatné používateľské alebo administrátorské účty namiesto zdieľania jedného spoločného prístupu.
6. Zákazník zodpovedá za ochranu hesiel, SSH kľúčov, API kľúčov, tokenov a ďalších autentifikačných údajov, ktoré poskytne externému dodávateľovi.
7. Poskytnutím administrátorského alebo iného privilegovaného prístupu tretej osobe Zákazník prijíma riziko spojené s rozsahom oprávnení, ktoré jej udelil.
8. WebHouse nezodpovedá za zásahy vykonané takouto osobou v zákazníkom spravovanej vrstve, pokiaľ následok nevznikol v dôsledku porušenia povinnosti WebHouse.
9. Môže ísť najmä o:

• zmenu alebo vymazanie súborov,
• nesprávnu konfiguráciu,
• zmenu DNS,
• zmenu databázy,
• zmenu oprávnení,
• inštaláciu zraniteľného softvéru,
• zmenu firewallu,
• alebo iný administrátorský zásah vykonaný externým dodávateľom.

10. Ak externý dodávateľ použije platné prístupové údaje Zákazníka, samotná skutočnosť, že požadovaný úkon technicky vykonal systém WebHouse, neznamená chybu WebHouse.
11. Ak však systém WebHouse vykoná správne zadaný a podporovaný úkon nesprávne v dôsledku chyby vo svojej spravovanej vrstve, zodpovednosť sa posudzuje podľa tejto skutočnej príčiny.
12. Zákazník je povinný primerane kontrolovať, komu poskytol prístup k svojim službám a či tento prístup naďalej trvá oprávnene.
13. Po skončení spolupráce s externým dodávateľom alebo inou oprávnenou osobou je Zákazník povinný bez zbytočného odkladu primerane zrušiť alebo zmeniť jej prístupy.
14. Podľa charakteru služby môže byť potrebné zrušiť alebo preveriť najmä:

• používateľské účty,
• administrátorské účty,
• FTP alebo SFTP účty,
• SSH kľúče,
• databázové prístupy,
• API kľúče a tokeny,
• prístupy k zákazníckemu účtu,
• a ďalšie autentifikačné mechanizmy.

15. Samotná zmena hlavného hesla nemusí postačovať, ak externý dodávateľ používal vlastný účet, SSH kľúč, API token alebo iný samostatný spôsob prístupu.
16. Zákazník by mal osobitne preveriť prístupy pri:

• ukončení pracovného alebo zmluvného vzťahu,
• zmene agentúry,
• zmene administrátora,
• spore s dodávateľom,
• alebo inom stave, pri ktorom osoba už nemá mať prístup k službe.

17. Ak má Zákazník dôvodné podozrenie, že externý dodávateľ zneužil alebo mohol zneužiť svoj prístup, je povinný primerane reagovať a príslušné prístupy zrušiť alebo obmedziť.
18. WebHouse môže pri dôvodnom podozrení na zneužitie účtu alebo prístupu vykonať primerané bezpečnostné opatrenie, napríklad dočasne obmedziť prístup alebo požadovať zmenu autentifikačných údajov.
19. WebHouse nie je povinný určovať, či konkrétny zásah vykonal Zákazník osobne alebo osoba, ktorej Zákazník poskytol rovnaké platné prihlasovacie údaje, ak to z dostupných technických údajov nemožno spoľahlivo rozlíšiť.
20. Z tohto dôvodu sa odporúča používať samostatné účty pre jednotlivé osoby vždy, keď to konkrétna služba umožňuje.
21. Ak Zákazník poverí externého dodávateľa komunikáciou s WebHouse, môže WebHouse požadovať primerané preukázanie jeho oprávnenia, najmä pri citlivých alebo nezvratných úkonoch.
22. Samotná komunikácia externého dodávateľa s technickou podporou neznamená automaticky oprávnenie meniť držiteľa domény, získavať autorizačné kódy, meniť vlastnícke údaje alebo vykonávať iné citlivé operácie.
23. WebHouse môže pri citlivom úkone požadovať potvrdenie priamo od Zákazníka alebo inú primeranú formu autorizácie.
24. WebHouse nie je povinný riešiť obchodný, pracovný alebo právny spor medzi Zákazníkom a jeho externým dodávateľom.
25. Ak medzi viacerými osobami vznikne spor o oprávnenie spravovať službu, WebHouse môže do vyriešenia oprávnenia obmedziť citlivé zmeny, ak je to primerané ochrane služby alebo dát.
26. Skutočnosť, že WebHouse v minulosti komunikoval s konkrétnym externým dodávateľom, sama osebe neznamená, že táto osoba zostáva oprávnená konať za Zákazníka neobmedzene alebo trvalo.
27. Zákazník zodpovedá za aktuálnosť zoznamu osôb, ktorým poskytol oprávnenia, v rozsahu, v akom takúto správu konkrétna služba umožňuje.
28. Ak bezpečnostný incident vznikne v dôsledku konania externého dodávateľa v zákazníkom spravovanej vrstve, zodpovednosť za túto vrstvu zostáva na strane Zákazníka.
29. Ak však incident vznikne alebo sa jeho následky rozšíria v dôsledku samostatnej bezpečnostnej chyby v technickej vrstve spravovanej WebHouse, zodpovednosť WebHouse sa posudzuje podľa tejto skutočnej príčiny.
30. Ustanovenia tohto článku nemožno použiť na prenesenie zodpovednosti za chybu WebHouse iba preto, že Zákazník súčasne využíval služby externého dodávateľa.

Článok 38

Sociálne inžinierstvo

1. Zákazník je povinný venovať primeranú pozornosť podvodným požiadavkám, phishingu, vydávaniu sa za inú osobu a ďalším formám sociálneho inžinierstva.
2. Zákazník by mal osobitne overovať požiadavky, ktorých cieľom je najmä:

• získanie hesla,
• získanie autorizačného alebo transferového kódu,
• zmena DNS,
• zmena držiteľa alebo kontaktných údajov,
• zmena bankového účtu,
• vytvorenie alebo rozšírenie administrátorského prístupu,
• reset viacfaktorovej autentifikácie,
• alebo iný citlivý zásah do služby či účtu.

3. WebHouse môže zaviesť dodatočné procesy overovania identity alebo oprávnenia pri citlivých úkonoch.
4. Takéto overenie môže zahŕňať najmä:

• potvrdenie z registrovaného kontaktu,
• overenie prostredníctvom zákazníckeho účtu,
• viacfaktorovú autentifikáciu,
• dodatočné bezpečnostné údaje,
• alebo inú primeranú formu overenia.

5. Rozsah overenia môže závisieť od rizikovosti požadovaného úkonu.
6. Čím vyšší je možný dopad neoprávneného zásahu, tým vyššiu úroveň overenia môže WebHouse primerane požadovať.
7. Ak má WebHouse dôvodnú pochybnosť o oprávnenosti požiadavky, môže jej vykonanie pozastaviť do dodatočného overenia.
8. Dôvodná pochybnosť môže vzniknúť najmä vtedy, ak:

• požiadavka prichádza z neobvyklého kontaktu,
• obsahuje neobvyklú alebo naliehavú požiadavku,
• požadovaný úkon výrazne mení kontrolu nad službou,
• údaje žiadateľa nezodpovedajú evidovaným údajom,
• alebo existujú iné znaky možného zneužitia.

9. WebHouse nie je povinný vykonať citlivý úkon iba na základe toho, že žiadateľ pozná niektoré verejné, fakturačné alebo technické údaje o Zákazníkovi.
10. Ochrana účtu, domény, dát alebo služby pred neoprávneným zásahom môže mať pri dôvodnom bezpečnostnom riziku prednosť pred okamžitým vykonaním požiadavky.
11. Dočasné zdržanie citlivého úkonu z dôvodu primeraného bezpečnostného overenia samo osebe nepredstavuje vadu služby.
12. Ak sa oprávnenie žiadateľa primerane preukáže, WebHouse môže v požadovanom úkone pokračovať podľa podmienok konkrétnej služby.
13. WebHouse môže odmietnuť alebo pozastaviť pokyn, ktorý je zjavne nezvyčajný, nebezpečný alebo nezodpovedá bežnému spôsobu používania služby, kým nebude primerane potvrdený.
14. WebHouse môže pri podozrení na kompromitáciu účtu vyžadovať aj zmenu hesla, reset autentifikačných údajov alebo iné bezpečnostné opatrenie.
15. Zákazník zodpovedá za poučenie svojich zamestnancov, administrátorov a ďalších oprávnených osôb o rizikách sociálneho inžinierstva.
16. Zákazník by mal svojich používateľov primerane upozorniť najmä na to, aby:

• neposkytovali heslá tretím osobám,
• nepotvrdzovali nečakané MFA požiadavky,
• neotvárali podozrivé odkazy,
• neposkytovali autorizačné kódy bez overenia účelu,
• a overovali neobvyklé požiadavky cez nezávislý komunikačný kanál.

17. Ak Zákazník alebo osoba konajúca v jeho mene poskytne útočníkovi platné heslo, token, autorizačný kód alebo iný autentifikačný údaj v dôsledku phishingu alebo sociálneho inžinierstva, samotné následné použitie tohto údaja nepreukazuje bezpečnostné zlyhanie systémov WebHouse.
18. Ak však neoprávnený úkon vznikne v dôsledku nedostatočného overenia alebo iného porušenia povinnosti v procese, ktorý mal podľa konkrétnej služby zabezpečiť WebHouse, zodpovednosť sa posudzuje podľa tejto skutočnej príčiny.
19. Samotná skutočnosť, že útočník vystupoval dôveryhodne, poznal údaje o Zákazníkovi alebo používal sfalšovanú identitu, neznamená, že WebHouse musí vykonať jeho požiadavku bez ďalšieho overenia.
20. WebHouse môže pri citlivom úkone odmietnuť pokyn osoby, ktorej oprávnenie nemožno primerane overiť.
21. Ak o rovnakú službu alebo doménu žiadajú protichodné úkony viaceré osoby, WebHouse môže vykonanie citlivých zmien pozastaviť, kým nebude oprávnenie žiadateľa primerane preukázané.
22. WebHouse nie je povinný v rámci technickej podpory rozhodovať právny alebo obchodný spor medzi osobami, ktoré tvrdia, že sú oprávnené disponovať so službou.
23. Ak má WebHouse dôvodné podozrenie, že došlo ku kompromitácii zákazníckeho účtu, môže obmedziť citlivé operácie aj bez predchádzajúceho súhlasu Zákazníka.
24. Takéto opatrenie môže zostať v platnosti do vykonania primeraného overenia a zabezpečenia účtu.
25. Bezpečnostné overenie môže výnimočne viesť k oneskoreniu legitímnej požiadavky, ale jeho účelom je predísť podstatne závažnejšiemu následku neoprávneného zásahu.
26. Toto ustanovenie nemožno vykladať tak, že WebHouse môže svojvoľne alebo bez primeraného dôvodu zdržiavať bežné požiadavky Zákazníka.
27. Ak konkrétna služba stanovuje osobitné procesy autorizácie, overovania identity alebo správy oprávnených osôb, majú tieto konkrétne pravidlá pred týmto všeobecným ustanovením prednosť.

Článok 39

Bezpečnostné odporúčania

1. WebHouse môže Zákazníkom poskytovať všeobecné alebo individuálne bezpečnostné odporúčania súvisiace s používaním poskytovaných služieb.
2. WebHouse môže odporúčať najmä:

• používanie silných a unikátnych hesiel,
• používanie viacfaktorovej autentifikácie,
• pravidelné aktualizácie operačných systémov, aplikácií a ďalšieho softvéru,
• odstránenie nepoužívaného alebo zastaraného softvéru,
• obmedzenie administrátorských oprávnení,
• používanie samostatných používateľských účtov,
• pravidelnú kontrolu používateľských účtov a prístupov,
• používanie šifrovaných protokolov,
• ochranu API kľúčov, tokenov a ďalších autentifikačných údajov,
• pravidelné zálohovanie,
• používanie nezávislých záloh pri kritických systémoch,
• monitoring kritických aplikácií,
• bezpečné nastavenie firewallov,
• alebo iné primerané bezpečnostné opatrenia.

3. Rozsah odporúčaní môže závisieť od typu služby, charakteru incidentu, používaných technológií a známych bezpečnostných rizík.
4. WebHouse môže svoje bezpečnostné odporúčania priebežne meniť alebo dopĺňať podľa vývoja technológií, hrozieb a bezpečnostnej praxe.
5. Bezpečnostné odporúčanie samo osebe nepredstavuje garanciu, že jeho aplikáciou sa odstránia všetky bezpečnostné riziká.
6. Ani dôsledné dodržiavanie odporúčaných opatrení nezaručuje, že služba, aplikácia alebo účet nebude nikdy kompromitovaný.
7. Bezpečnostné opatrenia znižujú riziko incidentu, ale nemôžu úplne vylúčiť všetky možné zraniteľnosti, útoky alebo spôsoby zneužitia.
8. Poskytnutie bezpečnostného odporúčania neznamená, že WebHouse prevzal správu alebo bezpečnostnú zodpovednosť za technickú vrstvu, ktorej sa odporúčanie týka.
9. Ak WebHouse napríklad odporučí:

• aktualizovať WordPress,
• odstrániť zraniteľný plugin,
• zmeniť heslo,
• aktivovať viacfaktorovú autentifikáciu,
• upraviť firewall,
• alebo zmeniť inú konfiguráciu,

samotné odporúčanie neznamená prevzatie správy príslušnej aplikácie, účtu alebo systému.

10. Ak Zákazník odporúčanie vykonáva sám alebo prostredníctvom tretej osoby, zodpovedá za správne vykonanie zmien v technickej vrstve, ktorú spravuje.
11. Ak konkrétny zásah na základe dohody vykonáva WebHouse, zodpovedá za správne vykonanie tohto konkrétneho zásahu v rozsahu prijatej práce.
12. WebHouse nemusí pri všeobecnom odporúčaní poznať všetky osobitosti konfigurácie, aplikácie, prevádzky alebo obchodných procesov Zákazníka.
13. Zákazník je preto povinný primerane posúdiť vhodnosť odporúčania pre svoje konkrétne prostredie, najmä ak jeho vykonanie môže ovplyvniť kompatibilitu alebo funkčnosť aplikácie.
14. Ak je odporúčanie súčasťou riešenia konkrétneho bezpečnostného incidentu, môže byť založené na technických informáciách dostupných WebHouse v čase jeho poskytnutia.
15. Neskoršie zistenia môžu viesť k doplneniu alebo zmene pôvodného odporúčania.
16. Skutočnosť, že WebHouse upozorní Zákazníka na bezpečnostné riziko, neznamená automaticky, že WebHouse je povinný toto riziko odstrániť, ak sa nachádza v technickej vrstve spravovanej Zákazníkom.
17. Ak sa však bezpečnostné riziko nachádza v technickej vrstve spravovanej WebHouse, WebHouse zodpovedá za primeranú reakciu a nápravu v rozsahu svojich povinností.
18. Ak Zákazník vedome pokračuje v používaní známeho zraniteľného alebo nebezpečného komponentu napriek primeranému upozorneniu a dostupnej možnosti nápravy, nesie zvýšené riziko vyplývajúce z jeho ďalšieho používania v rozsahu svojej správy.
19. Samotné neposkytnutie všeobecného bezpečnostného odporúčania ku konkrétnej zákazníckej aplikácii neznamená, že WebHouse prevzal povinnosť túto aplikáciu priebežne monitorovať alebo bezpečnostne spravovať.
20. Ak konkrétna managed, bezpečnostná alebo monitorovacia služba výslovne zahŕňa pravidelné bezpečnostné odporúčania, kontroly alebo upozornenia, rozsah povinností WebHouse sa riadi podmienkami tejto služby.
21. Bezpečnostné odporúčania nemožno vykladať ako úplný zoznam všetkých opatrení, ktoré môžu byť pri konkrétnej službe alebo aplikácii potrebné.

Článok 40

Kritické a osobitne citlivé systémy

1. Zákazník je povinný primerane posúdiť, či objednaná služba svojimi technickými, bezpečnostnými a prevádzkovými vlastnosťami zodpovedá významu a citlivosti systému, ktorý na nej chce prevádzkovať.
2. Pri tomto posúdení by mal Zákazník zohľadniť najmä:

• význam systému pre svoju prevádzku,
• citlivosť a hodnotu spracúvaných dát,
• požadovanú dostupnosť,
• požadovanú úroveň izolácie,
• potrebu monitoringu a auditu,
• požiadavky na obnovu po incidente,
• regulačné alebo zmluvné požiadavky,
• a možné následky výpadku alebo bezpečnostného incidentu.

3. Bežný zdieľaný hosting nemusí byť vhodný pre každý typ aplikácie alebo systému.
4. Pri systémoch s mimoriadne vysokými požiadavkami na:

• bezpečnosť,
• dostupnosť,
• výkon,
• izoláciu,
• audit,
• reguláciu,
• ochranu citlivých údajov,
• kontinuitu prevádzky,
• alebo rýchlosť obnovy

je Zákazník povinný zvoliť primerané technické riešenie.

5. Zákazník by nemal vychádzať z predpokladu, že základná alebo štandardná služba poskytuje vlastnosti, ktoré nie sú uvedené v jej technických parametroch alebo osobitných podmienkach.
6. Samotná skutočnosť, že určitú aplikáciu možno technicky prevádzkovať na konkrétnej službe, neznamená, že táto služba je vhodná pre všetky bezpečnostné, regulačné alebo prevádzkové požiadavky Zákazníka.
7. WebHouse môže Zákazníkovi odporučiť vhodnejšie technické riešenie, napríklad:

• výkonnejšiu alebo vyššiu úroveň webhostingu,
• VPS,
• spravovaný VPS,
• dedikovaný server,
• individuálnu infraštruktúru,
• oddelené prostredie,
• rozšírené zálohovanie,
• monitoring,
• alebo samostatné bezpečnostné riešenie.

8. Takéto odporúčanie môže vychádzať z informácií, ktoré má WebHouse o požiadavkách Zákazníka v čase poskytnutia odporúčania.
9. WebHouse nie je štandardne povinný vykonávať úplnú bezpečnostnú, regulačnú alebo architektonickú analýzu systému Zákazníka iba na účely výberu služby, pokiaľ takáto konzultácia nebola osobitne dohodnutá.
10. Zákazník zodpovedá za oznámenie takých požiadaviek na službu, ktoré sú pre výber vhodného riešenia podstatné a ktoré WebHouse nemôže primerane poznať bez informácie od Zákazníka.
11. Ak Zákazník napríklad požaduje osobitnú úroveň dostupnosti, redundancie, geografického oddelenia, auditu, šifrovania alebo obnovy, mal by túto požiadavku zohľadniť pri výbere služby alebo ju výslovne komunikovať WebHouse.
12. WebHouse nezodpovedá za to, že základná služba nespĺňa požiadavku, ktorá nebola súčasťou jej deklarovaných parametrov alebo individuálne dohodnutá.
13. Ak však WebHouse pri konkrétnej službe výslovne garantuje určitú bezpečnostnú, dostupnostnú alebo inú vlastnosť, zodpovedá za jej dodržanie v dohodnutom rozsahu.
14. Kritický charakter systému Zákazníka sám osebe nerozširuje rozsah povinností WebHouse nad rámec objednanej služby.
15. Rovnako však kritický charakter systému nemožno použiť na zúženie alebo vylúčenie povinností, ktoré WebHouse pri konkrétnej službe výslovne prevzal.
16. Pri kritických systémoch by mal Zákazník primerane zvážiť použitie viacerých nezávislých ochranných mechanizmov.
17. Môže ísť najmä o:

• nezávislé zálohy,
• redundanciu,
• monitoring,
• viacfaktorovú autentifikáciu,
• oddelenie produkčného a testovacieho prostredia,
• obmedzenie administrátorských oprávnení,
• bezpečnostný dohľad,
• a plán obnovy po incidente.

18. Prevádzka kritického systému by nemala byť založená iba na jednom bezpečnostnom alebo obnovovacom mechanizme, ak by jeho zlyhanie mohlo mať neprimerane závažné následky.
19. Ak je systém predmetom osobitných regulačných, odvetvových alebo zmluvných požiadaviek, Zákazník zodpovedá za posúdenie, či konkrétna služba tieto požiadavky spĺňa v rozsahu, ktorý sa týka jeho používania služby.
20. WebHouse môže na požiadanie poskytnúť dostupné technické informácie o službe potrebné na takéto posúdenie.
21. Poskytnutie technických informácií WebHouse však samo osebe nepredstavuje právne, regulačné alebo certifikačné stanovisko k súladu systému Zákazníka s jeho osobitnými povinnosťami.
22. Ak Zákazník prevádzkuje na štandardnej službe systém s mimoriadne vysokými požiadavkami bez toho, aby si objednal príslušné rozšírené parametre, WebHouse nezodpovedá za absenciu vlastností, ktoré neboli súčasťou objednanej služby.
23. WebHouse môže upozorniť Zákazníka, ak z dostupných informácií vyplýva, že používaná služba nemusí byť primeraná deklarovaným požiadavkám Zákazníka.
24. Takéto upozornenie neznamená, že WebHouse preberá povinnosť priebežne posudzovať vhodnosť architektúry alebo bezpečnostného modelu Zákazníka.
25. Ak sa požiadavky Zákazníka v priebehu používania služby významne zmenia, Zákazník by mal primerane prehodnotiť vhodnosť zvoleného technického riešenia.
26. To platí najmä pri významnom náraste:

• objemu alebo citlivosti dát,
• počtu používateľov,
• významu systému pre prevádzku,
• požiadaviek na dostupnosť,
• alebo bezpečnostných a regulačných nárokov.

27. Ak konkrétna služba obsahuje SLA, osobitnú bezpečnostnú úroveň, definovanú redundanciu, RPO, RTO alebo iné konkrétne parametre, tieto parametre sa posudzujú podľa podmienok danej služby.
28. Všeobecné ustanovenie o povinnosti Zákazníka zvoliť primerané riešenie nemožno použiť na obchádzanie konkrétnej povinnosti alebo garancie WebHouse.

Článok 41

Bezpečnostná povaha technických limitov

1. Niektoré technické limity služby môžu byť zavedené aj z bezpečnostných, prevádzkových alebo stabilizačných dôvodov.
2. Ich účelom môže byť najmä:

• obmedzenie zneužitia služby,
• ochrana pred automatizovanými útokmi,
• zabránenie preťaženiu spoločnej infraštruktúry,
• obmedzenie škôd pri kompromitovanom účte,
• ochrana reputácie služby,
• alebo zachovanie primeranej dostupnosti pre ostatných zákazníkov.

3. Medzi takéto limity môžu patriť najmä:

• rate limiting,
• počet procesov,
• počet súbežných spojení,
• počet autentifikačných pokusov,
• limity odosielania e-mailov,
• limity API,
• limity databázových spojení,
• blokovanie alebo obmedzenie vybraných portov,
• limity prístupu,
• alebo iné technické obmedzenia primerané charakteru služby.

4. Technický limit môže mať súčasne bezpečnostný aj prevádzkový účel.
5. Napríklad limit odosielania e-mailov môže znižovať riziko rozsiahleho zneužitia kompromitovaného účtu na rozosielanie spamu.
6. Rate limiting alebo obmedzenie počtu prihlasovacích pokusov môže slúžiť na zmierňovanie automatizovaných útokov a pokusov o získanie neoprávneného prístupu.
7. Limity počtu procesov alebo spojení môžu zabraňovať tomu, aby jedna služba neprimerane zaťažila spoločnú infraštruktúru alebo ovplyvnila ostatných zákazníkov.
8. Zákazník je povinný používať službu spôsobom, ktorý rešpektuje technické limity a bezpečnostné mechanizmy stanovené pre danú službu.
9. Zákazník nesmie technické alebo bezpečnostné limity úmyselne obchádzať spôsobom, ktorý je v rozpore s účelom služby alebo bezpečnostnými pravidlami.
10. Za obchádzanie limitu sa môže považovať najmä technické konanie, ktorého hlavným účelom je obísť ochranný alebo prevádzkový mechanizmus služby.
11. Samotné využívanie viacerých legitímne poskytovaných funkcií alebo účtov však nemožno automaticky považovať za obchádzanie limitov, ak je takéto používanie v súlade s podmienkami služby.
12. Pri posudzovaní obchádzania limitov sa prihliada najmä na účel, spôsob a dopad konkrétneho používania služby.
13. Úmyselné obchádzanie bezpečnostných alebo technických limitov môže byť považované za porušenie podmienok služby.
14. WebHouse môže pri zistení takéhoto konania vykonať primerané technické alebo bezpečnostné opatrenie.
15. Môže ísť najmä o:

• obmedzenie konkrétnej funkcie,
• zablokovanie prístupu,
• dočasné zníženie počtu povolených operácií,
• zablokovanie zdrojovej IP adresy,
• alebo iné primerané opatrenie potrebné na ochranu služby.

16. Ak prekročenie limitu vzniklo v dôsledku bezpečnostného incidentu, napríklad kompromitácie účtu, WebHouse môže službu dočasne obmedziť aj bez predchádzajúceho súhlasu Zákazníka.
17. Takéto obmedzenie môže byť potrebné aj v prípade, ak Zákazník sám škodlivú aktivitu nespôsobil.
18. Vykonanie bezpečnostného limitu alebo automatizovaného obmedzenia samo osebe neznamená, že Zákazník porušil podmienky úmyselne.
19. Technické limity môžu byť uplatňované automatizovane.
20. Automatizované uplatnenie limitu môže v odôvodnených prípadoch dočasne zasiahnuť aj legitímnu prevádzku.
21. Takéto obmedzenie samo osebe nepredstavuje vadu služby, ak bolo vzhľadom na charakter služby a dostupné informácie primerané svojmu bezpečnostnému alebo prevádzkovému účelu.
22. WebHouse môže technické limity primerane meniť, ak je to potrebné v dôsledku:

• vývoja bezpečnostných hrozieb,
• zmeny technológie,
• spôsobu zneužívania služby,
• ochrany stability infraštruktúry,
• alebo zmien parametrov konkrétnej služby.

23. Zmenou všeobecných technických limitov však nemožno obchádzať konkrétny parameter alebo kapacitu, ktorú WebHouse Zákazníkovi výslovne garantoval.
24. Ak konkrétna služba deklaruje napríklad určitý počet spojení, procesov, API požiadaviek alebo inú konkrétnu kapacitu, WebHouse je povinný rešpektovať túto hodnotu v rozsahu podmienok danej služby.
25. Bezpečnostný mechanizmus môže pri mimoriadnom incidente dočasne obmedziť aj prevádzku, ktorá by za bežných okolností bola v rámci povoleného limitu, ak je to nevyhnutné na ochranu infraštruktúry alebo ostatných zákazníkov.
26. Takéto mimoriadne obmedzenie musí byť primerané charakteru bezpečnostného rizika a nesmie slúžiť na bežné obchádzanie deklarovaných parametrov služby.
27. WebHouse môže pri opakovanom dosahovaní technických limitov odporučiť Zákazníkovi vhodnejšiu službu alebo vyššiu kapacitu.
28. Samotné pravidelné dosahovanie limitu však nemusí znamenať bezpečnostný incident; môže ísť aj o prirodzený dôsledok rozsahu používania služby.
29. Ak dosiahnutie limitu spôsobuje aplikácia alebo konfigurácia Zákazníka, Zákazník zodpovedá za jej optimalizáciu alebo za výber primeranej služby v rozsahu svojej správy.
30. Ak však limit alebo jeho nesprávne uplatnenie vznikne v dôsledku chyby v technickej vrstve spravovanej WebHouse, zodpovednosť sa posudzuje podľa tejto skutočnej príčiny.
31. WebHouse nie je povinný z bezpečnostných dôvodov zverejniť úplné interné prahové hodnoty, detekčné pravidlá alebo spôsob fungovania všetkých ochranných mechanizmov, ak by ich zverejnenie mohlo znížiť účinnosť ochrany.
32. Konkrétne limity, ich hodnoty a prípadné pravidlá ich prekročenia môžu byť upravené v technických parametroch, cenníku alebo osobitných podmienkach jednotlivých služieb.
33. Ak konkrétne podmienky služby stanovujú odlišný alebo presnejší režim technických limitov, majú tieto podmienky pred týmto všeobecným ustanovením prednosť.

Článok 42

Bezpečnostné skenovanie

1. WebHouse môže vykonávať automatizované alebo manuálne bezpečnostné kontroly svojich systémov a zákazníckych služieb v rozsahu potrebnom na ochranu infraštruktúry, služieb a ostatných zákazníkov.
2. Takéto kontroly môžu zahŕňať najmä:

• vyhľadávanie známych prejavov malvéru,
• detekciu škodlivých alebo podozrivých procesov,
• detekciu neobvyklej sieťovej prevádzky,
• detekciu spamu alebo iného zneužívania služby,
• kontrolu integrity vybraných systémových komponentov,
• kontrolu vybraných známych bezpečnostných indikátorov,
• alebo iné primerané bezpečnostné mechanizmy.

3. Rozsah bezpečnostného skenovania závisí od charakteru konkrétnej služby, použitej technológie a technických možností WebHouse.
4. Bezpečnostné skenovanie nemusí zahŕňať všetky súbory, procesy, aplikácie, databázy alebo ostatné komponenty zákazníckej služby.
5. Bezpečnostný monitoring alebo skenovanie nepredstavuje nepretržitý audit bezpečnosti zákazníckej aplikácie.
6. WebHouse nie je štandardne povinný priebežne preverovať:

• zdrojový kód Zákazníka,
• všetky pluginy a témy,
• všetky zraniteľnosti CMS,
• aplikačnú logiku,
• všetky používateľské účty,
• ani úplnú bezpečnostnú konfiguráciu zákazníckej aplikácie,

pokiaľ takáto činnosť nie je výslovne súčasťou objednanej služby.

7. Skutočnosť, že automatizovaný bezpečnostný systém nezistil škodlivý obsah alebo zraniteľnosť, neznamená potvrdenie, že aplikácia alebo služba je bezpečná.
8. Bezpečnostné skenery môžu určitý škodlivý kód, zraniteľnosť alebo inú hrozbu nezachytiť.
9. Rovnako môžu v niektorých prípadoch legitímny súbor, proces alebo aktivitu vyhodnotiť ako podozrivú.
10. Samotný výsledok automatizovaného skenovania preto nepredstavuje úplný bezpečnostný audit ani forenzný záver o stave aplikácie.
11. WebHouse môže pri zistení podozrivej alebo škodlivej aktivity vykonať primerané ďalšie preverenie alebo bezpečnostné opatrenie.
12. Ak skenovanie identifikuje pravdepodobný malware, škodlivý proces, spamovú aktivitu alebo inú bezpečnostnú hrozbu, WebHouse môže:

• upozorniť Zákazníka,
• označiť podozrivý obsah,
• obmedziť konkrétnu funkciu,
• izolovať službu alebo jej časť,
• alebo vykonať iné primerané bezpečnostné opatrenie.

13. Na vykonanie bezodkladného ochranného opatrenia nemusí byť vždy vopred definitívne preukázané, že označený súbor alebo aktivita je škodlivá, ak dostupné technické údaje odôvodňujú primerané podozrenie a odklad by mohol zvýšiť bezpečnostné riziko.
14. Ak sa následne ukáže, že išlo o nesprávne vyhodnotenie, WebHouse môže primerane upraviť alebo zrušiť príslušné obmedzenie.
15. Skutočnosť, že WebHouse vykonáva bezpečnostné skenovanie zákazníckej služby, sama osebe neznamená, že preberá bezpečnostnú správu zákazníckej aplikácie.
16. Rovnako pravidelné vykonávanie automatizovaných kontrol nevytvára garanciu, že WebHouse odhalí každý bezpečnostný incident pred jeho vznikom alebo bezprostredne po ňom.
17. Zákazník naďalej zodpovedá za bezpečnosť technických vrstiev, aplikácií a komponentov, ktoré podľa objednanej služby spravuje.
18. Ak WebHouse Zákazníka upozorní na zistený bezpečnostný problém v zákazníkom spravovanej vrstve, Zákazník zodpovedá za jeho primerané odstránenie.
19. Samotné upozornenie WebHouse neznamená povinnosť WebHouse problém opraviť, ak jeho odstránenie patrí do správy Zákazníka.
20. Ak sa však zistený problém nachádza v technickej vrstve spravovanej WebHouse, WebHouse zodpovedá za primeranú reakciu a nápravu v rozsahu svojich povinností.
21. WebHouse môže bezpečnostné skenovanie priebežne meniť, rozširovať alebo upravovať podľa vývoja bezpečnostných hrozieb a používaných technológií.
22. WebHouse nie je povinný Zákazníkovi sprístupniť úplnú konfiguráciu, signatúry, detekčné pravidlá alebo interné mechanizmy bezpečnostného skenovania, ak by ich zverejnenie mohlo znížiť účinnosť ochrany.
23. Detailná bezpečnostná analýza, penetračný test, audit zdrojového kódu, kontrola zraniteľností alebo forenzná analýza môžu byť predmetom samostatnej služby.
24. Ak konkrétna managed alebo bezpečnostná služba výslovne zahŕňa určitý rozsah monitoringu, skenovania alebo detekcie hrozieb, WebHouse zodpovedá za jeho poskytovanie podľa podmienok tejto konkrétnej služby.
25. Všeobecné ustanovenie o obmedzeniach automatizovaného skenovania nemožno použiť na obchádzanie konkrétnej bezpečnostnej alebo monitorovacej povinnosti WebHouse.

Článok 43

Povinnosť oznámiť incident

1. Ak Zákazník zistí alebo má dôvodné podozrenie, že jeho služba, účet, aplikácia alebo server boli kompromitované a incident môže ovplyvniť infraštruktúru WebHouse, ostatných zákazníkov alebo tretie osoby, je povinný WebHouse bez zbytočného odkladu informovať.
2. Zákazník nie je povinný pred oznámením incidentu s istotou určiť jeho príčinu alebo rozsah.
3. Oznámenie je vhodné vykonať aj vtedy, ak existuje iba dôvodné podozrenie na bezpečnostný incident a jeho presný charakter ešte nie je známy.
4. Zákazník by mal WebHouse informovať najmä v prípade, ak zistí alebo má dôvodné podozrenie na:

• neoprávnený prístup,
• kompromitáciu administrátorského účtu,
• odcudzenie hesla, SSH kľúča, API kľúča alebo tokenu,
• prítomnosť malvéru alebo škodlivého kódu,
• rozosielanie spamu alebo phishingu,
• útoky smerujúce zo služby Zákazníka,
• zapojenie systému do botnetu,
• neobvyklú sieťovú aktivitu,
• neoprávnené zmeny DNS alebo konfigurácie,
• alebo inú udalosť, ktorá môže mať bezpečnostný dopad mimo samotnej služby Zákazníka.

5. Zákazník by mal oznámenie vykonať čo najskôr, najmä ak škodlivá aktivita stále prebieha.
6. Oneskorené oznámenie môže znížiť možnosť WebHouse:

• obmedziť ďalšie šírenie incidentu,
• zachovať dostupné technické informácie,
• identifikovať súvisiacu prevádzku,
• alebo zabrániť negatívnemu dopadu na ďalšie služby.

7. Zákazník by mal poskytnúť dostupné technické informácie potrebné na posúdenie incidentu.
8. Môže ísť najmä o:

• identifikáciu dotknutej služby alebo domény,
• približný čas zistenia incidentu,
• čas podozrivej udalosti, ak je známy,
• popis zisteného správania,
• chybové alebo bezpečnostné hlásenia,
• relevantné IP adresy,
• názvy podozrivých súborov alebo procesov,
• informáciu o nedávnych zmenách,
• alebo ďalšie dostupné údaje relevantné pre incident.

9. Zákazník nie je povinný poskytovať informácie, ktoré objektívne nemá k dispozícii.
10. WebHouse môže Zákazníka požiadať o doplnenie informácií alebo vykonanie primeraného diagnostického úkonu, ak je to potrebné na posúdenie alebo obmedzenie incidentu.
11. Zákazník je povinný poskytnúť primeranú súčinnosť v rozsahu potrebnom na ochranu infraštruktúry, ostatných zákazníkov alebo tretích osôb.
12. Ak je incident aktívny a predstavuje bezprostredné riziko, WebHouse nie je povinný čakať na úplné informácie alebo ďalšiu súčinnosť Zákazníka pred vykonaním nevyhnutného bezpečnostného zásahu.
13. WebHouse môže podľa okolností:

• obmedziť podozrivú komunikáciu,
• zablokovať kompromitovaný prístup,
• izolovať službu,
• obmedziť odosielanie e-mailov,
• alebo vykonať iné primerané opatrenie potrebné na zastavenie alebo obmedzenie incidentu.

14. Zákazník by nemal pred oznámením incidentu bez potreby odstraňovať alebo meniť technické údaje, ktoré môžu byť významné pre jeho diagnostiku.
15. Môže ísť najmä o relevantné logy, podozrivé súbory alebo údaje o vykonaných zmenách.
16. Toto ustanovenie však neznamená, že Zákazník musí ponechať škodlivú aktivitu v prevádzke iba z dôvodu zachovania dôkazov.
17. Ak je potrebné bezodkladne zastaviť incident, ochrana systému, dát a ostatných subjektov môže mať prednosť pred zachovaním všetkých technických stôp.
18. WebHouse môže Zákazníkovi poskytnúť primeranú technickú súčinnosť podľa rozsahu objednanej služby a technickej podpory.
19. Takáto súčinnosť môže zahŕňať najmä:

• preverenie dostupných logov,
• preverenie infraštruktúrnej vrstvy,
• poskytnutie dostupných technických informácií,
• pomoc pri identifikácii pravdepodobnej príčiny,
• alebo vykonanie bezpečnostného zásahu v spravovanej vrstve WebHouse.

20. Poskytnutie technickej súčinnosti neznamená automaticky prevzatie správy alebo bezpečnostnej zodpovednosti za zákaznícku aplikáciu, server alebo inú vrstvu spravovanú Zákazníkom.
21. WebHouse nie je v rámci štandardnej technickej podpory povinný vykonať úplnú forenznú analýzu incidentu, pokiaľ takáto služba nebola osobitne dohodnutá.
22. Ak sa príčina incidentu nachádza v technickej vrstve spravovanej Zákazníkom, Zákazník zodpovedá za vykonanie potrebných nápravných opatrení v tejto vrstve.
23. Ak sa príčina incidentu nachádza v technickej vrstve spravovanej WebHouse, WebHouse zodpovedá za primerané odstránenie alebo obmedzenie tejto príčiny v rozsahu svojich povinností.
24. Oznámenie incidentu Zákazníkom samo osebe neznamená uznanie jeho zodpovednosti za vznik incidentu.
25. Rovnako prijatie alebo riešenie oznámenia WebHouse neznamená automaticky uznanie zodpovednosti WebHouse.
26. Zodpovednosť sa posudzuje podľa skutočnej príčiny incidentu a rozdelenia správy jednotlivých technických vrstiev.
27. Ak incident zahŕňa osobné údaje, oznámenie WebHouse podľa tohto článku nenahrádza samostatné povinnosti Zákazníka, ktoré mu môžu vzniknúť podľa príslušných pravidiel ochrany osobných údajov.
28. Ak WebHouse vystupuje ako sprostredkovateľ osobných údajov, jeho povinnosti pri porušení ochrany osobných údajov sa riadia príslušnou DPA a záväznými právnymi predpismi.
29. Ak Zákazník vedome neoznámi prebiehajúci incident, o ktorom vie a ktorý následne spôsobuje ďalšiu škodlivú aktivitu alebo ohrozenie infraštruktúry, môže WebHouse vykonať potrebné bezpečnostné opatrenia podľa ostatných ustanovení týchto podmienok.
30. Konkrétna bezpečnostná, managed alebo incident-response služba môže ustanovovať podrobnejší spôsob oznamovania incidentov, kontaktné kanály alebo rozsah vzájomnej súčinnosti; tieto konkrétne podmienky majú v príslušnom rozsahu prednosť.

Článok 44

Zachovanie dôkazov

1. Ak si Zákazník želá vykonať podrobnejšiu analýzu alebo digitálnu forenznú analýzu bezpečnostného incidentu, mal by pred vykonaním zásadných zmien zvážiť zachovanie relevantných technických údajov a dôkazov.
2. Medzi relevantné údaje môžu patriť najmä:

• systémové a aplikačné logy,
• autentifikačné logy,
• sieťové záznamy,
• podozrivé súbory,
• informácie o procesoch,
• časové údaje,
• konfigurácia systému,
• zoznam používateľských účtov,
• a ďalšie technické informácie súvisiace s incidentom.

3. Obnova zo zálohy, preinštalovanie systému, aktualizácia softvéru, odstránenie súborov alebo zmena konfigurácie môže zmeniť alebo odstrániť stopy potrebné na neskoršiu analýzu incidentu.
4. Rovnako môže dôjsť k prepísaniu logov alebo iných údajov v dôsledku bežnej prevádzky systému alebo uplynutia retenčnej doby.
5. Ak je forenzná analýza pre Zákazníka dôležitá, mal by túto skutočnosť oznámiť WebHouse čo najskôr.
6. Samotné oznámenie požiadavky na zachovanie dôkazov však neznamená, že WebHouse je povinný automaticky vytvoriť úplnú forenznú kópiu systému.
7. WebHouse nie je povinný automaticky uchovávať forenznú kópiu každého kompromitovaného systému, virtuálneho servera, hostingového účtu alebo zákazníckej aplikácie.
8. Vytvorenie obrazu disku, snapshotu, kópie virtuálneho servera, exportu logov alebo iného forenzného podkladu môže byť predmetom osobitnej dohody alebo technických možností konkrétnej služby.
9. WebHouse negarantuje, že pri každom incidente bude technicky možné zachovať úplný stav systému v okamihu kompromitácie.
10. Niektoré údaje môžu byť v čase zistenia incidentu už:

• prepísané,
• odstránené,
• zmenené útočníkom,
• zmenené bežnou prevádzkou,
• alebo mimo retenčnej doby.

11. Zachovanie dôkazov nesmie neprimerane brániť vykonaniu nevyhnutných bezpečnostných opatrení.
12. Ak kompromitovaný systém aktívne:

• vykonáva útoky,
• šíri malware,
• rozosiela spam,
• ohrozuje ďalšie systémy,
• alebo inak predstavuje bezprostredné bezpečnostné riziko,

WebHouse môže vykonať potrebný ochranný zásah aj vtedy, ak tým dôjde k zmene niektorých potenciálnych forenzných stôp.

13. Ochrana infraštruktúry, ostatných zákazníkov, dát a tretích osôb môže mať pri aktívnom incidente prednosť pred zachovaním úplného forenzného stavu kompromitovaného systému.
14. Ak je to technicky možné a primerané okolnostiam, WebHouse môže pred zásahom alebo počas neho zachovať vybrané údaje, ktoré môžu byť relevantné pre neskoršie preverenie incidentu.
15. Takýto postup však nie je automaticky súčasťou štandardnej hostingovej alebo serverovej služby.
16. Ak Zákazník vykonáva zásahy do kompromitovaného systému sám alebo prostredníctvom tretej osoby, zodpovedá za vplyv týchto zásahov na zachovanie forenzných stôp.
17. Zákazník by mal pri požiadavke na neskoršiu forenznú analýzu primerane dokumentovať vykonané zásahy, najmä ich čas a charakter.
18. Skutočnosť, že určitý dôkaz nebol zachovaný alebo už nie je dostupný, sama osebe nepreukazuje zodpovednosť WebHouse ani Zákazníka za vznik incidentu.
19. Rovnako nemožnosť úplne zrekonštruovať incident z dôvodu chýbajúcich dôkazov neznamená automaticky, že incident vznikol v technickej vrstve jednej alebo druhej strany.
20. Ak WebHouse uchová technické údaje súvisiace s incidentom, ich rozsah môže byť obmedzený technickými možnosťami, retenčnými pravidlami, bezpečnostnými požiadavkami a právnymi povinnosťami.
21. WebHouse môže odmietnuť sprístupnenie alebo kopírovanie údajov, ktorých poskytnutie by mohlo ohroziť bezpečnosť infraštruktúry, zasiahnuť do práv iných zákazníkov alebo sprístupniť údaje tretích osôb.
22. Ak je možné relevantné údaje oddeliť bez neprimeraného rizika, WebHouse ich môže poskytnúť v primeranom rozsahu podľa podmienok konkrétnej služby alebo osobitnej dohody.
23. Ak Zákazník potrebuje dôkazy pre súdne, regulačné, poistné alebo iné formálne konanie, môže byť vhodné včas zapojiť kvalifikovaného externého odborníka na digitálnu forenziku.
24. Bežné technické údaje alebo logy poskytnuté WebHouse nemusia samy osebe spĺňať požiadavky na forenzné zabezpečenie dôkazov pre konkrétne právne alebo odborné konanie.
25. Ak konkrétna bezpečnostná, incident-response alebo forenzná služba výslovne zahŕňa uchovávanie obrazov systémov, snapshotov, logov alebo iných dôkazov, rozsah povinností WebHouse sa riadi podmienkami tejto konkrétnej služby.

Článok 45

Zodpovednosť za stratu dát

1. Rozsah zodpovednosti za zálohovanie, uchovávanie a obnovu dát sa riadi podmienkami konkrétnej služby a dokumentom „Pravidlá zálohovania, uchovávania a obnovy dát“.
2. Bezpečnostný incident neznamená automaticky vznik zodpovednosti WebHouse za stratu, poškodenie alebo nedostupnosť dát.
3. Pri posudzovaní zodpovednosti je rozhodujúca najmä:

• skutočná príčina incidentu,
• technická vrstva, v ktorej incident vznikol,
• rozsah správy WebHouse,
• rozsah správy Zákazníka,
• a konkrétne zálohovacie alebo obnovovacie povinnosti dohodnuté pri danej službe.

4. Je potrebné rozlišovať medzi:

• stratou dát,
• poškodením alebo zmenou dát,
• dočasnou nedostupnosťou dát,
• a neoprávneným sprístupnením alebo skopírovaním dát.

5. Tieto udalosti môžu mať rozdielnu príčinu a nemusia zakladať rovnaký rozsah zodpovednosti.
6. Ak dôjde k strate alebo poškodeniu dát v dôsledku kompromitácie aplikácie, účtu, hesla, softvéru alebo inej technickej vrstvy spravovanej Zákazníkom, samotná skutočnosť, že dáta boli uložené na infraštruktúre WebHouse, neznamená zodpovednosť WebHouse za vznik incidentu.
7. To platí napríklad pri:

• neoprávnenom zmazaní dát prostredníctvom kompromitovaného účtu,
• poškodení databázy zraniteľnou aplikáciou,
• ransomware v zákazníkom spravovanom systéme,
• nesprávnom zásahu administrátora Zákazníka,
• alebo zmazaní dát zákazníckym skriptom alebo API automatizáciou.

8. Ak však strata alebo poškodenie dát vznikne v dôsledku chyby, bezpečnostného zlyhania alebo nesprávneho zásahu v technickej vrstve spravovanej WebHouse, zodpovednosť sa posudzuje podľa tejto skutočnej príčiny.
9. Samotná existencia zálohy neznamená, že nedošlo k strate alebo poškodeniu dát.
10. Záloha môže umožniť obnovenie dát do skoršieho stavu, ale nemusí obsahovať všetky zmeny vykonané po poslednom bode obnovy.
11. Rozsah možnej straty dát medzi posledným dostupným bodom obnovy a okamihom incidentu závisí od frekvencie a parametrov zálohovania konkrétnej služby.
12. Ak konkrétna služba stanovuje RPO, frekvenciu zálohovania, retenčnú dobu alebo inú konkrétnu zálohovaciu garanciu, posudzuje sa zodpovednosť WebHouse aj podľa týchto parametrov.
13. Samotná možnosť obnoviť dáta zo zálohy nevylučuje posúdenie príčiny ich pôvodnej straty alebo poškodenia.
14. Rovnako nemožnosť úplnej obnovy dát neznamená automaticky zodpovednosť WebHouse, ak požadované dáta neboli predmetom zálohovania alebo už neboli v dostupnej retenčnej dobe.
15. Ak však WebHouse výslovne prevzal povinnosť konkrétne dáta zálohovať alebo uchovávať určitý rozsah bodov obnovy, zodpovedá za splnenie tejto povinnosti podľa podmienok danej služby.
16. Povinnosť Zákazníka vytvárať vlastné zálohy nemožno použiť na vylúčenie zodpovednosti WebHouse za zálohovaciu povinnosť, ktorú WebHouse výslovne prevzal.
17. Zákazník zodpovedá za vlastné dáta, ktoré sa nachádzajú mimo rozsahu zálohovania poskytovaného WebHouse.
18. Pri nespravovanom VPS, dedikovanom serveri alebo serverhousingu zodpovedá Zákazník za zálohovanie dát, pokiaľ si zálohovaciu službu osobitne neobjednal alebo nie je výslovne súčasťou služby.
19. Zákazník zodpovedá aj za dáta uložené výlučne na svojich lokálnych zariadeniach alebo v systémoch tretích strán, ktoré WebHouse nespravuje.
20. Bezpečnostný incident môže viesť k poškodeniu dát aj bez ich úplného zmazania.
21. Môže ísť napríklad o:

• zmenu databázových záznamov,
• poškodenie súborov,
• neoprávnenú zmenu obsahu,
• zašifrovanie dát útočníkom,
• alebo nepozorovanú manipuláciu s údajmi.

22. Pri takomto incidente nemusí byť vždy možné presne určiť, ktoré dáta boli zmenené a kedy k zmene došlo.
23. WebHouse preto negarantuje úplnú rekonštrukciu pôvodného stavu dát, pokiaľ takáto možnosť nevyplýva z konkrétneho rozsahu zálohovania alebo osobitnej služby.
24. Ak je to technicky možné, WebHouse môže pri incidente vykonať obnovu dát alebo poskytnúť dostupné body obnovy podľa podmienok služby.
25. Vykonanie obnovy dát samo osebe neznamená uznanie zodpovednosti WebHouse za ich pôvodnú stratu alebo poškodenie.
26. Rovnako poskytnutie technickej pomoci pri obnove neznamená prevzatie zodpovednosti za zákaznícku aplikáciu, ktorá stratu alebo poškodenie spôsobila.
27. Ak je obnova potrebná v dôsledku chyby alebo nesprávneho zásahu WebHouse, nemožno prácu potrebnú na nápravu tejto chyby automaticky považovať za nadštandardnú platenú obnovu.
28. Ak sa na vzniku straty alebo poškodenia dát podieľali okolnosti na strane WebHouse aj Zákazníka, zodpovednosť sa posudzuje podľa konkrétnych príčin a povinností oboch strán.
29. Samotná existencia bezpečnostného incidentu, nefunkčnej aplikácie alebo poškodených dát preto nepostačuje na určenie zodpovednosti bez posúdenia ich skutočnej technickej príčiny.
30. Ak konkrétna služba obsahuje osobitné pravidlá zálohovania, obnovy, RPO, RTO, retencie alebo zodpovednosti za dáta, majú tieto konkrétne podmienky pred týmto všeobecným ustanovením prednosť.
31. Všeobecné ustanovenia o zodpovednosti Zákazníka za vlastné dáta nemožno použiť na obchádzanie konkrétnej povinnosti alebo garancie WebHouse.

Článok 46

Zodpovednosť za bezpečnostný incident

1. Samotná existencia bezpečnostného incidentu nepreukazuje porušenie povinnosti WebHouse.
2. Rovnako samotná skutočnosť, že sa incident prejavil na službe poskytovanej WebHouse, neznamená automaticky, že jeho príčina vznikla v technickej vrstve spravovanej WebHouse.
3. Pri posúdení zodpovednosti je potrebné určiť najmä:

• miesto vzniku incidentu,
• jeho technickú príčinu,
• komponent alebo technickú vrstvu, ktorá bola kompromitovaná,
• spôsob, akým sa incident rozšíril,
• subjekt zodpovedný za správu dotknutého komponentu,
• rozsah správy WebHouse,
• rozsah správy Zákazníka,
• a povinnosti vyplývajúce z konkrétnej služby.

4. Rozhodujúca je skutočná príčina incidentu, nie iba miesto, na ktorom sa prejavil jeho následok.
5. Bezpečnostný incident môže vzniknúť v jednej technickej vrstve a následne sa prejaviť v inej vrstve.
6. Napríklad kompromitácia zákazníckej aplikácie môže viesť k:

• zmene alebo zmazaniu dát,
• rozosielaniu spamu,
• útokom na iné systémy,
• poškodeniu databázy,
• alebo zneužitiu serverových prostriedkov,

bez toho, aby bola kompromitovaná infraštruktúra WebHouse.

7. Naopak, bezpečnostná chyba v technickej vrstve spravovanej WebHouse môže mať následok aj v zákazníckej aplikácii alebo dátach.
8. WebHouse zodpovedá za bezpečnostný incident v rozsahu, v akom vznikol porušením povinnosti, za ktorú podľa zmluvy alebo záväzných právnych predpisov zodpovedá WebHouse.
9. WebHouse nezodpovedá za incident iba preto, že bol technicky realizovaný prostredníctvom infraštruktúry WebHouse.
10. Samotné uloženie zákazníckej aplikácie, dát alebo účtu na infraštruktúre WebHouse nepresúva bezpečnostnú zodpovednosť za zákazníkom spravovanú vrstvu na WebHouse.
11. Ak incident vznikol v dôsledku:

• zraniteľnosti zákazníckej aplikácie,
• kompromitovaného hesla,
• phishingu,
• malvéru na zariadení Zákazníka,
• zneužitia API kľúča alebo tokenu,
• nesprávnej konfigurácie Zákazníka,
• zásahu externého dodávateľa,
• alebo inej príčiny v technickej vrstve spravovanej Zákazníkom,

zodpovednosť sa posudzuje podľa tejto skutočnej príčiny.

12. Ak incident vznikol v dôsledku:

• bezpečnostnej chyby infraštruktúry,
• nedostatočného oddelenia zákazníckych prostredí,
• chyby systémového softvéru,
• nesprávnej konfigurácie,
• zanedbanej bezpečnostnej správy,
• alebo iného porušenia povinnosti

v technickej vrstve spravovanej WebHouse, zodpovednosť sa posudzuje podľa tejto príčiny.

13. Používanie primeraných alebo odporúčaných bezpečnostných opatrení Zákazníkom samo osebe nepresúva zodpovednosť za zákazníkom spravovanú vrstvu na WebHouse.
14. Rovnako samotná existencia bezpečnostných mechanizmov WebHouse neznamená, že WebHouse garantuje absolútne zabránenie každému možnému incidentu.
15. Skutočnosť, že antimalware, IDS/IPS, firewall, antispam alebo iný bezpečnostný systém určitý útok nezachytil, sama osebe nepreukazuje porušenie povinnosti WebHouse.
16. Posudzuje sa najmä to, či WebHouse splnil bezpečnostné povinnosti, ktoré mal podľa konkrétnej služby primerane vykonávať.
17. Bezpečnostný incident môže mať viac súbežných alebo nadväzujúcich príčin.
18. Ak sa na jeho vzniku alebo rozsahu podieľalo konanie alebo opomenutie WebHouse aj Zákazníka, zodpovednosť sa posudzuje podľa konkrétneho významu jednotlivých príčin a povinností oboch strán.
19. Samotná existencia chyby na strane Zákazníka automaticky nevylučuje možnosť samostatného pochybenia WebHouse.
20. Rovnako samotná chyba WebHouse automaticky neznamená, že WebHouse zodpovedá aj za nesúvisiace následky spôsobené samostatnou chybou alebo konaním Zákazníka.
21. Ak presnú príčinu incidentu nemožno spätne jednoznačne určiť, zodpovednosť nemožno automaticky pripísať WebHouse ani Zákazníkovi iba z dôvodu tejto neistoty.
22. Pri posudzovaní sa vychádza z dostupných technických informácií, najmä:

• logov,
• monitoringu,
• konfigurácie,
• časových údajov,
• stavu systémov,
• zistených zraniteľností,
• vykonaných zmien,
• a ďalších relevantných technických podkladov.

23. Absencia úplných logov alebo forenzných dôkazov sama osebe nepreukazuje zodpovednosť jednej zo strán.
24. Rovnako existencia určitej zraniteľnosti sama osebe nepreukazuje, že práve táto zraniteľnosť bola pri incidente skutočne zneužitá.
25. Úspešné prihlásenie prostredníctvom platného hesla, API kľúča, SSH kľúča alebo iného autentifikačného údaja samo osebe nepreukazuje, kde alebo akým spôsobom bol tento údaj kompromitovaný.
26. Pri určovaní zodpovednosti je potrebné rozlišovať medzi:

• príčinou incidentu,
• spôsobom jeho technického vykonania,
• následkom incidentu,
• a technickou vrstvou, v ktorej sa následok prejavil.

27. Bezpečnostný zásah WebHouse vykonaný na zastavenie alebo obmedzenie incidentu nepredstavuje automaticky uznanie zodpovednosti WebHouse za jeho vznik.
28. Rovnako poskytnutie pomoci pri obnove, diagnostike alebo čistení zákazníckej aplikácie neznamená automaticky prevzatie zodpovednosti za pôvodný incident.
29. Ak WebHouse vykoná nápravný zásah ešte pred úplným určením príčiny incidentu, môže tak urobiť s cieľom minimalizovať jeho dopad bez prejudikovania otázky zodpovednosti.
30. Ak sa následne preukáže, že príčina incidentu vznikla v technickej vrstve spravovanej WebHouse, WebHouse zodpovedá za nápravu v rozsahu svojich povinností.
31. Ak sa preukáže, že príčina vznikla v technickej vrstve spravovanej Zákazníkom, Zákazník zodpovedá za odstránenie príčiny v tejto vrstve.
32. Jednorazová technická pomoc WebHouse v zákazníkom spravovanej vrstve nemení automaticky rozdelenie zodpovednosti medzi stranami.
33. Ak konkrétna managed alebo bezpečnostná služba rozširuje rozsah správy WebHouse, zodpovednosť sa posudzuje podľa tohto rozšíreného rozsahu.
34. Samotné označenie služby ako managed však neznamená automaticky prevzatie zodpovednosti za všetky aplikácie, dáta alebo technické vrstvy Zákazníka.
35. Rozsah zodpovednosti za škodu, obnovu dát, zálohovanie, dostupnosť alebo inú konkrétnu otázku sa posudzuje aj podľa príslušných osobitných podmienok služby.
36. Ak konkrétna služba obsahuje SLA, bezpečnostnú garanciu, RPO, RTO alebo inú konkrétnu povinnosť WebHouse, posudzuje sa splnenie tejto povinnosti samostatne podľa jej podmienok.
37. Všeobecné ustanovenia o bezpečnostných incidentoch nemožno použiť na obchádzanie konkrétnej povinnosti alebo garancie WebHouse.
38. Zodpovednosť Zákazníka za jeho technickú vrstvu nemožno vykladať tak, že WebHouse nezodpovedá za vlastnú chybu alebo nesplnenú povinnosť vo svojej spravovanej vrstve.
39. Rovnako zodpovednosť WebHouse za jeho spravovanú vrstvu neznamená prevzatie všeobecnej zodpovednosti za všetky bezpečnostné riziká zákazníckych aplikácií, účtov, zariadení alebo externých systémov.
40. Pri posudzovaní bezpečnostného incidentu sa preto vždy vychádza z konkrétneho rozdelenia správy technických vrstiev, skutočnej príčiny incidentu a povinností jednotlivých strán podľa objednanej služby.

Článok 47

Primerané, nie absolútne zabezpečenie

1. Žiadny informačný systém, sieť, aplikáciu alebo bezpečnostný mechanizmus nemožno považovať za absolútne bezpečný.
2. Poskytovanie služby preto nemožno vykladať ako záruku, že:

• služba nebude nikdy napadnutá,
• nikdy nebude objavená nová zraniteľnosť,
• nedôjde k bezpečnostnému incidentu,
• každý útok bude automaticky rozpoznaný,
• každý útok bude úspešne zastavený,
• každý škodlivý súbor bude detegovaný,
• alebo nikdy nedôjde k neoprávnenému prístupu.

3. WebHouse prijíma bezpečnostné opatrenia primerané najmä:

• charakteru poskytovanej služby,
• rozsahu správy WebHouse,
• používaným technológiám,
• známym a primerane predvídateľným rizikám,
• technickým možnostiam,
• a konkrétnym bezpečnostným parametrom služby.

4. Rozsah primeraných bezpečnostných opatrení sa môže pri jednotlivých službách líšiť.
5. Iný rozsah bezpečnostnej správy môže byť primeraný pri zdieľanom webhostingu, nespravovanom VPS, managed serveri, serverhousingu alebo individuálnom bezpečnostnom riešení.
6. Bezpečnostná povinnosť WebHouse sa vždy vzťahuje na technické vrstvy a komponenty, ktoré podľa konkrétnej služby spravuje.
7. Samotná existencia bezpečnostného incidentu preto automaticky nepreukazuje, že WebHouse zanedbal bezpečnostné opatrenia alebo porušil svoju povinnosť.
8. Rovnako skutočnosť, že určitý bezpečnostný mechanizmus nezachytil konkrétny útok, sama osebe nepreukazuje jeho nesprávnu prevádzku alebo porušenie povinnosti WebHouse.
9. Pri posudzovaní splnenia bezpečnostných povinností sa prihliada na konkrétny rozsah služby a na opatrenia, ktoré mal WebHouse v danej technickej vrstve primerane zabezpečovať.
10. Bezpečnostné opatrenia WebHouse môžu zahŕňať viacero vzájomne sa dopĺňajúcich mechanizmov a nemusia byť založené na jednom konkrétnom technickom riešení.
11. WebHouse môže používané bezpečnostné opatrenia primerane meniť, nahrádzať alebo dopĺňať podľa vývoja technológií a bezpečnostných hrozieb.
12. Zákazník nemá nárok na zachovanie konkrétneho interného bezpečnostného mechanizmu, ak WebHouse zabezpečuje primeranú úroveň ochrany zodpovedajúcu podmienkam služby.
13. Bezpečnostné opatrenia môžu mať preventívny, detekčný, obmedzujúci alebo nápravný charakter.
14. Nie každému bezpečnostnému incidentu je možné zabrániť preventívnym opatrením; pri niektorých incidentoch je podstatná najmä ich včasná detekcia, obmedzenie alebo náprava.
15. Ani použitie aktuálneho softvéru, firewallu, IDS/IPS, antimalvéru, viacfaktorovej autentifikácie, šifrovania alebo iných bezpečnostných mechanizmov nepredstavuje absolútnu garanciu proti kompromitácii.
16. Rovnaký princíp platí aj na strane Zákazníka: skutočnosť, že Zákazník vykonal primerané alebo odporúčané bezpečnostné opatrenia, nepresúva sama osebe zodpovednosť za zákazníkom spravovanú technickú vrstvu na WebHouse.
17. Ak je napríklad zákaznícka aplikácia kompromitovaná prostredníctvom doposiaľ neznámej zraniteľnosti v komponente spravovanom Zákazníkom, samotná skutočnosť, že Zákazník používal aktuálny softvér a primerané bezpečnostné opatrenia, neznamená, že správu tejto aplikačnej vrstvy prevzal WebHouse.
18. Ak však bezpečnostný incident vznikne v dôsledku chyby, nedostatočného zabezpečenia, zanedbanej správy alebo iného porušenia povinnosti v technickej vrstve spravovanej WebHouse, zodpovednosť sa posudzuje podľa tejto skutočnej príčiny.
19. Skutočnosť, že absolútnu bezpečnosť nemožno garantovať, nezbavuje WebHouse povinnosti riadne vykonávať bezpečnostné činnosti, ktoré podľa konkrétnej služby prevzal.
20. Toto ustanovenie preto nemožno vykladať ako všeobecné vylúčenie zodpovednosti WebHouse za bezpečnostné pochybenie vo vlastnej spravovanej vrstve.
21. Rovnako ho nemožno použiť na ospravedlnenie nevykonania konkrétnej bezpečnostnej aktualizácie, ochranného opatrenia, monitoringu alebo inej činnosti, ktorú WebHouse výslovne prevzal.
22. Ak konkrétna služba obsahuje výslovnú bezpečnostnú garanciu, SLA, definovaný rozsah monitoringu alebo inú konkrétnu bezpečnostnú povinnosť, WebHouse zodpovedá za jej splnenie v dohodnutom rozsahu.
23. Všeobecné ustanovenie o nemožnosti absolútneho zabezpečenia nemožno použiť na obchádzanie konkrétnej povinnosti alebo garancie WebHouse.
24. Primeranosť bezpečnostných opatrení sa posudzuje vo vzťahu ku konkrétnej službe a rozsahu povinností WebHouse, nie podľa predstavy absolútnej ochrany pred všetkými technicky možnými útokmi.
25. Ak Zákazník potrebuje vyššiu úroveň ochrany, než poskytuje štandardná služba, môže byť potrebné zvoliť službu s rozšírenou bezpečnostnou správou, monitoringom, izoláciou alebo individuálne dohodnutými bezpečnostnými parametrami.

Článok 48

Rozdelenie zodpovednosti – orientačný prehľad

Tabuľka má informačný charakter. Rozhodujúci je rozsah konkrétnej objednanej služby a individuálna dohoda.

Článok 49

Vzťah k technickej podpore

1. Bezpečnostná zodpovednosť a rozsah technickej podpory sú rozdielne otázky.
2. Skutočnosť, že WebHouse Zákazníkovi v rámci technickej podpory alebo nad jej rámec pomôže napríklad:

• identifikovať malware,
• preveriť podozrivý súbor,
• obnoviť web,
• upraviť konfiguráciu,
• analyzovať log,
• zmeniť heslo alebo prístup,
• vykonať diagnostický zásah,
• alebo odporučiť bezpečnostné opatrenie,

neznamená, že WebHouse prevzal trvalú správu alebo bezpečnostnú zodpovednosť za danú časť systému.

3. Rozsah bezpečnostnej zodpovednosti sa určuje podľa objednanej služby a skutočne prevzatého rozsahu správy, nie podľa toho, akú jednorazovú pomoc WebHouse v konkrétnom prípade poskytol.
4. Je potrebné rozlišovať najmä medzi:

• diagnostikou problému,
• odporúčaním riešenia,
• jednorazovým technickým zásahom,
• obnovou alebo nápravou konkrétneho stavu,
• a trvalou správou alebo monitoringom systému.

5. Poskytnutie jednej z uvedených foriem pomoci automaticky neznamená prevzatie ostatných činností.
6. Ak WebHouse napríklad pomôže odstrániť malware zo zákazníckej aplikácie, neznamená to automaticky, že prevzal:

• pravidelnú aktualizáciu aplikácie,
• kontrolu jej pluginov alebo modulov,
• monitoring jej bezpečnosti,
• správu používateľských účtov,
• alebo zodpovednosť za jej budúce kompromitácie.

7. Rovnako pomoc pri obnove webu zo zálohy neznamená, že WebHouse prevzal správu aplikácie alebo zodpovednosť za odstránenie pôvodnej príčiny incidentu.
8. Pomoc pri analýze logov neznamená automaticky povinnosť vykonávať nepretržitý monitoring alebo forenznú analýzu zákazníckeho systému.
9. Jednorazová pomoc nad rámec služby nevytvára právo Zákazníka na rovnaký alebo obdobný zásah v budúcnosti.
10. To platí aj v prípade, ak bola takáto pomoc v minulosti poskytnutá bezplatne, ako goodwill alebo v rámci mimoriadneho riešenia incidentu.
11. Opakované poskytnutie obdobnej pomoci samo osebe nemení rozsah objednanej služby, pokiaľ nebolo výslovne dohodnuté rozšírenie správy.
12. WebHouse môže ďalšiu obdobnú pomoc:

• poskytnúť v rámci technickej podpory,
• ponúknuť ako platený nadštandardný zásah,
• odporučiť objednanie managed služby,
• alebo ju odmietnuť, ak nepatrí do rozsahu poskytovanej služby.

13. Ak WebHouse vykoná konkrétny technický zásah, zodpovedá za jeho správne vykonanie v rozsahu, v akom tento zásah prevzal.
14. Ustanovenie o jednorazovej pomoci preto nemožno vykladať tak, že WebHouse nezodpovedá za vlastnú chybu pri zásahu, ktorý sám vykonal.
15. Ak však bol konkrétny zásah vykonaný správne a následný problém vznikol v dôsledku inej príčiny v zákazníkom spravovanej vrstve, samotná predchádzajúca pomoc WebHouse nezakladá jeho zodpovednosť za tento následný problém.
16. WebHouse môže pri riešení incidentu vykonať aj dočasnú zmenu konfigurácie alebo bezpečnostné opatrenie určené iba na obmedzenie bezprostredného rizika.
17. Takéto dočasné opatrenie nemusí predstavovať trvalé riešenie príčiny incidentu.
18. Zákazník naďalej zodpovedá za vykonanie potrebných dlhodobých opatrení v technickej vrstve, ktorú spravuje.
19. Ak WebHouse výslovne odporučí ďalší krok potrebný na bezpečné pokračovanie prevádzky a tento krok patrí do správy Zákazníka, samotné odporúčanie neznamená povinnosť WebHouse tento krok vykonať.
20. Ak však potrebný nápravný krok patrí do technickej vrstvy spravovanej WebHouse, WebHouse zodpovedá za jeho vykonanie v rozsahu svojich povinností.
21. Skutočnosť, že technická podpora pomáha diagnostikovať príčinu incidentu, nepredstavuje priznanie zodpovednosti WebHouse za jeho vznik.
22. Rovnako technická pomoc Zákazníkovi neznamená, že WebHouse súhlasí s jeho tvrdením o príčine incidentu alebo rozsahu zodpovednosti.
23. Rozsah štandardnej technickej podpory sa riadi osobitným dokumentom „Rozsah a podmienky technickej podpory“ a podmienkami konkrétnej služby.
24. Ak konkrétna managed, bezpečnostná alebo administrátorská služba výslovne zahŕňa určitú činnosť, nejde v tomto rozsahu o jednorazovú dobrovoľnú pomoc, ale o súčasť povinností WebHouse podľa danej služby.
25. Všeobecné ustanovenie o jednorazovej technickej pomoci nemožno použiť na obchádzanie konkrétnej povinnosti WebHouse, ktorá je súčasťou objednanej služby.

Článok 50

Vzťah k SLA

1. Bezpečnostný incident a nedostupnosť služby podľa SLA sú rozdielne pojmy.
2. Bezpečnostný incident môže, ale nemusí viesť k nedostupnosti služby v zmysle SLA.
3. Rovnako nie každá nedostupnosť služby je spôsobená bezpečnostným incidentom.
4. Posúdenie bezpečnostného incidentu podľa tohto dokumentu preto samo osebe neurčuje, či sa konkrétne obdobie započítava do dostupnosti podľa SLA.
5. Bezpečnostný zásah vykonaný oprávnene a primerane na ochranu:

• infraštruktúry WebHouse,
• ostatných zákazníkov,
• dát,
• siete,
• alebo tretích osôb

nemusí predstavovať započítateľnú nedostupnosť podľa SLA, ak to pripúšťajú podmienky konkrétnej SLA.

6. Môže ísť najmä o dočasné:

• obmedzenie sieťovej komunikácie,
• blokovanie portu alebo IP adresy,
• izolovanie kompromitovanej služby,
• obmedzenie odosielania e-mailov,
• pozastavenie škodlivej aplikácie,
• alebo iný nevyhnutný bezpečnostný zásah.

7. Samotné označenie udalosti ako bezpečnostného incidentu alebo bezpečnostného zásahu však automaticky nevylučuje príslušné obdobie z výpočtu SLA.
8. Rozhodujúce je, či boli splnené podmienky výnimky ustanovené v konkrétnej SLA.
9. Pri posudzovaní sa môže prihliadať najmä na:

• dôvod zásahu,
• existenciu bezpečnostného rizika,
• primeranosť prijatého opatrenia,
• rozsah zásahu,
• jeho nevyhnutnosť,
• a trvanie obmedzenia.

10. Ak WebHouse obmedzí službu z dôvodu bezpečnostného incidentu, ktorého príčina vznikla v technickej vrstve spravovanej Zákazníkom, môže sa takéto obmedzenie posudzovať podľa bezpečnostných výnimiek uvedených v konkrétnej SLA.
11. Ak však nedostupnosť vznikne v dôsledku bezpečnostnej chyby alebo porušenia povinnosti v technickej vrstve spravovanej WebHouse, samotná skutočnosť, že udalosť mala bezpečnostný charakter, automaticky nevylučuje uplatnenie SLA.
12. Rovnako nemožno zo SLA automaticky vylúčiť nedostupnosť, ktorá vznikla v dôsledku nesprávneho, neprimeraného alebo chybne vykonaného bezpečnostného zásahu WebHouse.
13. Ak bola služba z bezpečnostných dôvodov obmedzená oprávnene, ale obmedzenie trvalo dlhšie, než bolo vzhľadom na okolnosti primerane potrebné, posúdenie nadbytočného obdobia sa riadi podmienkami konkrétnej SLA.
14. Bezpečnostný zásah môže mať odlišný dopad na jednotlivé časti služby.
15. Obmedzenie jednej funkcie preto nemusí automaticky znamenať úplnú nedostupnosť celej služby podľa SLA.
16. Pri určovaní dostupnosti sa vychádza z definície dostupnosti a spôsobu jej merania uvedeného v konkrétnej SLA.
17. Ak SLA rozlišuje úplnú nedostupnosť, čiastočnú degradáciu, plánovanú údržbu, bezpečnostný zásah alebo inú kategóriu udalosti, použije sa toto konkrétne rozdelenie.
18. Bezpečnostný incident sám osebe nepredstavuje nárok na kompenzáciu podľa SLA, pokiaľ súčasne nedošlo k udalosti, ktorá podľa podmienok SLA takýto nárok zakladá.
19. Naopak, vznik nároku podľa SLA nemusí automaticky znamenať, že WebHouse zodpovedá aj za samotný bezpečnostný incident alebo všetky jeho následky.
20. SLA spravidla upravuje najmä dostupnosť služby a príslušnú kompenzáciu za jej nedodržanie; otázka zodpovednosti za bezpečnostný incident sa posudzuje samostatne podľa jeho príčiny a rozsahu povinností jednotlivých strán.
21. Jedna udalosť preto môže byť súčasne posudzovaná:

• z pohľadu bezpečnostnej zodpovednosti,
• z pohľadu dostupnosti podľa SLA,
• z pohľadu zálohovania a obnovy,
• a prípadne z pohľadu ďalších zmluvných povinností.

22. Výsledok posúdenia jednej z týchto otázok automaticky neurčuje výsledok ostatných.
23. Ak konkrétna SLA obsahuje presnejšiu definíciu bezpečnostných výnimiek, plánovaných zásahov, vylúčených období alebo spôsobu výpočtu dostupnosti, majú tieto konkrétne ustanovenia pred týmto všeobecným článkom prednosť.
24. Podrobné pravidlá dostupnosti, spôsob merania, výnimky a prípadná kompenzácia sú upravené v dokumente „SLA – Garancia dostupnosti služieb“.
25. Všeobecné ustanovenie o bezpečnostnom zásahu nemožno použiť na obchádzanie konkrétnej garancie dostupnosti WebHouse alebo na svojvoľné vylúčenie obdobia nedostupnosti zo SLA.

Článok 51

Vzťah k DPA

1. Ak WebHouse pri poskytovaní služby spracúva osobné údaje v mene Zákazníka, rozdelenie povinností v oblasti ochrany osobných údajov upravuje aj dokument „Podmienky spracúvania osobných údajov – DPA“.
2. Tieto Podmienky nemenia rozdelenie úloh prevádzkovateľa a sprostredkovateľa podľa GDPR ani podľa príslušnej DPA.
3. Bezpečnostné povinnosti podľa týchto Podmienok a povinnosti pri spracúvaní osobných údajov podľa DPA sa posudzujú vo vzájomnej súvislosti, ale nejde o totožné otázky.
4. Skutočnosť, že WebHouse vystupuje pri určitom spracúvaní ako sprostredkovateľ, neznamená automaticky, že preberá správu všetkých aplikácií, účtov, databáz alebo iných technických vrstiev Zákazníka.
5. Rozsah technickej správy WebHouse sa naďalej určuje podľa konkrétnej objednanej služby.
6. Zákazník ako prevádzkovateľ zodpovedá najmä za účel a právny základ spracúvania, rozsah spracúvaných údajov a ďalšie povinnosti, ktoré mu podľa právnych predpisov patria ako prevádzkovateľovi.
7. WebHouse ako sprostredkovateľ zodpovedá za povinnosti, ktoré mu vyplývajú z DPA, záväzných právnych predpisov a rozsahu služieb, ktoré pri spracúvaní osobných údajov vykonáva.
8. Bezpečnostný incident v zákazníckej aplikácii nemusí automaticky znamenať porušenie povinnosti WebHouse ako sprostredkovateľa.
9. Rovnako však skutočnosť, že príslušné osobné údaje spracúva Zákazník ako prevádzkovateľ, nezbavuje WebHouse povinností, ktoré má ako sprostredkovateľ alebo ako správca vlastnej technickej vrstvy.
10. Pri incidente, ktorý sa týka osobných údajov, je potrebné samostatne posúdiť najmä:

• technickú príčinu incidentu,
• rozsah správy jednotlivých technických vrstiev,
• rolu jednotlivých strán podľa GDPR,
• povinnosti podľa DPA,
• a prípadné oznamovacie alebo súčinnostné povinnosti.

11. Technická zodpovednosť za príčinu incidentu a právna rola podľa GDPR nemusia byť totožné.
12. Napríklad kompromitácia zákazníckej aplikácie môže vzniknúť v technickej vrstve spravovanej Zákazníkom, pričom WebHouse môže súčasne ako sprostredkovateľ plniť povinnosti súčinnosti podľa DPA.
13. Naopak, ak incident vznikne v technickej vrstve spravovanej WebHouse a týka sa osobných údajov spracúvaných v mene Zákazníka, posudzujú sa aj príslušné povinnosti WebHouse podľa DPA a právnych predpisov.
14. Oznámenie bezpečnostného incidentu WebHouse podľa týchto Podmienok nenahrádza automaticky ďalšie povinnosti Zákazníka, ktoré mu môžu vzniknúť ako prevádzkovateľovi podľa právnych predpisov o ochrane osobných údajov.
15. Rovnako technické riešenie alebo odstránenie incidentu samo osebe nemusí znamenať splnenie všetkých povinností súvisiacich s porušením ochrany osobných údajov.
16. WebHouse môže Zákazníkovi v rozsahu DPA a svojich dostupných informácií poskytnúť primeranú súčinnosť pri posudzovaní incidentu.
17. Takáto súčinnosť môže zahŕňať najmä dostupné technické informácie o:

• dotknutej službe,
• čase zistenia incidentu,
• známej alebo pravdepodobnej technickej príčine,
• prijatých opatreniach,
• a dostupnom rozsahu technického dopadu.

18. WebHouse nemusí mať informácie o obsahu, význame, kategóriách alebo počte osobných údajov uložených v zákazníckej aplikácii, ak tieto údaje spravuje Zákazník.
19. Poskytnutie technických informácií WebHouse nepredstavuje právne posúdenie toho, či Zákazník musí incident oznámiť dozornému orgánu, dotknutým osobám alebo inému subjektu.
20. Ak DPA stanovuje konkrétnu lehotu, spôsob oznámenia incidentu, rozsah súčinnosti alebo inú konkrétnu povinnosť WebHouse, má toto konkrétne ustanovenie pred všeobecným ustanovením týchto Podmienok prednosť.
21. Tieto Podmienky nemožno vykladať spôsobom, ktorý by obmedzoval alebo vylučoval povinnosť WebHouse, ktorú nemožno podľa GDPR alebo iného záväzného právneho predpisu zmluvne vylúčiť.
22. Rovnako ich nemožno vykladať tak, že Zákazník prenáša na WebHouse svoje povinnosti prevádzkovateľa, pokiaľ takýto prenos nevyplýva z právnych predpisov alebo z osobitne dohodnutej služby.
23. Ak medzi týmito Podmienkami a DPA vznikne rozpor v otázke spracúvania alebo ochrany osobných údajov, použije sa v príslušnom rozsahu DPA a záväzné právne predpisy.

Článok 52

Zmluvné a zákonné práva

1. Tieto Podmienky upravujú najmä prevádzkové, technické a bezpečnostné rozdelenie zodpovednosti medzi WebHouse a Zákazníka.
2. Určujú najmä, ktorá strana spravuje jednotlivé technické vrstvy, aké bezpečnostné povinnosti v nich vykonáva a podľa akých zásad sa posudzuje príčina bezpečnostného incidentu.
3. Samotné určenie technickej zodpovednosti podľa týchto Podmienok ešte automaticky neurčuje rozsah prípadného nároku na náhradu škody alebo inú kompenzáciu.
4. Rozsah prípadnej náhrady škody, spôsob jej uplatnenia, limity zodpovednosti a ďalšie súvisiace podmienky upravujú Všeobecné obchodné podmienky, podmienky konkrétnej služby a príslušné právne predpisy.
5. Ak konkrétna služba obsahuje osobitnú SLA, kompenzačný mechanizmus, limit zodpovednosti alebo inú osobitnú úpravu následkov porušenia povinnosti, použije sa táto konkrétna úprava v príslušnom rozsahu.
6. Tieto Podmienky nemožno vykladať ako všeobecné vylúčenie zodpovednosti WebHouse za vlastné porušenie povinnosti.
7. Nemožno ich vykladať ani ako vylúčenie alebo obmedzenie zodpovednosti WebHouse v rozsahu, v akom takéto vylúčenie alebo obmedzenie nepripúšťa záväzný právny predpis.
8. Ak právny predpis priznáva Zákazníkovi právo, ktoré nemožno zmluvne vylúčiť alebo obmedziť, zostáva toto právo týmito Podmienkami nedotknuté.
9. Rovnako ustanovenia o zodpovednosti Zákazníka za zákazníkom spravovanú technickú vrstvu nemožno vykladať tak, že WebHouse nezodpovedá za vlastnú chybu alebo porušenie povinnosti vo svojej spravovanej vrstve.
10. Naopak, skutočnosť, že WebHouse zodpovedá za svoju technickú vrstvu, neznamená automatické prevzatie zodpovednosti za aplikácie, účty, zariadenia alebo iné komponenty, ktoré podľa konkrétnej služby spravuje Zákazník.
11. Ak sa na jednej udalosti podieľajú príčiny na strane WebHouse aj Zákazníka, posúdenie zodpovednosti a jej následkov sa vykoná podľa konkrétnych okolností, rozsahu povinností jednotlivých strán a príslušných zmluvných a právnych pravidiel.
12. Ustanovenia týchto Podmienok sa vykladajú vo vzájomnej súvislosti s:

• Všeobecnými obchodnými podmienkami,
• podmienkami konkrétnej služby,
• SLA,
• DPA,
• pravidlami zálohovania a obnovy dát,
• pravidlami technickej podpory,
• a ďalšími dokumentmi, ktoré sú podľa zmluvy súčasťou príslušného zmluvného vzťahu.

13. Ak osobitné podmienky konkrétnej služby upravujú určitú otázku presnejšie alebo odlišne od týchto všeobecných Podmienok, použijú sa v príslušnom rozsahu osobitné podmienky.
14. Všeobecné ustanovenie týchto Podmienok nemožno použiť na obchádzanie konkrétnej povinnosti, garancie alebo záväzku, ktorý WebHouse pri konkrétnej službe výslovne prevzal.
15. Ak by bolo niektoré ustanovenie týchto Podmienok v rozpore s kogentným právnym predpisom, použije sa príslušný právny predpis v rozsahu tohto rozporu.
16. Takáto skutočnosť nemá sama osebe vplyv na platnosť a použiteľnosť ostatných ustanovení týchto Podmienok, pokiaľ právny predpis alebo povaha veci nevyžaduje inak.
17. Tieto Podmienky nemožno vykladať spôsobom, ktorým by boli Zákazníkovi odňaté práva, ktorých sa podľa záväzných právnych predpisov nemôže platne vzdať.

Článok 53

Zmeny bezpečnostných opatrení

1. WebHouse môže bezpečnostné opatrenia, technické mechanizmy a bezpečnostné pravidlá priebežne meniť, aktualizovať, rozširovať alebo nahrádzať v reakcii najmä na:

• nové technológie,
• nové alebo zmenené zraniteľnosti,
• nové typy útokov,
• zmeny spôsobu zneužívania služieb,
• zmeny infraštruktúry,
• bezpečnostné odporúčania,
• ukončenie podpory používaných technológií,
• zmeny právnych alebo regulačných požiadaviek,
• alebo potrebu zvýšenia stability a bezpečnosti služieb.

2. Zmeny môžu zahŕňať najmä úpravu alebo nahradenie:

• firewallových pravidiel,
• filtrov sieťovej prevádzky,
• IDS/IPS mechanizmov,
• antispamových a antimalvérových systémov,
• autentifikačných mechanizmov,
• požiadaviek na heslá alebo viacfaktorovú autentifikáciu,
• podporovaných šifrovacích protokolov a algoritmov,
• rate limitov a ďalších ochranných limitov,
• spôsobu izolácie služieb,
• alebo iných bezpečnostných technológií.

3. Zákazník nemá nárok na zachovanie konkrétneho technického bezpečnostného mechanizmu, jeho výrobcu, produktu, konfigurácie alebo implementácie, ak WebHouse zabezpečí primerané náhradné riešenie zodpovedajúce charakteru a podmienkam služby.
4. WebHouse môže bezpečnostný mechanizmus nahradiť aj účinnejším alebo technicky vhodnejším riešením bez toho, aby išlo o zmenu podstaty objednanej služby.
5. Zákazník nemôže požadovať zachovanie zastaraného alebo bezpečnostne nevhodného mechanizmu iba z dôvodu kompatibility svojej aplikácie alebo predchádzajúceho spôsobu používania služby.
6. WebHouse môže najmä ukončiť podporu:

• zastaraného šifrovacieho protokolu,
• nebezpečného autentifikačného mechanizmu,
• zraniteľného spôsobu prístupu,
• alebo inej technológie, ktorej ďalšie používanie predstavuje neprimerané bezpečnostné riziko.

7. Ak bezpečnostné riziko vyžaduje bezodkladnú reakciu, WebHouse môže potrebnú zmenu vykonať aj bez predchádzajúceho súhlasu Zákazníka.
8. V naliehavom prípade WebHouse nemusí zachovať bežnú lehotu na oznámenie technickej zmeny, ak by odklad mohol viesť k bezpečnostnému incidentu alebo ohrozeniu infraštruktúry.
9. Ak nejde o naliehavú bezpečnostnú zmenu a zmena môže mať významný dopad na spôsob používania služby, WebHouse by mal Zákazníka primerane vopred informovať, ak je to vzhľadom na okolnosti možné.
10. Zákazník zodpovedá za primerané prispôsobenie svojich aplikácií, zariadení alebo integrácií zmeneným bezpečnostným požiadavkám v technickej vrstve, ktorú spravuje.
11. To môže zahŕňať najmä:

• používanie podporovaných TLS protokolov,
• aktualizáciu klientského softvéru,
• úpravu autentifikácie,
• aktiváciu nových bezpečnostných požiadaviek,
• alebo zmenu integračného spôsobu prístupu.

12. Nefunkčnosť zastaranej zákazníckej aplikácie po primeranom odstránení nebezpečného alebo nepodporovaného bezpečnostného mechanizmu sama osebe neznamená vadu služby.
13. WebHouse nie je povinný oslabovať bezpečnostné opatrenia celej infraštruktúry iba preto, aby zachoval kompatibilitu so zastaraným alebo nebezpečným systémom Zákazníka.
14. Ak je možné bezpečne poskytnúť individuálnu výnimku, WebHouse môže jej poskytnutie posúdiť, nie je však povinný takúto výnimku udeliť.
15. WebHouse môže bezpečnostnú výnimku odmietnuť alebo už poskytnutú výnimku zrušiť, ak predstavuje neprimerané riziko pre infraštruktúru, službu alebo ostatných zákazníkov.
16. Zmeny bezpečnostných opatrení môžu v odôvodnených prípadoch viesť k dočasnému obmedzeniu určitého spôsobu prístupu alebo používanej funkcie.
17. Takéto obmedzenie samo osebe nepredstavuje vadu služby, ak je primerané bezpečnostnému riziku a nie je v rozpore s konkrétnymi garantovanými parametrami služby.
18. WebHouse nie je povinný Zákazníkovi sprístupniť úplnú konfiguráciu bezpečnostných systémov, interné detekčné pravidlá, prahové hodnoty alebo iné informácie, ktorých zverejnenie by mohlo znížiť účinnosť ochrany.
19. Zmena konkrétneho bezpečnostného mechanizmu neznamená automaticky zníženie úrovne bezpečnosti služby.
20. Bezpečnosť sa posudzuje podľa výsledného rozsahu ochrany a povinností WebHouse, nie podľa zachovania konkrétneho produktu alebo technologického riešenia.
21. Ak však konkrétna služba výslovne garantuje určitý bezpečnostný mechanizmus, vlastnosť, certifikáciu, rozsah ochrany alebo inú konkrétnu bezpečnostnú funkcionalitu, WebHouse je povinný túto garanciu dodržať podľa podmienok služby.
22. WebHouse nemôže jednostrannou zmenou interného bezpečnostného mechanizmu obísť konkrétnu povinnosť alebo bezpečnostnú garanciu, ktorú pri danej službe výslovne prevzal.
23. Ak zmena bezpečnostného opatrenia súvisí s odstránením bezprostrednej hrozby, jej vykonanie samo osebe neznamená, že predchádzajúce riešenie bolo chybné alebo že došlo k bezpečnostnému incidentu.
24. Rovnako zavedenie nového bezpečnostného opatrenia neznamená automaticky, že WebHouse bol povinný rovnaké opatrenie používať aj pred jeho zavedením.
25. Pri posudzovaní bezpečnostných povinností sa prihliada na okolnosti, technický stav a primerane známe riziká v čase, keď mala byť príslušná povinnosť splnená.
26. Ak konkrétne podmienky služby stanovujú osobitný spôsob oznamovania alebo vykonávania bezpečnostných zmien, majú tieto konkrétne pravidlá pred týmto všeobecným ustanovením prednosť.

Článok 54

Záverečné ustanovenia

1. Tieto Podmienky tvoria súčasť zmluvnej dokumentácie WebHouse a uplatňujú sa na služby v rozsahu, v akom sa na ne podľa zmluvy alebo podmienok konkrétnej služby vzťahujú.
2. Tieto Podmienky sa vykladajú vo vzájomnej súvislosti najmä s:

• Všeobecnými obchodnými podmienkami,
• podmienkami konkrétnej služby,
• dokumentom „Rozsah a podmienky technickej podpory“,
• dokumentom „Pravidlá zálohovania, uchovávania a obnovy dát“,
• dokumentom „SLA – Garancia dostupnosti služieb“,
• dokumentom „Podmienky spracúvania osobných údajov – DPA“,
• a ďalšími dokumentmi, ktoré sú podľa zmluvy súčasťou zmluvného vzťahu.

3. Ak osobitné podmienky konkrétnej služby alebo individuálna dohoda upravujú určitú otázku presnejšie alebo odlišne od týchto všeobecných Podmienok, majú v príslušnom rozsahu prednosť.
4. Individuálne dohodnutá správa, managed služba, bezpečnostná služba alebo iný osobitne dohodnutý rozsah činností rozširuje povinnosti WebHouse iba v rozsahu, ktorý bol výslovne dohodnutý.
5. Individuálna dohoda sa nevzťahuje automaticky na technické vrstvy alebo činnosti, ktoré v nej nie sú zahrnuté.
6. Všeobecné ustanovenia týchto Podmienok nemožno použiť na obchádzanie konkrétnej povinnosti, garancie alebo záväzku, ktorý WebHouse pri konkrétnej službe výslovne prevzal.
7. WebHouse je oprávnený tieto Podmienky primerane meniť najmä v nadväznosti na:

• technologický vývoj,
• zmeny poskytovaných služieb,
• zmeny technickej infraštruktúry,
• nové bezpečnostné riziká,
• nové alebo zmenené spôsoby zneužívania služieb,
• zmeny bezpečnostných štandardov,
• právne alebo regulačné zmeny,
• alebo potrebu spresnenia pravidiel poskytovania služieb.

8. Zmena týchto Podmienok sa vykonáva spôsobom a za podmienok stanovených vo Všeobecných obchodných podmienkach a v príslušných právnych predpisoch.
9. Zmenou týchto Podmienok nemožno spätne meniť posúdenie udalosti, ktorá nastala pred účinnosťou zmeny, ak by takýto postup bol v rozpore so zmluvou alebo záväznými právnymi predpismi.
10. Ak je niektoré ustanovenie týchto Podmienok neplatné, neúčinné alebo nevykonateľné, nemá táto skutočnosť sama osebe vplyv na platnosť, účinnosť alebo vykonateľnosť ostatných ustanovení, pokiaľ právny predpis alebo povaha veci nevyžaduje inak.
11. Ak je niektoré ustanovenie týchto Podmienok v rozpore s kogentným ustanovením všeobecne záväzného právneho predpisu, použije sa v príslušnom rozsahu tento právny predpis.
12. Ustanovenia týchto Podmienok sa majú vykladať tak, aby bol podľa možnosti zachovaný ich účel a zároveň súlad so záväznými právnymi predpismi.
13. Žiadne ustanovenie týchto Podmienok nemožno vykladať ako vylúčenie alebo obmedzenie zodpovednosti WebHouse v rozsahu, v akom takéto vylúčenie alebo obmedzenie nepripúšťa záväzný právny predpis.
14. Žiadne ustanovenie týchto Podmienok nemožno vykladať spôsobom, ktorý by Spotrebiteľa zbavoval práv, ktoré mu podľa všeobecne záväzných právnych predpisov nemožno zmluvne odňať alebo obmedziť.
15. Ak sa niektoré ustanovenie týchto Podmienok uplatňuje odlišne na Spotrebiteľa a na Zákazníka, ktorý nie je Spotrebiteľom, použije sa voči Spotrebiteľovi vždy úprava vyžadovaná záväznými právnymi predpismi.
16. Nadpisy článkov a jednotlivých častí slúžia predovšetkým na lepšiu orientáciu a samy osebe nemenia obsah alebo rozsah práv a povinností vyplývajúcich z príslušných ustanovení.
17. Odkaz na konkrétnu technológiu, bezpečnostný mechanizmus alebo typ služby sa vykladá podľa jeho funkcie a účelu, pokiaľ z konkrétneho ustanovenia nevyplýva, že ide o presne určenú technológiu alebo produkt.
18. Ak konkrétna služba používa odlišnú terminológiu pre technické vrstvy alebo komponenty, rozhodujúci je ich skutočný technický účel a rozsah správy jednotlivých strán.
19. Práva a povinnosti, ktoré svojou povahou majú pretrvať aj po ukončení služby, nie sú ukončením služby dotknuté v rozsahu vyplývajúcom zo zmluvy alebo právnych predpisov.
20. Tieto Podmienky nadobúdajú účinnosť dňom uvedeným pri ich zverejnení alebo iným spôsobom určeným podľa Všeobecných obchodných podmienok.