search

NUKIB / bezpecnostni-doporuceni-open-source

Bezpečnostní doporučení pro vývoj otevřeného software ve veřejné správě
53 stars 12 forks source link

Míra obecnosti bezpečnostních doporučení #5

Closed MikkCZ closed 2 years ago

MikkCZ commented 2 years ago

Jak obecná nebo naopak konkrétní má očekávaná výsledná verze tohoto dokumentu být? V #4 navrhuji doplnit informace k validaci vstupů, protože to v obecnosti pokrývá velkou třídu bezpečnostních rizik. Pak ale existují další velmi populární útoky a zneužívané bezpečnostní chyby, na které by stálo za to upozornit, ať už co se výsledného softwaru týče, nebo procesu a infrastruktury pro jeho vývoj.

Pokud by měla doporučení zůstat obecnější v zájmu stručnosti dokumentu, navrhoval bych alespoň zmínit nutnost dodržovat při vývoji opatření proti zavedení chyb z OWASP Top 10.

KaliszAd commented 2 years ago

Řada těch doporučení je očividně zaměřená na staticky typovaný, kompilovaný kód s manuální správou paměti i když je jsou zde samozřejmě opačné příklady a doporučení. Obecně dokument doporučuje věci, které jsou při vývoji relativně podružné, ale působí takovým cargo kultem. https://cs.wikipedia.org/wiki/Cargo_kult

Automatické sestavení je fajn a je celkem blbost to nedělat. Ale psát testy a projíždět je po každém commitu je třeba strašně populární a jakoby solidní v praxi ale v některých pokročilých jazycích kde mají např. funkční REPL a hot-code reloading tento přístup spíše opouštějí, protože šíleně zpomaluje vývoj a nepřidává zase takové garance. Taky je samozřejmě blbost spouštět testy na změnu gramatiky v komentářích. To samé 2FA: je strašně populární, ale v praxi se má prostě na věci používat password manager a tam je potom 2FA akorát otrava navíc - útok na heslo, hádání hesla nedává smysl a pokud Vám heslo někdo ukradl, máte nejspíš problém úplně jiných rozměrů a žádné 2FA Vám zásadně nepomůže. To samé s HSM moduly, ve většině případů je to divadlo a zbytečný výdaj navíc.

Na druhou stranu očividně dokument vůbec neřeší, že moderní systém by měl být aspoň do nějaké míry live-patchovatelný a že to je možná nutné nějak zohlednit. Třeba když někam vystavujete port pro připojení REPLu, aby tam byl správně default na localhost místo 0.0.0.0 resp. [::]. Obecně ke konfiguracím a jejich formě se tam nic moc nepíše.

MikkCZ commented 2 years ago

Řada těch doporučení je očividně zaměřená na staticky typovaný, kompilovaný kód s manuální správou paměti i když je jsou zde samozřejmě opačné příklady a doporučení.

Z čeho prosím vycházíte? Pročetl jsem sice dokument dost z rychlíku, ale přijde mi dost neutrální vůči konkrétních technologiím.

dokument doporučuje věci, které jsou při vývoji relativně podružné, ale působí takovým cargo kultem

Myslíte, že by měl být dokument ještě obecnější a povznést se nad konkrétní doporučení, nebo naopak konkrétněji vysvětlit důvody pro každý bod? Já osobně si myslím, že stačí najít správný balanc mezi oběma směry. O vývoji softwaru je spousta chytrých knížek, ale trvá dlouho je přečíst a ještě déle pochopit a osvojit, a naopak zbytečně zabíhat do detailů bude na úkor obecné použitelnosti. Já tenhle dokument vidím velmi blízko tomu být ideální krátkou osvětovou příručkou, která se dá alespoň částečně rovnou aplikovat. I když dokonalá zatím není, a od toho ji určitě @NUKIB vystavil takto veřejně, abychom ji mohli připomínkovat. ;)

psát testy a projíždět je po každém commitu je třeba strašně populární

Continuous integration potažmo continuous delivery není jen o spouštění testů, a pokud ho máte (a máte testy), tak třeba podle mě taky neexistuje důvod je nespouštět. Myšleno v rámci pull/merge requestu apod.

To samé 2FA: je strašně populární, ale v praxi se má prostě na věci používat password manager

