Kde su podla teba hranice sifrovania databaz? Kde sa maju sifrovat a naopak kde sa sifrovat nemaju?
Tak nebezpecne je to miesto, kde data su ulozene (cize sifrovanie at-rest) a transport (cize in-transit - od https, az po VPN/ipsec) - toto dnes ma kazdy dobry cloud.
Co sa tyka pristupov, tak tam je jasne, ze do produkcie by mal mat pristup len limitovany pocet ludi, ak to je vobec nutne, nejake logovanie/audit, pripadne zabezpecene procesy, aby tam nemohol nikto robit nieco len tak ked si zmysli. Na toto su rozne certifikacie, ktore public cloudy uz dost dlho maju.
Najslabsie miesto je z pravidla aj tak vzdy clovek alebo aplikacna vrstva web<->app<->db. A s tym ti cloudy velmi nepomozu.
Aky typ dat/zaznamov by mal byt sifrovany?
Kde vidis slabe miesto pri vyuziti apex-u (aplikacna vrstva) a autonomnej db v autonomnom private cloude u zakaznika?
z pohladu bezpecnosti na toto musi odpovedat bezpecnostny projekt. Zoberme si priklad toho co sa udialo na MV, pracovnik co mal opravnenie robit lustracie ju urobil na niekoho koho nemal. IT moze v idealnom pripade skontrolovat ci dana osoba je v spise a zapisat do logu ze sa spravila, ale to ci to bolo v sulade so zakonom, to dokaze urcit az kontrola. A to je organizacne opatrenie, nie uloha IT. Sifrovanie v tomto pripade nehra ziadnu rolu.
Slabe miesto tejto hrozby je teda samotny pristup, to co sa este da spravit je sledovat nestandartne spravanie, napriklad to ze niekoho vlozis do spisu a potom ho vymazes. Taketo spravanie by malo ist automaticky na kontrolu. A kontrola by mala byt nezavisla, idealne ina organizacia, ktora ale nema mat pristup k datam.
Vacsina hrozieb je od vnutornych ludi a to ziaden cloud nevyriesi, ani private ani public. Lenze zase cim viac bezpecnosti, tym tazsia prevadzka a platis za to efektivitou prace. Spravna hranica nie je jasne urcitelna, ale extremy na obe strany nie su dobre, ani heslo admina by nemalo byt na nastenke ani by na opravu chyb v datach nemusel davat povolenie NBU 
alebo dozorna rada.
Na svetlo vysiel pripad, ked lustroval pracovnik cez frontend. Ale kolko lustracii sa udialo cez backend/DB bez vedomia ministerstva? Kolko dat odislo z ministerstva dodavatelom ako testovacie data?
Toto asi nikto nevie a to su vacsie hrozby ako tie uniky, ktore sa daju aspon odhalit.
Dost pochybujem ze niekto lustroval cez backend, ale samozrejme o tom neviem nic a teda teoreticky mohol. Ale krcmove reci skor naznacuju ze ide o beznu prax policajtov, naco by to to niekto robil zlozito cez IT ? Aj v tomto pripade ak by to slo tak lahko, tak by prezident riesil cez nich, nie cez frontend.
Ak sa na to pozrieme ako na teoreticky priklad, tak bezpecnostna analyza by zrejme ukazala ze najvacsia slabina su ludia a kontrola, az ked zaplatas tuto dieru, tak ma zmysel ist dalej. A az niekde v dialke je potom SIEM. Do bezpecnosti sa da naliat penazi kolko len chces, s klesajucim vynosom.
A len tak na okraj, ta lustracia aj tak dala udaje, ktore by najaty detektiv zistil za par hodin. Adresu, cislo auta, dopravne priestupky. Ano, nechceme aby toto boli verejne udaje ale zdravotne udaje a pohyby na ucte su podla o mna o rad citlivejsie. A este stale nehovorime o tajnych informaciach.
Najznamejsi pripad zneuzitia beckendu bola kauza odpocuvanie.
Logovnie frontendu nie je velmi presne, nakolko nezriedka jedno heslo pouzivaju viaceri. ( v praxi vsak akontak funguje)
Prax ale ukazuje, ze nemame obrazne strazcov krori strazia strazcov (napr.db adminov). Na tom je potrebne popracovat.
A kedze som zastanca prevencie nad represiou asi najucinnejsie sa mi zda sifrovanie citlivych udajov obcanov s extremne obmedzenym pristupom( zasahom ludskeho faktora), kedze sme sa vybrali cestou elektronizacie tychto citlivych udajov.
Treba si tiez uvedomit, ze Europa ma negativnu skusenost s totalitnymi formami vlady, kedy sa osobne udaje zneuzivali. Preto je v Europe taky tlak na ochranu sukromnej sfery obcanov a ochranu osobnych udajov.
db admin nie je strazca, tym by mal byt security officier a naozaj tych je ako safranu. Ale opakujem, sifrovanie nie je riesenim pre vnutornych ludi, ti z podstaty maju pristup k desifrovanym udajom. Sifrovanie je navyse potrebne na viacerych urovniach, sifrovanie len DB je len ceresnickou. Ale nutnou ak ide o public cloud.
1 Like
Z akej podstaty maju pristup k datam admini? Nerozumiem, o oni totiz vecne s tymi datami (osobnymi datami) predsa nepracuju? Ich ulohou je predsa sprava db ako takej nie sprava zaznamov?
nie vsade maju pristup k datam, rozlisuj skutocne od role v IT systeme a zamestancom administratorom, zamestnanec moze mat rolu administratora a potom sa k datam dostane alebo ju nema a potom sa nedostane. To ale zase nesuvisisi s cloudom, aj v cloude im mozes dat pristup a naopak ani na vlastnom zeleze ju nemusia mat.
na to ti staci zapnut logovanie na DB urovni a nejaky automaticky monitoring, co bude tie logy vyhodnocovat a rozsvecovat majaky. Na to je tiez dnes plno rieseni.
Preco sa branite sifrovaniu osobnych/citlivych udajov v DB?
Do pozornosti davam este jeden fakt ze singapursky paswordd admina bol: Passw0rd
len v predstave IT zloducha, tak admin to vypne pred lustraciou, a potom upravi logy aby neostala stopa
ale uprimne, ked najvacsou hrozbou budu admini, tak uz bude dobre
lebo to predraží a predĺži vývoj aj 10 násobne.
SDLC - nedovoluje robit vyvoj a testy s nesiftovanými a nasadenie na sifrovane prostredia.
To znamena ze uz len ked si chces otestovat ci si spravne urobil nejaky jednoduchy ukon a ten ulozil, budes musiet ako vyvojar miesto jednoducheho kontrolneho selectu ci unit testu, vsetko rozsiforvavat … a to je len uvod problemov.
Take nieco nech má len SIS-ka …aj tak jej naklady nevie nikto skontrolovat.
a kde citas ze sa niekto brani ? Su s tym spojene nejake problemy prevadzky a vykonu ale v egov cloude urcite budu vsetky db sifrovane. Len tu pisem ze to nie je vseliek na bezpecnost a casto ani liek. Ale nikto nepise ze nie, nie nechce sifrovanie.
Ale upozornujem ze kluc na sifrovanie importuje admin :).
ale tu s iusom bavime o jednoduchom DB kryptovani, ako ma ORACLE. Nie o celom sifrovanom systeme.
To mu radsej ani nespominaj,lebo to bude ziadat a to potom naozaj amen tma.
Preco by mal mat obcan zaujem davat ukladat citlive udaje do nesifrovanej DB, napr v pripad e-health alebo elektronickej komunikacie?
Mne sa zda, ze je tu extremne nizke povedomie o tom co su osobne udaje, co su citlive udaje, ake prava z matrice ludskych prav prinalezia obcanom?
Ze pod zamienkou efektivity sme ochotni zlavit zo zakladnych a nescudzitelnych prav obcanov.
no, neviem a co ked ti poviem ze zapnutie data encryption pri Oracle zdvojnasobuje potrebu CPU a predlzuje pristup o 20 % ? Priplatis si aj ked vies ze k tvojim datam sa aj tak uradnik dostane ? Ci su sifrovane alebo nie ?
Preco by mal mat obcan zaujem davat ukladat citlive udaje do nesifrovanej DB, napr v pripad e-health alebo elektronickej komunikacie?
Neviem ci rozumieme, ze ochrana citlivych a osobnych udajov nie je samoucelna a je vymedzena najzakladnejsimi ludskopravnymi predpismi ku ktorym sa hlasime aspon poslednych 30 rokov.
Ze naklady na sifrovanie maju byt mandatornymi nakladmi pri sprave tychto udajov a ma sa s nimi pocitat.
Ake su naklady (skoda) pri uniku milionov citlivych udajov? Su nizsie ako naklady na sifrovanie? Ake su naklady zneuzitia citlivych udajov?