Connectie tussen 2 servers

[klepje]

Beste tweakers,

Wij zijn bezig met het ontwikkelen van een applicatie in PHP. Deze applicatie willen wij op één centrale server zetten, zodat we het maar op één plaats hoeven aan te passen.

Nu willen we de applicatie verbinding laten leggen met databases en websites op externe servers, maar dit moet wel veilig gebeuren doordat het te maken heeft met persoonlijke data.

De situatie:
De applicatie wordt weergegeven op een website (op de externe server). Op de website worden gegevens ingevoerd, deze gegevens worden bewerkt door de applicatie op de centrale server en deze worden dan doorgestuurd naar de database op de externe server.

Voorbeeld:

BTW: De verbinding gaat alleen tussen Hosting en centrale server, dus niet van Hosting 1, naar Centrale server, naar Hosting 2

Is deze verbinding tussen applicatie en externe hosting op een veilige manier mogelijk?
Zo ja, wat is hiervoor nodig?

Edit: Wat we willen is dat de PHP scripts alleen op onze server staat, dit omdat de webmasters de PHP code anders kunnen inzien/aanpassen. Dit willen wij graag voorkomen.

Met vriendelijke groet,
Klepje

PS: weet niet of het in de goede categorie staat, misschien moet het bij Internet & Netwerken?

[ Voor 7% gewijzigd door klepje op 20-11-2012 19:33 . Reden: Stukje toegevoegd ]

[Woy]

Een en ander is natuurlijk nogal afhankelijk van hoe de infrastructuur in elkaar steekt, maar er is natuurlijk van alles mogelijk. De makkelijkste manier lijkt me om gewoon gebruik te maken van HTTPS ( Eventueel in een combinatie met zowel client en server certificates ) of VPN om je verbindingen tot stand te brengen.

Maar als het echt om persoonlijke data gaat dan zou ik niet zelf een oplossing proberen te bedenken ( Al dan niet met hulp van het internet ). Als je niet al ervaring met dergelijke dingen hebt is het natuurlijk wachten totdat je een foutje maakt en de gegevens op straat liggen.

[ Voor 30% gewijzigd door Woy op 20-11-2012 19:09 ]

[klepje]

De centrale server zal ook gewoon een hostingpakket zijn. Het idee is voor de handigheid zodat we de php applicatie niet op elke server hoeven te zetten en het niet overal hoeven aan te passen. Maar daarnaast is het ook zo dat er zo geen wijzigingen kunnen worden gedaan in de PHP bestanden, wat wel zou kunnen als het op de externe servers zou staan.

[Freeaqingme]

Maar het deployen van je applicatie automatiseer je toch gewoon? Veel te risicovol anders...

[klepje]

Freeaqingme schreef op dinsdag 20 november 2012 @ 19:13:
Maar het deployen van je applicatie automatiseer je toch gewoon? Veel te risicovol anders...

Wat wij willen (als daar een goede mogelijkheid voor is) is dat de webmasters bij ons een account krijgen en dat zij dan onze applicatie in hun site kunnen verwerken.

Er zal dus eigenlijk maar één applicatie zijn, en die staat op onze server. Maar nu is het de vraag of dit op een veilige manier mogelijk is.

[IStealYourGun]

Ik vermoed dat hosting A & B en Centrale server op verschillende locaties staan en niet virtueel?

Er zijn verschillende oplossingen (onder linux). De goedkoopste kwa bandwidth is dat je alles gewoon synced met een cronjob. Afhankelijk hoe groot de applicatie is kan je die om het kwartier laten draaien. Je hebt dan wel nog steeds een "lag" van max 15 minuten. Als het een zeer kleine applicatie is en weinig data dan kan je dat eventueel om de 5 minuten of zelfs 1 minuut laten draaien.

Mapen van een folder over ssh of iSCSI zou ook een oplossing kunnen zijn, in dat geval wordt je applicatie server gewoon een fileserver. Nadeel is dat er meer bandwidth wordt verstookt en dat er wat lag zal ontstaan. Ook heb je dan meer spf's.

[ Voor 9% gewijzigd door IStealYourGun op 20-11-2012 19:24 ]

[klepje]

IStealYourGun schreef op dinsdag 20 november 2012 @ 19:23:
De goedkoopste kwa bandwidth is dat je alles gewoon synced met een cronjob.

Mapen van een folder over ssh of iSCSI zou ook een oplossing kunnen zijn, in dat geval wordt je applicatie server gewoon een fileserver.

Daar zat ik inderdaad ook aan te denken. Helaas heb je dan wel op elke server de applicatie draaien, wat we het liefst niet hebben i.v.m. de webmasters die de PHP code dan kunnen inzien/aanpassen.

Ik had die reden niet in de topicstart gezet, maar ik zal het er even bijzetten.

[Noork]

klepje schreef op dinsdag 20 november 2012 @ 19:30:
[...]


Daar zat ik inderdaad ook aan te denken. Helaas heb je dan wel op elke server de applicatie draaien, wat we het liefst niet hebben i.v.m. de webmasters die de PHP code dan kunnen inzien/aanpassen.

Ik had die reden niet in de topicstart gezet, maar ik zal het er even bijzetten.

Goed user management?

[klepje]

Noork schreef op dinsdag 20 november 2012 @ 19:32:
[...]

Goed user management?

Door te syncen komen de bestanden op de servers van die webmasters te staan, dus daar kun je dan geen user management voor gebruiken. Aangezien de webmasters dan gewoon bij de PHP bestanden kunnen komen en de bestanden kunnen aanpassen.

[Freeaqingme]

Ik krijg heel sterk het idee dat je een oplossing bedacht hebt voor een probleem, aan ons vraagt hoe je die oplossing kan implementeren, terwijl de oplossing allicht niet je onderliggende probleem niet oplost.

Misschien zou je kunnen vertellen wat voor applicatie je hebt, wat voor gebruikers je hebt (webmasters?), wat ze moeten doen met die applicatie, wat voor wie afgescheiden dient te worden en wat de constraints additionele wensen zijn tav je hosting omgeving?

[IStealYourGun]

klepje schreef op dinsdag 20 november 2012 @ 19:30:
[...]


Daar zat ik inderdaad ook aan te denken. Helaas heb je dan wel op elke server de applicatie draaien, wat we het liefst niet hebben i.v.m. de webmasters die de PHP code dan kunnen inzien/aanpassen.

Ik had die reden niet in de topicstart gezet, maar ik zal het er even bijzetten.

M.a.w je wil gewoon de output van de applicatie naar de webservers sturen? In dat geval moet je gewoon reverse proxy toepassen. Beetje vreemde opstelling, maar perfect mogelijk. Normaal gebruiken ze dat om load te verdelen. Jij doet het omgekeerde. De load centraliseren en de toegangspunten verdeel je.

[Gomez12]

Idd, proxy of iframe of webservices of ... of ... Eigenlijk kan je van alles verzinnen. Zolang het principe maar is dat je enkel data uitwisselt en geen programmacode. De programmacode mag de klant dan zelf maken voor zijn situatie.

Of alternatief : Jij regelt het hosting account voor de klant, klant mag overal een hoster uitzoeken. Maar jij maakt de account aan en jij hebt root-ww. De klant zelf heeft dan enkel lees-rechten over de php-bestanden (en dat zou geen barst uit moeten maken, anders heb je hele andere problemen op hele andere vlakken)

[klepje]

IStealYourGun schreef op dinsdag 20 november 2012 @ 19:46:
[...]

M.a.w je wil gewoon de output van de applicatie naar de webservers sturen?

Dat is inderdaad ongeveer onze bedoeling, maar het gaat ons dan ook vooral om het veilig verzenden van die output naar de webservers. Of dat mogelijk is of dat we beter een alternatief kunnen gebruiken.

---

