Přeskočit na hlavní obsah

Jak na autorizaci, DDoS je jen špička ledovce, Reddit breach a další

Mezi nejčastější formy řízení přístupu patří RBAC a ABAC. Víte, kdy který z nich použít? Znáte 7 typických cloudových hrozeb, které nás v roce 2023 čekají?

Malá drobnost k formátu

  • 💎 = tato informace je podle mě stěžejní
  • 💡 = tato informace mi přišla zajímavá

🏆 Téma: Autorizace pomocí RBAC a ABAC

  • = koncept řízení přístupu na základě oprávnění stanovených majitelem dat, aplikací nebo jinou politikou
    • Anonymní uživatel má právo číst články na webu
    • Redaktor má právo upravovat články, které sám napsal
    • Synchronizační služba má oprávnění zapisovat do tabulky articles
  • Autorizaci často předchází autentizace
  • Je možné ji v aplikaci implementovat někoika způsoby, ale nejpoužívanější formy jsou RBAC a ABAC
  • 💎 To, jakou formu řízení přístupu zvolíte, rozhodněte co nejdřív, nejlépe ve fázi návrhu aplikace

Co nabízí RBAC?​

  • Řídí přístup na základě rolí uživatele přiřazených uživatelům aplikace (Role Based Access Control)
  • Přiřazuje oprávnění dané roli a entitě (uživateli), ta od ní tato oprávnění dědí
    • editor má oprávnění psát a upravovat články → všichni uživatelé s touto rolí mají oprávnění psát a upravovat články
  • Umožňuje entitě mít víc rolí (vztah many-to-many) a role mohou mít hierarchickou podobu
    • editor-in-chief má stejné oprávnění jako editor, ale navíc může vytvářet nové redaktory
  • 💎 Je velmi agilní a jednoduchý na integraci
  • 💡 Podporuje pravidlo Least Privilege (přidělování pouze minimálních oprávnění nezbytné pro dokončení práce na nezbytně nutnou dobu)
  • Zjednodušuje administraci díky jednoduchosti rolí
  • 💡 Umožňuje reprezentovat firemní strukturu díky rolím, které odpovídají např. pracovním pozicím
    • Role se často pletou se skupinami, ale skupina je kolekce uživatelů, nikoli oprávnění, proto se role preferují
  • 💎 Uživatel by neměl být součástí rolí, které se vzájemně vylučují (Separation of Duties)
    • Má oprávnění pouze ke čtení dat, ale zároveň je admin, která má pravo zapisovat

Jak mu konkuruje ABAC?​

  • Povoluje požadavky na provedení operací na základě atributů (Attrubute Based Access Control)
  • 💡 Řeší zásadní nedostatek RBAC: editor má oprávnění psát a upravovat články
    • Je správně, že má editor právo upravit článek svého kolegy?
    • Je správně, že editor může upravit článek po jeho zveřejnění?
      • = kontrola atributů (vlastností nebo rysů dané entity)
  • Obecně se dá říct, že role je jeden z atributů řízení přístupu, RBAC a ABAC se často kombinují a doplňují
  • 💎 Role se často používají v jednodušších projektech, pokud se ale projekt dále rozvíjí, dá se předpokládat, že bude vyžadovat komplexnější systém pro řízení přístupu
    • Proto je v rané fázi projektu nutné zamyslet se nad požadavky, protože přepsání funkcionality v pozdějších fázích vývoje může být finančně a časově nákladné
  • 💎 V praxi se doporučuje použití ABAC

Příklady​

  • Způsob povolení přístupu: article.creatorId == editor.id
  • Atributy entit: denní doba, název projektu, MAC adresa, datum vytvoření, autor …

Základní pravidla pro integraci rolí​

  1. Zjistěte, jaké jsou požadavky na přístupová práva k jednotlivým zdrojům a datům (v rané fázi vývoje)
  2. Stanovte vhodnou formu řízení přístupu na základě zjištění z přechozího bodu
  3. Vynucujte least privilege
  4. Zajistěte deny-by-default (odmítnutí přístupu ve výchozím nastavení - pokud není přístup explicitně povolen, je zamítnut)
  5. Ověřujte oprávnění pro každý požadavek (např. middleware)
  6. Zkontrolujte autorizační logiku nástrojů a technologií, které používáte nebo chcete použít a případně implementujte logiku vlastní
  7. Preferujte autorizaci na základě atributů namísto rolí
  8. Preferujte centralizaci autorizační logiky (samostatný modul nebo služba)
  9. Napište integrační / jednotkové / end to end testy pro autorizační logiku (nejlépe 100% test coverage)

