streamalism.org

1. Pregled

U ovom uputstvu istražit ćemo Hashicorpov svod - popularni alat koji se koristi za sigurno upravljanje osjetljivim informacijama u modernim arhitekturama aplikacija.

Glavne teme koje ćemo pokriti uključuju:

• Koji problem Vault pokušava riješiti
• Arhitektura trezora i glavni pojmovi
• Postavljanje jednostavnog testnog okruženja
• Interakcija sa Trezorom pomoću alata za naredbene retke

2. Problem s osjetljivim informacijama

Prije nego što uđemo u Trezor, pokušajmo razumjeti problem koji pokušava riješiti: upravljanje osjetljivim informacijama.

Većini aplikacija potreban je pristup osjetljivim podacima kako bi mogli ispravno raditi. Na primjer, aplikacija za e-trgovinu može imati korisničko ime / lozinku konfiguriranu negdje kako bi se povezala sa svojom bazom podataka. Možda će mu trebati i API ključevi za integraciju s drugim davateljima usluga, poput pristupnika za plaćanje, logistike i drugih poslovnih partnera.

Vjerodajnice baze podataka i API ključevi neki su primjeri osjetljivih podataka koje trebamo pohraniti i učiniti dostupnima našim aplikacijama na siguran način.

Jednostavno rješenje je pohraniti te vjerodajnice u konfiguracijsku datoteku i pročitati ih prilikom pokretanja. Međutim, problem s ovim pristupom je očit. Tko ima pristup ovoj datoteci, dijeli iste privilegije baze podataka koje ima naša aplikacija - obično joj daje puni pristup svim pohranjenim podacima.

Šifriranjem tih datoteka možemo pokušati malo otežati stvar. Međutim, ovaj pristup neće dodati puno u smislu ukupne sigurnosti. Uglavnom zato što naša aplikacija mora imati pristup glavnom ključu. Kodiranje, kada se koristi na ovaj način, postići će samo "lažni" osjećaj sigurnosti.

Moderne aplikacije i okruženja u oblaku imaju tendenciju dodavanja dodatne složenosti: distribuirane usluge, više baza podataka, sustavi za razmjenu poruka i tako dalje, svi imaju osjetljive informacije posvuda malo raširene, što povećava rizik od narušavanja sigurnosti.

Pa, što možemo učiniti? Idemo na svod!

3. Što je trezor?

Hashicorp Vault bavi se problemom upravljanja osjetljivim informacijama - a tajna jezikom Vault. "Upravljanje" u ovom kontekstu znači da Vault kontrolira sve aspekte osjetljive informacije: njegovo generiranje, pohranjivanje, korištenje i, na kraju, ali ne manje važno, opoziv.

Hashicorp nudi dvije verzije trezora. Verzija otvorenog koda, korištena u ovom članku, besplatna je za upotrebu, čak iu komercijalnim okruženjima. Dostupna je i verzija koja se plaća, što uključuje tehničku podršku za različite SLA-ove i dodatne značajke, poput HSM (Hardware Security Module) podrške.

3.1. Arhitektura i ključne značajke

Arhitektura trezora zavaravajući je jednostavna. Njegove su glavne komponente:

• Upornost - čuvanje svih tajni
• API poslužitelj koji obrađuje zahtjeve klijenta i izvodi operacije nad tajnama
• Broj tajni motori, jedan za svaku vrstu podržane tajne vrste

Delegiranjem sve tajne obrade u Vault, možemo ublažiti neke sigurnosne probleme:

• Naše ih aplikacije više ne moraju pohranjivati ​​- jednostavno zatražite Trezor i bacite ga
• Možemo se služiti kratkotrajnim tajnama, ograničavajući tako „prozor mogućnosti“ gdje napadač može koristiti ukradenu tajnu

Trezor šifrira sve podatke ključem za šifriranje prije pisanja u trgovinu. Ovaj ključ za šifriranje šifriran je još jednim ključem - glavnim ključem, koji se koristi samo prilikom pokretanja.

Ključna točka u implementaciji Vault-a je da ne pohranjuje glavni ključ na poslužitelj. To znači da niti Vault ne može pristupiti svojim spremljenim podacima nakon pokretanja. U ovom trenutku se kaže da je instanca Trezora u "zapečaćenom" stanju.

