Bezpieczeństwo aplikacji tworzonych w Windows Azure  Udostępnij na: Facebook

  • Artykuł

Autor: Tomasz Kopacz

Opublikowano: 2012-01-13

Bezpieczna aplikacja?

Budowa bezpiecznej aplikacji to nie tylko technologia i infrastruktura. To także właściwa architektura, dobre praktyki, analiza ryzyka (i określenie sposobów przeciwdziałania nieoczekiwanym sytuacjom), właściwy proces wytwarzania oprogramowania i szkolenia członków zespołu.

W przypadku rozwiązań, wykorzystujących chmurę publiczną, odpowiedzialność za część z tych elementów spoczywa na dostawcy chmury, a część – na twórcy aplikacji.

Przed dalszymi rozważaniami, warto przyjrzeć się podstawowym elementom składniowym, tzw. „security frame”, czyli składnikom, które mają wpływ na postrzeganie bezpieczeństwa aplikacji. Tak naprawdę stanowią one tzw. „profil bezpieczeństwa” i są elementami, na które należy zwrócić szczególną uwagę, chcąc budować bezpieczne i godne zaufania systemy informatyczne. Są to:

  • walidacja wejścia,
  • uwierzytelnianie,
  • autoryzacja,
  • komunikacja,
  • zarządzanie konfiguracją,
  • zarządzanie sesją,
  • kryptografia,
  • „cenne” i poufne informacje,
  • zarządzanie wyjątkami,
  • audyt i logowanie.

Ponieważ z punktu widzenia programisty, API Windows Azure to rozszerzenie funkcjonalności, jakie oferuje „normalny” Windows Serwer, duża część tych elementów może być realizowana tak samo jak na klasycznym Windows (czy ASP.NET). Na przykład, do zabezpieczenia przed nieprawidłowymi żądaniami, można wykorzystać wbudowane walidatory w ASP.NET czy ASP.NET MVC. Dodatkowo, potok żądań automatycznie odrzuca komunikaty POST, zawierające potencjalnie niebezpieczne frazy itp. Można również w odpowiedni sposób skonfigurować serwer IIS – tak samo jak w przypadku systemów „on-premises”.

Budując architekturę rozwiązania, zwykle wybiera się ogólne ramy, które określają, w jaki sposób należy myśleć o bezpieczeństwie. Najpopularniejsze są dwa podejścia: C.I.A oraz AAA.

C (confidentiality).I(integrity).A(availability) to podejście, w którym należy zapobiec nieuprawnionemu odczytowi danych, zapewnieniu integralności (czyli, że zabezpieczysz informacje przed uszkodzeniem, czy naruszeniem spójności), a także, że osoba uprawniona będzie w stanie uzyskać dostęp w rozsądnym czasie, gdy będzie go potrzebować (w tym także podczas ewentualnego ataku). Zwykle C.I.A tworzy wierzchołki trójkąta, a budując aplikację stara się wyważyć tworzone składniki tak, by te trzy elementy pozostały w równowadze.

 W przypadku podejścia AAA (Authentication, Access control, Auditing/Accounting), tworząc kod i architekturę, należy skupić się na identyfikacji (uwierzytelnianiu), kontroli dostępu oraz audycie (rejestrowaniu) operacji wykonywanych w systemie (w tym operacji na danych).

Składniki Windows Azure i bezpieczeństwo

Windows Azure to publiczna platforma cloud computing, która jest przeznaczona dla twórców aplikacji. Należy do kategorii „platform as a sevices”, czyli udostępnia twórcy specjalne API i usługi, pozwalające budować aplikacje, które są wysoce skalowane. Microsoft zajmuje się utrzymaniem infrastruktury, bazowych usług i bezpieczeństwem platformy, a do twórcy rozwiązania należy zapewnienie bezbłędnego działania i bezpieczeństwo tworzonej aplikacji oraz informacji przetwarzanych w ramach chmury – oczywiście, wykorzystując cechy oferowane przez Azure. Należy pamiętać, że żadne zabezpieczenie nie będzie skuteczne, jeżeli programista udostępni stronę, przez którą (czy to w wyniku błędu typu SQL Injection, czy inaczej) da się pobrać chronione dane.

