Vynucování kontroly přístupu
- Řízení přístupu, access control nebo autorizace = proces povolování nebo zamítání požadavků uživatele, programu nebo procesu
- Řízení přístupu také zahrnuje udělování a odebírání těchto oprávnění
- Autorizace není totéž, co autentizace (ověřování identity)
- Existuje několik typů řízení přístupu
- Discretionary Access Control (DAC) = omezení přístupu k objektům (soubory, datové entity) na základě identity a znalosti subjektů (uživatel, proces) nebo skupin, do kterých objekt patří
- Každý objekt má vlastníka (subjekt), který se rozhodne, kdo další může nebo nemůže provádět akce s daným objektem
- Mandatory Access Control (MAC) = omezení přístupu k systémovým prostředkům na základě citlivosti informací v nich obsažených a oprávnění uživatelů k přístupu k takto citlivým informacím
- Zaměstnanec pracuje v nějaké firmě, která je vlastníkem dat, ta se rozhodne, jak bude s citlivými daty nakládáno, a jak je se budou sdílet
- Přístup k datům může být také předmětem právní regulace ze strany státu (např. HIPAA)
- Jedná se například o nakládání se zdravotními záznamy v nemocnicích, kde nemocnice stanoví, kdo má k datům přístup, za jakých podmínek, a jak se tato data mohou nebo nemohou dále šířit
- Role Based Access Control (RBAC) = řízení přístupu ke zdrojům, kde jsou povolené akce na zdrojích identifikovány rolemi jednotlivých subjektů
- U každého zdroje jsou definovány role, které k nim mají přístup (např. admin, běžný uživatel, anonymní uživatel, zaměstnanec, návštěvník atd.)
- Attribute Based Access Control (ABAC) = povolí nebo zamítne požadavky uživatele na základě libovolných atributů uživatele nebo objektu
- Blogovací platforma má dva redaktory, kde každý z nich může upravovat a mazat pouze ty články, které sami napsali
- Redaktor Michal tedy nemůže upravit ani smazat články redaktorky Jany
- Přístup k objektu je v tomto případě zamítnut na základě atributu
authors.idaarticles.author_id
- Discretionary Access Control (DAC) = omezení přístupu k objektům (soubory, datové entity) na základě identity a znalosti subjektů (uživatel, proces) nebo skupin, do kterých objekt patří
Zásady návrhu řízení přístupu
- Stanovte požadavky na kontrolu a řízení přístupu v počátečních fázích vývoje aplikace
Navrhněte řízení přístupu
- Po zvolení konkrétního návrhového vzoru řízení přístupu je obtížné a časově náročné (drahé) přepracovat aplikaci k používání jiného návrhového vzoru
- Jde o jednu z hlavních oblastí zabezpečení aplikace, která musí být navržena před samotným vývojem aplikace
- Návrh může začít jednoduše, ale často se může rozrůst do složitého a funkčně náročného bezpečnostního modulu
- Umožněte přizpůsobení funkce řízení přístupu pro konkrétní potřebu
Vynuťte, aby všechny požadavky prošli kontrolou řízení přístupu
- Zajistěte, aby všechny požadavky procházely určitou access control vrstvou nebo druhem ověření přístupu
- To platí i pro stránky a zdroje, které jsou veřejně přístupné
Použijte zásadu deny by default
- Deny by default = zásada, kde platí, že pokud není požadavek výslovně povolen, je odmítnut
- Toto pravidlo se v kódu projeví mnoha způsoby
- Aplikační kód může při zpracování požadavků vyhodit výjimku, čímž by měl být požadavek zamítnut
- Když se vytvoří nebo zaregistruje nový uživatel, měl by mít ve výchozím nastavení minimální nebo žádný přístup, dokud tento přístup není nakonfigurován
- Když je do aplikace přidána nová funkce, mělo by být všem uživatelům odepřeno ji používat, dokud není správně nakonfigurována
Použijte zásadu least privilege
- Zásada nejnižšího oprávnění
- Zajistěte, aby všichni uživatelé, programy a procesy měli co nejmenší nezbytně nutný přístup pro výkon jejich práce
- Dávejte si pozor na systémy, které neposkytují možnost nastavení granulárního přístupu
Nehardcodujte role
- Mnoho aplikací a frameworků má jako výchozí access control model role based
- V těchto aplikacích se běžně vyskytuje tato kontrola přístupu
if (user.hasRole("ADMIN")) || (user.hasRole("MANAGER")) {
deleteAccount();
}
- Role based model, má tato omezení a nebezpečí
- Je velmi křehký, protože je snadné kontrolu vynechat nebo ji nesprávně vytvořit
- Nepodporuje různá pravidla pro různé typy uživatelů nebo účtů. V takovém případě bude nutné rozvětvení kódu nebo přidání kontrol pro každého uživatele nebo účet zvlášť
- Neumožňuje pravidla řízení přístupu specifická pro data nebo horizontální pravidla (např. attribute based access control)
- Rozsáhlé codebase s mnoha kontrolami řízení přístupu mohou být obtížné pro audit nebo ověření celkové politiky řízení přístupu aplikace
- Zvažte tuto metodiku
if (user.hasAccess("DELETE_ACCOUNT")) {
deleteAccount();
}
- Kontroly přístupu založené na atributech nebo funkcích tohoto druhu jsou výchozím bodem pro budování dobře navržených a funkčně bohatých systémů řízení přístupu
- Tento typ programování také umožňuje větší možnosti přizpůsobení kontroly přístupu v průběhu času
Logujte všechny události řízení přístupu
- Logujte všechna selhání řízení přístupu, protože mohou svědčit o tom, že se uživatel pokouší hledat zranitelnosti aplikace