Gomez12 schreef op dinsdag 20 november 2012 @ 20:03:
Of alternatief : Jij regelt het hosting account voor de klant, klant mag overal een hoster uitzoeken. Maar jij maakt de account aan en jij hebt root-ww.

Bedankt, aan dat alternatief hadden we inderdaad nog niet gedacht . Maar ik weet niet of iedereen dat op prijs stelt, maar dat zouden we dan even uit moeten zoeken.

---

Freeaqingme schreef op dinsdag 20 november 2012 @ 19:43:
Ik krijg heel sterk het idee dat je een oplossing bedacht hebt voor een probleem, aan ons vraagt hoe je die oplossing kan implementeren, terwijl de oplossing allicht niet je onderliggende probleem niet oplost.

Misschien zou je kunnen vertellen wat voor applicatie je hebt, wat voor gebruikers je hebt (webmasters?), wat ze moeten doen met die applicatie, wat voor wie afgescheiden dient te worden en wat de constraints additionele wensen zijn tav je hosting omgeving?

Het is inderdaad al een soort oplossing, daarom was onze vraag of het op een veilige manier mogelijk was en hoe. Ook staan wij natuurlijk open voor alternatieven.

Onze "eisen" daarbij zijn dus eigenlijk:

• Veilige data transport
• Bestanden niet op externe webserver, maar alleen op eigen server

De gebruikers van onze applicatie zijn beheerders van websites. De data die wordt verstuurd via die sites gaat via onze applicatie naar hun eigen databases. En de data vanuit hun database gaat via onze applicatie naar de sites. (Oftewel heen- en terugverkeer)

[PatrickH89]

Een webservice klinkt in dit geval als de beste oplossing (bijv. REST of SOAP).

[kwaakvaak_v2]

of te wel een webservice met een locale cache. Ik zou zeggen verdiep je eens in het REST protocol. Voordeel is het gaat gewoon over http of https als je een certificaat koopt. Je kunt per client een API key inbouwen als je dat wilt, en dus ook gelijk je licenties op die manier aftikken.

[klepje]

Ik heb me even verdiept in het REST protocol en zag dat je inderdaad ook een SSL certificaat nodig hebt als je de verbinding beveiligd wilt hebben. Nu was ik in gesprek met iemand van Verisign en die zei dat ik dan op alle servers SSL moet zetten, dus de server waar de applicatie op draait en alle websites die daarmee communiceren.

Daarom denk ik dat ik ga zoeken naar een alternatief. En daarbij is het idee van Gomez12 een optie. Hebben jullie misschien nog andere alternatieven, waarbij veiligheid van gegevens van belang is en de applicatie beveiligd is tegen aanpassen?

[Styxxy]

Wat is het probleem met SSL? Je wilt iets veilig maken, maar je wilt zowat het gemakkelijkste niet doen omdat dan SSL "geïnstalleerd" moet worden op de servers. Neen, laten we in plaats daarvan gigantisch complexe constructies verzinnen...

[klepje]

Styxxy schreef op woensdag 21 november 2012 @ 00:11:
Wat is het probleem met SSL? Je wilt iets veilig maken, maar je wilt zowat het gemakkelijkste niet doen omdat dan SSL "geïnstalleerd" moet worden op de servers. Neen, laten we in plaats daarvan gigantisch complexe constructies verzinnen...

Het gaat erom dat je dan moet verplichten dat de webmasters van de sites die je applicatie gebruiken een SSL certificaat moeten aanschaffen.

[HyperioN]

klepje schreef op woensdag 21 november 2012 @ 00:09:
Ik heb me even verdiept in het REST protocol en zag dat je inderdaad ook een SSL certificaat nodig hebt als je de verbinding beveiligd wilt hebben. Nu was ik in gesprek met iemand van Verisign en die zei dat ik dan op alle servers SSL moet zetten, dus de server waar de applicatie op draait en alle websites die daarmee communiceren.

En waarom is dat een probleem?

[klepje]

