Poziom obrony x1. Klasyfikacja narzędzi bezpieczeństwa informacji z fstek i fsb rosji

Dla wielu ekspertów wymagania FSB wciąż pozostają zagadką. Dlaczego to się dzieje?

• Opcjonalne użycie szyfrowania przez operatorów.
• Trudne do zrozumienia podstawa normatywna.
• Brak wyjaśnień do dokumentów przez regulatora.
• Strach operatorów przed dodatkowymi kontrolami podczas korzystania z kryptografii.

Ale pomimo wszystkich trudności, ochrona kryptograficzna niezbędne przy przekazywaniu danych osobowych niezabezpieczonym kanałem komunikacji, co obejmuje np. Praca zdalna pracowników posiadających bazę klientów, wymianę informacji pomiędzy oddziałami a centralą, przekazywanie danych osobowych pracowników podmiotom trzecim. W takiej czy innej formie takie zadania są obecne w prawie każdej organizacji.

Przyjrzyjmy się ogólnie ramom regulacyjnym w tej kwestii. Istnieją trzy główne dokumenty dotyczące kryptograficznej ochrony danych osobowych w Federacji Rosyjskiej:

1. Wytyczne dotyczące zapewnienia bezpieczeństwa danych osobowych za pomocą narzędzi kryptograficznych, gdy są one przetwarzane w systemach informatycznych danych osobowych za pomocą narzędzi automatyzacji, zatwierdzone przez kierownictwo 8. Centrum FSB Rosji w dniu 21 lutego 2008 r. Nr 149 / 54 -144 -
2. Standardowe wymagania dotyczące organizacji i zapewnienia funkcjonowania narzędzi szyfrujących (kryptograficznych) przeznaczonych do ochrony informacji niezawierających informacji stanowiących tajemnica państwowa, jeśli są wykorzystywane w celu zapewnienia bezpieczeństwa danych osobowych podczas ich przetwarzania w systemach informatycznych danych osobowych ”, zatwierdzone przez kierownictwo 8. Centrum FSB Rosji w dniu 21 lutego 2008 r. Nr 149/6/6-622 - Dokument nie został oficjalnie opublikowany.
3. Zarządzenie Federalnej Służby Bezpieczeństwa nr 378 z dnia 10 lipca 2014 r. „W sprawie zatwierdzenia składu i treści środków organizacyjnych i technicznych zapewniających bezpieczeństwo danych osobowych, gdy są one przetwarzane w systemach informatycznych danych osobowych z wykorzystaniem kryptograficznych narzędzi ochrony informacji niezbędnych do spełniają wymogi ochrony danych osobowych ustalone przez Rząd Federacji Rosyjskiej dla każdego z poziomów bezpieczeństwa”. Zarejestrowany w Ministerstwie Sprawiedliwości Rosji 18 sierpnia 2014 r.

Dokument został przyjęty już w czasach „starych” dokumentów FSTEC („cztery księgi”, 58. Zakon, 781 Dekretów Rządowych) i uzupełniał ich treść. Należy zauważyć, że przedmiotowy dokument normatywny nie został zarejestrowany w Ministerstwie Sprawiedliwości, a dziś jego status jest niejasny. Najprawdopodobniej w związku z publikacją Rozporządzenia 378 Wytyczne straciły na aktualności. Chciałbym jednak pokrótce omówić treść dokumentu, aby było jasne, jak historycznie ewoluowały wymagania dotyczące systemów szyfrowania.

Wymogi powyższego dokumentu (a także innych przepisów z zakresu ochrony kryptograficznej PD) nie dotyczą następujących przypadków:

• Przetwarzanie danych osobowych bez użycia narzędzi automatyzacji;
• Praca z danymi osobowymi stanowiącymi tajemnicę państwową;
• Stosowanie środki techniczne zlokalizowane poza Federacją Rosyjską.

Dokument mówi, że w przypadku korzystania z narzędzi ochrony kryptograficznej konieczne jest opracowanie modelu zagrożenia zgodnie z wymaganiami zarówno FSTEC, jak i FSB (z rzadkimi wyjątkami). Operatorzy mogą sami tworzyć modele zagrożeń i intruza, tylko w razie potrzeby, przyciągając licencjobiorców z FSB. Wszystkie zagrożenia w dokumencie zostały podzielone na ataki i zagrożenia, które nie są atakami, podano przykłady typowych zagrożeń. Możesz kierować się Metodologią jako materiałem referencyjnym podczas pisania modelu dla nowych wymagań.

Model zagrożeń najwyższego poziomu określa charakterystykę zabezpieczeń PD i innych chronionych obiektów. W szczegółowym modelu zagrożeń wskazano wymagane warunki kryptoochrony.

Na model zagrożenia wpływają różne czynniki: warunki tworzenia i używania PD, formy prezentacji PD, cechy bezpieczeństwa itp.

Oprócz zwykłych cech wyróżnia się również integralność, poufność i dostępność, niezaprzeczalność, księgowość, autentyczność i adekwatność.

Przykładowy model zagrożeń najwyższego poziomu:

1. Zagrożenie poufności danych osobowych.
2. Zagrożenie integralności danych osobowych.
3. Zagrożenie dostępności danych osobowych.

Dokument poświęcony jest nie tylko stworzeniu modelu zagrożenia, ale także specyfice tworzenia odpowiedniego modelu intruza. Wszystkie naruszenia w Wytycznych dzielą się na dwie klasy: bezpośrednie i pośrednie naruszenia bezpieczeństwa danych osobowych (zagrożenia stwarzające warunki do powstania zagrożeń bezpośrednich). Istnieje 6 głównych typów przestępców: H1, H2, H3, H4, H5, H6. Im wyższa liczba, tym więcej możliwości, przestępca każdego kolejnego typu dziedziczy zdolności poprzedniego. Operator samodzielnie określa poziom wyszkolenia sprawców, dostępne im narzędzia i przyjmuje założenie o zmowie. Dokument wskazuje główne cechy intruza każdego typu. Zdefiniowano również 6 poziomów krypto-ochrony: KC1, KC2, KC3, KB1, KB2, KA1 i 6 klas krypto-środków o podobnych nazwach, nic się w tym zakresie nie zmieniło do dziś. ISPD są również podzielone na 6 klas, w zależności od najwyższej kategorii sprawcy. AK1 - jeśli najwyższą kategorią sprawcy jest H1, AK2 - jeśli H2, AK3 - jeśli H3, AK4 - jeśli H4, AK5 - jeśli H5, AK6 - jeśli H6. Środki kryptoochrony są odpowiednio rozdzielone: ​​AK1 - KS1, AK2 - KS2, AK3 - KS3, AK4 - KV1, AK5 - KV2, AK6 - KA1.

Typowe wymagania

Standardowe wymagania zostały napisane w tym samym okresie co Wytyczne, nie są zarejestrowane w Ministerstwie Sprawiedliwości, a ich status jest dziś niejasny. Moim zdaniem dokument zawiera przydatne informacje do nauki. Obowiązki użytkowników narzędzi kryptograficznych zostały szczegółowo opisane, wskazano główne dla nich zasady:

• zapobiec kopiowaniu kluczowych informacji;
• nie ujawniaj informacji o kluczach;
• nie nagrywaj na kluczowych nośnikach obce informacje itp.

Opisano proces niszczenia klucza, przedstawiono główne wymagania dotyczące lokalu. standardowe formularze czasopisma. Na podstawie informacji zawartych w dokumencie można zbudować przydatne instrukcje.

Zamówienie 378

Cała społeczność zawodowa czekała na wydanie Rozkazu 378, a teraz wreszcie wszedł on w życie. Na dzień dzisiejszy jest to główny dokument z zakresu kryptograficznej ochrony danych osobowych, a jego skutek dotyczy wszystkich ISPD, które jako ochronę stosują kryptograficzne IPS. Zamówienie określa wymagania nie tylko ochrony kryptograficznej, ale także reżimu zapewnienia bezpieczeństwa pomieszczeń, procedury przechowywania nośników informacji i innych środków organizacyjnych w zależności od poziomu bezpieczeństwa systemu. Oddzielnie wskazano, że operator powinien używać sprzętu do ochrony informacji, który przeszedł ocenę zgodności - certyfikowany zgodnie z wymogami bezpieczeństwa. Bardzo szczegółowo opisano środki ochronne, w tym wymagania dotyczące wyposażenia pomieszczeń (zamki, plomby, kraty okienne itp.). W przeciwieństwie do przepisów zalecenia metodologiczne w Rozporządzeniu 378 klasa CIPF jest określana w odniesieniu do poziomu bezpieczeństwa i rzeczywistego rodzaju zagrożeń. Możliwości napastnika są brane pod uwagę tylko przy określaniu klasy CIPF dla 4 poziomu bezpieczeństwa.

Tabela 1. Klasa CIPF

Zależność od poziomu bezpieczeństwa i rodzaju zagrożeń jest dość oczywista i jak widzimy, operator prawie zawsze może wybrać klasę ochrony informacji kryptograficznej spośród kilku opcji.

Dokument wyróżnia przejrzysta logika prezentacji - wystarczy znać poziom bezpieczeństwa swojego systemu - wymagania dla ISPD każdego poziomu przedstawione są w osobnych sekcjach. Należy zauważyć, że wymagania są dziedziczone z poziomów niższych na wyższe, ISPD poziomu bezpieczeństwa 1 musi spełniać wymagania dla poziomu 2, 3 i 4 ISPD. Moim zdaniem nawet początkującemu specjaliście nie będzie trudno poradzić sobie z wymaganiami nowego Zakonu.

Oczywiście w jednym krótkim artykule nie da się określić wszystkich niuansów kryptograficznej ochrony danych osobowych i czy jest to konieczne? Przeanalizowaliśmy tutaj główne punkty, zrozumieliśmy logikę dokumentów, reszta to szczegóły, które możesz samodzielnie przestudiować. A w piątej części nie mniej istotne kwestie zostaną rozważone: określenie wymagań dla systemu ochrony danych osobowych oraz wybór środków ochrony.

Wymagania dotyczące bezpieczeństwa informacji w projektowaniu systemów informatycznych wskazują na cechy charakteryzujące stosowane środki ochrony informacji. Określają je różne akty regulatorów w zakresie świadczenia bezpieczeństwo informacji, w szczególności - FSTEC i FSB Rosji. To, jakie istnieją klasy bezpieczeństwa, rodzaje i rodzaje narzędzi ochronnych, a także gdzie można dowiedzieć się więcej na ten temat, znajduje odzwierciedlenie w artykule.

Wstęp

Kwestie zapewnienia bezpieczeństwa informacji są dziś przedmiotem szczególnej uwagi, ponieważ technologie wprowadzane wszędzie bez bezpieczeństwa informacji stają się źródłem nowych poważnych problemów.

FSB Rosji donosi o powadze sytuacji: kwota szkód wyrządzonych przez cyberprzestępców na przestrzeni kilku lat na całym świecie wahała się od 300 miliardów do 1 biliona dolarów. Według informacji Prokuratora Generalnego Federacji Rosyjskiej tylko w pierwszym półroczu 2017 r. liczba przestępstw z zakresu wysokich technologii w Rosji wzrosła sześciokrotnie, łączna kwota szkód przekroczyła 18 mln USD. w atakach ukierunkowanych w sektorze przemysłowym w 2017 r. odnotowano na całym świecie. W szczególności w Rosji wzrost liczby ataków w porównaniu z 2016 r. wyniósł 22%.

Technologie informacyjne zaczęto wykorzystywać jako broń do celów wojskowo-politycznych, terrorystycznych, do ingerowania w wewnętrzne sprawy suwerennych państw, a także do popełniania innych przestępstw. Federacja Rosyjska opowiada się za stworzeniem międzynarodowego systemu bezpieczeństwa informacji.

Na terenie Federacji Rosyjskiej właściciele informacji i operatorzy systemów informatycznych mają obowiązek blokować próby nieautoryzowanego dostępu do informacji, a także na bieżąco monitorować stan bezpieczeństwa infrastruktury informatycznej. Jednocześnie ochrona informacji jest zapewniona poprzez zastosowanie różnych środków, w tym technicznych.

Narzędzia bezpieczeństwa informacji lub narzędzia bezpieczeństwa informacji zapewniają ochronę informacji w systemach informatycznych, które są zasadniczo połączeniem informacji przechowywanych w bazach danych, technologii informatycznych zapewniających ich przetwarzanie oraz środków technicznych.

Nowoczesne systemy informatyczne charakteryzują się wykorzystaniem różnych platform sprzętowych i programowych, terytorialnym rozmieszczeniem komponentów, a także interakcją z otwartymi sieciami transmisji danych.

Jak chronić informacje w takich warunkach? Odpowiednie wymagania są ustalane przez upoważnione organy, w szczególności FSTEC i FSB Rosji. W ramach artykułu postaramy się odzwierciedlić główne podejścia do klasyfikacji systemów bezpieczeństwa informacji z uwzględnieniem wymagań tych regulatorów. Inne sposoby opisu klasyfikacji obiektów bezpieczeństwa informacji, odzwierciedlone w dokumentach regulacyjnych departamentów rosyjskich, a także organizacji i agencji zagranicznych, wykraczają poza zakres tego artykułu i nie są dalej rozważane.

