Bezpečnosť mobilnej aplikácie: kam ukladať údaje, ako ich šifrovať a ako chrániť API

01Rýchla odpoveď: čo má bezpečná aplikácia spĺňať

02Prečo na tom záleží aj na Slovensku

Internet v mobile používa podľa Eurostatu 84,6 % Slovákov vo veku 16 až 74 rokov. Internetbanking v roku 2025 využívalo 60,5 % ľudí, čo je pod priemerom Európskej únie (69,7 %). Pri službách, ktoré ľudia v mobile ešte len začínajú používať, môže jeden únik údajov dôveru rýchlo pokaziť.

Národný bezpečnostný úrad v roku 2025 evidoval 1 650 nahlásených kybernetických incidentov, približne o 40 % viac než rok predtým. Časť nárastu možno podľa úradu pripísať legislatívnym zmenám, viac hlásení teda automaticky neznamená nebezpečnejší kybernetický priestor (NBÚ).

Mobilné aplikácie sú priamym cieľom. SK-CERT v septembri 2025 upozornil na škodlivé aplikácie pre Android, ktoré cielia na český a slovenský trh. Po inštalácii si vypýtajú povolenie na funkciu Prístupnosť, sledujú obrazovku, čítajú schránku a v českej verzii bankovej aplikácie George samy klikajú a schvaľujú prevody (SK-CERT). NBÚ zase opisuje útok z apríla 2025, pri ktorom útočníci cez falošné hlasovanie vylákali overovací kód a spárovali si účet WhatsApp obete so svojím zariadením (NBÚ).

03Kde mobilné aplikácie zlyhávajú najčastejšie

Bežne používaný prehľad rizík je OWASP Mobile Top 10. Aktuálne vydanie je z roku 2024 a vyzerá takto (OWASP):

1. Nesprávne zaobchádzanie s prihlasovacími údajmi, napríklad heslá a kľúče zapísané priamo v aplikácii.
2. Slabé zabezpečenie dodávateľského reťazca, teda knižníc a SDK tretích strán.
3. Nedostatočné overovanie a riadenie oprávnení.
4. Nedostatočná kontrola vstupov a výstupov.
5. Nezabezpečená komunikácia.
6. Slabá ochrana súkromia.
7. Nedostatočná ochrana binárneho kódu proti rozobratiu a úpravám.
8. Chybná konfigurácia.
9. Nezabezpečené ukladanie údajov.
10. Nedostatočná kryptografia.

Aké časté sú chyby v praxi, ukazujú automatizované testy. Firma NowSecure v roku 2023 preverila takmer 6 500 populárnych aplikácií a 95 % z nich neprešlo aspoň jednou z vtedajších siedmich oblastí štandardu OWASP MASVS (NowSecure). Berte to s rezervou: NowSecure testovanie sama predáva a za „neprešlo“ považuje akýkoľvek nález svojho nástroja, nie preukázaný útok.

04Ukladanie údajov v telefóne: čo kam patrí

Najjednoduchšie pravidlo znie: čo aplikácia v telefóne mať nemusí, tam nepatrí. Každý údaj navyše je údaj, ktorý môže uniknúť zo strateného telefónu, zo zálohy alebo cez škodlivú aplikáciu. Čo tam byť musí, napríklad prihlasovací token, patrí do trezoru, ktorý ponúka systém.

iPhone a iPad

• Keychain je určený na heslá, tokeny a kľúče. Pre citlivé položky sa hodí voľba „len toto zariadenie“, pri ktorej je položka dostupná len pri odomknutom telefóne a neprenesie sa na iné zariadenie (Apple).
• UserDefaults slúžia len na nastavenia. Apple výslovne píše, že systém ich ukladá na disk nešifrovane a osobné ani citlivé údaje sem nepatria (Apple).
• Súbory chráni Data Protection. Predvolená trieda však súbor sprístupní po prvom odomknutí telefónu a nechá ho dostupný až do reštartu, aj keď je displej zamknutý. Pre citlivé súbory má dodávateľ nastaviť najprísnejšiu triedu NSFileProtectionComplete (Apple).

Android

• Android Keystore drží šifrovacie kľúče tak, že sa z telefónu nedajú vytiahnuť. Ani útočník so skompromitovaným systémom ich nedostane von, hoci ich na samotnom zariadení môže zneužiť (Android Developers). Tokeny a citlivé údaje sa šifrujú kľúčom z Keystore.
• EncryptedSharedPreferences v nových projektoch už nepoužívajte. Google celú knižnicu Jetpack Security Crypto v roku 2025 označil za zastaranú a odporúča namiesto nej systémové rozhrania a priamu prácu s Android Keystore. Ďalšie verzie knižnice už podľa Googlu nevyjdú (Android Developers). Návody z rokov 2019 až 2024 ju pritom stále odporúčajú.
• Zálohy: Android predvolene zálohuje údaje aplikácií na Disk Google. Citlivé údaje má dodávateľ zo záloh vyradiť, radí Google (Android Developers). Pri aplikáciách, ktoré cielia na Android 12 a novší, nestačí len vypnúť zálohovanie, na niektorých telefónoch stále funguje prenos údajov na nové zariadenie (Android Developers).

Snímky obrazovky a schránka

Keď aplikáciu prepnete do pozadia, systém si uloží snímku jej obrazovky pre prepínač aplikácií. Ak je na nej číslo karty alebo kód, zostane v tom obrázku (OWASP MASWE-0038). V Androide to rieši príznak FLAG_SECURE, ktorý zablokuje snímky obrazovky aj prenos obrazu na iný displej (Android Developers). Malvér, pred ktorým varoval SK-CERT, vedel nahrávať obrazovku aj čítať a meniť obsah schránky, takže čísla účtov a kódy by aplikácia nemala do schránky kopírovať (SK-CERT).

05Šifrovanie pri prenose: HTTPS bez výnimiek

V iPhone stráži šifrované spojenie App Transport Security. Je zapnutá predvolene, vyžaduje TLS 1.2 alebo novšie a nešifrované spojenie zablokuje (Apple). Vývojár ju môže vypnúť kľúčom NSAllowsArbitraryLoads, pri schvaľovaní v App Store to však musí zdôvodniť (Apple). Práve vypnutú App Transport Security vytkol český úrad NÚKIB v júli 2025 aplikácii DeepSeek, spolu so zastaraným šifrovaním 3DES a citlivými údajmi obnoviteľnými z vyrovnávacej pamäte (NÚKIB).

Od Androidu 9 je nešifrovaná komunikácia predvolene zablokovaná pre všetky aplikácie, ktoré cielia na Android 9 alebo novší. Povoliť ju možno len výslovne v konfigurácii aplikácie (Android Developers). Pri kontrole hotovej aplikácie sa oplatí hľadať v kóde práve tieto výnimky.

Certificate pinning: áno, alebo nie?

Pinning znamená, že aplikácia verí len konkrétnemu certifikátu alebo kľúču vášho servera. Chráni pred podvrhnutým certifikátom, ale nesie riziko: keď na serveri certifikát alebo certifikačnú autoritu zmeníte, aplikácia sa prestane pripájať, kým si používatelia nenainštalujú aktualizáciu. Google preto pinning pri aplikáciách pre Android výslovne neodporúča. Ak ho dodávateľ použije, má mať záložné kľúče, aspoň jeden pod vašou plnou kontrolou, a krátku platnosť (Android Developers). Hodí sa najmä pre bankovníctvo a podobne citlivé aplikácie, bežný e-shop ho zvyčajne nepotrebuje.

06API kľúč v aplikácii nie je tajomstvo

Kľúč zapísaný v kóde aplikácie vidí každý, kto aplikáciu rozoberie. Google to píše bez okolkov: útočník s nástrojmi na spätné inžinierstvo taký kľúč získa veľmi ľahko (Android Developers). Obfuskácia ani šifrovanie kľúča vo vnútri aplikácie to nezmenia, podľa OWASP vytiahnutie kľúča len zdržia (OWASP MASWE-0004).

Ako to vyzerá v praxi, zmerali výskumníci z Viedenskej univerzity. Prešli 10 331 aplikácií, ktoré existujú pre Android aj iOS, a 10 164 možných kľúčov z verzií stiahnutých v roku 2023 naozaj vyskúšali. Funkčných prístupov bolo 416, medzi nimi 13 prístupov ku Gitu, ktoré otvárali 2 440 súkromných repozitárov so zdrojovým kódom. Platný kľúč obsahovalo 1,94 % aplikácií pre Android a 2,83 % pre iOS (Leaky Apps, ACM CCS 2025).

