Vlákno názorů k článku Regulace podle NIS2: Rozdělení telco firem podle množství provozovaných SIM karet z vyhlášek zmizelo od StarousCZ - Jinak jsem si na github zapnul passkeys a...

Jinak jsem si na github zapnul passkeys a jsem stastny jako blecha. Jsem zvedavy jak cesky urad bude v budoucnosti resit situaci ze system nebude mit zadna hesla, ale neco bezpečnějšího - pokutou ?

S timhle vyjmecne nejak pocitaji. Aneb kdyz budete mit HW token typu Yubikey a prihlasovat se pomoci nej, problem nebude. Akorat je teda problem to dostat do vsech aplikaci :-) A samozrejme prusvih jsou treba ty technicke ucty - tedy ucty, ktere treba pouziva aplikace pro pristup do databaze. I tam budete heslo kazdy rok a pul povinne menit... coz bude sranda, jak ostatne je videt obcas i pri vymenach certifikatu, kdy pak trva i pulden, nez to nekdo da dohromady :-)

Už ten režim pomalu implementujeme a tohle je právě peklo, uživatelé mě nějak netrápí, tam jsou jiné cesty jak to udělat, aniž by uživatel tím trpěl a musel něco změnit (o tom jsme debatovali tady nedávno a nepochopili se), všechny ty ale technické účty, to je problém, u řady míst to nelze vůbec snadno automatizovat, jsou buď offline nebo to ty technologie neumožňují.

Prakticky to třeba znamená i pravidelnou změnu ftp přihlášení u hostingu nebo změnu hesla do databáze u Wordpressu, která se dělá ručně.

Stejný problém jsou třeba i různé přístupy per aplikace, které se dnes řeší párem application id a secret id jako nějaký dlouhý a-z0-9 řetězec (např. smtp účet u gmailu, přístup na s3 u aws), to nesplňuje požadavky. Stejný je problém po změně neumožnit 30 minut další změnu, což třeba u hesel k HW prvkům nelze vůbec dnes zajistit.

Mně někdy připadá, že si NÚKIB není vědom důsledků. Pravidlo se třeba týká i autorizačního token pro externí přístup do datových schránek, opět je nutné ho každý rok a půl změnit, nesplňuje podmínky na složitost a nelze změnu udělat jinak než aplikace odebrat a pak zase složitě přidat.

Ne, na NUKIBu nepremysli - jen hledaji zpusoby, jak vykazovat cinnost na poli kyberneticke bezpecnosti a pritom se u toho nenadrit. A to splnuje jednoduchy checklist, kde si muzou pri kontrole odskrtavat ano/ne.

Jo, ze si clovek zhodnoti rizika ke kazdemu systemu a umerne rizikum zvoli adekvatni opatreni u kazdeho systemu individualne - to proverovat by uz zase bylo moc prace.

Kdyby skutecne implementovali na sobe to, co sami vymysli, tak by se chovali jinak. Jo, mozna resi takove ty jednoduche veci, jako vynucene zmeny hesla skrze GPO ve Windows... ale cokoliv slozitejsiho na znalosti u nich uz kulha, lze souhlasit ze netusi nic o praktickych dopadech svych teoretickych napadu :-) A dost sazi na to, ze hlidace nikdo nehlida. Prece urad pres kyberbezpecnost te bezpecnosti rozumi, ty hlidat nemusime ;-)

pred par lety jsem si hral s hashicorp vault a zmenu hesla do databaze nastavil na 15 minut. Taky se da...

To vam ale univerzalne nevyresi vsechny situace. Aneb treba pristup k API treti strany, kde ten pristupovy token vam nejakym zpusobem generuje protistrana. Jasne ze jsou mista, kde vault fungovat bude ale to "se da" neplati univerzalne.

Ale sám vault potřebuje také admin přístup do databáze, aby tam mohl hesla měnit či generovat dočasné účty, změnit tohle heslo už právě nelze tak snadno a ne bez výpadku. Nebo můžeš mít hesla uložená ve Vaultu a při změně je tam aktualizovat, ale aplikace se ti do vaultu přihlašuje přes application id a secret id, které nesplňují pravidla pro hesla. Jsme v kruhu, který právě řeším.

Tohle, ale nejde dělat bez malého výpadku, pokud ta databáze (nebo něco jiného) neumožňuje mít dvě různá hesla současně.

passkey nesplňuje žádný z bodů přímo, protože klíč může být uložen nebezpečně. Buď to budeš brát jako OTP, takže to je nedostatečné nebo klíč jako heslo, takže vlastně bezpečné heslo, ale musíš to měnit co rok a půl.