HyperioN schreef op woensdag 21 november 2012 @ 00:15:
[...]
En waarom is dat een probleem?

Zie hierboven, omdat je dan alle webmasters die gebruik maken van je applicatie moet verplichten om een SSL certificaat te nemen.

[8088]

Dat is toch niet zo'n gekke eis als je met persoonlijke data werkt? Bovendien heb je ze al voor een tientje. Of zelfs gratis.

[Gomez12]

klepje schreef op woensdag 21 november 2012 @ 00:09:
Daarom denk ik dat ik ga zoeken naar een alternatief. En daarbij is het idee van Gomez12 een optie. Hebben jullie misschien nog andere alternatieven, waarbij veiligheid van gegevens van belang is en de applicatie beveiligd is tegen aanpassen?

Het was zeg maar niet echt een serieus alternatief hoor...

Ik bedoel als ik iets meer als een wordpress of een joomla website heb draaien wil ik al snel root-toegang om mijn eigen zooi te kunnen draaien op die server, krijg ik die root-toegang niet dan is het enkel maar een extra black box waar nog steeds mee gecommuniceerd moet worden.

Maar als je toch bereidt bent om kosten voor de klant te maken, wat is dan het probleem met de mindere kosten voor een ssl-certificaat? Die kosten kan je dan toch ook gewoon dragen?

Maar eigenlijk zou ik je zo onderhand eens aanraden om gewoon een externe partij oid erbij te halen, want jij hebt er geen kaas van gegeten en jij zit je enkel maar blind te staren op jouw manier die niet wenselijk is.

Simpel voorbeeldje van hosting waar je niet vrolijk van gaat worden : Wat zijn de kosten voor het verspreiden van alle php-files en het maintainen van die externe hosting-contractjes? Als jij root hebt dan kan namelijk de klant die bak niet maintainen, dus dat mogen jullie gaan doen.

[kwaakvaak_v2]

Sterker nog, als je met persoonlijke data werkt die ingevoerd of verstuurd wordt en je gebruikt dan geen SSL kun je wat mij betreft je applicatie direct afschrijven. Als je gaat bezuinigen op iets simpel en basaals als een certificaat van een paar tientjes per jaar ben je gewoon erg dom en vooral onverantwoord bezig.

[IStealYourGun]

Je kan natuurlijk ook zelf self-signed certificates uitschrijven.

[Carharttguy]

Dus als ik het goed begijp:

-Draai jij een PHP applicatie op jouw webserver
-Draaien andere webmasters jouw andere PHP applicatie op hun eigen webserver
-Wil jij communicatie tussen die 2 appliacties
-En wil jij niet dat die webmasters jouw raw PHP code kunnen lezen?

Dat lijkt me een lastige constructie. Waarom draai je gewoon die PHP applicatie (voor de webmasters) op jouw eigen server, en geef je aan die webmasters een HTML pagina met daarin een iframe die linked aan jouw PHPapplicatie?

Je geeft jouw PHP code niet weg, je draait alles centraal dus is makkelijker te beheren (updates uitrollen?) en jij kan gewoon een SSL certificaat nemen, en al je gebruikers (webmasters) hebben daar geen last van omdat die SSL gewoon door die iframe draait.

[Observer]

Wat doet die PHP applicatie? Maakt die 1) een webpagina of 2) levert die alleen data die je klanten kunnen gebruiken in hun website? In beide gevallen zul je een manier van authenitcatie/authorisatie moeten verzorgen (Oauth bijvoorbeeld) om te zorgen dat niet iedereen de data in kan zien.

Indien 1)
Laad je applicatie in een iframe in de andere website. Dat heeft als bijkomend voordeel dat als jouw PHP applicatie problemen heeft, je de andere sites niet perse onbruikbaar maakt. Ik weet niet zeker of de pagina waarin de iframe zit dan ook via https moet werken als je de PHP applicatie onder https host.

