Bezpieczny projekt, bezpieczna chmura. Gerard Frankowski, Paweł Berus, Łukasz Olejnik Poznańskie Centrum Superkomputerowo-Sieciowe

Transkrypt

1 Bezpieczny projekt, bezpieczna chmura Gerard Frankowski, Paweł Berus, Łukasz Olejnik Poznańskie Centrum Superkomputerowo-Sieciowe

2 Agenda Znaczenie bezpieczeństwa rozwiązań IT Budowa bezpiecznych systemów informatycznych Co nam przeszkadza? Jak wbudować bezpieczeństwo w projekt IT? Bezpieczeństwo w chmurowym modelu obliczeniowym Specyficzne zagrożenia Wsparcie w zakresie bezpieczeństwa dla programistów MS Azure Anonimizacja danych Pytania, dyskusja

3 Znaczenie bezpieczeństwa IT Powszechność usług to powszechne zagrożenia Stwierdzenie prawdziwe zwłaszcza dla usług zorientowanych na masowego użytkownika Użytkownik taki nie musi być ekspertem bezpieczeństwa, czy w ogóle specjalistą IT Co możemy stracić? Zasoby: moc procesora, botnety, spamowanie, DDoS Dane: osobowe, finansowe, niejawne, wyniki badań Zaufanie (kluczowe na rynku produktów/usług) Narażeni są nawet najwięksi dostawcy Kwiecień 2011: atak na użytkowników Sony PSN

4 Od kogo zależy bezpieczeństwo produktu (projektu)? Bezpieczeństwo = problem kompleksowy (wielowarstwowy) Kto może popełnić błąd? Projektanci Programiści Wdrożeniowcy Użytkownicy Prawdziwa dogłębna ochrona (security security-in-depth) ma miejsce, jeśli bezpieczeństwo zaadresują w odpowiedni sposób wszystkie te grupy

5 Czy bezpieczeństwo się opłaca? Podwyższanie poziomu bezpieczeństwa kosztuje (i to sporo) Formalne metody dowodzenia poprawności Koszt produkcji oprogramowania krytycznego a zwykłego Bezpieczeństwa często nie widać! Jak użytkownik ma odróżnić np. bezpieczną chmurę od niepewnej? Po fakcie (udanym ataku) może być już za późno na decyzję

6 Czy nasze rozwiązania muszą być perfekcyjne? Czynniki ekonomiczne kierują nie tylko wytwórcą oprogramowania, ale także napastnikiem Jeżeli koszt ataku jest wyższy od wartości chronionych aktywów, atak jest nieopłacalny Produkty muszą być wystarczająco bezpieczne Bezpieczeństwo nie może kosztować więcej niż aktywa Bezpieczeństwo nie może powodować problemów z użytkowaniem produktu

7 Koszt naprawy błędu bezpieczeństwa Źródło: Applied Software Measurement, Capers Jones, 1996 BuildingSecurity Into The Software Life Cycle, Marco M. Morana, 2006

8 Jak zapewnić odpowiedni poziom bezpieczeństwa? Myśleć o nim od początku! Źródło: IT Infrastructure Threat Modeling Guide, Solution Accelerators Security and Compliance

9 O jakich przykładowych problemach możemy mówić w przypadku chmur? Ogólne zagrożenia usług IT Specyficzne zagrożenia związane z chmurowym modelem przetwarzania danych W kontekście obaw potencjalnych użytkowników rozważamy głównie zagrożenia dla danych Utrudnienia związane z korzystaniem z usługi Także bariery prawne Problemy tworzenia bezpiecznych usług w chmurze

10 Przykłady problemów prawnych Prawu trudno nadążyć za rozwojem technologii Przykładowe regulacje ogólne: UoODO, KK, KC Przykładowe regulacje szczególne: Prawo Bankowe Dopiero w 2012 r. ma zostać przyjęta strategia UE dotycząca przetwarzania danych w chmurze Mogą zależeć od rodzaju chmury (I/P/SaaS) Gdzie działa administrator (sprawca)? Gdzie przetwarzane są dane? Przykładowy problem: eksport danych poza EOG co do zasady wymaga zgody GIODO

