Atklāta vēstule centrālajai statistikas pārvaldei

marts 2, 2011

Latvijā norisinās tautas skaitīšana un anketu iespējams aizpildīt arīdzan internetā. Līdz šim dažādos ziņu portālos biju lasījis atsauksmes a la “neskaitīšos”, “negribu, lai mani saskaita”, “negribu, lai manus datus atdod citiem”. Tādas domas dzirdēju arī privātās sarunās. Tā kā nebiju iedziļinājies, kā tas notiek, tad cerēju, ka viss ir OK, un uzskatīju šos komentārus par tādu kā viduslaiku tumsonības izpausmi. Diemžēl tagad pārliecinos, ka viņiem tomēr bija liela daļa taisnības.

Tātad fakts, ka tautas skaitīšanas vietnē ir iespējams autorizēties ar personas kodu un pases numuru ir vienkārši grandiozs. Kāpēc? Padomājiet paši, kam pēdējā laikā kopš esat saņēmuši pēdējoreiz pasi esat to parādījuši, kam devuši pases kopijas paši un kas Jums ir pasi paņēmis un to nokopējis. Tad nu lūk visas šīs personas potenciāli var apskatīt un vēl trakāk modificēt Jūsu un manu tautas skaitīšanas anketu. Apsveicu!

Atšķirībā, piemēram, no internetbankas autorizācijas, kur parasti katrs cilvēks saprot, ka tā parole un kodu karte nav jāmētā riņķī, vēl vairāk – tas pat ir rakstīts bankas noteikumos -, pases datus un pases kopiju pilnīgi legāli prasa daudz un dažādas gan privātas, gan valsts iestādes. Un nevienam normālam cilvēkam nevar ienākt prātā un viņš negaida, ka pienāks brīdis, kad no pases datiem varēs iegūt krietni vien vairāk informācijas nekā tajā lapiņā, ko prasīja nokopēt.

Tātad šī ir vēstule, ko es nosūtīju Centrālajai statistikas pārvaldei, cc Datu valsts inspekcijai un vēl dažām iestādēm. Iespējams tajā minētie daži juridiskie formulējumi un atsauces uz likuma pantiem nav 100% precīzi, bet neesmu jurists un bija jau vēls :). Bet nu idejiski tas ir vienkārši ārprāts.

Labdien!

Uzzinot to, kā tautas skaitīšanas mājas lapā ir realizēta
autorizācija, esmu šokā. Tātad citēju tautas skaitīšanas mājas lapā
esošās skaitīšanas pamācībā
(http://www.tautasskaitisana.lv/files/pdf/Info.pdf) rakstīto:

“Lai piekļūtu tautas skaitīšanas anketai, var izmantot vienu no trim
autorizācijas veidiem:
– Pases numurs un personas kods”.

Pēc tam, kad ir ievadīti šie divi atribūti, lietotājam (kas kā mēs
tālāk redzēsim ir absolūti iespējama cita persona, nekā personas koda
īpašnieks), tiek attēloti tādi personas dati (saskaņā ar Fizisko
personu datu aizsardzības likumu) kā:
– deklarētā dzīvesvieta
– ģimenes stāvoklis
– valstiskā piederība
– darba vietu
– izglītība
Tai skaitā SENSITĪVI PERSONAS dati, piemēram, tautība.
Vēl vairāk. Pēc tam, kad es esmu aizpildījis anketu un datus par
__visiem saviem ģimenes locekļiem__, tai skaitā bērniem( sic!!!!), šo
informāciju var iegūt jebkurš, kam ir mana pases kopija. Viņš var
iegūt vēl papildus info, ko esmu ievadījis, piemēram, faktisko adresi,
telefona numuru vai e-pasta adresi.

Tālāk informēju, ka mani pases dati ir pieejami šādās iestādēs – darba
vietā, universitātē, bankā, apdrošināšanas sabiedrībā, pašvaldībā
iegūstot dažādus dokumentus, personām, ar kurām esmu slēdzis
pirkšanas/pārdošanas līgumus, tūrisma ceļojumu firmās, daudzās valsts
iestādēs, piemēram, CSDD, VID, VSAA.

Tagad lūdzu atbildi uz šādiem jautājumiem:
1. Ņemot vērā to, ka visas augšminētās personas, kam ir mana pases
kopija, var iegūt (un vēl vairāk – modificēt) datus par mani, kā tas
ir savienojams ar solījumu, ka mani dati būs drošībā?
(Citēju no tautas skaitītāju mājas lapas
http://www.tautasskaitisana.lv/lv/jautajumi-un-atbildes/7/ (Jebkura
informācija, kuru Jūs tautas skaitīšanas procesā sniegsiet Centrālajai
statistikas pārvaldei ar interneta mājas lapas vai tautas skaitītāja
starpniecību, tiek uzskatīta par konfidenciālu un aizsargājamu Valsts
statistikas likuma 18.panta izpratnē, un tā nav pieejama trešajām
personām (arī ne citām valsts pārvaldes iestādēm).)
Diemžēl kā redzams šī informācija pilnībā ir pieejama pietiekami
plašam personu lokam pilnīgi legāli, nemaz neveicot nekādas
prettiesiskas darbības, piemēram, nozogot man pasi.

2. Ņemot vērā augšminēto, kā statistikas pārvalde var būt
pārliecināta, ka datus esmu aizpildījis es, nevis kāds cits?

3. Kā Jūs nodrošināsiet man Fizisko personu datu aizsardzības likuma
9. pantā rakstīto, citēju:
(2) Pēc datu subjekta pieprasījuma pārzinim ir pienākums sniegt arī
šādu informāciju:

1) iespējamie personas datu saņēmēji;

