MySQL tabel uitlezen zonder verbinding

[CB32]

Beste allen,

ik zoek graag bevestiging of er nog onvoorziene haken en ogen zitten aan mijn oplossing voor onderstaand vraagstuk:

• op een vps draait een MySQL server met één database en verschillende tabellen/views voor een niet-publiekelijk toegankelijke webapp (via internet benaderbaar maar alleen login voor medewerkers, HTTPS uiteraard)
• op een aparte (cheap) webhost draait onze publieke website
• één tabel (view) op de VPS bevat informatie die gepresenteerd moet worden op de website
• alle informatie wordt (potentieel) gepresenteerd op de publieke website, de inhoud van de view (of de structuur van de tabel) is dan ook niet geheim
• ik zou de presentatie / selectie graag volledig op de webhost doen
• ik wil de MySQL server niet van buitenaf toegangkelijk maken, zelfs niet met een user die alleen die publieke view kan uitlezen

Ik heb gezocht in de trant van "read mysql table without access" maar ik vindt eigenlijk alleen maar manieren om een gebruiker op te stellen met één view, iets wat ik dus niet wil. Ik dacht aan de volgende oplossing:

• de VPS genereert een (publiek toegangkelijke) dump van de view
• de webhost vraagt deze dump op en voert deze in in zijn eigen database
• verwerking / presentatie van de gegevens kan verder op de webhost gebeuren
• synchronisatie aanmaken via cronjob

De gegevens zijn dynamisch, maar update aan webhost hoogstens één keer per uur is genoeg. Wellicht zelfs één keer per dag of alleen getriggerd.

Ik zie geen probleem in het (potentieel) beschikbaar zijn van de dump, maar wellicht zit ik verkeerd.

Ik hoor graag of iemand op- of aanmerkingen heeft over mijn voorgestelde oplossing.

Groeten uit Uganda,

Christian

[Axewi]

Ik mis de reden dat je de database niet via een connectie toegankelijk wil maken voor je webhost? De data is straks publiekelijk toegankelijk via de webhost.

Elke deftige VPS heeft een ACL, (en anders is er wel één te installeren op je server) is het niet beter\makkelijker om de connectie van de database alleen open te zetten voor het IP van je webhost?
Dit in combinatie met een read only account en een secure database connectie.

Zoals ik het zie ben je nu je probleem aan het verplaatsen, je wilt namelijk geen connectie rechtstreeks naar je database engine, maar je database file\export\synchronisatie via het internet is geen probleem

[CB32]

Axewi schreef op woensdag 13 december 2017 @ 14:13:
Ik mis de reden dat je de database niet via een connectie toegankelijk wil maken voor je webhost? De data is straks publiekelijk toegankelijk via de webhost.

Ik zag het als volgt:

Een verbinding die alleen openstaat voor mijn webhost, is in mijn ogen toch een potentieel risico voor de gehele database. En die gehele database, behalve die view, moet afgeschermd blijven. Het is de hele deur openzetten voor één klein zuchtje wind dat er af en toe door heen moet.

De inhoud van de view wordt plain-text gepresenteerd, dus dan heb ik liever het risico dat dat "lekt" (alleen lekt iets als iedereen de hele inhoud toch al mag zien?) dan dat de hele database lekt.

[steffex]

Je zou kunnen kijken naar een VPN tunnel, maar dat gaat je goedkope webhost waarschijnlijk niet ondersteunen.

Andere oplossing is een API bouwen met oauth o.i.d. voor je database en dat gebruiken om de data te presenteren.

Nog een andere oplossing is een mysql database opzetten op de host en deze als readonly slave instellen voor je prive database. Op die manier zou je master database dan wel data kunnen sturen naar je slave. Echter erg onderhoudsintensieve oplossing.

[Axewi]

CB32 schreef op woensdag 13 december 2017 @ 14:22:
[...]


Ik zag het als volgt:

Een verbinding die alleen openstaat voor mijn webhost, is in mijn ogen toch een potentieel risico voor de gehele database. En die gehele database, behalve die view, moet afgeschermd blijven. Het is de hele deur openzetten voor één klein zuchtje wind dat er af en toe door heen moet.

De inhoud van de view wordt plain-text gepresenteerd, dus dan heb ik liever het risico dat dat "lekt" (alleen lekt iets als iedereen de hele inhoud toch al mag zien?) dan dat de hele database lekt.

Dat maakt het verhaal al iets duidelijker Opzich geen slechte insteek.
Persoonlijk zou ik kijken naar een 2e database instance die alleen de data bevat die je daadwerkelijk wilt tonen, op deze manier kan je die database wel op de voorgestelde manier beschikbaar maken voor je webhost.

Je zou kunnen kijken naar PT table sync

[steffex]

Je kunt ook nog je VPS een export laten maken via een script, bijvoorbeeld als plain text, json of xml en die via een cron laten ftpen naar je host. Daar een script voor de pagina die het dan uitleest. Ervan uitgaan dat je VPS wel een internet connectie heeft.

[CB32]

steffex schreef op woensdag 13 december 2017 @ 14:42:
Je kunt ook nog je VPS een export laten maken via een script, bijvoorbeeld als plain text, json of xml en die via een cron laten ftpen naar je host. Daar een script voor de pagina die het dan uitleest. Ervan uitgaan dat je VPS wel een internet connectie heeft.

Dit is exact wat ik bedoelde als oplossing, wellicht niet zo goed omschreven: één weg verkeer, read only.
De VPS is wel publiekelijk toegankelijk (aan internet), ik bedoelde dat alleen onze medewerkers een login hebben (dus ook weer niet publiekelijk toegankelijk).

(Exact behalve dan dat de webhost de file kan opvragen (want internet) en de file niet gepusht hoeft te worden)

