Least privilege и RBAC/ABAC

Потребители, услуги и приложения получават само необходимите права.

RBAC задава роли; ABAC добавя context/attributes. Целта е compromise на един identity да не означава compromise на всичко.

Least privilege не пита „може ли този човек да има достъп?“, а „какъв е най-малкият набор права, с който работата остава възможна?“.

Developer трябва да чете production logs. Това не означава, че трябва да има:

• write достъп до production database;
• право да създава IAM roles;
• право да export-ва KMS keys.

Ролята Developer постепенно събира права за пет години и накрая е почти administrator. Това е permission creep, маскиран като RBAC.

Изберете 10 high-value accounts и попитайте за всяко право:

1. Нужно ли е?
2. Използвано ли е през последните 90 дни?
3. Може ли да бъде JIT?
4. Какво става при compromise на този identity?

• Default deny.
• Periodic entitlement reviews.
• No wildcard permissions без силна причина.
• Separate human/service identities.
• Machine-readable IAM policies.
• Access reviews при role change и offboarding.

Лошо дефинираните роли могат да институционализират прекомерния достъп.