Чи потрібно захищати доступ до бекенду ваших клієнтських додатків? Авжеж, якщо ви дбаєте про ризики кібербезпеки, час роботи, відповідність стандартам SOC II та NIST або архітектурним фреймворкам AWS, Azure та GCP.
Незалежно від розміру та масштабу хмарного додатка, закривати питання відповідності до вимог безпеки ідентифікації необхідно для розвитку вашого бізнесу, особливо коли ви працюєте з клієнтами в суворо регульованих галузях.
Конфіденційні дані недарма називаються конфіденційними. Аудитори, які оцінюють відповідність стандартам SOC II, NIST та іншим, не дбають про те, чи переносять організації програми на робочі навантаження віртуальних машин або створюють їх на основі контейнерів і безсерверних функцій. Аудиторам неважливо, які хмарні провайдери використовує команда розробників для створення своїх програм. І аудиторам точно не важливі круті архітектури мікросервісів, оцінки дизайну та терміни спринтів, які є пріоритетними для ваших інженерних груп.
Про що ж піклуються аудитори? Про те, щоб компанії належним чином захищали всі облікові записи, які отримують доступ до конфіденційних даних у своїх додатках.
Хороша новина полягає в тому, що кілька перевірених практик безпеки облікових записів та управління привілейованим доступом (PAM) можуть допомогти організаціям знизити ризики та створювати SaaS-додатки, які відповідають стандартам SOC II, NIST та іншим.
Нижче наведено кілька з цих практик. Пропонуємо познайомитись із ними ближче.

Принцип найменших привілеїв

Фреймворки відповідності вимагають від організацій дотримуватися принципу найменших привілеїв (PoLP), фундаментального поняття кібербезпеки. Фреймворки відрізняються своєю термінологією – наприклад, SOC II має вимоги щодо «логічного контролю доступу», тоді як NIST Cybersecurity Framework віддає перевагу терміну «найменші привілеї». Але не помиліться – для створення відповідних SaaS-додатків організації повинні подбати про те, щоб усі облікові записи мали необхідні права для виконання своїх обов'язків.

Організації мусять, як зазначено в AWS Well-Architected Framework, «реалізовувати принцип найменших привілеїв і забезпечувати розподіл обов'язків із відповідним дозволом для кожної взаємодії з ресурсами AWS».

Zero Standing Privileges (ZSP) для всіх операційних доступів

Після впровадження принципу найменших привілеїв організації повинні подбати про захист привілейованого доступу. Щоб забезпечити відповідність, багато організацій упроваджують нову філософію безпеки – Zero Standing Privileges (ZSP), тобто нульові постійні привілеї. Методології цього принципу безпеки будуються на основі найменших привілеїв, підвищуючи доступ лише в потрібний час і мінімізуючи використання довгострокових паролів та облікових даних для доступу до робочих навантажень і сервісів хмари.
Провідні постачальники хмарних сервісів рекомендують використовувати моделі федеративного доступу (а не спільні облікові записи) для доступу до робочих навантажень і сервісів. Розробники, інженери та спеціалісти з науки даних можуть виконувати ролі IAM без використання постійних облікових даних. В результаті більша частина доступу розробників може вважатися операційною: користувачам хмари не потрібен постійний доступ до ресурсів, а лише на час виконання конкретних завдань.
Організації можуть задовольнити вимоги аудиту та відповідності для цього операційного доступу з підходом ZSP. Ключові елементи ZSP передбачають:
● Підвищення доступу до консолі та CLI до рівня хмарних сервісів на принципах just-in-time з використанням ролей, які мають мінімальні необхідні дозволи для виконання поставленого завдання. Приклади включають доступ до сервісів CSP для зміни конфігурацій мережі, бази даних та автоматичного масштабування обчислень. ● Підвищення доступу до робочих навантажень, що працюють на хмарі, на принципах just-in-time. Приклади включають операційний доступ до віртуальних машин Linux і Windows для перенесених програм або Kubernetes та інших контейнерів для програм, що працюють у хмарних, мікросервісних архітектурах. ● Інтеграцію робочих процесів запитів на доступ з наявними інструментами розробки, щоб уникнути уповільнення швидкості. Розробникам часто потрібен додатковий доступ для розвʼязання проблем під час відключень або критичних ситуацій (так званих криз). Зробити цей доступ простим і повністю контрольованим важливо для відповідності.

Безпечне керування обліковими даними та їхня ротація

