Omówienie zabezpieczeń bazy danych w usłudze Azure Cosmos DB dla rdzeni wirtualnych bazy danych MongoDB
DOTYCZY: 
Rdzenie wirtualne bazy danych MongoDB
W tym artykule omówiono najlepsze rozwiązania w zakresie zabezpieczeń bazy danych i kluczowe funkcje oferowane przez rdzeń wirtualny usługi Azure Cosmos DB dla bazy danych MongoDB, aby ułatwić zapobieganie naruszeniom bazy danych, wykrywanie ich i reagowanie na nie.
Co nowego w zabezpieczeniach rdzeni wirtualnych usługi Azure Cosmos DB dla bazy danych MongoDB
Szyfrowanie magazynowane jest teraz dostępne dla dokumentów i kopii zapasowych przechowywanych w usłudze Azure Cosmos DB dla rdzeni wirtualnych bazy danych MongoDB w większości regionów świadczenia usługi Azure. Szyfrowanie magazynowane jest stosowane automatycznie zarówno dla nowych, jak i istniejących klientów w tych regionach. Nie ma potrzeby konfigurowania niczego. Uzyskujesz takie samo duże opóźnienie, przepływność, dostępność i funkcjonalność, jak wcześniej, dzięki korzyści płynącej z wiedzy, że dane są bezpieczne i bezpieczne dzięki szyfrowaniu magazynowanemu. Dane przechowywane w klastrze rdzeni wirtualnych usługi Azure Cosmos DB dla bazy danych MongoDB są automatycznie i bezproblemowo szyfrowane przy użyciu kluczy zarządzanych przez firmę Microsoft przy użyciu kluczy zarządzanych przez usługę.
Jak mogę zabezpieczyć moją bazę danych
Bezpieczeństwo danych to wspólna odpowiedzialność między Tobą, klientem i dostawcą bazy danych. W zależności od wybranego dostawcy bazy danych ilość odpowiedzialności może się różnić. Jeśli wybierzesz rozwiązanie lokalne, musisz zapewnić wszystko, od ochrony punktu końcowego po fizyczne zabezpieczenia sprzętu — co nie jest łatwe. Jeśli wybierzesz dostawcę bazy danych w chmurze PaaS, takiego jak usługa Azure Cosmos DB, twój obszar zainteresowania znacznie się zmniejsza. Na poniższej ilustracji, pożyczonej ze wspólnej odpowiedzialności firmy Microsoft za przetwarzanie w chmurze , przedstawiono spadek odpowiedzialności dostawcy PaaS, takiego jak Azure Cosmos DB.
Na powyższym diagramie przedstawiono ogólne składniki zabezpieczeń w chmurze, ale jakie elementy należy martwić się o rozwiązanie bazy danych? A jak można porównać rozwiązania ze sobą?
Zalecamy następującą listę kontrolną wymagań, dla których należy porównać systemy baz danych:
- Ustawienia zabezpieczeń sieci i zapory
- Uwierzytelnianie użytkownika i szczegółowe kontrolki użytkownika
- Możliwość replikacji danych globalnie w przypadku awarii regionalnych
- Możliwość przełączania w tryb failover z jednego centrum danych do innego
- Replikacja danych lokalnych w centrum danych
- Automatyczne kopie zapasowe danych
- Przywracanie usuniętych danych z kopii zapasowych
- Ochrona i izolowanie poufnych danych
- Monitorowanie ataków
- Reagowanie na ataki
- Możliwość stosowania danych ogrodzenia geograficznego w celu przestrzegania ograniczeń ładu danych
- Ochrona fizyczna serwerów w chronionych centrach danych
- Certyfikaty
I chociaż może się wydawać oczywiste, ostatnie naruszenia bazy danych na dużą skalę przypominają nam o prostym, ale krytycznym znaczeniu następujących wymagań:
- Serwery z poprawkami, które są aktualne
- Szyfrowanie HTTPS domyślnie/TLS
- Konta administracyjne z silnymi hasłami
Jak usługa Azure Cosmos DB zabezpiecza moją bazę danych
Rdzeń wirtualny usługi Azure Cosmos DB dla bazy danych MongoDB bezproblemowo spełnia każde z tych wymagań dotyczących zabezpieczeń.
Przyjrzyjmy się szczegółowo każdemu z nich.
| Wymaganie dotyczące zabezpieczeń | Podejście zabezpieczeń usługi Azure Cosmos DB |
|---|---|
| Bezpieczeństwo sieci | Korzystanie z zapory IP jest pierwszą warstwą ochrony w celu zabezpieczenia bazy danych. Usługa Azure Cosmos DB dla rdzeni wirtualnych bazy danych MongoDB obsługuje oparte na zasadach mechanizmy kontroli dostępu oparte na adresach IP na potrzeby obsługi zapory dla ruchu przychodzącego. Mechanizmy kontroli dostępu oparte na adresach IP są podobne do reguł zapory używanych przez tradycyjne systemy baz danych. Są one jednak rozszerzane tak, aby klaster rdzeni wirtualnych usługi Azure Cosmos DB dla bazy danych MongoDB był dostępny tylko z zatwierdzonego zestawu maszyn lub usług w chmurze. Rdzeń wirtualny usługi Azure Cosmos DB dla bazy danych MongoDB umożliwia włączenie określonego adresu IP (168.61.48.0), zakresu adresów IP (168.61.48.0/8) oraz kombinacji adresów IP i zakresów. Wszystkie żądania pochodzące z maszyn spoza tej listy dozwolonych są blokowane przez usługę Azure Cosmos DB dla rdzeni wirtualnych bazy danych MongoDB. Żądania z zatwierdzonych maszyn i usług w chmurze muszą następnie ukończyć proces uwierzytelniania, aby zapewnić kontrolę dostępu do zasobów. |
| Replikacja lokalna | Nawet w jednym centrum danych usługa Azure Cosmos DB dla bazy danych MongoDB replikuje dane przy użyciu magazynu LRS. Klastry z obsługą wysokiej dostępności mają również inną warstwę replikacji między węzłem podstawowym i pomocniczym, co gwarantuje umowę SLA gwarantującą dostępność na 99,995%. |
| Automatyczne kopie zapasowe online | Bazy danych z rdzeniami wirtualnymi usługi Azure Cosmos DB dla bazy danych MongoDB są regularnie tworzone i przechowywane w magazynie geograficznie nadmiarowym. |
| Przywracanie usuniętych danych | Automatyczne kopie zapasowe online mogą służyć do odzyskiwania danych, które mogły zostać przypadkowo usunięte do ~7 dni po zdarzeniu. |
| Ochrona i izolowanie poufnych danych | Wszystkie dane w regionach wymienionych w artykule Co nowego? funkcja jest teraz szyfrowana w spoczynku. |
| Monitorowanie ataków | Korzystając z dzienników rejestrowania inspekcji i aktywności, możesz monitorować konto pod kątem normalnej i nietypowej aktywności. Możesz wyświetlić operacje wykonywane na zasobach. Te dane obejmują; kto zainicjował operację, kiedy operacja miała miejsce, stan operacji i wiele innych. |
| Reagowanie na ataki | Po skontaktowaniu się z pomoc techniczna platformy Azure w celu zgłoszenia potencjalnego ataku rozpocznie się pięcioetapowy proces reagowania na zdarzenia. Celem procesu pięcioetapowego jest przywrócenie normalnych zabezpieczeń i operacji usługi. Pięcioetapowy proces przywraca usługi tak szybko, jak to możliwe po wykryciu problemu i rozpoczęciu badania. Dowiedz się więcej w artykule Microsoft Azure Security Response in the Cloud (Reagowanie na zabezpieczenia platformy Microsoft Azure w chmurze). |
| Chronione obiekty | Dane w usłudze Azure Cosmos DB dla rdzeni wirtualnych bazy danych MongoDB są przechowywane na dyskach SSD w chronionych centrach danych platformy Azure. Dowiedz się więcej w globalnych centrach danych firmy Microsoft |
| Szyfrowanie HTTPS/SSL/TLS | Rdzenie wirtualne usługi Azure Cosmos DB dla bazy danych MongoDB obsługują poziomy protokołu TLS do 1.3 (dołączone). Można wymusić minimalny poziom protokołu TLS po stronie serwera. |
| Szyfrowanie podczas transferu | Szyfrowanie (SSL/TLS) jest zawsze wymuszane, a próba nawiązania połączenia z klastrem bez szyfrowania zakończy się niepowodzeniem. Akceptowane są tylko połączenia za pośrednictwem klienta bazy danych MongoDB, a szyfrowanie jest zawsze wymuszane. Za każdym razem, gdy dane są zapisywane w usłudze Azure Cosmos DB dla rdzeni wirtualnych bazy danych MongoDB, dane są szyfrowane podczas przesyłania przy użyciu usługi Transport Layer Security 1.3. |
| Szyfrowanie w spoczynku | Usługa Azure Cosmos DB dla bazy danych MongoDB używa zweryfikowanego modułu kryptograficznego FIPS 140-2 do szyfrowania magazynu danych magazynowanych. Dane, w tym wszystkie kopie zapasowe, są szyfrowane na dysku, w tym pliki tymczasowe. Usługa używa 256-bitowego szyfru AES zawartego w szyfrowaniu usługi Azure Storage, a klucze są zarządzane przez system. Szyfrowanie magazynu jest zawsze włączone i nie można go wyłączyć. |
| Serwery z poprawkami | Rdzeń wirtualny usługi Azure Cosmos DB dla bazy danych MongoDB eliminuje konieczność automatycznego zarządzania klastrami poprawek i zarządzania nimi. |
| Konta administracyjne z silnymi hasłami | Trudno uwierzyć, że nawet musimy wspomnieć o tym wymaganiu, ale w przeciwieństwie do niektórych z naszych konkurentów nie można mieć konta administracyjnego bez hasła w usłudze Azure Cosmos DB dla rdzeni wirtualnych bazy danych MongoDB. Zabezpieczenia za pośrednictwem uwierzytelniania opartego na wpisie tajnym PROTOKOŁU TLS są domyślnie szyfrowane. |
| Certyfikaty zabezpieczeń i ochrony danych | Aby uzyskać najbardziej aktualną listę certyfikatów, zobacz zgodność platformy Azure i najnowszy dokument dotyczący zgodności platformy Azure ze wszystkimi certyfikatami platformy Azure, w tym usługą Azure Cosmos DB. |
Poniższy zrzut ekranu przedstawia sposób monitorowania konta przy użyciu rejestrowania inspekcji i dzienników aktywności: 
Opcje zabezpieczeń sieci
W tej sekcji opisano różne opcje zabezpieczeń sieci, które można skonfigurować dla klastra.
Brak dostępu
Brak dostępu jest opcją domyślną dla nowo utworzonego klastra, jeśli nie jest włączony dostęp publiczny lub prywatny. W takim przypadku żadne komputery, niezależnie od tego, czy znajdują się na platformie Azure, czy poza nią, mogą łączyć się z węzłami bazy danych.
Dostęp do publicznego adresu IP z zaporą
W opcji dostępu publicznego publiczny adres IP jest przypisywany do klastra, a dostęp do klastra jest chroniony przez zaporę.
Omówienie zapory
Rdzenie wirtualne usługi Azure Cosmos DB dla bazy danych MongoDB używają zapory na poziomie serwera, aby uniemożliwić cały dostęp do klastra, dopóki nie określisz, które komputery mają uprawnienia. Zapora udziela dostępu do klastra na podstawie źródłowego adresu IP każdego żądania. Aby skonfigurować zaporę, należy utworzyć reguły zapory określające zakresy dopuszczalnych adresów IP.
Reguły zapory umożliwiają klientom dostęp do klastra i wszystkich baz danych w nim. Reguły zapory na poziomie serwera można skonfigurować przy użyciu witryny Azure Portal lub programowo przy użyciu narzędzi platformy Azure, takich jak interfejs wiersza polecenia platformy Azure.
Domyślnie zapora blokuje cały dostęp do klastra. Aby rozpocząć korzystanie z klastra z innego komputera, należy określić co najmniej jedną regułę zapory na poziomie serwera, aby umożliwić dostęp do klastra. Użyj reguł zapory, aby określić zakresy adresów IP z Internetu, aby zezwolić. Reguły zapory nie mają wpływu na dostęp do samej witryny internetowej witryny azure portal. Próby nawiązania połączenia z Internetu i platformy Azure muszą najpierw przejść przez zaporę, zanim będą mogły uzyskać dostęp do baz danych. Oprócz reguł zapory dostęp do łącza prywatnego, który może być używany tylko dla prywatnego adresu IP dla klastra rdzeni wirtualnych usługi Azure Cosmos DB dla bazy danych MongoDB.