înregistrare Logare
Puncte:1
fgrieu avatar Server

Beneficiile serverului RDBMS separat

drapel de
fgrieu

Aș dori să compar beneficiile a două arhitecturi de găzduire pentru un server mic (adică un procesor cu 2 nuclee și 250 GB SSD, cu 100 GB dedicati pentru date, este mai mult decât suficient), constând în principal dintr-o aplicație personalizată care oferă servicii web, cu o arhitectură REST și toate datele dintr-o bază de date relațională.

  1. Găzduit pe o singură mașină în cloud (de exemplu, o instanță EC2) cu o bază de date relațională (de ex.mySQL, PostGreSQL) rulează local, cu backup-uri externe frecvente ale bazei de date criptate (de exemplu, pe S3/Glacier).
  2. Găzduit pe o mașină în cloud (de exemplu, o instanță EC2 similară cu mai puțin SSD) cu RDBMS un serviciu gestionat, de ex. Amazon Relational Database Service, poate cu backup-uri externe de baze de date criptate mai puțin frecvente.

Văd beneficii pentru 1

  • Mai ieftin (economisirea serviciului și a rețelei gestionate RDBMS) cu un factor de aproximativ 3, cred.
  • Posibil o latență mai bună a acceselor la baze de date?

si pentru 2

  • Dacă instanța EC2 este ștearsă, nu vom pierde date.
  • Nu este nevoie să copiați DB de la o instanță EC2 la alta atunci când reconstruiți serverul de la zero sau faceți o actualizare majoră, cum ar fi schimbarea sistemului de operare; astfel mai puțin timp de nefuncționare.
  • Poate o administrare mai ușoară a DB.

Ce imi lipseste? Vreo indicii către o poziție de autoritate în acest sens?

44
1 + 3
pmdba avatar
drapel cn
pmdba
Din punct de vedere al securității, datele nu ar trebui _nu_ niciodată să fie găzduite pe același server ca front-end-ul aplicației - mai ales dacă front-end-ul este expus la internet, dar și pe rețelele private. Bazele de date trebuie protejate în spatele unui firewall, separat de serverele de aplicații.
1
Răspunde
fgrieu avatar
drapel de
fgrieu
@pmdba: Văd punctul tău de vedere și este interesant. Totuși, dacă serverul cu front-end-ul aplicației este compromis și din moment ce are acreditările pentru a accesa RDBMS, toate datele din RDBMS pot fi, în principiu, exfiltrate sau/și corupte în scenariul 1/2 la fel (cu diferența că poate fi prin sistemul de fișiere numai în 1).Singura diferență fermă pe care o văd este că în scenariul 2 exfiltrarea/corupția este vizibilă în jurnalele RDBMS, când acestea pot fi modificate sau nuk cu restul în scenariul 1.
0
Răspunde
pmdba avatar
drapel cn
pmdba
Un design de aplicație securizat ar face ca aplicația să utilizeze un cont DB neprivilegiat, accesând datele printr-un API back-end (construit folosind procedurile stocate în DB). Aplicația nu ar trebui să se conecteze direct la un cont DB privilegiat și, mai ales, nu la contul care deține datele sau obiectele.
1
Răspunde
Puncte:1
avatar Server
drapel de
John Malloc

Referitor la primul punct:

  • Când serviciul dvs. web este compromis, baza de date va fi, de asemenea, compromisă. Cea mai bună practică este separarea stratului de prezentare de stratul de date.

  • latența cu același sau chiar între două AZ este minoră și poate fi omisă din considerente.

  • Nu aș spune că această soluție va fi mult mai ieftină decât RDS-ul deoarece factorul relevant care va afecta prețul ar fi stocarea SSD. Pretul ar fi de aproximativ 30% intre RDS si EC2.

  • În ceea ce privește tipul SSD, trebuie să decideți sau poate ați știut deja de ce nivel IOPS și MB/s la vârfuri ar avea nevoie în viitor baza de date. Acesta ar fi, de asemenea, un bun candidat pentru a îmbunătăți prețurile finale ale soluției.

Referitor la al doilea punct:

  • Puteți preveni această situație. În mod implicit, când atașați un volum EBS non-root la o instanță, DeleteOnTermination atributul este setat la fals. Presupun că baza de date ar fi localizată pe un volum EBS non-root. Steagul ar putea fi setat la fals și asupra volumului rădăcinii.

  • nu trebuie să copiați o bază de date de la EC2 la EC2, puteți atașa sau detașa volumul EBS cu baza de date.

  • după cum ați subliniat în soluția RDS, responsabilitatea administrativă revine AWS. Cu toate acestea, cu cât schema unei baze de date este mai complexă, cu atât aș opta mai mult pentru un serviciu de baze de date neadministrate.

Nu ai menționat care este factorul cheie pentru arhitectură. Economii de cost sau de management al operațiunii? Prețul va diferi semnificativ atunci când vă decideți asupra tipului de model de preț: fără avans vs toate în avans. Nu știu dacă acest serviciu va funcționa în timpul orelor de lucru și ar putea fi oprit în timpul nopții. De asemenea, nu ați menționat ce va rula pe serviciile web. Este crucial pentru afacere? Poate că o soluție bună și rentabilă ar fi să luați în considerare arhitectura fără server dacă serviciul web este o aplicație bazată pe evenimente.

0 + 2
fgrieu avatar
drapel de
fgrieu
Nu înțeleg de ce situația este mult mai bună din punct de vedere al securității cu RBS separat.Raționez că dacă serviciul web este compromis, deoarece are acces R/W la baza de date, un adversar poate face o extragere sau modificare. Recunosc o diferență: întreaga DB poate fi copiată prin sistemul de fișiere numai atunci când RBS rulează local. O DB criptată atenuează acest lucru într-o oarecare măsură.
0
Răspunde
drapel de
John Malloc
Să presupunem că sunt un hacker. Am pătruns în instanța dvs. EC2 în care rulează serviciul web împreună cu baza de date. Să presupunem, de asemenea, că nu ați observat că incidentul de securitate a avut loc. Aș instala un program sniffer și keylogger și aș aștepta o notificare. Când un administrator de bază de date se conectează sau cineva execută comenzi SQL local din greșeală, voi intercepta acreditările. M-aș autentifica din nou și m-aș arunca baza de date. Acest lucru este greu de făcut atunci când stratul de prezentare vorbește cu stratul de bază de date prin proxy HTTPS și cheile publice/private nu sunt localizate în același loc.
0
Răspunde
drapel romania
SEF 777
întrebarea această in alte limbi:

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.