Vlákno názorů k článku Bezpečnost dat ve zdravotnictví: většina úniků se zjistí pozdě od M. Korbel - Stav některých portálů, českých pojišťoven, je naprosto katastrofální. VZP...
-
Stav některých portálů, českých pojišťoven, je naprosto katastrofální.
VZP - má svoje mouchy, ale jen v detailech. Celkově vzato je moderní a stále se vyvíjí, pro přihlášení používá osobní certifikát.
ZPMR ČR - vypadá, že se za posledních 20 let vývoj nikam nepohnul, nevyužívá osobní certifikát jako ostatní ZP. Pozitivní je, že funguje a nenutí uživatele ohackovat svůj systém.
VoZP, OZP, RBP - Využívají společné prostředí, kde se vývoj zastavil také ještě v minulém století. Pro přihlášení a podpis využívají osobní certifikát, celé je to postavené na Java 1.5 (podepisovací komponenta Signer). Aby to člověk rozchodil na aktuální Javě, musí ji ohackovat neskutečným způsobem (více info na http://www.portalzp.cz/ke-stazeni). Uživatel musí komponentě umožnit přepis globálních souborů local_policy.jar, US_export_policy.jar, ... Když to uživatel překousne, tak to s hromadou varování a a chyb funguje.
ČPZP - Využívá společné prostředí jako předešlé tři pojišťovny, jen si na ně nasadil vlastní grafické prostředí. Což má za následek že kromě již zmíněných problému to ani pořádně nefunguje.ZPŠ - nepoužívám, nemám žádné zkušenosti
Všechny tyto portály využívám pravidelně, každý měsíc pro odesílání výkazů. Je pravda, že jako desktop systém používám Linux (Java), pod Windows lze použít i ActivX (což nepovažuji za lepší řešení).
-
Starous (neregistrovaný)
US_export_policy.jar není hack je to jen výmysl oraclu na to jak vynutit americkou legislativu která mezitím už byla asi zrušená- pokud chcete jakýkoli klíč délky 256 a delší tak potřebujete export policy která se tam musí přidat ručně - v Javě to jen nastaví nějaký boolean na true a povolí vám používat silnou kryptografii
-
Starous (neregistrovaný)
No on je to problém i na Windows, ale je to dělané by design - uživatel / admin tím na sebe bere legální odpovědnost a nedá se to zautomatizovat
Jinak je to samozřejmě velký nesmysl protože v zemích která nerespektují licenční a jiná ujednání mohou snadno udělat toto a žádnou policy nepotřebují:
(v nasich podminkach bych to neriskoval nejspis to neco porusuje)
static {
try {
Field field = Class.forName("javax.crypto.JceSecurity").getDeclaredField("isRestricted");
field.setAccessible(true);
field.set(null, java.lang.Boolean.FALSE);
} catch (Exception ex) {
}
} -
Filip JirsákStříbrný podporovatelTo je proto, že popsali postup, kterým s eta knihovna instaluje normálně – normálně se instaluje do systému, protože se to chápe jako součást JRE. Já si myslím, že by mělo být možné tu knihovnu dát i normálně na classpath nebo bootclasspath. Problém ještě může být s licencí, která možná znemožňuje distribuci spolu s aplikací.
