dodany: 19.02.2013 | tagi: , , ,

Autor:

Przesyłanie danych w aplikacjach online

2

Udostępnianie systemów firmowych na zewnątrz sieci i umożliwianie użytkownikom dostępu do zasobów wewnętrznych to dziś praktycznie konieczność i chyba nie ma dziś organizacji, która nie posiadałaby chociaż własnej strony internetowej. Taka strona zwykle nie niesie za sobą ryzyka utraty danych i zawiera informacje, które celowo są upubliczniane, a sam serwis działa na wykupionej usłudze hostingowej gdzieś w Polsce lub poza granicami. Sytuacja się komplikuje, jeżeli tym udostępnianym rozwiązaniem jest jeden z systemów oferujący nie tylko publiczne dane, ale dedykowane dla konkretnej grupy odbiorców lub pojedynczego użytkownika, którzy mogą założyć konto, zalogować się, przejrzeć niepubliczne dane (np. listę faktur dotyczącej podpisanej przez siebie umowy z operatorem telekomunikacyjnym).

Może to być usługa w chmurze (w zarysie wspomniane przeze mnie we wcześniejszym artykule), ale też aplikacja wykorzystująca własną infrastrukturę i strefę zdemilitaryzowaną (o czym też pisałem wcześniej).

W przypadku systemu uruchamianego przy pomocy wykupionej usługi w chmurze, poza odpowiednio bezpiecznie funkcjonującymi modułami aplikacji, nie musimy martwić się o techniczne sposoby zabezpieczenia (a nawet za dużej możliwości manewru nie mamy). System posadowiony na własnych zasobach sprzętowych i uruchomiony na bazie własnej sieci i mechanizmów zabezpieczeń, wymaga od nas pieczołowitej opieki i nadzoru. Zyskujemy pełną kontrolę, ale też ponosimy pełną odpowiedzialność.

W trakcie korzystania z takiego udostępnionego zasobu, zawsze są przesyłane dane. Mniej lub bardziej poufne, ale najczęściej nie powinny się w żadnym wypadku dostać w niepowołane ręce. Poza samą kradzieżą informacji, grozi nam naruszenie integralności, niezaprzeczalności i utrata kontroli nad serwisem i danymi. Są to niebezpieczeństwa, które stają się realne, jeżeli administratorzy serwisów nie zadbają chociażby o podstawowe mechanizmy. Pomocne w weryfikacji, czy dostęp do systemu jest bezpieczny, czy nie, są testy penetracyjne i odpowiednia polityka bezpieczeństwa w firmie. Jak jednak stwierdzić w trakcie projektowania rozwiązania, jakie mechanizmy są odpowiednie i rozsądne w danej sytuacji? Jak nie przesadzić i nie przeinwestować, wdrażając niepotrzebne i przesadzone zabezpieczenia?

Na to pytanie nie ma odpowiedzi idealnej, ale na pewno przyda się wspomniana polityka bezpieczeństwa, połączona z pewną dozą rozsądku i wiedzy na temat obecnie stosowanych podejść i technologii. Nie bez znaczenia będzie także doświadczony personel w firmie lub chociaż wiarygodny i sprawdzony dostawca, który może przeanalizować sytuację i zasugerować najlepsze i optymalne techniki. Warto także stosować zasadę zabezpieczania przesyłanych danych zawsze wtedy, gdy są to dane osobowe, poufne, ważne i wszelkie inne, w przypadku których nie chcielibyśmy (lub nie powinniśmy pozwolić), żeby znalazły się w niepowołanych rękach.

Postaram się na prostym przykładzie zaprezentować, jak można podejść do tematu bezpieczeństwa komunikacji w wymyślonym na potrzeby tego artykułu rozwiązaniu. Jest to system, który umożliwia użytkownikom zamawianie produktów i dokonywanie płatności za nie przez zintegrowaną usługę płatności elektronicznych. Ogólna architektura rozwiązania zaprezentowana jest na poniższej ilustracji:

Obrazek1

System wewnętrzny (sklep internetowy) jest ulokowany w sieci wewnętrznej i odseparowany od internetu strefą zdemilitaryzowaną (DMZ). Jest także skomunikowany z odpowiednim interfejsem z drugim systemem zlokalizowanym w tej samej sieci – systemem rozliczeniowym wystawiającym faktury dla klientów. Na zewnątrz sieci wewnętrznej firmy jest także usługa płatności elektronicznych. Niebieskimi połączeniami zaprezentowałem przebieg danych wewnątrz sieci firmy, czerwony kolor obrazuje kanał publiczny, gdzie dane w komunikacji z użytkownikiem są przesyłane już poza wszelkimi zabezpieczeniami firmy. Zielonym kolorem dodatkowo oznaczyłem kanał wykorzystywany w komunikacji z systemem płatności elektronicznych, który może używać (a nawet powinien) wymagać większego poziomu bezpieczeństwa, niż kanał dla użytkownika.

Można teraz zadać pytanie – jakie zabezpieczenia w którym miejscu trzeba stosować? Zapewne od razu nasuwa się pomysł, że https/SSL musi być wszędzie, gdzie jest połączenie zestawiane z wykorzystaniem sieci publicznej i to jest prawda – te połączenia należy odpowiednio zabezpieczyć i nierozsądne byłoby przesyłanie danych w postaci otwartej. A co z innymi interfejsami? Czy trzeba je dodatkowo zabezpieczać? Czy może jednak wystarczy zwykłe połączenie http?

Podejście zależy od kilku czynników – rodzaju przesyłanych danych (czy są poufne, czy są to dane osobowe, czy może w wariancie najbardziej krytycznym – dane wrażliwe), zaufania do sieci, w której są interfejsy, możliwych do zainwestowania środków (zaufane certyfikaty nie są oferowane za darmo) i wielu innych okoliczności, które mogą wyjść przy okazji projektowania rozwiązania i analizy tematu.

Na ilustracji poniżej naniosłem przykład, jak może wyglądać sposób komunikacji w tym rozwiązaniu.

Obrazek2

Po pierwsze czerwone połączenia (publiczne) – obowiązkowo zabezpieczone certyfikatem – SSL. Użytkownik logując się do systemu, musi mieć pewność, że jego login i hasło nie zostaną podsłuchane i wykradzione. A dodatkowo nie może mieć miejsca podszycie się pod użytkownika, czy naruszenie integralności komunikatów.

Połączenie zielone – także zabezpieczone certyfikatami, które zagwarantują pewność transakcji płatniczej. Wszelkie interfejsy związane z przepływem środków pieniężnych muszą być w ten sposób potraktowane i nie wyobrażam sobie innego rozwiązania. Bez certyfikatu prosta droga do kłopotów i malwersacji finansowych. Oczywiście dotyczy to wywołania płatności elektronicznej i jej faktycznej realizacji. Zwykle mamy też drugi, równoległy kanał, którym powracają statusy dokonanych płatności i on już nie musi być aż tak ściśle zabezpieczony. Warto jednak i tu pokusić się o zakup certyfikatu – w razie włamania możliwe jest zaburzenie dostarczania statusów i wiele płatności może pozostać dla systemu zamówień w statusie niezrealizowanych, co na pewno spowoduje wysyp zgłoszeń od klientów domagających się swoich pieniędzy. W obu “zielonych” kanałach warto (o ile nie jest to i tak wymagane przez dostawców usługi płatności) zastosować dodatkowe mechanizmy – np. dopuszczanie do usługi połączeń tylko z określonego zakresu adresów IP – to mocno utrudni wywołanie usług z innych niż dozwolone lokalizacji. Usługa płatności może akceptować tylko połączenia z systemu zamówień, a system zamówień akceptować połączenia tylko z usługi płatności. To bardzo proste rozwiązanie podwyższa poziom bezpieczeństwa i w kombinacji z certyfikatami pozwala spać spokojnie.

Teraz połączenia “niebieskie” – wewnątrz sieci – zarówno przekierowujące dane użytkowników, jak i dane płatności realizowanych w systemie zamówień. Tu poziom bezpieczeństwa jest mocno uzależniony od zaufania do infrastruktury, po której odbywa się komunikacja. Jeżeli jest to jedna wspólna sieć firmowa, odseparowana przez DMZ od sieci zewnętrznej, można zrezygnować z dodatkowych mechanizmów i ruch zrealizować bez zabezpieczania certyfikatami i połączeń szyfrowanych. Tyle można stwierdzić teoretycznie. W praktyce zależy to też trochę od podejścia działów bezpieczeństwa i od przeróżnych polis i procedur firmowych. W dużych firmach pracownicy mają do podpisania przy zatrudnieniu sterty papierów, w których zobowiązują się do zachowania poufności, niewynoszenia danych firmowych i innych ograniczeń.

