Zabezpieczenia danych medycznych w chmurze

Podziel się

I idąc za ciosem kolejny artykuł (żeby nie było, że nic nie publikuje ;)) Tym razem o sposobach zabezpieczeń danych medycznych na przykładzie konkretnych mechanizmów w Azure.

Przyglądamy się rozwiązaniom chmurowym pod kątem zabezpieczenia danych w sektorze medycznym w podziale na ogólnie przyjęte rodzaje platform chmurowych oraz mechanizmy, dzięki którym to bezpieczeństwo można zwiększyć, a także wykazać się zasadą rozliczalności, o której tak wiele mówi się w kontekście nowego unijnego rozporządzenia o ochronie danych osobowych.

Bardzo ważnym aspektem pojawiającym się u każdego managera IT, którego organizacja przetwarza dane o szczególnym priorytecie, jest kwestia zapewnienia bezpieczeństwa tych danych. Nie inaczej jest i w przypadku danych medycznych – ich bezpieczeństwo powinno być priorytetem. „No jak to, przecież się nie da”, „przecież muszę mieć możliwość fizycznego audytu danych, za które odpowiadam”, „trzymanie danych medycznych gdzieś za granicą jest niemożliwe i niebezpieczne” – często na konferencjach w oficjalnych pytaniach czy kuluarowych rozmowach słychać takie wątpliwości. Przyjrzyjmy się zatem w pierwszej kolejności temu, co mówią nam nowe regulacje odnośnie do wymagań, jakie trzeba spełnić z perspektywy podmiotu przetwarzającego dane osobowe w chmurze.

Zarówno przepisy uodo, jak i rodo regulują i dopuszczają powierzenie danych osobowych. Trzeba pamiętać o tym, że Komisja Europejska w motywie 81 preambuły rodo wskazuje na konieczność korzystania wyłącznie z usług takich podmiotów przetwarzających, które zapewniają wystarczające gwarancje wdrożenia odpowiednich środków technicznych i organizacyjnych, w szczególności jeżeli chodzi o wiedzę fachową, wiarygodność i zasoby, odpowiadających wymaganiom bezpieczeństwa przetwarzania, w tym wymaganiom określonym przez rodo. Najlepszą wskazówką w szukaniu odpowiedniego usługodawcy usług chmurowych (także zgodnie z dokumentem „Rekomendacje Centrum Systemów Informacyjnych Ochrony Zdrowia w zakresie bezpieczeństwa oraz rozwiązań technologicznych stosowanych podczas przetwarzania dokumentacji medycznej w postaci elektronicznej”) mogą być międzynarodowe standardy postępowania z danymi osobowymi, a zatem normy takie jak: ISO/IEC 27001, ISO/IEC 27002, ISO/IEC 22301 oraz normy branżowe, np. ISO 13606-1, ISO 13606-4. Warto zwrócić też uwagę na normę ISO/IEC 27018.

Oczywiście trzeba zdawać sobie sprawę z możliwych incydentów bezpieczeństwa, które są nieco odmienne dla rozwiązań chmurowych w porównaniu z rozwiązaniami on premise. Rozważaniami na ten temat na poziomie europejskim zajęła się Grupa Robocza art. 29, która w opinii 5/2012 w sprawie przetwarzania danych w chmurze obliczeniowej przyjętej w dniu 1 lipca 2012 r. przeanalizowała kwestie istotne dla dostawców usług przetwarzania danych w chmurze działających w Europejskim Obszarze Gospodarczym (EOG) oraz ich klientów, określając wszystkie mające zastosowanie zasady z dyrektywy o ochronie danych UE (95/46/WE) oraz dyrektywy o prywatności i łączności elektronicznej 2002/58/WE (zrewidowanej dyrektywą 2009/136/WE). Wtedy nie było jeszcze mowy o rodo, ale specjaliści wskazują, że w tym zakresie nie zachodzą żadne zmiany w opinii.

