feed.xml

<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
    <title>Smerek.Blog</title>
    <link href="https://smerek.blog/feed.xml" rel="self" />
    <link href="https://smerek.blog" />
    <updated>2022-03-21T11:07:48+01:00</updated>
    <author>
        <name>Michał Smereczyński</name>
    </author>
    <id>https://smerek.blog</id>

    <entry>
        <title>Chmura w końcu potrzebna!</title>
        <author>
            <name>Michał Smereczyński</name>
        </author>
        <link href="https://smerek.blog/chmura-w-koncu-potrzebna/"/>
        <id>https://smerek.blog/chmura-w-koncu-potrzebna/</id>
            <category term="Security"/>
            <category term="Data"/>
            <category term="Azure"/>

        <updated>2022-03-21T11:07:48+01:00</updated>
            <summary>
                <![CDATA[
                    <p>Aktualna sytuacja geopolityczna, a konkretnie mówiąc wojna, sprawiła, że jedna z cech chmury publicznej, która do 24.02.2022 roku była uważana za jeden z głównych minusów, właśnie zaczęła być rozpatrywana przez firmy i instytucje jako najlepsza opcja zabezpieczenia. Nie chodzi tu o migrację serwerów/systemów/aplikacji do chmury - na to potrzeba względnie dużo czasu (ocena wynika z doświadczenia). Chodzi o zabezpieczenie danych strategicznych - czymkolwiek nie są dla firmy czy instytucji. Mogą to być dane handlowe, analityczne, matematyczne, geosejsmiczne, kosmiczne. Mogą to być dane historyczne, ale i dane kreujące przyszłość firmy (lub jedno i drugie, rzecz jasna). Różne mogą być też wolumeny tych danych (od kilobajtów do petabajtów) i dynamika ich zmian (od tych, które zmieniają się codziennie, do tych które zmieniają się kwartalnie czy rocznie). Łączy je jedna cecha - jeśli zostaną utracone lub przejęte (a ten scenariusz może być często gorszy niż utrata) to daleko idące problemy mogą być nie tylko personalne czy biznesowe ale mogą dotykać całych gałęzi gospodarki, a nawet wpływać na losy państwa.<br>Przez zabezpieczenie danych mam na myśli zmianę rezydencji tych danych (oryginałów lub kopii) z lokalnej infrastruktury (to znaczy umiejscowionej w Polsce, w siedzibie firmy lub współdzielonym centrum danych) na lokalizacje oddalone na tyle, aby lokalna sytuacja geopolityczna nie wpływała na ich bezpieczeństwo. Oczywiście istnieje wiele scenariuszy, które są odpowiedzią na tę potrzebę i nie wszystkie opierają się o infrastrukturę chmury publicznej. Chmura publiczna cechuje się tym, że od ponad dekady jest gotowa na takie scenariusze i z myślą o nich była budowana.</p>

                ]]>
            </summary>
        <content type="html">
            <![CDATA[
                <p>Aktualna sytuacja geopolityczna, a konkretnie mówiąc wojna, sprawiła, że jedna z cech chmury publicznej, która do 24.02.2022 roku była uważana za jeden z głównych minusów, właśnie zaczęła być rozpatrywana przez firmy i instytucje jako najlepsza opcja zabezpieczenia. Nie chodzi tu o migrację serwerów/systemów/aplikacji do chmury - na to potrzeba względnie dużo czasu (ocena wynika z doświadczenia). Chodzi o zabezpieczenie danych strategicznych - czymkolwiek nie są dla firmy czy instytucji. Mogą to być dane handlowe, analityczne, matematyczne, geosejsmiczne, kosmiczne. Mogą to być dane historyczne, ale i dane kreujące przyszłość firmy (lub jedno i drugie, rzecz jasna). Różne mogą być też wolumeny tych danych (od kilobajtów do petabajtów) i dynamika ich zmian (od tych, które zmieniają się codziennie, do tych które zmieniają się kwartalnie czy rocznie). Łączy je jedna cecha - jeśli zostaną utracone lub przejęte (a ten scenariusz może być często gorszy niż utrata) to daleko idące problemy mogą być nie tylko personalne czy biznesowe ale mogą dotykać całych gałęzi gospodarki, a nawet wpływać na losy państwa.<br>Przez zabezpieczenie danych mam na myśli zmianę rezydencji tych danych (oryginałów lub kopii) z lokalnej infrastruktury (to znaczy umiejscowionej w Polsce, w siedzibie firmy lub współdzielonym centrum danych) na lokalizacje oddalone na tyle, aby lokalna sytuacja geopolityczna nie wpływała na ich bezpieczeństwo. Oczywiście istnieje wiele scenariuszy, które są odpowiedzią na tę potrzebę i nie wszystkie opierają się o infrastrukturę chmury publicznej. Chmura publiczna cechuje się tym, że od ponad dekady jest gotowa na takie scenariusze i z myślą o nich była budowana.</p>

<p>Z uwagi na fakt, że zajmuję się wyłącznie platformą Microsoft Azure, robię to od mniej więcej 10 lat (niewiele krócej, niż ta platforma istnieje), to będę wypowiadał się jedynie w kontekście tej platformy - przełożenie na inne platformy pozostawiam koleżankom i kolegom, którzy się nimi zajmują - w tym wypadku, choć gramy w różnych drużynach, to do jednej bramki.</p>
<h2>Magazyn danych </h2>
<p>Nie wchodząc zbyt głęboko w marketing (choć siłą rzeczy już w niego wszedłem): Azure Storage to usługa, która daje opcje przechowania bajtów w chmurze. Komunikacja z takim kontem to przede wszystkim REST, ale i NFS lub SFTP, jeśli ktoś bardzo mocno tego potrzebuje. Jeśli wystarczy REST (do czego zachęcam), to sposobów dostępu jest wiele - od dedykowanej aplikacji Storage Explorer, przez narzędzia wiersza polecenia po możliwość zamontowania tej przestrzeni w systemie plików.</p>
<p>Taki chmurowy magazyn danych ma swoje limity - jak to chmura:</p>
<ul>
<li>250 kont per region per subskrypcja (ilość regionów jest listą skończoną, za to ilość możliwych subskrypcji już praktycznie nie).</li>
<li>każde konto ma limit pojemności: 5PB (5000TB), ale spokojnie, to soft limit.</li>
<li>limit IOPS per konto to 20000 (to też soft limit)</li>
<li>limit transferu przychodzącego per konto to 60Gbps, a wychodzącego 120Gbps (i to też soft limity)</li>
<li>maksymalna wielkość pojedynczego pliku (bloba), który możemy przechować, to 190.7TB (tak, terabajta)</li>
<li>maksymalna ilość IOPS per blob to 500</li>
<li>maksymalna przepustowość per blob to 60MBps</li>
</ul>
<h2>Redundancja, wysoka dostępność i odporność na awarie</h2>
<p>Opcji redundancji danych, wysokiej dostępności i odporności na awarie w przypadku Azure Storage jest kilka. Omówmy opcję "na bogato" (o cenach później).</p>
<p>Realizując temat lokalnie, a właściwie "tradycyjnie", zapewne umieszczamy nasze cenne dane na macierzy, która ma solidną, godną zaufania konfigurację (nie jestem specjalistą, więc określę to jako RAID 1, 5, 6 lub równoważną, w tym hiperkonwergentną). Zreplikujemy te dane do drugiej lokalizacji lub wykonamy ich backup do drugiej lokalizacji (lub nawet jedno i drugie). Pytaniem pozostanie: co znaczy druga lokalizacja? Drugi serwer? Druga szafa? Druga komora? Drugie DC w tej samej lokalizacji geograficznej? Inna lokalizacja geograficzna? Jak bardzo oddalona? 10 km? 100km? 700km? Pytania można mnożyć - nie chodzi o to by teraz na nie odpowiedzieć, ale o fakt, że parametrów jest sporo i wpływają one na koszty i logistykę.</p>
<p>Zapisując dowolny bajt danych w Azure Storage (a usługa ta jest nie tylko dostępna jako storage per se, ale także jest bazą do praktycznie wszystkich usług w Azure - od relacyjnych baz danych po aplikacje web), dostajemy w minimalnej opcji 3 repliki każdego bajtu (jedną gorącą, na której pracujemy i 2 w odwodzie - jeśli gorąca ulega awarii, to jest zastępowana zapasówką i od razu tworzona jest nowa zapasówka do kworum 3). W opcji bogatej wykorzystujemy wszystkie możliwości platformy Microsoft Azure jeśli chodzi o zabezpieczenie danych:</p>
<ul>
<li>Trzy repliki w obrębie jednego regionu</li>
<li>Repliki rozrzucone pomiędzy strefy dostępności, czyli centra danych oddalone od siebie o dziesiątki kilometrów i nie posiadające wspólnego, pojedynczego punktu awarii</li>
<li>Trzy repliki w siostrzanym regionie geograficznym, oddalonym o setki kilometrów</li>
<li>Gwarancja persystencji obiektu zapisanego w magazynie skonfigurowanym w taki sposób, to 99.99999999999999%</li>
<li>Gwarancja dostępności usługi Azure Storage w tej konfiguracji dla operacji odczytu to 99.99% (zapis 99.9%)</li>
</ul>
<p><img loading="lazy" src="https://docs.microsoft.com/en-us/azure/storage/common/media/storage-redundancy/geo-zone-redundant-storage.png" data-is-external-image="true"  alt="Diagram showing how data is replicated with GZRS or RA-GZRS"></p>
<h2>Szyfrowanie danych</h2>
<p>Dane, niezależnie od tego, gdzie są przechowywane, mogą być szyfrowane na trzech poziomach:</p>
<ol>
<li>Po stronie klienta (szyfrowanie danych przed zapisaniem do docelowego magazynu)</li>
<li>Po stronie serwera - usługa (szyfrowanie w usłudze przechowującej)</li>
<li>Po stronie serwera - infrastruktura (szyfrowanie w warstwie sprzętowej po stronie serwera)</li>
</ol>
<p>Azure Storage oferuje, jako usługa, dwie z trzech opcji - szyfrowanie wszystkich danych:</p>
<ul>
<li>W spoczynku AES 256 bit (zgodne z FIPS 140-2)</li>
<li>W warstwie infrastruktury AES 256 (zgodne z FIPS 140-2)</li>
</ul>
<p>Zarządzanie kluczami szyfrującymi może być po stronie platformy Microsoft Azure (obie warstwy) lub po stronie klienta (warstwa usługowa spoczynku danych) - w tym HSM zarządzany przez Azure Key Vault (Thales).</p>
<h2>Nienaruszalność dancyh</h2>
<p>Azure Storage oferuje możliwość skorzystania z polityk nienaruszalności danych w magazynie - WORM (Write Once, Read Many). Polityki nienaruszalności Azure Storage zgodne są z regulacjami SEC 17a-4(f), CFTC 1.31(d) i FINRA.</p>
<p>Dostępne są dwie polityki nienaruszalności:</p>
<p><strong>Time-based retention - </strong>Obiekt objęty tą polityką może być stworzony i odczytany, ale nie może być zmieniony ani usunięty. Polityka ta obowiązuje przez wskazany okres czasu od utworzenia obiektu (od 1 dnia do 400 lat). Po upłynięciu terminu ochrony obiekt może być usunięty, ale nie może być nadpisany.</p>
<p><strong>Legal hold - </strong>Obiekt objęty tą polityką może zostać stworzony lub odczytany, ale nie może być zmieniony lub usunięty do czasu zdjęcia ochrony.</p>
<p><img loading="lazy" src="https://docs.microsoft.com/en-us/azure/storage/blobs/media/immutable-storage-overview/worm-diagram.png" data-is-external-image="true"  alt="Diagram showing how retention policies and legal holds prevent write and delete operations"></p>
<h2>Dostęp do danych</h2>
<p>Azure Storage realizuje model dostępu do danych na dwa sposoby:</p>
<ol>
<li>Dostęp na bazie kluczy (2 klucze z możliwością rotacji)</li>
<li>Dostęp oparty o Role-Based Access Control - role przypisywane konkretnym użytkownikom w kontekście konkretnych kont magazynu</li>
</ol>
<p>Oba modele pozwalają na operowanie poświadczeniami bezpośrednio ale i operowanie pośrednie za pomocą tak zwanych Shared Access Signatires - odnośników generowanych na żądanie wraz z parametrami, takimi jak data ważności odnośnika, filtr IP i możliwe do wykonania operacje (odczyt, zapis, usunięcie).</p>
<h3>Warstwa sieci</h3>
<p>Dostęp do kont magazynu na platformie Microsoft Azure może być realizowany przez publiczne łącza internetowe zabezpieczone TLS, ale są też opcje prywatnego dostępu. Pierwszą z nich jest klasyczny VPN - S2S IPSec lub P2S IPSec/OpenVPN - oraz funkcjonalność Private Endpoint dla usługi Azure Storage.</p>
<p>Drugą opcją jest dzierżawione, dedykowane łącze telekomunikacyjne z wybranym georegionem lub konkretnym regionem Azure - zestawiane przez operatora telekomunikacyjnego z wybranej przez klienta lokalizacji. Łącze to może być w warstwie 1, 2 lub 3 modelu OSI (w zależności, gdzie i jak hostuje się klient), a nawet może być realizowane satelitarnie i przez infrastrukturę 5G. Usługa ta pozwala nie tylko na skorzystanie z kont magazynu po prywatnej adresacji (co jest funkcją dodatkową Azure Storage), ale także pozwala na prywatny routing do publicznych endpointów usługi. Usługa, która pozwala realizować taki scenariusz to Azure ExpressRoute.</p>
<p><img loading="lazy" src="https://docs.microsoft.com/en-au/azure/expressroute/media/expressroute-introduction/expressroute-connection-overview.png" data-is-external-image="true"  alt="ExpressRoute connection overview"></p>
<h2>Logowanie</h2>
<p>Usługa Azure Storage potrafi odkładać logi nie tylko diagnostyczne, dotyczące działania usługi, ale także logi analityczne, dotyczące operacji wykonywane na usłudze - wywołania zakończone sukcesem i niepowodzeniem oraz szczegóły operacyjne tych wywołań. Oznacza to, że usługa jest audytowalna.</p>
<h2>Próg wejścia - konfiguracja wstępna</h2>
<p>To jest obszar w którym Azure pokazuje szczególny uzysk. Funkcjonalności opisane powyżej budują przekonanie o zasadności użycia, a prostota wdrożenia tego rozwiązania tylko dopełnia procesu decyzyjnego. Utworzenie konta magazynu to jedno wywołanie do API - oczywiście można je wykonać za pomocą wielu narzędzi, ale w czystej formie ukazuje jak niski jest próg wejścia:</p>
<p><code>PUT https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Storage/storageAccounts/{accountName}?api-version=2018-02-01</code></p>
<p><code>{ <span class="hljs-attr">"sku"</span>: { <span class="hljs-attr">"name"</span>: <span class="hljs-string">"Standard_RAGZRS"</span> }, <span class="hljs-attr">"kind"</span>: <span class="hljs-string">"StorageV2"</span>, <span class="hljs-attr">"location"</span>: <span class="hljs-string">"westeurope"</span>, }</code></p>
<h2>Lokalizacja</h2>
<p>Ostatecznym wyborem w świetle przyczyny tego artykułu, to znaczy konieczności zabezpieczenia istotnych danych, jest wybór lokalizacji. Platforma Microsoft Azure to obecnie około 60 regionów geograficznych. Opcja bogata replikacji i wysokiej dostępności opisana powyżej ogranicza się do krótszej listy:</p>
<ul>
<li>(Asia Pacific) Asia East</li>
<li>(Asia Pacific) Asia Southeast</li>
<li>(Asia Pacific) Australia East</li>
<li>(Asia Pacific) Japan East</li>
<li>(Canada) Canada Central</li>
<li><strong>(Europe) North Europe</strong></li>
<li><strong>(Europe) West Europe</strong></li>
<li><strong>(Europe) France Central</strong></li>
<li><strong>(Europe) Norway East</strong></li>
<li>(Europe) UK South</li>
<li>(South America) Brazil South</li>
<li>(US) US Central</li>
<li>(US) US East</li>
<li>(US) US East 2</li>
<li>(US) US Government East</li>
<li>(US) US South Central</li>
<li>(US) US West 2</li>
<li>(US) US West 3</li>
</ul>
<p>Wyszczególnione regiony znajdują się w Europejskim Obszarze Gospodarczym (region Polski Centralnej zostanie otwarty, zgodnie z planem, pod koniec 2022 roku).</p>
<h2>Cena</h2>
<p>Poruszyłem powyżej wiele aspektów funkcjonowania magazynu danych opartego o Azure Storage - od samego magazynu i jego parametrów, przez opcje wysokiej dostępności i odporności na awarie, polityk nienaruszalności po aspekty dostępu do danych - w tym sieciowe. Część z tych kwestii wpływa na cenę, a część nie. ExpressRoute jest usługą sieciową i odrębną od samego magazynu, a także zależną od oferty jaką od operatora telekomunikacyjnego otrzyma klient. Samo połączenie ExpressRoute jak i VPN wymaga bramy po stronie Azure - jej koszt zależy od przepustowości - od €23.65/mc za 100Mbps po €2758/mc za 10Gbps. W przypadku ExpressRoute ponosimy też koszt podłączenia go po stronie Azure - od €49.48/mc za 50Mbps po €3059/mc za 10Gbps.</p>
<p>Kolejnym kosztem jest koszt danych wychodzących z Azure. Od €0.0450 do €0.0788/GB dla danych wychodzących poza Azure przez publiczny internet. €0.018/GB dla transferu między regionami i €0.009/GB za transfer między strefami dostępności. Jeśli zdecydujemy się na ExpressRoute to zaoszczędzimy na koszcie ruchu wychodzącego, który będzie nas kosztował. €0.023/GB. Możemy też zdecydować się na nielimitowany transfer wychodzący przez ExpressRoute - tak przyjemność zakosztuje nas od €269.93/mc za 50Mbps do €46157/mc za 10Gbps. Jeśli zaś wystarczy nam podpięcie się tylko do konkretnego regionu Azure to w planie bez limitu bdzie taniej - od €1079/mc za 1Gbps do €4948/mc za 10Gbps.</p>
<p>Jak wygląda koszt samego magazynu? Tutaj jst już nieco przyjaźnij niż w warstwie sieciowej. Za każdy GB przestrzeni przyjdzie nam zapłacić od €0.02599/mc do €0.0518/mc (w zależności od Tier i ilości danych, ale w szczegóły na tym etapie nie ma sensu wchodzić). Jeśli wiemy, że będziemy konsumować duże ilości danych, to możemy rezerwować pojemność w pakietach po 100TB lub 1PB. Zarezerwowane na trzy lata 100TB to koszt od €1756/mc do €3497/mc. Zarezerwowane na 3 lata 1PB przestrzeni to wydatek od €16891/mc do €33635/mc. Jeśli myślimy o retencji chłodnej (jak backup czy replika), to patrzmy na wartości niższe.<br>W kontach magazynu płacimy także za operacje na danych - przykładowo od €0.1058 do €0.1800 za każde 10000 operacji zapisu, czy od €0.0090 do €0.0039 za każde 10000 operacji odczytu.</p>
<p>Co z politykami nienaruszalności, szyfrowaniem i mechanizmem replikacji oraz nadmiarowości? To mamy wliczone w cenę każdego GB danych.</p>
<h2>Konkluzja</h2>
<p>Przestrzeń na dane w chmurze to dziś najlepsza opcja na zabezpieczenie danych wartościowych przed ich utratą lub przejęciem w przypadku fizycznego ataku na nie. Jak widać wybór opcji i przewidzenie kosztów wymaga odrobiny gimnastyki. Klienci nie są jednak z tym sami. Są ludzie, którzy robią to od lat.</p>
<p> </p>
            ]]>
        </content>
    </entry>
</feed>