O aplikacji mObywatel wiemy niewiele mimo szumnie zapowiadanego udostępnienia kodu, gdzie tradycyjnie okazało się że udostępniono tylko część kodu aplikacji.
Czy ktoś z Was orientuje się co się dzieje na serwerach? Co tak naprawdę jest w centralnej bazie mObywatela, czy wszystkie dane za jego pomocą pobierane tam siedzą, są tam kopiowane, czy może backend mObywatela na bieżąco łączy się z innymi centralnymi systemami?
Pytanie pomocnicze - jak to będzie w przypadku e-dziennika
Co wlaściwie jest w centralnej(?) bazie aplikacji mObywatel
- Rejestracja: dni
- Ostatnio: dni
- Postów: 1944
- Rejestracja: dni
- Ostatnio: dni
- Lokalizacja: Poznań
- Postów: 9281
Szczerze to raczej nikt nie będzie wiedział co tam jest - ponad to, co jest dostępne online.
A jeśli ktoś by mógł odpowiedzieć na to pytanie to na 99,9% ma takie NDA że nie odpowie choćbyś mu puszczała Martyniuka 24/7 przez miesiąc.
Kolega brał udział we wdrożeniu pewnej funkcji w mObywatelu. Za wiele nie wiedział o tym jak to działa. Dostał tylko info odnośnie swojego kawałka, jak ma zintegrować pewną funkcję obywatela z bazą instytucji dla której pracował. I już. Co dalej się dzieje, jakie są serwery itp. nie ma pojęcia (na pewno wiedział więcej niż mi powiedział, ale ogólnie to za wiele nie wiedział poza takim totalnym minimum, które było konieczne).
Zwłaszcza, że takie typowe NDA to kara finansowa za ujawnienie. A w przypadku tego typu rządowych/strategicznych aplikacji to już mamy odpowiedzialność karną, a jak ktoś podejdzie ambitnie do tematu to można podciągnąć pod zagrożenie bezpieczeństwa państwa: szpiegostwo, zdradę ojczyzny, działania dywersyjne lub sabotaż oraz bardziej przyziemne tematy: ujawnienie informacji niejawnych i/lub tajnych.
Pytanie pomocnicze - jak to będzie w przypadku e-dziennika
A co do e-dziennika: bardzo mnie bawi że teraz zrobiło się wielkie halo że rząd chce mieć bazę dot. uczniów i w niej zawierać wiele informacji poufnych - takich jak PESELE, nazwiska, adresy, oceny, informacje o frekwencji itp. Tragedia się dzieje, Sutener argumentował że takie dane nie sa odpowiednio zabezpieczone itp. Tyle że państwo przechowuje o wiele bardziej drażliwe i strategiczne dane (chociażby szczegółowe informacje dot. chorób, policja posiada własną bazę z informacjami o zatrzymaniach, zarzutach, postępowaniach itp.) i jakoś one nie wyciekają, a tutaj płacz pod publiczkę że dane dzieciaków wyciekać będą.
Ale jeszcze lepsze jest to, że z rządowego dziennika mogą wyciekać. Tyle że obecnie są 2 główne e-dzienniki (Librus i Vulkan) i (dane z tyłka, ale bardzo prawdopodobne) 98% szkół w Polsce z nich korzysta. I one zbierają dokładnie te same dane, ale nikt nie widział kodu tych dzienników, cholera wie gdzie są hostowane, a przede wszystkim - należą do prywatnych firm, które w każdej chwili mogą jedną decyzją serwer zamknąć, dane mogą zniknąć, nikt nie ma nad tym kontroli. Oczywiście - szanse są niewielkie, ale jakby to się stało nagle to będzie jak z Amber Gold - nikt nie pomyślał ani nie zareagował wcześniej. A jak była próba rządu ogarnięcia tematu (podobnie jak było chociażby z kryptowalutami i słynną Zonda) to naczelny kibol blokuje.
Czyli podsumowując - państwowy dziennik jest niedobry, bo gromadzi dane, bo jest podatny na awarie i tak dalej. Ale dokładnie to samo robi w bliżej nieokreślony sposób prywatny e-dziennik należący do jednego z dwóch polskich monopolistów i to już jest całkiem spoko. Genialna logika Snussoliniego :D
- Rejestracja: dni
- Ostatnio: dni
- Lokalizacja: Kraków
- Postów: 2067
cerrato napisał(a):
Kolega brał udział we wdrożeniu pewnej funkcji w mObywatelu. Za wiele nie wiedział o tym jak to działa. Dostał tylko info odnośnie swojego kawałka, jak ma zintegrować pewną funkcję obywatela z bazą instytucji dla której pracował i już. Co dalej się dzieje, jakie są serwery itp. nie ma pojęcia (na pewno wiedział więcej niż mi powiedział, ale ogólnie to za wiele nie wiedział poza takim totalnym minimum, które było konieczne).
Zwłaszcza, że takie typowe NDA to kara finansowa za ujawnienie. A w przypadku tego typu rządowych/strategicznych aplikacji to już mamy odpowiedzialność karną, a jak ktoś podejdzie ambitnie do tematu to można podciągnąć pod zagrożenie bezpieczeństwa państwa: szpiegostwo, zdradę ojczyzny, działania dywersyjne lub sabotaż oraz bardziej przyziemne tematy: ujawnienie informacji niejawnych i/lub tajnych.
Typowe security by obscurity.
Z punktu widzenia bezpieczeństwa państwa itp. może i takie podejście byłoby zrozumiałe - jakieś systemy zarządzające rezerwami strategicznymi, systemy uzbrojenia, systemy wymiany tajnych dokumentów... No niech będzie. Kradzież danych / wykorzystanie jakichś hipotetycznych dziur mObywatela by podszyć się pod kogoś i podpisać dokument lub wykraść kolejne dane byłaby gruba, ale nie tak gruba jak wysadzenie w powietrze magazynów uzbrojenia, elektrowni, wystrzelenie rakiet albo sparaliżowanie szpitali.
Tylko jakoś nie mam zaufania, że w parze z modelem security by obscurity idzie większe bezpieczeństwo aplikacji w znaczeniu braku podatności w zależnościach lub w kodzie.
Jak pojedynczy wykonawcy nie wiedzą nawet do końca, co robią, to ciekawe jak przeprowadzany jest audyt bezpieczeństwa i czy jak ktoś coś wynajdzie, to zostaje naprawione.
- Rejestracja: dni
- Ostatnio: dni
- Postów: 1944
cerrato napisał(a):
A co do e-dziennika: bardzo mnie bawi że teraz zrobiło się wielkie halo że rząd chce mieć bazę dot. uczniów i w niej zawierać wiele informacji poufnych - takich jak PESELE, nazwiska, adresy, oceny, informacje o frekwencji itp. Tragedia się dzieje, Sutener argumentował że takie dane nie sa odpowiednio zabezpieczone itp. Tyle że państwo przechowuje o wiele bardziej drażliwe i strategiczne dane (chociażby szczegółowe informacje dot. chorób, policja posiada własną bazę z informacjami o zatrzymaniach, zarzutach, postępowaniach itp.) i jakoś one nie wyciekają, a tutaj płacz pod publiczkę że dane dzieciaków wyciekać będą.
Ale jeszcze lepsze jest to, że z rządowego dziennika mogą wyciekać. Tyle że obecnie są 2 główne e-dzienniki (Librus i Vulkan) i (dane z tyłka, ale bardzo prawdopodobne) 98% szkół w Polsce z nich korzysta. I one zbierają dokładnie te same dane, ale nikt nie widział kodu tych dzienników, cholera wie gdzie są hostowane, a przede wszystkim - należą do prywatnych firm, które w każdej chwili mogą jedną decyzją serwer zamknąć, dane mogą zniknąć, nikt nie ma nad tym kontroli. Oczywiście - szanse są niewielkie, ale jakby to się stało nagle to będzie jak z Amber Gold - nikt nie pomyślał ani nie zareagował wcześniej. A jak była próba rządu ogarnięcia tematu (podobnie jak było chociażby z kryptowalutami i słynną Zonda) to naczelny kibol blokuje.
no właśnie, może ktoś wie jak to wygląda aktualnie z punktu widzenia dyrektora szkoły, on chyba kupując dostęp do aplikacji nie podpisuje NDA?
czy dostają na koniec roku jakąś kopię zapasową tych danych?
Czyli podsumowując - państwowy dziennik jest niedobry, bo gromadzi dane, bo jest podatny na awarie i tak dalej. Ale dokładnie to samo robi w bliżej nieokreślony sposób prywatny e-dziennik należący do jednego z dwóch polskich monopolistów i to już jest całkiem spoko. Genialna logika Snussoliniego :D
no tak, ale państwowy powinien być zrobiony właśnie inaczej, porządnie. wiem, że to dobry dowcip
- Rejestracja: dni
- Ostatnio: dni
- Lokalizacja: Poznań
- Postów: 9281
Typowe security by obscurity.
No nie zgodzę się z Panem.
Dla mnie security by obscurity to bardziej jest celowe zagmatwanie kodu żeby czytający nie mógł się połapać co i jak zostało napisane i dlaczego to ogóle działa, podstawianie jakichś funkcji dynamicznie (które są skądś-tam pobierane w locie)*, jakieś szyfrowanie literałów w kodzie (co utrudnia człowiekowi przeczytanie, ale nie jest problemem dla AI), ukrycie panelu logowania admina pod URL w stylu https://strona.pl/krzysio/U445/kaszanka.php, jakieś magiczne klucze zapisane na sztywno w kodzie apki, które muszą zostać przesłane razem z danymi na serwer bo inaczej serwer odrzuci taki pakiet itp.
A opisana procedura jest (w mojej ocenie) jak najbardziej sensowna. Po co mamy dawać informacje dot. systemu, które w danej sytuacji nie są potrzebne?
Po co koleś od frontu ma wiedzieć jak jest skonfigurowana baza? Ma jakieś API z którym się komunikuje, więc z jego punktu widzenia to nie ma żadnego znaczenia, co za tym API się kryje. Równie dobrze, zamiast SQL, może tam być krasnoludek zapisujący dane na glinianej tabliczce. Albo odwrotnie - ktoś odpowiedzialny za komunikację z jakimiś czujnikami przez RS nie musi niczego wiedzieć o aplikacji na komórkę, która te dane potem odczyta z bazy i przedstawi serwisantowi.
Security by obscurity mamy wtedy, gdy wyciek dokumentacji/kodu/ujawnienie tych magicznych zabezpieczeń powoduje ich utratę/zabiera im rację bytu. Need-to-know (ograniczenie przekazanych informacji do niezbędnego minimum) jest wtedy, gdy wyciek dokumentacji tylko ułatwia atakującemu zrozumienie jak apka jest napisana, ale nadal musi on złamać uwierzytelnianie, szyfrowanie lub inne zabezpieczenia.
* oczywiście sam fakt dynamicznego podstawiania funkcji nie jest niczym złym, mamy tematy w stylu DI, jakieś pluginy itp. Mi chodzi jedynie o sytuację, w której nie wynika to z architektury aplikacji, a jedynym powodem zastosowania czegoś takiego jest "zwiększenie bezpieczeństwa" - bo jak np. jakiejś funkcji nie ma wprost w kodzie HTML/JS strony, tylko się potem pobierze, to przecież nikt nigdy nie złamie takiego zabezpieczenia ;)
no tak, ale państwowy powinien być zrobiony właśnie inaczej, porządnie. wiem, że to dobry dowcip
OK, ale skąd założenie, że tutaj by była fuszerka? Skoro dziesiątki systemów urzędowych działających w Polsce, zarówno niedostępnych dla obywateli (wszystko co się wyświetla ludziom w urzędach na ekranach, systemy policji, NFZ itp.) oraz dających nam dostęp do danych (e-KRS, profil zaufany, mObywatel, e-doręczenia, ZUS online itp.) działa (z grubsza) OK to czemu akurat dziennik by miał być wyjątkiem?
To jest dokładnie taka sama logika jak kopnięcie faceta prewencyjnie kolanem w jaja, bo może będzie chciał mnie zgwałcić. OK, nie da się tego wykluczyć, ale samo stwierdzenie że to jest możliwe/że prawdopodobieństwo jest niezerowe to za mało, żeby kogoś oskarżać.
- Rejestracja: dni
- Ostatnio: dni
- Postów: 2282
Pewnie ci, którzy o tym decydują, nie ogarniają jeszcze podstaw współczesnego podejścia do bezpieczeństwa i trochę zostali w PRL-u ;)
A jak słyszą „publiczny klucz”, to dostają białej gorączki
Tymczasem:
Niemcy — oficjalny federalny klient eID, kod źródłowy:
https://github.com/Governikus/AusweisApp
UE — European Digital Identity Wallet, otwarta implementacja referencyjna + architektura:
https://github.com/eu-digital-identity-wallet/
A u nas udostępniono tylko część kodu mObywatela, a oficjalne uzasadnienie mówi m.in., że nieudostępnione fragmenty „mogą zawierać funkcje o kluczowym znaczeniu z punktu widzenia bezpieczeństwa aplikacji”.
Security by obscurity? ;)
- Rejestracja: dni
- Ostatnio: dni
- Postów: 1