Cyfroteka.pl

klikaj i czytaj online

Cyfro
Czytomierz
00268 004576 14685415 na godz. na dobę w sumie
Bezpieczeństwo systemu e-commerce, czyli jak bez ryzyka prowadzić biznes w internecie - książka
Bezpieczeństwo systemu e-commerce, czyli jak bez ryzyka prowadzić biznes w internecie - książka
Autor: , , Liczba stron: 240
Wydawca: Onepress Język publikacji: polski
ISBN: 978-83-246-3873-4 Data wydania:
Lektor:
Kategoria: ebooki >> poradniki >> e-biznes
Porównaj ceny (książka, ebook (-30%), audiobook).

Na straży Twojego e-biznesu

Biznes w internecie to świetna alternatywa dla sprzedaży towarów czy usług w sposób tradycyjny. Kupować w sieci można taniej, szybciej, wygodniej, a rynek odbiorców zwiększa się wielokrotnie w stosunku do tradycyjnego. No i oczywiście 'prowadzić e-biznes każdy może'. Aż do pierwszego potknięcia, często związanego z niedostatecznym zabezpieczeniem systemu, w oparciu o który pracuje sklep czy też platforma e-biznesowa.

Problemy z bezpieczeństwem systemów e-commerce mogą mieć wiele rozmaitych przyczyn.

W książce Bezpieczeństwo systemu e-commerce znajdziesz przede wszystkim informacje o mechanizmach prewencyjnych, czyli możliwych sposobach zabezpieczania systemu. Poznasz także wymogi prawne obowiązujące osoby handlujące przez internet. Autorzy rozpatrują je od strony aplikacji e-commerce, lecz także szerzej (opisują m.in. kwestię zapisów w regulaminie sklepu internetowego).


Bardzo wartościowa publikacja, łącząca kwestie prawne oraz informatyczne, z naciskiem na aspekty praktyczne, pomocna przy projektowaniu rozwiązań na użytek małych i średnich przedsiębiorców.
dr Stefan Szyszko,
polski i unijny ekspert w dziedzinie ochrony informacji, ze szczególnym uwzględnieniem ochrony danych osobowych w sektorze ubezpieczeniowym


Informacje zawarte w tym opracowaniu mogą przydać się przedsiębiorcom zamierzającym wejść ze swoją ofertą w świat rozwiązań internetowych lub zmieniającym sposób świadczenia usług. Mogą przydać się też administratorom wdrażającym i eksploatującym systemy e commerce oraz służyć jako przewodnik osobom zainteresowanym ochroną informacji w systemach e biznesu.
Maciej Kołodziej,
administrator bezpieczeństwa informacji w spółce Nasza Klasa, specjalista informatyki śledczej


Publikacja z pewnością przyczyni się do rozwoju kultury bezpieczeństwa informacyjnego. To bardzo ważna książka dla wszystkich zaangażowanych w biznes online, zarówno tych prowadzących sklepy internetowe, jak i przygotowujących dla nich aplikacje i rozwiązania informatyczne.
Marcin Olszewik,
Dyrektor zarządzający w Allianz Direct New Europe


Leszek Kępa - menedżer wydziału bezpieczeństwa w grupie kapitałowej działającej w branży finansowej; absolwent Szkoły Głównej Handlowej, Politechniki Częstochowskiej i Akademii Podlaskiej. Autor książki Dane osobowe w firmie. Praktyczny poradnik przedsiębiorcy. Zawodowo zajmuje się m.in. zagadnieniami związanymi m.in. takimi, jak zarządzaniem bezpieczeństwem informacji, badaniami bezpieczeństwa systemów i aplikacji, elementami ciągłości działania i problematyką ochrony danych osobowych. Członek ISACA oraz Podkomisji Ochrony Danych i Standaryzacji Informacji Polskiej Izby Ubezpieczeń.

Paweł Tomasik - absolwent Wyższej Szkoły Informatyki Stosowanej i Zarządzania w Warszawie; wieloletni praktyk w zarządzaniu bezpieczeństwem informacji w firmach z branży finansowej (bankowość, ubezpieczenia) oraz logistycznej. Ma doświadczenie poparte uznanymi certyfikatami, takimi jak m.in. Certified Information Systems Auditor (CISA), Audytor wewnętrzny ISO27001. Członek- założyciel ISACA Warsaw Chapter.

Sebastian Dobrzyński - aplikant radcowski w Okręgowej Izbie Radców Prawnych w Warszawie. Doświadczenie zawodowe zdobył podczas pracy pracując w bankach, m.in. przy analizie prawnej zabezpieczeń kredytów hipotecznych oraz w sprawach legislacyjnych. Obecnie pełni funkcję Administratora Bezpieczeństwa Informacji w jednej ze spółek grupy kapitałowej działającej w branży finansowej, w której zajmuje się ochroną danych osobowych. Jest członkiem zespołu ekspertów ds. Kodeksu Dobrych Praktyk w zakresie ochrony danych osobowych w ubezpieczeniach, działającego przy Podkomisji Ochrony Danych i Standaryzacji Informacji Polskiej Izby Ubezpieczeń.

Znajdź podobne książki Ostatnio czytane w tej kategorii

Darmowy fragment publikacji:

Wszelkie prawa zastrzeżone. Nieautoryzowane rozpowszechnianie całości lub fragmentu niniejszej publikacji w jakiejkolwiek postaci jest zabronione. Wykonywanie kopii metodą kserograficzną, fotograficzną, a także kopiowanie książki na nośniku filmowym, magnetycznym lub innym powoduje naruszenie praw autorskich niniejszej publikacji. Wszystkie znaki występujące w tekście są zastrzeżonymi znakami firmowymi bądź towarowymi ich właścicieli. Autor oraz Wydawnictwo HELION dołożyli wszelkich starań, by zawarte w tej książce informacje były kompletne i rzetelne. Nie biorą jednak żadnej odpowiedzialności ani za ich wykorzystanie, ani za związane z tym ewentualne naruszenie praw patentowych lub autorskich. Autor oraz Wydawnictwo HELION nie ponoszą również żadnej odpowiedzialności za ewentualne szkody wynikłe z wykorzystania informacji zawartych w książce. Autorzy: Leszek Kępa, Paweł Tomasik, Sebastian Dobrzyński Redaktor prowadzący: Barbara Gancarz-Wójcicka Projekt okładki: Jan Paluch Fotografia na okładce została wykorzystana za zgodą Shutterstock. Wydawnictwo HELION ul. Kościuszki 1c, 44-100 GLIWICE tel. 32 231 22 19, 32 230 98 63 e-mail: onepress@onepress.pl WWW: http://onepress.pl (księgarnia internetowa, katalog książek) Drogi Czytelniku! Jeżeli chcesz ocenić tę książkę, zajrzyj pod adres http://onepress.pl/user/opinie/bezsec Możesz tam wpisać swoje uwagi, spostrzeżenia, recenzję. ISBN: 978-83-246-3873-4 Copyright © Helion 2012 Printed in Poland. • Kup książkę • Poleć książkę • Oceń książkę • Księgarnia internetowa • Lubię to! » Nasza społeczność SPIS TRE¥CI PRZEDMOWA WSTĉP Podstawowe informacje o e-commerce Czego chcą cyberprzestĊpcy? Podstawy bezpieczeĔstwa 1. PRAWO WOBEC E-COMMERCE Jakie prawo dotyczy e-handlu? Regulamin serwisu ĝwiadcząc usáugi drogą elektroniczną Przetwarzanie danych osobowych Zawarcie umowy miĊdzy stronami O czym naleĪy informowaü Kodeks spóáek handlowych Prawo wobec cyberprzestĊpców 2. BEZPIECZEēSTWO OGÓLNE Informacje o systemie Zapasowe kopie danych 3. BEZPIECZNY HOSTING Hosting czy wáasny serwer? DirectAdmin 4. ZABEZPIECZENIA SERWERA WWW Zabezpieczenia hosta Zabezpieczenia Apache 9 15 18 21 24 33 34 37 54 57 60 65 72 72 77 78 82 89 89 90 97 98 102 6 | B E Z P I E C Z E ” S T W O S Y S T E M U E - C O M M E R C E Konfiguracja PHP Zabezpieczenie kodu PHP Przeglądanie logów Obsáuga komunikatów 403, 404 etc. Zabezpieczanie plików konfiguracyjnych Tripwire Obrona przed atakami DoS — Fail2ban 5. BAZA DANYCH Poáączenie z bazą Szyfrowanie danych 6. BEZPIECZNA TRANSMISJA DANYCH Dlaczego warto szyfrowaü? Szyfrowanie komunikacji webowej A jeĞli nie ma szans na SSL? Komunikacja przez e-mail Administrowanie poprzez sieü IntegralnoĞü danych podczas transmisji 7. IDENTYFIKACJA STRON W BIZNESIE Wiarygodny sprzedawca Zidentyfikowany uĪytkownik 8. KONTA I HASàA Data wprowadzenia danych Hasz zamiast hasáa Provisioning — zakáadanie konta Cookies Sesje w aplikacji Sprawdzanie, czy poáączenie odbywa siĊ „po SSL” Autoryzacja transakcji 9. ZABEZPIECZENIA KODU APLIKACJI Specyfika jĊzyka Jak przesyáaü dane — GET czy POST? Walidowanie danych przesyáanych do serwera Zabezpieczenia przed automatami 108 116 117 118 119 120 122 125 128 130 133 136 137 153 154 156 159 165 166 168 177 177 179 184 185 189 195 196 197 198 198 201 208 SQL injection File inclusions Ataki XSS Ataki CSRF i XSRF HTTP_REFERER Badanie kodu PHP 10. KODOWANIE DANYCH ZAKOēCZENIE O AUTORACH S P I S T R E ¥ C I | 7 212 222 226 230 232 233 235 239 240 8 | B E Z P I E C Z E ” S T W O S Y S T E M U E - C O M M E R C E Rozdziaï 2. BEZPIECZE”STWO OGÓLNE WspomnieliĞmy juĪ wczeĞniej, Īe zagadnienie bezpieczeĔstwa systemu e-commerce jest záoĪone. Skáada siĊ na nie: x bezpieczeĔstwo fizyczne serwerów, na których znajduje siĊ apli- kacja, serwer WWW, baza danych itd.; x zabezpieczenie systemów operacyjnych, w których są zainsta- lowane aplikacja, serwer WWW i baza danych; x takie bezpieczeĔstwo transmisji, aby danych w trakcie przesy- áania nikt nie podsáuchaá ani nie zmieniá; x bezpieczeĔstwo serwera DNS i domeny — to, Īeby nikt nie ukradá „nazwy internetowej” serwisu ani nie przekierowaá ruchu do innego, podrobionego systemu; x bezpieczeĔstwo aplikacji, a wiĊc takie jej utworzenie, aby nie moĪna byáo nią manipulowaü; x ciągáoĞü dziaáania, tj. takie zorganizowanie systemu i uzyskanie takiej jego odpornoĞci, aby nawet mimo ataku mógá on dalej funkcjonowaü lub wznowiü aktywnoĞü; x bezpieczeĔstwo organizacyjne, czyli procesy związane z admi- nistrowaniem aplikacją, zarządzanie zmianami i wszystko to, co jest dookoáa systemu, a ma na niego (znaczący) wpáyw; x bezpieczeĔstwo prawne, a wiĊc zarządzanie stanem zgodnoĞci z prawem. 7 8 | B E Z P I E C Z E ” S T W O S Y S T E M U E - C O M M E R C E Tutaj chcemy przedstawiü najogólniejsze zagadnienia związa- ne z bezpieczeĔstwem systemu e-commerce. INFORMACJE O SYSTEMIE Zapewne nieraz siĊ zastanawiaáeĞ, jak to siĊ dzieje, Īe haker w koĔcu „dopada” okreĞloną witrynĊ. Mogą byü tego dwa gáówne powody. Pierwszy moĪe byü taki, Īe witryna jest sáabo zabezpieczona i stanowi dla hakera áatwy áup — bĊdzie on mógá jej zhakowanie wpisaü do ewidencji swoich sukcesów. Drugi to celowy atak na wáaĞnie ten, a nie inny serwis. Na pewno jednak nieodáącznym elementem kaĪdego ataku jest rekonesans, czyli rozpoznanie. Odbywa siĊ to zupeánie tak jak w „realu” — zanim záodziej przystąpi do dziaáania, obserwuje i zbiera informacje. KaĪda informacja moĪe byü dla hakera przydatna, a szczególnie o: x systemie operacyjnym (rodzaj, wersja, uruchomione programy i usáugi); x bazie danych (rodzaj i wersja); x kodzie aplikacji; x chronionych czĊĞciach aplikacji; x konfiguracji i zabezpieczeniach systemu. ZnajomoĞü wersji oprogramowania pozwala hakerowi znaleĨü luki w zabezpieczeniach — przy odrobinie szczĊĞcia moĪe on trafiü na wersjĊ, w której nie zostaáy one zaáatane. Do wyszukania luk za- bezpieczeĔ w okreĞlonej wersji oprogramowania haker moĪe uĪyü np. bazy CVE1. Ty z niej korzystasz, aby wiedzieü, co jest dziurawe, i Īeby to zaktualizowaü, a cyberprzestĊpcy uĪywają jej, aby mieü in- formacje o tym, jakie systemy (i jakie ich wersje) „chorują”, są po- datne na atak. 1 https://cve.mitre.org/ B E Z P I E C Z E ” S T W O O G Ó L N E | 7 9 Wiedza o rodzaju bazy danych pozwala z kolei dostosowaü ata- ki polegające na wstrzykiwaniu kodu SQL — juĪ sama ta informacja jest istotna, bo niektóre ataki są specyficzne dla rodzaju bazy da- nych, np. dziaáają w przypadku PostgreSQL, ale nie z MySQL. Nawet rodzaj jĊzyka, w którym napisano aplikacjĊ, ma znaczenie. SprawdĨmy, jak moĪe wyglądaü atak cyberprzestĊpcy, który dla zabawy chce spróbowaü swoich siá w hackingu. Pierwsze, co moĪe on zrobiü, to wpisanie w wyszukiwarce ciągu sql dorks. Oto przy- káadowe ciągi tego typu: allinurl:showimg.php?id= allinurl:view.php?id= allinurl:website.php?id= allinurl:hosting_info.php?id= allinurl:gallery.php?id= Haker kopiuje i wkleja jeden z nich do wyszukiwarki, a nastĊpnie otwiera strony bĊdące wynikami wyszukiwania i przeprowadza re- konesans. Najáatwiej jest zacząü od sprawdzenia, czy dany ciąg (okre- Ğlany mianem SQL dorka) zadziaáa. Przykáadowo http://www. witryna.com/gallery.php?id=1 zawiera SQL dork gallery.php?id=. Wystarczy w pasku adresowym na koĔcu dodaü znak apostrofu i w wyniku otrzymujemy: Fatal error: Uncaught exception Exception with message SQL Query failed: SELECT image,title,location,description,height,width from tblSCAImages WHERE id=83\ You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near \ at line 1 in /home/sca/wwwlib/gallery_lib.php:16 Stack trace: #0 /home/sca/www/gallery.php(21): sca_gallery_get_image_meta( 83 ) #1 {main} thrown in /home/sca/wwwlib/gallery_lib.php on line 16 Mamy tu informacje o báĊdach i juĪ coĞ wiemy o witrynie — wiemy, Īe jest to MySQL, a takĪe o nazwach tabel i ich kolumn, o funkcjach PHP, a nawet o systemie plików. To siĊ przyda. SprawdĨmy, jak witryna internetowa zareaguje na wpisanie báĊdnego 8 0 | B E Z P I E C Z E ” S T W O S Y S T E M U E - C O M M E R C E adresu strony http://www.witryna.com/coscokolwiek. Tu teĪ otrzy- mujemy komunikat: Not Found The requested URL /coscokolwiek was not found on this server. Apache/2.2.3 (CentOS) Server at www.allspeedperformance.com Port 80 Znamy juĪ wersjĊ serwera Apache. Zobaczmy jeszcze, jakie czĊĞci witryny są chronione. Wpiszmy http://www.witryna.com/ robots.txt. Otrzymamy: User-agent: * Disallow: /checkout/ To tylko przykáad tego, jak moĪna zacząü. Dalej moĪna „grze- baü” w cookies, uĪyü programu sqlmap, rĊcznie wstrzykiwaü kod… MoĪliwoĞci jest wiele. To pokazuje, Īe ujawnianie zbyt wielu infor- macji moĪe dziaáaü na szkodĊ systemu, bo pozwala przeprowadziü rekonesans. Dla hakera moĪe byü przydatna w zasadzie kaĪda infor- macja, zadbaj wiĊc o to, aby nie wypuszczaü na zewnątrz komuni- katów o báĊdach wraz z ich detalami oraz informacjami o wersji oprogramowania. Pozwala to hakerowi odnaleĨü sáabe punkty da- nej wersji. Jak wprowadziÊ hakera w bïÈd UwaĪamy, Īe skoro podstawą ataków jest rekonesans, to moĪe warto atakującego wyprowadziü w pole. Gdy widaü wyraĨnie, Īe coĞ jest porządnie chronione, to pewnie jest warte tego, aby to ukraĞü. MoĪna to wykorzystaü do stworzenia puáapki na cyberprzestĊpcĊ. BĊdzie on dáugo áamaá zabezpieczenia, aby w efekcie uzyskaü do- stĊp do nic nie wartych informacji lub uruchomiü alarm informujący, Īe dzieje siĊ coĞ záego. Takie rozwiązanie nazywa siĊ z angielskiego honeypot. Taką puáapkĊ moĪna przykáadowo zastawiü, korzystając z pliku robots.txt, który sáuĪy do zezwalania na indeksowanie lub B E Z P I E C Z E ” S T W O O G Ó L N E | 8 1 do wykluczania z indeksowania tych czĊĞci witryny, na których przeszukiwanie nie chcemy pozwoliü tzw. robotom (np. botowi in- deksującemu strony dla Google). Plik ten znajduje siĊ w roocie (ka- talogu gáównym) witryny, np. http://ecommerce/robots.txt. MoĪna go uĪyü do zmylenia przeciwnika, wpisując w nim faászywe odnie- sienia, a nastĊpnie monitorowaü te faászywie podstawione punkty. User-agent: * Crawl-delay: 10 Disallow: /strona_administracyjna/ Disallow: /admin_password.txt Inną moĪliwoĞcią „wkrĊcania” atakującego jest wprowadzanie go w báąd co do wykorzystanego oprogramowania. Przykáadowo po zmianie rozszerzenia i nagáówków kod PHP moĪe udawaü inny kod: ?php error_reporting(0); header( X-Powered-By: ASP.NET ); ? NaleĪy wtedy jeszcze pamiĊtaü, aby korzystając z session_name(), ustawiü nazwĊ sesji na przykáad na SessionID, poniewaĪ domyĞlne PHPSESSID od razu wskazuje na PHP. Rewrite Parametry kategorii, subkategorii i rozmaitych podstron wystĊpujące w adresie URL moĪna z áatwoĞcią ukryü, korzystając z mod_rewrite2. JeĞli Twój system prezentuje adres w postaci http://strona/news. php?kategoria=10 rodzaj=4, to moĪna to zmieniü, zapisując przy- káadowo w .htaccess3 na serwerze nastĊpujący ciąg: 2 Coraz czĊĞciej pojawiają siĊ opinie, Īe moduá ten umiarkowanie wpáywa na bezpieczeĔstwo, dlatego trzeba mieü zainstalowaną aktualną wersjĊ i stosowaü go ostroĪnie. 3 Nazwa pliku .htaccess zaczyna siĊ od kropki. ObecnoĞü kropki na po- czątku nazwy pliku (lub folderu) oznacza, Īe jest to plik (folder) ukryty. 8 2 | B E Z P I E C Z E ” S T W O S Y S T E M U E - C O M M E R C E RewriteEngine On RewriteRule ^([a-z0-9-_]+),([a-z0-9-_]+),([a-z0-9-_]+).html$ $1.php?kategoria=$2 rodzaj=$3 [L,NC,NS] Zmienne $ z cyfrą odpowiadają poszczególnym nawiasom reguá- ki, natomiast ^ rozpoczyna, a $ koĔczy wyraĪenie regularne. Jesz- cze ciekawszy wydaje siĊ zapis RewriteRule ^artykul/([0-9]+)_(.*).html$ articles.php?id=$1 W tym przykáadzie /artykul/24_wielka_wojna i /artykul/24_protesty_ ´acta zostaną zamienione na /articles.php?id=24 (odniesienie $2 jest ignorowane). Jak widzisz, jeĞli dobrze wykorzystasz ten moduá, to ciągi sql-dork nie bĊdą w serwisie widoczne. ZAPASOWE KOPIE DANYCH Znamy osoby, które pisząc pracĊ magisterską, nie wykonaáy zapa- sowej kopii danych. Po stracie plików (póárocznej pracy) musiaáy napisaü ją w ciągu miesiąca. W takich przypadkach zwykliĞmy Īartowaü, Īe ludzie dzielą siĊ na tych, którzy robią kopie za- pasowe, i na tych, którzy bĊdą je robiü. Bezpowrotna utrata danych jest jedną z najgorszych rzeczy, jakie siĊ mogą przedsiĊ- biorcy przydarzyü — moĪe to prowadziü nawet do bankructwa. Skra- dzione komputery moĪna kupiü, a danych niestety nie. W tej materii ĞwiadomoĞü nie jest jednak zbyt wysoka, a sam temat kopii zapaso- wych (zwanych backupami) staje siĊ waĪny dopiero wtedy, gdy coĞ siĊ wydarzy. Tak samo jest w przypadku systemów e-commerce, szczególnie tych maáych i Ğrednich. Tymczasem ciągáy i poprawny proces wykonywania kopii zapasowych oraz testowania, czy da siĊ z nich odtworzyü dane konieczne do prowadzenia biznesu, pozwala zminimalizowaü ryzyko ich bezpowrotnej utraty. Wiedzą to bez wątpienia ci, którzy interesują siĊ zagadnieniami zachowania cią- gáoĞci dziaáania (tzw. BCM4). 4 BCM — ang. business continuity management. B E Z P I E C Z E ” S T W O O G Ó L N E | 8 3 W jakiej sytuacji kopia danych moĪe siĊ przydaü? Chyba najle- piej odpowiedzieü, Īe w kaĪdej: x awaria urządzeĔ (najczĊĞciej ulegają jej noĞniki danych — dys- ki twarde); x báąd ludzki, czyli utrata danych w wyniku niecelowego dziaáa- nia pracownika (coĞ siĊ niechcący usunĊáo); x sabotaĪ — utrata danych w wyniku celowego szkodliwego dziaáania na przykáad niezadowolonego pracownika; x dziaáanie wirusów (oprogramowania záoĞliwego), których celem moĪe byü usuniĊcie bądĨ zaszyfrowanie danych, aby uniemoĪ- liwiü do nich dostĊp; x atak hakerów, czyli celowe usuniĊcie, zmodyfikowanie czy znisz- czenie danych. x kradzieĪ sprzĊtu i utrata noĞników danych; x zdarzenie losowe — uszkodzenie sprzĊtu w wyniku przepiĊcia, zalania itp. Jedno z praw Murphy’ego mówi, Īe jeĞli coĞ moĪe pójĞü Ĩle, to z pewnoĞcią pójdzie Ĩle, wiĊc nie ma co liczyü, Īe nic siĊ nie zda- rzy. Na pewno siĊ zdarzy — to tylko kwestia czasu. Co naleĝy backupowaÊ? Przede wszystkim wykonuje siĊ kopie zapasowe danych bizneso- wych. BĊdą to bazy danych, pliki i katalogi serwisu e-commerce. W przypadku hostingu zajmuje siĊ tym hostingodawca, ale jeĞli ser- wery są w caáoĞci pod Twoim wáadaniem, to zadanie to spada na Ciebie (rysunek 2.1). JeĞli zarządzasz caáym systemem, niezbĊdny bĊdzie backup konfiguracji aplikacji, bazy danych, systemów operacyjnych czy teĪ urządzeĔ sieciowych. 8 4 | B E Z P I E C Z E ” S T W O S Y S T E M U E - C O M M E R C E Rysunek 2.1. Hosting — moĪliwoĞü wykonania samodzielnie backupu z poziomu panelu hostingowego (DirectAdmin) To, jak czĊsto naleĪy wykonywaü zapasową kopiĊ danych biz- nesowych, zaleĪy od systemu i jego specyfiki. Trzeba odpowiedzieü sobie na pytanie o to, z jakiego okresu dane mogą zostaü utracone. JeĞli serwis jest maáo aktywny, to zapasowa kopia danych wyko- nywana raz na tydzieĔ teĪ moĪe byü dobra, jednak w przypadku aktywnych systemów na pewno powinna ona byü tworzona co- dziennie. PamiĊtaj, Īe serwisy pracujące w klastrze to nie backup; nie stanowi go teĪ np. disk mirroring. Dane dotyczące konfiguracji moĪna backupowaü nieco rza- dziej, ale naleĪy to robiü przed kaĪdą zmianą i po niej. B E Z P I E C Z E ” S T W O O G Ó L N E | 8 5 JeĞli chodzi o hosting, to wiĊkszoĞü hostingodawców — jeĞli nie wszyscy — tworzy zapasowe kopie danych i udostĊpnia je uĪyt- kownikowi (rysunek 2.2). Rysunek 2.2. Backup danych dostĊpny w usáudze hostingu W wiĊkszoĞci przypadków dostĊpny jest takĪe backup na Īą- danie. Przydaje siĊ on na przykáad przed dokonaniem w serwisie istotnych zmian, które są na tyle ryzykowne, Īe lepiej zapewniü sobie kopiĊ. Operacją taką jest choüby aktualizacja systemu czy zmiana struktury bazy danych. System informatyczny to nie czáo- wiek — wiĊkszoĞci operacji nie powinno siĊ wykonywaü na „Īy- wym organizmie”. Kopia zapasowa moĪe byü niewiele warta, jeĪeli okaĪe siĊ, Īe zostaáa nieprawidáowo wykonana, dlatego okresowo naleĪy spraw- dzaü, czy w kopii zapisane są potrzebne dane i czy da siĊ je odtwo- rzyü. Za bardzo waĪne uwaĪamy to, aby backup byá przechowywany takĪe poza siedzibą firmy, nawet w domu, jeĞli zostaną zapewnione odpowiednie warunki. DziĊki temu w przypadku duĪej awarii bĊdzie 8 6 | B E Z P I E C Z E ” S T W O S Y S T E M U E - C O M M E R C E moĪliwe szybkie odtworzenie systemu na przykáad na innym sprzĊcie i (lub) w innej lokalizacji. Kopia zapasowa danych zawiera wszystko to, co jest w orygi- nalnym Ğrodowisku e-commerce, wiĊc mogáaby byü cenną zdoby- czą dla konkurencji. W związku z tym backup powinien byü chro- niony na poziomie nie niĪszym niĪ sam system e-commerce. DostĊp do niego powinny mieü tylko wybrane osoby. Dobrze by byáo, aby dane na noĞnikach byáy szyfrowane, szczególnie jeĪeli mają byü one przechowywane w domu. Zapewnienie tego jest akurat proste, bo caáy backup moĪna zabezpieczyü hasáem: ~# gpg -c backup.tar #zaszyfrowanie ~# gpg backup.tar.gpg #odszyfrowanie Nawiasem mówiąc, polecenie gpg domyĞlnie kompresuje dane przed szyfrowaniem. Wystarczające jest teĪ spakowanie danych do pliku ZIP i zabezpieczenie go hasáem. DziĊki temu jest maáe ryzy- ko, Īe dane, za pomocą których moĪna by utworzyü „duplikat fir- my”, wpadną w niepowoáane rĊce. Warto teĪ zauwaĪyü, Īe do zabezpieczania plików moĪna uĪyü pakietu openssl. Przykáadem są nastĊpujące polecenia do szyfro- wania i (póĨniej) odszyfrowywania danych: ~# openssl aes-128-cbc -salt -in plik.tar -out plik.tar.aes enter aes-128-cbc encryption password: Verifying - enter aes-128-cbc encryption password: ~# openssl aes-128-cbc -d -salt -in plik.tar.aes -out plik.tar MoĪna teĪ zrobiü to nieco inaczej — „starowaü” katalog, spa- kowaü do pliku ZIP, póĨniej zaszyfrowaü: ~# tar -zcf - caly_katalog | openssl aes-128-cbc -salt -out caly_katalog.tar.gz.aes a w koĔcu odszyfrowaü: ~# openssl aes-128-cbc -d -salt -in caly_katalog.tar.gz.aes | tar -xz -f - B E Z P I E C Z E ” S T W O O G Ó L N E | 8 7 Nie zalecamy uĪywania opcji -k hasđo po wyraĪeniu aes-128-cbc — wtedy co prawda unikamy interaktywnego pytania o hasáo, ale prowadzi to do zapisania go na przykáad w pliku .history5. MoĪna teĪ uĪyü aes-256-cbc zamiast aes-128-cbc, jeĞli jest potrzebne silniejsze szyfrowanie, ale naszym zdaniem rzadko kiedy jest to konieczne. MówiliĞmy o backupie wszystkich danych, ale moĪe siĊ teĪ zdarzyü, Īe pracując na pojedynczych plikach (np. kodzie PHP), bĊdziesz w trakcie ich modyfikacji tworzyá podrĊczne kopie zapaso- we. Chodzi nam o Īywy organizm, tj. dziaáający system e-commerce. Przykáadowo edytując plik dbconnect.inc, moĪesz zrobiü kopiĊ te- go pliku i zapisaü ją jako dbconnect.inc.old. Jest to bardzo niebez- pieczne, gdyĪ moĪe siĊ okazaü, Īe o ile pliki *.inc serwer moĪe bloko- waü przy uĪyciu dyrektywy Files *.inc , to moĪe tego nie robiü dla plików *.old czy *.backup. Wtedy atakujący bĊdzie mógá je odczytaü przez przeglądarkĊ, wpisując na przykáad adres http://ecommerce/ dbconnect.inc.old. PowinieneĞ wiĊc dodaü do konfiguracji webserwe- ra odpowiednią dyrektywĊ i konsekwentnie trzymaü siĊ nazewnic- twa takich „backupów” tymczasowych (podrĊcznych). Backup haseï Hasáo moĪna zapomnieü, wiĊc je teĪ warto w pewien sposób bac- kupowaü, czyli zapisywaü. Najlepiej uĪyü to tego oprogramowania — nie zalecamy przechowywania haseá w postaci jawnej w note- sach, na „Īóátych karteczkach” etc. KorzyĞci związane z ich zapi- sywaniem z uĪyciem elektronicznego sejfu są doĞü duĪe — moĪesz tworzyü unikalne, záoĪone hasáa dla kaĪdego serwisu i nie przej- mowaü siĊ tym, Īe je zapomnisz. Elektroniczny sejf to po prostu zaszyfrowany plik z hasáami; pisaliĞmy juĪ wczeĞniej o programie KeePass. Musisz mieü jego backup! Najlepiej mieü ich kilka 5 W pliku .history przechowywana jest historia wszystkich poleceĔ wy- dawanych w oknie terminalu. 8 8 | B E Z P I E C Z E ” S T W O S Y S T E M U E - C O M M E R C E i w róĪnych miejscach — wtedy prawdopodobieĔstwo jednocze- snej utraty ich wszystkich jest niewielkie. Piszemy o tym, bo przy tworzeniu hasáa na przykáad do poáą- czenia z bazą systemu e-commerce niekiedy brakuje nam fantazji. KeePass „wymyĞli” hasáo za Ciebie (rysunek 2.3), a poniewaĪ jed- noczeĞnie je zachowa, nie bĊdziesz musiaá przejmowaü siĊ tym, jakie ono jest, i bĊdziesz mógá pozwoliü sobie na to, by byáo hard- core’owe — dáugie i wrĊcz niemoĪliwe do zapamiĊtania. Zalecamy, aby tworzyü z uĪyciem tego programu przede wszystkim hasáa administracyjne (a najlepiej wszystkie). Rysunek 2.3. Generowanie haseá przy uĪyciu programu KeePass Na koniec warto jeszcze wspomnieü o tym, Īe plik z hasáami powinien byü zabezpieczony porządnym hasáem i przechowywany poza serwerem, na którym znajduje siĊ Twoja aplikacja.
Pobierz darmowy fragment (pdf)

Gdzie kupić całą publikację:

Bezpieczeństwo systemu e-commerce, czyli jak bez ryzyka prowadzić biznes w internecie
Autor:
, ,

Opinie na temat publikacji:


Inne popularne pozycje z tej kategorii:


Czytaj również:


Prowadzisz stronę lub blog? Wstaw link do fragmentu tej książki i współpracuj z Cyfroteką: