Database encrypten / 'afschermen'?
Ik ben bezig met een eigen CMS. Dit CMS zou op mijn eigen server gaan draaien. De klant logt hier in, en kan zijn website aanpassen via het systeem. Alles wordt weggeschreven naar de database van de klant zelf (op zijn eigen server)
Stel dat een klant na een jaar zegt te willen stoppen met het CMS (ik vraag een bedrag per jaar), dan wil ik niet dat bijvoorbeeld 'het neefje met wat verstand van PHP' een eigen CMS'je zou kunnen bouwen met mijn database.
Dus dacht ik de database te encrypten. Alleen moet de decryptie-functie ook op de server van de klant staan, dus daar schiet ik niets mee op.
Hoe zou ik dit kunnen oplossen? De database is van de klant, ik kan geen wachtwoorden achterhouden.
Alvast bedankt voor het meedenken!
Gewijzigd op 08/02/2012 09:34:50 door P-ter AA
Klant weg is toch site en database weg lijkt mij.
- SanThe - op 08/02/2012 11:09:36:
Ik snap het probleem waarschijnlijk niet.
Klant weg is toch site en database weg lijkt mij.
Klant weg is toch site en database weg lijkt mij.
Nee, de website draait op de server van de klant. Daar heb ik niets over te zeggen. Het enige dat ik kan tegenhouden is het gebruik van het CMS indien de klant niet meer wilt betalen. Ik wil voorkomen dat iemand verder kan boorduren op de bestaande database van de klant (gegenereerd door mijn CMS).
Niet echt zinvol imho.
Quote:
Nee, de website draait op de server van de klant. Daar heb ik niets over te zeggen. Het enige dat ik kan tegenhouden is het gebruik van het CMS indien de klant niet meer wilt betalen.
In dat opzicht kun je dan beter zorgen dat of
a) Het CMS zelf geëncrypt is (Zend Guard bijvoorbeeld) http://www.zend.com/en/products/guard/
b) Het CMS draait op een afgeschermde omgeving in eigen beheer.
Gewijzigd op 08/02/2012 16:57:14 door Maikel Doeze
Maar als de klant stopt met het gebruik van het CMS, zou hij iemand anders een CMS'je kunnen laten maken op basis van de door mij ontworpen database. Maar als alle data ge-encrypt is, kan hij er niets mee.
Pim - op 09/02/2012 14:40:01:
Je kan gewoon op jouw server de html renderen en die dan via PHP FTP uploaden naar de server van de klant. Dan beschikt jouw klant even weinig over jouw code als elke willekeurige bezoeker.
Daar zat ik ook aan te denken.. Maar dan kan een website van de klant nooit dynamisch zijn..
2. Of de database op jouw server hosten en daar de website van de mee laten connecten?
Pim - op 09/02/2012 19:56:17:
Eventueel kan je die dynamische scripts (nieuwsbrief inschrijven ofzo) op je eigen server draaien, maar ik denk dat je heel veel situaties af kan vangen met statische HTML pagina's en eventueel wat javascript.
Kan inderdaad, maar dat wordt wel echt een gedoe als ik meerdere klanten krijg. Alles door elkaar.
Hertog Jan op 09/02/2012 21:21:57:
1. Als je toch CMS op je eigen server hebt staan waarom dan de websites van de klant niet op jouw server?
2. Of de database op jouw server hosten en daar de website van de mee laten connecten?
2. Of de database op jouw server hosten en daar de website van de mee laten connecten?
Zit wat in, maar ik heb geen dedicated server. Maar misschien moet ik dit gewoon overwegen en ben ik inderdaad van dit probleem af.
Het leek mij alleen zo mooi als ik de website van mijn CMS 'los kon koppelen'. Zodat het op zich zelf zou kunnen staan.
Stel je encrypt de html code die je WYSIWYG genereert, en slaat het vervolgens op in de database van de klant.
Bij het uitlezen hiervan (bestand wat nodig is voor de website) decrypt je dit weer. De php code van dit bestand zelf encrypt je met bv zend guard of ioncube.
Zodra de klant geen gebruik meer wil maken van je CMS zal de volledige website blijven werken.
Gerben G op 10/02/2012 19:36:14:
Wat misschien een makkelijkere manier is om de data in de database te encrypten, en niet de hele database.
Stel je encrypt de html code die je WYSIWYG genereert, en slaat het vervolgens op in de database van de klant.
Bij het uitlezen hiervan (bestand wat nodig is voor de website) decrypt je dit weer. De php code van dit bestand zelf encrypt je met bv zend guard of ioncube.
Zodra de klant geen gebruik meer wil maken van je CMS zal de volledige website blijven werken.
Stel je encrypt de html code die je WYSIWYG genereert, en slaat het vervolgens op in de database van de klant.
Bij het uitlezen hiervan (bestand wat nodig is voor de website) decrypt je dit weer. De php code van dit bestand zelf encrypt je met bv zend guard of ioncube.
Zodra de klant geen gebruik meer wil maken van je CMS zal de volledige website blijven werken.
Was niet duidelijk merk ik nu, maar dit is precies wat ik bedoelde inderdaad! Het probleem is alleen dat de 'buurjongen' die encryptie-functie en decryptie-functie ook vindt en in zijn simpele CMS'je kan zetten.
Is dit te voorkomen?
Quote:
De php code van dit bestand zelf encrypt je met bv zend guard of ioncube.
Zoals ik reeds zei: Door de php code zelf te encrypten voorkom je dat.
Jeroen vd op 10/02/2012 20:24:45:
Je kunt zelf een encrypt algoritme maken, of op meerdere manieren encrypten. Of je hasht alle gegevens, en gebruikt een dynamische salt die je opslaat in je eigen db.
Maar als ik die op sla in mijn database, moet het wachtwoord van mijn database in de code staan. En dan kunnen ze nog de salt ophalen..
Gerben G op 10/02/2012 20:42:21:
@Maurice,
Zoals ik reeds zei: Door de php code zelf te encrypten voorkom je dat.
Quote:
De php code van dit bestand zelf encrypt je met bv zend guard of ioncube.
Zoals ik reeds zei: Door de php code zelf te encrypten voorkom je dat.
Maar dan kunnen ze toch ook gewoon de decrypt-functie gebruiken?
Gerben G op 10/02/2012 20:42:21:
@Maurice,
Zoals ik reeds zei: Door de php code zelf te encrypten voorkom je dat.
Quote:
De php code van dit bestand zelf encrypt je met bv zend guard of ioncube.
Zoals ik reeds zei: Door de php code zelf te encrypten voorkom je dat.
Met Zend Guard encrypt je het niet maar doe je het precompilen. Dus wat je dan doet is het werk van de PHP module in apache alvast (de PHP interpeter), die doet je PHP compilen naar bytecode, dus binair. Binaire code is zo goed als onmogelijk terug te draaien naar leesbaar PHP.
Het is een performance winst en beveiliging van je applicatie eigenlijk.
Verder zou ik de data in je database absoluut niet encrypten. Dat is een enorme performance killer. Ik zou het hosten op een eigen server, virtueel eventueel.
Kees Schepers op 10/02/2012 21:26:36:
Met Zend Guard encrypt je het niet maar doe je het precompilen. Dus wat je dan doet is het werk van de PHP module in apache alvast (de PHP interpeter), die doet je PHP compilen naar bytecode, dus binair. Binaire code is zo goed als onmogelijk terug te draaien naar leesbaar PHP.
Het is een performance winst en beveiliging van je applicatie eigenlijk.
Verder zou ik de data in je database absoluut niet encrypten. Dat is een enorme performance killer. Ik zou het hosten op een eigen server, virtueel eventueel.
Gerben G op 10/02/2012 20:42:21:
@Maurice,
Zoals ik reeds zei: Door de php code zelf te encrypten voorkom je dat.
Quote:
De php code van dit bestand zelf encrypt je met bv zend guard of ioncube.
Zoals ik reeds zei: Door de php code zelf te encrypten voorkom je dat.
Met Zend Guard encrypt je het niet maar doe je het precompilen. Dus wat je dan doet is het werk van de PHP module in apache alvast (de PHP interpeter), die doet je PHP compilen naar bytecode, dus binair. Binaire code is zo goed als onmogelijk terug te draaien naar leesbaar PHP.
Het is een performance winst en beveiliging van je applicatie eigenlijk.
Verder zou ik de data in je database absoluut niet encrypten. Dat is een enorme performance killer. Ik zou het hosten op een eigen server, virtueel eventueel.
Oke! Dat is wel een goed idee. Moet me toch maar eens in Zend gaan verdiepen. Bevat Zend misschien ook een functie waarmee het mogelijk is een query uit te voeren op een eerder gedane query? Adobe Coldfusion heeft die mogelijkheid. Zo hoeft de database alleen maar bij de 1e query aangeroepen te worden.
Jeroen vd op 10/02/2012 21:27:05:
Er zijn encrypt methoden die je niet kunt decrypten als je alleen de uitkomst weet
Waar moet ik dan aan denken? Maar als ik de uitkomst al weet, bereik ik er toch niets mee?
Accepteer gewoon je verlies als de klant dat doet, de bug's en dergelijke krijgt de klant op de koop toe. Natuurlijk kan je ook de export functie uitzetten, maar daar maak je geen vrienden mee. En zelfs dan.. is het mogelijk d.m.v. inserts en updates de structuur te kopiëren.
Dus accepteer je verlies en/of laat de klant een contract tekenen waarin de klant verklaard database structuren en programmatuur nooit te zullen kopiëren.
Eddy Bisschops op 11/02/2012 01:58:45:
Waarom moet de database perse op de server staan van de klant? Ik zelf hou de database in eigen beheer en geef de klant daarvan de inloggegevens. Natuurlijk kan de klant een export uitdraaien, maar goed.. dat risico loop je. Daarnaast is een database structuur over het algemeen makkelijk in elkaar te flansen, met bijv. varchar(2000) op elk veld.
Accepteer gewoon je verlies als de klant dat doet, de bug's en dergelijke krijgt de klant op de koop toe. Natuurlijk kan je ook de export functie uitzetten, maar daar maak je geen vrienden mee. En zelfs dan.. is het mogelijk d.m.v. inserts en updates de structuur te kopiëren.
Dus accepteer je verlies en/of laat de klant een contract tekenen waarin de klant verklaard database structuren en programmatuur nooit te zullen kopiëren.
Accepteer gewoon je verlies als de klant dat doet, de bug's en dergelijke krijgt de klant op de koop toe. Natuurlijk kan je ook de export functie uitzetten, maar daar maak je geen vrienden mee. En zelfs dan.. is het mogelijk d.m.v. inserts en updates de structuur te kopiëren.
Dus accepteer je verlies en/of laat de klant een contract tekenen waarin de klant verklaard database structuren en programmatuur nooit te zullen kopiëren.
Ik denk dat ik dit dan maar moet doen inderdaad.
Iedereen heel erg bedankt! Fijn dat er zo wordt meegedacht. Ik ga me eens verdiepen in Zend en ga accepteer het als een klant dingen zou willen overnemen. Indien ik de klante tevreden hou is dit natuurlijk allemaal niet nodig.