Złośliwy dostawca usług hostingowych może zrobić dużo więcej niż tylko ukraść Twój kod. Mogą go zmodyfikować, aby wprowadzić backdoory, mogą ukraść dane Twoich klientów i zrujnować cały Twój biznes. Między tobą a hostem musi istnieć zaufanie.

Informacje o kodzie źródłowym. Jeśli osoba atakująca próbuje uzyskać dostęp do Twojego kodu źródłowego, uzyska dostęp do Twojego kodu źródłowego, zaciemnionego lub nie, skompilowanego lub zinterpretowanego.

Jest / em> wartość w zaciemnianiu kodu, ponieważ prawdopodobnie sprawisz, że będzie on tylko trochę trudniejszy do uzyskania przez okazjonalnego oportunistycznego atakującego. Ale jeśli Twój host chce cię dopaść, dopadną cię.

Rozwiązanie? Prawo. Podpisz z nimi umowę i zaakceptuj jakąś formę NDA.

Cóż, wymaga to trzech komentarzy:

• Nie można chronić tajemnic za pomocą zaciemniania kodu. Nie naprawdę . Maskowanie kodu w jakiś sposób działa przeciwko niemotywowanym napastnikom, ale nie jest mocne. Jeśli przebicie się przez to ma wartość komercyjną, tak się stanie.

• Jeśli nie ufasz swojej usłudze hostingowej, poszukaj innej usługi hostingowej. Jeśli tajność twojego kodu jest ważna i warta więcej niż kilkaset dolarów, powinieneś użyć własnego sprzętu: wynajmujesz wydzieloną przestrzeń wnęki z zamkami i osłonami i uruchamiasz w niej własną maszynę.

• Twój kod istnieje jako skompilowany (bajtowy) kod na serwerach, ale także jako kod źródłowy w twoich systemach programistycznych oraz w głowach twoich programistów. Nie może być tym tajemnicą. Jak mówią, milion dolarów zawsze wystarczy, aby odkryć sekrety, choćby przez przekupienie jednej z osób, które zostały ujawnione.

  (W tym ostatnim przypadku może to być twój plan: ty możesz chcieć, aby jakiś większy konkurent po prostu Cię wykupił.)

Ochrona przed inżynierią wsteczną i kradzieżą Twojej własności intelektualnej jest zwykle zapewniana za pomocą środków prawnych, a nie technicznych.

Nie, to nie jest tego warte. Nikt nie chce ukraść Twojego kodu. Tysiąc milionów produktów SaaS zostało uruchomionych przez osoby i firmy korzystające z hostingu stron trzecich o takim czy innym opisie i prawie żaden z nich nie okazał się konkurować ze sobą po tym, jak kod ich produktów został skradziony przez hosta.

Więc czy powinieneś zaciemniać swój kod? Jasne, jeśli to sprawi, że poczujesz się lepiej. Żadna krzywda. Czy chronisz swoje IP przed ważnym zagrożeniem? Nie, nie bardzo. To rodzaj kapelusza z folii aluminiowej w wersji dla programistów internetowych.

Cokolwiek robisz, nie trać dużo czasu i energii na myślenie o tym. Podejmij decyzję o zaciemnieniu lub nie, a następnie przejdź do martwienia się o łagodzenie prawdziwych zagrożeń.

Ostatecznie jesteś jedyną osobą, która może dokonać oceny ryzyka. Jeśli będziesz spać lepiej, zaciemniając swój kod, zrób to.

Osobiście nie zawracałbym sobie głowy. Renomowane usługi hostingowe działają w branży hostingu, a nie w branży kradzieży kodu źródłowego. Jeśli ukradną Twój kod, nadal będą musieli go zainstalować, sprzedać usługę, znaleźć klientów i odeprzeć pozew, który wytoczysz przeciwko nim. To dla nich zbyt duży wysiłek, zbyt duże ryzyko za zbyt małą nagrodę.

Maskowanie jest nieskuteczne wobec zdeterminowanego napastnika, a jedynie nieco utrudnia. Jeśli masz konkretny powód, aby nie ufać dostawcy usług hostingowych, zdobądź inny.

Jeśli chcesz tylko być bezpieczny, uzyskaj umowę o zachowaniu poufności i inne gwarancje prawne, które pozwolą Ci ścigać gospodarza, jeśli coś nadużywa.

Jeśli nadal nie ufasz im nawet przy tych zapewnieniach prawnych, zdobądź dedykowane serwery, które możesz kontrolować i szyfrować tak, aby dostawca hostingu nie miał dostępu do danych, chyba że włamują się do serwera operacyjnego.

Jeśli martwisz się, że ktoś ma fizyczny dostęp do twoich serwerów, skonfiguruj własne centrum danych lub fizycznie zamknij je w obudowie w kolokowanym obiekcie z monitoringiem fizycznego mienia.

Samo skorzystanie z umowy o zachowaniu poufności powinno wystarczyć z każdym renomowanym dostawcą usług hostingowych.

Nie zawracałbym sobie głowy.

Z dwóch powodów:

Języki interpretowane w czasie wykonywania naprawdę nie mogą być w ten sposób w pełni chronione. Aby całkowicie go zaciemnić, musiałbyś go również zaciemnić z poziomu środowiska wykonawczego, wtedy nie byłoby sposobu, aby go wykonać. Zaciemnienie sprawia, że ​​zadanie jest nieco bardziej irytujące. Może również sprawić, że debugowanie i wdrażanie będzie bardziej czasochłonne dla twojego personelu.

Bardzo niewiele aplikacji zawiera rodzaj tajnego kodu sosu, którego ludzie naprawdę zadaliby sobie tyle trudu, aby ukraść. O wiele łatwiej jest po prostu uzyskać listę funkcji i niektórych wykonawców i powiedzieć „zrób coś takiego”, niż kopiować funkcję po funkcji w większości popularnych aplikacji.

Powinieneś podjąć środki ostrożności, aby się chronić, ale nie z powodów lub przed zagrożeniem, które sobie wyobrażasz.

Po pierwsze, jeśli nie możesz zaufać dostawcy usług hostingowych, uzyskać nowego dostawcę usług hostingowych . Nie trzeba już o tym mówić.

Po drugie, nawet jeśli uważasz, że własność intelektualna w zbudowanej przez Ciebie aplikacji internetowej jest cenna, są szanse, że jesteś tylko jeden. Czy ukradłbyś witrynę konkurencji? Prawdopodobnie nie; nie byłoby to warte zachodu. Z reguły ludzie nie są zainteresowani kradzieżą Twojej witryny. Zwykle koszt dostosowania witryny innej osoby do własnych potrzeb jest zbliżony lub przekracza koszt jej samodzielnego zbudowania.

Wreszcie, powinieneś martwić się, że hakerzy pobiorą Twój kod i użyją go do zaatakowania Ciebie. Zapisane hasła, bazy danych użytkowników, błędy programistyczne i luki w zabezpieczeniach - Twój kod prawdopodobnie stanowi atrakcyjny cel dla złośliwych atakujących . Jest to szczególnie ważne, jeśli Twój kod jest źle napisany lub Twoja usługa jest popularna.

Maskowanie kodu nie jest rozwiązaniem i i tak nie pomoże. Ale dobre praktyki bezpieczeństwa, w tym przestrzeganie zasady najniższych przywilejów, powinny ci pomóc. Oddziel swój dostęp, aby narażenie jednego systemu lub komponentu nie zapewniło atakującemu całej aplikacji w zgrabnym małym pakiecie. Im bardziej niezależne i odłączone są elementy Twojej firmy, tym mniej osoba atakująca może złapać za jednym zamachem.

Mam wiele aplikacji internetowych hostowanych online. Jakiś kod jest cenny, tak. Jednak nie zaciemniłem żadnego z nich, ponieważ nawet jeśli zostanie skradziony, nikt inny nie może go utrzymać. W końcu wyciągną włosy. Wypróbowałem to z kimś, kto bardzo chciał mojego oprogramowania. Nie mógł go zainstalować, zrozumieć ani nic z tego wyciągnąć, więc w jaki sposób mógłby znaleźć klientów i sprzedawać, jak wspomniano powyżej.

Wartość tkwi w danych i wsparciu, które dajesz i utrzymanie zadowolenia klienta.

Wszystkie moje aplikacje komputerowe mogą zostać zdekompilowane w taki czy inny sposób. Myślę, że VB6 był jedynym, którego nie można było zdekompilować. Nikt nie mógł ich konserwować, ponieważ używam skomplikowanego kodowania i skomplikowanych nazw zmiennych.

Próba zaciemnienia kodu po stronie klienta nie ma żadnych zalet w zakresie bezpieczeństwa. Wystarczająco zdeterminowany atakujący będzie ominąć wszelkie metody zaciemniania, które mu rzucisz.

Jeśli kod jest naprawdę ważny, pozostaw go po stronie biznesowej. Rozważ każdy kod po stronie klienta jako publiczny i dostępny dla każdego.

Jeśli nie ufasz swojemu dostawcy usług hostingowych, że nie wykradnie Twoich danych, powinieneś poszukać bardziej wiarygodnego dostawcy usług hostingowych lub samemu hostować.

Nie powierzasz im tylko kodu programu, powierzasz również wszystkie twoje dane i dane wszystkich twoich użytkowników. Kiedy zakładasz, że Twój dostawca usług hostingowych jest na tyle złośliwy, aby ukraść Twój program, jest on również na tyle złośliwy, aby ukraść Twoje dane użytkownika i sprzedać je licytantowi oferującemu najwyższą cenę. Dane, które prawdopodobnie obiecałeś chronić w ramach polityki prywatności.

Kiedy dojdziesz do wniosku, że nie ufasz żadnemu dostawcy usług hostingowych, ale samodzielny hosting jest zbyt drogi, możesz kupić własny serwer fizyczny i niech ktoś inny go hostuje, ale 1. w pełni zaszyfruj system plików, aby nie mógł klonować dysków twardych podczas konserwacji, i 2. upewnij się, że cała komunikacja sieciowa jest szyfrowana, aby nie mogli podsłuchiwać ruchu.

Świat jest do góry nogami, prawdziwej wartości zwykle nie ma w kodzie aplikacji. To w danych klienta kod jest używany do gromadzenia / modyfikowania. W wielu aplikacjach internetowych kod jest zabezpieczony, a dane są często przechowywane w postaci zwykłego tekstu bez żadnej prostej ochrony. Jest to jeden z problemów, które PCI DSS, HIPAA i inne standardy bezpieczeństwa danych mają rozwiązać.

Zakładając, że Twój dostawca hostingu jest złośliwy, uzyskanie dostępu do danych klientów znacznie szybciej zniszczy Twoją firmę niż zdobycie kodu.

Oprócz kwestii bezpieczeństwa poprzez zaciemnienie, zaciemnianie kodu może również powodować problemy z bezpieczeństwem i będzie musiało zostać sprawdzone na tym samym lub wyższym poziomie, co zwykła baza kodu.

Nie

Oczywiście: planujesz zainwestować czas w tak zwaną technologię zabezpieczenia przez zaciemnienie .

To nie jest dobry pomysł!

Aby chronić swój pomysł przed licencjonowaniem przez osoby trzecie, możesz opublikować je na takiej publicznej licencji, jak GNU GPL, creative commons lub inne.

Maskowanie nigdy nie ukrywa ani nie zmienia twojego kodu, po prostu modyfikuje go do innego formatu, w którym może go przetwarzać,

Np .: jeśli chcesz zaciemnić nazwę swojej klasy Moja strona główna, moja strona zostanie zmieniona na M4Page Podobnie jak metoda of addWidgets () zostanie nazwane w innym, a nazwa funkcji może również zostać zmieniona, a nie Functionality Więc jeśli chcę wywołać metodę z twojego zaciemnionego kodu, mogę ją łatwo zaimplementować ...

Nie możesz wystarczająco zaciemnić kodu lub danych, aby były bezpieczne. Gdybyś był w stanie, twój kod i dane byłyby bezużyteczne nawet dla ciebie.

Bezpieczeństwo poprzez ukrywanie działa tylko tak długo, jak długo tajemnica twojego zaciemniania pozostaje nienaruszona. Sekrety nigdy nie pozostają tajemnicą. To jest podstawa większości systemów praw cyfrowych i jak dotąd wszystkie z nich zostały złamane.

Z bardziej technicznego punktu widzenia, jeśli używasz języka interpretowanego (Perl, PHP) lub interpretowanego przez kod bajtowy język (Java), rozważ użycie dla nich dołączonych natywnych narzędzi do kompilacji. Wiele takich języków wysokiego poziomu zawiera narzędzie do generowania wersji C / C ++ twoich skryptów lub kompilacji natywnie dla twojego sprzętu. Posiadanie wersji skompilowanej natywnie eliminuje potrzebę utrzymywania drzewa źródeł na zdalnych serwerach, a także zapewnia znaczny wzrost wydajności.

Bezpieczeństwo dzięki niejasności nie jest złe, jeśli nie jest to jedyna rzecz, na której możesz polegać. Używanie zaciemniania do ochrony kodu nie zadziała, ale używanie zaciemniania z innymi licencjami nie jest złe.