Ministerstvo průmyslu a obchodu Na Františku 32 Praha 1 V Praze dne 15. 8. 2012 Připomínky k návrhu vyhlášky o uchovávání, předávání a likvidaci provozních a lokalizačních údajů Členové ICTU projednali návrh vyhlášky v legislativní komisi s následujícími doporučeními a připomínkami, které uvádíme přehledně k jednotlivým paragrafům (odstavcům) návrhu vyhlášky. V obecné rovině upozorňujeme na skutečnost, že s ohledem na předpokládaný objem uchovávaných záznamů o datovém provozu očekáváme zvýšení nároků na kapacitu našich úložišť a s tím spojený nárůst nákladů na uchovávání těchto údajů. 1 pojem stanice BTS Toto označení je příliš specifické, neboť např. v sítích LTE se základnové stanice nazývají jinak. Pojem tedy nelze užívat univerzálně. Je to záměr předkladatele? V Důvodové zprávě na str. 16 je uvedeno k 1 písm. a) Stanicí BTS se rozumí základnová stanice sítě GSM, která je zodpovědná za přenos a příjem rádiových signálů z mobilního telefonu. Z toho by se dalo odvodit, že uchovávání dat by se mělo týkat jen sítě GSM a telefonní služby poskytované v této síti? 1 pojem adresa MAC MAC adresa není identifikátorem síťového zařízení, ale síťového rozhraní. Jedno zařízení může mít více MAC adres a síťových rozhraní současně. Jako problematickou dále shledáváme skutečnost, že v některých případech není možné zjistit MAC adresu uživatele služby, ale pouze přístupového bodu služby (např. pouze MAC adresu ADSL modemu či WiFi přístupového uzlu, nikoliv samotného uživatelského zařízení). Sběr MAC adres je obtížný, neboť tyto se mohou i během jediné datové komunikace měnit.
1 absence pojmu přístup k internetu V návrhu vyhlášky zcela postrádáme definici pojmu přístup k internetu jedná se o zakoupení služby datového balíčku, nebo o konkrétní datovou komunikaci po síti Internet? Jak detailně je nutno danou komunikaci vnímat na smlouvu, na den, na službu, na spojení? 2 odst. 1 písm. b) datum a čas zahájení a ukončení volání Navrhujeme ponechat text z původní verze vyhlášky: datum a čas zahájení komunikace, délka komunikace Odůvodnění: Ponechání délky komunikace namísto uchování data a konce komunikace zajistí jednak minimalizaci nejasností při přechodu ze zimního na letní čas a naopak, a dále nebude nutno investovat prostředky do nákladných úprav systémů (úspora i pro stát). 2 odst. 1 písm. f) stav komunikace Navrhujeme doplnit text: - je-li k dispozici. 2 odst. 2 písm. a) uchovávání IMSI Navrhujeme změnit znění na: identifikátor IMSI mobilního účastníka, jehož provozní a lokalizační údaje byly vyžádány. Odůvodnění: Formulace je nepřesná a navozuje dojem, že máme předávat IMSI u obou stran komunikace to je technicky v některých případech nerealizovatelné (pokud jedna strany komunikace není účastníkem v naší síti) či velmi technicky náročné (museli bychom vlastně spojovat dva záznamy o hovoru do jednoho). 2 odst. 2 písm. b) Navrhujeme doplnit konec textu ustanovení o text: použitý v síti operátora zprostředkovávajícího volání Odůvodnění: Tento údaj je dostupný pouze v případě, že je přístroj registrován v síti operátora, který výpis poskytuje. 2 odst. 3 písm. a) 4 adresa MAC zařízení uživatele služby Navrhujeme doplnit text: - je-li k dispozici. Odůvodnění: vit text u 1 pojem adresa MAC
2 odst. 3 písm. b) 4 datum a čas zahájení a ukončení přístupu k internetu Co přesně má být chápáno pod pojmem datum a čas zahájení přístupu k internetu? Půjde o datum a čas, na který si daný uživatel zaplatil datový balíček; kdy používal internet v daném dnu; kdy otevřel spojení? Jak bude definován konec přístupu k internetu? Půjde o konkrétní poslední paket datového spojení? Jaký je čas vypršení sledování, pokud takovýto poslední paket nelze zjistit či neexistuje? Případně, půjde o sběr průběžné informace o toku ( flow )? Běží-li provoz velmi dlouho ( trvale ), tak není konec definován? 2 odst. 3 písm. b), bod 6. - IP adresa a číslo portu 2 odst. 3 písm. c) 1 pojem IP adresa a číslo portu 2 odst. 3 písm. c) přístup k elektronické poště Vzhledem k tomu, že zde jde o velké objemy záznamů, považujeme za nezbytné vytvořit přesné definice všech použitých pojmů. Má se uchovávat IP a port zdroje nebo cíle nebo oboje? Co přesně je IP adresou a číslem portu myšleno? Jde o číslo zdrojové, cílové, obojí? Lze u vícečetné komunikace z jedné IP adresy tuto informaci agregovat? Má informace o portech vůbec reálný smysl (např. číslo zdrojového portu, které se neustále mění a rotuje)? Co jiné protokoly rodiny IP, které porty nemají? V případě, že uživatel nepoužívá e-mailový server či e-mailovou schránku operátora sítě (používá např. firemní e-mail), vztahuje se povinnost získávat informace o přístupu k takové elektronické poště a o přenosu elektronické pošty i na tohoto operátora sítě? Je v takovém případě povinností síťového operátora požadované informace zjišťovat z internetového provozu, nebo se uvedené týká pouze provozovatelů veřejných služeb e-mailových serverů a schránek? Jaké by bylo řešení v případě šifrovaného přístupu? Podobný problém shledáváme i u IP telefonie.
2 odst. 3 písm. e) bod 1 IP telefonie, adresa IP a číslo portu zdrojového zařízení 2 odst. 3 písm. e) bod 2 - IP telefonie, adresa IP a číslo portu cílového zařízení Strany komunikace mohou být kromě IP a portu reprezentovány i tel. číslem tento údaj nemá být uchováván? Strany komunikace mohou být kromě IP a portu reprezentovány i tel. číslem tento údaj nemá být uchováván? V tomto bodě je důležitost uchovávat tel. číslo ještě větší, neboť může docházet k tomu, že bude voláno z IP telefonu na klasický pevný či mobilní telefon, nikoli na VoIP klienta. V některých případech nerealizovatelné. 2 odst. 3 písm. e) bod 4 - IP telefonie, datum a čas 2 odst. 4 doplňující údaje Tato povinnost bude vyžadovat dodatečný vývoj a tím zprostředkovaně větší zátěž na státní rozpočet, přičemž přidaná hodnota těchto informací je dle našeho soudu minimální, neboť se jedná o veřejně dostupné informace. 2 odst. 5 uchovávání jméno, příjmení, adresy 2 odst. 6 písm. d) u předplacených služeb datum a čas aktivace služby a označní stanice BTS, v jejímž dosahu byla aktivace provedena Povinnost uchovávat a předávat tyto informace ukládá zákon (v 97 odstavci 5), tato povinnost nepatří do vyhlášky o provozních a lokalizačních údajích. Navrhujeme doplnit : Informace o BTS bude držena pouze po dobu uchovávání ostatních lokalizačních údajů, nikoli po celou dobu životnosti předplacené karty. Odůvodnění: Požadovaný údaj je k dispozici jako datum a čas prvního uskutečněného hovoru z dané SIM karty, u něhož je současně záznam o stanici BTS, přes kterou byl tento hovor uskutečněn(start BTS). Tento záznam je pak součásti standardního CDR. Je tedy logické, že takový údaj je k dispozici pouze v době šesti měsíců od aktivace/prvního hovoru na dané SIM kartě. V opačném případě, pokud by to mělo být interpretováno jako údaj, který se uchovává po neomezeně dlouhou dobu (celou životnost SIM karty), pak by bylo nutné toto první CDR z databáze vyjmout a zálohovat do nějaké separátní tabulky v rámci úložiště CDR. To by ale současně znamenalo překročení povolené maximální doby uchovávání provozního a lokalizačního údaje.
2 odst. 6 písm. e) údaje o všech přístupových bodech s uvedením jejich označení, popřípadě všech dalších používaných identifikátorů, dále geografických souřadnic v souřadnicovém systému WGS 84, azimutu směrování antén a slovního popisu umístění. 2, odst. 7. Údaje o času se podle této vyhlášky uchovávají a předávají v koordinovaném světovém čase UTC Není jasné, o jaké přístupové body se jedná. Navíc jsme toho názoru, že tento požadavek jde nad rámec standardu Evropské unie dle zaslané rozdílové tabulky. Jedná se o údaje o fyzické konfiguraci sítě. Doporučujeme úpravu znění odstavce :. Údaje o čase se uchovávají a předávají tak, jak je obvyklé u telekomunikačních operátorů a dle nastavení telekomunikačními operátory používaných systémů. V předávaném výpisu musí být uvedeno v jakém časovém pásmu je uvedený čas zaznamenán.. Odůvodnění: Tento požadavek jde nad rámec standardu Evropské unie dle zaslané rozdílové tabulky. 3 odst. 11 předávání údajů Navrhujeme upravit tak, že předávání údajů o VTA se převéde do režimu první věty 3 odst. 11, tj. na vyžádání. Odůvodnění: Jde o frekvenci předávání údajů o VTA ( 2 odst. 6 písm. a), která je v 3 odst. 11 stanovena ve druhé větě na 1x ročně. Při této frekvenci nemůžeme zaručit autentičnost údajů. Při navržené úpravě by se nepředávala databáze, ale jednotlivé údaje, ke kterým provozovatel zaručí autentičnost. 4 - Doba uchovávání předaných údajů Doba uchovávání předaných údajů Datový soubor nebo listinu obsahující údaje předané oprávněnému orgánu podle 3 provozovatel uchovává po dobu 12 měsíců ode dne předání. Pro možnost ověření autenticity předaných údajů i po uplynutí této doby uchovává provozovatel otisky datových souborů předaných bez uznávaného elektronického podpisu nebo uznávané elektronické značky po dobu 3 let ode dne jejich předání. Doporučujeme úpravu znění odstavce:. Datový soubor nebo listinu obsahující údaje předané oprávněnému orgánu podle 3 provozovatel uchovává po dobu 12 měsíců ode dne předání. Není jasné, co požaduje druhá věta. Navíc jsme názorů, že tento požadavek jde nad rámec standardu Evropské unie dle zaslané rozdílové tabulky.
6 Přechodné ustanovení Již v minulosti jsme navrhovali tuto lhůtu prodloužit. Je nutné ověřit, zda již nyní předávané formáty bude možno elektronicky podepsat nebo označit značkou. Jednání sice probíhají, ale my chceme sjednotit zadávání i výstupy u všech oprávněných subjektů a dosáhnou shod, což je vskutku komplikované. S pozdravem, Ing. Svatoslav Novák Prezident ICT UNIE o.s.