🎓 Učíme se společně

Co jsme se dozvěděli z přednášek, školení, čtení knih a dalších aktivit?

Getting API Security Right​

  • Speaker: Philippe De Ryck
  • 💎 Většina lidí bere DDoS / DoS jako velký problém, ale pravdou je, že je to jen část problému = ostatní scénáře mají větší (přímý) dopad na API a data, řešit by se mělo hlavně následující:
    • Limitace výpočetních zdrojů a zdrojů na infrastruktuře
    • Aplikační validace vstupu (pagination)
    • Přenesení zodpovědnosti na někoho jiného - využití služby nebo providera
      • Hlavně v případě zpracování obrázků - zde je mnoho míst, kde může nastat problém
    • Specifický rate limiting pro danou aplikaci - uživatel si může změnit fotku maximálně 3x za den
  • 💎 Vstup validujeme hlavně na backendu (serveru)
    • Často se stává, že se na frontendu zobrazí hláška, že uživatel překročil limit, ale když se dotáže API napřímo, tak se operace vykoná bez jakékoli chyby (podobný problém měl Twitter)
  • API a klientská část není jedna aplikace = bezpečnost API nesmí být závislá na klientské aplikaci
    • Tester by měl testovat jak API, tak klientskou část
  • 💎 Dobrá praxe je oddělit citlivá data od ostatních dat
    • Vlastní služba a patřičná ochrana dat
    • Vlastní služba má nejnižší nutná oprávnění (least privilege), zvážit musíme také přístupnost služby k internetu atp.
  • 💡 Manuální testování endpointů není udržitelné
    • Používat OpenAPI specifikaci a definovat response schéma
    • Swagger / OpenAPI není jen dokumentace, ale umožňuje i testování

📰 Co je nového

  1. Při útoku byl kompromitován kód Redditu, interní dokumenty, dashboardy a další systémy
    • Vlivem phishingového útoku byly odcizeny credentials jednomu ze zaměstnanců
    • Útočníci získali přístup k informacím o inzerentech a zaměstnancích
    • 💎 Reddit uvedl, že uživatelská data nebyla ovlivněna a ani neunikla
  2. Severní Korea využívá útoky na zdravotnictví k financování další kybernetické kriminality
    • Prostřednictvím ransomwaru Maui a H0lyGh0st využívají příjmy z výkupného k podpoře národních priorit včetně kyber operací
    • Celé odvětví je útoky znepokojeno hlavně kvůli jejich množství a dopadu
    • Aktéři využívají hlavně kryptoměn a spolupráce se zahraničními subjekty
    • Nejčastěji se zaměřují na běžné zranitelnosti a využívají nejnovějších CVE
      • Apache Log4j (Log4Shell) a chyby vzdáleného spuštění kódu v zařízeních SonicWall
  3. 7 kritických cloudových hrozeb, kterým čelí podnik v roce 2023

    • Rostoucí závislost na cloudu přináší bezpečnostní výzvy k již tak složitému systému

    • Otázkou není, zda k útoku dojde, ale kdy k němu dojde

    1. Rizika softwaru třetích stran a dodavatelského řetězce
    2. Cloudový ransomware
    3. APT - Advanced Persisted Threats
    4. Používání více cloudů
    5. Datové stíny (informace, které za sebou člověk neúmyslně zanechá)
    6. Nadměrná oprávnění v cloudu
    7. Lidská chyba, chybná konfigurace a zneužití dat

😂 Závěrečný ftípek: What’s a hacker’s favorite season? … Phishing season.

🔔 Sledujte nás na Twitteru a LinkedInu, kam pravidelně sdílíme další novinky a know-how.

🆘 S bezpečností vám rádi pomůžeme, klidně nám napište - školíme vývojáře i management, nastavujeme procesy, vyvíjíme bezpečné aplikace a poskytujeme další služby.