Platforma Windows Azure składa się z kilku podstawowych składników (tutaj omawiane są tylko te najbardziej istotne z punktu widzenia bezpieczeństwa):

Azure Compute to jednostki obliczeniowe (instancje) w chmurze. Mogą one pełnić wiele różnych funkcji – od serwera WWW (tzw. Web Role) po uniwersalny pojemnik na procesy (tzw. Worker Role). Programista przygotowuje aplikację w postaci specjalnego pakietu, który przekazuje (zwykle – używając albo narzędzia Visual Studio albo portalu Azure) do chmury, która zgodnie z podaną konfiguracją instaluje go automatycznie w danej jednostce. W chmurze działa specjalna wersja Windows Server (2008 lub 2008 R2), na której działają tworzone aplikacje. Za zarządzanie jednostkami odpowiada komponent Azure Fabric. Technicznie, programista tworzy projekt, składający się z jednej lub większej ilości ról. Instancja to działająca jedna (lub większa ilość) kopia kodu roli. Skalowanie aplikacji w Azure polega na tym, że dobierana jest liczba instancji do założonego (lub zmierzonego) obciążenia, a load balancer (część chmury) rozkłada ruch pomiędzy instancje. Oczywiście liczbę instancji można zmieniać w razie potrzeby, bez przerywania działania całego systemu.

Technicznie, Azure Fabric Controller (FC) można porównać do kernela systemu operacyjnego. Odpowiada on za alokację zasobów, zarządza sprzętem w datacenter i obsługuje cykl życia serwisu, który działa w Windows Azure. FC to rozproszona, stanowa aplikacja, działająca na wszystkich węzłach we wszystkich datacenter.

Aby zrozumieć działanie i zabezpieczenia wewnątrz Windows Azure, należy prześledzić, w jaki sposób nowy węzeł jest inicjowany wewnątrz Azure i jak wgrywany jest pakiet. Po włączeniu serwera, mechanizmem PXE wgrywany jest tzw. „Maintance OS”, który sprawdza, czy nie ma uszkodzenia sprzętowego, po czym pobiera Host OS. Host OS startuje, uruchamia polecenie sysprep/specialize i restartuje się. Następnie Fabric Controller podłącza się do Host Agent – jego głównym zadaniem jest analiza poprawnego funkcjonowania całej instalacji. Na zainicjowany węzeł (tak naprawdę FC utrzymuje pulę zainicjowanych i gotowych do użycia węzłów) można wgrać pakiet.

Pakiet z serwisem (aplikacją WWW itp.) jest przekazywany za pośrednictwem portalu Azure (lub API) do komponentu Red Dog Front End, który analizuje jego poprawność i spójność, po czym przekształca w format wewnętrzny używany przez Azure Fabric (nazwa kodowa Red Dog), gdzie pakiet jest zapisywany. Wgranie pakietu (instancji) na węzeł składa się z następujących operacji:

  • Fabric Controller umieszcza pliki roli (wraz z plikiem konfiguracyjnym) na wybranym węźle (czyli wysyła go do właściwego Host Agenta).
  • Host Agent tworzy trzy pliki VHD: przyrostowy dla dysku z systemem operacyjnym (zwykle litera D:\), tymczasowy, przeznaczony na pliki zasobów (zwykle C:\), plik VHD, zawierający pliki roli (wypakowane z pakietu – zwykle litera E: ).
  • Host Agent tworzy maszynę wirtualną (Azure Guest OS w danej wersji), podłącza do niej dyski, po czym startuje VM.
  • Guest Agent (wgrany razem z rolą) rejestruje się w Host Agent i na żądanie zwraca informacje o swoim stanie.

W przypadku, gdy aktualizowany jest system operacyjny (lub – aktualizowany pakiet) proces jest powtarzany (to znaczy ponownie inicjowana jest nowa instancja). Wykorzystywane są wtedy tzw. „update domains”, które narzucają takie rozproszenie elementów, by można było je niezależnie aktualizować, zapewniając równocześnie ciągłość działania całego serwisu.

Aby uniknąć niedostępności serwisu, wynikającego z uszkodzenia sprzętu, gdy wdrożonych jest więcej niż jedna instancja danej roli, są one rozpraszane po wielu tzw. „fault domain” – czyli niezależnych sprzętowo jednostkach, których równoczesne uszkodzenie jest bardzo mało prawdopodobne. Dzięki temu, usługi Azure Compute, są dostępne z SLA co najmniej 99.95%. Podobny mechanizm służy do zapewnienia niezawodności innym usługom dla programisty, działającym na Azure – w tym np. Service Bus, SQL Azure, Azure Storage i innych.

Agenci w Windows Azure komunikują się w specyficzny sposób. Guest Agent nie nawiązuje połączenia z Host Agent, ale to Host Agent okresowo, odpytuje lokalnie zainstalowanego agenta i pobiera status. Podobnie jest w przypadku komunikacji pomiędzy samym Azure Fabric a Host Agent. Instancje ról w jednym pakiecie Windows Azure, poza tym, że mogą udostępniać usługi publicznie w Internecie, mogą także komunikować się bezpośrednio (wykorzystując tzw. Internal Endpoint). Aby zapewnić bezpieczny kanał komunikacyjny wewnątrz datacenter, w momencie uruchomienia pakietu dla wszystkich instancji budowana jest sieć VLAN (oparta o dynamicznie generowane certyfikaty prywatne dla danego wdrożenia). Dodatkowo stosowane jest filtrowanie pakietów i oczywiście cała komunikacja jest na kilku poziomach szyfrowana. Oprócz tego (zgodnie z metodologią SDL) w specjalny sposób weryfikowane są wszystkie informacje, przekazywane od komponentów mniej zaufanych. Wszystkie usługi systemowe w Windows Azure działają z najmniejszym niezbędnym zestawem uprawnień. Składając te elementy razem, można być pewnym, że nie jest możliwe, by aplikacja (pakiet) uzyskała dostęp do komunikacji sieciowej innych instancji. Oprócz tego, Hypervisor zapewnia całkowity poziom izolacji jednostek obliczeniowych. Dodatkowo wdrażane są mechanizmy, zabezpieczające przed tzw. atakiem sidechannel, w którym wykorzystywane są różne opóźnienia, wynikające z pamięci podręcznej; warto przeczytać tu dokument Microsoft Research – https://research.microsoft.com/apps/pubs/?id=64367. Opisuje on, jak takie zabezpieczenie jest zrealizowane (i jak taki atak może wyglądać).

Za utrzymanie datacenter Windows Azure odpowiada organizacja GFS (Global Foundation Services). Na jej stronach (https://www.globalfoundationservices.com/ ) można znaleźć odsyłacze do uzyskanych certyfikatów dla infrastruktury i usług (w tym – ISO 27001:2005, SAS 70 type I i II). Warto dodać, że w większości przypadków certyfikaty branżowe przyznawane są aplikacjom działającym na Windows Azure.

Drugim ważnym komponentem Windows Azure jest Azure Storage – pojemniki na dane. Są to Azure Blob (do przechowywania dużych danych binarnych) oraz Azure Table (do przechowywania miliardów wierszy (encji). Dostępna jest także Azure Queue – kolejka, używana głównie jako mechanizm zapewniający skalowalność rozwiązania. API do Azure Storage oparte jest na koncepcji REST. Żądanie musi być podpisane za pomocą klucza. Dane zapisane w Azure Storage są szyfrowane na kilku poziomach. Oczywiście aplikacja może także zaszyfrować je na własny sposób. Dane przechowywane są w co najmniej 3 kopiach, co gwarantuje dostępność informacji nawet w przypadku częściowego uszkodzenia.

Rys. 1. Podstawowe komponenty Windows Azure.

W przypadku wykonania operacji usuwania danych, informacje stają się niedostępne za pośrednictwem Storage REST API i są zamazywane. Dodatkowo, na koniec cyklu życia dysku twardego jest on niszczony (zgodnie z procedurami).

Innym komponentem, który służy do przechowywania danych jest SQL Azure. To baza relacyjna, w dużym stopniu zgodna z SQL Server, dostępna jako usługa. Z technicznego punktu widzenia oferuje podobne mechanizmy, związane z bezpieczeństwem, co SQL Server. Do uwierzytelniania używane jest logowanie SQL. Zidentyfikowanemu użytkownikowi można nadawać określone uprawnienia do obiektów czy wykonywania operacji. Do komunikacji pomiędzy klientem a bazą SQL Azure używany jest protokół TDS, co pozwala stosować normalne biblioteki dostępu do danych – ADO.NET, ODBC czy Entity Framework). Dodatkowo SQL Azure wymusza, by komunikacja TDS była szyfrowana. Do dyspozycji programisty jest także firewall, który może blokować dostęp do serwera (na podstawie zakresu adresów IP; można też ograniczać dostęp z poziomu kodu działającego w Azure Compute).

Dwa komponenty – Azure Service Bus i Azure Connect – zapewnia dodatkowe mechanizmy komunikacyjne, tworzące bezpieczny kanał pomiędzy Azure a zewnętrznymi systemami. Azure Connect pozwala zestawić bezpieczny kanał VPN, używając IPv6. W ten sposób można dołączyć się do konkretnych instancji w Azure z serwera uruchomionego lokalnie (i np. używać autoryzacji domenowej w portalu Web, uruchamianym w chmurze).

Azure Service Bus to w pewnym sensie „dzierżawiony” firewall. Jest to usługa, działająca w chmurze, w której można rejestrować i udostępniać własne usługi. Klient nie komunikuje się bezpośrednio ze źródłowym serwerem, a tylko z końcówką wystawioną w Service Bus (stanowiącą de facto serwer proxy).

Za pośrednictwem Service Bus można zarządzać uprawnieniami. Do dyspozycji programisty są także bardziej zaawansowane mechanizmy – jak na przykład kolejki, pozwalające rozładować nadmierny ruch, który normalnie zablokowałby udostępniany serwis.

Za zarządzanie uprawnieniami odpowiada Azure Access Control. Jest to usługa, która bazując na standardach (SAML 1.1 i 2.0, SWT, WS-Federation itp.) agreguje informacje o sposobach uwierzytelniania (i potem – razem z Service Bus lub z konfiguracją ról) uprawnień użytkownika. Obsługiwani są następujący dostawcy tożsamości: Windows Live ID, Google ID, Yahoo, Facebook, dostawca zgodny z WS-Federation (w tym – Microsoft AD FS 2.0). Do obsługi tokena po stronie aplikacji klienckiej, może być używana na przykład biblioteka Windows Identity Foundation.

Obiekt Sposób uwierzytelnienia
Subskrypcja Windows Live ID
Windows Azure Portal Windows Live ID
Service Management API Certyfikat X.509 (może być tzw. „self-signed”)
Azure Storage Klucz (shared key)
SQL Azure Klient TDS (ADO.NET, Entity Framework) – SQL login (szyfrowany)
Do REST API – certyfikat
Azure Service Bus

Do zarządzania: Windows Live ID

Operacyjne / API: klucz symetryczny, hasło, certyfikat X.509
Azure Access Control Do zarządzania: Windows Live ID

Tabela 1. Sposób zabezpieczenia podstawowych elementów w Windows Azure z punktu widzenia dostępu developerskiego.

Należy podkreślić, że w przypadku Windows Azure bezwzględnie należy pilnować konta dostępowego (Live ID) do subskrypcji, ponieważ właściciel konta jest administratorem subskrypcji i w szczególnym przypadku może np. skasować bazę czy skontaktować się z suportem, by zamknąć subskrypcję. Z tego powodu należy pamiętać, by mieć oddzielne konto, z odpowiednio skomplikowanym hasłem dostępowym, a na co dzień, do celów developerskich używać certyfikatów X.509 (tak naprawdę członkom zespołu nie jest potrzebne konto Live ID do codziennej pracy). Dodatkowo, bezwzględnie (jak przy normalnych projektach), należy oddzielać subskrypcje testowe/developerskie i subskrypcje produkcyjne, do których mają dostęp tylko członkowie suportu / działu zajmującego się jakością.

Dostępność

Jednym z ważniejszych elementów, niezbędnych w bezpiecznej aplikacji, jest dostępność – niezależnie od aktualnego obciążenia (czy np. ataków typu (D)DoS). W przypadku Azure, posługując się prostymi schematami, można zbudować aplikację, odporną na tego problemy – patrz Rys. 2. Założenie jest takie, że kod Web Role otrzymuje żądanie, wkłada polecenie do kolejki, a kod w Worker Role wykonuje kolejno polecenia wyjmowane z kolejki. W razie potrzeby, wystarczy zwiększać liczbę instancji, realizujących zadania Web czy Worker Role, by móc reagować na zwiększające się obciążenie.

Rys. 2. Architektura zapewniająca wysoką dostępność aplikacji, działających na Windows Azure.

Do zapewnienia wysokiej dostępności, można także wykorzystać mechanizmy Service Bus. Jednym z komponentów tego rozwiązania jest mechanizm kolejkowy, który może być pośrednikiem pomiędzy klientem a usługą.

Azure oferuje także Azure Traffic Manager, który potrafi dodatkowo dystrybuować ruch pomiędzy geograficznie rozproszonymi rolami. Obecnie dostępnych jest 6 regionów geograficznych w Europie, Azji i Ameryce Północnej. Warto tu wspomnieć, że sam Azure ma usługi, zabezpieczające przed atakami (D)DOS – chociażby dławik czy składniki wbudowane w Windows Server mechanizm „anty” SYN-Attack.

W dalszej części artykułu zostaną opisane wybrane zagadnienia związane z budową aplikacji. Możliwym sposobom rozwiązania ich jest wykorzystanie składników Windows Azure.

Wybrany przypadek – sesja i stan

Każda z instancji, działających w ramach roli, jest niezależna – to znaczy ma własne dyski, własną pamięć/procesor itp. Load Balancer rozkłada ruch pomiędzy instancjami. Jeżeli aplikacja chce zapisać stan, musi użyć zewnętrznego pojemnika. Aby obsłużyć sesję w aplikacji Windows Azure, programista może użyć :

  • ASP.NET Universal Providers (które mogą zapisać stan sesji w SQL Azure). Dostępne są jako pakiety NuGet.
  • Azure Cache, współdzielona pamięć, dostępna za pośrednictwem specjalnego API, w której można umieścić sesję. Jest to najszybszy (i wspierany) sposób tworzenia sesji.

Wybrany przypadek – uwierzytelnianie

W przypadku chmury, do uwierzytelniania można wykorzystać mechanizm Membership Provider z ASP.NET. Jednak – ponieważ standardowi dostawcy ASP.NET nie działają w środowisku chmury, trzeba użyć wspomnianych ASP.NET Universal Providers. Dostępny jest też przykład implementacji dostawcy Membership, wykorzystujący Azure Table.

Często spotykanym scenariuszem jest sytuacja, gdy rozwiązanie działające w chmurze jest rozszerzeniem systemu działającego lokalnie, albo – z uwagi na polityki bezpieczeństwa – wymagane jest, by w organizacji istniał jeden, centralny system autoryzacyjny i zarządzający uprawnieniami.

W takim scenariuszu używany jest tzw. Security Token Services, który po uwierzytelnieniu użytkownika wystawia stosowny token, traktowany (dzięki relacji zaufania) przez Web Role jako prawidłowa tożsamość.

Rys. 3. Przykładowa architektura systemu, w którym za potwierdzenie tożsamości odposwiada usługa Active Directory, zainstalowana on-premise, lokalnie.

Często, zamiast lokalnie udostępnionego ADFS2, wykorzystywany jest jakiś provider obsługiwany przez Azure Access Control Services. Wtedy aplikacja w ogóle nie ma kodu odpowiedzialnego za uwierzytelnianie – tylko ufa tokenom, wystawionym przez ACS. W kodzie .NET, na podstawie takich tokenów, budowane są standardowe mechanizmy Principal/Identity/Role itp. – tak więc z poziomu sprawdzania uprawnień w aplikacji niewiele się zmienia.

Wybrany przypadek – certyfikaty

W przypadku certyfikatów, jeżeli umieścisz je w pakiecie, ryzykujesz, że w wyniku swojej pomyłki, w jakiś sposób pozwolisz atakującemu odczytać klucz prywatny (używany np. do szyfrowania komunikacji TLS/SSL). Aby temu zapobiec, w Windows Azure stosowany jest zupełnie oddzielny mechanizm zarządzania certyfikatami. Certyfikaty wgrywane są za pośrednictwem portalu i umieszczane w bezpiecznym pojemniku w Azure Fabric. Z poziomu aplikacji (i pakietu), wskaż tylko konkretny certyfikat, który ma być użyty (i który dostarczany jest do danej aplikacji). Oczywiście dostępne jest także API, pozwalające skorzystać z takiego certyfikatu

Rys. 4. Zarządzanie certyfikatami w Windows Azure i Visual Studio.

Wybrany przypadek – dostęp do Azure Storage

W przypadku, gdy aplikacja w chmurze korzysta z Azure Storage, może wykorzystywać standardowy klucz, używany do podpisywania żądań API. Jednak w przypadku, gdy zewnętrzna usługa (czy bogaty klient) chce skorzystać z Azure Storage, nie może mieć dostępu do klucza. W takim scenariuszu zwykle udostępniane są specjalistyczne usługi, odczytujące poszczególne encje z tabeli. Dobre rozwiązanie zastosowano w przypadku Windows Azure Toolkit for Windows Phone (https://watwp.codeplex.com/).

Usługi są skonstruowane tak, że z punktu widzenia aplikacji na urządzeniu przenośnym, Azure Storage jest po prostu pojemnikiem (tabelą), w którym (w której) można zapisywać informacje.

Rys. 5. Dostęp do Azure Storage z poziomu aplikacji, działającej na Windows Phone.

Szczególnym przypadkiem jest Azure Blob. Ponieważ w tym pojemniku przechowywane są duże elementy, budowanie pośrednika nie ma sensu. Zwykle, serwis na Azure przekazuje do klienta URL, z tzw. Shared Access Signature, określającą krótkotrwałe uprawnienia do danego kontenera czy bloba. Warto się przyjrzeć, jak taki mechanizm może być wykorzystany na krótkim przykładzie.

Najpierw tworzone jest połączenie do Azure Storage, klient do Blob i referencja do pojemnika (w którym umieszczamy przykładowy obraz).

StorageCredentialsAccountAndKey ak = […]
CloudStorageAccount csa = new CloudStorageAccount(ak, true);
CloudBlobClient cbc = csa.CreateCloudBlobClient();
CloudBlobContainer cb = cbc.GetContainerReference("mts2011");
//Shared Access Signature – do odczytu
CloudBlockBlob cbPrivate = cb.GetBlockBlobReference("MyPrivateImage.jpg");
cbPrivate.DeleteIfExists();
cbPrivate.UploadFile("gilgil.jpg");

Następnie definiujemy SharedAccessPolicy. Definiuje się w nim:

  • SharedAccessStartTime – od kiedy polityka obowiązuje; może być to czas w przyszłości.
  • SharedAccessExpiryTime – jak długo obowiązuje dana polityka; musi być większe od SharedAccessStartTime.
  • Permissions – określa przyznawane uprawnienia. Może to być kombinacja wartości: Delete (kasowanie), List (listowanie obiektów w kontenerze), Read (odczyt), Write (zapis).
SharedAccessPolicy sap = new SharedAccessPolicy();
sap.Permissions = SharedAccessPermissions.Read;
sap.SharedAccessStartTime = DateTime.Now;
sap.SharedAccessExpiryTime = sap.SharedAccessStartTime.Value.AddMinutes(10);

Następnie przypisujemy zdefiniowaną politykę do pojemnika (Blob Container), albo do konkretnego bloba (jak w tym przypadku). Polecenie GetSharedAccessSignature zwraca fragment, który należy dokleić do URI, tak by wykorzystać daną politykę.

string sapString = cbPrivate.GetSharedAccessSignature(sap);

Ponieważ dany blob jest prywatny (to znaczy nie jest dostępny bez użycia mechanizmu autoryzacyjnego, opartego o współdzielony klucz, to poniższy URL nie pozwala na bezpośredni dostęp do bloba.

string urlPrivate = cbPrivate.Uri.ToString(); //Brak dostępu

Jednak jeżeli  dokleimy fragment do URL, wygenerowany przy użyciu GetSharedAccessSignature, to (w tej sytuacji) obrazek będzie dostępny np. w przypadku użycia znacznika IMG na stronie HTML.

string urlPublic = string.Format("{0}{1}", cbPrivate.Uri, sapString); //Można odczytać

Warto dodać, że operacje zapisu do bloba wymagają użycia standardowych operacji PUT, tyle że do URL (tak, jak w przypadku powyższego fragmentu kodu) należy dokleić fragment generowany przez funkcję GetSharedAccessSignature().

Dodatkowo, jest dostępne specjalne API, pozwalające utworzyć proxy klienckie dla Windows Azure Blob na podstawie SharedAccessSignature. Można wywołać:

CloudBlobClient cbcSap = new CloudBlobClient("https://tkdpefpstorage.blob.core.windows.net",
new StorageCredentialsSharedAccessSignature(sapString));

Następnie można normalnie pobrać referencję do obiektu (tu – do bloba), po czym wykonać operację (tu – wgranie nowego obrazu):

CloudBlockBlob cbbSap = cbcSap.GetBlockBlobReference("mts2011/gilgil.jpg");
cbbSap.UploadFile("OsobistyTransportLotniczy.jpg");

Proces i zespół

Oprócz właściwej architektury i użytych mechanizmów, bezpieczna aplikacja wymaga także odpowiedniego procesu wytwórczego, by w odpowiedni sposób skonstruować zespół.

Microsoft Security Development Lifecycle to rozszerzenia metodyk, takich jak MSF czy SCRUM, o artefakty związane z bezpieczeństwem. Metodyka powstała w Microsoft w latach poprzedzających wprowadzenie SQL 2005, Windows Vista itp. Obecnie dostępne są także gotowe wzorce dla Team Foundation Server, pozwalające prowadzić projekty, zgodnie z takim podejściem.

Wśród głównych elementów, jakie przynosi SDL, warto wymienić:

  • Okresowe OBOWIĄZKOWE szkolenia z bezpieczeństwa dla WSZYSTKICH zaangażowanych w proces tworzenia aplikacji. W ramach takich szkoleń powstają (lub są adoptowane) także najlepsze praktyki; część z nich może być też wymuszona w narzędziu (np. w Visual Studio reguły FxCop, metryki kodu itp.).
  • Zdefiniowanie (i stosowanie) metryk bezpieczeństwa dla zespołów projektowych.
  • „Doradca bezpieczeństwa” dla KAŻDEGO komponentu. On odpowiada za to, czy wszystkie metryki związane z bezpieczeństwem mają właściwą wartość. Techniczne – jest władny opóźnić udostępnienie komponentu. Zwykle, chcąc zapewnić wysoki poziom bezpieczeństwa, warto, by taka osoba nie podlegała bezpośrednio kierownikowi, odpowiadającemu za dany składnik – tylko należała do innego działu. Dzięki temu unika się nacisków, by na pewne elementy „przymknąć” oko.
  • Modelowanie zagrożeń jako część procesu projektowego (zgodnie z STRIDE (identyfikacja zagrożeń)/DREAD (kwantyfikacja ryzyk)).
  • Przeglądy bezpieczeństwa i testowanie przewidziane w harmonogramie projekcie. Dodatkowo, w ramach iteracji wydzielony jest okres czasu, w którym odbywa się tylko testowanie bezpieczeństwa.
  • Pod koniec iteracji/pewnego cyklu w projekcie następuje faza weryfikacji (Security Push), gdzie zgodnie z ustalonymi miarami odbywają się tylko testy, związane z bezpieczeństwem, także wykonywane przez zewnętrznych specjalistów. Przez ten etap można przejść tylko wtedy, gdy nie zostanie znaleziony żaden błąd związany z security.
  • W ramach budżetu projektu określana jest grupa SRT (Security Response Team), która odpowiada za reagowanie na problemy związane z bezpieczeństwem po udostępnieniu komponentu na rynku (lub innemu zespołowi w przypadku dużych projektów).

Więcej o procesie SDL można znaleźć pod adresem Microsoft Security Development Lifecycle (SDL) – Process Guidance (https://msdn.microsoft.com/en-us/library/windows/desktop/cc307891.aspx ). Oczywiście – nie da się zapewnić procesu, który zagwarantuje, że aplikacja będzie bezpieczna, ale dzięki SDL da się powiedzieć, jaki jest postęp prac i w miarę dokładnie oszacować ryzyko.

Materiały dodatkowe: