Bezpečnostní aspekty¶

Účelem těchto pokynů je pomoci implementátorům a vlastníkům systému DHIS2 přijmout přiměřená a vhodná opatření k identifikaci a řízení rizik spojených s provozováním systému DHIS2. Doufáme, že to bude užitečné zejména pro vlastníky systémů, kteří by jinak mohli mít potíže s definováním a uvalováním technických omezení na implementátory.

DHIS2 je implementováno mnoha různými typy organizací v různých měřítcích a pro různé účely. Primárním vlastníkem systému je zde ministerstvo zdravotnictví nebo ministerstvo, ale mnohé z hlavních principů by měly platit také pro nevládní organizace a organizace soukromého sektoru.

DHIS2 jako webový systém dosahuje svého maximálního potenciálu, když je přístupný přes otevřený internet zdravotnickým pracovníkům pomocí jakýchkoli zařízení, která jim mohou být dostupná, a prostřednictvím jakýchkoli dostupných poskytovatelů připojení k internetu (např. systémy mobilních telefonů 4G). Viděli jsme, jak je při použití takového otevřeného modelu možné zavést národní systémy napříč zeměmi a programy během několika měsíců, nikoli let.

Bohužel jsme ve stejném období také viděli rostoucí hrozbu pro internetové systémy ze strany kriminálních i státních aktérů. Útoky se staly častějšími a sofistikovanějšími. Potřeba být důslednější a chytřejší je nyní mnohem zjevnější, než když byly před 10 lety uváděny první webové verze DHIS2.

Komplexní bezpečnostní praxe se týká DŮVĚRNOSTI, INTEGRITY a DOSTUPNOSTI dat.

DHIS2 byl pozoruhodně úspěšný při adaptaci a udržování v mnoha zemích jako národní zdravotnický informační systém, typicky jako souhrnný rutinní systém hlášení. Zatímco důvěrnost rutinních dat není pravděpodobně příliš důležitým problémem, integrita a dostupnost dat se stávají důležitějšími, protože systém se postupem času více institucionalizuje. Závažnější je zejména dopad ztráty dat.

Povaha dat shromážděných v DHIS2 se také stala citlivější. Databáze DHIS2 bude stále více obsahovat značné množství osobních identifikačních informací (PII) nebo osobních údajů. Mohou to být demografické údaje pacienta, ale také osobní údaje zdravotníků (e-mail, telefon, adresa, zprávy) zachycené jako informace o uživateli. Je třeba zavést přiměřená opatření na ochranu důvěrnosti takových údajů a soukromí zúčastněných osob.

Kontext použití¶

Právní a regulační souvislosti¶

Neexistuje žádný univerzální soubor zákonů, postupů a zásad, které by platily všude. Dominantní nedávnou legislativou týkající se ochrany osobních údajů v zemích Evropské unie je například GDPR (General Data Protection Regulation, in force from May 2018). This legislation introduces a set of guiding principles and accompanying terminology which differs in scope, justificatory narrative and intent from the U.S. HIPAA (Health Insurance Portability and Accountability Act), což je primární legislativa upravující zdravotní údaje v této zemi.

Oba tyto právní předpisy jsou poměrně nové a složité. Země, kde se DHIS2 používá, obecně nepodléhají ani HIPAA, ani GDPR, ale mnohé z nich vypracovaly nebo vypracovávají národní legislativu v této oblasti - například zákon o ochraně osobních údajů z roku 2013 v Jihoafrické republice a zákon o ochraně osobních údajů z roku 2019 (návrh) v Indii. Implementátoři a vlastníci systémů by měli vynaložit úsilí na to, aby se plně seznámili s legislativou v jurisdikci, kde ji používají. Organizace UNCTAD spravuje stránku s aktuálními právními předpisy o ochraně osobních údajů pro jednotlivé země po celém světě.

Pro systémy veřejného sektoru (možná většina případů použití DHIS2) mohou existovat další zásady a standardní provozní postupy související s bezpečností systémů a dat, které rovněž nesou váhu zákona.

Ve většině případů se nelze hájit neznalostí zákona.

Působit mimo kontext jakékoli relevantní legislativy a politiky je obtížné, ale v kontextech, kde je stávající regulační prostředí zastaralé nebo nevyhovující, je třeba na základě konsensu zavést vhodné kontroly v rámci samotného systému DHIS2.

Lidský a organizační kontext¶

Pro "vyspělé" kapitalistické ekonomiky je charakteristická vysoce rozvinutá dělba práce. Jasně to vidíme v odvětví informačních technologií v Evropě a USA, kde existují velmi jasné rozdíly mezi správci systémů, programátory, síťovými inženýry, koncovými uživateli informací a také vysoce rozvinuté struktury, role a postupy řízení informačních technologií, zejména ve velkých organizacích.

