Знову цикл… Ідея цієї статті крутилась в мене в голові вже давно. Проблема контролю доступу не нова, як і інструменти, що її вирішують. Якщо говорити про Go - чого я тільки не бачив…
В сучасних системах управління доступ до ресурсів є критично важливим компонентом безпеки. Коли система росте, кількість користувачів збільшується, а структура організації ускладнюється, виникає потреба в гнучкому та надійному механізмі контролю доступу. Традиційні підходи, такі як жорстко закодовані перевірки прав або прості системи ролей, часто виявляються недостатніми для складних бізнес-вимог.
Саме тут на допомогу приходить Casbin - open-source бібліотека, що дозволяє реалізувати складні політики доступу, не ускладнюючи код бізнес-логіки. Всього в циклі буде дві статті і в першій частині, як зазвичай, розглянемо все це з точки зору теорії. Поговоримо про типи контролю доступу, про моделі та їх можливості, про функції та ще багато іншого.
Хочу зазначити, що результатом циклу буде така собі open-source абстракція над Casbin на Go. Для чого? Відповідь достатньо проста - можливості Casbin доволі великі, але і писати все треба руками. Тип паче, функціонал з коробки покриває (наскільки мені досвід дозволяє таке заявляти) чи не 90%+ для того, що потрібно для будь-якої SaaS-системи.
Як я вже казав - ідея виникла доволі давно, але спробувати написати якийсь wrapper над Casbin - можливо десь півроку тому, коли стартап, на якому я працюю, потребував доволі гнучкої системи контролю доступу. В той же час була вимога до структури - задумано три рівні, які залежать один від одного:
І мій колега, Герман, (дуже йому дякую за зроблену роботу!) імплементував всі необхідні вимоги і працювало це просто афігенно! Із зрозумілих причин, я не можу поділитись тут цим кодом, але я вирішив, що можна зробити певний wrapper, на основі того, що зробив Герман. Мало того, дати можливість розробникам самим реалізовувати потрібну модель із тими вимогами, що потрібні їм! Ми ж розглянемо тільки RBAC.
Кожен тип контролю доступом має свої переваги та обмеження, які слід враховувати при проєктуванні системи безпеки. Розглянемо детальніше основні підходи до управління доступом та їх особливості в сучасних системах, щоб краще зрозуміти, який підхід найкраще підходить для конкретних кейсів.
Система, де власник ресурсу самостійно визначає права до нього. Наприклад, Google Docs, де автор документу вирішує, хто має доступ.
Плюси: інтуїтивність, гнучкість налаштувань, швидке керування правами, можливість делегування, мінімальне навантаження на адміністраторів
Мінуси: ризики через неправильне надання прав, складний контроль розповсюдження, можливість надання надто широких прав, відсутність централізації
Система, де права доступу визначаються централізовано на основі рівнів безпеки. Використовується в урядових та військових системах, де документи мають рівні секретності (цілком таємно, секретно, для службового користування), а користувачі - рівні допуску.
Плюси: висока безпека, чітка ієрархія, мінімізація витоків даних, централізоване управління, простота впровадження у державних структурах
Мінуси: низька гнучкість, складність адміністрування, високі витрати, можливі затримки, обмежена масштабованість
Система, де користувачам призначаються ролі, а ролям - набори прав доступу. Найбільш поширений підхід в корпоративних системах та веб-додатках, де права доступу визначаються через ролі користувачів.