Active Directory

Головна ідея: Access Control — це система правил і механізмів, які визначають, хто, до чого, коли і на яких умовах має доступ.

Чому це цікаво: контроль доступу є однією з основ кібербезпеки. Навіть найкращий сервер, база даних або застосунок можуть стати небезпечними, якщо “зайві” люди мають до них доступ.

Важливо: Access Control — це не тільки пароль. Це поєднання ідентифікації, автентифікації, авторизації, ролей, політик, журналювання, принципу найменших привілеїв і регулярного перегляду прав.

1. Загальний опис

Access Control або контроль доступу — це набір процесів, правил і технічних механізмів, які визначають, хто може отримати доступ до певного ресурсу.

Ресурсом може бути:

файл;
папка;
база даних;
сервер;
застосунок;
API;
хмарний сервіс;
корпоративна мережа;
кабінет у будівлі;
банківський рахунок;
медична картка;
репозиторій коду;
панель адміністратора;
Kubernetes-кластер;
ERP/CRM-система.

Контроль доступу відповідає на питання:

Хто?
До чого?
Коли?
Звідки?
На яких умовах?
Що саме може зробити?

2. Коротка характеристика

Характеристика	Значення
Назва	Access Control
Українською	Контроль доступу
Сфера	Інформаційна безпека, фізична безпека, адміністрування, IAM
Основна мета	Дозволяти доступ тільки тим, кому він потрібен і дозволений
Ключові поняття	Identification, Authentication, Authorization, Accountability
Типові моделі	DAC, MAC, RBAC, ABAC, ACL, Rule-Based Access Control
Принцип	Least privilege
Сучасний підхід	Zero Trust
Приклади	Паролі, MFA, ролі, права файлів, IAM policies, ACL, badges, biometrics

3. Access Control простими словами

Контроль доступу можна пояснити на прикладі школи.

Є різні люди:

учень;
учитель;
директор;
охоронець;
бухгалтер;
гість.

І є різні зони:

клас;
учительська;
архів;
серверна;
кабінет директора;
електронний журнал.

Не кожен має доступ всюди.

Учень може зайти в клас, але не повинен мати доступ до оцінок інших учнів або серверної.

Учитель може виставляти оцінки своїм класам, але не повинен змінювати фінансові документи.

Директор може мати ширший доступ, але навіть йому не завжди потрібен прямий доступ до всіх технічних секретів.

Людське пояснення: Access Control — це як система ключів у великій будівлі. Правильна людина має правильний ключ до правильних дверей, але не до всіх дверей одразу.

4. Основна ідея

Access Control не зводиться до фрази:

“Введи пароль”.

Повна логіка виглядає так:

1. Хто ти?
2. Чи можеш ти довести, що це справді ти?
3. Що тобі дозволено робити?
4. Чи треба записати твої дії в журнал?
5. Чи не змінився контекст доступу?

Наприклад:

Користувач: Anna
Ресурс: financial_report.xlsx
Дія: read
Контекст: робочий ноутбук, корпоративна мережа, робочий час
Рішення: дозволити

Або:

Користувач: Anna
Ресурс: payroll_database
Дія: delete
Контекст: невідомий пристрій, інша країна, ніч
Рішення: заблокувати або вимагати додаткову перевірку

5. Identification

Identification — це процес заявлення особи.

Користувач каже системі:

Я — ось цей користувач.

Приклади ідентифікаторів:

username;
email;
employee ID;
номер телефону;
login;
user ID;
smart card ID.

Приклад:

login: ivan.petrenko

Але сам логін ще нічого не доводить.

6. Authentication

Authentication або автентифікація — це перевірка, що користувач справді той, за кого себе видає.

Приклади:

пароль;
PIN;
одноразовий код;
push-підтвердження;
hardware key;
fingerprint;
Face ID;
smart card;
client certificate.

Проста схема:

Користувач назвав себе.
Система просить доказ.
Користувач надає доказ.
Система перевіряє доказ.

7. Authorization

Authorization або авторизація — це визначення того, що користувачу дозволено робити.

Приклад:

Anna успішно увійшла в систему.
Але чи може Anna видалити базу даних?
Чи може Anna переглянути зарплати?
Чи може Anna змінити ролі інших користувачів?

Authentication відповідає на питання:

Хто ти?

Authorization відповідає на питання:

Що тобі дозволено?

8. Accountability

Accountability — це можливість відстежити, хто що зробив.

Для цього використовують:

audit logs;
access logs;
security events;
timestamps;
user IDs;
IP addresses;
device IDs;
session IDs.

Приклад:

2026-05-09 14:32
user: manager01
action: exported customer list
resource: CRM
ip: 10.0.5.22
result: success

Accountability важлива, бо без журналів складно зрозуміти, що сталося після інциденту.

9. Цікавий факт: пароль — це лише маленька частина контролю доступу

Багато людей думають:

Є пароль — значить є безпека.

Але насправді пароль може бути:

слабким;
вкраденим;
повторно використаним;
записаним у нотатках;
переданим іншій людині;
збереженим у небезпечному місці;
перехопленим через phishing.

Тому сучасний контроль доступу часто включає:

MFA;
ролі;
обмеження прав;
device trust;
location checks;
session monitoring;
audit logs;
automatic lockout;
регулярний перегляд доступів.

10. Основні типи Access Control

Тип	Повна назва	Ідея
DAC	Discretionary Access Control	Власник ресурсу сам керує доступом.
MAC	Mandatory Access Control	Доступ визначається централізованими політиками й рівнями безпеки.
RBAC	Role-Based Access Control	Доступ залежить від ролі користувача.
ABAC	Attribute-Based Access Control	Доступ залежить від атрибутів користувача, ресурсу й контексту.
ACL	Access Control List	Список дозволів для конкретного ресурсу.
Rule-Based	Rule-Based Access Control	Доступ визначається правилами.

11. DAC

Discretionary Access Control або DAC — модель, у якій власник ресурсу може сам визначати, хто має доступ.

Приклад:

Користувач створив файл.
Він може дозволити іншому користувачу читати або змінювати цей файл.

DAC часто зустрічається в:

файлових системах;
desktop OS;
простих shared folders;
document sharing.

Перевага DAC:

гнучкість;
зручність для користувачів;
легко ділитися ресурсами.

Недолік:

користувач може випадково дати зайвий доступ;
важче централізовано контролювати безпеку.

12. MAC

Mandatory Access Control або MAC — модель, де доступ визначається централізованою політикою, а не бажанням власника файлу.

Приклад:

Документ має рівень Secret.
Користувач має clearance Confidential.
Доступ заборонено.

MAC використовується там, де важлива сувора безпека:

військові системи;
державні системи;
високозахищені середовища;
SELinux;
AppArmor у певних сценаріях;
системи з класифікацією даних.

13. RBAC

Role-Based Access Control або RBAC — одна з найпопулярніших моделей контролю доступу.

У RBAC права даються не кожній людині окремо, а ролям.

Приклад ролей:

Administrator;
Manager;
Accountant;
Sales;
Support;
Developer;
Viewer.

Схема:

User → Role → Permissions

Наприклад:

Olena має роль Accountant.
Роль Accountant дозволяє створювати invoices.
Отже, Olena може створювати invoices.

14. ABAC

Attribute-Based Access Control або ABAC — модель, де рішення про доступ залежить від атрибутів.

Атрибути можуть бути:

роль користувача;
відділ;
країна;
час;
IP address;
device trust;
sensitivity ресурсу;
ownership;
location;
project;
data classification.

Приклад правила:

Дозволити доступ,
якщо користувач із відділу Finance,
ресурс має classification Internal,
пристрій корпоративний,
а запит іде з дозволеної країни.

ABAC гнучкіший за RBAC, але складніший.

15. ACL

Access Control List або ACL — список прав доступу до ресурсу.

Приклад:

Користувач / група	Доступ
Alice	Read, Write
Bob	Read
Admins	Full Control
Guests	No Access

ACL часто використовуються у:

файлових системах;
мережевих пристроях;
firewall rules;
cloud storage;
databases;
object storage.

16. Rule-Based Access Control

Rule-Based Access Control використовує правила.

Приклади правил:

Доступ дозволений тільки з 09:00 до 18:00.

Доступ до admin panel дозволений тільки з корпоративної мережі.

Якщо login із нової країни — вимагати MFA.

Rule-based підхід часто комбінується з RBAC або ABAC.

17. Цікавий факт: у реальних системах часто змішують кілька моделей

У підручниках моделі виглядають окремо:

DAC
MAC
RBAC
ABAC
ACL

А в реальному житті вони змішуються.

Наприклад, у хмарній системі може бути:

RBAC для ролей;
ABAC для умов;
ACL для конкретного bucket;
MFA для login;
audit logs для accountability;
policy engine для правил;
network restrictions для додаткового захисту.

Сучасний access control — це не одна кнопка, а шарова система.

18. Principle of Least Privilege

Principle of Least Privilege або принцип найменших привілеїв означає:

Користувач або сервіс має отримувати тільки ті права,
які потрібні для виконання конкретної роботи.

Не більше.

Приклад погано:

Усі працівники мають admin access.

Приклад краще:

Бухгалтер має доступ до рахунків.
Менеджер має доступ до клієнтів.
Розробник має доступ до dev environment.
Адміністратор має окремий privileged account.

19. Need to Know

Need to Know — принцип, за яким доступ дають тільки тим, кому інформація реально потрібна.

Навіть якщо людина має високий рівень довіри, це не означає, що їй потрібні всі дані.

Приклад:

HR може бачити персональні дані працівників.
Sales не повинен бачити медичні документи.
Developer не повинен бачити зарплати.

20. Separation of Duties

Separation of Duties означає розділення критичних повноважень між різними людьми.

Приклад:

Одна людина створює платіж.
Інша людина його затверджує.

Це зменшує ризик:

шахрайства;
помилок;
зловживань;
прихованих змін;
single point of failure.

21. Цікавий факт: “admin для всіх” — це не зручність, а майбутня проблема

У маленькій команді часто кажуть:

Дамо всім admin, щоб не заважало працювати.

Спочатку це зручно.

Але потім:

хтось випадково видаляє дані;
обліковий запис зламують;
неможливо зрозуміти, хто що зробив;
колишній працівник зберігає доступ;
auditor ставить незручні питання;
production змінюють без контролю.

Адмінські права мають бути винятком, а не стандартом.

22. MFA

Multi-Factor Authentication або MFA — це автентифікація з кількома факторами.

Фактори:

Фактор	Приклад
Щось, що ви знаєте	Пароль, PIN.
Щось, що ви маєте	Телефон, hardware key, smart card.
Щось, чим ви є	Fingerprint, face recognition.

MFA значно зменшує ризик, що вкрадений пароль сам по собі дасть доступ.

23. SSO

Single Sign-On або SSO дозволяє входити в різні сервіси через один identity provider.

Приклад:

Користувач входить через корпоративний Microsoft Entra ID, Google Workspace, Okta або Keycloak.
Після цього отримує доступ до різних застосунків.

Переваги SSO:

менше паролів;
централізоване керування;
легше вимикати доступ;
MFA в одному місці;
audit;
зручність для користувачів.

Недолік:

identity provider стає критично важливою системою.

24. IAM

Identity and Access Management або IAM — це ширша система керування користувачами, ролями, політиками й доступом.

IAM включає:

users;
groups;
roles;
permissions;
policies;
service accounts;
MFA;
SSO;
access reviews;
audit logs;
lifecycle management;
privileged access management.

IAM особливо важливий у cloud.

25. PAM

Privileged Access Management або PAM — це керування привілейованими доступами.

Привілейовані акаунти:

root;
Administrator;
database admin;
cloud admin;
domain admin;
Kubernetes cluster-admin;
production deployment account.

PAM допомагає:

контролювати admin-доступ;
видавати тимчасові права;
записувати сесії;
вимагати approval;
обмежувати доступ;
зменшувати ризик зловживань.

26. Zero Trust

Zero Trust — сучасний підхід до безпеки.

Його часто пояснюють так:

Never trust, always verify.

Тобто не можна автоматично довіряти користувачу лише тому, що він “у внутрішній мережі”.

Zero Trust враховує:

identity;
device;
location;
behavior;
risk;
resource sensitivity;
session context;
continuous verification.

27. Цікавий факт: Zero Trust не означає “нікому не довіряти взагалі”

Назва може звучати агресивно.

Але Zero Trust не означає, що всі підозрілі.

Він означає:

Не давати доступ автоматично.
Перевіряти контекст.
Давати мінімальні права.
Постійно переоцінювати ризик.

Це схоже на аеропорт: навіть якщо людина вже всередині, це не означає, що вона може зайти в кабіну пілота.

28. Physical Access Control

Access Control буває не тільки цифровим.

Physical Access Control керує доступом до фізичних місць.

Приклади:

ключі;
бейджі;
турнікети;
охорона;
biometric readers;
smart locks;
дверні контролери;
відеоспостереження;
журнали відвідувачів.

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

29. Logical Access Control

Logical Access Control — це доступ до цифрових систем.

Приклади:

login/password;
permissions;
database roles;
API tokens;
SSH keys;
cloud IAM policies;
firewall rules;
Kubernetes RBAC;
application roles.

Фізичний і логічний контроль доступу часто мають працювати разом.

30. Access Control у Linux

У Linux контроль доступу базується на:

users;
groups;
file permissions;
ownership;
sudo;
ACL;
capabilities;
SELinux;
AppArmor.

Приклад прав:

-rw-r--r--

Це означає:

owner: read/write
group: read
others: read

Команди:

chmod
chown
chgrp
getfacl
setfacl
sudo

31. Access Control у Windows

У Windows широко використовуються ACL.

Поняття:

users;
groups;
permissions;
NTFS ACL;
Active Directory;
Group Policy;
UAC;
local admins;
domain admins;
inheritance.

Типові права:

Read;
Write;
Modify;
Full Control;
Execute;
List folder contents.

32. Access Control у базах даних

У базах даних контроль доступу визначає, хто може:

читати таблиці;
змінювати дані;
створювати таблиці;
видаляти записи;
виконувати procedures;
робити backup;
керувати користувачами.

Приклад SQL:

GRANT SELECT, INSERT
ON customers
TO sales_user;

Видалення права:

REVOKE INSERT
ON customers
FROM sales_user;

33. Access Control в API

API має перевіряти доступ до кожної важливої дії.

Поганий приклад логіки:

Користувач увійшов — значить може все.

Правильніше:

Користувач увійшов.
Перевірити, чи може він бачити саме цей object.
Перевірити, чи може виконати саме цю action.
Записати дію в audit log.

API access control часто використовує:

OAuth 2.0;
OpenID Connect;
JWT;
API keys;
scopes;
claims;
roles;
policies.

34. Access Control у cloud

У хмарі access control зазвичай реалізується через IAM.

Приклади:

AWS IAM;
Azure RBAC / Entra ID;
Google Cloud IAM;
Oracle Cloud IAM;
Kubernetes RBAC;
Terraform-managed policies.

Cloud IAM контролює:

хто може створити VM;
хто може прочитати storage bucket;
хто може змінити firewall;
хто може видалити database;
який сервіс має доступ до secrets;
які дії дозволені automation pipeline.

35. Access Control у Kubernetes

У Kubernetes контроль доступу часто базується на RBAC.

Об'єкти:

Role;
ClusterRole;
RoleBinding;
ClusterRoleBinding;
ServiceAccount.

Приклад:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: dev
  name: pod-reader
rules:
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["get", "list", "watch"]

Це дозволяє створити роль, яка може читати Pods у namespace `dev`.

36. Цікавий факт: найнебезпечніший доступ часто має не людина, а сервісний акаунт

Люди часто звертають увагу на користувачів:

Хто має admin?
Хто має пароль?

Але в сучасній інфраструктурі багато дій роблять service accounts:

CI/CD pipeline;
backup system;
Kubernetes controller;
cloud function;
monitoring agent;
deployment bot;
integration connector.

Якщо service account має надмірні права, його компрометація може бути дуже небезпечною.

37. Broken Access Control

Broken Access Control — одна з найпоширеніших категорій вразливостей у вебзастосунках.

Суть:

Користувач може зробити те,
що йому не повинно бути дозволено.

Приклади:

звичайний користувач відкриває admin page;
користувач бачить чужий invoice;
можна змінити `user_id` в URL і отримати чужі дані;
API не перевіряє ownership object;
роль перевіряється тільки на frontend;
видалення ресурсу доступне без перевірки прав.

38. IDOR

IDOR означає Insecure Direct Object Reference.

Приклад:

/invoice/1001

Користувач змінює URL:

/invoice/1002

І бачить чужий рахунок.

Проблема не в самому числі в URL, а в тому, що backend не перевірив:

Чи має цей користувач право бачити invoice 1002?

39. Цікавий факт: frontend-перевірка доступу не є справжнім захистом

Якщо кнопка “Delete” прихована в інтерфейсі, це ще не безпека.

Користувач може:

викликати API напряму;
змінити request;
використати dev tools;
написати скрипт;
повторити запит.

Тому access control має перевірятися на backend.

Frontend може покращити UX, але не повинен бути єдиним бар'єром.

40. Access Review

Access Review — регулярна перевірка, хто має які права.

Питання:

чи працівник досі працює в компанії?
чи змінив він роль?
чи потрібен йому старий доступ?
чи є зайві admin-права?
чи є неактивні акаунти?
чи є service accounts без власника?
чи є публічні ресурси?
чи відповідає доступ принципу least privilege?

Access reviews особливо важливі після:

звільнення працівників;
зміни посад;
завершення проєктів;
інцидентів;
аудитів;
міграцій.

41. Joiner-Mover-Leaver

Joiner-Mover-Leaver — модель життєвого циклу доступу.

Етап	Що означає
Joiner	Нова людина приходить у компанію і отримує потрібні доступи.
Mover	Людина змінює роль або відділ, доступи треба оновити.
Leaver	Людина йде з компанії, доступи треба вимкнути.

Найчастіша проблема:

Людина змінила роль або пішла,
а старі доступи залишилися.

42. Audit Logs

Audit logs потрібні для розслідувань і контролю.

Вони мають показувати:

хто виконав дію;
коли;
звідки;
над яким ресурсом;
який був результат;
які права були використані.

Погано:

action completed

Краще:

user=olena
action=delete_invoice
invoice_id=9281
time=2026-05-09T10:44:12Z
ip=10.1.4.55
result=success

43. Типові помилки в Access Control

Помилка	Чому небезпечно	Як краще
Усім admin	Один зламаний акаунт дає повний контроль.	Least privilege.
Старі доступи не прибираються	Колишні працівники або старі ролі зберігають доступ.	Joiner-Mover-Leaver процес.
Перевірка тільки на frontend	API можна викликати напряму.	Backend authorization checks.
Один shared account	Неможливо зрозуміти, хто що зробив.	Іменні акаунти.
Відсутність MFA	Вкрадений пароль дає доступ.	MFA для важливих систем.
Немає audit logs	Неможливо розслідувати інцидент.	Централізоване журналювання.
Занадто широкі service accounts	Automation може отримати надмірний доступ.	Scoped service accounts.

44. Переваги хорошого Access Control

Перевага	Опис
Менше ризику витоку даних	Люди бачать тільки те, що їм потрібно.
Менше шкоди від зламаного акаунта	Least privilege обмежує наслідки.
Кращий аудит	Видно, хто що робив.
Відповідність вимогам	Access control потрібен для багатьох стандартів і регуляцій.
Кращий порядок у компанії	Ролі й відповідальність стають зрозумілішими.
Безпечніша автоматизація	Service accounts мають обмежені права.

45. Недоліки і складність

Проблема	Опис
Складність налаштування	У великих системах багато ролей, груп і правил.
Ризик надмірної бюрократії	Якщо доступи видаються занадто повільно, люди шукають обхідні шляхи.
Role explosion	Занадто багато ролей стають некерованими.
Помилки в політиках	Неправильна IAM policy може відкрити зайвий доступ.
Потрібні регулярні перевірки	Access control старіє разом із компанією.
Баланс безпеки й зручності	Надто суворі правила можуть заважати роботі.

46. RBAC vs ABAC

Критерій	RBAC	ABAC
Основа	Ролі	Атрибути
Приклад	Manager може approve invoices	User department=Finance і device=trusted може approve invoices
Простота	Простішій	Складніший
Гнучкість	Менша	Більша
Ризик	Role explosion	Складність політик
Найкраще для	Організацій із чіткими ролями	Складних систем із контекстними умовами

47. Authentication vs Authorization

Поняття	Питання	Приклад
Authentication	Хто ти?	Користувач ввів пароль і MFA-код.
Authorization	Що тобі дозволено?	Користувач може читати звіти, але не видаляти їх.

Простий приклад:

Охоронець перевірив паспорт — authentication.
Охоронець дозволив зайти тільки на 3 поверх — authorization.

48. Access Control vs IAM

Поняття	Опис
Access Control	Конкретні правила й механізми доступу до ресурсів.
IAM	Ширша система керування identity, ролями, політиками, групами й життєвим циклом доступу.

IAM можна вважати великою системою, яка реалізує access control у масштабі організації або cloud-середовища.

49. Access Control vs Encryption

Механізм	Що робить
Access Control	Визначає, хто може отримати доступ.
Encryption	Робить дані нечитабельними без ключа.

Вони не замінюють одне одного.

Краще:

Access Control + Encryption + Audit Logs

50. Коли Access Control особливо важливий

Access Control критично важливий для:

банків;
лікарень;
шкіл;
державних систем;
ERP;
CRM;
хмарної інфраструктури;
баз даних;
Git-репозиторіїв;
production-серверів;
Kubernetes;
бухгалтерії;
персональних даних;
медичних даних;
фінансових систем;
admin panels.

51. Базовий хороший workflow

1. Визначити ресурси.
2. Визначити ролі.
3. Визначити потрібні дії.
4. Дати мінімальні права.
5. Увімкнути MFA.
6. Розділити admin і звичайні акаунти.
7. Створити audit logs.
8. Регулярно переглядати доступи.
9. Видаляти старі акаунти.
10. Перевіряти service accounts.
11. Тестувати access control у застосунках.
12. Документувати політики.

52. Приклад простої RBAC-моделі

Роль	Дозволено	Заборонено
Viewer	Переглядати дані	Редагувати, видаляти, експортувати
Editor	Створювати й редагувати записи	Керувати користувачами
Manager	Затверджувати, експортувати, бачити звіти	Змінювати системні налаштування
Admin	Керувати системою	Не повинен використовуватися для щоденної роботи

53. Приклад access policy простими словами

Доступ до фінансових звітів дозволено, якщо:
- користувач належить до Finance або Management;
- увімкнено MFA;
- пристрій корпоративний;
- запит іде не з заблокованої країни;
- дія записується в audit log.

54. Цікаві факти

Факт	Пояснення
Access Control існує не тільки в IT	Замки, ключі, бейджі й охорона — теж контроль доступу.
Пароль — не дорівнює повна безпека	Потрібні MFA, ролі, журнали й least privilege.
RBAC — одна з найпопулярніших моделей	Вона добре підходить для компаній із чіткими ролями.
ABAC гнучкіший за RBAC	Але складніший у налаштуванні й підтримці.
Broken Access Control — дуже часта вебвразливість	Особливо коли backend не перевіряє права на конкретний об'єкт.
Service accounts можуть бути небезпечнішими за людей	Бо часто мають широкі права й працюють автоматично.
Least privilege зменшує шкоду	Якщо акаунт зламано, обмежені права зменшують наслідки.
Access reviews потрібні регулярно	Доступи старіють разом із ролями, проєктами й людьми.

55. Людське пояснення: чим є Access Control

Access Control — це не про недовіру до людей.

Це про порядок.

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

Не менше — щоб не заважати.

Не більше — щоб не створювати ризик.

Поганий контроль доступу схожий на офіс, де всі мають ключі від усіх кімнат, сейфів і серверної.

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

56. Безпека

Рекомендовані практики:

використовувати MFA;
застосовувати least privilege;
не використовувати shared accounts;
регулярно переглядати доступи;
вимикати акаунти колишніх працівників;
розділяти admin і звичайні акаунти;
логувати критичні дії;
перевіряти backend authorization;
не покладатися тільки на frontend;
обмежувати service accounts;
використовувати SSO/IAM;
шифрувати чутливі дані;
налаштовувати alerts для підозрілих дій;
документувати політики доступу.

57. Висновок

Access Control — це фундаментальна частина безпеки, яка визначає, хто має доступ до ресурсів і що саме може робити.

Його головні елементи:

identification;
authentication;
authorization;
accountability;
roles;
policies;
ACL;
RBAC;
ABAC;
MFA;
audit logs;
least privilege;
access reviews.

Головні переваги:

захист даних;
менше ризику зловживань;
кращий контроль;
простіший аудит;
менша шкода від зламаних акаунтів;
відповідність security-вимогам.

Головні ризики:

надмірні права;
старі акаунти;
відсутність MFA;
погані IAM policies;
broken access control у застосунках;
shared admin accounts;
відсутність журналювання;
поганий контроль service accounts.

Access Control найкраще працює не як одноразове налаштування, а як постійний процес: видавати доступ, перевіряти його, прибирати зайве, логувати важливе й адаптувати політики до змін у компанії.

58. Джерела

NIST: Access Control concepts
OWASP: Broken Access Control
OWASP: Authorization Cheat Sheet
Microsoft Entra ID documentation
AWS IAM documentation
Google Cloud IAM documentation
Kubernetes RBAC documentation
Linux permissions documentation
Windows access control documentation
Zero Trust security model documentation

59. Див. також

Access Control Контроль доступу Кібербезпека Інформаційна безпека Authentication Authorization Identification Accountability IAM RBAC ABAC ACL DAC MAC MFA SSO Zero Trust Least privilege Audit log Broken Access Control IDOR Linux permissions Windows ACL Kubernetes RBAC Безпека даних