it-swarm-eu.dev

Jak prohledávat databázi MySQL se šifrovanými poli

Předpokládejme, že potřebuji zašifrovat určitá tabulková pole z MySQL databáze. Kromě toho musím prohledat některá z těchto polí , kterou jsem zašifroval.

Jak by se dalo hledat v těchto polích?

Dešifrování každého záznamu krok za krokem není žádná možnost: Předpokládejme, že mám několik tisíc záznamů. Dešifrování každého záznamu a ověření, zda se každý jednotlivý záznam shoduje s vyhledáváním, by vyžadovalo příliš mnoho času a prostoru.

UPDATE 2012-09-07

Přidání dalších podrobností do schématu databáze by bylo v pořádku , protože se chystám implementovat novou aplikaci. Kromě toho musím rozšířit aplikace, které jsou v současné době ve výrobě. Ale i pro tyto aplikace by bylo přidání dalších podrobností v pořádku.

UPDATE 2012-09-08

Šifrování je jádro této otázky.

Omezení přístupu, jak navrhují některé odpovědi, již platí - ale neodpovídají formálnímu požadavku na šifrování dat.

Tento formální požadavek není není Standard pro zabezpečení údajů v odvětví platebních karet [PCI].

16
SteAp

Je zřejmé, že nemají být prohlíženy, a proto by jejich vyhledávání bylo problematické.

Jeden trik, který jsem v minulosti použil, spočívá v hašování šifrovaných dat před jejich šifrováním a uložení hashů do indexovaného sloupce. To samozřejmě funguje pouze tehdy, pokud hledáte celou hodnotu; dílčí hodnoty nebudou mít stejný hash.

Pravděpodobně byste to mohli rozšířit vytvořením indexu hash „fulltextového“, pokud byste to potřebovali, ale mohlo by to být velmi rychle komplikované.

DODATEK

Bylo navrženo, abych přidal poznámku pod čarou k poměrně dlouhé debatě v chatu o zranitelnosti vůči slovníkovým útokům, takže o výše zmíněném přístupu budu diskutovat toto potenciální bezpečnostní riziko.

Slovník Attack: Útok ve slovníku je, když někdo předem hashuje seznam známých hodnot a porovnává hash s vaším hashovaným sloupcem v databázi. Pokud najdou shodu, je pravděpodobné, že známá hodnota je vlastně to, co je hashováno (není to však definitivní, protože hashování není zaručeno, že budou jedinečné). Toto je obvykle zmírněno hašováním hodnoty náhodným „solí“ připojeným nebo předepřeným, takže hash nebude odpovídat slovníku, ale výše uvedená odpověď nemůže použít sůl, protože ztratíte prohledávání.

Tento útok je nebezpečný při práci s hesly: pokud vytvoříte slovník populárních hashů hesel, můžete rychle prohledat v tabulce tuto hashovou hodnotu a identifikovat uživatele, který má takové heslo, a účinně extrahovat pověření a ukrást takovou identitu uživatele .

To je méně nebezpečné pro položky s vysokou mírou mohutnosti, jako jsou SSN, čísla kreditních karet, GUID atd. (Ale s jejich uložením jsou spojena různá rizika [číst: legální], takže nemám sklon radit při jejich ukládání ).

Důvodem je to, aby slovníkový útok fungoval, musíte mít předem vytvořený slovník možných hodnot a jejich hashe. Teoreticky byste mohli vytvořit slovník všech možných SSN (miliarda řádků, za předpokladu, že budou odstraněny všechny formátovací permutace; několik desítek biliónů záznamů pro kreditní karty) ... ale to obvykle není místo útoku na slovník a v podstatě se stává srovnatelným s útokem brutální síly, kde systematicky zkoumáte každou hodnotu.

Můžete také hledat konkrétní číslo SSN nebo číslo kreditní karty, pokud se pokoušíte spojit SSN s osobou. Znovu, obvykle se nejedná o útok na slovník, ale je to možné, takže pokud je to riziko, kterému se musíte vyhnout, moje odpověď pro vás není dobrým řešením.

Takže to máte. Stejně jako u všech zašifrovaných dat je to obvykle z nějakého důvodu šifrováno, takže si uvědomte svá data a před čím se snažíte je chránit.

11
Jeremy Holovacs

Možná se budete chtít podívat na CryptDB . Je to front-end pro MySQL a PostgreSQL, který umožňuje transparentní ukládání a dotazování šifrovaných dat. Funguje tak, že šifruje a dešifruje data, když prochází mezi aplikací a databází, přepisuje dotazy tak, aby fungovaly na šifrovaných datech. a dynamickým nastavením režimu šifrování každého sloupce tak, aby se zobrazovaly pouze tolik informací, kolik je potřeba pro dotazy, které aplikace používá.

