Розуміння галузі: як розвиватиметься хмарна безпека у 2017 році?

Наступаючий рік обіцяє значне зростання для постачальників послуг громадських хмарних послуг та постачальників рішень Software-as-a-Service (SaaS). Для однієї з нових технологій на фундаментальному рівні, таких як розгортання мікросервісів та блокчейн, зокрема, є невикористані шляхи для інновацій. Але, мабуть, ще важливіше, що один із найбільш часто цитованих CIO блокаторів прийняття хмари (а саме безпека та безпека даних), нарешті, переходить на другий план, особливо для підприємств та середнього бізнесу.

Хоча аналітики сходяться на думці, що сьогодні більшість підприємств - включаючи сегменти підприємств та середніх розмірів - мають різні хмарні розгортання, вони також погоджуються, що більші організації повільно переносять основні робочі навантаження в хмару, головна причина - хмарна безпека та дані безпека. Це важливо для цих клієнтів не тільки через величезний обсяг даних, які ці організації мігруватимуть, але й тому, що проходження суворої перевірки відповідності та регуляторних норм, таких як Закон про переносність та підзвітність медичного страхування (HIPAA) та ISO 27001, є для них вирішальним. вести бізнес. Безпека є справжньою для цих CIO, і до недавнього часу вони просто не були достатньо надійними, щоб широко розповсюджувати хмару.

Але, за прогнозами аналітиків на 2017 рік, це все має змінитися. Хмарна безпека пройшла дуже довгий шлях в останньому півріччі, і, схоже, багато ІТ-фахівців і керівників службових служб погоджуються. Це означає, що аналітики прогнозують, що в 2017 році ми побачимо набагато більший обсяг хмарної інфраструктури та послуг із сектору підприємств.

Я провів інтерв'ю електронною поштою з Брайаном Келлі, головним співробітником служби безпеки відомого керованого постачальника хмарних технологій Rackspace, щоб дізнатися, що змінюється щодо безпеки хмари в майбутньому році, і щоб побачити, чи погоджується він з прогнозами цих аналітиків.

PCMag: Як саме Rackspace бачить свою роль порівняно з ІТ-персоналом своїх клієнтів, коли справа стосується безпеки та безпеки даних?

Брайан Келлі (BK): Ми бачимо прямі докази того, що клієнти приходять до хмари через безпеку, а не тікають від неї. За невеликими винятками, компанії просто не мають ресурсів та навичок, щоб ефективно захищати свої організації від більш складних та постійних загроз. Так само хмарні постачальники визнають, що майбутнє нашого бізнесу залежить від довіри та впевненості завдяки ефективній практиці безпеки. Незважаючи на збільшення інвестицій постачальників хмарних технологій у безпеку, захист організаційних активів завжди залишатиметься спільною відповідальністю. Хоча постачальник хмарних послуг безпосередньо відповідає за захист об'єктів, центрів обробки даних, мереж та віртуальної інфраструктури, споживачі також несуть відповідальність за захист операційних систем, додатків, даних, доступу та облікових даних.

Форестер ввів термін "нерівномірне рукостискання" стосовно цієї спільної відповідальності. В деяких аспектах споживачі вважають, що вони несуть на собі тягар безпеки своїх даних. Це, можливо, було правдою кілька років тому; однак ми спостерігаємо врівноваження рукостискання. Тобто постачальники хмарних послуг можуть і повинні зробити більше для того, щоб споживачі поділили відповідальність за безпеку. Це може мати форму простого забезпечення більшої видимості та прозорості розміщених робочих навантажень, надання доступу до контрольних літаків або пропонування керованих служб безпеки. Хоча обов'язки споживачів щодо безпеки ніколи не зникнуть, хмарні постачальники продовжуватимуть брати на себе більше відповідальності та надаватимуть пропозиції безпеки, керовані доданою вартістю, щоб створити довіру, необхідну обом сторонам для безпечної роботи в хмарі.

PCMag: Чи є якісь поради для ІТ-фахівців та бізнес-клієнтів щодо того, що вони можуть зробити, крім того, що постачає провайдер, щоб самостійно захистити свої хмарні дані?

BK: Вони повинні продовжувати впроваджувати найкращі практики безпеки у своїх анклавах. Їм потрібно відповідально сегментувати навантаження в анклаві, щоб обмежити коло компромісів, забезпечити належне забезпечення та виправлення середовищ робочого навантаження (операційні системи, контейнери, віртуальні локальні мережі), використання технологій зондування та відповіді на кінцевій точці та мережі (IDS / IPS, виявлення та обмеження зловмисного програмного забезпечення) та активне управління обліковими записами та доступом. Часто клієнти можуть включати ці послуги та технології у свої договори на використання хмарних ситуацій, але якщо ні, то споживач повинен переконатися, що це відбувається з їх боку.

