Vene Föderatsiooni valitsuse dekreet 01.11.12 1119. Määrus isikuandmete kaitse nõuete kinnitamise kohta nende töötlemisel isikuandmete infosüsteemides - Rossiyskaya Gazeta. Regulaarne nõuete täitmise jälgimine

Uue regulatiivse meistriteose kohal pikalt klaviatuuri poole sirutanud käed on juba kontideks pekstud.

Ei suuda enam tagasi hoida ega talu enam. Peab kirjutama. Veelgi enam, täna kehtib 1. novembri 2012. a määrus nr 1119 „Isikuandmete kaitse nõuete kinnitamise kohta nende töötlemisel infosüsteemid isikuandmed", millega tühistatakse 17. novembri 2007 määrus nr 781, jõustub. Seitse päeva alates avaldamise kuupäevast aegub.

Ausalt öeldes ei üllatanud kolleegide reaktsioon uuele resolutsioonile, mis tegelikult määratleb infosüsteemides isikuandmete töötlemise tehnilise turvalisuse ülesehitamise süsteemi, mind mitte ainult üllatas, vaid pigem hämmastas. Osadele, ja mitte vähestele, see meeldis, sest nende hinnangul ei sisalda see midagi põhimõtteliselt uut ega keera kruvisid rohkem kinni ning nõuete hulk isegi väheneb võrreldes PP-781-ga. Teine osa kolleege kirub dokumenti, kuid väga üldiselt, peamiselt konkreetsuse puudumise pärast.

Mul oli nõuete osas veidi teistsugune arvamus, väljendasin seda põgusalt tänasel veebiseminaril, mille pidas meie agentuur koos Turvakoodeksi ettevõttega ning selleteemaliste taotluste hulk ajendas mind lõpuks seda postitust kirjutama.

Oma visiooni süstematiseerimiseks mõtlesin välja mitu riiulit, mille järgi lagundan oma hinnangu dokumendile. Vabandust, kirju tuleb palju. Kõrgelt. Sõnad olid hoolikalt valitud, et lugejate kategooria saaks olla 0+.

Kõigepealt riiul. Seaduse järgimine. PP-1119 avaldamine on 152-FZ "Isikuandmete kohta" uue väljaande artikli 19 3. osa lõigete 1 ja 2 otsene nõue. See võimaldab mul väga teravalt hinnata asjade seisu sellel riiulil. Valitsuse määrus ei ole seadusega kooskõlas.

Seadus nägi ette turvatasemete ja neile esitatavate nõuete määramise sõltuvalt viiest tegurist:

  • võimalik kahju isikuandmete subjektile,
  • töödeldavate isikuandmete maht,
  • töödeldavate isikuandmete sisu,
  • tegevuse liik, mille käigus isikuandmeid töödeldakse,
  • ohtude olulisus isikuandmete turvalisusele.

Vastuvõetud dokumendis tegevusliigid ja, mis kõige tähtsam, subjekti kahjustamine kvalifitseerivate märkidena üldiselt puuduvad. Nõuete punktis 7 on operaator “pole üldse inimlik”, ma ei saa teisiti väita, tehakse ettepanek iseseisvalt määrata infosüsteemi seisukohalt oluliste isikuandmete turvalisuse ohtude liik, võttes arvesse 2010.a. võimaliku kahju hindamine, lähtudes FSB ja FSTECi dokumentidest, mida veel ei eksisteeri.

Need. lasteaia juhataja või toruvaltsimistehase automaatikaosakonna juhataja (kuna sellistes organisatsioonides pole lihtsalt kedagi teist, kes selliste probleemidega tegeleks) hindab töötajate, kasvatajate, külastajate ja töötajate andmete avalikustamisest tulenevat kahju. nende sugulased. Kuna selles küsimuses pole riigis toimunud täielikku metoodilist arengut. Kes vähegi selliste küsimustega kokku puutub, teab, et kodanikuõigusi rikkuva kahju suuruse kindlaksmääramise probleem on kohtupraktikas ja kohtumenetluses üks keerulisemaid. Kuid ilmselt, pidades meeles klassikalist postulaati iga koka võimete kohta, otsustasid autorid, et probleemi saab lahendada ühishanke abil. Hinnanguliselt on operaatoreid umbes seitse miljonit. Vaata, mida nad välja mõtlevad. Klassikaline näide probleemide ühest peast teise nihutamisest, teate mis.

Tegevustega ka varitsus. Arvestades, et seaduse uus redaktsioon ei jäta ruumi isikuandmetega töötamise tööstusstandarditele, tuleb neid samu liike arvesse võtta ainult ühel viisil - FSB-le täiendavate turvaohtudega. ja FSTEC, mis on tegelikult sõnastatud seaduse sama artikli 19 5. ja 6. osas. Punkt. Ainult selleks, et tuvastada uusi ohte, mitte ette näha mingeid leebendeid, mis on sarnased nendega, millega tervishoiuministeerium oma metoodilistes dokumentides FSTECiga kokku leppis.

Riiul teine. Metoodika. Riiul on kõige ... halvasti riputatud. Kuna metoodika on kõige olulisem, siis dokumendi probleemid. Peamiste ohtude väljakuulutamine, mis paratamatult viib kõrgemad tasemed turvalisus (vt tabel 1), deklareerimata (dokumenteerimata) võimalused süsteemis ja rakenduses Nõuded ei paku üldse meetodeid ega viise nende neutraliseerimiseks. Selliste meetodite puhul saab ainult selle tarkvara kontrollimine järjehoidjate ja muude halbade harjumuste puudumise suhtes. Ja keegi ei nõua seda operaatoritelt, vähemalt PP-1119 puhul.

Loogiliste pommide, tagauste ja muude kurjade vaimude raviks pakuvad nad vanu tõestatud meetodeid - grammofoni nõeltega klastrit ja katkematute jäsemete krohvimist. Vaata tabelit.

Kuidas on kasutamine tulemüürid ja üksuse (või vastutava isiku) määramine võib aidata vältida mõjusid operatsioonisüsteem ilmselt teavad töödeldavatest andmetest ainult autorid.

Riiul kolmas. Terminoloogia. Ja see on dokumendi kõige salapärasem osa. Kust tulid "operaatori töötajad" ja miks nad ei ole töötajad, kelle õiguslik seisund on tööseadustikus selgelt kirjeldatud, on lihtne ja ilmne küsimus. Aga mis on "elektrooniline teadete logi" (lk 15) ja mille poolest see erineb "elektroonilisest turvalisuse logist" (lk 16), kui see üldse erineb - selles on suur saladus. ma arvan seda me räägime palkide kohta. Mille logid? OS? DB? Tagumik? GIS? Kõik koos või midagi eraldi? Küsimused ilma vastusteta.

Määrusega tutvustatakse avalikult kättesaadavaid isikuandmeid töötleva infosüsteemi mõistet, mis seaduses puudub, ja loetakse, et need saadakse ainult avalikult kättesaadavatest isikuandmete allikatest, mis on loodud kooskõlas 152-FZ artikliga 8.

Ja kui need on saadud muul viisil, näiteks kui tegemist on avaldamisele ja kohustuslikule avaldamisele kuuluva teabega, teabena, mis on pärit ja mis on avalikult kättesaadav vastavalt föderaalseadusele juriidiliste isikute ja üksikettevõtjate kohta või teabena ettevõttega seotud isikute kohta. emitent Või saadikukandidaatide isikuandmed, avaldatakse. Kuidas nendega koos olla? Jälle küsimus, millele pole vastust.

Lõpuks vastavushindamine. Mõiste, millel pole infoturbe rajatise kohta selgitusi üheski seaduses, välja arvatud suletud dekreet nr 330, tiirleb regulatiivses raamistikus edasi. Kuid isegi kui käitaja on seda määrust näinud, ei anta talle aru, kuidas riikliku kontrolli ja järelevalve käigus vastavushindamine toimub. Ja hinnata ka vastutava töötleja saabumise ootamise tagajärgi ja tema käitumist sertifitseerimata fondide silmis. Noh, ärgem unustagem, et seaduse uues redaktsioonis kuuluvad isikuandmete töötlemisega seotud normatiivaktid ametlikule avaldamisele.

Neljas riiul. Kohaldatavus. Resolutsioon saab täielikult toimida alles pärast FSB ja FSTECi asjakohaste aktide vastuvõtmist, mis on sätestatud 152-FZ artikli 19 4. osas, samuti föderaalorganite poolt, kes täidavad riigi ja õigusliku reguleerimise väljatöötamise ülesandeid. kehtestatud tegevusala, subjektide riigiasutused Venemaa Föderatsioon, riigieelarveväliste fondide organid, muud riigiasutused isikuandmete turvalisuse tegelike ohtude kindlakstegemisel (152-FZ artikli 19 5. osa, nõuete punkt 2), mis puuduvad ja ei ole teada millal nad lapsendatakse.

Nendel tingimustel on operaatoril peaaegu võimatu kehtestatud nõudeid täita. Naasen lasteaia juhataja ja toruvaltsimistehase automaatikaosakonna juhataja juurde. Kes selgitab esimesena, mis on "deklareerimata süsteemitarkvara võimalused" ja milliste kriteeriumide alusel hindab ta selle ohu asjakohasust? Mis võib panna teise inimese neid ohte oma tehase jaoks oluliseks tunnistama ja lisaprobleeme võtma? Kuidas nad hindavad kahju, millest esimese riiuli analüüsimisel kirjutati? Ootame FSB ja FSTEC dokumente. Miski ütleb mulle, et deklareerimata võimete neutraliseerimisest ei saa lihtsalt keelduda. Pangad ja telekomid lahendavad selle lõpuks ära. Ja kuidas on lood ülejäänutega, kellel pole FSB / FSTECi spetsialiste ja litsentse - ja ülikoolid, haiglad ja kliinikud, registriametid ja tööhõivekeskused jne jne? Midagi peale hämmelduse, selline dokument võib neid tekitada.

Ma ei kirjuta CV-d. Ja nii on kõik selge.

Uue regulatiivse meistriteose kohal pikalt klaviatuuri poole sirutanud käed on juba kontideks pekstud. Ei suuda enam tagasi hoida ega talu enam. Peab kirjutama. Veelgi enam, täna jõustub 01.11.2012 määrus nr 1119 "Isikuandmete kaitse nõuete kinnitamise kohta nende töötlemisel isikuandmete infosüsteemides", millega tühistatakse 11.17.2007 määrus nr 781. Seitse päeva alates avaldamise kuupäevast aegub.

Ausalt öeldes ei üllatanud kolleegide reaktsioon uuele resolutsioonile, mis tegelikult määratleb infosüsteemides isikuandmete töötlemise tehnilise turvalisuse ülesehitamise süsteemi, mind mitte ainult üllatas, vaid pigem hämmastas. Osadele, ja mitte vähestele, see meeldis, sest nende hinnangul ei sisalda see midagi põhimõtteliselt uut ega keera kruvisid rohkem kinni ning nõuete hulk isegi väheneb võrreldes PP-781-ga. Teine osa kolleege kirub dokumenti, kuid väga üldsõnaliselt, peamiselt konkreetsuse puudumise pärast.

Olin nõuete osas veidi teistsugusel arvamusel, väljendasin seda põgusalt tänasel meie agentuuri koos Turvakoodeksi ettevõttega peetud veebiseminaril ning selle kohta laekunud küsimuste hulk ajendas mind lõpuks seda postitust kirjutama.

Oma visiooni süstematiseerimiseks mõtlesin välja mitu riiulit, mille järgi lagundan oma hinnangu dokumendile. Vabandust, kirju tuleb palju. Kõrgelt. Sõnad olid hoolikalt valitud, et lugejate kategooria saaks olla 0+.

Kõigepealt riiul. Seaduse järgimine. PP-1119 avaldamine on 152-FZ "Isikuandmete kohta" uue väljaande artikli 19 3. osa lõigete 1 ja 2 otsene nõue. See võimaldab mul väga teravalt hinnata asjade seisu sellel riiulil. Valitsuse määrus ei ole seadusega kooskõlas. Seadus nägi ette turvatasemete ja neile esitatavate nõuete määramise sõltuvalt viiest tegurist:

· võimalik kahju isikuandmete subjektile,

· töödeldavate isikuandmete maht,

· töödeldavate isikuandmete sisu,

· tegevuse liik, mille käigus isikuandmeid töödeldakse,

· ohtude olulisus isikuandmete turvalisusele.

Vastuvõetud dokumendis tegevusliigid ja, mis kõige tähtsam, subjekti kahjustamine kvalifitseerivate märkidena üldiselt puuduvad. Nõuete punktis 7 on operaator “pole üldse inimlik”, ma ei saa teisiti väita, tehakse ettepanek iseseisvalt määrata infosüsteemi seisukohalt oluliste isikuandmete turvalisuse ohtude liik, võttes arvesse 2010.a. võimaliku kahju hindamine, lähtudes FSB ja FSTECi dokumentidest, mida veel ei eksisteeri. Need. lasteaia juhataja või toruvaltsimistehase automaatikaosakonna juhataja (kuna sellistes organisatsioonides pole lihtsalt kedagi teist, kes selliste probleemidega tegeleks) hindab töötajate, kasvatajate, külastajate ja töötajate andmete avalikustamisest tulenevat kahju. nende sugulased. Kuna selles küsimuses pole riigis toimunud täielikku metoodilist arengut. Kes vähegi selliste küsimustega kokku puutub, teab, et kodanikuõigusi rikkuva kahju suuruse kindlaksmääramise probleem on kohtupraktikas ja kohtumenetluses üks keerulisemaid. Kuid ilmselt, pidades meeles klassikalist postulaati iga koka võimete kohta, otsustasid autorid, et probleemi saab lahendada ühishanke abil. Operaatoreid on Roskomnadzori andmetel umbes seitse miljonit. Vaata, mida nad välja mõtlevad. Klassikaline näide probleemide ühest peast teise nihutamisest, teate mis.

Tegevustega ka varitsus. Arvestades, et seaduse uus redaktsioon ei jäta ruumi isikuandmetega töötamise tööstusstandarditele, tuleb just nende liikidega arvestada ainult ühel viisil – leiutades turvaohte, mis täiendavad isikuandmetega töötamist. FSB ja FSTEC, mis on tegelikult sõnastatud seaduse sama artikli 19 5. ja 6. osas. Punkt. Ainult selleks, et tuvastada uusi ohte, mitte ette näha mingeid leebendeid, mis on sarnased nendega, millega tervishoiuministeerium oma metoodilistes dokumentides FSTECiga kokku leppis.

Riiul teine. Metoodika. Riiul on kõige ... halvasti riputatud. Kuna metoodikas on dokumendi kõige olulisemad, võtmeprobleemid. Peamiste ohtude väljakuulutamine, mis paratamatult viib kõrgeima turvataseme kehtestamiseni (vt tabel 1), on süsteemis ja rakenduses deklareerimata (dokumenteerimata) võimalused. tarkvara, Nõuded ei paku üldse meetodeid ja vahendeid nende neutraliseerimiseks. Selliste meetodite puhul saab ainult selle tarkvara kontrollimine järjehoidjate ja muude halbade harjumuste puudumise suhtes. Ja keegi ei nõua seda operaatoritelt, vähemalt PP-1119 puhul.

Tabel 1

ISPD tüüp

Operaator personal

Õppeainete arv

Praeguste ohtude tüüp

1

2

3

ISPDn-S

Mitte

> 100 000

UZ-1

UZ-1

UZ-2

Mitte

< 100 000

UZ-1

UZ-2

UZ-3

Jah

ISPDn-B

UZ-1

UZ-2

UZ-3

ISPDn-I

Mitte

> 100 000

UZ-1

UZ-2

UZ-3

Mitte

< 100 000

UZ-2

UZ-3

UZ-4

Jah

ISPDn-O

Mitte

> 100 000

UZ-2

UZ-2

UZ-4

Mitte

< 100 000

UZ-2

UZ-3

UZ-4

Jah

Loogiliste pommide, tagauste ja muude kurjade vaimude raviks pakuvad nad vanu tõestatud meetodeid - grammofoni nõeltega klastrit ja katkematute jäsemete krohvimist. Vaata tabelit 2.

tabel 2

Nõuded

Tasemed

turvalisus

1

2

3

4

Isikuandmete töötlemise ruumide turvarežiim

Isikuandmekandjate ohutus

Isikuandmetele lubatud isikute nimekiri

IPS, mis on läbinud vastavushindamismenetluse

Isikuandmete turvalisuse tagamise eest vastutav ametnik ISPD-s

Juurdepääsu piiramine elektroonilise sõnumite logi sisule

Operaatori töötaja isikuandmetele juurdepääsu volituste muutumise automaatne registreerimine elektroonilises turvalogis

Isikuandmete turvalisuse tagamise eest vastutav struktuuriüksus

Kuidas sertifitseeritud tulemüüride kasutamine ja vastutava üksuse (või vastutava isiku) määramine aitab ära hoida operatsioonisüsteemi mõju töödeldavatele andmetele, teavad ilmselt vaid autorid.

Riiul kolmas. Terminoloogia. Ja see on dokumendi kõige salapärasem osa. Kust tulid "operaatori töötajad" ja miks nad ei ole töötajad, kelle õiguslik seisund on tööseadustikus selgelt kirjeldatud, on lihtne ja ilmne küsimus. Aga mis on "elektrooniline teadete logi" (lk 15) ja mille poolest see erineb "elektroonilisest turvalisuse logist" (lk 16), kui see üldse erineb - selles on suur saladus. See on vist palkidest. Mille logid? OS? DB? Tagumik? GIS? Kõik koos või midagi eraldi? Küsimused ilma vastusteta.

Määrusega tutvustatakse avalikult kättesaadavaid isikuandmeid töötleva infosüsteemi mõistet, mis seaduses puudub, ja loetakse, et need saadakse ainult avalikult kättesaadavatest isikuandmete allikatest, mis on loodud kooskõlas 152-FZ artikliga 8.

Ja kui need saadakse muul viisil, näiteks kui see on avaldamisele ja kohustuslikule avaldamisele kuuluv teave, nagu teave juriidiliste isikute ühtsest riiklikust registrist ja EGRIP-ist, mis on avalikult kättesaadav vastavalt föderaalseadusele riiklik registreerimine juriidilised isikud ja üksikettevõtjad. Või teave emitendi sidusettevõtete kohta väärtuslikud paberid. Või avaldamisele saadikukandidaatide isikuandmed. Kuidas nendega koos olla? Jälle küsimus, millele pole vastust.

Lõpuks vastavushindamine. Mõiste, millel pole infoturbe rajatise kohta selgitusi üheski seaduses, välja arvatud suletud dekreet nr 330, tiirleb regulatiivses raamistikus edasi. Kuid isegi kui käitaja on seda määrust näinud, ei anta talle aru, kuidas riikliku kontrolli ja järelevalve käigus vastavushindamine toimub. Ja hinnata ka vastutava töötleja saabumise ootamise tagajärgi ja tema käitumist sertifitseerimata fondide silmis. Noh, ärgem unustagem, et seaduse uues redaktsioonis kuuluvad isikuandmete töötlemisega seotud normatiivaktid ametlikule avaldamisele.

