top of page
Anchor 1
Anchor 2

Zabezpečení aplikací

Zabezpečení aplikací (AppSec) pomáhá chránit data a kód aplikací před kybernetickými útoky a krádeží dat. Zahrnuje všechna bezpečnostní hlediska během návrhu, vývoje a nasazení aplikací. AppSec zahrnuje implementaci softwaru, hardwaru a procedur, které identifikují a snižují počet bezpečnostních slabin a minimalizují šanci na úspěšný útok. 

AppSec obvykle zahrnuje zabudování ochran a ovládacích prvků do softwarových procesů. Například automatizovaná statická analýza nového kódu, testování nových verzí softwaru na bezpečnostní zranitelnosti nebo nesprávné konfigurace a použití aplikačního firewallu k přísné definici povolených a zakázaných činností. 

 

V tomto článku:

Co je Threat Molahůdkyng


Modelování hrozeb pomáhá optimalizovat zabezpečení systémů, obchodních procesů a aplikací. Zahrnuje identifikaci slabých míst a cílů a definování vhodných protiopatření ke zmírnění a prevenci dopadů hrozeb. Je základní součástí komplexního programu zabezpečení aplikací.

Zde jsou hlavní kroky modelování hrozeb:

  1. Definujte všechna aktiva podniku.

  2. Identifikujte funkci aplikace týkající se identifikovaných aktiv.

  3. Vytvořte profil zabezpečení pro každou aplikaci.

  4. Identifikujte a upřednostněte potenciální hrozby.

  5. Zdokumentujte nežádoucí události a všechny akce provedené během každého scénáře.

Tvoří se modely hrozebzásadní součást procesu vývoje bezpečnosti. Když je modelování hrozeb začleněno do procesu DevOps, umožňuje týmům zabudovat zabezpečení do projektu během fází vývoje a údržby, aby se zabránilo běžným problémům, jako je např.slabé ověření, selhání ověření vstupu, chybějící šifrování dat a nedostatečné zpracování chyb.

Co je Testování zabezpečení aplikací


Testování zabezpečení aplikací nebo testování AppSec (AST) pomáhá identifikovat a minimalizovat zranitelnosti softwaru. Tento proces testuje, analyzuje a podává zprávy o úrovni zabezpečení aplikace v průběhu životního cyklu vývoje softwaru (SDLC). Umožňuje týmům předcházet zranitelnostem softwaru před nasazením a rychle identifikovat zranitelnosti v produkci. Cílem je vyvinout silnější zdrojový kód a učinit aplikace bezpečnější.

Nástroje a řešení pro zabezpečení aplikací

Zde jsou nejběžnější kategorie zabezpečení aplikací:

Statické testování zabezpečení aplikací (SAST)

SAST pomáhá odhalit chyby v kódu tím, že analyzuje zdrojové soubory aplikace na hlavní příčiny. Umožňuje porovnat výsledky skenování statické analýzy s řešeními v reálném čase, aby bylo možné rychle detekovat bezpečnostní problémy, zkrátit střední dobu opravy (MTTR) a společně řešit problémy.

Dynamické testování zabezpečení aplikací (DAST)

DAST je proaktivní testovací přístup, který simuluje narušení zabezpečení běžící webové aplikace, aby identifikoval zneužitelné chyby. Tyto nástroje vyhodnocují aplikace v produkci, aby pomohly odhalit chyby související s runtime nebo prostředím.

 

Interaktivní testování zabezpečení aplikací (IAST)

IAST využívá prvky SAST a DAST a provádí analýzu v reálném čase nebo v jakékoli fázi SDLC z aplikace. Nástroje IAST získávají přístup ke kódu a komponentám aplikace, což znamená, že nástroje dosahují hloubkového přístupu potřebného k vytváření přesných výsledků.

 

Runtime Application Security Protection (RASP)

Nástroje RASP fungují v rámci aplikace tak, aby poskytovaly nepřetržité bezpečnostní kontroly a automaticky reagovaly na možná narušení. Mezi běžné reakce patří upozornění IT týmů a ukončení podezřelé relace.

 

Testování zabezpečení mobilních aplikací (MAST)

Nástroje MAST testují bezpečnost mobilních aplikací pomocí různých technik, jako je provádění statické a dynamické analýzy a zkoumání forenzních dat shromážděných mobilními aplikacemi. Nástroje MAST pomáhají identifikovat problémy a zranitelnosti zabezpečení specifické pro mobily, jako jsou škodlivé WiFi sítě, útěk z vězení a únik dat z mobilních zařízení.

 

Web Application Firewall (WAF)

Řešení WAF monitoruje a filtruje veškerý HTTP provoz procházející mezi internetem a webovou aplikací. Tato řešení nepokrývají všechny hrozby. Spíše WAF fungují jako součást balíčku zabezpečení, který poskytuje holistickou obranu proti relevantním útočným vektorům.

WAF funguje jako ochrana protokolové vrstvy sedm, je-li použita jako součást modelu propojení otevřených systémů (OSI). Pomáhá chránit webové aplikace před různými útoky, včetně cross-site-scripting (XSS), SQL injection (SQLi), vkládání souborů a cross-site padělání (CSRF).

 

CNAPP

Platforma ochrany cloudových nativních aplikací (CNAPP) centralizuje ovládání všech nástrojů používaných k ochraně cloudových nativních aplikací. Sjednocuje různé technologie, jako je správa pozice zabezpečení v cloudu (CSPM) a platforma ochrany pracovní zátěže v cloudu (CWPP), správa nároků na identitu, zabezpečení automatizace a orchestrace pro platformy orchestrace kontejnerů, jako je Kubernetes, a zjišťování a ochrana API.

Doporučené postupy zabezpečení aplikací


Následující osvědčené postupy by měly pomoci zajistit zabezpečení aplikací.
 

Sledování aktiv

Organizace musí mít plný přehled o svých aktivech, aby je mohla chránit. Prvním krokem k vytvoření bezpečného vývojového prostředí je určení, které servery jsou hostiteli aplikace a které softwarové komponenty aplikace obsahuje.

Selhání při sledování digitálních aktiv může vést k vysokým pokutám (jako je pokuta společnosti Equifax ve výši 700 milionů dolarů za neochrání údajů milionů zákazníků). Vývojové a bezpečnostní týmy musí vědět, jaký software běží v jednotlivých aplikacích, aby umožnily včasné opravy a aktualizace. 

Například Equifax mohl zabránit narušení tím, že by záplatoval komponentu Apache Struts na zákaznickém webovém portálu, ale nevěděl, že používá zranitelnou komponentu.

Sledování aktiv předchází bezpečnostním problémům. Automatizace může urychlit tento časově náročný proces a podporovat škálování, zatímco klasifikace na základě funkce umožňuje podnikům stanovit priority, posoudit a opravit aktiva. 

 

Posun zabezpečení doleva

Moderní, rychle se rozvíjející odvětví vývoje softwaru vyžaduje časté vydávání – někdy i několikrát denně. Bezpečnostní testy musí být začleněny do vývojového kanálu, aby bylo zajištěno, že vývojářské a bezpečnostní týmy udrží krok s poptávkou. Testování by mělo začít brzy v SDLC, aby se zabránilo zpomalení vydávání na konci kanálu. 

Pochopení stávajícího vývojového procesu a vztahů mezi vývojáři a bezpečnostními testery je důležité pro implementaci efektivní strategie posunu doleva. Vyžaduje to naučit se odpovědnosti, nástroje a procesy týmů, včetně toho, jak vytvářejí aplikace. Dalším krokem je integrace bezpečnostních procesů do stávajícího vývojového kanálu, aby vývojáři snadno přijali nový přístup. 

Potrubí CI/CD by mělo zahrnovat automatizované bezpečnostní testy v různých fázích. Integrace nástrojů pro automatizaci zabezpečení do kanálu umožňuje týmu interně testovat kód, aniž by se spoléhal na jiné týmy, takže vývojáři mohou problémy rychle a snadno opravit.

 

Provádění hodnocení hrozeb

Po vypsání aktiv vyžadujících ochranu je možné začít s identifikací konkrétních hrozeb a protiopatření. Hodnocení hrozeb zahrnuje určení cest, které mohou útočníci zneužít k narušení aplikace. 

S identifikovanými potenciálními vektory útoků může bezpečnostní tým vyhodnotit své stávající bezpečnostní kontroly pro detekci a prevenci útoků a identifikovat nové nástroje ke zlepšení bezpečnostní pozice společnosti.

Při hodnocení stávajících bezpečnostních opatření a plánování nové bezpečnostní strategie je však důležité mít realistická očekávání ohledně vhodných úrovní zabezpečení. Například ani nejvyšší úroveň ochrany nezablokuje hackery úplně. 

Jedním z důvodů je dlouhodobá udržitelnost bezpečnostní strategie – nejvyšší bezpečnostní standardy nemusí být možné udržet, zvláště pro omezený tým v rostoucí společnosti. Dalším hlediskem je přijatelná míra rizika a posouzení nákladů a přínosů navrhovaných bezpečnostních opatření. 

 

Správa privilegií

Ne každý uživatel v organizaci vyžaduje stejná přístupová oprávnění. Klíčovým osvědčeným postupem v oblasti zabezpečení je omezení přístupu k datům a aplikacím na základě potřeby vědět. Omezení oprávnění má dva hlavní důvody: 

  • Pokud se hackeři mohou dostat do systému s odcizenými přihlašovacími údaji (např. od zaměstnance v marketingovém oddělení), musí existovat kontroly, které jim zabrání v přístupu k jiným datům. Nejméně privilegované kontroly přístupu pomáhají zabránit bočnímu pohybu a minimalizovat rádius útoku. 

  • Hrozby zevnitř jsou nebezpečnější, když má síť otevřený interní přístup. Tyto hrozby mohou být škodlivé nebo neúmyslné, například zaměstnanec nesprávně umístí zařízení nebo stáhne škodlivé soubory. 

Správa privilegií by se měla řídit zásadou nejmenšího privilegia, aby zabránila zaměstnancům a externím uživatelům v přístupu k datům, která nepotřebují, čímž se sníží celková expozice.

Anchor 3
Anchor 4
bottom of page