В процеса на преминаването на компютърните операции в облака от маркетингов инструмент към реалността реални клиенти, с реални внедрявания, става все поважно за професионалистите по сигурността на информацията да разбират значителната промяна в изчислителната среда и риска за корпорациите. Облачният компютинг се развива бързо и много доставчици изведнъж обявиха, че са „облачни“, което може да затрудни разпознаването на критичните последици за сигурността в облака за корпорациите.
Тук ще хвърлим светлина върху изчислителните облаци и начина, по който общественият облак променя риска за корпорациите. Също така ще проучим как практикуващите информационна сигурност трябва да се подготвят за прехвърляне в облака, както и за появата на рамки за управлението й и за други промени, които трябва да се случат, за да станат изчислителните облаци по-надеждни.
Как облакът влияе върху сигурността
Като за начало изчислителните облаци са еволюция в компютинга, а не въвеждане на нова технология. По-скоро облакът се отнася за различен бизнес и оперативен модел на работа основан на споделени ресурси. Тези споделени ресурси са единственият начин за постигане на икономии от мащаб, който води до по-ниски разходи, което е един от основните двигатели за бизнеса, за да се ориентира към изчислителните облаци, както и поради бързината му. Но тази промяна в бизнес модела също предвещава промени в информационната сигурност, които изискват оценка. Ето някои от предизвикателствата пред сигурността, които идват с обществените облаци.
1. Границите на доверителност са неясни. В традиционните ИТ на организациите специалистите по сигурност на информацията знаят къде са границите на доверителност. Обикновено това означава, че всичко в рамките на „периметъра“ (най-малкото на концепцията за периметър), както и външните интерфейсни системи и някои връзки към трети страни, зависят от специфичните условия на организацията. При изчислителните облаци, когато тези граници на доверие са лице в лице с отговорностите на доставчиците на облачни услуги, те са много по-неясни. Какви са преките ви отговорности за сигурността спрямо тези на доставчика, може би не е ясно определено в споразумението за нивото на услугите на доставчика (SLA). Освен това тези промени в отговорността варират от доставчик до доставчик на услуги. И отгоре на всичко отговорностите зависят от това, къде се намирате в модела на обслужване в облака на доставчика SPI (софтуер-като-услуга, платформа-като-услуга и инфраструктура-като-услуга). Това означава, че вашата отговорност в сравнение с отговорността на доставчика е различна за SaaS спрямо IaaS. Това объркване около доверителните граници е основната причина специалистите по сигурността на информацията да са загрижени за сигурността при изчислителните облаци, заедно с общата липса на прозрачност от страна на доставчиците на услуги в облака по отношение на тяхната сигурност.
2. Всяко, разделение на данни сега е логично. В миналото организациите обикновено искаха да се уверят, че техните данни са физически отделени от данните на други организации. Разбира се, когато данните се съхраняват вътрешно в собствени центрове за данни на организацията, точно това се случва физическо разделяне на данните. Дори когато една организация използва хостинг услуга, тя все още отделя данните си физически. Например, въпреки че дадена хостинг услуга предоставя общи съоръжения за няколко клиенти и обикновено има някакво споделяне на мрежовите ресурси, клиентите обикновено имат предназначени за тях (макар и под наем или лизинг) сървъри, на които работят техните приложения или се съхраняват техните данни. Същото важи и за доставчиците на услуги (ASP). Обаче при публичните изчислителни облаци всички изчислителни ресурси са споделени.
3. Видимостта на мрежата се увеличава. Въпреки че тази видимост на мрежата не е нещо ново, величината й е много по-голяма в облака отколкото преди. Тъй като потребителите вече трябва да преминават през интернет, за да достигнат своите приложения и/или данни, за разлика може би само в интранет, има повишен риск този достъп да е предмет на мрежовите заплахи, които обикновено са избегнати във вътрешния периметър. Например атака тип разпределен отказ от услуги (DDoS) може да е насочена срещу интернет гейтуея на вашата организация или на вашия доставчик на услуги в облака, с което да възпрепятства достъпа до базираните на облака приложения и/или данни. Представете си, че такава атака е осъществена по време на месечното или тримесечното приключване във вашата организация. Прекъсване на трафика чрез пренасочване с помощта на атака тип Border Gateway Protocol (BGP) също е възможна при обществените изчислителни облаци.
4. Видимостта на приложенията се увеличава. Приложенията, които преди може да са били защитени, защото са се намирали на вътрешно местоположение, сега са външни и доста видими, ако са базирани на облака или са в контакт с интернет. Много доставчици на SaaS твърдят, че приложенията им са безопасни, защото са с намалена повърхност за атака, понеже са базирани на сървър за достъп се използва само браузър; няма специфичен за приложението код или функционалност при клиента както и на факта, е че някои SaaS приложения са видими само през своите приложни програмни интерфейси (API). Разбира се, това предполага, че SaaS доставчиците действително са предприели мерки за защита на техните приложения и API, и са ги тествали. Това също така предполага, че SaaS приложенията се използват като самостоятелни услуги, без интеграция с други приложения, което е съмнително предположение. Фактът, че много SaaS приложения всъщност са построени от трети страни върху други услуги в облака (или PaaS, или IaaS), допълнително поставя под въпрос сигурността на SaaS приложенията. Освен това много SaaS API (включително Amazon Web Services, Google и Salesforce.com) използват REST (REpresentational State Transfer), който няма предварително вградени методи за сигурност.
5. Променя се моделът на управление. Поконкретно въпросът е, че няма установен модел на управление в момента за облачния компютинг. Как точно професионалистите по сигурността на информацията трябва да защитават своите корпоративни данни в това, което трябва да се счита за ненадеждна околна среда? За щастие вече се работи по разработването на модел на управление за облачния компютинг.
Как да се подготвим за облака
Като се имат предвид рисковете, общественият облак поне засега не е добър за чувствителна, регулирана от закона и/или класифицирана информация. Това, за което е добър, са не-чувствителни, не-регулирани и некласифицирани данни данни, които вероятно вече са публични, като повечето от тях са били предназначени предварително да бъдат публични. При по-голямата част от организациите (с изключение на отбраната, военните и разузнавателната общност) такава публично обявявана информация вероятно съставлява 90 процента от техните данни. Освен това за чувствителна, регулирана и/или класифицирана информация частните облаци или облачната инфраструктура, споделена между няколко организации (общностни облаци), все още са атрактивни възможности. Като имаме предвид това, тук даваме стъпки за практикантите по сигурност, които те трябва да предприемат, когато изследват използването на публични услуги в облака:
1. Самооценка. Номер едно приоритет не трябва да бъде проучване на сигурността, гарантирана от страна на доставчиците на услуги в облака. Найважният приоритет е да разгледате вашите собствени политики за класификация на данни и как тези политики се прилагат в момента. Преди да обвинявате доставчиците на услуги в облака за тяхната относителна липса на сигурност (в сравнение с тази, осъществявана от най-големите предприятия), се уверете, че вашата собствена къща с данни е в ред. Имате ли актуална за момента политика за класификация на данните? Колко добре се прилага тази политика? Имате ли собственици и попечители, предвидени за всички данни? Какво е нивото на информираност за политиката за поверителност във вашата собствена организация и колко добре се прилага (ако приемем, че вашата организация има такава)?
2. Анонимизиране на данните. Какви средства и възможности има вашата организация за анонимизиране на данни, така че всички елементи, които идентифицират лица да са отстранени? Ако все пак се местите в „облака“, очаквайте, че другите бизнес отдели вероятно ще залеят информационната сигурност с молби за помощ за анонимизиране на данните, така че да може те да бъдат пуснати в облака в съответствие с вашата политика за класификация на данните.
3. Дю дилиджънс. Когато тези дейности за класификация на данните са изпълнени от организацията ви, тогава дължимата грижа към сигурността на доставчиците на услуги в облака трябва да започне. Например, какъв е моделът на свързаност към обществения облак за администрацията? Каква подкрепа има за финансиране на наблюдение на съществуващате сигурност и на инструменти за управление, включително скенери на уязвимости, промяна на управлението и налагане на политики за защитната стена на мрежата и на хост равнище (например, чрез използване на виртуални частни облаци)? Някои приложения изискват свързване с база данни обратно в организацията и може да нарушат съществуващата политика. Също така вашата организация може да има изискване за поддръжка на силно удостоверяване може ли доставчикът да отговари на това изискване?
4. Сигурността в крайната точка. Въпреки че провеждате такава дължима грижа, съществена за новите ИТ възможности на задния фронт на вашата организация, не забравяйте за ИТ възможностите на предния фронт на вашата организация. Каква е сигурността на всички тези крайни потребителски устройства, които ще бъдат използвани за достъп до облака и данните в него?
Усилиятa на управлението
Докато публичните облаци са добри за публични данни (нечувствителни, които не са регулирани и които не са класифицирана информация), има много организации, които биха искали да използват обществени облаци за други данни при условие че тяхната сигурност е адекватна. А днес сигурността на обществените облаци не е подходяща за тази чувствителна информация.
Най-големият проблем със сигурността на обществените изчислителни облаци е липсата на прозрачност от страна на доставчиците на услуги в облака за техните възможности за защита. Като цяло те не са склонни да бъдат проверявани и техните споразумения за ниво на обслужване са без стойност. Доставчиците на услуги в облака само са започнали, макар и в частни разговори, да признават тези недостатъци. Те са съгласни, че е в техен интерес, както и на техните клиенти, да има повече прозрачност и да има някаква стандартизирана рамка за сигурност, според която да се измерват възможностите им.
В действителност през последните няколко месеца се разви почти обратният проблем. Сега има няколко организации, които развиват различни рамки за сигурност за изчислителните облаци. Тези рамки включват:
• Работна група A6 (Automated Audit , Assertion, Assessment, and Assurance API): Това усилие, известно също като CloudAudit (облачен одит), се ръководи от известния експерт по сигурността Крис Хоф, директор за решенията в облака и виртуализацията в Cisco Systems.
• Инициатива Trusted Cloud Initiative: В процес на разработване от Cloud Security Alliance. Според Лиам Линч, главен стратег за сигурността в eBAy и съпредседател на инициативата, усилията ще се основават на „стълбове“, изградени от работата на алианса, и ще включват всички производители на продукти, които предоставят платформа за сигурност от край до край. Инициативата също така планира да предостави референтни внедрявания и ще включи инициативата А6.
• Модел Common Assurance Maturity Model (CAMM): 24-членен консорциум, състоящ се предимно от доставчици, но включващ също и Европейската агенция за мрежова и информационна сигурност (ENISA). CAMM първоначално стартира през февруари като Common Assurance Metric (обща гаранция за измерване). Според Джери О`Нийл, главен изпълнителен директор на базирания във Великобритания институт на професионалистите по информационна сигур-ност и на управителния комитет на CAMM, официалната версия е планирана за пускане през ноември.
• Програма Federal Risk and Authorization Management Program (FedRAMP): Свързано с дру-гите три проекта, това е едно усилие, замислено като обща инициатива на правителството на САЩ, която да осигури съвместна оторизация и наблюдение на споделените услуги за ИТ сигурност за федералните служби и агенции, които са сключили договори с външни доставчици, включително и такива, които предлагат решения за облачен компютинг. Нацио-налният институт по стандарти и технологии (NIST) съпредседателства тези усилия.
Необходима е повече сигурност.
Освен по-голяма прозрачност има и други подобрения, от които се нуждае облачният компютинг, за да може корпоративният бизнес да разчита на него за повече неща от нечувствителни и нерегулиран данни. От техническа гледна точка основното необходимо подобрение на сигурността е по-добро управление на атрибутите както за идентичността, така и за криптографското управление. По-доброто управление на идентичността е необходимо от гледна точка на разширеното използване на обединена идентичност – както корпоративно ориентираната, обикновено под-държана от стандарти, като Security Assertion Mark-Up Language (SAML), така и потребителски ориентираната, подкрепяна от стандарти като OpenID. Въпреки това управлението на обединената идентичност все още страда от проблеми с доверието (т.е. с приемането на удостоверенията, издавани от друга организация), както и със самото управление на пълномощията.Управлението на криптографските ключове също страда от липса на обединение. Протоколът OASIS’ Key Management Interoperability Protocol (KMIP) е подобрение, което стандартизира употребата на протоколите клиент-сървър. Въпреки че тези усилия са значителни за частните облаци на корпорациите, те все още са недостатъчни за публичните изчислителни облаци. Това, което е наистина необходимо за управление на криптографските ключове, в допълнение към KMIP, е стандартизираното използване на сървър-сървър протоколи и поддръжка от трети лица (независими от доставчиците на услуги в облака) за управление на жизнения цикъл на ключовете, в това число създаване на техни резервни копия и отмяната им. Но по-голям въпрос е защо управляваме идентичностите и криптографските ключове отделно, особено когато и едните и другите са се развили в подобни рамки за управление. И идентичностите, и криптографските ключове са атрибути, които следва да се управляват в една обща рамка, която също покрива и други атрибути. Само такава рамка ще се мащабира до обществени облаци и вътрешни облаци, или до взаимодействието облак-облак.
Ние само докоснахме повърхността на трвогите около сигурността в изчислителните облаци, по-специално при използването на публични облаци. Въпреки това, преди да се занимаваме твърде много с възможностите на доставчиците на услуги в облака и техните предложения, погледнете назад към собствената си организационна готовност за използване на облака. И нека не забравяме, че облачният компютинг наистина все още е незрял в този момент. Облакът се развива и не липсват стандартизиращи организации и индустриални групи, които гарантират, че това се случва. Но преди импулсивно да призоваваме за правила, трябва да дадем на пазара известно време да намери собственото си ниво.
През последните две години е налице огромен напредък в този нов бизнес модел и модел за предоставяне на услуги, и можем да очакваме, че свързаната с това сигурност и неприкосновеността на личния живот ще постигнат напредък в следващите две години. Ще бъде ли достатъчно това развитие, за да даде възможност на обществените облаци да хостват чувствителна или регулирана информация през следващите две години? Много съмнително. Ще бъде ли достатъчна тази еволюция, за да разсее загрижеността на организации и потребители за това как доставчиците на услуги в облака боравят с техните данни? Вероятно. Облакът се развива бързо и все по-добре – бъдате търпеливи и усърдни.
Основите
Тук е даден кратък преглед на съществените елементи на облачния компютинг.
Засега специалистите по сигурност трябва най-малкото да имат добро, основно разбиране на облачния компютинг. Ако сте прекалено заети да гасите тактически пожари, за да сте придобили такова разбиране, трябва да намерите време, за да бъдете в крак с технологията. Добро начало е запознаването със стандартите.
Американският National Institute of Standards and Technology (NIST) дефинира облачния компютинг като съставен от пет съществени характеристики, три модела на услуги и четири модела на разгръщане.
Сред петте съществени характеристики, описани от NIST, най-важната е общият фонд на ресурсите и това, което разграничава облачния компютинг от предишните бизнес модели. Мислете за споделените ресурси като за жилище с много наематели, както го определят някои доставчици.
Най-същественото обещание на облачния компютинг е намаляванто на цените, което е само поради икономиите, дължащи се на мащаба поради споделените ресурси. За разлика от по-раншни бизнес модели, като хостване на услуги или доставчици на приложения като услуга (ASP), всички ресурси се споделят в облачния компютинг.
Забележете, че виртуализацията не е определяща характеристика на облачната обработка. Много често медиите слагат равенство между виртуализацията и облачния компютинг. Това е неправилно. Виртуализацията е технология, която предоставя възможности, често използвана в облачния компютинг, но тя не е еквивалентна на него. В действителност най-големият доставчик на облачен компютинг – Гугъл, не използва виртуализация на системите или машините (въпреки че използва виртуализация на приложенията и сториджа). Тя е избрала хоризонтално мащабиране чрез добавяне на стандартизирани сървъри.
В технологичния сектор ние обичаме съкращенията почти толкова, колкото и във военния сектор. Но някои съкращения са съществени за разбирането на облачния компютинг. “SPI” се отнася за трите модела на доставяне на услуги в облака – софтуера като услуга, платформата като услуга и инфрастриктурата като услуга. Тези три модела образуват „облачен стек“, като най-отгоре е софтуерът като услуга, а най-отдолу инфраструктурата като услуга. Тези три различни типа облачни услуги се разгръщат по четири различни модела, които са дефинирани от NIST като – частен облак, общностен облак, обществен облак и хибриден облак.
От гледна точка на сигурността е важно да се отбелжи, че когато една организация премине към облачния стек, тя губи оперативна гъвкавост и директен контрол върху сигурността. Един клиент на IaaS има много по-голям контрол върху конфигурациите си, действията си и сигурността си от клиент на SaaS. За някои потребители това е недостатък. Обаче за много организации относителната липса на оперативна гъвкавост в SaaS е предимство. Много компании се прехвърлят в облака точно поради тази липса на оперативна гъвкавост – доставчикът на услуги в облака е отговорен да осигурява почти всичко, с което изключително улеснява организациите да преминат към този нов бизнес модел.