Kormányablak, Ügyfélkapu, magyarorszag.hu, kormany.hu
KORMÁNYABLAK, ÜGYFÉLKAPU - A ZÁRT AJTÓK MÖGÖTT...
(nem hivatalos e-kormányzati témájú oldal)
  
BEMUTATKOZÁS 
E-KÖZIGAZGATÁS 
IT BIZTONSÁG 
  
































  Mottó:
Senki sem tudja az igazi nevem,
Senki sem érezheti, ha szeretem.
/Zanzibár: Az igazi nevem/
2016. november 28.  
 GDPR: Ha nem elég a PR... 
   
Az Európai Unió leporolta a korábbi adatvédelmi direktívát (95/46/EC), hogy jogi értelemben megerősödve, rendeleti szinten egy új jogszabály jöjjön létre, a General Data Protection Regulation, azaz GDPR (2016/679/EU). A figyelem középpontjába elsősorban a hatalmas büntetési tételek miatt került: aki nem felel meg a leírtaknak, az "a vállalkozások esetében az előző pénzügyi év teljes éves világpiaci forgalmának" (azaz nem csak a nyereségnek, hanem a bevételnek!) legfeljebb 2%-át (vagy 10.000.000 EUR) vagy 4%-át (vagy 20.000.000 EUR) kitevő bírságot kaphat 2018. május 25. után.
GDPR (2016/679/EU)
Article 83
General conditions for imposing administrative fines
4. Infringements of the following provisions shall, in accordance with paragraph 2, be subject to administrative fines up to 10 000 000 EUR, or in the case of an undertaking, up to 2 % of the total worldwide annual turnover of the preceding financial year, whichever is higher [...].
5. Infringements of the following provisions shall, in accordance with paragraph 2, be subject to administrative fines up to 20 000 000 EUR, or in the case of an undertaking, up to 4 % of the total worldwide annual turnover of the preceding financial year, whichever is higher [...].
6. Non-compliance with an order by the supervisory authority as referred to in Article 58(2) shall, in accordance with paragraph 2 of this Article, be subject to administrative fines up to 20 000 000 EUR, or in the case of an undertaking, up to 4 % of the total worldwide annual turnover of the preceding financial year, whichever is higher.
Bár, bizonyos "kötelezettségek nem vonatkoznak a 250 főnél kevesebb személyt foglalkoztató vállalkozásra vagy szervezetre", ettől még mindenkinek érdemes megnéznie, hogy mire kell ezután figyelnie pl. egy rendszer üzemeltetésénél, egy termék tervezésénél, fejlesztésénél, esetleg hogy lehet a személyes adatok kezeléséből, feldolgozásából fakadó kockázatokat csökkenteni pl. tanúsítás révén (aminek "önkéntesnek kell lennie", viszont "bizonyítják, hogy az adatkezelő vagy adatfeldolgozó által végrehajtott adatkezelési műveletek megfelelnek e rendelet előírásainak", igaz, ettől még a "tanúsítás nem csökkenti az adatkezelő vagy adatfeldolgozó e rendelet betartásáért való felelősségét").
GDPR (2016/679/EU)
Article 30
Records of processing activities
5. The obligations referred to in paragraphs 1 and 2 shall not apply to an enterprise or an organisation employing fewer than 250 persons unless the processing it carries out is likely to result in a risk to the rights and freedoms of data subjects, the processing is not occasional, or the processing includes special categories of data as referred to in Article 9(1) or personal data relating to criminal convictions and offences referred to in Article 10.
GDPR (2016/679/EU)
Article 42
Certification
1. The Member States, the supervisory authorities, the Board and the Commission shall encourage, in particular at Union level, the establishment of data protection certification mechanisms and of data protection seals and marks, for the purpose of demonstrating compliance with this Regulation of processing operations by controllers and processors. The specific needs of micro, small and medium-sized enterprises shall be taken into account.
[...]
3. The certification shall be voluntary and available via a process that is transparent.
4. A certification pursuant to this Article does not reduce the responsibility of the controller or the processor for compliance with this Regulation and is without prejudice to the tasks and powers of the supervisory authorities which are competent pursuant to Article 55 or 56.
Mire is kell akkor figyelni pontosan a GDPR szerint? Van több téma (pl. a gyakran emlegetett újdonság, a törléshez, "az elfeledtetéshez való jog"), amit egy rendszernek valahogy biztosítania kell a személyes adatok kapcsán, de engem most kifejezetten azok érdekelnek, amik pontosabban vannak megfogalmazva, illetve kapcsolódnak a kriptográfiához.