Druhé poučenie zo štúdie je nepríjemnejšie: vývojári kľúč z novej verzie aplikácie odstránia, ale často ho zabudnú zneplatniť. Aplikácia Viber mala podľa štúdie vo verzii pre Android z roku 2023 prístupové údaje k AWS priamo v natívnej knižnici. Vo verzii z roku 2024 už neboli, ale stále fungovali (Leaky Apps). Staršia analýza Symantecu z roku 2022 našla 1 859 aplikácií s prihlasovacími údajmi k AWS priamo v kóde a 53 % z nich používalo rovnaké kľúče ako iné aplikácie, pretože pochádzali zo zdieľaných knižníc a SDK tretích strán (Symantec).

Čo s kľúčmi robiť

• Firebase: kľúč obmedzený na služby Firebase tajný byť nemusí. Údaje chránia pravidlá Firebase Security Rules a App Check, nie utajenie kľúča. Výnimkou je kľúč pre Gemini API, ten do aplikácie nepatrí nikdy (Firebase). Pravidlo „čítať a zapisovať môže ktokoľvek“ znamená, že údaje môže čítať, meniť aj mazať každý, kto uhádne ID projektu (Firebase).
• Mapy a iné verejné kľúče: obmedziť na názov balíka a odtlačok certifikátu (Android) alebo identifikátor aplikácie (iOS). Pozor, v mobilnej aplikácii sa kľúč vymení až vtedy, keď si ju používatelia aktualizujú, a to môže trvať mesiace (Google Maps Platform).
• Platby, umelá inteligencia, e-maily, SMS: tajné kľúče k plateným službám patria len na váš server. Aplikácia volá váš server a ten až potom volá službu.
• Uniknutý kľúč nestačí odstrániť z novej verzie. Treba ho hneď zneplatniť a vydať nový.

Únikom kľúčov cez balíky a vývojárske nástroje sa podrobne venujeme v článku API kľúče a útoky cez npm.

07Ochrana API: prihlásenie, tokeny a kontrola oprávnení

Mobilná aplikácia je len okno do vášho servera. Útočník ju vôbec nemusí používať, stačí mu poslať rovnaké požiadavky na API iným nástrojom. Každé pravidlo, ktoré má platiť, preto musí vynucovať server.

Prihlásenie podľa štandardu

• Prihlásenie cez OAuth 2.0 má v mobilných aplikáciách prebiehať v systémovom prehliadači, nie vo WebView vnútri aplikácie. Odporúčaný postup IETF RFC 8252 to zakazuje formuláciou MUST NOT a zároveň vyžaduje rozšírenie PKCE (RFC 8252, RFC 7636).
• Novšie odporúčanie RFC 9700 z januára 2025 požaduje, aby obnovovacie tokeny verejných klientov boli buď viazané na zariadenie, alebo sa pri každom použití menili (rotácia). Prihlasovanie, pri ktorom aplikácia posiela meno a heslo priamo autorizačnému serveru (password grant), zakazuje úplne (RFC 9700).
• Prístupové tokeny majú mať krátku platnosť a len oprávnenia, ktoré aplikácia naozaj potrebuje.

Kontrola, čie údaje používateľ číta

Na prvé miesto v rebríčku rizík API zaraďuje OWASP chybu so skratkou BOLA (Broken Object Level Authorization) a označuje ju za veľmi rozšírenú. Server síce overí, že je používateľ prihlásený, ale už neskontroluje, či objednávka č. 1043 patrí práve jemu. Stačí potom v požiadavke zmeniť číslo a čítate cudzie údaje. OWASP odporúča kontrolovať oprávnenie v každej funkcii, ktorá siaha do údajov podľa ID od používateľa (OWASP API1:2023).

Učebnicovým príkladom je Peloton. V roku 2021 jeho API vracalo súkromné údaje používateľov aj neprihláseným. Prvá „oprava“ len pridala povinné prihlásenie, takže rovnaké údaje videl ďalej každý, kto si založil účet (Pen Test Partners). Prihlásenie nenahrádza kontrolu oprávnení.

Obmedzenie počtu požiadaviek a overenie aplikácie