Kasnije ćemo proći korake potrebne za generiranje glavnog ključa i otključavanje instance Trezora.

Jednom otpečaćen, Vault će biti spreman prihvatiti API zahtjeve. Ti zahtjevi, naravno, trebaju provjeru autentičnosti, što nas dovodi do toga kako Vault provjerava autentičnost klijenata i odlučuje što oni mogu, a što ne mogu učiniti.

3.2. Ovjera

Da bi pristupio tajnama u Trezoru, klijent se mora ovjeriti pomoću jedne od podržanih metoda. Najjednostavnija metoda koristi žetone, koji su samo nizovi poslani na svaki API zahtjev pomoću posebnog HTTP zaglavlja.

Kada je inicijalno instaliran, Vault automatski generira "root token". Ovaj je token ekvivalentan root superuseru u Linux sustavima, pa bi njegova upotreba trebala biti ograničena na minimum. Kao najbolju praksu, trebali bismo koristiti ovaj root žeton samo za stvaranje drugih tokena s manje privilegija, a zatim ga opozvati. To, međutim, nije problem, budući da kasnije možemo generirati još jedan korijenski token pomoću ključeva za otključavanje.

Trezor također podržava ostale mehanizme provjere autentičnosti, kao što su LDAP, JWT, TLS certifikati, između ostalog. Svi se ti mehanizmi nadograđuju na osnovni mehanizam tokena: nakon što Vault provjeri valjanost našeg klijenta, pružit će token koji možemo koristiti za pristup drugim API-ima.

Žetoni su povezani s nekoliko svojstava. Glavna svojstva su:

• Skup pridruženih Politike (vidi sljedeći odjeljak)
• Vrijeme za život
• Može li se obnoviti
• Maksimalni broj upotrebe

Ako nije drugačije rečeno, tokeni koje je stvorio Vault činit će odnos roditelja i djeteta. Dijete token može imati najviše istu razinu privilegija kao i roditelj.

Suprotno nije istina: možemo - i obično to radimo - stvoriti podređeni token s restriktivnim politikama Još jedna ključna stvar u ovom odnosu: Kada onesposobimo žeton, svi podređeni žetoni i njihovi potomci su također poništeni.

3.3. Politike

Politike točno definiraju kojim tajnama klijent može pristupiti i koje radnje s njima može izvršiti. Pogledajmo kako izgleda jednostavno pravilo:

put "tajno / računovodstvo" {mogućnosti = ["pročitati"]}

Ovdje smo koristili sintaksu HCL (Hashicorpov konfiguracijski jezik) za definiranje naših pravila. Vault također podržava JSON u tu svrhu, ali mi ćemo se u svojim primjerima držati HCL-a jer je lakši za čitanje.

Pravila u Trezoru "odbacuju prema zadanim postavkama". Token priložen ovom uzorku pravila dobit će pristup tajnama pohranjenim pod tajno / računovodstvo i nista vise. U vrijeme stvaranja token se može pridružiti više pravila. To je vrlo korisno jer nam omogućuje stvaranje i testiranje manjih pravila, a zatim njihovu primjenu prema potrebi.

Sljedeći važan aspekt politika je u tome što koriste lijenu procjenu. To znači da možemo ažurirati dano pravilo i to će odmah utjecati na sve tokene.

Do sada opisane politike nazivaju se i Pravilima popisa za kontrolu pristupa ili ACL pravilima. Trezor također podržava dvije dodatne vrste pravila: EGP i RGP politike. Oni su dostupni samo u plaćenim verzijama i proširuju osnovnu sintaksu pravila uz podršku Sentinela.

Kada su dostupni, to nam omogućuje da u svojim pravilima uzmemo u obzir dodatne atribute kao što su doba dana, višestruki faktori provjere autentičnosti, porijeklo klijentske mreže itd. Na primjer, možemo definirati politiku koja omogućuje pristup određenoj tajni samo u radno vrijeme.

Više detalja o sintaksi pravila možemo pronaći u dokumentaciji Vault-a.

4. Tajne vrste

Trezor podržava niz različitih tajnih vrsta koje se bave različitim slučajevima upotrebe:

• Ključ / vrijednost: jednostavni statički parovi ključ / vrijednost
• Dinamički generirane vjerodajnice: generira Vault na zahtjev klijenta
• Kriptografski ključevi: Koristi se za izvođenje kriptografskih funkcija s podacima klijenta

Svaka tajna vrsta definirana je sljedećim atributima:

• A montiratitočka, koji definira njegov prefiks REST API
• Skup operacija izloženih kroz odgovarajući API
• Skup konfiguracijskih parametara

Danoj tajnoj instanci moguće je pristupiti putem a staza, slično stablu direktorija u datotečnom sustavu. Prva komponenta ovog puta odgovara točka montiranja gdje se nalaze sve tajne ovog tipa.

Na primjer, niz tajna / moja prijava odgovara putu pod kojim možemo pronaći parove ključ / vrijednost moja prijava.

4.1. Tajne ključa / vrijednosti

Tajne ključa / vrijednosti su, kao što i samo ime govori, jednostavni parovi dostupni pod određenim putem. Na primjer, možemo spremiti par foo = traka ispod staze / tajna / moja prijava.

Kasnije koristimo isti put za dohvaćanje istog para ili parova - više parova može se pohraniti pod isti put.

Trezor podržava tri vrste tajnosti Key-Value:

• Neverzirani parovi ključeva, gdje ažuriranja zamjenjuju postojeće vrijednosti
• Verzirani parovi ključeva, koji drže do prilagodljivog broja starih verzija
• Ostava, posebna vrsta ne-verzijskih parova ključeva čije su vrijednosti ograničene na zadani pristupni token (više o onima kasnije).

Tajne Key-Value po svojoj su prirodi statične, tako da s njima ne postoji koncept pridruženog isteka. Glavni slučaj upotrebe ove vrste tajne je pohrana vjerodajnica za pristup vanjskim sustavima, poput API ključeva.

U takvim scenarijima ažuriranje vjerodajnica je poluručni postupak, koji obično zahtijeva da netko nabavi nove vjerodajnice i pomoću naredbenog retka trezora ili korisničkog sučelja za unos novih vrijednosti.

4.2. Dinamički generirane tajne

Dinamične tajne generira Vault u hodu na zahtjev aplikacije. Trezor podržava nekoliko vrsta dinamičkih tajni, uključujući sljedeće:

• Vjerodajnice baze podataka
• SSH ključni parovi
• X.509 Potvrde
• Vjerodajnice za AWS
• Računi usluge Google Cloud
• Računi Active Directory

Svi ovi slijede isti obrazac korištenja. Prvo konfiguriramo tajni mehanizam s detaljima potrebnim za povezivanje s pridruženom uslugom. Zatim definiramo jednog ili više njih uloge, koji opisuju stvarno tajno stvaranje.

Uzmimo za primjer tajni mehanizam baze podataka. Prvo, moramo konfigurirati Vault sa svim detaljima veza s korisničkom bazom podataka, uključujući vjerodajnice već postojećeg korisnika s administratorskim privilegijama za stvaranje novih korisnika.

Zatim kreiramo jednu ili više uloga (uloge trezora, a ne uloge baze podataka) koje sadrže stvarne SQL izraze koji se koriste za stvaranje novog korisnika. Oni obično uključuju ne samo izjavu o stvaranju korisnika već i sve potrebne dodijeliti izjave potrebne za pristup objektima sheme (tablice, pogledi i tako dalje).

Kada klijent pristupi odgovarajućem API-ju, Vault će stvoriti novog privremenog korisnika u bazi podataka pomoću danih izjava i vratiti svoje vjerodajnice. Klijent zatim može koristiti te vjerodajnice za pristup bazi podataka tijekom razdoblja definiranog atributom vremena do traženja tražene uloge.

Kad vjerodajnica istekne vrijeme isteka, Vault će automatski opozvati sve povlastice povezane s ovim korisnikom. Klijent također može zatražiti da Vault obnovi te vjerodajnice. Postupak obnove dogodit će se samo ako ga podržava određeni pokretački program baze podataka i dopušta pridružena politika.

4.3. Kriptografski ključevi

Tajni strojevi tipa obrađuju kriptografske funkcije kao što su šifriranje, dešifriranje, potpisivanje i tako dalje. Sve te operacije koriste kriptografske ključeve koje generira i pohranjuje interno Vault. Ako to izričito nije rečeno, Vault nikada neće izložiti dani kriptografski ključ.

