Přeskočit na hlavní obsah

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.id a articles.author_id

Zásady návrhu řízení přístupu

  1. Stanovte požadavky na kontrolu a řízení přístupu v počátečních fázích vývoje aplikace
  • 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
  1. 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

  1. 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
    1. 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
    2. 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
    3. 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í
  1. Zajistěte, aby všichni uživatelé, programy a procesy měli co nejmenší nezbytně nutný přístup pro výkon jejich práce
  2. 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

  1. Logujte všechna selhání řízení přístupu, protože mohou svědčit o tom, že se uživatel pokouší hledat zranitelnosti aplikace

Kam dál

Zranitelnosti

Cheat sheety

Checklisty

Další