Когато Ерик Шмит, сега ръководител на Google, за пръв път използва термина „облак“ за обозначаване на разпределена изчислителна система в мрежата, той едва ли знаеше, че това е една от онези думи, които често се срещат в легендите. В почти всички митове на народите по света божествените същества живеят много близо до небето - върху облаците. В резултат на това терминът „облачни изчисления“ е много популярен сред маркетолозите, тъй като предоставя пространство за творчество. Ще се опитаме също да вербализираме тези митове и да разберем колко органично те се комбинират с ИТ.

Смъртта на Мерлин

Един от героите в цикъла от легенди за крал Артур и неговата Кръгла маса е магьосникът и магьосник Мерлин, който помогна на Артър по време на неговото управление. Показателно е, че Мерлин се оказа затворен в облаците. Той, желаейки да се похвали с младата магьосница и да покаже магическата си сила, построи замък от облаци и покани страстта си да го разгледа. Магьосницата обаче се оказа хитра и затвори магьосника в собствения му облачен замък. След това никой не е видял Мерлин, така че се смята, че той е умрял някъде там - в замъка от облаци, който самият той е построил.

Сега „магьосниците от ИТ“ също са изградили цяла митология около разпределените изчисления, така че за да не бъдете затворени в тези „ключалки“, първо трябва да разберете какви са тези облаци, тоест да отделите маркетинга от котлетите.

Първоначално имаше само един облак - именно с този символ Интернет традиционно се обозначаваше. Този облак означаваше събирането на всички компютри, свързани чрез IP протокол и имащи собствен IP адрес. С течение на времето Интернет започна да разпределя сървърни ферми, които са инсталирани при доставчици и на които се основават уеб проекти. В същото време, за да се осигури високо натоварване и устойчивост на повреди, най-големите уеб системи станаха многостепенни и разпределени.

В типична такава система могат да се разграничат следните нива: обратен прокси, който действа и като балансиращ натоварване и SSL декриптор, самият уеб сървър, след това сървър на приложения, СУБД и система за съхранение. В същото време на всяко ниво може да има няколко елемента, изпълняващи същите функции, и следователно не винаги е било ясно кои компоненти са били използвани за обработка на потребителски заявки. И когато не е ясно, това са облаците. Затова те започнаха да казват, че потребителските заявки се изпълняват някъде в „облака“ от голям брой сървъри. Така възниква терминът „облачни изчисления“.

Въпреки че първоначално облачните изчисления бяха свързани с публично достъпни уеб проекти - портали, с развитието на разпределените отказоустойчиви уеб системи те започнаха да се използват за решаване на вътрешни корпоративни проблеми. Това беше времето на бума на корпоративните портали, базирани на уеб технологии, разработени в публичните системи. В същото време корпоративните системи започнаха да се консолидират в центрове за данни, които бяха по -лесни и по -евтини за поддръжка.

Въпреки това би било неефективно да се разпредели отделен сървър за всеки елемент от облака - не всички елементи от облака се зареждат еднакво, така че индустрията за виртуализация започна да се развива паралелно. В публичните облаци се оказа доста популярен, тъй като даде възможност да се разграничат правата за достъп и да се осигури бързо прехвърляне на елемент от разпределена система към друг хардуерен носител. Без виртуализация облачните изчисления биха били по -малко динамични и мащабируеми, поради което сега облаците обикновено се състоят от виртуални машини.

Облачните изчисления се свързват основно с отдаването под наем на приложения, дефиниращи три вида такива услуги: IaaS - инфраструктура като услуга, PaaS - платформа като услуга и SaaS - софтуер като услуга. Понякога сигурността като услуга също се свежда до SaaS, но за да не се бъркат облачните услуги за сигурност с наемане на софтуер, е по -добре да го наречем ISaaC - Информационна сигурност като облак. Такива услуги също започват да се предоставят. Не бъркайте обаче аутсорсинга на приложенията и облачните изчисления, тъй като облаците могат да бъдат вътрешни, публични и хибридни. Всеки от тези видове облаци има свои собствени характеристики при организиране на система за сигурност.

Трите стъпки на Вишну

Бог Вишну в индуистката митология е известен с факта, че именно той завладява пространството за човешкия живот с помощта на три стъпки: първата е направена на земята, втората - в облаците, а третата - в най -високите обитавам. В съответствие с Риг Веда, именно с това действие Вишну завладява всички тези пространства за хората.

Съвременните ИТ също правят подобна „втора стъпка“ - от земята до облаците. За да не паднете от тези облаци на земята обаче, си струва да се погрижите за безопасността. В първата част анализирах структурата на облака толкова подробно, за да разбера какви заплахи съществуват за облачните изчисления. От горното трябва да се разграничат следните класове заплахи:

Традиционни атаки срещу софтуер... Те са свързани с уязвимостта на мрежовите протоколи, операционните системи, модулните компоненти и други. Това са традиционни заплахи, за защита срещу които е достатъчно да инсталирате антивирусна програма, защитна стена, IPS и други обсъждани компоненти. Важно е само тези защити да са адаптирани към облачната инфраструктура и да работят ефективно във виртуализирана среда.

Функционални атаки срещу облачни елементи... Този тип атака е свързана с наслояването на облака, общ принцип на сигурност, че цялостната защита на системата е равна на тази на най -слабата връзка. Така че успешна DoS атака срещу обратен прокси, инсталиран пред облака, ще блокира достъпа до целия облак, въпреки че всички комуникации вътре в облака ще работят без намеса. По същия начин, SQL инжекция, преминала през сървъра на приложения, ще даде достъп до системни данни, независимо от правилата за достъп в слоя за съхранение на данни. За да се предпазите от функционални атаки, за всеки облачен слой трябва да използвате специфични средства за защита: за прокси - защита срещу DoS атаки, за уеб сървър - контрол на целостта на страницата, за сървър на приложения - екран на ниво приложение, за СУБД слой - защита срещу SQL -инжекции, за системата за съхранение - архивиране и контрол на достъпа. Отделно всеки от тези защитни механизми вече е създаден, но те не са събрани заедно за цялостна защита на облака, така че задачата за интегрирането им в една система трябва да бъде решена по време на създаването на облака.

Атаки на клиенти... Този вид атака се практикува в уеб средата, но е от значение и за облака, тъй като клиентите се свързват с облака, обикновено с помощта на браузър. Той включва такива атаки като Cross Site Scripting (XSS), отвличане на уеб сесии, кражба на пароли, „човек в средата“ и други. Традиционно силното удостоверяване и шифрованата комуникация с взаимно удостоверяване са били защита срещу тези атаки, но не всички създатели на облаци могат да си позволят такива разточителни и обикновено не много удобни средства за защита. Следователно в тази индустрия на информационна сигурност все още има нерешени задачи и пространство за създаване на нови средства за защита.

Заплахи за виртуализация... Тъй като платформата за облачни компоненти традиционно е виртуализирана среда, атаките срещу системата за виртуализация също заплашват целия облак като цяло. Този вид заплаха е уникална за облачните изчисления, затова ще я разгледаме по -отблизо по -долу. Решения за някои заплахи за виртуализация сега започват да се появяват, но тази индустрия е съвсем нова, поради което досега съществуващите решения все още не са разработени. Напълно възможно е пазарът на информационна сигурност скоро да разработи средства за защита срещу този вид заплахи.

Изчерпателни облачни заплахи... Контролът и управлението на облаците също е проблем за сигурността. Как да гарантираме, че всички облачни ресурси се отчитат и в него няма неконтролирани виртуални машини, не се стартират ненужни бизнес процеси и не се нарушава взаимната конфигурация на слоеве и елементи на облака. Този вид заплаха е свързана с управляемостта на облака като единна информационна система и търсенето на злоупотреби или други смущения в работата на облака, което може да доведе до ненужни разходи за поддържане на здравето на информационната система. Например, ако има облак, който ви позволява да откриете вирус в него с помощта на подаден файл, тогава как да предотвратите кражбата на такива детектори? Този вид заплаха е най -високото ниво и подозирам, че за него няма универсални средства за защита - за всеки облак цялостната му защита трябва да бъде изградена индивидуално. Това може да бъде подпомогнато от най -общия модел за управление на риска, който все още трябва да бъде правилно приложен към облачните инфраструктури.

Първите два вида заплахи вече са достатъчно проучени и за тях е разработена защита, но те все още трябва да бъдат адаптирани за използване в облака. Например защитните стени са предназначени да защитават периметъра, но в облака не е лесно да се разпредели периметър на отделен клиент, което прави защитата много по -трудна. Следователно технологията на защитната стена трябва да бъде адаптирана към облачната инфраструктура. Работата в тази посока сега се извършва активно, например от Check Point.

Нов вид заплаха за облачните изчисления са проблемите с виртуализацията. Факт е, че когато се използва тази технология, в системата се появяват допълнителни елементи, които могат да бъдат атакувани. Те включват хипервизор, система за прехвърляне на виртуални машини от един хост на друг и система за управление на виртуални машини. Нека разгледаме по -подробно какви атаки могат да претърпят изброените елементи.

Атаки на хипервизор... Всъщност ключовият елемент на виртуалната система е хипервизорът, който осигурява разделянето на ресурсите на физическия компютър между виртуални машини. Намесата в работата на хипервизора може да доведе до факта, че една виртуална машина може да получи достъп до паметта и ресурсите на друга, да прехване мрежовия й трафик, да отнеме нейните физически ресурси и дори напълно да измести виртуалната машина от сървъра. Досега малко хакери разбират как точно работи хипервизорът, така че практически няма атаки от този тип, но това не гарантира, че те няма да се появят в бъдеще.

Мигрирайте виртуални машини... Трябва да се отбележи, че виртуалната машина е файл, който може да бъде стартиран за изпълнение в различни облачни възли. Системите за управление на виртуални машини осигуряват механизми за прехвърляне на виртуални машини от един хост на друг. Файлът на виртуалната машина обаче може да бъде откраднат и да се опита да се изпълни извън облака. Невъзможно е да се извади физически сървър от центъра за данни, но виртуална машина може да бъде открадната през мрежата, без да има физически достъп до сървърите. Вярно е, че отделна виртуална машина извън облака няма практическа стойност - трябва да откраднете поне една виртуална машина от всеки слой, както и данни от системата за съхранение, за да възстановите подобен облак, въпреки това виртуализацията доста позволява кражба на части или целия облак. Тоест намесата в механизмите за прехвърляне на виртуални машини създава нови рискове за информационната система.

Атаки на контролната система... Големият брой виртуални машини, които се използват в облаците, особено в публичните облаци, изискват системи за управление, които могат надеждно да контролират създаването, миграцията и изхвърлянето на виртуални машини. Намесата в системите за управление може да доведе до появата на невидими виртуални машини, блокиране на някои машини и заместване на неоторизирани елементи в облачните слоеве. Всичко това позволява на нападателите да получават информация от облака или да улавят части от него или целия облак.

Трябва да се отбележи, че досега всички изброени по -горе заплахи са чисто хипотетични, тъй като практически няма информация за реални атаки от този тип. В същото време, когато виртуализацията и облакът станат достатъчно популярни, всички тези видове атаки могат да бъдат съвсем реални. Следователно те трябва да се имат предвид дори на етапа на проектиране на облачни системи.

Отвъд седмото небе

Апостол Павел твърди, че познава човек, който е бил издигнат до седмото небе. Оттогава фразата „седмо небе“ е здраво закрепена за обозначаването на рая. Не всички християнски светци обаче имаха честта да посетят дори първото небе, но няма такъв човек, който да не мечтае да погледне седмото небе поне с едно око.

Може би именно тази легенда е подтикнала създателите на Trend Micro да назоват един от своите проекти за защита на облака Cloud Nine - деветия облак. Това очевидно е над седмия. Сега обаче това име се дава на голямо разнообразие от неща: песни, детективски истории, компютърни игри, но е напълно възможно това име да е вдъхновено от християнската легенда за Павел.

Въпреки това, досега компанията Trend Micro публикува само информация, че Cloud Nine ще бъде свързана с криптиране на данни в облака. Именно криптирането на данни дава възможност за защита срещу повечето заплахи за данните в публичния облак, така че сега такива проекти ще бъдат активно разработвани. Нека си представим какви средства за защита все още могат да бъдат полезни за смекчаване на описаните по -горе рискове.

На първо място, трябва да осигурите надеждна идентификация както на потребителите на облак, така и на неговите компоненти. За да направите това, най-вероятно можете да използвате готови системи за единична идентификация (SSO), които са базирани на Kerberos и протокола за взаимно хардуерно удостоверяване. След това ще ви трябват системи за управление на самоличността, които ви позволяват да конфигурирате правата за достъп на потребителите до различни системи, използвайки управление, основано на ролите. Разбира се, трябва да се потърсите с дефиницията на ролите и минималните права за всяка роля, но след като конфигурирате системата, тя може да се използва дълго време.

Когато всички участници в процеса и техните права са определени, трябва да наблюдавате спазването на тези права и откриването на административни грешки. Това изисква системи за обработка на събития от средства за защита на облачните елементи и допълнителни защитни механизми, като защитни стени, антивируси, IPS и други. Вярно е, че си струва да използвате тези опции, които могат да работят в среда за виртуализация - това ще бъде по -ефективно.

Освен това трябва да използвате и някакъв вид машина за измами, която би ви позволила да откривате измами при използването на облаци, тоест да намалите най -трудния риск от намеса в бизнес процесите. Вярно е, че сега на пазара най -вероятно няма машина за измами, която да позволява работа с облаци, но технологиите за откриване на случаи на измами и злоупотреби вече са разработени за телефония. Тъй като в облаците ще трябва да бъде внедрена система за фактуриране, машината за измами трябва да бъде свързана с нея. По този начин ще бъде възможно поне да се контролират заплахите за бизнес процесите в облака.

Какви други защитни механизми могат да се използват за защита на облаците? Въпросът е все още отворен.

Има няколко метода за изграждане на корпоративна ИТ инфраструктура. Разполагането на всички ресурси и услуги в облачна платформа е само един от тях. Предразсъдъците относно сигурността на облачните решения обаче често се превръщат в пречка по този начин. В тази статия ще разберем как системата за сигурност е подредена в облака на един от най -известните руски доставчици - Yandex.

Приказката е лъжа, но в нея има намек

Началото на тази история може да бъде разказано като известна приказка. В компанията имаше трима администратори: старшият беше умен човек, средният беше този и онзи, най -малкият беше ... стажант на enikeys. Стартирах потребители в Active Directory и обърнах опашки към tsiska. Дойде време компанията да се разшири и кралят, тоест шефът, призова административната си армия. Искам, казва той, нови уеб услуги за нашите клиенти, собствено съхранение на файлове, управлявани бази данни и виртуални машини за тестване на софтуер.