Povezani API omogućuje klijentima slanje podataka trezora u običnom tekstu i primanje šifrirane verzije istih. Moguće je i suprotno: možemo poslati šifrirane podatke i vratiti izvorni tekst.

Trenutno postoji samo jedan motor ove vrste: Tranzit motor. Ovaj mehanizam podržava popularne vrste ključeva, kao što su RSA i ECDSA, a također podržava Konvergentno šifriranje. Kada se koristi ovaj način, zadana vrijednost otvorenog teksta uvijek rezultira istim rezultatom kiferteksta, svojstvom koje je vrlo korisno u nekim aplikacijama.

Na primjer, ovaj način možemo koristiti za šifriranje brojeva kreditnih kartica u tablici dnevnika transakcija. S konvergentnom enkripcijom, svaki put kada umetnemo novu transakciju, vrijednost šifrirane kreditne kartice bila bi ista, što bi omogućilo upotrebu uobičajenih SQL upita za izvještavanje, pretraživanje i tako dalje.

5. Postavljanje trezora

U ovom ćemo odjeljku stvoriti lokalno testno okruženje kako bismo testirali mogućnosti trezora.

Uvođenje Vault-a je jednostavno: samo preuzmite paket koji odgovara našem operativnom sustavu i izvadi njegovu izvršnu datoteku (svod ili trezor.exe na Windows) u neki direktorij na našem PUTU. Ova izvršna datoteka sadrži poslužitelj i ujedno je standardni klijent. Dostupna je i službena Dockerova slika, ali ovdje je nećemo pokrivati.

Podrška trezora a razvoj način, što je u redu za brzo testiranje i navikavanje na njegov alat naredbenog retka, ali je previše pojednostavljen za stvarne slučajeve upotrebe: svi se podaci gube pri ponovnom pokretanju, a API pristup koristi obični HTTP.

Umjesto toga, upotrijebit ćemo trajnu pohranu i postavljanje HTTPS-a na temelju datoteka kako bismo mogli istražiti neke detalje stvarne konfiguracije koji mogu biti izvor problema.

5.1. Pokretanje poslužitelja trezora

Trezor koristi konfiguracijsku datoteku koja koristi HCL ili JSON format. Sljedeća datoteka definira svu konfiguraciju potrebnu za pokretanje našeg poslužitelja pomoću spremišta datoteka i samopotpisanog certifikata:

pohrana "datoteka" {put = "./vault-data"} slušatelj "tcp" {adresa = "127.0.0.1:8200" tls_cert_file = "./src/test/vault-config/localhost.cert" tls_key_file = ". /src/test/vault-config/localhost.key "}

Ajmo sada pokrenuti Vault. Otvorite ljusku naredbe, idite u direktorij koji sadrži našu konfiguracijsku datoteku i pokrenite ovu naredbu:

$ trezor poslužitelj -config ./vault-test.hcl

Trezor će se pokrenuti i prikazat će nekoliko inicijalizacijskih poruka. Uključit će njegovu verziju, neke detalje o konfiguraciji i adresu na kojoj je API dostupan. To je to - naš poslužitelj Vault je pokrenut i pokrenut.

5.2. Inicijalizacija trezora

Naš poslužitelj Vault sada radi, ali budući da je ovo njegovo prvo pokretanje, trebamo ga inicijalizirati.

Otvorimo novu ljusku i izvršimo sljedeće naredbe da bismo to postigli:

$ izvoz VAULT_ADDR = // localhost: 8200 $ izvoz VAULT_CACERT =. / src / test / vault-config / localhost.cert $ operator trezora init

Ovdje smo definirali nekoliko varijabli okoline, tako da ih ne moramo svaki put prosljeđivati ​​u Vault kao parametre:

• VAULT_ADDR: osnovni URI gdje će naš API poslužitelj posluživati ​​zahtjeve
• VAULT_CACERT: Put do javnog ključa certifikata našeg poslužitelja

U našem slučaju koristimo VAULT_CACERT tako da možemo koristiti HTTPS za pristup Vault-ovom API-ju. To nam treba jer koristimo samopotpisane certifikate. To ne bi bilo potrebno za proizvodna okruženja, gdje obično imamo pristup certifikatima potpisanim od CA.