Indien 2)
Maak er een webservice van (via REST, SOAP is onnodige overhead IMHO). Documenteer de API goed en laat de klanten zelf een client schrijven. Of lever er zelf een (als alle klanten PHP gebruiken), het enige wat die client hoeft te doen is HTTP calls en misschien wat responses parsen, dat is niet iets wat je hoeft te "beschermen", zeker niet als je standaard oplossingen gebruikt (bv. JSON, XML). En als je klant rare dingen gaat doen revoke je z'n authorisatie gewoon.

[Tarilo]

We hebben echt meer informatie nodig om zinnige oplossingen aan te dragen.

Ik zie in de TS nergens beschreven staan wat het daadwerkelijke probleem nu is. Er staat alleen een oplossing omschreven, die blijkbaar niet werkt in zijn huidige vorm(verbinding is niet veilig).

Als we wat meer uitleg zouden hebben over het daadwerkelijke probleem, zou dat een stuk helpen. Waarom moet er bijv. via een omweg met de applicatie gewerkt worden? kan dat niet rechtstreeks? En waarom is het zo belangrijk dat de php code niet bekend mag zijn bij de externe hosting? Veiligheid, auteursrecht? En wat is de reden om de databases extern te hebben? Kosten, veiligheid?

[Hydra]

kwaakvaak_v2 schreef op woensdag 21 november 2012 @ 08:51:
Sterker nog, als je met persoonlijke data werkt die ingevoerd of verstuurd wordt en je gebruikt dan geen SSL kun je wat mij betreft je applicatie direct afschrijven.

Volgens de wet bescherming persoonsgegevens artikel 13: "De verantwoordelijke legt passende technische en organisatorische maatregelen ten uitvoer om persoonsgegevens te beveiligen tegen verlies of tegen enige vorm van onrechtmatige verwerking."

Nu wordt niet expliciet gezegd wat "passende technische" maatregelen zijn, maar iets simpels als SSL is wel een minimum me dunkt. Daarnaast is het denk ik een goed idee dat de TS zelf die tekst even doorleest (ook het stukje over toestemming verlenen) en dit eventueel ook even onder de aandacht brengt van "het management". Er zijn al teveel Hyves-klonen die maar een beetje aanmodderen met persoonsgegevens onder het mom van "je zet het zelf op internet".

[Miyamoto]

klepje schreef op dinsdag 20 november 2012 @ 18:27:
Edit: Wat we willen is dat de PHP scripts alleen op onze server staat, dit omdat de webmasters de PHP code anders kunnen inzien/aanpassen. Dit willen wij graag voorkomen.

Wat is nu het initiele probleem? Het versturen van data tussen verschillende servers of het niet openbaar maken van je broncode? Voor dat laatste zijn er PHP encoders, like Ioncube. Is zover ik weet redelijk standaard aanwezig bij alle webhosts. Als je dat bovendien als 'systeemeis' vermeld, is er niks aan de hand lijkt me.

[Janoz]

Volgens mij wordt er hier ontiegelijk moeilijk gedaan vanwege een hypotetisch probleem dat afnemers mogelijk code gaan aanpassen of 'stelen'. Als oplossing wordt er vervolgens iets voorgesteld wat een enorme impact heeft op performance en security en wat vervolgens ook nog een berg complexiteit toevoegd. Om eerlijk te zijn denk ik dat, gezien een SSL certificaat aanschaffen blijkbaar al een hobbel schijnt te zijn, jullie organisatie helemaal niet klaar is voor een dergelijke complexe implementatie.

Je hebt twee mogelijkheden. Alles bij jezelf neerzetten (dus ook de data) of het probleem op juridische wijze afbakenen.

[Hydra]

Janoz schreef op woensdag 21 november 2012 @ 14:27:
Je hebt twee mogelijkheden. Alles bij jezelf neerzetten (dus ook de data) of het probleem op juridische wijze afbakenen.

