Pomoc - Szukaj - Użytkownicy - Kalendarz
Pełna wersja: Zabezpieczanie wrażliwych danych osobowych
Forum PHP.pl > Forum > PHP
adbacz
Czy macie jakieś doświadczenie w zabezpieczaniu dwanych wrażliwych w aplikacjach webowych? Przykładowo, na stronie jest formularz w którym podaje się imię, nazwisko, adres zamieszkania, adres e-mail i numer telefonu. Wszystko to już razem jest daną wrażliwą, więc należy to zabezpieczyć. Jak to wygląda w waszych aplikacjach?

Nie mówię tutaj o umowie powieżenia danych, informacji do GIODO itp. Chodzi mi tylko o czyste zabezpieczenia tych danych, typu szyfrowanie przed wrzuceniem do DB np.
Pyton_000
Szyfrujesz tylko hasło. Ew. jakieś PIN itd. czyli dane których się nie odzyskuje a resetuje.

Musisz podnieść poziom bezpieczeństwa przechowywania danych. Czyli np. bardzo silne hasła do serwerów, baz itd. Ograniczone i monitorowane dostępy, separacja itd itd.
SSL must have.
adbacz
Cytat
czyli dane których się nie odzyskuje a resetuje


Chodzi Ci o szyfrowanie hasła do konta użytkownika? Niezbyt rozumiem. Tych danych wrażliwych, czyli adresu zamieszkania, już nie trzeba szyfrować? Mógłbyś rozwinąć myśl?
!*!
Cytat(adbacz @ 21.11.2016, 15:39:40 ) *
Tych danych wrażliwych, czyli adresu zamieszkania, już nie trzeba szyfrować? Mógłbyś rozwinąć myśl?


Można, tylko po co? Zabezpieczasz bazę, serwer, oprogramowanie (przemyślana logika biznesowa). Jeśli ktoś nieuprawniony zdobędzie dostęp do serwera, lub bazy to odkoduje sobie te dane i nie będzie miało to znaczenia w jakiej są formie
adbacz
Jak dostanie się do serwera to tak, zrobi co będzie chciał. Ale jeśli dostanie się tylko do bazy danych, to będzie miał utrudnione zadanie by dostać się do danych, bo będą zaszyfrowane. Musiałby wiedzieć jak są zaszyfrowane, by je odszyfrować.
!*!
A to już takie oczywiste nie jest. Zależy to od wielu czynników
by_ikar
Cytat(adbacz @ 21.11.2016, 16:49:20 ) *
Jak dostanie się do serwera to tak, zrobi co będzie chciał. Ale jeśli dostanie się tylko do bazy danych, to będzie miał utrudnione zadanie by dostać się do danych, bo będą zaszyfrowane. Musiałby wiedzieć jak są zaszyfrowane, by je odszyfrować.


Raczej się nie wystawia bazy na świat, tylko dostęp do niej jest via jakaś podsieć.
sazian
Cytat(adbacz @ 21.11.2016, 15:49:20 ) *
Jak dostanie się do serwera to tak, zrobi co będzie chciał. Ale jeśli dostanie się tylko do bazy danych, to będzie miał utrudnione zadanie by dostać się do danych, bo będą zaszyfrowane. Musiałby wiedzieć jak są zaszyfrowane, by je odszyfrować.


To teraz wyobraź sobie że chciałbyś wyszukać wszystkie osoby z jakiegoś miasta. Albo jeszcze lepiej, szukasz osobny o imieniu Jan, nazwisku zaczynającym się na Now.
I co ? A no dupa. Nie zrobisz tego w bazie bo dane są zaszyfrowane, musisz pobierać wszystko, odszyfrować i dopiero porównywać.

Wyobrażasz sobie takie wyszukiwanie przy milionie rekordów ?
lukaskolista
Cytat
Nie mówię tutaj o umowie powieżenia danych, informacji do GIODO itp. Chodzi mi tylko o czyste zabezpieczenia tych danych, typu szyfrowanie przed wrzuceniem do DB np.

A szkoda, że nie mówisz o GIODO, bo GIODO daje jasne wytyczne co do sposobu przechowywania takich danych.
adbacz
@lukaskolista - A masz może jakieś namiary na dokument z GIODO dotyczący tego tematu? Wcześniej tylko pisałem o zgłoszeniu zbioru do GIODO, nie znalazłem dokumentu od nich mówiącego jasno co trzeba zrobić w temacie zabezpieczenia aplikacji WEB.
Pilsener
Tak. Dane takie są "wypychane" na inną maszynę. Dostęp do nich odbywa się w najprostszej postaci bezpośrednio, jako dostęp do bazy lub też (co jest preferowane) przez specjalny serwis.
Idea jest taka, że jak ktoś uzyska dostęp do bazy aplikacji nie będzie miał "danych wrażliwych", natomiast jak uzyska dane wrażliwe to nie będzie miał ich z czym połączyć. Musiałby mieć obie bazy (co podnosi poziom bezpieczeństwa).
adbacz
@Pilsener - Czyli podsumowując, aplikacja podpinana jest pod dwie osobne bazy, najlepiej na dwóch różnych maszynach - na jednej trzymamy dany wrażliwe, a na drugiej dane aplikacji. Tylko nie rozumiem co to da, skoro jak ktoś się dostanie do bazy z danymi to i tak będzie miał wszystko na talerzu, jak nie będzie to zaszyfrowane.
Pilsener
Cytat(adbacz @ 22.11.2016, 08:57:24 ) *
Tylko nie rozumiem co to da


Da to, że jak ktoś wyciągnie coś z pierwszej bazy zobaczy:
id | login | id_surname | id_email | password |

A jak do drugiej:
id | surname |

Musiałby mieć obie bazy i znać jeszcze sposób powiązania danych (bo nie zawsze jest tak oczywisty jak w moich przykładzie). Tą drugą bazę można jeszcze dodatkowo zabezpieczyć.
adbacz
@Pilsener - Fakt, masz rację. Tego nie przewidziałem smile.gif

Wygląda na to, że trzeba trochę pogłówkować by zabezpieczyć to w taki sposób, by ktoś niepowołany miał problem z "ogarnięcie" jak działa system by się do tego wszystkiego dobrać.
Pyton_000
Nie musisz aż tak kombinować. Wystarczy zachowanie podstaw bezpieczeństwa.
sazian
Jakoś pomysł z dwiema bazami też mi się nie podoba tongue.gif
Przecież po środku i tak stoi aplikacja która musi mieć dostęp do obu baz, więc dostają się do aplikacji i tak mam wszystkiego...
Poza tym to znowu morduje wyszukiwanie, jak tu zrobić normalnego joina czy subquery pomiędzy odseparowanymi bazami ?
Pilsener
Cytat(sazian @ 22.11.2016, 19:45:23 ) *
Jakoś pomysł z dwiema bazami też mi się nie podoba tongue.gif

1. Wymagania prawne (a jak dobrze wiemy, twórcy prawa są totalnymi ignorantami w dziedzinie IT)
2. Wymagania klienta

Natomiast jak to zrobisz, czy API, czy dostęp bezpośredni, jaki silnik wyszukiwana - to są detale businesssmiley.png
I to ma być zabezpieczenie na dość popularny przypadek, gdy ktoś np. dokona SQL injection typu " UNION select from users...." a nie na wypadek przejęcia kontroli nad aplikacją. Zresztą tak szczerze to mnie to dużo nie obchodzi, cieszę się, że robota jest nerdsmiley.png
adbacz
A czy macie jakies informacje gdzie można znaleźć jakąś lekturę - z GIODO na przykład - dotyczącą wymogów zabezpieczeń?

Znalazłem tylko jedną, "ABC bezpieczeństwa cośtam...", ale jest to dokument z 2007 roku, i chyba trochę przeterminowany.
Pyton_000
Cytat
1. Wymagania prawne (a jak dobrze wiemy, twórcy prawa są totalnymi ignorantami w dziedzinie IT)

Przytocz proszę...
To jest wersja lo-fi głównej zawartości. Aby zobaczyć pełną wersję z większą zawartością, obrazkami i formatowaniem proszę kliknij tutaj.
Invision Power Board © 2001-2025 Invision Power Services, Inc.