Én ezeket a témákat találtam a "személyes adatok kezelésére vonatkozó elvek" között:
"A személyes adatok kezelését oly módon kell végezni, hogy megfelelő technikai vagy szervezési intézkedések alkalmazásával biztosítva legyen a személyes adatok megfelelő biztonsága, az adatok jogosulatlan vagy jogellenes kezelésével, véletlen elvesztésével, megsemmisítésével vagy károsodásával szembeni védelmet is ideértve ('integritás és bizalmas jelleg')."
"Az adatkezelő felelős az (1) bekezdésnek való megfelelésért, továbbá képesnek kell lennie e megfelelés igazolására ('elszámoltathatóság')."
GDPR (2016/679/EU)
Article 5
Principles relating to processing of personal data
1. Personal data shall be:
[...]
(f) processed in a manner that ensures appropriate security of the personal data, including protection against unauthorised or unlawful processing and against accidental loss, destruction or damage, using appropriate technical or organisational measures ('integrity and confidentiality').
2. The controller shall be responsible for, and be able to demonstrate compliance with, paragraph 1 ('accountability').
A követelmények pontosításaként a jogszabály előírja "a személyes adatok álnevesítését és titkosítását", "a személyes adatok kezelésére használt rendszerek és szolgáltatások folyamatos bizalmas jellegének biztosítását, integritását, rendelkezésre állását és ellenálló képességét", illetve "a továbbított, tárolt vagy más módon kezelt személyes adatok véletlen vagy jogellenes megsemmisítéséből, elvesztéséből, megváltoztatásából, jogosulatlan nyilvánosságra hozatalából vagy az azokhoz való jogosulatlan hozzáférésből" eredő problémák elleni védekezést is.

Lesz-e ennél részletesebb információ a rendszertervezők, fejlesztők számára? Hát, a GDPR-szakértők szerint nem érdemes másra várni, mert nincs tervben műszakibb jellegű végrehajtási rendeletek vagy műszaki specifikációk kiadása. A rendelet ezen előírásai alapján kell felkészíteni a rendszereket! Valahogy... Nézzük meg közelebbről a kriptográfiához is kapcsolódó követelményeket!
GDPR (2016/679/EU)
Article 32
Security of processing
1. Taking into account the state of the art, the costs of implementation and the nature, scope, context and purposes of processing as well as the risk of varying likelihood and severity for the rights and freedoms of natural persons, the controller and the processor shall implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk, including inter alia as appropriate:
(a) the pseudonymisation and encryption of personal data;
(b) the ability to ensure the ongoing confidentiality, integrity, availability and resilience of processing systems and services;
[...]
2. In assessing the appropriate level of security account shall be taken in particular of the risks that are presented by processing, in particular from accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to personal data transmitted, stored or otherwise processed.
Személyes adatok titkosítása
Ha "a személyes adatok álnevesítését és titkosítását" célzó követelményt nézzük, akkor felmerül a kérdés, hogy pontosan kivel szemben kell védeni az adatok bizalmasságát? Csak a személyes adatokat kezelő vagy feldolgozó oldal belső rendszergazdájától vagy a külső támadótól is, aki pl. SQL injection révén szerzi meg az adatbázis dump-ot? A kérdés fontos, hiszen ettől függ, hogy milyen módon kell alkalmazni a kriptográfiát! A belső rendszergazda - vagy egyéb, fájlrendszer szintjén hozzáférést szerző támadó - ellen elegendő lehet pl. adatbázisoknál a TDE (Transparent Data Encryption) alkalmazása. A valósidejű rejtjelezés és megfejtés az adatbázist használó alkalmazás elől rejtve marad, számára a működés transzparens, viszont a fájlrendszer szintjén rejtjelezetten tárolt állományokat találunk. A rejtjelezés megjelenhet több szinten is: pl. Oracle esetében lehetőség van csak egy adott tábla néhány - a személyes adatokat tároló - oszlopát védeni. A védendő adat rejtjelezése az adatbázisban tárolt szimmetrikus (pl. AES) kulccsal (pl. TDE Table Key) történik, míg az AES kulcsok rejtjelezésére biztonságos kulcstároló eszközben (pl. HSM) található aszimmetrikus (pl. RSA) kulcsot (pl. TDE Master Encryption Key) szoktak alkalmazni.
Microsoft SQL Server
Encryption of the database file is performed at the page level. The pages in an encrypted database are encrypted before they are written to disk and decrypted when read into memory. TDE does not increase the size of the encrypted database.
https://msdn.microsoft.com/en-us/library/bb934049.aspx
MySQL
MySQL Enterprise TDE enables data-at-rest encryption by encrypting the physical files of the database. Data is encrypted automatically, in real time, prior to writing to storage and decrypted when read from storage.
https://www.mysql.com/products/enterprise/tde.html
Oracle
TDE helps protect data stored on media (also called data at rest) in the event that the storage media or data file is stolen.
https://docs.oracle.com/database/121/ASOAG/asotrans.htm#ASOAG10117

Hogy történik a lekérdezés egy rejtjelezett oszlopon? Ha jön a hívó féltől egy pl. SELECT, akkor az adatbázis az RSA kulccsal megfejti az AES kulcsot, ezután az AES kulccsal megfejti az adott táblát vagy oszlopot, majd végrehajtja a lekérdezést, és az eredményt nyíltan adja vissza. Hmm, nyíltan adja vissza... Igen, muszáj neki, hiszen ettől lesz transzparens a működés a hívó fél számára. Viszont... Ebből az is következik, hogy ha jön a külső támadótól egy másodlagos lekérdezésben az SQL injection (pl. a jó, öreg UNION SELECT, miután egy egyszerű Google kereséssel találtunk az árulkodó hibaüzenetek révén egy sérülékeny adatbázist), nos... Az ellen nem véd!
When a user selects encrypted columns, Oracle Database 10g transparently retrieves the encrypted table key from the data dictionary, fetches the master key from the wallet, and decrypts the table key. Then the database decrypts the encrypted data on the disk and returns the clear text to the user.
http://www.oracle.com/technetwork/testcontent/o55security-100471.html
Mi ellen kell akkor védekezni? Szerencsére a választ a SIEM (Security Information and Event Management) fejlesztő cégek marketingesei adják meg közvetve. Azt állítják ugyanis (nem egy gyártónál olvasható ez), hogy a GDPR követelményeknek való megfeleléshez elegendő bekötni a SIEM rendszerüket (ld. Gartner Magic Quadrant). Ezek a rendszerek pedig a leírások szerint alkalmaznak az adatbázisoknál TDE (Transparent Data Encryption) funkciót, másféle rejtjelezésről viszont nem írnak az adatbázis kapcsán. Ha tehát hinni lehet a leírásoknak, akkor elegendő a személyes adatokat az adatbázisban a TDE (Transparent Data Encryption) funkció révén védeni, azaz nem kell külső támadó által végrehajtható SQL injection ellen készülni...