Nou nee, een VPN tussen de omgevingen is ook gewoon een optie. Ik ben het er mee eens dat het een vrij complexe oplossing is, maar ik ken de applicatie verder niet en zonder die goed te kennen vind ik ook dat 'wij' niet dergelijke uitspraken moeten doen.

Er kunnen veel goede redenen zijn om alle data centraal te willen hebben, niet in de laatste plaats voor rapportage, maar die redenen kennen wij op dit moment misschien niet.

[Tarilo]

Janoz schreef op woensdag 21 november 2012 @ 14:27:
Volgens mij wordt er hier ontiegelijk moeilijk gedaan vanwege een hypotetisch probleem dat afnemers mogelijk code gaan aanpassen of 'stelen'. Als oplossing wordt er vervolgens iets voorgesteld wat een enorme impact heeft op performance en security en wat vervolgens ook nog een berg complexiteit toevoegd. Om eerlijk te zijn denk ik dat, gezien een SSL certificaat aanschaffen blijkbaar al een hobbel schijnt te zijn, jullie organisatie helemaal niet klaar is voor een dergelijke complexe implementatie.

Je hebt twee mogelijkheden. Alles bij jezelf neerzetten (dus ook de data) of het probleem op juridische wijze afbakenen.

QFT! Ik heb ook het idee dat dit het probleem is. Alleen is dit geen oplossing voor het probleem, dat moet juridish gedaan worden.

Hydra schreef op woensdag 21 november 2012 @ 14:55:
[...]


Nou nee, een VPN tussen de omgevingen is ook gewoon een optie. Ik ben het er mee eens dat het een vrij complexe oplossing is, maar ik ken de applicatie verder niet en zonder die goed te kennen vind ik ook dat 'wij' niet dergelijke uitspraken moeten doen.

Er kunnen veel goede redenen zijn om alle data centraal te willen hebben, niet in de laatste plaats voor rapportage, maar die redenen kennen wij op dit moment misschien niet.

Het punt is nu juist dat de applicatie centraal staat, maar de data niet. Deze wordt overal en nergens extern geplaatst. Als ik het plaatje goed interperteer...

[Hydra]

Tarilo schreef op woensdag 21 november 2012 @ 15:02:
Het punt is nu juist dat de applicatie centraal staat, maar de data niet. Deze wordt overal en nergens extern geplaatst. Als ik het plaatje goed interperteer...

Ah, oops. Nevermind

[TheNephilim]

Zend Guard is altijd nog een mogelijkheid hè

Mijn idee van je probleem; je hebt een applicatie gemaakt.
- Je wil je applicatie verkopen aan verschillende klanten.
- Je wil je applicatie niet rauw op de host van de klant zetten, omdat ze de code dan kunnen stelen.
- Je wil makkelijk updates uit kunnen rollen bij alle klanten zonder één voor één alle klanten langs te gaan.

Wat je in deze situatie vaak ziet, is dat jij de hosting regelt voor die klant. Daarbij haal je de applicatie specifieke bestanden uit één bron, de database/config file/static/etc zijn per klant verschillend.

Alle andere mogelijkheden vergen sowieso een boel gezeur, omdat elke klant een andere hosting omgeving heeft en je per klant updates zal moeten uitrollen. Oplossingen zoals Zend Guard kunnen je code eventueel wel veilig stellen, maar daarmee stel je meteen weer eisen aan de hosting van de klant.

[Gomez12]

Hoe is het geregeld dat jullie wel bij de data van de klanten mogen komen?

Ik bedoel je bent bang dat je klanten je php gaan kopieren, maar hoe is het geregeld dat jullie niet de data van de klant kopieren?

Situatie 2 lijkt mij eigenlijk belangrijker dan situatie 1.

Worst case scenario 1 is dat je 1 klant voor de rechter moet gaan dagen vanwege contractbreuk etc.
Worst case scenario 2 is dat al je klanten je voor de rechter slepen.

Heb je scenario 2 afgedicht dan kan je toch dezelfde constructie gebruiken voor scenario 1, of zie ik het verkeerd?