Nakon izdavanja gornje naredbe, trebali bismo vidjeti poruku poput ove:

Ključ za otključavanje 1: Otključavanje za ključ 2: Ključ za otključavanje 3: Otključavanje ključa 4: Otključavanje ključa 5: Početni korijenski žeton: ... izostavljeno je više poruka

Pet prvih redaka su udjeli glavnog ključa koje ćemo kasnije koristiti za otključavanje spremišta Vault-a. Imajte na umu da Vault prikazuje samo dijeljenje glavnog ključa tijekom inicijalizacije - i nikada više.Zabilježite i spremite ih na sigurno ili ćemo izgubiti pristup našim tajnama nakon ponovnog pokretanja poslužitelja!

Također, uzmite u obzir korijenski žeton, jer će nam trebati kasnije. Za razliku od otključanih ključeva, korijenski tokeni mogu se lako generirati kasnije, pa ga je sigurno uništiti nakon dovršetka svih zadataka konfiguracije. Budući da ćemo kasnije izdavati naredbe za koje je potreban token za provjeru autentičnosti, spremimo root root za sada u varijablu okruženja:

$ export VAULT_TOKEN = (Unix / Linux)

Pogledajmo status našeg poslužitelja sada kada smo ga inicijalizirali, sljedećom naredbom:

$ trezor status Vrijednost ključa --- ----- Tip brtve shamir Zapečaćeno istina Ukupno dionica 5 Prag 3 Otključavanje Napredak 0/3 Otpečaćenje Nepočetano n / a Verzija 0.10.4 HA Omogućeno false

Vidimo da je Trezor još uvijek zapečaćen. Također možemo pratiti napredak otpečaćivanja: "0/3" znači da Vault trebaju tri dionice, ali zasad nije dobio nijednu. Krenimo dalje i pružimo ga svojim dionicama.

5.3. Otključavanje trezora

Sada smo otpečatili Vault kako bismo mogli početi koristiti njegove tajne službe. Moramo navesti bilo koje tri od pet ključnih dionica kako bismo dovršili postupak otpečaćivanja:

$ vault operator unseal $ vault operator unseal $ vault operator unseal 

Nakon izdavanja svakog naredbenog trezora ispisat će se napredak otključavanja, uključujući koliko dijeljenja treba. Nakon slanja zadnjeg dijeljenja ključa, vidjet ćemo poruku poput ove:

Ključna vrijednost --- ----- Tip brtve shamir Zapečaćeno lažno ... izostavljena druga svojstva

Svojstvo "Sealed" u ovom je slučaju "false", što znači da je Trezor spreman za prihvaćanje naredbi.

6. Ispitivanje trezora

U ovom ćemo odjeljku testirati našu postavku trezora koristeći dvije podržane vrste tajnih podataka: ključ / vrijednost i baza podataka. Pokazat ćemo i kako stvoriti nove tokene s njima povezanim određenim pravilima.

6.1. Korištenje tajni ključa / vrijednosti

Prvo, pohranimo tajne parove ključ / vrijednost i pročitajmo ih natrag. Pod pretpostavkom da je ljuska naredbe koja se koristi za inicijalizaciju trezora i dalje otvorena, koristimo sljedeću naredbu za spremanje tih parova pod tajna / lažna banka staza:

$ trezor kv stavi tajno / lažna banka api_key = abc1234 api_secret = 1a2b3c4d

Te parove sada možemo oporaviti u bilo kojem trenutku pomoću sljedeće naredbe:

$ vault kv get secret / fakebank ======= Podaci ======= Vrijednost ključa --- ----- api_key abc1234 api_secret 1a2b3c4d 

Ovaj jednostavan test pokazuje nam da Vault radi kako treba. Sada možemo testirati neke dodatne funkcionalnosti.

6.2. Stvaranje novih tokena

Do sada smo koristili root žeton za autentifikaciju naših zahtjeva. Budući da je korijenski žeton put premoćan, smatra se najboljom praksom korištenje žetona s manje privilegija i kraćim vremenom života.

Stvorimo novi token koji možemo koristiti baš kao korijenski token, ali istječe nakon samo minute:

