Któregoś dnia otrzymaliśmy zapytanie o usługi w chmurze. Określiliśmy ogólnie, co będzie od nas wymagane i odesłaliśmy listę pytań w celu wyjaśnienia szczegółów. Następnie przeanalizowaliśmy odpowiedzi i zdaliśmy sobie sprawę: klient chce umieścić w chmurze dane osobowe drugiego stopnia bezpieczeństwa. Odpowiadamy mu: „Masz drugi poziom danych osobowych, przepraszam, możemy stworzyć tylko chmurę prywatną”. A on: „Wiesz, ale w firmie X mogą mi wszystko publicznie wrzucać”.
Zdjęcie: Steve Crisp, Reuters
Dziwne rzeczy! Weszliśmy na stronę internetową firmy X, przestudiowaliśmy jej dokumenty certyfikacyjne, potrząsnęliśmy głowami i zdaliśmy sobie sprawę: istnieje wiele otwartych kwestii związanych z umieszczaniem danych osobowych i należy je szczegółowo rozwiązać. Właśnie to zrobimy w tym poście.
Jak wszystko powinno działać
Najpierw zastanówmy się, jakie kryteria służą do klasyfikacji danych osobowych na ten lub inny poziom bezpieczeństwa. Zależy to od kategorii danych, liczby podmiotów tych danych, które operator przechowuje i przetwarza, a także rodzaju aktualnych zagrożeń.
Rodzaje aktualnych zagrożeń zdefiniowano w z dnia 1 listopada 2012 r. „W sprawie zatwierdzenia wymagań dotyczących ochrony danych osobowych podczas ich przetwarzania w systemach informatycznych danych osobowych”:
„Zagrożenia typu 1 są istotne dla systemu informacyjnego, jeśli obejmuje on aktualne zagrożenia związane z z obecnością nieudokumentowanych (niezadeklarowanych) zdolności w oprogramowaniu systemowymwykorzystywane w systemie informatycznym.
Zagrożenia drugiego typu są istotne dla systemu informacyjnego, jeśli są dla niego m.in aktualne zagrożenia związane z z obecnością nieudokumentowanych (niezadeklarowanych) zdolności w oprogramowaniu aplikacyjnymwykorzystywane w systemie informatycznym.
Zagrożenia trzeciego typu są istotne dla systemu informatycznego, jeśli dla niego zagrożenia, które nie są ze sobą powiązane z obecnością nieudokumentowanych (niezadeklarowanych) zdolności w oprogramowaniu systemowym i aplikacyjnymwykorzystywane w systemie informatycznym.”
Najważniejsze w tych definicjach jest obecność nieudokumentowanych (niezadeklarowanych) zdolności. Aby potwierdzić brak nieudokumentowanych możliwości oprogramowania (w przypadku chmury jest to hypervisor), certyfikacja przeprowadzana jest przez FSTEC z Rosji. Jeśli operator PD zaakceptuje, że w oprogramowaniu nie ma takich możliwości, to odpowiadające im zagrożenia są nieistotne. Zagrożenia typu 1 i 2 są niezwykle rzadko uważane przez operatorów PD za istotne.
Oprócz określenia poziomu bezpieczeństwa PD, operator musi także określić konkretne aktualne zagrożenia chmury publicznej i na podstawie zidentyfikowanego poziomu bezpieczeństwa PD oraz aktualnych zagrożeń określić niezbędne środki i środki ochrony przed nimi.
FSTEC wyraźnie wymienia wszystkie główne zagrożenia (baza zagrożeń). Dostawcy infrastruktury chmurowej i asesorzy korzystają z tej bazy danych w swojej pracy. Oto przykłady zagrożeń:
: „Zagrożeniem jest możliwość naruszenia bezpieczeństwa danych użytkownika programów działających wewnątrz maszyny wirtualnej przez szkodliwe oprogramowanie działające poza maszyną wirtualną.” Zagrożenie to wynika z obecności luk w oprogramowaniu hypervisora, które zapewniają, że przestrzeń adresowa służąca do przechowywania danych użytkownika dla programów działających wewnątrz maszyny wirtualnej jest odizolowana od nieuprawnionego dostępu ze strony szkodliwego oprogramowania działającego poza maszyną wirtualną.
Implementacja tego zagrożenia jest możliwa pod warunkiem, że szkodliwy kod programu skutecznie pokona granice maszyny wirtualnej, nie tylko wykorzystując luki hypervisora, ale także przeprowadzając taki wpływ z niższych (w stosunku do hypervisora) poziomów funkcjonowanie systemu.”
: „Zagrożenie polega na możliwości nieuprawnionego dostępu do chronionych informacji jednego konsumenta usług w chmurze od drugiego. Zagrożenie to wynika z faktu, że ze względu na charakter technologii chmurowych konsumenci usług chmurowych muszą korzystać z tej samej infrastruktury chmurowej. Zagrożenie to może zostać zrealizowane w przypadku błędów przy rozdzielaniu elementów infrastruktury chmurowej pomiędzy odbiorcami usług chmurowych, a także przy izolowaniu ich zasobów i oddzielaniu od siebie danych.”
Przed tymi zagrożeniami można się chronić jedynie za pomocą hypervisora, ponieważ to on zarządza zasobami wirtualnymi. Dlatego hiperwizor należy traktować jako środek ochrony.
I zgodnie z z dnia 18 lutego 2013 r. hiperwizor musi posiadać certyfikat non-NDV na poziomie 4, w przeciwnym razie wykorzystanie za jego pomocą danych osobowych poziomu 1 i 2 będzie nielegalne („Klauzula 12. ... W celu zapewnienia 1 i 2 poziomu bezpieczeństwa danych osobowych, a także zapewnienia 3 poziomu bezpieczeństwa danych osobowych w systemach informatycznych, dla których zagrożenia typu 2 klasyfikowane są jako aktualne, stosowane są narzędzia bezpieczeństwa informacji, których oprogramowanie zostało przetestowane co najmniej według 4 poziomu kontroli pod kątem braku niezadeklarowanych zdolności”).
Tylko jeden hypervisor opracowany w Rosji ma wymagany poziom certyfikacji NDV-4. . Delikatnie mówiąc, nie jest to najpopularniejsze rozwiązanie. Chmury komercyjne z reguły budowane są w oparciu o VMware vSphere, KVM, Microsoft Hyper-V. Żaden z tych produktów nie posiada certyfikatu NDV-4. Dlaczego? Prawdopodobnie uzyskanie takiego certyfikatu dla producentów nie jest jeszcze ekonomicznie uzasadnione.
I jedyne co nam pozostaje dla danych osobowych poziomu 1 i 2 w chmurze publicznej to Horizon BC. Smutne ale prawdziwe.
Jak wszystko (naszym zdaniem) naprawdę działa
Na pierwszy rzut oka wszystko jest dość rygorystyczne: zagrożenia te należy wyeliminować, poprawnie konfigurując standardowe mechanizmy ochrony hypervisora certyfikowanego zgodnie z NDV-4. Ale jest jedna luka. Zgodnie z rozporządzeniem FSTEC nr 21 („klauzula 2 Bezpieczeństwo danych osobowych przetwarzanych w systemie informacyjnym danych osobowych (zwanym dalej systemem informatycznym) zapewnia operator lub osoba przetwarzająca dane osobowe w imieniu operatora zgodnie z art. Federacja Rosyjska"), dostawcy niezależnie oceniają istotność ewentualnych zagrożeń i odpowiednio dobierają środki ochrony. Dlatego jeśli nie zaakceptujesz zagrożeń UBI.44 i UBI.101 jako aktualnych, nie będzie potrzeby korzystania z hypervisora certyfikowanego zgodnie z NDV-4, który właśnie powinien zapewniać ochronę przed nimi. I to wystarczy, aby uzyskać certyfikat zgodności chmury publicznej z poziomami 1 i 2 bezpieczeństwa danych osobowych, z czego Roskomnadzor będzie w pełni usatysfakcjonowany.
Oczywiście oprócz Roskomnadzora FSTEC może przyjść z inspekcją - a ta organizacja jest znacznie bardziej skrupulatna w kwestiach technicznych. Pewnie ją zainteresuje, dlaczego właśnie groźby UBI.44 i UBI.101 uznano za nieistotne? Zwykle jednak FSTEC przeprowadza inspekcję dopiero po otrzymaniu informacji o jakimś znaczącym incydencie. W tym przypadku usługa federalna w pierwszej kolejności trafia do operatora danych osobowych – czyli klienta usług chmurowych. W najgorszym wypadku operator otrzymuje niewielką karę – np. za Twittera na początku roku w podobnym przypadku wyniósł 5000 rubli. Następnie FSTEC idzie dalej do dostawcy usług w chmurze. Które równie dobrze mogą zostać pozbawione licencji z powodu niespełnienia wymogów regulacyjnych – a to są zupełnie inne ryzyka, zarówno dla dostawcy chmury, jak i dla jego klientów. Ale powtarzam, Aby sprawdzić FSTEC, zwykle potrzebujesz wyraźnego powodu. Dlatego dostawcy usług w chmurze są skłonni podejmować ryzyko. Aż do pierwszego poważnego incydentu.
Istnieje również grupa „bardziej odpowiedzialnych” dostawców, którzy uważają, że możliwe jest zamknięcie wszystkich zagrożeń poprzez dodanie do hiperwizora dodatku takiego jak vGate. Jednak w środowisku wirtualnym rozproszonym wśród klientów dla niektórych zagrożeń (na przykład powyższy UBI.101) skuteczny mechanizm ochrony można wdrożyć jedynie na poziomie hypervisora certyfikowanego zgodnie z NDV-4, ponieważ wszelkie systemy dodatkowe do standardowe funkcje hypervisora do zarządzania zasobami (w szczególności pamięcią RAM) nie mają wpływu.
Jak my pracujemy
Mamy segment chmurowy zaimplementowany na hypervisorze certyfikowanym przez FSTEC (ale bez certyfikatu dla NDV-4). Segment ten posiada certyfikaty, dzięki czemu na jego podstawie można przechowywać dane osobowe w chmurze 3 i 4 poziomy bezpieczeństwa — w tym przypadku nie trzeba przestrzegać wymagań dotyczących ochrony przed niezadeklarowanymi zdolnościami. Przy okazji, oto architektura naszego segmentu bezpiecznej chmury:
Systemy danych osobowych 1 i 2 poziomy bezpieczeństwa Realizujemy wyłącznie na dedykowanym sprzęcie. Tylko w tym przypadku zagrożenie ze strony UBI.101 tak naprawdę nie jest istotne, ponieważ szafy serwerowe, które nie są połączone jednym środowiskiem wirtualnym, nie mogą na siebie wpływać, nawet jeśli znajdują się w tym samym centrum danych. W takich przypadkach oferujemy dedykowaną usługę wynajmu sprzętu (nazywaną także Hardware as a service).
Jeśli nie jesteś pewien, jaki poziom bezpieczeństwa jest wymagany dla Twojego systemu danych osobowych, pomagamy również w jego klasyfikacji.
Wniosek
Nasze badanie na małym rynku pokazało, że niektórzy operatorzy chmur są dość skłonni zaryzykować zarówno bezpieczeństwo danych klientów, jak i własną przyszłość, aby otrzymać zamówienie. Ale w tych sprawach stosujemy inną politykę, którą pokrótce opisaliśmy tuż powyżej. Chętnie odpowiemy na Twoje pytania w komentarzach.
Źródło: www.habr.com