Навіть у хмарі не оминути певний довготривалий доступ на системному рівні. Типовими прикладами є:
● облікові записи root ● реєстрації, необхідні для створення хмарного середовища ● секрети DevOps, що використовуються програмами ● облікові записи служб та програм ● облікові записи адміністратора для перенесених робочих навантажень програмного забезпечення, що працюють усередині віртуальних машин (наприклад, облікові записи адміністратора для ERP, бази даних або систем безпеки)
Стратегії безпеки та відповідності повинні враховувати підвищений ризик, який являють собою ці довгострокові облікові записи на рівні системи. У цьому можуть допомогти усталені підходи до PAM і управління секретами. Наприклад:
● Відкриття облікових даних, що використовуються адміністраторами, обліковими записами служб та іншими ідентифікаторами, та їхня інтеграція в рішення PAM. Це зменшує ризик крадіжки облікових даних. ● Централізоване керування секретами, що використовується розробниками, зокрема шляхом інтеграції з рідними сховищами секретів CSP. Цей підхід до управління секретами дозволяє розробникам використовувати їхні переважні інструменти, водночас забезпечуючи керування обліковими записами та їхню ротацію, що відповідає цілям комплаєнсу. ● Автоматичну ротацію облікових даних через інтервали, узгоджені з політикою організації (що часто визначаються в рамках відповідності). ● Реєстрація всього використання привілейованих облікових записів для стримування внутрішніх загроз. Щоб підвищити ефективність аудиту, централізовано зберігайте аудиторські сліди для обох сеансів, використовуючи спільні привілейовані облікові записи або сеанси з федеративним доступом із нульовими постійними привілеями. ● Ізоляція використання цих облікових записів для запобігання проникненню програм-вимагачів та іншого шкідливого програмного забезпечення на віртуальні машини та інші робочі навантаження в хмарі.

Розширення безпеки облікових записів на сторонніх постачальників

Внутрішні співробітники — не єдині особи, які мають доступ до бекенду ваших SaaS-додатків. Багато організацій користуються послугами віддалених сторонніх постачальників і підрядників для налаштування або запуску хмарних робочих навантажень і сервісів, що підтримують їхні додатки.
Аудитори, які оцінюють відповідність провідним фреймворкам кібербезпеки, часто приділяють велику увагу цьому доступу. Зокрема, відповідність SOC II ґрунтується на конкретних вимогах щодо управління віддаленим доступом та всіма точками доступу до даних. Організації можуть продемонструвати відповідність цим вимогам за допомогою звичних стратегій. Приклади:
● Керування всіма точками віддаленого доступу до даних – як для внутрішніх, так і для зовнішніх доступів: розробників-підрядників, IT-підрядників та інших сторонніх постачальників. ● Скасування будь-якого постійного привілейованого доступу для сторонніх осіб до робочих навантажень і сервісів хмари. Надмірний доступ сторонніх осіб був причиною кількох випадків витоку даних у хмарних середовищах останніми роками. ● Застосування сильної біометричної автентифікації для доступу сторонніх осіб до бекенду SaaS-додатків.

Посилена автентифікація та моніторинг для глибшого захисту

Контроль доступу — це потужний спосіб зменшення ризику. Але прийняття парадигми Zero Trust вимагає від організацій «ніколи не довіряти» та «завжди перевіряти» доступ до їхнього хмарного середовища.
Та сама філософія Zero Trust може надати додаткову цінність організаціям, які прагнуть створювати безпечні програми із дотриманням усіх вимог. Щоб посилити відповідність SOC II та іншим фреймворкам, організації повинні розглянути додаткові елементи контролю глибинного захисту, такі як:
● Застосування сильної, адаптивної багатофакторної автентифікації (MFA) та виявлення загроз ідентифікації для всіх спроб доступу до бекенду SaaS-додатків. Це має включати автентифікацію для доступів третіх осіб та застосування елементів керування, таких як посилена та безперервна автентифікація. ● Забезпечення автентифікації всіх з'єднань між машинами. ● Моніторинг усіх сеансів з високим рівнем ризику для робочих навантажень і сервісів, включно з повною інформацією про аудиторські сліди. Запис екрана та відтворення відео можуть допомогти аудиторам і командам з судової експертизи спростити свої завдання. ● Систематичний перегляд і сертифікація доступу, видалення прав для забезпечення того, що дозволи доступу відповідають посадовим обов'язкам і рівню відповідальності. ● Впровадження можливостей для забезпечення швидкого реагування на зловживання привілейованими обліковими записами або будь-яким доступом з високим рівнем ризику.
Перелічені практики безпеки облікових записів можуть зміцнити ваші ініціативи щодо комплаєнсу.

Про CyberArk 

CyberArk (NASDAQ: CYBR) є світовим лідером у сфері захисту персональних даних. Орієнтуючись на інтелектуальний контроль привілеїв, CyberArk надає найповнішу пропозицію безпеки для будь-яких облікових даних в бізнес-додатках, розподілених робочих групах, гібридних хмарних середовищах і протягом усього життєвого циклу DevOps. Провідні світові організації довіряють CyberArk захист своїх найбільш важливих активів.