Csak a szükséges adat
Előre tisztázzuk, milyen adat kell, miért kell, meddig marad meg, és mikor törölhető. A kevesebb tárolt adat kisebb kockázat.
03 / BIZTONSÁG · ADATVÉDELEM · HELYREÁLLÍTHATÓSÁG
A biztonságot nem a végén tesszük hozzá.
Egy rendszer csak akkor javít a működésen, ha közben nem növeli a kockázatot. Már a tervezésnél tisztázni kell, milyen adat kerül be, ki fér hozzá, mi legyen visszanézhető, és hogyan áll helyre a munka egy hiba után.
Hozzáférés feladat szerint
Mindenki csak azt lássa és módosíthassa, ami a munkájához szükséges. Az adminisztrátori hozzáférés különösen szűk és ellenőrzött.
Mentés és visszaállítás
Nem elég mentést készíteni. Tudni kell, miből, mikor és hogyan állítható helyre a működés, ha valami elromlik.
Követhető változások
A fontos döntések, állapotváltozások és műveletek legyenek visszanézhetők. Nem megfigyelés miatt, hanem azért, hogy később is egyértelmű legyen, mi történt.
Karbantartott szoftver
A függőségek legyenek ismertek, a rendszer javítható, a biztonsági frissítések pedig rendszeresek. Ami nincs karbantartva, az idővel kockázattá válik.
Rendezett licencek és átadás
A külső komponensek és szolgáltatások felhasználási feltételeit rögzítjük, a projekt átadásakor pedig tisztázzuk a forráskód, az adatok és a felhasználási jogok kereteit.
BIZTONSÁGI ALAPELV
Feltörhetetlen rendszer nincs. A jó védelem viszont megtervezhető.
Nem ígérek feltörhetetlen rendszert. Azt viszont igen, hogy a biztonságot, a hozzáféréseket és a helyreállítást már a tervezésnél végiggondolom.
A pontos követelményeket mindig az adott projekt, az érintett adatok és a ténylegesen alkalmazandó szabályok alapján rögzítjük.MIT JELENT EZ A GYAKORLATBAN?
Az adatbiztonság nálam nem egy lakat ikon.
A cél az, hogy egy fontos kérdésre se az legyen a válasz, hogy „valószínűleg rendben van”. Tudni kell, milyen adat van a rendszerben, ki férhet hozzá, mi változott, és hogyan lehet helyreállni, ha valami elromlik.
Csak az kerül be, amire tényleg szükség van.
Nem gyűjtünk adatot „hátha egyszer kell” alapon. Minél kevesebb felesleges adat van a rendszerben, annál kevesebbet kell védeni.
Nem mindenki fér hozzá mindenhez.
A jogosultságot a feladat és a felelősség határozza meg. Az érzékenyebb vagy adminisztratív hozzáférés külön kezelendő.
A fontos változásoknak marad nyoma.
Ha valami megváltozik, később is érthetőnek kell maradnia, mi történt és mihez kapcsolódott. Ez hiba és vita esetén is érték.
A mentéshez visszaállítási terv is tartozik.
Egy mentés csak akkor ér valamit, ha tudjuk, mire használható. A cél nem a mentés megléte, hanem a működés visszaállíthatósága.
A frissítés nem vakon megy ki.
Egy változtatást ellenőrizni kell, mielőtt valódi adatokra és napi munkára hat. Hibánál pedig számolni kell a biztonságos visszaúttal.
Az átadás után sem maradhatnak homályos határok.
Legyen világos, hol vannak az adatok, milyen külső szolgáltatások vesznek részt, milyen jogosultságok maradnak, és mi tartozik az ügyfélhez.
MILYEN HIBÁKRA KÉSZÜLÜNK?
Nem csak egy támadás okozhat adatvesztést vagy leállást.
A komoly biztonsági problémák egy része hétköznapi helyzetből indul: rossz jogosultság, véletlen törlés, hibás frissítés, elavult komponens vagy egy külső szolgáltatás kiesése.
Illetéktelen hozzáférés
A cél, hogy csak az lásson vagy módosítson adatot, akinek a feladata ezt valóban indokolja.
Véletlen törlés vagy felülírás
A védelemhez nemcsak jogosultság kell, hanem olyan mentési és helyreállítási gondolkodás is, amely hiba után használható.
Hibás frissítés
A változtatást kiadás előtt ellenőrizni kell. Ha valami mégis rosszul viselkedik, a helyreállítás lehetősége már előre fontos szempont.
Elvesző előzmény
A fontos műveletek és döntések követhetősége segít megérteni, mi történt, és gyorsabban megtalálni a hiba valódi okát.
Elavult komponens
A használt összetevőket ismerni és karbantartani kell. Egy régen elfelejtett függőség ugyanúgy kockázattá válhat, mint egy saját programhiba.
Külső szolgáltatás hibája
Ha a rendszer más szolgáltatásra támaszkodik, annak kiesésével is számolni kell. A szükséges hibakezelést a működési kockázathoz igazítjuk.
MIÉRT BÍZHATSZ AZ AXIONA-BAN?
Nem azt kérem, hogy higgy nekem. A rendszernek kell átláthatónak maradnia.
A bizalom számomra nem azt jelenti, hogy sok biztonsági kifejezést írunk egy oldalra. Azt jelenti, hogy a fontos döntéseknek van oka, a hozzáféréseknek van határa, a változtatások ellenőrizhetők, és hiba esetén nem először akkor kezdünk azon gondolkodni, hogyan lehet helyreállni.
A jó biztonság nem láthatatlan varázslat. Olyan rendszer, amelynek a határait és a kockázatait ismerjük.
A biztonság már a rendszerterv része.
Nem a kész szoftver végére kerül néhány beállítás. Az adat, a jogosultság, a visszakövethetőség és a helyreállítás már a tervezésnél kérdés.
Nem ígérek lehetetlent.
Nincs feltörhetetlen rendszer. A reális kockázatok csökkenthetők, a hibák hatása mérsékelhető, a helyreállítás pedig megtervezhető.
A hozzáférés nem kényelmi kérdés.
A jogosultságot mindig ahhoz kell igazítani, hogy kinek mire van valóban szüksége. A túl széles hozzáférés önmagában kockázat.
A helyreállítás ugyanúgy része a védelemnek.
Nemcsak azt nézzük, hogyan előzzük meg a hibát, hanem azt is, hogyan folytatható a munka, ha mégis megtörténik.
A rendszernek később is karbantarthatónak kell maradnia.
A biztonság idővel változik. Ezért fontos, hogy a szoftver frissíthető, javítható és a használt komponensek szempontjából követhető legyen.
Az érzékenyebb adat külön figyelmet kap.
A konkrét technikai és jogi követelményeket mindig az adott projekt, az érintett adatok és a működési kockázat alapján kell meghatározni.