Zabezpieczenia w usłudze Azure Database for PostgreSQL — serwer elastyczny
DOTYCZY: 
Azure Database for PostgreSQL — serwer elastyczny
Dostępnych jest wiele warstw zabezpieczeń, które ułatwiają ochronę danych w wystąpieniu usługi Azure Database for PostgreSQL — serwer elastyczny. W tym artykule przedstawiono te opcje zabezpieczeń.
Ponieważ organizacje coraz częściej polegają na danych przechowywanych w bazach danych w celu prowadzenia krytycznych działań decyzyjnych, które napędzają przewagę konkurencyjną, potrzeba solidnych środków zabezpieczeń bazy danych nigdy nie była ważniejsza. Wygaśnięcie zabezpieczeń może spowodować katastrofalne konsekwencje, w tym ujawnienie poufnych danych, co powoduje uszkodzenie reputacji organizacji.
Ochrona informacji i ich przechowywanie
Usługa Azure Database for PostgreSQL — serwer elastyczny szyfruje dane na dwa sposoby:
Dane przesyłane: usługa Azure Database for PostgreSQL — serwer elastyczny szyfruje dane przesyłane przy użyciu protokołu Secure Sockets Layer i Transport Layer Security (SSL/TLS). Szyfrowanie jest wymuszane domyślnie. Aby uzyskać bardziej szczegółowe informacje na temat zabezpieczeń połączeń z protokołem SSL\TLS, zobacz tę dokumentację. Aby uzyskać lepsze zabezpieczenia, możesz włączyć uwierzytelnianie SCRAM w usłudze Azure Database for PostgreSQL — serwer elastyczny.
Chociaż zdecydowanie nie jest to zalecane, jeśli jest to konieczne, ze względu na niezgodność starszego klienta, istnieje możliwość wyłączenia protokołu TLS\SSL dla połączeń z usługą Azure Database for PostgreSQL — serwer elastyczny przez zaktualizowanie parametru
require_secure_transportserwera do pozycji WYŁĄCZONE. Wersję protokołu TLS można również ustawić, ustawiającssl_max_protocol_versionparametry serwera.Dane magazynowane: w przypadku szyfrowania magazynu usługa Azure Database for PostgreSQL — serwer elastyczny używa zweryfikowanych modułów kryptograficznych FIPS 140-2. Dane są szyfrowane na dysku, co obejmuje kopie zapasowe i pliki tymczasowe tworzone podczas wykonywania zapytań.
Usługa używa trybu Galois/Counter Mode (GCM) z szyfrem 256-bitowym AES dołączonym do szyfrowania usługi Azure Storage, a klucze są zarządzane przez system. Jest to podobne do innych technologii szyfrowania danych magazynowanych, takich jak transparentne szyfrowanie danych w bazach danych SQL Server i Oracle. Szyfrowanie magazynu jest zawsze włączone i nie można go wyłączyć.
Bezpieczeństwo sieci
Gdy korzystasz z usługi Azure Database for PostgreSQL — serwer elastyczny, masz dwie główne opcje obsługi sieci:
Dostęp prywatny: Możesz wdrożyć serwer w sieci wirtualnej platformy Azure. Sieci wirtualne platformy Azure pomagają zapewnić prywatną i bezpieczną komunikację sieciową. Zasoby w sieci wirtualnej mogą komunikować się za pośrednictwem prywatnych adresów IP. Aby uzyskać więcej informacji, zobacz Omówienie sieci dla usługi Azure Database for PostgreSQL — serwer elastyczny.
Reguły zabezpieczeń w sieciowych grupach zabezpieczeń umożliwiają filtrowanie typu ruchu sieciowego, który może wchodzić do podsieci sieci wirtualnej i interfejsów sieciowych oraz z nich wychodzić. Aby uzyskać więcej informacji, zobacz omówienie sieciowych grup zabezpieczeń.
Dostęp publiczny: Dostęp do serwera można uzyskiwać za pośrednictwem publicznego punktu końcowego. Publiczny punkt końcowy jest publicznie rozpoznawalnym adresem DNS. Dostęp do niego jest zabezpieczony za pośrednictwem zapory, która domyślnie blokuje wszystkie połączenia.
Zapora IP udziela dostępu do serwerów na podstawie źródłowego adresu IP każdego żądania. Aby uzyskać więcej informacji, zobacz omówienie reguł zapory.
Obsługa Microsoft Defender dla Chmury
Usługa Microsoft Defender dla relacyjnych baz danych typu open source wykrywa nietypowe działania wskazujące na nietypowe i potencjalnie szkodliwe próby uzyskania dostępu do baz danych lub wykorzystania ich. Defender dla Chmury zapewnia alerty zabezpieczeń dotyczące nietypowych działań, dzięki czemu można wykrywać potencjalne zagrożenia i reagować na nie w miarę ich występowania. Po włączeniu tego planu Defender dla Chmury udostępnia alerty, gdy wykrywa nietypowy dostęp do bazy danych i wzorce zapytań oraz podejrzane działania bazy danych.
Te alerty są wyświetlane na stronie alertów zabezpieczeń usługi Defender for Cloud i obejmują:
- Szczegóły podejrzanego działania, które je wyzwoliły
- Skojarzona taktyka MITRE ATT&CK
- Zalecane akcje dotyczące sposobu badania i eliminowania zagrożenia
- Opcje kontynuowania badań za pomocą usługi Microsoft Sentinel
Usługa Microsoft Defender for Cloud i ataki siłowe
Atak siłowy jest jednym z najczęstszych i dość udanych metod hakerskich, mimo że jest najmniej wyrafinowaną metodą. Teoria takiego ataku polega na tym, że jeśli weźmiesz nieskończoną liczbę prób odgadnięcia hasła, ostatecznie będziesz mieć rację. Gdy usługa Microsoft Defender for Cloud wykryje atak siłowy, wyzwala alert informujący o tym, że doszło do ataku siłowego. Może również oddzielić prosty atak siłowy od ataku siłowego na właściwego użytkownika lub udanego ataku siłowego.
Aby uzyskać alerty z planu usługi Microsoft Defender, najpierw musisz je włączyć, jak pokazano w następnej sekcji.
Włączanie zwiększonych zabezpieczeń przy użyciu Microsoft Defender dla Chmury
- W witrynie Azure Portal przejdź do menu Zabezpieczenia w okienku po lewej stronie
- Wybierz Microsoft Defender dla Chmury
- W okienku po prawej stronie wybierz pozycję Włącz.
Uwaga
Jeśli w planie usługi Microsoft Defender jest włączona funkcja "relacyjnych baz danych typu open source", zauważysz, że usługa Microsoft Defender jest domyślnie włączona dla zasobu serwera elastycznego usługi Azure Database for PostgreSQL.
Zarządzanie dostępem
Najlepszym sposobem zarządzania uprawnieniami dostępu do bazy danych usługi Azure Database for PostgreSQL — serwer elastyczny na dużą skalę jest użycie koncepcji ról. Rola może być użytkownikiem bazy danych lub grupą użytkowników bazy danych. Role mogą być właścicielami obiektów bazy danych i przypisywać uprawnienia do tych obiektów do innych ról, aby kontrolować, kto ma dostęp do których obiektów. Istnieje również możliwość przyznania członkostwu w roli innej roli, dzięki czemu rola członka może używać uprawnień przypisanych do innej roli. Azure Database for PostgreSQL — serwer elastyczny umożliwia przyznawanie uprawnień bezpośrednio użytkownikom bazy danych. Dobrym rozwiązaniem w zakresie zabezpieczeń może być utworzenie ról z określonymi zestawami uprawnień na podstawie minimalnych wymagań aplikacji i dostępu. Następnie można przypisać odpowiednie role do każdego użytkownika. Role są używane do wymuszania modelu najniższych uprawnień na potrzeby uzyskiwania dostępu do obiektów bazy danych.
Wystąpienie usługi Azure Database for PostgreSQL — serwer elastyczny jest tworzone z trzema zdefiniowanymi rolami domyślnymi, oprócz wbudowanych ról tworzonych przez usługę PostgreSQL. Te role można wyświetlić, uruchamiając polecenie:
SELECT rolname FROM pg_roles;
Poniżej wymieniono role:
- azure_pg_admin
- azuresu
- rola administratora
Podczas tworzenia wystąpienia usługi Azure Database for PostgreSQL — serwer elastyczny podajesz poświadczenia dla roli administratora. Tej roli administratora można używać do tworzenia dodatkowych ról usługi PostgreSQL.
Na przykład poniżej możemy utworzyć przykładowego użytkownika/roli o nazwie "demouser"
CREATE USER demouser PASSWORD password123;
Rola administratora nigdy nie powinna być używana przez aplikację.
W środowiskach PaaS opartych na chmurze dostęp do konta superużytkownika usługi Azure Database for PostgreSQL — serwer elastyczny jest ograniczony do sterowania operacjami płaszczyzny tylko przez operatory chmury. azure_pg_admin W związku z tym konto istnieje jako konto pseudoużytkownika. Rola administratora jest członkiem azure_pg_admin roli.
Jednak konto administratora serwera nie jest częścią azuresu roli, która ma uprawnienia administratora i służy do wykonywania operacji płaszczyzny sterowania. Ponieważ ta usługa jest zarządzaną usługą PaaS, tylko firma Microsoft jest częścią roli administratora.
Można okresowo przeprowadzać inspekcję listy ról na serwerze. Możesz na przykład nawiązać połączenie przy użyciu psql klienta i wykonać zapytanie względem pg_roles tabeli, która zawiera listę wszystkich ról wraz z uprawnieniami, takimi jak tworzenie innych ról, tworzenie baz danych, replikacja itp.
select * from pg_roles where rolname='demouser';
-[ RECORD 1 ]--+---------
rolname | demouser
rolsuper | f
rolinherit | t
rolcreaterole | f
rolcreatedb | f
rolcanlogin | f
rolreplication | f
rolconnlimit | -1
rolpassword | ********
rolvaliduntil |
rolbypassrls | f
rolconfig |
oid | 24827
Ważne
Ostatnio włączyliśmy możliwość tworzenia poleceń CAST na serwerze elastycznym usługi Azure Database for PostgreSQL. Należy pamiętać, że obecnie funkcja działa zgodnie z oczekiwaniami z wyjątkiem instrukcji DROP. Innymi słowy, obecnie nie można usunąć rzutu rzutowania po jego utworzeniu. Aktywnie pracujemy nad dodaniem tej funkcji i przewidujemy jej dostępność w najbliższej przyszłości.
Rejestrowanie inspekcji w usłudze Azure Database for PostgreSQL — serwer elastyczny jest również dostępny w usłudze Azure Database for PostgreSQL — serwer elastyczny w celu śledzenia aktywności w bazach danych.
Kontrola dostępu do schematu
Nowo utworzone bazy danych w usłudze Azure Database for PostgreSQL — serwer elastyczny mają domyślny zestaw uprawnień w publicznym schemacie bazy danych, który umożliwia wszystkim użytkownikom i rolam bazy danych tworzenie obiektów. Aby lepiej ograniczyć dostęp użytkowników aplikacji do baz danych utworzonych w wystąpieniu usługi Azure Database for PostgreSQL — serwer elastyczny, zalecamy odwołanie tych domyślnych uprawnień publicznych. Po wykonaniu tej czynności można przyznać określone uprawnienia użytkownikom bazy danych w bardziej szczegółowy sposób. Na przykład:
Aby uniemożliwić użytkownikom bazy danych aplikacji tworzenie obiektów w schemacie publicznym, odwoływanie uprawnień tworzenia do
publicschematu zpublicroli.REVOKE CREATE ON SCHEMA public FROM PUBLIC;Następnie utwórz nową bazę danych.
CREATE DATABASE Test_db;Odwołaj wszystkie uprawnienia ze schematu PUBLICZNEGO w tej nowej bazie danych.
REVOKE ALL ON DATABASE Test_db FROM PUBLIC;Tworzenie roli niestandardowej dla użytkowników bazy danych aplikacji
CREATE ROLE Test_db_user;Nadaj użytkownikom bazy danych tę rolę możliwość nawiązywania połączenia z bazą danych.
GRANT CONNECT ON DATABASE Test_db TO Test_db_user; GRANT ALL PRIVILEGES ON DATABASE Test_db TO Test_db_user;Tworzenie użytkownika bazy danych
CREATE USER user1 PASSWORD 'Password_to_change'Przypisywanie roli z jej połączeniem i wybieranie uprawnień do użytkownika
GRANT Test_db_user TO user1;
W tym przykładzie użytkownik user1 może nawiązać połączenie i ma wszystkie uprawnienia w testowej bazie danych Test_db, ale nie żadnej innej bazy danych na serwerze. Zaleca się dalsze, zamiast nadać temu użytkownikowi/roli WSZYSTKIE UPRAWNIENIA w tej bazie danych i jego obiektach, aby zapewnić bardziej selektywne uprawnienia, takie jak SELECT, INSERT, EXECUTE itp. Aby uzyskać więcej informacji na temat uprawnień w bazach danych PostgreSQL, zobacz polecenia GRANT i REVOKE w dokumentacji bazy danych PostgreSQL.
Zmiany własności schematu publicznego w usłudze PostgreSQL 15
Z wersji 15 bazy danych Postgres własność schematu publicznego została zmieniona na nową rolę pg_database_owner. Umożliwia ona każdemu właścicielowi bazy danych posiadanie publicznego schematu bazy danych.
Więcej informacji można znaleźć w informacjach o wersji bazy danych PostgreSQL.
Zmiany bazy danych PostgreSQL 16 z zabezpieczeniami opartymi na rolach
W roli bazy danych PostgreSQL może mieć wiele atrybutów, które definiują jego uprawnienia. Jednym z takich atrybutów jest atrybut CREATEROLE, który jest ważny dla zarządzania bazą danych PostgreSQL użytkowników i ról. W programie PostgreSQL 16 wprowadzono istotne zmiany w tym atrybucie. W programie PostgreSQL 16 użytkownicy z atrybutem CREATEROLE nie mają już możliwości rozdania członkostwu w żadnej roli każdemu; zamiast tego, podobnie jak inni użytkownicy, bez tego atrybutu, mogą rozdać członkostwo tylko w rolach, dla których mają OPCJĘ ADMINISTRATORA. Ponadto w programie PostgreSQL 16 atrybut CREATEROLE nadal umożliwia nieużytkownikowi możliwość aprowizowania nowych użytkowników, jednak mogą oni usuwać tylko utworzonych przez siebie użytkowników. Próby porzucania użytkowników, które nie są tworzone przez użytkownika za pomocą atrybutu CREATEROLE , spowodują błąd.
Usługa PostgreSQL 16 wprowadziła również nowe i ulepszone wbudowane role. Nowa rola pg_use_reserved_connections w usłudze PostgreSQL 16 umożliwia korzystanie z miejsc połączenia zarezerwowanych za pośrednictwem reserved_connections. Rola pg_create_subscription umożliwia superużytkownikom tworzenie subskrypcji.
Ważne
Azure Database for PostgreSQL — serwer elastyczny nie zezwala użytkownikom na przyznawanie pg_write_all_data atrybutu, który umożliwia użytkownikowi zapisywanie wszystkich danych (tabel, widoków, sekwencji), tak jak w przypadku praw INSERT, UPDATE i DELETE dla tych obiektów oraz praw UŻYTKOWANIA we wszystkich schematach, nawet bez jawnego udzielenia. Aby obejść ten problem, zalecamy przyznanie podobnych uprawnień na bardziej skończonym poziomie dla bazy danych i obiektu.
Zabezpieczenia na poziomie wiersza
Zabezpieczenia na poziomie wiersza to funkcja zabezpieczeń na poziomie wiersza usługi Azure Database for PostgreSQL — serwer elastyczny, która umożliwia administratorom bazy danych definiowanie zasad w celu kontrolowania sposobu wyświetlania i działania określonych wierszy danych dla co najmniej jednej roli. Zabezpieczenia na poziomie wiersza to dodatkowy filtr, który można zastosować do tabeli bazy danych usługi Azure Database for PostgreSQL — serwer elastyczny. Gdy użytkownik próbuje wykonać akcję w tabeli, ten filtr jest stosowany przed kryteriami zapytania lub innymi filtrami, a dane są zawężone lub odrzucane zgodnie z zasadami zabezpieczeń. Możesz utworzyć zasady zabezpieczeń na poziomie wiersza dla określonych poleceń, takich jak SELECT, INSERT, UPDATE i DELETE, określ je dla wszystkich poleceń. Przypadki użycia zabezpieczeń na poziomie wiersza obejmują implementacje zgodne ze standardami PCI, środowiska sklasyfikowane oraz współużytkowanie aplikacji hostingowych/wielodostępnych.
Tylko użytkownicy z prawami SET ROW SECURITY mogą stosować prawa zabezpieczeń wierszy do tabeli. Właściciel tabeli może ustawić zabezpieczenia wierszy w tabeli. Podobnie jak OVERRIDE ROW SECURITY obecnie jest to niejawne prawo. Zabezpieczenia na poziomie wiersza nie zastępują istniejących GRANT uprawnień, dodaje bardziej szczegółowy poziom kontroli. Na przykład ustawienie ROW SECURITY FOR SELECT zezwalające użytkownikowi na nadawanie wierszy dałoby użytkownikowi dostęp tylko wtedy, gdy użytkownik ma SELECT również uprawnienia do danej kolumny lub tabeli.
Oto przykład pokazujący, jak utworzyć zasady, które gwarantują, że tylko członkowie niestandardowej roli "menedżer" będą mogli uzyskiwać dostęp tylko do wierszy dla określonego konta. Kod w poniższym przykładzie został udostępniony w dokumentacji bazy danych PostgreSQL.
CREATE TABLE accounts (manager text, company text, contact_email text);
ALTER TABLE accounts ENABLE ROW LEVEL SECURITY;
CREATE POLICY account_managers ON accounts TO managers
USING (manager = current_user);
Klauzula USING niejawnie dodaje klauzulę WITH CHECK , zapewniając, że członkowie roli menedżera nie mogą wykonywać SELECToperacji , DELETEani UPDATE na wierszach należących do innych menedżerów i nie INSERT mogą tworzyć nowych wierszy należących do innego menedżera.
Zasady zabezpieczeń wiersza można usunąć przy użyciu polecenia DROP POLICY, jak w swoim przykładzie:
DROP POLICY account_managers ON accounts;
Mimo że zasady mogły zostać usunięte, menedżer ról nadal nie może wyświetlić żadnych danych należących do innego menedżera. Dzieje się tak, ponieważ zasady zabezpieczeń na poziomie wiersza są nadal włączone w tabeli accounts. Jeśli zabezpieczenia na poziomie wiersza są domyślnie włączone, usługa PostgreSQL używa zasad odmowy domyślnej. Zabezpieczenia na poziomie wiersza można wyłączyć, jak pokazano poniżej:
ALTER TABLE accounts DISABLE ROW LEVEL SECURITY;
Pomijanie zabezpieczeń na poziomie wiersza
Usługa PostgreSQL ma uprawnienia BYPASSRLS i NOBYPASSRLS , które można przypisać do roli; NOBYPASSRLS jest domyślnie przypisywany. W przypadku nowo aprowizowania serwerów w usłudze Azure Database for PostgreSQL — serwer elastyczny pomijając uprawnienia zabezpieczeń na poziomie wiersza (BYPASSRLS) jest implementowany w następujący sposób:
- W przypadku serwerów Postgres 16 i nowszych, stosujemy standardowe zachowanie bazy danych PostgreSQL 16. Użytkownicy niebędący administratorami utworzonymi przez rolę administratora azure_pg_admin umożliwiają tworzenie ról za pomocą atrybutu BYPASSRLS\privilege zgodnie z potrzebami.
- W przypadku serwerów Postgres 15 i nowszych. , można użyć azure_pg_admin użytkownika do wykonywania zadań administracyjnych, które wymagają uprawnień BYPASSRLS, ale nie można utworzyć użytkowników niebędących administratorami z uprawnieniami BypassRLS, ponieważ rola administratora nie ma uprawnień administratora, tak jak często w usługach PaaS PostgreSQL opartych na chmurze.
Aktualizowanie haseł
Aby zapewnić lepsze bezpieczeństwo, dobrym rozwiązaniem jest okresowe obracanie haseł administratora i haseł użytkowników bazy danych. Zaleca się używanie silnych haseł przy użyciu wyższej i małej litery, cyfr i znaków specjalnych.
Korzystanie z protokołu SCRAM
Mechanizm uwierzytelniania odpowiedzi na żądanie (Salted Challenge Response Authentication) znacznie poprawia bezpieczeństwo uwierzytelniania użytkowników opartego na hasłach, dodając kilka kluczowych funkcji zabezpieczeń, które zapobiegają atakom typu rainbow-table, atakom typu man-in-the-middle i przechowywanym atakom na hasła, a jednocześnie dodaje obsługę wielu algorytmów tworzenia skrótów i haseł, które zawierają znaki inne niż ASCII.
W przypadku uwierzytelniania SCRAM klient uczestniczy w wykonywaniu szyfrowania w celu wygenerowania dowodu tożsamości. W związku z tym uwierzytelnianie SCRAM odciąża niektóre koszty obliczeń dla swoich klientów, co w większości przypadków to serwery aplikacji. Wdrożenie protokołu SCRAM, oprócz silniejszego algorytmu skrótu, w związku z tym zapewnia również ochronę przed atakami DDoS (distributed denial-of-service) na PostgreSQL, uniemożliwiając przeciążenie procesora CPU serwera do obliczania skrótów haseł.
Jeśli sterownik klienta obsługuje protokół SCRAM, możesz skonfigurować dostęp do usługi Azure Database for PostgreSQL — serwer elastyczny przy użyciu protokołu SCRAM jako scram-sha-256 domyślnego.md5
Resetowanie hasła administratora
Postępuj zgodnie z instrukcjami, aby zresetować hasło administratora.
Aktualizowanie hasła użytkownika bazy danych
Za pomocą narzędzi klienckich można aktualizować hasła użytkowników bazy danych.
Przykład:
ALTER ROLE demouser PASSWORD 'Password123!';
ALTER ROLE
Obsługa usługi Azure Policy
Usługa Azure Policy pomaga wymuszać standardy organizacyjne i oceniać zgodność na dużą skalę. Za pośrednictwem pulpitu nawigacyjnego zgodności udostępnia zagregowany widok umożliwiający ocenę ogólnego stanu środowiska, z możliwością przechodzenia do szczegółów poszczególnych zasobów i zasad. Pomaga również zapewnić zgodność zasobów dzięki korygowaniu zbiorczemu istniejących zasobów i automatycznemu korygowaniu nowych zasobów.
Wbudowane definicje zasad
Wbudowane zasady są opracowywane i testowane przez firmę Microsoft, zapewniając, że spełniają one typowe standardy i najlepsze rozwiązania, które można szybko wdrożyć bez konieczności dodatkowej konfiguracji, co czyni je idealnymi dla standardowych wymagań dotyczących zgodności. Wbudowane zasady często obejmują powszechnie rozpoznawane standardy i struktury zgodności.
Poniższa sekcja zawiera indeks wbudowanych definicji zasad usługi Azure Policy dla usługi Azure Database for PostgreSQL — serwer elastyczny. Użyj linku w kolumnie Źródło, aby wyświetlić źródło w repozytorium GitHub usługi Azure Policy.
| Nazwa (witryna Azure Portal) | Opis | Efekty | Version(GitHub) |
|---|---|---|---|
| Administrator firmy Microsoft Entra powinien być aprowizowany dla serwerów elastycznych PostgreSQL | Przeprowadź inspekcję aprowizacji administratora entra firmy Microsoft dla serwera elastycznego PostgreSQL, aby włączyć uwierzytelnianie firmy Microsoft Entra. Uwierzytelnianie firmy Microsoft Entra umożliwia uproszczone zarządzanie uprawnieniami i scentralizowane zarządzanie tożsamościami użytkowników bazy danych i innych usługi firmy Microsoft | AuditIfNotExists, Disabled | 1.0.0 |
| Inspekcja przy użyciu narzędzia PgAudit powinna być włączona dla serwerów elastycznych PostgreSQL | Te zasady ułatwiają inspekcję serwerów elastycznych PostgreSQL w środowisku, które nie są włączone do korzystania z narzędzia pgaudit. | AuditIfNotExists, Disabled | 1.0.0 |
| Ograniczanie połączeń powinno być włączone dla serwerów elastycznych PostgreSQL | Te zasady ułatwiają inspekcję serwerów elastycznych PostgreSQL w środowisku bez włączonego ograniczania połączeń. To ustawienie umożliwia tymczasowe ograniczanie przepustowości połączenia na adres IP dla zbyt wielu nieprawidłowych niepowodzeń logowania haseł | AuditIfNotExists, Disabled | 1.0.0 |
| Wdrażanie ustawień diagnostycznych dla serwerów elastycznych PostgreSQL w obszarze roboczym usługi Log Analytics | Wdraża ustawienia diagnostyczne dla serwerów elastycznych PostgreSQL w celu przesyłania strumieniowego do regionalnego obszaru roboczego usługi Log Analytics, gdy w przypadku dowolnego serwera elastycznego PostgreSQL brakuje tego ustawienia diagnostycznego, zostanie utworzone lub zaktualizowane | DeployIfNotExists, Disabled | 1.0.0 |
| Rozłączenia powinny być rejestrowane dla serwerów elastycznych PostgreSQL | Te zasady ułatwiają inspekcję wszystkich serwerów elastycznych PostgreSQL w środowisku bez włączenia log_disconnections | AuditIfNotExists, Disabled | 1.0.0 |
| Wymuszanie połączenia SSL powinno być włączone dla serwerów elastycznych PostgreSQL | Usługa Azure Database for PostgreSQL obsługuje łączenie elastycznego serwera usługi Azure Database for PostgreSQL z aplikacjami klienckimi przy użyciu protokołu SSL (Secure Sockets Layer). Wymuszanie połączeń SSL między serwerem elastycznym bazy danych a aplikacjami klienckimi pomaga chronić przed atakami typu "człowiek w środku", szyfrując strumień danych między serwerem a aplikacją. Ta konfiguracja wymusza, że protokół SSL jest zawsze włączony do uzyskiwania dostępu do serwera elastycznego PostgreSQL | AuditIfNotExists, Disabled | 1.0.0 |
| Tworzenie geograficznie nadmiarowej kopii zapasowej powinno być włączone dla serwerów elastycznych usługi Azure Database for PostgreSQL | Elastyczne serwery usługi Azure Database for PostgreSQL umożliwiają wybranie opcji nadmiarowości dla serwera bazy danych. Można go ustawić na geograficznie nadmiarowy magazyn kopii zapasowych, w którym dane są nie tylko przechowywane w regionie, w którym jest hostowany serwer, ale także jest replikowany do sparowanego regionu w celu zapewnienia opcji odzyskiwania w przypadku awarii regionu. Konfigurowanie magazynu geograficznie nadmiarowego na potrzeby kopii zapasowej jest dozwolone tylko podczas tworzenia serwera | Inspekcja, wyłączone | 1.0.0 |
| Punkty kontrolne dziennika powinny być włączone dla serwerów elastycznych PostgreSQL | Te zasady ułatwiają inspekcję serwerów elastycznych PostgreSQL w środowisku bez włączonego ustawienia log_checkpoints | AuditIfNotExists, Disabled | 1.0.0 |
| Połączenia dzienników powinny być włączone dla serwerów elastycznych PostgreSQL | Te zasady ułatwiają inspekcję serwerów elastycznych PostgreSQL w środowisku bez włączonego ustawienia log_connections | AuditIfNotExists, Disabled | 1.0.0 |
| Serwery PostgreSQL FlexIble powinny używać kluczy zarządzanych przez klienta do szyfrowania danych magazynowanych | Użyj kluczy zarządzanych przez klienta, aby zarządzać szyfrowaniem magazynowanych serwerów elastycznych PostgreSQL. Domyślnie dane są szyfrowane w spoczynku przy użyciu kluczy zarządzanych przez usługę, ale klucze zarządzane przez klienta są często wymagane do spełnienia standardów zgodności z przepisami. Klucze zarządzane przez klienta umożliwiają szyfrowanie danych przy użyciu klucza usługi Azure Key Vault utworzonego i należącego do Ciebie. Masz pełną kontrolę i odpowiedzialność za cykl życia klucza, w tym rotację i zarządzanie | Inspekcja, Odmowa, Wyłączone | 1.0.0 |
| Serwery elastyczne PostgreSQL powinny mieć uruchomiony protokół TLS w wersji 1.2 lub nowszej | Te zasady ułatwiają inspekcję wszystkich serwerów elastycznych PostgreSQL w środowisku, które są uruchomione z protokołem TLS w wersji mniejszej niż 1.2 | AuditIfNotExists, Disabled | 1.0.0 |
| Prywatny punkt końcowy powinien być włączony dla serwerów elastycznych PostgreSQL | Połączenia prywatnych punktów końcowych wymuszają bezpieczną komunikację, włączając prywatną łączność z usługą Azure Database for PostgreSQL. Skonfiguruj połączenie prywatnego punktu końcowego, aby umożliwić dostęp do ruchu pochodzącego tylko ze znanych sieci i uniemożliwić dostęp ze wszystkich innych adresów IP, w tym na platformie Azure | AuditIfNotExists, Disabled | 1.0.0 |
Definicje zasad niestandardowych
Zasady niestandardowe można precyzyjnie dostosować do określonych wymagań organizacji, w tym unikatowych zasad zabezpieczeń lub mandatów zgodności. Dzięki niestandardowym zasadom masz pełną kontrolę nad logiką i parametrami zasad, co pozwala na zaawansowane i szczegółowe definicje zasad.