$ vault token create -ttl 1m Ključna vrijednost --- ----- token token_accessor token_duration 1m token_renewable true token_policies ["root"] identity_polities [] policy ["root"]

Isprobajmo ovaj token, koristeći ga za čitanje parova ključ / vrijednost koje smo stvorili prije:

$ export VAULT_TOKEN = $ vault kv get secret / fakebank ======= Podaci ======= Ključna vrijednost --- ----- api_key abc1234 api_secret 1a2b3c4d

Ako pričekamo minutu i pokušamo ponovno izdati ovu naredbu, dobit ćemo poruku o pogrešci:

$ vault kv get secret / fakebank Pogreška prilikom izrade zahtjeva za API. URL: GET // localhost: 8200 / v1 / sys / internal / ui / mounts / secret / fakebank Šifra: 403. Pogreške: * odbijeno odobrenje

Poruka ukazuje na to da naš token više nije valjan, što smo i očekivali.

6.3. Politike testiranja

Uzorak tokena koji smo stvorili u prethodnom odjeljku bio je kratkog vijeka, ali i dalje vrlo moćan. Upotrijebimo sada politike za stvaranje ograničenijih tokena.

Na primjer, definirajmo politiku koja dopušta samo čitanje pristupa datoteci tajna / lažna banka put koji smo koristili prije:

$ cat> sample-policy.hcl <

Sada stvaramo žeton s ovim pravilom sa sljedećom naredbom:

$ export VAULT_TOKEN = $ trezor token create -policy = fakebank-ro Ključna vrijednost --- ----- token token_accessor token_duration 768h token_renewable true token_policies ["default" "fakebank-ro"] identity_polities [] policy ["default" " lažna banka-ro "]

Kao što smo i prije radili, pročitajmo svoje tajne vrijednosti koristeći ovaj token:

$ export VAULT_TOKEN = $ vault kv get secret / fakebank ======= Podaci ======= Ključna vrijednost --- ----- api_key abc1234 api_secret 1a2b3c4d

Zasada je dobro. Očekivano možemo čitati podatke. Pogledajmo što se događa kada pokušamo ažurirati ovu tajnu:

$ vault kv put secret / fakebank api_key = foo api_secret = bar Pogreška prilikom upisivanja podataka u secret / fakebank: Pogreška prilikom izrade zahtjeva za API. URL: PUT //127.0.0.1:8200/v1/secret/fakebank Šifra: 403. Pogreške: * odobrenje odbijeno

Budući da naša politika izričito ne dopušta upisivanje, Vault vraća statusni kôd 403 - pristup odbijen.

6.4. Korištenje vjerodajnica za dinamičke baze podataka

Kao naš posljednji primjer u ovom članku, upotrijebimo tajni mehanizam baze podataka Vault kako bismo stvorili dinamičke vjerodajnice. Ovdje pretpostavljamo da imamo MySQL poslužitelj dostupan lokalno i da mu možemo pristupiti s “root” privilegijama. Također ćemo koristiti vrlo jednostavnu shemu koja se sastoji od jedne tablice - račun .

SQL skripta koja se koristi za stvaranje ove sheme i privilegiranog korisnika dostupna je ovdje.

Sada, konfigurirajmo Vault da koristi ovu bazu podataka. Tajni mehanizam baze podataka nije omogućen prema zadanim postavkama, pa to moramo popraviti prije nego što nastavimo:

$ vault tajne omogućuju uspjeh baze podataka! Omogućen je mehanizam za tajne baze podataka na: database /

Sada kreiramo resurs za konfiguraciju baze podataka:

$ vault write database / config / mysql-fakebank \ plugin_name = mysql-legacy-database-plugin \ connection_url = "{{korisničko ime}}: {{lozinka}} @ tcp (127.0.0.1:3306) / fakebank" \ allowed_roles = "*" \ username = "fakebank-admin" \ password = "Sup & rSecre7!"

Prefiks puta baza podataka / konfiguracija je mjesto gdje se moraju pohraniti sve konfiguracije baze podataka. Mi biramo ime mysql-lažna banka tako da možemo lako otkriti na koju se bazu podataka odnosi ova konfiguracija. Što se tiče konfiguracijskih tipki:

• ime_dodatka: Definira koji će se dodatak za bazu podataka koristiti. Dostupni nazivi dodataka opisani su u dokumentima Vault-a
• veza_url: Ovo je predložak koji dodatak koristi prilikom povezivanja s bazom podataka. Primijetite rezervirana mjesta predloška {{korisničko ime}} i {{lozinka}}. Prilikom povezivanja s bazom podataka, Vault će zamijeniti ta rezervirana mjesta stvarnim vrijednostima
• dopuštene_uloge: Definirajte koje uloge trezora (o kojima ćemo raspravljati sljedeće) mogu koristiti ovu konfiguraciju. U našem slučaju koristimo "*", tako da je dostupno svim ulogama
• korisničko ime Zaporka: Ovo je račun koji će Vault koristiti za obavljanje operacija baze podataka, poput stvaranja novog korisnika i opoziva njegovih privilegija

Postavljanje uloge baze podataka trezora

Konačni konfiguracijski zadatak je stvaranje resursa uloge baze podataka Vault koji sadrži SQL naredbe potrebne za stvaranje korisnika. Možemo stvoriti onoliko uloga koliko je potrebno, u skladu sa našim sigurnosnim zahtjevima.

Ovdje stvaramo ulogu koja omogućuje pristup samo za čitanje svim tablicama lažna banka shema:

$ vault write baza podataka / uloge / fakebank-accounts-ro \ db_name = mysql-fakebank \ creation_statements = "STVORI KORISNIKA '{{name}}' @ '%' IDENTIFIKIRANO PO '{{lozinka}}'; DODATI ODABIR na lažnoj banci. * DO '{{name}}' @ '%'; " 

Mehanizam baze podataka definira prefiks puta baza podataka / uloge kao mjesto za pohranu uloga. lažne banke-računi-ro je naziv uloge koji ćemo kasnije koristiti pri izradi dinamičkih vjerodajnica. Također isporučujemo sljedeće ključeve:

• db_name: Ime postojeće konfiguracije baze podataka. Odgovara zadnjem dijelu puta koji smo koristili prilikom stvaranja konfiguracijskog resursa
• statement_statements: Popis predložaka SQL izraza koje će Vault koristiti za stvaranje novog korisnika

Stvaranje dinamičkih vjerodajnica

Nakon što pripremimo ulogu baze podataka i njezinu odgovarajuću konfiguraciju, generiramo nove dinamičke vjerodajnice sljedećom naredbom:

Vrijednost ključne riječi $ vault read database / creds / fakebank-accounts-ro --- ----- lease_id database / creds / fakebank-accounts-ro / 0c0a8bef-761a-2ef2-2fed-4ee4a4a076e4 lease_duration 1h lease_renewable true username username 

The baza podataka / krediti prefiks koristi se za generiranje vjerodajnica za dostupne uloge. Budući da smo koristili lažne banke-računi-ro ulogu, vraćeno korisničko ime / lozinka bit će ograničeni na Odaberi operacijama.

To možemo provjeriti povezivanjem s bazom podataka pomoću isporučenih vjerodajnica i zatim izvođenjem nekih SQL naredbi:

$ mysql -h 127.0.0.1 -u -p fakebank Unesite lozinku: MySQL [fakebank]> odaberite * s računa; ... izostavljeno za kratkoću 2 retka u skupu (0,00 sek) MySQL [fakebank]> izbriši s računa; POGREŠKA 1142 (42000): naredba DELETE odbijena je za korisnika 'v-fake-9xoSKPkj1' @ 'localhost' za tablicu 'račun' 

To možemo vidjeti prvi Odaberi uspješno dovršen, ali nismo mogli izvršiti izbrisati izjava. Napokon, ako pričekamo jedan sat i pokušamo se povezati pomoću istih vjerodajnica, više se nećemo moći povezati s bazom podataka. Trezor je automatski ukinuo sve privilegije ovom korisniku

7. Zaključak

U ovom su članku istražene osnove Hashicorpovog trezora, uključujući neke pozadine problema koje pokušava riješiti, njegovu arhitekturu i osnovnu uporabu.

Usput smo stvorili jednostavno, ali funkcionalno testno okruženje koje ćemo koristiti u daljnjim člancima.

Sljedeći će članak pokrivati ​​vrlo specifičan slučaj upotrebe trezora: Koristeći ga u kontekstu aplikacije Spring Boot. Pratite nas!