Jak udržovat zabezpečené úložiště GitHub

  • 8 min

Tady probereme některé základní nástroje a techniky zabezpečení, které jsou k dispozici správcům úložiště GitHub.

Poznámka

Tento obsah se zaměřuje na **důležité aspekty zabezpečení, nástroje a funkce pro použití v úložišti GitHub.

Důležitost strategie zabezpečeného vývoje

Zabezpečení aplikací je důležité. Informační služby často přenášejí příběhy o nějakém porušení systémů společnosti a soukromých společností a zákaznických dat, která byla odcizena.

Jaké jsou tedy problémy, které je potřeba zvážit při plánování strategie zabezpečeného vývoje? Je zřejmé, že potřebujeme chránit informace před zveřejněním lidem, kteří by k němu neměli mít přístup, ale důležitější je, abychom zajistili, že informace budou změněny nebo zničeny pouze tehdy, když je to vhodné.

Musíme se ujistit, že správně ověřujeme, kdo k datům přistupuje, a že k tomu mají správná oprávnění. Prostřednictvím historických nebo archivních dat nebo protokolů musíme být schopni najít důkaz, když se něco nepovedlo.

Vytváření a nasazování zabezpečených aplikací má mnoho aspektů. Tady jsou tři věci, které je potřeba vzít v úvahu:

  • Existuje obecný problém se znalostmi: Mnoho vývojářů a dalších zaměstnanců předpokládá, že rozumí zabezpečení, ale ne. Kybernetická bezpečnost je neustále se vyvíjející disciplína. Program průběžného vzdělávání a odborné přípravy je nezbytný.

  • Kód musí být správně a bezpečně vytvořen: Musíme mít jistotu, že je kód vytvořen správně a bezpečně implementuje požadované funkce. Musíme se také ujistit, že funkce byly navrženy s ohledem na zabezpečení.

  • Aplikace musí dodržovat pravidla a předpisy: Musíme zajistit, aby kód splňoval požadovaná pravidla a předpisy. Při sestavování kódu musíme testovat dodržování předpisů a pak ho pravidelně testovat, a to i po nasazení.

Zabezpečení v každém kroku

image štítu GitHubu se zabezpečením napsaným pod ním.

Zabezpečení není něco, co můžete přidat později do aplikace nebo systému. Zabezpečený vývoj musí být součástí každé fáze životního cyklu vývoje softwaru. Tento koncept je ještě důležitější pro kritické aplikace a aplikace, které zpracovávají citlivé nebo vysoce důvěrné informace.

V praxi, aby týmy zodpovídaly za to, co vyvíjejí, procesy se musí posunout doleva nebo musí být dokončeny dříve v životním cyklu vývoje. Přesunutím kroků z konečné brány v době nasazení do předchozího kroku dojde k menšímu počtu chyb a vývojáři se můžou rychleji přesunout.

V minulosti se vývojáři nezaměřovali na koncepty zabezpečení aplikací. Kromě problémů se vzděláváním a školením je to proto, že jejich organizace zdůraznily rychlý vývoj funkcí.

S zavedením postupů DevOps je ale snazší integrovat testování zabezpečení do kanálu. Místo toho, aby bylo testování zabezpečení úkolem prováděným specialisty na zabezpečení, mělo by být součástí každodenních procesů.

Celkově platí, že když se bere v úvahu čas pro přepracování, přidání zabezpečení do postupů DevOps dříve v životním cyklu vývoje umožňuje vývojovými týmy zachytit problémy dříve. Zachycení problémů dříve může ve skutečnosti zkrátit celkovou dobu potřebnou k vývoji kvalitního softwaru.

Posun doleva je změna procesu, ale nejedná se o jediný ovládací prvek ani konkrétní nástroj. Jde o to, aby veškerá vaše zabezpečení byla více zaměřena na vývojáře a poskytovala vývojářům zpětnou vazbu v prostředí, kde pracují.

Funkce záložky Zabezpečení

GitHub nabízí funkce zabezpečení, které pomáhají zabezpečit data v úložištích a napříč organizacemi. Chcete-li najít kartu zabezpečení:

  1. Na GitHub.com přejděte na hlavní stránku úložiště.

  2. Pod názvem úložiště vyberte Security.

Snímek obrazovky ukazující, kde na GitHubu najdete kartu Zabezpečení.

Na kartě Zabezpečení můžete do pracovního postupu GitHubu přidat funkce, které vám pomůžou vyhnout se ohrožením zabezpečení v úložišti a základu kódu. Mezi tyto funkce patří:

  • zásady zabezpečení, které umožňují určit, jak v projektu nahlásit ohrožení zabezpečení přidáním souboru SECURITY.md do úložiště.
  • Upozornění Dependabotu, která vás upozorní, když GitHub zjistí, že vaše úložiště používá zranitelnou závislost nebo malware.
  • Bezpečnostní doporučení, pomocí kterých můžete soukromě diskutovat, opravovat a publikovat informace o bezpečnostních zranitelnostech ve vašem úložišti.
  • Skenování kódu, které vám pomůže najít, určit a opravit zranitelnosti a chyby v kódu.
  • Kontrola tajných kódů, která detekuje tokeny, přihlašovací údaje a tajné kódy potvrzené do vašeho úložiště, a může je před odesláním zablokovat. Ochrana nabízených oznámení je ve výchozím nastavení povolená ve veřejných úložištích.

Další informace najdete v tématu funkce zabezpečení GitHubu.

Dále prozkoumáme některé z těchto funkcí a naučíme se, jak distribuovat bezpečnostní a provozní zodpovědnosti napříč všemi fázemi životního cyklu vývoje softwaru.

Sdílejte zásady zabezpečení pomocí SECURITY.md

Výhody komunity GitHubu jsou podstatné, ale také nesou potenciální rizika. Skutečnost, že kdokoli může navrhnout opravy chyb veřejně, přichází s určitými zodpovědnostmi. Nejdůležitější je zodpovědné zpřístupnění informací, které by mohly vést k zneužití zabezpečení dříve, než je možné opravit jejich základní chyby. Vývojáři, kteří chtějí nahlásit nebo řešit problémy se zabezpečením, hledají soubor SECURITY.md v kořenovém adresáři úložiště, aby mohli zodpovědně sdělit své obavy. Poskytnutí pokynů v tomto souboru nakonec urychlí řešení těchto kritických problémů.

Další informace o SECURITY.mdnajdete v tématu Přidání zásad zabezpečení do úložiště.

Poradce zabezpečení GitHubu

Informační zpravodaje zabezpečení GitHubu umožňují správci úložišť soukromě diskutovat a opravovat ohrožení zabezpečení v projektu. Jakmile správci úložiště spolupracují na opravě, mohou zveřejnit bezpečnostní upozornění, aby veřejně oznámili zranitelnost zabezpečení komunitě projektu. Publikováním poradce pro zabezpečení správci úložišť usnadňují komunitě aktualizaci závislostí balíčků a zkoumání důsledků ohrožení zabezpečení. GitHub ukládá publikovaná upozornění v seznamu běžných zranitelností a expozic (CVE). Tento seznam slouží k automatickému upozorňování ovlivněných úložišť, která používají software s uvedenou chybou zabezpečení. Pro více informací viz Bezpečnostní upozornění úložiště.

Udržování citlivých souborů mimo úložiště pomocí .gitignore

Vývojáři snadno přehlédnou soubory zahrnuté do potvrzení. Někdy jsou tyto přehlížené soubory neškodné, například přechodné soubory sestavení. Existuje však vždy riziko, že někdo neúmyslně zveřejní citlivá data. Někdo může například potvrdit klíč rozhraní API nebo soukromá konfigurační data, která by mohl použít objekt actor se zlými úmysly. Jednou z technik, jak se tomuto riziku vyhnout, je vytváření a údržba .gitignore souborů. Tyto soubory dávají klientským nástrojům, jako je nástroj příkazového řádku git, ignorovat cesty a vzory při agregaci souborů pro potvrzení.

Následující ukázka ukazuje některé běžné případy použití pro ignorování souborů:

# User-specific files - Ignore all files ending in ".suo"
*.suo

# Mono auto generated files - Ignore all files starting with "mono_crash."
mono_crash.*

# Build results - Ignore all files in these folders found at any folder depth
[Dd]ebug/
[Rr]elease/
x64/
x86/

# Root config folder - Ignore this directory at the root due to leading slash
# Removing the slash would ignore "config" directories at all depths 
/config

# Ignore intermediate JS build files produced during TypeScript build at any 
# folder depth under /Web/TypeScript. This won't ignore JS files elsewhere. 
/Web/TypeScript/**/*.js

Úložiště může obsahovat několik .gitignore souborů. Nastavení se dědí z nadřazených adresářů, přičemž přepsání polí v nových .gitignore souborech má přednost před nadřazeným nastavením pro jejich složky a podsložky. Je to značná námaha udržovat kořenový soubor .gitignore, i když přidání souboru .gitignore do adresáře projektu může být užitečné, pokud má tento projekt specifické požadavky, které je jednodušší udržovat odděleně od nadřazeného objektu, například soubory, které by neměly být ignorovány.

Další informace o .gitignorenajdete v tématu Ignorování souborů. Podívejte se také na kolekci počátečních .gitignore souborů nabízených pro různé platformy v úložišti gitignore.

Odebrání citlivých dat z úložiště

I když mohou být .gitignore soubory užitečné pro to, aby se přispěvatelé vyhnuli potvrzení citlivých dat, jsou jen silným doporučením. Vývojáři můžou soubor dál obejít .gitignore a přidat soubory, pokud jsou dostatečně motivovaní, a někdy se může stát, že soubory proklouznou, protože nesplňují .gitignore konfiguraci souboru. Účastníci projektu by měli být vždy na pozoru před commity, které obsahují data, jež by neměla být zahrnuta do úložiště nebo jeho historie.

Důležitý

Měli byste předpokládat, že v jakémkoli okamžiku došlo k ohrožení všech dat potvrzených do GitHubu. Přepsání commitu samo o sobě nestačí k zajištění, že data nebudou v budoucnu přístupná. Kompletní průvodce odebráním citlivých dat z GitHubu najdete v tématu Odebrání citlivých dat z úložiště.

Pravidla ochrany větví

Můžete vytvořit pravidlo ochrany větví k vynucení určitých pracovních postupů pro jednu nebo více větví. Můžete například vyžadovat schválení revize nebo úspěšné splnění kontrol stavu pro všechny žádosti o přijetí změn, které jsou sloučeny do chráněné větve.

Pracovní postupy, které chrání větev, můžete použít k:

  • Spuštěním sestavení ověřte, že lze zkompilovat změny kódu.
  • Spuštěním linteru zkontrolujte překlepy a soulad s interními konvencemi kódování;
  • Spuštěním automatizovaných testů zkontrolujte případné změny chování kódu;
  • A tak dále.

Povinní kontroloři v žádostech o přijetí změn

Zabezpečení úložiště můžete zlepšit vyžadováním kontrol před sloučením kódu do důležitých větví. Povinní kontroloři pomáhají vynucovat kvalitu, zabezpečení a odpovědnost.

Konfigurace požadovaných revidujících:

  1. Přejděte do úložiště na GitHubu.
  2. Pod názvem úložiště klikněte na Nastavení>větví.
  3. Vedle větve, kterou chcete chránit, klikněte na Přidat pravidlo nebo upravit existující pravidlo.
  4. Před sloučením vyberte Vyžadovat kontroly žádostí o přijetí změn.
  5. Volitelně zaškrtněte:
    • Vyžadovat kontrolu od vlastníků kódu
    • Zavření zastaralých schválení žádostí o přijetí změn při vložení nových potvrzení
    • Požadovat schválení od někoho jiného než posledního nabízení

Požadované kontroly se nedají obejít bez oprávnění správce. Před sloučením zajistí, aby navrhované změny zkontroloval jiný přispěvatel nebo určený vlastník kódu.

Další podrobnosti najdete v tématu o chráněných větvích.

Přidejte soubor CODEOWNERS

Přidáním souboru CODEOWNERS do úložiště můžete přiřadit jednotlivé členy týmu nebo celé týmy jako vlastníky kódu k cestám v úložišti. Tito vlastníci kódu jsou pak vyžadováni pro revize pull-requestů pro změny souborů ve složkách, pro které jsou nakonfigurované.

# Changes to files with the js extensions need to be reviewed by the js-owner user/group:
*.js    @js-owner

# Changes to files in the builds folder need to be reviewed by the octocat user/group:
/build/ @octocat

Soubor CODEOWNERS můžete vytvořit buď v kořenovém adresáři úložiště, nebo ve složce docs nebo .github.