MENU

Oracle: Konieczne jest stosowanie wielowarstwowego modelu bezpieczeństwa
EVP

27 lipca 2016Artykuł z magazynu ITwiz, CSO, Executive ViewPoint, Polecane tematy

Executive ViewPoint
Z Michałem Wawrzyńskim, dyrektorem Działu Converged Infrastructure, Oracle Platform Business Group, oraz Pawłem Gregorczykiem, kierownikiem Działu Wsparcia Sprzedaży Infrastruktury, Oracle Polska, rozmawiamy o koniecznej zmianie podejścia do cyberbezpieczeństwa.

oracle_EVP_MW
Michał Wawrzyński, dyrektor Działu Converged Infrastructure, Oracle Platform Business Group:

Do tej pory mniej więcej 75% wydatków na bezpieczeństwo koncentrowało się na warstwie sieciowej, podczas gdy zdecydowana większość ataków tę warstwę omijała. W efekcie, bardzo przystający do dzisiejszych czasów stał się wielowarstwowy model bezpieczeństwa defense in depth. Zakłada on, że w centrum ochrony powinny znajdować się dane. Następnie zabezpieczamy aplikacje, z których korzystają konkretni użytkownicy. W kolejnej warstwie dbamy o bezpieczeństwo hostów wirtualnych i fizycznych, a w warstwie zewnętrznej możemy skupić się na bezpieczeństwie sieci.

Mówi się często, że dotychczasowe, dość powszechne, podejście do bezpieczeństwa środowisk IT jest dziś niewystarczające?

M.W.: Do ochrony infrastruktury IT ciągle podchodzi się na zasadzie ochrony zamku poprzez kopanie głębokiej fosy dookoła i zapewnienie wejścia do niego jedynie poprzez zwodzone mosty. Tymczasem – biorąc pod uwagę doniesienia o większości współczesnych ataków – najeźdźcy już dawno buszują po naszym skarbcu, wykorzystując konie trojańskie czy inne sposoby ominięcia zabezpieczeń zewnętrznych. Potwierdzają to analizy. Do tej pory mniej więcej 75% wydatków na bezpieczeństwo koncentrowało się na warstwie sieciowej, podczas gdy zdecydowana większość ataków tę warstwę omijała. W efekcie, bardzo przystający do dzisiejszych czasów stał się wielowarstwowy model bezpieczeństwa defense in depth. Zakłada on, że w centrum ochrony powinny znajdować się dane. Następnie zabezpieczamy aplikacje, z których korzystają konkretni użytkownicy. W kolejnej warstwie dbamy o bezpieczeństwo hostów wirtualnych i fizycznych, a w warstwie zewnętrznej możemy skupić się na bezpieczeństwie sieci. Tylko takie podejście da nam pewność, że nawet jeśli ktoś nieuprawniony uzyska dostęp do naszego centrum danych – nie będzie w stanie dostać się do naszego najcenniejszego skarbu – danych.

P.G.: Należy mieć świadomość, że wszystkim zagrożeniom nie da się dziś zapobiec. Zabezpieczenia działające w warstwie sieciowej lub na poziomie poszczególnych maszyn nie zawsze będą skuteczne. Jeżeli jednak zabezpieczymy dane tak, aby tylko uprawniona osoba mogła z nich skorzystać, to w efekcie każdy atak będzie nieudany. Takim zabezpieczeniem będzie na przykład zaszyfrowanie danych.

Na czym polega zintegrowana wizja bezpieczeństwa Oracle?