De pontosan mik a védendő személyes adatok? E rendelet alkalmazásában személyes adat az "azonosított vagy azonosítható természetes személyre ('érintett') vonatkozó bármely információ; azonosítható az a természetes személy, aki közvetlen vagy közvetett módon, különösen valamely azonosító, például név, szám, helymeghatározó adat, online azonosító vagy a természetes személy testi, fiziológiai, genetikai, szellemi, gazdasági, kulturális vagy szociális azonosságára vonatkozó egy vagy több tényező alapján azonosítható". Jellemzően tehát egy rendszernél a felhasználói törzsadatokat tároló részen kellene alkalmazni az adatbázis TDE (Transparent Data Encryption) funkcióját, hogy a név, a születési adatok, a lakcím, a kapcsolattartási adatok (e-mail cím, mobiltelefonszám, Facebook/Google azonosító stb.), a különböző okmányazonosítók és közigazgatási azonosítók, esetleg fényképek rejtjelezve tárolódjanak.
GDPR (2016/679/EU)
Article 4
Definitions
For the purposes of this Regulation:
(1) 'personal data' means any information relating to an identified or identifiable natural person ('data subject'); an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person;
2011. évi CXII. törvény
az információs önrendelkezési jogról és az információszabadságról
3. § E törvény alkalmazása során:
1. érintett: bármely meghatározott, személyes adat alapján azonosított vagy - közvetlenül vagy közvetve - azonosítható természetes személy;
2. személyes adat: az érintettel kapcsolatba hozható adat - különösen az érintett neve, azonosító jele, valamint egy vagy több fizikai, fiziológiai, mentális, gazdasági, kulturális vagy szociális azonosságára jellemző ismeret -, valamint az adatból levonható, az érintettre vonatkozó következtetés;
1992. évi LXVI. törvény
a polgárok személyi adatainak és lakcímének nyilvántartásáról
1. §
(1) E törvény célja, hogy meghatározza a polgárok személyi, lakcím és értesítési cím adatait tartalmazó nyilvántartás (a továbbiakban: nyilvántartás) működésének törvényes feltételeit.
[...]
(5) E törvény garanciális szabályokat állapít meg a nyilvántartásban kezelt adatok védelmére, valamint előírja az adatkezelés és a szolgáltatás ellenőrzésének kötelezettségét.
1996. évi XX. törvény
a személyazonosító jel helyébe lépő azonosítási módokról és az azonosító kódok használatáról
4. §
(4) Természetes személyazonosító adat a polgár
a) családi és utóneve, születési családi és utóneve,
b) születési helye,
c) születési ideje és
d) anyja születési családi és utóneve.
5. §
(1) Az azonosító kód olyan, matematikai módszerrel képzett, különleges adatra nem utaló számjegysor, amely a polgárt az adatkezelés során egyértelműen azonosítja.
(2) Az azonosító kód személyes adat, ezért azt kezelni és továbbítani csak törvényben meghatározott szabályok szerint lehet.
6. §
(1) Az adózással kapcsolatos nyilvántartás azonosító kódja az adóazonosító jel, melynek képzési szabályait a törvény 1. számú melléklete tartalmazza.
(2) Az egészségügyi, a szociális és a társadalombiztosítási és a magánnyugdíj rendszerrel kapcsolatos nyilvántartások azonosító kódja a Társadalombiztosítási Azonosító Jel (a továbbiakban: TAJ szám), melynek képzési szabályait a törvény 2. számú melléklete tartalmazza.
(3) A személyiadat- és lakcímnyilvántartás azonosító kódja a személyi azonosító, melynek képzési szabályait a törvény 3. számú melléklete tartalmazza.
Most, hogy ezt ilyen jó kitaláltuk, nincs is más dolgunk, mint rohanni a sarki boltba, venni egy HSM-et, összelőni az adatbázissal és beállítani a TDE (Transparent Data Encryption) kulcsokat a rendszerünk számára... Vagy legalább PKCS#12 állományként kérni egy kulcsot...

Rendszerek bizalmasságának és integritásának biztosítása
A rendszert futtató környezet, illetve maga a rendszer is tartalmazhat olyan védelmi mechanizmusokat, amelyek figyelik, hogy tényleg a gyártótól származó, nem módosított kódok futnak-e vagy sem. Lehet forráskódot letölteni és lenyomatokat (hash) ellenőrizni, majd legyártani (build) a binárisokat... Lehet binárisokat letölteni és a rajtuk levő digitális aláírást ellenőrizni, illetve visszavezetni a tanúsítványt (code signer certificate) egy megbízható pontig (trusted root CA)... De, ha valaki tudja, hogy pl. milyen a DLL-betöltési sorrend a Windows operációs rendszereken (még SafeDllSearchMode beállítása mellett is), akkor az tisztában van vele, hogy - ha van egy jó code signer certificate, akkor - egy "DLL injection" vagy "DLL preloading attack" kivitelezése - ami mondjuk csak annyit csinál, hogy a rajta átfolyó adatokat (akár a személyes adatokat is) kiírja egy naplóállományba - nem olyan problémás... A környezetre (pl. Windows operációs rendszerre) hagyatkozni nem elég, maga a Microsoft is azt ajánlja, hogy a rendszernek, alkalmazásnak kell, hogy legyen saját védelmi mechanizmusa is, pl. tartsa nyilván a saját, biztonságosnak ítélt moduljait lenyomatok (hash) szintjén, egy digitálisan aláírt listában (pl. Manifest XML, XMLDSIG DigestValue és Signature elemekkel), és - azt már én teszem hozzá, hogy - az ezen aláíráshoz használt kulcs ellenőrzését is maga végezze el, ne a környezet.
Important
If an attacker gains control of one of the directories that is searched, it can place a malicious copy of the DLL in that directory.
[...]
If SafeDllSearchMode is enabled, the search order is as follows:
1. The directory from which the application loaded.
2. The system directory. Use the GetSystemDirectory function to get the path of this directory.
3. The 16-bit system directory. There is no function that obtains the path of this directory, but it is searched.
4. The Windows directory. Use the GetWindowsDirectory function to get the path of this directory.
5. The current directory.
6. The directories that are listed in the PATH environment variable. Note that this does not include the per-application path specified by the App Paths registry key. The App Paths key is not used when computing the DLL search path.
https://msdn.microsoft.com/en-us/library/windows/desktop/ms682586(v=vs.85).aspx
Consider using DLL redirection or a manifest to ensure that your application uses the correct DLL.
https://msdn.microsoft.com/en-us/library/windows/desktop/ff919712(v=vs.85).aspx
ClickOnce uses an algorithmic hash of all the files in an application as a security check to ensure that none of the files were changed after deployment.
https://msdn.microsoft.com/en-us/library/9a30dzbz.aspx
A rendszer integritása nem csak a futtatható moduloknál, hanem a naplóknál is fontos, főleg azért, mert az elszámoltathatósághoz, az események utólagos rekonstruálásához szükség van kellően részletes, pontos és hiteles, sértetlen adatokra. A naplóbejegyzések részletessége és pontossága a rendszertől, alkalmazástól függ, a hitelességet és sértetlenséget viszont lehet fokozni kriptográfia segítségével. Persze, a kriptográfia nem tudja megakadályozni, hogy a naplóállományból teljes sorokat töröljenek (a BASH history kitakarításához hasonlóan), de legalább azonnal észlelhető a módosítás ténye, vagyis az, hogy az adatok pontossága, hitelessége nem megfelelő (peres eljárásnál ez fontos lehet). Szerencsére, a naplózásra vonatkozólag léteznek műszaki szabványok (IETF RFC 5424 - The Syslog Protocol), sőt, ezek kriptográfiával való védelme is megoldott (IETF RFC 5848 - Signed Syslog Messages), egy kis csavarással pedig - pl. legyen láncolt a digitális aláírás a naplóbejegyzéseken - a hiteles elszámoltathatósági követelmény teljesíthető is syslog segítségével (vagy azzal egyenértékű más - állományba vagy adatbázisba naplózó - megoldással is).

