Jak chronić się przed utratą danych biznesowych

W poprzedniej części artykułu na temat bezpieczeństwa omawiałem rolę backupu i archiwizacji w zabezpieczaniu firmowych danych operacyjnych. Dzisiaj przedstawię kilka innych aspektów tego ważnego dla firm zagadnienia.

Zjawiskiem szczególnie nagłaśnianym w mediach jest ryzyko utraty danych związane z zagrożeniami zewnętrznymi. Sabotaż gospodarczy, hakerzy wyłudzający okup za wykradzione lub zablokowane dane czy wreszcie tzw. “haktywiści”. Zagrożenia z zewnątrz są bardzo poważne i firmy skupiają się właśnie na zabezpieczeniu tych obszarów wykorzystując zabezpieczenia sieciowe. Zwracam jednak uwagę, że w całym łańcuchu zwanym “bezpieczeństwo”, najsłabszym ogniwem są zazwyczaj ludzie. Technologia powinna w dużym stopniu skupiać się na ochronie przed błędami popełnianymi przez pracowników firmy. Może to być na przykład niezadowolony administrator, który skasuje lub sprzeda dane. Inny przykład to pracownik firmy, który podłączy zainfekowany pendrive do komputera w sieci firmowej. Może to być też pracownik call-center, który pod wpływem ataku socjotechnicznego ujawni dane osobowe klienta. I wreszcie pracownik firmy w delegacji, któremu ktoś najzwyczajniej “przez ramię” będzie podglądał ekran laptopa. 

Sporo mówi się też o bezpieczeństwie danych przechowywanych w chmurze. Tak naprawdę zabezpieczanie usług w chmurze i danych we własnej serwerowni to tematy zbieżne. Najważniejsza rzecz tutaj, to zaufanie między klientem a usługodawcą. Przewagę mają niewątpliwie duzi dostawcy usług, gdyż potrafią oni dynamiczniej reagować na potencjalne zagrożenia. Jeśli pojawia się jakaś dziura w oprogramowaniu - tacy dostawcy wiedzą o tym najwcześniej, i są w stanie łatać środowiska w najszybszy sposób. Przeniesienie przetwarzania do chmury nie zwalnia nas od obowiązku dbania o bezpieczeństwo (szczególnie w modelu IaaS) gdzie tak naprawdę to użytkownicy zarządzają podobnym środowiskiem, tylko znajdującym się w innym Data Center. 

Ważne jest, aby dostawca usług chmurowych miał odpowiednio zbudowane centra danych, zabezpieczenie geograficzne to też bardzo ważna kwestia. Kolejna rzecz to dostępność oprogramowania związanego z bezpieczeństwem w swoim katalogu usług. Oracle budując swoje usługi chmurowe przykłada ogromną wagę do architektury HA/DR i buduje swoje centra w modelu “Availability Domains”, gdzie w geograficznej lokalizacji jest kilka centrów świadczących te same usługi. Usługi w katalogu Platform as a Service (PaaS) umożliwiają z kolei wykorzystanie oprogramowania do uwierzytelniania, kontroli dostępu, monitoringu i audytowania. Możliwe jest także przechowywanie kluczy umożliwiających deszyfrowanie danych po stronie klienta. 

Aby maksymalnie zwiększyć poziom bezpieczeństwa danych w centrach obliczeniowych, można zastosować najnowsze rozwiązanie Oracle, sprzęt wykorzystujący mechanizmy “Security in Silicon”. Procesory M7 i S7 mają funkcjonalność akceleracji szyfrowania a także mechanizmy weryfikujące dostęp do pamięci w trybie online. Wykorzystanie “Security in Silicon” pozwala zwiększyć bezpieczeństwo budowanych środowisk bez konieczności zakupu dodatkowych szyfratorów, a także bez narzutu na wydajność środowisk wykorzystujących szyfrowanie. 
 
Autorem artykuł jest Paweł Gregorczyk, kierownik Działu Wsparcia Sprzedaży Infrastruktury w Oracle Polska

Udostępnij na LinkedIn

Dowiedz się więcej
Oracle Cloud
Oracle SPARC
Software in Silicon
Bezpieczeństwo w chmurze

Oracle Systems przedstawia: nowy procesor i serwery SPARC S7

Paweł Zawadzki, Principal Sales Consultant, Oracle Polska

Pod koniec czerwca br. światło dzienne ujrzały produkty serwerowe oparte o nowy procesor Oracle SPARC S7. Jest on kuzynem zaprezentowanego w 2015 roku procesora SPARC M7. 

Inżynierowie odchudzili poprzednią architekturę i dzięki temu obniżone zostały znacząco ceny serwerów, w których wykorzystany jest nowy procesor. Serwery z rodziny S7 dołączają do równolegle oferowanych modeli T7 i M7, ale są tak spozycjonowane cenowo, aby skutecznie konkurować z generycznymi rozwiązaniami klasy X86. Najmniejsze konfiguracje nowych serwerów S7 dostępne są już poniżej $10 000 - cena uwzględnia system operacyjny Solaris OS, wirtualizator Oracle VM jak również oprogramowanie monitorujące i zarządzające Enterprise Manager OPS Center & Cloud Control.

