PODSTAWOWE ZASADY KRYPTOGRAFII W e-BIZNESIE

Ochrona dostępu i wyjścia z prywatnych systemów komputerowych na rozległy obszar to tylko jeden aspekt bezpieczeństwa systemu. Dane muszą być również jak najbardziej odporne na korupcję. Zwykłym sposobem na to jest stworzenie procesu bezpieczeństwa, który opiera się na algorytmach szyfrowania. Ponownie zwracamy uwagę, ponieważ nie można tego robić zbyt często, że musimy dokonać rozróżnienia między implementacjami a algorytmami. Algorytm szyfrowania to wyrażenie matematyczne opisujące, na przykład, w jaki sposób ma zostać zaszyfrowana część danych (i odszyfrowana, jeśli metoda jest inna). Wdrożenie dotyczy tego, jak ma się to odbywać w rzeczywistości. Może to odbywać się za pomocą oprogramowania, sprzętu lub ręcznie i obejmuje rozważenie sieci lub innego systemu używanego do przesyłania tajnych kluczy i sposobu organizacji umów między użytkownikami. Należy zauważyć, że bezpieczeństwo zależy zarówno od algorytmu, jak i implementacji. Na rysunku przedstawiamy podstawowe elementy procesu szyfrowania i leżące u jego podstaw algorytmy, które są wspólne dla większości aplikacji, niezależnie od tego, czy służą one do utrzymywania tajemnic, przesyłania pieniędzy, udowadniania, że ​​jesteś tym, za kogo się podajesz, itp.

System jest napędzany przez algorytm, który w pewien sposób chroni transakcję poprzez zastosowanie pewnej uprzywilejowanej wiedzy, posiadanej przez jedną lub obie strony transakcji. Ta wiedza może być tajnym hasłem lub może po prostu oznaczać, że obie strony znają się nawzajem z widzenia i dlatego mogą prowadzić swoją działalność za pośrednictwem łącza wideo. Zawsze istnieją pewne elementy sprzętowe i/lub programowe sprzętu zabezpieczającego, które przechowują i obsługują algorytmy zapewniające bezpieczeństwo – w przytoczonym przykładzie kamery wideo, monitory i łącza transmisyjne. Częściej pojawią się maszyny kryptograficzne, które będą kodować wiadomości, aby zapobiec podsłuchiwaniu lub manipulacji. W tym przypadku są one konwencjonalnie nazywane kryptowalutami. Ostatnim elementem systemu jest bezpieczny kanał. Obejmuje to pewien zestaw procesów i technologii, które umożliwiają pełną i niezawodną wymianę informacji uprzywilejowanych między obiema stronami. Prostym przykładem może być wymiana kluczy używanych do konfiguracji algorytmów szyfrowania i deszyfrowania w celu bezpiecznej transmisji wiadomości. Może to być nawet wymiana zdjęć legalnych uczestników w naszym przykładzie konferencji. Nawiasem mówiąc, czasami twierdzi się, że systemy bezpieczeństwa, takie jak szyfrowanie kluczem publicznym, sprawiają, że nie jest już konieczne zapewnienie bezpiecznego kanału. O tym, czy jest to dokładnie poprawne, omówimy później.

OCHRONA WIRTUALNYCH SIECI PRYWATNYCH Z WYKORZYSTANIEM TUNELI ZAPORA OGNIOWYCH

W przypadku operacji typu business-to-business sytuacja może być czasami inna: obie strony mogą sobie ufać i chcieć robić interesy przez Internet, zachowując jednak między sobą bezpieczny kanał. W takim przypadku zapory można skonfigurować tak, aby zapewniały wirtualną sieć prywatną przy użyciu techniki znanej jako tunelowanie. Tunel zapewnia bezpieczny kanał między wewnętrznie prywatnymi sieciami każdej firmy

Wykorzystuje to jeden z ograniczonej liczby bezpiecznych protokołów tunelowania, takich jak protokół IPSec, który umożliwia hermetyzację pakietu IP w bezpiecznej otoczce. Zostanie to omówione później, po rozważeniu niektórych technik szyfrowania, które są używane w jego implementacji.

BEZPIECZEŃSTWO PRZEZ SERWER PROXY („HOST BASTION”)

Zamiast zezwalać zewnętrznym, potencjalnie złośliwym komputerom klienckim na bezpośrednią komunikację z serwerami i klientami w sieci firmowej, czasami lepiej jest skierować je do innego serwera proxy lub hosta bastionu. Host bastionu (rysunek 2.9) to po prostu standardowy komputer, niekoniecznie szczególnie wydajny (na przykład 486-DX66 z zaledwie 16 MB pamięci), który działa jako bariera między światem zewnętrznym a bezpieczną siecią wewnętrzną

Posiada dwie karty sieciowe i dwa adresy IP. Serwer otrzymuje żądania ze świata zewnętrznego, ale musi następnie poprosić klienta o zweryfikowanie przekazania żądania do bezpiecznej aplikacji. Żadne pakiety IP nie przechodzą bezpośrednio. Prawidłowo skonfigurowany zapewnia wysoki stopień bezpieczeństwa. Można go również skonfigurować do przechowywania rejestru przechodzących wiadomości, ustanawiając w ten sposób pełną ścieżkę audytu do monitorowania bezpieczeństwa online lub offline. Bastiony są szczególnie dobre do implementacji bram aplikacji, ponieważ możliwe jest przeprowadzanie złożonych kontroli zawartości wiadomości, które przez nie przechodzą, na przykład w celu uniknięcia wirusów e-mail. Jedno podejście, SOCKS, opracowane przez Internet Engineering Task Force (IETF), zapewnia standardowy sposób zezwalania bezpiecznym aplikacjom na działanie przez zaporę. Każda taka aplikacja wymaga poddania się procesowi skarpetkowania. Pierwotnie oznaczało to, że aplikacja musiała zostać ponownie skompilowana i połączona z zestawem funkcji bibliotecznych SOCKS. Było to skomplikowane i czasochłonne. Ostatnio, biblioteki dołączane dynamicznie, które działają w czasie wykonywania, usunęły ten problem, przynajmniej w przypadku aplikacji Windows. Wciąż jednak toczy się debata na temat tego, czy SOCKS są konieczne i/lub pożądane w dłuższej perspektywie.

FILTRY PAKIETOWE

Możemy mieć dowolną liczbę i tak złożonych sieci wewnętrznych, jak tylko chcemy, ale wszystkie łączą się ze światem zewnętrznym za pomocą jednej pary filtrów, jednego do sprawdzania pakietów wychodzących i jednego do sprawdzania pakietów przychodzących. Filtry są konwencjonalnymi routerami wzbogaconymi o możliwość sprawdzenia adresów każdego pojedynczego pakietu. Administrator systemu (który musi być kimś, komu można ufać – problem sam w sobie) tworzy tabelę dla każdego filtra, z którą ma się sprawdzać, aby zobaczyć, czy przekazanie pakietu jest w porządku. Jeśli pojawią się zabronione adresy, są one odrzucane, a administracja powiadamiana. Za pomocą bramy usługowej można również przeprowadzić filtrowanie, nie tylko na poziomie pakietów, ale także według określonej zawartości i celów przesyłanych danych .

Na przykład można ustawić bezpłatny tranzyt poczty e-mail między siecią firmową a światem zewnętrznym, ale zablokować każdą inną usługę. Jedną z najczęstszych filtracji selektywnych jest przepuszczanie pakietów zawierających żądanie HTTP (tj. do pobrania strony internetowej), ale nie pakietów FTP (które żądają dostępu do plików). Jednak, jak widzieliśmy wcześniej, samo wprowadzenie filtra pakietów niekoniecznie jest wystarczające do zapewnienia bezpieczeństwa. W każdym razie istnieją pewne problemy operacyjne z zaporami filtrującymi pakiety: po pierwsze, ponieważ po prostu używa się routera, który jest skonfigurowany do odrzucania pakietów, które nie są zgodne z jego akceptowalną listą, często nie ma możliwości zbierania dzienników na tym, co dotarło do routera. Oznacza to, że może być trudno uświadomić sobie, że ktoś został zaatakowany; podobnie, nie jest łatwo wykryć odrzucenie ludzi, którym wolałbyś przepuścić. Trudne jest również skonfigurowanie uprawnień dla specjalnych użytkowników, aby umożliwić przesyłanie ich wiadomości e-mail lub dla techników terenowych z bezpiecznie zidentyfikowanymi terminalami, aby mogli zdalnie wchodzić do systemu plików.

ZAPORY

Planując obronę przed atakiem, najlepszą rzeczą do zrobienia jest poleganie na wypróbowanej i przetestowanej zasadzie bezpieczeństwa polegającej na zmniejszeniu liczby punktów dostępu, a następnie rygorystycznym patrolowaniu tych punktów. To jest zasada „firewalla”. Każde wejście do wewnętrznej sieci korporacyjnej z domeny publicznej (w praktyce najczęściej połączenie z Internetem) odbywa się przez firewall, który sprawdza ruch w celu określenia, czy i na jakich warunkach należy go zezwolić. Zasadniczo istnieją dwa różne typy firewalli: te, które działają jako filtry pakietów i te, które są serwerami proxy lub hostami bastionowymi, jak są również nazywane. Mogą być używane osobno lub razem. Mogą pobierać dane na podstawowym poziomie pakietów lub działać jako filtry aplikacji, odmawiając przekazywania danych przeznaczonych dla konkretnych aplikacji lub usług.

TECHNOLOGIE WSPIERAJĄCE POLITYKI BEZPIECZEŃSTWA

W celu zrozumienia zagadnień bezpieczeństwa w eBiznesie wprowadziliśmy standardowy, trzypoziomowy model polityki, procesu i technologii. Uznaliśmy, że najlepiej zacząć od kilku przykładów tego, jak może to zostać naruszone w sytuacjach, w których brakuje środków bezpieczeństwa lub nie ma ich wcale. Aby zobaczyć, jak takie środki mogą poprawić sytuację, musimy teraz przyjrzeć się podstawowym technologiom, a następnie zobaczyć, w jaki sposób można je wbudować w standardowe procesy do pracy na dużym obszarze.

ATAKI BAZY DANYCH

Potencjalne współdzielenie krytycznych danych między różnymi częściami przedsiębiorstwa, zwykle w ekstranecie przedsiębiorstwa, jest postrzegane jako jeden z głównych postępów w zachowaniu biznesowym. Oczywiście ma to zalety, ale jest też ryzyko. Oprócz wariantów wspomnianych powyżej ataków, które umożliwiają atakującym dostęp lub sabotowanie plików, do których nie mają uzasadnionych praw, istnieją operacje zbierania danych wywiadowczych, które mogą być przeprowadzane „legalnie” przez każdego, kto ma nawet ograniczony dostęp do bazy danych. Jednym z takich działań jest wnioskowanie z zapytań statystycznych. Rozważ tabelę .

Reprezentuje (poufną) wartość kontraktów wygranych przez Twoją firmę na zaopatrzenie wielu różnych rodzajów firm w różnych częściach Stanów Zjednoczonych. Aby chronić szczegółową wiedzę zawartą w tabeli, ale aby umożliwić (rozsądnie) zaufanym innym osobom dostęp do niektórych danych, ograniczasz ich do wykonywania tylko określonego zestawu zapytań statystycznych. Mogą na przykład wysłać zapytanie SQL, które zwraca średnią wartość zamówienia dla bazy danych. Mogą również poprosić o łączną liczbę firm w dowolnej lokalizacji, dla której masz dane typu produktu.

To, czego nie chcesz, aby zadawali, to pytania dotyczące tego, ile pieniędzy zabrałeś z pojedynczej firmy. Załóżmy, że pozwalasz im poprosić o średnią wartość dostarczonych zamówień do firm programistycznych w Seattle? (= 3 miliony dolarów). Załóżmy teraz, że pozwolisz im również zapytać o całkowitą liczbę firm w Seattle, które dostarczają oprogramowanie? (= 1). Ups! Chociaż nie pozwoliliśmy na bezpośredni dostęp do zapytań typu „ile pieniędzy pobraliśmy od Tiny”, widzimy, że para zapytań zebranych razem, z powodzeniem znalazła dokładnie taką liczbę. Generalnie okazuje się, że zatrzymanie zestawu uśrednionych statystycznie zapytań dających konkretną odpowiedź jest praktycznie niemożliwe. Jedną z części obrony jest zachowanie ścieżki audytu zapytań i obliczenia wstecz, aby ocenić, co robili użytkownicy. Ale nie ma łatwej całkowitej obrony przed wydarzeniem.

NIEZAAWANSOWANE ATAKI

Nie trzeba nawet nieumyślnie instalować na serwerze podatnego na ataki oprogramowania. Czasami sprzedawcy sami zostawiają otwarte drzwi. Pojawiły się doniesienia, że ​​jeden popularny serwer UNIX ma prawie 30 możliwości nielegalnego wejścia, chyba że zostaną one indywidualnie wyłączone. Inny bardzo popularny system operacyjny ma ponad 45 domyślnych haseł. Jeśli nie zostaną usunięte, każdy z nich może umożliwić nieautoryzowany dostęp. Jednym z przykładów cytowanych przez organ doradczy US NIPC w 1999 r. (o nazwie kodowej 99-027) jest zdalny atak bazy danych na dobrze znany internetowy serwer informacyjny. O ile domyślna opcja pozostawienia tzw. stron przykładowych RDS nie została nadpisana, umożliwia to przeglądarce internetowej wysyłanie i odbieranie zapytań SQL do bazy danych oraz zmianę wpisów. Twierdzi się nawet, że istnieje narzędzie atakujące, które może automatycznie wykryć tę lukę. Inny przykład, od innego dostawcy, jest jeszcze prostszy. Zakładając, że po adresie URL serwera zostanie wpisana dość duża liczba symboli ///, uzyskuje się dostęp do katalogu głównego. Podano liczbę 211 ukośników, ale różni się ona w zależności od wersji serwera. Większość z tych gotowych do użycia luk zostało pozostawionych, aby ułatwić administratorom systemów konfigurowanie i konfigurowanie nowych systemów. Sprzedawcy twierdzą, a sądy jak dotąd nie poświadczają inaczej, że obowiązkiem nabywców jest podjęcie niezbędnych środków ostrożności w celu usunięcia tych luk w zabezpieczeniach. Biorąc pod uwagę kompetentną, a może lepiej „doskonałą” administrację systemami, to nie stanowią one problemów bezpieczeństwa, ale kto jest doskonały?

ATAKI NA SERWER WWW

Wiele innych ataków można zamontować na serwerach sieci Web, co ma różne skutki: na najprostszym poziomie można przeprowadzić atak typu „odmowa usługi”, po prostu bombardując serwer żądaniami. Jeśli ta możliwość nie została uwzględniona przez projektantów, prawdopodobnie doprowadzi to do przepełnienia buforów wejściowych i może doprowadzić do przypadkowego zapisu danych w obszarach zawierających kod wykonywalny. To prawie nieuchronnie doprowadzi do awarii systemu. Nie zawsze łatwo jest wykryć na serwerze, że trwa atak typu „odmowa usługi”. Jak wyjaśniono , wydajność systemu, niezależnie od tego, czy jest on atakowany, czy uzasadniony duży popyt, może wymagać zdalnego monitorowania. Wszystkie, z wyjątkiem najprostszych projektów serwerów sieci Web, obejmują możliwość wywoływania innych programów aplikacji (na przykład operacji wyszukiwania i pobierania danych) w odpowiedzi na żądania klientów-użytkowników poprzez uruchomienie kodu wykonywalnego, na podstawie parametrów przesłanych przez przeglądarkę użytkownika, przy użyciu , na przykład CGI lub Active Server Pages. Zbyt często dla wygody badania bezpieczeństwa ujawniają, że procesy te są zaprojektowane i zainstalowane w sposób niepewny i mogą zostać uszkodzone w celu uruchomienia procesów, do których projektanci nigdy nie mieli zamiaru, gdy są wywoływane zdalnie za pomocą legalnego wiersza poleceń HTTP z dostępem do sieci Web. Dodatkowe instrukcje w HTTP są przekazywane z serwera WWW w celu aktywowania różnych usług aplikacji, które tworzą usługę i dostarczenia im danych. Programy aplikacyjne są skonfigurowane tak, aby odbierać dane przekazywane im przez serwer WWW w postaci ciągów danych zawartych w adresie URL. Na przykład www.myshop.com/cgi-bin/search.cgi?subject = cardigan łączy się z serwerem sieciowym myshop.com, który z kolei aktywuje aplikację o nazwie search i dostarcza jej łańcuch danych cardigan. Przypuszczalnie program przeszuka bazę danych i zwróci informacje o kardiganach. Taki jest zamiar. Załóżmy jednak, że złośliwy użytkownik zauważa, że ​​poprawny adres URL ma postać www.myshop.com/cgi-bin/search.cgi?subject ¼ cardigan wysyła do serwera WWW coś innego, www.myshop.com/cgi-bin/searchTEST. cgi?subject = sweter. Co się stanie? Może nic; być może uda się zgadnąć, a searchTEST.cgi uruchomi wczesny, wadliwy lub niebezpieczny proces. To, co się faktycznie wydarzy, będzie całkowicie zależeć od integralności projektu i jego odporności na atak. Jeśli jest zagrożony, haker może zablokować serwer lub podłączyć tę aplikację do innych aplikacji.

ATAKOWANIE UŻYTKOWNIKÓW INTERNETOWYCH POPRZEZ TAJNE KANAŁY

Niechroniony charakter Internetu pozwala na montowanie wielu innych form ataków. Przyczynia się do tej luki jest również coraz aktywniejsza rola terminala klienta. Jak opisano na stronie 94, w pierwotnym trybie działania sieci przeglądarka terminala działała zasadniczo jako prosty mechanizm pobierania statycznych stron internetowych, których jedynymi informacjami nietekstowymi były informacje używane przez przeglądarkę do formatowania stron. Ustąpiło to sytuacji, w której kod wykonywalny, w postaci apletów Javy lub kontrolek ActiveX, jest uruchamiany na terminalu i może wykonywać szereg czynności, które mogą być potencjalnie niebezpieczne. Aby podać jeden przykład: Dean i in. na Uniwersytecie Princeton podali szczegóły dotyczące wielu luk w zabezpieczeniach JAVA. Rozróżniają one ataki dwu- i trójstronne, w których w pierwszym przypadku musi być zaangażowany serwer sieciowy, ale drugie może zostać przeprowadzone bez zmowy z serwerem. Ataki trójstronne polegają na słabości zabezpieczeń w metodach mających na celu ograniczenie apletów JAVA do komunikacji tylko z serwerem, z którego zostały pobrane do przeglądarki użytkownika. W jednej z odmian ataku możliwe jest, że aplet, po uruchomieniu w przeglądarce, zażąda od serwera wysłania wiadomości e-mail do dowolnego komputera w innym miejscu w Internecie. W jaki sposób ten złośliwy aplet dostaje się na serwer? Dean i wsp. sugerują, że A mógłby umieścić go w pozornie nieszkodliwym narzędziu, które B uznał za atrakcyjne i zamieścił na swojej stronie internetowej. C przegląda stronę internetową, a tym samym ładuje i włącza aplet, który teraz komunikuje się z A za pomocą prostego protokołu transmisji poczty SMTP (e-mail) przez serwer B, nieznany B. Inna odmiana tego procesu może wykorzystywać domenę Name Service (DNS) jako dwukierunkowy ukryty kanał komunikacyjny: aplet wysyła wywołanie do fikcyjnej nazwy, która znajduje się w domenie atakującego. System atakującego rozpoznaje tę fikcyjną nazwę. Możliwe jest wielokrotne wykorzystanie tej metody, aby otworzyć dwukierunkowy kanał komunikacji między maszyną użytkownika a maszyną atakującego. Takie metody zostały wykorzystane do wyodrębnienia danych karty kredytowej z komputera klienckiego.