Zarządzanie ryzykiem na biegunie i w chmurze obliczeniowej

Śmiałkowie Norweski badacz polarny, Odkrywca i pionier Roal Amundsen Robert Falcon Scott Norweski badacz polarny, Odkrywca i pionier Pierwszy zdobywca bieguna południowego. Oficer brytyjskiej marynarki wojennej Badacz Antarktydy Odkrywca i podróżnik

Cel Zdobyć biegun południowy Wrócić cało do domu

Planowanie Doświadczenie Relacje z innych wypraw Roal Amundsen Robert Falcon Scott Doświadczenie Relacje z innych wypraw Zbudowanie baz i magazynów żywności Dbałość o drobiazgi (jedzenie, odzież, bielizna, narzędzia. ekwipunek) Dobór ludzi Biegły w sztuce przetrwania Doświadczenie Był już na biegunie południowym (1902 r.) Zbudowanie baz i magazynów żywności Bogate wsparcie zasobów (3 tony sprzętu) Poleganie na szczęściu i opatrzności

Przygotowanie 5 osób 95 psów zaprzęgowych Narty biegowe 10 par specjalnie przygotowanych sań 6 namiotów Lapońskie anoraki z foczego futra i futra z renów 3 magazyny żywności 65 osób (17 członków wyprawy) 19 kucyków mandżurskich 6 sań motorowych Psy zaprzęgowe Brezentowe kombinezony 3 magazyny żywności i paliwa

Przebieg Start z tego samego sektora Antarktydy (podobna odległość do bieguna) Amundsen wybrał miejsce lądowania w miejscu obfitującym w pożywienie Scott wyruszył 11 dni przed Amudsenem znaną sobie trasą Amundsen wytyczał nowy szlak Te same warunki pogodowe przez pierwsze 34 dni Scott poruszał się z prędkością około 10 km dziennie Amundsen pokonywał 15-20 km dziennie, a w drodze powrotnej 50-70 km dzięki lżejszym saniom (rekord 100 km) Pierwszą istotną cechą przetwarzania w chmurze według NIST jest Szeroki dostęp (Broad Network Access), który oznacza, że zasoby informatyczne są dostępne przez powszechnie istniejące mechanizmy takie jak Standardowi klienci jak telefony komórkowe, laptopy, komputery stacjonarne, zarówno wewnętrzne jak i zewnętrzne wobec sieci firmowej Tradycyjne usługi jak aplikacje i middleware. Nie powinno być żadnych ograniczeń w warunkach dostępu poprzez usługi oparte o model chmury

Wynik 14.12.1911 – zdobycie bieguna południowego 30.12.1911 – przekroczenie równoleżnika (w drodze powrotnej) 22.01.1912 – Powrót do bazy Framheim (punkt startu) Stan osobowy w komplecie 30.12.1911 – przekroczenie równoleżnika (w drodze na biegun) 04.01.1912 – do bieguna zmierza już tylko 5 uczestników wyprawy (reszta zostaje odesłana) 18.01.1912 - zdobycie bieguna południowego ~29.03.1912 – prawdopodobna data śmierci Roberta Falcona Scotta Stan osobowy: 5 ofiar śmiertelnych

Śmiałkowie Pan Pani Społeczeństwo

Cel Redukcja kosztów Brak wydatków kapitałowych (chmura publiczna) Bardziej zwinny Nieograniczona skalowalność Lepsze wykorzystanie zasobów Płatność za faktyczne wykorzystanie Możliwość korzystania z nowych usług Współpraca i współdzielenie wiedzy Koncentracja na biznesie Możliwość powrotu (uniknięcie vendor lock-in)

Planowanie Identyfikacja aktywów Dane Aplikacje Funkcje Procesy Ocena aktywów Poufność Integralność Dostępność Mapowanie aktywów Normy Standardy Regulacje Ocena modeli chmury Rozmieszczenie usługi (Publiczna, prywatna, hybrydowa, wspólna) Rodzaj usługi (SPI) Przepływ danych Organizacja Klienci Dostawcy

Model chmury wg NIST Publikacja NIST (National Institiute of Standards and Technology) jest ogólnie akceptowana i z tego powodu CSA wybrało jego definicje przetwarzania w chmurze w celu uspójnienia i ujednolicenia pojęć. Intencją twórców poradnika było to, aby był on szeroko dostępny i do zastosowania w organizacjach na całym świecie. NIST definiuje przetwarzanie w chmurze poprzez określenie 5 istotnych cech, 3 modeli usług i 4 modeli rozmieszczenia usług. Przedstawiony diagram ilustruje tą definicję. Szerzej będzie omówiony w dalszej części modułu

Chmura rozdziela aplikacje i zasoby informacyjne oraz mechanizmy odpowiedzialne za ich dostarczenie od podstawowej infrastruktury Chmura określa korzystanie z usług, aplikacji, informacji i infrastruktury za pomocą puli zasobów obliczeniowych, sieciowych, informacyjnych i pamięciowych. Pule zasobów mogą być szybko zaaranżowane, dostarczone, zaimplementowane, odinstalowane oraz skalowane Chmura dostarcza użyteczności na żądanie np. według alokacji i konsumpcji. Jednym z największym wyzwań w zakresie bezpieczeństwa chmury jest zrozumienie czym jest przetwarzanie w chmurze. 4 główne aspekty chmury powinny nieco przybliżyć sprawę. Aplikacje i zasoby obliczeniowe (bazy danych, CPU, sieć itp.) są oddzielone w modelu chmury. Tak więc idea zarządzania serwerami, pojemnością baz danych, połączeniami sieciowymi nie jest w tym modelu problemem użytkownika (w modelu SaaS) Kolejną cechą przetwarzania w chmurze jest elastyczność (flexibility). Odkąd zasoby informatyczne są zorganizowane w tzw. pule, użytkownik może płacić za to co wykorzystuje. Pule zasobów mogą być w mgnieniu oka dostarczone i odinstalowane co oznacza, że w modelu chmury nie ma ograniczeń związanych z natychmiastową zmianą infrastruktury Zasoby mogą być z łatwością zarówno zwiększane jak i pomniejszane umożliwiąjąc użytkownikowi skalowanie jego środowiska na podstawie faktycznego zużycia zasobów.

Cechy charakterystyczne chmury Szeroki dostęp (Broad Access Network) Błyskawiczna elastyczność (Rapid elasticity) Mierzalne usługi (Measured services) Samoobsługa na żądanie (On demand self-service) Agregacja zasobów (Resource pooling Pierwszą istotną cechą przetwarzania w chmurze według NIST jest Szeroki dostęp (Broad Network Access), który oznacza, że zasoby informatyczne są dostępne przez powszechnie istniejące mechanizmy takie jak Standardowi klienci jak telefony komórkowe, laptopy, komputery stacjonarne, zarówno wewnętrzne jak i zewnętrzne wobec sieci firmowej Tradycyjne usługi jak aplikacje i middleware. Nie powinno być żadnych ograniczeń w warunkach dostępu poprzez usługi oparte o model chmury

Modele usług w chmurze Software as a Service (SaaS) Platform as a Service (PaaS) Infrastructure as a Service (IaaS) W zakresie tego co kupujesz kiedy korzystasz z modelu chmury, typy usług są zazwyczaj podzielone na trzy różne poziomy. Typy usług są określane terminem stos SPI. S- Software as a Service, P- Platform as a Service, I - Infrastructure as a Service. Obecnie stos chmury ewoluuje i można zauważyć pokrywanie się i coraz mniejsze zróżnicowanie pomiędzy warstwami stosu. Zacznijmy, więc od standardowej definicji dla każdej warstwy, następnie użyjemy kilku przykładów pokazujących zamazywanie się tych różnic

Infrastructure as a Service (IaaS) Dostarczanie podstawowych zasobów obliczeniowych, sieciowych, przechowywania danych i innych Klient instaluje i uruchamia dowolne oprogramowanie Może zawierać systemy operacyjne i aplikacje Model IaaS jest podobny do uruchomienia własnego centrum danych, ale bez konieczności martwienia się o detale. Dostawca oferuje nam niezbędną infrastrukturę oraz sprzęt, dzięki którym klient może zainstalować własne systemy lub korzystać z zasobów obliczeniowych poprzez zbiory abstrakcji lub API. Klient nie zarządza ani nie kontroluje najniższej warstwy infrastruktury chmury (sprzęt, urządzenia) ale kontroluje systemy operacyjne, składowanie danych (storage), zainstalowane aplikacje i w ograniczonym stopniu wybrane komponenty sieciowe (np. host firewalls)

Platform as a Service (PaaS) Umożliwia klientom instalację własnych aplikacji i systemów w infrastrukturze dostawcy Stworzona za pomocą języków programowania i narzędzi wspieranych przez dostawcę PaaS is the next level up, further abstracting the hardware by providing access via middleware or other integrations offered by the provider. PaaS jest kolejnym poziomem znajdującym się ponad poziomem IaaS umożliwiając dostęp do sprzętu poprzez oprogramowanie pośredniczące (middleware) lub inne narzędzia umożliwiające integrację Klient nie zarządza ani kontroluje podstawowej infrastruktury włączając również zasoby sieciowe, serwery, systemy operacyjne i składowanie danych (storage). Klient kontroluje zainstalowane aplikacje oraz ewentualnie może zarządzać konfiguracją własnych hostów.

Software as a Service (SaaS) Klient korzysta z aplikacji dostawcy umieszczonych w chmurze Klient nie zarządza ani kontroluje podstawowej infrastruktury włączając również zasoby sieciowe, serwery, systemy operacyjne i składowanie danych, ani nawet poszczególnych właściwości aplikacji Aplikacje są dostępne za pomocą różnych urządzeń poprzez interfejs „cienkiego klienta” jak przeglądarka internetowa Klient nie zarządza ani kontroluje podstawowej infrastruktury włączając również zasoby sieciowe, serwery, systemy operacyjne i składowanie danych. Może też mieć ograniczoną możliwość zmiany ustawień oraz kastomizacji aplikacji, z których korzysta. Przykłady znaczących aplikacji w modelu SaaS: Salesforce.com Gmail Quickbooks Online MailChimp (lista milingowa) Marketo (marketing) Workday (HR i księgowośc)

Wpływ bezpieczeństwa na stos SPI Im niżej stosu dostawca dostarcza usługę tym klient jest bardziej odpowiedzialny za zarządzanie ryzykiem i zabezpieczenie środowiska SaaS PaaS IaaS Wszystko zawiera się w jednym zdaniu. Im niżej stosu dostawca świadczy usługi w chmurze, tym klient jest bardziej odpowiedzialny za zarządzanie i zabezpieczenie środowiska. W modelu Iaas, dostawca dostarcza niezbędną infrastrukturę i sprzęt, więc klient jest odpowiedzialny za zabezpieczenie systemów i aplikacji . PaaS jest pośrodku stosu i może oferować pewien poziom bezpieczeństwa. Klient jest odpowiedzialny za zabezpieczenie aplikacji, która jest osadzona na platformie W przypadku modelu SaaS, dostawca jest odpowiedzialny za całokształt rozwiązania (od kołyski aż po grób) stąd jest również odpowiedzialny za zapewnienie bezpieczeństwa na wszystkich warstwach stosu. Odpowiedzialność za zarządzanie ryzykiem Dostawca Klient

IaaS Korzyści Możliwość kastomizacji i kontroli nad środowiskiem Elastyczność w zabezpieczaniu danych do swoich potrzeb Wątpliwości Zaangażowanie w integrację wszystkich aspektów aplikacji (DB, plug-ins, API itd.) Odpowiedzialność za całość konfiguracji (również aplikacji) Odpowiedzialność za aktualizację oprogramowania Współdzielenie na poziomie hypervisora Now let’s return to the case study, where Research Corp is looking to move their content delivery platform to the cloud. Is IaaS the right choice for them? Benefits: First off is the matter of control. Research Corp would have the ability to use whatever content delivery platform they want. They can customize it to their heart’s content. It’s not much different than what they are currently doing, relative to selecting the solution and having to manage most of the operations. Next is the flexibility to provide whatever security capabilities they deem (uważają) necessary to protect their intellectual property. IaaS allows Research Corp to secure the operating systems to whatever degree they want (even to the point of supporting a hardened O/S image), as well as any other host based protections they choose. There may also be some network protections available from the provider, but that will depend on the specific service provider. Are there other benefits to selecting IaaS? (DISCUSS) Issues: Research Corp gains no leverage in terms of application operation or integration. They have to assemble (składać) everything (or buy a traditional software solution that includes these components). They are also flying solo relative to hardening and configuring all of these devices. Since many attacks are a direct result of configuration errors and other administrative mistakes, this increases the risk profile. Most software will require periodic patches to address defects or other security vulnerabilities, and this remains the responsibility of the customer. They have to manage patches and downtime and ensure the patches don’t introduce other issues. Although there are not (m)any weaponized exploits targeting hypervisor technology, the underlying hardware abstraction layer remains a point of vulnerability for all cloud services. By supporting multiple clients on the same infrastructure, losing control of the hypervisor results in all tenants being exposed. What other issues will Research Corp experience by moving their application to an IaaS provider? (DISCUSS)

PaaS Korzyści Zintegrowane rozwiązanie pomaga zredukować złożoność zarządzania (konfiguracja, komponenty) Jeśli dostawca wspiera API, ułatwia implementację Wątpliwości Klient wciąż odpowiedzialny za utrzymanie aktualizacji stosu Możliwość uzależnienia od dostawcy API (lock-in) Współdzielenie na poziomie platformy Now let’s return to the case study, where Research Corp is looking to move their content delivery platform to the cloud. Is IaaS the right choice for them? Benefits: First off is the matter of control. Research Corp would have the ability to use whatever content delivery platform they want. They can customize it to their heart’s content. It’s not much different than what they are currently doing, relative to selecting the solution and having to manage most of the operations. Next is the flexibility to provide whatever security capabilities they deem necessary to protect their intellectual property. IaaS allows Research Corp to secure the operating systems to whatever degree they want (even to the point of supporting a hardened O/S image), as well as any other host based protections they choose. There may also be some network protections available from the provider, but that will depend on the specific service provider. Are there other benefits to selecting IaaS? (DISCUSS) Issues: Research Corp gains no leverage in terms of application operation or integration. They have to assemble everything (or buy a traditional software solution that includes these components). They are also flying solo relative to hardening and configuring all of these devices. Since many attacks are a direct result of configuration errors and other administrative mistakes, this increases the risk profile. Most software will require periodic patches to address defects or other security vulnerabilities, and this remains the responsibility of the customer. They have to manage patches and downtime and ensure the patches don’t introduce other issues. Although there are not (m)any weaponized exploits targeting hypervisor technology, the underlying hardware abstraction layer remains a point of vulnerability for all cloud services. By supporting multiple clients on the same infrastructure, losing control of the hypervisor results in all tenants being exposed. What other issues will Research Corp experience by moving their application to an IaaS provider? (DISCUSS)

SaaS Korzyści Zintegrowane rozwiązanie pomaga zredukować złożoność zarządzania (konfiguracja, komponenty) Skalowanie środowiska nie jest problemem klienta Aktualizacja, konfiguracja, bezpieczeństwo – odpowiedzialność dostawcy Wątpliwości Bardzo mała możliwość kastomizacji Brak kontroli na komponentami. Brak kontroli nad bezpieczeństwem (tylko ocena, brak wpływu) . Współdzielenie na poziomie aplikacji. Now let’s return to the case study, where Research Corp is looking to move their content delivery platform to the cloud. Is IaaS the right choice for them? Benefits: First off is the matter of control. Research Corp would have the ability to use whatever content delivery platform they want. They can customize it to their heart’s content. It’s not much different than what they are currently doing, relative to selecting the solution and having to manage most of the operations. Next is the flexibility to provide whatever security capabilities they deem necessary to protect their intellectual property. IaaS allows Research Corp to secure the operating systems to whatever degree they want (even to the point of supporting a hardened O/S image), as well as any other host based protections they choose. There may also be some network protections available from the provider, but that will depend on the specific service provider. Are there other benefits to selecting IaaS? (DISCUSS) Issues: Research Corp gains no leverage in terms of application operation or integration. They have to assemble everything (or buy a traditional software solution that includes these components). They are also flying solo relative to hardening and configuring all of these devices. Since many attacks are a direct result of configuration errors and other administrative mistakes, this increases the risk profile. Most software will require periodic patches to address defects or other security vulnerabilities, and this remains the responsibility of the customer. They have to manage patches and downtime and ensure the patches don’t introduce other issues. Although there are not (m)any weaponized exploits targeting hypervisor technology, the underlying hardware abstraction layer remains a point of vulnerability for all cloud services. By supporting multiple clients on the same infrastructure, losing control of the hypervisor results in all tenants being exposed. What other issues will Research Corp experience by moving their application to an IaaS provider? (DISCUSS)

Modele chmury ze względu na rozmieszczenie Chmura publiczna (Public) Chmura prywatna (Private) Współdzielona (Community) Hybrydowa (Hybrid) Chmura publiczna – Infrastruktura jest dostępna publicznie lub dla sektora branżowego i jest zarządzana i w posiadaniu dostawca (third party provider), który za jej pomocą oferuje usługi. Jest umieszona na zewnątrz (off-premises) organizacji. Ten model jest najczęściej określany mianem „chmury” przez organizacje. Zasadniczo jest to zbiór zasobów sprzętowych udostępnianych "w locie” (mogą być natychmiastowo skalowane w górę lub w dół) wspierających prawie każdy rodzaj aplikacji, zaś dostęp do nich odbywa się za pomocą Internetu. Chmura prywatna – Infrastruktura jest wykorzystywana jedynie przez pojedynczą organizację. Może być zarządzana przez organizację lub przez dostawcę (third party provider), może być ulokowana wewnątrz (on-premises) lub na zewnątrz (off-premises) organizacji. Każda infrastruktura, w której odpowiedzialność za zarządzanie leży po stronie organizacji może być nazwana chmurą prywatną. Oznacza to ,że każde istniejące centrum danych, posiadające cechy charakterystyczne dla infrastruktury chmury (szeroki dostęp przez internet, błyskawiczna elastyczność, mierzalne usługi itd.) jest rodzajem chmury prywatnej. Chmura współdzielona- Infrastruktura wspiera i jest dzielona pomiędzy kilka organizacji, które może łączyć wspólny cel, wspólnota interesów, wspólna misja, wymagania bezpieczeństwa i zgodności itp. (np. grupa kapitałowa, organizacje rządowe, sektor branżowy). Wykorzystanie potencjału chmury i efektu skali pomaga na obniżenie kosztów i zwiększenie możliwości usług IT. Chmura współdzielona może być zarządzana przez organizację dostawcę i być umieszczona wewnątrz lub na zewnątrz organizacji Chmura hybrydowa – Infrastruktura jest kompozycją dwóch lub więcej chmur (publicznych, prywatnych lub współdzielonych, które pozostają odrębnymi jednostkami, ale są ze soba połączone przy wykorzystaniu standardowej lub własnej technologii, która umożliwia przenaszalność (portability) danych i aplikacji np. rozerwanie chmury (cloud bursting) na potrzeby równoważenia obciążenia (load-balancing) pomiędzy chmurami lub na potrzeby redundancji środowisk. Może być w posiadaniu i zarządzana jednocześnie zarówno przez organizację jak i dostawcy i jednocześnie być rozmieszczona zarówno wewnątrz jak i na zewnątrz organizacji

Modele wdrożenia i odpowiedzialności Infrastruktura zarządzana1 przez: Infrastruktura2 w posiadaniu: Infrastruktura umieszczona3 : Dostępna i wykorzystywana przez4 Publiczna Dostawca (Third Party Provider) Na zewnątrz (Off-Premise) Niezaufana strona Prywatna/ Współdzielona Organizacja Wewnątrz (On-Premise) Zaufana strona Hybrydowa Zarówno Organizacja jak i Dostawca Zarówno Wewnątrz jak i Na zewnątrz Zarówno Zaufana i Niezaufana strona Lub Powyższy diagram podsumowuje wiele kluczowych aspektów modelu rozmieszczenia chmury (publiczna, prywatna, współdzielona, hybrydowa). Poniżej objaśnienia do pojęć użytych w poszczególnych kolumnach tabeli: Zarządzanie obejmuje: nadzór, operacje, bezpieczeństwo, zgodność (compliance) itp. Pojęcie infrastruktury obejmuje fizyczną infrastrukturę jak urządzenia oraz zasoby sieciowe i obliczeniowe oraz składowania danych. 3. Rozmieszczenie infrastruktury nie powinno być rozpatrywana jedynie w kontekście ‘wewnętrzny’ czy ‘zewnętrzny’ w odniesieniu do fizycznej lokalizacji zasobów, informacji czy aktywów. W przypadku modelu chmury rozmieszczenie oznacza zarówno fizyczną lokalizację jak i obejmuje kwestie przez kogo jest wykorzystywana i kto jest odpowiedzialny za zarządzanie nimi (nadzór, bezpieczeństwo itd.) Nie oznacza to, ze lokalizacja wewnątrz lub na zewnątrz organizacji nie wpływa na bezpieczeństwo i ryzyko, ale powinny one być rozpatrywane pod względem: • Typów zarządzanych aktywów , zasobów i informacji • Kto nimi zarządza i kiedy • Jakie kontrole są wybrane i jak są zintegrowane • kwestie zgodności (compliance) Przykładowo LAMP (Linux, Apache, MySQL, Pearl) umieszczony na infrastrukturze Amazona AWS EC2 zostanie sklasyfikowany jako chmura publiczna w modelu IaaS, na zewnątrz organizacji, zarządzana przez dostawcę; nawet jeśli poszczególne instancje i aplikacje oraz dane zawarte w środowisku są zarządzane przez organizację. Całe środowisko, które współdzielimy z innymi użytkownikami jest pod kontrolą dostawcy. Kastomizowalna aplikacja służąca wielu jednostkom biznesowym, umieszczona w chmurze Eucalyptusa, która będzie pod kontrolą i w posiadaniu organizacji będzie określona jako chmura prywatna w modelu SaaS, wewnątrz organizacji, zarządzana przez organizację. 4. Zaufana strona to ta, która jest rozpatrywana jako część organizacji (pod względem prawnym, biznesowym, wspólnej polityki i misji itp.) obejmująca pracowników (stałych i kontraktowych) oraz partnerów biznesowych. Niezaufana strona to ta, która może być autoryzowana do korzystania z części lub całości usług, ale nie jest logiczną częścią organizacji

Jericho Cloud Cube Model Internal (I)/External (E) – fizyczna lokalizacja danych Proprietary (P)/Open (O) – kto dostarcza usługi Perimeterised (Per)/Deperimeterised (D-p) – logiczne granice sieci 4 wymiary, 8 stanów Per - (IP,IO,EP,EO), D-p (IP,IO,EP,EO) Insourced (Per, IP)– usługa jest dostarczana w ramach organizacji i kontrolowana Outsourced (D-p, EO) – usługa jest dostarczana i kontrolowana przez zewnętrznego dostawcę Pictures usually say a thousand words, so let’s take a look at another view of cloud responsibilities. The Jericho Forum’s Cloud Cube Model illustrates the many permutations available in cloud offerings today and presents four criteria/dimensions in order to differentiate cloud ‘formations’ from one another and the manner of their provision, in order to understand how cloud computing affects the way in which security might be approached. By assessing your options relative to a few attributes, you can figure out (zrozumieć, odnaleźć) to what degree the cloud can make sense for your environment. But keep in mind none of these things are exactly clear cut, so it’s really just a start. Internal vs. External – Who is responsible for the infrastructure? Proprietary vs. Open – Is the infrastructure and/or computing stack open or locked to a certain provider? Perimeterized vs. De-perimeterized – Are all components of the application within a logical network perimeter?

Gdzie teraz jest granica? Cloud Security Chmura burzy tradycyjne podejście do określania granic Co jest wewnętrzne? Co jest zewnętrzne? Now that we have a decent (skromną, uczciwą), w tym kontekście podstawową idea of what cloud computing is, let’s think a little about cloud security. Of course, we’ll be spending most of the rest of the course digging deeply into these topics, but ultimately embracing cloud computing requires a change of mentality. You’ll need to have flexible definitions of what is “internal” to your networks and what is “external.” This also means the idea of the traditional network perimeter goes out the window. So you’ve got to look at protecting not just the infrastructure anymore, but also the applications and even the data itself. When trying to get your arms around these concepts, it helps to start with answering a few questions to understand who will be consuming the resources, and who is responsible for protecting it. Let’s answer those questions for Research Corp to get a feel for how we need to think about protecting the content delivery platform. Gdzie teraz jest granica?

Przygotowanie Architektura cloud computing Terminologia, cechy, modele, lokalizacja Nadzór i zarządzanie ryzykiem Zarządzanie ryzykiem, zapisy w umowach, odpowiedzialność za zarządzanie ryzykiem Prawo i informatyka śledcza Aspekty prawne, gromadzenie, analiza i udostępnianie dowodów Zgodność i audyt Prawo do audytu, analiza i wpływ na zgodność z regulacjami Zarządzanie informacją i ochrona danych Bezpieczeństwo, lokalizacja, odzyskiwanie danych Przenaszalność i interoperacyjność Zmiana dostawcy usług, możliwość powrotu, współpraca pomiędzy BCP i DRP Zarządzanie ciągłością i plany awaryjne Centrum danych i zarządzanie operacjami Architektura i infrastruktura centrum danych, polityki i procedury Zarządzanie incydentami Wykrywanie, powiadamianie i reagowanie na incydenty, rejestracja i analiza Bezpieczeństwo aplikacji Bezpieczeństwo aplikacji, zarządzanie podatnościami , SDLC Szyfrowanie i zarządzanie kluczami Szyfrowanie danych , zarządzanie kluczami, mechanizmy kryptograficzne Zarządzanie własnością, tożsamością i dostępem Zarządzanie tożsamością i uprawnieniami, nadawanie i odbieranie dostępu, odpowiedzialność Wirtualizacja Multi-tenancy, izolacja VM, bezpieczeństwo hypervisorów, zarządzanie podatnościami, złośliwe oprogramowanie Security as a service Korzyści i obawy, transparentność rozwiązań, wymagania

Przebieg i wynik ??? Pierwszą istotną cechą przetwarzania w chmurze według NIST jest Szeroki dostęp (Broad Network Access), który oznacza, że zasoby informatyczne są dostępne przez powszechnie istniejące mechanizmy takie jak Standardowi klienci jak telefony komórkowe, laptopy, komputery stacjonarne, zarówno wewnętrzne jak i zewnętrzne wobec sieci firmowej Tradycyjne usługi jak aplikacje i middleware. Nie powinno być żadnych ograniczeń w warunkach dostępu poprzez usługi oparte o model chmury

Cloud Security Alliance Polska Stowarzyszenie, polski oddział CSA Organizacja non-profit Promowanie najlepszych praktyk i edukacja w zakresie bezpieczeństwa cloud computing Koalicja praktyków, ekspertów, korporacji, stowarzyszeń z obszaru bezpieczeństwa w chmurze Platforma komunikacji pomiędzy stronami zaangażowanymi i zainteresowanymi bezpieczeństwem chmury Wymiany wiedzy oraz doświadczeń. Około 50.000 członków Ponad 60 oddziałów Now that we have a decent idea of what cloud computing is, let’s think a little about cloud security. Of course, we’ll be spending most of the rest of the course digging deeply into these topics, but ultimately embracing cloud computing requires a change of mentality. You’ll need to have flexible definitions of what is “internal” to your networks and what is “external.” This also means the idea of the traditional network perimeter goes out the window. So you’ve got to look at protecting not just the infrastructure anymore, but also the applications and even the data itself. When trying to get your arms around these concepts, it helps to start with answering a few questions to understand who will be consuming the resources, and who is responsible for protecting it.

Cloud Security Alliance Polska Celem przewodnika CSA jest ustanowienie i dostarczenie zbioru najlepszych  praktyk dla menadżerów i użytkowników, którzy chcą korzystać z usług w przetwarzania w chmurze w bezpieczny sposób . Trzecia edycja przewodnika składa się z  14 domen Now that we have a decent idea of what cloud computing is, let’s think a little about cloud security. Of course, we’ll be spending most of the rest of the course digging deeply into these topics, but ultimately embracing cloud computing requires a change of mentality. You’ll need to have flexible definitions of what is “internal” to your networks and what is “external.” This also means the idea of the traditional network perimeter goes out the window. So you’ve got to look at protecting not just the infrastructure anymore, but also the applications and even the data itself. When trying to get your arms around these concepts, it helps to start with answering a few questions to understand who will be consuming the resources, and who is responsible for protecting it.

Cloud Security Alliance Polska Certyfikat Cloud Security Knowledge (CCSK) jest pierwszym branżowym programem certyfikacyjnym  stworzonym dla profesjonalistów odpowiedzialnych za zabezpieczenie chmury. Otrzymanie certyfikatu  CCSK potwierdza znajomość  najlepszych praktyk w zakresie  zarządzania ryzykiem w modelu cloud computing. Now that we have a decent idea of what cloud computing is, let’s think a little about cloud security. Of course, we’ll be spending most of the rest of the course digging deeply into these topics, but ultimately embracing cloud computing requires a change of mentality. You’ll need to have flexible definitions of what is “internal” to your networks and what is “external.” This also means the idea of the traditional network perimeter goes out the window. So you’ve got to look at protecting not just the infrastructure anymore, but also the applications and even the data itself. When trying to get your arms around these concepts, it helps to start with answering a few questions to understand who will be consuming the resources, and who is responsible for protecting it.

Cloud Security Alliance Polska Cloud Control Matrix (CCM) został zaprojektowany w celu dostarczenia dostawcom w chmurze fundamentalnych zasad z zakresu bezpieczeńtwa i wspomagania odbiorców usług w chmurze w ocenie i analizie ryzyka związanego z modelem cloud computing Now that we have a decent idea of what cloud computing is, let’s think a little about cloud security. Of course, we’ll be spending most of the rest of the course digging deeply into these topics, but ultimately embracing cloud computing requires a change of mentality. You’ll need to have flexible definitions of what is “internal” to your networks and what is “external.” This also means the idea of the traditional network perimeter goes out the window. So you’ve got to look at protecting not just the infrastructure anymore, but also the applications and even the data itself. When trying to get your arms around these concepts, it helps to start with answering a few questions to understand who will be consuming the resources, and who is responsible for protecting it.

Cloud Security Alliance Polska Cloud Security Alliance (CSA) uruchomił nową inicjatywę zachęcającą do transparentności rozwiązań i praktyk z zakresu bezpieczeństwa stosowanych przez dostawcę usług w chmurze. CSA Security, Trust & Assurance Registry (STAR) jest darmowym, publicznie dostępnym rejestrem dokumentującym mechanizmy kontrolne stosowane w różne rozwiązaniach opartych na modelu cloud computing. Dzięki temu potencjalni odbiorcy usług mogą ocenić w jaki sposób dostawcy zarządzają ryzykiem i bezpieczeństwem w oferowanych przez siebie usługach. CSA STAR jest częścią CSA Open Certification Framework – branżowej inicjatywy aby przyznawać dostawcom usług w chmurze  globalne, akredytowane, zaufane certyfikaty Now that we have a decent idea of what cloud computing is, let’s think a little about cloud security. Of course, we’ll be spending most of the rest of the course digging deeply into these topics, but ultimately embracing cloud computing requires a change of mentality. You’ll need to have flexible definitions of what is “internal” to your networks and what is “external.” This also means the idea of the traditional network perimeter goes out the window. So you’ve got to look at protecting not just the infrastructure anymore, but also the applications and even the data itself. When trying to get your arms around these concepts, it helps to start with answering a few questions to understand who will be consuming the resources, and who is responsible for protecting it.

Cloud Security Alliance Polska Dziękuję za uwagę www.csa.org.pl Linkedin – Grupa Cloud Security Alliance Polska Marcin Fronczak CCSK, CIA, CISA, CRISC biuro@csa.org.pl Now that we have a decent idea of what cloud computing is, let’s think a little about cloud security. Of course, we’ll be spending most of the rest of the course digging deeply into these topics, but ultimately embracing cloud computing requires a change of mentality. You’ll need to have flexible definitions of what is “internal” to your networks and what is “external.” This also means the idea of the traditional network perimeter goes out the window. So you’ve got to look at protecting not just the infrastructure anymore, but also the applications and even the data itself. When trying to get your arms around these concepts, it helps to start with answering a few questions to understand who will be consuming the resources, and who is responsible for protecting it.

Bibliografia Zdobycie bieguna południowego – Roald Amundsen Security Guidance for Critical Areas of Focus in Cloud Computing v3.0 – Cloud Security Alliance Cloud Computing – Benefits, risk and recommendations for information security – ENISA Cloud Cube Model – www.jerichoforum.org