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 knihovny 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).

Šifrovací klíč je možné zobrazit v nástroji AppServerProp na záložce Monitor pomocí tlačítka Zobrazit šifrovací klíč. Tato funkce je navíc chráněna heslem do repozitoře.

Případně pomocí příkazu:

APPServerProp.exe -password=<heslo_repozitoře> -show-cipherkey

Podrobněji popsáno v kapitole Automatizace.

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.

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ě.

V nástroji DBAdmin zvolte funkci „Změna šifrovacího klíče (pro všechna spojení najednou)“ a pokračujte tlačítkem Dále.. V dalším kroku se do položky Původní klíč předvyplní aktuální šifrovací klíč z repozitoře. Do položky Nový klíč můžete vložit svůj vlastní šifrovací klíč nebo pomocí tlačítka Vygenerovat si vytvořit nový klíč. Změnu spustíte pomocí tlačítka Dokončit.

Jak změna probíhá interně (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 :

   • Nejdříve se provede dešifrování hodnot pomocí původního šifrovacího klíče uloženého v repozitoři.

   • V druhém kroku se provede zašifrování pomocí nové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 repozitořeStorage.STF.

   • Původní šifrovací klíč se přeuloží do repozitoře 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

   • Více v kapitole Jak postupovat v případě kdy nelze dešifrovat data.

Změnu je také možné provést pomocí nástroje DBAdminCmd.

DBAdminCmd.exe password <heslo_repozitoře> change-cipherkey [NEW_KEY_BASE64]

Podrobněji popsáno v kapitole Automatizace.

Každá instalace systému ABRA Gen má svůj vlastní šifrovací klíč, více např. v kapitole Jak postupovat v případě kdy nelze dešifrovat data”

Pokud potřebujeme přenést databázi z jedné instalace na druhou, je nutné, aby bylo možné s touto databázi pracovat ji zkonvertovat na šifrovací klíč instalace do které ji přenášíme.

Kdy je nutné zkonvertovat databázi na nový šifrovacího klíče?

Pokud se provádí zásah do spojení a jeho databáze, například:

• Přesun databáze z jedné instalace systému ABRA Gen do jiné instalace.

• Obnova nativní zálohy databáze z jedné instalace systému ABRA Gen do jiné instalace.

• Obnova nativní zálohy po změně šifrovacího klíče v instalaci systému ABRA Gen.

Pro úspěšnou konverzi je potřeba znát šifrovací klíč původní instalace (jak je uvedeno v kapitole Kde je uložen šifrovací klíč).

V nástroji DBAdmin.exe vyberte spojení, které chcete zkonvertovat a poté zvolte „Zkonvertovat databázi na aktuální šifrovací klíč (pokud spojení aktuálně používá jiný klíč). V dalším kroku zadejte do pole Původní klíč šifrovací klíč instalace odkud databáze pochází, do pole Aktuální klíč se předvyplní šifrovací klíč aktuální instalace systému ABRA Gen. Konverzi zahájíte stiskem tlačítka Dokončit.

Jak změna probíhá interně:

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:

   • Nejdříve se provede dešifrování hodnot pomocí zadaného původního šifrovacího klíče.

   • V druhém kroku se provede zašifrování pomocí šifrovacího klíče uloženého v repozitoři.

4. Pokud v konverzi někde nastala chyba:

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

   • Více v kapitole Jak postupovat v případě kdy nelze dešifrovat data.

Konverzi je také možné provést pomocí nástroje DBAdminCmd.

DBAdminCmd.exe password <heslo_repozitoře> connection <název_spojení> convert-to-actual-cipherkey [OLD_KEY_BASE64]

Podrobněji popsáno v kapitole Automatizace.

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ý.

Pokud se nelze do systému ABRA Gen přihlásit, a systém hlásí Uživatel nebo heslo není správné. je možné si v nástroji AppServerProp obnovit heslo. Nástroj vymaže původní heslo a vygeneruje náhodné nové. Zároveň na uživateli nastaví příznak, aby si heslo při dalším přihlášení změnil.

Spusťte nástroj AppServerProp a přejděte na záložku Obnova hesla. Zde se po výběru spojení zobrazí seznam uživatelů. Vyberte uživatele, kterému chcete heslo obnovit a pokračujte tlačítkem Obnovit heslo. Po potvrzení akce se zobrazí potvrzení s novým heslem a možností si jej zkopírovat do schránky.

Ú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ě):

Tento postup je určen pro případy, kdy testovací prostředí je samostatná instalace ABRA Gen a nejedná se pouze o testovací spojení v produkční ABRA Gen (v tomto případě není nic potřeba).

Každá instalace ABRA Gen, respektive každý aplikační server má svůj vlastní jedinečný šifrovací klíč. To se týká i instalací v produkčním a testovacím prostředí. Pro usnadnění práce při vytváření a správě Testovacího prostředí doporučujeme nastavit pro obě instalace stejný šifrovací klíč.

Toho lze dosáhnout několika způsoby:

1. Vytvořením nového testovacího prostředí z kopie produkčního prostředí

2. Sjednocením šifrovacích klíčů

Vytvořením nového testovacího prostředí z kopie produkčního prostředí

Pokud testovací prostředí vznikne jako kopie produkčního prostředí, je v takto vytvořeném testovacím prostředí shodný šifrovací klíč s produkčním prostředím. Šifrovací klíč je uložen v souboru repozitoře Storage.STF a při „kopírování“ se tedy přenese. V tomto případě není nutné provádět žádné další speciální kroky.

Sjednocením šifrovacích klíčů

Pokud z nějakého důvodu nelze vytvořit nové testovacího prostředí z kopie produkčního prostředí, je možné šifrovací klíče mezi instalacemi přenést a sjednotit. Pro tuto akci musíme znát šifrovací klíč produkčního prostředí a poté všechna Spojení, respektive jejich databáze převést na tento šifrovací klíč. V produkčním prostředí tedy v nástroji AppServerProp zjistíme šifrovací klíč (jak je popsáno v kapitole Kde je uložen šifrovací klíč)). A následně v testovacím prostředí v nástroji DBAdmin ve funkci Změna šifrovacího klíče (pro všechna spojení najednou) zadáme do pole Nový klíč šifrovací klíč produkčního prostředí a tlačítkem Dokončit převedeme všechna spojení (detailnější postup je uveden v kapitole Kde a jak provést změnu šifrovacího klíče). Tím dojde ke sjednocení šifrovacích klíčů mezi produkčním a testovacím prostředím. Tuto akci je nutné provést pouze jednou a je trvalá.

Pokud už byla do stávajícího testovacího prostředí s vlastním šifrovacím klíčem přidána databáze z produkčního prostředí, může nastat situace, kdy některá spojení v testovacím prostředí fungují, zatímco nově přidaná spojení z produkčního prostředí hlásí problém s dešifrováním.

V takovém případě je nutné nejprve zkonvertovat dané spojení na stávající šifrovací klíč testovacího prostředí. Postup je popsán v kapitole Jak zkonvertovat databázové spojení na aktuální šifrovací klíč.

Teprve poté je možné provést případné Sjednocení šifrovacích klíčů, viz výše.

Všechny úkony v rámci práce s šifrovacím klíčem lze automatizovat pomocí příkazové řádky.

Vypsání šifrovacího klíče do konzole

Další informace v kapitole Kde je uložen šifrovací klíč.

Provádí se spuštěním nástroje AppServerProp s parametrem -show-cipherkey.

Vypsání je navíc chráněno heslem do repozitoře, které se zadává pomocí parametru -password=<heslo_repozitoře>

Změna šifrovacího klíče všech spojení z příkazového řádku

Další informace v kapitole Kde a jak provést změnu šifrovacího klíče.

Stejná funkce jako „Změna šifrovacího klíče (pro všechna spojení najednou)“ v nástroji DBAdmin.exe. Provádí se spuštěním nástroje DBAdminCmd.exe s parametrem: change-cipherkey [NEW_KEY_BASE64]. Pokud není zadán nový klíč (argument [NEW_KEY_BASE64]) systém jej vygeneruje automaticky. Změna je chráněna pomocí hesla do repozitoře, které se zadává parametrem password.

Zkonvertování databáze na aktuální šifrovací klíč

Další informace v kapitole Jak zkonvertovat databázi na aktuální šifrovací klíč

Stejná funkce jako Zkonvertovat databázi na aktuální šifrovací klíč (pokud spojení aktuálně používá jiný klíč) v nástroji DBAdmin.exe.

Provádí se spuštěním nástroje DBAdminCmd.exe s parametrem: convert-to-actual-cipherkey [OLD_KEY_BASE64]. Argument [OLD_KEY_BASE64] je povinný a jedná se o šifrovací klíč databáze, respektive instalace systému ABRA Gen, ze které databáze původně pochází.

Změna se týká vždy konkrétního spojení a je chráněna pomocí hesla do repozitoře, které se zadává parametrem password.

Jak postupovat, pokud systém ABRA Gen hlásí:

• Nepodařilo se dešifrovat hodnotu XXX v Bezpečném úložišti.

• V Bezpečném úložišti byla detekována chybná data:

• POZOR, Nepodařilo se dešifrovat žádná data z Bezpečného úložiště

Jak již bylo řečeno v jiných kapitolách, každá instalace systému ABRA Gen, respektive každý aplikační server má svůj vlastní jedinečný šifrovací klíč. Tento šifrovací klíč je uložen v repozitoři a jsou jím zašifrována data v Bezpečném úložišti. Každé spojení má své vlastní Bezpečné úložiště a jeho data jsou uložena v databázi daného spojení. Pokud se má nějaký údaj z bezpečného úložiště použít (např. ověření hesla při přihlášení uživatele) musí se nejdříve dešifrovat správným šifrovacím klíčem.

K dešifrování dat v systému ABRA Gen dochází na mnoha místech, krom přihlášení do systému, je to při jakémkoliv použití hesel uložených v systému např. pro odesílání a příjem e-mailů, ale např. také při zálohování dat, kdy se ověřuje že data v bezpečném úložišti jsou v pořádku a bude možné je obnovit.

Pokud dojde k tomu, že se databáze vytvořená v jedné instalaci systému ABRA Gen napojuje nebo nějakým způsobem přenáší do jiné instalace systému ABRA Gen (kromě obnovy dat z ABF). Dojde k tomu, že šifrovací klíč v instalaci je jiný než šifrovací klíč, kterým byly zašifrovány data v Bezpečném úložiště databáze. Při pokusu o dešifrování (např. opět při ověření hesla při přihlášení uživatele) poté dojde k tomu, že se data nepodaří dešifrovat. Bohužel v tuto chvíli systém nedokáže přesně určit, zda je použit jiný šifrovací klíč nebo zda je problém jinde, např. v poškozených datech v Bezpečném úložišti. Systém ABRA Gen ve všech případech hlásí že se nepodařilo dešifrovat data.

Jak poznat že je použit jiný šifrovací klíč:

• Kontrola Bezpečného úložiště v AppServerProp hlásí „POZOR, Nepodařilo se dešifrovat žádná data z Bezpečného úložiště. Viz kapitola Jak zkontrolovat bezpečné úložiště.

• Pokud víme že databáze byla původně vytvořená v jiné instalaci, dá se celkem s jistotou říct, že problém je způsoben použitím jiného šifrovacího klíče, než jakým byla zašifrována data v Bezpečném úložišti.

• Dalším způsobem, jakým se dá určit tato příčina je to, že nelze dešifrovat žádná data z Bezpečného úložiště, např. tak, že se do spojení nemůže přihlásit žádný uživatel

Jak poznat že problém je v datech bezpečného úložiště:

• Naopak pokud se alespoň jeden uživatel může přihlásit, nebo se chyba zobrazuje již přihlášenému uživateli při práci v systému ABRA Gen, tak lze s jistotou říct, že šifrovací klíč instalace a šifrovací klíč kterým byly zašifrovány data v Bezpečném úložišti jsou shodné. A problém tedy bude v datech v Bezpečném úložišti konkrétního záznamu.

• Kontrola Bezpečného úložiště v AppServerProp vypisuje „V Bezpečném úložišti spojení Demodata byla detekována chybná data:“ a následuje výpis poškozených záznamů Viz kapitola Jak zkontrolovat bezpečné úložiště.

Ve zde uváděném příkladu s ověřením hesla uživatele při přihlášení to znamená, že jsou poškozená data hesla uživatele v Bezpečném úložišti. Na rozdíl od problému s rozdílnými šifrovacími klíči, by k tomuto problému ale docházet nemělo a může být způsoben ručním zásahem do bezpečného úložiště nebo i chybou v databázi.

Oba výše uvedené problémy lze prostředky systému ABRA Gen vyřešit a ani jeden nevede k jakékoliv ztrátě či poškození důležitých dat. Vždy se zde jedná pouze o problém s daty bezpečného úložiště uložená v tabulce SecureStore databáze daného spojení.

Jak postupovat, pokud je rozdílný šifrovací klíč je popsáno v kapitole Jak zkonvertovat databázi na aktuální šifrovací klíč

Jak postupovat, pokud je podezření na problém s poškozenými daty je popsáno v kapitole Jak zkontrolovat bezpečné úložiště.

Jak postupovat, pokud pracuji s Testovacím prostředím je popsáno v kapitole Testovací prostředí / Sjednocení šifrovacích klíčů mezi instalacemi.

Každá instalace systému ABRA Gen má svůj vlastní šifrovací klíč, více např.  v kapitole Jak postupovat v případě kdy nelze dešifrovat data.

Pokud potřebuji přenést databázi z jedné instalace na druhou, je nutné, aby bylo možné s touto databázi pracovat ji zkonvertovat na šifrovací klíč instalace do které ji přenáším.

Dále postupujte dle návodu v kapitole Jak zkonvertovat databázové spojení na aktuální šifrovací klíč.

V případě, že narazíme na chybu v systému, která říká, že není možné dešifrovat hodnotu v bezpečném úložišti, i když používáme korektní šifrovací klíč, viz kapitola Jak postupovat v případě kdy nelze dešifrovat data, máme pravděpodobně nějakou hodnotu v úložišti poškozenou.

Data v Bezpečném úložišti je možné nechat zkontrolovat, což spočívá v tom, že všechna data zde uložená se pokusí dešifrovat aktuálním šifrovacím klíčem.

V nástroji AppServerProp.exe a v menu Funkce vybereme možnost Bezpečné úložiště. Tímto se přepneme na nově zobrazenou záložku Bezpečné úložiště. Na této záložce vybereme spojení, které chceme nechat zkontrolovat a tlačítkem Kontrola bezpečného úložiště spustíme kontrolu.

Všechna data, která se dešifrovat nepodaří budou následně vypsána. Spolu s doporučením dalšího postupu.

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ů v bezpečném úložišti. 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 funkce nástroje AppServerProp, záložku Obnova hesel. Více v kapitole Obnova hesla uživatele. 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.

Pokud „Kontrola Bezpečného úložiště dle postupu Jak zkontrolovat bezpečné úložiště vypsala konkrétní poškozená data pokračujte dle postupu dále.

Chybná data není možné dešifrovat a dále s nimi pracovat. Jedinou možnou opravu je je smazat a následně v systému znovu nastavit.

Před pokračováním si vypsané údaje zkopírujeme (třeba do textového souboru), abychom je měli později k dispozici.

Oprava záznamů

Poznačíme si tedy, které údaje byly poškozeny, a teprve poté provedeme vymazání hodnot. Vymazání je v tento okamžik jediný korektní postup, jelikož když jsou údaje poškozeny a není možné je dešifrovat, nelze je dále použít. Následně pak můžeme přejít do systému ABRA Gen a hodnoty, které byly poškozeny, znovu zadat v příslušných záznamech.

To, o jaký záznam se jedná, určuje kombinace domény a klíče. Tabulky níže uvádějí seznam domén i klíčů, aby bylo možné rozpoznat, kde je přesně problém.

Domény jsou pevně dané:

Klíče jsou kombinace daného klíče a ID záznamu, kterého se to týká:

V tomto příkladu při pohledu na chybu (viz obrázek výše) vidíme poškozený přístupový token, a to hodnotu token/9800000101, doména auth. Vidíme, že se jedná o doménu auth, dle tabulky domén tedy víme, že se jedná o uživatele. Dále z chyby můžeme vidět klíč token/9800000101. Dle něho víme, že se jedná o položku token u uživatele, který má ID 9800000101.

Otevřeme tedy agendu Uživatelé, kde si vyhledáme záznam, který potřebujeme opravit, a nastavíme nový token. Tím dojde k opravě záznamů.

Stejným způsobem postupujeme u všech nalezených záznamů, kde se nepovedlo data dešifrovat. Tímto postupem zajistíme úplnou integritu dat a předejdeme problémům do budoucna.

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.

Tip na video...

Podívejte se na podporu šifrování dat mezi klientem a aplikačním serverem ve videu

Video je součástí celého kurzu Představení technických novinek verze 25.4. v ABRA Academy. Přihlásit se na tento bezplatný kurz a podívat se na všechna videa můžete zde.

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 bezpečné šifrování. Pro maximální zabezpečení prostředí lze použít i vlastní certifikát.