Správce přihlašovacích údajů je samozřejmě dobrá věc, ale na rozdíl od MFA ho nelze systémově vynutit a principiálně ho nenahradí.

pokud Vám heslo někdo ukradl, máte nejspíš problém úplně jiných rozměrů a žádné 2FA Vám zásadně nepomůže

Dovolím si nesouhlasit. Pokud uživateli uteče heslo - omylem vložení do vyhledávače nebo někde do chatu, MFA to zachrání. Navíc je uvedené opatření v dokumentu směřováno i na přihlašování k infrastruktuře (GitHub, CI/CD, ...), nejen do administrace vyvíjeného nebo spravovaného systému.

Obecně ke konfiguracím a jejich formě se tam nic moc nepíše.

S tímhle souhlasím a myslím, že by si dokument zasloužil doplnit informace o tom, jak software vyvíjet s ohledem na následný bezpečný provoz v různých prostředích. Přecijen bavíme se o open source, a tak bude typicky více instancí spravovaných více subjekty, které se ne vývoji nemusí ani přímo podílet. Pak už je dobré se bavit nejenom o výchozí konfiguraci (portů apod.), ale hlavně o konfigurovatelnosti (aby to vůbec šlo konfigurovat pro různá nasazení a potřeby). I proto jsem svůj dotaz položil.

MikkCZ commented 2 years ago

měl být aspoň do nějaké míry live-patchovatelný

port pro připojení REPLu, aby tam byl správně default na localhost místo 0.0.0.0 resp. [::]

Pro jistotu zopakuji, že nejsem autor příručky, ale jen kolemjdoucí stejně, jako vy. Ale podle toho, jak dokument zatím vypadá, bych v něm pro obě tyto věci čekal maximálně nefunkcionální požadavky na rychlost otočky a provozní podmínky pro nasazování změn, respektive zajištění zabezpečeného přístupu do rozhraní aplikace. Na druhou stranu to jsou obojí požadavky, které silně závisí na konkrétní aplikaci a nemají nutně nic společného s open source.

KaliszAd commented 2 years ago

Řada těch doporučení je očividně zaměřená na staticky typovaný, kompilovaný kód s manuální správou paměti i když je jsou zde samozřejmě opačné příklady a doporučení.

Z čeho prosím vycházíte? Pročetl jsem sice dokument dost z rychlíku, ale přijde mi dost neutrální vůči konkrétních technologiím.

Protože CI zde zaručuje, že se program zkompiluje aspoň tam, ideálně se provedou testy kontrolující základní přehmaty, které se prostě v těch jazycích dějí pořád dokola. Je to prostě tento způsob myšlení, že když jedna funkce kdysi fungovala, už fungovat nemusí, protože se software napsal šíleně konkrétně a nový vstup i u triviálních věcí není nutně podporovaný, protože jinak by se programátor u definování struktur/ objektů musel zbláznit.

dokument doporučuje věci, které jsou při vývoji relativně podružné, ale působí takovým cargo kultem

Myslíte, že by měl být dokument ještě obecnější a povznést se nad konkrétní doporučení, nebo naopak konkrétněji vysvětlit důvody pro každý bod? Já osobně si myslím, že stačí najít správný balanc mezi oběma směry. O vývoji softwaru je spousta chytrých knížek, ale trvá dlouho je přečíst a ještě déle pochopit a osvojit, a naopak zbytečně zabíhat do detailů bude na úkor obecné použitelnosti. Já tenhle dokument vidím velmi blízko tomu být ideální krátkou osvětovou příručkou, která se dá alespoň částečně rovnou aplikovat. I když dokonalá zatím není, a od toho ji určitě @NUKIB vystavil takto veřejně, abychom ji mohli připomínkovat. ;)

Třeba si myslím, že 2FA přístup k repozitáři je třešnička na dortu, to samé jako CI když nepočítáme automatické sestavení, což má skutečný přínos a je to praktické. Míchají se zde tyto "bonusové" věci pro hodně přísná nasazení s věcmi, které jsou vhodné i u relativních drobností. Pedagogicky/ politicky je lepší mít něco, na co můžu ukázat a říct konrétnímu projektu, "tohle je úplný základ a vy nesplňujete ani to", než dokument, který míchá úplný základ a relativně pokročilé a hlavně neesenciální přístupy.

psát testy a projíždět je po každém commitu je třeba strašně populární