Kā ņemot vērā augšminēto, statistikas pārvalde, nodrošinās man
informāciju par tām PATIESAJĀM PERSONĀM, kas ir ieguvušas manus
personas datus, tai skaitā sensitīvos personas datus?

4. Lūdzu informēt kā, ņemot vērā visu augšminēto, tas atbilst Fizisko
personu datu aizsardzības likuma 10. pantā rakstītajam:
10.pants. (1) Lai aizsargātu datu subjekta intereses, pārzinis nodrošina:
2) personas datu apstrādi tikai atbilstoši paredzētajam mērķim

5. Reāls piemērs – manas darba vietas atbildīgajai personai ir
pieejama mana pases kopija. Viņai šobrīd ir iespēja apskatīt un
modificēt datus par mani un visiem citiem firmas darbiniekiem un arī
viņu ģimenes locekļiem, ja viņi būs bijuši neuzmanīgi un
“saskaitījušies”.

Ar cieņu,
Gints Plivna,
Latvijas valsts pilsonis

Gaidīsim atbildi.

Es, protams, neesmu pirmais, kas raksta par šo lietu. Pirms manis kā minimums to jau darīja laacz un defense.lv, bet neviens neatzīstas, ka būtu uzrakstījis arī vismaz elektronisku vēstuli satraukuma izraisītājiem 🙂


25 bīstamākās programmēšanas kļūdas

februāris 19, 2010

Taisni kā saklausījušies Latvijas neseno hītu par VID datu noplūdi, par ko pirmais publiski ziņoja De facto pēdējās svētdienas raidījumā

un tālāk aprunāja kaut vai Domburs savā Kas notiek Latvijā un arī savā vietnē publicēja interviju ar datu ņēmēju vadoni Neo, kurā viņš diezgan sīki apraksta gan paņemto, gan pašu “caurumu”, MITRE ir publicējuši 25 visbīstamākās 2010 gada programmēšanas kļūdas. Lasīt pārējo šī ieraksta daļu »


Slinkums jeb predikātu neizpilde

janvāris 21, 2010

