Хмари: легенди і міфи

 

Коли Ерік Шміт, нині глава Google, вперше вжив термін "хмара" по відношенню до розподіленої обчислювальної веб-системі він навряд чи здогадувався, що це одне з тих слів, які часто зустрічаються в легендах. Практично у всіх міфах народів світу божественні істоти живуть дуже близько до неба – на хмарах. У результаті, термін "хмарні обчислення" дуже сподобався маркетологам, оскільки дає простір для творчості. Спробуємо і ми вербалізувати ці міфи, і зрозуміти наскільки вони органічно поєднуються з ІТ.


Смерть Мерліна


Одним з персонажів циклу легенд про короля Артура і його Круглому столі є маг і чарівник Мерлін, який допомагав Артуру в його правлінні. Показово, що скінчив Мерлін тим, що був заточений у хмарах. Він, бажаючи похвалитися перед молодою чарівницею і показати свою магічну силу, побудував замок із хмар і запропонував своїй пасії його оглянути. Однак чарівниця виявилася хитра і заточила мага в його власному хмарному замку. Після цього Мерліна вже ні хто не бачив, тому вважається, що він помер десь там – у збудованому ним же самим хмарному замку.


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


Спочатку хмара було тільки одне – саме цим символом традиційно позначали мережу Інтернет. Ця хмара позначало сукупність всіх комп'ютерів, об'єднаних протоколом IP і мають власну IP-адресу. З часом в Інтернет почали виділяти серверні ферми, які встановлювалися у провайдерів і на яких базувалися веб-проекти. При цьому для забезпечення високого навантаження і відмовостійкості найбільш великі веб-системи ставали багаторівневими і розподіленими.


У типовій такій системі можна було виділити наступні рівні: зворотний проксі, що виконує також роль балансувальникам навантаження і дешифратора SSL, власне веб-сервер, далі сервер додатків, СУБД і систему зберігання. При цьому на кожному рівні могло бути кілька елементів, що виконують однакові функції, і тому не завжди було зрозуміло які саме компоненти використовуються для обробки користувальницьких запитів. А коли незрозуміло, то це і є хмари. Тому почали говорити, що користувацькі запити виконуються де-то в "хмарі" з великої кількості серверів. Так і з'явився термін "хмарні обчислення".


Хоча спочатку хмарні обчислення були пов'язані з загальнодоступними веб-проектами – порталами, проте у міру розвитку розподілених відмовостійких веб-систем їх почали використовувати і для вирішення внутрішньокорпоративних завдань. Це був час буму на корпоративні портали, які були засновані на веб-технологіях, відпрацьованих у публічних системах. У той же час корпоративні системи почали консолідуватися в центри обробки даних, які було простіше і дешевше обслуговувати.


Однак виділяти на кожен елемент хмари окремий сервер була б неефективно – не всі елементи хмари навантажені однаково, тому паралельно почала розвиватися індустрія віртуалізації. У публічних хмарах вона виявилася досить популярною, оскільки дозволила розмежовувати права доступу і забезпечувала швидке перенесення елемента розподіленої системи на інший апаратний носій. Без віртуалізації хмарні обчислення були б менш динамічними і масштабованими, тому зараз хмари, як правило, складаються з віртуальних машин.


Хмарні обчислення в основному пов'язують з орендою додатків, визначаючи три типи таких послуг: IaaS – інфраструктура як сервіс, PaaS – платформа як сервіс і SaaS – програмне забезпечення як сервіс. Іноді й послуги "безпека як сервіс" також скорочують до SaaS, проте, щоб не плутати хмарні послуги безпеки з орендою ПО краще називати її ISaaC – Information Security as a Cloud. Такі послуги також починають надаватися. Однак не слід плутати аутсорсинг додатків і хмарні обчислення, оскільки хмари можуть бути внутрішньокорпоративні, публічні та гібридні. У кожного з цих типів хмар є свої особливості при організації системи захисту.


Три кроки Вішну


Бог Вішну в індуїстській міфології відомий тим, що саме він завоював простір для життя людей за допомогою трьох кроків: перший був зроблений на землі, другий – у хмарах, а третім – у вищій обителі. У Відповідно до "Ріг-Веда" саме цим дією Вішну відвоював всі ці простори для людей.


Сучасні ІТ також роблять аналогічний "другий крок" – із землі в хмари. Однак, щоб з цих хмар не звалитися ще на землі варто подбати про безпеку. У першій частині я так докладно розібрав структуру хмари для того, щоб було зрозуміло які загрози існують для хмарних обчислень. З описаного вище слід виділити наступні класи загроз:




  • Традиційні атаки на ПЗ. Вони пов'язані з уразливістю мережевих протоколів, операційних систем, модульних компонент і інших. Це традиційні загрози, для захисту від яких досить встановити антивірус, міжмережевий екран, IPS та інші обговорювані компоненти. Важливо тільки, щоб ці засоби захисту були адаптовані до хмарної інфраструктурі і ефективно працювали в умовах віртуалізації.



  • Функціональні атаки на елементи хмари. Цей тип атак пов'язаний з багатошаровістю хмари, загальним принципом безпеки, що загальна захист системи дорівнює захисту найслабшої ланки. Так успішна DoS-атака на зворотний проксі, встановлений перед хмарою, заблокує доступ до всього хмари, не дивлячись на те, що всередині хмари всі зв'язки будуть працювати без перешкод. Аналогічно SQL-ін'єкція, що пройшла через сервер додатків дасть доступ до даних системи, не залежно від правил доступу в шарі зберігання даних. Для захисту від функціональних атак для кожного шару хмари потрібно використовувати специфічні для нього засоби захисту: для проксі – захист від DoS-атак, для веб-сервер – Контроль цілісності сторінок, для сервера додатків – екран рівня додатків, для шару СУБД – захист від SQL-ін'єкцій, для системи зберігання – резервне копіювання і розмежування доступу. Окремо кожні з цих захисних механізмів вже створені, але вони не зібрані разом для комплексного захисту хмари, тому завдання щодо інтеграції їх в єдину систему потрібно вирішувати під час створення хмари.



  • Атаки на клієнта. Цей тип атак відпрацьований у веб-середовищі, але він також є актуальним і для хмари, оскільки клієнти підключаються до хмари, як правило, за допомогою браузера. У неї потрапляють такі атаки як Cross Site Scripting (XSS), перехоплення веб-сесій, злодійство паролів, "людина посередині" та інші. Захистом від цих атак традиційно є сувора аутентифікації і використання шифрованого з'єднання із взаємною аутентифікацією, проте не всі творці "хмар" можуть собі дозволити настільки марнотратні і, як правило, не дуже зручні засоби захисту. Тому в цій галузі інформаційної безпеки є ще невирішені завдання і простір для створення нових засобів захисту.



  • Загрози віртуалізації. Оскільки платформою для компонент хмари традиційно є віртуальні середовища, то атаки на систему віртуалізації також загрожують і всьому хмарі в цілому. Цей тип загроз унікальний для хмарних обчислень, тому його ми докладно розглянемо нижче. Зараз починають з'являтися рішення для деяких загроз віртуалізації, однак галузь ця досить нова, тому поки що склалися рішень поки що не вироблено. Цілком можливо, що ринок інформаційної безпеки найближчим часом буде виробляти засоби захисту від цього типу загроз.



  • Комплексні загрози "хмарам". Контроль хмар і управління ними також є проблемою безпеки. Як гарантувати, що всі ресурси хмари пораховані і в ньому немає непідконтрольних віртуальних машин, не запущено зайвих бізнес-процесів і не порушена взаємна конфігурація шарів та елементів хмари. Цей тип загроз пов'язаний з керованістю хмарою як єдиної інформаційної системою і пошуком зловживань або інших порушень в роботі хмари, які можуть призвести до зайвих витрат на підтримку працездатності інформаційної системи. Наприклад, якщо є хмара, що дозволяє по представленому файлу детектувати в ньому вірус, то як запобігти крадіжкам подібних детектив? Цей тип загроз найбільш високорівнева і, я підозрюю, що для нього неможливо універсального засобу захисту – для кожного хмари її загальну захист потрібно будувати індивідуально. Допомогти в цьому може найбільш загальна модель управління ризиками, яку потрібно ще правильно застосувати для хмарних інфраструктур.


Перші два типи загроз вже достатньо вивчені і для них вироблені засоби захисту, проте їх ще потрібно адаптувати для використання в хмарі. Наприклад, міжмережеві екрани призначені на захисту периметра, проте в хмарі непросто виділити Edge для окремого клієнта, що значно ускладнює захист. Тому технологію міжмережевого екранування потрібно адаптувати до хмарної інфраструктурі. Роботу в цьому напрямку зараз активно веде, наприклад, компанія Check Point.