Continuous integration potažmo continuous delivery není jen o spouštění testů, a pokud ho máte (a máte testy), tak třeba podle mě taky neexistuje důvod je nespouštět. Myšleno v rámci pull/merge requestu apod.

Ano, v rámci pull/ merge requestu nebo před releasem to určitě smysl dává. Pokud ale projekt CI nemá, není to dostatečné kritérium projekt odepsat, že není dostatečně profesionální či robustní. Však definice bugu v produkci je, že prošel přes všechny testy a kontroly.

To samé 2FA: je strašně populární, ale v praxi se má prostě na věci používat password manager

Správce přihlašovacích údajů je samozřejmě dobrá věc, ale na rozdíl od MFA ho nelze systémově vynutit a principiálně ho nenahradí.

Na tom je kus pravdy. Ale je to zase do velké míry takové pravidlo typu "kvůli jednorázové neopatrnosti jednoho člověka, kterou šlo poměrně triviálně opravit" teď trpíme všichni pořád. Protože ruku na srdce, kdyby každý login vyžadoval opravdu pořád přihlášení i druhým, skutečně nezávislým faktorem, tak za chvíli nebude dělat nikdo nic, protože to je prostě otrava. Třeba vím, že cokoliv bankovního mě teď štve, protože mi banka naordinovala všude dost otřesnou implementaci 2FA - a já se to teda snažím dělat "správně" - mít skutečně random heslo i na ten token, že se tomu teď vědomě snažím vyhnout.

pokud Vám heslo někdo ukradl, máte nejspíš problém úplně jiných rozměrů a žádné 2FA Vám zásadně nepomůže

Dovolím si nesouhlasit. Pokud uživateli uteče heslo - omylem vložení do vyhledávače nebo někde do chatu, MFA to zachrání. Navíc je uvedené opatření v dokumentu směřováno i na přihlašování k infrastruktuře (GitHub, CI/CD, ...), nejen do administrace vyvíjeného nebo spravovaného systému.

Ano, od toho je možnost změnit heslo. Jinak teda když někde vložím náhodný string, tak to ještě rozhodně nevede ke kompromitaci mého účtu někde. Zkrátka, na ten reset hesla mám v absolutní většině případů dost času. Pokud MFA, tak jen na případy, které jsou mimo vzor chování - protože to otravuje typicky minimálně a ořeže absolutní většinu potenciálních útoků. Tento přístup je ale opravdu už poměrně pokročilý.

Obecně ke konfiguracím a jejich formě se tam nic moc nepíše.

S tímhle souhlasím a myslím, že by si dokument zasloužil doplnit informace o tom, jak software vyvíjet s ohledem na následný bezpečný provoz v různých prostředích. Přecijen bavíme se o open source, a tak bude typicky více instancí spravovaných více subjekty, které se ne vývoji nemusí ani přímo podílet. Pak už je dobré se bavit nejenom o výchozí konfiguraci (portů apod.), ale hlavně o konfigurovatelnosti (aby to vůbec šlo konfigurovat pro různá nasazení a potřeby). I proto jsem svůj dotaz položil.

Zhruba tak. Třeba pokud projekt umožňuje konfigurovatelnost, aby nevymýšleli další syntaxi, ale prostě použili nějaký JSON s komentáři, nebo INI nebo tak, aby se to dalo manipulovat nějak rozumně automaticky např. z Ansible. Ať jsou přibalené typické příklady, ať je defaultní nastavení rozumné - třeba pokud je potřeba vytvořit nějaké heslo, ať není možné zadat prázdné heslo a zároveň software rovnou vystavit do internetu. Ať software poslouchá na localhostu dokud admin neřekne explicitně jinak. U nástrojů na desktop by třeba bylo fajn doporučit, kdyby lidé balíček přidali do scoop nebo chocolatey, pokud se jedná o Windows nebo měli aktuální verzi hotového balíčku na určité statické URL, aby se to dalo naskriptovat a udržovat automaticky.

Vlastně, když už se o tom všem bavíme, asi by bylo nejlepší mít 2 příklady. Jeden nástroj např. pro desktopy a druhý client-server projektík, který všechny ty aspekty splňuje, který je možné upravit prostě k obrazu svému a odpíchnout se od toho jednoduchým forkem zde na GitHubu. Však bohatě stačí nějaký relativně triviální příklad, kde je ale možné ukázat např. ošetření toho vstupu, nebo jak se teda aktivně zbavovat těch secrets v paměti, nebo řešit tu bezpečnou perzistenci, logging apod. Jinak celý ten text nebude mít svoji váhu, když to vlastně nikdo neumí ukázat na příkladu.

KaliszAd commented 2 years ago

měl být aspoň do nějaké míry live-patchovatelný

port pro připojení REPLu, aby tam byl správně default na localhost místo 0.0.0.0 resp. [::]

Pro jistotu zopakuji, že nejsem autor příručky, ale jen kolemjdoucí stejně, jako vy. Ale podle toho, jak dokument zatím vypadá, bych v něm pro obě tyto věci čekal maximálně nefunkcionální požadavky na rychlost otočky a provozní podmínky pro nasazování změn, respektive zajištění zabezpečeného přístupu do rozhraní aplikace. Na druhou stranu to jsou obojí požadavky, které silně závisí na konkrétní aplikaci a nemají nutně nic společného s open source.

Ano, u desktopového nástroje na krátké použití (řekněme nějaký skript) live-patchování nečekám. :-) U něčeho, co má běžet prakticky non-stop buď musím podporovat clustering, nebo live-patching, aby bylo možné aktualizovat během normálních pracovních/ úředních hodin s minimálním (řekněme do 15 sekund?), nebo žádným výpadkem. Jinak se obávám, že budeme lovit neaktuální verze.

ondj commented 2 years ago

@MikkCZ: Jak obecná nebo naopak konkrétní má očekávaná výsledná verze tohoto dokumentu být?

Ve státní správě se používají různé technologie a jazyky. A i při použití stejných technologií míra bezpečnosti velmi závisí na určení systému - od systému pro rezervaci termínu na vyzvednutí občanky až po komunikační systém IZS. Proto jsme zvolili obecnou formu doporučení, ale s uvedením příkladů v určitých jazycích.

@KaliszAd: Řada těch doporučení je očividně zaměřená na staticky typovaný, kompilovaný kód s manuální správou paměti i když je jsou zde samozřejmě opačné příklady a doporučení.

To určitě není záměr. Které pravidlo podle Vás směřuje na staticky typované jazyky?

@KaliszAd: Obecně dokument doporučuje věci, které jsou při vývoji relativně podružné, ale působí takovým cargo kultem.

Které konkrétně?

@KaliszAd: To samé 2FA: je strašně populární, ale v praxi se má prostě na věci používat password manager a tam je potom 2FA akorát otrava navíc - útok na heslo, hádání hesla nedává smysl a pokud Vám heslo někdo ukradl, máte nejspíš problém úplně jiných rozměrů a žádné 2FA Vám zásadně nepomůže. To samé s HSM moduly, ve většině případů je to divadlo a zbytečný výdaj navíc.

Jak správně uvádí @MikkCZ, používání password managerů nelze technicky vynutit, což je vždy výhoda. Současné systémy 2FA jsou již navíc uživatelsky přívětivé, že neexistuje moc důvodů, proč 2FA nevyužít.

@KaliszAd: Obecně ke konfiguracím a jejich formě se tam nic moc nepíše.

Zvážíme doplnění doporučení o sekci, která by se věnovala výchozímu nastavení aplikace.

@KaliszAd: Pokud ale projekt CI nemá, není to dostatečné kritérium projekt odepsat, že není dostatečně profesionální či robustní.

Z naší zkušenosti s open-source projekty se ukazuje, že někteří vývojáři jsou schopni commitovat přímo do masteru syntaktycky nevalidní soubory nebo nevyřešené merge konflikty. Proto by každý projekt měl obsahovat alespoň základní CI zaměřující se na validování syntaxe, u kompilovaných jazyků alespoň schopnost projekt zkompilovat.

@KaliszAd: Jeden nástroj např. pro desktopy a druhý client-server projektík, který všechny ty aspekty splňuje, který je možné upravit prostě k obrazu svému a odpíchnout se od toho jednoduchým forkem zde na GitHubu.

Tohle je nereálný požadavek. Státní správa není homogenní prostředí, využívají se různé jazyky, frameworky, technologie. Budou se využívat různé nástroje na správu kódu. Každý dodavatel taktéž pracuje jiným způsobem. Proto je potřeba spíše nastavit obecná doporučení, ze kterých by se pak konkrétní úřad/dodavatel měl vytvořit pravidla na míru určená pro jejich prostředí.

