Egy napon felhőszolgáltatásra vonatkozó kérést kaptunk. Általánosságban felvázoltuk, hogy mit kívánnak tőlünk, és visszaküldtük a kérdések listáját, hogy tisztázzuk a részleteket. Aztán elemeztük a válaszokat, és rájöttünk: az ügyfél a második biztonsági szint személyes adatait szeretné a felhőben elhelyezni. Azt válaszoljuk neki: „Második szintű személyes adataid vannak, sajnálom, csak privát felhőt tudunk létrehozni.” És ő: "Tudod, de az X cégnél mindent közzétehetnek nekem nyilvánosan."
Fotó: Steve Crisp, Reuters
Furcsa dolgok! Felkerestük az X cég honlapját, áttanulmányoztuk a tanúsító okmányaikat, megráztuk a fejünket és rájöttünk: nagyon sok nyitott kérdés van a személyes adatok elhelyezésében, és ezeket alaposan meg kell vizsgálni. Ebben a bejegyzésben ezt fogjuk tenni.
Hogyan kell mindennek működnie
Először is nézzük meg, milyen kritériumok alapján minősítik a személyes adatokat egy vagy másik biztonsági szintnek. Ez függ az adatok kategóriájától, az üzemeltető által tárolt és feldolgozott adatok alanyainak számától, valamint az aktuális fenyegetések típusától.
Az aktuális fenyegetések típusait a 1. november 2012-jén kelt „A személyes adatok személyes adatok információs rendszerekben történő kezelése során történő védelmére vonatkozó követelmények jóváhagyásáról”:
„Az 1-es típusú fenyegetések relevánsak egy információs rendszer számára, ha tartalmaz kapcsolódó aktuális fenyegetések dokumentálatlan (be nem jelentett) képességek jelenlétével rendszerszoftverbenhasználják az információs rendszerben.
A 2. típusú fenyegetések akkor relevánsak egy információs rendszer számára, ha számára, beleértve kapcsolódó aktuális fenyegetések dokumentálatlan (be nem jelentett) képességek jelenlétével alkalmazási szoftverbenhasználják az információs rendszerben.
A 3. típusú fenyegetések relevánsak egy információs rendszer számára, ha annak számára fenyegetések, amelyek nem kapcsolódnak egymáshoz dokumentálatlan (be nem jelentett) képességek jelenlétével rendszer- és alkalmazásszoftverekbenhasználják az információs rendszerben."
Ezekben a definíciókban a fő dolog a nem dokumentált (be nem jelentett) képességek jelenléte. A nem dokumentált szoftverképességek hiányának megerősítése érdekében (a felhő esetében ez egy hipervizor), a tanúsítást az orosz FSTEC végzi. Ha a PD kezelő elfogadja, hogy a szoftverben nincsenek ilyen képességek, akkor a megfelelő fenyegetések nem relevánsak. Az 1. és 2. típusú fenyegetéseket a PD operátorok rendkívül ritkán tartják relevánsnak.
Az üzemeltetőnek a PD biztonság szintjének meghatározása mellett meg kell határoznia a nyilvános felhőt érintő konkrét aktuális fenyegetéseket is, és az azonosított PD biztonsági szint és az aktuális fenyegetések alapján meg kell határoznia az ellenük való védekezéshez szükséges intézkedéseket és eszközöket.
Az FSTEC egyértelműen felsorolja az összes fő fenyegetést (fenyegetés adatbázis). A felhő infrastruktúra szolgáltatói és értékelői ezt az adatbázist használják munkájuk során. Íme, példák a fenyegetésekre:
: "A fenyegetés annak lehetősége, hogy a virtuális gépen kívül működő rosszindulatú szoftverek megsértik a virtuális gépen belül működő programok felhasználói adatainak biztonságát." Ez a fenyegetés a hipervizor-szoftver sérülékenységeinek köszönhető, amely biztosítja, hogy a virtuális gépen belül működő programok felhasználói adatainak tárolására használt címteret elszigeteljék a virtuális gépen kívül működő rosszindulatú szoftverek illetéktelen hozzáférésétől.
Ennek a fenyegetésnek a megvalósítása akkor lehetséges, ha a rosszindulatú programkód sikeresen átlépi a virtuális gép korlátait, nemcsak a hypervisor sebezhetőségeinek kihasználásával, hanem azáltal is, hogy az ilyen hatást a hipervizorhoz képest alacsonyabb szintről hajtja végre. a rendszer működése."
: „A veszély abban rejlik, hogy a felhőszolgáltatás egyik fogyasztójának védett információihoz jogosulatlan hozzáférhet a másiktól. Ez a veszély abból adódik, hogy a felhőtechnológiák természetéből adódóan a felhőszolgáltatás fogyasztóinak ugyanazon a felhő-infrastruktúrán kell osztozniuk. Ez a fenyegetés akkor valósulhat meg, ha hibákat követnek el a felhő-infrastruktúra elemek felhőszolgáltatás-fogyasztók közötti szétválasztásakor, valamint az erőforrásaik elkülönítésekor és az adatok egymástól való elkülönítésekor.”
Ezekkel a fenyegetésekkel szemben csak hypervisor segítségével lehet védekezni, hiszen az kezeli a virtuális erőforrásokat. Így a hipervizort védelmi eszköznek kell tekinteni.
És ennek megfelelően 18. február 2013-i keltezésű hypervisornak 4. szintű nem NDV minősítéssel kell rendelkeznie, ellenkező esetben az 1. és 2. szintű személyes adatok vele való felhasználása jogellenes lesz („12. szakasz. ... A személyes adatok 1. és 2. szintű biztonságának, valamint a 3. szintű személyes adatok biztonságának biztosítására azokban az információs rendszerekben, amelyeknél a 2. típusú fenyegetések aktuálisnak minősülnek, olyan információbiztonsági eszközöket alkalmaznak, amelyek szoftverei legalább a be nem jelentett képességek hiányának ellenőrzése 4. szintje szerint tesztelve").
Csak egy, Oroszországban kifejlesztett hipervizor rendelkezik a szükséges szintű tanúsítvánnyal, az NDV-4. . Enyhén szólva nem a legnépszerűbb megoldás. A kereskedelmi felhők általában VMware vSphere, KVM, Microsoft Hyper-V alapján épülnek fel. Ezen termékek egyike sem rendelkezik NDV-4 tanúsítvánnyal. Miért? Valószínű, hogy a gyártók ilyen tanúsítvány megszerzése gazdaságilag még nem indokolt.
És már csak a Horizon BC marad nekünk az 1. és 2. szintű személyes adatokhoz a nyilvános felhőben. Szomorú, de igaz.
Hogyan működik minden (szerintünk) valójában
Első pillantásra minden meglehetősen szigorú: ezeket a fenyegetéseket az NDV-4 szerint tanúsított hypervisor szabványos védelmi mechanizmusainak megfelelő konfigurálásával kell kiküszöbölni. De van egy kiskapu. Az FSTEC 21. számú rendeletének megfelelően („2. pont A személyes adatok biztonságát a személyes adatok információs rendszerében (a továbbiakban: információs rendszer) történő kezelés során az üzemeltető vagy az üzemeltető nevében személyes adatot feldolgozó személy biztosítja a Orosz Föderáció"), a szolgáltatók önállóan értékelik a lehetséges fenyegetések relevanciáját, és ennek megfelelően választanak ki védelmi intézkedéseket. Ezért, ha nem fogadja el aktuálisnak az UBI.44 és UBI.101 fenyegetéseket, akkor nem lesz szükség az NDV-4 szerint tanúsított hypervisor használatára, amely éppen az, hogy védelmet nyújtson ellenük. És ez elegendő lesz ahhoz, hogy megszerezze a nyilvános felhő megfelelőségi tanúsítványát a személyes adatok biztonságának 1. és 2. szintjének, amellyel a Roskomnadzor teljesen elégedett lesz.
Természetesen a Roszkomnadzor mellett az FSTEC is jöhet ellenőrzéssel – ez a szervezet pedig sokkal aprólékosabb technikai kérdésekben. Valószínűleg érdekelni fogja, hogy pontosan az UBI.44 és UBI.101 fenyegetéseket miért tekintették irrelevánsnak? Az FSTEC azonban általában csak akkor hajt végre ellenőrzést, ha információt kap valamilyen jelentős eseményről. Ebben az esetben a szövetségi szolgáltatás először a személyes adatok üzemeltetőjéhez érkezik - vagyis a felhőszolgáltatások ügyfeléhez. A legrosszabb esetben kisebb bírságot kap az üzemeltető – például a Twitterért az év elején hasonló esetben 5000 rubelt tett ki. Ezután az FSTEC továbbmegy a felhőszolgáltatóhoz. Amelyeket a hatósági követelmények be nem tartása miatt megfoszthatnak a licenctől – ezek pedig teljesen más kockázatok, mind a felhőszolgáltató, mind az ügyfelei számára. De ismétlem, Az FSTEC ellenőrzéséhez általában egyértelmű ok szükséges. A felhőszolgáltatók tehát hajlandóak kockázatot vállalni. Az első komolyabb incidensig.
Van egy csoport „felelősségteljesebb” szolgáltató is, akik úgy vélik, hogy minden fenyegetést be lehet zárni egy olyan kiegészítővel, mint a vGate, a hypervisorhoz. De bizonyos fenyegetések (például a fenti UBI.101) ügyfelek között elosztott virtuális környezetben hatékony védelmi mechanizmus csak az NDV-4 szerint tanúsított hypervisor szintjén valósítható meg, mivel bármely kiegészítő rendszer az erőforrások (különösen a RAM) kezelésére szolgáló hypervisor szabványos funkciói nem érintik.
Hogyan dolgozunk
Van egy felhőszegmensünk az FSTEC által tanúsított hipervizoron (de NDV-4 tanúsítvány nélkül). Ez a szegmens tanúsított, így ez alapján személyes adatok tárolhatók a felhőben 3 és 4 biztonsági szint — itt nem kell betartani a be nem jelentett képességekkel szembeni védelem követelményeit. Itt van egyébként a biztonságos felhő szegmensünk architektúrája:
Személyes adatok rendszerei 1 és 2 biztonsági szint Kizárólag erre a célra szolgáló berendezéseken végezzük a kivitelezést. Csak ebben az esetben például az UBI.101 veszélye valóban nem releváns, mivel a nem egy virtuális környezet által egyesített szerverállványok még akkor sem befolyásolhatják egymást, ha ugyanabban az adatközpontban helyezkednek el. Ilyen esetekre külön berendezésbérlési szolgáltatást ajánlunk (ezt Hardvernek is hívják szolgáltatásként).
Ha nem biztos abban, hogy személyes adatrendszerének milyen biztonsági szintre van szüksége, segítünk a besorolásban is.
Teljesítmény
Kisebb piackutatásunk kimutatta, hogy egyes felhőszolgáltatók meglehetősen hajlandóak kockáztatni mind az ügyfelek adatainak biztonságát, mind a saját jövőjüket a megrendelés megszerzéséért. De ezekben a kérdésekben egy másik politikához ragaszkodunk, amelyet fentebb röviden ismertettünk. Szívesen válaszolunk kérdéseire a megjegyzésekben.
Forrás: will.com