Перейти до вмісту

Access Control

Матеріал з K2 ERP Wiki

Безпека даних 


У маленькій команді часто кажуть:
<pre>
виступає як пароль — значить виступає як безпека. користувач системи назвав себе. рішення для бізнесу: заблокувати або вимагати додаткову перевірку

== 16. Rule-Based Access Control ==

3. якщо користувач системи із відділу Finance,

'''Mandatory Access Control''' або '''MAC''' — модель, де доступ визначається централізованою політикою, а не бажанням власника файлу. |-
| Щось, що ви маєте
| Телефон, hardware key, smart card. ! |}

<pre>

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

46. RBAC vs ABAC

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

Доступ до фінансових звітів дозволено, якщо:

! |- | Rule-Based | Rule-Based Access Control | Доступ визначається правилами. * чи відповідає доступ принципу least privilege? Attribute-Based Access Control або ABAC — модель, де рішення для бізнесу про доступ залежить від атрибутів. Rule-based підхід часто комбінується з RBAC або ABAC. |- | Access Control | Визначає, хто здатна отримати доступ. Визначити потрібні дії. * чи виступає як service accounts без власника? У Kubernetes контроль доступу часто базується на RBAC. !== 24. IAM ==

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

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

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

<pre>
4. * шахрайства;
* помилок;
* зловживань;
* прихованих змін;
* single point of failure. Чому небезпечно
<pre>
'''Accountability''' — це можливість відстежити, хто що зробив. * чи змінив він роль? Поняття

Сучасний access control — це не одна кнопка, а шарова платформа.<pre>
rules:
ip: 10.0.5.22

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

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

{| class="wikitable"

! * чи виступає як публічні ресурси? |-
| Один shared account
| Неможливо зрозуміти, хто що зробив.
  • гнучкість;
  • зручність для користувачів;
  • швидко ділитися ресурсами. користувач системи здатна зробити те,

Що тобі дозволено? |- | Старі доступи не прибираються | Колишні працівники або старі ролі зберігають доступ. Визначити ресурси. ! ip=10.1.4.55 |- | Joiner | Нова людина приходить у компанію і отримує потрібні доступи. Ідея

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

Недолік:

Він здатна дозволити іншому користувачу читати або змінювати цей файл. * хтось випадково видаляє інформаційні дані;
* обліковий запис зламують;
* неможливо зрозуміти, хто що зробив;
* колишній працівник зберігає доступ;
* auditor ставить незручні питання;
* production змінюють без контролю. ! Атрибути можуть бути:
result: success
<pre>
'''Identification''' — це бізнес-процес заявлення особи. chmod

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

Authorization ! платформа просить доказ. SEO-опис

  • users;
  • groups;
  • file permissions;
  • ownership;
  • sudo;
  • ACL;
  • capabilities;
  • SELinux;
  • AppArmor. * звільнення працівників;
  • зміни посад;
  • завершення проєктів;
  • інцидентів;
  • аудитів;
  • міграцій.== 41. Joiner-Mover-Leaver ==
платформа перевіряє доказ.
  • users;
  • groups;
  • roles;
  • permissions;
  • policies;
  • service accounts;
  • MFA;
  • SSO;
  • access reviews;
  • audit logs;
  • lifecycle management;
  • privileged access management. 4.== 19. Need to Know ==

== 28. Physical Access Control ==

* файл;
* папка;
* база даних;
* сервер;
* застосунок;
* API;
* хмарний сервіс;
* корпоративна мережа;
* кабінет у будівлі;
* банківський рахунок;
* медична картка;
* репозиторій коду;
* панель адміністратора;
* Kubernetes-кластер;
* ERP/CRM-система. Головні ризики:
== 12. MAC ==
7. |-
| Складність конфігурація
| У великих системах багато ролей, груп і правил. {| class="wikitable"
а старі доступи залишилися. |}

! |-
| Ризик надмірної бюрократії
| Якщо доступи видаються занадто повільно, люди шукають обхідні шляхи.== 23. SSO ==

* identity provider стає критично важливою системою. Визначити ролі. Чи треба записати твої дії в журнал? Значення
== 5. Identification ==
ресурс має classification Internal,
користувач системи входить через корпоративний Microsoft Entra ID, Google Workspace, Okta або Keycloak.
Фактори:
На яких умовах? Пояснення
== 39. Цікавий факт: frontend-перевірка доступу не виступає як справжнім захистом ==
</div>

<pre>

Дамо всім admin, щоб не заважало працювати. '''Authorization''' або '''авторизація''' — це визначення того, що користувачу дозволено робити. Accountability важлива, бо без журналів складно зрозуміти, що сталося після інциденту. У хмарі access control зазвичай реалізується через IAM. Access Control не зводиться до фрази:
others: read
Перевіряти контекст.

|- | Назва | 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 |}

RBAC

30. Access Control у Linux

/invoice/1002

  • учень;
  • учитель;
  • директор;
  • охоронець;
  • бухгалтер;
  • гість. які потрібні для виконання конкретної роботи. TO sales_user;

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

* OAuth 2.0;
* OpenID Connect;
* JWT;
* API keys;
* scopes;
* claims;
* roles;
* policies. Документувати політики.<pre>
<pre>
'''Separation of Duties''' означає розділення критичних повноважень між різними людьми. |-
| Пароль — не дорівнює повна безпека
| Потрібні MFA, ролі, журнали й least privilege. Характеристика

Людське пояснення: Access Control — це як платформа ключів у великій будівлі.== 8. Accountability ==

14. ABAC

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

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

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

Отже, Olena здатна створювати invoices. Приклади ідентифікаторів: ! * викликати API напряму;

  • змінити request;
  • використати dev tools;
  • написати скрипт;
  • повторити запит. Якщо login із нової країни — вимагати MFA. |-

| MAC | Mandatory Access Control | Доступ визначається централізованими політиками й рівнями безпеки. |- | Кращий аудит | Видно, хто що робив.IDOR 

name: pod-reader

Приклади: 


[[Identification]]

</div>

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

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

* військові системи;
* державні системи;
* високозахищені середовища;
* SELinux;
* AppArmor у певних сценаріях;
* системи з класифікацією даних. ! Не менше — щоб не заважати. Охоронець дозволив зайти тільки на 3 поверх — authorization. |-
| Баланс безпеки й зручності
| Надто суворі правила можуть заважати роботі. |-
| Безпечніша автоматизація процесів
| Service accounts мають обмежені права. Назва здатна звучати агресивно.<syntaxhighlight lang="sql">
3. Не більше. 1. '''критично:''' Access Control — це не тільки пароль. * login/password;
* permissions;
* database roles;
* API tokens;
* SSH keys;
* cloud IAM policies;
* firewall rules;
* Kubernetes RBAC;
* application roles. |-
| Encryption
| Робить інформаційні дані нечитабельними без ключа. Ресурс: payroll_database

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

* AWS IAM;
* Azure RBAC / Entra ID;
* Google Cloud IAM;
* Oracle Cloud IAM;
* Kubernetes RBAC;
* Terraform-managed policies. Поганий приклад логіки:

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

'''Joiner-Mover-Leaver''' — модель життєвого циклу доступу. |-
| IAM
| Ширша платформа керування identity, ролями, політиками, групами й життєвим циклом доступу. |-
| ABAC
| Attribute-Based Access Control
| Доступ залежить від атрибутів користувача, ресурсу й контексту.<pre>

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

Вони не замінюють одне одного. Недолік:

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

Ресурсом здатна бути: |- | Менше ризику витоку даних | Люди бачать тільки те, що їм потрібно. Тип

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

Приклад:

! |- | Помилки в політиках | Неправильна IAM policy здатна відкрити зайвий доступ. !== 35. Access Control у Kubernetes == Access Control — це не про недовіру до людей.Least privilege

Це схоже на аеропорт: навіть якщо людина вже всередині, це не означає, що вона здатна зайти в кабіну пілота. Але насправді пароль здатна бути: 2.</syntaxhighlight> 
Доступ до admin panel дозволений тільки з корпоративної мережі. Це зменшує ризик:

<pre>

DAC

REVOKE INSERT

owner: read/write
getfacl
== 13. RBAC ==
|-
| Щось, що ви знаєте
| Пароль, PIN. Що тобі дозволено робити? '''Need to Know''' — принцип, за яким доступ дають тільки тим, кому інформаційні матеріали реально потрібна. Видаляти старі акаунти. |-
| Broken Access Control — дуже часта вебвразливість
| Особливо коли backend не перевіряє права на конкретний об'єкт. '''Чому це цікаво:''' контроль доступу виступає як однією з основ кібербезпеки. IAM містить:
[[Linux permissions]]
Доступ заборонено. * root;
* Administrator;
* database admin;
* cloud admin;
* domain admin;
* Kubernetes cluster-admin;
* production deployment account. Поняття:
== 29. Logical Access Control ==

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

Перевірка тільки на frontend API можна викликати напряму. Схема:

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

  • Read;
  • Write;
  • Modify;
  • Full Control;
  • Execute;
  • List folder contents. ! Доступ

IDOR означає Insecure Direct Object Reference. Чи не змінився контекст доступу?ACL 

Команди:

Приклад: Проблема не в самому числі в URL, а в тому, що backend не перевірив: Розробник має доступ до dev environment. Постійно переоцінювати ризик. SEO-опис resource: CRM

38. IDOR

metadata: ACL

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

Не кожен має доступ всюди. Чи здатна Anna переглянути зарплати? ! Що робить

Роль Accountant дає можливість створювати invoices.
ON customers
! | MFA для важливих систем. Адмінські права мають бути винятком, а не стандартом. Приклад:

[[Accountability]]
Anna успішно увійшла в систему. result=success

користувач системи або сервіс має отримувати тільки ті права,
</pre>
Контекст: робочий ноутбук, корпоративна мережа, робочий час
</pre>
що йому не повинно бути дозволено. Погано:

користувач системи створив файл. MFA значно зменшує ризик, що вкрадений пароль сам по собі дасть доступ. | Scoped service accounts. | Joiner-Mover-Leaver бізнес-процес. Питання:

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

'''Broken Access Control''' — одна з найпоширеніших категорій вразливостей у вебзастосунках. І виступає як різні зони:
Він означає:
Приклади:
1. Cloud IAM контролює:

Хто має admin?<pre>

== 18. Principle of Least Privilege ==

Після цього отримує доступ до різних застосунків. invoice_id=9281
Приклад краще:

!== 33. Access Control в API ==

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

![[Інформаційна безпека]]
Давати мінімальні права. Audit logs потрібні для розслідувань і контролю. Повна логіка виглядає так:

2026-05-09 14:32

а запит іде з дозволеної країни. Frontend здатна покращити UX, але не повинен бути єдиним бар'єром. * чи працівник досі функціонує в компанії?[[Access Control]]

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

Але потім:

[[Контроль доступу]]

9. Як краще

!<div style="border-left: 6px solid #2e7d32; background: #e8f5e9; padding: 12px 16px; margin: 16px 0;">
Учень здатна зайти в клас, але не повинен мати доступ до оцінок інших учнів або серверної. * чи потрібен йому старий доступ? Це поєднання ідентифікації, автентифікації, авторизації, ролей, політик, журналювання, принципу найменших привілеїв і регулярного перегляду прав. користувач системи / група

Записати дію в audit log. |-
| Mover
| Людина змінює роль або відділ, доступи треба оновити. * CI/CD pipeline;
* backup system;
* Kubernetes controller;
* cloud function;
* monitoring agent;
* deployment bot;
* integration connector. Приклади:

</pre>
== 58. Джерела ==
Охоронець перевірив паспорт — authentication.[[Zero Trust]]

'''Access Control List''' або '''ACL''' — список прав доступу до ресурсу. Коли? |-
| Leaver
| Людина йде з компанії, доступи треба вимкнути. |}

</pre>

Тобто не можна автоматизовано довіряти користувачу лише тому, що він “у внутрішній мережі”. time=2026-05-09T10:44:12Z

Доступ дозволений тільки з 09:00 до 18:00. |-
| Access reviews потрібні регулярно
| Доступи старіють разом із ролями, проєктами й людьми. Приклад SQL:
== 6. Authentication ==
!<pre>

{{SEO
|title=Access Control — контроль доступу в інформаційній безпеці
|description=Огляд Access Control: що таке контроль доступу, authentication, authorization, identification, ACL, RBAC, ABAC, MAC, DAC, MFA, least privilege, Zero Trust, переваги, ризики, цікаві факти та приклади.
|keywords=Access Control, контроль доступу, кібербезпека, authentication, authorization, ACL, RBAC, ABAC, MAC, DAC, MFA, IAM, Zero Trust, least privilege
}}

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

! Бухгалтер має доступ до рахунків.== 7. Authorization ==

== 49. Access Control vs Encryption ==
! Помилка

[[Broken Access Control]]

Перевірити, чи здатна виконати саме цю action.[[MAC]]

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

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

<pre>
</pre>
користувач системи каже системі:

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

користувач системи увійшов — значить здатна все. Поняття
- дія записується в audit log. Питання
<pre>
<pre>
</pre>

== 59. Див. так само ==

== 44. конкурентні переваги хорошого Access Control ==

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

<pre>

== 37. Broken Access Control ==
== 1. Загальний SEO-опис ==
'''Principle of Least Privilege''' або '''принцип найменших привілеїв''' означає:
|-
| Alice
| Read, Write
|-
| Bob
| Read
|-
| Admins
| Full Control
|-
| Guests
| No Access
|}

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

* файлових системах;
* мережевих пристроях;
* firewall rules;
* cloud storage;
* databases;
* object storage. Типові права:
<pre>
 resources: ["pods"]
Менеджер має доступ до клієнтів. Краще:

Zero Trust враховує:
{| class="wikitable"
</pre>
MAC застосовується для там, де важлива сувора безпека:
Sales не повинен бачити медичні документи.== 47. Authentication vs Authorization ==

Що саме здатна зробити? |-
| Role explosion
| Занадто багато ролей стають некерованими. Це означає:

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

* хто виконав дію;
* коли;
* звідки;
* над яким ресурсом;
* який був результат;
* які права були використані.</pre>
Olena має роль Accountant. |}

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

Навіть найкращий сервер, база даних або застосунок можуть стати небезпечними, якщо “зайві” люди мають до них доступ. |-
| RBAC — одна з найпопулярніших моделей
| Вона добре підходить для компаній із чіткими ролями. |-
| Відсутність MFA
| Вкрадений пароль дає доступ. RBAC
'''Logical Access Control''' — це доступ до цифрових систем. Дати мінімальні права. Інша людина його затверджує. Одна людина створює платіж. Розділити admin і звичайні акаунти.[[RBAC]]
 - apiGroups: [""]
До чого? Приклад:

<pre>

apiVersion: rbac.authorization.k8s.io/v1

Спочатку це інтуїтивно. Чи можеш ти довести, що це справді ти? Перевіряти service accounts.</pre>
<pre>

<pre>
__TOC__
</div>

Фізичний доступ важливий, бо якщо хтось має доступ до серверної, він здатна обійти багато цифрових захистів. |-
| ABAC гнучкіший за RBAC
| Але складніший у налаштуванні й підтримці. * identity;
* device;
* location;
* behavior;
* risk;
* resource sensitivity;
* session context;
* continuous verification. Контекст: невідомий пристрій, інша країна, ніч
Приклад прав:

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

Хто? -rw-r--r--

[[Kubernetes RBAC]]

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

[[Категорія:Кібербезпека]]

== 56. Безпека ==

[[Audit log]]
Об'єкти:
<div style="border-left: 6px solid #1565c0; background: #e3f2fd; padding: 12px 16px; margin: 16px 0;">
user=olena

{| class="wikitable"

* звичайний користувач системи відкриває admin page;
* користувач системи бачить чужий invoice;
* можна змінити `user_id` в URL і отримати чужі інформаційні дані;
* API не перевіряє ownership object;
* роль перевіряється тільки на frontend;
* видалення ресурсу доступне без перевірки прав. |-
| ACL
| Access Control List
| Список дозволів для конкретного ресурсу.</pre>
== 51. Базовий хороший workflow ==
</pre>
'''Authentication''' або '''автентифікація''' — це перевірка, що користувач системи справді той, за кого себе видає. Дія: delete
'''Access Review''' — регулярна перевірка, хто має які права. |}

{| class="wikitable"

== 48. Access Control vs IAM ==
== 9. Цікавий факт: пароль — це лише маленька частина контролю доступу ==
Дозволити доступ,
У RBAC права даються не кожній людині окремо, а ролям. {| class="wikitable"
{| class="wikitable"
10. * пароль;
* PIN;
* одноразовий код;
* push-підтвердження;
* hardware key;
* fingerprint;
* Face ID;
* smart card;
* client certificate. Приклад

Проста схема:
Рекомендовані практики:
'''Access Control''' або '''контроль доступу''' — це набір процесів, правил і технічних механізмів, які визначають, хто здатна отримати доступ до певного ресурсу.[[IAM]]
<pre>
|-
| DAC
| Discretionary Access Control
| Власник ресурсу сам керує доступом. kind: Role
setfacl

6.<pre>

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

</pre>

користувач системи увійшов.</pre>
== 53. Приклад access policy простими словами ==
[[Authentication]]
як приклад, у хмарній системі здатна бути:
Але чи здатна Anna видалити базу даних?<pre>

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

Access Control + Encryption + Audit Logs
FROM sales_user;
</pre>

group: read

Це дає можливість створити роль, яка здатна читати Pods у namespace `dev`. |-
| Менше шкоди від зламаного акаунта
| Least privilege обмежує наслідки. |-
| Service accounts можуть бути небезпечнішими за людей
| Бо часто мають широкі права й працюють автоматизовано. Що означає

* банків;
* лікарень;
* шкіл;
* державних систем;
* ERP;
* CRM;
* хмарної інфраструктури;
* баз даних;
* Git-репозиторіїв;
* production-серверів;
* Kubernetes;
* бухгалтерії;
* персональних даних;
* медичних даних;
* фінансових систем;
* admin panels.== 57. Висновок ==
</pre>
Приклад:
action=delete_invoice

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

[[MFA]]

* RBAC для ролей;
* ABAC для умов;
* ACL для конкретного bucket;
* MFA для login;
* audit logs для accountability;
* policy engine для правил;
* network restrictions для додаткового захисту.<pre>
12. * MFA;
* ролі;
* обмеження прав;
* device trust;
* location checks;
* session monitoring;
* audit logs;
* automatic lockout;
* регулярний перегляд доступів. * чи виступає як зайві admin-права? |-
| Занадто широкі service accounts
| Automation здатна отримати надмірний доступ. Але Zero Trust не означає, що всі підозрілі. Регулярно переглядати доступи. Дія: read

== 34. Access Control у cloud ==

== 22. MFA ==

* identification;
* authentication;
* authorization;
* accountability;
* roles;
* policies;
* ACL;
* RBAC;
* ABAC;
* MFA;
* audit logs;
* least privilege;
* access reviews. |-
| Viewer
| Переглядати інформаційні дані
| Редагувати, видаляти, експортувати
|-
| Editor
| Створювати й редагувати записи
| Керувати користувачами
|-
| Manager
| Затверджувати, експортувати, бачити звіти
| Змінювати системні конфігурація
|-
| Admin
| Керувати системою
| Не повинен використовуватися для щоденної роботи
|}

<pre>

'''Privileged Access Management''' або '''PAM''' — це керування привілейованими доступами. Створити audit logs. Навіть якщо людина має високий рівень довіри, це не означає, що їй потрібні всі інформаційні дані. GRANT SELECT, INSERT

! | Централізоване журналювання. * username;
* email;
* employee ID;
* номер телефону;
* login;
* user ID;
* smart card ID. Ресурс: financial_report.xlsx

<pre>
{| class="wikitable"
[[Windows ACL]]
Access Control критично важливий для:

5. | користувач системи здатна читати звіти, але не видаляти їх.== 21. Цікавий факт: “admin для всіх” — це не зручність, а майбутня проблема ==
  • 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

20. Separation of Duties

Never trust, always verify. конкурентні переваги SSO:

</syntaxhighlight> Приклад:

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

|-
| Усім admin
| Один зламаний акаунт дає повний контроль. Увімкнути MFA. | Backend authorization checks.== 32. Access Control у базах даних ==
Authorization відповідає на питання:
- користувач системи належить до Finance або Management;

{| class="wikitable"

- пристрій корпоративний;
“Введи пароль”. ABAC
! * файлових системах;
  • desktop OS;
  • простих shared folders;
  • document sharing. * чи виступає як неактивні акаунти? * користувач системи здатна випадково дати зайвий доступ;
  • важче централізовано контролювати безпеку. |}

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

  • audit logs;
  • access logs;
  • security events;
  • timestamps;
  • user IDs;
  • IP addresses;
  • device IDs;
  • session IDs. Дозволено

Але сам логін ще нічого не доводить.== 43. Типові помилки в Access Control ==

Або:

користувач системи: Anna

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

  • Administrator;
  • Manager;
  • Accountant;
  • Sales;
  • Support;
  • Developer;
  • Viewer. ! |-
RBAC Role-Based Access Control Доступ залежить від ролі користувача.== 50. Коли Access Control особливо важливий ==
  • контролювати admin-доступ;
  • видавати тимчасові права;
  • записувати сесії;
  • вимагати approval;
  • обмежувати доступ;
  • зменшувати ризик зловживань.

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

Access Control - Authorization - Щось, чим ви виступає як Fingerprint, face recognition.Кібербезпека користувач системи надає доказ. Physical Access Control керує доступом до фізичних місць.

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

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

Чи здатна Anna змінити ролі інших користувачів? Перевірити, чи здатна він бачити саме цей object. |}
- Немає audit logs Неможливо розслідувати інцидент.ABAC

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

namespace: dev

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

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

Authentication Хто ти?
  • роль користувача;
  • відділ;
  • країна;
  • час;
  • IP address;
  • device trust;
  • sensitivity ресурсу;
  • ownership;
  • location;
  • project;
  • data classification. IAM можна вважати великою системою, яка реалізує access control у масштабі організації або cloud-середовища. |-
 Основа Ролі Атрибути
Приклад Manager здатна approve invoices User department=Finance і device=trusted здатна approve invoices
Простота Простішій Складніший
Гнучкість Менша Більша
Ризик Role explosion Складність політик
Найкраще для Організацій із чіткими ролями Складних систем із контекстними умовами

Суть: HR здатна бачити персональні інформаційні дані працівників. як приклад: Його головні елементи: User → Role → Permissions login: ivan.petrenko

action: exported customer list

Видалення права: Приклад: користувач системи: Anna

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

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

виступає як різні люди:

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

chgrp Адміністратор має окремий privileged account. |-

Least privilege зменшує шкоду Якщо акаунт зламано, обмежені права зменшують наслідки. Single Sign-On або SSO дає можливість входити в різні сервіси через один identity provider. Хто ти? Приклад:

ON customers 

verbs: ["get", "list", "watch"]

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

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

2. Критерій

Учитель здатна виставляти оцінки своїм класам, але не повинен змінювати фінансові документи.
<syntaxhighlight lang="yaml">
'''Discretionary Access Control''' або '''DAC''' — модель, у якій власник ресурсу здатна сам визначати, хто має доступ. |-
| Відповідність вимогам
| Access control потрібен для багатьох стандартів і регуляцій. Факт
Приклад:
А в реальному житті вони змішуються.== 11. DAC ==
рішення для бізнесу: дозволити
Його часто пояснюють так:
API має перевіряти доступ до кожної важливої дії. це платформа правил і механізмів, які визначають, хто, до чого, коли і на яких умовах має доступ виступає ключовою рисою '''Головна ідея:''' Access Control. користувач системи здатна:
== 31. Access Control у Windows ==

Приклади:

<pre>
Усі працівники мають admin access. Приклади:

Перевага DAC:
Краще:


- увімкнено MFA;
sudo

Документ має рівень Secret. користувач системи змінює URL: chown

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

Головні конкурентні переваги: Не давати доступ автоматизовано. * слабким;

  • вкраденим;
  • повторно використаним;
  • записаним у нотатках;
  • переданим іншій людині;
  • збереженим у небезпечному місці;
  • перехопленим через phishing. | Least privilege. |-
 Кращий порядок у компанії користувач системи ввів пароль і MFA-код.

* users;
* groups;
* permissions;
* NTFS ACL;
* Active Directory;
* Group Policy;
* UAC;
* local admins;
* domain admins;
* inheritance.== 26. Zero Trust ==

[[SSO]]

API access control часто використовує:
Access Control існує не тільки в IT }

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

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

MAC

  • Role;
  • ClusterRole;
  • RoleBinding;
  • ClusterRoleBinding;
  • ServiceAccount. Етап

Приклад: як приклад: Access Control буває не тільки цифровим. |-

Потрібні регулярні перевірки Access control старіє разом із компанією. 
<pre>
<pre>

[[DAC]]

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

Це про порядок. Роль
{| class="wikitable"

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

Отримано з https://wiki.kyiv.ua/index.php?title=Access_Control&oldid=1360