Zabezpieczanie danych w aplikacjach hostowanych

Opublikowano: 10 stycznia 2008

Zawartość strony

	Wstęp
	Zabezpieczanie tabel baz danych
	Filtry widoków dzierżawców
	Szyfrowanie danych dzierżawcy
	Podsumowanie

Wstęp

Zaufanie – czy też jego brak – to kluczowy czynnik decydujący o stosowaniu modelu Aplikacji hostowanych i Oprogramowania jako usługi (SaaS). Można przyjąć, że najważniejszym elementem każdej aplikacji biznesowej są dane – dane o produktach, klientach, pracownikach, dostawcach itp. W modelu hostowanym organizacja musi zaufać usługodawcy i przekazać mu część kontroli nad własnymi danymi.

Dla dostawcy usług, który chce zyskać zaufanie klientów jedną z najważniejszych spraw powinno być stworzenie architektury danych, która zapewni równocześnie wystarczającą dynamikę, jak i bezpieczeństwo kojące obawy klientów zaniepokojonych przekazaniem kontroli nad istotnymi danymi biznesowymi firmie niezależnej. Bezpieczna architektura powinna zapewniać głęboko urzutowaną ochronę przy użyciu szeregu poziomów wzajemnie uzupełniających się zabezpieczeń, chroniących dane na wiele sposobów, w różnych warunkach, tak przed zagrożeniami zewnętrznymi, jak i wewnętrznymi.

W artykule do realizacji wieloużytkownikowej architektury danych wykorzystamy trzy wzorce:

• Filtrowanie: Wprowadzenie warstwy pośredniej pomiędzy użytkownikiem a źródłem danych. Spełnia ona rolę sita, dzięki któremu użytkownik ma wrażenie, że w bazie danych znajdują się tylko jego dane.
• System uprawnień: Wykorzystanie list kontroli dostępu (ACL), by określić kto ma dostęp do danych aplikacji i co może z nimi zrobić.
• Szyfrowanie: Przekształcenie najważniejszych danych wszystkich użytkowników, tak, aby były niedostępne dla osób nieautoryzowanych nawet po wejściu w ich posiadanie.

W wielowarstwowych środowiskach aplikacji wielowarstwowych do zabezpieczania danych, przechowywanych w bazach danych wykorzystywana jest zazwyczaj jedna z dwóch metod: impersonacja lub konto zaufanego podsystemu.

W przypadku impersonacji baza danych zostaje skonfigurowana tak, by poszczególni użytkownicy mieli dostęp do odrębnych tabel, widoków, zapytań, procedur składowanych i pozostałych obiektów bazy danych.

Gdy użytkownik przeprowadza operację, która bezpośrednio lub pośrednio odwołuje się do bazy danych, aplikacja przedstawia się bazie danych jako ten właśnie użytkownik, podszywając się po niego w celu dostępu do bazy danych (używając terminologii technicznej: aplikacja korzysta z kontekstu bezpieczeństwa użytkownika). Do umożliwienia procesowi aplikacji nawiązania połączenia z bazą danych w imieniu użytkownika można wykorzystać mechanizm taki, jak delegacje Kerberos.

Rys. 1. Aplikacja łączy się z bazą danych przy użyciu impersonacji.

W przypadku metody zaufanego podsystemu aplikacja zawsze łączy się z bazą danych przy użyciu własnej, niezależnej od użytkownika, tożsamości procesu aplikacji. Serwer przyznaje następnie aplikacji dostęp do obiektów bazy danych, które aplikacja może czytać lub przetwarzać.

Wszelkie dodatkowe zabezpieczenia muszą zostać zaimplementowane w samej aplikacji, aby zapobiec dostępowi użytkowników końcowych do danych, do których nie powinni mieć oni dostępu. Takie podejście ułatwia zarządzanie zabezpieczeniami, eliminując konieczność konfiguracji dostępu do obiektów bazy danych dla poszczególnych użytkowników, ale oznacza równocześnie rezygnację z możliwości zabezpieczania obiektów bazy danych na poziomie pojedynczych użytkowników.

Rys. 2. Aplikacja łączy się z bazą danych jako zaufany podsystem.

