Aneks A, deo 22: A.8.24 — Kriptografija

 Dvadeset drugi deo serije o Aneksu A, i prvi posvećen samo jednoj kontroli. Kriptografija zvuči kao tema za velike IT timove, ne za malu firmu — ali u praksi, većina kriptografije koju mala firma treba već postoji u alatima koje verovatno koristi. Pitanje nije da li je graditi, nego da li je ispravno uključiti i upravljati njome.

Šta ova kontrola traži

A.8.24 traži da firma definiše i primeni pravila za efikasno korišćenje kriptografije, uključujući upravljanje kriptografskim ključevima. To se svodi na tri odvojena pitanja:

Kada se koristi kriptografija? Ne mora se primeniti svuda podjednako — odluka treba da bude zasnovana na tome koliko je osetljiv podatak, u skladu sa shemom klasifikacije opisanom u ranijem delu serije. Javni marketinški materijal ne zahteva enkripciju; finansijski podaci klijenata zahtevaju.

Šta se štiti? Kriptografija u praksi radi dve odvojene stvari, i firme ih često mešaju. Enkripcija „u mirovanju" (at rest) štiti podatke dok sede na disku — ako neko fizički ukrade laptop ili spoljni disk, ne može da pročita sadržaj bez ključa. Enkripcija „u prenosu" (in transit) štiti podatke dok putuju, na primer između zaposlenog i cloud platforme — sprečava da neko ko presretne mrežni saobraćaj pročita sadržaj. Obe su potrebne; jedna ne zamenjuje drugu.

Ko upravlja ključevima? Ovo je deo koji se najčešće zanemari. Enkripcija je samo onoliko dobra koliko je dobro upravljanje ključem koji je otključava — loše čuvan ključ čini enkripciju beskorisnom, a izgubljen ključ znači trajno izgubljene podatke.

Zašto je ova kontrola bitna

Najveći mit o kriptografiji kod malih firmi jeste da zahteva izgradnju nečega novog, skupog i tehnički zahtevnog. U praksi, najveći deo kriptografije koju mala firma treba već postoji, ugrađen u alate koje verovatno već koristi — enkripcija diska je ugrađena u svaki moderni operativni sistem, enkripcija u prenosu je podrazumevana kod svake ozbiljne cloud platforme kroz HTTPS. Posao firme retko je da gradi kriptografiju od nule; skoro uvek je da proveri da li je ono što već postoji zaista uključeno, i da smisleno upravlja ključevima.

Primer iz prakse

Enkripcija u mirovanju, korak koji smo već pomenuli: enkripcija diska na laptopovima, pomenuta u delu serije o korisničkim uređajima, jeste direktna primena ove kontrole. Uključena je kroz ugrađenu opciju operativnog sistema, ne kroz poseban, kupljen proizvod.

Enkripcija u prenosu, provera koja je već urađena: kad je agencija proveravala ugovor o nivou usluge sa cloud platformom, u delu serije o odnosima sa dobavljačima, deo te provere odnosio se i na ovo — potvrda da platforma enkriptuje podatke i dok putuju između zaposlenog i servera, i dok sede na serverima dobavljača. Agencija nije morala sama da implementira nijedno od ovoga; morala je samo da proveri da dobavljač to već radi, i da traži pisanu potvrdu.

Upravljanje ključevima, deo koji zahteva stvarnu odluku: kad je enkripcija diska uključena na svim laptopovima, pojavilo se pitanje na koje tehnologija sama ne daje odgovor — gde se čuva rezervni ključ za oporavak, koji je potreban ako neko zaboravi lozinku ili disk zatreba oporaviti? Ako ključ ne postoji nigde osim u glavi jednog zaposlenog, gubitak lozinke znači trajno izgubljene podatke. Ako je ključ previše dostupan, svrha enkripcije nestaje. Agencija je rešila ovo tako što koordinatorka čuva rezervne ključeve za sve uređaje na posebnom, dodatno zaštićenom mestu — odvojeno od uobičajenog sistema za lozinke opisanog u ranijem delu serije, ne u istom fajlu ili alatu gde se čuva sve ostalo. Razdvajanje „ključa koji otključava sve" od običnih pristupnih podataka bila je svesna odluka, ne slučajnost.

Gde se dokumentuje

Kratka tematska politika o kriptografiji dovoljna je za malu firmu — koje vrste podataka zahtevaju enkripciju, na osnovu klasifikacije opisane ranije u seriji, koji alati se koriste za to, i, najvažnije, ko čuva rezervne ključeve i gde. Nema potrebe za detaljnim tehničkim specifikacijama algoritama — to je, za većinu malih firmi, već rešeno kroz izbor pouzdanih, priznatih alata i platformi, ne kroz sopstveno kreiranje kriptografskih rešenja.

Najčešća greška

Najčešća greška je potpuno zanemarivanje ove kontrole jer zvuči previše tehnički za malu firmu, iako je stvarni posao skoro uvek samo provera da li je već ugrađena opcija uključena, ne izgradnja nečega novog. Druga, ozbiljnija greška je enkripcija bez ikakvog plana za upravljanje ključevima — firma uključi enkripciju diska na svim uređajima, ali nikad ne reši pitanje ko čuva rezervni ključ, sve dok se prvi put ne pojavi zaboravljena lozinka i podaci ne postanu nedostupni čak i legitimnom vlasniku. Treća greška je mešanje enkripcije u mirovanju i u prenosu, kao da je jedno dovoljno za oboje — provera cloud dobavljača mora pokriti obe, ne samo jednu.

Šta sledi

Sledeći, poslednji deo cele serije o Aneksu A ide na kontrole A.8.25–8.31 i A.8.34 — bezbedan razvoj softvera. Za knjigovodstvenu agenciju, koja ne razvija sopstveni softver, ovaj deo će biti prilika da pokažemo, slično kao kod A.8.4, kako izgleda grupa kontrola koja se za jednu firmu gotovo u potpunosti isključuje, dok je za drugu, poput softverske agencije iz mini-serije, jedna od najvažnijih u celom Aneksu A.