Neljas riiul. Kohaldatavus. Resolutsioon saab täielikult toimima hakata alles pärast FSB ja FSTECi asjakohaste aktide vastuvõtmist, mis on sätestatud 152-FZ artikli 19 4. osas, samuti föderaalsete täitevorganite poolt, kes täidavad riigi poliitika väljatöötamise ülesandeid ja ülesandeid. õiguslik regulatsioon kehtestatud tegevusvaldkonnas, Vene Föderatsiooni moodustavate üksuste riigiasutused, Venemaa Pank, riigieelarveväliste fondide organid, muud riigiasutused isikuandmete turvalisuse tegelike ohtude kindlaksmääramisel ( 152-FZ artikli 19 5. osa, nõuete punkt 2), mis puuduvad ja ei ole teada, millal need vastu võetakse. Nendel tingimustel on operaatoril peaaegu võimatu kehtestatud nõudeid täita. Naasen lasteaia juhataja ja toruvaltsimistehase automaatikaosakonna juhataja juurde. Kes selgitab esimesena, mis on "deklareerimata süsteemitarkvara võimalused" ja milliste kriteeriumide alusel hindab ta selle ohu asjakohasust? Mis võib panna teise inimese neid ohte oma tehase jaoks oluliseks tunnistama ja lisaprobleeme võtma? Kuidas nad hindavad kahju, millest esimese riiuli analüüsimisel kirjutati? Ootame FSB ja FSTEC dokumente. Miski ütleb mulle, et deklareerimata võimete neutraliseerimisest ei saa lihtsalt keelduda. Pangad ja telekomid lahendavad selle lõpuks ära. Ja kuidas on teistega, kellel pole spetsialiseeritud spetsialiste ja FSB / FSTEC litsentse - koolid ja ülikoolid, haiglad ja kliinikud, registriametid ja tööhõivekeskused jne jne? Midagi peale hämmelduse, selline dokument võib neid tekitada.

Ma ei kirjuta CV-d. Ja nii on kõik selge.

Artikkel 19 föderaalseadus"Isikuandmete kohta" Vene Föderatsiooni valitsus otsustab:

1. Kinnitada lisatud nõuded isikuandmete kaitseks nende töötlemisel isikuandmete infosüsteemides.

2. Tunnistada kehtetuks Vene Föderatsiooni valitsuse 17. novembri 2007. aasta määrus N 781 "Isikuandmete turvalisuse tagamise eeskirjade kinnitamise kohta nende töötlemisel isikuandmete infosüsteemides" (Vene Föderatsiooni kogutud õigusaktid , 2007, N 48, art. 6001) .

Vene Föderatsiooni valitsuse esimees

D. Medvedev

Nõuded isikuandmete kaitsele nende töötlemisel isikuandmete infosüsteemides

1. See dokument kehtestab nõuded isikuandmete kaitsele nende töötlemisel isikuandmete infosüsteemides (edaspidi infosüsteemid ) ja nende andmete kaitse tasemed.

2. Isikuandmete turvalisus nende infosüsteemis töötlemise ajal tagatakse isikuandmete kaitsesüsteemi abil, mis neutraliseerib föderaalseaduse "Isikuandmete kohta" artikli 19 5. osa kohaselt määratletud praegused ohud.

Isikuandmete kaitse süsteem sisaldab organisatsioonilisi ja (või) tehnilisi meetmeid, mis on määratud, võttes arvesse isikuandmete turvalisusele avalduvaid aktuaalseid ohte ja infotehnoloogiad kasutatakse infosüsteemides.

3. Isikuandmete turvalisuse nende infosüsteemis töötlemise ajal tagab selle süsteemi operaator, kes töötleb isikuandmeid (edaspidi operaator), või isik, kes töötleb isikuandmeid käitaja nimel isikuandmeid töötleva isikuandmete alusel. selle isikuga (edaspidi volitatud isik) sõlmitud lepingust. Käitaja ja volitatud isiku vaheline leping peab sätestama volitatud isiku kohustuse tagada isikuandmete turvalisus nende töötlemisel infosüsteemis.

4. Isikuandmete kaitsesüsteemi infoturbevahendite valiku teeb operaator vastavalt Vene Föderatsiooni Föderaalse Julgeolekuteenistuse ja Föderaalse Tehnilise ja Ekspordikontrolli Talituse poolt 4. osa alusel vastu võetud normatiivaktidele. föderaalseaduse "Isikuandmete kohta" artikli 19 punkt.

5. Infosüsteem on infosüsteem, mis töötleb isikuandmete erikategooriaid, kui selles töödeldakse isikuandmeid, mis on seotud isikuandmete subjektide rassi, rahvuse, poliitiliste vaadete, usuliste või filosoofiliste veendumuste, tervisliku seisundi, intiimse eluga.

Infosüsteem on infosüsteem, mis töötleb biomeetrilisi isikuandmeid, kui see töötleb isiku füsioloogilisi ja bioloogilisi omadusi iseloomustavat teavet, mille alusel on võimalik tuvastada tema isikusamasust ja mida operaator kasutab subjekti tuvastamiseks. isikuandmeid ega töötle isikuandmete erikategooriatega seotud teavet.

Infosüsteem on infosüsteem, mis töötleb avalikult kättesaadavaid isikuandmeid, kui see töötleb isikuandmete subjektide isikuandmeid, mis on saadud ainult föderaalseaduse "Isikuandmete kohta" artikli 8 kohaselt loodud avalikult kättesaadavatest isikuandmete allikatest.

Infosüsteem on infosüsteem, mis töötleb muid isikuandmete kategooriaid, kui see ei töötle käesoleva lõike punktides üks kuni kolm nimetatud isikuandmeid.

Infosüsteem on infosüsteem, mis töötleb operaatori töötajate isikuandmeid, kui see töötleb ainult nimetatud töötajate isikuandmeid. Muudel juhtudel on isikuandmete infosüsteem infosüsteem, mis töötleb nende isikuandmete subjektide isikuandmeid, kes ei ole operaatori töötajad.

6. Isikuandmete turvalisuse tegelike ohtude all mõistetakse tingimuste ja tegurite kogumit, mis loovad tegeliku ohu volitamata, sealhulgas juhuslikuks, juurdepääsuks isikuandmetele nende töötlemisel infosüsteemis, mis võib kaasa tuua isikuandmete hävitamise, muutmise, andmete muutmise, isikuandmete töötlemise, isikuandmete ja isikuandmete töötlemise. isikuandmete blokeerimine, kopeerimine, edastamine, levitamine, samuti muud ebaseaduslikud toimingud.

1. tüüpi ohud on infosüsteemi jaoks olulised, kui see on muu hulgas allutatud ohtudele, mis on seotud infosüsteemis kasutatava süsteemitarkvara dokumenteerimata (deklareerimata) võimete olemasoluga.

2. tüüpi ohud on infosüsteemi jaoks olulised, kui see on muu hulgas allutatud ohtudele, mis on seotud infosüsteemis kasutatava rakendustarkvara dokumenteerimata (deklareerimata) võimete olemasoluga.

3. tüüpi ohud on infosüsteemi jaoks olulised, kui seda ähvardavad ohud, mis ei ole seotud dokumenteerimata (deklareerimata) võimekuse olemasoluga süsteemis ja infosüsteemis kasutatavas rakendustarkvaras.

7. Infosüsteemi jaoks oluliste isikuandmete turvaohtude liigi määrab operaator, võttes arvesse föderaalseaduse artikli 18 1. osa lõike 5 alusel tehtud võimaliku kahju hindamist. Isikuandmete kohta" ja vastavalt föderaalseaduse "Isikuandmete kohta" artikli 19 5. osa alusel vastu võetud regulatiivsetele õigusaktidele.

8. Isikuandmete töötlemisel infosüsteemides kehtestatakse 4 isikuandmete kaitse taset.

9. Isikuandmete kaitse 1. taseme tagamise vajadus nende infosüsteemis töötlemisel tuvastatakse, kui esineb vähemalt üks järgmistest tingimustest:

a) 1. tüüpi ohud on infosüsteemi jaoks olulised ja infosüsteem töötleb kas isikuandmete erikategooriaid või biomeetrilisi isikuandmeid või muid isikuandmete kategooriaid;

b) 2. tüüpi ohud on infosüsteemi jaoks olulised ja infosüsteem töötleb enam kui 100 000 isikuandmete subjekti erikategooriaid, kes ei ole operaatori töötajad.

10. Isikuandmete kaitse 2. taseme tagamise vajadus nende infosüsteemis töötlemisel tuvastatakse, kui esineb vähemalt üks järgmistest tingimustest:

a) 1. tüüpi ohud on infosüsteemi jaoks olulised ja infosüsteem töötleb avalikult kättesaadavaid isikuandmeid;

b) 2. tüüpi ohud on infosüsteemi jaoks olulised ja infosüsteem töötleb operaatori töötajate erikategooriaid isikuandmeid või vähem kui 100 000 isikuandmete subjekti isikuandmete erikategooriaid, kes ei ole operaatori töötajad;

c) 2. tüüpi ohud on infosüsteemi jaoks olulised ja infosüsteem töötleb biomeetrilisi isikuandmeid;

d) 2. tüüpi ohud on infosüsteemi jaoks olulised ja infosüsteem töötleb enam kui 100 000 isikuandmesubjekti avalikult kättesaadavaid isikuandmeid, kes ei ole operaatori töötajad;

e) 2. tüüpi ohud on infosüsteemi jaoks olulised ja infosüsteem töötleb rohkem kui 100 000 isikuandmete subjekti muid isikuandmeid, kes ei ole operaatori töötajad;

f) 3. tüüpi ohud on infosüsteemi jaoks olulised ja infosüsteem töötleb enam kui 100 000 isikuandmete subjekti erikategooriaid, kes ei ole operaatori töötajad.

11. Isikuandmete kaitse 3. taseme tagamise vajadus nende infosüsteemis töötlemisel tuvastatakse, kui esineb vähemalt üks järgmistest tingimustest:

a) 2. tüüpi ohud on infosüsteemi jaoks olulised ja infosüsteem töötleb operaatori töötajate avalikult kättesaadavaid isikuandmeid või vähem kui 100 000 isikuandmesubjekti avalikult kättesaadavaid isikuandmeid, kes ei ole operaatori töötajad;

b) 2. tüüpi ohud on infosüsteemi jaoks olulised ja infosüsteem töötleb operaatori töötajate muude kategooriate isikuandmeid või vähem kui 100 000 isikuandmesubjekti muud kategooriat, kes ei ole operaatori töötajad;

c) 3. tüüpi ohud on infosüsteemi jaoks olulised ja infosüsteem töötleb operaatori töötajate erikategooriaid või vähem kui 100 000 isikuandmesubjekti isikuandmete erikategooriaid, kes ei ole operaatori töötajad;

d) 3. tüüpi ohud on infosüsteemi jaoks olulised ja infosüsteem töötleb biomeetrilisi isikuandmeid;

e) 3. tüüpi ohud on infosüsteemi jaoks olulised ja infosüsteem töötleb rohkem kui 100 000 isikuandmete subjekti, kes ei ole operaatori töötajad, muid isikuandmete kategooriaid.

12. Isikuandmete kaitse 4. taseme tagamise vajadus nende infosüsteemis töötlemisel tuvastatakse, kui esineb vähemalt üks järgmistest tingimustest:

a) 3. tüüpi ohud on infosüsteemi jaoks olulised ja infosüsteem töötleb avalikult kättesaadavaid isikuandmeid;

b) infosüsteemi jaoks on asjakohased 3. tüüpi ohud ja infosüsteem töötleb operaatori töötajate muud kategooriat või alla 100 000 isikuandmesubjekti muude kategooriate isikuandmeid, kes ei ole operaatori töötajad.

13. Isikuandmete 4. kaitsetaseme tagamiseks nende infosüsteemides töötlemisel peavad olema täidetud järgmised nõuded:

a) režiimi korraldamine nende ruumide turvalisuse tagamiseks, kus infosüsteem asub, vältides nendesse ruumidesse juurdepääsuõiguseta isikute kontrollimatut sisenemist või seal viibimist;

b) isikuandmete kandjate ohutuse tagamine;

c) nende isikute loetelu määratleva dokumendi kinnitamine operaatori juhi poolt, kelle juurdepääs infosüsteemis töödeldavatele isikuandmetele on vajalik nende ameti- (töö)ülesannete täitmiseks;

d) infoturbevahendite kasutamine, mis on läbinud Venemaa Föderatsiooni infoturbealaste õigusaktide nõuetele vastavuse hindamise menetluse, kui selliste vahendite kasutamine on vajalik praeguste ohtude neutraliseerimiseks.

14. Isikuandmete kaitse 3. taseme tagamiseks nende infosüsteemides töötlemisel on lisaks käesoleva dokumendi punktis 13 sätestatud nõuete täitmisele vaja määrata ametnik (töötaja), kes vastutab selle tagamise eest. isikuandmete turvalisus infosüsteemis.

15. Isikuandmete kaitse 2. taseme tagamiseks nende infosüsteemides töötlemisel on lisaks käesoleva dokumendi punktis 14 sätestatud nõuete täitmisele vajalik, et juurdepääs elektroonilise sõnumilogi sisule oleks võimalik ainult käitaja või volitatud isiku ametnikele (töötajatele), kelle jaoks on nimetatud logis sisalduvad andmed vajalikud ameti(töö)ülesannete täitmiseks.

16. Isikuandmete kaitse 1. taseme tagamiseks nende infosüsteemides töötlemisel peavad lisaks käesoleva dokumendi punktis 15 sätestatud nõuetele olema täidetud järgmised nõuded:

a) operaatori töötaja infosüsteemis sisalduvatele isikuandmetele juurdepääsu õiguste muutumise automaatne registreerimine elektroonilises turvalogis;

b) infosüsteemis isikuandmete turvalisuse tagamise eest vastutava struktuuriüksuse loomine või selle turvalisuse tagamise funktsioonide määramine ühele struktuuriüksusest.

17. Kontrolli käesolevate nõuete täitmise üle korraldab ja teostab käitaja (volitatud isik) iseseisvalt ja (või) lepingulisel kaasamisel. juriidilised isikud ja üksikettevõtjad, kellel on konfidentsiaalse teabe tehnilise kaitse tegevusluba. Määratud kontroll viiakse läbi vähemalt 1 kord 3 aasta jooksul operaatori (volitatud isiku) määratud tähtaegadel.

Uue regulatiivse meistriteose kohal pikalt klaviatuuri poole sirutanud käed on juba kontideks pekstud. Ei suuda enam tagasi hoida ega talu enam. Peab kirjutama. Veelgi enam, täna jõustub 01.11.2012 määrus nr 1119 "Isikuandmete kaitse nõuete kinnitamise kohta nende töötlemisel isikuandmete infosüsteemides", millega tühistatakse 11.17.2007 määrus nr 781. Seitse päeva alates avaldamise kuupäevast aegub.

Ausalt öeldes ei üllatanud kolleegide reaktsioon uuele resolutsioonile, mis tegelikult määratleb infosüsteemides isikuandmete töötlemise tehnilise turvalisuse ülesehitamise süsteemi, mind mitte ainult üllatas, vaid pigem hämmastas. Osadele, ja mitte vähestele, see meeldis, sest nende hinnangul ei sisalda see midagi põhimõtteliselt uut ega keera kruvisid rohkem kinni ning nõuete hulk isegi väheneb võrreldes PP-781-ga. Teine osa kolleege kirub dokumenti, kuid väga üldsõnaliselt, peamiselt konkreetsuse puudumise pärast.

Olin nõuete osas veidi teisel arvamusel, väljendasin seda põgusalt tänasel Turvakoodeksi ettevõttega ühiselt peetud veebiseminaril ja selle kohta laekunud küsimuste hulk ajendas mind lõpuks seda postitust kirjutama.

Oma visiooni süstematiseerimiseks mõtlesin välja mitu riiulit, mille järgi lagundan oma hinnangu dokumendile. Vabandust, kirju tuleb palju. Kõrgelt. Sõnad olid hoolikalt valitud, et lugejate kategooria saaks olla 0+.

Kõigepealt riiul. Seaduse järgimine. PP-1119 avaldamine on 152-FZ "Isikuandmete kohta" uue väljaande artikli 19 3. osa lõigete 1 ja 2 otsene nõue. See võimaldab mul väga teravalt hinnata asjade seisu sellel riiulil. Valitsuse määrus ei ole seadusega kooskõlas. Seadus nägi ette turvatasemete ja neile esitatavate nõuete määramise sõltuvalt viiest tegurist:

· võimalik kahju isikuandmete subjektile,

· töödeldavate isikuandmete maht,

· töödeldavate isikuandmete sisu,

· tegevuse liik, mille käigus isikuandmeid töödeldakse,

· ohtude olulisus isikuandmete turvalisusele.

Vastuvõetud dokumendis tegevusliigid ja, mis kõige tähtsam, subjekti kahjustamine kvalifitseerivate märkidena üldiselt puuduvad. Nõuete punktis 7 on operaator “pole üldse inimlik”, ma ei saa teisiti väita, tehakse ettepanek iseseisvalt määrata infosüsteemi seisukohalt oluliste isikuandmete turvalisuse ohtude liik, võttes arvesse 2010.a. võimaliku kahju hindamine, lähtudes FSB ja FSTECi dokumentidest, mida veel ei eksisteeri. Need. lasteaia juhataja või toruvaltsimistehase automaatikaosakonna juhataja (kuna sellistes organisatsioonides pole lihtsalt kedagi teist, kes selliste probleemidega tegeleks) hindab töötajate, kasvatajate, külastajate ja töötajate andmete avalikustamisest tulenevat kahju. nende sugulased. Kuna selles küsimuses pole riigis toimunud täielikku metoodilist arengut. Kes vähegi selliste küsimustega kokku puutub, teab, et kodanikuõigusi rikkuva kahju suuruse kindlaksmääramise probleem on kohtupraktikas ja kohtumenetluses üks keerulisemaid. Kuid ilmselt, pidades meeles klassikalist postulaati iga koka võimete kohta, otsustasid autorid, et probleemi saab lahendada ühishanke abil. Operaatoreid on Roskomnadzori andmetel umbes seitse miljonit. Vaata, mida nad välja mõtlevad. Klassikaline näide probleemide ühest peast teise nihutamisest, teate mis.

Tegevustega ka varitsus. Arvestades, et seaduse uus redaktsioon ei jäta ruumi isikuandmetega töötamise tööstusstandarditele, tuleb just nende liikidega arvestada ainult ühel viisil – leiutades turvaohte, mis täiendavad isikuandmetega töötamist. FSB ja FSTEC, mis on tegelikult sõnastatud seaduse sama artikli 19 5. ja 6. osas. Punkt. Ainult selleks, et tuvastada uusi ohte, mitte ette näha mingeid leebendeid, mis on sarnased nendega, millega tervishoiuministeerium oma metoodilistes dokumentides FSTECiga kokku leppis.

Riiul teine. Metoodika. Riiul on kõige ... halvasti riputatud. Kuna metoodikas on dokumendi kõige olulisemad, võtmeprobleemid. Tunnistades deklareerimata (dokumenteerimata) võimekused süsteemi- ja rakendustarkvaras peamisteks ohtudeks, mis paratamatult viivad kõrgema turvataseme kehtestamiseni (vt tabel 1), ei paku Nõuded nende neutraliseerimiseks üldse meetodeid ega viise. Selliste meetodite puhul saab ainult selle tarkvara kontrollimine järjehoidjate ja muude halbade harjumuste puudumise suhtes. Ja keegi ei nõua seda operaatoritelt, vähemalt PP-1119 puhul.

Tabel 1

ISPD tüüp

Operaator personal

Õppeainete arv

Praeguste ohtude tüüp

1

2

3

ISPDn-S

Mitte

> 100 000

UZ-1

UZ-1

UZ-2

Mitte

< 100 000

UZ-1

UZ-2

UZ-3

Jah

ISPDn-B

UZ-1

UZ-2

UZ-3

ISPDn-I

Mitte

> 100 000

UZ-1

UZ-2

UZ-3

Mitte

< 100 000

UZ-1

UZ-3

UZ-4

Jah

ISPDn-O

Mitte

> 100 000

UZ-2

UZ-2

UZ-4

Mitte

< 100 000

UZ-2

UZ-3

UZ-4

Jah

Loogiliste pommide, tagauste ja muude kurjade vaimude raviks pakuvad nad vanu tõestatud meetodeid - grammofoni nõeltega klastrit ja katkematute jäsemete krohvimist. Vaata tabelit 2.

tabel 2

Nõuded

Tasemed

turvalisus

1

2

3

4

Isikuandmete töötlemise ruumide turvarežiim

Isikuandmekandjate ohutus

Isikuandmetele lubatud isikute nimekiri

IPS, mis on läbinud vastavushindamismenetluse

+