Továbbított adatokhoz való jogosulatlan hozzáférés
A személyes adatok biztonságos tárolását már az eddig elemzett követelmények lefedték, a személyes adatok biztonságos továbbítására vonatkozó követelményeknél pedig sok új dolgot nem biztos, hogy lehet mondani. A sértetlenséget és bizalmasságot biztosító kommunikációs csatornára jó lehet egy SSL/TLS réteg (pl. akár client/mutual authentication módban) a kommunikáló felek között. A személyes adatok feldolgozásának védelme lehet még egy kérdéses pont, főleg a mai, cloud-alapú világban. Ha a "feldolgozás" nem csupán "tárolást" jelent, hanem "műveletvégzést" is az adott adatokon, akkor arra az időre nyilván nyílttá kell tenni azokat, azaz meg fognak jelenni ilyen formában az adott környezetben (pl. ez lehet egy cloud-környezetben valamelyik virtuális gép memóriája, esetleg ideiglenes állomány a fájlrendszerben). Ezt a területet valószínűleg nem műszakilag kell lefedni, hanem jogilag, bár, ez valószínűleg jelenleg is így van megoldva (pl. minden olyan környezettel szükséges titoktartási nyilatkozat a kezelt, feldolgozott adatokra vonatkozólag, amelyeket adott rendszer igénybe vesz, sőt, eleve olyan "cross-border" szolgáltatásokra lehet csak építeni, amelyek megfelelnek a GDPR követelményeinek, tudva, hogy vannak kivételek is).
GDPR (2016/679/EU)
Article 4
Definitions
For the purposes of this Regulation:
(23) 'cross-border processing' means either:
(a) processing of personal data which takes place in the context of the activities of establishments in more than one Member State of a controller or processor in the Union where the controller or processor is established in more than one Member State; or
(b) processing of personal data which takes place in the context of the activities of a single establishment of a controller or processor in the Union but which substantially affects or is likely to substantially affect data subjects in more than one Member State.
GDPR (2016/679/EU)
Article 9
Processing of special categories of personal data
2. Paragraph 1 shall not apply if one of the following applies:
(i) processing is necessary for reasons of public interest in the area of public health, such as protecting against serious cross-border threats to health or ensuring high standards of quality and safety of health care and of medicinal products or medical devices, on the basis of Union or Member State law which provides for suitable and specific measures to safeguard the rights and freedoms of the data subject, in particular professional secrecy;
Ha pedig mindennel készen vagyunk, akkor nyugodt(abb)an várhatjuk 2018. május 25-ét.
GDPR (2016/679/EU)
Article 99
Entry into force and application
2. It shall apply from 25 May 2018.
Kapcsolódó anyagok:
 vissza 
   
  info@kormanyablak.org
info@ugyfelkapu.info