Bezpečnost dat

Bezpečné úložiště je úložiště citlivých dat v systému ABRA Gen. Slouží pro ukládání hesel a tokenů uživatelů ABRA Gen, autentizačních dat, e-mailových a SMTP účtů a je také dostupné ze skriptování a API pro použití v aplikacích třetích stran.

Pro podporu bezpečného úložiště používáme knihovnu abracrypt napsanou v jazyce Rust.

Pro podporu bezpečného úložiště byla vytvořena tabulka SecureStore, do které se ukládají všechny citlivé údaje, jako jsou hesla, tokeny, apod.

Sloupce v tabulce:

• SKey - klíč
• SDomain - doména
• SValue – hodnota (Text BLOB)

Nejprve přehledná tabulka, jaká data jsou aktuálně šifrována. Tabulka obsahuje původní umístění dat před uložením do bezpečného úložiště. Původní sloupec zůstává pro zachování zpětné kompatibility, ale data se již neukládají a hodnoty ve sloupcích jsou vynulovány.

Většina hodnot je přímo šifrována pomocí symetrické šifry AES-128-GCM do bezpečného úložiště.

Výjimkou jsou pouze položky pro přístup uživatele do systému. Tyto hodnoty jsou ještě před uložením do bezpečného úložiště hashovány:

• SecPassword + SecToken jsou hashovány pomocí SHA-384
• SecPortalPassword pomocí MD5, jelikož se takto zahashované přímo používá

Příklad šifrování a dešifrování hesla uživatele

Šifrování:

• Zahájí se proces uložení, kde vstupují: VALUE, SDOMAIN, SKEY
  • SDOMAIN = předdefinovaná doména (např. auth, email, bank)
  • SKEY = složený klíč (prefix + ID), např. password/1234
  • VALUE – například heslo uživatele "Heslo".
  • Tato VALUE se ještě zahashuje pomocí SHA-384, takže ve VALUE je hash hesla (tento krok je výjimka pro SecPassword uživatele, jak je uvedeno výše)
  • AAD = spojení SKEY + SDOMAIN, převedené na bajty (GetBytes(SKEY + SDOMAIN))
  • AAD se nešifruje, ale vstupuje do výpočtu autentizační značky → chrání kontext
  • K samotnému VALUE se přidá náhodný 16bytový SALT:
  • DATA = SALT | VALUE
• DATA + AAD + CIPHER_KEY se předají knihovně abracrypt
  • Knihovna vygeneruje 12bytový náhodný NONCE.
  • Proběhne šifrování pomocí AES-128-GCM s klíčem CIPHER_KEY a NONCE:
  • Výsledek = ENCRYPTED_DATA (šifrovaný obsah)
  • Na konci ENCRYPTED_DATA je AUTH_TAG (16 B), který zajišťuje integritu a ověření AAD/NONCE

Dešifrování:

• Načte se uložený blob z DB
• Oddělí se z něj NONCE, ENCRYPTED_DATA a AUTH_TAG
• Pomocí AES-128-GCM se znovu inicializuje šifra se stejným CIPHER_KEY, načteným NONCE a původním AAD (musí být identické jako při šifrování)
• Ověří se, zda AUTH_TAG souhlasí (pokud ne, dešifrování se odmítne → data byla změněna nebo AAD neodpovídá)
• Pokud kontrola proběhne úspěšně, dešifrují se ENCRYPTED_DATA → získá se původní DATA = SALT | VALUE
• Odstraní se SALT → zůstane původní VALUE

Update na verzi ABRA Gen s bezpečným úložištěm

Při updatu na verzi s bezpečným úložištěm se všechny výše zmíněné hodnoty přeuloží za pomoci nového šifrování do tabulky SecureStore. Původní hodnoty v původních tabulkách se vynulují. Od tohoto momentu pracují zmíněná hesla pouze s tabulkou SecureStore. Sloupce jako takové byly v daných tabulkách zachovány, aby případné zakázkové SQL dotazy byly nadále validní (data v minulosti bylo možné číst, ale nebyla cesta, jak je dekódovat bez znalosti permutačního algoritmu).

Data v bezpečném úložišti jsou šifrována pomocí symetrické šifry s autentizací dat AES-128-GCM. Klíč pro symetrickou šifru AES-128 je uložený ve Storage.STF v klíči /Security, a pokud zatím neexistuje, tak se vytvoří pomocí generátoru náhodných čísel. Šifrovací klíč je možné zobrazit v nástroji AppserverProp na hlavní záložce.

Změnu šifrovacího klíče je možné provést pomocí nástroje DBAdmin, a to volbou Změna šifrovacího klíče. Změna se provádí nad všemi spojeními nadefinovanými v DBAdminu současně. Je nutné, aby v době změny byla v DBAdminu přidána všechna spojení, která chcete používat — jinak budou všechny hodnoty v bezpečném úložišti u těchto nezahrnutých spojení nepoužitelné, protože je nebude možné dešifrovat novým klíčem.

Jak změna probíhá (každý krok probíhá vždy pro všechna spojení):

1. Vyčistí se tabulka SecureStoreBackup.

2. Vytvoří se záloha všech záznamů v tabulce SecureStore do tabulky SecureStoreBackup.

3. Provede se konverze všech záznamů v tabulce SecureStore pomocí nově specifikovaného šifrovacího klíče.

4. Pokud všechny kroky výše proběhly bez chyby na všech spojeních:
   

   • nový šifrovací klíč se zapíše do Storage.STF

   • původní šifrovací klíč se přeuloží do Storage.STF do klíče Security/History

5. Pokud v konverzi někde nastala chyba:

   • v takovém případě se všechny již zkonvertovaná spojení obnoví zpět z tabulky SecureStoreBackup

Pokud zapomeneme nějaké spojení zkonvertovat, pak v nástroji DBAdmin existuje také možnost zkonvertovat vybrané spojení na aktuální šifrovací klíč. Pří této konverzi je potřeba zadat původní šifrovací klíč, kterým bylo spojení zašifrováno, následně se překonvertuje na aktuální šifrovací klíč.

Pokud provádíme zálohu pomocí ABRA Gen, do vytvořeného *.ABF souboru se také zálohuje aktuální šifrovací klíč, aby bylo možné při obnově všechny záznamy zkonvertovat.

Pokud ale provádíme zálohu pomocí nativních prostředků databáze, je nutné zálohovat jako doposud také storage.stf, kde je uložen aktuální šifrovací klíč, aby bylo možné databázi použít v jiném prostředí.

U zákazníků, kteří mají zakoupené ABRA BI nebo jim byl v minulosti poskytnut licenční klíč pro testování ABRA BI, dojde po přechodu na systém ABRA Gen s bezpečným úložištěm k zapnutí režimu zpětné kompatibility přihlašování. Konkrétně se jedná o zavedení parametru KeepLegacyPasswordFormat=1 do souboru NEXUS.CFG. Pokud je tento parametr v NEXUS.CFG nastaven, přihlašovací uživatelská hesla se ukládají nejen do bezpečného úložiště, ale nadále i původním způsobem.

Od verze ABRA BI 25.1.7 bude možné využít nový způsob přihlašování uživatelů s ověřením přes Web API. Návod na přepnutí ověřování přes Web API naleznete zde.

Po zprovoznění ověřování přes Web API nebude parametr KeepLegacyPasswordFormat již potřeba a je vhodné ho z důvodu zvýšení bezpečnosti ze souboru NEXUS.CFG odstranit.

Pokud Web API nepoužíváte, ponechte parametr KeepLegacyPasswordFormat zapnutý.

V případě, že došlo ke ztrátě hesla od administrátorského účtu, již není v databázi možné jednoduše upravit položku SecPassword uživateli, kterému jsme chtěli heslo resetovat. Nastavení této hodnoty již nijak neovlivní přihlášení a tedy není řešením.

Pro obnovu hesla je potřeba využít nástroj AppServerProp, záložku Obnova hesla, která obsahuje seznam uživatelů ze spojení. Na nich je možné vyvolat obnovu hesla. Obnova hesla nastaví uživateli náhodně vygenerované heslo a nastaví mu příznak, aby si heslo při dalším přihlášení změnil.

V případě ztráty šifrovacího klíče k databázi nebo nativní záloze dojde jen ke znehodnocení zadaných zabezpečených údajů. Uživatelská hesla se tím změní na nevalidní obsah. U hesel a tokenů k e-mailovým účtům a dalším službám dojde k jejich nefunkčnosti. Do takovéhoto spojení se nelze přihlásit pod žádným uživatelem.

Pro přihlášení uživatele do takového databázového spojení je třeba využít nástroje AppServerProp, záložku Obnova hesel. Zde vybereme spojení a zvolíme volbu "Vyčistit údaje v bezpečném úložišti". Následně vás systém vyzve v rámci bezpečnosti o vypsání kontrolního slova pro tuto akci. Po vyčištění údajů pak vybereme uživatele, za kterého se potřebujeme přihlásit, a zvolíme funkci Obnovit heslo.

Úložiště je možné používat také k uchovávání vlastních citlivých údajů pro použití ve skriptech nebo API. Například pro nadefinování hesel, která chcete používat ve skriptu komunikujícím s nějakou službou, a podobně. Tyto vlastní citlivé hodnoty jsou vždy ukládány do domény „ext“.

Ve skriptingu je tyto hodnoty možné použít prostřednictvím metod na ObjectSpace – ReadFromSecureStore, WriteToSecureStore a DeleteFromSecureStore. Tyto funkce nedovolují specifikovat doménu záznamu v úložišti, použije se vždy doména “ext” určená pro externí aplikace. Příklad viz kap. Příklady pokročilého skriptování.

Podobně je možné pracovat s úložištěm přes Web API. V něm byl vytvořen controller “securestore”, který obsluhuje metody GET, POST a DELETE na url securestore/{key}, kde {key} představuje klíč záznamu v bezpečném úložišti. Doména je podobně jako v případě skriptování pevně daná - “ext”. Příklad viz kap. Knihovna praktických příkladů Web API.

Klíče můžeme dále spravovat v nástroji AppServerProp (Funkce > Bezpečné úložiště):

TLS (Transport Layer Security) je technologie, která chrání data posílaná mezi dvěma stranami — například mezi serverem a klienty. Představte si to jako uzamčenou obálku pro vaše zprávy, aby je nikdo jiný nemohl číst nebo měnit během cesty. Pro podporu TLS používáme knihovnu třetí strany rustls napsanou v jazyce Rust.

Bez TLS putují data mezi serverem a klientem „otevřeně“, tedy nezabezpečeně. To znamená, že kdokoliv, kdo by „odposlouchával“ komunikaci, by mohl vidět citlivé informace, jako jsou hesla nebo osobní údaje. S TLS je komunikace zašifrovaná, což znamená, že ji mohou číst a rozumět jí jen server a klient. Tím se zvyšuje bezpečnost a soukromí.

Komunikace bez TLS (bez šifrování)

Klient pošle požadavek serveru v čitelné podobě a server odpoví také v čitelné podobě. Kdokoli na síti může snadno číst zprávy.

Komunikace s TLS (zašifrovaná)

Klient a server si nejdříve dohodnou tajný klíč pro šifrování. Všechny další zprávy jsou zakódované, takže je mohou rozluštit pouze oni dva. Když někdo zprávu zachytí, vidí jen nesrozumitelný text.

TLS se aktivuje v konfiguračním souboru NEXUS.CFG.

Ve výchozím nastavení je TLS zapnuté a používá vestavěný certifikát. Tento certifikát má prakticky neomezenou platnost a je vystaven pro adresu „localhost“. Jelikož je parametr TrustServerCert ve výchozím stavu zapnutý (hodnota 1), systém tomuto certifikátu automaticky důvěřuje bez dalšího ověřování, což umožňuje TLS používat i pro běžnou síťovou komunikaci.

Toto základní nastavení zajišťuje funkční šifrování. Pro maximální zabezpečení v produkčním prostředí však doporučujeme nasadit vlastní certifikáty.