mboost-dp1
PostgreSQL kommunikation over Internettet
Jeg har brug for at lade en PostgreSQL klient kommunikere med en PostgreSQL server, der er hostet på et andet netværk. Jeg ved ikke om PostgreSQL i sig selv er sikkert nok til at man kan lade det kommunikere over Internettet. Og min søgen efter dokumentation på området har ikke givet nogen resultater.
Er her nogen som ved, hvor man finder dokumentation på området?
Hvis ikke PostgreSQL i sig selv er sikkert nok, så er mine muligheder at enten sætte noget VPN op, eller at bruge en SSH portforwarding. Af de to muligheder foretrækker jeg SSH fordi vi allerede bruger SSH til mange andre formål. Men jeg er en lille smule bekymret for problemer hvis en netværksglitch får SSH forbindelsen til at hænge, og jeg aldrig kan være helt sikker på om jeg trygt kan slå en gammel SSH klient ned eller om den stadigvæk kommunikerer. Er her nogen som har erfaringer med det?
Er her nogen som ved, hvor man finder dokumentation på området?
Hvis ikke PostgreSQL i sig selv er sikkert nok, så er mine muligheder at enten sætte noget VPN op, eller at bruge en SSH portforwarding. Af de to muligheder foretrækker jeg SSH fordi vi allerede bruger SSH til mange andre formål. Men jeg er en lille smule bekymret for problemer hvis en netværksglitch får SSH forbindelsen til at hænge, og jeg aldrig kan være helt sikker på om jeg trygt kan slå en gammel SSH klient ned eller om den stadigvæk kommunikerer. Er her nogen som har erfaringer med det?
#1
Generelt anbefales det ikke at lade databaser være tilgængelige via internet.
De er ikke designet til det og sikkerhedsniveauet må antages at være betydeligt under en web applikation (med et rimeligt design).
Om du vil kalde generel koncensus baseret på den slags antagelser for dokumentation er nok lidt åbent.
Typisk vil man foretrække:
client---(HTTP)---web service----(db protokol)----database
over:
client---(db protokol over sikker tunnel)----database
Måske fordi HTTP er en internet egnet protokol.
Generelt anbefales det ikke at lade databaser være tilgængelige via internet.
De er ikke designet til det og sikkerhedsniveauet må antages at være betydeligt under en web applikation (med et rimeligt design).
Om du vil kalde generel koncensus baseret på den slags antagelser for dokumentation er nok lidt åbent.
Typisk vil man foretrække:
client---(HTTP)---web service----(db protokol)----database
over:
client---(db protokol over sikker tunnel)----database
Måske fordi HTTP er en internet egnet protokol.
Sådan et setup ville introducere meget ny kode og en helt ny angrebsflade.arne_v (2) skrev:Typisk vil man foretrække:
client---(HTTP)---web service----(db protokol)----database
PostgreSQL klienterne og serveren er komponenter i vores eget system og kører på maskiner, som vi selv administrerer. Pt. kører det hele på en enkelt computer. Vi kan bare ikke blive ved med at have resurser nok på en enkelt maskine til at køre alle klienterne samlet.
Jeg har ingen tvivl om at det rigtige valg er at blive ved med at køre PostgreSQL protokollen mellem klient og server, fremfor at indføre en ny protokol til formålet og flere ekstra komponenter, som i sidste ende bare ville være en anden indpakning af SQL forespørgsler og svar.
Spørgsmålet er blot om der er brug for at pakke PostgreSQL kommunikationen ind i noget kryptering, eller om PostgreSQL selv kan håndtere det.
Data i transit bør vel aldrig være andet end krypteret? Ud over det så ville jeg bestemt også gå efter det design arne_v kom med.
Hvis du ikke vil gøre som arne_v og jeg mener du skal gøre er du vel næsten ude i at lave et frontend/backend database setup hvor du bruger frontenden istedet for en web service.
Jeg kan heller ikke finde noget der tyder på at en progres database sender trafik krypteret. Så jeg vil da mene at det sikreste er at gå ud fra at det ikke er tilfældet hvis du da ikke gider finde en tcpdump frem. :)
Hvis du ikke vil gøre som arne_v og jeg mener du skal gøre er du vel næsten ude i at lave et frontend/backend database setup hvor du bruger frontenden istedet for en web service.
Jeg kan heller ikke finde noget der tyder på at en progres database sender trafik krypteret. Så jeg vil da mene at det sikreste er at gå ud fra at det ikke er tilfældet hvis du da ikke gider finde en tcpdump frem. :)
Selvfølgelig skal det være krypteret. Spørgsmålet er blot hvilken kryptering der skal bruges. Kan PostgreSQL selv gøre det (med SSL eller tilsvarende)? Eller skal jeg bruge et andet lag til at sikre kommunikationen (SSH eller VPN)?Hubert (4) skrev:Data i transit bør vel aldrig være andet end krypteret?
Det design indfører en masse ny kompleksitet med nye angrebsflader til følge. Det vil tage tid at implementere, og jeg kan ikke se en eneste fordel ved det.Hubert (4) skrev:Ud over det så ville jeg bestemt også gå efter det design arne_v kom med.
Derimod ville PostgreSQL pakket ind i en SSH tunnel være sikkert og kunne gøres med den software der allerede bruges i systemet. Det eneste problem jeg kan få øje på ved den løsning er hvis SSH forbindelsen fryser efter et netværksudfald.
Jeg gik ud fra at PostgreSQL ikke krypterede som default. Og jeg ville da heller ikke stole på PostgreSQLs egen kryptering uden både at have læst dokumentation af det og kigget på det med tcpdump og wireshark.Hubert (4) skrev:Så jeg vil da mene at det sikreste er at gå ud fra at det ikke er tilfældet hvis du da ikke gider finde en tcpdump frem
Så nu tror jeg spørgsmålet er reduceret til hvorvidt jeg skal bruge SSH eller VPN til indpakning af trafikken. Jeg ender nok med SSH.
Nu hvor jeg fandt nogle lidt bedre søgeord lykkedes det mig at finde frem til at PostgreSQL har SSL support. Så spørgsmålet er så om PostgreSQL over SSL er sikkert nok, og om klient libraryet kan konfigureres til at bruge SSL.kasperd (5) skrev:Kan PostgreSQL selv gøre det (med SSL eller tilsvarende
kasperd (3) skrev:Sådan et setup ville introducere meget ny kode
kasperd (5) skrev:Det vil tage tid at implementere,
Ja. Nogen gange kræver det lidt at lave den rigtige løsning.
kasperd (3) skrev:og en helt ny angrebsflade.
kasperd (5) skrev:Det design indfører en masse ny kompleksitet med nye angrebsflader til følge.
Det fjerner en angrebsflade (PostgreSQL) og tilføjer en angrebsflade (web service).
kasperd (5) skrev:og jeg kan ikke se en eneste fordel ved det.
Der er almindelige programmeringsteknikker og software til rådighed som er beregnet på at beskytte web services.
Databaser har ikke den slags, fordi de er designet til at fungere i sikre miljøer.
kasperd (5) skrev:Derimod ville PostgreSQL pakket ind i en SSH tunnel være sikkert
Hvis du definerer sikkert som at forbindelsen er krypteret: ja. Ellers: nej.
Jeg har fin erfaring med både PostgreSQL og MySQL over SSH-tunnels, og har ikke bemærket den netværksglitch som du nævner.
Men et netværks veje er dog uransagelige, så jeg skal ikke kunne sige hvad der sker hvis den sker. Ville serveren ikke bare droppe klienten ved timeout?
Men et netværks veje er dog uransagelige, så jeg skal ikke kunne sige hvad der sker hvis den sker. Ville serveren ikke bare droppe klienten ved timeout?
Sidebemærkning: Hvis der er betydelig netværkslatency mellem klienter og server, så kan det give en gevaldig performance-lusing, hvis dine klienters logik ofte foretager mange små queries på én gang. E.g. n + 1 queries.
Jeg vil anbefale at holde database og klienter i samme datacenter i så fald.
Jeg vil anbefale at holde database og klienter i samme datacenter i så fald.
PostgreSQL har indbygget support for SSL. Så det må betragtes som standardløsningen. Alt andet er noget man selv strikker sammen, og så er man selv nødt til at sikre sig, at det også virker.Hubert (8) skrev:Ssh >ssl
Den bemærkning kan jeg ikke bruge til noget, hvis ikke den bliver lidt mere konkret.arne_v (9) skrev:Hvis du definerer sikkert som at forbindelsen er krypteret: ja. Ellers: nej.
Hvad mener du med "den netværksglitch"? Har man en TCP forbindelse, hvor der i en periode ikke er netværksforbindelse mellem de to endepunkter, og den ene ende er idle, og den anden ende dropper forbindelsen, så vil forbindelsen blot hænge, når netværksforbindelsen kommer igen.KaW (10) skrev:Jeg har fin erfaring med både PostgreSQL og MySQL over SSH-tunnels, og har ikke bemærket den netværksglitch som du nævner.
Hvis der et sted mellem de to endepunkter er stateful udstyr så som firewall eller NAT, så bliver problemet endnu større. Man kan til dels afhjælpe problemet med TCP keepalive. Det tager lidt tid før det bliver opdaget at forbindelsen er død, og man risikerer at lukke TCP forbindelsen for tidligt såfremt TCP forbindelsen stadigvæk er i live, men netværkset mellem de to endepunkter midlertidigt er afbrudt.
Det er ikke givet at der er et timeout. Og det største problem er ikke om serveren har døde forbindelser hængende, men derimod at man ikke kan åbne en ny portforwarding på den samme port før den gamle er helt død.KaW (10) skrev:Ville serveren ikke bare droppe klienten ved timeout?
Det er jeg klar over, og derfor vil det i første omgang kun være komponenter som udfører batch opgaver, der bliver flyttet på. Interaktive klienter holder vi sammen med databasen så længe som muligt.nielsbuus (11) skrev:Hvis der er betydelig netværkslatency mellem klienter og server, så kan det give en gevaldig performance-lusing, hvis dine klienters logik ofte foretager mange små queries på én gang. E.g. n + 1 queries.
Selvom den kører SSH så vil jeg også anbefale at det er kun bestemte ip-addresser der kan tilgå porten. Så lukker det ned for at uvedkommende der prøver at grave sig ind..
Begrænsninger på IP adresser er ikke praktisk, når der er personer med dynamisk IP adresse, som har brug for adgang. Det er også upraktisk at være afskåret fra at administrere serveren, når der opstår en fejl, mens man ikke er i nærheden af sin sædvanlige netforbindelse.didriksen86 (13) skrev:Selvom den kører SSH så vil jeg også anbefale at det er kun bestemte ip-addresser der kan tilgå porten. Så lukker det ned for at uvedkommende der prøver at grave sig ind..
Så vil jeg hellere begrænse serveren til at kun tillade login med nøgle. Det lyder også bedre sikkerhedsmæssigt end at bruge IP adresse som en del af autentifikationen.
Måden man gør det på er så vidt jeg kan se følgende:kasperd (7) skrev:Det ville også være rart, hvis man kan fortælle klienten hvad serverens public key er i stedet for at basere sig på en CA.
1. Lav mit eget CA certifikat
2. Lav et servercertifikat og signer det med CA certifikatet
3. Lav et klientcertifikat og signer det med CA certifikatet
4. Destruer CA nøglen
5. Placer server certifikat, server nøgle og CA certifikat på serveren
6. Placer client certifikat, client nøgle og CA certifikat på klienten
7. Fortæl server og klient at de skal bruge mit CA certifikat
CN skal indeholde hhv. hostnavn og brugernavn for at det fungerer nemmest.
Selvfølgelig skal der også være autentifikation og integritet af kommunikationen. Både SSH og SSL kan løse den opgave.arne_v (16) skrev:Eksempler på sikkerhedsproblemer som ikke løses ved at kryptere trafikken?
Maskinerne i hver ende af kommunikationen kan sikres på samme måde, man ville sikre den enkelte maskine. Man kommer ikke udenom, at de skal kommunikere med hinanden. Så spørgsmålet er blot, hvad der er den rette måde at gøre det på.
Så vidt jeg kan se står valget mellem enten at bruge SSL, som PostgreSQL har officiel support for, eller at selv finde på sin egen løsning. Der er nogle sikkerhedsmæssige fordele ved at holde sig til standardløsninger.
Antallet af roundtrips er bestemt noget vi kan arbejde på at forbedre. Men omkostningen til ekstra latens har dog vist sig at være mindre end fordelene ved at få nogle tunge beregninger flyttet til en separat host.nielsbuus (11) skrev:Hvis der er betydelig netværkslatency mellem klienter og server, så kan det give en gevaldig performance-lusing, hvis dine klienters logik ofte foretager mange små queries på én gang.
Det var desværre ikke en mulighed. Men på trods af ca. 25ms latens kører det faktisk så godt nu, at latens ikke er vores største problem. Man skal dog tænke over hvor mange databasequeries ny kode foretager, men det har altid været fornuftigt at tænke på.nielsbuus (11) skrev:Jeg vil anbefale at holde database og klienter i samme datacenter i så fald.
kasperd (17) skrev:
Selvfølgelig skal der også være autentifikation og integritet af kommunikationen.
Ja. Men det er stadig kun en ret lille del af database sikkerhed.
kasperd (17) skrev:Maskinerne i hver ende af kommunikationen kan sikres på samme måde, man ville sikre den enkelte maskine. Man kommer ikke udenom, at de skal kommunikere med hinanden. Så spørgsmålet er blot, hvad der er den rette måde at gøre det på.
Ja.
kasperd (17) skrev:Så vidt jeg kan se står valget mellem enten at bruge SSL, som PostgreSQL har officiel support for, eller at selv finde på sin egen løsning.
Hvis du stiller som krav at det skal være en 2 tier løsning.
Det er bare ikke den måde som man gør det på idag og ikke har gjordt det på de sidste 10 år.
Jeg stiller som krav at klient og server, som kører på hver deres computer, skal kunne kommunikere med hinanden. Jeg har kigget tråden igennem igen og ikke fundet noget forslag til en bedre løsning.arne_v (18) skrev:Hvis du stiller som krav at det skal være en 2 tier løsning.
Når kravet er at en SQL klient og en SQL server skal kunne kommunikere, så er en webservice ikke den rigtige løsning. Og webservices står ikke på listen over djangos understøttede database backends.arne_v (20) skrev:Det krav vil en web service jo også klare.
Desuden har jeg svært ved at tage et forslag om at opfinde vores egen sikkerhedsløsning seriøst, når der findes en standardløsning, som er designet præcist til at dække vores krav.
kasperd (21) skrev:Når kravet er at en SQL klient og en SQL server skal kunne kommunikere, så er en webservice ikke den rigtige løsning.
At client og server skal snakke SQL er ikke et "hvad" men et "hvordan".
Det er ikke et krav der skal opfyldes men en måde at opfylde et krav på.
kasperd (21) skrev:Og webservices står ikke på listen over djangos understøttede database backends.
En web service er ikke en database, men man kan godt lave DAL i Django som bruger en web service.
kasperd (21) skrev:Desuden har jeg svært ved at tage et forslag om at opfinde vores egen sikkerhedsløsning seriøst, når der findes en standardløsning, som er designet præcist til at dække vores krav.
Web services eller anden ikke-SQL protokol er standard for database adgang over internet.
Fordi det giver bedre sikkerhed. Og muligvis mere stabil drift.
At forbinde direkte til databasen over internet er en egen løsning udfra nogle berettigede eller uberettigede specifikke grunde.
#22
Med hensyn til sikkerhed skal det dog siges at risikoen ved direkte forbindelse mindskes markant hvis database client er en rimelig sikret server.
Og at der køres Django antyder jo at det er en sådan.
At lade en rigtig klient maskine forbinde direkte til en database server er mange gange mere slemt end en wep applikation som er åben for SQL injection.
Med hensyn til sikkerhed skal det dog siges at risikoen ved direkte forbindelse mindskes markant hvis database client er en rimelig sikret server.
Og at der køres Django antyder jo at det er en sådan.
At lade en rigtig klient maskine forbinde direkte til en database server er mange gange mere slemt end en wep applikation som er åben for SQL injection.
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Software
Gå til bund