11 Ryzyka przetwarzania danych w chmurze Wg raportu CSA Top Threats to Cloud Computing (2010) Zagrożenie IaaS PaaS SaaS Nadużycie (złośliwe użycie) usługi!! Niebezpieczne interfejsy/api!!! Ataki od wewnątrz (u dostawcy)!!! Problemy współdzielenia technologii! Utrata lub wyciek danych!!! Kradzież konta!!! Nieznany profil ryzyka!!!

12 Chmura publiczna czy prywatna? Chmura publiczna klasyczne cloud computing Chmura prywatna najlepsza z punktu widzenia bezpieczeństwa, ale podejście to ma innego rodzaju wady: Konieczność posiadania, przygotowania oraz utrzymania infrastruktury Nadal istnieje możliwość przeinwestowania Gorsza skalowalność Chmura hybrydowa Możliwość połączenia zalet chmur publicznych i prywatnych, np. wrażliwe dane przechowujemy w części prywatnej

13 Obawa o prywatność danych Zasady Privacy by Design Proaktywne, a nie reaktywne działania Domyślne ustawienia zapewniające prywatność Prywatność wbudowana od etapu projektowania i obecna na wszystkich etapach SDLC Prywatność i,, a nie albo bezpieczeństwo Transparentność Poszanowanie prywatności użytkowników Microsoft Privacy Principles

14 Grafika:

15 Bezpieczeństwo MS Azure dla programisty Azure nie wprowadza dodatkowych rozwiązań bezpieczeństwa, ale pozwala programistom korzystać z już dostępnych usług Zarządzanie tożsamością i kontrolą dostępu Możliwość integracji z Security Token Service Współpraca z narzędziami oraz systemami służącymi zarządzaniu tożsamością Windows Identity Foundation Windows Azure AppFabric Access Control Service Active Directory Federation Services

16 Szerokie wykorzystanie kryptografii Wszędzie certyfikaty! Połączenia z punktami końcowymi (portami) aplikacji (HTTP over SSL) Możliwy dostęp do zdalnego pulpitu dla instancji aplikacji Szyfrowane połączenia z STS-ami Nie jest wymagane! Można ominąć walidację certyfikatu dla testowego STS Dla systemów produkcyjnych zaleca się zarówno walidację certyfikatu, jak i szyfrowanie połączenia

17 Administracja instancjami ułatwienia i problemy Instancje = maszyny wirtualne Domyślna konfiguracja powinna spełniać większość oczekiwań Jeśli nie możemy mieć (przez zdalny pulpit) dostęp do maszyny wirtualnej z aplikacją! Można niemal dowolnie konfigurować maszynę (instalacja usług, ról, zmiany rejestru), a nawet ją wyłączyć Problemy: Można źle (niebezpiecznie) skonfigurować maszynę Można pominąć jakąś maszynę, jeśli jest ich dużo

18 Inne wybrane aspekty bezpieczeństwa Dostępność Gdy padnie instancja aplikacji, Azure sam zareaguje (przy kilku instancjach nie będzie widoczna przerwa w działaniu) W przypadku zbyt dużego obciążenia usługi można napisać własnego load balancera,, który dołoży instancji Opcja Swap VIP Możliwość szybkiego przełączania się między instancją testową a produkcyjną

19 A co z ogólnymi zagrożeniami? Azure oferuje wbudowane mechanizmy zapobiegające lub utrudniające m.in. skanowanie portów czy ataki D(D)oS Zastosowanie maszyn wirtualnych drastycznie utrudnia ataki na fizyczną maszynę Ale rozwijamy aplikacje pod Microsoft Visual Studio nie zastąpi ono programisty w myśleniu o bezpieczeństwie Jeżeli napiszemy niebezpieczny kod, prosimy się o problemy (np. XSS, CSRF) Częściową pomocą mogą być rozwiązania takie, jak Microsoft Anti-Cross-Site-ScriptingScripting Library