W przypadku metody SaaS czy aplikacji hostowanej koncepcja użytkowników jest nieco bardziej skomplikowana niż w przypadku tradycyjnych aplikacji ze względu na rozróżnienie pomiędzy dzierżawcą a użytkownikiem końcowym. Dzierżawca to organizacja, która korzysta z aplikacji do dostępu do własnego magazynu danych, który jest logicznie odizolowany od pozostałych magazynów danych należących do innych dzierżawców. Każdy dzierżawca przyznaje dostęp do aplikacji jednemu lub więcej użytkowników końcowych, zezwalając im na dostęp do części danych dzierżawcy przy użyciu nadzorowanych przez dzierżawcę kont użytkowników końcowych.

Scenariusz ten umożliwia zastosowanie hybrydowego podejścia do dostępu do danych, łączącego elementy impersonacji i zaufanego podsystemu. Można więc wykorzystać zalety wbudowanych mechanizmów bezpieczeństwa serwera bazy danych, by zagwarantować maksymalną logiczną izolację danych dzierżawców bez konstruowania przesadnie skomplikowanego modelu zabezpieczeń.

Rys. 3. Aplikacja SaaS łączy się z bazą danych, wykorzystując kombinację metod impersonacji i zaufanego podsystemu.

Takie podejście zakłada utworzenie osobnego konta dostępowego do bazy danych dla każdego dzierżawcy i zastosowanie list ACL do przydzielenia każdemu z tych kont dostępu do tych obiektów bazy danych, do których dzierżawca ma mieć dostęp. Gdy użytkownik końcowy przeprowadza operację, która bezpośrednio lub pośrednio wiąże się z wywołaniem bazy danych, aplikacja wykorzystuje dane uwierzytelniające związane z kontem dzierżawcy, a nie dane związane z użytkownikiem końcowym.

Jedną z metod uzyskania odpowiednich danych uwierzytelniających przez aplikację jest zastosowanie impersonacji w połączeniu z systemem uwierzytelniającym, takim jak Kerberos. Inna możliwość to wykorzystanie usługi tokena bezpieczeństwa, która zwraca właściwy zestaw zaszyfrowanych danych uwierzytelniających logowania danego dzierżawcy, które proces aplikacji może następnie przekazać bazie danych.

Serwer bazy danych nie odróżnia zapytań pochodzących od poszczególnych użytkowników końcowych związanych z tym samym dzierżawcą i umożliwia wszystkim takim zapytaniom dostęp do danych dzierżawcy.

Załóżmy dla przykładu, że użytkownik końcowy aplikacji CRM przeprowadza operację, która wysyła do bazy danych kwerendę o rekordy klientów pasujące do określonego łańcucha. Aplikacja przekazuje zapytanie do bazy danych, korzystając z kontekstu bezpieczeństwa dzierżawcy, tak więc zamiast zwrócić wszystkie, pasując rekordy w bazie, kwerenda zwróci jedynie te wiersze, do których dzierżawca ma prawa dostępu. Na razie, wszystko dobrze – ale co w przypadku, gdy rola użytkownika końcowego zezwala mu jedynie na dostęp do rekordów klientów z określonego rejonu geograficznego? Aplikacja musi przechwycić wyniki zapytania i przedstawić użytkownikowi tylko te rekordy, do których ma on prawo dostępu.

 Do początku strony

Zabezpieczanie tabel baz danych

Do zabezpieczenia baz danych na poziomie tabel można wykorzystać polecenie GRANT serwera Microsoft SQL Server 2005, by przydzielić kontu dzierżawcy dostęp do tabeli lub innego obiektu bazy danych:

GRANT SELECT, UPDATE, INSERT, DELETE ON [NazwaTabeli] FOR [NazwaUżytkownika]

Polecenie to dodaje dane konto użytkownika do listy ACL tabeli. Przy zastosowaniu omówionego wcześniej hybrydowego podejścia do dostępu do bazy danych, w którym użytkownicy końcowi są związani z kontekstami bezpieczeństwa swoich dzierżawców, wystarczy zrobić to raz, podczas procesu konfiguracji dzierżawcy. Wszystkie konta użytkowników końcowych utworzone przez dzierżawcę będą miały dostęp do tabeli.

