Pracovní e-mailová adresa vývojáře

[paveljanik]

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ů:

1. pokud je otevřený software primárně vyvíjen společností, tak daný požadavek říká, že zaměstnanci mají všichni mít účty svázány se svojí pracovní e-mailovou adresy. Jaký je k tomu důvod? Co je to "svázán"? Co na to řekne HR oddělení dané společnosti?
2. pokud do kódu přispívá nečlen primárního vývojového týmu (tedy nezaměstnanec dané společnosti), tak vyžadujeme jeho pracovní mail. Proč, když se ve své práci věnuje něčemu úplně jinému? Proč, když se softwaru věnuje ve svém volném čase? Vylučujeme tím, že by se mohl stát merge-masterem? Proč?
3. spousta lidí používá jednu e-mailovou adresu jak pro práci tak pro soukromé věci. Co je to v takovém případě pracovní adresa?
4. Trošku Venezuely (to je už spíše vtip): vylučujeme tedy nezaměstnané a důchodce?

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ý).

[ondj]

Dobrý den,

pracovní e-mailová schránka má být svázána pouze pro ty účty, které mají právo vydávat nové verze a spravovat uživatelské účty, takže určitě se nejedná o nutnost pro přispěvatele z řad veřejnosti. Důvody pro toto doporučení jsou dvojí:

1. Auditovatelnost účtů: pokud bude mít uživatel soukromý e-mail třeba pejsek123@seznam.cz a přezdívku pejsek123, kontrole, zda se jedná o legitimní účet nebo ne je mnohem složitější.
2. Bezpečnost schránky: i přes doporučení využívat vícefaktorovou autentizaci, jedním z faktorů bude obvykle heslo, které je možné resetovat zasláním e-mailu do schránky uživatele. V případě osobní schránky na ni nejsou kladeny žádné požadavky na bezpečnost, zatímco o orgánů veřejné moci se bude jednat o regulovaný systém dle zákona o kybernetické bezpečnosti a i u ostatních organizací bude většinou spadat pod ISMS, takže jsou na něj kladeny větší nároky.

Dává vám to takto smysl?

[paveljanik]

Dobrý den, díky za vysvětlení myšlenkových postupů. Připomínky níže v textu.

On 21. 1. 2022, at 10:33, ondj ***@***.***> wrote: pracovní e-mailová schránka má být svázána pouze pro ty účty, které mají právo vydávat nové verze a spravovat uživatelské účty, takže určitě se nejedná o nutnost pro přispěvatele z řad veřejnosti.

Již tato první věta naznačuje (a já věřím, že je to pouze zjednodušením v úsudku), jak to s open source zamýšlíte (takže určitě se nejedná...) ;-) Proč? Jaký je důvod? Vývoj a vlastní nasazení a provoz jsou dvě odlišné věci. Je zřejmé, že open source systém pro zabezpečenou výměnu informací může být nasazen pro komunikaci např. mezi ministerstvy. Proč by vývoj takového systému nemohl vést ***@***.*** [github: sergej at zabijak dot cz]? Nasazení do provozu je věc jiná, s vývojem vlastně "nesouvisející". Podle mého názoru může být i vývoj open source software pro provozování kritického systému u povinné osoby řízen a spravován kýmkoli toho schopným a nikoli a pouze jen zaměstnancem této povinné osoby. Dovedu si představit, že např. vývoj softwaru u @mfcr.cz bude řízen někým např. z @spcss, tedy nezaměstnancem @mfcr.cz. Bude mu MF ČR důvěřovat pouze a jenom proto, že má tu správnou mail doménu? Zcela jistě NE. Kontrola důvěryhodnosti jedince na základě jeho e-mailové adresy je špatně by design. Některé osoby z "důvěryhodné domény" mohou být též nedůvěryhodné (vzdálená analogie k hradním prověrkám). Kontrola dodavatelů (a v tomto smyslu jsou vlastně přispěvatelé do open source softwaru dodavatelé [!?]) je zcela jiná otázka opět nesouvisející s open source, ale obecně s požadavky ZKB.

Důvody pro toto doporučení jsou dvojí: • Auditovatelnost účtů: pokud bude mít uživatel soukromý e-mail třeba ***@***.*** a přezdívku pejsek123, kontrole, zda se jedná o legitimní účet nebo ne je mnohem složitější.

A byla z tohoto pohledu v uplynulých letech adresa ***@***.*** [github: ministr at mzcr dot cz] "důvěryhodná" (ne ve vztahu k doméně, ale ve vztahu k počtu osob)? Viz výše, není možné zakládat důvěryhodnost jedince na základě jeho e-mailu. Je pan Sergej Zabiják z MZ ČR důvěryhodný? Má mail ***@***.*** [github: zabijak at mzcr dot cz].

• Bezpečnost schránky: i přes doporučení využívat vícefaktorovou autentizaci, jedním z faktorů bude obvykle heslo, které je možné resetovat zasláním e-mailu do schránky uživatele. V případě osobní schránky na ni nejsou kladeny žádné požadavky na bezpečnost, zatímco o orgánů veřejné moci se bude jednat o regulovaný systém dle zákona o kybernetické bezpečnosti a i u ostatních organizací bude většinou spadat pod ISMS, takže jsou na něj kladeny větší nároky. Dává vám to takto smysl?

To je pouze paper security vs. reality. Mnohé soukromé e-mailové adresy jsou lépe spravovány než některé poštovní systémy povinných osob. Viz OOP Mail se sadou doporučení a termíny ve vzdálené budoucnosti atd. ... Vezměme to ještě z druhé strany - když si takovýto dokument přečte např. MKB na ministerstvu a potřebuje nasadit poštovní server, tak automaticky vyřadí Postfix, protože Wietse Venema má podivnou adresu? Je toto cílem tohoto dokumentu? Nad e-mailem/uživatelem je možné případně vybudovat další vrstvu - SSH klíče, podepisování kódu apod. Nebo code review od již důvěryhodných osob před integrací, nebo až před nasazením do provozu apod.

[ondj]

Tady možná dochází k nepochopení účelu doporučení. Tato doporučení vůbec nesměřuje na nastavení pravidel využívání open-source ve veřejné správě, ale o jeho vývoji veřejnou správou. To znamená, že doporučení bude aplikovat pouze organizace na software, který si sama nebo dodavatelsky vyvíjí a pokud se ho rozhodnout zveřejnit. Mají zvýšit pravděpodobnost, že vyvíjený software nebude představovat zvýšené riziko jak pro samotnou organizaci, tak pro další organizace, které se rozhodnou tento software využít.

Pokud se jakýkoliv škodlivý kód nebo nová zranitelnost objeví v Pull requestu, nic se neděje. I pokud je mergnuta do masteru, tak se obvykle taktéž ještě nic neděje. Problém je, až se dostane do finálního produktu a ten se obvykle sestavuje při vytvoření nového tagu a následně pomocí CD nasazuje nebo v případě knihovny nahrává do správce knihoven.

Pokud by se škodlivý kód objevil ve finální verzi, došlo k narušení bezpečnosti jak organizace, který software vyvíjí, tak i dalších organizací případně uživatelů a tím i poškození reputace organizace, která systém vyvíjí.

Proto doporučujeme u těchto účtů s vysokým oprávněním využívat pracovní e-mailové schránky. Nijak to neovlivňuje možnost do kódu přispívat komukoliv z řad veřejnosti nebo spolupracujících organizací, pokud si to organizace přeje. V ideálním světě by bylo nejlepší, aby takový účet byl svázán s IdM organizace.

A co se týká bezpečnosti e-mailových řešení organizací vs. různých freemailových služeb, tak na řešení organizací alespoň nějaké požadavky existují, u freemailových služeb je kvalita zabezpečení různá.

[paveljanik]

Tento dokument se jmenuje "Bezpečnostní doporučení pro vývoj otevřeného softwaru ve veřejné správě".

Případná publikace binárních verzí, nasazování do provozu apod. jsou podle mého názoru až činnosti navazující na vývoj v rámci dané organizace (a případně i dalších uživatelů daného otevřeného softwaru) a přiznám se, že nevidím žádný důvod pro tuto podmínku s výjimkou organizace, která by všechny tyto činnosti měla sloučeny v jednu.

O této možnosti jsem ale ani neuvažoval, ale je pravdou, že mohou být instituce, kde vývojáři řídí kompletní proces až do provozu. Ale takovým organizacím nepomůže už nic a pak je jedno, jestli daný vývojář má pracovní e-mail nebo dodavatelský nebo freemailový.

V takovém případě rozumím preferenci pracovní e-mailové adresy tak, že je vyžadován jistý smluvní vztah s organizací (odpovědnost za škodu, ...) a není to tedy primárně o typu e-mailové adresy. Smluvní vztah mohu mít i s osobou, jejíž e-mail je privátní, tedy nepracovní.