STRIDE je rámec pro modelování hrozeb vytvořený společností Microsoft, který organizuje bezpečnostní rizika do šesti kategorií: falšování, manipulace, odmítnutí, zveřejnění informací, odmítnutí služby a zvýšení oprávnění. Vývojářům poskytuje opakovaný způsob, jak se v jakékoli fázi životního cyklu softwaru zeptat: „Co se tu může pokazit?“.
Proč by vývojáři měli v softwarových projektech používat model hrozeb STRIDE?
Pokud zasíláte kód, správa pipelines nebo dotykem CI/CD V každém případě by mělo být modelování hrozeb STRIDE součástí vaší sady nástrojů. STRIDE je zkratka pro Spoofing (falšování), Tampering (neoprávněná manipulace), Repudiation (odmítnutí), Information Disclosure (zveřejnění informací), Denial of Service (odmítnutí služby) a Elevation of Privilege (zvýšení oprávnění), což je šest kategorií bezpečnostních hrozeb, které musí vývojáři zvažovat v průběhu celého životního cyklu softwaru.
Vytvořeno společností Microsoft na začátku roku 2000Rámec pro modelování hrozeb STRIDE se může zdát jako staromódní přístup. Jeho síla však spočívá v nadčasové jednoduchosti: pomáhá týmům systematicky se ptát: „Co se tu může pokazit?“ Navzdory tomu, jak moc se vývoj v oblasti dodávek softwaru projevil s cloudově nativními architekturami, kontejnerizací a… CI/CD pipelineSTRIDE zůstává velmi relevantní. Dokonale odpovídá potřebám moderní DevSecOps tím, že nabízí praktickou a vývojářům přívětivou metodu proaktivní identifikace a řešení bezpečnostních rizik.
Toto není teoretický model vyhrazený pro audity nebo postmortem analýzy. Model hrozeb STRIDE je vaší mapou pro nalezení slabých míst dříve, než je udělají útočníci. Ať už píšete skript pro nasazení, kontrolujete pull requestnebo propojením služeb třetích stran STRIDE odhaluje úhly, které by útočníci mohli zneužít.
DevSecOps znamená vytvářet bezpečný software od samého začátku. STRIDE vás nezpomaluje, ale jde o snížení počtu překvapení později kontrolou správných věcí hned teď. Neustálé používání rámce pro modelování hrozeb STRIDE posiluje vaši schopnost předvídat a řešit problémy včas.
Stručný přehled: Kategorie STRIDE, které vývojáři musí pochopit
Model hrozeb STRIDE rozděluje hrozby do šesti kategorií. Každá z nich mapuje společné problémy v softwaru a infrastruktuře.
S: Spoofing Identita (Předstírání, kým jste) Riziko: Neoprávnění uživatelé nebo služby, kteří se vydávají za někoho, kým nejsou. Příklad: Napadený běžec CI se vydává za důvěryhodného nasazení a odesílá nebezpečné změny. CI/CD Scénář: Útočník získá přístup k agentovi CI a spustí úlohy, které zdánlivě pocházejí od důvěryhodného člena týmu.
T: Manipulace Riziko spojené s daty nebo kódem (hrát si s vašimi věcmi): Útočníci, kteří bez povšimnutí mění kód, konfigurace nebo artefakty. Příklad: Nepoctivý skript upravuje obraz kontejneru během procesu sestavení. CI/CD Scénář: Krok sestavení je tiše upraven tak, aby nasadil upravený obraz z neoprávněného zdroje.
R: Odmítnutí (Žádný důkaz o tom, kdo co udělal) Riziko: Nedostatek odpovědnosti nebo auditní stopy. Příklad: Sloučení probíhá bez ověření, kdo jej schválil nebo vytvořil. CI/CD Scénář: Sestavení a nasazení se spouštějí bez protokolování, kdo je inicioval, což ztěžuje sledování problémů.
I: Zveřejnění informací (Unikající tajemství) Riziko: Únik citlivých dat v protokolech, sestaveních nebo artefaktech. Příklad: Tajné kódy vytištěné do protokolů během neúspěšného spuštění skriptu. CI/CD Scénář: Proměnné prostředí s tajnými klíči jsou zveřejněny v pipeline protokoly nebo chybové zprávy.
D: Odmítnutí služby (Riziko ničení vašich zdrojů): Procesy nebo služby se stávají nedostupnými kvůli špatné logice nebo zneužití. Příklad: Nekonečné smyčky úloh zahlcují frontu CI. CI/CD Scénář: Nesprávně nakonfigurovaný pipeline spouští se příliš často a spotřebovává veškerou dostupnou kapacitu běžce.
E: Zvýšení privilegií (Získání většího přístupu, než je povoleno) Riziko: Uživatelé nebo služby získávají oprávnění, která by neměli mít. Příklad: A pipeline úloha běží s přístupem na produkční úrovni, který by mít neměla. CI/CD Scénář: Úloha přispěvatele se spouští se zvýšenými oprávněními kvůli nesprávně nakonfigurovaným ovládacím prvkům přístupu.
Modelování hrozeb STRIDE v DevOps: Stručná referenční tabulka
| Kategorie | Riziko DevOps | Příklad reálného světa |
|---|---|---|
| Spoofing | Zosobnění uživatelů nebo služeb | CI runner falšuje produkční deployer |
| Manipulace | Neoprávněné změny kódu nebo konfigurace | Škodlivý skript v nasazení pipeline |
| Odmítnutí | Žádné protokoly ani auditní záznamy pro akce | Sloučit bez commit podpisová nebo auditní stopa |
| Informace o zveřejnění | Únik tajných dat v protokolech nebo sestaveních | Přihlašovací údaje vytištěné do protokolů CI |
| Denial of Service | Vyčerpání zdrojů nebo přerušení pracovního postupu | Rekurzivní pipeline pracovní místa zahlcují běžce |
| Zvýšení privilegií | Nadměrná přístupová oprávnění pro uživatele nebo procesy | dev pipeline token s přístupem k produktu |
Aplikace STRIDE v pracovních postupech DevOps
Spoofing v DevOps CI/CD Pipelines
Neoprávněné procesy se vydávají za důvěryhodné pipeline fáze. Repozitáře: Napadené účty přispěvatelů vkládají škodlivý kód pod legitimní uživatelské jméno. Závislosti: Škodlivé balíčky používají názvy podobné populárním knihovnám (typosquatting), aby vypadaly důvěryhodně.
Manipulace v DevOps CI/CD Pipelines
Upravený skript pro nasazení zamění kontejnery nebo vloží nepoctivé příkazy. Repozitáře: Vynuceně odeslané. commitobcházení kontroly kódu, vkládání zadních vrátek. Závislosti: Škodlivé aktualizace knihoven zavádějí skryté funkce.
Odmítnutí v DevOps CI/CD Pipelines
Nasazení jsou spouštěna bez protokolování, kdo je inicioval. Repozitáře: Nedostatek commit Podepisování znemožňuje ověření původu změn. Závislosti: Změny balíčků jsou načítány bez ověřitelného seznamu změn nebo podpisu.
Zveřejňování informací v DevOps CI/CD Pipelines
Tajné kódy byly zveřejněny ve výstupu protokolu kvůli podrobnému ladění. Úložiště: Soubory .env nebo tajné kódy konfigurace byly omylem odstraněny. committed do správy zdrojového kódu. Závislosti: Balíčky s nesprávně nakonfigurovanými oprávněními zpřístupňují citlivé soubory.
Odmítnutí služby v DevOps CI/CD Pipelines
Přetížené běžce kvůli nekonečným smyčkám triggerů. Repozitáře: Škodlivé příspěvky s extrémně velkými soubory nebo složitými triggery sestavení. Závislosti: Rekurzivní nebo špatně optimalizované knihovny spotřebovávají nadměrné systémové prostředky.
Zvýšení oprávnění v DevOps CI/CD Pipelines
Sdílené tokeny umožňují úlohám bez administrátorských oprávnění provádět administrátorské úkoly. Repozitáře: Git hooks nebo automatizační skripty běží s nepotřebnými oprávněními. Závislosti: Knihovny třetích stran spouštějí instalační skripty s root přístupem během sestavení.
Příklady vložených textů: Před a po použití STRIDE
Příklad odmítnutí: Bez znaménka Commits
Co se opravuje: zabránění neauditovaným sloučením ověřováním commit podpisy.
// Anyone can commit and push, no verification of who or with what identity
git commit -m "update deploy config"
git push origin main
// No branch protection: unsigned, unverified commits merge freely
// .github/settings.yml (missing or absent)Neexistuje žádný podpis, žádný povinný kontrolor a žádný způsob, jak později prokázat, kdo tuto změnu vytvořil nebo zda byla během přenosu upravena.
// Commit signing enabled and enforced locally
git config commit.gpgsign true
git commit -S -m "update deploy config"
git push origin main
// Branch protection requires signed commits before merge
// .github/settings.yml
branches:
- name: main
protection:
required_signatures: true
required_pull_request_reviews:
required_approving_review_count: 1Nyní každý commit on main nese ověřitelný podpis a je nepodepsaný commitjsou odmítnuty na úrovni větve, čímž se uzavírá mezera v odmítnutí.
Příklad zveřejnění informací: Tajné informace v protokolech
Co se opravuje: zabránění úniku tajných informací tím, že se zabrání přímému tisku citlivých proměnných prostředí.
// CI job prints the secret directly to logs for "debugging"
steps:
- name: Deploy
run: |
echo "Using API key: $API_KEY"
curl -H "Authorization: Bearer $API_KEY" https://api.example.com/deployPokud tato úloha selže nebo má člen týmu přístup k protokolu, $API_KEY je nyní uložen v prostém textu v historii CI a viditelný pro kohokoli s oprávněním pro čtení pipeline.
// Secret is referenced, never printed, and CI masks it by default
steps:
- name: Deploy
run: |
curl -H "Authorization: Bearer ${{ secrets.API_KEY }}" https://api.example.com/deploy
env:
API_KEY: ${{ secrets.API_KEY }}Klíč se za běhu načítá z úložiště tajných klíčů CI, nikdy se neodesílá na standardní výstup a většina platforem CI jej v protokolech automaticky maskuje, i když se ve výstupu objeví omylem.
Jak mohou vývojáři aplikovat STRIDE bez bezpečnostních znalostí
Pokud pracujete v DevSecOps, modelování hrozeb by se mělo stát druhou přirozeností. Používáním modelování hrozeb STRIDE jako vodítka během kontrol a nastavení automatizace můžete předvídat problémy dříve, než se dostanou do produkčního prostředí.
Nemusíte být bezpečnostní expert. Stačí se během svého běžného pracovního postupu ptát na otázky založené na platformě STRIDE:
Během kontroly kódu:
- Může si tu někdo zfalšovat identitu?
- Dalo by se s tím manipulovat?
Během CI/CD recenze:
- Jsou někde odhalena tajemství?
- Je každá akce sledovatelná?
Během analýzy závislostí:
- Čerpáme z ověřených zdrojů?
- Mohla by tato závislost zvýšit jeho oprávnění?
A pak automatizujte, co můžete:
- Použijte podepsaný commits
- Implementace podepisování artefaktů
- Nastavení skenování tajných kódů
- Monitorování aktualizací závislostí
Tyto malé kroky uvádějí do provozu model hrozeb STRIDE bez dodatečných režijních nákladů.
Než budete důsledně používat modelování hrozeb STRIDE, je užitečné vědět, kdy a kde zapadá do vašeho pracovního postupu.
Ultimátní průvodce ochranou vašeho CI/CD Pipeline
Naučte se, jak identifikovat, předcházet a reagovat na CI/CD bezpečnostní rizika.
Integrace STRIDE do procesu modelování hrozeb
STRIDE přirozeně zapadá do životního cyklu vývoje jako nenáročný a opakovatelný nástroj pro včasnou identifikaci potenciálních bezpečnostních hrozeb. Nejúčinnější je při konzistentním použití v klíčových fázích:
- Během kontroly kóduPtejte se například: „Může to být zfalšované nebo pozměněné?“ nebo „Existuje pro tuto změnu auditní stopa?“
- Během konfigurace CI/CD PipelinesVyhodnoťte, zda tajemství jsou odhalena, pokud jsou úlohy sledovatelné nebo pokud jsou rozsahy oprávnění příliš široké.
- In Správa závislostíZkontrolujte, zda jsou balíčky třetích stran ověřené, podepsané a zda neobsahují riskantní instalační skripty nebo nadměrný přístup.
- Při plánování nových funkcí nebo služeb, použijte rámec pro modelování hrozeb STRIDE jako kontrolní seznam k brainstormingu, co by se mohlo v každé kategorii hrozeb pokazit.
Díky tomu je modelování hrozeb STRIDE praktickou a proveditelnou součástí vašeho bezpečnostního úsilí, nikoliv těžkopádným procesem, ale spíše součástí každodenního vývoje a DevOps pracovních postupů.
Jak Xygeni mapuje jednotlivé kategorie STRIDE
Xygeni nejenže upozorňuje na rizika, ale také na ně působí napříč celým světem. pipeline.
Zde je návod Xygeni's detekční mapy pro každou kategorii STRIDE v reálném pipeline:
- Spoofing: Příznaky detekce anomálií v Xygeni CI/CD zneužití tokenů a úlohy vydávající se za důvěryhodnou identitu, což upozorní tým, aby bylo možné před spuštěním úlohy rotovat přihlašovací údaje.
- Manipulace: Detekce manipulace s kódem Xygeni identifikuje neoprávněné změny v YAML souboru nasazení, souborech sestavení a IaC šablony a upozorní tým na konkrétní commit a dotčené soubory.
- Odmítnutí: Xygeni vlajky nepodepsané commita vynucují odesílání, které obcházejí ochranu větví, což týmům poskytuje přehled o vynucování podepsanýchcommit zásady před sloučením pozemků.
- Zveřejnění informací: Skenování tajných klíčů Xygeni detekuje odhalené přihlašovací údaje v protokolech, kódu a historii CI, ověřuje, zda jsou stále aktivní, a spouští automatické zrušení pro podporované typy tajných klíčů.
- Odmítnutí služby: Detekce anomálií Xygeni identifikuje neobvyklé CI/CD aktivitu, jako je abnormální doba sestavení nebo četnost úloh, a upozorňuje tým v reálném čase.
- Zvýšení privilegií: Monitorování nejnižších oprávnění od Xygeni identifikuje uživatele s nadměrnými oprávněními nebo neaktivní uživatele a CI/CD tokeny a vystavuje je k nápravě prostřednictvím Health Check vlastnost.
Závěr: STRIDE usnadňuje vývojářům modelování hrozeb
Rámec pro modelování hrozeb STRIDE poskytuje vývojářům jasný a praktický náhled na včasné odhalení rizik. Nepřemýšlejte o tom příliš. Stačí se zeptat: „Co se tu může pokazit?“ pro každou část vašeho kódu, repozitáře, pipeline, nebo závislost.
Modelování hrozeb STRIDE vám pomůže opravit bezpečnostní chyby ještě před jejich spuštěním. A nástroje jako Xygeni vám pomohou automatizovat proces bez zbytečných komplikací.
Začleňte model hrozeb STRIDE do způsobu, jakým píšete, kontrolujete a odesíláte kód. Průběžné modelování hrozeb STRIDE pomáhá udržovat vaši pipelinejsou bezpečné, a to i při jejich škálování a vývoji.
Nejčastější dotazy
Co znamená zkratka STRIDE?
Spoofing, manipulace, odmítnutí, zveřejnění informací, odmítnutí služby a zvýšení oprávnění, šest kategorií, které společnost Microsoft vytvořila pro organizaci bezpečnostních hrozeb.
Potřebuji bezpečnostní vzdělání pro používání STRIDE?
Ne. STRIDE funguje jako kontrolní seznam otázek, jako například „může být toto zfalšováno?“ nebo „je to sledovatelné?“, které mohou vývojáři položit během běžné kontroly kódu a CI/CD konfigurace.
Je STRIDE stále relevantní pro cloudové nativní a CI/CD prostředí?
Ano. Přestože byl vytvořen před kontejnerizací a CI/CD byly standardŠest kategorií STRIDE přímo odráží moderní pipeline rizika jako zneužití tokenů, nepodepsané commita odhalení tajemství.
