IT wachtwoord manager met ondersteuning voor groepen #58

New Issue

Open

opened 2024-04-07 13:44:02 +00:00 by bart_terpstra · 0 comments

bart_terpstra commented

2024-04-07 13:44:02 +00:00

Member

zie ook: #30, #37, #12

we hebben credentials nu in een encrypted git repo.
echter, deze biedt minder controle dan sommige password managers.
we moeten wellicht deze overwegingen eens verder in kaart brengen.

gewenste features:

groepen om access te compartmentaliseren
plan voor access ontnemen
2FA

opties:

naam	distributie	delen	2fa	notes
~~	~~lastpass~~	commercieel		☑️
~~	~~1password~~	commercieel		☑️
~~	~~dashlane~~	commercieel		☑️
~~	~~keyhub~~	commercieel		☑️
univention	open-source		☑️	nauwelijks github stars
bitwarden	open-source maar hosted betaald voor groepen		☑️	heeft lichtere server vaultwarden maar minder support voor orgs
~~	~~keepass~~	open-source	❌	☑️
~~	~~keepassx~~	open-source	❌	☑️
~~	~~keepassxc~~	open-source	❌	☑️
passbolt	open-source maar zelfs self-hosted kost geld
psono	open-source			nauwelijks gitlab stars

kunnen we dat git repo encrypten niet opsplitsen naar groepen?
ja, met pass kan je per directory aangeven welke keys er bij mogen

dit komt bij pass neer op -p <PATH> parameter toevoegen aan pass (git) init commando's.
iig voor IT denk ik dat de volgende generieke (niet project-specifieke) toegangs niveaus al relevant kunnen zijn:

gast (kan PRs maken naar publieke repo's)
dev (kan repo's zien zonder unencrypted PII/credentials, mag committen naar onbeschermde git branches, mag PR reviews doen?)
repo owner (mag PRs goedkeuren naar beschermde git branches van eigen repo's)
dev cleared voor persoonsgegevens (mag ook bij persoonsgegevens zij het liefst compartmentalized, maar moet 2FA)
sysadmin (sudo (/ desnoods root) level server toegang)
admin (root/sudo/panel level server toegang, admin toegang tot systemen, mag PRs goedkeuren naar beschermde git branches, moet 2FA)

open vragen: hoe structureren we nextcloud groepen en pass om zo'n hiërarchie te reflecteren?

nextcloud: geen persoonsgegevens op team niveau delen
pass: ?

we zouden in pass wat moeten doen met subfolders, zodat we daar de granulaire permissies kunnen toepassen (?)

we kunnen dit ook doen via nextcloud, met bv:

nieuwe devs hebben mischien niet een pass nodig.

voortgang om pass granulairder te maken: bij1/password-store#4

zie ook: #30, #37, #12 we hebben credentials nu in een [encrypted git repo](https://gitlab.com/bij1/sysadmins/password-store "‌"). echter, deze biedt minder controle dan sommige password managers. we moeten wellicht deze overwegingen eens verder in kaart brengen. gewenste features: - groepen om access te compartmentaliseren - plan voor access ontnemen - 2FA opties: |naam|distributie|delen|2fa|notes| |-|-|-|-|-| ~~|~~[~~lastpass~~](https://lastpass.com/ "‌")~~|commercieel||☑️||~~ ~~|~~[~~1password~~](https://1password.com/ "‌")~~|commercieel||☑️||~~ ~~|~~[~~dashlane~~](https://www.dashlane.com/ "‌")~~|commercieel||☑️||~~ ~~|~~[~~keyhub~~](https://topicus-keyhub.com/ "‌")~~|commercieel||☑️||~~ |[univention](https://www.univention.com/ "‌")|[open-source](https://github.com/univention/univention-corporate-server "‌")||☑️|nauwelijks github stars| |[bitwarden](https://bitwarden.com/ "‌")|[open-source](https://github.com/bitwarden/server "‌") maar hosted [betaald voor groepen](https://bitwarden.com/pricing/business/ "‌")||☑️|heeft lichtere server [vaultwarden](https://github.com/dani-garcia/vaultwarden "‌") maar [minder support voor orgs](https://github.com/dani-garcia/vaultwarden/wiki#missing-features "‌")| ~~|~~[~~keepass~~](https://keepass.info/ "‌")~~|open-source|❌|☑️||~~ ~~|~~[~~keepassx~~](https://www.keepassx.org/ "‌")~~|open-source|❌|☑️||~~ ~~|~~[~~keepassxc~~](https://keepassxc.org/ "‌")~~|open-source|❌|☑️||~~ |[passbolt](https://www.passbolt.com/ "‌")|[open-source](https://github.com/passbolt/passbolt_api "‌") maar [zelfs self-hosted kost geld](https://signup.passbolt.com/pricing/pro "‌")|||| |[psono](https://psono.com/ "‌")|[open-source](https://gitlab.com/psono/psono-server "‌")|||nauwelijks gitlab stars| kunnen we dat git repo encrypten niet opsplitsen naar groepen? ja, met pass kan je per directory aangeven welke keys er bij mogen dit komt bij `pass` neer op `-p <PATH>` parameter toevoegen aan `pass (git) init `commando's. iig voor IT denk ik dat de volgende generieke (niet project-specifieke) toegangs niveaus al relevant kunnen zijn: - gast (kan PRs maken naar publieke repo's) - dev (kan repo's zien zonder unencrypted PII/credentials, mag committen naar onbeschermde git branches, mag PR reviews doen?) - repo owner (mag PRs goedkeuren naar beschermde git branches van eigen repo's) - dev cleared voor persoonsgegevens (mag ook bij persoonsgegevens zij het liefst compartmentalized, maar moet 2FA) - sysadmin (sudo (/ desnoods root) level server toegang) - admin (root/sudo/panel level server toegang, admin toegang tot systemen, mag PRs goedkeuren naar beschermde git branches, moet 2FA) open vragen: hoe structureren we nextcloud groepen en pass om zo'n hiërarchie te reflecteren? - [x] nextcloud: geen persoonsgegevens op team niveau delen - [ ] pass: ? we zouden in pass wat moeten doen met subfolders, zodat we daar de granulaire permissies kunnen toepassen (?) we kunnen dit ook doen via nextcloud, met bv: * https://apps.nextcloud.com/apps/passwords * https://apps.nextcloud.com/apps/passman nieuwe devs hebben mischien niet een pass nodig. voortgang om pass granulairder te maken: https://code.bij1.org/bij1/password-store/issues/4