Dzięki takiemu zabiegowi zyskujemy bardzo atrakcyjną platformę obliczeniową – niezwykle wydajne serwery RISC (testy wydajności rdzenia M7/S7 przeprowadził Kamil Stawiarski z ORA-600, ich wyniki są dostępne w osobnym artykule tutaj) w cenie generycznych rozwiązań X86.
Idealnym zastosowaniem dla nowych serwerów S7 będą małe i średnie instancje baz danych Oracle w wersji Enterprise oraz środowiska aplikacyjne Weblogic – decydując się na zakup takiego serwera użytkownik odniesie korzyści dwojakiego rodzaju: 
•  Optymalizacja użycia posiadanych licencji technologicznych Oracle (DB i Weblogic) -dwupoziomowa wirtualizacja pozwoli dopasować zalicencjonowane środowisko dokładnie do wymaganej wydajności przy optymalizacji ilości wymaganych licencji;
•  Technologia „Software in Silicon” znacząco przyspieszy wydajność baz danych, w szczególności trybu In-Memory, jednocześnie podnosząc poziom bezpieczeństwa danych przedsiębiorstwa. 

Inne możliwości zastosowań serwerów SPARC S7: 
•  Idealny serwer lub klaster serwerów RAC dla Oracle DB Standard Edition oraz Standard Edition Two, wraz z wydajnym wewnętrznym podsystemem Storage (możliwość konfiguracji węzłów jedno lub dwu-procesorowych);
•  Konsolidacja środowisk RISC poprzedniej generacji klasy entry-level i mid-range (znaczna gęstość konsolidacji dzięki wysokiej wydajności pojedynczego wątku i dwu-poziomowej wirtualizacji);
•  Ekonomiczna platforma dla bazy danych w trybie In-Memory (sprzętowa akceleracja Software In Silicon);
•  Wydajny backup serwer lub media server (wysoko wydajna szyna danych oparta na magistrali PCI-Express gen3);
•  Węzły obliczeniowe dla skalowalnej horyzontalnie chmury prywatnej RISC;
•  Aplikacje typu BATCH wymagające wysokiej wydajności pojedynczego wątku obliczeniowego (wysoka wydajność rdzenia S7 taktowanego 4,27Ghz).

Technologia SPARC S7 trafia również do chmury publicznej. Równolegle do premiery serwerów S7, Oracle poszerza swoją ofertę chmurową o usługi IaaS oparte o SPARC M7 i S7, umożliwiając użytkowanie tej samej technologii jednocześnie - zarówno we własnych serwerowniach, jak i w chmurze. Krok ten jest dowodem na wysokie zaangażowanie Oracle w rozwój technologii SPARC i Solaris. 

C.D.N. (w części drugiej artykułu opowiemy więcej o cechach technicznych SPARC S7)

Dowiedz się więcej
Informacje o produktach SPARC
„Mapa drogowa” produktów Oracle SPARC

Oracle SPARC M7 - test porównawczy

Kamil Stawiarski, Oracle Certified Master, szef firmy ORA-600

Jak zapowiadaliśmy w części pierwszej artykułu, dzisiaj publikujemy wyniki testu porównawczego czasu odpowiedzi dla procesorów SPARC M7, Intel® Xeon® X5670 (2.93 GHz), Intel® Xeon® E5-2699 v3 (2.3 GHz) oraz IBM Power 8.

