Leszek K.

Leszek K. Zarządzanie
bezpieczeństwem
informacji. Dane
osobowe.

Temat: Aplikacja udostępniona klientowi (np. bankowość...

Szanowni Państwo,
jeśli aplikacja jest udostępniona przez internet klientom przez administratora danych (np. bankowość elektroniczna, serwis internetowy z logowaniem, etc, to czy musi ona spełniać (po stronie klienta) wymogi uodo, czy nie?

Wątpliwość dotyczy w szczególności polityki haseł - czy hasło klient musi zmieniać co 30 dni, czy hasło musi zawierać duże, małe litery i cyfry lub znaki specjalne. Czy musi miec minimum 8 znaków, czy hasło musi być przesyłane w formie zabezpieczonej, etc. Nie chodzi mi o "powinno" (dobre praktyki) tylko o "musi" (konieczność wynikająca z litery prawa).

Sądzę, że nie - wymogi/funkcjonalność/zabezpieczenia udostępnione stronie klienta, to jest kwestia tego, na co się obie strony umówiły. Ale może są jeszcze jakieś akty prawne, poza uodo, które należy do tego założenia uwzględnić.

Będę wdzieczny za komentarze.

konto usunięte

Temat: Aplikacja udostępniona klientowi (np. bankowość...

Ciekawe pytanie.

Kłopot z jednoznaczną interpretacją bierze się chyba z tego, iż rozporządzenie nie definiuje co należy rozumieć pod pojęciem 'użytkownika' , o którym mowa w pkt A.IV.2 Rozporządzenia. Jeśli czytać ten punkt literalnie, to każdy korzystający z systemu będzie użytkownikiem i obowiązkowo trzeba będzie zmieniać hasła, etc.

Chociaż nie wykluczam takiej wykładni, to moim zdaniem z innych przepisów wynika, iż wymóg zmiany hasła i wymogi dotyczące samego hasła nie dotyczą użytkowników systemu, którzy z niego korzystają w sposób 'kliencki' a dotyczą jedynie użytkowników upoważnionych do przetwarzania danych przez administratora danych (czyli po stronie administratora) - zob. pkt A.IV.1 czy też art 39.1.3 uodo.

Odpowiadając na Twoje pytanie o inne akty prawne - nie ma na szczęście innych na które musiałbyś zwrócić uwagę, natomiast sprawa umówienia się/nie umówienia się pomiędzy klientem a usługodawcą nie ma tu nic do rzeczy.

pozdrawiam
DC
Przemysław Osiak

Przemysław Osiak zarządzanie w IT /
project management/
project portfolio
...

Temat: Aplikacja udostępniona klientowi (np. bankowość...

Kwestia jest bardzo ciekawa.
Tym bardziej, że w samy rozporządzeniu MSWiA pojawiają się pewne niekonsekwencje.
Definiując pojęcie "hasła", rozporządzenie odwołuje się do osoby uprawnionej do pracy w systemie informatycznym podczas, gdy w definicji "identyfikatora użytkownika" mamy już jednoznaczne odwołanie do osoby upoważnionej do przetwarzania danych osobowych w systemie informatycznym.Przemysław Osiak edytował(a) ten post dnia 20.02.11 o godzinie 23:34

konto usunięte

Temat: Aplikacja udostępniona klientowi (np. bankowość...

I właśnie dlatego uważam, że te wymagania będą miały zastosowanie wyłącznie wobec osoby upoważnionej do przetwarzania danych. Czyli nie wobec klienta.

konto usunięte

Temat: Aplikacja udostępniona klientowi (np. bankowość...

czyli pełna zgoda :)) a to rzadko się zdarza

konto usunięte

Temat: Aplikacja udostępniona klientowi (np. bankowość...

Ja kilka lat temu pisałem opinię prawną na ten temat, oczywiście pod poprzednim brandem ;-) W każdym razie od tego czasu zdania nie zmieniłem.

konto usunięte

Temat: Aplikacja udostępniona klientowi (np. bankowość...

;-) bo rozporządzenie się nie zmieniło, a przydałaby się mu korekta po tylu latach...
Barbara Pióro

Barbara Pióro ABI, Prezes Zarządu,
Global Information
Security Sp. z o.o.

Temat: Aplikacja udostępniona klientowi (np. bankowość...

Klient nie ma obowiązku zmiany hasła, ale dobre praktyki wskazują, że należy informowac klienta, iż jego hasło powinno mieć konkretną składnię i powinno byc zmieniane. Należy również pamiętać, że aplikacja powinna umozliwiać, a nawet wymuszać określoną długość hasła np. min 8 znaków.
Marcin W.

Marcin W.
TI/IT/VM/HT/PC/XP/AD
/SE/XL/XE/AS/TB/CP/J
S/JV

Temat: Aplikacja udostępniona klientowi (np. bankowość...

witam, odświeżę temat: co należy stosować, gdy aplikacja zabezpieczona jest kluczem elektronicznym ?

Tzn. bez włożenia karty elektronicznej wpisywanie jakiegokolwiek hasła nie ma sensu, a w przypadku wpisania 3x błędnie hasła klucz na karcie jest trwale zablokowany, by go odblokować trzeba po prostu zamówić nową kartę lub certyfikat dla karty (koszty, koszty, koszty!) - strach przed pomyłką we wpisywaniu hasła (które de facto służy wyłącznie do odkodowania klucza certyfikującego) prowadzi prostą drogą do "kartkologii" - i jaki tu sens zmiany hasła co miesiąc ? Nie mówiąc o tym, że zmiana hasła to też konieczność wgrania przekodowanego certyfikatu na urządzenie, czego bez uprawnienia administratora nie da się zrobić - przy 20 stanowiskach z certyfikatem elektronicznym zmiana ich haseł to comiesięczny bieg przełajowy dla administratora... jak skończy u ostatniego, to za chwilę będzie musiał znów zmienić u pierwszego.
Adam Danieluk

Adam Danieluk Prezes
stowarzyszenia ISSA
Polska. Zarządzanie
ryzykiem, ...

Temat: Aplikacja udostępniona klientowi (np. bankowość...

Pozwolę sobie dorzucić kilka wątpliwości:
1. Jako klient, jestem właścicielem swoich danych więc jestem upoważniony do dostępu do nich, ale jeśli ktoś ma inną opinię to proszę o przedstawienie opinii.

2. Jestem również użytkownikiem systemu, bo to wynika z umowy z dostawcą usługi.

3. Mam przyznany identyfikator w systemie informatycznym, wymagania dotyczą systemu a nie mnie jako użytkownika więc system powinien spełniać wymagania rozporządzenia.

Wypowiedzi przedmówców są bardzo jednoznaczne, ale są tylko ich interpretacjami, a ja czekam na przypadek kiedy GIODO określi swoją interpretację dla konkretnego systemu.
Na pewno jednoznaczna i literalna interpretacja nie jest dla nikogo wygodna, ale ja mam ciągle wątpliwości czy jednak hasło nie powinno być zmieniane co 30 dni, mieć odpowiedniej długości i złożoności. Opór zainteresowanych stron budzi tak naprawdę konieczność zmiany hasła co 30 dni i z tym mamy problem zarówno jako użytkownicy systemów jak i dostawcy usług.
Poza tym wielu dostawców usług zapomina o tym że w sieciach publicznych identyfikator i hasło powinien być:
"Administrator danych stosuje środki kryptograficznej ochrony wobec danych wykorzystywanych do uwierzytelnienia, które są przesyłane w sieci publicznej."

Jako użytkownik systemów i właściciel danych chcę aby były one chronione. Boli mnie konieczność zmiany hasła co 30 dni i to jest pewien absurd bo poziom ochrony jest nieadekwatny do wagi chronionej informacji - przynajmniej w moim odczuciu.

Dla kolegi od certyfikatów, zwróciłbym uwagę na zapis z załącznika:
"W przypadku gdy do uwierzytelniania użytkowników używa się hasła ..."
Więc jak używamy certyfikatu to moim zdaniem nie ma potrzeby zmieniana hasła na certyfikacie. Ale chętnie poznam też inne rozumienie zapisu.

Swoją drogą to właśnie my jako środowisko merytoryczne powinniśmy zaproponować takie zapisy do rozporządzenia abyśmy przedsiębiorcy mogli działać zgodnie z prawem, prawa i dane osób które przekazują swoje dane były chronione z rozsądkiem.
ma Adam Danieluk edytował(a) ten post dnia 27.03.11 o godzinie 04:04
Przemysław Osiak

Przemysław Osiak zarządzanie w IT /
project management/
project portfolio
...

Temat: Aplikacja udostępniona klientowi (np. bankowość...

Adam Danieluk:
Pozwolę sobie dorzucić kilka wątpliwości:
1. Jako klient, jestem właścicielem swoich danych więc jestem upoważniony do dostępu do nich, ale jeśli ktoś ma inną opinię to proszę o przedstawienie opinii.
Ja pozwolę sobie wyrazić inną opinię: Otóż będąc "właścicielem" swoich danych osobowych, nie mogę być upoważniony do ich przetwarzania. Mam po prostu prawo do ich przetwarzania. :-)
Ale żarty na bok...
Co do haseł, to należy stwierdzić, że w tym zakresie przepisy nie są dość precyzyjne (poniżej wskazywałem chociażby na niespójność pojęciową), co moim zdaniem nie pozwala na wywiedzenie z nich obowiązku zmiany haseł przez klientów.
2. Jestem również użytkownikiem systemu, bo to wynika z umowy z dostawcą
usługi.
Co do tego też można by zgłosić wątpliwości ;-)
Przeprowadźmy taki oto eksperyment logiczny.
Mimo, że rozporządzenie nie definiuje wprost pojęcia "użytkownik" jednak definiuje pojęcie odwołujące się do tego pojęcia, przez co można pośrednio odczytać definicję "użytkownika". Otóż § 2 pkt 2 definiuje "identyfikator użytkownika" jako ciąg znaków identyfikujących osobę upoważnioną do przetwarzania danych osobowych w systemie informatycznym. A więc "użytkownikiem" będzie tutaj osoba upoważniona do przetwarzania danych osobowych. A jak już wspomniałem wyżej, będąc, jako klient, właścicielem swoich danych, nie będę osobą upoważnioną do ich przetwarzania.
A zatem skoro użytkownikiem jest osoba upoważniona do przetwarzania danych osobowych, a klient nie jest osobą upoważnioną do przetwarzania danych osobowych, to klient nie jest użytkownikiem.
QED ;-)
Czy brzmi to kuriozalnie czy nie, to już pozostawiam Państwa ocenie.
Nie mniej jednak uważam, że warto by rozważyć zmianę (przynajmniej niektórych) przepisów rozporządzenia - co nie jest, jak mniemam, poglądem odosobnionym.
Adam Danieluk

Adam Danieluk Prezes
stowarzyszenia ISSA
Polska. Zarządzanie
ryzykiem, ...

Temat: Aplikacja udostępniona klientowi (np. bankowość...

Witam,
jak już wspomniałem, jesteśmy na gruncie dosyć delikatnym, interpretacji :).
Generalnie idąc w kierunku wskazanym przez Przemka, powinniśmy uwzględnić Art. 37. "Do przetwarzania danych mogą być dopuszczone wyłącznie osoby posiadające upoważnienie nadane przez administratora danych"

Do jakich wniosków nas to prowadzi?

Czy ADO może dopuścić do przetwarzania danych osobę których dane dotyczą, bez nadania upoważnienia?

Jeśli mamy interpretować to wprost to okazałoby się że nie mamy w Polsce usług które działają legalnie, albo przyjmujemy że ADO nadaje upoważnienia dla wszystkich i wtedy wpadamy w reżim rozporządzenia - również jako osoby których dane dotyczą.

Pozdr.
Przemysław C.

Przemysław C. Trener biznesu,
coach ACC ICF,
ochrona danych
osobowych

Temat: Aplikacja udostępniona klientowi (np. bankowość...

po analizie stwierdziłem ze nie na temat i usunełem - przepaszam za zamieszaniePrzemysław C. edytował(a) ten post dnia 31.03.11 o godzinie 09:17
Przemysław Osiak

Przemysław Osiak zarządzanie w IT /
project management/
project portfolio
...

Temat: Aplikacja udostępniona klientowi (np. bankowość...

Adam Danieluk:
Witam,
jak już wspomniałem, jesteśmy na gruncie dosyć delikatnym, interpretacji :).
Nie uważam tego za jakąś ułomność. Nie jest zasadne stanowienie takiego prawa, które by w sposób zbyt daleko idący w szczegóły regulowało każdą kwestie ze wszystkich sfer naszego życia.
Po pierwsze dlatego, że jest to po prostu totalitaryzm, a po drugie dlatego, że takie prawo już w chwili ogłoszenia byłoby najczęściej nieaktualne.
Poza tym interpretacja przepisów jest prowadzona zazwyczaj w ramach
ustalonych reguł i jeśli się tylko tych reguł przestrzega nie ma obawy, że nagle okaże się, że UODO reguluje sposób uprawy pomidorów. ;-)
Generalnie idąc w kierunku wskazanym przez Przemka, powinniśmy uwzględnić Art. 37. "Do przetwarzania danych mogą być dopuszczone wyłącznie osoby posiadające upoważnienie nadane przez administratora danych"

Do jakich wniosków nas to prowadzi?
Mnie prowadzi do wniosku, który już wcześniej przedstawiłem. ;-)
Będąc osobą, której dane są przetwarzane, jestem podmiotem ochrony danych osobowych, dlatego też nikt nie ma mocy upoważnienia mnie do przetwarzania moich danych.Przemysław Osiak edytował(a) ten post dnia 01.04.11 o godzinie 19:40
Leszek K.

Leszek K. Zarządzanie
bezpieczeństwem
informacji. Dane
osobowe.

Temat: Aplikacja udostępniona klientowi (np. bankowość...

Przemysław Osiak:

(...) Nie jest zasadne stanowienie takiego prawa, które by w sposób zbyt daleko idący w szczegóły regulowało każdą kwestie (...)

Otóż to! Dlatego jestem przeciwnikiem np. szczegółowo uregulowanej kwestii długości haseł albo częstotliwości ich zmiany, podczas gdy można by było ustalić - podobnie jak w ustawie - hasło albo lepiej dostęp do systemu powinien byc zabezpieczony "odpowiednio do zagrożeń oraz kategorii danych objętych ochroną" (=definiowane przez ryzyko).

Pomijam (korzystną) rolę edukacyjną rozporządzenia :)



Wyślij zaproszenie do