PCMag: Одне ключове питання, яке ми бачили читачам, - це ефективна захист від масових атак Інтернет-речей (IoT) з розподілом відмови в обслуговуванні (DDoS), подібно до інциденту минулого жовтня, коли китайський постачальник IoT ненавмисно зробив великий внесок у напад. Чи працюють такі атаки з постачальниками Інтернет-провайдерів, що проходять раніше? І як вони перешкоджають нападу на одного клієнта, щоб не забирати всіх людей у ​​заклад?

BK: Основна мета захисту DDoS - підтримка доступності під час атаки. Можливості DDoS-атаки IoT добре відомі і їх можна успішно пом'якшити, застосовуючи кращі практики безпеки та використовуючи інтелектуальні системи пом'якшення DDoS. Найбільшою загрозою є не метод атак від IoT, а величезна кількість вразливих пристроїв з підтримкою Інтернету. Мережі потрібно заблокувати для обмеження впливу загроз в Інтернеті. Операторам мережі потрібно проявляти активність у виявленні всіх можливих загроз та знати найефективніші методи їх пом'якшення, зберігаючи при цьому можливість аналізу та класифікації всього мережевого трафіку.

Сильна стратегія пом'якшення рівня DDoS вимагає застосування багатошарового оборонного підходу. Велика кількість пристроїв IoT ускладнює пом'якшення IoT-атак для невеликих мереж. Ефективність атаки IoT полягає в її гнучкості для генерування різних векторів атак та отримання масового великого обсягу трафіку DDoS. Навіть найзапекліша мережа може швидко бути заполонена величезним обсягом трафіку, який IoT може генерувати в руках здібного нападника. Провідні провайдери часто краще обладнані та укомплектовані персоналом для боротьби з цими масштабними атаками, які швидко насичуватимуть невеликі мережеві зв’язки. Крім того, масштаб роботи мережі та інструменти, необхідні для пом’якшення таких атак, дозволяють ефективно виявляти та реагувати поза межами досяжності більшості організацій. Кращим рішенням є аутсорсинг таких операцій для початкових провайдерів хмарних провайдерів, які вже працюють з такою мережею.

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

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

Клацніть зображення для отримання повної інфографіки. Кредит зображення: Twistlock

PCMag: Ще одне запитання, яке задають нам читачі, стосується безпеки контейнерів. Чи хвилюєтесь ви про озброєні контейнери, які можуть містити складні атакуючі системи, чи ви думаєте, що архітектура захищає від подібних подвигів?

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

Контейнер, по суті, є дуже перехідним і легким, віртуалізованим середовищем операційної системи. Чи віртуальні машини менш безпечні, ніж окремі фізичні сервери? Вони в більшості випадків є. Однак багато підприємств бачать вигідну користь від віртуалізації (менше витрачають, простіше в управлінні, легко перенацілюють машини), і вони вирішують скористатись цим, зменшуючи якомога більше ризиків. Intel навіть зрозумів, що вони можуть допомогти зменшити деякі ризики, і саме звідси походить Intel VT.

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

Експерти Linux занепокоєні тим, що кожен контейнер ділиться ядром хоста, завдяки чому площа поверхні для експлуатації набагато більша, ніж традиційні технології віртуалізації, такі як KVM та Xen. Таким чином, є потенціал для нової атаки, в якій зловмисник хакує привілеї в одному контейнері, щоб отримати доступ або вплинути на умови всередині іншого контейнера.

У нас поки що не дуже багато в дорозі внутрішньо-контейнерних датчиків безпеки. На мою думку, ця сфера ринку повинна дозріти. Крім того, контейнери не можуть використовувати функції захисту, вбудовані в процесори (наприклад, Intel VT), які дозволяють виконувати код у різних кільцях залежно від рівня привілеїв.

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

Провайдер хостингу повинен використовувати модулі безпеки Linux (наприклад, SELinux або AppArmor) для ізоляції контейнерів, і за цією системою слід ретельно контролювати. Також важливо постійно оновлювати ядро ​​хоста, щоб уникнути місцевих подвигів ескалації привілеїв. Ізоляція унікального ідентифікатора (UID) також допомагає, оскільки вона не дозволяє кореневому користувачеві в контейнері фактично мати корінь на хості.