Най -младият веднага предложи да създаде своя собствена инфраструктура от нулата: закупуване на сървъри, инсталиране и конфигуриране на софтуер, разширяване на основния интернет канал и добавяне на резервен към него - за надеждност. И компанията е по -спокойна: хардуерът е винаги под ръка, по всяко време можете да замените или преконфигурирате нещо, а той самият ще има отлична възможност да изпомпва административните си умения. Те изчислиха и проляха сълзи: компанията няма да може да си позволи такива разходи. Големите предприятия могат да направят това, но за средния и малкия бизнес се оказва твърде скъпо. Е, не е нужно просто да закупите оборудване, да оборудвате сървърна стая, да окачите климатици и да настроите пожароизвестители, също така трябва да организирате смяна, за да поддържате ред ден и нощ и да отблъсквате мрежовите атаки на натрапчиви хора от интернет . И по някаква причина администраторите не искаха да работят през нощта и през почивните дни. Само за двойно плащане.

Старшият администратор погледна замислено към прозореца на терминала и предложи да постави всички услуги в облака. Но след това неговите колеги започнаха да се плашат взаимно с ужасни истории: казват, че облачната инфраструктура има незащитени интерфейси и API, лошо балансиращи натоварването на различни клиенти, което може да увреди собствените ви ресурси, а също така е нестабилно за кражба на данни и външни атаки . И като цяло е страшно да прехвърлите контрола върху критични данни и софтуер на неоторизирани лица, с които не сте изяли половин килограм сол и сте изпили кофа бира.

Mediocre даде идеята да постави цялата ИТ система в центъра за данни на доставчика, в нейните канали. На това и реши. Нашето трио обаче очакваше няколко изненади, не всички от които бяха приятни.

Първо, всяка мрежова инфраструктура изисква задължителната наличност на инструменти за сигурност и защита, които, разбира се, са били внедрени, конфигурирани и стартирани. Но цената на хардуерните ресурси, които използват, както се оказа, трябва да бъде платена от самия клиент. А съвременната система за информационна сигурност консумира значителни ресурси.

Второ, бизнесът продължава да расте и инфраструктурата, изградена от самото начало, бързо достига тавана на мащабируемостта. Освен това, за неговото разширяване, проста промяна на тарифата не беше достатъчна: в този случай много услуги трябваше да бъдат прехвърлени на други сървъри, да бъдат конфигурирани и нещо напълно преработено от нулата.

И накрая, един ден, поради критична уязвимост в едно от приложенията, цялата система се срина. Администраторите бързо го взеха от архивите, но не успяха бързо да разберат причините за случилото се, защото забравиха да настроят резервно копие за услугите за регистриране. Ценното време беше загубено, а времето, както казва народната мъдрост, са пари.

Изчисляването на разходите и обобщаването на резултатите доведе ръководството на компанията до разочароващи заключения: администраторът, който от самото начало предложи използването на облачния модел на IaaS - „инфраструктура като услуга“, беше прав. Що се отнася до сигурността на такива платформи, струва си да говорим за това отделно. И ние ще направим това, като използваме примера на най -популярната от тези услуги - Yandex.Cloud.

Сигурност в Yandex.Cloud

Нека започнем, както Чеширската котка съветва момичето Алис, от самото начало. Тоест от въпроса за разграничаване на отговорността. В Yandex.Cloud, както и във всички други подобни платформи, доставчикът отговаря за сигурността на услугите, предоставяни на потребителите, докато клиентът е отговорен за осигуряването на правилната работа на разработваните от него приложения, организиране и ограничаване на отдалечения достъп до специални ресурси , конфигуриране на бази данни и виртуални машини, контрол върху регистрирането. За това обаче той е снабден с всички необходими инструменти.

Сигурността на облачната инфраструктура на Yandex има няколко нива, всяко от които прилага свои собствени принципи на защита и използва отделен арсенал от технологии.

Физически слой

Не е тайна, че Yandex има свои собствени центрове за данни, които се обслужват от техните отдели за сигурност. Говорим не само за видеонаблюдение и услуги за контрол на достъпа, предназначени да предотвратят външни лица да влизат в сървърните помещения, но и за системи за климатичен контрол, пожарогасене и непрекъснато захранване. Охранителите на Stern са малко полезни, ако сървърната ви стойка веднъж е залята с вода от пожарните пръскачки или ако прегрее след повреда на климатика. Това определено няма да им се случи в центровете за данни на Yandex.

В допълнение, облачният хардуер е физически отделен от "големия Yandex": те са разположени в различни стелажи, но по същия начин преминават през редовна рутинна поддръжка и подмяна на компоненти. На границата на тези две инфраструктури се използват хардуерни защитни стени, а вътре в облака - софтуерна базирана на хост защитна стена. В допълнение, комутаторите от най-високата стойка използват системата за контрол на достъпа (ACL), което значително подобрява сигурността на цялата инфраструктура. Yandex непрекъснато сканира облака отвън в търсене на отворени портове и грешки в конфигурацията, така че потенциалната уязвимост може да бъде разпозната и елиминирана предварително. За служители, работещи с облачни ресурси, е внедрена централизирана система за удостоверяване, използваща SSH ключове с ролево базиран модел на достъп, и всички администраторски сесии се регистрират. Този подход е част от модела Secure по подразбиране, широко използван от Yandex: защитата е включена в ИТ инфраструктурата на етапа на нейното проектиране и развитие и не се добавя по -късно, когато всичко вече е пуснато в експлоатация.

Ниво на инфраструктура

На ниво „хардуерна и софтуерна логика“ Yandex.Cloud използва три инфраструктурни услуги: Compute Cloud, Virtual Private Cloud и Yandex Managed Services. А сега за всеки от тях малко по -подробно.

Compute Cloud

Тази услуга осигурява мащабируема изчислителна мощ за различни задачи, като например хостинг на уеб проекти и услуги с високо натоварване, тестване и прототипиране, или временна миграция на ИТ инфраструктура за периода на ремонт или подмяна на собствено оборудване. Можете да управлявате услугата чрез конзолата, командния ред (CLI), SDK или API.

Защитата на Compute Cloud се основава на факта, че всички клиентски виртуални машини използват поне две ядра и няма свръх ангажираност при разпределението на паметта. Тъй като в този случай само клиентският код се изпълнява на ядрото, системата не е податлива на уязвимости като L1TF, Spectre и Meltdown или атаки на странични канали.

В допълнение, Yandex използва свой собствен Qemu / KVM монтаж, в който всичко ненужно е деактивирано, оставяйки само минималния набор от код и библиотеки, необходими за работата на хипервизорите. В същото време процесите се стартират под контрола на базирана на AppArmor апаратура, която, използвайки политики за сигурност, определя до кои системни ресурси и с какви привилегии може да има достъп определено приложение. AppArmor, работещ върху всяка виртуална машина, намалява риска клиентското приложение да има достъп до хипервизора от виртуалната машина. За да получава и обработва регистрационни файлове, Yandex е изградил процес за доставяне на данни от AppArmor и пясъчници до собствения Splunk.

Виртуален частен облак

Услугата Virtual Private Cloud ви позволява да създавате облачни мрежи, използвани за прехвърляне на информация между различни ресурси и тяхната връзка с Интернет. Тази услуга се поддържа физически от три независими центъра за данни. В тази среда логическата изолация се извършва на ниво мултипротоколна комуникация - MPLS. В същото време Yandex постоянно размива SDN и интерфейса на хипервизор, тоест от страната на виртуалните машини непрекъснато се изпраща поток от деформирани пакети към външната среда, за да получи отговор от SDN, да го анализира и да затвори възможното пропуски в конфигурацията. DDoS защитата се активира автоматично при създаване на виртуални машини.

Управлявани услуги на Yandex

Управляваните услуги на Yandex са софтуерна среда за управление на различни услуги: СУБД, клъстери Kubernetes, виртуални сървъри в инфраструктурата на Yandex.Cloud. Тук услугата поема по -голямата част от работата по сигурността. Всички архиви, криптиране на резервни копия, управление на уязвимости и т.н. се предоставят автоматично от софтуера Yandex.Cloud.

Инструменти за реакция при инциденти

За да се реагира своевременно на инциденти със сигурността на информацията, е необходимо навреме да се идентифицира източникът на проблема. За това е необходимо да се използват надеждни инструменти за наблюдение, които трябва да работят денонощно и без прекъсвания. Такива системи неизбежно ще консумират ресурси, но Yandex.Cloud не прехвърля разходите за изчислителна мощност на инструментите за сигурност върху потребителите на платформата.

При избора на инструментариума Yandex се ръководеше от друго важно изискване: в случай на успешна експлоатация на 0 дневна уязвимост в едно от приложенията, нападателят не трябва да напуска хоста на приложението, докато екипът по сигурността трябва незабавно да научи за инцидента и да реагира като необходими.

Не на последно място, желанието беше всички инструменти да бъдат с отворен код. Тези критерии са напълно изпълнени от пакета AppArmor + Osquery, който беше решено да се използва в Yandex.Cloud.

AppArmor

AppArmor беше споменато по -горе: това е проактивен софтуерен инструмент за защита, базиран на персонализирани профили за сигурност. Профилите използват технологията за етикетиране на поверителността на задължителния контрол на достъпа (MAC), внедрена с помощта на LSM директно в самото ядро ​​на Linux от версия 2.6. Разработчиците на Yandex избраха AppArmor по следните причини:

• лекота и скорост, тъй като инструментът разчита на част от ядрото на Linux;
• това е решение с отворен код;
• AppArmor може да бъде внедрен много бързо в Linux, без да пише никакъв код;
• гъвкава конфигурация е възможна с помощта на конфигурационни файлове.

Osquery

Osquery е инструмент за мониторинг на сигурността на системата, разработен от Facebook и сега успешно се използва в много ИТ индустрии. В същото време инструментът е междуплатформен и с отворен код.

С Osquery можете да събирате информация за състоянието на различни компоненти на операционната система, да я акумулирате, да я трансформирате в стандартизиран JSON формат и да я изпращате на избрания получател. Този инструмент ви позволява да пишете и изпращате стандартни SQL заявки към приложението си, които се съхраняват в базата данни rocksdb. Можете да персонализирате честотата и условията за изпълнение или обработка на тези заявки.

Стандартните таблици вече са внедрили много функции, например можете да получите списък с процеси, изпълнявани в системата, инсталирани пакети, текущия набор от правила за iptables, crontab обекти и т.н. Изпълнена е поддръжката за получаване и анализиране на събития от системата за одит на ядрото (използва се в Yandex.Cloud за обработка на събития в AppArmor).

Самият Osquery е написан на C ++ и се разпространява с отворен код, можете да ги променяте и да добавяте нови таблици към основната кодова база, както и да създавате свои собствени разширения в C, Go или Python.

Полезна функция на Osquery е наличието на разпределена система за заявки, с която можете да изпълнявате заявки в реално време към всички виртуални машини в мрежата. Това може да бъде полезно, например, ако се открие уязвимост в пакет: с една заявка можете да получите списък с машини, на които е инсталиран този пакет. Тази функция се използва широко при администриране на големи разпределени системи със сложна инфраструктура.

изводи

Ако се върнем към историята, разказана в самото начало на тази статия, ще видим, че страховете, които накараха нашите герои да откажат да внедрят инфраструктура на облачна платформа, се оказаха неоснователни. Поне що се отнася до Yandex.Cloud. Сигурността на облачната инфраструктура, създадена от Yandex, има многопластова ешелонирана архитектура и следователно осигурява високо ниво на защита срещу повечето от известните в момента заплахи.

В същото време, благодарение на спестяванията от рутинната поддръжка на хардуера и плащането за ресурси, консумирани от системите за наблюдение и предупреждение за инциденти, които Yandex предприема, използването на Yandex.Cloud значително спестява пари за малкия и среден бизнес. Разбира се, напълно изоставяне на ИТ отдела или отдела, отговорен за сигурността на информацията (особено ако и двете от тези роли са обединени в един екип) няма да работи. Но Yandex.Cloud значително ще намали разходите за труд и режийните разходи.

Тъй като Yandex.Cloud предоставя на своите клиенти защитена инфраструктура с всички необходими инструменти за сигурност, те могат да се съсредоточат върху бизнес процесите, оставяйки задачите по обслужването и мониторинга на хардуера на доставчика. Това не премахва необходимостта от настоящото администриране на виртуални машини, бази данни и приложения, но във всеки случай такъв набор от задачи би трябвало да бъде решен. Като цяло можем да кажем, че Yandex.Cloud спестява не само пари, но и време. И вторият, за разлика от първия, е незаменим ресурс.

ГРИГОРИЕВ1 Виталий Робертович, кандидат на техническите науки, доцент КУЗНЕЦОВ2 Владимир Сергеевич

ПРОБЛЕМИ НА ИДЕНТИФИКАЦИЯ НА УРЕНИТЕЛНОСТИТЕ В ОБЛАЧЕН ИЗЧИСЛИТЕЛЕН МОДЕЛ

Статията предоставя преглед на подходите за изграждане на концептуален модел на облачни изчисления, както и сравнение на съществуващите възгледи за идентифициране на уязвимости, присъщи на системите, изградени на базата на този модел. Ключови думи: облачни изчисления, уязвимост, ядро ​​на заплаха, виртуализация.

Целта на тази статия е да предостави преглед на подходите за изграждане на концептуален модел на облачни изчисления, очертани в референтната архитектура на NIST облачни изчисления, и да сравни възгледите на водещите организации в тази област относно уязвимостите в този изчислителен модел, както и основните играчи на пазара на облачни изчисления.

Облачните изчисления са модел, който осигурява удобен достъп при поискване до мрежата до конфигурируеми споделени изчислителни ресурси (мрежи, сървъри, хранилища на данни, приложения и услуги), които се доставят бързо с минимално управление и взаимодействие с доставчика на услуги. Това определение на Националния институт по стандартизация (NIST) е широко прието в цялата индустрия. Определението за облачни изчисления включва пет основни характеристики, три модела на услуги и четири модела за внедряване.

Пет основни характеристики

Самообслужване при поискване

Потребителите могат да получават, контролират и управляват компютърни ресурси без помощта на системните администратори. Достъп до широка мрежа - Изчислителните услуги се предоставят чрез стандартни мрежи и хетерогенни устройства.

Оперативна еластичност - 1T-

ресурсите могат бързо да бъдат мащабирани във всяка посока, ако е необходимо.