Operaatori töötaja isikuandmetele juurdepääsu volituste muutumise automaatne registreerimine elektroonilises turvalogis

- -

Kuidas sertifitseeritud tulemüüride kasutamine ja vastutava üksuse (või vastutava isiku) määramine aitab ära hoida operatsioonisüsteemi mõju töödeldavatele andmetele, teavad ilmselt vaid autorid.

Riiul kolmas. Terminoloogia. Ja see on dokumendi kõige salapärasem osa. Kust tulid "operaatori töötajad" ja miks nad ei ole töötajad, kelle õiguslik seisund on tööseadustikus selgelt kirjeldatud, on lihtne ja ilmne küsimus. Aga mis on "elektrooniline teadete logi" (lk 15) ja mille poolest see erineb "elektroonilisest turvalisuse logist" (lk 16), kui see üldse erineb - selles on suur saladus. See on vist palkidest. Mille logid? OS? DB? Tagumik? GIS? Kõik koos või midagi eraldi? Küsimused ilma vastusteta.

Määrusega tutvustatakse avalikult kättesaadavaid isikuandmeid töötleva infosüsteemi mõistet, mis seaduses puudub, ja loetakse, et need saadakse ainult avalikult kättesaadavatest isikuandmete allikatest, mis on loodud kooskõlas 152-FZ artikliga 8.

Ja kui need saadakse muul viisil, näiteks kui tegemist on avaldamisele ja kohustuslikule avaldamisele kuuluva teabega, nagu teave juriidiliste isikute ühtsest riiklikust registrist ja EGRIP-ist, mis on vastavalt riigi föderaalseadusele avalikult kättesaadav. Juriidiliste isikute ja üksikettevõtjate registreerimine. Või teave väärtpaberite emitendiga seotud isikute kohta. Või avaldamisele saadikukandidaatide isikuandmed. Kuidas nendega koos olla? Jälle küsimus, millele pole vastust.

Lõpuks vastavushindamine. Mõiste, millel pole infoturbe rajatise kohta selgitusi üheski seaduses, välja arvatud suletud dekreet nr 330, tiirleb regulatiivses raamistikus edasi. Kuid isegi kui käitaja on seda määrust näinud, ei anta talle aru, kuidas riikliku kontrolli ja järelevalve käigus vastavushindamine toimub. Ja hinnata ka vastutava töötleja saabumise ootamise tagajärgi ja tema käitumist sertifitseerimata fondide silmis. Noh, ärgem unustagem, et seaduse uues redaktsioonis kuuluvad isikuandmete töötlemisega seotud normatiivaktid ametlikule avaldamisele.

Neljas riiul. Kohaldatavus. Resolutsioon saab täielikult toimima hakata alles pärast FSB ja FSTECi asjakohaste aktide vastuvõtmist, mis on sätestatud 152-FZ artikli 19 4. osas, samuti föderaalsete täitevorganite poolt, kes täidavad riigi poliitika väljatöötamise ülesandeid ja ülesandeid. õiguslik regulatsioon kehtestatud tegevusvaldkonnas, Vene Föderatsiooni moodustavate üksuste riigiasutused, Venemaa Pank, riigieelarveväliste fondide organid, muud riigiasutused isikuandmete turvalisuse tegelike ohtude kindlaksmääramisel ( 152-FZ artikli 19 5. osa, nõuete punkt 2), mis puuduvad ja ei ole teada, millal need vastu võetakse. Nendel tingimustel on operaatoril peaaegu võimatu kehtestatud nõudeid täita. Naasen lasteaia juhataja ja toruvaltsimistehase automaatikaosakonna juhataja juurde. Kes selgitab esimesena, mis on "deklareerimata süsteemitarkvara võimalused" ja milliste kriteeriumide alusel hindab ta selle ohu asjakohasust? Mis võib panna teise inimese neid ohte oma tehase jaoks oluliseks tunnistama ja lisaprobleeme võtma? Kuidas nad hindavad kahju, millest esimese riiuli analüüsimisel kirjutati? Ootame FSB ja FSTEC dokumente. Miski ütleb mulle, et deklareerimata võimete neutraliseerimisest ei saa lihtsalt keelduda. Pangad ja telekomid lahendavad selle lõpuks ära. Ja kuidas on teistega, kellel pole spetsialiseeritud spetsialiste ja FSB / FSTEC litsentse - koolid ja ülikoolid, haiglad ja kliinikud, registriametid ja tööhõivekeskused jne jne? Midagi peale hämmelduse, selline dokument võib neid tekitada.

Ma ei kirjuta CV-d. Ja nii on kõik selge.


Vene Föderatsiooni valitsuse 01. novembri 2012 dekreediga nr 1119 maeti kõigile juba tuttavaks saanud isikuandmete infosüsteemide klassid.

Klasside asemel kehtestatakse uue määruse kohaselt neli isikuandmete kaitsetaset nende töötlemisel infosüsteemides ja nõuded igaühele neist. Infosüsteemide määramine ühele või teisele turbetasemele toimub olenevalt infosüsteemis töödeldavate isikuandmete liigist, hetkeohtude tüübist, infosüsteemis töödeldavate isikuandmete subjektide arvust ja sellest, milliste isikuandmete kohta infosüsteem töötleb. millist kontingenti töödeldakse.

Isikuandmete infosüsteemid (ISPD) jagunevad vastavalt määruse nr 1119 lõikele 5 4 rühma:

  • Spetsiaalsed ISPD-d

    kui ISPD töötleb isikuandmeid, mis on seotud isikuandmete subjektide rassi, rahvuse, poliitiliste vaadete, usuliste või filosoofiliste veendumuste, tervisliku seisundi, intiimse eluga;

  • Biomeetrilised ISPD-d

    kui ISPD töötleb isiku füsioloogilisi ja bioloogilisi omadusi iseloomustavat teavet, mille alusel on võimalik tuvastada tema isikut ja mida operaator kasutab isikuandmete subjekti tuvastamiseks, ning isikuandmete erikategooriatega seotud teavet. isikuandmeid ei töödelda;

  • Avalikud ISPD-d

    kui ISPD töötleb isikuandmete subjektide isikuandmeid, mis on saadud ainult avalikult kättesaadavatest isikuandmete allikatest, mis on loodud vastavalt föderaalseaduse "Isikuandmete kohta" artiklile 8;

  • Muud ISPD-d

    kui ISPD töötleb isikuandmesubjektide isikuandmeid, mida ei ole esitatud kolmes eelmises rühmas.

Vastavalt teie organisatsiooni ja subjektide vaheliste suhete vormile jaguneb töötlemine kahte tüüpi:

  • töötajate isikuandmete töötlemine (subjektid, kellega teie organisatsioonil on töösuhted);
  • isikute isikuandmete töötlemine, kes ei ole teie organisatsiooni töötajad.