API má obmedzovať počet požiadaviek, aby sa dalo zabrániť hádaniu hesiel, hromadnému sťahovaniu údajov aj nečakaným faktúram za platené služby (OWASP API4:2023). Ako doplnok možno overovať, že požiadavka prichádza z vašej nezmenenej aplikácie na skutočnom zariadení: v Androide cez Play Integrity API, v iOS cez App Attest. Obe firmy však upozorňujú, že nejde o samostatnú ochranu. Google odporúča Play Integrity kombinovať s ďalšími signálmi (Android Developers) a Apple píše, že App Attest skompromitovaný systém spoľahlivo nerozpozná (Apple). Staršia služba SafetyNet Attestation od januára 2025 nefunguje vôbec (Android Developers).

Ako prepájať aplikáciu s ďalšími systémami cez API, opisujeme v článku Prepojenie systémov cez API.

08Biometria, ktorá sa dá obísť

Prihlásenie odtlačkom prsta alebo tvárou pôsobí bezpečne, ale záleží na tom, ako je naprogramované. Ak aplikácia len čaká na odpoveď „overené“ a podľa nej pustí používateľa ďalej, útočník s kontrolou nad aplikáciou túto odpoveď podvrhne. OWASP to vedie ako samostatnú slabinu (OWASP MASWE-0020).

Správne riešenie viaže biometriu na kryptografický kľúč. V iPhone sa položka v Keychain odomkne len po overení Face ID alebo Touch ID priamo v bezpečnostnom čipe (Apple), v Androide sa používa BiometricPrompt s objektom CryptoObject (Android Developers). O tom, či používateľ smie vykonať citlivú akciu, má navyše vždy rozhodnúť server.

09Obfuskácia a ochrana proti úpravám

Obfuskácia sťažuje čítanie kódu. V Androide ju robí nástroj R8, ktorý hlavne skracuje názvy tried a metód a zmenšuje aplikáciu (Android Developers). Proti skúsenému útočníkovi je to len zdržanie, tajomstvo to neochráni.

Ochrana proti rozobratiu, úpravám a spúšťaniu na rootnutom telefóne má zmysel pri bankovníctve, platbách, hrách o peniaze alebo aplikáciách s cenným obsahom. OWASP pre ňu má samostatný testovací profil MAS-R, v ktorom je útočníkom sám používateľ zariadenia (OWASP). Pri bežnej firemnej aplikácii sú peniaze lepšie investované do servera a testov.

10Čo sa stane, keď sa to podcení

V júli 2025 unikli údaje americkej aplikácie Tea, ktorá má ženám pomáhať s bezpečnosťou pri zoznamovaní. Podľa vyhlásenia firmy útočník získal asi 72 000 obrázkov, z toho približne 13 000 selfie a fotografií dokladov z overenia účtu. Ležali v starom úložisku, ktoré sa pri prechode na nový systém nepresunulo (Tea, archív vyhlásenia). Používatelia 4chanu, ktorých cituje 404 Media, ho opísali ako verejne prístupné úložisko vo Firebase bez prihlásenia (404 Media). O pár dní neskôr sa objavila druhá databáza s 1,1 milióna súkromných správ, ku ktorej sa podľa výskumníka dostal ktorýkoľvek prihlásený používateľ (BleepingComputer).

Z úniku vyplývajú štyri pravidlá, ktoré platia pre každú aplikáciu: ukladať len nevyhnutné údaje, doklady po overení mazať, cloudové úložisko nikdy nenechať verejné a pri migrácii staré úložisko zrušiť.

Na Slovensku prijal Úrad na ochranu osobných údajov v roku 2025 celkovo 177 oznámení o porušení ochrany osobných údajov, o 45 % viac než rok predtým. Najčastejšou príčinou bol kybernetický útok, najmä ransomware (ÚOOÚ SR).

Podľa tej istej správy 53 % firiem zasiahnutých únikom nemalo citlivé údaje šifrované zároveň pri ukladaní aj pri prenose (IBM). Ako zabezpečiť údaje na strane servera a čo robiť pri úniku, rozoberáme v článku Bezpečnosť dát v systéme na mieru.

11Čo hovoria zákony: GDPR a Cyber Resilience Act

GDPR