Je bláhové očekávat, že ve všech zemích najdeme stejné struktury a role, zejména tam, kde DHIS2 může být prvním nebo alespoň nejdůležitějším národním systémem v rámci národního ministerstva zdravotnictví. Zavádění komplexního webového systému, jako je DHIS2, bez relativně moderní základny managementu a kvalifikované pracovní síly s sebou přináší jedinečná rizika a výzvy. Vytvoření vhodných organizačních forem, které umožní zvládnout rizika a umožní systému prosperovat a udržet se, je přinejmenším stejně důležité jako jakékoli technické úvahy.

Výzva se zhoršuje tam, kde existuje složitá směs vládních ministerstev, partnerských organizací a dárců, z nichž všichni nemusí sdílet stejné perspektivy a priority, pokud jde o bezpečnost a soukromí.

Opatření¶

Organizační opatření¶

Tváří v tvář organizačním výzvám, kterým mohou majitelé systémů čelit, se stává důležitější než méně, aby vlastníci systému vyvinuli vhodný plán pro řízení bezpečnosti systému. Následuje malá sbírka praktických rad.

Mít plán správy zabezpečení je prvním krokem k prosazení jakéhokoli druhu vlastnictví systému. Pokud je ministerstvo zdravotnictví pasivním uživatelem systému vyvinutého a spravovaného partnerskými organizacemi, neprosazují vlastnictví.

Bezpečnost je otázka řízení. Nemůžete to delegovat na nejnižšího, nejtechničtějšího člověka v organizaci (běžné!), ani to nemůžete zadat technickému partnerovi (také běžné). Téměř jistě se o tyto zdroje opřete, ale motivace by měla být řízena vedením.

V ideálním světě by mohl existovat hlavní bezpečnostní ředitel (CSO) s profesionálním zázemím v některém z mnoha rámců zabezpečení a správy (TOGAF, ITIL, ISO27000x atd.). Je mnohem pravděpodobnější, že tomu tak nebude a lidé si musí vytvořit agilnější plán s tím, jaké zdroje mají. Improvizace může být klíčová. Mít špatný nebo alespoň špatně vypracovaný plán pro řízení bezpečnosti je mnohem lepší než nemít žádný plán. Slabý plán lze vylepšit a dále rozvíjet.

Doporučujeme, aby organizace přijaly některé z metod, jako je ISO27002 (Information Security Management), aniž by se nutně vydaly na cestu k souladu s normou ISO27000. Minimálně by to znamenalo, že:

1. Máte k dispozici prohlášení na vysoké úrovni shrnující bezpečnostní pozici vaší organizace. Jedná se o jednu stránku, která by měla zdůraznit zásady a záměry a signalizovat závazek vrcholového vedení k tomuto procesu.

2. V týmu jste jasně určili někoho (přiměřeně vysokého), kdo převezme úlohu vypracování, udržování a provádění bezpečnostního plánu. Můžeme jej nazvat manažerem bezpečnosti.

3. Manažer bezpečnosti se zavázal k procesu identifikace, dokumentace a zmírňování rizik. Jedná se o průběžný proces, který se zpravidla točí kolem vedení registru rizik, který podléhá pravidelné revizi.

4. Je zaveden proces (včetně času a rozpočtu) pro pravidelný interní a/nebo externí audit nasazení, konfigurace a metadat DHIS2, včetně bezpečnostního plánu organizace.

5. Existuje dohoda o sdílení údajů mezi stranami, která definuje, s jakými údaji se nakládá, za jakým účelem a jakým způsobem, přičemž jsou stanoveny jasné limity a hranice, aby se zabránilo narušení údajů o pacientech, jakož i ochrana integrity a důvěrnosti údajů.

6. Pro systém DHIS2 je stanoveno vlastnictví dat a technické vlastnictví.

Mnoho dalších artefaktů a procesů předpokládaných v rámci, jako je ISO 27000, by mohlo přirozeně vzniknout z tohoto cyklu. Například pokud neexistuje plán obnovy po havárii nebo strategie zálohování, bylo by to v registru označeno jako hlavní riziko. Sestavení a vedení takového registru umožňuje týmu identifikovat a stanovit priority úkolů, které je třeba provést, a vyhodnotit pokrok směrem k dosažení lepšího stavu.