[ Voor 8% gewijzigd door CB32 op 13-12-2017 14:48 ]

[steffex]

CB32 schreef op woensdag 13 december 2017 @ 14:44:
[...]


Dit is exact wat ik bedoelde als oplossing, wellicht niet zo goed omschreven: één weg verkeer, read only.
De VPS is wel publiekelijk toegankelijk (aan internet), ik bedoelde dat alleen onze medewerkers een login hebben (dus ook weer niet publiekelijk toegankelijk).

Ah kijk, nu wordt het wat duidelijker. Dan zou ik in de webapp een API bouwen, die deze data kan ontsluiten. Daarna een implementatie doen op de website waar de data moet verschijnen. Je kunt zelfs een php script publiekelijk maken die de data teruggeeft en die via een php script ophalen.

[MSalters]

Kort gezegd wil je access, maar geen access.

Dat werkt natuurlijk niet. Ja, je kunt workarounds gaan bouwen die zoiets proberen te benaderen, maar de user rights enforcement in fatsoenlijke databases (Postgres, MSSQL, Oracle, etc) is volwassen en breed getest. Zo betrouwbaar krijg je het zelf niet.

Kortom, stap over je aannames heen, en maak een read-only view voor die ene read-only gebruiker.

[CB32]

MSalters schreef op woensdag 13 december 2017 @ 15:01:maar de user rights enforcement in fatsoenlijke databases (Postgres, MSSQL, Oracle, etc) is volwassen en breed getest. Zo betrouwbaar krijg je het zelf niet.

Uiteraard zou ik de data op de VPS uitlezen via een database-gebruiker die alleen bij de view kan, maar nog wel nog steeds lokaal vanaf de VPS. Dat lijken mij nog steeds minder risico's dan een beveiligde SQL verbinding opzetten (?).

[DukeBox]

Zoals eerder genoemd, mooiste is een table sync. Dan geef je alleen read toegang tot je binlog op je source. Op de slave heb je dan de betreffende tabel gewoon beschikbaar.
Via een SSH tunnel naar je source mysql poort is dat verder prima beveiligd.

Anders kan je natuurlijk een simpele export/import maken. De volledige import kan je vanaf je source pushen/schedulen en een remote execute doen.

[ Voor 10% gewijzigd door DukeBox op 13-12-2017 15:40 ]

[Pizzalucht]

Als je zorgt dat:
- de MySQL alleen bereikbaar is vanaf het IP van de publieke VPS
- er een readonly user
- de readonly user alleen een view mag bekijken

Snap ik niet dat je moeilijk wilt gaan doen met een andere oplossing.

De site die niet publiek is heb je ook aan het internet hangen (alleen dan met een login form ervoor), wat mij betreft zit daar een groter risico.

Als je echt geen database verbinding wilt maken zou ik een simpele publieke endpoint maken die de view output als json. Deze kan je dan op de publieke VPS opvragen en uitlezen.

[Ramon]

Ik heb toch altijd geleerd dat je database niet van buiten bereikbaar moet zijn. Je hoeft ook maar één misconfiguratie te doen en je hele database is publiek bereikbaar.

Daarom zou ik een API overwegen, dat kan je imho toch duidelijker configureren wat voor data je wil aanbieden en wie/wat je toegang wilt geven.

[CB32]

Ramon schreef op woensdag 13 december 2017 @ 18:48:
Ik heb toch altijd geleerd dat je database niet van buiten bereikbaar moet zijn. Je hoeft ook maar één misconfiguratie te doen en je hele database is publiek bereikbaar.

Daarom zou ik een API overwegen, dat kan je imho toch duidelijker configureren wat voor data je wil aanbieden en wie/wat je toegang wilt geven.

Bedankt voor deze en andere reacties. Ik ga het volgende doen:

• MySQL gebruiker die alleen leesrechten heeft op de view
• aparte subdomein/virtual host die alleen deze gebruiker kent
• PHP script dat een JSON presenteert van de view
• er zijn maar een bepaald aantal WHERE, en ORDER BY nodig dus deze zal ik via het script laten afhandelen
• [/li]
• webhost raadpleegt de JSON en presenteert gegevens, zonder eerst op te slaan in eigen database

Bedankt!

Ik zie net dat ik een discussietopic heb gestart en geen vraag/antwoord topic. Excuus! Wat mij betreft mag de reactie hier voor aangemerkt worden als oplossing.

[ Voor 8% gewijzigd door CB32 op 14-12-2017 08:12 . Reden: vergeten vraagtopic te maken ]

[DukeBox]

CB32 schreef op donderdag 14 december 2017 @ 08:01:
aparte subdomein/virtual host die alleen deze gebruiker kent

Zou daar dan ook een htaccess op zetten op IP o.i.d. Er op 'gokken' dat deze niet vindbaar is is niet echt een goede beveiliging

[Pizzalucht]

Ramon schreef op woensdag 13 december 2017 @ 18:48:
Ik heb toch altijd geleerd dat je database niet van buiten bereikbaar moet zijn. Je hoeft ook maar één misconfiguratie te doen en je hele database is publiek bereikbaar.

Daarom zou ik een API overwegen, dat kan je imho toch duidelijker configureren wat voor data je wil aanbieden en wie/wat je toegang wilt geven.

Als je hem met een firewall dicht zet zou ik niet zeggen dat hij van buiten bereikbaar is. Zelfs als hij dat door een misconfiguratie wel is dan heb je nog steeds een user login nodig. En stel dat je die dan ook nog weet te bemachtigen dan heb je nog steeds alleen toegang tot een view die al publiek via de website te bekijken is.

Dus je moet 3 misconfiguraties doen om iets echt fout te laten gaan in dit geval.