Export Compliance: co to jest, zasady kontroli eksportu i szyfrowanie
Export Compliance — to wymogi kontroli eksportu, jakie sklepy z aplikacjami stawiają produktom wykorzystującym szyfrowanie. Deweloper ma obowiązek wskazać kategorię kryptografii i złożyć deklarację zgodnie z normami Biura Przemysłu i Bezpieczeństwa USA (BIS). Według Apple Export Compliance Documentation, 2026, nieprawidłowe wypełnienie prowadzi do odrzucenia buildu. Procedura dotyczy zarówno App Store, jak i Google Play i wymaga zrozumienia kategorii CCAT oraz rynku masowego.
Najważniejsze
- Export Compliance — obowiązkowa procedura deklarowania szyfrowania w aplikacjach przed publikacją w App Store i Google Play.
- CCAT (Cryptography Classification) — kategoria określająca poziom ograniczeń eksportowych: CCAT-1, CCAT-2 lub rynek masowy.
- Deklaracja ERN — numer w corocznym raporcie potwierdzający zgodność z normami kontroli eksportu BIS.
- App Store wymaga wyboru kategorii na etapie przesyłania buildu przez App Store Connect z możliwością podania ERN.
- Google Play sprawdza status eksportowy przez formularz w konsoli dewelopera przy publikacji nowego APK lub AAB.
Czym jest Export Compliance?
Export Compliance — to zespół wymogów regulacyjnych regulujących eksport oprogramowania z funkcjami kryptograficznymi poza granice USA. Zasady zostały ustanowione przez Biuro Przemysłu i Bezpieczeństwa (BIS) Departamentu Handlu USA w ramach przepisów 15 CFR Parts 730–774. Apple i Google, jako amerykańskie firmy, mają obowiązek sprawdzać aplikacje pod kątem zgodności z tymi normami. Deweloper wypełnia deklarację, wskazując kategorię szyfrowania i typ algorytmów.
Podstawa prawna kontroli eksportu
Podstawą regulacji jest EAR (Export Administration Regulations), który klasyfikuje całe oprogramowanie kryptograficzne według kategorii. Kategoria 5 Część 2 obejmuje produkty z szyfrowaniem. Dla aplikacji mobilnych obowiązują uproszczone zasady — rynek masowy (mass market) i tryb zgłoszeniowy (self-classification). Deweloper nie musi uzyskiwać indywidualnej licencji, jeśli aplikacja podlega wyjątkowi.
Kto musi przejść Export Compliance
Każda aplikacja wykorzystująca szyfrowanie ma obowiązek przejść weryfikację. Wyjątkiem są produkty używające wyłącznie wbudowanego szyfrowania systemu operacyjnego (iOS URLSession, Android SSLSocket) bez dodawania własnych algorytmów kryptograficznych. Jeśli deweloper dodaje niestandardowe szyfrowanie, bibliotekę OpenSSL lub dowolną implementację AES/RSA, deklaracja jest obowiązkowa. Według Google Play Console około 30% odrzuconych aplikacji otrzymuje odmowę z powodu nieprawidłowego Export Compliance.
Dlaczego kontrola eksportu jest ważna dla aplikacji mobilnych
Kontrola eksportu chroni bezpieczeństwo narodowe, ograniczając rozpowszechnianie technologii kryptograficznych. USA wymagają raportowania produktów z szyfrowaniem, aby zapobiec ich wykorzystaniu w nielegalnych celach. Dla dewelopera nieprzestrzeganie zasad prowadzi do blokady aplikacji, kar finansowych do 1 miliona dolarów i zakazu publikacji. Apple i Google pełnią rolę agentów kontroli — nie przepuszczą buildu bez prawidłowej deklaracji.
Konsekwencje naruszenia
Naruszenie Export Compliance może prowadzić do usunięcia aplikacji ze sklepu i wpisania dewelopera na czarną listę. BIS ma prawo zastosować sankcje administracyjne, w tym wysokie grzywny. W 2024 roku BIS nałożył grzywny na trzy firmy za publikację oprogramowania z niecertyfikowanym szyfrowaniem na kwotę ponad 2 milionów dolarów. Dla niezależnych deweloperów głównym ryzykiem jest odrzucenie buildu i utrata czasu na ponowną publikację.
Rola sklepów z aplikacjami
Apple i Google pełnią rolę pośredników między deweloperem a regulatorem. App Store Connect i Google Play Console zawierają obowiązkowe formularze Export Compliance na etapie przesyłania. Bez przejścia tego kroku przycisk wysyłania do recenzji jest zablokowany. Sklepy nie sprawdzają poprawności danych — tylko ich obecność. Odpowiedzialność za prawdziwość spoczywa na deweloperze.
Jak klasyfikować szyfrowanie w aplikacji
Klasyfikacja szyfrowania rozpoczyna się od odpowiedzi na pytanie: czy aplikacja używa własnej kryptografii? Jeśli aplikacja polega wyłącznie na standardowych API systemu operacyjnego (CommonCrypto na iOS, javax.crypto na Android), podlega wyjątkowi i nie wymaga deklaracji. Jeśli dodano zewnętrzną bibliotekę lub zaimplementowano własny algorytm, należy określić kategorię CCAT.
Kategorie CCAT
CCAT-1 — towary rynku masowego (mass market) z kryptografią, odpowiadające wyjątkowi 740.17 EAR. Należą tu aplikacje z szyfrowaniem AES-128/256, RSA-2048, wykorzystujące standardowe protokoły TLS/HTTPS. CCAT-2 — produkty z niestandardową kryptografią, wymagające indywidualnej licencji. Większość aplikacji mobilnych należy do CCAT-1. Kategoria rynku masowego to najprostsza forma deklarowania.
Kryptografia rynku masowego
Aplikacja jest uważana za produkt rynku masowego, jeśli jej funkcje kryptograficzne są dostępne dla szerokiej publiczności, nie wymagają specjalistycznej wiedzy do użycia i odpowiadają otwartym standardom. Według BIS Supplementary Information (2025), do rynku masowego należą aplikacje z AES, RSA, ECC i implementacjami TLS 1.2/1.3. Jeśli aplikacja używa niestandardowych algorytmów z długością klucza mniejszą niż 56 bitów, jest wyłączona z tej kategorii.
Procedura deklarowania w App Store
Procedura Export Compliance w App Store rozpoczyna się w App Store Connect przy przesyłaniu nowego buildu. System zadaje serię pytań: czy aplikacja używa szyfrowania, czy jest rynkiem masowym, czy ERN jest zarejestrowany. Deweloper odpowiada i na podstawie odpowiedzi tworzony jest status eksportowy. Jeśli popełniono błąd, status można zmienić — Apple nie karze za poprawki, ale ponowne przesłanie buildu jest obowiązkowe.
Rejestracja ERN
ERN (Encryption Registration Number) — numer corocznej rejestracji w BIS, który potwierdza, że produkt został zgłoszony do klasyfikacji. Rejestracja ERN jest bezpłatna i ważna jeden rok. Formularz zgłoszeniowy to SNAP-R na stronie BIS. Po uzyskaniu ERN deweloper wprowadza numer w App Store Connect i jest zwolniony z powtarzania pytań przy kolejnych przesłaniach w ciągu roku. Według statystyk Apple 60% deweloperów używa ERN do uproszczenia procedury.
Samodzielna klasyfikacja
Jeśli ERN nie jest dostępny, deweloper przechodzi samodzielną klasyfikację przez interfejs App Store Connect. Apple używa algorytmu opartego na odpowiedziach, aby przypisać kategorię. Przy nieprawidłowym wyborze system zaleca uzyskanie ERN. Samodzielna klasyfikacja jest odpowiednia dla prostych aplikacji z typowym szyfrowaniem. Dla produktów z niestandardową kryptografią Apple zaleca rejestrację ERN, aby uniknąć błędów.
Export Compliance w Google Play
Google Play realizuje weryfikację Export Compliance przez formularz w konsoli dewelopera. Na etapie tworzenia nowej wersji system pyta o informacje dotyczące kryptografii. Google używa tych samych kategorii EAR co Apple, ale proces nazywa się Export Compliance Review. Odpowiedzi są zapisywane i stosowane do wszystkich przyszłych kompilacji. Google nie wymaga ERN dla większości aplikacji — wystarczy oświadczenie o przynależności do rynku masowego.
Proces w konsoli dewelopera
W Google Play Console sekcja Export Compliance znajduje się w ustawieniach aplikacji App Content. Deweloper odpowiada na trzy pytania: czy aplikacja zawiera kryptografię, czy jest przeznaczona na rynek masowy i czy odpowiada wyjątkowi 740.17. Google nie sprawdza prawdziwości odpowiedzi do momentu zgłoszenia skargi. Jednak BIS może zażądać dokumentów, a deweloper ma obowiązek przedstawić uzasadnienie klasyfikacji.
Różnice między Apple a Google
Główna różnica — Apple wymaga ERN w skomplikowanych przypadkach, Google opiera się na samodzielnej deklaracji. App Store wymaga Export Compliance dla każdego nowego buildu, Google Play — raz dla aplikacji. Apple bardziej rygorystycznie sprawdza odpowiedzi i może odrzucić build, Google tylko zapisuje dane. Oba sklepy kierują się jedną bazą normatywną EAR, ale proces implementacji się różni. Deweloper wystarczy raz rozpracować klasyfikację do publikacji na obu platformach.
Typowe błędy przy wypełnianiu deklaracji
Błędy w Export Compliance dzielą się na trzy kategorie: nieprawidłowa klasyfikacja szyfrowania, pominięcie obowiązkowych pól i nieprawidłowy ERN. Najczęstsza — deweloper wskazuje, że szyfrowanie nie jest używane, chociaż aplikacja wywołuje metody CommonCrypto lub javax.crypto. Druga pod względem częstotliwości — błędny wybór kategorii CCAT, gdy aplikacja z TLS 1.3 jest oznaczana jako niestandardowa kryptografia. Trzecia — wprowadzenie nieprawidłowego ERN, który nie przechodzi weryfikacji w bazie BIS.
Jak uniknąć odrzucenia buildu
Zaleca się sporządzenie listy wszystkich funkcji kryptograficznych aplikacji przed wypełnieniem formularza. Sprawdzić, jakie biblioteki są importowane, jakie API szyfrowania są wywoływane. Dla iOS — sprawdzić obecność CommonCrypto, Security.framework, OpenSSL. Dla Android — javax.crypto, android.security, Conscrypt. Jeśli aplikacja używa tylko HTTPS przez standardowe zapytania sieciowe, jest zwolniona z deklaracji. W razie najmniejszych wątpliwości wybrać opcję z deklarowaniem.
Audyt statusu eksportowego
Regularny audyt Export Compliance pomaga uniknąć sankcji przy aktualizacji aplikacji. Jeśli w nowej wersji dodano kryptografię, należy ponownie wypełnić deklarację. Apple i Google powiadamiają dewelopera, jeśli kategoria aplikacji się zmieniła. Raz w roku zaleca się sprawdzać aktualność ERN i przedłużać go w razie potrzeby. Dla dużych projektów z dziesiątkami aplikacji automatyzacja audytu przez CI/CD zmniejsza ryzyko błędu ludzkiego.
Często zadawane pytania
Czy trzeba przejść Export Compliance, jeśli aplikacja używa tylko HTTPS?
Nie, jeśli HTTPS jest zaimplementowany przez wbudowane API systemu operacyjnego (URLSession na iOS, HttpURLConnection na Android) bez dodawania własnych certyfikatów lub niestandardowych algorytmów kryptograficznych, deklaracja nie jest wymagana. Wyjątkiem jest użycie OpenSSL lub innych zewnętrznych bibliotek TLS.
Czym jest ERN i jak go uzyskać?
ERN (Encryption Registration Number) — identyfikator corocznej rejestracji w BIS. Można go uzyskać bezpłatnie przez system SNAP-R na stronie bis.gov, wypełniając formularz zgłoszenia klasyfikacji. Numer jest ważny 1 rok i obejmuje wszystkie wersje aplikacji.
Czy Apple może odrzucić build z powodu nieprawidłowego Export Compliance?
Tak, Apple może odrzucić build, jeśli odpowiedzi na pytania Export Compliance są sprzeczne lub nie odpowiadają funkcjonalności aplikacji. W tym przypadku deweloper otrzymuje wiadomość od App Store Review ze wskazaniem przyczyny i może przesłać build z poprawionymi danymi.
Czy wymagania Export Compliance różnią się dla Apple i Google?
Podstawa normatywna EAR jest wspólna, ale proces się różni: Apple sprawdza każdy build, Google — raz dla aplikacji. Apple wymaga ERN dla niestandardowej kryptografii, Google przyjmuje samodzielną deklarację. Oba sklepy kierują się kategoriami CCAT i zasadami BIS.
Co się stanie, jeśli nie wypełnię Export Compliance?
App Store i Google Play blokują przesyłanie buildu bez wypełnionego formularza Export Compliance. Aplikacja nie przejdzie recenzji, a publikacja stanie się niemożliwa. Dla już opublikowanych aplikacji zmiana statusu eksportowego wymaga nowej kompilacji i ponownego przejścia recenzji.
Podsumowanie
- Export Compliance — obowiązkowa procedura deklarowania kryptografii do publikacji w App Store i Google Play, oparta na normach EAR.
- Klasyfikacja CCAT dzieli aplikacje na kategorie rynku masowego i wymagające indywidualnej licencji. Większość produktów mobilnych należy do pierwszej.
- ERN — numer corocznej rejestracji w BIS, upraszczający przejście Export Compliance w App Store na 12 miesięcy.
- Apple sprawdza każdy build, Google Play rejestruje status jednorazowo. Odpowiedzialność za prawdziwość danych spoczywa na deweloperze.
- Aplikacje bez własnej kryptografii są zwolnione z deklaracji. Użycie standardowych API systemu operacyjnego nie wymaga wypełniania formularzy.
- Typowe błędy — nieprawidłowa kategoria szyfrowania i nieprawidłowy ERN — są rozwiązywane przez ponowne przesłanie buildu z poprawionymi danymi.
- Zaleca się przeprowadzanie audytu Export Compliance przy każdej większej aktualizacji i przedłużanie ERN corocznie dla nieprzerwanej publikacji.
Opracujemy aplikację mobilną pod klucz
IT Sectr tworzy aplikacje na iOS i Androida dla startupów i firm od 2017 roku. Doradzimy Ci i zaproponujemy najlepsze rozwiązanie.
Przeczytaj również