Adott egy dobozos rendszer (több ügyfélnek szállítjuk ugyanazt, mi találjuk ki, stb.), amely látható forráskódú (pl. PHP). Ez nem is probléma, mert mi üzemeltetjük is. Tipikusan CRM, azaz jó, hogy felhőben van, minden kolléga eléri HTML5 felületen.
A mi felhőnket az ügyfél nem szereti, pedig minden ügyfélnek saját szervere van (VPS+titkosított SSD), saját IP-vel. Nem egy 1GB-os tárhelyen van minden ügyfél közös DB-ben! Ügyfél szeretné, ha saját gépére telepítenénk a szoftvert. Ha a vas ott van az irodában, akkor már nyugodt. 100mbit helyett 8mbit-en fogja kifelé szolgáltatni, de ez neki jó.
Bele is ment, hogy CentOS telepítő lemezzel az ő gépére rakjuk a rendszert, a root password a miénk marad. A kérdés, hogy akár VPS-t ad a saját rendszerében, akár egy fizikai vasat ad nekünk oda: milyen lehetőségei vannak, hogy a rendszerbe belelásson? HDD-t kiveszi és egy másik gépben olvasható, nem? Rescue lemezzel is be tud lépni ROOT-ként egy felhasználóval? Ki is tud minket zárni?
Megoldás lenne még ha a szerver havonta lekérne egy hosszabbító-kulcsot, amellyel tovább megy. De az olvasható PHP jellegű forrás miatt meg tudja ezt is kerülni.
Kerekasztal jellegű ötleteket várok, ha van hozzá kedvetek. Köszönöm!
Hozzászólások
Valami bytecode alapu megoldas?
Egy-ket fizetos esetleg:
* source guardian
* zend guard
* ionCube
+1
Mi lenne, ha az ügyfélnél az alkalmazást tartalmazó (pl.: LVM) kötetet/partíciót LUKS-sal eltitkosítanád? Egy spéci szkript - miután a hálózat elérhető - letölthetné a központból, egy PHP kód által kikeresett kititkosítási kulcsot, és csatolná a kötetet/partíciót.
A kulcs így lehet mindig nálatok, és egy egyszerű LAMP megoldással kezelhető a hozzáférés. Admin felületen pedig szabályozható lenne, hogy az adott ügyfél aktív-e, vagy sem? A megoldás tetszőlegesen kiegészíthető további ellenőrzésekkel is.
Jól megírt szerződés?
+1
Üdv,
Marci
akár VPS-t ad a saját rendszerében, akár egy fizikai vasat ad nekünk oda: milyen lehetőségei vannak, hogy a rendszerbe belelásson?
ha ez komoly kerdes volt, akkor nem csoda, ha nem bizik a ti felhotokben. Eleve o csinal egy virtualis gepet (vagy telepit centos-t a sajat gepere), nem is ertem, hogy gondoltad, hogy nem fog hozzaferni...
Ki is tud minket zárni?
pl. a tuzfalon blokkol titeket, etc...
--
"Pont attól akartam megkímélni magam, hogy gondolkodni kelljen ;)" (lajos22)
Pont emiatt zavaros a kérdés. Mitől gondolja, hogy én nyugodt vagyok ha az ő vasán fut. És mivel annyi ideje nem vagyunk szerződéses viszonyban, hogy hihessen, hogy jó szándékú, sajnos marad a kis félsz és vele együtt a "csak nálunk tud futni" elv.
Thx!
Az ilyen Ügyfelekkel csak a szívás van (tapasztalat), amit tennék a helyetekben:
- Csak nálatok futhat, Ügyfélnék nem és pont!
Valami miatt Titeket választottak, támaszkodj erre.
- Mehet az Ügyfélnél, de ennek az ára pl.: alapár * 5.
Mert ez Nektek plusz feladatot és költséget jelent. Étteremben sem variálhatod a menün lévő ételeket a végtelenségig.
- Jó ügyvéddel egy tuti szerződés, de ebben az esetben is jól megtolt felárral adnám Nekik.
- Vegye meg egyben, szerződésben kikötve, hogy mit tehet vele is mit nem
Nyilván valami durva áron, ahol ez Nektek megéri.
Gyakran, ha kedves Ügyfél lát egy jó kis árat, hirtelen elenged egy rakás dolgot, amihez eddig úgy ragaszkodott.
+1
Ilyen fejlesztővel csak baj van... Ha hülyének, ellenségnek, rosszakarónak tekinti az ügyfelet, akkor jobb helyen megköszönik az ajánlatot, és gyorsan elfelejtik az ilyen "fejlesztőt".
Nem rosszakarónak tekinti az ügyfelet, hanem az ügyfél igények alapján elgondolkozik. Hogy mindkét félnek jó legyen...
A végén pedig kiderül, hogy nincs (hatékony) megoldás, akkor jön a mondat: "Sajnos ilyen termékünk nincs, havi díjas termékek közül tudok Önnek ajánlani."
És ez a mondat igaz, kamutól mentes és hosszútávon is működni fog.
+1 :-]
best customer service award 2015
pedig még csak február van
Ő még itt csak lead és nem customer!
- Minden Ügyfelemet kiemelten megbecsülöm pl.: ha megnézed még a szót is mindig nagybetűvel írom le!
- Nálam bónusz jár a Kollégának és beszállítónak, ha magas az Ügyfél elégedettség.
- Ennek mérésére pedig a Dynamics CRM-et használom (igen, fizetek érte, mert megérdemlik az Ügyfelek, hogy egy profi rendszerben kezeljem a teljes életciklust).
De tudod van olyan, ha nem vagyunk pálya egymásnak (pl.: McDonalds-ban nagyfröccsöt kérsz vagy vega étteremben steak-et => nyilván nem fog menni).
Ilyenkor közös érdekünk, hogy ez minél korábban kiderüljön és ebben az esetben is mindig ajánlok egy másik szolgáltatót, aki jobban megfelelhet számukra.
A kód egy részét phc-val védeni ( http://www.phpcompiler.org/ ), esetleg az egészet...
--
Coding for fun. ;)
"milyen lehetőségei vannak, hogy a rendszerbe belelásson?"
Pont ugyanazok mintha pl. ellopnák a laptopod és kb. pont ugyanazok a védelmek is kellenek ellene.
Pl. a futó rendszeren lévő rootos bohóckodás semmit nem ér ha nincs a diszk/mappa titkosítva (linux live cd boot aztán azt szed le róla amit akar).
De mivel tartósan nála lenne a gép, igazából tökmindegy milyen technikai védelmet használsz az törhető lesz (vagy legalábbis a rendes védelemnek akkora effortja lenne hogy biztos nem vállalnád be meg ő sem).
Innentől kezdve az van amit mások is irtak, vagy nem adod el neki, vagy jogilag alaposan bevédve megfelelő felárral. De ez is csak akkor müködik ha nem nevenincs jóska pista bt/magánszemély stb a vevő hanem egy komolyabb, ellenörizhető cég ahol úgymond feltételezhető hogy nem akarja ellopni a kódodat meg nagyobbat is tud bukni a jogi dolgokon.
Nem is a forráskód, mint érték ellopásáról van szó...
Hanem arról, hogy felfedezi, hogy belelát, elkezd bízni önmagában és belebütyköl: feltölt egy doksit, átnevez egy pontos nevű állományt (ami egy csatolt doksi), "véletlenül" lefuttat egy DELETE parancsot rossz feltételekkel.
És utána mutogatunk egymásra, hogy ki a felelős...
Hasonló feladatot kell éppen megoldanom nekem is, az egyetlen biztos megoldás, ha te adod alá a vasat is, kifelé minden kommunikáció VPN-en, és a szerződésben súlyos szankciók kilátásba helyezése a gép megbontása esetére (szerverek általában logolják).
Ezt megfelelő oprendszer/adatbázis audit logolással oldanám meg.
A probléma itt ugye több rétű. A licencelés csak az egyik probléma, de nem a legfőbb. Tegyük ugyanis fel, hogy az ügyfél rendesen fizet, mert ilyen vagy olyan okból érdeke. Viszont a kihelyezett appliance-ra milyen módon kerülnek ki a szoftverfrissítések és hogyan debuggolod ha probléma van? Az ügyfél kifizetni azt a plusz pénzt amibe Neked kerül üzemeltetni a cuccot?
Egyébként én azt mondanám az ügyfélnek, hogy ok, rendben van, kihelyezünk a Te hálozatodra egy dobozt (pl. HP Mikroszerver), amit mi üzemeltetünk távolról. A doboz árát és az üzemeltetés többletköltségét ki kell fizetni. Értelemszerűen nem szabad elfeledtkezni arról, hogy szükség van backupokra, stb. A merevlemezt meg titkosítani kell, ha reboot van, akkor be kell menni management felületen és el kell indítani, vagy valami hardver kulcsos megoldást kell választani, amit ha felbontja a szerződést, vissza kell adni.
Ez az egész természetsen sokkal drágább lesz mint a hosted megoldás, de ez általában így is szokott lenni. Ha az ügyfél kifizeti, akkor valszeg nem kispályás, kell vele foglalkozni. Ha 10-20e Ft-os havidijakról beszélünk, akkor meg felejtsük el az egészet, használja a hosted megoldást vagy keressen mást.
--
Pásztor János
Üzemeltető Macik
"ha reboot van, akkor be kell menni management felületen és el kell indítani"
Ennel jobb TPM-es measured boot-ot hasznalni, az eleg sok minden ellen ved, amig ra nem mennek logikai analizatorral az LPC buszra, vagy direktben a memoriara. Ha letiltod a firewire portokat es leragasztod a gephazat tamper seal-ekkel, akkor mar eleg maceras hozzaferni.
--
"You're NOT paranoid, we really are out to get you!"