Různé metody šifrování používané CryptDB zahrnují:

  • [~ # ~] rnd [~ # ~] , plně zabezpečené šifrovací schéma IND-CPA, které nevrací žádné informace o datech (kromě jeho přítomnosti a (pro typy s proměnnou délkou a délkou), ale umožňuje pouze ukládání a vyhledávání, žádné dotazy.

  • [~ # ~] det [~ # ~] , varianta RND, která je deterministická, takže se dvě identické hodnoty (ve stejném sloupci) zašifrují do stejného šifrového textu. Podporuje dotazy na rovnost tvaru WHERE column = 'constant'.

  • [~ # ~] ope [~ # ~] , šifrovací schéma pro zachování objednávek, které podporuje dotazy na nerovnost, jako je WHERE column > 'constant'.

  • [~ # ~] hom [~ # ~] , částečně homomorfní šifrovací schéma (Paillier), které umožňuje přidávat šifrované hodnoty společně vynásobením ciphertexts. Podporuje SUM() dotazy, sčítání a zvyšování.

  • [~ # ~] vyhledávání [~ # ~] , schéma, které podporuje vyhledávání pomocí klíčových slov ve tvaru WHERE column LIKE '% Word %'.

  • [~ # ~] připojit se [~ # ~] a OPE-JOIN , varianty DET a OPE, které umožňují porovnání hodnot v různých sloupcích. Podporovat rovnost a rozsah spojuje, resp.

Skutečná síla CryptDB spočívá v tom, že dynamicky přizpůsobuje metodu šifrování každého sloupce dotazům, které vidí, takže pomalejší a/nebo méně zabezpečená schémata se používají pouze pro sloupce, které je vyžadují. Existují také různé další užitečné funkce, například řetězení šifrovacích klíčů k uživatelským heslům.

Pokud vás to zajímá, měli byste se podívat na články odkazované na webových stránkách CryptDB, zejména „CryptDB: Ochrana důvěrnosti pomocí šifrovaného zpracování dotazů“ od Popa, Redfield, Zeldovich a Balakrishnan ( SOSP 2011). Tyto práce také podrobněji popisují různá kompromisy v oblasti zabezpečení a výkonu související s podporou různých typů dotazů.

5
Ilmari Karonen

Nechápu, proč současné odpovědi nezpochybnily požadavky úplně, takže se zeptám a nechám to jako odpověď.

Jaké jsou obchodní důvody? Jaká data potřebujete zašifrovat a proč? Pokud hledáte shodu s PCI, mohl bych napsat esej.

Dotazy k vašemu požadavku:

  • Budete muset v důsledku toho vrátit existující/neexistující nebo skutečná data?
  • Potřebujete LIKE '% OMG_SEKRIT%' schopnost?
  • Kdo data nevidí a proč?

Zabezpečení RDBMS se obvykle provádí na základě oprávnění vynucovaného uživatelem/rolí. Data jsou obvykle šifrována pomocí RDBMS na disku, ale ne v samotných sloupcových datech, protože to ve skutečnosti nemá smysl pro aplikaci navrženou k efektivnímu ukládání a načítání dat.

Omezit uživatelem/rolí/api. Šifrovat na disku. Pokud ukládáte důležitější data, ráda bych věděla, proč používáte MySQL.

3
Philᵀᴹ

Dívám se na to a narazil jsem na vaši otázku. Přikláním se k přístupu uvedenému v části 5.4 článku „Praktické techniky pro vyhledávání šifrovaných dat“ http://www.cs.berkeley.edu/~dawnsong/papers/se.pdf

Základní Gist je vytvořit index, který obsahuje šifrovaná klíčová slova, která jsou přítomna v šifrovaném vyhledávacím dokumentu. Trik spočívá také v zašifrování umístění v dokumentu (nebo databázi), kde jsou tato klíčová slova přítomna.

2
M. Scott Ford

Programově je efektivní řešení

  1. načíst VŠECHNY záznamy pro POUZE pole, proti kterému hledáte, s ID záznamu
  2. dešifrovat je do dočasné tabulky
  3. proveďte vyhledávání podle této tabulky
  4. použijte id k získání úplných záznamů (všechna pole), která odpovídají vyhledávacím kritériím
  5. dešifrovat je a vrátit je uživateli

Jde o to, že 1 a 4 jsou významně menší sady dat než načtení a dešifrování všech polí všech záznamů na začátku.

Doufám, že to pomůže.

1
Paul B. Hartzog

To je možné s plnou funkčností vyhledávání pomocí interních šifrovacích funkcí MYSQL.

Zde je příklad:

!!! I AM POUŽÍVÁNÍ MYSQL ENCODE () ZDE PRO ZJEDNODUŠENÍ, MYSQL_ENCODE IS TEĎ SE Zvažoval POJIŠTĚNÍ, POUŽÍVEJTE JEDEN OSTATNÍ INTERNÍ FUNKCE MYSQL INSTEAD !!!

UPDATE my_table
SET field=ENCODE('my_data', 'my_password')
WHERE ID=1;

SELECT DECODE(field, 'my_password') as field FROM my_table
WHERE field LIKE 'data';

Jak naznačuje výše uvedený komentář, NEPOUŽÍVEJTE ENCODE (), nepoužívejte jedna z dalších šifrovacích funkcí V tomto příkladu používám ENCODE pouze kvůli jeho jednoduchosti

Pokud to děláte v rámci aplikace, jako je php, můžete tak učinit v rámci vaší brány db nebo tříd úložiště uložením seznamu/pole šifrovaných sloupců každé tabulky v příslušné třídě brány.

class UserGateway
{
    protected $encrypted_fields = array(
        'username',
        'email'
    );

    public function get($fields, ...)
    {
        foreach ($fields as $k => $field) {
            if (in_array($field, $fields)) {
                $fields[$k] = $this->decodeSelect($field);
            }
        }

        $sql = 'SELECT '.implode(',', $fields);

        //......
    }

    protected function decodeSelect($field)
    {
        return "DECODE($field, $pass) AS $field";
    }
}

Samozřejmě je to velmi hrubý a nejistý kód, který by neměl být použit ve výrobě bez výrazného zlepšení. Měl by však sloužit svému účelu při poskytování obecné myšlenky.

1
Leigh Bicknell