Wzorzec taki nadaje się do zastosowania zarówno w podejściach wykorzystujących oddzielne bazy danych, jak i oddzielne schematy. W przypadku z odrębnymi bazami danych dane można odizolować, ograniczając po prostu dostęp na poziomie bazy danych do związanego z daną bazą danych dzierżawcy, choć można również użyć tego wzorca na poziomie tabel, by stworzyć dodatkową warstwę zabezpieczeń.

 Do początku strony

Filtry widoków dzierżawców

Widoki pozwalają przydzielić poszczególnym dzierżawcom prawo dostępu do wybranych wierszy danej tabeli przy równoczesnym uniemożliwieniu dostępu do pozostałych wierszy.

W SQL Server widok to wirtualna tabela definiowana przez wyniki kwerendy SELECT.

Wynikowy widok może stanowić punkt wyjścia dla kolejnych kwerend i być używany w procedurach składowanych, tak jakby był rzeczywistą tabelą bazy danych.

Na przykład:

Następujące wyrażenie w SQL Server tworzy widok tabeli o nazwie Pracownicy, który został tak przefiltrowany, by widoczne były jedynie wiersze należące do pojedynczego dzierżawcy:

CREATE VIEW PracownicyDzierżawcy AS

SELECT * FROM Pracownicy WHERE IDDzierżawcy= SUSER_SID()

Wyrażenie pobiera identyfikator bezpieczeństwa (SID) użytkownika uzyskującego dostęp do bazy danych, czyli, jak pamiętamy, jest konto dzierżawcy, nie użytkownika końcowego, i używa go do określenia wierszy, które powinny znaleźć się w widoku. (Przykład zakłada, że unikatowy identyfikator dzierżawcy jest taki sam, jak jego SID. W innym przypadku potrzebne byłoby przeprowadzenie kilku dodatkowych operacji, by przypisać odpowiednie wiersze do dzierżawców). Wszystkie konta dostępu do danych dzierżawcy będą miały dostęp do widoku PracownicyDzierżawcy, ale bez możliwości dostępu do samej tabeli Pracownicy. Konstruując kwerendy i procedury współdzielone z użyciem widoków, można uzyskać wrażenie izolacji danych poszczególnych dzierżawców, nawet w przypadku wieloużytkownikowych baz danych.

Wzorzec ten jest nieco bardziej skomplikowany niż zabezpieczanie tabel baz danych, ale jest to właściwy sposób zabezpieczania danych dzierżawcy w bazach danych o współdzielonym schemacie, w którym wielu dzierżawców korzysta z tego samego zestawu tabel.

 Do początku strony

Szyfrowanie danych dzierżawcy

Sposobem na dalsze zabezpieczenie danych dzierżawcy jest ich zaszyfrowanie wewnątrz bazy danych, w taki sposób, by dane pozostały bezpieczne, nawet jeśli znajdą się w niepowołanych rękach.

Metody kryptograficzne można podzielić na symetryczne i asymetryczne. W kryptografii symetrycznej wygenerowany klucz jest używany do szyfrowania i deszyfrowania danych. Dane zaszyfrowane przy użyciu klucza symetrycznego mogą zostać odszyfrowane przy użyciu tego samego klucza.

W kryptografii asymetrycznej (nazywanej również kryptografią klucza publicznego) używane są dwa klucze: klucz publiczny i kluczem prywatny. Dane zaszyfrowane przy użyciu danego klucza publicznego mogą być odszyfrowane tylko przy użyciu odpowiedniego klucza prywatnego i vice versa.

Klucze publiczne są zazwyczaj udostępniane wszystkim zainteresowanym komunikacją z właścicielem klucza, zaś klucze prywatne są przechowywane w bezpiecznym miejscu. Jeśli na przykład Alicja chce wysłać zaszyfrowaną wiadomość do Boba, pobiera w uzgodniony wcześniej sposób klucz publiczny Boba i używa go do zaszyfrowania wiadomości. Uzyskany w ten sposób zaszyfrowany komunikat może zostać odszyfrowany tylko przez osobę posiadającą prywatny klucz Boba (w praktyce powinien to być jedynie Bob). W ten sposób Bob nigdy nie musi udostępniać swojego prywatnego klucza Alicji. Aby wysłać wiadomość do Boba przy użyciu szyfrowania symetrycznego, Alicja musiałaby przesłać klucz symetryczny oddzielnie – z czym wiąże się ryzyko jego przechwycenia podczas transmisji przez osoby trzecie.