Ресурсен пул - ИТ ресурсите се споделят от различни приложения и потребители в прекъснат режим.

Изчисляване на цената на услугата - използването на 1T ресурс се проследява за всяко приложение и потребител, като правило, за осигуряване на фактуриране за публичния облак и вътрешни плащания за използването на частни облаци.

Три модела на обслужване

Софтуер като услуга (SaaS) - Обикновено приложенията се доставят на крайните потребители като услуга чрез уеб браузър. Днес има стотици предложения на SaaS, вариращи от хоризонтални корпоративни приложения до специфични за индустрията предложения, както и потребителски приложения като имейл.

Платформа като услуга (PaaS) - Платформа за разработка и внедряване на приложения се предоставя като услуга на разработчиците за създаване, внедряване и управление на SaaS приложения. Обикновено платформата включва бази данни, междинен софтуер и инструменти за разработка, като всички те се предоставят като услуга през Интернет. PaaS често се насочва към език за програмиране или API като Java или Python. Виртуализирана, клъстерирана разпределена изчислителна архитектура често служи като основа за системите

1 - МГТУ МИРЕА, доцент от катедра „Информационна сигурност“;

2 - Московски държавен университет по радиоелектроника и автоматизация (MSTU MIREA), студент.

Paradise, тъй като мрежовата структура на мрежовия ресурс осигурява необходимата еластична мащабируемост и обединяване на ресурси. Инфраструктура като услуга (IaaS) - Сървърите, съхранението и мрежовият хардуер се предоставят като услуга. Този инфраструктурен хардуер често се виртуализира, така че софтуерът за виртуализация, управление и операционна система също са част от LaaR.

Четири модела на внедряване

Частни облаци - Проектирани за изключително използване на една организация и обикновено се контролират, управляват и хостват от частни центрове за данни. Хостингът и управлението на частни облаци могат да бъдат възложени на външен доставчик на услуги, но често

Новият облак остава в изключителна употреба на една организация. Обществени облаци - споделяни от много организации (потребители), поддържани и управлявани от външни доставчици на услуги.

Групови облаци - Използва се от група свързани организации, които искат да се възползват от споделена облачна компютърна среда. Например, група може да се състои от различни военни клонове, всички университети в даден регион или всички доставчици на голям производител.

Хибридни облаци - появяват се, когато организация използва както частен, така и публичен облак за едно и също приложение, за да се възползва от двете. Например, в сценарий "буря", организация-потребител в случай на стандартно натоварване на приложението

използва частен облак и когато натоварването е пиково, например в края на тримесечие или през ваканционния сезон, той използва потенциала на публичния облак, като впоследствие връща тези ресурси в общия пул, когато те не са необходими.

На фиг. 1 показва концептуалния модел на облачни изчисления съгласно документа "NIST Cloud Computing Reference Architecture". Както е показано на фиг. 1 модел в стандарта подчертава основните участници в облачната система: облачен потребител, облачен доставчик, облачен одитор, облачен брокер, облачен посредник. Всеки участник е лице или организация, изпълняващи свои собствени функции по внедряване или предоставяне на облачни изчисления. Облачен потребител - лице или организация, която поддържа бизнес взаимодействие с други

Облачен потребител

Облачен одитор

C Одит на сигурността L I J

I Одит на поверителност I J

(Одит на предоставените услуги |

Облачен доставчик

Комплекс от нива

Персонално ниво

^ Услуга като услуга ^ ^ Платформа като услуга ^ Инфраструктура като услуга)

Ниво на абстракция

Физически слой

Облачна услуга

^ J поддръжка ^ J персонализиране

Преносимост

Облачен брокер

Облачен посредник

Ориз. 1. Концептуален модел, разработен от специалисти на NIST

tori мрежа и използва услуги от доставчици на облак. Облачен доставчик - лице, организация или всеки, който е отговорен за наличието на услуги, предоставяни на заинтересованите потребители. Cloud auditor - участник, който може да извършва независими оценки на облачните услуги, услуги и сигурността на облачната реализация. Облачен брокер е участник, който управлява използването, производителността и доставката на облачни услуги на потребителя и преговаря за взаимодействието между доставчиците на облак и потребителите в облака. Облачен посредник - Посредник, който осигурява комуникация и доставка на облачни услуги между доставчици на облак и потребители на облак.

Предимства и предизвикателства на облачните изчисления

Последните проучвания на ИТ специалисти показват, че облачните изчисления предлагат две основни предимства при организирането на разпределени услуги - скорост и цена. С автономен достъп до група изчислителни ресурси, потребителите могат да бъдат включени в интересуващите ги процеси за минути, а не за седмици или месеци, както беше в миналото. Изчислителният капацитет също се променя бързо благодарение на еластично мащабируемата Grid изчислителна среда. Тъй като в облачните изчисления потребителите плащат само за това, което използват, а мащабируемостта и автоматизацията достигат високо ниво, съотношението цена и ефективност на предоставяните услуги също е много привлекателен фактор за всички участници в обменните процеси.

Същите анкети показват, че има редица сериозни съображения, които възпират някои компании да преминат към облака. Сред тези съображения сигурността в облачните изчисления е далеч водеща.

За адекватна оценка на сигурността в облачните системи има смисъл да се проучат вижданията за заплахите в тази област на основните играчи на пазара. Ще сравним настоящите подходи за облачни заплахи, представени в пътната карта на стандартите за облачни изчислителни системи NIST с тези, предлагани от IBM, Oracle и VmWare.

Стандарт за сигурност на американските национални институти за стандарти за изчислителни облаци

Пътната карта на стандартите за облачни изчисления NIST, приета от NIST, обхваща възможните потенциални видове атаки срещу услугите за облачни изчисления:

♦ компрометиране на поверителността и наличността на данни, предавани от доставчици на облак;

♦ атаки, които произтичат от структурните характеристики и възможности на облачната изчислителна среда за усилване и увеличаване на щетите от атаки;

♦ неоторизиран достъп на потребителите (чрез неправилно удостоверяване или оторизация, или уязвимости, въведени чрез периодична поддръжка) до софтуер, данни и ресурси, използвани от оторизиран потребител на облачни услуги;

♦ увеличаване на нивото на мрежови атаки, като DoS, експлоатиране на софтуер, чието разработване не е взело предвид модела на заплахата за разпределени интернет ресурси, както и уязвимости в ресурси, достъпни от частни мрежи;

♦ ограничени възможности за криптиране на данни в среда с голям брой участници;

♦ преносимост в резултат на използването на нестандартни API, които затрудняват потребителя в облака да мигрира към нов доставчик в облак, когато не са изпълнени изискванията за наличност;

♦ атаки, които експлоатират физическото абстрахиране на облачни ресурси и използват недостатъци в одиторските записи и процедури;

♦ атаки срещу виртуални машини, които не са актуализирани съответно;

♦ атаки, използващи несъответствия в глобалната и частната политика за сигурност.

Стандартът също така подчертава основните цели на сигурността при облачните изчисления:

♦ защита на потребителските данни от неоторизиран достъп, разкриване, промяна или преглед; предполага поддръжка на услугата за идентификация по такъв начин, че потребителят да има възможност да извършва политики за идентификация и контрол на достъпа на оторизирани потребители, които имат достъп до облачни услуги; този подход предполага способността на потребителя да предоставя достъп до своите данни избирателно на други потребители;

♦ защита срещу заплахи по веригата на доставки; включва потвърждение на степента на доверие и надеждност на доставчика на услуги в същата степен като степента на доверие в използвания софтуер и хардуер;

♦ предотвратяване на неоторизиран достъп до облачни изчислителни ресурси; включва създаване на защитени домейни, които са логически отделени от ресурсите (например логическо разделяне на натоварванията, изпълнявани на същия физически сървър чрез хипервизор в многопотребителска среда) и използване на защитени конфигурации по подразбиране;

♦ разработване на уеб приложения, внедрени в облака за модела на заплахата от разпределени интернет ресурси и интегриране на функциите за сигурност в процеса на разработка на софтуер;

♦ защита на интернет браузърите от атаки за смекчаване на слабостите в сигурността на крайните потребители; включва предприемане на мерки за защита на интернет връзката на персонални компютри чрез използването на защитен софтуер, защитни стени (защитни стени) и периодично инсталиране на актуализации;

♦ внедряване на технологии за контрол на достъпа и откриване на проникване

niy от доставчик на облак и провеждане на независима оценка, за да се провери тяхната наличност; включва (но не се ограничава до) традиционни мерки за сигурност по периметъра, комбинирани с модел за сигурност на домейн; Традиционната защита на периметъра включва ограничаване на физическия достъп до мрежата и устройствата, защита на отделни компоненти от експлоатация чрез внедряване на актуализации, задаване на повечето настройки за защита по подразбиране, деактивиране на всички неизползвани портове и услуги, използване на ролево базиран контрол на достъпа, мониторинг на одиторските записи, минимизиране на използваните привилегии , използвайки антивирусни пакети и криптирани връзки;

♦ определяне на доверени граници между доставчика (ите) на услугите и потребителите, за да се гарантира, че разрешената отговорност за осигуряване на сигурност е ясна;

♦ поддръжка на преносимост, осъществявана така, че потребителят да има възможност да смени доставчика на облак в случаите, когато трябва да отговаря на изискванията за цялост, наличност, поверителност; това включва възможността да затворите акаунта в момента и да копирате данни от един доставчик на услуги към друг.

По този начин пътната карта на стандартите за облачни изчислителни системи NIST, приета от NIST, определя основен списък с атаки срещу облачни системи и списък с основни задачи, които трябва

се справя с кандидатстване

подходящи мерки.

Нека формулираме заплахите за информационната сигурност на облачната система:

♦ U1 - заплаха (компромис, наличност и т.н ...) за данните;

♦ U2 - заплахи, породени от структурните характеристики и възможности на архитектурата за внедряване на разпределени изчисления;

♦ U4 - заплахи, свързани с неправилен модел на заплаха;

♦ U5 - заплахи, свързани с неправилно използване на криптиране (необходимо е да се използва криптиране в среда, в която има няколко потока от данни);

♦ U6 - заплахи, свързани с използването на нестандартни API по време на разработката;

♦ U7 - заплахи за виртуализация;

♦ U8 - заплахи, използващи несъответствия в глобалните политики за сигурност.

Гледната точка на IBM за сигурността в облачните изчисления

Ръководство за защита в облака Препоръките на IBM за внедряване на защита в облак ни позволяват да правим изводи за визията на IBM за сигурността. Въз основа на този документ можем да разширим предложения по -рано списък на заплахи, а именно:

♦ U9 - заплахи, свързани с достъп на трети страни до физически ресурси \ системи;

♦ U10 - заплахи, свързани с неправилно изхвърляне (жизнен цикъл) на лична информация;

♦ U11 - заплахи, свързани с нарушаване на регионалните, националните и международните закони относно обработваната информация.

Подходи на IBM, Oracle и VmWare към сигурността на облачните изчисления

Документацията, предоставена от тези компании, описваща техните виждания за сигурността в техните системи, не се различава коренно от горепосочените заплахи.

Таблица 1 изброява основните класове уязвимости, формулирани от компаниите в техните продукти. Раздел. 1 ви позволява да видите липсата на пълно покритие на заплахите в изследваните компании и да формулирате „ядрото на заплахите“, създадено от компаниите в техните облачни системи:

♦ заплаха за данните;

♦ заплахи въз основа на структурата \ възможностите на разпределените изчисления;

♦ заплахи, свързани с неправилен модел на заплаха;

♦ заплахи за виртуализация.

Заключение

Преглед на основните класове уязвимости в облачната платформа ни позволява да заключим, че в момента няма готови решения за пълна защита на облака поради разнообразието от атаки, които използват тези уязвимости.

Трябва да се отбележи, че конструираната таблица на класовете на уязвимост (Таблица 1), която интегрира подходите на водещите

Таблица 1. Класове на уязвимост

Източник Декларирани заплахи

U1 U2 U3 U4 U5 U6 U7 U8 U9 U10 U11

NIST + + + + + + + + + - - -

IBM + + + + + + - + - + + +

Слънце / Oracle + + + + - - + - - + -

VmWare + + + + - - + - - - -

тази индустрия от играчи не се ограничава до заплахите, представени в нея. Например, той не отразява заплахите, свързани с размиване на границите между среди с различни нива на поверителност на данните, както и размиване на границите на отговорност за информационна сигурност между потребителя на услугата и доставчика на облак.

Става очевидно, че за да се внедри сложна облачна система, трябва да се разработи защита за конкретна реализация. Също така важна роля за внедряването на защитени изчисления във виртуални среди играе липсата на стандарти FSTEC и FSB за облачни системи. Има смисъл да се използва „ядрото на заплахите“, подчертано в работата в изследването

задачата за изграждане на единен модел на класове на уязвимост. Тази статия е с прегледен характер, в бъдеще се планира да се анализират подробно класовете заплахи, свързани с виртуализацията, да се разработят подходи за създаване на система за защита, която потенциално възпрепятства изпълнението на тези заплахи

Литература

1. Ръководство за сигурност в облака Препоръки на IBM за внедряване на защита в облак, ibm.com/redbooks, 2 ноември 2009 г.

2.http: //www.vmware.com/technical-resources/security/index.html.

3. NIST облак. Изчислителна референтна архитектура, Национален институт по стандарти и. Технологии, специална публикация. 500-292, септември 2011 г.

4. NIST облак. Пътна карта за изчислителни стандарти, Национален институт по стандарти и. Технологии, специална публикация. 500-291, юли 2011 г.

5.http: //www.oracle.com/technetwork/indexes/documentation/index.html.

Облачните изчисления колективно се отнасят до голям набор от лесно използваеми и лесно достъпни виртуализирани ресурси (като хардуерни системи, услуги и т.н.). Тези ресурси могат да бъдат динамично преразпределени (мащабирани), за да се адаптират към динамично променящото се натоварване, осигурявайки оптимално използване на ресурсите. Този резерв от ресурси обикновено се предоставя на принципа на плащане при движение. В същото време собственикът на облака гарантира качеството на услугата въз основа на определени споразумения с потребителя.

В съответствие с всичко по -горе могат да се разграничат следните основни характеристики на облачните изчисления:

1) облачните изчисления са нова парадигма за предоставяне на изчислителни ресурси;

2) основни инфраструктурни ресурси (хардуерни ресурси, системи за съхранение, системен софтуер) и приложения се предоставят като услуги;

3) тези услуги могат да се предоставят от независим доставчик за външни потребители на базата на плащането, тъй като основните характеристики на облачните изчисления са виртуализация и динамична мащабируемост;