Główne opisane zagrożenia obejmują brak kontroli oraz brak przejrzystości (różne aspekty, m.in.: brak dostępności, brak integralności, brak odizolowania). W ramach grupy roboczej opracowano także wytyczne dla klientów i dostawców usług przetwarzania danych w chmurze. To ważny aspekt związany z bezpieczeństwem przetwarzania danych osobowych i wrażliwych (a zatem także medycznych), ponieważ właśnie te wytyczne powinny być dla działów IT podstawą do opracowywania procedur ochrony danych przetwarzanych w środowiskach, za które odpowiadają. Są one także podstawą do zrozumienia, na jakich zasadach przetwarzać w chmurze dane swojej organizacji, aby zapewnić im bezpieczeństwo oraz sobie kontrolę nad nimi. Zgodnie ze wspominanym wcześniej dokumentem opracowanym przez CSIOZ najważniejsze z nich to:

  • Odpowiedzialność klienta usługi w chmurze jako administratora – klient powinien wybrać dostawcę usługi w chmurze, który gwarantuje zgodność z przepisami w zakresie ochrony danych, co odzwierciedlają odpowiednie zabezpieczenia umowne;
  • Zabezpieczenia w przypadku powierzenia – przepisy dla podmiotów, którym powierzono realizację usług, powinny być przewidziane w każdej umowie pomiędzy dostawcą usługi w chmurze i jego klientami;
  • Przestrzeganie podstawowych zasad ochrony danych – klientowi należy zapewnić zrozumiałe informacje na temat środków technicznych i organizacyjnych wdrożonych przez dostawcę; klient w ramach dobrych praktyk powinien przekazać osobom, których dane dotyczą, informacje na temat dostawcy usługi w chmurze, jak również dane na temat lokalizacji, w których dane mogą być przechowywane lub przetwarzane;
  • Określenie i ograniczenie celu – klient powinien zapewnić zgodność z zasadami określenia i ograniczenia celu przetwarzania danych oraz zadbać o to, aby żadne dane nie były przetwarzane do innych celów przez dostawcę;
  • Zatrzymywanie danych – klient jest odpowiedzialny za zapewnienie, aby dane osobowe zostały usunięte ze wszystkich miejsc, w których są przechowywane, w przypadku gdy ich przetwarzanie nie odbywa się lub realizowane jest prawo (do zapomnienia) osoby, której dane dotyczą;
  • Zabezpieczenia umowne – umowa z dostawcą powinna zapewniać wystarczające gwarancje pod względem technicznych środków bezpieczeństwa i środków organizacyjnych;
  • Dostęp do danych – tylko upoważnione osoby powinny mieć dostęp do danych. W umowie powinna być zawarta klauzula poufności w odniesieniu do dostawcy i jego pracowników;
  • Zobowiązania do współpracy – klient powinien zapewnić, aby dostawca był zobowiązany do współpracy w związku z prawem klienta do monitorowania operacji przetwarzania, do ułatwiania realizacji praw osób, których dane dotyczą, do dostępu do/poprawiania/usuwania ich danych oraz do powiadamiania klienta usługi w chmurze o wszelkich naruszeniach ochrony danych mających wpływ na dane klienta;

źródło:  Artykuł pochodzi z czasopisma „IT Professional” nr 04/2018.

(http://www.it-professional.pl/archiwum/art,7951,zabezpieczenia-danych-medycznych-w-chmurze.html)

1 Shares:
46 comments
  1. Pingback: viagra
  2. Pingback: levitra 20 mg
  3. Pingback: cialis online
  4. Pingback: viagra 100mg
  5. Pingback: best custom essay
  6. Pingback: psychology thesis
  7. Pingback: buy cialis online
  8. Pingback: viagra
  9. Pingback: generic viagra
  10. Pingback: how to get viagra
  11. Pingback: peoples pharmacy
  12. Pingback: european cialis
  13. Pingback: nnoyxmfl
  14. Pingback: buy cialis
  15. Pingback: buy viagra
Dodaj komentarz

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

You May Also Like

Polityka bezpieczeństwa – wykaz budynków, pomieszczeń

Podziel się

Dzisiaj krótka i łatwa kontynuacja budowania naszej polityki bezpieczeństwa. Mamy zidentyfikowane zbiory danych, przypisane osoby oraz pomieszczenia w których te osoby się znajdują. Teraz, żeby wszystko było w porządku spróbujmy wyłuskać pomieszczenia z poprzedniego przykładu. Czyli np.:

recepcja, gabinet 1, gabinet 2, gabinet 3, sekretariat, sala rehabilitacji 1 .

Zastanówmy się czy to z pewnością wszystkie miejsca? Ułatwi to poniższa tabelka do której dla porządku dopiszmy sobie jeszcze oprogramowanie w których są przetwarzane dane osobowe.

1. Wykaz pomieszczeń, w których przetwarzane są dane osobowe (wskazanie konkretnych nr pomieszczeń) recepcja, gabinet 1, gabinet 2, gabinet 3, sekretariat, sala rehabilitacji 1
2. Wykaz pomieszczeń, w których znajdują się komputery stanowiące element systemu informatycznego recepcja, gabinet 1, gabinet 2, gabinet 3, sekretariat, sala rehabilitacji 1, pomieszczenie informatyka
3. Wykaz pomieszczeń, gdzie przechowuje się wszelkie nośniki informacji zawierające dane osobowe recepcja, gabinet 1, gabinet 2, gabinet 3, sekretariat, sala rehabilitacji 1, serwerownia, archiwum, pomieszczenie informatyka
4. Wykaz pomieszczeń, w których składowane są uszkodzone komputerowe nośniki danych (taśmy, dyski, płyty CD, dyski przenośne, uszkodzone komputery) recepcja, gabinet 1, gabinet 2, gabinet 3, sekretariat, sala rehabilitacji 1, serwerownia, archiwum, pomieszczenie informatyka
5. Wykaz pomieszczeń archiwum pokój nr 6
6. Wykaz programów, w których przetwarzane są dane osobowe Symfonia, Płatnik, PSS

 

7. Wykaz podmiotów zewnętrznych, które mają dostęp do danych osobowych lub je przetwarzają na podstawie podpisanych umów (np. informatyk) – nazwa firmy, imię, nazwisko, adres, funkcja. Firma “Usługi IT” Michał Zieliński

ul. Długa 80, Warszawa

osoby: Michał Zieliński, Łukasz Madejski – informatycy


Usługi księgowe Bożena Słomiana

ul. Niska 100, Skierniewice

osoby: Bożena Słomiana

 

 

 

 

 

To bardziej szczegółowe zestawienie. Tutaj nie do końca interesują nas przetwarzane zbiory danych. Może być tak, że na przykład w danym pomieszczeniu nie są dane zbiory przetwarzane ale mimo wszystko jest tam dostęp (czy to fizyczny czy poprzez system IT) do danych osobowych i medycznych. Na komentarz zasługuje z pewnością punkt 3 w tabeli. Chodzi tutaj o np. szafy z dokumentacją papierową, szafy zawierające komputerowe nośniki informacji z kopiami zapasowymi danych, stacje komputerowe, serwery i inne urządzenia komputerowe. W pkt. 6 nie mamy pomieszczeń tylko oprogramowanie. To także ważne, żeby wiedzieć i mieć świadomość w jakich aplikacjach wrażliwe dane są przetwarzane – chociażby w kontekście zabezpieczeń tych systemów. Uzupełnieniem tego spojrzenia jest wykaz podmiotów zewnętrznych, które czy to w naszej placówce (np. informatyk) czy na zewnątrz (np. biuro księgowe) przetwarzają dane naszych pracowników czy pacjentów.

Ostatnio na jednej z konferencji spotkałem się z prawniczą opinią, że zgodnie z nowymi przepisami RODO posiadanie polityki bezpieczeństwa nie jest konieczne (a do tej pory trzeba było ją mieć jakby ktoś nie wiedział :)) Moim zdaniem nie zmienia to faktu, że jest to dokument niezbędny do uporządkowania miejsc i zasad przetwarzania danych a także ujednolicenia na poziomie firmy poziomów zabezpieczeń i odpowiednich procedur (np. szkolenia pracowników). Powiem inaczej – 100% rzeczy, które powinny znajdować się w Polityce Bezpieczeństwa RODO wymaga. Dlatego przedstawiona opinia mnie poruszyła bo jest to niepotrzebne “zamydlanie oczu” i kolejna komplikacja dla osób odpowiedzialnych za porządek w placówce.