Článok 32 GDPR ukladá prevádzkovateľovi aj sprostredkovateľovi zaviesť zabezpečenie primerané riziku a ako príklady uvádza „pseudonymizáciu a šifrovanie osobných údajov“ a „proces pravidelného testovania, posudzovania a hodnotenia účinnosti“ opatrení. Článok 25 („Špecificky navrhnutá a štandardná ochrana údajov“) vyžaduje, aby sa štandardne spracúvali len údaje nevyhnutné na daný účel (GDPR). Za porušenie týchto dvoch článkov hrozí pokuta do 10 miliónov eur alebo 2 % celosvetového obratu, podľa toho, ktorá suma je vyššia (čl. 83 ods. 4).

Cyber Resilience Act

Nariadenie (EÚ) 2024/2847 o kybernetickej odolnosti, skrátene CRA, sa týka aj mobilných aplikácií. Bod 11 odôvodnenia výslovne hovorí, že ak aplikácia potrebuje prístup k API alebo databáze poskytovanej cez službu, ktorú vyvinul výrobca, patrí pod nariadenie aj táto služba (CRA). Výrobcom je pritom aj firma, ktorá si aplikáciu dala vyvinúť a ponúka ju pod svojím menom, a to aj bezplatne (čl. 3 bod 13). Ak teda zadávate aplikáciu agentúre, povinnosti výrobcu podľa CRA ponesiete spravidla vy, nie agentúra.

• Od 11. 9. 2026 musí výrobca hlásiť aktívne zneužívané zraniteľnosti: do 24 hodín včasné varovanie, do 72 hodín oznámenie a do 14 dní od sprístupnenia opravy alebo zmierňujúceho opatrenia záverečnú správu (čl. 14). Platí to aj pre aplikácie, ktoré už sú v obchodoch (Európska komisia).
• Od 11. 12. 2027 sa nariadenie uplatňuje celé, vrátane základných požiadaviek na bezpečnosť v prílohe I a podpory aktualizáciami spravidla aspoň 5 rokov (čl. 13 a 71). Na aplikácie vydané pred týmto dátumom sa tieto požiadavky vzťahujú až pri podstatnej zmene (čl. 69).
• Väčšina aplikácií patrí do predvolenej kategórie, pri ktorej stačí posúdenie samotným výrobcom (Európska komisia).
• Pokuty za porušenie základných požiadaviek alebo povinnosti hlásiť môžu dosiahnuť 15 miliónov eur alebo 2,5 % celosvetového obratu, podľa toho, ktorá suma je vyššia (čl. 64).

Slovenský zákon č. 69/2018 Z. z. o kybernetickej bezpečnosti po novele 366/2024 Z. z., účinnej od 1. 1. 2025, sa týka prevádzkovateľov základných služieb, nie každej aplikácie (zákon 69/2018 Z. z.). Ak však aplikáciu objednáva regulovaná firma, musí bezpečnostné požiadavky premietnuť do zmluvy s dodávateľom. Pohľad vedenia firmy na NIS2 a CRA zhŕňa článok Bezpečnosť aplikácie pre vedenie.

12Pravidlá App Store a Google Play

• Apple: od 1. 5. 2024 App Store Connect neprijme aplikáciu, ktorá v súbore PrivacyInfo.xcprivacy nezdôvodní použitie vybraných systémových rozhraní (Required Reason API). Tieto rozhrania by sa dali zneužiť na identifikáciu zariadenia alebo používateľa podľa odtlačku (fingerprinting), čo Apple zakazuje (Apple).
• Google Play: od 31. 8. 2026 musia nové aplikácie a aktualizácie cieliť na Android 16 (API 36), odklad možno získať do 1. 11. 2026 (Google Play). Ani drobná oprava chyby sa tak nezaobíde bez zvýšenia cieľovej verzie aplikácie na Android 16, čo môže znamenať úpravy kódu a ďalšie testovanie. Prečo počítať s pravidelnými aktualizáciami, vysvetľujeme v článku Aktualizácia mobilnej aplikácie po spustení.
• Sekciu Bezpečnosť údajov v Google Play musí vyplniť každý vývojár, aj keď aplikácia žiadne údaje nezbiera. Formulár sa pýta aj na šifrovanie prenosu a na možnosť požiadať o vymazanie údajov (Google Play).
• Odznak nezávislej bezpečnostnej kontroly v Google Play dostane aplikácia, ktorú preverí autorizované laboratórium v programe MASA podľa štandardu OWASP. Je dobrovoľný, hradí ho vývojár a certifikácia platí 365 dní (App Defense Alliance). Správnosť údajov v sekcii Bezpečnosť údajov však overovať nemusí (Google Play).