4) облачните услуги могат да се предоставят на крайния потребител чрез уеб браузър или чрез специфичен API (Application Programming Interface).

Общият модел за изчислителни облаци се състои от външна и вътрешна част. Тези два елемента са свързани през мрежа, в повечето случаи през интернет. Чрез външната част потребителят взаимодейства със системата; вътрешната част всъщност е самият облак. Предният край се състои от клиентски компютър или мрежа от корпоративни компютри и приложения, използвани за достъп до облака. Вътрешната част е представена от приложения, компютри, сървъри и хранилища за данни, които създават облак от услуги чрез виртуализация (фиг. 1).

Когато съществуващите физически виртуални машини (виртуални машини) се преместят от центъра за данни (DC) във външни облаци или предоставянето на ИТ услуги извън защитения периметър в частни облаци, периметърът на мрежата става напълно безсмислен и общото ниво на сигурност става доста ниско.

Докато в традиционните центрове за данни достъпът на инженерите до сървърите е строго контролиран на физическо ниво, докато в облачните изчисления достъпът на инженерите се осъществява чрез интернет, което води до появата на съответни заплахи. Съответно, строгият контрол на достъпа за администраторите е от решаващо значение, както и гарантирането на контрол и прозрачност на промените на системно ниво.

Виртуалните машини са динамични. Нестабилността на виртуалните машини затруднява създаването и поддържането на съгласувана система за сигурност. Уязвимости и грешки в конфигурацията могат да се разпространят извън контрол. Освен това е много трудно да се запише състоянието на защита във всеки конкретен момент от време за последващ одит.

Сървърите за облачни изчисления използват същата операционна система и същите уеб приложения като локалните виртуални и физически сървъри. Съответно за облачните системи заплахата от отдалечено хакване или заразяване със злонамерен софтуер е също толкова голяма.

Друга заплаха е заплахата за целостта на данните: компромис и кражба на данни. Трябва да се следи целостта на операционната система и файловете на приложенията, както и вътрешната дейност.

Използването на облачни услуги с множество наематели затруднява спазването на изискванията на стандартите и законите, включително изискванията за използването на криптографски инструменти, за защита на чувствителна информация, като например информация за собственика на кредитна карта и информация, която идентифицира човек. Това от своя страна поставя обезсърчаващата задача да осигури надеждна защита и сигурен достъп до чувствителни данни.

Въз основа на анализа на възможните заплахи в облачните изчисления се предлага възможна хардуерна и софтуерна комплексна защита за изчислителни облаци, която включва 5 технологии: защитна стена, откриване и предотвратяване на проникване, контрол на целостта, анализ на регистрационни файлове и защита срещу злонамерен софтуер.

Доставчиците на облачни изчисления използват виртуализация, за да предоставят на своите клиенти достъп до евтини компютърни ресурси. В същото време клиентските виртуални машини споделят едни и същи хардуерни ресурси, което е необходимо за постигане на най -голяма икономическа ефективност. Корпоративните клиенти, които се интересуват от облачните изчисления за разширяване на вътрешната си ИТ инфраструктура, трябва да обмислят заплахите, които представлява такъв ход. В допълнение към традиционните механизми за мрежова защита на центровете за обработка на данни, използващи такива подходи за сигурност като: ръбова защитна стена, демилитаризирани зони, сегментиране на мрежата, мониторинг на състоянието на мрежата, системи за откриване и предотвратяване на проникване, софтуерни механизми за защита на данни трябва да се използват и на сървъри за виртуализация или на самите сървъри.ВМ, тъй като с прехвърлянето на виртуални машини към публични облачни услуги, периметърът на корпоративната мрежа постепенно губи значението си и най -малко защитените възли започват да влияят значително върху общото ниво на сигурност. Невъзможността за физическо разделяне и използване на защитен хардуер за отблъскване на атаки между виртуални машини води до необходимостта от поставяне на защитния механизъм на сървъра за виртуализация или на самите виртуални машини. Прилагането на цялостен метод за защита на самата виртуална машина, включително софтуерно внедряване на защитна стена, откриване и предотвратяване на проникване, контрол на целостта, анализ на регистрационни файлове и защита срещу злонамерен код, е най -ефективният начин за защита на целостта, спазване на нормативните изисквания и спазване на политики за сигурност при преместване на виртуални ресурси от интранет към облака.

Литература:

1. Радченко Г.И. Разпределени изчислителни системи // Урок. - 2012.- С. 146-149.

2. Кондрашин М. Сигурност на облачните изчисления // Новини за съхранение. - 2010. - No1.

Курсова работа по дисциплина

Софтуер и хардуер за защита на информацията

"Информационна сигурност в облачните изчисления: уязвимости, методи и средства за защита, инструменти за одит и разследване на инциденти."

Въведение

1. История и ключови фактори за развитие

2. Определение на облачните изчисления

3. Референтна архитектура

4. Споразумение за ниво на обслужване

5. Методи и средства за защита в облачните изчисления

6. Сигурност на облачните модели

7. Одит на сигурността

8. Разследване на инциденти и криминалистика в облачните изчисления

9. Модел на заплаха

10. Международни и вътрешни стандарти

11. Териториална идентичност на данните

12. Държавни стандарти

13. Средства за облачна сигурност

14. Практическа част

Изход

Литература

Въведение

Нарастващата скорост на облачните изчисления се обяснява с факта, че за малко, като цяло пари, клиентът получава достъп до най -надеждната инфраструктура с необходимата производителност, без да е необходимо да купува, инсталира и поддържа скъпи компютри. Системата достига 99,9% , което също спестява изчислителни ресурси. ... И което е по -важно - почти неограничени възможности за мащабиране. Чрез закупуване на редовен хостинг и опит за прескачане на главата (с рязко покачване на натоварването) съществува риск да получите услуга, която е паднала за няколко часа. В облака са налични допълнителни ресурси при поискване.

Основният проблем на облачните изчисления е негарантираното ниво на сигурност на обработваната информация, степента на защита на ресурсите и често напълно липсващата регулаторна рамка.

Целта на изследването ще бъде да предостави преглед на съществуващия пазар на облачни изчисления и средствата за гарантиране на сигурността в тях.

информация за сигурността в облачните изчисления

1. История и ключови фактори за развитие

Идеята за това, което днес наричаме облачни изчисления, е изразена за първи път от J. C. R. Licklider през 1970 г. През тези години той е отговорен за създаването на ARPANET (мрежа от агенции за напреднали изследователски проекти). Идеята му беше, че всеки човек на земята ще бъде свързан към мрежа, от която ще получава не само данни, но и програми. Друг учен Джон Маккарти предложи идеята, че изчислителната мощ ще бъде предоставена на потребителите като услуга (услуга). Поради това развитието на облачните технологии беше спряно до 90 -те години, след което редица фактори допринесоха за неговото развитие.

Разширяването на интернет честотната лента през 90 -те години не позволи значителен скок в развитието на облачните технологии, тъй като почти никоя компания и технологии от онова време не бяха готови за това. Самият факт на ускорението на Интернет обаче даде тласък на ранното развитие на облачните изчисления.

2. Едно от най -значимите разработки в тази област беше появата на Salesforce.com през 1999 г. Тази компания стана първата компания, която предостави достъп до приложението си чрез сайта. Всъщност тази компания стана първата компания, предоставила своя софтуер на базата на софтуер като услуга (SaaS).

Следващата стъпка беше разработването на облачна уеб услуга от Amazon през 2002 г. Тази услуга даде възможност за съхраняване на информация и извършване на изчисления.

През 2006 г. Amazon пусна услуга, наречена Elastic Compute cloud (EC2) като уеб услуга, която позволява на потребителите да стартират свои собствени приложения. Amazon EC2 и Amazon S3 бяха първите налични услуги за облачни изчисления.

Друг крайъгълен камък в развитието на облачните изчисления дойде със създаването от Google на платформата Google Apps за уеб приложения в бизнес сектора.

Технологиите за виртуализация са изиграли значителна роля в развитието на облачните технологии, по -специално софтуер, който ви позволява да създадете виртуална инфраструктура.

Развитието на хардуера допринесе не толкова за бързия растеж на облачните технологии, а за достъпността на тази технология за малките предприятия и частни лица. По отношение на технологичния прогрес, създаването на многоядрени процесори и увеличаването на капацитета на устройствата за съхранение на информация изиграха значителна роля в това.

2. Определение на облачните изчисления

Както е определено от Националния институт по стандарти и технологии на САЩ:

Облачни изчисления (Облачни изчисления) (АнглийскиОблак -облак; изчисления- изчисляване) е модел за предоставяне на повсеместен и удобен достъп до мрежата, ако е необходимо, до споделен пул от конфигурируеми изчислителни ресурси (например мрежи, сървъри, системи за съхранение, приложения и услуги), които могат да бъдат бързо предоставени и освободени с минимални усилия за управление и нужда от взаимодействие с доставчик на услуги (доставчик на услуги).

Моделът в облака поддържа висока наличност на услуги и се описва с пет основни характеристики, три модела услуги / услуги и четири модела на внедряване.

Програмите се стартират и извеждат резултатите от работата в стандартен прозорец на уеб браузър на локален компютър, докато всички приложения и техните данни, необходими за работа, се намират на отдалечен сървър в Интернет. Компютърните компютри в облак се наричат ​​„облачни изчисления“. В този случай натоварването между компютрите, включени в "изчислителния облак", се разпределя автоматично. Най -простият пример за облачни изчисления са p2p мрежите.

За внедряване на облачни изчисления се използват продукти на средния софтуер, създадени със специални технологии. Те служат като междинна връзка между оборудването и потребителя и осигуряват мониторинг на състоянието на оборудването и програмите, равномерно разпределение на натоварването и своевременно предоставяне на ресурси от общ пул. Една от тези технологии е виртуализацията в изчисленията.

Виртуализация в компютрите- процесът на представяне на набор от изчислителни ресурси или тяхната логическа комбинация, което дава някакви предимства пред първоначалната конфигурация. Това е нов виртуален изглед на ресурсите на съставните части, който не е ограничен от изпълнението, физическата конфигурация или географското местоположение. Обикновено виртуализираните ресурси включват изчислителна мощност и съхранение на данни. Научно виртуализацията е изолация на изчислителните процеси и ресурси един от друг.

Пример за виртуализация са симетрични многопроцесорни компютърни архитектури, които използват повече от един процесор. Операционните системи обикновено са конфигурирани така, че множество процесори се появяват като един процесор. Ето защо софтуерните приложения могат да бъдат написани за една логическа ( виртуален) изчислителен модул, който е много по -лесен от работата с голям брой различни конфигурации на процесора.

За особено големи и ресурсоемки изчисления се използват изчисления на мрежата.

Грид изчисления (решетка -решетка, мрежа) е форма на разпределени изчисления, при която „виртуален суперкомпютър“ е представен като клъстери от мрежови, слабо свързани, хетерогенни компютри, работещи заедно за изпълнение на огромен брой задачи (операции, работни места).

Тази технология се използва за решаване на научни и математически проблеми, които изискват значителни изчислителни ресурси. Grid изчисленията се използват и в търговската инфраструктура за решаване на отнемащи време задачи като икономическо прогнозиране, сеизмичен анализ и разработване и проучване на свойствата на нови лекарства.

От гледна точка на мрежова организация, мрежата е последователна, отворена и стандартизирана среда, която осигурява гъвкаво, сигурно, координирано разделяне на изчислителните и съхраняващите ресурси, които са част от тази среда в рамките на една виртуална организация.

ПаравиртуализацияТова е техника за виртуализация, която предоставя на виртуалните машини интерфейс за програмиране, подобен, но не идентичен на основния хардуер. Целта на този модифициран интерфейс е да намали времето, прекарано от гостуващата операционна система за извършване на операции, които са много по-трудни за изпълнение във виртуална среда, отколкото в невиртуализирана.

Има специални куки, които позволяват на госта и хоста да искат и да признаят тези сложни задачи, които могат да се изпълняват във виртуална среда, но с много по -бавни темпове.

Хипервизор (или Монитор на виртуална машина) - в компютрите, програма или хардуерна схема, която осигурява или позволява едновременно, паралелно изпълнение на няколко или дори много операционни системи на един и същ хост компютър. Хипервизорът също така осигурява изолация на ОС един от друг, защита и сигурност, споделяне на ресурси между различни работещи ОС и управление на ресурси.

Хипервизорът може също (но не е задължително) да осигури на операционната система, работеща на същия хост компютър, средства за комуникация и взаимодействие помежду си (например чрез обмен на файлове или мрежови връзки), сякаш тези ОС работят на различни физически компютри.

Самият хипервизор е по някакъв начин минимална операционна система (микроядро или наноядро). Той предоставя на операционните системи, работещи под негов контрол, услуга за виртуална машина, виртуализираща или емулираща реалния (физически) хардуер на определена машина, и управлява тези виртуални машини, разпределяйки и освобождавайки ресурси за тях. Хипервизорът позволява независимо "включване", рестартиране, "изключване" на която и да е от виртуалните машини с определена ОС. Въпреки това, операционна система, работеща във виртуална машина под контрола на хипервизор, може, но не е задължително, да "знае", че работи във виртуална машина, а не на реален хардуер.

Модели на облачни услуги

Опциите за осигуряване на изчислителна мощност са много различни. Всичко, свързано с облачните изчисления, обикновено се нарича aaS - означава просто „като услуга“, тоест „като услуга“ или „под формата на услуга“.

Софтуер като услуга (SaaS) -доставчикът предоставя на клиента готово за употреба приложение. Приложенията са достъпни от различни клиентски устройства или чрез тънки клиентски интерфейси, като уеб браузър (например уеб поща) или интерфейси на програми. В същото време потребителят не контролира основната облачна инфраструктура, включително мрежи, сървъри, операционни системи, системи за съхранение и дори индивидуални настройки на приложението, с изключение на някои настройки за конфигурация на потребителско приложение.

В модела SaaS клиентите плащат не за притежаване на софтуера като такъв, а за наемането му (тоест да го използват чрез уеб интерфейс). По този начин, за разлика от класическата схема за лицензиране на софтуер, клиентът понася относително малки повтарящи се разходи и не е необходимо да инвестира значителни средства за закупуване на софтуер и неговата поддръжка. Схемата за периодични плащания предполага, че ако нуждата от софтуер временно отсъства, клиентът може да спре използването му и да замрази плащанията към разработчика.

От гледна точка на разработчика, моделът SaaS ви позволява ефективно да се борите с нелицензираното използване на софтуер (пиратство), тъй като самият софтуер не достига до крайните клиенти. В допълнение, концепцията SaaS често може да намали разходите за внедряване и внедряване на информационни системи.

Ориз. 1 Типично оформление на SaaS

Платформа като услуга (PaaS) -доставчикът предлага на клиента софтуерна платформа и инструменти за проектиране, разработване, тестване и внедряване на потребителски приложения. В същото време потребителят не контролира основната облачна инфраструктура, включително мрежи, сървъри, операционни системи и системи за съхранение, но има контрол върху внедрените приложения и евентуално някои конфигурационни параметри на хостинг средата.

Ориз. 2 Типично оформление на PaaS

Инфраструктурата като услуга (IaaS). -доставчикът предлага на клиента изчислителни ресурси под наем: сървъри, системи за съхранение, мрежово оборудване, операционни системи и системен софтуер, системи за виртуализация, системи за управление на ресурси. В същото време потребителят не контролира основната облачна инфраструктура, но има контрол върху операционни системи, системи за съхранение, разгърнати приложения и евентуално ограничен контрол върху избора на мрежови компоненти (например хост с защитни стени).

Ориз. 3 Типично оформление на IaaS

Допълнителноразграничават услуги като:

Комуникация като услуга (Com -aaS) -разбира се, че комуникационните услуги се предоставят като услуги; обикновено това е IP телефония, поща и незабавни комуникации (чатове, незабавни съобщения).

Съхранение на данни в облак- на потребителя е предоставено определено пространство за съхранение на информация. Тъй като информацията се съхранява разпределена и дублирана, такива хранилища осигуряват много по -голяма степен на безопасност на данните от локалните сървъри.

Работно място като услуга (WaaS) -потребителят, разполагащ с недостатъчно мощен компютър, може да закупи изчислителни ресурси от доставчика и да използва компютъра си като терминал за достъп до услугата.

Антивирусен облак- инфраструктурата, която се използва за обработка на информация, идваща от потребителите с цел своевременно разпознаване на нови, неизвестни досега заплахи. Облачният антивирус не изисква никакви ненужни действия от потребителя - той просто изпраща заявка за подозрителна програма или връзка. Когато опасността бъде потвърдена, всички необходими действия се извършват автоматично.

Модели на внедряване

Сред моделите за внедряване има 4 основни типа инфраструктура.

Частен облак -инфраструктура, предназначена за използване от една организация, включително няколко потребители (например подразделения на една организация), вероятно също от клиенти и изпълнители на тази организация. Частен облак може да бъде притежаван, управляван и експлоатиран от самата организация или от трета страна (или някаква комбинация от тях) и физически може да съществува както вътре, така и извън юрисдикцията на собственика.

Ориз. 4 Частен облак.

Обществен облак -инфраструктура, предназначена за безплатно ползване от широката общественост. Публичният облак може да бъде притежаван, управляван и управляван от търговски, академични и държавни организации (или всяка комбинация от тях). Публичният облак физически съществува в юрисдикцията на собственика - доставчика на услуги.

Ориз. 5 Обществен облак.

Хибриден облак -това е комбинация от две или повече различни облачни инфраструктури (частни, публични или публични), които остават уникални обекти, но са свързани помежду си чрез стандартизирани или частни технологии за прехвърляне на данни и приложения (например краткосрочно използване на публични облачни ресурси за балансиране натоварването между облаците).

Ориз. 6 Хибриден облак.

Публичен облак (облак на общността) -вид инфраструктура, предназначена за използване от конкретна общност от потребители от организации с общи цели (напр. мисия, изисквания за сигурност, политики и спазване на различни изисквания). Публичен облак може да бъде съсобственост, да се управлява и управлява от една или повече организации на общността или трета страна (или всяка комбинация от тях) и той физически може да съществува както в рамките на юрисдикцията на собственика, така и извън нея.

Ориз. 7 Описание на свойствата на облака

Основни свойства

NIST в своя документ „Определението на NIST за облачни изчисления“ дефинира следните характеристики на облаците:

Самообслужване при поискване.Потребителят има възможност за достъп до предоставените изчислителни ресурси едностранно при необходимост, автоматично, без да е необходимо да взаимодейства със служителите на всеки доставчик на услуги.

Широк достъп до мрежата.Предоставените изчислителни ресурси са достъпни в мрежата чрез стандартни механизми за различни платформи, тънки и дебели клиенти (мобилни телефони, таблети, лаптопи, работни станции и др.).

Обединяване на ресурси (Resorce pooling).Изчислителните ресурси на доставчика са обединени, за да обслужват много потребители в модел с множество наематели. Пуловете включват разнообразни физически и виртуални ресурси, които могат да бъдат динамично присвоени и преназначени, за да отговорят на нуждите на клиентите. Потребителят не трябва да знае точното местоположение на ресурсите, но е възможно да посочи тяхното местоположение на по -високо ниво на абстракция (например държава, регион или център за данни). Примерите за тези видове ресурси включват системи за съхранение, изчислителна мощност, памет, мрежова честотна лента.

Бърза еластичност.Ресурсите могат да бъдат разпределени еластично и освободени, в някои случаи автоматично, за бързо увеличаване в съответствие с търсенето. За потребителя възможностите за предоставяне на ресурси се разглеждат като неограничени, тоест те могат да бъдат разпределени във всяко количество и по всяко време.

Премерено обслужване.Облачните системи автоматично управляват и оптимизират ресурси, като използват инструменти за измерване, внедрени на ниво абстракция за различни видове услуги (например управление на външна памет, обработка, честотна лента или активни потребителски сесии). Използваните ресурси могат да бъдат наблюдавани и контролирани, което осигурява прозрачност като за доставчика и за потребителя, използващ услугата.

Ориз. 8 Структурна схема на облачен сървър

Плюсове и минуси на облачните изчисления

Предимства

· Намаляват се изискванията за изчислителната мощ на компютъра (задължително условие е само наличието на достъп до Интернет);

· Отказоустойчивост;

· сигурност;

· Висока скорост на обработка на данни;

· Намалени разходи за хардуер и софтуер, поддръжка и електроенергия;

· Спестяване на дисково пространство (данните и програмите се съхраняват в Интернет).

· Миграция на живо - прехвърляне на виртуална машина от един физически сървър на друг без прекъсване на виртуалната машина и спиране на услугите.

· В края на 2010 г., поради DDoS атаки срещу компании, които отказаха да предоставят ресурси на WikiLeaks, беше разкрито друго предимство на облачните изчисления. Всички компании, които се противопоставиха на WikiLeaks, бяха атакувани, но само Amazon се оказа нечувствителен към тези влияния, тъй като използва средства за изчислителни облаци. („Анонимен: сериозна заплаха или просто досада“, Мрежова сигурност, N1, 2011).

недостатъци

· Зависимост на безопасността на потребителските данни от компаниите, предоставящи облачни изчислителни услуги;

· Постоянна връзка с мрежата - за да получите достъп до услугите на "облака" се нуждаете от постоянна връзка с интернет. В наше време обаче това не е толкова голям недостатък, особено с появата на 3G и 4G клетъчни технологии.

· Софтуер и неговата модификация - има ограничения за софтуера, който може да бъде разгърнат в „облаците“ и предоставен на потребителя. Потребителят на софтуера има ограничения в използвания софтуер и понякога няма възможност да го персонализира за собствените си цели.

· Поверителност - поверителността на данните, съхранявани в публични „облаци“, в момента е предмет на много противоречия, но в повечето случаи експертите са съгласни, че не се препоръчва да се съхраняват най -ценните за компанията документи в публичния „облак“, тъй като в момента няма технология, която да гарантира 100% поверителност на съхраняваните данни, поради което използването на криптиране в облака е задължително.

· Надеждност - що се отнася до надеждността на съхраняваната информация, можем да кажем с увереност, че ако сте загубили информация, съхранявана в "облака", значи сте я загубили завинаги.

· Сигурност - самият „облак“ е доста надеждна система, но когато проникне в него, нападателят получава достъп до огромно хранилище за данни. И други, което позволява използването на вируси.

· Висока цена на оборудването - за да изгради свой собствен облак, компанията трябва да разпредели значителни материални ресурси, което не е от полза за новосъздадените и малките компании.

3. Референтна архитектура

Референтната архитектура на NIST Cloud Computing включва пет основни действащи лица - актьорите. Всеки актьор играе роля и изпълнява действия и функции. Референтната архитектура е представена като последователни диаграми с нарастващи нива на детайлност.

Ориз. 9 Концептуална диаграма на референтна архитектура

Облачен потребител- лице или организация, поддържаща бизнес отношения и използваща услугите на доставчиците на облак.

Потребителите на облак са разделени на 3 групи:

· SaaS - използва приложения за автоматизиране на бизнес процесите.

PaaS - Разработва, тества, внедрява и управлява приложения, внедрени в облачната среда.

· IaaS - създава, управлява ИТ инфраструктурни услуги.

Облачен доставчик- лицето, организацията или образуванието, отговорно за наличността на облачната услуга за потребителите в облак.

SaaS - Инсталира, управлява, поддържа и предоставя софтуер, внедрен в облачна инфраструктура.

PaaS - Предоставя и управлява облачната инфраструктура и междинния софтуер. Предоставя инструменти за разработка и администриране.

· IaaS - предоставя и поддържа сървъри, бази данни, изчислителни ресурси. Осигурява облачна структура на потребителя.

Дейностите на доставчиците на облак са разделени на 5 основни типични действия:

Разгръщане на услугата:

o Частен облак - обслужван от една организация. Инфраструктурата се управлява както от самата организация, така и от трета страна и може да бъде внедрена както от Доставчика (извън помещенията), така и от организацията (на място).

o Споделен облак - инфраструктурата се споделя от няколко организации със сходни изисквания (сигурност, съответствие с RD).

o Обществен облак - инфраструктурата се използва от голям брой организации с различни изисквания. Само извън помещенията.

o Хибриден облак - инфраструктурата съчетава различни инфраструктури, базирани на подобни технологии.

Управление на услуги

o Ниво на обслужване - определя основните услуги, предоставяни от Доставчика.

§ SaaS е приложение, използвано от Потребителя чрез достъп до облака от специални програми.

§ PaaS - контейнери за потребителски приложения, инструменти за разработка и администриране.

§ IaaS - изчислителна мощност, бази данни, основни ресурси, върху които потребителят разполага своята инфраструктура.

o Ниво на абстракция и контрол на ресурсите

§ Управление на хипервизора и виртуални компоненти, необходими за внедряване на инфраструктурата.

o Ниво на физически ресурси

§ Компютърно оборудване

§ Инженерна инфраструктура

o Наличност

o Конфиденциалност

o Идентификация

o Мониторинг на сигурността и обработка на инциденти

o Политики за сигурност

поверителност

o Защита на обработването, съхранението и предаването на лични данни.

Облачен одитор- Сътрудник, който може независимо да оцени облачните услуги, поддръжката на информационните системи, производителността и сигурността на облачната реализация.

Той може да даде своя собствена оценка на сигурността, поверителността, производителността и други неща в съответствие с одобрените документи.

Ориз. 10 Дейности на доставчика

Облачен брокер- субектът, който управлява използването, производителността и доставката на облачни услуги и установява връзката между доставчици и потребители.

С развитието на облачните изчисления интеграцията на облачните услуги може да е твърде трудна за потребителя.

o Посредничество в услугата - разширяване на посочената услуга и предоставяне на нови възможности

o Агрегиране - комбиниране на различни услуги за предоставяне на Потребителя

Оператор на облачна комуникация- посредник, предоставящ услуги за връзка и транспорт (комуникационни услуги) за доставка на облачни услуги от доставчици до потребители.

Осигурява достъп чрез комуникационни устройства

Осигурява ниво на връзка, съгласно SLA.

Сред представените петима актьори облачен брокер не е задължителен, тъй като потребителите на облак могат да получават услуги директно от доставчика на облак.

Въвеждането на актьори се дължи на необходимостта да се изработят взаимоотношенията между субектите.

4. Споразумение за ниво на обслужване

Споразумение за ниво на услуга - документ, описващ нивото на предоставяне на услугата, очаквано от клиента от доставчика, въз основа на показателите, приложими към дадената услуга, и установяващо отговорността на доставчика, ако договорените показатели не са постигнати.

Ето някои показатели, под една или друга форма, открити в операторските документи:

ASR (Коефициент на отговор на изземване) -параметър, който определя качеството на телефонната връзка в дадена посока. ASR се изчислява като процент от броя на телефонните връзки, установени в резултат на повиквания към общия брой обаждания, направени в дадена посока.

PDD (Забавяне след набиране) -параметър, определящ периода от време (в секунди), изминал от момента на повикването до момента на установяване на телефонната връзка.

Коефициент на наличност на услуги- съотношението на времето на прекъсване на предоставянето на услугите към общото време, през което услугата трябва да бъде предоставена.

Коефициент на загуба на пакети- съотношението на правилно получените пакети данни към общия брой пакети, предавани по мрежата за определен период от време.

Закъснения във времето при предаването на информационни пакети- времевият интервал, необходим за предаване на пакет информация между две мрежови устройства.

Надеждност на предаването на информация- съотношението на броя на погрешно предадените пакети данни към общия брой на предадените пакети данни.

Периоди на работа, време за уведомяване на абонатите и време за възстановяване на услугите.

С други думи, наличността на услугата от 99,99% показва, че операторът гарантира не повече от 4,3 минути прекъсване на комуникацията на месец, 99,9% - че услугата може да не се предоставя за 43,2 минути и 99% - че почивката може да продължи повече повече от 7 часа. В някои практики има диференциация на наличността на мрежата и се приема по -ниска стойност на параметъра - в извънработно време. Предлагат се и различни стойности на показатели за различни видове услуги (класове трафик). Например, най -важното за гласа е латентността - тя трябва да бъде минимална. А скоростта за него се нуждае от ниска, плюс някои от пакетите могат да бъдат загубени без загуба на качество (до около 1%, в зависимост от кодека). При предаването на данни скоростта е на първо място и загубата на пакети трябва да се стреми към нула.

5. Методи и средства за защита в облачните изчисления

Трябва да се гарантира поверителност по цялата верига, включително доставчикът на облак, потребителят и комуникациите, които ги свързват.

Задачата на Доставчика е да гарантира както физическата, така и софтуерната цялост на данните от атаките на трети страни. Потребителят трябва да въведе подходящи политики и процедури „на тяхна територия“, за да изключи прехвърлянето на права за достъп до информация на трети страни.

Задачите за осигуряване на целостта на информацията в случай на използване на отделни „облачни“ приложения могат да бъдат решени - благодарение на съвременните архитектури на бази данни, системи за архивиране, алгоритми за проверка на целостта и други индустриални решения. Но това не е всичко. Нови предизвикателства могат да възникнат, когато става въпрос за интегриране на множество облачни приложения от различни доставчици.

В близко бъдеще за компаниите, които търсят сигурна виртуална среда, единственият вариант е да създадат частна облачна система. Факт е, че частните облаци, за разлика от публичните или хибридните системи, са най -сходни с виртуализираните инфраструктури, които ИТ отделите на големите корпорации вече са се научили да прилагат и над които могат да поддържат пълен контрол. Пропуските в сигурността на информацията в публичните облачни системи представляват значително предизвикателство. Повечето инциденти с взлом се случват в обществени облаци.

6. Сигурност на облачните модели

Нивото на риск в трите облачни модела е много различно и начините за решаване на проблеми със сигурността също се различават в зависимост от нивото на взаимодействие. Изискванията за сигурност остават същите, но нивото на контрол на сигурността се променя в различните модели, SaaS, PaaS или IaaS. От логическа гледна точка нищо не се променя, но възможностите за физическо изпълнение са коренно различни.

Ориз. 11. Най -спешните заплахи за сигурността на информацията

в модела SaaS приложението работи в облачната инфраструктура и е достъпно чрез уеб браузър. Клиентът няма контрол върху мрежата, сървърите, операционните системи, хранилището или дори някои възможности на приложението. Поради тази причина в модела SaaS основната отговорност за сигурността се полага почти изцяло на доставчиците.

Проблем номер 1 е управление на пароли. В модела SaaS приложенията са в облака, така че основният риск е използването на множество акаунти за достъп до приложения. Организациите могат да решат този проблем чрез обединяване на акаунти за облачни и локални системи. С еднократно влизане потребителите имат достъп до работни станции и облачни услуги, използвайки един акаунт. Този подход намалява вероятността от „заседнали“ акаунти, предмет на неразрешено използване след прекратяване на служителите.

Според обяснението на CSA, PaaS приема, че клиентите изграждат приложения, използвайки поддържани от доставчиците езици и инструменти за програмиране и след това ги разгръщат в облачната инфраструктура. Както в модела SaaS, клиентът не може да управлява или контролира инфраструктурата - мрежи, сървъри, операционни системи или системи за съхранение - но има контрол върху внедряването на приложения.

В модел на PaaS потребителите трябва да обърнат внимание на сигурността на приложението, както и на въпроси, свързани с управлението на API, като валидиране, упълномощаване и проверка.

Проблем номер 1 е криптиране на данни. Моделът PaaS по своята същност е сигурен, но рискът е неадекватна производителност на системата. Това е така, защото криптирането се препоръчва при комуникация с доставчици на PaaS и това изисква допълнителна мощност за обработка. Независимо от това при всяко решение предаването на поверителни потребителски данни трябва да се извършва по криптиран канал.

Докато клиентите тук нямат контрол върху основната облачна инфраструктура, те имат контрол върху операционните системи, съхранението и внедряването на приложения и евентуално ограничен контрол върху избора на мрежови компоненти.

Този модел има няколко вградени възможности за сигурност, без да защитава самата инфраструктура. Това означава, че потребителите трябва да управляват и защитават операционни системи, приложения и съдържание, обикновено чрез API.

Ако това е преведено на езика на методите за защита, тогава доставчикът трябва да предостави:

· Надежден контрол на достъпа до самата инфраструктура;

· Устойчивост на инфраструктурата.

В същото време потребителят в облака поема много повече функции за защита:

· Защитни стени в рамките на инфраструктурата;

· Защита от проникване в мрежата;

· Защита на операционни системи и бази данни (контрол на достъпа, защита от уязвимости, контрол на настройките за сигурност);

· Защита на крайните приложения (антивирусна защита, контрол на достъпа).

По този начин повечето от мерките за защита падат върху раменете на потребителя. Доставчикът може да предостави типични препоръки за защита или готови решения, което ще опрости задачата за крайните потребители.

Таблица 1. Разграничаване на отговорността за сигурност между клиента и доставчика на услуги. (P - доставчик, K - клиент)

	Enterprise сървър
Приложение
Данни
Среда по време на работа
Среден софтуер
Операционна система
Виртуализация
Сървър
Складове за данни
мрежов хардуер

7. Одит на сигурността

Задачите на Cloud Auditor са същите като тези на одитора на конвенционалните системи. Одитът за сигурност в облака се подразделя на одит на доставчик и одит на потребител. Одитът на Потребителя се извършва по искане на Потребителя, докато одитът на Доставчика е едно от най -важните условия за правене на бизнес.

Състои се от:

· Започване на одиторската процедура;

· Събиране на одитна информация;

· Анализ на одиторските данни;

· Изготвяне на одитен доклад.

На етапа на започване на одиторската процедура трябва да се решат въпросите за правомощията на одитора, времето на одита. Трябва да се предвиди и задължителната помощ на служителите към одитора.

По принцип одиторът провежда одит, за да определи надеждността

· Системи за виртуализация, хипервизор;

· Сървъри;

· Складове за данни;

· Мрежово оборудване.

Ако Доставчикът използва модела IaaS на проверения сървър, тази проверка ще бъде достатъчна за идентифициране на уязвимости.

Когато използвате модела PaaS, трябва да се направят допълнителни проверки

· операционна система,

Среден софтуер,

· Среда по време на работа.

При използване на модела SaaS се проверяват и уязвимости

Системи за съхранение и обработка на данни,

· Приложения.

Одитите за сигурност се извършват, като се използват същите методи и инструменти като одита на конвенционалните сървъри. Но за разлика от конвенционалния сървър в облачните технологии, хипервизорът се проверява допълнително за стабилност. В облака хипервизорът е една от основните технологии и затова трябва да се обърне особено внимание на одита.

8. Разследване на инциденти и криминалистика в облачните изчисления

Мерките за защита на информацията могат да бъдат разделени на превантивни (например криптиране и други механизми за контрол на достъпа) и реактивни (разследвания). Проактивният аспект на облачната сигурност е област на активни изследвания, докато реактивният аспект на облачната сигурност е получил много по -малко внимание.

Разследването на инциденти (включително разследване на престъпления в информационната сфера) е добре известен раздел на сигурността на информацията. Целите на такова разследване обикновено са:

Доказателство, че престъплението / инцидентът е настъпил

Възстановяване на събитията около инцидента

Идентифициране на нарушителите

Доказателство за участие и отговорност на нарушителите

Доказателство за нечестни намерения от страна на извършителите.

Появи се нова дисциплина - компютърна и техническа експертиза (или криминалистика), с оглед на необходимостта от съдебномедицински анализ на цифрови системи. Целите на компютърната криминалистика обикновено са следните:

Възстановяване на данни, които може да са били изтрити

Възстановяване на събития, настъпили вътре и извън цифровите системи, свързани с инцидента

Идентифициране на потребители на цифрови системи

Откриване на наличието на вируси и друг злонамерен софтуер

Откриване на наличието на незаконни материали и програми

Разбиване на пароли, ключове за шифроване и кодове за достъп

В идеалния случай компютърната съдебна медицина е един вид машина на времето за следовател, която може да пътува всеки момент в миналото на цифрово устройство и да предоставя на следователя информация за:

хора, които са използвали устройството в определен момент

действия на потребителя (например отваряне на документи, достъп до уебсайт, отпечатване на данни в текстов процесор и др.)

данни, съхранявани, създавани и обработвани от устройството в определен момент.

Облачните услуги, заместващи самостоятелни цифрови устройства, трябва да осигурят подобно ниво на съдебна готовност. Това обаче изисква преодоляване на предизвикателствата, свързани с обединяването на ресурси, многонаемността и устойчивостта на инфраструктурата за облачни изчисления. Основният инструмент при разследването на инциденти е одиторската следа.

Одиторските пътеки - предназначени да наблюдават историята на потребителските влизания, административните задачи и промените в данните - са съществена част от системата за сигурност. В облака самата одитна следа е не само инструмент за разследвания, но и инструмент за изчисляване на разходите за използване на сървъри. Въпреки че одиторската следа не преодолява дупките в сигурността, тя осигурява критично око за случващото се и прави предложения за коригиране на ситуацията.

Създаването на архиви и архивиране е важно, но не може да замени официална одитна следа, която записва кой какво е направил, кога и какво. Одиторската следа е един от основните инструменти на одитора по сигурността.

В споразумението за услуги обикновено се споменава кои журнали за одит ще се съхраняват и предоставят на потребителя.

9. Модел на заплаха

През 2010 г. CSA проведе анализ на основните заплахи за сигурността в облачните технологии. Резултатът от тяхната работа беше документът „Топ заплахи на Cloud Computing v 1.0“, който в момента описва модела на заплахата и модела на нарушителя по най -пълния начин. В момента се разработва по -пълна, втора версия на този документ.

Настоящият документ описва нападателите за три модела услуги SaaS, PaaS и IaaS. Идентифицирани са седем основни вектора на атаката. В по-голямата си част всички разглеждани видове атаки са атаки, присъщи на конвенционалните сървъри, които не са в облак. Облачната инфраструктура им налага определени функции. Например атаките срещу уязвимости в софтуерната част на сървърите се допълват от атаки срещу хипервизора, който е и тяхната софтуерна част.

Заплаха за сигурността №1

Неподходящо и нечестно използване на облачни технологии.

Описание:

За да получи ресурси от базиран на облак доставчик на IaaS, потребителят трябва само да има кредитна карта. Лесното регистриране и разпределение на ресурси позволява на спамери, автори на вируси и др. използват облачната услуга за свои собствени престъпни цели. По -рано този вид атака се наблюдаваше само в PaaS, но последните проучвания показват възможността за използване на IaaS за DDOS атаки, поставяне на зловреден код, създаване на ботнет мрежи и др.

Примери за услуги бяха използвани за създаване на ботнет мрежа, базирана на троянския "Zeus", съхраняване на кода на троянския кон на "InfoStealer" и публикуване на информация за различни уязвимости на MS Office и AdobePDF.

В допълнение, мрежите за ботнет използват IaaS за управление на своите връстници и изпращане на спам. Поради това някои услуги на IaaS бяха включени в черния списък и техните потребители бяха напълно игнорирани от пощенските сървъри.

Подобрения в процедурите за регистрация на потребители

Подобряване на процедурите за проверка на кредитни карти и наблюдение на използването на платежни средства

Цялостно проучване на мрежовата дейност на потребителите на услуги

· Проследяване на основните черни листове за появата на мрежа от доставчик на облак там.

Засегнати модели услуги:

Заплаха за сигурността # 2

Несигурни интерфейси за програмиране (API)

Описание:

Доставчиците на облачна инфраструктура предоставят на потребителите набор от API за управление на ресурси, виртуални машини или услуги. Сигурността на цялата система зависи от сигурността на тези интерфейси.

Анонимният достъп до интерфейса и предаването на идентификационни данни в ясен текст са основните отличителни белези на незащитените API. Ограниченото наблюдение на използването на API, липсата на системи за регистриране, както и неизвестни връзки между различни услуги само увеличават риска от хакерство.

Анализирайте модела на сигурност на доставчика на облак

Уверете се, че се използват силни алгоритми за криптиране

Уверете се, че се използват силни методи за удостоверяване и оторизация

· Разберете цялата верига от зависимости между различните услуги.

Засегнати модели услуги:

Заплаха за сигурността # 3

Вътрешни нарушители

Описание:

Проблемът с незаконния достъп до информация отвътре е изключително опасен. Често от страна на доставчика не се прилага система за мониторинг на дейността на служителите, което означава, че нападателят може да получи достъп до информацията на клиента, използвайки официалната му позиция. Тъй като доставчикът не разкрива своята политика за набиране на персонал, заплахата може да дойде както от хакер -аматьор, така и от организирана престъпна структура, проникнала в редиците на служителите на доставчика.

В момента няма примери за такъв вид злоупотреба.

Прилагане на строги правила за закупуване на оборудване и използване на подходящи системи за откриване на неоторизиран достъп

Регламентиране на правилата за наемане на служители при обществени договори с потребители

Създаване на прозрачна система за сигурност, заедно с публикуването на доклади за одит на сигурността във вътрешните системи на доставчика

Засегнати модели услуги:

Ориз. 12 Пример за вътрешна информация

Заплаха за сигурността # 4

Уязвимости в облачните технологии

Описание:

Доставчиците на услуги на IaaS използват абстракция на хардуерни ресурси, използвайки системи за виртуализация. Хардуерът обаче може да бъде проектиран, без да се вземат предвид споделените ресурси. За да се сведе до минимум въздействието на този фактор, хипервизорът контролира достъпа на виртуалната машина до хардуерни ресурси, но дори при хипервизори могат да съществуват сериозни уязвимости, чието използване може да доведе до ескалация на привилегиите или до получаване на неправомерен достъп до физическо оборудване.

За да се защитят системите от подобни проблеми, е необходимо да се внедрят механизми за изолиране на виртуални среди и системи за откриване на повреди. Потребителите на виртуални машини не трябва да имат достъп до споделени ресурси.

Има примери за потенциални уязвимости, както и теоретични методи за заобикаляне на изолацията във виртуални среди.

Внедряване на най -модерните методи за инсталиране, конфигуриране и защита на виртуални среди

Използване на системи за откриване на неоторизиран достъп

Прилагане на строги правила за удостоверяване и оторизация за административна работа

Затягане на изискванията за времето за прилагане на корекции и актуализации

· Провеждане на навременни процедури за сканиране и откриване на уязвимости.

Заплаха за сигурността # 5

Загуба или изтичане на данни

Описание:

Загубата на данни може да се случи по хиляди причини. Например умишленото унищожаване на ключа за шифроване ще доведе до невъзстановяване на шифрованата информация. Изтриване на данни или част от данни, неоторизиран достъп до важна информация, промяна на записите или повреда на носителя също са примери за такива ситуации. В сложна облачна инфраструктура вероятността за всяко от събитията се увеличава поради тясното взаимодействие на компонентите.

Неправилното прилагане на правилата за удостоверяване, оторизация и одит, неправилното използване на правилата и методите за шифроване и повреда на оборудването могат да доведат до загуба или изтичане на данни.

Използване на надежден и сигурен API

Шифроване и защита на предаваните данни

Анализ на модела за защита на данните на всички етапи от функционирането на системата

Въвеждане на надеждна система за управление на ключ за криптиране

Избор и закупуване само на най -надеждните носители

Осигуряване на своевременно архивиране на данни

Засегнати модели услуги:

Заплаха за сигурността # 6

Кражба на самоличност и незаконен достъп до услугата

Описание:

Този вид заплаха не е нова. Среща се с милиони потребители всеки ден. Основната цел на нападателите е потребителското име (вход) и неговата парола. В контекста на облачните системи кражбата на парола и потребителско име увеличава риска от използване на данни, съхранявани в облачната инфраструктура на доставчика. Така нападателят има възможност да използва репутацията на жертвата за своите дейности.

Забрана за прехвърляне на сметки

Използване на два факторни метода за удостоверяване

Прилагане на проактивен мониторинг на неоторизиран достъп

· Описание на модела за сигурност на доставчика на облак.

Засегнати модели услуги:

Заплаха за сигурността # 7

Други уязвимости

Описание:

Използването на облачни технологии за правене на бизнес позволява на компанията да се съсредоточи върху бизнеса си, оставяйки грижите за ИТ инфраструктурата и услугите на доставчик на облак. Когато рекламира своята услуга, доставчик на облак се стреми да покаже всички възможности, като същевременно разкрие подробностите за внедряването. Това може да представлява сериозна заплаха, тъй като познаването на вътрешната инфраструктура дава на нападателя възможността да открие неизправена уязвимост и да започне атака срещу системата. За да се избегнат подобни ситуации, доставчиците на облак може да не предоставят информация за вътрешната структура на облака, но този подход също не повишава доверието, тъй като потенциалните потребители нямат възможност да оценят степента на защита на данните. В допълнение, този подход ограничава възможността за своевременно откриване и отстраняване на уязвимости.

Amazon отказва да извърши одит на сигурността в облака EC2

Уязвимост при обработка на софтуер, водеща до нарушаване на системата за сигурност на центъра за данни Hearthland

Разкриване на лог данни

Пълно или частично разкриване на данни за архитектурата на системата и подробности за инсталирания софтуер

· Използване на системи за мониторинг на уязвимости.

Засегнати модели услуги:

1. Правно основание

Според експерти 70% от проблемите със сигурността в облака могат да бъдат избегнати, ако правилно съставите споразумение за услуга.

Основата за такова споразумение може да послужи като „Бил за права на облака“

Билът за правата на Cloud е разработен през 2008 г. от Джеймс Уркухарт. Той публикува този материал в своя блог, което предизвика толкова голям интерес и противоречия, че авторът периодично актуализира своя „ръкопис“ в съответствие с реалностите.

Член 1 (отчасти): Клиентите притежават своите данни

· Никой производител (или доставчик) не трябва, в процеса на взаимодействие с клиенти на който и да е план, да обсъжда правата върху всички данни, качени, създадени, генерирани, модифицирани или други права, които клиентът има.

· Първоначално производителите трябва да осигурят минимален достъп до данните на клиентите на етапа на разработване на решения и услуги.

· Клиентите притежават техните данни, което означава, че те носят отговорност да гарантират, че данните отговарят на законовите разпоредби и закони.

· Тъй като спазването на данните, сигурността и спазването на безопасността са критични, наложително е клиентът да локализира собствените си данни. В противен случай производителите трябва да предоставят на потребителите всички гаранции, че техните данни ще се съхраняват в съответствие с всички правила и разпоредби.

Клауза 2: Производителите и клиентите съвместно притежават и управляват нивата на услуги в системата

· Производителите притежават и трябва да направят всичко, за да отговорят на нивото на обслужване за всеки клиент поотделно. Всички необходими ресурси и усилия, положени за постигане на подходящо ниво на обслужване при работа с клиенти, трябва да бъдат безплатни за клиента, тоест да не са включени в цената на услугата.

· Клиентите от своя страна са отговорни и притежават нивото на услугите, предоставяни на техните собствени вътрешни и външни клиенти. Когато използвате решенията на производителя за предоставяне на собствени услуги, отговорността на клиента и нивото на такова обслужване не трябва да зависят изцяло от производителя.

· Ако е необходимо да се интегрират системите на производителя и клиента, производителите трябва да предложат на клиентите възможността да наблюдават процеса на интеграция. Ако клиентът има корпоративни стандарти за интегриране на информационни системи, производителят трябва да спазва тези стандарти.

· При никакви обстоятелства производителите не трябва да закриват потребителски акаунти за политически изказвания, неподходящи изказвания, религиозни коментари, освен ако не противоречат на конкретни законови разпоредби, не са израз на омраза и т.н.

Член 3: Производителите притежават своите интерфейси

· От производителите не се изисква да предоставят стандартни интерфейси или интерфейси с отворен код, освен ако не е посочено друго в споразуменията с клиентите. Производителите имат права на интерфейси. Ако производителят не счита за възможно да предостави на клиента възможност за усъвършенстване на интерфейса на познат език за програмиране, клиентът може да закупи от производителя или разработчици на трети страни услуги за финализиране на интерфейсите в съответствие със собствените им изисквания.

· Клиентът обаче има право да използва закупената услуга за свои цели, както и да разшири възможностите си, да я възпроизведе и подобри. Тази клауза не освобождава клиентите от права на патент и интелектуална собственост.

Горните три статии са основата за клиенти и доставчици в облака. Можете да намерите пълния им текст в публичното пространство в Интернет. Разбира се, този законопроект не е пълен правен документ, още по -малко официален. Статиите му могат да се променят и разширяват по всяко време, както и законопроектът може да бъде допълнен с нови членове. Това е опит за формализиране на „собствеността“ в облака, за да се стандартизира по някакъв начин тази свободолюбива област на знания и технологии.

Взаимоотношения между страните

Най -добрият експерт в областта на сигурността в облака е Cloud Security Alliance (CSA). Организацията пусна и наскоро актуализира ръководство, което включва стотици нюанси и най -добри практики, които трябва да се вземат предвид при оценката на рисковете в облачните изчисления.

Друга организация, която се занимава с аспекти на сигурността в облака, е Trusted Computing Group (TCG). Тя е автор на няколко стандарта в тази и други области, включително широко използваните днес Trusted Storage, Trusted Network Connect (TNC) и Trusted Platform Module (TPM).

Тези организации съвместно са решили редица въпроси, които клиентът и доставчикът трябва да решат при сключването на договор. Тези въпроси ще решат повечето проблеми при използване на облака, форсмажорни обстоятелства, смяна на доставчици на облачни услуги и други ситуации.

1. Безопасност на съхраняваните данни. Как доставчикът на услуги гарантира безопасността на съхраняваните данни?

Най -добрата мярка за защита на данните, съхранявани в хранилище на данни, е използването на технологии за криптиране. Доставчикът винаги трябва да криптира информацията за клиента, съхранявана на неговите сървъри, за да предотврати случаи на неоторизиран достъп. Доставчикът също трябва да изтрие за постоянно данни, когато те вече не са необходими и няма да се изискват в бъдеще.

2. Защита на данните по време на предаването. Как доставчикът гарантира безопасността на данните по време на тяхното прехвърляне (вътре в облака и по пътя от / към облака)?

Предаваните данни трябва винаги да бъдат криптирани и достъпни за потребителя само след удостоверяване. Този подход гарантира, че тези данни не могат да бъдат променяни или четени от никого, дори ако те получат достъп до тях чрез ненадеждни възли в мрежата. Тези технологии са разработени в продължение на "хиляди човеко-години" и са довели до създаването на надеждни протоколи и алгоритми (например TLS, IPsec и AES). Доставчиците трябва да използват тези протоколи, а не да измислят свои собствени.

3. Удостоверяване. Как доставчикът знае автентичността на клиента?

Най -често срещаният метод за удостоверяване е защитата с парола. Доставчиците, които искат да предложат на своите клиенти по -голяма надеждност, търсят по -мощни инструменти като сертификати и жетони. Доставчиците трябва да могат да работят със стандарти като LDAP и SAML в допълнение към използването на по -сигурни средства за удостоверяване. Това е необходимо, за да се гарантира, че доставчикът взаимодейства със системата за идентификация на потребителя на клиента при оторизиране и определяне на разрешенията, дадени на потребителя. Благодарение на това доставчикът винаги ще има актуална информация за оторизираните потребители. Най -лошият сценарий е, когато клиентът предоставя на доставчика определен списък с оторизирани потребители. По правило в този случай, когато служител бъде уволнен или преместен на друга длъжност, могат да възникнат трудности.

4. Изолация на потребителя. Как данните и приложенията на един клиент са отделени от данните и приложенията на други клиенти?

Най -добрият вариант: когато всеки от клиентите използва индивидуална виртуална машина (Virtual Machine - VM) и виртуална мрежа. Разделянето между виртуалните машини и следователно между потребителите се осигурява от хипервизора. Виртуалните мрежи от своя страна се разгръщат с помощта на стандартни технологии като VLAN (виртуална локална мрежа), VPLS (виртуална частна LAN услуга) и VPN (виртуална частна мрежа).

Някои доставчици поставят всички клиентски данни в единна софтуерна среда и се опитват да изолират клиентските данни един от друг чрез промени в кода. Този подход е безразсъден и ненадежден. Първо, нападателят може да открие недостатък в нестандартния код, който би му позволил да получи достъп до данни, които не трябва да вижда. Второ, грешка в кода може да доведе до факта, че един клиент случайно „вижда“ данните на друг. Напоследък имаше и такива, и други случаи. Следователно, за да се разграничат потребителските данни, използването на различни виртуални машини и виртуални мрежи е по -разумна стъпка.

5. Регулаторни въпроси. Доколко доставчикът спазва законите и разпоредбите, приложими за индустрията за облачни изчисления?

В зависимост от юрисдикцията законите, разпоредбите и всякакви специални разпоредби могат да варират. Например, те могат да забранят износа на данни, да изискват строго определени предпазни мерки, да отговарят на определени стандарти и да бъдат одитирани. В крайна сметка те могат да изискват правителствените ведомства и съдилищата да имат достъп до информация, когато е необходимо. Небрежността на доставчика към тези моменти може да доведе клиентите му до значителни разходи поради правни последици.

Доставчикът трябва да спазва строги правила и да се придържа към единна правна и регулаторна стратегия. Това се отнася до сигурността на потребителските данни, техния износ, спазването на стандартите, одита, безопасността и изтриването на данни, както и разкриването на информация (последното е особено важно, когато информация на няколко клиенти може да се съхранява на един физически сървър). За да разберете, клиентите силно се насърчават да потърсят помощ от специалисти, които ще проучат внимателно този въпрос.

6. Реакция на инциденти. Как доставчикът реагира на инциденти и до каква степен клиентите му могат да участват в инцидента?

Понякога не всичко върви по план. Следователно доставчикът на услуги е длъжен да се придържа към специфични правила за поведение в случай на непредвидени обстоятелства. Тези правила трябва да бъдат документирани. Наложително е доставчиците да идентифицират инциденти и да сведат до минимум техните последствия, като информират потребителите за текущата ситуация. В идеалния случай те трябва редовно да предоставят на клиентите възможно най -подробна информация по въпроса. В допълнение, клиентите трябва да преценят вероятността от проблем със сигурността и да предприемат необходимите действия.

10. Международни и вътрешни стандарти

Еволюцията на облачните технологии изпревари усилията за създаване и промяна на необходимите индустриални стандарти, много от които не са актуализирани от години. Следователно законотворчеството в областта на облачните технологии е една от най -важните стъпки към гарантиране на сигурността.

IEEE, една от най -големите световни организации за разработване на стандарти, обяви стартирането на специална инициатива за облачни изчисления. Това е първата инициатива за стандартизация в облака, стартирана в международен план - досега стандартите за облачни изчисления бяха доминирани от индустриалните консорциуми. Понастоящем инициативата включва 2 проекта: IEEE P2301 (tm), „Проект на ръководство за преносимост и оперативна съвместимост на облачните профили“ и IEEE P2302 (tm) - „Проект на стандарт за оперативна съвместимост и разпределена оперативна съвместимост (федерация) на облачните системи“.

В рамките на Асоциацията за разработване на стандарти на IEEE бяха създадени 2 нови работни групи, които да работят съответно по проекти IEEE P2301 и IEEE P2302. IEEE P2301 ще съдържа профили на съществуващи и предстоящи приложения, стандарти за преносимост, управление и оперативна съвместимост, както и файлови формати и оперативни конвенции. Информацията в документа ще бъде логически структурирана според различни целеви аудитории: доставчици, доставчици на услуги и други заинтересовани участници на пазара. След приключване стандартът се очаква да бъде използваем при закупуването, разработването, изграждането и използването на облачни продукти и услуги, базирани на стандартни технологии.

Стандартът IEEE P2302 ще описва основната топология, протоколи, функционалност и методи за управление, необходими за взаимодействието на различни облачни структури (например за взаимодействието на частен облак и публичен, като EC2). Този стандарт ще позволи на доставчиците на облачни продукти и услуги да извлекат икономически ползи от икономиите от мащаба, като същевременно осигури прозрачност за потребителите на услуги и приложения.

ISO подготвя специален стандарт за сигурност на изчислителните облаци. Основният фокус на новия стандарт е да се обърне внимание на организационните въпроси, свързани с облаците. Въпреки това, поради сложността на процедурите за хармонизация на ISO, окончателната версия на документа не трябва да бъде публикувана до 2013 г.

Ценността на документа е, че в подготовката му участват не само правителствени организации (NIST, ENISA), но и представители на експертни общности и асоциации като ISACA и CSA. Освен това един документ съдържа препоръки както за доставчиците на облачни услуги, така и за техните потребители - клиентски организации.

Основната цел на този документ е да опише подробно най -добрите практики, свързани с използването на облачни изчисления от гледна точка на сигурността на информацията. В същото време стандартът не се концентрира само върху технически аспекти, а по -скоро върху организационни аспекти, които не трябва да се забравят при прехода към облачни изчисления. Това е разделянето на правата и отговорностите, и подписването на споразумения с трети страни, и управлението на активи, притежавани от различни участници в „облачния“ процес, и въпросите за управлението на персонала и т.н.

Новият документ до голяма степен включва материали, разработени преди това в ИТ индустрията.

Австралийско правителство

След месеци на мозъчна атака, австралийското правителство пусна поредица от базирани в облака ръководства за миграция на 15 февруари 2012 г. в блога на Австралийската правителствена служба за управление на информацията (AGIMO).

За да се улесни мигрирането на компаниите в облака, са предоставени насоки относно най -добрите практики за използване на облачни услуги, за да отговарят на изискванията на Закона за по -добри практики за финансово управление и отчетност от 1997 г. Ръководствата разглеждат финансовите, правните и защитата на данните в общи линии.