Jeżeli zespół wdrażający projekt w porozumieniu ze sponsorami lub zarządem firmy stwierdzi, że zaufanie jest na tyle duże, że nie ma się czego obawiać ze strony personelu pracującego wewnątrz firmy, wtedy nie trzeba stosować zabezpieczeń. Jeżeli jest inaczej i kierownictwo obawia się, że ktoś może mimo wszystko ingerować w ruch pomiędzy systemami, wtedy sugerowane jest mimo wszystko zabezpieczenie połączeń. To generuje obciążenie i spowolnienie komunikacji – dlatego decyzja nie jest łatwa i musi być poprzedzona analizą – jakie dane przechodzą między systemami, czy ich utrata lub podszycie się może być groźne w skutkach, czy ktoś może zrobić z nich użytek itd. Szyfrowanie połączeń to kolejne koszty i nakład pracy (implementacja, testy). Z drugiej strony, jeżeli kierownictwo nie ma zaufania do pracowników, to problem jest bardziej złożony niż tylko możliwość podsłuchania komunikacji czy kradzieży. Administratorzy mają pełny dostęp do wybranych elementów infrastruktury lub do całych struktur – teoretycznie są w stanie narobić najwięcej szkód, ale nie jest to jednak powszechne.

Każdy wewnętrzny kanał komunikacyjny powinien być dogłębnie przeanalizowany i każdorazowo skonfrontowany z polityką bezpieczeństwa firmy i skonsultowany z działem bezpieczeństwa (tam gdzie obie te instytucje funkcjonują). Jeżeli przesyłane są dane niekrytyczne (np. wiadomości ogólnofirmowe), nie warto zbytnio inwestować w zabezpieczenia, które w ogóle nie będą użyte (bo po co?) a i wygenerują problemy (opóźnienia w transmisji, koszty, odnawianie certyfikatów). Tam jednak, gdzie dane są ważne, krytyczne, wrażliwe (to tylko w niektórych rozwiązaniach – jeżeli nie jest to wymagane nawet nie wolno przetwarzać takich danych), warto zainwestować i mieć pewność, że zrobiliśmy wszystko, co możliwe, żeby uniknąć problemów. Certyfikaty nie są drogie, porównując koszt do potencjalnych strat, jakie się mogą pojawić w przypadku niepowołanego dostępu i kradzieży danych.

Przykład powyżej to tylko proste odwzorowanie systemu – zwykle rozwiązania są dużo bardziej skomplikowane i rozbudowane, a interfejsów jest o wiele więcej. To oznacza sporo więcej pracy nad uważnym zaprojektowaniem komunikacji i wyłapaniem tych wszystkich kanałów, które muszą być zabezpieczone. Zachęcam Was do zapoznania się z rozwiązaniami usług płatności elektronicznych (jak eCard, BlueCash, PayU, Przelewy24), które mają dość dobrze przemyślane sposoby komunikacji, a dodatkowo warto znać zasady ochrony danych osobowych dostępne chociażby w poradniku ABC bezpieczeństwa danych osobowych w systemach informatycznych. Postaram się do tej tematyki jeszcze nawiązać w przyszłości, trochę lepiej opisując mechanizmy rządzące przesyłaniem danych, w szczególności płatności elektronicznych.

avatar

M S

2 odpowiedzi na “Przesyłanie danych w aplikacjach online”

  1. avatar seciurak napisał(a):

    super tekst!

  2. avatar dpils.ru napisał(a):

    Long range wireless doorbells and wireless doorbells have almost exactly the same functions except a long range doorbell can transmit messages from over
    150 ft from the receiver. 35K resistor across these pin-outs shunts the IC to
    the above gain. A mesh pocket on the exterior of the bed accommodates a tee shirt or shorts and
    provides optimal air circulation that allows the dog to easily detect the owner’s calming,
    familiar scent.

Odpowiedz na „seciurakAnuluj pisanie odpowiedzi

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *