Bezpečnost služby Shipvise

Verze: 1.0
Účinnost: dnem zveřejnění této verze
Naposledy aktualizováno: 20. 8. 2026
Stabilní URL: https://shipvise.com/cs/legal/security/

Tento dokument poskytuje konzervativní veřejný přehled bezpečnostních principů Shipvise. Nejde o certifikaci, auditní zprávu ani příslib opatření, která nejsou reálně nasazena.

1. Přístup k bezpečnosti

Shipvise je platforma, která sestavuje a spouští zákaznický software. Bezpečnost proto řeší odděleně:

zákaznický účet a Portál;
control plane;
zdrojový kód a build;
Preview/staging;
Production;
runtime konfiguraci a secrets;
data a zálohy;
lidský support a review.

Bezpečnostní opatření se průběžně mění s architekturou. Veřejná tvrzení se mají vztahovat pouze k aktuálnímu produkčnímu stavu.

2. Veřejná komunikace

Veřejné webové služby Shipvise jsou určeny k provozu přes HTTPS/TLS. Produkční konfigurace musí před zveřejněním této verze ověřit platnost certifikátů, HTTPS redirect a bezpečnostní hlavičky.

Interní komunikace uvnitř infrastruktury nemusí být ve všech vrstvách end-to-end TLS. Shipvise proto netvrdí, že každé interní spojení je samostatně šifrováno TLS.

3. Hesla a přihlášení

Lokální hesla nejsou ukládána v plaintextu; autentizační stack používá jednosměrné hashování hesel.

Browser přihlášení používá server-side session a ochranu proti CSRF. Session cookie je určena k nastavení jako Secure a HttpOnly s odpovídajícím SameSite režimem.

Shipvise může používat dočasný lock po opakovaných chybných pokusech o přihlášení a další anti-abuse opatření.

4. MFA

MFA není součástí MVP a Shipvise netvrdí, že ji podporuje nebo vynucuje.

Její případné zavedení bude samostatnou bezpečnostní změnou.

5. Role a oprávnění

Shipvise používá role a aplikační oprávnění k omezení funkcí podle role uživatele ve Workspace.

Principem je least privilege: uživatel a technická identita mají mít pouze oprávnění potřebná pro danou operaci.

Ne všechny budoucí administrátorské nebo Enterprise funkce musí být v MVP dostupné.

6. Staging a Production

Preview/staging a Production jsou logicky rozlišena jako samostatná prostředí a mají používat oddělenou konfiguraci a oprávnění.

To neznamená fyzicky oddělený hardware nebo kernel pro každý tenant. Shipvise nesmí popisovat současný model jako fyzickou tenant izolaci, pokud taková architektura není skutečně nasazena.

Produkční data se nemají automaticky kopírovat do staging bez záměrné funkce nebo pokynu zákazníka.

7. Build prostředí

Shipvise přijímá skutečnost, že zákaznický build může obsahovat nedůvěryhodný kód.

Před umožněním veřejných arbitrary-code buildů musí produkční build infrastruktura používat bezpečnostní boundary odpovídající tomuto riziku, zejména oddělení od citlivého control plane, omezená oprávnění, resource limity a přiměřené síťové omezení.

Veřejný arbitrary-code provoz nesmí být spuštěn na známé konfiguraci, která je interně označena jako nevyhovující pro nedůvěryhodné buildy.

8. Runtime workloady

Produkční runtime je navržen s omezenými oprávněními workloadů a resource limity. Podle aktuální architektury mohou být používány například:

non-root běh;
zákaz privilege escalation;
omezení Linux capabilities;
read-only root filesystem tam, kde je to technicky vhodné;
seccomp/runtime hardening;
Kubernetes resource quotas/limits;
logické síťové politiky.

Účinnost konkrétní kontroly závisí na reálně nasazeném clusteru a musí být provozně ověřena.

9. Immutable artefakty a release

Shipvise je navržen tak, aby build vytvořil konkrétní OCI artefakt identifikovaný immutable digestem a aby promotion/rollback pracoval se stejným artefaktem bez skrytého rebuildu.

Tento princip zlepšuje reprodukovatelnost a dohledatelnost release. Neznamená však automaticky, že artefakt neobsahuje chybu nebo bezpečnostní zranitelnost.

10. Secrets

Runtime secrets mají být odděleny od zdrojového kódu a immutable build artefaktu.

Běžné zákaznické API nemá vracet plaintext secret values a secrets nemají být záměrně zapisovány do build/runtime logů nebo AI promptů.

