Egyszer egy felkérés érkezett hozzánk a felhőszolgáltatásokra. Áttekintettük általánosságban, hogy mire lesz szükség tőlünk, és válaszként küldtünk egy lista kérdést a részletek pontosításához. Aztán elemeztük a válaszokat, és megértettük: az ügyfél második szintű védettségű személyes adatokat szeretne tárolni a felhőben. Válaszolunk neki: „Önnek második szintű személyes adatai vannak, sajnáljuk, csak magán felhőt tudunk készíteni.” Mire ő: „Tudják, a X cégnél mindezeket nyilvános helyen is el tudják helyezni.”
Fotó: Steve Crisp, Reuters
Furcsa dolgok! Látogattunk a X cég weboldalára, tanulmányoztuk az akkreditációs dokumentumaikat, és megráztuk a fejünket, amikor rájöttünk: a személyes adatok elhelyezésével kapcsolatban nagyon sok nyitott kérdés van, amelyeket alaposan meg kell vitatnunk. Ezt fogjuk tenni ebben a posztban.
Hogyan kell mindennek működnie
Először is nézzük meg, milyen kritériumok alapján sorolják a személyes adatokat különböző szintű védettségébe. Ez a dátumok kategóriájától, a kezelő által tárolt és feldolgozott adatfélék számától, valamint az aktuális fenyegetések típusától függ.
A releváns fenyegetési típusok meghatározását a 2012. november 1-jén, „A személyes adatok védelmére vonatkozó követelmények jóváhagyásáról a személyes adatok feldolgozása információs rendszereiben”:
„Az első típusú fenyegetések relevánsak egy információs rendszer számára, ha a következő fenyegetések is érvényesek: azok a fenyegetések, amelyek a nem dokumentált (nem nyilvános) lehetőségekkel kapcsolatosak a rendszerprogramban,amelyet az információs rendszer használnak.
A második típusú fenyegetések relevánsak egy információs rendszer számára, ha a következő fenyegetések is érvényesek azok a fenyegetések, amelyek a nem dokumentált (nem nyilvános) lehetőségekkel kapcsolatosak a alkalmazásprogrambanamelyet az információs rendszer használnak.
A harmadik típusú fenyegetések relevánsak egy információs rendszer számára, ha a rendszerhez kapcsolódnak azok a fenyegetések, amelyek nem kapcsolódnak a nem dokumentált (nem nyilvános) lehetőségekkel kapcsolatosak a rendszer- és alkalmazásprogramokban,amelyet az információs rendszer használnak.”
A legfontosabb ezekben a meghatározásokban a nem dokumentált (nem nyilvános) lehetőségek megléte. A nem dokumentált lehetőségek megcáfolására a szoftverben (felhő esetén a hipervizor) Oroszország FSTEK szabályozói tanúsítást végeznek. Ha a személyes adatok kezelője elfogadja, hogy nincsenek ilyen lehetőségek a szoftverben, akkor a hozzájuk tartozó fenyegetések sem relevánsak. Az első és második típusú fenyegetéseket a személyes adatok kezelői rendkívül ritkán tekintik relevánsnak.
A személyes adatok védelmi szintjének meghatározása mellett az üzemeltetőnek meg kell határoznia a nyilvános felhővel kapcsolatos konkrét, aktuális fenyegetéseket, és az országos védelmi szint és az aktuális fenyegetések alapján ki kell alakítania a szükséges védelmi intézkedéseket és eszközöket.
A FSTEK-nél az összes fő fenyegetés pontosan fel van tüntetve a (fenyegetések adatbázisában). A felhőinfrastruktúra szolgáltatói és minősítők ezt az adatbázist használják. Íme néhány példa a fenyegetésekre:
: „A fenyegetés abban rejlik, hogy a virtuális gépen belül futó programok felhasználói adatainak biztonsága megsérülhet olyan rosszindulatú szoftverek által, amelyek a virtuális gépen kívül működnek. E fenyegetés oka a hipervizor szoftverének sebezhetőségei, amelyek garantálják a felhasználói adatok virtuális gépen belüli tárolásához használt címzési tér izoláltságát a rosszindulatú szoftverek általi jogosulatlan hozzáféréstől, amelyek a virtuális gépen kívül működnek.
A fenyegetés megvalósulása akkor lehetséges, ha a rosszindulatú kód sikeresen átlépi a virtuális gép határait nem csupán a hipervizor sebezhetőségeit kihasználva, hanem egy alacsonyabb (a hipervizorhoz viszonyítva) működési szintről történő beavatkozással is.
: „A fenyegetés abban rejlik, hogy az egyik felhőszolgáltatás igénybe vevője jogosulatlan hozzáférést szerezhet a védett információkhoz egy másik felhasználótól. E fenyegetés oka az, hogy a felhőtechnológia sajátosságai miatt a felhőszolgáltatással rendelkező felhasználók ugyanazt a felhő infrastruktúrát kényszerülnek megosztani. A fenyegetés megvalósulása lehetséges, ha hibát követnek el a felhő infrastruktúra elemeinek elválasztásakor a felhasználók között, valamint ha nem megfelelően izolálják a forrásaikat és elkülönítik az adataikat egymástól.
Ezekkel a fenyegetésekkel szemben csak a hipervizor segítségével lehet védekezni, mivel ő irányítja a virtuális erőforrásokat. Így a hipervizort védekezési eszközként kell kezelni.
És a 2013. február 18-tól kezdődően a hypervisoroknak a 4. szintű NVD hiányosságok mentességére vonatkozó tanúsítvánnyal kell rendelkezniük, különben a vele való együttműködés során a 1. és 2. szintű személyes adatok felhasználása jogszerűtlen lesz („12. pont. ... A személyes adatok 1. és 2. szintű védelme, valamint a személyes adatok 3. szintű védelme érdekében az informatikai rendszerekben, ahol a fenyegetések a 2. típusra vonatkoznak, olyan információvédelmi eszközöket alkalmaznak, amelyek szoftvere legalább a 4. szintű NVD-ellenőrzésen átesett.”).
A szükséges tanúsítványszinttel rendelkező NVD-4 tanúsítvánnyal csak egy orosz fejlesztésű hypervisor rendelkezik — . Finoman szólva, nem a legnépszerűbb megoldás. A kereskedelmi felhők általában a VMware vSphere, KVM, Microsoft Hyper-V alapjain épülnek. E termékek közül egyik sem rendelkezik NVD-4 tanúsítvánnyal. Miért? Valószínűleg a gyártók számára gazdaságilag nem indokolt ennek megszerzése.
Így a 1. és 2. szintű személyes adatok számára a nyilvános felhőben csak a Horizont BS marad. Szomorú, de igaz.
Hogyan működik minden (véleményünk szerint) valójában
Első pillantásra minden elég szigorúnak tűnik: a megjelölt fenyegetéseket el kell hárítani a hypervisor helyes beállításával, amelyet NVD-4 szerint tanúsítottak. De van egy kiskapu. A FSTEK 21. számú rendelete értelmében („2. pont. A személyes adatok biztonsága a személyes adatok informatikai rendszerében való feldolgozása során (továbbiakban: informatikai rendszer) a kezelőt vagy azt a személyt biztosítja, aki a kezelő megbízásából személyes adatokat dolgoz fel, a következő szerint: Orosz Föderáció”), a szolgáltatók önállóan értékelik a lehetséges fenyegetések aktuális mivoltát, és ennek megfelelően választanak védelmi intézkedéseket. Ezért ha a UBI.44 és UBI.101 fenyegetéseket nem tartják aktuálisnak, akkor nem is lesz szükség a NVD-4 szerint tanúsított hypervisor használatára, amely éppen ezeket a védelmeket kell, hogy nyújtsa. Ez elegendő lesz a nyilvános felhő 1. és 2. szintű PDL védelmi tanúsítványának megkövetéséhez, amellyel a Roszkomnadzor teljesen elégedett lesz.
Természetesen a Roszkomnadzor mellett a FSTEK is megjelenhet ellenőrzés céljából – ennek a szervezetnek a műszaki kérdésekben sokkal szigorúbb a hozzáállása. Biztosan érdekli őket, hogy miért éppen az UBI.44 és UBI.101 fenyegetéseit tartották aktuálisnak? Általában a FSTEK csak akkor indít ellenőrzést, ha valamilyen figyelemfelkeltő incidenst tapasztal. Ebben az esetben az szövetségi szolgálat először a személyadatok operátorához – vagyis a felhőszolgáltatások megrendelőjéhez – fordul. A legrosszabb esetben az operátor kis bírságot kap – például a Twitter esetében az év elején hasonló esetben 5000 rubel volt. Ezután a FSTEK továbbhalad a felhőszolgáltatóhoz, amelyet akár meg is foszthatnak a licenctől a szabályozási követelmények meg nem feleléséért – ez már egészen más kockázatokat jelent, mind a felhőszolgáltató, mind az ügyfelek számára. De hangsúlyozom, a FSTEK-nek általában világos indoklásra van szüksége az ellenőrzéshez. Így a felhőszolgáltatók készen állnak a kockázatok vállalására. Az első komoly incidenst megelőzően.
Van egy másik csoport, a "felelősebb" szolgáltatók, akik azt gondolják, hogy minden fenyegetést le lehet zárni egy vGate típusú hypervisor kiegészítéssel. De a megrendelők között megosztott virtuális környezetben egyes fenyegetések (például az előbb említett UBI.101) esetén csak a tanúsított NDV-4 hypervisor szintjén lehet hatékony védelmi mechanizmust megvalósítani, mivel a hypervisor működését irányító rendszerekre (különösen a RAM kezelésére) semmilyen kiegészítők nem hatnak.
Hogyan dolgozunk
Van egy felhőszegmensünk, amely egy FSTEK által tanúsított hypervisoron alapul (de NDV-4 tanúsítás nélkül). Ez a szegmens hitelesített, így ebben a felhőben személyes adatokat lehet elhelyezni. 3. és 4. védelmi szint – itt nem szükséges betartani a nem nyilvános lehetőségekkel szembeni védelmi követelményeket. Itt, amúgy, a védett felhőszegmenseink architektúrája:
Személyes adatok számára 1. és 2. védelmi szint Csak dedikált hardveren valósítjuk meg. Csak ilyen esetben, például az UBI.101 fenyegetés valóban nem aktuális, mivel a dedikált szerverállványok, amelyek nem egy közös virtuális környezetben működnek, nem befolyásolhatják egymást, még akkor sem, ha egy adatközpontban helyezkednek el. Az ilyen esetekre dedikált hardver bérlés szolgáltatást kínálunk (más néven Hardver mint szolgáltatás).
Ha nem biztos abban, hogy milyen védelem szükséges a személyes adataihoz, akkor segítünk a megfelelő osztályozásban is.
Következtetés
Kis piackutatásunk azt mutatta, hogy egyes felhőszolgáltatók hajlandóak kockáztatni az ügyfeleik adatainak biztonságát és saját jövőjüket a megrendelés megszerzése érdekében. De mi más politikát képviselünk ezeken a területeken, amit röviden fenn említettünk. Örömmel válaszolunk a kérdéseikre a hozzászólásokban.
Forrás: habr.com
