Cea mai bună modalitate de a stoca o parolă de bază de date într-un script de pornire/config?

Deci, aplicațiile serverului nostru web trebuie să se conecteze la baza de date, iar alte aplicații au scripturi de pornire care se execută la momentul încărcării.

Care este cel mai bun mod de a stoca numele/parola pentru aceste aplicații, în termeni de

  • securitate, de ex. poate că nu vrem ca sysadmins să cunoască parola bazei de date
  • mentenabilitate, de ex. făcând configurația ușor de schimbat atunci când se schimbă parola etc.

atât ferestre și soluții linux apreciat!

0
fr hi bn

7 răspunsuri

clarificare: din punct de vedere al securității, al mentenabilității (de exemplu, dacă datele de conectare trebuie să se schimbe, pot să le găsesc mai târziu etc.)

@lomax: poate că nu aș vrea ca toată lumea care are acces la serverul fizic (de exemplu, sysadmins) să vadă parola.

Mulțumiri!

0
adăugat

text simplu? Dacă vă aflați pe serverul dvs., sper că serverul este suficient de sigur pentru a nu permite accesul neautorizat. Dacă oamenii pot accesa fișierele de configurare de pe server, ceva a greșit mult mai devreme.

0
adăugat
În urma acestei strategii s-ar pierde ocazia de a construi o apărare în profunzime.
adăugat autor AJ., sursa

Cea mai bună modalitate de a vă asigura parola este să nu mai utilizați una. Utilizați o conexiune de încredere: Cum să: conectați la SQL Server utilizând autentificarea Windows în ASP.NET 2.0 . Apoi nu aveți nimic de ascuns - publicați-vă web.config și sursa în lume, ei încă nu pot lovi baza de date.

Dacă acest lucru nu va funcționa pentru dvs., utilizați construit în sistem de criptare a configurației în ASP .NET .

0
adăugat

În cele mai multe cazuri, cred că este suficient să obfusem parola într-un fișier text simplu (de exemplu, cu base64). Nu puteți proteja complet o parolă stocată împotriva unui sistem sysadmin determinat, cu acces la rădăcină, deci nu este nevoie de încercare. Obfuscația simplă, totuși, protejează împotriva dezvăluirii accidentale a parolei unui surfer la umăr.

O alternativă mai complexă este crearea unui server dedicat de parole securizate care să fie:

  • oferă un serviciu de decriptare a parolei
  • stochează parolele pentru a fi utilizate de alte servere mai puțin sigure

În funcție de protocoalele de rețea folosite, este posibil ca aceasta să nu protejeze împotriva unui sistem sysadmin necinstit cu tcpdump. Și, probabil, nu va proteja împotriva unui sysadmin determinat cu un debugger, fie. În acel moment, ar putea fi momentul să te uiți la ceva de genul biletelor Kerberos.

0
adăugat

Sunt de acord cu lomaxx: dacă cineva se află deja pe server sau are acces larg la el (ca un sysadmin), jocul este aproape terminat. Deci, ideea ar fi să folosiți un server în care aveți încredere că este sigur în măsura în care doriți să fie. Specific:

  • Trebuie să ai încredere în sysadmins
  • Trebuie să ai încredere în oricine altcineva care rulează codul pe același server (de aceea hostingul în comun este un mare nu-nu pentru mine)

Dincolo de aceasta, variabilele de mediu par a fi o alegere populară pentru stocarea acestor tipuri de acreditări, deoarece acest lucru înseamnă că accesul la sursă numai (de exemplu prin compromiterea casetei dev) nu o dezvăluie direct și, de asemenea, poate fi bine localizată fiecare server (dev, test, etc).

0
adăugat
Este destul de posibil ca un defect al serverului web să permită unui atacator să facă serverul să servească un fișier de configurare, dar să nu permită accesul complet la server. Din acest motiv și pentru că, în general, este o idee bună să construiți o apărare în profunzime, nu ar trebui să stocați date sensibile într-o stare neccripționată.
adăugat autor AJ., sursa

Puteți să coaceți o cheie simetrică de criptare în binar și să citiți binar un nume de utilizator/o parolă criptat dintr-un fișier pe disc când acesta pornește.

Cu toate acestea, acest lucru nu este cu mult mai mult decât obfuscation, deoarece codul dvs. este probabil să fie stocat în unele depozit sursă undeva.

V-aș sugera să vă servească mai bine pentru a controla accesul la serverele dvs. atât fizic, cât și prin rețea folosind un firewall și o bule de rețea privată și să stocați parolele pe hard disk-ul (cu codul de bază-64) cu permisiuni blocate la utilizatorul care rulează pentru aplicația dvs. Web.

De asemenea, puteți bloca serverul bazei de date pentru a accepta numai conexiunile de la mașinile de aplicații web prin IP.

În cele din urmă, problema dvs. este că cheia (perechea dvs. de nume de utilizator/parolă DB) trebuie să fie disponibilă pentru aplicații programate, nesupravegheate de aplicațiile dvs. web.

0
adăugat

PostgreSQL oferă o soluție bună pentru acest tip de situație în documentație. În esență, utilizați ssh pentru a acoperi un port de pe aparat la portul de server PostgreSQL de pe aparatul de la distanță. Aceasta are trei etape de autentificare:

  1. Restricționați accesul la portul local, cum ar fi dacă permiteți unui anumit utilizator să se conecteze la acesta.
  2. Configurați conexiunea fără parolă la gazda PostgreSQL cu ssh ca utilizator particular
  3. Permite utilizatorului ssh să se conecteze ca să aibă acces local la PostgreSQL fără o parolă.

Acest lucru reduce siguranța dacă conturile de utilizator sunt securizate și configurația ssh este solidă și nu aveți nevoie de o parolă stocată oriunde.

Edit: I should add that this will work with any database that listens to a TCP/IP port. It just happens to be described in PostgreSQL. And you will want iptables (or the equivalent off Linux) to do the port restrictions. See this.

0
adăugat