W trakcie testu, porównaliśmy ze sobą procesory SPARC M7, Intel® Xeon® X5670 Processors (2.93 GHz), Intel® Xeon® E5-2699 v3 Processors (2.3 GHz) oraz IBM Power 8. Metodyka testu zakładała użycie tego samego schematu na wszystkich środowiskach, wygenerowanego za pomocą narzędzia SSB (https://github.com/electrum) (SCALEFACTOR=100). 

Na każdym badanym środowisku, został użyty INSTANCE CAGING w celu zasymulowania pracy przy zaledwie 6 licencjach bazodanowych oraz In-Memory. Wszystkie tabele zostały załadowane do pamięci z opcją MEMCOMPRESS FOR QUERY HIGH z włączoną równoległością na wartość 8. 

Symulacja zakładała uruchamianie poniższego zapytania za pomocą JMeter dla liczby użytkowników od 10 do 100 z kwantem 10. 
select count(distinct(lo_custkey)) 
from( select lo_custkey 
from lineorder,date_dim

where lo_orderdate = d_datekey
and d_weeknuminyear = :1
and d_year = :2

and lo_orderpriority <> :3
and lo_ordtotalprice between 7000 and 150000 
group by lo_orderkey, lo_custkey
having count(lo_linenumber) =1); 

Poniższe wyniki pokazują średnie czasu odpowiedzi dla poszczególnych procesorów:

Dla procesora IBM P8 wyniki wyglądały na początku bardzo niepokojąco: 

Jednak po ustawieniu parametru: 
export LDR_CNTRL=DATAPSIZE=64K@TEXTPSIZE=64K@STACKPSIZE=64K oracle (notka metalink numer 2066837.1) sytuacja dla 100 użytkowników zdecydowanie się ustabilizowała. 

Na powyższych przykładach widzimy, że nowy SPARC M7 bije na głowę badanych konkurentów przy testach In-Memory. Ja jednak z niecierpliwością czekam na rozwój interfejsu DAX, który pozwoli na użycie „software in silicon” dla np. standardowych funkcji analitycznych SQL lub może nawet PL/SQL – bez konieczności zakupu dodatkowej opcji dla bazy Enterprise.

Oracle SPARC M7 – śledzenie koprocesorów DAX

Kamil Stawiarski, Oracle Certified Master, szef firmy ORA-600

W epoce chmur pojawiają się czasem sprzętowe perełki, które zachwycają administratorów i programistów, przedkładających twarde fakty nad eteryczne byty. 
Jednym z takich rozwiązań jest nowy procesor SPARC M7 dostarczony przez dział Engineered Systems firmy Oracle. Pierwszy rzut oka na testową maszynę wystarczył żeby poczuć szacunek –jak często można pracować na maszynie posiadającej 256 corów i pół terabajta RAM? Nie to jest jednak największą mocą procesora SPARC M7 – są nią koprocesory DAX. 
Żeby jednak dokładnie wyjaśnić ich rolę, przyjrzyjmy się najpierw nowej funkcjonalności bazy 12.1.0.2 – In-Memory. 

Oracle Database In-Memory

Coraz częściej trudno jest jednoznacznie określić charakterystykę danego systemu – w wielu przypadkach mamy bowiem do czynienia z systemami mieszanymi – niby jest to system transakcyjny ale na bieżąco musimy wykonywać bardzo dużo analitycznych zapytań. Sprawa wydawałaby się łatwo rozwiązywalna w związku z faktem istnienia coraz tańszych kości pamięci RAM i coraz większych możliwości obsługi takiej pamięci w nowych serwerach. 

Problem jest jednak bardziej złożony – duża pamięć współdzielona oznacza konieczność istnienia mechanizmów chroniących takie obszary – np. latche i mutexy. W efekcie ciągłe podnoszenie wielkości pamięci SGA (a w ramach niej bufora BUFFER CACHE), prowadzi często do sytuacji wyglądającej teoretycznie absurdalnie – zapytania wykonywane z wielu sesji jednocześnie, odpowiadają szybciej, kiedy czytają z dysku niż kiedy walczą o blokady na poziomie dużych obszarów pamięci współdzielonej! 
Firma Oracle zaadresowała ten problem w funkcjonalności In-Memory, dostępnej wraz z bazą 12.1.0.2 EE (oczywiście za dodatkową opłatą). 

Opcja In-Memory pozwala trzymać w pamięci kolumnową reprezentację tabel w postaci skompresowanej, co zdecydowanie przyspiesza wszelkie zapytania analityczne, wykonujące się równolegle. 

Koprocesory DAX

Na procesorach Intel, Oracle wykorzystuje rejestry SIMD w celu akceleracji wykonania zapytań analitycznych In-Memory – nowy SPARC M7 dostarczył jednak czegoś znacznie ciekawszego – specjalnych koprocesorów DAX (data analytics accelerator), które stanowią implementację idei „software in silicon”. 

Koprocesory DAX wykonują sprzętowo operacje bezpośredniego dostępu do pamięci, dekompresji danych algorytmem OZIP i umieszczają wyniki bezpośrednio w warstwie cache L3 procesora. 
Każdy procesor M7 ma 8 koprocesorów DAX a każdy koprocesor posiada 4 tzw. „query pipelines”, które są właściwymi narzędziami akceleracji zapytań In-Memory. 

Offloading zapytań In-Memory dotyczy następujących funkcjonalności:
•  Złączenia typu HASH JOIN
•  Predykaty klauzuli WHERE 
•  Dekompresja i kompresja algorytmem OZIP używanym przez klauzulę: MEMCOMPRESS FOR QUERY HIGH 

Jednym z pierwszych pytań, które sobie zadałem w trakcie testów brzmiało: „Skąd mam wiedzieć, kiedy DAX jest uruchamiany?” 
Na szczęście system operacyjny Solaris jest wyposażony w niezwykle przydatne narzędzie – DTrace. Narzędzie to może zostać wykorzystane do dynamicznego śledzenia przebiegu skompilowanych programów, pozwalając nam na odkrycie ich niskopoziomowych sekretów. 

Zachęcam do przeczytania krótkiego tutoriala na temat podstaw używania narzędzia DTrace.

W części drugiej artykułu zamieścimy testy porównawcze czasu odpowiedzi dla procesorów SPARC M7, Intel® Xeon® X5670 (2.93 GHz), Intel® Xeon® E5-2699 v3 (2.3 GHz) oraz IBM Power 8.