Artykuł może być przydatny dla początkujących w dziedzinie bezpieczeństwa informacji jako źródło uporządkowanych informacji o metodach klasyfikacji informacji dotyczących bezpieczeństwa informacji w oparciu o wymagania FSTEC Rosji (w większym stopniu) i krótko FSB Rosji .

Strukturą, która określa procedurę i koordynuje działania w zakresie dostarczania niekryptograficznych metod bezpieczeństwa informacji, jest FSTEC Rosji (dawniej Państwowa Komisja Techniczna przy Prezydencie Federacji Rosyjskiej, Państwowa Komisja Techniczna).

Gdyby czytelnik musiał zobaczyć państwowy rejestr certyfikowanych narzędzi bezpieczeństwa informacji, który jest tworzony przez FSTEC Rosji, to z pewnością zwrócił uwagę na obecność w opisowej części celu zabezpieczenia informacji takich fraz jak „klasa RD SVT”, „poziom braku NDV” itp. (Rysunek 1).

Rysunek 1. Fragment rejestru certyfikowanych obiektów ochrony informacji

Klasyfikacja kryptograficznych środków ochrony informacji

FSB Rosji definiuje następujące klasy kryptograficznych narzędzi bezpieczeństwa informacji: KS1, KS2, KS3, KB i KA.

Do głównych cech klasy SZI KS1 należy ich odporność na ataki przeprowadzane spoza strefy kontrolowanej. Oznacza to, że tworzenie metod ataku, ich przygotowanie i implementacja odbywa się bez udziału specjalistów z zakresu rozwoju i analizy narzędzi kryptograficznego bezpieczeństwa informacji. Zakłada się, że informacje o systemie, w którym wykorzystywane są te narzędzia bezpieczeństwa informacji, można uzyskać z otwartych źródeł.

Jeżeli kryptograficzny IPS może wytrzymać ataki blokowane za pomocą klasy CS1, a także przeprowadzane w strefie kontrolowanej, to taki IPS odpowiada klasie CS2. Jednocześnie zakłada się np., że w trakcie przygotowywania ataku mogą stać się dostępne informacje o fizycznych środkach ochrony systemów informatycznych, udostępnieniu strefy kontrolowanej itp.

Jeśli możliwe jest odparcie ataków w obecności dostęp fizyczny do funduszy Informatyka z zainstalowanym zabezpieczeniem informacji kryptograficznej oznacza, że ​​środki te odpowiadają klasie KS3.

Jeżeli obiekt bezpieczeństwa informacji kryptograficznej odpiera ataki, w których stworzenie zaangażowani byli specjaliści w opracowywanie i analizę tych narzędzi, w tym ośrodki badawcze, możliwe było przeprowadzenie badań laboratoryjnych narzędzi ochronnych, to mówimy o zgodności z klasą KV.

Jeżeli w opracowywanie metod ataku zaangażowani byli specjaliści z zakresu wykorzystania oprogramowania systemu NDV, dostępna była odpowiednia dokumentacja projektowa i był dostęp do dowolnych elementów sprzętowych obiektów bezpieczeństwa informacji kryptograficznej, to narzędzia klasy KA mogą zapewnić ochronę przed takimi atakami.

Klasyfikacja środków ochrony podpisu elektronicznego

Budynków podpis elektroniczny w zależności od wytrzymałości na ataki zwyczajowo porównuje się z klasami: KS1, KS2, KS3, KV1, KV2 i KA1. Ta klasyfikacja jest podobna do tej omówionej powyżej w odniesieniu do kryptograficznego IPS.

wnioski

W artykule rozważono kilka sposobów klasyfikacji bezpieczeństwa informacji w Rosji, które opierają się na ramach regulacyjnych regulatorów w dziedzinie ochrony informacji. Rozważane opcje klasyfikacji nie są wyczerpujące. Niemniej jednak mamy nadzieję, że przedstawione zestawienie informacji pozwoli początkującemu specjaliście w dziedzinie bezpieczeństwa informacji na szybką nawigację.

Sposoby kryptograficznej ochrony informacji o klasach ochrony KS2 i KS1 zgodnie z wymaganiami Federalnej Służby Bezpieczeństwa Rosji różnią się faktycznymi możliwościami źródeł ataków oraz środkami podejmowanymi w celu przeciwdziałania atakom.

1. Aktualne możliwości źródeł ataków

Narzędzia ochrony informacji kryptograficznej (CIPF) klasy KS1 są wykorzystywane z rzeczywistymi możliwościami źródeł ataków, a mianowicie do samodzielnego tworzenia metod ataku, przygotowywania i przeprowadzania ataków tylko poza strefą kontrolowaną.

1. samodzielnie tworzyć metody ataków, przygotowywać i przeprowadzać ataki tylko poza strefą kontrolowaną;
2. samodzielnie tworzyć metody ataku, przygotowywać i przeprowadzać ataki w strefie kontrolowanej, ale bez fizycznego dostępu do sprzętu, na którym zaimplementowany jest system ochrony informacji kryptograficznej i ich środowisko operacyjne (SF).

Tym samym CIPF klasy KS2 różni się od KS1 w zakresie neutralizacji rzeczywistą zdolnością źródeł ataków do samodzielnego tworzenia metod ataku, przygotowywania i przeprowadzania ataków w strefie kontrolowanej, ale bez fizycznego dostępu do sprzętu, na którym CIPF i SF są realizowane.

2. Wersje w klasie ochrony CIPF KS3, KS2 i KS1

Opcja 1 to podstawowe oprogramowanie CIPF zapewniające klasę ochrony KS1.

Opcja 2 to CIPF klasy KS2, składający się z podstawowego CIPF klasy KS1 wraz z certyfikowanym modułem sprzętowo-programowym zaufany boot(APMDZ).

Wariantem 3 jest CIPF klasy KS3, który składa się z CIPF klasy KS2 wraz ze specjalistycznym oprogramowaniem do tworzenia i kontrolowania zamkniętego środowiska programowego.

Tym samym oprogramowanie CIPF klasy KS2 różni się od KS1 tylko dodaniem certyfikowanego APMDZ do CIPF klasy KS1. Różnice CIPF klasy KS3 od klasy KS1 polega na zastosowaniu CIPF klasy KS1 wraz z certyfikowanym APMDZ oraz specjalistycznym oprogramowaniem do tworzenia i kontrolowania zamkniętego środowiska programowego. A także różnicą pomiędzy CIPF klasy KS3 a KS2 jest zastosowanie CIPF klasy KS2 wraz ze specjalizowanym oprogramowaniem do tworzenia i sterowania zamkniętym środowiskiem programowym.

Oprogramowanie ViPNet SysLocker (1.0 z dnia 28.03.2016) to darmowe, specjalistyczne oprogramowanie do tworzenia i kontrolowania zamkniętego środowiska programowego.

3. Środki przeciwdziałania atakom

CIPF klasa KS2 nie stosuje środków do przeciwdziałania atakom, które są obowiązkowe dla działania CIPF klasy KS1, a mianowicie:

1. zatwierdziła listę osób uprawnionych do wstępu do lokalu;
2. zatwierdzono wykaz osób uprawnionych do wstępu do pomieszczeń, w których znajduje się CIPF;
3. zatwierdziła zasady dostępu do pomieszczeń, w których znajduje się CIPF, w godzinach pracy i poza godzinami pracy, a także w sytuacjach awaryjnych;
4. dostęp do kontrolowanego obszaru i pomieszczeń, w których znajdują się zasoby systemów informatycznych danych osobowych (ISPD) i (lub) CIPF, jest zapewniony zgodnie z reżimem kontroli dostępu;
5. informacja o środkach ochrony fizycznej obiektów, w których znajdują się ISPD, jest dostępna dla ograniczonego kręgu pracowników;
6. dokumentacja do CIPF jest przechowywana przez osobę odpowiedzialną za CIPF w metalowym sejfie (szafie);
7. pomieszczenia, w których znajduje się dokumentacja komponentów CIPF, CIPF i SF, wyposażone są w drzwi wejściowe z zamkami, zapewniające, że drzwi lokalu są na stałe zamknięte i otwierane tylko dla upoważnionego przejścia;
8. przedstawiciele służb technicznych, konserwacyjnych i innych usług pomocniczych podczas pracy w pomieszczeniach (regałach), w których znajduje się CIPF, oraz pracownicy, którzy nie są użytkownikami CIPF, przebywają w tych pomieszczeniach tylko w obecności pracowników operacyjnych;
9. pracownicy będący użytkownikami ISPD, ale nie będący użytkownikami CIPF, są informowani o zasadach pracy w ISPD i odpowiedzialności za nieprzestrzeganie zasad zapewnienia bezpieczeństwa informacji;
10. Użytkownicy CIPF są informowani o zasadach pracy w ISPD, zasadach pracy z CIPF oraz odpowiedzialności za nieprzestrzeganie zasad zapewnienia bezpieczeństwa informacji;
11. rejestracja i rozliczanie działań użytkownika z danymi osobowymi;
12. monitorowana jest integralność narzędzi bezpieczeństwa informacji.

Środki kryptograficznej ochrony informacji, w skrócie CIPF, służą do zapewnienia kompleksowej ochrony danych przesyłanych liniami komunikacyjnymi. W tym celu konieczne jest przestrzeganie autoryzacji i ochrony podpisu elektronicznego, uwierzytelnianie komunikujących się stron protokołami TLS i IPSec, a także ochrona samego kanału komunikacji, jeśli to konieczne.

W Rosji zastosowanie środki kryptograficzne Bezpieczeństwo informacji jest w dużej mierze tajne, dlatego niewiele jest publicznie dostępnych informacji na ten temat.

Metody stosowane w CIPF

• Autoryzacja danych i zapewnienie bezpieczeństwa ich znaczenia prawnego podczas przesyłania lub przechowywania. W tym celu wykorzystywane są algorytmy do tworzenia podpisu elektronicznego i jego weryfikacji zgodnie z ustalonymi przepisami RFC 4357 oraz korzystają z certyfikatów zgodnych ze standardem X.509.
• Ochrona poufności danych i kontrola ich integralności. Stosowane jest szyfrowanie asymetryczne i ochrona przed imitacją, czyli przeciwdziałanie fałszowaniu danych. Zgodny z GOST R 34.12-2015.
• Ochrona oprogramowania systemowego i aplikacyjnego. Śledzenie nieautoryzowanych zmian lub usterek.
• Zarządzanie najważniejszymi elementami systemu w ścisłej zgodności z przyjętymi przepisami.
• Uwierzytelnianie stron wymieniających dane.
• Ochrona połączenia za pomocą protokołu TLS.
• Ochrona połączeń IP z wykorzystaniem protokołów IKE, ESP, AH.

Metody zostały szczegółowo opisane w dokumentach: RFC 4357, RFC 4490, RFC 4491.

Mechanizmy CIPF do ochrony informacji

1. Poufność przechowywanych lub przesyłanych informacji jest chroniona za pomocą algorytmów szyfrowania.
2. Podczas nawiązywania połączenia identyfikacja jest realizowana za pomocą podpisu elektronicznego używanego podczas uwierzytelniania (zgodnie z zaleceniami X.509).
3. Cyfrowy obieg dokumentów jest również chroniony podpisem elektronicznym wraz z ochroną przed nałożeniem lub powtórzeniem, a także monitorowana jest wiarygodność kluczy służących do weryfikacji podpisów elektronicznych.
4. Integralność informacji zapewnia podpis cyfrowy.
5. Korzystanie z funkcji szyfrowania asymetrycznego pomaga chronić dane. Ponadto do sprawdzania integralności danych można wykorzystać funkcje mieszające lub algorytmy ochrony przed imitacją. Metody te nie obsługują jednak ustalania autorstwa dokumentu.
6. Występuje ochrona powtórek funkcje kryptograficzne podpis elektroniczny do szyfrowania lub ochrony imitacyjnej. Jednocześnie do każdej sesji sieciowej dodawany jest unikalny identyfikator, wystarczająco długi, aby wykluczyć jego przypadkowy zbieg okoliczności, a weryfikację przeprowadza strona odbierająca.
7. Ochronę przed nałożeniem, czyli przenikaniem do komunikacji z zewnątrz, zapewnia podpis elektroniczny.
8. Inna ochrona - przed zakładkami, wirusami, modyfikacjami system operacyjny itp. - dostarczane za pomocą różnych narzędzi kryptograficznych, protokołów bezpieczeństwa, oprogramowania antywirusowego i środków organizacyjnych.

Jak widać, algorytmy podpisu elektronicznego są fundamentalną częścią środków ochrony informacji kryptograficznej. Zostaną one omówione poniżej.

Wymagania dotyczące korzystania z CIPF

CIPF ma na celu ochronę (poprzez weryfikację podpisu elektronicznego) otwartych danych w różnych publicznych systemach informacyjnych oraz zapewnienie ich poufności (poprzez weryfikację podpisu elektronicznego, ochronę przed imitacją, szyfrowanie, weryfikację hashowania) w sieciach korporacyjnych.

Do ochrony danych osobowych użytkownika stosuje się osobiste środki ochrony informacji kryptograficznej. Na szczególną uwagę zasługują jednak informacje dotyczące tajemnicy państwowej. Zgodnie z prawem CIPF nie może być używany do pracy z nim.

