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

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

Щодня хакери обходять периметри безпеки, перетинають довільні межі й оминають рішення безпеки, щоб зрештою непомітно отримати потрібні їм дані. Josh Stella, головний архітектор Snyk і засновник та генеральний директор Fugue — SaaS-компанії, що спеціалізується на хмарній безпеці, — пояснює, чому керівникам варто просити фахівців із безпеки розповісти їм про робоче хмарне середовище, щоб обґрунтувати інвестиції в безпеку перед усіма командами.

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

1. Наскільки наше хмарне середовище не відповідає вимогам?

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

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

2. Скільки вразливостей ми виявили й усунули?

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

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

3. Скільком вразливостям ми завадили потрапити в розгортання?

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

4. Чи інтегрувала ваша команда безпеку в конвеєри безперервної інтеграції та безперервної доставки (CI/CD)?

Чи перевіряє ваша команда інфраструктуру як код (спосіб програмного створення й розгортання хмарної інфраструктури), щоб виявляти й виправляти неправильні конфігурації до розгортання — тоді, коли це швидше, простіше й безпечніше? Якщо відповідь «ні», можливо, інфраструктуру як код і конвеєри CI/CD ще не впроваджено. Якщо ж їх використовують, має бути принаймні план забезпечення безпеки цих процесів.

5. Чи захищаємо ми площину керування хмарним API?

Усі злами хмарних середовищ відбуваються за однією схемою: компрометація рівня керування. Інтерфейси прикладного програмування (API) — рушійна сила хмарних обчислень; уявляйте їх як «програмних посередників», які дають змогу різним програмам взаємодіяти між собою. Площина керування API — це набір API, які використовують для налаштування й експлуатації хмарного середовища.

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

Щоб оцінити ризик будь-якого потенційного проникнення через неправильні конфігурації, вразливості програм, ключі API у вихідному коді тощо, потрібен досвід у проєктуванні хмарної безпеки. Він допомагає виявляти й уникати прорахунків у конструкції, якими зловмисники користуються щодня. Хмарна безпека — це знання, а прогалини виникають, коли захисники не мають повного уявлення про своє середовище й не можуть завадити зловмисникам виявляти ці прогалини.

6. Наскільки безпека знижує продуктивність?

Хмара означає швидкість інновацій, а безпека — головний чинник, який обмежує швидкість роботи команд і впливає на успіх цифрової трансформації. Чи чекають розробники програм на інфраструктуру, яку їм потрібно розгорнути? Чи чекають команди DevOps, поки служба безпеки перевірить і схвалить їхню інфраструктуру? Чи витрачають ваші хмарні інженери забагато часу на трудомісткі ручні завдання із забезпечення безпеки та відповідності вимогам, хоча могли б приносити більше користі вашій компанії та клієнтам? Регулярне оцінювання пропускної здатності розробників і команд DevOps допоможе виявити затримки через неналежні процеси безпеки, що знижують продуктивність і моральний дух.

7. У якому вигляді ми формулюємо політику безпеки?

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

8. Наскільки швидко ми можемо реагувати на вразливості нульового дня?

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

9. Чи мають усі команди все необхідне для успіху?

У сучасній корпоративній безпеці немає ізольованих сховищ. Для забезпечення безпеки потрібен інтегрований підхід, який об’єднує команди й центри витрат, а також керівництво та підтримка керівників, щоб усе робилося як слід. Наприклад, підхід shift-left до безпеки передбачає, що розробники й команди DevOps беруть на себе певну відповідальність за пошук і усунення проблем на ранніх етапах життєвого циклу розробки програмного забезпечення. Але якщо інвестиції в безпеку не враховуватимуть ці нові пріоритети, виникнуть розбіжності, які зведуть нанівець усі зусилля.