nukib / bezpecnostni-doporuceni-open-source Goto Github PK
View Code? Open in Web Editor NEWBezpečnostní doporučení pro vývoj otevřeného software ve veřejné správě
Bezpečnostní doporučení pro vývoj otevřeného software ve veřejné správě
Až teď mi došlo, že by si tento dokument zasloužil aplikovat sám na sebe (byť nejde o software), což znamená doplnit např. soubor CONTRIBUTING a hlavně licenci. Předpokládám, že to bude potřeba probrat interně v NÚKIBu, co to obnáší, ale osobně bych doporučoval Creative Commons.
S výběrem případně pomohou:
Tento dokument vzniká jako doporučení pro veřejný sektor, a v něm lze očekávat i cizojazyčně mluvící zaměstnance a vývojáře. Aby mohly firmy tento dokument používat a čerpat z něj dlouhodobě, doporučoval bych poskytnout i jeho anglický překlad, alespoň v březnu po dokončení první finální verze. Návrh na anglickou verzi je ve skutečnosti jeden z prvních komentářů od mého (zahraničního) kolegy.
Sám ve volném čase přispívám do překladů open source softwaru, ale pokud nebude k dispozici žádný copywriter, tak v případě zájmu z vaší strany bych se na překladu tohoto dokumentu rád podílel.
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.
Dobrý den.
Náš spolek OpenAlt z.s. aktivně propaguje otevřené technologie, softwarové i hardwarové, jejich používání, vývoj a samozřejmě osvětu v této oblasti. Neunikla nám proto vaše společná iniciativa vytvořit Bezpečnostní doporučení pro vývoj otevřeného softwaru ve veřejné správě.
Kromě samotného faktu, že takový dokument vůbec vzniká, velmi oceňujeme jeho zveřejnění a možnost zasílání připomínek formou komentářů (issues) i konkrétních návrhů na změny (pull requesty). Doporučení jsou formulována do poměrně jednoduché příručky, nejsou navázána na konkrétní zákonné požadavky nebo paragrafy, ale jsou použitelná obecně. Na tvorbě a doplnění dokumentu se tedy mohou podílet členové našeho spolku i další profesionálové z oboru, jak je přímo vidět z aktivity v repozitáři, takže dokument nejen open source podporuje, ale sám se jeho principy snaží řídit.
Tímto dopisem děkujeme za váš přístup a vyjadřujeme podporu při tvorbě dalších podobných dokumentů nyní i v budoucnu. Rovněž vás zveme na další ročník naší konference OpenAlt (dříve pod názvem LinuxAlt), kterou od roku 2006 pořádáme, a kde je i vždy silné zastoupení přednášek zaměřených na téma bezpečnosti. Uvítáme vás na ní ať už jako partnery, přednášející i návštěvníky.
S pozdravem za spolek OpenAlt z.s.
Michal Stanke, předseda
README a název dokumentu obsahují pojem veřejná sféra, kterou jsem si nejdříve vysvětlil jako soukromý sektor, soukromé firmy. Dále se ale v textu vyskytuje formulace Doporučení není pro veřejnou správu právně závazné... a ...připravena k připomínkám veřejné správy, dodavatelů software pro veřejnou správu .... Možná jsem jen neznalý pojmů, ale jaká je tedy prosím cílová skupina, pro kterou je dokument určený?
Měli bychom definovat, že aplikace by měli poskytovat popis API v OpenAPI formátu. Ideálně i vč. Swagger testing UI, apod.
Stejně tak by se měla definovat konektivita na MQTT či podobné IoT protokoly. Budou je potřebovat v rámci digitalizace všechny aplikace.
Co myslíte?
Nesouvisí to přímo z bezpečnostní vývoje, ale aby projekt reálně spadal do kategorie open source, stálo by za to zmínit, pod jakou licencí musí být jeho kód dostupný. Případně existuje už k tomu ve státní správě nějaká jiné metodika nebo doporučení?
Bezpečná aplikace by v ideálním případě neměla mít výchozí přihlašovací údaje (nedejbože statické - stejné pro každou instalaci). Případné přístupové údaje by si měl provozovatel/uživatel nastavit během nasazení aplikace/založení účtu.
Pokud už je potřeba výchozí údaje vygenerovat, mělo by to proběhnou kryptograficky bezpečným způsobem. To už je tedy popsáno v C.8.
V O.5 a D.3 je zmiňován termín 30 dnů pro opravu bezpečnostních chyb. V O.3 je pak (sice jako příklad) 48 hodin pro odpověď na hlášení bezpečnostních chyb. Souhlasím s tím, že v případě bezpečnostních problémů je potřeba jednat rychle, ale nejsem si jistý, jestli je vhodně zde uvádět konkrétní termíny (nebo jsou dané vyhláškou?). Očekával bych spíše, aby vůbec nějaký postup pro řešení takových hlášení existoval a v rámci něj abych byl jako případný autor hlášení vhodně informován o průběhu a očekávaném termínu řešení, v závislosti na závažnosti nahlášené chyby. Podle konkrétní aplikace, způsobu jejího provozu a používání, a samozřejmě v závislosti na konkrétní chybě, může být 30 dnů nebezpečně dlouhá doba, nebo naopak zbytečně krutý požadavek.
Rád bych otevřel téma využití decentralizovaných technologií.
Myslím, že software, který se bude používat ve státech by měl co nejvíce využívat decentralizované technologie. Nejedná se jen o známější blockchain, ale například i o IPFS (Inter Planetary File System). Tyto technologie umožní snížit náklady na vývoj, údržbu, řeší identity management, zásadně zjednodušují backup souborů, jehich přenos mezi vzdělávací sférou a průmyslem a také mají přirozenou ochranu proti ransomware (takto by se dalo ještě pokračovat dále. Detailnější analýzu zpracovalo například MPO:
MPO - Potenciál decentralizovaných technologií pro rozvoj České ekonomiky
Velkou výhodou je, že se lidé mohou zapojit do zálohování dat, držení sítě, hlasování, apod., což ochrání tato data proti případným útokům, haváriím jinak centralizovaných datových center, apod.
Z pohledu bezpečnosti hraje roli i snížení energetické náročnosti provozu státní IT infrastruktury. Díky úsporám na vývoji i provozu získáme rezervu, kterou můžeme směřovat kam bude potřeba.
Protože se delší dobu zabývám tématem digitalizace, tak jsem začal pro tyto účely psát již před rokem OpenSource Framework (https://veframework.com/). V tomto roce ho budeme posunovat výrazně kupředu a lze do něj zapracovat spoustu nástrojů, které nám zjednodušší implementaci nových systémů. Vše je free i pro komerční účely. Nyní jsem najmul několik vývojářů, kteří pomůžou s refaktoringem, zvýšením bezpečnosti a stability, dokumentací, apod. a další se budou přidávat v průběhu roku.
Již jsem koukal, že například dokládání identity, či ověřování buildů aplikací může být velmi jednoduše řešno pomocí NFT a IPFS. Máme na to už konkrétní případy (řeším to veframeworku kvůli některým security issues, které jsou v průmyslu, apod.). Postupně zkusím doplnit jednotlivé příklady, kde se co dá použít. Budu rád, když by někdo s tímto pomohl.
Přístup k technologiím skrze VEFramework lze řešit i přes API, takže i pokud je nějaká aplikace napsaná v jiném jazyce, tak může touto formou získávat data například z různých blockchanů nebo je tam posílat (nemusí přitom psát sami logiku pro podepisování transakcí, apod.). S tím souvisí i další Issue, kterou bychom měli otevřít a to je formát pro API a IoT konektivitu, ale tu otevřu samostatně.
Doporučil bych v dokumentu explicitně jako doporučení zmínit ošetřování uživatelských vstupů, a to z pohledu:
Zamýšlím se nad principem otevřeného software a požadavkem na svázání účtu ve VCS s pracovní e-mailovou adresu vývojáře...
Požadavek má několik problémů:
Požadavek na pracovní e-mailové adresy tedy podle mého názoru nedává příliš smysl a zřejmě s otevřeným softwarem vlastně ani nesouvisí. Dovedu si to však představit za jistých předpokladů jako podmínku používání VCS uvnitř společnosti pro jakýkoli software (nejen otevřený).
Nevím přesně jestli to sem patří, ale pokud to bude vyvíjet i veřejná správa, tak asi ano. Je nutné v dokumentaci deklarovat, kdo je vlastníkem toho produktu, což veřejná správa potřebuje vzhledem k zadávání veřejných zakázek, i kdyby faktickým dodavatele byl někdo jiný.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.