Новим для хмарних обчислень типом загроз є проблеми віртуалізації. Справа в тому, що при використанні цієї технології в системі з'являються додаткові елементи, які можуть бути піддані атаці. До них можна віднести гіпервізор, систему перенесення віртуальних машин з одного вузла на інший і систему управління віртуальними машинами. Розглянемо докладніше, яким же атакам можуть піддатися перераховані елементи.




  • Атаки на гіпервізор. Власне ключовим елементом віртуальної системи є гіпервізор, який забезпечує поділ ресурсів фізичного комп'ютера між віртуальними машинами. Втручання в роботу гіпервізора може привести до того, що одна віртуальна машина може отримати доступ до пам'яті і ресурсів іншого, перехоплювати її мережевий трафік, відбирати її фізичні ресурси і навіть зовсім витіснити віртуальну машину з сервера. Поки що мало хто з хакерів розуміє, як саме працює гіпервізор, тому атак подібного типу практично немає, однак це ще не гарантує, що вони не з'являться в майбутньому.



  • Перенесення віртуальних машин. Слід зазначити, що віртуальна машина являє собою файл, який може бути запущений на виконання в різних вузлах хмари. У системах управління віртуальними машинами передбачені механізми переносу віртуальних машин з одного вузла на інший. Однак файл віртуальної машини можна і взагалі вкрасти і спробувати запустити її за межами хмари. Винести фізичний сервер з ЦОДа неможливо, а ось віртуальну машину можна вкрасти по мережі, не маючи фізичного доступу до серверів. Правда, окрема віртуальна машина за межами хмари не має практичної цінності – красти треба як мінімум по одному віртуальному машині з кожного шару, а також дані з системи зберігання для відновлення аналогічного хмари, тим не менш, віртуалізація цілком допускає злодійство частин або всього хмари цілком. Тобто втручання в механізми перенесення віртуальних машин породжує нові ризики для інформаційної системи.



  • Атаки на системи управління. Величезна кількість віртуальних машин, які використовуються в хмарах, особливо в публічних хмарах, вимагає таких систем управління, які могли б надійно контролювати створення, перенесення і утилізацію віртуальних машин. Втручання в системи управління може призвести до появи віртуальних машин невидимок, блокування одних машин і підстановка в шари хмари неавторизованих елементів. Все це дозволяє зловмисникам отримувати інформацію з хмари або захоплювати його частини або всі хмара цілком.


Слід зазначити, що поки всі перераховані вище загрози є суто гіпотетичними, оскільки відомостей про реальні атаках цього типу практично немає. У той же час, коли віртуалізація і хмари стануть досить популярними, всі ці типи нападів можуть виявитися цілком реальними. Тому їх варто мати на увазі ще на етапі проектування хмарних систем.


За сьомим небом


Апостол Павло стверджував, що знав людину, який був захоплений на сьоме небо. З тих пір словосполучення "сьоме небо" міцно закріпилося для позначення раю. Втім, далеко не всі християнські святі сподобилися побувати навіть на першому небі, тим не менше, немає такої людини, який не мріяв би хоч одним оком поглянути на сьоме небо.


Можливо, саме ця легенда і надихнула творців компанії Trend Micro назвати один зі своїх проектів із захисту хмар Cloud Nine – дев'яте хмара. Це ж явно вище сьомого. Втім, зараз цим ім'ям названі найрізноманітніші речі: пісні, детективи, комп'ютерні ігри, однак цілком можливо, що це ім'я було навіяно християнської легендою Павла.


Втім, поки компанія Trend Micro опублікувала тільки відомості про те, що Cloud Nine буде пов'язаний з шифруванням даних в хмарі. Саме шифрування даних і дозволяє захиститися від більшості загроз даними в публічному хмарі, тому подібні проекти зараз будуть активно розвиватися. Давайте пофантазуємо, які інструменти захисту ще можуть стати в нагоді для зниження описаних вище ризиків.


У першу чергу потрібно забезпечити надійну аутентифікацію, як користувачів хмари, так і його компонентів. Для цього можна, швидше за все, застосовувати вже готові системи одноразової аутентифікації (SSO), які базуються на Kerberos і протокол взаємної аутентифікації обладнання. Далі будуть потрібні системи управління ідентифікаційної інформацією, які дозволяють налаштовувати права доступу користувачів до різних систем за допомогою рольового управління. Звичайно, доведеться повозитися з визначенням ролей і мінімальних прав для кожної ролі, але, один раз настроївши систему, її можна буде експлуатувати досить довго.


Коли всі учасники процесу та їх права визначені потрібно стежити за дотриманням цих прав і виявленням помилок адміністрування. Для цього потрібні системи обробки подій від засобів захисту елементів хмари і додаткових захисних механізмів, таких як міжмережеві екрани, антивіруси, IPS та інші. Правда, варто використовувати ті їх варіанти, які можуть працювати в середовищі віртуалізації – це буде ефективніше.


Крім того, варто також використовувати яку-небудь фрод-машину, яка дозволяла б виявляти шахрайство у використанні хмар, тобто знизити найскладніший ризик втручання в бізнес-процеси. Щоправда, зараз на ринку, швидше за все, немає фрод-машини, яка дозволяла працювати з хмарами, тим не менш, технології виявлення випадків шахрайства та зловживання вже відпрацьовані для телефонії. Оскільки в хмарах доведеться впроваджувати білінгову систему, то і фрод-машину до неї варто приєднати. Таким чином, можна буде хоча б контролювати загрози для бізнес-процесів хмари.


Які ж ще захисні механізми можна використовувати для захисту хмар? Питання поки що залишається відкритим.

Схожі статті:


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

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*