Revokovaný nebo kompromitovaný secret se nesmí stát znovu použitelným pouze tím, že zákazník aktivuje starší Release.

Před veřejným MVP musí být kompletní produkční cesta bezpečného přijetí, uložení a injekce runtime secretu dokončena a ověřena.

11. Šifrování uložených dat

Shipvise netvrdí univerzální encryption-at-rest, dokud není šifrování konkrétního úložiště technicky ověřeno.

Hashování hesel není totéž jako encryption-at-rest všech databází, Git repozitářů, OCI registry, Kubernetes secrets nebo záloh.

Bezpečnostní dokumentace bude po zavedení ověřeného encryption-at-rest odpovídajícím způsobem aktualizována.

12. Zálohy

Vybraná zákaznická a platformní data jsou standardně zálohována denně a provozní zálohy mají standardní rotační retenci 7 dní.

Zálohy jsou ukládány mimo hlavní běžící workload na vlastní provozní infrastrukturu Shipvise a přenos probíhá privátním zabezpečeným propojením.

Záloha je určena pro disaster recovery, ne jako trvalý archiv.

Standardní tarif negarantuje smluvní RPO/RTO ani přesný čas obnovy. Shipvise se při incidentu snaží obnovu provést bez zbytečného odkladu z dostupné použitelné zálohy.

13. Logy a auditní záznamy

Shipvise zaznamenává vybrané technické a bezpečnostně relevantní operace, například build/deployment/release nebo změny runtime konfigurace, pokud je daná funkce auditována aplikací.

Standardní build/runtime logy mají běžnou retenční dobu 14 dní.

Shipvise netvrdí, že všechny přímé infrastrukturní administrátorské zásahy jsou dnes kryptograficky neměnně auditovány. Rozsah auditu se bude postupně rozšiřovat.

14. Vulnerability management

Shipvise průběžně udržuje platformní software a dependencies. Pokud není konkrétní automatický scan nebo release gate výslovně uveden jako dostupná funkce, zákazník nemá předpokládat, že každý build, image nebo dependency automaticky prochází úplným vulnerability scanem.

Review není náhradou za bezpečnostní testování zákaznické aplikace.

15. Lidský administrátorský přístup

Shipvise nepředstírá, že provozovatel infrastruktury nemůže technicky získat přístup k zákaznickým datům.

Přístup má být omezen na nezbytný rozsah a účel, například:

zákazníkem objednaný Senior Review nebo Assisted Fix;
support požadavek;
provozní nebo bezpečnostní incident;
zákonnou povinnost.

Osoby s přístupem jsou povinny zachovávat mlčenlivost.

16. Senior Review

Senior Review je nezávislé odborné posouzení v předem dohodnutém rozsahu. Reviewer může získat přístup k relevantnímu source, diffu a logům.

Review nesmí být prezentováno jako absolutní bezpečnostní certifikace nebo záruka, že Aplikace nemá chyby či zranitelnosti.

17. Monitoring a incidenty

Shipvise používá technické health a provozní mechanismy v rozsahu aktuální platformy a může mít alerty na vybrané kritické komponenty.

Standardní služba nemá garantovanou 24/7 lidskou on-call podporu. Běžná podpora je poskytována zejména v pracovních dnech. Kritický incident může být řešen i mimo ně podle dostupnosti, ale není to smluvní SLA.

U porušení osobních údajů, kdy Shipvise jedná jako zpracovatel, informuje zákazníka bez zbytečného odkladu podle DPA.

18. Odpovědnost zákazníka

Zákazník odpovídá za zabezpečení vlastní aplikační logiky, použití správných access controls, aktualizaci dependencies, bezpečnou správu vlastních třetích účtů a za to, že do logů nebo source záměrně nevkládá secrets.

Shipvise security controls nenahrazují bezpečnostní povinnosti zákazníka vůči jeho vlastním uživatelům.

19. Co standardní MVP negarantuje

Pokud individuální smlouva výslovně nestanoví jinak, Shipvise zejména negarantuje:

konkrétní procento uptime;
smluvní RPO/RTO;
24/7 lidskou podporu;
MFA;
fyzickou izolaci každého zákazníka;
univerzální encryption-at-rest všech vrstev;
úplný immutable audit všech admin zásahů;
automatický vulnerability scan každého zákaznického buildu;
absolutní bezpečnost nebo bezchybnost zákaznické Aplikace.

20. Hlášení bezpečnostního problému

Bezpečnostní incident nebo zneužití lze hlásit na abuse@shipvise.com. Běžné technické problémy na support@shipvise.com.