Opis funkcji zabezpieczeń

Ukończone

Usługa Azure Database for MySQL — serwer elastyczny udostępnia kilka funkcji, które są przeznaczone do ochrony i zabezpieczania danych i operacji. Przyjrzyjmy się każdej z tych funkcji.

Sieć

Azure Database for MySQL — serwer elastyczny zapewnia niezawodne ustawienia zapory w celu ochrony łączności z bazą danych na potrzeby dostępu publicznego, a także sieci wirtualnych platformy Azure. Istnieją trzy ustawienia połączenia elastycznego serwera MySQL: dostęp publiczny, dostęp prywatny i link prywatny. We wszystkich przypadkach połączenia muszą nadal uwierzytelniać się za pomocą serwera.

Dostęp publiczny zapewnia publicznie rozpoznawalny adres DNS dostępny przez Internet przez dozwoloną listę zakresów adresów IP. Domyślnie żadne adresy IP nie są dozwolone. Adresy IP można dodawać podczas tworzenia lub po jego utworzeniu. Możesz również zezwolić na dostęp z dowolnego adresu IP platformy Azure (w tym innych subskrypcji klientów w innych regionach).

Dostęp prywatny używa delegowanej podsieci do hostowania serwerów elastycznych MySQL i zapewnia adres DNS rozpoznawalny z sieci wirtualnej lub równorzędnej sieci wirtualnej. Spowoduje to zablokowanie dostępu do bazy danych tylko do infrastruktury sieci wirtualnej. Reguły zapory sieciowej grupy zabezpieczeń (NSG) można skonfigurować w celu dokładniejszego filtrowania ruchu sieciowego. Dostęp prywatny umożliwia bezpieczne łączenie się z serwerem elastycznym MySQL z poziomu tej samej sieci wirtualnej, z innej sieci wirtualnej przy użyciu komunikacji równorzędnej, a nawet z sieci lokalnej przy użyciu połączenia expressRoute lub sieci VPN.

Link prywatny udostępnia prywatny punkt końcowy adresu IP w podsieci sieci wirtualnej w celu bezpośredniego nawiązania połączenia z serwerem elastycznym MySQL. Usługa Azure Private Link zasadniczo przenosi usługi platformy Azure wewnątrz prywatnej sieci wirtualnej za pośrednictwem adresu IP, takiego jak każdy inny zasób sieci wirtualnej. Możesz utworzyć kilka prywatnych punktów końcowych, na przykład jeden na połączenie aplikacji lub zasób usługi Azure PaaS. W połączeniu z regułami zapory sieciowej grupy zabezpieczeń linki prywatne zapewniają szczegółową kontrolę nad tym, które usługi mogą uzyskiwać dostęp do bazy danych.

Microsoft Defender for Cloud

Microsoft Defender dla Chmury monitoruje bazę danych pod kątem nietypowych i potencjalnie szkodliwych działań. Defender dla Chmury jest dostarczany jako plan dodatku do rozwiązywania potencjalnych zagrożeń bez konieczności tworzenia monitorowania zabezpieczeń ani zarządzania nim. Defender dla Chmury ma dostępność w wielu chmurach w usłudze Azure Database for MySQL — serwer elastyczny, oprócz bazy danych MySQL na platformie AWS Aurora i RDS. Defender dla Chmury obsługuje również bazy danych PostgreSQL i MariaDB.

Defender dla Chmury wykrywa zagrożenia bazy danych, takie jak:

  • Ataki siłowe: nietypowo wysokie błędy logowania i pomyślne logowanie po wielu niepowodzeniach.
  • Nietypowe wzorce logowania: jeśli użytkownik loguje się po raz pierwszy za ponad dwa miesiące.
  • Nietypowe lokalizacje logowania: jeśli użytkownik loguje się z nietypowej bazy danych platformy Azure lub innego dostawcy usług w chmurze lub jako podejrzanego oznaczono adres IP.

Defender dla Chmury wysyła alerty wykrywania do witryny Azure Portal i za pośrednictwem poczty e-mail. Alerty obejmują:

  • Szczegóły podejrzanego działania.
  • Skojarzone MITRE ATT&CK (niepożądane taktyki, techniki i wspólna wiedza).
  • Sugestie dotyczące badania i eliminowania ataku.
  • Więcej opcji badania za pomocą usługi Microsoft Sentinel.

Uwierzytelnianie