Biorąc pod uwagę powyższe z uporem maniaka będę przedstawiał kolejne aspekty, które taki dokument powinien zawierać.

Read More

Chmura w praktyce – część 1 – VPN

Podziel się

Na wstępnie chciałbym zaznaczyć, że żaden z moich wpisów nie jest wpisem sponsorowanym. Mam zamiar pokazywać tutaj różne produkty, ich wady i zalety. Nie będę ukrywał, że najczęściej będą to produkty, które sam wdrażam klientom – ale to chyba dobrze, bo na ich temat mam większą wiedzę. Mnogość rozwiązań w każdym temacie zmusza do skupienia się na czymś bo inaczej nie będę w stanie nic konkretnego pokazać. Przygodę z chmurą publiczną chciałbym zatem rozpocząć od rozwiązania Microsoftu – Azure. Dlaczego? Bo sam ją teraz testuje. W miarę wolnego czasu chętnie skupię się na innych rozwiązaniach, mogę też pokusić się o porównanie. W tym momencie jednak moim celem jest pokazanie na przykładzie tego, w jaki sposób usługi chmurowe mogą przyczynić się do usprawnienia pracy i zwiększenia bezpieczeństwa danych w placówce medycznej. Zaczynajmy zatem swoją przygodę z chmurą!

We wpisie “Co to jest chmura i czy może nam się przydać?” opowiedziałem (nic odkrywczego) o rodzajach chmury i sposobach jej wykorzystania. Zakładajmy zatem szybko konto i logujmy się do swojej chmury aby zobaczyć jak to wygląda w praktyce. Microsoft daje nam 170 euro i 30 dni na zabawę. Po tym czasie możemy korzystać z zasobów darmowych przez kolejny rok. W szczególnych przypadkach z pomocą resselera (np. mnie) można bez problemu testową usługę przedłużyć. Albo założyć nowe konto testowe 😉 Z minusów – w celach aktywacyjnych trzeba podać dane swojej karty kredytowej. Też się krzywiłem ale spokojnie, nic bez naszej wiedzy z konta nie ma prawa zostać zabrane i tak się nie stanie.

Pierwsze logowanie

Żeby zalogować się do usługi musimy  mieć swoje konto w MS. Wejdźmy najpierw na stronę https://azure.microsoft.com/pl-pl/free/ (tutaj można przeczytać więcej info o możliwościach testów) a następnie “Rozpocznij bezpłatnie”. Zostaniemy przekierowani na stronę logowania MS i jeżeli mamy konto wystarczy się zalogować. Jeżeli nie – musimy przejść do rejestracji nowego konta.

Możemy wybrać dwie metody weryfikacji konta – albo telefonicznie albo mailowo. Na wybrane medium przyjdzie nam hasło, które będziemy musieli wpisać potwierdzając, że to nasze. Później jeszcze tylko captcha (przepisanie tekstu z obrazka) i wypełnienie formularzy z danymi:

Na tym etapie musimy podać numer telefonu a następnie wybrać rodzaj weryfikacji (sms lub telefon):

Później zostają już (tylko) dane karty:

zatwierdzenie umowy licencyjnej i jesteśmy w domu.

Następnie po przekierowaniu, lub po wejściu na stronę https://portal.azure.com jesteśmy po raz pierwszy w swoich zasobach chmurowych. Oczom naszym ukaże się dashboard:

Proponuję poklikać tutaj z 10 minut i wiele rzeczy stanie się jasne. Możliwości dopasowania do swoich potrzeb są ogromne – zarówno pod kątem wyglądu jak i elementów wyświetlanych. W miarę dodawania nowych usług nasza strona główna będzie ewoluowała – musimy się po prostu tego nauczyć. Praca tutaj jest w miarę intuicyjna i przyjemna. Jak czegoś nie wiemy – Google wie wszystko a MS dokumentację ma.

Jak widzicie przeklikanie wszystkich usług graniczy z cudem. Tyle tego jest a do tego cały czas dodawane są kolejne. Warto też zaznaczyć, że w Azure nie są dostepne usługi Office365 – czyli popularnego pakietu do tworzenia i zarządzania dokumentami w chmurze. To odrębny i wbrew pozorom również bardzo rozbudowany temat.

Tworzenie VPN Point-to-Site do chmury

Długo zastanawiałem się od czego zacząć. Zdecydowałem, że zacznę od końca. Utworzymy sobie (jeden z wielu możliwych do utworzenia) szyfrowany kanał komunikacji pojedynczej stacji roboczej (czy serwera, to bez znaczenia) do naszej instancji chmurowej a konkretniej – do jednej z nowo utworzonych sieci wirtualnych. W tej sieci na dalszym etapie będziemy mogli tworzyć sobie maszyny wirtualne czy inne usługi do których będziemy chcieli mieć dostęp z poziomu komputerów w placówce. Jeżeli chodzi o pytania dotyczące bezpieczeństwa (bezpieczeństwo to raz a RODO dwa :)) to już  odpowiadam. Połączenia w tym modelu są szyfrowane na dwa sposoby:

  • Secure Socket Tunelling Protocol (SSTP) – używany głównie w systemach Windows protokół przenoszący ramki PPP (te, które odpowiadają za komunikację w modelu Point-to-Point i w naszym przypadku za Point-to-Site) poprzez bezpieczny kanał szyfrowania Transport Layer Security (TLS) i jego poprzednika – Secure Socket Layer (SSL)
  • Internet Key Exchange version 2 (IKEv2) – protokół transmisji danych poprzez protokół IpSec.

Opis działania tych protokołów jest tutaj zbędny. Proponuję po prostu przyjąć, że połączenie to jest bezpieczne na nasze potrzeby. W przypadkach szczególnych trzeba sytuację analizować i dopasowywać do szczególnych potrzeb a tutaj pole do popisu jest.

Aktualnie możliwe jest połączenie z następujących systemów operacyjnych:

  • Windows 7 (32-bit and 64-bit)
  • Windows Server 2008 R2 (64-bit only)
  • Windows 8 (32-bit and 64-bit)
  • Windows 8.1 (32-bit and 64-bit)
  • Windows Server 2012 (64-bit only)
  • Windows Server 2012 R2 (64-bit only)
  • Windows Server 2016 (64-bit only)
  • Windows 10
  • OSX version 10.11 for Mac (El Capitan)
  • macOS version 10.12 for Mac (Sierra) .

Samych usług VPN Microsoft ma co najmniej kilka. Prawie każdą z konfiguracji możemy zrobić na różne sposoby (np. wyklikując lub korzystając z linii komend PowerShella). Więcej o tych sposobach a także o możliwościach konkretnych modeli a także o tym jak dany model połączenia skonfigurować można przeczytać tutaj: https://docs.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-plan-design . Jeżeli chodzi natomiast o pełną konfigurację tego co przestawiłem poniżej to wersję oficjalną na której bardzo mocno bazowałem znajdziecie pod tym adresem .

Dodawanie sieci wirtualnej i bramy dla VPN

Wejdźmy na Marketplace i wpiszmy “Virtual Network”. Zaznaczmy żądaną opcję , “deployment model” wybierzmy “Resource Manager”.

Wypełnijmy pola formularza w następujący sposób (subscription mamy do wyboru tylko Free Trial):

Czyli tworzymy wirtualną sieć o nazwie VNet1 (192.168.0.0 – 192.168.255.255) z podsiecią FrontEnd dla naszej infrastruktury (192.168.1.0 – 192.168.1.255). Następnie musimy stworzyć w naszej sieci wirtualnej  podsieć dla bramy domyślnej – klikjijmy na +Gateway subnet dla naszej podsieci. w ustawieniach sieci:

i podajmy jakąś wolną podsieć z zakresu naszej sieci. Niech to będzie 192.168.200.0/24:

Teraz stwórzmy wirtualną bramę dla swojej usługi. W znanym już menu +New wpiszmy “Virtual network gateway”. Uzupełnijmy pola wybierając i wpisując następujące ustawienia (subscription to oczywiście Free Trial):

