Úvod do trezoru

1. Prehľad

V tomto tutoriáli preskúmame Hashicorpov trezor - populárny nástroj používaný na bezpečnú správu citlivých informácií v moderných aplikačných architektúrach.

Medzi hlavné témy, ktorým sa budeme venovať, patria:

  • Aký problém sa Vault snaží vyriešiť
  • Architektúra úložiska a hlavné koncepty
  • Nastavenie jednoduchého testovacieho prostredia
  • Interakcia s Vaultom pomocou jeho nástroja príkazového riadku

2. Problém s citlivými informáciami

Predtým, ako sa pustíme do úschovne, pokúsme sa pochopiť problém, ktorý sa snaží vyriešiť: správu citlivých informácií.

Väčšina aplikácií potrebuje na správne fungovanie prístup k citlivým údajom. Napríklad aplikácia elektronického obchodu môže mať niekde nakonfigurované užívateľské meno / heslo na pripojenie k svojej databáze. Možno bude tiež potrebné kľúče API na integráciu s ďalšími poskytovateľmi služieb, ako sú napríklad platobné brány, logistika a ďalší obchodní partneri.

Poverenia na databázu a kľúče API sú niektoré príklady citlivých informácií, ktoré musíme bezpečne uložiť a sprístupniť našim aplikáciám.

Jednoduchým riešením je uložiť tieto poverenia do konfiguračného súboru a prečítať si ich pri spustení. Problém s týmto prístupom je však zrejmý. Ktokoľvek má prístup k tomuto súboru, zdieľa rovnaké databázové privilégiá, aké má naša aplikácia - zvyčajne jej dáva plný prístup ku všetkým uloženým údajom.

Môžeme sa pokúsiť trochu sťažiť šifrovanie týchto súborov. Tento prístup však z hľadiska celkovej bezpečnosti veľa nepridá. Hlavne preto, že naša aplikácia musí mať prístup k hlavnému kľúču. Ak sa šifrovanie použije týmto spôsobom, dosiahne sa iba „falošný“ pocit bezpečia.

Moderné aplikácie a cloudové prostredia majú tendenciu pridávať ďalšie zložitosti: distribuované služby, viac databáz, systémy správ atď., Všetky majú citlivé informácie rozšírené všade, čo zvyšuje riziko narušenia bezpečnosti.

Čo môžeme robiť? Poďme to klenbovať!

3. Čo je to Vault?

Hashicorp Vault rieši problém správy citlivých informácií - a tajomstvo v Vaultovom jazyku. „Správa“ v tejto súvislosti znamená, že Vault ovláda všetky aspekty citlivých informácií: jeho generovanie, ukladanie, používanie a v neposlednom rade jeho odvolanie.

Hashicorp ponúka dve verzie aplikácie Vault. Verzia open-source použitá v tomto článku je zadarmo na použitie, a to aj v komerčných prostrediach. K dispozícii je tiež platená verzia, ktorá obsahuje technickú podporu pri rôznych dohodách SLA a ďalšie funkcie, napríklad podporu HSM (Hardware Security Module).

3.1. Architektúra a kľúčové vlastnosti

Architektúra aplikácie Vault je klamne jednoduchá. Jeho hlavné zložky sú:

  • Trendový backend - úložisko pre všetky tajomstvá
  • Server API, ktorý spracováva požiadavky klientov a vykonáva operácie na tajomstvách
  • Počet tajné motory, jeden pre každý typ podporovaného tajného typu

Delegovaním všetkej manipulácie s tajomstvami do aplikácie Vault môžeme zmierniť niektoré problémy so zabezpečením:

  • Naše aplikácie ich už nemusia ukladať - v prípade potreby sa jednoducho opýtajte úložiska a zahoďte ho
  • Môžeme použiť krátkodobé tajomstvá, a tým obmedziť „okno príležitostí“, kde môže útočník použiť ukradnuté tajomstvo

Pred zápisom do obchodu Vault zašifruje všetky údaje šifrovacím kľúčom. Tento šifrovací kľúč je šifrovaný ešte ďalším kľúčom - hlavným kľúčom, ktorý sa používa iba pri štarte.

Kľúčovým bodom pri implementácii aplikácie Vault je, že neukladá hlavný kľúč na serveri. To znamená, že ani Vault nemá po spustení prístup k svojim uloženým údajom. V tomto okamihu sa hovorí, že inštancia úložiska je v „zapečatenom“ stave.

Neskôr prejdeme krokmi potrebnými na vygenerovanie hlavného kľúča a odpečatenie inštancie úložiska.

Po odpečatení bude Vault pripravený prijať požiadavky API. Tieto žiadosti samozrejme potrebujú autentifikáciu, čo nás privádza k tomu, ako Vault autentifikuje klientov a rozhoduje o tom, čo môžu alebo nemôžu robiť.

3.2. Overenie

Na prístup k tajomstvám v aplikácii Vault sa musí klient autentifikovať pomocou jednej z podporovaných metód. Najjednoduchšia metóda používa tokeny, ktoré sú iba reťazcami odosielanými na každú požiadavku API pomocou špeciálnej hlavičky HTTP.

Keď je Vault pôvodne nainštalovaný, automaticky vygeneruje „koreňový token“. Tento token je ekvivalentný ako root superuser v systémoch Linux, takže jeho použitie by malo byť obmedzené na minimum. Ako najlepší postup by sme mali použiť tento koreňový token iba na vytvorenie ďalších tokenov s menšími oprávneniami a potom ho odvolať. To však nie je problém, pretože neskôr môžeme vygenerovať ďalší koreňový token pomocou odpečatených kľúčov.

Vault podporuje aj ďalšie mechanizmy autentifikácie, ako napríklad LDAP, JWT, TLS certifikáty. Všetky tieto mechanizmy stavajú na základnom mechanizme tokenov: keď Vault overí nášho klienta, poskytne token, ktorý potom môžeme použiť na prístup k ďalším API.

S tokenmi je spojených niekoľko vlastností. Hlavné vlastnosti sú:

  • Sada pridružených Postupy (pozri nasledujúcu časť)
  • Čas do života
  • Či sa dá obnoviť
  • Maximálny počet použití

Pokiaľ nie je uvedené inak, tokeny vytvorené Vaultom vytvoria vzťah rodič - dieťa. Podradený token môže mať najviac rovnakú úroveň oprávnení ako rodič.

Opak nie je pravdou: môžeme - a zvyčajne to dokážeme - vytvoriť detský token s obmedzujúcimi politikami. Ďalším dôležitým bodom tohto vzťahu: Keď zneplatníme token, zneplatnia sa aj všetky podradené tokeny a ich potomkovia.

3.3. Postupy

Pravidlá presne definujú, ku ktorým tajomstvám môže klient pristupovať a ktoré operácie s nimi môže vykonávať. Pozrime sa, ako vyzerá jednoduchá politika:

cesta "tajomstvo / účtovníctvo" {capabilities = ["čítať"]}

Tu sme na definovanie našej politiky použili syntax HCL (Hashicorp's Configuration Language). Vault na tento účel podporuje aj JSON, ale v našich príkladoch sa budeme držať HCL, pretože je ľahšie čitateľný.

Pravidlá v trezore sú „predvolene odmietnuté“. Token pripojený k tejto vzorovej politike získa prístup k tajomstvám uloženým v priečinku tajomstvo / účtovníctvo a nič iné. V čase vytvorenia môže byť token pripojený k viacerým politikám. Je to veľmi užitočné, pretože nám to umožňuje vytvárať a testovať menšie politiky a potom ich podľa potreby aplikovať.

Ďalším dôležitým aspektom politík je, že využívajú lenivé hodnotenie. To znamená, že môžeme aktualizovať dané pravidlá a všetky tokeny budú ovplyvnené okamžite.

Doteraz opísané politiky sa tiež nazývajú politiky zoznamov riadenia prístupu alebo politiky ACL. Vault podporuje aj dva ďalšie typy politík: politiky EGP a RGP. Tie sú k dispozícii iba v platených verziách a rozširujú základnú syntax politiky s podporou Sentinel.

Ak sú k dispozícii, umožní nám to zohľadniť v našich zásadách ďalšie atribúty, ako napríklad čas, viacnásobné faktory autentifikácie, pôvod v klientskej sieti atď. Môžeme napríklad definovať politiku, ktorá umožňuje prístup k danému tajomstvu iba v pracovnú dobu.

Viac podrobností o syntaxi politiky nájdeme v dokumentácii aplikácie Vault.

4. Tajné typy

Vault podporuje celý rad rôznych tajných typov, ktoré sa zameriavajú na rôzne prípady použitia:

  • Pár kľúč - hodnota: jednoduché statické páry kľúč - hodnota
  • Dynamicky generované poverenia: vygenerované Vaultom na žiadosť klienta
  • Kryptografické kľúče: Používa sa na vykonávanie kryptografických funkcií s údajmi klienta

Každý tajný typ je definovaný nasledujúcimi atribútmi:

  • A namontovaťbod, ktorý definuje svoju predponu REST API
  • Sada operácií vystavených prostredníctvom zodpovedajúceho API
  • Sada konfiguračných parametrov

Daná tajná inštancia je prístupná prostredníctvom a cesta, podobne ako adresárový strom v súborovom systéme. Prvá zložka tejto cesty zodpovedá prípojný bod kde sa nachádzajú všetky tajomstvá tohto typu.

Napríklad reťazec tajomstvo / moja žiadosť zodpovedá ceste, pod ktorou nájdeme páry kľúč - hodnota moja aplikácia.

4.1. Tajomstvá kľúč - hodnota

Tajomstvá kľúč-hodnota sú, ako už z názvu vyplýva, jednoduché páry dostupné pod danou cestou. Napríklad môžeme dvojicu uložiť foo = bar pod cestou / secret / my-application.

Neskôr použijeme rovnakú cestu na získanie rovnakého páru alebo párov - pod tú istú cestu je možné uložiť viac párov.

Vault podporuje tri druhy tajomstiev kľúč-hodnota:

  • Neverzované páry kľúčov, kde aktualizácie nahrádzajú existujúce hodnoty
  • Verzie kľúčových párov, ktoré udržujú až konfigurovateľný počet starých verzií
  • Kója, špeciálny typ neaktualizovaných párov kľúčov, ktorých hodnoty sú obmedzené na danú hodnotu prístupový token (o tých viac neskôr).

Tajomstvá kľúč-hodnota sú svojou povahou statické, takže s nimi nie je spojený žiadny koncept súvisiaceho vypršania platnosti. Hlavným prípadom použitia tohto druhu tajomstva je ukladanie poverení na prístup k externým systémom, ako sú napríklad kľúče API.

V takýchto scenároch sú aktualizácie poverení polomanuálnym procesom, ktorý zvyčajne vyžaduje, aby niekto získal nové poverenia, a na zadanie nových hodnôt použije príkazový riadok alebo používateľské rozhranie aplikácie Vault.

4.2. Dynamicky generované tajomstvá

Dynamické tajomstvá generuje Vault za chodu, keď to vyžaduje aplikácia. Vault podporuje niekoľko typov dynamických tajomstiev, vrátane nasledujúcich:

  • Poverenia databázy
  • Kľúčové páry SSH
  • Certifikáty X.509
  • Poverenia AWS
  • Účty služieb Google Cloud
  • Účty služby Active Directory

Všetky tieto modely majú rovnaký spôsob používania. Najskôr nakonfigurujeme tajný modul s podrobnosťami potrebnými na pripojenie k pridruženej službe. Potom definujeme jeden alebo viac roly, ktoré popisujú skutočné vytvorenie tajomstva.

Zoberme si ako príklad databázový tajný modul. Najprv musíme nakonfigurovať Vault so všetkými podrobnosťami pripojenia k databáze používateľov, vrátane poverení od už existujúceho používateľa s oprávneniami správcu, aby sme mohli vytvárať nových používateľov.

Potom vytvoríme jednu alebo viac rolí (role Vaultu, nie roly databázy) obsahujúcich skutočné príkazy SQL použité na vytvorenie nového používateľa. Spravidla zahŕňajú nielen vyhlásenie o vytvorení používateľa, ale aj všetky požadované údaje grant príkazy potrebné na prístup k objektom schémy (tabuľky, zobrazenia atď.).

Keď klient získa prístup k príslušnému API, Vault vytvorí nového dočasného používateľa v databáze pomocou poskytnutých príkazov a vráti svoje poverenia. Klient potom môže použiť tieto poverenia na prístup do databázy počas obdobia definovaného atribútom time-to-live požadovanej role.

Akonáhle poverenie dosiahne čas vypršania platnosti, Vault automaticky zruší všetky privilégiá spojené s týmto používateľom. Klient môže tiež požiadať Vault o obnovenie týchto poverení. Proces obnovy sa uskutoční, iba ak to podporuje konkrétny ovládač databázy a umožňuje to príslušná politika.

4.3. Kryptografické kľúče

Tajné motory typu pracujú s kryptografickými funkciami, ako je šifrovanie, dešifrovanie, podpisovanie atď. Všetky tieto operácie používajú kryptografické kľúče generované a interne uložené v aplikácii Vault. Pokiaľ to nie je výslovne uvedené, Vault nikdy nevystaví daný kryptografický kľúč.

Pridružené API umožňuje klientom odosielať údaje vo formáte Vault vo formáte prostého textu a prijímať ich šifrovanú verziu. Možný je aj opak: Môžeme posielať šifrované údaje a získať späť pôvodný text.

V súčasnosti existuje iba jeden motor tohto typu: Tranzit motor. Tento modul podporuje populárne typy kľúčov, napríklad RSA a ECDSA, a taktiež podporuje Konvergentné šifrovanie. Pri použití tohto režimu vedie daná hodnota obyčajného textu vždy k rovnakému výsledku cyphertextu, vlastnosti, ktorá je v niektorých aplikáciách veľmi užitočná.

Tento režim môžeme napríklad použiť na šifrovanie čísel kreditných kariet v tabuľke denníkov transakcií. Pri konvergentnom šifrovaní bude zakaždým, keď vložíme novú transakciu, hodnota šifrovanej kreditnej karty rovnaká, čo umožní použitie bežných dotazov SQL na vytváranie prehľadov, vyhľadávanie atď.

5. Nastavenie trezoru

V tejto časti vytvoríme lokálne testovacie prostredie, aby sme otestovali možnosti aplikácie Vault.

Nasadenie aplikácie Vault je jednoduché: stačí stiahnuť balíček, ktorý zodpovedá nášmu operačnému systému, a extrahuje jeho spustiteľný súbor (klenba alebo vault.exe vo Windows) do nejakého adresára na našej PATH. Tento spustiteľný súbor obsahuje server a je tiež štandardným klientom. K dispozícii je tiež oficiálny obrázok Dockera, ale tu sa ho nebudeme venovať.

Podpora trezoru a rozvoja režim, ktorý je vhodný na rýchle testovanie a zvykanie si na jeho nástroj príkazového riadku, ale pre skutočné prípady použitia je príliš zjednodušujúci: pri reštarte sa stratia všetky údaje a prístup API používa obyčajný protokol HTTP.

Namiesto toho použijeme trvalé úložisko založené na súboroch a nastavíme HTTPS, aby sme mohli preskúmať niektoré podrobnosti konfigurácie v reálnom živote, ktoré môžu byť zdrojom problémov.

5.1. Spustenie servera Vault

Vault používa konfiguračný súbor vo formáte HCL alebo JSON. Nasledujúci súbor definuje všetku konfiguráciu potrebnú na spustenie nášho servera pomocou ukladacieho priestoru súborov a certifikátu s vlastným podpisom:

storage "file" {path = "./vault-data"} poslucháč "tcp" {address = "127.0.0.1:8200" tls_cert_file = "./src/test/vault-config/localhost.cert" tls_key_file = ". /src/test/vault-config/localhost.key "}

Teraz spustíme aplikáciu Vault. Otvorte príkazový shell, prejdite do adresára obsahujúceho náš konfiguračný súbor a spustite tento príkaz:

$ vault server -config ./vault-test.hcl

Spustí sa Vault a zobrazí sa niekoľko inicializačných správ. Zahrnú jeho verziu, niektoré podrobnosti o konfigurácii a adresu, kde je API k dispozícii. To je všetko - náš server Vault je funkčný.

5.2. Inicializácia trezoru

Náš server Vault je teraz spustený, ale keďže ide o prvé spustenie, musíme ho inicializovať.

Poďme otvoriť nový shell a vykonať nasledujúce príkazy, aby sme to dosiahli:

$ export VAULT_ADDR = // localhost: 8200 $ export VAULT_CACERT =. / src / test / vault-config / localhost.cert $ vault operátor init

Tu sme definovali niekoľko premenných prostredia, takže ich nemusíme zakaždým odovzdávať do aplikácie Vault ako parametre:

  • VAULT_ADDR: základný URI, kde bude náš server API obsluhovať požiadavky
  • VAULT_CACERT: Cesta k verejnému kľúču certifikátu nášho servera

V našom prípade použijeme VAULT_CACERT takže môžeme použiť HTTPS na prístup k API aplikácie Vault. Potrebujeme to, pretože používame certifikáty s vlastným podpisom. To by nebolo potrebné v produkčných prostrediach, kde zvyčajne máme prístup k certifikátom podpísaným CA.

Po vydaní vyššie uvedeného príkazu by sa mala zobraziť táto správa:

Odpečatenie kľúča 1: Odpečatenie kľúča 2: Odpečatenie kľúča 3: Odpečatenie kľúča 4: Odpečatenie kľúča 5: Počiatočný koreňový token: ... viac správ vynechaných

Päť prvých riadkov predstavuje zdieľanie hlavného kľúča, ktoré neskôr použijeme na odpečatenie úložiska úložiska. Upozorňujeme, že Vault zobrazuje počas inicializácie iba zdieľania hlavného kľúča - a nikdy viac.Berte na vedomie a bezpečne ich uložte, inak po reštarte servera stratíme prístup k našim tajomstvám!

Upozorňujeme tiež na koreňový token, pretože to budeme neskôr potrebovať. Na rozdiel od odpečatených kľúčov koreňové tokeny je možné ľahko vygenerovať neskôr, takže je bezpečné ho zničiť po dokončení všetkých konfiguračných úloh. Pretože budeme neskôr vydávať príkazy, ktoré budú vyžadovať autentifikačný token, uložme si teraz koreňový token do premennej prostredia:

$ export VAULT_TOKEN = (Unix / Linux)

Pozrime sa na stav nášho servera, keď sme ho inicializovali pomocou nasledujúceho príkazu:

Stav kľúča $ Hodnota Hodnota --- ----- Typ pečate shamir Zapečatená pravda Celkom akcií 5 Prahová hodnota 3 Postup pečatenia 0/3 Zrušenie pečiatky Nonce neuvedené Verzia 0.10.4 HA Povolené nepravdivé

Vidíme, že Vault je stále zapečatený. Môžeme tiež sledovať postup pečatenia: „0/3“ znamená, že Vault potrebuje tri zdieľania, ale zatiaľ žiadne. Poďme ďalej a poskytnime to svojim podielom.

5.3. Odpečatenie trezoru

Teraz odlepíme Vault, aby sme mohli začať používať jeho tajné služby. Aby sme dokončili proces odpečatenia, musíme poskytnúť akékoľvek tri z piatich kľúčových zdieľaní:

Odpečatenie operátora úschovne $ Odpečatenie operátora úschovne $ Odpečatenie operátora úschovne $ 

Po vydaní každého trezoru príkazu vytlačí postup odpečatenia vrátane toho, koľko zdieľaní potrebuje. Po odoslaní posledného zdieľaného kľúča sa nám zobrazí správa ako táto:

Kľúčová hodnota --- ----- Typ pečate shamir Zapečatené nepravdivé ... iné vlastnosti vynechané

Vlastnosť „Sealed“ je v tomto prípade „false“, čo znamená, že Vault je pripravený prijímať príkazy.

6. Testovanie trezoru

V tejto časti otestujeme naše nastavenie Vaultu pomocou dvoch z jeho podporovaných tajných typov: Key / Value a Database. Ukážeme tiež, ako vytvoriť nové tokeny s konkrétnymi politikami, ktoré sú s nimi spojené.

6.1. Používanie tajomstiev kľúč / hodnota

Najskôr si uložme tajné páry kľúč - hodnota a prečítajme si ich späť. Za predpokladu, že príkazový shell použitý na inicializáciu Vaultu je stále otvorený, použijeme na uloženie týchto párov pod nasledujúci príkaz tajná / falošná banka cesta:

$ vault kv zatajený / fakebank api_key = abc1234 api_secret = 1a2b3c4d

Teraz môžeme tieto páry kedykoľvek obnoviť pomocou nasledujúceho príkazu:

$ vault kv get secret / fakebank ======= Údaje ======= Kľúčová hodnota --- ----- api_key abc1234 api_secret 1a2b3c4d 

Tento jednoduchý test nám ukazuje, že Vault funguje tak, ako má. Teraz môžeme otestovať niektoré ďalšie funkcie.

6.2. Vytváranie nových tokenov

Doteraz sme na overenie našich požiadaviek používali koreňový token. Pretože koreňový token je spôsobom príliš silné, považuje sa za najlepší postup používať tokeny s menšími oprávneniami a kratšou dobou života.

Vytvorme nový token, ktorý môžeme použiť rovnako ako root root, ale jeho platnosť vyprší po chvíli:

$ vault token create -ttl 1m hodnota kľúča --- ----- token token_accessor token_duration 1m token_renewable true token_policies ["root"] identity_policies [] politiky ["root"]

Vyskúšajme tento token a použijeme ho na načítanie párov kľúč / hodnota, ktoré sme vytvorili predtým:

$ export VAULT_TOKEN = $ vault kv get secret / fakebank ======= Data ======= Hodnota kľúča --- ----- api_key abc1234 api_secret 1a2b3c4d

Ak chvíľu počkáme a pokúsime sa tento príkaz vydať znova, zobrazí sa chybové hlásenie:

$ vault kv get secret / fakebank Chyba pri vytváraní požiadavky API. URL: GET // localhost: 8200 / v1 / sys / internal / ui / mounts / secret / fakebank Kód: 403. Chyby: * povolenie odmietnuté

Správa naznačuje, že náš token už nie je platný, čo sme očakávali.

6.3. Pravidlá testovania

Vzorový token, ktorý sme vytvorili v predchádzajúcej časti, bol skratovaný, ale stále veľmi výkonný. Poďme teraz pomocou politík vytvoriť viac obmedzených tokenov.

Definujme napríklad politiku, ktorá umožňuje prístup iba na čítanie tajná / falošná banka cesta, ktorú sme používali predtým:

$ cat> sample-policy.hcl <

Teraz vytvoríme token s touto politikou pomocou nasledujúceho príkazu:

$ export VAULT_TOKEN = $ vault token create -policy = fakebank-ro Hodnota kľúča --- ----- token token_accessor token_duration 768h token_renewable true token_policies ["predvolené" "fakebank-ro"] identity_policies [] politiky ["predvolené" " fakebank-ro "]

Ako sme už urobili predtým, prečítajme si svoje tajné hodnoty pomocou tohto tokenu:

$ export VAULT_TOKEN = $ vault kv get secret / fakebank ======= Data ======= Hodnota kľúča --- ----- api_key abc1234 api_secret 1a2b3c4d

Zatiaľ je všetko dobré. Dáta môžeme čítať podľa očakávania. Pozrime sa, čo sa stane, keď sa pokúsime aktualizovať toto tajomstvo:

$ vault kv put secret / fakebank api_key = foo api_secret = bar Chyba pri zápise údajov do tajnej / fakebank: Chyba pri vytváraní požiadavky API. URL: PUT //127.0.0.1:8200/v1/secret/fakebank Kód: 403. Chyby: * zamietnuté povolenie

Pretože naše pravidlá výslovne neumožňujú zápisy, Vault vráti stavový kód 403 - Prístup odmietnutý.

6.4. Používanie poverení dynamickej databázy

Ako náš posledný príklad v tomto článku, poďme na vytvorenie dynamických poverení použiť tajný nástroj Database Vault. Tu predpokladáme, že máme lokálne k dispozícii server MySQL a že k nemu môžeme pristupovať s oprávneniami typu „root“. Použijeme tiež veľmi jednoduchú schému pozostávajúcu z jednej tabuľky - účet .

Skript SQL použitý na vytvorenie tejto schémy a privilegovaný používateľ je k dispozícii tu.

Teraz nakonfigurujme Vault na používanie tejto databázy. Databázový tajný nástroj nie je predvolene povolený, takže skôr ako budeme môcť pokračovať, musíme to opraviť:

$ tajné tajomstvá umožňujú databázu Úspech! Povolil databázový tajný stroj na adrese: database /

Teraz vytvárame prostriedok na konfiguráciu databázy:

$ vault write database / config / mysql-fakebank \ plugin_name = mysql-legacy-database-plugin \ connection_url = "{{používateľské meno}}: {{heslo}} @ tcp (127.0.0.1:3306) / fakebank" \ enabled_roles = "*" \ username = "fakebank-admin" \ heslo = "Sup & rSecre7!"

Predpona cesty databáza / konfigurácia je miesto, kde musia byť uložené všetky konfigurácie databázy. Vyberáme meno mysql-fakebank takže môžeme ľahko zistiť, ktorej databázy sa táto konfigurácia týka. Pokiaľ ide o konfiguračné kľúče:

  • plugin_name: Definuje, ktorý databázový doplnok sa použije. Názvy dostupných doplnkov sú opísané v dokumentoch aplikácie Vault
  • pripojenie_url: Toto je šablóna, ktorú používa doplnok pri pripájaní k databáze. Všimnite si zástupné symboly šablón {{username}} a {{password}}. Pri pripájaní k databáze Vault nahradí tieto zástupné symboly skutočnými hodnotami
  • povolené_roly: Definujte, ktoré roly úložiska (diskutované ďalej) môžu používať túto konfiguráciu. V našom prípade používame „*“, takže je k dispozícii všetkým rolám
  • užívateľské meno a heslo: Toto je účet, ktorý Vault použije na vykonávanie databázových operácií, ako je napríklad vytvorenie nového používateľa a odvolanie jeho privilégií

Nastavenie roly databázy úložiska

Úlohou konečnej konfigurácie je vytvoriť prostriedok roly databázy Vault, ktorý obsahuje príkazy SQL potrebné na vytvorenie používateľa. Podľa našich bezpečnostných požiadaviek môžeme vytvoriť toľko rolí, koľko je potrebné.

Tu vytvárame rolu, ktorá udeľuje prístup iba na čítanie ku všetkým tabuľkám v falošná banka schéma:

$ vault napísať databázu / role / fakebank-accounts-ro \ db_name = mysql-fakebank \ creation_statements = "VYTVORIŤ UŽÍVATEĽA '{{name}}' @ '%' IDENTIFIKOVANÉ '{{heslo}}'; GRANTOVAŤ VÝBER NA fakebank. * Pomenovať}}'@'%';" 

Databázový stroj definuje predponu cesty databáza / roly ako miesto na ukladanie rolí. fakebank-accounts-ro je názov roly, ktorý neskôr použijeme pri vytváraní dynamických poverení. Dodávame tiež nasledujúce kľúče:

  • názov_db: Názov existujúcej konfigurácie databázy. Zodpovedá poslednej časti cesty, ktorú sme použili pri vytváraní prostriedku konfigurácie
  • creation_statements: Zoznam šablón príkazov SQL, ktoré služba Vault použije na vytvorenie nového používateľa

Vytváranie dynamických poverení

Keď máme pripravenú databázovú rolu a jej zodpovedajúcu konfiguráciu, vygenerujeme nové dynamické poverenia pomocou nasledujúceho príkazu:

Kľúčová hodnota $ vault načítaná databáza / kredity / fakebank-accounts-ro --- ----- databáza nájmu_id / kredity / fakebank-accounts-ro / 0c0a8bef-761a-2ef2-2fed-4ee4a4a076e4 doba nájmu 1 h rent_renewable skutočné heslo používateľské meno 

The databáza / kredity predpona sa používa na generovanie poverení pre dostupné roly. Keďže sme použili fakebank-accounts-ro role bude vrátené užívateľské meno / heslo obmedzené na vyberte operácie.

Môžeme to overiť pripojením k databáze pomocou dodaných poverení a vykonaním niektorých príkazov SQL:

$ mysql -h 127.0.0.1 -u -p fakebank Zadajte heslo: MySQL [fakebank]> vyberte * z účtu; ... vynechané pre stručnosť 2 riadky v sade (0,00 s) MySQL [fakebank]> vymazať z účtu; CHYBA 1142 (42000): príkaz DELETE bol odmietnutý používateľovi „v-fake-9xoSKPkj1“ @ „localhost“ pre tabuľku „účet“ 

Vidíme, že prvý vyberte úspešne dokončené, ale nemohli sme vykonať vymazať vyhlásenie. Nakoniec, ak počkáme jednu hodinu a pokúsime sa pripojiť pomocou rovnakých prihlasovacích údajov, nebudeme sa už môcť pripojiť k databáze. Vault tomuto používateľovi automaticky odobral všetky privilégiá

7. Záver

V tomto článku sme preskúmali základy Hashicorpovho trezoru vrátane niektorých pozadí problému, ktorý sa pokúša vyriešiť, jeho architektúry a základného použitia.

Počas toho sme vytvorili jednoduché, ale funkčné testovacie prostredie, ktoré použijeme v nasledujúcich článkoch.

Nasledujúci článok sa bude zaoberať veľmi konkrétnym prípadom použitia aplikácie Vault: Jeho použitie v kontexte aplikácie Spring Boot. Zostaňte naladení!


$config[zx-auto] not found$config[zx-overlay] not found