20 Problem zabezpieczania danych w chmurze Dane zostają wysłane do chmury Wtedy w praktyce nie są one już tylko nasze dostęp do nich może mieć potencjalnie operator chmury Ryzyko wycieków danych jest realne W związku z tym, warto dokładnie przeanalizować: Jakie dane mogą trafić do chmury? Jakie powinny zostać tajemnicą, gdyż są ważne? (A jakich danych potrzebuje chmura, aby wykonać obliczenia?) Tradycyjny przetarg użyteczność/bezpieczeństwo

21 Anonimizacja danych jako metoda ich ochrony Jeżeli zachodzi konieczność przesłania wrażliwych danych do chmury z uwagi na konieczność ich przetworzenia, można zastosować anonimizację Na początku warto wyodrębnić dane opisowe (np. w przypadku chorób: miażdżyca ) i kolumn w tabelach potencjalnie je opisujących (np. data urodzenia, płeć, itp.) Dąży się do tego, żeby żaden z zapisów nie wskazywał na konkretną osobę/przedmiot w sposób jednoznaczny

22 Jak w praktyce zaciemniać dane opisowe? Ogólnym problemem jest zapewnienie odwracalności zaciemnienia Przykładowe proste techniki Zamiana danych losowymi wartościami z jakiegoś wybranego zakresu (wcześniej ustalonego) Mieszanie zamiana danych (obejmujących kolumnę) wierszami, tak żeby każda zmieniła swoje położenie. Daty (np. urodzenia) można zamieniać, dodając losowy interwał np. +/- N dni. (problem: dane rzadkie ) Szyfrowanie (problem: widać, że to chronione aktywa) Usunięcie (problem: odpowiednie mapowanie, potencjalne błędy/niemożność przetwarzania danych)

23 Anonimizacja dalsze rozważania Jak dobrać dane do anonimizacji? Czy to jest wrażliwe? A tamto? Często nie wiemy, jaka informacja może być użyteczna dla napastnika Możliwość wnioskowania przede wszystkim na podstawie unikalnych danych Np. sprzedajemy 1000 produktów, a jeden z nich kosztuje 10x więcej od innych Projektanci aplikacji muszą udostępnić użytkownikowi możliwości jej konfiguracji tak, aby mogli decydować o klasyfikacji poszczególnych danych

24 Podsumowanie Przetwarzanie chmurowe to możliwości i zagrożenia. Zarówno dostawcy usług chmurowych, jak i prawnicy, naukowcy, czynią wiele dla bezpieczeństwa chmur na różnych płaszczyznach od projektu do wdrożenia Microsoft Azure nie wprowadza dodatkowej warstwy bezpieczeństwa, ale korzysta ze sprawdzonych rozwiązań skojarzonych z używanymi technologiami Dlatego programiści, administratorzy i użytkownicy MS Azure nadal muszą uważać! W przypadku przetwarzania wrażliwych danych możemy z uwagą zastosować technikę anonimizacji danych.

25 Więcej informacji ENISA: ryzyka przetwarzania danych w chmurze computing-risk-assessment/at_download/fullreport Modelling Cloud Computing Architecture Without Compromising Privacy: A Privacy by Design Approach Microsoft Security Development Life Cycle Centrum bezpieczeństwa MS Azure Bardziej formalnie o anonimizacji danych

26 Dane kontaktowe Autorzy prezentacji Zespół Bezpieczeństwa PCSS Zainteresowanych zapraszamy do dyskusji!

27 Pytania

28 Dziękuję za uwagę! Zapraszam na prezentację scenariusza Grafika: