Я колись жартувала, що не маю дозволу на свою роботу, але цей жарт був недалеким від правди. Я працювала розробником у суворо регульованій енергетичній галузі. Системи, з якими працював мій код, обробляли мільярди доларів на місяць.
«У нас серйозна проблема у виробництві. Можете подивитися, що не так?» Я чула цю фразу кожні кілька місяців і знизувала плечима, відповідаючи: «Ви можете відтворити транзакцію, яка викликає проблеми, у нашому тестовому середовищі? Я не маю доступу, необхідного для налагодження у виробничому середовищі».
На той час я категорично не погоджувалася з таким жорстким контролем, оскільки відчувала себе безсилою вирішити проблеми, що стояли переді мною, але з часом я почала розуміти логіку такого підходу. Коли на кону стоять такі великі гроші, зменшення навіть найменшого ризику за будь-яку ціну – навіть якщо ці критичні хвилини коштують компанії незліченні суми – є цілком логічним з точки зору бізнесу. Вартість потенційної невдачі перевищувала вартість затримки.
… ми прагнемо створити той безпроблемний досвід, якого так прагнуть розробники…
Проте я мріяла про світ, де не доводилося б жертвувати продуктивністю заради безпеки. Delinea прагне створити той безпроблемний досвід, якого так прагнуть розробники, одночасно забезпечуючи безпеку їхніх ідентичностей, що дозволяє бізнесу інноваційно розвиватися та процвітати.
У цьому блозі ви дізнаєтеся, як захистити та керувати ідентифікаційними даними розробників – людей, відповідальних за розробку. У рамках співпраці з розробниками в галузі безпеки також варто врахувати нелюдські, машинні ідентичності, які розробники можуть створювати та використовувати у своїй роботі.
Чому ідентифікаційні дані розробників є такими ризикованими?
Ідентифікаційні дані розробників — це ідентичності людей, які зазвичай мають особливі привілеї. Розробники відіграють вирішальну роль в управлінні та вдосконаленні критично важливих систем та інфраструктури, що робить їх привабливою мішенню для зловмисників.
Серед чотирьох типів ідентичностей у вашій поверхні атаки на ідентичність ідентичності розробників є найбільш складними, оскільки вони мають спільні характеристики з іншими трьома типами. Як і ІТ-адміністратори, вони мають високий рівень привілеїв і технічних навичок. Як і ідентичності співробітників, їхня продуктивність дуже цінується, а дистанційна робота та залучення третіх сторін є поширеною практикою. Додайте до цього той факт, що розробники мають доступ до машинних ідентичностей і часто їх створюють.
Це потужна комбінація факторів, яка повинна поставити ідентичності розробників на перше місце у вашому списку пріоритетів.
Ідентифікаційні дані розробників важко захистити з кількох причин:
- Розробники зосереджуються на ефективності, щоб швидко випустити код і запустити програмне забезпечення, що часто має пріоритет над безпекою. Вони не хочуть чекати на затвердження, щоб отримати підвищені привілеї. Вони воліють мати постійні привілеї, щоб працювати у зручний для них час.
- Як висококваліфіковані технічні експерти, розробники можуть бути незалежними; вони часто використовують програми, які можуть бути невідомі центральному ІТ-відділу, або знаходять обхідні шляхи для встановлених процесів безпеки.
- Окрім внутрішніх команд штатних співробітників, розробка часто передається на аутсорсинг третім сторонам, особливо в періоди інтенсивного виробництва або реалізації нових ініціатив. Ці команди отримують віддалений доступ до критично важливих систем і конфіденційних даних. Зазвичай вони працюють у групах, що може призвести до спільного використання облікових даних або привілейованих облікових записів.
- Розробники мають доступ до конфіденційних даних, часто захищених персональних даних та даних клієнтів. Вони працюють не тільки в виробничих середовищах, але й у середовищах розробки та тестування. Крім того, розробники також використовують сторонні репозиторії, такі як GitHub, де часто можна забути облікові дані.
Щоб отримати повне уявлення про схильність до ризиків та усунути прогалини, керівники служб безпеки повинні враховувати особливі потреби розробників, інтегруючи цю спільноту в централізовано керовані процеси.
Як можна захистити ідентифікаційні дані розробників?
1. Виявлення та інвентаризація
Завдяки безперервному виявленню, вбудованому в програму захисту ідентифікаційних даних, ви можете знаходити та класифікувати всі привілейовані облікові записи та пов’язані з ними секретні дані, дозволи та правила MFA у всіх локальних, хмарних і програмних середовищах.
Це гарантує, що всі посвідчення розробників, які працюють у вашому розширеному ІТ-середовищі, враховуються, що зменшує ризик появи некерованих або занедбаних облікових записів, які можуть бути використані зловмисниками.
Оскільки створюються нові ідентифікаційні дані та облікові записи, а дозволи часто змінюються, постійне виявлення гарантує, що ви завжди маєте найновішу інформацію та статус.
2. Захищені облікові дані
Централізоване зберігання та ротація облікових даних дозволяють уникнути використання статичних секретів, які використовуються ідентифікаторами людей та машин. Розробники, включаючи віддалених працівників та сторонніх осіб, повинні мати можливість легко використовувати те саме зашифроване сховище корпоративного рівня, що й решта співробітників підприємства, для динамічного оновлення паролів, усуваючи типові вразливості, такі як статичні та спільні облікові дані.
Переконайтеся, що ви можете пов’язати права доступу та поведінку з унікальними ідентифікаторами розробників, а не зі спільними привілейованими обліковими записами.
Централізовані корпоративні сховища також підтримують робочі процеси розробників, зберігаючи та керуючи обліковими даними, що використовуються службовими обліковими записами, ідентифікаторами машин та штучним інтелектом, включаючи ключі SSH, токени та сертифікати.
3. Привілейований безпечний доступ
Забезпечте автентифікацію та авторизацію всіх комунікацій між розробниками та машинами, а також між машинами за допомогою детального контролю доступу, що дозволяє здійснювати лише легітимні взаємодії.
Контекстно-залежна багатофакторна автентифікація (MFA) є важливим засобом безпеки для захисту ідентичності розробників. Хоча MFA забезпечує додатковий захист ідентичності від цілеспрямованих атак, розробники можуть відчувати втому від MFA – так само, як і всі інші співробітники вашої організації! Завдяки контекстній MFA ви можете вибирати, коли додавати рівні захисту для систем або дій з високим рівнем ризику.
Привілейований безпечний доступ – це не підхід, який можна налаштувати один раз і забути, особливо якщо мова йде про ідентифікацію розробників. Розробники можуть часто змінювати проєкти, що вимагає від них доступу до різних систем і даних. Такі умови роблять статичні політики доступу, навіть політики на основі ролей, недостатніми. На відміну від фіксованих ролей, інтелектуальна авторизація є динамічною і базується на контексті, включаючи зміну моделей поведінки та оцінки ризиків.
4. Прийняття принципу нульових постійних привілеїв (ZSP)
Цей компонент безпеки ідентичності гарантує, що ідентичності розробників працюють із стандартним доступом, доки не знадобиться більше. Замість постійних привілеїв розробникам надаються підвищені дозволи за принципом just-in-time, just-enough.
Завдяки впровадженню нульових постійних привілеїв (ZSP), найкращі практики безпеки дотримуються без перешкоджання творчому та продуктивному процесу розробників.
Навіть якщо ідентичність розробника буде скомпрометована, ZSP мінімізує радіус ураження та наслідки, оскільки підвищення привілеїв та бічні переміщення обмежені.
5. Аналіз стану ідентифікації та загроз
В якості превентивних заходів контролю аналіз стану ідентифікації та загроз допомагає виявляти поширені помилки налаштування ідентифікації, такі як відсутність MFA, і розуміти пов’язані з ними ризики.
Крім того, аудит і моніторинг ідентифікаційних даних, доступу та поведінки розробників створюють систему раннього попередження, яка дає вам час для вжиття заходів до того, як невелика проблема перетвориться на катастрофу.
Отримавши базові дані про типову поведінку розробників, ви зможете виявляти ознаки потенційного порушення безпеки або внутрішньої загрози, наприклад, доступ розробника до конфіденційних даних у незвичайний час або створення ним облікового запису з прихованим доступом.
Виявлення загроз може навіть повідомити вам, якщо атака MFA-бомбардування надсилає запити один за одним одному з ваших розробників. Тоді ви зможете втрутитися, перш ніж вони випадково приймуть запит і відкриють двері для атаки.
Ви можете повідомити про це свою команду з безпеки, щоб вона могла перевірити сигнали про загрози в відповідному контексті, або навіть увімкнути автоматичні дії, такі як застосування додаткових рівнів багатофакторної автентифікації (MFA) або повне скасування привілейованого доступу для ідентифікатора розробника.
6. Управління життєвим циклом ідентифікаційних даних
Ручне надання, скасування доступу та постійне управління ідентифікаційними даними розробників є трудомістким процесом, що супроводжується ризиком людських помилок.
Автоматизація спрощує процеси управління ідентифікаційними даними розробників, такі як затвердження прийняття, переведення та звільнення співробітників (JML) та перевірка доступу. Це зменшує адміністративні витрати та забезпечує дотримання політик безпеки та нормативних вимог.
Крім того, ви можете автоматизувати робочі процеси, пов’язані з розробниками, включаючи такі процеси, як надання та скасування доступу до облікових записів, введення секретних даних та управління змінами, такими як інфраструктура як код.
Захист особистостей розробників за допомогою платформи Delinea

Платформа Delinea забезпечує безперебійну централізовану авторизацію для управління доступом розробників за допомогою інтелектуальних засобів контролю на основі політик.
Замість розрізнених рішень, керованих різними командами і розрізненими даними, ви можете захистити ідентифікаційні дані розробників і керувати їхнім доступом за допомогою тієї самої платформи, що захищає й ідентифікаційні дані працівників, ІТ-адміністраторів, машин і ШІ.
Це означає, що ви можете отримати повний огляд усіх ідентичностей, що діють у вашому середовищі, та цілісне уявлення про ризики безпеки ідентичностей.
Джерело: Securing developer identities: A frictionless experience