W tym miejscu musimy się chociaż na chwilę zatrzymać. Jeżeli chodzi o Gateway type  to jak się domyślamy rodzaje bram. Te rodzaje różnią się od siebie (w skrócie) gwarantowanym transferem oraz ilościom kanałów, które można utworzyć a co za tym idzie ceną. Więcej informacji na temat cen i sposobów rozliczania dostępne jest tutaj . Jeżeli chodzi o standardowe wykorzystanie naszego VPNa – do połączeń dla użytkowników wybieramy po prostu VPN i odpowiedni typ i SKU (który mówi o cenie, transferze oraz ilości tuneli). W przypadku gdybyśmy potrzebowali większego transferu – na przykład chcąc robić migrację większej ilości danych przez narzędzie, lub jakieś mechanizmy backupu itp. ExpressRoute pozwala korzystać z bardziej zaawansowanych protokołów WAN niż zwykły Internet (np. MPLS) i osiągać transery do 10 Gbps. To już kwestia indywidualnych potrzeb, w każdym razie warto zapamiętać, że w przypadku gdy ktoś nie ma pewności czy wybrać chmurę ze względu  na potrzebę zapewniania stabilności i szybkości transferu to nie ma się o co martwić. Zawsze zrobi się tak, jak będzie trzeba . Więcej info o samym ExpressRoute znajdziecie tutaj .

Idąc dalej w konfiguracji wybierzmy naszą wirtualną sieć oraz kliknijmy w Create public IP adress i tam wybierzmy ustawienia Basic:

Następnie dajemy Create i rozpoczyna się proces tworzenia naszej bramy VPN.

Certyfikaty

Już sporo za nami – mamy utworzoną podsieć dla naszego środowiska z którym będziemy chcieli się łączyć, utworzyliśmy dla niego bramę domyślną. Teraz musimy zająć się certyfikatami. To zadanie musimy wykonać w dwóch etapach – po pierwsze wygenerować nasz główny certyfikat, który będzie miał za zadanie pilnować od strony platformy Azure naszych połączeń a następnie wygenerować certyfikat/certyfikaty dla klientów.

Zadania te możemy wykonać na dwa sposoby. Albo na jakimkolwiek PC z systemem operacyjnym Windows 10 (w przypadku gdy takowego nie mamy możemy na tą potrzebę utworzyć sobie na naszym koncie wirtualną maszynę na naszym Azure – ja tak zrobiłem) lub skorzystać z narzędzia MakeCert.

Jeżeli chodzi o bezpieczeństwo to nasze certyfikaty są oparte o algorytm hashujący sha256 a klucze zaszyfrowane są w schemacie Base64. Certyfikaty zapisane są w standardzie X.509 .

Procedura generowania została krok po kroku opisana tutaj i nie ma sensu jej powielać. W przypadku gdyby ktoś miał jakieś konkretne pytania zapraszam do ich zadawania. Jeżeli przejdziecie krok po kroku procedurę wszystko się uda.

Dokończenie konfiguracji na bramie domyślnej

Mając certyfikat główny możemy do dodać do konfiguracji naszej bramy.  W tym celu przechodzimy do jej konfiguracji – do zakładki Point-to-site Configuration:

Tam po pierwsze wpisujemy adres puli prywatnej dla bramy (adresy z tej puli będą dostawać komputery klientów i z tej sieci będzie routing do naszej sieci wirtualnej):

Następnie wybierzmy typy tuneli (opisane wcześniej) oraz nasz authentication type:

i kopiując nasz wygenerowany wcześniej root cert ze zwykłego notatnika:

nadajmy mu nazwę Rootcert1 i wklejmy go do konfiguracji bramy:

Instalacja certyfikatów u klientów

Teraz wystarczy wygenerowane wcześniej certyfikaty zainstalować u klientów. Dla Windows i Mac procedura opisana jest tutaj . Jest to dodawanie certyfikatów standardowe dla wszystkich usług i pewnie nie raz tak robiliśmy. Generowanie certyfikatów (jakby ktoś przeoczył) dostępne jest tutaj w sekcji na samym dole – Export a client certificate .

Pobieranie, konfiguracja i test klienta VPN