Ważne: przed zainstalowaniem CIPF, pierwszym krokiem jest sprawdzenie samego pakietu oprogramowania CIPF. To pierwszy krok. Zazwyczaj integralność pakietu instalacyjnego jest weryfikowana przez porównanie sum kontrolnych otrzymanych od producenta.

Po instalacji należy określić poziom zagrożenia, na podstawie którego można określić rodzaje niezbędnej do użytkowania ochrony informacji kryptograficznej: oprogramowanie, sprzęt oraz sprzęt-oprogramowanie. Należy również pamiętać, że organizując niektóre CIPF, należy wziąć pod uwagę lokalizację systemu.

Klasy ochrony

Zgodnie z rozporządzeniem FSB Rosji z dnia 10 lipca 2014 r. nr 378, regulującym stosowanie kryptograficznych środków ochrony informacji i danych osobowych, określono sześć klas: KS1, KS2, KS3, KB1, KB2, KA1. Stopień ochrony dla konkretnego systemu jest określany na podstawie analizy danych o modelu intruza, czyli z oceny możliwe sposoby hakowanie systemu. Ochrona w tym przypadku jest zbudowana z oprogramowania i sprzętowej ochrony informacji kryptograficznej.

AC (rzeczywiste zagrożenia), jak widać z tabeli, są 3 rodzaje:

1. Zagrożenia pierwszego typu są związane z nieudokumentowanymi funkcjami oprogramowania systemowego używanego w System informacyjny.
2. Zagrożenia drugiego typu są związane z nieudokumentowanymi funkcjami oprogramowania użytkowego używanego w systemie informatycznym.
3. Zagrożenie trzeciego typu nazywa się całą resztą.

Nieudokumentowane funkcje to funkcje i cechy oprogramowania, które nie są opisane w oficjalnej dokumentacji lub jej nie odpowiadają. Oznacza to, że ich użycie może zwiększyć ryzyko naruszenia poufności lub integralności informacji.

Dla jasności rozważ modele osób naruszających zasady, do przechwycenia których potrzebna jest ta lub inna klasa narzędzi do ochrony informacji kryptograficznych:

• KS1 - intruz działa z zewnątrz, bez pomocników wewnątrz systemu.
• KS2 jest wtajemniczonym, ale nie ma dostępu do CIPF.
• KS3 to insider, który jest użytkownikiem CIPF.
• KV1 - intruz, który przyciąga zasoby stron trzecich, takich jak specjaliści CIPF.
• KV2 to intruz, za którego działaniami stoi instytut lub laboratorium zajmujące się badaniem i rozwojem narzędzi ochrony informacji kryptograficznej.
• KA1 - służby specjalne państw.

W ten sposób KS1 można nazwać podstawową klasą ochrony. W związku z tym im wyższa klasa ochrony, tym mniej specjalistów jest w stanie ją zapewnić. Na przykład w Rosji według danych za 2013 r. tylko 6 organizacji posiadało certyfikat FSB i było w stanie zapewnić ochronę klasy KA1.

Używane algorytmy

Rozważ główne algorytmy używane w narzędziach do ochrony informacji kryptograficznych:

• GOST R 34.10-2001 i zaktualizowany GOST R 34.10-2012 - algorytmy tworzenia i weryfikacji podpisu elektronicznego.
• GOST R 34.11-94 i najnowszy GOST R 34.11-2012 - algorytmy tworzenia funkcji skrótu.
• GOST 28147-89 i nowsze GOST R 34.12-2015 - implementacja algorytmów szyfrowania danych i ochrony przed imitacją.
• Dodatkowe algorytmy kryptograficzne znajdują się w RFC 4357.

Podpis elektroniczny

Nie można sobie wyobrazić wykorzystania narzędzi ochrony informacji kryptograficznej bez wykorzystania algorytmów podpisu elektronicznego, które zyskują coraz większą popularność.

Podpis elektroniczny to specjalna część dokumentu tworzona przez przekształcenia kryptograficzne. Jego głównym zadaniem jest wykrywanie nieautoryzowanych zmian i ustalanie autorstwa.

Certyfikat podpisu elektronicznego jest oddzielnym dokumentem potwierdzającym autentyczność i własność podpisu elektronicznego przez jego właściciela za pomocą klucza publicznego. Certyfikat wydawany jest przez urzędy certyfikacji.

Właścicielem certyfikatu podpisu elektronicznego jest osoba, w imieniu której certyfikat jest zarejestrowany. Jest powiązany z dwoma kluczami: publicznym i prywatnym. Klucz prywatny umożliwia złożenie podpisu elektronicznego. Klucz publiczny ma na celu weryfikację autentyczności podpisu ze względu na związek kryptograficzny z kluczem prywatnym.

Rodzaje podpisu elektronicznego

Zgodnie z ustawą federalną nr 63 podpis elektroniczny dzieli się na 3 typy:

• zwykły podpis elektroniczny;
• niekwalifikowany podpis elektroniczny;
• kwalifikowany podpis elektroniczny.

Prosty ES tworzony jest za pomocą haseł nałożonych na otwieranie i przeglądanie danych lub podobnych środków, które pośrednio potwierdzają właściciela.

Niekwalifikowany ES jest tworzony przy użyciu przekształceń danych kryptograficznych przy użyciu klucza prywatnego. Pozwala to potwierdzić osobę, która podpisała dokument oraz stwierdzić, czy w danych zostały wprowadzone nieautoryzowane zmiany.

Podpisy kwalifikowane i niekwalifikowane różnią się tylko tym, że w pierwszym przypadku certyfikat dla ES musi być wystawiony przez centrum certyfikacji certyfikowane przez FSB.

Zakres podpisu elektronicznego

Poniższa tabela przedstawia zakres PE.

Technologie ES są najaktywniej wykorzystywane w wymianie dokumentów. W obiegu wewnętrznym ES pełni funkcję zatwierdzania dokumentów, czyli osobistego podpisu lub pieczęci. W przypadku zarządzania dokumentami zewnętrznymi obecność ES ma kluczowe znaczenie, ponieważ jest potwierdzeniem prawnym. Warto również zauważyć, że dokumenty podpisane przez ES mogą być przechowywane bezterminowo i nie tracą na znaczeniu prawnym ze względu na takie czynniki jak podpisy kasowalne, uszkodzony papier itp.

Kolejnym obszarem, w którym rozwija się elektroniczne zarządzanie dokumentami, jest raportowanie do organów regulacyjnych. Wiele firm i organizacji doceniło już wygodę pracy w tym formacie.

Zgodnie z prawem Federacji Rosyjskiej każdy obywatel ma prawo do korzystania z ES podczas korzystania z usług publicznych (np. podpisując elektroniczny wniosek do władz).

Handel online to kolejny interesujący obszar, w którym aktywnie wykorzystywany jest podpis elektroniczny. Jest to potwierdzenie, że w licytacji bierze udział prawdziwa osoba, a jej propozycje można uznać za wiarygodne. Nie bez znaczenia jest również to, że każda umowa zawarta z pomocą ES nabiera mocy prawnej.

Algorytmy podpisu elektronicznego

• Pełne szyfrowanie domeny (FDH) i standardy kryptografii klucza publicznego (PKCS). Ten ostatni to cała grupa standardowych algorytmów dla różnych sytuacji.
• DSA i ECDSA to amerykańskie standardy podpisu cyfrowego.
• GOST R 34.10-2012 - standard tworzenia podpisów elektronicznych w Federacji Rosyjskiej. Ten standard zastąpił GOST R 34.10-2001, który został oficjalnie zakończony po 31 grudnia 2017 r.
• Unia Eurazjatycka stosuje standardy całkowicie podobne do tych w Rosji.
• STB 34.101.45-2013 - białoruski standard cyfrowego podpisu elektronicznego.
• DSTU 4145-2002 - standard tworzenia podpisu elektronicznego na Ukrainie i wielu innych.

Należy również zauważyć, że algorytmy tworzenia ES mają różne spotkania i cele:

• Grupowy podpis elektroniczny.
• Jednorazowy podpis cyfrowy.
• Zaufany PE.
• Podpis kwalifikowany i niekwalifikowany itp.

Zgodnie z częścią 5 art. 8 ustawy federalnej z dnia 6 kwietnia 2011 r. N 63-FZ „O podpisie elektronicznym” 1 zamówienie zatwierdzić:

Wymagania dotyczące środków podpisu elektronicznego (Załącznik N 1);
Wymagania dotyczące środków centrum certyfikacji (Załącznik nr 2).

Dyrektor A. Bortnikow

1 Zbiór ustawodawstwa Federacji Rosyjskiej, 2011, N 15, art. 2036; nr 27, art. 3880.

Wymagania dotyczące narzędzi do podpisu elektronicznego

I. Postanowienia ogólne

3) klucz ES - unikalna sekwencja znaków zaprojektowana do tworzenia ES;

4) Klucz weryfikacji ES – unikalny ciąg znaków jednoznacznie skojarzony z kluczem ES i przeznaczony do uwierzytelniania ES (zwany dalej weryfikacją ES);

5) Narzędzia ES – narzędzia szyfrujące (kryptograficzne) służące do wdrożenia co najmniej jednego z następujące funkcje- tworzenie ES, weryfikacja ES, tworzenie klucza ES i klucza weryfikacji ES;

6) Certyfikat klucza weryfikacyjnego ES – dokument elektroniczny lub papierowy wydany przez CA lub upoważnionego przedstawiciela CA i potwierdzający przynależność klucza weryfikacyjnego ES do właściciela certyfikatu klucza weryfikacyjnego ES.

3. Niniejsze wymagania określają strukturę i treść wymagań dla narzędzi ES.

4. Niniejsze Wymagania są przeznaczone dla klientów i deweloperów opracowanych (zaktualizowanych) narzędzi ES we wzajemnej interakcji, z organizacjami prowadzącymi badania kryptograficzne, inżyniersko-kryptograficzne i specjalne narzędzia ES, Federalna Służba Bezpieczeństwa Rosji, która potwierdza zgodność narzędzi ES z niniejszymi wymaganiami.

5. Niniejsze Wymagania dotyczą funduszy ES przeznaczonych do wykorzystania na terytorium Federacji Rosyjskiej, w instytucjach Federacji Rosyjskiej za granicą oraz w wydzielonych oddziałach osób prawnych zlokalizowanych za granicą, utworzonych zgodnie z ustawodawstwem Federacji Rosyjskiej.

6. Narzędzia EP w zakresie rozwoju, produkcji, sprzedaży i eksploatacji podlegają wymaganiom określonym w Rozporządzeniu w sprawie rozwoju, produkcji, sprzedaży i eksploatacji narzędzi szyfrujących (kryptograficznych) do zabezpieczania informacji (Rozporządzenie PKZ-2005), zatwierdzonym zamówieniem Federalnej Służby Bezpieczeństwa Rosji z dnia 9 lutego 2005 r. Nr 66 1 (zmienionym rozporządzeniem Federalnej Służby Bezpieczeństwa Rosji z dnia 12.04.2010 r. Nr 173 2) o szyfrowaniu (kryptograficznym) środkach ochrony informacji o ograniczonym dostępie niezawierające informacji stanowiących tajemnicę państwową.

7. Wymagania dotyczące technologii tworzenia (formowania) i weryfikacji ES za pomocą narzędzia ES są wskazane w taktycznej zakres zadań lub SIWZ na prowadzenie prac rozwojowych lub integralną część prac rozwojowych na rzecz rozwoju (modernizacji) narzędzia ES (zwane dalej TOR dla rozwoju (modernizacji) narzędzia ES).

II. Wymagania dotyczące narzędzi EP

8. Podczas tworzenia ES narzędzia ES muszą:

Pokaż osobie podpisującej dokument elektroniczny treść informacji, które podpisuje3;
- tworzenie ES dopiero po potwierdzeniu przez osobę podpisującą dokument elektroniczny operacji tworzenia ES3;
- jednoznacznie wskazują, że ES jest tworzony 3 .

9. Podczas sprawdzania ES narzędzia ES muszą:

Pokaż zawartość dokumentu elektronicznego podpisanego przez ES 3 ;
- pokazywać informacje o dokonaniu zmian w podpisanym dokumencie elektronicznym ES 3 ;
- wskazać osobę posługującą się kluczem ES, której podpisano dokumenty elektroniczne 3 .

10. Wymogi pkt 8 i 9 niniejszych Wymogów nie mają zastosowania do narzędzi ES używanych do automatycznego tworzenia i (lub) automatyczne sprawdzenie PE w systemie informacyjnym.
11. Narzędzie ES musi przeciwdziałać zagrożeniom, które są celowymi działaniami przy użyciu sprzętu i (lub) oprogramowania w celu naruszenia bezpieczeństwa informacji chronionych przez narzędzie ES lub stworzenia do tego warunków (zwane dalej atakiem).

12. W zależności od zdolności do odparcia ataków środki ES dzielą się na klasy 4 .
13. Klasa ES KS1 oznacza odporność na ataki, przy tworzeniu metod, przygotowaniu i przeprowadzeniu, których wykorzystuje się następujące cechy:
13.1. Samodzielna implementacja tworzenia metod ataków, przygotowywania i przeprowadzania ataków.
13.2. Działania na różnych etapach cyklu życia narzędzia ES5.
13.3. Dokonywanie ataku tylko z zewnątrz przestrzeni, w której odbywa się kontrola przebywania i działań osób i (lub) pojazdów (dalej strefa kontrolowana 6).

13.4. Przeprowadzenie następujących ataków na etapie rozwoju, produkcji, magazynowania, transportu narzędzi ES oraz na etapie uruchomienia narzędzi ES (prace uruchomieniowe):

Dokonywanie nieautoryzowanych zmian w narzędziu ES i (lub) komponentach SF, w tym przy użyciu szkodliwych programów;
- dokonywanie nieautoryzowanych zmian w dokumentacji narzędzia ES i komponentów SF.

13.5. Przeprowadzanie ataków na następujące obiekty:

Dokumentacja narzędzia ES i komponentów SF;

- informacje o kluczu, uwierzytelnianiu i haśle narzędzia ES;
- narzędzie ES oraz jego oprogramowanie i komponenty sprzętowe;
- sprzęt zawarty w SF, w tym mikroukłady z zapisanym mikrokodem BIOS, który inicjuje te narzędzia (zwane dalej komponentami sprzętowymi SF);
- komponenty oprogramowania Rady Federacji;

- pomieszczenia, w którym znajduje się zestaw oprogramowania i elementów technicznych systemów przetwarzania danych zdolnych do samodzielnego funkcjonowania lub w ramach innych systemów (zwanych dalej CVT), na których wdrażane są narzędzia ES i SF;
- inne obiekty ataków, które w razie potrzeby są wskazane w TOR w celu rozwoju (modernizacji) narzędzia ES, z uwzględnieniem technologii informatycznych stosowanych w systemie informatycznym, sprzętu (zwanym dalej AS) i oprogramowania ( zwane dalej oprogramowaniem).

13.6. Uzyskiwanie następujących informacji:

Ogólne informacje o systemie informatycznym, w którym wykorzystywane jest narzędzie ES (przeznaczenie, skład, operator, obiekty, w których znajdują się zasoby systemu informatycznego);
- Informacja o technologia informacyjna, bazy danych, AS, oprogramowanie wykorzystywane w systemie informacyjnym wraz z narzędziem ES;
- informacje o środkach ochrony fizycznej obiektów, w których znajdują się środki ES;
- informacje o środkach zapewniających kontrolowany obszar obiektów systemu informatycznego, w którym wykorzystywane jest narzędzie ES;
- informacje o środkach ograniczających dostęp do pomieszczeń, w których znajduje się sprzęt komputerowy, na których wdrażane są środki ES i SF;
- zawartość ogólnodostępnej dokumentacji dotyczącej komponentów sprzętowych i programowych środków ES i SF;
- ogólne informacje o chronionych informacjach wykorzystywanych podczas działania narzędzia ES;

- informacje o liniach komunikacyjnych, którymi przesyłane są informacje chronione przez ES;
- informacje o wszelkich naruszeniach zasad funkcjonowania środków ES i SF, które pojawiają się w kanałach komunikacji, które nie są zabezpieczone przed nieuprawnionym dostępem do informacji środkami organizacyjnymi i technicznymi;
- informacje o wszystkich przejawiających się w kanałach komunikacyjnych, które nie są chronione przed UA do informacji środkami organizacyjnymi i technicznymi, awariami i awariami komponentów sprzętowych środków ES i SF;
- informacje uzyskane w wyniku analizy dowolnych sygnałów z elementów sprzętowych środków ES i SF, które mogą zostać przechwycone przez intruza.

13.7. Stosowanie:

Swobodnie dostępne lub używane poza kontrolowanym obszarem AS i oprogramowanie, w tym komponenty sprzętowe i programowe ES i SF;

13.8. Wykorzystanie jako środka przekazu od podmiotu do obiektu (od obiektu do podmiotu) ataku działań przeprowadzonych podczas przygotowania i (lub) przeprowadzenia ataku (zwanej dalej kanałem ataku):

Kanały komunikacji niechronione przed nieuprawnionym dostępem do informacji środkami organizacyjnymi i technicznymi (zarówno poza strefą kontrolowaną, jak i w jej obrębie), którymi przesyłane są informacje chronione przez ES;
- kanały dystrybucji sygnałów towarzyszących działaniu środków ES i SF.

13.9. Przeprowadzenie ataku z sieci informatycznych i telekomunikacyjnych, do których dostęp nie jest ograniczony do określonego kręgu osób.

13.10. Wykorzystanie AS i oprogramowania z kompozycji narzędzi systemu informatycznego wykorzystywanych w miejscach eksploatacji narzędzia ES (zwanych dalej narzędziami standardowymi) i znajdujących się poza kontrolowanym obszarem.

14. Klasa ES KS2 oznacza odporność na ataki, przy tworzeniu metod, przygotowaniu i przeprowadzeniu których wykorzystuje się możliwości wymienione w punktach 13.1 - 13.10 niniejszych Wymogów oraz następujące dodatkowe cechy:

14.1. Wyprowadzanie ataku będąc poza granicami oraz w strefie kontrolowanej.

14.2. Stosowanie środków regularnych, ograniczonych środkami zaimplementowanymi w systemie informatycznym, w którym wykorzystywane jest narzędzie ES, a mających na celu zapobieganie i tłumienie nieautoryzowanych działań.

15. Klasa ES KS3 oznacza odporność na ataki, przy tworzeniu metod, przygotowaniu i przeprowadzeniu, które wykorzystuje się możliwości wymienione w punktach 13.1 - 13.10, 14.1, 14.2 niniejszych Wymogów oraz następujące dodatkowe funkcje:

15.1. Dostęp do SVT, na którym realizowane są środki ES i SF.

15.2. Możliwość posiadania komponentów sprzętowych narzędzia ES i SF w ilości zależnej od środków mających na celu zapobieganie i tłumienie nieautoryzowanych działań zaimplementowanych w systemie informatycznym, w którym używane jest narzędzie ES.

16. KV1 klasa ES oznacza odporność na ataki, przy tworzeniu metod, przygotowaniu i przeprowadzeniu których wykorzystuje się możliwości wymienione w punktach 13.1 - 13.10, 14.1, 14.2, 15.1, 15.2 niniejszych Wymogów oraz następujące dodatkowe funkcje:

16.1. Tworzenie metod ataku, przygotowanie i realizacja ataków przy zaangażowaniu specjalistów posiadających doświadczenie w rozwoju i analizie narzędzi ES, w tym specjalistów z zakresu analizy sygnałów towarzyszących działaniu narzędzi ES i SF.

16.2. Przeprowadzenie badań laboratoryjnych narzędzia ES używanego poza kontrolowanym obszarem, w zakresie zależnym od środków mających na celu zapobieganie i tłumienie nieautoryzowanych działań zaimplementowanych w systemie informatycznym, w którym jest używane narzędzie ES.

17. KV2 klasa ES oznacza odporność na ataki, przy tworzeniu metod, przygotowaniu i przeprowadzeniu których wykorzystuje się możliwości wymienione w punktach 13.1 - 13.10, 14.1, 14.2, 15.1, 15.2, 16.1, 16.2 niniejszych Wymogów oraz następujące dodatkowe funkcje :

17.1. Tworzenie metod ataków, przygotowywanie i przeprowadzanie ataków z udziałem specjalistów posiadających doświadczenie w tworzeniu i analizie narzędzi ES, w tym specjalistów w zakresie wykorzystania możliwości oprogramowania aplikacyjnego do realizacji ataków, które nie są opisane w dokumentacji oprogramowania aplikacyjnego.

17.2. Organizacja prac nad tworzeniem metod i środków ataków w ośrodkach badawczych specjalizujących się w opracowywaniu i analizie narzędzi ES i SF.

17.3. Możliwość posiadania tekstów źródłowych oprogramowania aplikacyjnego zawartego w SF.

18. Klasa EP KA1 oznacza odporność na ataki, przy tworzeniu metod, przygotowaniu i przeprowadzeniu, które wykorzystuje się zdolności wymienione w punktach 13.1 - 13.10, 14.1, 14.2, 15.1, 15.2, 16.1, 16.2, 17.1 - 17.3 niniejszych Wymogów, oraz następujące dodatkowe funkcje:

18.1. Tworzenie metod ataków, przygotowywanie i przeprowadzanie ataków z udziałem specjalistów posiadających doświadczenie w tworzeniu i analizie narzędzi ES, w tym specjalistów w zakresie wykorzystania możliwości oprogramowania systemowego do realizacji ataków, które nie są opisane w dokumentacji oprogramowania systemowego.

18.2. Możliwość posiadania całej dokumentacji komponentów sprzętowych i programowych SF.

18.3. Możliwość posiadania wszystkich elementów sprzętowych EP i SF.

19. Jeżeli narzędzie ES realizuje funkcję sprawdzania ES dokumentu elektronicznego za pomocą certyfikatu klucza weryfikacyjnego ES, implementacja ta musi wykluczać możliwość sprawdzenia ES dokumentu elektronicznego bez sprawdzenia ES w certyfikacie klucza weryfikacyjnego ES lub bez obecność wynik pozytywny Weryfikacja ES w certyfikacie klucza weryfikacyjnego ES.

20. Przy opracowywaniu narzędzi ES należy stosować algorytmy kryptograficzne zatwierdzone jako standardy państwowe lub posiadające pozytywną opinię FSB Rosji na podstawie wyników ich eksperckich badań kryptograficznych7.

21. Inżynierska i kryptograficzna ochrona środków ES powinna wykluczać zdarzenia prowadzące do możliwości przeprowadzenia udane ataki w warunkach możliwe usterki lub awarie komponentu sprzętowego narzędzia ES lub komponentu sprzętowego CVT, na którym zaimplementowano narzędzie programowe ES.

22. W narzędziu ES powinny być zaimplementowane jedynie algorytmy funkcjonowania narzędzia ES określone w SIWZ dla rozwoju (modernizacji) narzędzia ES.

23. Komponent oprogramowania narzędzia ES (jeśli istnieje komponent oprogramowania narzędzia ES) musi spełniać następujące wymagania:

Kod obiektowy (rozruchowy) komponentu oprogramowania narzędzia ES musi odpowiadać jego tekstowi źródłowemu;
- w komponencie oprogramowania narzędzia ES przy wdrażaniu powinny być wykorzystywane wyłącznie funkcje środowiska oprogramowania opisane w dokumentacji, w której działa narzędzie ES;
- w tekstach źródłowych komponentu oprogramowania narzędzia ES nie powinno być możliwości, które pozwoli na modyfikację lub zniekształcenie algorytmu narzędzia ES w procesie jego użytkowania, modyfikację lub zniekształcenie informacji lub sterowanie przepływami i procesami związanymi z operacją narzędzia ES oraz uzyskanie dostępu do osób naruszających informacje przechowywane w kluczu kasowym, informacje identyfikacyjne i (lub) uwierzytelniające narzędzia ES;
- wartości wejściowe i parametry wewnętrzne, a także wartości ustawień komponentu programowego narzędzia ES nie powinny negatywnie wpływać na jego działanie.

24. W przypadku planowania rozmieszczenia środków ES w pomieszczeniach, w których znajduje się mowa akustyczna i wizualna zawierająca informacje stanowiące tajemnicę państwową oraz (lub) zainstalowane głośniki i systemy do odbioru, nadawania, przetwarzania, przechowywania i wyświetlania informacji zawierających informacje stanowiące tajemnicę państwową AS wyprodukowane za granicą, wchodzące w skład środków ES, muszą zostać poddane kontrolom w celu identyfikacji urządzeń przeznaczonych do potajemnego pozyskiwania informacji.

W przypadku planowania rozmieszczenia środków ES w pomieszczeniach, w których nie ma mowy informacji akustycznej i wizualnej zawierającej informacje stanowiące tajemnicę państwową, a także SZR oraz systemów do odbioru, przesyłania, przetwarzania, przechowywania i wyświetlania informacji zawierających informacje stanowiące tajemnicę państwową są zainstalowane:

Decyzję o przeprowadzeniu kontroli zagranicznych elektrowni jądrowych wchodzących w skład urządzeń ES klas KS1, KS2, KS3, KB1 i KB2 podejmuje organizacja zapewniająca eksploatację tych urządzeń ES;
- kontrole AS zagranicznych, które są częścią środka klasy ES KA1, są przeprowadzane bezbłędnie.

25. Narzędzie ES musi uwierzytelniać podmioty dostępu (osoby, procesy) do tego narzędzia, przy czym:

Podczas uzyskiwania dostępu do narzędzia ES uwierzytelnienie podmiotu dostępu musi być przeprowadzone przed wykonaniem pierwszego modułu funkcjonalnego narzędzia ES;
- mechanizmy uwierzytelniania powinny blokować dostęp tych podmiotów do funkcji narzędzia ES w przypadku negatywnego wyniku uwierzytelnienia.

26. Narzędzie ES musi uwierzytelniać osoby zapewniające lokalny dostęp do narzędzia ES.

27. Potrzeba narzędzia ES do uwierzytelniania procesów zapewniających lokalny lub zdalny (sieciowy) dostęp do narzędzia ES jest wskazana w TOR dla rozwoju (aktualizacji) narzędzia ES.

28. Dla każdego mechanizmu uwierzytelniania zawartego w narzędziu ES należy wdrożyć mechanizm ograniczający liczbę kolejnych prób uwierzytelnienia jednego podmiotu dostępu, których liczba nie powinna przekraczać 10. Jeżeli liczba kolejnych prób uwierzytelnienia jednego podmiotu dostępu przekracza ustaloną wartość graniczną, dostęp tego podmiotu do ES musi zostać zablokowany na czas określony w SIWZ na rozwój (modernizację) środków ES.

29. W narzędziu ES należy wdrożyć mechanizm (procedurę) monitorowania integralności narzędzia ES i SF.

Kontrolę integralności można przeprowadzić:

Na początku pracy z narzędziem ES przed przejściem CVT, w którym narzędzie ES jest zaimplementowane, do stanu roboczego (np. przed załadowaniem systemu operacyjnego CVT);
- w trakcie rutynowych kontroli urządzeń ES w miejscach eksploatacji (kontrola regulacyjna);
- w trybie automatycznym podczas pracy środków ES (sterowanie dynamiczne).

Kontrolę integralności należy przeprowadzić na początku pracy z narzędziem ES.

Mechanizm rutynowej kontroli integralności powinien być częścią narzędzi ES.

30. W przypadku narzędzi ES klas KS1 i KS2 konieczność przedstawienia wymagań dotyczących kontroli dostępu i czyszczenia pamięci oraz ich zawartości jest wskazana w TOR dla rozwoju (modernizacji) narzędzia ES.

31. Skład ES klas KS3, KB1, KB2 i KA1 lub SF powinien zawierać elementy, które zapewniają:

Zarządzanie dostępem podmiotów do różnych komponentów i (lub) funkcji docelowych narzędzia ES i SF w oparciu o parametry ustawione przez administratora lub producenta narzędzia ES (wymagania dla określonego komponentu są określane i uzasadnione przez organizację prowadzącą badania narzędzie ES w celu oceny zgodności narzędzia ES z niniejszymi wymaganiami);
- czyszczenie operacyjne i pamięć zewnętrzna używany przez narzędzie ES do przechowywania chronionych informacji podczas zwalniania (redystrybucji) pamięci poprzez zapisywanie w pamięci informacji maskujących (losowa lub pseudolosowa sekwencja znaków).

32. Skład narzędzi ES klas KV2 i KA1 lub SF powinien obejmować komponenty zapewniające awaryjne usunięcie chronionych informacji o ograniczonym dostępie. Wymagania dotyczące wdrożenia i niezawodności usuwania są określone w TOR dla rozwoju (modernizacji) narzędzia ES.

33. W przypadku narzędzi ES klas KS1 i KS2 konieczność przedstawienia wymagań dotyczących rejestracji zdarzeń i ich treści wskazano w TOR dla rozwoju (modernizacji) narzędzi ES.

34. Skład narzędzi ES klas KSZ, KV1, KB2 i KA1 powinien zawierać moduł rejestrujący w elektronicznym dzienniku zdarzenia w narzędziach ES i SF związane z wykonywaniem przez narzędzia ES funkcji docelowych.

Wymagania do określony moduł a lista zarejestrowanych zdarzeń jest ustalana i uzasadniana przez organizację prowadzącą badania narzędzia ES w celu oceny zgodności narzędzia ES z niniejszymi Wymaganiami.

35. Dziennik zdarzeń powinien być dostępny wyłącznie dla osób wskazanych przez operatora systemu informatycznego, w którym wykorzystywane jest narzędzie ES lub osoby przez niego upoważnione. W takim przypadku dostęp do dziennika zdarzeń powinien być możliwy tylko w celu przeglądania zapisów i przenoszenia zawartości dziennika zdarzeń na nośniki archiwalne.

36. Okres ważności klucza weryfikacji ES nie może przekraczać okresu ważności klucza ES o więcej niż 15 lat.

37. Wymagania dotyczące mechanizmu monitorowania okresu użytkowania klucza ES, blokującego działanie narzędzia ES w przypadku próby użycia klucza dłuższego niż określony okres, określa twórca narzędzia ES oraz uzasadnione przez organizację prowadzącą badania narzędzia ES w celu oceny zgodności narzędzia ES z niniejszymi Wymaganiami.

38. Protokoły kryptograficzne, które dostarczają operacji z kluczowymi informacjami narzędzia ES, muszą być zaimplementowane bezpośrednio w narzędziu ES.

39. Badania narzędzi ES w celu oceny zgodności narzędzi ES z niniejszymi Wymaganiami należy przeprowadzić z wykorzystaniem wartości liczbowych parametrów i charakterystyk mechanizmów zabezpieczających zaimplementowanych w narzędziach ES oraz komponentów sprzętowych i programowych SF 8 opracowany przez FSB Rosji.

1 Zarejestrowany przez rosyjskie Ministerstwo Sprawiedliwości w dniu 3 marca 2005 r., numer rejestracyjny 6382.

3 Jest ona realizowana m.in. za pomocą narzędzi sprzętowych i programowych, w połączeniu z którymi narzędzia ES funkcjonują normalnie i które mogą wpływać na spełnienie wymagań dla narzędzi ES, które łącznie reprezentują środowisko działania narzędzi ES (dalej – SF).
4 Wymagana klasa opracowanego (zaktualizowanego) narzędzia ES jest określana przez klienta (programistę) narzędzia ES poprzez określenie możliwości tworzenia metod ataku, przygotowywania i przeprowadzania ataków w oparciu o punkty 13-18 niniejszych Wymogów i jest wskazana w T3 dla rozwoju (uaktualnienia) narzędzia ES.
5 Etapy cyklu życia narzędzia ES obejmują rozwój (modernizację) tych narzędzi, ich produkcję, magazynowanie, transport, uruchomienie (uruchomienie), eksploatację.
6 Granicą strefy kontrolowanej może być: obwód chronionego terytorium przedsiębiorstwa (instytucji), otaczające konstrukcje chronionego budynku, chroniona część budynku, przydzielone lokale.
7 Punkt 25 ust. 9 Regulaminu w sprawie Służba Federalna bezpieczeństwa Federacji Rosyjskiej, zatwierdzone Dekretem Prezydenta Federacji Rosyjskiej z dnia 11 sierpnia 2003 r. nr 960 (Sobraniye Zakonodatelstva Rossiyskoy Federatsii, 2003, nr 33, art. 3254; 2004, nr 28, art. 2883; 2005, nr 36, art. 3665; nr 49, art. 5200; 2006, nr 25, art. 2699; nr 31 (część I), art. 3463; 2007, nr 1 (część I), art. nr 49, art. 6133; nr 53, art. 6554; 2008, nr 36, art. 4087; nr 43, art. 4921; nr 47, art. 5431; 2010, nr 17, art. 2054; nr 20, Artykuł 2435; 2011, nr 2, artykuł 267; nr 9, artykuł 1222) (dalej - Regulamin FSB Rosji).
8 Paragraf 47 paragrafu 9 Regulaminu w sprawie FSB Rosji.

Załącznik nr 2

Wymagania dotyczące narzędzi urzędu certyfikacji

I. Postanowienia ogólne

1. Niniejsze Wymagania zostały opracowane zgodnie z prawo federalne z dnia 6 kwietnia 2011 r. N 63-FZ „O podpisie elektronicznym” (zwana dalej ustawą federalną).

2. W niniejszych Wymogach stosowane są następujące podstawowe pojęcia zdefiniowane w art. 2 ustawy federalnej:

1) podpis elektroniczny (dalej - ES) - informacja w formie elektronicznej, która jest dołączana do innych informacji w formie elektronicznej (informacja podpisana) lub w inny sposób jest z taką informacją powiązana i która służy do identyfikacji osoby podpisującej informację;

3) Narzędzia ES – narzędzia szyfrujące (kryptograficzne) służące do realizacji co najmniej jednej z następujących funkcji – tworzenie ES, sprawdzanie ES, tworzenie klucza ES i klucza weryfikacji ES;

4) klucz ES - unikalna sekwencja znaków zaprojektowana do tworzenia ES;

5) Klucz weryfikacji ES – unikalny ciąg znaków jednoznacznie skojarzony z kluczem ES i przeznaczony do uwierzytelniania ES (zwany dalej weryfikacją ES);

6) Certyfikat klucza weryfikacyjnego ES – dokument elektroniczny lub papierowy wydany przez CA lub upoważnionego przedstawiciela CA i potwierdzający przynależność klucza weryfikacyjnego ES do właściciela certyfikatu klucza weryfikacyjnego ES;

7) kwalifikowany certyfikat klucza weryfikacyjnego ES (zwany dalej kwalifikowanym certyfikatem) – certyfikat klucza weryfikacyjnego ES wystawiony przez akredytowany CA lub upoważnionego przedstawiciela akredytowanego CA lub federalny organ wykonawczy upoważniony w zakresie stosowania ES (dalej określany jako upoważniony organ federalny);

8) właściciel certyfikatu klucza weryfikacyjnego ES – osoba, której w trybie określonym w Ustawie Federalnej wydano certyfikat klucza weryfikacyjnego ES;

9) akredytacja CA - uznanie przez uprawniony organ federalny zgodności CA z wymogami ustawy federalnej;

10) urządzenia CA – sprzęt i (lub) oprogramowanie służące do realizacji funkcji CA;

11) uczestnicy interakcji elektronicznej - organy państwowe, samorządowe, organizacje, a także obywatele wymieniający informacje w formie elektronicznej.

3. Niniejsze Wymagania określają strukturę i treść wymagań dla narzędzi CA.

4. Niniejsze Wymagania są przeznaczone dla klientów i deweloperów opracowanych (zaktualizowanych) narzędzi CA we wzajemnej interakcji, z organizacjami prowadzącymi badania kryptograficzne, inżyniersko-kryptograficzne i specjalne badania narzędzi CA, Federalna Służba Bezpieczeństwa Rosji, która potwierdza zgodność narzędzi CA z niniejszymi wymaganiami.

5. Niniejsze Wymagania dotyczą środków CA przeznaczonych do wykorzystania na terytorium Federacji Rosyjskiej.

6. Narzędzia CA w zakresie rozwoju, produkcji, sprzedaży i eksploatacji podlegają wymogom określonym w Regulaminie rozwoju, produkcji, sprzedaży i eksploatacji narzędzi szyfrujących (kryptograficznych) bezpieczeństwa informacji (Rozporządzenie PKZ-2005), zatwierdzonym przez zarządzenie Federalnej Służby Bezpieczeństwa Rosji z dnia 9 lutego 2005 r. Nr 66 1 (zmienione rozporządzeniem nr 1732 FSB Rosji z dnia 12 kwietnia 2010 r.) dotyczące szyfrowania (kryptograficznego) środków ochrony informacji (zwanych dalej do jako CIPF) z ograniczonym dostępem, które nie zawierają informacji stanowiących tajemnicę państwową.

II. Wymagania dotyczące funduszy CA

7. Narzędzia CA muszą przeciwdziałać zagrożeniom, które są ukierunkowanymi działaniami przy użyciu sprzętu i (lub) narzędzi programowych w celu naruszenia inżynieryjnego, technicznego i kryptograficznego bezpieczeństwa narzędzi CA lub stworzenia do tego warunków (zwane dalej atakiem).

8. W zależności od odporności na ataki, narzędzia CA dzielą się na klasy 3 .

9. Narzędzia klasy CA KS1 są odporne na ataki, przy tworzeniu metod, przygotowaniu i przeprowadzaniu których wykorzystuje się następujące cechy:

9.1. Przygotowanie i przeprowadzenie ataków spoza przestrzeni, w której monitorowany jest pobyt i działania osób i (lub) pojazdów (zwanej dalej strefą kontrolowaną).
9.2. Przygotowywanie i przeprowadzanie ataków bez dostępu do funkcjonalność oprogramowanie i sprzęt do interakcji z CA.

9.3. Samodzielna implementacja tworzenia metod ataków, przygotowywania i przeprowadzania ataków na następujące obiekty:

Dokumentacja dla funduszy CA;
- chronione dokumenty elektroniczne;
- informacje o kluczu, uwierzytelnianiu i haśle;
- narzędzia CA, ich oprogramowanie i komponenty sprzętowe;
- dane przesyłane kanałami komunikacyjnymi;
- pomieszczenia, w których znajduje się sprzęt (zwany dalej AS), na którym zaimplementowane są narzędzia CA oraz inne chronione zasoby systemu informatycznego.

9.4. Wprowadzenie na etapach rozwoju, produkcji, magazynowania, transportu i uruchomienia narzędzi CA:

Negatywna funkcjonalność w narzędziach CA, w tym wykorzystanie złośliwego oprogramowania;
- nieautoryzowane zmiany w dokumentacji funduszy CA.

9.5. Uzyskiwanie następujących informacji:

Ogólne informacje o systemie informatycznym, w którym wykorzystywane są narzędzia CA (przeznaczenie, skład, obiekty, w których znajdują się zasoby systemu informatycznego);
- informacje o technologiach informatycznych, bazach danych, AS, oprogramowaniu (zwanym dalej oprogramowaniem) wykorzystywanych w systemie informatycznym wraz z narzędziami CA;
- informacje o środkach ochrony fizycznej obiektów, w których zlokalizowane są obiekty CA;
- informacje o środkach zapewniających ochronę kontrolowanej strefy obiektów systemu informatycznego, w których wykorzystywane są narzędzia CA;
- informacje o środkach ograniczających dostęp do pomieszczeń, w których zlokalizowane są placówki CA;
- zawartość ogólnodostępnej dokumentacji technicznej dla funduszy CA;
- informacje o informacjach chronionych wykorzystywanych podczas funkcjonowania placówek CA (rodzaje informacji chronionych: informacje serwisowe, informacje o hasłach i uwierzytelnieniach, informacje konfiguracyjne, informacje kontrolne, informacje w elektronicznych dziennikach rejestracji; informacje ogólne o treści każdego rodzaju informacji chronionych; cechy bezpieczeństwa dla każdego rodzaju chronionych informacji);
- wszelkie możliwe dane przekazywane w formie otwartej kanałami komunikacji, które nie są zabezpieczone przed nieuprawnionym dostępem (zwane dalej UA) do informacji za pomocą środków organizacyjnych i technicznych;
- informacje o liniach komunikacyjnych, którymi przesyłane są informacje chronione przy pomocy CA;
- informacje o wszelkich naruszeniach zasad funkcjonowania placówek CA, które pojawiają się w kanałach komunikacji, które nie są zabezpieczone przed nieuprawnionym dostępem do informacji środkami organizacyjnymi i technicznymi;
- informacje o wszystkich przejawiających się w kanałach komunikacji, które nie są chronione przed nieuprawnionym dostępem do informacji środkami organizacyjnymi i technicznymi, awariami i awariami obiektów CA;
- informacje uzyskane w wyniku analizy dowolnych sygnałów dostępnych do przechwycenia z elementów sprzętowych CA.

9.6. Stosowanie:

Swobodnie dostępne lub poza kontrolowanym obszarem AS i oprogramowania, w tym komponentów oprogramowania i sprzętu CA;
- specjalnie zaprojektowany AS i oprogramowanie.

9.7. Wykorzystywanie jako kanałów ataku kanałów komunikacji, które nie są zabezpieczone przed nieuprawnionym dostępem do informacji środkami organizacyjnymi i technicznymi (zarówno poza strefą kontrolowaną, jak i w jej obrębie), za pośrednictwem których informacje są przesyłane, przetwarzane przez CA.

10. Narzędzia klasy CA KS2 są odporne na ataki, przy tworzeniu metod, przygotowaniu i wykonaniu, które mają następujące cechy:

10.1. Możliwości wymienione w punktach 9.3 - 9.7 niniejszych Wymogów.

10.2. Przygotowanie i wykonanie ataków ze strefy kontrolowanej.

10.3. Przygotowanie i wykonanie ataków bez korzystania z dostępu do AS, na którym zaimplementowane są narzędzia CA.

10.4. Korzystanie ze zwykłych narzędzi systemu informatycznego wykorzystujących narzędzia CA.

11. Narzędzia CA klasy KSZ opierają się atakom, tworząc metody, przygotowując i przeprowadzając, które wykorzystuje następujące cechy:

11.1. Możliwości wymienione w punktach 10.1, 10.4 niniejszych Wymogów.

11.2. Przygotowanie i wykonanie ataków spoza kontrolowanego obszaru z wykorzystaniem dostępu do funkcjonalności oprogramowania i narzędzi sprzętowych do interakcji z CA w oparciu o legalne posiadanie informacji uwierzytelniających lub przygotowanie i wykonanie ataków z kontrolowanego obszaru z wykorzystaniem dostępu do AS na którym zaimplementowane są komponenty CA, na prawach osoby nie będącej członkiem grupy osoby fizyczne uprawnienia do instalacji, konfiguracji i obsługi narzędzi CA, konfiguracji profilu i parametrów dziennika audytu (funkcje administratora systemu), archiwizacji, tworzenia kopii zapasowych i przywracania informacji po awariach (funkcje operatora), tworzenia i unieważniania certyfikatów kluczy weryfikacyjnych ES (funkcje administratora certyfikacji ), przeglądanie i utrzymywanie dziennika audytu (funkcji administratora audytu) (zwanej dalej grupą administratorów narzędzi CA) dowolnego z komponentów CA.

11.3. Posiadanie AS CA w ilości zależnej od wdrożonych środków mających na celu zapobieganie i tłumienie nieautoryzowanych działań.

12. Obiekty CA klasy KV1 są odporne na ataki, tworząc metody, przygotowując i przeprowadzając, które wykorzystuje następujące cechy:

12.1. Możliwości wymienione w punktach 11.1 - 11.3 niniejszych Wymogów.

12.2. Realizacja tworzenia metod i przygotowania ataków z udziałem specjalistów posiadających doświadczenie w opracowywaniu i analizie CIPF CA (w tym specjalistów z zakresu analizy sygnałów transmisji liniowej i sygnałów bocznych promieniowanie elektromagnetyczne i odbiory CIPF UT).

12.3. Prowadzenie badań laboratoryjnych narzędzi CA wykorzystywanych poza kontrolowanym obszarem w zakresie zależnym od wdrożonych środków mających na celu zapobieganie i tłumienie nieuprawnionych działań.

13. Obiekty klasy CA KV2 są odporne na ataki, podczas tworzenia metod, przygotowywania i przeprowadzania, których wykorzystuje się następujące cechy:

13.1. Możliwości wymienione w punktach 12.1 - 12.3 niniejszych Wymogów.

13.2. Realizacja tworzenia metod i przygotowania ataków z udziałem specjalistów z zakresu wykorzystania do realizacji ataków o niezadeklarowanych możliwościach oprogramowania aplikacyjnego i systemowego.

13.3. Organizacja prac nad tworzeniem metod i środków ataków w ośrodkach badawczych specjalizujących się w rozwoju i analizie narzędzi CA.

13.4. Posiadanie tekstów źródłowych oprogramowania aplikacyjnego używanego w systemie informatycznym, w którym wykorzystywane są narzędzia CA oraz dokumentacji będącej w domenie publicznej.

14. Narzędzia CA klasy KA1 są odporne na ataki, tworząc metody, przygotowując i przeprowadzając, które mają następujące cechy:

14.1. Możliwości wymienione w punktach 13.1 - 13.4 niniejszych Wymogów.

14.2. Realizacja tworzenia metod i przygotowania ataków z udziałem ośrodków badawczych specjalizujących się w opracowywaniu i analizie ochrony informacji kryptograficznej oraz w zakresie wykorzystania niezadeklarowanych możliwości oprogramowania aplikacyjnego i systemowego do realizacji ataków.

14.3. Posiadanie całej dokumentacji komponentów sprzętowych i programowych urzędu certyfikacji.

14.4. Posiadanie wszystkich komponentów sprzętowych CA.

15. Obiekty CA muszą być obsługiwane zgodnie z dokumentacją operacyjną dla obiektów CA. W dokumentacji eksploatacyjnej obiektów CA należy wskazać zestaw środków organizacyjnych i technicznych zapewniających bezpieczną eksploatację obiektów CA.

16. Klasa narzędzi ES stosowanych w narzędziach CA nie może być niższa niż odpowiadająca im klasa narzędzi CA. Klasa narzędzi ES stosowanych w narzędziach CA musi być określona w dokumentacji operacyjnej narzędzi CA.

Klasa CIPF używana w narzędziach CA nie może być niższa niż odpowiednia klasa narzędzi CA. Klasa ochrony informacji kryptograficznej stosowanej w placówkach CA musi być wskazana w dokumentacji operacyjnej placówek CA.

17. Każde wymaganie dla placówek CA jakiejkolwiek klasy innej niż CA1 jest albo nałożone na placówki CA następnej klasy bez zmian (w tym przypadku nie jest to wskazane w wykazie wymagań dla placówek CA następnej klasy), albo jest zaostrzone (w tym przypadku w wykazie wymagań dla środków CA następnej klasy podano ostrzejsze sformułowanie). Wymagania dla obiektów CA następnej klasy mogą obejmować: Dodatkowe wymagania, które nie są zawarte w wymaganiach dla obiektów CA poprzedniej klasy.

18. Wymagania dotyczące oprogramowania narzędzi CA:

18.1. Wymagania dla obiektów klasy CA KS1:

Oprogramowanie narzędzi CA nie powinno zawierać narzędzi, które umożliwiają modyfikację lub zniekształcenie algorytmu działania narzędzi oprogramowania i AS CA.

18.2. Wymagania dla klasy CA KS2:

Oprogramowanie użytkowe narzędzi CA i CIPF używane w CA musi wykorzystywać wyłącznie udokumentowane funkcje oprogramowania systemowego.

18.3. Wymagania dla obiektów klasy CA KS3:

Oprogramowanie systemowe i aplikacyjne narzędzi CA musi zapewniać kontrolę dostępu dla administratora systemu do narzędzi CA, administratora do certyfikacji narzędzi CA i dostarczonych osób Administrator systemu narzędzia CA z informacjami identyfikującymi i uwierzytelniającymi oraz niebędące administratorem certyfikacji narzędzi CA (dalej jako użytkownicy narzędzi CA), do informacji przetwarzanych przez narzędzia CA, w oparciu o reguły kontroli dostępu ustalone przez administratora systemu narzędzi CA;
- oprogramowanie systemowe i aplikacyjne narzędzi CA musi odpowiadać 4. poziomowi kontroli braku niezadeklarowanych możliwości;
- oprogramowanie systemowe i aplikacyjne narzędzi CA nie powinno zawierać znanych podatności opublikowanych w źródłach publicznych;
- struktura systemu i (lub) oprogramowania aplikacyjnego narzędzi CA powinna zawierać mechanizm zapewniający czyszczenie pamięci RAM i pamięci zewnętrznej służącej do przechowywania informacji o ograniczonym dostępie.

18.4. Wymagania dla obiektów CA klasy KB1 pokrywają się z wymaganiami dla obiektów CA klasy KS3.

18.5. Wymagania dla klasy CA KV2:

Teksty źródłowe systemu i oprogramowania aplikacyjnego narzędzi CA muszą być sprawdzone pod kątem zaimplementowania w nich metod i środków ochrony informacji odpornych na ataki, dla przygotowania i wdrożenia których możliwości wymienione w punktach 9 - 13 niniejszych Wymogów są używane;
- teksty źródłowe systemu i oprogramowania muszą być sprawdzone pod kątem braku niezadeklarowanych funkcji;
- oprogramowanie systemowe i aplikacyjne musi być odporne na ataki komputerowe z sieci zewnętrznych.

18.6. Wymagania dla klasy CA KA1:

Teksty źródłowe systemu i oprogramowania aplikacyjnego narzędzi CA muszą przejść formalną weryfikację implementacji w nich metod i środków ochrony informacji odpornych na ataki, dla przygotowania i wdrożenia których możliwości wymienione w paragrafach 9-14 stosuje się te Wymagania, jak również brak w nich niezadeklarowanych możliwości.

19. Wymagania dla AS CA:

19.1. W przypadku planowania rozmieszczenia AS CA w pomieszczeniach, w których znajduje się mowa akustyczna i wizualna informacja zawierająca informacje stanowiące tajemnicę państwową oraz (lub) środki i systemy techniczne do odbierania, przesyłania, przetwarzania, przechowywania i wyświetlania informacji zawierających informacje stanowiące tajemnica państwowa to tajemnica instalowana, obce środki techniczne będące częścią narzędzi CA muszą być poddane kontrolom w celu identyfikacji urządzeń przeznaczonych do potajemnego pozyskiwania informacji, a także badaniom pod kątem zgodności z wymogami ochrony przed wyciekiem informacji kanałami niepożądanego promieniowania elektromagnetycznego i zakłóceń zgodnie z kategorią przydzielonych pomieszczeń.

19.2. Wymagania dla obiektów klasy CA KS1:

Zgodność z realizacją docelowych funkcji CA sprawdzana jest na podstawie systemu testów CA AS.

19.3. Wymagania dla obiektów CA klasy KS2, KS3, KB1, KB2 pokrywają się z wymaganiami dla obiektów CA klasy KS1.

19.4. Wymagania dla klasy CA KA1:

Przeprowadzanie specjalnej kontroli środków technicznych produkcji zagranicznej wchodzących w skład AS CA, w celu identyfikacji urządzeń przeznaczonych do potajemnego pozyskiwania informacji;
- przeprowadzenie pełnej weryfikacji AS (wraz z analizą kodu programu BIOS), na którym zaimplementowano narzędzia CA, w celu wykluczenia negatywnej funkcjonalności.

20. Wymagania dotyczące zróżnicowania ról:

20.1. Aby zapewnić wydajność funkcji urzędu certyfikacji, narzędzia urzędu certyfikacji muszą obsługiwać zróżnicowanie ról członków grupy administratorów narzędzi urzędu certyfikacji.

20.2. Wymagania dla obiektów klasy CA KS1:

Należy zdefiniować listę ról i podział odpowiedzialności między rolami;
- lista ról i podział odpowiedzialności między rolami powinien być określony w dokumentacji operacyjnej dla obiektów CA.

20.3. Wymagania dla obiektów CA klasy CS2 są takie same jak dla obiektów CA klasy CA1.

20.4. Wymagania dla obiektów klasy CA KS3:

Narzędzia CA muszą obsługiwać następujące obowiązkowe role:

1) administrator systemu, którego głównym obowiązkiem jest instalowanie, konfigurowanie i utrzymanie działania narzędzi CA, tworzenie i utrzymywanie profili dla członków grupy administratorów narzędzi CA, konfigurowanie parametrów profilu i dziennika audytu;

2) administrator certyfikacji, do którego głównych obowiązków należy: tworzenie i unieważnianie certyfikatów kluczy weryfikacyjnych ES;

Narzędzia CA muszą zaimplementować mechanizm, który wyklucza możliwość upoważnienia jednego członka grupy Administratorzy narzędzi CA do pełnienia różnych ról.

20.5. Wymagania dla klasy CA KB1:

Placówki CA powinny pełnić obowiązkową rolę operatora z podstawowymi obowiązkami tworzenia kopii zapasowych i odzyskiwania.

20.6. Wymagania dla obiektów CA klasy KB2 są takie same jak dla obiektów CA klasy KB1.

20.7. Wymagania dla klasy CA KA1:

Narzędzia CA powinny pełnić obowiązkową rolę administratora audytu z głównymi obowiązkami: przeglądanie i utrzymywanie dziennika audytu;
- administrator systemu nie powinien mieć możliwości wprowadzania zmian w dzienniku audytu.

21. Wymagania dotyczące integralności narzędzi CA:

21.1. Narzędzia CA muszą zawierać mechanizm kontroli nieautoryzowanego przypadkowego i (lub) celowego zniekształcenia (zmiany, modyfikacji) i (lub) zniszczenia informacji, oprogramowania i AS CA (dalej - mechanizm kontroli integralności).

21.2. Wymagania dla obiektów klasy CA KS1:

Wymagania dotyczące mechanizmu kontroli integralności powinny być określone w TOR dla rozwoju (modernizacji) narzędzi CA;
- okres kontroli integralności narzędzi programowych i AS CA musi być określony i wskazany w dokumentacji operacyjnej narzędzi CA;
- kontrola integralności oprogramowania i AS CA powinna być wykonywana przy każdym ponownym uruchomieniu systemu operacyjnego (zwanego dalej OS);
- muszą istnieć środki przywrócenia integralności obiektów CA.

21.3. Wymagania dla obiektów CA klasy CS2 są takie same jak dla obiektów CA klasy CA1.

21.4. Wymagania dla obiektów klasy CA KS3:
- Kontrolę integralności należy przeprowadzać co najmniej raz dziennie.

21.5. Wymagania dla klasy CA KB1:
- Kontrola integralności musi być przeprowadzona przed załadowaniem narzędzi urzędu certyfikacji przez system operacyjny.

21.6. Wymagania dla obiektów CA klasy KB2 są takie same jak dla obiektów CA klasy KB1.

21.7. Wymagania dla klasy CA KA1:
- kontrola integralności powinna być realizowana dynamicznie w trakcie funkcjonowania obiektów CA.

22. Wymagania dotyczące kontroli dostępu:

22.1. Obiekty CA muszą zapewniać kontrolę dostępu.

22.2. Wymagania dla obiektów klasy CA KS1:
- w TOR dla rozbudowy (modernizacji) obiektów CA należy określić i sprecyzować wymagania dotyczące kontroli dostępu.

22.3. Wymagania dla obiektów CA klasy CS2 są takie same jak dla obiektów CA klasy CA1.

22.4. Wymagania dla obiektów klasy CA KS3:
- w CA należy zapewnić uznaniową zasadę kontroli dostępu.

22.5. Wymagania dla obiektów CA klasy KB1 pokrywają się z wymaganiami dla obiektów CA klasy KS3.

22.6. Wymagania dla klasy CA KV2:
- należy zapewnić stworzenie zamkniętego środowiska pracy 4 obiektów CA.

22.7. Wymagania dla klasy CA KA1:
- CA musi zapewnić obowiązkową zasadę kontroli dostępu; do wprowadzenia klucza ES administratora certyfikacji wymagane są co najmniej dwie zaufane osoby 5 .

23. Wymagania dotyczące identyfikacji i uwierzytelnienia:

23.1. Identyfikacja i uwierzytelnianie obejmuje rozpoznanie użytkownika narzędzi CA, członka grupy administratorów narzędzi CA lub procesu oraz weryfikację ich tożsamości. Mechanizm uwierzytelniania powinien blokować dostęp tych podmiotów do funkcji CA w przypadku negatywnego wyniku uwierzytelnienia.

23.2. W narzędziach CA dla każdej realizowanej procedury uwierzytelniania należy zastosować mechanizm ograniczania liczby kolejnych prób uwierzytelnienia jednego podmiotu dostępu, których liczba nie powinna przekraczać trzech. Jeżeli liczba kolejnych prób uwierzytelnienia jednego podmiotu dostępu przekroczy ustaloną wartość graniczną, dostęp tego podmiotu dostępu do udogodnień CA musi zostać zablokowany na czas, który jest wskazany w SIWZ na rozbudowę (modernizację) Obiekty CA.

23.3. Wymagania dla obiektów klasy CA KS1:

Opis procedury rejestracji użytkowników narzędzi CA (wprowadzania danych do rejestru użytkowników narzędzi CA) powinien znajdować się w dokumentacji operacyjnej narzędzi CA;
- wszystkie osoby uzyskujące dostęp do środków CA muszą być uwierzytelnione. Jednocześnie dopuszcza się ograniczenie użycia tylko znaku, okresowo zmieniającego się hasła o długości co najmniej 8 znaków do uwierzytelniania o pojemności alfabetu co najmniej 36 znaków. Okres zmiany hasła nie powinien przekraczać 6 miesięcy.

23.4. Wymagania dla klasy CA KS2:

Konieczność okazania przez użytkownika środków CA podczas rejestracji dokumentów tożsamości powinna znaleźć odzwierciedlenie w dokumentacji operacyjnej środków CA;
- dla wszystkich użytkowników obiektów CA dopuszcza się stosowanie mechanizmów zdalnego uwierzytelniania. Szczególne cechy mechanizmów zdalnego uwierzytelnienia muszą być potwierdzone w ramach weryfikacji zgodności narzędzi CA i obiektów informatyzacji wykorzystujących te narzędzia z niniejszymi Wymaganiami;
- przy wdrażaniu dostęp lokalny do narzędzi CA uwierzytelnianie członków grupy administratorów narzędzi CA musi zostać wykonane, zanim te narzędzia CA zaczną działać (na przykład przed załadowaniem podstawowego systemu operacyjnego).

23.5. Wymagania dla obiektów klasy CA KS3:

Mechanizm uwierzytelniania musi być zaimplementowany w narzędziach CA lokalni użytkownicy którzy mają dostęp do narzędzi urzędu certyfikacji, ale nie są członkami grupy administratorów narzędzi urzędu certyfikacji.

23.6. Wymagania dla klasy CA KB1:

Podczas wdrażania zdalny dostęp tylko hasło symboliczne nie jest dozwolone dla narzędzi CA, należy stosować mechanizmy uwierzytelniania oparte na protokołach kryptograficznych.

23.7. Wymagania dla obiektów CA klasy KB2 są takie same jak dla obiektów CA klasy KB1.

23.8. Wymagania dla klasy CA KA1:

W narzędziach CA dla dowolnego zaimplementowanego mechanizmu uwierzytelniania musi istnieć możliwość ustawienia limitu dopuszczalna kwota kolejne próby uwierzytelnienia jednego podmiotu dostępu oraz ustawienie czasu blokowania dostępu do obiektów CA w miejscach ich działania.

24. Wymagania dotyczące ochrony danych przychodzących (eksportowanych) do (z) CA:

24.1. Narzędzia urzędu certyfikacji muszą zapewniać wiarygodne dane wejściowe w postaci samopodpisanego certyfikatu klucza weryfikacyjnego ES.

24.2. Wymagania dla obiektów klasy CA KS1:

Obiekty CA muszą zapewniać transfer danych zawierających informacje o ograniczonym dostępie otrzymywane przez CA i eksportowane z CA w sposób zabezpieczony przed nieuprawnionym dostępem;
- za pomocą CA powinna zostać wdrożona procedura chroniąca przed narzucaniem fałszywych wiadomości 6 ;
- wymagania dotyczące procedury ochrony przed narzucaniem fałszywych wiadomości są wskazane w TOR dla rozwoju (modernizacji) narzędzi CA.

24.3. Wymagania dla klasy CA KS2:

Środki CA muszą zapewniać ochronę pierwotnego wniosku o certyfikat klucza weryfikacyjnego ES;
- Narzędzia CA powinny akceptować informacje krytyczne dla funkcjonowania CA tylko wtedy, gdy są podpisane przez ES.

24.4. Wymagania dla obiektów klasy CA KS3:

Narzędzia CA muszą wdrożyć mechanizm ochrony przed narzucaniem fałszywych komunikatów w oparciu o wykorzystanie narzędzi ES, które otrzymały potwierdzenie zgodności z wymaganiami dla narzędzi ES.

24.5. Wymagania dla klasy CA KB1:

Narzędzia CA muszą wdrażać mechanizm ochrony danych podczas przesyłania ich między fizycznie odseparowanymi komponentami w oparciu o wykorzystanie CIPF.

24.6. Wymagania dla obiektów CA klasy KB2 i KA1 są takie same jak dla obiektów CA klasy KB1.

25. Wymagania dotyczące rejestracji na wydarzenie:

25.1. Podstawowy system operacyjny narzędzi urzędu certyfikacji musi obsługiwać rejestrowanie audytu zdarzeń systemowych.

25.2. Wymagania dla obiektów klasy CA KS1:

Narzędzia CA muszą zaimplementować mechanizm, który selektywnie rejestruje w dzienniku audytu zdarzenia związane z wykonywaniem przez CA jego funkcji;
- wykaz zarejestrowanych zdarzeń powinien być zawarty w dokumentacji operacyjnej obiektów CA.

25.3. Wymagania dla obiektów CA klasy CS2 są takie same jak dla obiektów CA klasy CA1.

25.4. Wymagania dla obiektów klasy CA KS3:

Należy podjąć środki w celu wykrycia nieautoryzowanych zmian w dzienniku audytu przez użytkowników narzędzi CA, którzy nie są członkami grupy CA Tools Administrators.

25.5. Wymagania dla obiektów CA klasy KB1 pokrywają się z wymaganiami dla obiektów CA klasy KS3.

25.6. Wymagania dla klasy CA KV2:

Należy podjąć środki w celu wykrycia nieautoryzowanych zmian w każdym wpisie w dzienniku audytu.

25.7. Wymagania dla klasy CA KA1:

Dziennik audytu powinien być dostępny tylko dla administratora audytu, który może tylko przeglądać, kopiować i kompletne czyszczenie. Po oczyszczeniu pierwszy wpis w dzienniku audytu powinien automatycznie rejestrować fakt sprzątania, wskazując datę, godzinę oraz informacje o osobie, która wykonała operację.

26. Wymagania dotyczące niezawodności i stabilności funkcjonowania obiektów CA:

26.1. Wymagania dotyczące niezawodności i stabilności funkcjonowania obiektów CA powinny być określone i określone w SIWZ dla rozwoju (modernizacji) obiektów CA.

26.2. Wymagania dla obiektów klasy CA KS1:

Przeprowadzane jest obliczenie prawdopodobieństwa awarii i niesprawności CA AS, prowadzących do niewypełniania przez CA swoich funkcji.

26.3. Wymagania dla klasy CA KS2:

Należy przeprowadzić badania stabilności funkcjonowania obiektów CA.

26.4. Wymagania dla obiektów klasy CA KS3:

Na rozbudowę (modernizację) obiektów CA należy określić i wskazać w SIWZ wymagania dotyczące czasu odzyskania środków PZ po awarii;

Środki i środki zwiększające wiarygodność i stabilność funkcjonowania funduszy CA powinny zawierać mechanizmy kwotowania środków funduszy CA.

26.5. Wymagania dla klasy CA KB1:

Prawdopodobieństwo awarii i niesprawności CA AS, prowadzących do niewypełniania przez CA swoich funkcji, w ciągu dnia nie powinno przekraczać tego samego prawdopodobieństwa dla używanego CIPF.

26.6. Wymagania dla obiektów CA klasy KB2 i KA1 są takie same jak dla obiektów CA klasy KB1.

27. Wymagania dotyczące kluczowych informacji:

27.1. Procedura tworzenia, wykorzystywania, przechowywania i niszczenia kluczowych informacji jest określana zgodnie z wymogami dokumentacji operacyjnej dla ES i innych CIPF stosowanych przez CA.

27.2. Okres ważności klucza ES narzędzia ES używanego przez narzędzia CA musi być zgodny z wymaganiami ustanowionymi dla narzędzi ES.

27.3. Wymagania dla obiektów klasy CA KS1:

Niedozwolone jest kopiowanie informacji z dokumentów kluczy (kluczy kryptograficznych, w tym kluczy ES) na nośniki (np. dysk twardy) nie są kluczowi nosiciele, bez jego wstępnego zaszyfrowania (co powinno być realizowane przez wbudowaną funkcję używanego CIPF). Kopiowanie kluczowych dokumentów powinno odbywać się wyłącznie zgodnie z dokumentacją operacyjną dla używanego CIPF;

Klucze ES używane do podpisywania certyfikatów kluczy weryfikacyjnych ES oraz listy unikalnych numerów certyfikatów kluczy weryfikacyjnych ES, których ważność została zakończona w określonym momencie przez urząd certyfikacji przed ich wygaśnięciem (zwane dalej listą certyfikatów unieważnionych), powinny nie mogą być wykorzystywane do żadnych innych celów;

Okresy ważności wszystkich kluczy muszą być wskazane w dokumentacji operacyjnej dla obiektów CA.

27.4. Wymagania dla obiektów CA klasy KS2 i KS3 pokrywają się z wymaganiami dla obiektów CA klasy KS1.

27.5. Wymagania dla klasy CA KB1:

Należy podjąć środki organizacyjne i techniczne w celu wykluczenia możliwości skompromitowania klucza ES używanego do podpisywania certyfikatów kluczy weryfikacyjnych ES oraz list unieważnionych certyfikatów w przypadku ujawnienia kluczowych informacji dostępnych dla jednej osoby.

27.6. Wymagania dla klasy CA KV2:

Klucz ES używany do podpisywania certyfikatów kluczy weryfikacji ES oraz listy unieważnionych certyfikatów musi być generowany, przechowywany, używany i niszczony w narzędziu ES. Dozwolone jest używanie tylko narzędzi ES, które uzyskały potwierdzenie zgodności z wymaganiami dla narzędzi ES zgodnie z Ustawą Federalną;
- należy podjąć środki organizacyjne i techniczne w celu wykluczenia możliwości skompromitowania klucza ES używanego do podpisywania certyfikatów kluczy weryfikacyjnych ES i list unieważnionych certyfikatów w przypadku naruszenia kluczowych informacji dostępnych dla dwóch osób.

27.7. Wymagania dla klasy CA KA1:

Należy podjąć środki organizacyjne i techniczne, aby wykluczyć możliwość złamania klucza ES używanego do podpisywania certyfikatów kluczy weryfikacyjnych ES i list unieważnionych certyfikatów, gdy naruszone zostaną kluczowe informacje dostępne dla trzech osób.

28. Wymagania dotyczące tworzenia kopii zapasowych i przywracania narzędzi CA:

28.1. Narzędzia CA muszą implementować funkcje tworzenia kopii zapasowych i odzyskiwania w przypadku uszkodzenia AS i (lub) informacji przetwarzanych przez narzędzia CA. Podczas wykonywania kopii zapasowej należy wykluczyć możliwość kopiowania kluczy kryptograficznych.

28.2. Wymagania dla obiektów klasy CA KS1:

Dane zapisywane, gdy utworzyć kopię zapasową, powinno wystarczyć do przywrócenia funkcjonowania placówek CA do stanu ustalonego w momencie kopiowania.

28.3. Wymagania dla obiektów CA klasy KS2 i KS3 pokrywają się z wymaganiami dla obiektów CA klasy KS1.

28.4. Wymagania dla klasy CA KB1:

Należy podjąć środki w celu wykrycia nieautoryzowanych zmian w przechowywanych danych;
- w TOR dla rozwoju (modernizacji) obiektów CA oraz w dokumentacji eksploatacyjnej obiektów CA powinny być określone i określone wymagania dotyczące czasu odtworzenia.

28.5. Wymagania dla klasy CA KV2:

Chronione informacje zapisane podczas tworzenia kopii zapasowej powinny być przechowywane wyłącznie w postaci zaszyfrowanej.

28.6. Wymagania dla obiektów klasy CA KA1 są takie same jak dla obiektów klasy CA KB2.

29. Wymagania dotyczące tworzenia i unieważniania certyfikatów kluczy weryfikacyjnych ES:

29.1. Protokoły tworzenia i odwoływania certyfikatów kluczy weryfikacyjnych ES muszą być opisane w dokumentacji operacyjnej dla obiektów CA.

29.2. Utworzone przez CA certyfikaty kluczy weryfikacyjnych ES oraz listy unieważnionych certyfikatów muszą być zgodne z międzynarodowymi zaleceniami ITU-T X.509 7 (zwanymi dalej zaleceniami X.509). Wszystkie pola i uzupełnienia zawarte w certyfikacie klucza weryfikacyjnego ES oraz lista certyfikatów unieważnionych muszą być wypełnione zgodnie z zaleceniami X.509. W przypadku korzystania z alternatywnych formatów certyfikatów kluczy weryfikacyjnych ES wymagania dotyczące protokołów tworzenia i odwoływania certyfikatów kluczy weryfikacyjnych ES muszą być zdefiniowane i określone w ToR na potrzeby opracowywania (aktualizacji) narzędzi urzędu certyfikacji.

29.3. Narzędzia urzędu certyfikacji muszą implementować protokół unieważniania certyfikatu klucza weryfikacji ES przy użyciu list unieważnionych certyfikatów.

29.4. Dopuszcza się implementację protokołów unieważnienia bez korzystania z list unieważnionych certyfikatów, których wymagania muszą być określone w TOR dla rozwoju (modernizacji) narzędzi CA.

29.5. Wymagania dla obiektów klasy CA KS1:

Narzędzia CA muszą wdrożyć funkcję tworzenia certyfikatu klucza weryfikacyjnego ES na papierze. Procedura wydawania certyfikatu klucza weryfikacyjnego ES w wersji papierowej oraz procedura monitorowania zgodności certyfikatu klucza weryfikacyjnego ES w w formie elektronicznej i na papierze muszą być wskazane w dokumentacji operacyjnej dla obiektów CA;

Mechanizmy sprawdzania unikalności klucza weryfikacyjnego ES i posiadania odpowiedniego klucza ES muszą być zaimplementowane w narzędziach CA w stosunku do właściciela certyfikatu klucza weryfikacyjnego ES.

29.6. Wymagania dla obiektów CA klasy CS2 są takie same jak dla obiektów CA klasy CA1.

29.7. Wymagania dla obiektów klasy CA KS3:

Błąd wartości czasu w certyfikatach kluczy weryfikacyjnych ES i listach unieważnionych certyfikatów nie powinien przekraczać 10 minut.

29.8. Wymagania dla klasy CA KB1:

Błąd wartości czasu w certyfikatach kluczy weryfikacyjnych ES i listach unieważnionych certyfikatów nie powinien przekraczać 5 minut.

29.9. Wymagania dla obiektów CA klasy KB2 i CA1 są takie same jak wymagania dla obiektów CA klasy KB 1.

30. Wymagania dotyczące struktury certyfikatu klucza weryfikacyjnego ES oraz wykazu certyfikatów unieważnionych:

30.1. Wymagania dla obiektów klasy CA KS1:

Prawidłowe struktury certyfikatu klucza weryfikacyjnego ES oraz lista unieważnionych certyfikatów muszą być wymienione w dokumentacji operacyjnej dla obiektów CA;
- narzędzia CA powinny wdrożyć mechanizm monitorowania zgodności tworzonych certyfikatów kluczy weryfikacyjnych ES oraz list unieważnionych certyfikatów z daną strukturą;
- struktura certyfikatu klucza weryfikacyjnego ES musi zawierać pole zawierające informacje o klasie narzędzi CA, które zostały użyte do utworzenia tego certyfikatu klucza weryfikacyjnego ES oraz pole zawierające informacje o klasie narzędzia ES właściciela ES certyfikat klucza weryfikacyjnego.

30.2. Wymagania dla obiektów CA klasy KS2 i KS3 pokrywają się z wymaganiami dla obiektów CA klasy KS1.

30.3. Wymagania dla klasy CA KV1:

Narzędzia CA muszą wdrożyć mechanizm ustawiania przez administratora systemu zestawu prawidłowych dodatków do certyfikatu klucza weryfikacyjnego ES oraz listy certyfikatów unieważnionych.

30.4. Wymagania dla obiektów CA klasy KB2 i KA1 są takie same jak dla obiektów CA klasy KB1.

31. Wymagania dotyczące rejestru certyfikatów kluczy weryfikacyjnych ES i zapewnienia do niego dostępu:

31.1. Wymagania dla obiektów klasy CA KS1:

Narzędzia CA muszą zaimplementować mechanizmy przechowywania i wyszukiwania wszystkich utworzonych certyfikatów kluczy weryfikacyjnych ES oraz list unieważnionych certyfikatów w rejestrze, a także dostęp do sieci do rejestru.

31.2. Wymagania dla obiektów CA klasy CS2 są takie same jak dla obiektów CA klasy CA1.

31.3. Wymagania dla obiektów klasy CA KS3:

Narzędzia CA muszą wdrożyć mechanizm wyszukiwania certyfikatów kluczy weryfikacji ES oraz list certyfikatów unieważnionych w rejestrze certyfikatów kluczy weryfikacji ES według ich różnych atrybutów;
- wszystkie zmiany w rejestrze certyfikatów kluczy weryfikacyjnych ES muszą być odnotowane w dzienniku audytów.

31.4. Wymagania dla obiektów CA klas KB1, KB2 i CA1 są takie same jak wymagania dla obiektów CA klasy KS3.
32. Wymagania dotyczące weryfikacji ES w certyfikacie klucza weryfikacji ES:

32.1. Mechanizm weryfikacji podpisu w certyfikacie klucza weryfikacyjnego ES na żądanie uczestnika interakcji elektronicznej musi być określony i określony w dokumentacji operacyjnej obiektów CA.

32.2. Narzędzia CA muszą implementować mechanizm uwierzytelniania CA ES w wydawanych przez siebie certyfikatach klucza weryfikacyjnego ES.

32.3. Weryfikacja ES w certyfikacie klucza weryfikacyjnego ES odbywa się zgodnie z zaleceniami X.509, w tym: obowiązkowa kontrola wszystkie krytyczne dodatki.

32.4. Jeżeli na podstawie charakterystyki działania narzędzi CA dopuszcza się stosowanie alternatywnych formatów certyfikatu klucza weryfikacyjnego ES, należy określić i określić w SIWZ mechanizm weryfikacji podpisu w certyfikacie klucza weryfikacyjnego ES. rozwój (uaktualnienie) narzędzi CA.

33. Aby ograniczyć możliwości budowania kanałów ataków na obiekty CA z wykorzystaniem kanałów komunikacyjnych, należy stosować firewalle.

34. Wymagania dotyczące ochrony narzędzi CA przed wirusami komputerowymi i atakami komputerowymi należy określić i sprecyzować w SIWZ dla rozwoju (modernizacji) narzędzi CA.

35. Przy podłączaniu urządzeń CA do sieci teleinformatycznej, do której dostęp nie jest ograniczony do określonego kręgu osób, urządzenia te muszą spełniać wymagania dla urządzeń CA klasy KV2 lub KA1.

36. Badania narzędzi CA w celu potwierdzenia zgodności narzędzi CA z niniejszymi Wymaganiami należy przeprowadzić z wykorzystaniem wartości liczbowych parametrów i charakterystyk mechanizmów ochrony zaimplementowanych w narzędziach CA opracowanych przez FSB Rosji 8 .

1 Zarejestrowany przez Ministerstwo Sprawiedliwości Rosji 3 marca 2005 r., numer rejestracyjny 6382.
2 Zarejestrowany przez Ministerstwo Sprawiedliwości Rosji w dniu 25 maja 2010 r., numer rejestracyjny 17350.
3 Wymagana klasa opracowanych (zaktualizowanych) narzędzi CA jest określana przez klienta (programistę) narzędzi CA poprzez określenie możliwości tworzenia metod ataku, przygotowania i przeprowadzania ataków w oparciu o punkty 9-14 niniejszych Wymogów i jest wskazana w przydział taktyczno-techniczny lub przydział techniczny na przeprowadzenie eksperymentalnych prac projektowych lub integralną część prac rozwojowych nad rozbudową (modernizacją) obiektów CA (dalej T3 dla rozwoju (modernizacji) obiektów CA).
4 Środowisko oprogramowania, co pozwala na istnienie w nim tylko ustalonego zbioru podmiotów (programów, procesów).
5 Osoby, które są członkami grupy administratorów narzędzi CA i nie są znane jako naruszające.
6 Nałożenie fałszywej wiadomości to działanie odbierane przez uczestników interakcji elektronicznej lub za pośrednictwem CA jako przekazanie prawdziwej wiadomości w sposób zabezpieczony przed nieuprawnionym dostępem.
7 Zalecenie ITU-T X.509. Technologia informacyjna - Otwarte połączenie systemów - Katalog: ramy certyfikatów kluczy publicznych i atrybutów. 2008. http://www.itu.int/rec/T-REC-X.509-200811-i.
8 Punkt 47 ust. 9 Regulaminu Federalnej Służby Bezpieczeństwa Federacji Rosyjskiej, zatwierdzonego dekretem Prezydenta Federacji Rosyjskiej z dnia 11 sierpnia 2003 r. nr 960 (Sobraniye Zakonodatelstva Rossiyskoy Federatsii, 2003, nr 33, art. 3254; 2004, nr 28, art. 2883; 2005, nr 36, art. 3665; nr 49, art. 5200; 2006, nr 25, art. 2699; nr 31 (część I), art. 3463; 2007 205 ; Nr 49, poz. 6133; Nr 53, poz. 6554; 2008, Nr 36, poz. 4087; Nr 43, poz. 4921; Nr 47, poz. 5431; 2010 , Nr 17, poz. 2054; Nr 20, 2435; 2011, Nr 2, art. 267; Nr 9, art. 1222).