Pri licenˇcnem sistemu je zelo pomembno, da varnost sistema ni pod vpraˇsajem, zato sem v sistem implementiral nekaj dodatnih varnostnih ukrepov, ki pripo-morejo k varnosti sistema in poslediˇcno neavtorizirane uporabe programske opreme.
Najbolj osnovni in najlaˇzji varnostni ukrep je obvezna uporaba HTTPS prometa med zaledjem in aplikacijo oziroma spletnim servisom. Naslednji nujen varnostni ukrep je bil ˇsifriranje vseh podatkov, ki se shranjujejo na napravi aplikacije, uporabil sem kriptografsko metodo AES, kljuˇc je definiran v kodi in potem zgoˇsˇcen s funkcijo SHA1 za dodatno varnost.
Veliko potencialno varnostno luknjo predstavlja spreminjanje ˇcasa na na-pravi in s tem neomejeno podaljˇsevanje licence. To teˇzavo sem reˇsil tako, da vsakiˇc, ko uporabnik odpre programsko opremo, si ta zapomni trenutni ˇcas na raˇcunalniku,ˇce se kadarkoli pojavi, da je ˇcas raˇcunalnika manjˇsi kot ˇcas, ki si ga je zapomni pri zadnji uporabi programske opreme, se licenca izbriˇse in uporabnik nima veˇc dostopa do programske opreme, dokler se licenca znova ne preveri s strani zaledja.
Nujen varnostni ukrep je avtorizacija posameznih zahtevkov na API, ˇse posebej ker se vsi zahtevki poˇsiljajo na isti API, tako za dodajanje licenc in
Diplomska naloga 21 tudi potrditev licenc. Avtorizacija poteka prek JWT ˇzetona, ki ga je treba vsako uro obnoviti ali pa na novo zahtevati.
Zaradi same narave licenc je treba te povezati na neko strojno opremo, v nasprotnem primeru bi en licenˇcen kljuˇc lahko licenciral neomejeno ˇstevilo programske opreme na razliˇcnih napravah in s tem praktiˇcno izniˇcil funkcijo celotnega sistema. Naslednji varnostni ukrep, ki ga bom opisal, se navezuje na mreˇzne licence. Ker te niso vezane s strojno opremo, imajo pomanjklji-vost, ker bi bilo moˇzno licencirati neomejeno ˇstevilo naprav, vendar pa je administrator edini, ki lahko nastavi pot do spletnega servisa in tako one-mogoˇci izrabljanje te funkcionalnosti, kljub temu je treba pazit, da uporabi lokalni naslov, v nasprotnem primeru se servis lahko izrabi in poˇsilja licence tudi zunaj svoje mreˇze.
Uporabniˇski vmesnik sam po sebi ne potrebuje veliko zaˇsˇcite, saj morajo vsi podatki skozi zaledje, ki preveri ali je poˇsiljatelj avtoriziran. Kljub temu ima dodatno zaˇsˇcito, ki onemogoˇca uporabniku, da pride do dejanske vsebine spletne aplikacije, ne da bi bila ta avtorizirana.
22 Nejc Kozjek
Poglavje 5
Predstavitev sistema
V tem poglavju bom predstavil uporabniˇski vmesnik in nekaj primerov im-plementacije licenˇcnega sistema.
5.1 Uporabniˇ ski vmesnik
Uporabniˇski vmesnik je razdeljen na ˇstiri glavna obmoˇcja: nadzorna ploˇsˇca, produkti, stranke in administracija. Namenjen je zgolj administratorjem, ki imajo dovoljenje manipulacije z licencami. Celoten vmesnik je prilagojen tudi za mobilne naprave. Ob prihodu na spletno mesto se odpre obrazec za vpis (slika 5.1).
Slika 5.1: Obrazec za vpis v aplikacijo
Uporabniˇski vmesnik je narejen na principu zavihkov, kar pomeni, da se za vsak modul, ki ga uporabnik odpre, naredi nov zavihek: Med zavihki se
23
24 Nejc Kozjek uporabnik lahko premika in jih zapira. Skozi celoten uporabniˇski vmesnik nas spremlja orodna vrstica na desni strani, ki jo po ˇzelji lahko uporabnik tudi skrije (slika 5.2).
Slika 5.2: Orodna vrstica
Po vpisu se uporabniku odpre nadzorna ploˇsˇca, ker vidi ˇstevilo partnerjev, ki imajo aktivne licence, ˇstevilo aktivnih licenc, ˇstevilo licenc, ki ˇse niso bile povezane na strojno opremo, ˇstevilo aktivnih produktov (produkti, ki so vezani na aktivno licenco), potem pa ˇse dve tabeli, ena z aktivnimi licencami in druga z licencami, ki bodo kmalu zapadle. Primer nadzorne ploˇsˇce lahko vidite na sliki 5.3, slika je posneta s tablice.
V obmoˇcju produkti ima uporabnik nadzor nad produkti, prvi je modul produkti. Tu dodajamo nove produkte, jih urejamo, briˇsemo ali pa jim do-dajamo verzije. Zraven modula produkti pa spada v omenjeno obmoˇcje tudi
Diplomska naloga 25
Slika 5.3: Nadzorna ploˇsˇca, na tablici
modul verzije, ki ima skoraj enako funkcionalnost kot verzije v modulu pro-dukti, le da tu verzije niso po grupirane po produktih, ampak so vse v eni tabeli.
Obmoˇcje stranke se deli na dva dela, in sicer partnerje in kontakte. Mo-dul kontakti vsebuje tabelo, kjer lahko uporabnik na partnerja in licenco dodaja kontakte za boljˇso organiziranost. Tu je miˇsljen predvsem scenarij, ko je licenca stranke pred tem, da zapade in ima administrator hiter dostop do kontakta, da lahko stranko opozori na stanje licence. Modul partnerji je najbolj obˇsiren modul celotnega uporabniˇskega sistema, saj zdruˇzuje tri module skupaj. Najprej uporabnik ustvari partnerja oziroma ˇce ta ˇze ob-staja, lahko razˇsiri vrstico v tabeli in odprejo se mu partnerjeve licence, tem mora dodati ˇcas trajanja in v primeru, da gre za mreˇzno licenco, ˇse pot do
26 Nejc Kozjek spletnega servisa. Ponovno je mogoˇce razˇsiriti vrstico z licencami, kjer lahko dodelimo produkte licencam in jim, ˇce to ˇzelimo, nastavimo verzijo. S tem postopkom je licenca dodeljena partnerju, licenˇcni kljuˇc se ustvari sam in je na voljo v vrstici licence.
Obmoˇcje administracija vsebuje modula uporabniki in raˇcunalniˇske speci-fikacije. Modul raˇcunalniˇske specifikacije vsebuje tabelo, ki omogoˇca pregled naprav, ki so se licencirale s sistemom. Modul uporabniki pa omogoˇca do-dajanje in spreminjanje uporabnika. ˇCe ˇzelimo uporabniku spremeniti geslo, se odpre pojavno okno, kjer se mora uporabnik dvakrat vpisati novo geslo.
Sprememba gesla se poˇslje s posebnim klicem na zaledje, ki ga obdela z zgoˇsˇcevalno funkcijo SHA512.
Uporabniˇski vmesnik omogoˇca ˇse nekaj osnovnik funkcij, kot so izpis, iskanje modulov, prav tako je na vseh tabelah mogoˇce grupiranje in filtriranje po stolpcih.
5.2 Implementacija sistema
Za implementacijo sistema v programsko opremo sem izdelal dve knjiˇznici, ena podpira ASP.NET Core, druga pa .NET Framework in dodatno ˇse moˇznost za licenciranje programske opreme, ki ne podpira knjiˇznic, ki so implemen-tirane v sklopu sistema. Dodatno je implementirana tudi aplikacija, ki prek uporabniˇskega vmesnika doda datoteko z licenˇcnim kljuˇcem in doda kontakt na licenco (slika 5.4).
Implementacija mreˇzne licence je s strani programerja popolnoma enaka kot pri klasiˇcnih, razlikuje se le v tem, da mora biti dodatno nameˇsˇcen nekje v omreˇzju spletni servis.
V naslednjih poglavjih bom opisal proces implementiranja licenˇcnega sis-tema v obstojeˇco programsko opremo in nazadnje ˇse specifike licenciranja programske opreme, ki je nameˇsˇcena na napravi, ki se ji specifikacije redno spreminjajo.
Diplomska naloga 27
Slika 5.4: Aplikacija za vnos licenˇcnega kljuˇca in kontakta
5.2.1 Licenciranje namizne aplikacije
Za licenciranje je treba najprej dodati napisano knjiˇznico v projekt. Pa-ziti moramo, da uporabimo verzijo knjiˇznice, ki ima naˇs posodobljen kljuˇc za kriptiranje, v nasprotnem primeru aplikacija ne bo delovala. ˇCe ˇzelimo, lahko preverimo obstoj datoteke LicenceKey.lsc. V primeru, da ta ne ob-staja, pomeni, da licenˇcni kljuˇc ni dodan, v tem primeru ima programer dve moˇznosti, lahko izpiˇse napaka ali pa odpre aplikacijo za vnaˇsanje licenˇcnega kljuˇca, ki je del reˇsitve licenˇcnega sistema. Dejansko pa programer za pri-dobitev licenciranih produktov potrebuje le eno vrstico kode: var output = await LscLicenceManager.GetLicenses(); , enaka funkcija obstaja tudi v sin-hroni obliki. Od pridobitve licenciranih produktov naprej je na programerju, da preveri ali so v licenci res zajeti ustrezni produkti in ustrezno ukrepa, ˇce ti niso.
5.2.2 Licenciranje ERP sistema
V tem podpoglavju bom opisal licenciranje ERP sistema, ki bazira na sple-tnih tehnologijah, licenciral bom zaledje, ki pa bo imelo vpliv na uporabniˇski vmesnik. ERP sistemi imajo po navadi nek sistem pravic, ki definirajo, katere module uporabnik vidi in katerih ne. Ideja za licenciranje ERP sistema je, da prestreˇzemo komunikacijo med podatkovno bazo in zaledjem in prefiltriramo module glede na licence, kar onemogoˇci uporabniku, dodajanje pravic za
mo-28 Nejc Kozjek dul,e za katere nima licence, kot tudi nalaganje samih pravic za te module, ker s strani zaledja ti sploh ne bodo obstajali. Velik problem licenciranja zaledja leˇzi v tem, da ta deluje konstantno in se ga ne zaganja, ko uporabnik odpre spletno aplikacijo. To sem reˇsil tako, da kliˇcem licenˇcni API vsakiˇc, ko se pokliˇce klic za nalaganje modulov, kar pa je ustvarilo nov problem, in sicer sistem se je upoˇcasnil. Obstajala je moˇznost, da module naloˇzim ob zagonu programa, vendar pa bi to pomenilo, da bi tudi v primeru, ko se licenca odvzame stranki, ta lahko ˇse vedno uporablja sistem, dokler se ta ne ugasne, in obratno administrator lahko doda modul stranki, vendar ga ta ne bo mogla uporabljati, dokler se ne ustavi in ponovno priˇzge zaledje. Reˇsitev je bila lokala shramba, vsakiˇc ko uporabnik ˇzeli dostopati do ˇsifranta modu-lov, najprej pogledam, ˇce so ti na voljo v lokalni shrambi, ˇce niso je vse po starem in uporabnik mora ˇcakati malo dlje, ampak v veˇcini primerov se mo-duli nahajajo v lokalni shrambi, kar pomeni, da se ti naloˇzijo s praktiˇcno isto hitrostjo, kot ˇce produkt ne bi bil licenciran. Problem osveˇzevanja licenc pa sem reˇsil tako, da na svoji posebni niti (katere izvedbe ne poˇcakam) izvedem klic, ki poˇslje klic na API in shrani nove podatke o licenci v lokalno shrambo.
Pri implementaciji sem module tretiral kot produkte, vendar se je zapletlo pri licenciranju maksimalnega ˇstevila uporabnikov ERP sistema. Reˇsitev je bil nov produkt, ki mu kot verzijo podam ˇstevilo dovoljenih uporabnikov, v primeru, da ˇstevilo dovoljenih uporabnikov v sistemu presega koliˇcino, ki je navedena v licenci, je uporabnikom onemogoˇcen dostop do sistema.
5.2.3 Licenciranje nepodprte programske opreme
Pri programski opremi, ki je napisana z nepodprtim ogrodjem, naletimo na problem, da ne moremo vkljuˇciti knjiˇznic, ki so na voljo kot del sistema.
Ostaneta nam dve moˇznosti, prva in najboljˇsa je, da implementiramo svojo knjiˇznico, ki podpira programsko opremo, ki jo ˇzelimo licencirati, in druga je, da uporabimo aplikacijo, ki je kot del sistema narejena in podpira opera-cijske sisteme Linux, Windows in macOS. Implementacija licenciranje prek omenjene aplikacije je malce bolj kompleksna in ima veˇcji vpliv na delovanje
Diplomska naloga 29 programske opreme, ki jo licenciramo.
Osnovna ideja je, da programska oprema, ki se ˇzeli licencirati, zaˇzene to aplikacijo in ta ji v standardni izhod vrne JSON objekt vseh produktov.
Samo po sebi je to zelo vpraˇsljiva metoda in ne zagotovi ustreznega nivoja varnosti za produkcijsko okolje, zato programska oprema mora pred zago-nom aplikacije za licenciranje preveriti z zgoˇsˇcevalno funkcijo pristnost apli-kacije. Konˇcano implementacijo lahko s perforamnˇcnega vidika izboljˇsamo tako, aplikacijo za licenciranje naprej zaˇzenemo in med ˇcakanjem na odgovor preverimo pristnost omenjene aplikacije, tako zmanjˇsamo dolˇzino preverjanja licence.
5.2.4 Licenciranje aplikacije v Docker kontejnerju
Licenciranje aplikacije znotraj Docker kontejnerja je bolj kompleksno zaradi dveh razlogov. Prvi je, da je nekako treba spraviti licenˇcni kljuˇc znotraj kontejnerja, to sem storil z uporabo okoljskih spremenljivk in posodobil apli-kacijo tako, da je ob zagonu ustvarila datoteko LicenceKey.lsc. Druga teˇzava je, da se Docker kontejnerju spreminjajo sistemske specifikacije, to je mogoˇce reˇsiti z mreˇzno licenco, ki je nameˇsˇcena zunaj Docker kontejnerja.
30 Nejc Kozjek
Poglavje 6 Zakljuˇ cki
Izdelava licenˇcnega sistema je zahtevna naloga zaradi veliko razlogov. Izpo-stavil bi tri najbolj zahtevne, prvi je dejanska varnost licenc. Velikokrat sem moral zaradi varnosti spremeniti naˇcin licenciranja, kljub temu da je bil naˇcin hitrejˇsi kot konˇcna implementacija. Drugi razlog je imeti minimalni vpliv na programsko opremo, ki bo implementirala licenˇcni sistem, saj se konstantno bori proti varnosti sistema in tudi proti tretjemu razlogu za zahtevnost in to je ˇcim hitrejˇsa posodobitev licenc. Potreba po hitri posodobitvi licenc je povsem odvisna od narave programske opreme, vendar veˇcinoma ne ˇzelimo velike stopnje upoˇcasnitve programske opreme, ko jo integriramo z licenˇcnim sistemom.
Z razvojem licenˇcnega sistema smo dosegeli ˇzeljeni rezultat, funkcional-nost ustreza zastavljenim ciljem, bil sem celo preseneˇcen nad hitrostjo, ki jo ponuja sistem. Za veliko funkcionalnosti sem ˇcrpal navdih iz sorodnih reˇsitev in jih zdruˇzil v eno. Kljub temu ostajajo varnostni pomisleki, ki se jih brez problema odpravi z drugaˇcno implementacijo knjiˇznic za licenciranje programske opreme, sam tega nisem storil, ker je trenutna implementacija veliko hitrejˇsa in dovolj varna, da je ni mogoˇce pretentati zlahka.
Sistem sem testiral na treh namiznih aplikacijah, ERP sistemu in testni Docker aplikaciji, sprva se je pojavilo nekaj problemov, predvsem s strani licenc, ki nimajo dostopa do spleta, in pa dejansko licenciranje ERP sistema
31
32 Nejc Kozjek je zahtevalo veliko poskuˇsanja, da sem implementiral sistem v taki meri, da sem bil zadovoljen z rezultatom.
6.1 Ideje za nadaljnji razvoj
Moˇznosti za nadaljnji razvoj sistema je skoraj neomejeno, ˇce bi hotel podpreti vse najpopularnejˇse tehnologije za razvoj aplikacij, bi ˇze samo to vzelo veliko ˇcasa. Mreˇzne licence so delno implementirane in ne ponujajo tako dobrega nivoja zaˇsˇcite kot klasiˇcne licence, prav tako bi bilo treba mreˇzne licence nadgraditi v tej smeri, da je mogoˇce nastaviti na licenci, koliko uporabnikov lahko na enkrat uporablja programsko opremo.
Ko sem implementiral licenˇcni sistem v ERP, sem dobil dodatno idejo, da bi lahko na produkte uporabnik dodajal neke dinamiˇcne atribute, s katerimi bi programerju, ki implementira sistem v programsko opremo, dodali veliko veˇc manevrskega prostora.
Trenutno je uporabniˇski vmesnik namenjen samo administratorjem, ideja pa je, da se razvije ˇse uporabniˇski vmesnik za stranke, kjer bi lahko pregledali svoje licence, jih podaljˇsali in celo kupili novo.
Literatura
[1] Wikipedia ASP.NET Core. url: https://en.wikipedia.org/wiki/
ASP.NET_Core(pridobljeno 3. 7. 2021).
[2] Wikipedia Denuvo. url: https : / / en . wikipedia . org / wiki / Denuvo (pridobljeno 3. 7. 2021).
[3] Uradna spletna stran lantek. url: https://www.lantek.com/us (pri-dobljeno 3. 7. 2021).
[4] Wikipedia SolidWorks. url: https : / / en . wikipedia . org / wiki / SolidWorks (pridobljeno 3. 7. 2021).
[5] Wikipedia Microsoft SQL Server. url: https://en.wikipedia.org/
wiki/Microsoft_SQL_Server(pridobljeno 3. 7. 2021).
[6] Wikipedia TypeScript.url:https://en.wikipedia.org/wiki/TypeScript (pridobljeno 3. 7. 2021).
[7] Wikipedia Visual Studio. url: https : / / en . wikipedia . org / wiki / Microsoft_Visual_Studio (pridobljeno 3. 7. 2021).
[8] Wikipedia Visual Studio Code. url: https : / / en . wikipedia . org / wiki/Visual_Studio_Code (pridobljeno 3. 7. 2021).
[9] Vue.js vodiˇc.url:https://vuejs.org/v2/guide/(pridobljeno 3. 7. 2021).
33