Egyedi hitelesítési és biztonsági megoldások tervezése és fejlesztése

Egyedi biztonság magánprojektekhez

Az Egyedi biztonság akkor kell, ha egy online felületnél nem elég az alap belépés, az egyszerű jelszó és a kézzel kezelt jogosultság. A magánügyfél ilyenkor olyan online szakembert keres, aki távolról átnézi a működést, rendbe teszi a hozzáféréseket, és érthető szabályokat épít a rendszerbe. Nem minden feladat nagy fejlesztés. Néha elég egy biztonságosabb belépési folyamat, egy szerepkör alapján működő jogosultsági szint, vagy egy jobb adatkezelési rend.

Én azt látom, hogy a legtöbb kérés mögött nem elméleti biztonsági igény áll, hanem egy konkrét félelem. Valaki nem szeretné, hogy idegenek lássák a privát tartalmakat. Más attól tart, hogy egy korábbi segítő, felhasználó vagy partner még mindig hozzáfér valamihez. Egy harmadik ügyfél csak azt szeretné, hogy a saját kis online rendszere ne omoljon össze egy hibás beállítás miatt. A Qjob.hu felületén ilyen megbízáshoz magánszakembert lehet keresni, aki nem helyszíni jelenlétre épít, hanem távoli egyeztetésre, pontos feladatleírásra és ellenőrizhető eredményre.

Az egyedi hitelesítés nem csak belépési képernyőt jelent. Ide tartozhat a jelszó visszaállítása, a kétlépcsős azonosítás, az ideiglenes hozzáférés, a felhasználói szerepkör, a munkamenet kezelése és a hozzáférési napló. Szerintem a jó biztonsági fejlesztés nem akkor jó, ha bonyolultnak látszik. Akkor jó, ha az ügyfél érti, ki mit lát, ki mit módosíthat, és mi történik hibás belépésnél.

Biztonsági fejlesztés célja

A biztonsági fejlesztés célja, hogy a magánprojektben lévő adatokhoz csak az férjen hozzá, akinek valóban kell. Ez lehet családi használatú webes felület, kisebb foglalási rendszer, ügyfélkapus megoldás, privát tartalomtár, tanfolyami oldal vagy egy saját alkalmazás. A lényeg ugyanaz. A belépés, a jogosultság és az adatmozgás legyen átlátható.

Sokan ott hibáznak, hogy először minden funkciót meg akarnak építeni, és csak később gondolnak a védelemre. Ez később drágább. Ha a hozzáférésvédelem már az elején szerepel a leírásban, a szakember könnyebben választ jó megoldást. Nem kell utólag szétszedni a felületet. Nem kell mentett adatokat javítani. És nem lesz olyan helyzet, hogy egy vendég felhasználó véletlenül szerkesztési jogot kap.

Tapasztalatom szerint a magánügyfeleknek nem hosszú biztonsági előadásra van szükségük. Nekik működő döntési pontok kellenek. Ki lehet belépett felhasználó. Kell-e külön tulajdonosi fiók. Mennyi ideig maradjon aktív egy bejelentkezés. Mi legyen, ha valaki elfelejti a jelszavát. Hogyan kapjon a megrendelő jelzést gyanús eseményről. Ezek egyszerű kérdéseknek tűnnek, de a rendszer minőségét erősen befolyásolják.

Egyedi biztonság ára

Az Egyedi biztonság ára főleg attól függ, hogy meglévő rendszert kell javítani, vagy új hozzáférési rendet kell felépíteni. Egy rövid ellenőrzés lehet néhány órás munka. Egy összetettebb egyedi hitelesítés már tervezést, kódmódosítást, próbát és átadási leírást is kér. A túl olcsó munka ezen a területen gyakran gyengébb minőséget jelent, mert a láthatatlan részek maradnak ki. Ilyen a hibakezelés, a naplózás, a visszaállítás és a jogosultságok tesztelése.

Az alábbi összegek távoli munkára, kisebb és közepes magánprojektekre adnak reális támpontot. Nem végleges árlista, mert a régi kód állapota sokat számít. Egy tiszta rendszer gyorsabban javítható. Egy rendezetlen rendszerben előbb fel kell térképezni, mi mihez kapcsolódik.

A díj akkor marad ésszerű, ha a megbízás határai tiszták. Más árat kap egy belépési hiba javítása, és mást egy teljes jogosultsági rendszer átalakítása. Én óvatos lennék azzal az ajánlattal, amely már az első üzenetben mindent fixen ígér, de nem kér hozzáférési képet, folyamatleírást vagy tesztelési igényt.

Biztonsági szakember kiválasztása

Biztonsági szakember választásakor nem csak az számít, hogy tud-e kódot írni. Fontosabb, hogy tud-e kérdezni. Egy jó szakember először megérti, milyen adatot kell védeni, hányféle felhasználó van, milyen eszközről lépnek be, és mi számít kockázatos helyzetnek. Aki rögtön kész megoldást ajánl, de nem kérdez rá a használatra, könnyen rossz irányba viszi a munkát.

A portfólió hasznos, de ezen a területen nem mindig látványos. Egy biztonsági fejlesztő munkája sokszor pont attól jó, hogy a felhasználó nem vesz észre belőle semmit, csak azt, hogy a rendszer stabilabb és kiszámíthatóbb. Érdemes korábbi példát kérni, de nem kell bizalmas adatokat látni. Elég, ha a szakember el tudja mondani, milyen problémát oldott meg, milyen korlátokkal dolgozott, és hogyan ellenőrizte a végeredményt.

Szerintem a legjobb jel az, ha a kivitelező nem ijesztget, hanem rendez. Nem használ feleslegesen nagy szavakat. Nem ígér teljes védelmet. Inkább leírja, melyik kockázatot kezeli most, mi marad későbbre, és milyen döntést kell meghoznia a megrendelőnek. Egy magánügyfélnek ez sokkal többet ér, mint egy hosszú, nehezen érthető szakmai lista.

Egyedi hitelesítés előkészítése

Az egyedi hitelesítés előkészítéséhez rövid, de pontos leírás kell. Le kell írni, kik használják a felületet, hogyan kapnak hozzáférést, van-e ideiglenes vendég, és mi történjen a jogosultság megszűnésekor. Hasznos képernyőképet küldeni a belépésről, a felhasználói beállításokról és minden olyan pontról, ahol adat látható vagy módosítható. A jelszót nem kell üzenetben elküldeni. A hozzáférést inkább külön, ideiglenes módon érdemes megadni.

Volt olyan eset, amikor egy ügyfél azt kérte, hogy csak a jelszó visszaállítását javítsák. A rövid átnézés közben kiderült, hogy a régi meghívó hivatkozások soha nem jártak le. Ez azt jelentette, hogy egy hónapokkal korábban elküldött hivatkozással még mindig be lehetett lépni. A javítás végül nem lett sokkal drágább, de teljesen más lett a feladat. Nem csak egy gomb működését kellett javítani, hanem a hozzáférési szabályt is.

A jó előkészítés nem hosszú dokumentum. Egy oldal is elég lehet. A fontos az, hogy a szakember lássa a szerepeket, a folyamatot és a kockázatot. Így nem találgatásból dolgozik. És az ügyfél is könnyebben ellenőrzi, hogy a megoldás tényleg azt adja, amit kért.

Hozzáférésvédelem munkamenete

A hozzáférésvédelem távoli munkamenete általában egyeztetéssel indul. Az ügyfél elküldi a rövid leírást, a szakember visszakérdez, majd meghatározzák a pontos feladatot. Ezután jön a hozzáférés biztosítása, a mentés ellenőrzése, a módosítás, a próba és az átadás. Jó esetben minden fontos döntés írásban marad. Ez csökkenti a félreértést.

A kommunikáció legyen egyszerű. Nem kell egész nap hívásban ülni. Elég a rövid üzenet, a képernyőkép, a próbára adott visszajelzés és a határidő. Egy kisebb javítás akár egy munkanapon belül lezárható. Egy összetettebb jogosultsági rend több napot is kérhet, főleg akkor, ha több felhasználói szerep van. A fejlesztő ilyenkor nem csak megírja a módosítást, hanem végigpróbálja a tipikus helyzeteket is.

Az átadásnál fontos, hogy ne csak a kész eredmény érkezzen meg. Kell rövid leírás arról, mi változott, hogyan lehet új felhasználót adni, hol lehet jogot visszavonni, és mire kell figyelni későbbi módosításnál. Ha a biztonsági fejlesztés csak a készítő fejében létezik, az ügyfél később kiszolgáltatott lesz. Ez nem jó munkamód.

Gyakori hibák a biztonsági fejlesztésnél

A leggyakoribb hiba az, hogy az ügyfél csak a látható belépési részt nézi. Pedig a valódi gond sokszor a háttérben van. Régi felhasználók maradnak aktívak. Túl széles jogosultságot kap egy segítő. Nincs napló arról, ki módosított valamit. A jelszó visszaállítása ugyan működik, de túl könnyen kérhető. Ezek nem mindig látványos hibák, mégis komoly zavart okozhatnak.

Másik gyakori gond a túl bonyolult elvárás. Minden egyes művelethez külön szabályt kérni elsőre alaposnak tűnik, de kis projektnél nehezen fenntartható. Tapasztalatom szerint jobb a kevés, de érthető szerepkör. Tulajdonos, szerkesztő, olvasó. Vagy aktív és lezárt fiók. A túl sok kivétel később hibát termel.

Az Egyedi biztonság akkor lesz hasznos, ha nem ijedtségből készül, hanem átgondolt szabályok alapján. A biztonság nem egyszeri dísz a felület szélén. Inkább rend a belépésben, rend a jogosultságban és rend az átadásban. Egy magánügyfélnek ez ad nyugalmat. Nem az, hogy a rendszer bonyolult. Hanem az, hogy érthető, ellenőrizhető és javítható marad.