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 | Dostęp prywatny zaimplementowany za pośrednictwem dojrzałej technologii usługi Private Link umożliwia zapewnienie dostępu do klastra dla zasobów w sieciach wirtualnych platformy Azure. Dostęp publiczny umożliwia otwieranie klastra w zdefiniowanym zestawie publicznych adresów IP. Dostęp prywatny i publiczny można łączyć i włączać lub wyłączać w dowolnym momencie. Konfiguracja domyślna: usługa Azure Cosmos DB dla klastrów rdzeni wirtualnych Bazy danych MongoDB jest domyślnie blokowana. Aby zapewnić dostęp do klastra, należy zaktualizować ustawienia sieci, aby umożliwić prywatny i/lub publiczny dostęp do klastra podczas tworzenia klastra lub po nim. Dostęp prywatny: po włączeniu dostępu prywatnego można utworzyć prywatny punkt końcowy w celu uzyskania dostępu do klastra prywatnego z poziomu sieci wirtualnej platformy Azure. Prywatny punkt końcowy jest tworzony w podsieci określonej sieci wirtualnej. Po zakończeniu wszystkie funkcje sieci wirtualnej platformy Azure są dostępne dla klastra, w tym lokalnej i globalnej komunikacji równorzędnej sieci wirtualnych, dostępu do prywatnych środowisk lokalnych, filtrowania i routingu ruchu sieciowego oraz innych. Dostęp publiczny: Użycie 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. 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 regionie usługa Azure Cosmos DB dla bazy danych MongoDB replikuje dane na poziomie magazynu, zachowując 3 synchroniczne repliki każdego fizycznego fragmentu w sposób niewidoczny przez cały czas. Klastry z obsługą wysokiej dostępności mają kolejną warstwę replikacji między każdą podstawową i rezerwową parą fragmentów fizycznych. Replikacja o wysokiej dostępności jest synchroniczna i zapewnia zerową utratę danych w trybie failover, co gwarantuje 99,99% miesięcznej dostępności umowy SLA dla konfiguracji pojedynczego regionu. |
| Replikacja globalna | Usługa Azure Cosmos DB dla bazy danych MongoDB oferuje replikację między regionami, która umożliwia replikowanie danych do innego regionu świadczenia usługi Azure. Replikacja globalna umożliwia globalne skalowanie i zapewnia dostęp o małych opóźnieniach do danych na całym świecie. W kontekście zabezpieczeń replikacja globalna zapewnia ochronę danych przed rzadkimi awariami regionalnymi. W przypadku klastra replik między regionami kopia danych jest zawsze obecna w innym regionie. Replika w innym regionie w połączeniu z wysoką dostępnością zapewnia umowę SLA gwarantującą dostępność miesięczną na poziomie 99,995% dla konfiguracji w wielu regionach. |
| Izolacja bazy danych | Bazy danych z rdzeniami wirtualnymi usługi Azure Cosmos DB dla bazy danych MongoDB są hostowane we własnych dedykowanych zasobach. Oznacza to, że każdy klaster pobiera własny dedykowany węzeł nazywany fragmentem fizycznym lub kilka w konfiguracji wieloczęściowej. Każdy fragment fizyczny ma dołączony własny magazyn obliczeniowy i zdalny. Nie ma udostępniania infrastruktury między klastrami, zapewniając dodatkową warstwę izolacji fizycznej i logicznej dla bazy danych. |
| Automatyczne kopie zapasowe klastra | Tworzenie kopii zapasowej klastrów rdzeni wirtualnych usługi Azure Cosmos DB dla bazy danych MongoDB jest włączone w czasie tworzenia klastra, jest w pełni zautomatyzowane i nie można ich wyłączyć. Przywracanie jest dostarczane do dowolnego znacznika czasu w ciągu 35-dniowego okresu przechowywania kopii zapasowych. |
| Przywracanie usuniętych danych | Automatyczne kopie zapasowe online mogą służyć do odzyskiwania danych z klastra, które mogły zostać przypadkowo usunięte do około 7 dni po zdarzeniu. |
| Szyfrowanie HTTPS/SSL/TLS | Cała komunikacja sieciowa z klastrami rdzeni wirtualnych usługi Azure Cosmos DB dla bazy danych MongoDB jest szyfrowana. 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. Szyfrowanie danych obsługuje poziomy protokołu TLS do 1.3 (dołączone). |
| Szyfrowanie w spoczynku | Dane rdzeni wirtualnych usługi Azure Cosmos DB dla bazy danych MongoDB, 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ć. |
| Monitorowanie ataków | Korzystając z dzienników rejestrowania inspekcji i aktywności, można monitorować bazę danych 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 temacie Wspólna odpowiedzialność w chmurze. |
| Chronione obiekty | Dane w usłudze Azure Cosmos DB dla rdzeni wirtualnych bazy danych MongoDB są przechowywane w chronionych centrach danych platformy Azure. Dowiedz się więcej w globalnych centrach danych firmy Microsoft |
| Serwery z poprawkami | Rdzeń wirtualny usługi Azure Cosmos DB dla bazy danych MongoDB eliminuje konieczność automatycznego zarządzania aktualizacjami oprogramowania i klastrami poprawek. |
| 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. Hasło powinno mieć długość co najmniej 8 znaków, zawierać wielkie litery angielskie i małe litery, cyfry i znaki inne niż alfanumeryczne. Zabezpieczenia za pośrednictwem uwierzytelniania opartego na wpisie tajnym PROTOKOŁU TLS są domyślnie szyfrowane. |
| Konta pomocnicze | W przypadku bardziej szczegółowego dostępu dodatkowe konta użytkowników można tworzyć w klastrach z uprawnieniami tylko do odczytu i zapisu lub tylko do odczytu w bazach danych klastra. |
| 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. W klastrze można połączyć opcje dostępu publicznego i prywatnego. Ustawienia konfiguracji sieci można zmienić w dowolnym momencie.
Brak dostępu
Brak dostępu jest opcją domyślną dla nowo utworzonego klastra, jeśli nie utworzono reguł zapory ani prywatnych punktów końcowych podczas aprowizacji klastra dla dostępu publicznego lub prywatnego odpowiednio. 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ę. Jeśli publiczny adres IP nie jest określony w jednej z reguł zapory w klastrze, żądania z tego adresu IP są odrzucane przez zaporę i nie docierają do bazy danych.
Dostęp prywatny
W opcji dostępu prywatnego dla klastra jest tworzony prywatny punkt końcowy. Ten prywatny punkt końcowy jest skojarzony z siecią wirtualną platformy Azure i podsiecią w tej sieci wirtualnej. Prywatny punkt końcowy umożliwia hostom w skojarzonej sieci wirtualnej i równorzędnych sieciach wirtualnych dostęp do klastra rdzeni wirtualnych usługi Azure Cosmos DB for MongoDB.
Omówienie zapory
Rdzenie wirtualne usługi Azure Cosmos DB dla bazy danych MongoDB używają zapory na poziomie klastra, aby uniemożliwić dostęp do klastra do momentu określenia, które komputery (adresy IP) 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 klastra 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 klastra, 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.