Усі хочуть найменших привілеїв, тож чому нікому їх не вдається?

Коли я формував ідею компанії, яка мала стати Veza, ми з моїми співзасновниками взяли інтерв’ю у десятків керівників інформаційної безпеки (CISO) і керівників інформаційних технологій (CIO). Незалежно від розміру та зрілості їхніх сучасних технічно підкованих компаній, ми знову і знову чули одну тему: вони не могли бачити, хто має доступ до найбільш конфіденційних даних їхньої компанії. Кожен із них дотримувався принципу найменший привілей, але жоден із них не міг сказати, наскільки близько їхня компанія досягла цього.

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

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

Є три перешкоди для досягнення найменших привілеїв: видимість, масштаб і показники.

Основою є видимість

Важко керувати тим, чого ви не бачите, а дозволи на доступ розподілені по незліченній кількості систем підприємства. Багато з них керуються локально за допомогою унікальних елементів керування доступом системи (наприклад, дозволи адміністратора Salesforce). Навіть коли компанії впроваджують постачальника ідентифікаційної інформації, наприклад Okta, Ping або ForgeRock, це лише верхівка айсберга. Він не може показати всі дозволи, розташовані нижче ватерлінії, включаючи локальні облікові записи та облікові записи служб.

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

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

шкала

Будь-яка компанія може мати тисячі ідентифікацій для співробітників, а також тисячі інших для нелюдей, як-от сервісні облікові записи та боти. Можуть бути сотні «систем», включаючи хмарні служби, програми SaaS, спеціальні програми та системи даних, такі як SQL Server і Snowflake. Кожен пропонує десятки чи сотні можливих дозволів на будь-яку кількість ресурсів деталізації даних. Оскільки рішення про доступ необхідно прийняти для кожної можливої ​​комбінації, легко уявити складність перевірки мільйона рішень.

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

Компанії не можуть подолати проблему масштабу без автоматизації. Одним з рішень є обмежений за часом доступ. Наприклад, якщо працівник отримав доступ до групи, але не використовує 90% дозволів протягом 60 днів, можливо, доцільно обрізати цей доступ.

Метрика

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

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

Як команди кількісно визначать свій доступ? Це буде називатися «балами привілеїв»? Загальний бал дозволів? Папір 2017 винайшов метрику для виявлення бази даних під назвою «величина ризику порушення». Як би ми це не називали, зростання цього показника стане переломним моментом у безпеці на першому місці – ідентифікація. Навіть якщо показник недосконалий, він змінить мислення компанії в бік управління найменшими привілеями, як бізнес-процес.

Йти вперед

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

• Розповсюдження контенту та PR на основі SEO. Отримайте посилення сьогодні.
• Платоблокчейн. Web3 Metaverse Intelligence. Розширені знання. Доступ тут.
• джерело: https://www.darkreading.com/attacks-breaches/everybody-wants-least-privilege-so-why-isn-t-anyone-achieving-it