Als je een programma hebt gemaakt met PHP is het open source, omdat PHP een scripttaal is.
Je kunt het programma aanbieden via SaaS met servers in eigen beheer, zodat de code onbereikbaar is voor klanten.
Maar hoe ga je om met een klant die SaaS On Premise wil?
Wat zijn de opties om het bedrijfsgeheim te borgen, om te voorkomen dat je in een rechtbank belandt?
De "lastig te koppelen" vlieger gaat ook niet helemaal op, daar zijn legio oplossingen voor, zeker met MS Azure (AzureAD, VPN naar locatie, SSO via OIDC provider om er een paar te noemen).
Als het argument "niet goedkoop te koppelen" is zou dat al meer hout snijden.
Los van dit, als dat de wens van de klant is en jij bang bent dat ze met jouw intellectueel eigendom aan de haal gaan zou ik me afvragen of het wel de juiste weg/klant is. Zoals ik al zei, het is een kwestie van vertrouwen dat ze zich aan de gestelde licentie en de wet houden.
Er zijn wel methoden te verzinnen om de database dusdanig weg te stoppen dat uitlezen door een gebruiker/beheerder lastig word maar hierbij moet je je wel afvragen of het dan nog wel zin heeft om het on-prem te draaien.
Je verbergt de hele database, inclusief configuratie en eventueel logging wat het voordeel van data on-site hebben volledig teniet doet.
?
Onbekende gebruiker
03-03-2021 10:26
Inderdaad een hele goede Ozzie, om het de klant zelf te laten benoemen waarom ze graag SaaS On Premise willen, dat heb ik nog niet voldoende helder. Ik heb gegokt naar de meest waarschijnlijke redenen, ze willen integratie met hun eigen loggingstraat om de logging forensisch sluitend te hebben, en ik vermoed dat ze ook graag hebben dat gevoelige gegevens het intranet niet verlaten. Wat ik onderschrijf. Maar het is inderdaad het stukje vertrouwen waar je niet aan ontkomt, dus moet dat gegeven en contractueel geborgd.
En dank Thom, die opties waren nog niet in me opgekomen. Hier heb ik zeker wat aan!
Wat ik me hierna bedacht, zelfs als je root bent op een VPS on premise, moet je voorkomen dat gegevens in verkeerde handen kunnen vallen. Er zijn ook nog encryptie-tools voor linux om bestanden en directories in zijn geheel te versleutelen. https://www.tecmint.com/file-and-disk-encryption-tools-for-linux
Graag gedaan, er is veel mooi cloud en SaaS spul op de markt, sommige dingen zijn alleen nog wat onbekend buiten de Infrastructuur wereld :)
Nog wel een toevoeging op je laatste alinea:
Allemaal leuk en aardig die disk-level encryptie maar alles wat in RAM staat is gewoon onversleuteld.
Als je root access hebt kun je dat heel simpel dumpen naar een bestand en databases hebben de (nare) eigenschap dat ze zo veel mogelijk in RAM cachen.
Dit probleem ondervond ik ook met het opzetten van een Hashicorp Vault instance, de Vault root tokens zijn gewoon uit RAM te dumpen als je root bent op de onderliggende host (VM/VPS).
Dat brengt mij tot het volgende punt:
Root toegang (of eigenlijk alle verhoogde toegang) tot een systeem moet m.i. dan ook "gated" zijn middels bijv. een PAM-tool. Het komt zelden voor dat je daadwerkelijk alle root rechten nodig hebt en áls je verhoogde toegang hebt moet het goedgekeurd worden en traceerbaar zijn.
Maargoed, dan verzanden we in een geheel andere discussie, namelijk infra security.
>> Allemaal leuk en aardig die disk-level encryptie maar alles wat in RAM staat is gewoon onversleuteld.
Ik weet niet of dit bij een server/VPS kan, maar ik ben in de BIOS van een PC wel eens een optie tegengekomen waarmee je RAM onleesbaar kunt maken. Ik heb even geGoogled maar kan het zo snel niet vinden. Het kwam er volgens mij op neer dat de data in het RAM-geheugen 'gescrambled' wordt, waardoor de data als je die zou dumpen compleet onleesbaar is.
Ah ... ik heb toch nog wat gevonden. Mogelijk heet hetgeen ik bedoel TSME. Het lekken van gegevens uit RAM wordt 'rambleed' genoemd.
Intel SGX of AMD SEV werkt helaas (op dit moment) alleen op bare-metal. De hypervisor kan dan zijn RAM wel encrypten maar het RAM in de VM is dan alsnog onversleuteld. Helaas geen oplossing voor een PaaS dus.
Daarnaast is zijn veel Intel CPUs vatbaar voor bijvoorbeeld rowhammer of meltdown/spectre aanvallen dus SGX is niet waterdicht.
?
Onbekende gebruiker
03-03-2021 15:34
gewijzigd op 03-03-2021 16:20
Dus er zijn toch nog meer zaken om rekening mee te houden...
Misschien is het simpelste wel om een dedicated server bij de klant te plaatsen?
Dat biedt dan hardware bescherming tegen RAMBleed, bestandssystemen kunnen niet onderhuids gemount worden, de enige zwakke plek is dan de root toegang via ssh. Ik denk dan aan een gewone LUA-account die sudo kan doen wanneer dat nodig is.
Kan je iets meer toelichten over jouw gedachte over "gated" toegang via PAM?
Oooh! Je bedoelt vast "Priviliged Access Management" (ik dacht aan Pluggable Authentication Module). Ik ga eens goochelen.
En ik om er op dat de root-credentials opgeslagen zijn in een veilige repository. Maar dat zal er eentje zijn van de klant, en dan kan die mogelijk de credentials aan zichzelf toewijzen?
In principe ja maar niet helemaal.
Op het moment van uitrollen van een server is alles misschien goed, maar wat als er volgende week een kritiek lek zit in een softwarepakket?
Wie gaat die lekken bijhouden, de software bijwerken en controleren of alles is gedicht?
Op het moment dat je je met serverconfiguraties gaat bezighouden (infrastructuur dus) open je een totaal nieuw boek, niet alleen een hoofdstuk. Er komt ineens gigantisch veel op je af, te veel om allemaal hier te benoemen.
Daarbij komt dat je dan zeer waarschijnlijk ook de root toegang moet afgeven zodat het door iemand beheerd kan worden.
Infra goed configureren en onderhouden is een fulltime baan en een vak apart, ik spreek uit ervaring. Als je niet bekend bent met het inrichten van enterprise-grade linux systemen zou ik het uitbesteden.
Lang verhaal kort: De makkelijkste weg is om het op eigen, eventueel gehuurde, hardware te zetten bij een van de grote clouddiensten. Dan hoef je zelf niet na te denken over de infra.
?
Onbekende gebruiker
03-03-2021 16:32
Heel erg bedankt voor deze info.
Ik moet er duidelijk nog even op kauwen, want de keuze tussen SaaS On Premise versus traditioneel SaaS (of een mix daarvan) hangt erg samen met in hoeverre de klant te vertrouwen is. Tot nu toe is mijn eigen ervaring dat dat niet altijd het geval is, dus dan heeft volledig SaaS de voorkeur.
Als het om een unieke vondst gaat, kun je die misschien beschermen met een octrooi of patent. Anders is voor software sowieso altijd het auteursrecht van toepassing en eventueel ook het databankrecht wanneer je zelf data verzamelt of verrijkt. Zie:
Als ik het goed begrijp, is de data van je klant maar wil je vooral de structuur van de database beschermen? Of gaat het meer om de PHP-code die de data verwerkt?
?
Onbekende gebruiker
03-03-2021 20:15
Beide. PHP, en qua database de structuur en queries.
Het is meeste is natuurlijk geen rocket science, maar er zitten concepten in die heel logisch lijken, maar die jaren van research en testen in de praktijk achter zich hebben. In een aantal queries zit essentiële (business)logica waaruit iemand die mee kan lezen weet hoe het product werkt, en het daarmee na kan maken.
Dank voor de aanvulling, octrooirecht en databankenrecht hoort er zeker bij. Omdat het concept al een poosje in de praktijk heeft gedraaid is een octrooi niet van toepassing. Het gevaar van octrooien is dat na een periode (was het anderhalf jaar?) als tegenprestatie vindingen gepubliceerd moeten worden, waarna je de bescherming van het bedrijfsgeheim kwijt bent en meer richting juridisch speelveld beweegt.
De uitwerking van een aantal ideeën is uniek, vandaar dat ik uitkom op bedrijfsgeheim.
Ik ging er van uit dat databanken in mijn geval niet van toepassing was, maar het kan geen kwaad de wettekst eens helemaal na te gaan, misschien is er toch nog iets van toepassing.