Šoreiz nebūs runa par cilvēcisko slinkumu, bet par datubāžu slinkumu. Parasti viens no galvenajiem mērķiem datubāzes darbībā ir, lai tā visus SQL teikumus apstrādātu pēc iespējas ātrāk. Tiecoties pēc šī mērķa, tiek veikti daudzi un dažādi uzlabojumi, tai skaitā arī daži vienkāršākie un vēsturiski senākie – datubāzes beidz SQL teikuma kritēriju (predikātu) pārbaudi tiklīdz rezultāts ir skaidrs atlikušos nemaz nerēķinot.
Paši vienkāršākie piemēri ir šādi:

  • ja vairāki predikāti ir apvienoti ar loģisko UN (AND), tad tiklīdz neizpildās (ir aplams) viens no tiem, nākošo vērtības vairs nav svarīgas, jo viss izteikums ir aplams;
  • ja vairāki predikāti ir apvienoti ar loģisko VAI (OR), tad tiklīdz izpildās kaut viens no tiem (ir patiess), nākošo vērtības vairs nav svarīgas, jo viss izteikums ir patiess. Lasīt pārējo šī ieraksta daļu »

SQL un PL/SQL injekcijas

oktobris 29, 2008

Moto:
‘Why, what can be worse than cutting our throats?’ she asked, with pretty, naive surprise.
‘Cutting our purses,’ he answered. ‘Man is so made these days that his capacity for living is determined by the money he possesses.’

– Kā, kas tad var būt vēl ļaunāk kā laupīt mums dzīvību? – viņa jautāja diezgan naivā pārsteigumā.
– Nolaupīt mūsu makus, – viņš atbildēja. – Mūsu dienās cilvēks ir izveidojies tā, ka viņa spēju dzīvot nosaka nauda, kas viņam pieder.

The Sea-Wolf, Jack London.

Neba nu tā, ka es šim citātam pilnīgi piekristu, vēl jo vairāk tāpēc, ka Vilks Larsens ar savu filozofiju diezgan slikti beidza (starp citu saistošs stāsts, iesaku izlasīt). Taču savi maki (dati) ir jāaizsargā, jo citādi kāds tos atnāks un paņems tādā vai citādā veidā. Viens no veidiem, kā makus atstāt vaļā, ir atstāt caurumu, lai Jūsu aplikācijās varētu veikt SQL injekcijas.

Šis raksts galvenokārt ir domāts programmētājiem, kas raksta kodu, nevis lauzējiem, kas cenšas to uzlauzt. Šajā rakstā esošos piemērus bez īpašas piepūles var atrast simtiem vietās internetā, tāpēc nevajadzētu uzskatīt šo par iedrošinājumu “sliktajiem“, bet par aicinājumu “labajiem” neatstāt durvis puspievērtas, ja mājā iekšā vērtīgas lietas.

Visi turpmākie piemēri būs balstīti tikai uz Oracle SQL un PL/SQL. Tai pašā laikā šai rakstā demonstrētās tehnikas nebūt nav ierobežotas tikai ar šo konkrēto SQL implementāciju un programmēšanas valodu.

Kas tas ir?

SQL injekcijas rezultātā datubāzē tiek izpildīts pavisam cits SQL teikums, nevis tas, kas sākotnēji domāts. Tas var būt gan datu atlases (SELECT) gadījumā, gan arī, piemēram, datu koriģēšanas (UPDATE) gadījumā. Parasti “cits” nozīmē vai nu sensitīvu datu iegūšanu (SELECT gadījumā), vai nesankcionētu datu koriģēšanu, vai arī nesankcionētu tiesību piekļuves iegūšanu.

Kad tas notiek?

Parastākais un izplatītākais gadījums ir tad, kad programmētājs neuzmanīgi veido SQL vaicājumu un konkatenē to kopā kā tekstu. Līdz ar to potenciāli ir apdraudēts jebkurš koda gabals jebkurā programmēšanas valodā, kurā programmētājs “lipina” kopā SQL teikumus kā teksta virknes.

SQL injekcija Select vaicājumā nesankcionētai datu ieguvei

Visiem turpmākajiem piemēriem mēs lietosim šādas 2 tabulas,  kas simbolizēs visiem pieejamo informāciju un slepeno informāciju.

CREATE TABLE publiska (
  id NUMBER,
  dati VARCHAR2(100));
CREATE TABLE slepena (
  id NUMBER,
  dati VARCHAR2(100));