M.W.: Poziom bezpieczeństwa jest pochodną trzech aspektów: poufności, integralności danych oraz dostępności systemów. Tymczasem nasze podejście zakłada, aby w porozumieniu z odpowiednią architekturą systemów i na podstawie nowych rozwiązań sprzętowych wyeliminować konieczność poszukiwania kompromisów w zakresie poufności danych. Jeśli zaszyfrujemy wszystkie informacje, to możemy skupić się na dostępności oraz integralności danych. Jednocześnie, szyfrowanie bardzo często kojarzy się dziś z narzutem na wydajność. Zdejmując ograniczenie wydajnościowe – za sprawą dedykowanych koprocesorów wbudowanych w procesory SPARC M7 – możemy włączyć szyfrowanie dla wszystkich danych w bazie danych czy aplikacji w trakcie przesyłania i tych znajdujących się w spoczynku. Wówczas nasze dane będą zabezpieczone tak, że nawet jeśli przestępcom uda się przełamać inne zabezpieczenia, to z wykradzionych danych nie będą w stanie skorzystać. Warto podkreślić, że szyfrowanie przy użyciu funkcji nowych układów SPARC nie wymaga dodatkowych zasobów sprzętowych, a narzut wydajnościowy jest naprawdę pomijalny.

P.G.: Różnica pomiędzy światem SPARC a x86 jest taka, że w procesorze SPARC mamy koprocesory wykonujące całość działań związanych z szyfrowaniem. SPARC wspiera 16 różnych mechanizmów szyfrowania, a ich wykorzystanie nie wiąże się ze wzrostem obciążenia platformy. W technologii x86 mamy zaś jedynie instrukcje obsługujące szyfrowanie kosztem mocy głównych rdzeni obliczeniowych.

oracle_EVP_PG
Paweł Gregorczyk, kierownik Działu Wsparcia Sprzedaży Infrastruktury w Oracle Polska:

Ważny element procesorów SPARC M7 stanowią mechanizmy Silicon Secured Memory, czyli rozwiązania sprzętowe pozwalające na weryfikację dostępu do pamięci na poziomie poszczególnych procesów aplikacji. Jeśli spojrzymy na popularne języki programowania, jak C, to nie gwarantują one ochrony dostępu do pamięci. Powoduje to, że dwa różne procesy uruchomione przez jednego użytkownika mogą sobie wzajemnie zaglądać do pamięci. Na takim zjawisku, zwanym Buffer Overflow/Over-read, opierały się błędy takie jak Heartbleed czy Venom. Praktyka pokazuje, że ich tropienie może być wyjątkowo trudne. Są oczywiście narzędzia pozwalające wyśledzić takie błędy, jednak jest to możliwe na etapie tworzenia aplikacji. Tymczasem w układach SPARC M7 po stronie sprzętowej realizujemy procedury weryfikacji, co oznacza, że od razu – bez potrzeby wprowadzania żadnych zmian w aplikacjach – widać, które z naszych aplikacji są podatne na wycieki pamięci.

O jakich innych możliwościach najnowszej serii układów SPARC warto wspomnieć w kontekście bezpieczeństwa?

P.G.: Ważny obszar stanowią mechanizmy Silicon Secured Memory, czyli rozwiązania sprzętowe pozwalające na weryfikację dostępu do pamięci na poziomie poszczególnych procesów aplikacji. Jeśli spojrzymy na popularne języki programowania, jak C, to nie gwarantują one ochrony dostępu do pamięci. Powoduje to, że dwa różne procesy uruchomione przez jednego użytkownika mogą sobie wzajemnie zaglądać do pamięci. Na takim zjawisku, zwanym Buffer Overflow/Over-read, opierały się błędy takie jak Heartbleed czy Venom. Praktyka pokazuje, że ich tropienie może być wyjątkowo trudne. Są oczywiście narzędzia pozwalające wyśledzić takie błędy, jednak jest to możliwe na etapie tworzenia aplikacji. Tymczasem w układach SPARC M7 po stronie sprzętowej realizujemy procedury weryfikacji, co oznacza, że od razu – bez potrzeby wprowadzania żadnych zmian w aplikacjach – widać, które z naszych aplikacji są podatne na wycieki pamięci. Za sprawą takich mechanizmów łatwiejsze staje się też tworzenie bezpiecznych aplikacji, co oczywiście wykorzystujemy, rozwijając oprogramowanie Oracle. Przykładem jest baza danych Oracle Database 12c, w której na bieżąco weryfikowany jest dostęp do pamięci współdzielonej (SGA). Również nasza konkurencja wykorzystuje procesory SPARC do tego, aby uszczelnić własne rozwiązania.