Kryptografia klucza publicznego wymaga znacznie większej siły obliczeniowej niż kryptografia symetryczna. Para silnych kluczy może wymagać setek albo nawet tysięcy razy więcej czasu do zaszyfrowania i odszyfrowania danych w porównaniu do klucza symetrycznego o zbliżonej jakości. W przypadku aplikacji hostowanych, w których każdy element przechowywanych danych jest zaszyfrowany, związany z szyfrowaniem narzut operacji obliczeniowych może spowodować, że kryptografia klucza publicznego okaże się niepraktyczna jako całościowe rozwiązanie. Lepszym rozwiązaniem jest użycie systemu opakowywania klucza, który łączy zalety obu systemów.

Przy zastosowaniu tego podejścia dla każdego dzierżawcy tworzone są trzy klucze: klucz symetryczny i para kluczy asymetrycznych składająca się z klucza publicznego i klucza prywatnego. Wydajniejszy, klucz symetryczny, jest używany do szyfrowania przechowywanych ważnych danych dzierżawcy. Aby wprowadzić kolejną warstwę zabezpieczeń, klucz symetryczny jest szyfrowany i odszyfrowywany przy użyciu kluczy asymetrycznych, co zabezpiecza go przed potencjalnymi intruzami.

Gdy użytkownik końcowy loguje się, aplikacja korzysta z impersonacji, by uzyskać dostęp do bazy danych przy użyciu kontekstu bezpieczeństwa dzierżawcy, co daje procesowi aplikacji dostęp do klucza prywatnego dzierżawcy. Aplikacja (wciąż korzystająca z tożsamości dzierżawcy) może wtedy użyć klucza prywatnego dzierżawcy do odszyfrowania klucza symetrycznego dzierżawcy i zastosowania go do odczytu i zapisu danych.

To kolejny przykład zastosowania zasady głęboko urzutowanej obrony. Przypadkowe lub złośliwe udostępnienie danych dzierżawcy innym dzierżawcom – scenariusz dla każdego świadomego znaczenia bezpieczeństwa danych usługodawcy rodem z koszmaru – jest uniemożliwiane na wielu poziomach. Pierwsza linia obrony, na poziomie bazy danych, zapobiega dostępowi użytkowników końcowych do prywatnych danych pozostałych dzierżawców. Jeśli wirus lub błąd w serwerze baz danych spowodowałby przekazanie dzierżawcy niewłaściwego wiersza danych, zaszyfrowana zawartość byłaby bezużyteczna bez dostępu do prywatnego klucza dzierżawcy.

Znaczenie szyfrowania jest tym większe, im bardziej aplikacja jest współdzielona, a mniej izolowana. Szyfrowanie jest szczególnie ważne w sytuacjach, gdy dane mają wysoką wartość lub ważna jest ich prywatność, lub gdy wielu dzierżawców współdzieli ten sam zestaw tabel bazy danych.

Ponieważ zaszyfrowanych kolumn nie można indeksować, wybór kolumn i tabel, które mają zostać zaszyfrowane wiąże się z kompromisem pomiędzy bezpieczeństwem danych a wydajnością. Podejmując decyzję o szyfrowaniu, należy zastanowić się nad przeznaczeniem i stopniem poufności poszczególnych rodzajów danych w stosowanym modelu danych.

 Do początku strony

Podsumowanie

Zaprojektowanie hostowanej architektury danych, która godzi sprzeczne korzyści i wymagania udostępniania i izolacji nie jest zadaniem trywialnym, a omówione wzorce powinny pomóc w identyfikacji krytycznych zagadnień przed którymi stają twórcy. Mam nadzieję, że pomogą w stworzeniu podwalin zaufania, tak istotnego dla sukcesu modelu aplikacji hostowanych.

Do początku strony