pavelsterba commented 2 years ago

Z naší zkušenosti s open-source projekty se ukazuje, že někteří vývojáři jsou schopni commitovat přímo do masteru syntaktycky nevalidní soubory nebo nevyřešené merge konflikty. Proto by každý projekt měl obsahovat alespoň základní CI zaměřující se na validování syntaxe, u kompilovaných jazyků alespoň schopnost projekt zkompilovat.

Tohle je nereálný požadavek. Státní správa není homogenní prostředí, využívají se různé jazyky, frameworky, technologie. Budou se využívat různé nástroje na správu kódu. Každý dodavatel taktéž pracuje jiným způsobem. Proto je potřeba spíše nastavit obecná doporučení, ze kterých by se pak konkrétní úřad/dodavatel měl vytvořit pravidla na míru určená pro jejich prostředí.

@ondj nechci utíkat od původního tématu, ale nestálo by za to mít pro potřeby státní správy nějaký vlastní "hosting"? Kvůli různým technologiím spíše formou třeba předkonfigurovaných VPS (pro Python, PHP, Go...), ale k tomu i interní GIT, podporu pro CI...? Úřad/dodavatel by dostal železo a nastavil si pipeline pro deploy.

chovanecm commented 2 years ago

@pavelsterba Tak velké státy mají dokonce government cloud třeba u AWS apod. Ale to už je fakt OT, omlouvám se :-)

KaliszAd commented 2 years ago

@MikkCZ: Jak obecná nebo naopak konkrétní má očekávaná výsledná verze tohoto dokumentu být?

Ve státní správě se používají různé technologie a jazyky. A i při použití stejných technologií míra bezpečnosti velmi závisí na určení systému - od systému pro rezervaci termínu na vyzvednutí občanky až po komunikační systém IZS. Proto jsme zvolili obecnou formu doporučení, ale s uvedením příkladů v určitých jazycích.

Dovolím si k tomu něco poznamenat. Ano, však to nikdo nerozporuje. Jenom bych možná připomněl, že všechny zmíněné jazyky vznikly ve 20. století a je to na nich prostě vidět i když prošly nějakým vývojem. Většina z nich už v době vzniku nebyla nějak výrazně pokroková. Je to myslím dobrý podnět pro zamyšlení.

@KaliszAd: Řada těch doporučení je očividně zaměřená na staticky typovaný, kompilovaný kód s manuální správou paměti i když je jsou zde samozřejmě opačné příklady a doporučení.

To určitě není záměr. Které pravidlo podle Vás směřuje na staticky typované jazyky?

Viz moje odpověď včera: "Protože CI zde zaručuje, že se program zkompiluje aspoň tam, ideálně se provedou testy kontrolující základní přehmaty, které se prostě v těch jazycích dějí pořád dokola. Je to prostě tento způsob myšlení, že když jedna funkce kdysi fungovala, už fungovat nemusí, protože se software napsal šíleně konkrétně a nový vstup i u triviálních věcí není nutně podporovaný, protože jinak by se programátor u definování struktur/ objektů musel zbláznit."

@KaliszAd: Obecně dokument doporučuje věci, které jsou při vývoji relativně podružné, ale působí takovým cargo kultem.

Které konkrétně?