Насоките говорят за необходимостта от постоянно наблюдение и контрол на използването на облачни услуги чрез ежедневен анализ на сметки и отчети. Това ще помогне да се избегнат скритите надценки и зависимостта от доставчиците на облачни услуги.

Първото ръководство е озаглавено Поверителност и облачни изчисления за австралийските държавни агенции (9 страници). Този документ се фокусира върху проблемите на поверителността и сигурността на данните.

В допълнение към това ръководство, „Преговори в облака - правни проблеми в споразуменията за облачни изчисления“ (19 страници) също е подготвено, за да ви помогне да разберете клаузите, включени в договора.

Последният, трети наръчник, Финансови съображения за правителственото използване на облачни изчисления, на 6 страници, обсъжда финансовите въпроси, на които една компания трябва да обърне внимание, ако реши да използва облачни изчисления в своя бизнес.

В допълнение към тези, обхванати в ръководствата, има редица други въпроси, които трябва да бъдат разгледани при използване на облачни изчисления, включително въпроси, свързани с правителството, обществените поръчки и политиката за управление на бизнеса.

Публичното обсъждане на този документ за политика предоставя възможност на заинтересованите страни да разгледат и коментират следните проблеми, които предизвикват безпокойство:

· Неразрешен достъп до класифицирана информация;

· Загуба на достъп до данни;

Неспазване на целостта и автентичността на данните, и

· Разбиране на практическите аспекти на предоставянето на облачни услуги.

11. Териториална идентичност на данните

В редица държави има редица разпоредби, които изискват чувствителните данни да останат в страната. Въпреки че съхраняването на данни в рамките на дадена територия може да не изглежда трудно на пръв поглед, доставчиците на облачни услуги често не могат да гарантират това. В системи с висока степен на виртуализация данните и виртуалните машини могат да се преместват от една държава в друга за различни цели - балансиране на натоварването, устойчивост на грешки.

Някои от основните играчи на пазара на SaaS (като Google, Symantec) могат да гарантират съхранението на данни в съответната държава. Но това са по -скоро изключения; като цяло изпълнението на тези изисквания все още е доста рядко. Дори ако данните останат в страната, няма начин клиентите да ги проверят. Освен това не трябва да забравяме за мобилността на служителите на компанията. Ако специалист, работещ в Москва, пътува до Ню Йорк, тогава е по -добре (или поне по -бързо) той да получава данни от център за данни в САЩ. Да се ​​гарантира, че това вече е с порядък по -трудна задача.

12. Държавни стандарти

Към момента у нас няма сериозна регулаторна рамка за облачните технологии, въпреки че развитието в тази област вече тече. И така, със заповед на президента на Руската федерация № 146 от 8.02.2012г. беше установено, че федералните изпълнителни органи, оторизирани в областта на сигурността на данните в информационни системи, създадени с помощта на суперкомпютърни и мрежови технологии, са ФСБ на Русия и FSTEC на Русия.

Във връзка с това постановление правомощията на тези служби са разширени. Сега ФСБ на Русия разработва и одобрява регулаторни и методологични документи за осигуряване на сигурността на тези системи, организира и провежда изследвания в областта на информационната сигурност.

Услугата също така извършва експертни криптографски, инженерно-криптографски и специални проучвания на тези информационни системи и изготвя експертни становища по предложения за работа по тяхното създаване.

Документът също така предвижда, че FSTEC на Русия разработва стратегия и определя приоритетни области за гарантиране на сигурността на информацията в информационните системи, създадени с помощта на суперкомпютърни и мрежови технологии, които обработват ограничени данни, а също така следи състоянието на работа, за да гарантира тази сигурност.

FSTEC поръча проучване, което доведе до бета версия на „терминологичната система в областта на„ облачните технологии “

Както можете да разберете, цялата тази терминологична система представлява адаптиран превод на два документа: „Фокус група по технически доклад за облачни изчисления“ и „Дефиницията на облачните изчисления NIST“. Е, фактът, че тези два документа не са много съгласувани помежду си, е отделен въпрос. Но визуално все още се вижда: в руската "Терминосистема" авторите просто не предоставиха за начало връзки към тези английски документи.

Факт е, че за такава работа първо трябва да обсъдите концепцията, целите и задачите, методите за тяхното решаване. Има много въпроси и коментари. Основната методологична бележка: необходимо е много ясно да се формулира какъв проблем решава това изследване, неговата цел. Искам да отбележа веднага, че „създаването на терминологична система“ не може да бъде цел, то е средство, но постигането на това, което все още не е много ясно.

Да не говорим, че нормалното изследване трябва да включва раздел за статуквото.

Трудно е да се обсъдят резултатите от изследване, без да се знае оригиналната формулировка на проблема и как авторите са го разрешили.

Но една фундаментална грешка на терминологичната система е ясно видима: невъзможно е да се обсъжда „облачният предмет“ отделно от „не облачния“. Извън общия ИТ контекст. Но този контекст не се вижда в изследването.

Резултатът от това е, че на практика такава терминологична система ще бъде невъзможно да се приложи. Това може само да обърка допълнително ситуацията.

13. Средства за облачна сигурност

Системата за защита на облачен сървър в своята минимална конфигурация трябва да гарантира сигурността на мрежовото оборудване, съхранението на данни, сървъра и хипервизора. Освен това е възможно да се постави антивирус в специално ядро, за да се предотврати заразяване на хипервизора чрез виртуална машина, система за криптиране на данни за съхраняване на потребителска информация в криптирана форма и средства за прилагане на криптиран тунел между виртуалния сървър и клиента машина.

За това имаме нужда от сървър, който поддържа виртуализация. Решения от този вид се предлагат от Cisco, Microsoft, VMWare, Xen, KVM.

Допустимо е също да се използва класически сървър и да се осигури виртуализация на него с помощта на хипервизор.

Всички сървъри със съвместими процесори са подходящи за виртуализация на операционни системи за x86-64 платформи.

Подобно решение ще опрости прехода към компютърна виртуализация, без да прави допълнителни финансови инвестиции в хардуерни надстройки.

Схема на работа:

Ориз. 11. Пример за "облачен" сървър

Ориз. 12. Реакция на сървъра при повреда на оборудването

В момента пазарът на инструменти за сигурност в облачните изчисления все още е доста празен. И това не е изненадващо. При липса на регулаторна рамка и несигурност относно бъдещите стандарти, компаниите за развитие не знаят върху какво да насочат усилията си.

Въпреки това, дори при такива условия се появяват специализирани софтуерни и хардуерни системи, които дават възможност да се защити облачната структура от основните видове заплахи.

Нарушение на почтеността

Хакване на хипервизор

Вътрешни лица

Идентификация

Удостоверяване

Шифроване

Акорд-Б

Хардуер и софтуерна система Акорд-Б.предназначени за защита на инфраструктурата за виртуализация VMware vSphere 4.1, VMware vSphere 4.0 и VMware Infrastructure 3.5.

Акорд-Б. Осигурява защита за всички компоненти на средата за виртуализация: ESX сървъри и самите виртуални машини, сървъри за управление на vCenter и допълнителни сървъри с VMware услуги (например VMware Consolidated Backup).

В хардуерния и софтуерен комплекс Accord-V са внедрени следните защитни механизми:

· Поетапен контрол на целостта на хипервизора, виртуалните машини, файловете във виртуалните машини и сървърите за управление на инфраструктурата;

· Разграничаване на достъпа за администратори на виртуална инфраструктура и администратори на сигурността;

· Разграничаване на потребителския достъп вътре във виртуални машини;

· Хардуерна идентификация на всички потребители и администратори на инфраструктурата за виртуализация.

ИНФОРМАЦИЯ ЗА НАЛИЧНОСТТА НА СЕРТИФИКАТИ:

Сертификатът за съответствие на FSTEC на Русия № 2598 от 20.03.2012 г. удостоверява, че хардуерният и софтуерен комплекс от средства за защита на информацията от неоторизиран достъп "Accord-V." Отговаря на изискванията на ръководните документи "Компютърни съоръжения. Защита срещу неоторизиран достъп до информация. Показатели за сигурност срещу неоторизиран достъп до информация "(Държавна техническа комисия на Русия, 1992 г.) - съгласно 5 клас на защита, "Защита срещу неоторизиран достъп до информация. Част 1. Софтуер за защита на информацията. Класификация по нивото на контрол на липсата на недекларирани възможности" (Държавна техническа комисия на Русия, 1999 г.) - от 4 нивото на контрол и техническите условия TU 4012-028-11443195-2010, а също така може да се използва за създаване на автоматизирани системи до клас на сигурност 1G включително и за защита на информацията в информационните системи за лични данни до клас 1 включително.

vGate R2

vGate R2 е сертифицирано средство за защита на информацията срещу неоторизиран достъп и контрол на изпълнението на политиките за защита на информацията за виртуална инфраструктура, базирана на VMware vSphere 4 и VMware vSphere 5.S R2 системи - версия на продукта, приложим за защита на информацията във виртуални инфраструктури на публични компании, към чиито IP се прилагат изисквания за използване на системи за информационна сигурност с високо ниво на сертифициране.

Позволява ви да автоматизирате работата на администраторите, за да конфигурирате и управлявате системата за сигурност.

Помага за противодействие на грешки и злоупотреби при управление на виртуална инфраструктура.

Позволява ви да приведете виртуалната инфраструктура в съответствие със законодателството, индустриалните стандарти и най -добрите световни практики.

<#"783809.files/image017.gif"> <#"783809.files/image018.gif"> <#"783809.files/image019.gif"> <#"783809.files/image020.gif"> Ориз. 13 обявени възможности на vGate R2 Така, за да обобщим, ето основните инструменти, които vGate R2 притежава, за да защити центъра за данни на доставчика на услуги от вътрешни заплахи, произтичащи от собствените му администратори: Организационно и техническо разделение на правомощията за администраторите на vSphere Разпределяне на отделна роля на администратора на IS, който ще управлява сигурността на ресурсите на центъра за данни на базата на vSphere Разделяне на облака в зони за сигурност, в рамките на които действат администратори със съответното ниво на правомощия Контрол на целостта на виртуални машини Възможност за получаване на отчет за сигурността на vSphere инфраструктурата по всяко време, както и за одит на събития за сигурност на информацията По принцип това е почти всичко необходимо за защита на инфраструктурата на виртуален център за данни от вътрешни заплахи от гледна точка на виртуалната инфраструктура. Разбира се, вие също се нуждаете от защита на ниво хардуер, приложения и гост операционна система, но това е друг проблем, който също се решава чрез кодовете за сигурност на продуктите на компанията<#"783809.files/image021.gif"> Ориз. 14. Структура на сървъра. За да се гарантира безопасността на такова съоръжение, е необходимо да се гарантира безопасността, съгласно Таблица 2. За тази цел предлагам да използвате софтуерния продукт vGate R2.Това ще ви позволи да решите проблеми като: · По -силно удостоверяване за администратори на виртуална инфраструктура и администратори за защита на информацията. · Защита на инструментите за управление на виртуална инфраструктура от подправяне. · Защита на ESX-сървъри от подправяне. · Задължителен контрол на достъпа. · Наблюдение на целостта на конфигурацията на виртуални машини и надеждно зареждане. · Контрол на достъпа на VI администратори до данни на виртуални машини. · Регистрация на събития, свързани с информационната сигурност. · Наблюдение на целостта и защита срещу подправяне на компонентите на системата за информационна сигурност. · Централизирано управление и мониторинг. Таблица 2. Съпоставяне на нуждите за сигурност за модела PaaS Сертификат FSTEC на Русия (SVT 5, NDV 4) позволява продуктът да се използва в автоматизирани системи с ниво на сигурност до клас 1G включително и в информационни системи за лични данни (ISPDN) до клас K1 включително. Цената на това решение ще бъде 24 500 рубли за 1 физически процесор на защитения хост. Освен това, за да се предпазите от вътрешни лица, ще трябва да инсталирате аларма за сигурност. Тези решения са доста богато предоставени на пазара за защита на сървъри. Цената на такова решение с ограничен достъп до контролираната зона, система за аларма и видеонаблюдение варира от 200 000 рубли и повече Да вземем например сумата от 250 000 рубли. За да защити виртуалните машини от вирусни инфекции, едно сървърно ядро ​​ще изпълнява McAfee Total Protection for Virtualization. Цената на решението е от 42 200 рубли. Symantec Netbackup ще се използва за предотвратяване на загуба на данни в хранилищата. Тя ви позволява сигурно да архивирате информация и системни изображения. Общите разходи за изпълнение на такъв проект ще бъдат: Реализация на Microsoft на подобно дизайнерско решение може да бъде изтеглена от тук: http://www.microsoft.com/en-us/download/confirmation. aspx? id = 2494 Изход „Облачните технологии“ са една от най -активно развиващите се области на ИТ пазара в момента. Ако темпът на растеж на технологиите не намалее, тогава до 2015 г. те ще допринесат за съкровищницата на европейските страни с над 170 милиона евро годишно. У нас облачните технологии се третират с повишено внимание. Това отчасти се дължи на окостенелите възгледи на ръководството, отчасти на липсата на доверие в сигурността. Но този тип технологии, с всичките им предимства и недостатъци, са нов локомотив на ИТ напредъка. Приложението „от другата страна на облака“ няма абсолютно никакво значение дали формулирате заявката си на компютър с x86 процесор Intel, AMD, VIA или я съставяте на телефон или смартфон на базата на ARM процесор Freescale, OMAP, Tegra . Освен това като цяло няма да има значение дали използвате Linux операционни системи Google Chrome, OHA Android, Intel Moblin, Windows CE, Windows Mobile Windows XP / Vista / 7 или използвате нещо още по -екзотично за това. ... Ако само заявката е била компилирана правилно и разбираемо и вашата система е успяла да „овладее“ получения отговор. Въпросът за сигурността е един от основните проблеми в облачните изчисления и неговото решение ще подобри качеството на услугите в компютърната сфера. Все пак има още много да се направи в тази посока. У нас си струва да се започне с единен речник на термините за цялата IT област. Разработване на стандарти въз основа на международния опит. Предложете изисквания за системите за сигурност. Литература 1. Финансови съображения за правителственото използване на облачни изчисления - Австралийско правителство 2010 г. 2. Поверителност и облачни изчисления за австралийските държавни агенции 2007 г. Договаряне на облака - правни въпроси в споразуменията за облачни изчисления 2009 г. Списание "Съвременна наука: Актуални проблеми на теорията и практиката" 2012. Подобна работа с - Информационна сигурност в облачните изчисления: уязвимости, методи и средства за защита, инструменти за одит и разследване на инциденти