13Ako bezpečnosť overiť a koľko to stojí

Meradlom je štandard OWASP MASVS. Aktuálna verzia 2.1.0 z januára 2024 má 24 kontrol v ôsmich oblastiach: ukladanie údajov, kryptografia, prihlásenie, sieť, práca so systémom, kód, odolnosť a súkromie (OWASP MASVS). Niekdajšie „úrovne“ L1, L2 a R už v štandarde nie sú, presunuli sa do testovacích profilov v príručke MASTG (OWASP):

Verejný slovenský cenník penetračného testu mobilnej aplikácie sme nenašli, slovenské firmy cenu stanovujú individuálne. Pre predstavu: Všeobecná zdravotná poisťovňa v roku 2020 vyhlásila zákazku na rámcovú dohodu na penetračné testovanie mobilnej aplikácie a webových služieb, teda na viacero testov, s predpokladanou hodnotou 54 827,25 € (Josephine). Nemecká firma AWARE7 uvádza za test jednej platformy (iOS alebo Android) 5 000 až 15 000 € pri dennej sadzbe 1 350 € bez DPH (AWARE7). Test zadávajte nezávislej firme, nie tímu, ktorý aplikáciu napísal, a opravy nechajte overiť opakovaným testom.

S bezpečnosťou je dobré počítať už v rozpočte a harmonograme. Ako u nás vyzerá vývoj krok za krokom, nájdete na stránke Ako to prebieha, orientačné ceny v cenníku. Rozhodujete sa ešte medzi natívnou a multiplatformovou aplikáciou? Pomôže článok Natívna, alebo multiplatformová aplikácia.

14Čo požadovať od dodávateľa: kontrolný zoznam

• Zoznam údajov, ktoré aplikácia ukladá v telefóne, a kde presne ich ukladá.
• Tokeny v Keychain, v Androide šifrované kľúčom z Android Keystore, žiadne EncryptedSharedPreferences v nových projektoch.
• Žiadne tajné kľúče v aplikácii, kontrola nástrojom typu gitleaks v repozitári a preverenie rozbalenej produkčnej verzie aplikácie.
• Len HTTPS, žiadne NSAllowsArbitraryLoads ani povolená nešifrovaná komunikácia v Androide.
• Prihlásenie cez systémový prehliadač s PKCE, rotácia obnovovacích tokenov, krátka platnosť prístupových tokenov.
• Kontrola oprávnení na serveri pri každom zázname, obmedzenie počtu požiadaviek.
• Pravidlá Firebase alebo inej cloudovej databázy skontrolované pred spustením, žiadny verejný prístup.
• Citlivé obrazovky skryté v prepínači aplikácií, citlivé údaje mimo záloh a schránky.
• Penetračný test podľa OWASP MASVS a opakovaný test po opravách.
• Postup na hlásenie zraniteľností podľa CRA a plán aktualizácií na niekoľko rokov dopredu.

Ak aplikáciu prevádzkujete a nie ste si istí, ako na tom je, začnite auditom toho, čo ukladá v telefóne, a kontrolou API. Pre samotných používateľov sme spísali návod Ako zabezpečiť telefón a účty.

15Časté otázky

16Zdroje

• OWASP Mobile Top 10 2024, OWASP MASVS 2.1.0, MAS Testing Profiles, OWASP API Security Top 10 2023
• Apple: UserDefaults, Data Protection, Keychain, App Transport Security, App Attest
• Apple: Required Reason API
• Google: Android Keystore, Jetpack Security Crypto, Network Security Config, Play Integrity, cieľová úroveň API, Firebase API kľúče
• IETF: RFC 8252, RFC 7636, RFC 9700
• Štúdie: Leaky Apps, Viedenská univerzita 2025, Symantec 2022, NowSecure 2023
• Štúdie: IBM Cost of a Data Breach 2026
• Právo: GDPR, Cyber Resilience Act, zákon 69/2018 Z. z.
• Slovensko: NBÚ, správa 2025, ÚOOÚ SR, správa 2025, SK-CERT, NÚKIB, varovanie DeepSeek, VšZP, zákazka
• Štatistika: Eurostat, dátové súbory isoc_ci_dev_i, isoc_ci_ac_i a isoc_ec_ib20