Sprowadza się to do ściągnięcia instalki z konfiguracji bramy (Download VPN Client na górze konfiguracji). Szczegóły opisane są tutaj (wrzucam ponieważ dla iOS wygląda to troszkę inaczej niż dla Windows gdzie wystarczy ściągnąć oprogramowanie,m zainstalować i mając zainstalowany już na kliencie certyfikat po prostu się podłączyć. Ale to też jest do zrobienia.

Finalnie (w Windowsie) odpalamy naszego klienta:

i połączenie zostanie utworzone:

Na tego potwierdzenia załączam screen ze swojego połączenia z jak widać przypisanym poprawnie adresem IP z puli:

Koszty

Wcześniej wspomniałem coś o kosztach i metodach rozliczeń tej usługi. Generalnie w celu estymacji jakichkolwiek cen w Azure i zapoznania się z metodami rozliczania polecam kalkulator znajdujący się pod tym linkiem: https://azure.microsoft.com/pl-pl/pricing/calculator/ . Będę go tutaj jeszcze używał.

Dla naszej usługi sprawa kosztów przedstawia się następująco:

Microsoft Azure Estimate
Twoje szacowanie
Service type Custom name Region Description SKU Estimated Cost
VPN Gateway West Europe Typ Bramy VPN Gateway, warstwa Podstawowa sieć VPN, godz. korzystania z bramy: 160, 50 GB, typ bramy VPN Gateway na wyjściu: VPN €8,16
Virtual Network Transfer danych z regionu Europa Zachodnia do regionu Europa Zachodnia: 50 GB €0,84
Support Free level Support €0,00
Monthly Total €9,00
Annual Total €108,03

 

 

 

 

Założyłem 50 GB miesięcznego transferu wychodzącego i tyle samo przychodzącego przy 160 godzinach w miesiącu działania bramy. To 38 zł przy transferze Basic (tutaj jeszcze raz pełny cennik) – 128 połączeń, transfer 100 Mb/s. Czy to dużo czy mało? Nie mnie odpowiadać na to pytanie. To kwestia indywidualnych potrzeb – w przypadku VPN potrzeb związanych z poziomem zapewnienia bezpieczeństwa, ilości połączeń, czasu dostępności połączenia (co także przekłada się na bezpieczeństwo), transferu miesięcznego a także szybkości. Jedno jest pewne. Możliwości dopasowania każdej z usług w tym modelu, także kosztowego dopasowania, są tak ogromne, że moim zdaniem każdy znajdzie optymalny dla siebie sposób.

Podumowanie

Uff udało się. Trochę tego było, prawda? Ale udało nam się skonfigurować naszą bazową usługę dla chmury. Jest to do przeklikania, trzeba tylko poznać strukturę i zależności. Jak widać bezpieczeństwo jest tutaj priorytetem. Aby jeszcze troszkę dołożyć odnośnie naszego słynnego RODO to istnieje możliwość uruchomienia swojej infrastruktury chmurowej w dwóch lokalizacjach w Niemczech. Jest to o tyle istotne, że lokalizacje te posiadają certyfikat ISO/IEC 27018:2014 charakteryzujący się spełnianiem podwyższonych norm z zakresu ochrony danych osobowych. Więcej można przeczytać tutaj. W innym przypadku zawsze można skorzystać z Holandii czy Irlandii. W każdym razie MS w zakresie bezpieczeństwa danych i wymogów RODO udostępnił (i stale rozwija) platformę na której możemy zobaczyć bardzo rozbudowaną dokumentację potwierdzającą zgodność z normami przetwarzania danych. Można tam także zobaczyć przykłady wdrożeń a także (narazie tylko dla o365 ale już wkrótce dla Azure) platformę, dzięki której sami będziemy mogli przeprowadzić audyt swojej chmury pod kątem konkretnych zapisów z RODO. Wszystko dostępne jest tutaj ale to biorąc pod uwagę, że jest oddzielnym i bardzo złożonym tematem czeka w kolejce na liście postów do napisania na blogu.

Zachęcam do testów!

P.S. Jak ktoś chciałby konto testowe bez podawania danych karty zapraszam 😉

Czy wdrożenie RODO to zadanie IT?

Podziel się

Klienci podczas rozmów bardzo często poruszają tę kwestię, mało tego, często w mniejszych placówkach słyszę, że informatyk się zajmuje RODO. Sprawa nie jest jednak taka prosta i oczywista. Aspekty IT to dość otwarta kwestia w RODO, ponieważ akt nie nakazuje niczego szczególnego. System i dane powinny być odpowiednio zabezpieczone. Należy sobie jednak zdawać sprawę z tego, że warstwa systemów informatycznych to tylko część procesu wdrożenia RODO w organizacji a samo wdrożenie to proces interdyscyplinarny wymagający zaangażowania trzech głównych warstw kompetencyjnych – regulacyjnej, organizacyjno-procesowej i dopiero warstwy systemów i infrastruktury IT.  Warstwa informatyczna jest to istotny, jednakże nie jedyny czynnik, który trzeba przystosować do nowych regulacji. Istotna w tym wymiarze jest także współpraca specjalistów z tych dziedzin tak aby wszystko przebiegło pomyślnie i z korzyścią dla szpitala, przychodni czy innego podmiotu.

Poniżej krótko opisałem ramowe czynności, które są do zrobienia przy wdrażaniu RODO w organizacji z podziałem na wspominane wcześniej obszary.

1. Warstwa regulacyjna:

– analiza konieczności powołania inspektora ochrony danych osobowych

– analiza konieczności prowadzenia rejestru czynności przetwarzania danych osobowych

– ocena legalności przetwarzania danych (podstawy prawnej, celu, zakresu przetwarzania)

– weryfikacja umów powierzenia

– weryfikacja dotychczasowych dokumentów dotyczących ochrony danych osobowych

2. Warstwa organizacyjno-procesowa

– identyfikacja zbiorów danych osobowych w organizacji

– identyfikacja procesów biznesowych przetwarzających dane osobowe

– weryfikacja osób i podmiotów zewnętrznych przetwarzających dane osobowe

– wskazanie kluczowych obszarów ryzyka, niezgodności oraz luk podczas przetwarzania danych w odniesieniu zarówno do procesów jak również dokumentacji biznesowej (polityk, procedur, umów) oraz klienckiej (np. klauzule zgód)

3. Warstwa systemów informatycznych

– obszar zarządzania danymi i procesami:

  • inwentaryzacja danych osobowych i ich jakości w zakresie całego środowiska informatycznego
  • identyfikacja narzędzi i przeprowadzenie działań inwentaryzacyjnych w procesach użytkowników końcowych

– obszar architektury systemów:

  • analiza funkcjonalności systemów informatycznych z uwzględnieniem wymogu anonimizacji i pseudonimizacji danych
  • „privacy by design”
  • analiza realizacji praw podmiotów danych – m.in. do usunięcia, przeniesienia, ograniczenia przetwarzania oraz aktualizacji w systemach informatycznych

– obszar bezpieczeństwa systemów:

  • środki zabezpieczające dane osobowe a istniejące standardy bezpieczeństwa
  • przeprowadzenie oceny wpływu planowanych operacji przetwarzania na prywatność
  • przygotowanie do zgłaszania naruszeń danych osobowych i przygotowanie rejestru czynności przetwarzania

Miłego wdrażania! 🙂

CSIOZ udostępnił dokumentację integracyjną w zakresie e-skierowania

Podziel się

Dokumentację można znaleźć pod adresem https://www.csioz.gov.pl/interoperacyjnosc/interfejsy/ . Obejmuje ona:

Dokumentacja integracyjna obejmuje:

  1. Specyfikację usług
  2. Opis i strukturę dokumentu elektronicznego skierowania
  3. Reguły biznesowe
  4. Kody wyników operacji
  5. Zasady otrzymania dostępu do środowiska integracyjnego .

Obiecano także, że pod koniec czerwca pojawi się środowisko testowe dla tej funkcjonalności.

CSIOZ naruszyło przepisy ustawy o ochronie danych osobowych?

Podziel się

Taka ciekawostka.. 23 listopada 2017 r. Prezes Naczelnej Rady Lekarskiej  skierował do Generalnego Inspektora Ochrony Danych Osobowych  pismo dotyczące ochrony danych osobowych lekarzy i lekarzy dentystów gromadzonych w systemie SMK:

“Niniejszym informuję o naruszeniu przepisów ustawy z dnia 29 sierpnia 1997 r. o ochronie danych osobowych (Dz. U. z 2016 r. poz. 922), do którego doszło 16 listopada 2017 r. poprzez wysłanie przez pracownika Centrum Systemów Informacyjnych Ochrony Zdrowia, dalej „CSIOZ”, do wszystkich okręgowych izb lekarskich oraz do wszystkich urzędów wojewódzkich danych osobowych lekarzy i lekarzy dentystów wygenerowanych z Systemu Monitorowania Kształcenia Pracowników Medycznych, zwanego dalej „SMK”.

W załączeniu przekazuję wydruki wysyłanej przez CSIOZ korespondencji i wskazuję, że rozesłana baza danych obejmowała następujące dane lekarzy i lekarzy dentystów: nr PESEL, imię i nazwisko, nr Prawa Wykonywania Zawodu, nr dokumentu Prawa Wykonywania Zawodu, nr rejestracyjny w izbie lekarskiej. Z treści załączonej wiadomości mailowej wynika, że dane lekarzy zostały przesłane celem weryfikacji ich poprawności. W tym zakresie należy wskazać, że okręgowa izba lekarska ma dostęp tylko do danych osobowych lekarzy i lekarzy dentystów będących jej członkami. Z powyższych względów przesłanie do takiej izby lekarskiej danych osobowych członków innej izby, celem weryfikacji poprawności tych danych, jest nie tylko bezprawne ale również nieracjonalne.
Zgodnie z treścią art. 4a ustawy z dnia 5 grudnia 1996 r. o zawodach lekarza i lekarza dentysty (Dz. U. z 2017 r. poz. 125 z późn. zm.), dane zamieszczane w SMK, na podstawie niniejszej ustawy, mogą zostać udostępnione okręgowym izbom lekarskim w zakresie zadań określonych niniejszą ustawą oraz ustawą z dnia 2 grudnia 2009 r. o izbach lekarskich (Dz. U. z 2016 r. poz. 522 z późn. zm.), a wojewodom w zakresie zadań określonych niniejszą ustawą, w szczególności w zakresie procesu szkolenia specjalizacyjnego lekarzy. Powyższe oznacza, że dane z SMK mogą być udostępniane jedynie w zakresie zadań realizowanych przez ww. podmioty.
W świetle powyższego udostępnienie danych osobowych lekarzy i lekarzy dentystów będących członkami jednej okręgowej izby lekarskiej innym izbom lekarskim nie znajduje oparcia w treści art. 4a ustawy. Podobnie nie znajduje podstawy prawnej udostępnienie danych osobowych lekarzy i lekarzy dentystów wszystkim wojewodom. Zgodnie bowiem z treścią art. 16 ust. 1 pkt 1 ustawy lekarz składa, za pomocą SMK, wniosek o odbywanie szkolenia specjalizacyjnego w wybranej dziedzinie medycyny odpowiednio do wojewody właściwego ze względu na obszar województwa, na terenie którego zamierza odbywać szkolenie specjalizacyjne. Nie ma podstaw prawnych aby dane lekarza lub lekarza dentysty zainteresowanego odbywaniem szkolenia specjalizacyjnego na obszarze konkretnego województwa trafiały do wszystkich wojewodów.
Powyższe ponad wszelką wątpliwość wskazuje, że doszło do naruszenia przepisu art. 26 ust. 1 pkt 1 ustawy o ochronie danych osobowych w zw. z art. 4a ustawy o zawodach lekarza i lekarza dentysty, polegającego na przetworzeniu danych osobowych niezgodnie z prawem poprzez udostępnienie danych osobowych podmiotom nieuprawnionym.
Wnoszę o podjęcie stosownych działań w zakresie posiadanych kompetencji, które zapewnią bezpieczeństwo przetwarzanych w SMK danych osobowych lekarzy i lekarzy dentystów. Jednocześnie proszę o informację o podjętych działaniach i poczynionych ustaleniach”.

Źródło: http://www.nil.org.pl/aktualnosci/promobox/bezpieczenstwo-danych-osobowych-lekarzy-i-lekarzy-dentystow-w-systemie-smk?utm_content=buffer1d64d&utm_medium=social&utm_source=facebook.com&utm_campaign=buffer

Rusza dofinansowanie opieki koordynowanej w projekcie POZ Plus – czy jest to szansa na rozwój IT w placówkach?

Podziel się

Pomijając zupełnie warunki finansowe podmiotów, które będą mogły ubiegać się o udział w pilotażu (małe placówki z małych miast, miasteczek lub wsi) pierwszą rzeczą, która rzuca się w oczy to wymagania techniczne jakie są przed nimi stawiane i punktowane przy wniosku o dofinansowanie. To szereg mało precyzyjnych wymagań dotyczących systemów informatycznych do przetwarzania dokumentacji medycznej oraz dotyczących bezpieczeństwa przetwarzania danych osobowych i medycznych, które można w obecnym kształcie dość mocno interpretować. Bez jasno określonych wytycznych można spodziewać się nieścisłości w procesie oceny wniosków – na ten moment punkty przyznawane podczas „audytu ex-ante”  będą mogły być przyznawane na podstawie „widzi mi się” członków komisji. Warto także zaznaczyć, że przynajmniej jeden z punktów jest niekoniecznie możliwy do spełnienia. Chodzi o to „Czy świadczeniodawca prowadzi elektroniczną dokumentację medyczną (EDM w rozumieniu przepisów ustawy o systemie w ochronie zdrowia, zgodnie z art. 11 ust. 1 tej ustawy)”. Istnieją bowiem poważne wątpliwości co do tego, czy którykolwiek z istniejących na rynku systemów spełnia to wymaganie biorąc pod uwagę brak centralnego Systemu Informacji Medycznej.

Kolejną sprawą jest to, że dużo i nośnie mówi się o opiece koordynowanej w kontekście projektu POZ Plus w tematach związanych z ułatwieniami komunikacji na styku lekarz-pacjent chociażby poprzez wykorzystanie nowoczesnych narzędzi telemedycznych czy telediagnostycznych. Można było wręcz odnieść wrażenie, że projekt to umożliwi i pozwoli właśnie tym mniejszym podmiotom korzystać z dobrodziejstw telekonsultacji czy telediagnostyki a pacjenci dostaną szansę na korzystanie z różnego rodzaju narzędzi edukujących i wspierających w związku z chorobami przewlekłymi z którymi się borykają. Rzeczywistość jednak wygląda inaczej. Tzw. „grant technologiczny” przyznawany w maksymalnej wersji w kwocie 50 000 zł w trzech na cztery obszary w których można go dostać dotyczy sprawozdawczości związanej z projektem POZ Plus. W czwartym punkcie można będzie otrzymać dofinansowanie na integrację „…z systemami: Zintegrowany Informator Pacjenta (ZIP) i System Informatyczny Monitorowania Profilaktyki (SIMP) w celu pobierania informacji o świadczeniach udzielonych pacjentom objętym opieką koordynowaną”. Tutaj problemy są dwa – po pierwsze nie wiadomo w jakim konkretnie zakresie a po drugie brak jest w tych systemach mechanizmów (tzw. API programistyczne), które umożliwiałyby jakąkolwiek integracje.

Biorąc pod uwagę powyższe oraz inne problemy o których mówi się po pojawieniu się dokumentacji należałoby się zastanowić czy obecny kształt projektu jest właściwym kierunkiem. Na szczęście to tylko pilotaż z którego będzie można wyciągnąć wnioski. I oby finał był szczęśliwy zarówno dla placówek jak i dla pacjentów bo chyba o to w ochronie zdrowia chodzi.