Минулого місяця я написав Стаття про те, як платформи з низьким кодом/без коду пропонують спільний доступ до облікових даних як послугу, чому вони це роблять і як це виглядає з точка зору зловмисника. У цій статті я зосереджуся на наслідках цього компромісу та на тому, як він впливає на сучасні підприємства.
Ось чому ділитися своїми корпоративними обліковими даними з кимось іншим є поганою практикою. Скажімо, я хочу передати свої облікові дані колезі, щоб запитати робочі журнали для одноразового аналізу поведінки користувачів. У типовому підприємстві надання комусь дозволу на запит до нового джерела даних може означати тривалий процес перевірки доступу, особливо коли йдеться про виробничі або конфіденційні дані. Мій колега міг легко розчаруватися. «Все, що я хотів, це зробити цей маленький одноразовий запит, і я вже чекав місяць!» вони могли сказати. Я міг би просто запустити для них запит, але я перевантажений своїми повсякденними завданнями, а одноразові запити стають складнішими.
У мене є одне швидке рішення: я можу просто поділитися своїм ім’ям користувача/паролем зі своїм колегою. Якщо вони отримають виклик МЗС, я з радістю схвалю. Мені не потрібно витрачати час на виконання запиту, а мій колега розблокується. Всі виграють! правильно?
Що ж, ви мали б рацію у своєму аналізі, але ви втрачаєте ширшу картину. Хоча для підприємства важливо, щоб ваш колега провів аналіз поведінки користувачів, так само, якщо не більше, важливо, щоб ваше підприємство дотримувалося низки стандартів конфіденційності та безпеки та зберігало довіру клієнтів, дотримуючись зобов’язань компанії щодо безпеки .
Якщо корпоративні цілі високого рівня вас не переконують, подумайте про центральні команди управління ІТ або безпеки. Ці команди базують свої операції та стратегії безпеки на тому факті, що кожен користувач має власну унікальну ідентифікацію. ІТ-групи встановлюють мережеві політики та політики доступу, які передбачають, що кожен користувач буде входити в систему з однієї корпоративної IP-адреси або корпоративного ноутбука одночасно; групи безпеки корелюють події на основі ідентифікатора користувача; фінансові команди могли б агрегувати звіти про витрати для кожного користувача та свого персонального хмарного середовища. Спільне використання облікових даних підриває всі ці припущення, зокрема. Це позбавляє основного значення онлайн-ідентичності.
Приклад із реального світу
Давайте повернемося до світу низького/без коду та розглянемо реальний сценарій. У великому підприємстві Джейн, натхненна співробітниця з команди обслуговування клієнтів, зрозуміла, що коли працівники всієї організації беруть участь у розгляді клієнтської справи, вони зазвичай не мають ключової інформації про клієнта, такої як історія його звернень у службу підтримки та останні покупки. Це погіршує досвід клієнта, оскільки йому доводиться пояснювати свою проблему знову і знову, поки справа перенаправляється до потрібного працівника, який може вирішити проблему.
Щоб покращити це, Джейн створила додаток, який дозволяє співробітникам компанії переглядати цю ключову інформацію про клієнтів, коли ці співробітники є частиною команди, відповідальної за розгляд запитів клієнтів у службу підтримки. По-перше, давайте визнаємо силу низького/без коду, який дозволяє Джейн визначити потребу та вирішити її самостійно, не вимагаючи бюджету та не чекаючи виділення ІТ-ресурсів.
Під час створення програми Джейн довелося вирішити кілька проблем, найбільшою з яких були дозволи. Співробітники всієї організації не мають прямого доступу до бази даних клієнтів, щоб отримати потрібну інформацію. Якби вони це зробили, то Джейн не потрібно було б створювати цю програму. Щоб подолати цю проблему, Джейн увійшла в базу даних і вбудувала свій автентифікований сеанс безпосередньо в додаток. Коли програма отримує запит від одного користувача, вона використовуватиме ідентифікатор Джейн для виконання цього запиту, а потім повертає результати користувачеві. Ця функція вбудовування облікових даних, як ми досліджували минулого місяця, є ключовою особливістю платформ з низьким кодом/без коду. Джейн переконалася, що налаштувала керування доступом на основі ролей (RBAC) у програмі таким чином, щоб кожен користувач міг отримати доступ лише до заяв клієнтів, які йому призначені.
Програма вирішила важливу бізнес-проблему, тому її швидко прийняли користувачі в усьому підприємстві. Люди були щасливі, що вони могли надавати кращі послуги своїм клієнтам, маючи правильний контекст для розмови. Клієнти теж були задоволені. Через місяць після того, як Джейн створила додаток, ним уже користуються сотні користувачів у всій організації, а рівень задоволеності клієнтів зростає.
Тим часом у SOC було викликано сповіщення високого рівня серйозності, яке демонструє аномальну активність навколо робочої бази даних клієнтів, і було призначено Емі, досвідченому аналітику безпеки. Початкове розслідування Емі показало, що внутрішній користувач намагався отримати всю базу даних, запитуючи інформацію про кількох клієнтів із кількох IP-адрес у всій організації. Шаблон запиту був дуже складним; замість простого шаблону перерахування, який ви очікуєте побачити під час збирання бази даних, дані того самого клієнта запитувалися кілька разів, іноді через різні IP-адреси та в різні дати. Чи може це бути зловмисником, який намагається ввести в оману системи моніторингу безпеки?
Після швидкого розслідування Емі виявила важливу інформацію: усі ці запити за всіма IP-адресами та датами використовували одну особу користувача, когось на ім’я Джейн з команди обслуговування клієнтів.
Емі звернулася до Джейн, щоб запитати її, що відбувається. Спочатку Джейн не знала. Її облікові дані вкрали? Вона натиснула не те посилання чи довірилася не тій вхідній електронній пошті? Але коли Джейн розповіла Емі про програму, яку вона нещодавно створила, вони обидві зрозуміли, що між ними може бути зв’язок. Емі, аналітик SOC, не була знайома з низьким кодом/без кодування, тому вони звернулися до команди AppSec. За допомогою Джейн команда з’ясувала, що програма Джейн містить облікові дані Джейн. З точки зору бази даних, програми не було — була лише Джейн, яка виконувала купу запитів.
Джейн, Емі та команда AppSec вирішили закрити програму, доки не буде знайдено рішення. Користувачі програми в усій організації були розчаровані, оскільки почали покладатися на неї, і клієнти теж це відчули.
У той час як Емі закрила проблему та задокументувала свої висновки, віце-президент із обслуговування клієнтів був незадоволений зниженням рівня задоволеності клієнтів, тому вони попросили Джейн знайти постійне рішення. За допомогою документації платформи та команди Центру передового досвіду організації Джейн видалила свою вбудовану особу з програми, змінила програму на використання ідентифікації кожного користувача для запитів до бази даних і переконалася, що користувачі отримують дозволи лише на випадки клієнтів, з якими вони пов’язані. . У своїй новій покращеній версії програма використовувала ідентифікаційні дані кожного користувача для запиту до бази даних клієнтів. Джейн і користувачі програми були щасливі, що програма повернулася в Інтернет, Емі та команда AppSec були раді, що особу Джейн більше не розкривають, а підприємство помітило, що рівень задоволеності клієнтів знову почав зростати. Все було добре.
Через два тижні SOC отримав ще одне сповіщення про ненормальний доступ до бази даних клієнтів виробництва. Воно виглядало підозріло схожим на попереднє сповіщення в тій самій базі даних. Знову ж таки, IP-адреси з усієї організації використовували ідентифікатор одного користувача для запиту до бази даних. Знову ж таки, цим користувачем була Джейн. Але цього разу команда безпеки та Джейн знали, що програма використовує ідентифікаційні дані своїх користувачів. Що відбувається?
Розслідування показало, що оригінальний додаток мав неявно поділилися Автентифікований сеанс бази даних Jane із користувачами програми. Поділившись програмою з користувачем, цей користувач отримав прямий доступ до зв'язку, обгортка навколо автентифікованого сеансу бази даних, надана платформою з низьким кодом/без коду. Використовуючи це з’єднання, користувачі могли безпосередньо використовувати автентифікований сеанс — їм більше не потрібно було використовувати програму. Виявилося, що кілька користувачів дізналися про це і, вважаючи, що це була запланована поведінка, використовували автентифікований сеанс бази даних Джейн для виконання своїх запитів. Їм сподобалося це рішення, оскільки використання прямого з’єднання дало їм повний доступ до бази даних, а не лише для випадків, які вони призначені клієнтам.
З’єднання було видалено, і інцидент вичерпано. Аналітик SOC зв’язався з користувачами, які використовували з’єднання Джейн, щоб переконатися, що вони відкидають будь-які дані клієнтів, які вони зберігають.
Вирішення проблеми безпеки з низьким кодом/без коду
Наведена вище історія є сценарієм із реального життя транснаціональної B2C компанії. Деякі деталі були опущені або скориговані для захисту конфіденційності. Ми бачили, як доброзичливий працівник міг мимоволі поділитися своєю особою з іншими користувачами, що спричинило цілий ряд проблем у ІТ, безпеці та бізнесі. Як ми досліджували минулого місяця, спільний доступ до облікових даних є ключовою особливістю низького коду/без коду. Це норма, а не виняток.
As низький код/без коду продовжує процвітати на підприємстві, свідомо чи ні, надзвичайно важливо, щоб служби безпеки та ІТ-команди приєдналися до розмови про розвиток бізнесу. Програми з низьким кодом/без коду постачаються з a унікальний набір проблем безпеки, і їх плідний характер означає, що ці виклики стають гострими швидше, ніж будь-коли раніше.