Psal jsem to ve threadu výše. Tak jen v bodech: HSM, CI/CD na každý commit, 2FA, kontrola "života" knihovny, což možná sedí u nějaké JavaScriptové knihovny, ale u řady i dost populárních knihoven např. ze světa Clojure toto často může být zavádějící doporučení. (např. https://github.com/davidsantiago/pathetic nebo https://github.com/davidsantiago/hickory)

@KaliszAd: To samé 2FA: je strašně populární, ale v praxi se má prostě na věci používat password manager a tam je potom 2FA akorát otrava navíc - útok na heslo, hádání hesla nedává smysl a pokud Vám heslo někdo ukradl, máte nejspíš problém úplně jiných rozměrů a žádné 2FA Vám zásadně nepomůže. To samé s HSM moduly, ve většině případů je to divadlo a zbytečný výdaj navíc.

Jak správně uvádí @MikkCZ, používání password managerů nelze technicky vynutit, což je vždy výhoda. Současné systémy 2FA jsou již navíc uživatelsky přívětivé, že neexistuje moc důvodů, proč 2FA nevyužít.

Jak už jsem psal, ne nejsou. Resp. ano, řadu z nich lze ohnout, aby to jakoby přívětivé bylo, ale potom to už je často výrazně méně bezpečné, vyžaduje ale pořád řadu kroků navíc.

@KaliszAd: Obecně ke konfiguracím a jejich formě se tam nic moc nepíše.

Zvážíme doplnění doporučení o sekci, která by se věnovala výchozímu nastavení aplikace.

@KaliszAd: Pokud ale projekt CI nemá, není to dostatečné kritérium projekt odepsat, že není dostatečně profesionální či robustní.

Z naší zkušenosti s open-source projekty se ukazuje, že někteří vývojáři jsou schopni commitovat přímo do masteru syntaktycky nevalidní soubory nebo nevyřešené merge konflikty. Proto by každý projekt měl obsahovat alespoň základní CI zaměřující se na validování syntaxe, u kompilovaných jazyků alespoň schopnost projekt zkompilovat.

Ano, chápu. Je to ale zase rovnák na ohýbák, který se prostě třeba v jazycích se strukturálním editováním a hot-code reloadem neděje. Editor by na Vás řval, aplikace by Vám nejela a při vývoji to je vidět prostě hned.

@KaliszAd: Jeden nástroj např. pro desktopy a druhý client-server projektík, který všechny ty aspekty splňuje, který je možné upravit prostě k obrazu svému a odpíchnout se od toho jednoduchým forkem zde na GitHubu.

Tohle je nereálný požadavek. Státní správa není homogenní prostředí, využívají se různé jazyky, frameworky, technologie. Budou se využívat různé nástroje na správu kódu. Každý dodavatel taktéž pracuje jiným způsobem. Proto je potřeba spíše nastavit obecná doporučení, ze kterých by se pak konkrétní úřad/dodavatel měl vytvořit pravidla na míru určená pro jejich prostředí.

Nemyslím si. Základní Django/ Flask appku s úplně primitivním formulářem zde na GitHubu jistě zveřejnit lze. To samé třeba nějaký PowerShellový/ Bashový skript. Prostě nějaký repozitář, který by ukázal, jak rozchodit úplné minimum těch požadavků, co jsme si tu navymýšleli. Však se na to dodavatel může a nemusí podívat, ale může se tím řídit veřejnost nebo malí dodavatelé, kteří třeba chtějí jít s kvalitou nahoru a už nějakou "appku" třeba v tom Pythonu dodávají.

Alternativně lze aspoň vypíchnout pár projektů, které to tedy dělají jako "správně" a popsat proč si to myslíme. Třeba dobrý příklad je podle mě NetBox, což je přesně nástroj, který by mohl na řadě úřadů ulehčit správu infrastruktury. Třeba ale namají SECURITY.txt, což může být v doporučení okomentováno, že tu je pár věcí, kde by se i oni mohli ještě zlepšit. Zrovna tak je docela dobrý příklad třeba Icinga což je blízký příbuzný Nagiosu, taky bez SECURITY.txt.

Na druhou stranu je tu třeba desktopový nástroj NAPS2 na jednodušší skenování, který možná nesplňuje těch doporučení vícero, ale zase to je poměrně ohraničený a velmi užitečný desktopový software. Myslím, že např. LibreOffice tak dobrý příklad není, protože to je extrémně komplexní projekt, takže se z něj jen špatně "okoukává".

KaliszAd commented 2 years ago

Z naší zkušenosti s open-source projekty se ukazuje, že někteří vývojáři jsou schopni commitovat přímo do masteru syntaktycky nevalidní soubory nebo nevyřešené merge konflikty. Proto by každý projekt měl obsahovat alespoň základní CI zaměřující se na validování syntaxe, u kompilovaných jazyků alespoň schopnost projekt zkompilovat.

Tohle je nereálný požadavek. Státní správa není homogenní prostředí, využívají se různé jazyky, frameworky, technologie. Budou se využívat různé nástroje na správu kódu. Každý dodavatel taktéž pracuje jiným způsobem. Proto je potřeba spíše nastavit obecná doporučení, ze kterých by se pak konkrétní úřad/dodavatel měl vytvořit pravidla na míru určená pro jejich prostředí.

@ondj nechci utíkat od původního tématu, ale nestálo by za to mít pro potřeby státní správy nějaký vlastní "hosting"? Kvůli různým technologiím spíše formou třeba předkonfigurovaných VPS (pro Python, PHP, Go...), ale k tomu i interní GIT, podporu pro CI...? Úřad/dodavatel by dostal železo a nastavil si pipeline pro deploy.

@pavelsterba @chovanecm to jde opravdu už hodně daleko. Nikdo nebrání lidem ze státní správy rozjet veřejný vývoj klidně třeba na GitHubu. Jsou zde GitHub Pages i GitHub Actions. Podobně to bude na GitLabu. Hosting ve veřejné správě je už nějak v provozu, státní cloud se nějak řeší: https://www.lupa.cz/aktuality/vnitro-zverejnilo-nabidky-sesti-zajemcu-o-poskytovani-statniho-cloudu/ Myslím, že tohle je od záměru dokumentu skutečně hodně daleko. Ale samozřejmě, může se vyčlenit dokument, který sbírá nějaký základ k provozu veřejně vyvinutého softwaru.

MikkCZ commented 2 years ago

@KaliszAd: To samé 2FA: je strašně populární, ale v praxi se má prostě na věci používat password manager a tam je potom 2FA akorát otrava navíc - útok na heslo, hádání hesla nedává smysl a pokud Vám heslo někdo ukradl, máte nejspíš problém úplně jiných rozměrů a žádné 2FA Vám zásadně nepomůže. To samé s HSM moduly, ve většině případů je to divadlo a zbytečný výdaj navíc.

Jak správně uvádí @MikkCZ, používání password managerů nelze technicky vynutit, což je vždy výhoda. Současné systémy 2FA jsou již navíc uživatelsky přívětivé, že neexistuje moc důvodů, proč 2FA nevyužít.

Jak už jsem psal, ne nejsou. Resp. ano, řadu z nich lze ohnout, aby to jakoby přívětivé bylo, ale potom to už je často výrazně méně bezpečné, vyžaduje ale pořád řadu kroků navíc.

Zdá se, že tady se budeme rozcházet v subjektivním názoru, co je a není přívětivé. Za sebe opisování SMS kódu moc rád nemám, ale zvednout telefon a potvrdit nějakou akci skrze push notifikaci z aplikace (např. Duo či PingID) nebo hardwarový token (YubiKey) mi problém nedělá. Typicky je to navíc potřeba jenom při přihlášení nebo potvrzení nějaké riskantnější akce, rozhodně ne při každém commitu ani nic podobného, co bych dělal několikrát denně. Samozřejmě, nemuset dělat nic z toho by bylo rychlejší, ale v tomto případě asi neexistuje bezpečnostní opatření, které by mělo smysl a zároveň jsem pro něj nemusel vůbec nic udělat.

ondj commented 2 years ago

@KaliszAd: Tak jen v bodech: HSM, CI/CD na každý commit, 2FA, kontrola "života" knihovny

U každého doporučení je potřeba zvážit, zda se hodí na konkrétní projekt, u některých projektů si dovedu představit, že můžou působit i kontraproduktivně. Zkusím ale vysvětlit, proč tato pravidla obecně dávají smysl.

@pavelsterba nechci utíkat od původního tématu, ale nestálo by za to mít pro potřeby státní správy nějaký vlastní "hosting"?

Jak uvádí @KaliszAd, něco se připravuje v rámci státní správy, ale dokument má širší zacílení (třeba i na samosprávy) a bez vazby na konkrétní technologie.

KaliszAd commented 2 years ago

@ondj díky za diskuzi, Vaším bodům rozumím - sám se jimi řídím. Jenom znám lidi, jak už se osypou jenom když člověk řekne správce hesel. Nedokážu si představit, jak by se někteří z nich tvářili na "kryptografický token" pro 2FA a jakýkoliv výdaj z jejich pohledu navíc. Proto jsem zde navrhoval jasně říct, co je úplný základ a co už je bonus.

Jinak ohledně projektu Pathetic: Ano, PR je otevřené a očividně knihovna udržovaná oficiálně není. Je to ale ani ne 300 řádků čitelného kódu. PR jen konvertuje kód na aktuální reader literály. Zkrátka, ta knihovna je užitečná, jenom něco dělá možná méně moderně. Není to projekt velikosti Reactu, Linuxu, Firefoxu, LibreOffice apod. který si běžný programátor na koleně při bezpečnostní chybě opravdu neopraví, protože vnitřnosti zpravidla nezná.

ondj commented 2 years ago

@KaliszAd Jinak ohledně projektu Pathetic [...]

Napadá vás, jak pravidlo D.1 upravit? Například ve smyslu: „v případě, že vývojář dokáže případný bezpečnostní problém opravit vlastními silami, je možné použít i neudržovanou závislost.”?

KaliszAd commented 2 years ago

@KaliszAd Jinak ohledně projektu Pathetic [...]

Napadá vás, jak pravidlo D.1 upravit? Například ve smyslu: „v případě, že vývojář dokáže případný bezpečnostní problém opravit vlastními silami, je možné použít i neudržovanou závislost.”?

@ondj to zní dobře. Možná spíš „V případě, že vývojář dokáže původním autorem či autory neudržovanou závislost zodpovědně udržovat např. opravou chyb, je možné použít i neudržovanou závislost a efektivně tak údržbu zajistit.” Myslím, že to je vcelku jasné, co je myšleno i u Vás, jak tam odstranil z mého pohledu zbytečnou specificitu na bezpečnost.

LBubn commented 2 years ago

Chybí mi v částech o testování "doporučení", aby testy nebyly prováděny vývojářem (ale jinou osobou - testerem, jiným vývojářem atd.). Pokud to tam je a přehlédla jsem, omlouvám se :).

KaliszAd commented 2 years ago

Chybí mi v částech o testování "doporučení", aby testy nebyly prováděny vývojářem (ale jinou osobou - testerem, jiným vývojářem atd.). Pokud to tam je a přehlédla jsem, omlouvám se :).

Tohle je podle mě další z již dříve zmíněných "cargo cult" přístupů. Nejsem si jistý, že rozdělení programování a testování v reálu něčemu pomůže. Spíš to zmrazí rychlost vývoje a vede k technickému dluhu, protože strašně zdržuje. Naopak rozumná míra code review před začleněním nějaké větší funkce, nebo pro kritický software občasný hloubokový audit není špatná věc. Vývojář má odevzdávat kód, který je zřejmý, otestovat si dopady sám, resp. pokud jsou dopady jinde, než bylo zamýšleno, je nutné kód upravit/ přepracovat. Pokud má někdo potřebu tyto věci rozdělovat, tak by se měl zamyslet, jestli najímá myslící lidi, kteří můžou nést zodpovědnost a jaké má vedení, jestli umí komunikovat např. důležitost nebo potřebnou robustnost funkce. Škatulkování zodpovědnosti ničemu moc nepomůže, tým který systém vyvíjí je za něj a případně i za jeho provoz zodpovědný. Celý DevOps je přeci o tom, že už se kód nehází přes plot na tým adminů, kteří nemůžou na kódu nic změnit, ale jsou zodpovědní za jeho provoz. Prostě máte v týmu lidi, kteří jsou lepší v hledání bugů nebo řešení provozu, ale můžou a měli by psát kód, aby se věci zlepšily a bugy nebyly v kódu moc dlouho.

MikkCZ commented 2 years ago

Pokud se bavíme o open source, tak si nejsem jistý, jak moc je DevOps model uplatnitelný, protože nejspíše bude instalací softwaru běžet více různě po světě nebo alespoň po republice, a za každou bude zodpovědný někdo jiný. Také to ale implikuje potenciální vývojáře a přispěvatele mimo organizaci a nemožnost testerů se na cokoliv zeptat.

Z osobních zkušeností, které mám jenom spíše s DevOps modelem, musím souhlasit s @KaliszAd. Jako vývojář jsem s tím spokojený a naopak je pak pro nás občas nepříjemné pracovat na integraci s dalším produktem, kde mají oddělené QA a tím vynucené docela pevné (a dlouhé) cykly vývoj-testování-nasazování-patchování, takže naše změny někdy čekají měsíce, než se dostanou do vydání.

Taky bych se bál, že podobné doporučení povede k zavedení manuálních nebo velké množství složitých blackbox testů, protože "proč psát při vývoji testy, když máme lidi od toho, aby to všechny vyzkoušeli". Ale to nemám ničím podloženo, určitě se najdou i nějaké výhody.