Jako první krok každého bezpečnostního programu by měly být vytvořeny minimálně následující dokumenty: - Asset inventory - Dokument o hodnocení rizik / registr rizik - Zásady zálohování - Zásady obnovy po havárii - Plán reakce na incident - Plán správy identit a přístupu

Abychom implementátorům pomohli nastartovat jejich programy zabezpečení, vytvořili jsme sadu šablon, které může každý použít a přizpůsobit svým potřebám, nazvanou Security Starter Kit.

Opatření pro konfiguraci systému¶

Existuje také řada opatření, která lze učinit pro zlepšení zabezpečení na úrovni konfigurace DHIS2, například související se zajištěním vhodného přístupu k systému a datům. Zde je uveden navrhovaný seznam opatření pro konfiguraci systému s vysokou prioritou (10 nejlepších):

Správa systému

1. Do systému má superuživatelský (plný) přístup omezený počet osob (méně než 5). Lze snadno vyhodnotit prostřednictvím rozhraní API: /api/users.json?filter=userCredentials.userRoles.authorities:!in:[_ALL_]&filter=userCredentials.userRoles.authorities:in:\[ALL].

2. Správci systému mají oprávnění pouze k provádění funkcí, které jsou relevantní pro jejich role při správě systému. Například správce odpovědný za správu grafů a panelů nepotřebuje práva k úpravě organizačních jednotek..

3. Výchozí uživatelský účet DHIS2 (uživatelské jméno "admin") je smazán nebo zakázán. Účet "admin" by měl být použit pouze při prvním spuštění systému DHIS2 pro nastavení osobního superuživatele. Poté by měl být zakázán a/nebo odstraněn. Stav účtu admin lze ověřit pomocí rozhraní API: /api/users.json?filter=userCredentials.username:eq:admin&fields=name,userCredentials\[name,disabled\]

Správa uživatelů

4. Existují postupy pro zakázání nebo odstranění uživatelských účtů osob, které službu opustí. Měly by být zavedeny jasné postupy pro deaktivaci/odstranění uživatelských účtů osob, které opouštějí (zdravotní) službu. Určitý náznak tohoto postupu lze odvodit z rozhraní API, a to tak, že se podíváme na uživatelské účty, které nejsou zakázány a které se do systému nepřihlásily např. v aktuálním roce: /api/users.json?filter=userCredentials.disabled:eq:false&filter=userCredentials.lastLogin:lt:2021

5. Všechny uživatelské účty v systému jsou osobní, tj. nejsou sdíleny více osobami. Uživatelské účty by neměly být sdíleny několika osobami, protože to znemožňuje audit. To je obzvláště důležité, pokud se nástroj Tracker používá pro údaje na úrovni jednotlivců.

6. Existují jasně definované uživatelské role a uživatelské skupiny s pokyny, jaké role a skupiny by měly být používány podle postavení uživatele v rámci (zdravotnické) služby.

7. Pokud je povolena samoregistrace uživatelů, uživatelská role přidělená těmto uživatelům by měla být velmi omezená, např. pouze na prohlížení veřejných panelů.

8. Zakázání účtů by mohlo být dobrým způsobem, jak omezit přístup k některým uživatelům, kteří byli v systému zapomenuti. Systém DHIS2 poskytuje naplánovanou úlohu, která toto automatizuje. Uvědomte si však, že to může mít důsledky (vedoucí ke ztrátě dat) při používání zařízení se systémem Android, jak je vysvětleno v oficiální dokumentaci.

Tracker

9. Přístup k datům Trackeru je omezen na uživatele s oprávněnou potřebou upravovat/prohlížet data prostřednictvím vhodného použití sdílení a uživatelských skupin. Žádné programy typu tracker určené k použití pro záznam informací o jednotlivých osobách nejsou nakonfigurovány s veřejným přístupem. *Údaje trackeru jsou obvykle spojeny s jednotlivými osobami, a proto by měly být omezeny na uživatele s legitimním využitím těchto údajů. Ačkoli by bylo vhodné, aby souhrnné údaje byly přístupné všem uživatelům, v případě údajů ze sledovacích zařízení tomu tak není *.

10. Programy sledování jsou nakonfigurovány tak, aby uživatelé mohli vyhledávat a přistupovat pouze k údajům o osobách, k jejichž prohlížení mají oprávněný důvod. Například uživatel pracující v rámci jednoho zdravotnického zařízení by neměl být přiřazen k okresu. "Organizační jednotka pro vyhledávání sledovaných subjektů" by neměla být nastavena širší, než je prakticky nutné, pokud je používána.

Android

Používání mobilních zařízení (Android) v systému DHIS2 je stále častější díky jejich možnostem práce v režimu offline a na poslední míli. Přináší však další požadavky, na které je třeba se zaměřit z hlediska bezpečnosti, protože se zvyšuje expozice při přechodu z jednoho serveru obsahujícího informace na více zařízení, která mohou obsahovat citlivé informace.

Pokud jsou v zařízeních ukládány citlivé informace, je třeba vzbudit obavy prostřednictvím školení a/nebo dokumentace. A správci systému by mohli chtít povolit různá opatření, která by mohla pomoci snížit rizika, pro která je k dispozici webová aplikace Android Settings Web App (ASWA).

ASWA umožňuje správcům systému (mimo jiné):

• Vynutit šifrování místní databáze DHIS2 v zařízeních, aby se zabránilo úniku dat škodlivým subjektům v případě, že mají přístup k zařízení.
• Povolení/zakázání funkce snímání obrazovky snižuje (ale neomezuje) riziko úniku důvěrných informací.

V části oficiální dokumentace (DHIS2 Android App) jsou všechny tyto funkce podrobně popsány.

Kromě toho může být aplikace pro Android individuálně nakonfigurována tak, aby požadovala PIN kód jako další vrstvu zabezpečení k dvojici uživatelské jméno/heslo.

V implementacích, kde existuje riziko ztráty/odcizení zařízení, mohou správci systému chtít přidat další vrstvu zabezpečení, kterou přinášejí nástroje jako Mobile Device Management, které by mohly umožnit vzdálené vymazání, lokalizaci atd. Konkrétní návod je k dispozici v oficiální dokumentaci: správa mobilních zařízení.

Technická opatření¶

Existuje mnoho způsobů, jak lze systém DHIS2 zřídit, včetně různých fyzických prostředí (místní, společné umístění, privátní cloud, veřejný cloud) pomocí různých operačních systémů, pomocí kontejnerů, sdílení zátěže, replikace atd. Existují různé podrobné soubory bezpečnostních kontrol, které mohou a měly by být uplatňovány v závislosti na těchto volbách návrhu, které jsou provedeny při zajišťování.

V nejobecnějším smyslu můžeme říci, že by mělo existovat:

• zdokumentovaný soubor povinných technických kontrol
• proces auditu proti těmto kontrolám

Organizace, jako je Centrum pro internetovou bezpečnost (https://cisecurity.org), udržují podrobné srovnávací testy softwarových produktů, které lze použít k sestavení souboru kontrol pro vaši implementaci. Ve většině případů nepoužijete všechny z nich, ale vyberete ty, které jsou nejvhodnější. Ze seznamu dostupného na adrese https://www.cisecurity.org/cis-benchmarks/ byste si měli stáhnout a prostudovat benchmarky pro Apache Tomcat, Postgresql, nginx (nebo Apache2). Kromě toho můžete v závislosti na volbě technologie najít benchmarky pro Ubuntu linux, lxd, Docker nebo Microsoft Windows, které jsou pro vaši implementaci relevantní.

Navrhovaný seznam technických opatření s vysokou prioritou (10 nejlepších), která by měla být zavedena:

1. Operační systém je LTS (long term service edition).

2. Existuje automatický proces aplikace bezpečnostních záplat operačního systému.

3. Brána firewall na bázi hostitele a/nebo sítě je nakonfigurována tak, že do sítě jsou zpřístupněny pouze nezbytné služby.

4. Administrativní přístup k serveru DHIS2 probíhá prostřednictvím SSH v souladu s dohodnutými osvědčenými postupy - pouze ověřování klíčů, žádný přístup roota, explicitní seznam uživatelů, nízký počet maximálních pokusů o ověření.

5. Verze DHIS2 není o více než 3 verze pozadu za nejnovější verzí. Existuje proces, který pravidelně aplikuje opravné verze.

6. Je zaveden a pravidelně testován automatizovaný systém zálohování, včetně zálohování mimo pracoviště.

7. Uživatelé systému Postgres a systému se řídí zásadou nejmenších oprávnění: povolují pouze minimální oprávnění a přístupy.

8. DHIS2 je vystaven přes webový server nakonfigurovaný s TLS/SSL (musí získat minimálně A v ssllabs).

9. Data databáze jsou na odděleném místě (datový oddíl, pevný disk, cloudové úložiště atd.), což umožňuje šifrování v klidovém stavu.

10. Jsou zavedeny systémy monitorování a upozorňování na systémové metriky (CPU, paměť, disk, síť, databáze, minimálně webový proxy server) s odpovídajícími mechanismy ověřování (např. 2FA, SSO, požadavky na silné heslo) a přístupem založeným na rolích.