PCMag: Однією з причин PCMag.com не було проведено широкомасштабного порівняння постачальників керованих служб безпеки (MSSP) в тому, що в галузі існує плутанина щодо того, що саме означає цей термін, і що може пропонувати цей клас постачальника послуг. Чи можете ви порушити керовану службу безпеки Rackspace? Що це робиться, чим це відрізняється від інших провайдерів, і де ви бачите, що це відбувається, щоб читачі могли зрозуміти, що саме вони підписуються, коли використовують таку послугу?

BK: MSSP повинні визнати, що безпека не працює, і налагодити свою стратегію та операції, щоб бути ефективнішими в сьогоднішньому ландшафті загроз - який містить більш складних та наполегливих супротивників. У Rackspace ми визнали цю зміну загрози та розробили нові можливості, необхідні для їх зменшення. Безпека, керована Rackspace - це вдосконалена операція виявлення та реагування 24/7/365. Він був розроблений не тільки для захисту компаній від атак, але для мінімізації впливу на бізнес, коли трапляються напади, навіть після успішного злому середовища.

Щоб досягти цього, ми скоригували свою стратегію трьома способами:

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

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

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

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

PCMag: Rackspace є великим прихильником, дійсно заслуженим засновником, OpenStack. Деякі наші читачі ІТ запитують, чи розробка безпеки для такої відкритої платформи насправді повільніша і менш ефективна, ніж для закритої системи, таких як Amazon Web Services (AWS) або Microsoft Azure через сприйняту дилему "занадто багато кухарів", яка викликає занепокоєння. багато великих проектів з відкритим кодом. Як ви на це реагуєте?

BK: За допомогою програмного забезпечення з відкритим кодом «помилки» виявляються у відкритій спільноті та фіксуються у відкритій спільноті. Неможливо приховати ступінь або вплив проблеми безпеки. Завдяки власному програмному забезпеченню, ви вирішили виправити вразливості. Що робити, якщо вони не роблять нічого щодо вразливості протягом півроку? Що робити, якщо вони пропустять звіт дослідника? Ми бачимо всі ті "занадто багато кухарів", які ви називаєте величезними засобами забезпечення програмного забезпечення. Сотні розумних інженерів часто дивляться на кожну частину великого пакету з відкритим кодом, наприклад OpenStack, що ускладнює недоліки проскочити через щілини. Обговорення недоліку та оцінка варіантів його усунення відбувається відкрито. Приватні програмні пакети ніколи не можуть отримувати подібний аналіз на рівні коду на рівні коду, і виправлення ніколи не отримають такого відкритого перевірки.

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

Також спільноти з відкритим кодом швидко поширюють знання про ці вразливі місця безпеки. Питання "Як нам не допустити цього пізніше?" його швидко запитують, а роздуми проводяться спільно та відкрито.

PCMag: Закінчимо з початковим запитанням цього інтерв'ю: Чи згодні ви з аналітиками, що 2017 рік стане «проривним» у частині прийняття хмари підприємств, головним чином або принаймні частково через прийняття підприємством безпеки безпеки хмарного постачальника?

Б.К .: Давайте на мить відступимо, щоб обговорити різні хмарні середовища. Більшість ваших запитань вказує на суспільний ринок хмар. Як я вже згадував вище, дослідники Forrester відзначили «нерівномірне рукостискання» між хмарними постачальниками та споживачами, оскільки хмарні постачальники послуг надають набір послуг, але хмарні споживачі часто припускають, що вони отримують набагато більше в плані безпеки, резервного копіювання, стійкості, і т. д. Я виступав з моменту приєднання до Rackspace, щоб хмарові постачальники повинні навіть виправити це рукостискання, бути більш прозорими щодо наших споживачів. Ніде все ж рукостискання не є рівним, як і сьогодні, ніж у громадських хмарних умовах.

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

Але я не думаю, що це створить перешкоду хмарі в 2017 році. Переміщення робочих навантажень і цілих центрів обробки даних тягне за собою значні зміни в плануванні та організації. Це набагато відрізняється від оновлення обладнання в центрі обробки даних. Я закликаю ваших читачів вивчити перехід Netflix; вони перетворили свій бізнес, перемістившись у хмару, але на це знадобилося сім років наполегливої ​​праці. Для одного вони переосмислили і переписали більшість своїх додатків, щоб зробити їх більш ефективними та краще адаптуватися до хмари.

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