Nende subjektide arvu järgi, kelle PD-d töödeldakse, määratleb määrus nr 1119 ainult 2 kategooriat:

  • vähem kui 100 000 subjekti;
  • rohkem kui 100 000 subjekti;

Ja lõpuks Praeguste ohtude tüübid:

  • 1. tüüpi ohud on seotud deklareerimata (dokumenteerimata) võimaluste olemasoluga ISPD-s kasutatavas süsteemitarkvaras;
  • 2. tüüpi ohud on seotud deklareerimata võimaluste olemasoluga ISPD-s kasutatavas rakendustarkvaras;
  • 3. tüüpi ohud ei ole seotud ISPD-s kasutatava tarkvara deklareerimata võimaluste olemasoluga.

Tegelike ohtude tüübi määramine ei ole reguleeritud. PP-1119 nõuded ei paku mingeid meetodeid ja viise nende neutraliseerimiseks. Kui varem sai operaator valida tüüpilise ISPD klassifikatsiooni tabeli järgi või ohumudeli tulemuste põhjal spetsiaalse ISPD klassifikatsiooni, siis nüüd enam valikut ei ole. Turvalisuse tase määratakse alati lähtuvalt ohtude asjakohasusest. Tõenäoliselt ei suuda operaator neid ise määrata - ta peab võtma ühendust kõrgema organisatsiooni või konsultandiga. Lihtsaim viis on minna kergema vastupanu teed, st. määrake 3. tüüpi tegeliku ohu tüüp ja unustage süsteemi- ja rakendustarkvara deklareerimata (dokumenteerimata) funktsioonid, kuid see peab olema põhjendatud. Kogu küsimus on selles, kuidas?, pöördudes tagasi lõigu algusesse.
Isikuandmete infosüsteemide ohtude asjakohasuse teema on väga oluline, sest õigesti kirjeldatud ohud määravad, kui kompetentselt süsteemi kaitstakse ning kui palju kaitse läheb isikuandmete haldurile maksma.

Kui olete otsustanud konkreetse ISPD algandmed, sealhulgas praeguste ohtude tüübi, saate määrata selle turvataseme. Turvataseme määramise hõlbustamiseks kasutage järgmist tabelit, mis põhineb PP-1119:

ISPD tüüp

Operaator personal

Õppeainete arv

Praeguste ohtude tüüp

1
(NDV OS)

2
(NDV PO)

3
(Ilma NDV-ta)

ISPDn-S
(eriline)

Mitte > 100 000 UZ-1 UZ-1 UZ-2
Mitte < 100 000 UZ-1 UZ-2 UZ-3
Jah

ISPDn-B
(biomeetriline)

UZ-1 UZ-2 UZ-3

ISPDn-I
(muu)

Mitte > 100 000 UZ-1 UZ-2 UZ-3
Mitte < 100 000 UZ-2 UZ-3 UZ-4
Jah

ISPDn-O
(avalik)

Mitte > 100 000 UZ-2 UZ-2 UZ-4
Mitte < 100 000 UZ-2 UZ-3 UZ-4
Jah

Olenevalt valitud PD turvalisuse tasemest määratleb PP-1119 isikuandmete kaitseks rea nõudeid, mida operaator (volitatud isik) korraldab ja viib ellu iseseisvalt ja (või) lepingulisel alusel kaasates. juriidilised isikud ja üksikettevõtjad, kellel on konfidentsiaalse teabe tehnilise kaitse tegevusluba. Kontrolli nõuete täitmise üle tuleb teostada vähemalt üks kord 3 aasta jooksul käitaja (volitatud isiku) määratud tähtaegadel.

Nõuded

Tasemed
turvalisus

Režiimi korraldamine nende ruumide turvalisuse tagamiseks, kus infosüsteem asub, vältides nendesse ruumidesse juurdepääsuõigust mitteomavate isikute kontrollimatut sisenemist või viibimist nendesse ruumidesse. + + + +
Isikuandmekandjate ohutuse tagamine + + + +
Nende isikute loetelu, kelle juurdepääs infosüsteemis töödeldavatele isikuandmetele on vajalik nende ameti- (töö)ülesannete täitmiseks, kinnitamine operaatori juhi poolt + + + +
Infoturbe tööriistade kasutamine, mis on läbinud Venemaa Föderatsiooni infoturbealaste õigusaktide nõuetele vastavuse hindamise menetluse, juhul kui selliste vahendite kasutamine on vajalik hetkeohtude neutraliseerimiseks + + + +
ISPD-s isikuandmete turvalisuse tagamise eest vastutava ametniku määramine + + + -
Juurdepääsu piiramine elektroonilise sõnumite logi sisule + + - -
Operaatori töötaja infosüsteemis sisalduvatele isikuandmetele juurdepääsu õiguste muutumise automaatne registreerimine elektroonilises turvalogis + - - -
Infosüsteemis isikuandmete turvalisuse tagamise eest vastutava struktuuriüksuse loomine või sellise turvalisuse tagamise funktsioonide määramine mõnele struktuuriüksusele + - - -

Olles otsustanud isikuandmete kaitse nõuete üle vastavalt PP-1119-le, võite asuda valima organisatsioonilisi ja tehnilisi meetmeid isikuandmete turvalisuse tagamiseks, lähtudes Venemaa FSTECi korralduse nr. 21, 18. veebruar 2013. mille eesmärk on neutraliseerida tegelikud ohud isikuandmete turvalisusele.

Mida teha infoturbe tööriistadega, mille sertifikaadid olid varem teatud ISPD klasside jaoks välja antud?

Vastavalt infosõnumile Venemaa FSTEC kuupäevaga 20. november 2012 N 240/24/4669 "Isikuandmete kaitse tunnuste kohta nende töötlemisel isikuandmete infosüsteemides ja isikuandmete kaitseks mõeldud infoturbevahendite sertifitseerimise kohta", FSTECi väljastatud vastavussertifikaadid Venemaa enne Venemaa FSTECi reguleeriva õigusakti (tähendab korraldust nr 21) jõustumist, millega kehtestatakse organisatsiooniliste ja tehniliste meetmete koosseis ja sisu, et tagada isikuandmete turvalisus nende töötlemisel isikuandmete teabes. süsteemid, ei kuulu uuesti väljastamisele.
I klassi isikuandmete infosüsteemides töödeldavate isikuandmete kaitsmiseks kasutatavaid infoturbevahendeid saab kasutada isikuandmete infosüsteemides töödeldavate isikuandmete turvalisuse tagamiseks kuni 1. tasemeni (kaasa arvatud);
Infoturbe tööriistu, mida saab kasutada klassi 2 isikuandmete infosüsteemides töödeldavate isikuandmete kaitsmiseks, saab kasutada isikuandmete infosüsteemides töödeldavate isikuandmete kaitse 4. taseme tagamiseks.