INSERT INTO publiska VALUES (1, 'publiska info');
INSERT INTO slepena VALUES (1, 'slepena info');
commit;

Refkursori ir ērts un parocīgs veids, kā no Oracle atdot datus izsaucošajai videi. Lai tā būtu .NET, PHP vai jebkas cits. Protams, ja to dara nekorekti, tad var iedzīvoties pamatīgās nepatikšanās. Skatamies piemēru, ko var pilnībā izpildīt no SQL*Plusa, bet tikpat labi izsaukums var tikt veikts no jebkuras citas vides.

Piemērs 1. Ievainojamas SQL funkcijas izveides piemērs.
CREATE OR REPLACE FUNCTION f_slikta (
  in_filtrs IN VARCHAR2)
RETURN sys_refcursor IS
  rcur sys_refcursor;
BEGIN
  OPEN rcur FOR 'SELECT *
                 FROM publiska
                 WHERE dati LIKE ''' || in_filtrs || '''';
  RETURN rcur;
END;
/
Piemērs 2. Ievainojamās SQL funkcijas sākotnēji paredzētais izsaukums.
SQL> variable cv refcursor
SQL> exec :cv := f_slikta('pub%')
PL/SQL procedure successfully completed.
SQL> print cv
        ID DATI
---------- ---------------
         1 publiska info

Viss kārtībā, vai ne? Dabūjām apmēram to, ko vēlējāmies? Taču paskatamies, kas notiek ar speciālu virkni.

Piemērs 3. Ievainojamās SQL funkcijas izsaukums izmantojot speciālu virkni – SQL injekcija.
SQL> exec :cv := f_slikta(''' UNION ALL SELECT * FROM slepena -- ')
PL/SQL procedure successfully completed.
SQL> print cv
        ID DATI
---------- -------------
         1 slepena info

Slepenā info vairs nav nekāds noslēpums! Kā tad tas notika? Tātad ir vairākas lietas, kas nepieciešamas:

  • tiekam vaļā no iepriekšējā vaicājuma rezultāta vienkārši LIKE salīdzināšanas mainīgā vietā padodot 3 apostrofus, kas SQL teikumā pārvērtīsies par vienu un gala rezultātā iegūstam šādu salīdzināšanu LIKE ” . Protams šis solis nebūt nav obligāts, galu galā jau publiskā info mūs arī briesmīgi netraucēja.
  • Izmantojot kopas operatoru UNION ALL lasam datus no slepenās tabulas.
  • Beigās izmantojam vienrindas komentāru, lai aizkomentētu pēdējo fiksēto apostrofu, kas ir ielikts funkcijas refcursora veidošanas izteiksmē.

Ja vēl joprojām nav skaidrs kā tas īsti notika, tad varam modificēt funkciju un izdrukāt (piemēram, izmantotojot dbms_output.put_line) ārā SQL teikumu. Tad mēs iegūtu šādu izpildīto SQL teikumu:

SELECT * FROM publiska
WHERE dati LIKE '' UNION ALL SELECT * FROM slepena -- '

Select vaicājums bez injekcijas iespējas

Redzam, ka ir slikti, ko darīt, lai būtu labāk? Atceramies, ka visa ļaunuma sakne slēpjas apstāklī, ka mums tika konkatenētas kopā teksta virknes, kur viena bija lietotāja iedotā. No tā var izvairīties lietojot bind mainīgos. Šajā gadījumā mainīgais tik tiešām būs tikai mainīgais, nevis kaut kāda teksta virkne, kuru lietotājs var uzdot kā vien vēlas un kas maina SQL teikuma jēgu un sākotnējo mērķi. Tātad veidojam labo funkciju.

Piemērs 4. NEIevainojamas SQL funkcijas izveides piemērs.
CREATE OR REPLACE FUNCTION f_laba (
  in_filtrs IN VARCHAR2)
RETURN sys_refcursor IS
  rcur sys_refcursor;
BEGIN
  OPEN rcur FOR 'SELECT *
                 FROM publiska
                 WHERE dati LIKE :y' USING in_filtrs;
  RETURN rcur;
END;
/

Skatamies, kas notiks ar iepriekšējiem izsaukumiem.

Piemērs 5. NEIevainojamās SQL funkcijas sākotnēji paredzētais izsaukums.
SQL> variable cv refcursor
SQL> exec :cv := f_laba('pub%')
PL/SQL procedure successfully completed.
SQL> print cv
        ID DATI
---------- ---------------
         1 publiska info

Kā redzams nekas vismaz šoreiz rezultātā nav mainījies.

Piemērs 6. NEIevainojamās SQL funkcijas izsaukums izmantojot speciālu virkni – SQL injekcijas mēģinājums.
SQL> exec :cv := f_laba(''' UNION ALL SELECT * FROM slepena -- ')
PL/SQL procedure successfully completed.
SQL> print cv
no rows selected

Nu re – nekas netika atrasts, kā jau sākumā bija cerēts. Pie tam šim variantam arī no ātradarbības viedokļa ir papildus bonusi – nelietojot bind mainīgos shared pool (atmiņas apgabals, kur tiek glabāti izpildītie SQL teikumi un to izpildes plāni) tiek pārpludināts ar ļoti līdzīgiem SQL teikumiem, kas atšķiras tikai par konstantes tiesu (t.i. katram mainīgajam savs SQL teikums). Ja lieto bind mainīgos, tad šādu problēmu nav.

Tātad redzam, ka pirmajā gadījumā tika atgriezts vēlamais rezultāts un arī otrajā gadījuma tika atgriezts vēlamais rezultāts, jo tikai un vienīgi tabulā publiska tika meklēta kaut kāda simbolu virkne, kura bija pagadījusies tāda diezgan speciāla un to nevarēja atrast.

SQL injekcija Select vaicājumā nesankcionētai jebkādai darbībai

Ja nu gadījumā Jūs iepriekšējais piemērs pilnībā nepārliecināja – sak mēs godīgi cilvēki, mums nav ko slēpt – tad paskatamies uz nākošo piemēru. Šeit lietotājs Zaglis jau ir iekļuvis sistēmā un viņam ir izveidots lietotāja konts. Atceramies, ka reālajā dzīvē tas var būt kāds no esošajiem noklusētajiem lietotājiem (scott, hr utt), kuram administrators nav nomainījis noklusēto paroli, vai arī parole ir bijusi pietiekami vienkārša un zaglis to ir uzminējis.

Piemērs 7. Zagļa mēģinājums nesankcionēti koriģēt datus.
SQL> create user zaglis identified by zaglis;
User created.
SQL> grant create procedure to zaglis;
Grant succeeded.
SQL> grant create session to zaglis;
Grant succeeded.
SQL> conn zaglis/zaglis
Connected.
SQL> INSERT INTO gints.slepena VALUES (2, 'ŠEIT BIJA ZAGLIS');
INSERT INTO gints.slepena VALUES (2, 'ŠEIT BIJA ZAGLIS')
                  *
ERROR at line 1:
ORA-00942: table or view does not exist

Tātad redzam, ka zaglis ir iekļuvis sistēmā un mēģina pievienot savu “parakstu”, bet viņam tas neizdodas, jo tiesību mehānisms to neļauj. Bet zaglis ir pietiekami gudrs, lai izveidotu savu speciālo funkciju (Savā shēmā!!!), kas viņam šīs tiesības iedos, un iedotu tiesības to izpildīt uzbrukuma mērķim.

Piemērs 8. SQL injekcijas funkcijas izveide un izpilde, kas dod nesankcionētas tiesības.
create or replace function dot_tiesibas return number
authid current_user is
  pragma autonomous_transaction;
begin
  execute immediate 'grant all on slepena to zaglis';
  return 1;
end;
/
SQL> grant execute on dot_tiesibas to gints;
Grant succeeded.
SQL> conn gints/gints
Connected.
SQL> exec :cv := f_slikta(-
> ''' UNION ALL SELECT zaglis.dot_tiesibas, null FROM dual --')
PL/SQL procedure successfully completed.
SQL> print cv
        ID DATI
---------- ------
         1
SQL> conn zaglis/zaglis
Connected.
SQL> INSERT INTO gints.slepena VALUES (2, 'ŠEIT BIJA ZAGLIS');
1 row created.
SQL> commit;
Commit complete.

Redzam, ka zaglis tagad no sava konta var bez problēmām darīt visu ar tabulu slepena. Kā tad tas īsti notika?

Tātad Zaglim savā kontā ir tiesības izveidot procedūras un funkcijas. Zaglis izveido funkciju dot_tiesibas, kurai ir šādas īpašības:

  • Tā ir lietotāja definēta funkcija un tādas ir iespējams izsaukt Select vaicājumos;
  • Zaglis ir iedevis tiesības lietotājam gints šo funkciju izpildīt, tāpēc lietotājs gints to var izdarīt (pats nemaz to neapzinādamies);
  • Select vaicājumā izpildāmās funkcijas nedrīkst veikt izmaiņas datubāzē un/vai ar datubāzes objektiem, ja vien šī funkcija nav izsaukta atsevišķas transakcijas ietvaros – ko arī norāda atslēgas vārdi pragma autonomous_transaction;
  • Šī funkcija speciāli ir veidota ar atslēgas vārdiem authid current_user, kas nozīmē to, ka funkcija tiks izpildīta tekošā lietotāja shēmā, nevis kā noklusēti – tā lietotāja shēmā, kas šo funkciju ir izveidojis;
  • execute immediate ļauj izpildīt dinamisko SQLu, tai skaitā arī DDL un DCL.

Nākošaja solī Zaglis izpilda ievainojamo funkciju f_slikta ar šoreiz mazliet citādu SQL injekciju, kas lietotāja gints shēmā izsauc zagļa izveidoto funkciju, kas atgriež 1, bet daudz svarīgāk – piešķir visas tiesības uz tabulu slepena lietotājam Zaglis. Tādējādi Zaglis ir nonācis pie sava vēlamā rezultāta.

Līdzīgu mehānismu var izmantot arī citos datu manipulēšanas teikumos (INSERT, UPDATE, DELETE), ja tie tiek konkatenēti kopā kā teksta virknes, nevis tajos tiek korekti izmantoti mainīgie.

Tātad stāsta morāle ir šāda – nevainosim zagli, ja paši rakstam sliktu kodu. Zagļi vienmēr ir bijuši un būs, bet tikai mūsu izvēle ir rakstīt kodu, kuru zagļi var viegli izmantot saviem mērķiem, vai arī rakstīt kodu, kuru šādi izmantot nevar.

Tālākā lasāmviela

SQL injekcijas un cita drošības informācija Oracle datubāzē:

Informācija par SQL injekcijām (ne tikai Oracle) latviski:


Cilvēku slimīgā tieksme glabāt svešus sensitīvus datus…

jūnijs 3, 2008

Moto: Two things are infinite: the universe and human stupidity; and I’m not sure about the universe. Albert Einstein
(Divas lietas ir bezgalīgas: universs un cilvēku muļķība; un es neesmu pārliecināts par universu).

… ir patiešām apbrīnojama. Vēl apbrīnojamāka ir tā bezrūpība ar kādu vieni to uzglabā un otri savus datus ar vieglu roku dod, itin nemaz nepainteresējoties, vai tos vajag, kāpēc tos vajag, kam tos lietos, kam tos dos, kam tos nedos, kā tos uzglabās. Latvijā pēdējā laikā ir bijuši vismaz pārītis precedentu, kad datubāzes ar parolēm, lietotāju vārdiem, uzvārdiem, personas kodiem, adresēm, izglītībām, profesijām un sazin ko vēl vienkārši nosper un publicē internetā. Pirmā bija šeit, otrā šeit. Lai gan man ir ļoti skaidrs viedoklis par otrajā gadījumā minēto organizāciju, par to šoreiz nav runa. Runa ir par faktu, ka ir nozagta informācija, piedevām gana sensitīvā kontekstā. Protams, mēs varam vainot ļaunos hakerus, Kanādu un Dievs vien zina vēl ko visos šais grēkos, bet vispirmām kārtām mums ir jāvaino pašiem sevi. Ja mums mājās ir pietiekami vērtīgas lietas, vēl jo vairāk, ja šīs lietas mums glabāšanā ir uzticējuši citi cilvēki, tad mūsu pienākums ir rūpēties, lai šīs lietas nenozog. Ja mēs nevaram nodrošināt pienācīgu apsardzi, tad labāk šādas lietas neglabāt. Ņemot vērā to, ka klientu vēlmes reizēm mēdz būt visai neadekvātas, izstrādātāju pienākums ir vismaz painformēt viņus par potenciālajām sekām, kas notiks, ja tiks nozagta uzkrātā informācija. Kā minimums pats mazākais sods būs reputācijas zudums, kas dažām kompānijām var būt visai nopietni. Sliktākā gadījumā var iestāties arī tiesu darbi, piemēram, runājot par otro gadījumu, kas no sensitīvā viedokļa dažiem dalībniekiem varētu būt ļoti nepatīkams. Otrām kārtām mums ir jāvaino sevi vēlreiz – ja mēs esam tik dumji, ka dodam savus personas datus pa labi un pa kreisi, rakstam savu vārdu uzvārdu, rakstam savus dzimšanas datus, rakstam savu personas kodu, savu darba vietu, amatu un tā tālāk, tad neko darīt – mums ir jārēķinās, ka pastāv pietiekami liela varbūtība, ka šo info agrāk vai vēlāk iegūs kāda(-s) personas(-s), kam tā nebija paredzēta un augšminētais otrais gadījums ir fantastiski perfekts piemērs, jo šīs iestādes mājaslapā ir rakstīts, ka viņi savu biedru sarakstu nedos nevienam un ne pa kam, taču kaut kā dzīvē ir izrādījies savādāk…

Tātad – ko darīt izstrādātājiem un datubāzu turētājiem, lai tas nenotiktu?

  • Vispirmām kārtām sākt uztvert šīs lietas nopietni. Pat ja Jūsu datubāzē ir 100 cilvēki, bet Jūs viņiem nez kāpēc esat prasījuši amatus, personas kodus, adreses un e-pastus, no kuriem ļoti bieži var izsecināt darba vietu, kā tas diemžēl ir augšminētajā otrajā gadījumā, tad saprotiet, ka arī tas prasa drošības ievērošanu.
  • Atrast cilvēku, kas kaut ko sajēdz no drošības un tās nodrošināšanas Jūsu datubāzei, kas satur sensitīvus datus. Tajā brīdī, kad kāds nozags Jūsu db, izmaksas gan tiešās, gan netiešās būs daaaaaudz lielākas nekā tās, ko Jums nāksies samaksāt pietiekami gudram administratoram.
  • Beidzot izvētīt savas prasības un reālo nepieciešamību un glabāt tikai patiesi nepieciešamos datus, nevis visu ko vien var paprasīt, ar domu – ja nu ievajagas. Tā arī neesmu sapratis, kāpēc ntajās starptautiskajās interneta vietnēs, piemēram, prasa adresi un telefonu. Kam tas ir vajadzīgs? Statistikai pilnīgi pietiktu ar valsti, Latvijā ar pilsētu vai rajonu. Kāpēc un cik vispār likumīgi augšminētajā otrajā gadījumā bija cilvēkiem prasīt personas kodu? No kura atgādinu, var iegūt dzimšanas datumu.
  • Ja Jums nav naudas zinošam cilvēkam un nav arī vēlmes dzēst sensitīvus un patiesībā Jums nevajadzīgus datus, tad vismaz izraujiet vadu. Tīkla vadu. Līdz šim nekas vēl nav dzirdēts par hakeriem, kas būtu datorus uzlauzuši pa elektrības vadiem. Glabājiet atsevišķi lietotāja vārdus un paroles, kas nepieciešami ikdienas darbam un potenciālajiem interneta lietotājiem no pārējiem datiem, tādiem kā amats, epasts, personas kods un sazin vēl kas. Ja nozags paroles būs nepatīkami. Bet vēl daudzkārt nepatīkamāk būs tad, ja nozags personas kodus un amatus. 

Ko darīt interneta lietotājiem, kuriem nekaunīgi prasa datus, kas patiesībā ir sensitīvi?

  • Vispirmām kārtām paturēt prātā, ka par spīti visiem apgalvojumiem, ka Jūsu datus nevienam nedos pat ar pistoli pie pieres, tas viss lielākoties ir tikai tukši vārdi bez reāla seguma. Pat ja speciāli nedos, kāds var atnākt un paņemt. Katrā gadījumā pārdomājiet, cik ļoti Jums nepatiks, ja šos datus kaut kur publiski atklās. Ja tas Jums uzdzen šermuļus pār kauliem, tad labāk nevajag. Labāk ejiet prom.
  • Ja nu tomēr Jūsu vēlme piereģistrēties ir nepārvarama, tad norādiet tik maz, cik vien nepieciešams. Aizpildiet tikai obligātos laukus, aizpildiet tos ar “Rīga” Jūsu adreses vietā. Rakstiet pseidonīmus, rakstiet kaut ko citu, izvēlieties noklusētās vērtības.
  • Iegādājieties kādu publisku e-pasta adresi. Nemaz nerunājot par to, ka vairums ļaužu neievēro (parasti) darba noteikumos rakstīto, ka darba epastu nedrīkst izmantot privātiem mērķiem, pēc tā var noteikt Jūsu darba vietu. Vai Jūs to vēlaties? Ja ne, tad kautkas@gmail.com vai sazinkas@inbox.lv būs daudz labāk.
  • Atcerieties, ka ar mūsdienu grafiskajiem redaktoriem var panākt brīnumus, kaut vai šādu jau gandrīz vai klasisku pajokošanos par GWB, kas ir tikai viena no ļoti daudzām. Visticamāk, ka Jūs nekļēsiet par tādu “slavenību”, bet ar to ir jārēķinās un tas ir jāatceras. 

Arī perfekta tehnika un drošības programmas nav 100% drošas

Tas ir vairāku iemeslu dēļ. Pirmā kā jau moto teikts, ir cilvēku muļķiba, kas ir bezgalīga. Pietiek kaut vai atcerēties samērā neseno skandālu Lielibritānijā, kur kāds ierēdnis izmantojot kurjeru nosūtīja uz CD diskiem ierakstītas ziņas par 25 miljoniem cilvēku. Sūtījums netika nekā speciāli iereģistrēts un tā arī galā neieradās. Lai uzliktu punktu uz i, sūtījums tika nosūtīts vēlreiz, šoreiz ar ierakstītu pastu un tomēr galu galā nokļuva galamērķī. Pirmais sūtījums tā arī netika atrasts. Fakts, ka vājprātīgi idiotiskā darbība tika veikta otrreiz mazliet uzlabotā variantā rada sevišķu drošības sajūtu 😉 Šādos gadījumos diemžēl nekāda programmatūra nelīdzēs, jo zinošs idiots diemžēl spēj sagraut praktiski visu. Otra lieta, par ko potenciāli ir vērts atcerēties, bet kas mums visdrīzāk vēl nedraud, jo esam maziņi un neinteresanti, ir pietiekami lielas un nopietnas organizācijas, kas velta pūles, lai kaut ko nozagtu, sabojātu vai vadītu ne tā kā paredzēts. Kā jau teikts, nebūt ne visam, kas rakstīts internetā ir jātic, tai skaitā arī šim rakstam, bet gan jau ka zināma daļa patiesības ir arī šai rakstā.

Varbūt kādam šis raksts liksies paranojisks, varbūt kādam tas liksies kā ziloņa izpūšana no mušas, bet es esmu pārliecināts, ka šī problēma ir reāla un diemžēl pieteikami daudz datu turētāji to neuztver nopietni, un tai pašā laikā bariem cilvēku nekad nav aizdomājušies, ko patiesībā var nozīmēt fakts, ka es ievadu savu personas kodu, adresi un epastu atkal kādā tiešsaistes formā. Mēstules var būt mazākais ļaunums…

Saistītie raksti