Oracle do tej pory nie był zwykle kojarzony z obszarem bezpieczeństwa. Czy w strategii firmy coś się zmieniło?

M.W.: W naszym przypadku kluczowe znaczenie ma fakt, że Oracle, jako dostawca całego stosu technologii, może podchodzić do kwestii bezpieczeństwa w sposób najbardziej kompleksowy. Co ważne, nasze rozwiązania związane z bezpieczeństwem nie są zamknięte do świata Oracle. W środowiskach opartych na naszych technologiach poszczególne mechanizmy bezpieczeństwa będziemy w stanie wykorzystać najlepiej, ale nie ograniczamy możliwości ich stosowania w powiązaniu z produktami innych dostawców.

P.G.: Jest to też ważne, ponieważ jednym z najistotniejszych produktów Oracle są rozwiązania infrastrukturalne i bazodanowe skupione na danych oraz ich ochronie. Dysponując stosem rozwiązań Oracle, klienci zyskują dostęp do poprawek, które w każdej warstwie zostały ze sobą przetestowane. Takie podejście zwiększa niezawodność środowiska, a jednocześnie eliminuje problemy z kompatybilnością oraz możliwość powstawania nowych luk. Przykładowo, dla rozwiązań zintegrowanych „Engineered Systems” nowe paczki aktualizacji – dla całego stosu technologicznego – udostępniamy raz na kwartał. Uwzględniają one cały stos – od firmware sprzętu, po oprogramowanie.

P.G.: W kontekście bezpieczeństwa stosu technologicznego Oracle wiele powiedzieć można także o warstwie systemowej. Na podstawie rozwiązań uniksowych możemy, przykładowo, szyfrować maszyny wirtualne przenoszone pomiędzy serwerami. Cenna jest też możliwość tworzenia bezpiecznych szablonów wirtualizacyjnych, które pozwalają sprawdzić, czy obraz uruchamianej maszyny wirtualnej nie został podmieniony. Maszynę wirtualną możemy też skonfigurować w trybie tylko do odczytu, co oznacza, że jeśli ktoś złamie zabezpieczenia sieciowe i dostanie się do maszyny wirtualnej, to będzie w stanie jedynie poznać jej konfigurację.

W jaki sposób, przy użyciu technologii Oracle, warto dziś budować nowoczesne bezpieczeństwo IT?

M.W.: Należy skupić się na danych, a co za tym idzie – to, po pierwsze – warto ograniczyć obszar występowania baz danych. Zalecamy konsolidację baz danych, ponieważ przy odpowiednio ustalonych politykach bezpieczeństwa łatwiej będzie zarządzać środowiskiem bazodanowym i ograniczyć liczbę potencjalnych punktów ataku. Po drugie, szyfrujemy wszystkie dane, a że jesteśmy w stanie to zrobić bez utraty wydajności, nie musimy zastanawiać się, które dane są cenniejsze i które powinny być szyfrowane. Po trzecie, sięgamy po wszystkie dostępne mechanizmy ochrony infrastruktury. Podejście oparte na zabezpieczeniu całego stosu technologii potrafi zdziałać naprawdę cuda. W wielu przypadkach widzimy, że właściwie to nie technologia jest problemem w kontekście bezpieczeństwa, ale ludzie i procedury. Przykładowo, często okazuje się, że wiele teoretycznie ze sobą niepowiązanych instancji bazodanowych działa na tych samych danych dostępowych. Powoduje to, że w razie włamania do jednej bazy eskalowanie dostępu do kolejnych staje się bardzo łatwe. Trzeba mieć świadomość, ze żadne technologie nas nie zabezpieczą, jeśli nie popracujemy nad świadomością i stosowaniem najlepszych praktyk. Dlatego do naszych rozwiązań dostarczamy też zestawy dobrych praktyk, również w obszarze bezpieczeństwa. Oczywiście nie wszędzie uda się je wdrożyć w pełni, ale będą stanowić wskazówkę, w jaki sposób optymalnie podejść do zagadnień cyberbezpieczeństwa.

Podobne tematy:

Dodaj komentarz

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

« »