Usługa Azure Database for MySQL oferuje dwa tryby uwierzytelniania: uwierzytelnianie MySQL (nazwa użytkownika/hasło) i uwierzytelnianie identyfikatora Entra firmy Microsoft. Oba można włączyć w tym samym czasie.

Uwierzytelnianie identyfikatora Entra firmy Microsoft umożliwia uwierzytelnianie oparte na tożsamościach na serwerze elastycznym MySQL przy użyciu tożsamości udostępnianych przez identyfikator entra firmy Microsoft. Centralizuje to zarządzanie użytkownikami dla bazy danych i innych usługi firmy Microsoft.

Domyślnie serwer elastyczny MySQL jest ustawiony tak, aby używał tylko uwierzytelniania MySQL (nazwa użytkownika/hasło). To ustawienie można zmienić tak, aby używało tylko uwierzytelniania identyfikatora Entra firmy Microsoft (bez użytkowników bazy danych) lub połączyć tożsamości zarządzane z uwierzytelnianiem mySQL.

W przypadku korzystania z uwierzytelniania identyfikatora Entra firmy Microsoft istnieją dwa konta administratora: oryginalny administrator MySQL i administrator microsoft Entra ID. Administrator identyfikatora Entra firmy Microsoft może być użytkownikiem lub grupą użytkowników. Jeśli administrator jest grupą, każdy członek grupy może zarządzać uwierzytelnianiem identyfikatora Entra firmy Microsoft. Grupy administratorów są łatwiejsze do zarządzania, ponieważ centralizuje zarządzanie użytkownikami w usłudze Microsoft Entra ID, a nie konieczności bezpośredniego aktualizowania użytkowników lub uprawnień mySQL. Można skonfigurować tylko jednego administratora identyfikatora Entra firmy Microsoft, niezależnie od tego, czy jest to jeden użytkownik, czy jedna grupa użytkowników.

Na poniższym diagramie przedstawiono dwa tryby zarządzania uwierzytelnianiem.

Diagram przedstawiający sposób, w jaki administratorzy mySQL i administratorzy firmy Microsoft Entra dla programu MySQL mogą tworzyć użytkowników i zarządzać usługą Azure Database for MySQL — serwer elastyczny.

Gdy użytkownicy lub aplikacje próbują nawiązać połączenie z serwerem elastycznym MySQL przy użyciu tożsamości Firmy Microsoft Entra, token jest wystawiany w celu umożliwienia logowania. Tożsamość jest skojarzona z użytkownikiem bazy danych za pośrednictwem unikatowego identyfikatora użytkownika Microsoft Entra, a nie nazwy lub innych atrybutów.

Szyfrowanie danych

Serwery elastyczne MySQL szyfrują dane podczas przesyłania. Domyślnie serwery wymagają połączenia z protokołem Transport Layer Security (TLS) 1.2 i odmawiają niezaszyfrowanych połączeń lub połączeń przy użyciu przestarzałych protokołów TLS 1.0 i 1.1. Można wyłączyć połączenia szyfrowane (może to być starsza aplikacja nie obsługuje szyfrowania) lub zezwalać na wersje wcześniejsze niż 1.2 lub użyć protokołu TLS 1.3, co jest zalecanym ustawieniem dla tworzenia nowych aplikacji.

Domyślnie usługa Azure Database for MySQL — serwer elastyczny szyfruje dane magazynowane (w tym pliki kopii zapasowej i tymczasowe utworzone podczas uruchamiania zapytań) przy użyciu symetrycznego klucza szyfrowania danych AES 256-bitowego (DEK). Za pomocą kluczy zarządzanych przez klienta (CMK) można przenieść własny klucz (BYOK), aby dodać kolejną warstwę szyfrowania, szyfrując klucz szyfrowania usługi.

Funkcja BYOK zapewnia pełną kontrolę nad szyfrowaniem danych i cyklem życia klucza: tworzenie, przekazywanie, rotacja i usuwanie. Zarządzanie cyklem życia klucza umożliwia dostosowanie rotacji kluczy do zasad firmy i umożliwia rozdzielenie obowiązków zespołu ds. zabezpieczeń, administratora bazy danych i administratora systemu.

Włączenie klucza zarządzanego wymaga połączenia bazy danych z tożsamością zarządzaną przypisaną przez użytkownika, a następnie określenie klucza przechowywanego w usłudze Azure Key Vault do użycia. Jeśli tworzysz kopię serwera, kopia zostanie zaszyfrowana i można również dodać tożsamości zarządzane i klucze do istniejących replik.