Поделиться через

Защита сервера Базы данных Azure для PostgreSQL

База данных Azure для PostgreSQL — это полностью управляемая служба баз данных, которая обеспечивает встроенную высокую доступность, автоматизированные резервные копии и возможности масштабирования. Защита развертываний баз данных PostgreSQL важна для защиты конфиденциальных данных и обеспечения соответствия отраслевым стандартам.

В этой статье описано, как защитить развертывание сервера Базы данных Azure для PostgreSQL.

Это важно

Начиная с 11 ноября 2025 г. в регионах Azure из следующего списка запланирована ротация TLS/SSL-сертификатов с использованием новых промежуточных сертификатов УЦ.

  • центрально-западная часть США
  • East Asia
  • UK South

Начиная с 19 января 2026 г., эта смена планируется распространить на все остальные регионы Azure, включая Azure для государственных организаций и все остальные регионы.

Сведения об устранении неполадок см. в разделе "Проблемы с закреплением сертификатов".

Сетевая безопасность

В разделе "Безопасность сети" описано, как запретить общедоступный доступ и использовать сетевые функции для интеграции PostgreSQL в безопасную сегментированную сетевую архитектуру.

  • Отключение доступа к общедоступной сети. Отключите доступ к общедоступной сети для PostgreSQL, чтобы предотвратить воздействие на Интернет. Это действие гарантирует, что доступ к базе данных может получить только доверенные сети.

  • Частные конечные точки: используйте частные конечные точки для безопасного подключения к PostgreSQL из виртуальной сети.

  • Кроме того, используйте интеграцию виртуальной сети: используйте интеграцию виртуальной сети для подключения PostgreSQL к виртуальной сети. Эта интеграция обеспечивает безопасный доступ из ресурсов Azure и сервера к используемым ресурсам, таким как ИИ.

  • Устаревшие правила брандмауэра и конечные точки службы: если необходимо разрешить доступ с определенных IP-адресов, используйте устаревшие правила брандмауэра и конечные точки службы. Однако этот подход не рекомендуется. Вместо этого предпочитайте использовать частные конечные точки или интеграцию виртуальной сети.

Статьи по безопасности сети приведены в разделах сети:

Управление удостоверениями

В разделе "Управление удостоверениями" основное внимание уделяется проверке подлинности, защите удостоверений и элементам управления доступом с помощью централизованных систем управления удостоверениями и доступом. В ней рассматриваются рекомендации, такие как надежные механизмы проверки подлинности и управляемые удостоверения для приложений.

Ниже приведены некоторые возможные службы безопасности, функции и рекомендации по управлению удостоверениями.

  • Используйте Entra вместо локальной проверки подлинности базы данных: следует запретить локальную проверку подлинности для сервера PostgreSQL. Вместо этого используйте проверку подлинности Microsoft Entra (не смешанный режим) для управления доступом к базе данных. Microsoft Entra обеспечивает централизованную проверку подлинности с строгими элементами управления безопасностью и защитой Defender для удостоверений в режиме реального времени. Дополнительные сведения см. в общем разделе Microsoft Entra и проверке подлинности Microsoft Entra с помощью Базы данных Azure для PostgreSQL.

  • Используйте управляемые удостоверения для безопасного доступа к приложениям: используйте управляемые удостоверения в Azure для безопасной проверки подлинности приложений и служб без необходимости управления учетными данными. Это обеспечивает безопасный и упрощенный способ доступа к ресурсам, таким как База данных Azure для PostgreSQL. Дополнительные сведения см. в разделе "Управляемые удостоверения".

  • Принудительное обеспечение безопасности с помощью политик условного доступа: настройте политики условного доступа в Microsoft Entra для применения элементов управления безопасностью на основе пользовательского, расположения или контекста устройства. Эти политики позволяют динамически применять требования к безопасности на основе риска, повышая общую безопасность. Дополнительные сведения см. в статье об условном доступе Microsoft Entra.

  • Локальная проверка подлинности должна использовать проверку подлинности SCRAM: если необходимо использовать локальную проверку подлинности, убедитесь, что политики надежных паролей применяются. Используйте требования к сложности паролей и обычную смену паролей, чтобы свести к минимуму риск скомпрометированных учетных записей. Дополнительные сведения см. в статье "Проверка подлинности SCRAM" в Базе данных Azure для PostgreSQL.

Управление доступом

В разделе управления доступом основное внимание уделяется защите уровня доступа на основе принципа наименьших привилегий. В ней подчеркивается минимизация риска несанкционированного доступа к конфиденциальным ресурсам путем ограничения и управления повышенными разрешениями, применение многофакторной проверки подлинности и обеспечение регистрации и аудита привилегированных действий.

Ниже приведены некоторые возможные службы безопасности, функции и рекомендации по управлению доступом в разделе:

  • Используйте роли Entra для управления доступом: реализуйте управление доступом в Azure Role-Based (Role-Based управление доступом (RBAC) для управления доступом к ресурсам Базы данных Azure для PostgreSQL. Назначьте роли на основе принципа наименьшей привилегии, гарантируя, что пользователи и приложения имеют только необходимые им разрешения. Дополнительные сведения см. в статье "Управление доступом на основе ролей Azure" (RBAC) и управление ролями Microsoft Entra в Базе данных Azure для PostgreSQL.

  • Следуйте рекомендациям По использованию MFA, политик условного доступа, jIT-доступа для защиты пользователей и баз данных.

  • Управление пользователями, ролями и разрешениями локальной базы данных: используйте встроенное управление ролями PostgreSQL для управления доступом на уровне базы данных. Создайте пользовательские роли с определенными разрешениями, чтобы применить принцип наименьшей привилегии. Регулярно просматривайте и проверяйте эти роли, чтобы обеспечить соответствие политикам безопасности. Дополнительные сведения см. в статье "Создание пользователей в Базе данных Azure для PostgreSQL".

Защита данных

В разделе защиты данных основное внимание уделяется защите конфиденциальных данных, неактивных и передаваемых данных. Это гарантирует, что данные зашифрованы, доступ контролируется, а конфиденциальная информация защищается от несанкционированного доступа. Он подчеркивает использование шифрования, безопасных подключений и маскирования данных для защиты целостности и конфиденциальности данных.

Ниже приведены некоторые возможные службы безопасности, функции и рекомендации для раздела защиты данных:

Шифрование данных при передаче

  • Проверка подключений TLS: Azure PostgreSQL всегда использует протокол SSL или TLS для шифрования данных при передаче между приложением и базой данных. Необходимо настроить приложение для проверки используемого сертификата, например корневого ЦС, просроченных сертификатов, несоответствия имени узла и отзыва сертификатов. Эта практика помогает защитить конфиденциальную информацию от перехвата и атак в середине. Дополнительные сведения см. в статье "Безопасное подключение с помощью TLS и SSL" в Базе данных Azure для PostgreSQL.

  • Убедитесь, что у клиента установлены последние сертификаты TLS: убедитесь, что клиентские приложения имеют последние сертификаты TLS, установленные для поддержки безопасных подключений. Эта практика помогает предотвратить сбои подключения и гарантирует, что приложение может устанавливать безопасные подключения с сервером PostgreSQL. Дополнительные сведения см. в статье "Скачивание сертификатов корневого ЦС" и обновление клиентов приложений.

  • Требовать использование TLS 1.3. Настройте сервер PostgreSQL, чтобы требовать TLS 1.3 для всех подключений. Эта конфигурация гарантирует, что используется только последняя и самая безопасная версия протокола, обеспечивающая лучшую безопасность и производительность. Дополнительные сведения см. в версиях TLS.

Шифрование данных в состоянии покоя

  • Данные всегда прозрачно шифруются с помощью SMK: База данных Azure для PostgreSQL автоматически шифрует неактивных данных с помощью ключей, управляемых службой (SMK). Это шифрование гарантирует защиту данных без дополнительной настройки. Она использует базовую инфраструктуру службы хранилища Azure. Он охватывает основной сервер, реплики, восстановление на определенный момент времени (PITR) и резервные копии. Дополнительные сведения см. в разделе "Шифрование данных" в Базе данных Azure для PostgreSQL.

  • Используйте управляемые клиентом ключи для дополнительного управления: если требуется больше контроля над ключами шифрования, используйте ключи, управляемые клиентом (CMK), хранящиеся в Azure Key Vault или Azure HSM. Этот параметр позволяет управлять ключами шифрования и обеспечивать больше параметров безопасности и соответствия требованиям. Дополнительные сведения см. в разделе "Управляемые клиентом ключи" в Базе данных Azure для PostgreSQL и настройка шифрования данных в Базе данных Azure для PostgreSQL.

  • Настройте автоматическую смену ключей в KV или Managed HSM: если вы используете управляемые клиентом ключи, настройте автоматическую смену ключей в Azure Key Vault, чтобы убедиться, что ключи шифрования регулярно обновляются. База данных Azure для PostgreSQL поддерживает автоматическое обновление версий ключей после смены ключа. Дополнительные сведения см. в статье "Настройка автоматического создания ключей в управляемом HSM Azure " или "Общие сведения об автоматическом подключении" в Azure Key Vault . Дополнительные сведения см. в статье "Настройка шифрования данных с помощью управляемого клиентом ключа во время подготовки сервера " для получения дополнительных сведений о настройке автоматической смены ключей.

  • Шифрование конфиденциальных данных с помощью шифрования на стороне клиента: для ультра-конфиденциальных данных рекомендуется реализовать шифрование на стороне клиента. Этот подход включает шифрование данных перед отправкой в базу данных, гарантируя, что в базе данных хранятся только зашифрованные данные. Эта практика обеспечивает более широкий уровень безопасности, так как сама база данных и, следовательно, администратор базы данных не имеет доступа к незашифрованным данным.

Конфиденциальные вычисления

Конфиденциальные вычисления Azure (ACC) позволяют организациям безопасно обрабатывать конфиденциальные данные и совместно работать с конфиденциальными данными, такими как персональные данные или защищенные сведения о работоспособности (PHI). ACC обеспечивает встроенную защиту от несанкционированного доступа путем защиты данных, используемых с помощью доверенных сред выполнения (TEEs).

  • Поставщики SaaS и поставщики услуг размещения рассмотрите возможность настройки конфиденциальных вычислений. Если вы являетесь поставщиком программного обеспечения как услуга (SaaS) или поставщиком услуг размещения, а рабочие нагрузки PostgreSQL включают обработку конфиденциальных данных, рассмотрите возможность использования конфиденциальных вычислений Azure для защиты используемых данных. Это решение обеспечивает более высокий уровень безопасности, обеспечивая обработку данных в безопасной среде, предотвращая несанкционированный доступ даже от привилегированных пользователей. Дополнительные сведения см. в статье о конфиденциальных вычислениях Azure для Базы данных Azure для PostgreSQL .

Маскирование и редактирование данных

  • Реализация маскирования данных: используйте расширение Анонимизатора PostgreSQL для поддержки:

  • Анонимные дампы: экспорт маскированных данных в SQL-файл.

  • Статическая маскировка: удалите персональные данные в соответствии с правилами.

  • Динамическое маскирование: скрытие персональных данных только для маскированных пользователей.

  • Маскирование представлений: создание выделенных представлений для маскированных пользователей.

  • Маскирование оболочки данных: применение правил маскирования для внешних данных.

Ведение журнала и обнаружение угроз

В разделе "Ведение журнала и обнаружение угроз" рассматриваются элементы управления для обнаружения угроз в средах Azure. В ней рассматриваются возможности включения, сбора и хранения журналов аудита для служб Azure. В ней подчеркивается использование собственных возможностей обнаружения угроз, централизованного управления журналами и правильного хранения журналов для расследований безопасности и соответствия требованиям. В этом разделе рассматривается создание высококачественных оповещений, централизованное анализ безопасности с помощью средств Azure, поддержание точной синхронизации времени и обеспечение эффективных стратегий хранения журналов.

Ниже приведены некоторые возможные службы безопасности, функции и рекомендации по ведению журнала и обнаружению угроз:

Резервное копирование и восстановление

В разделе резервного копирования и восстановления основное внимание уделяется обеспечению регулярного резервного копирования, защиты и восстановления данных и конфигураций в службах Azure. В ней подчеркивается автоматизация резервных копий, защита данных резервного копирования и проверка процессов восстановления для удовлетворения целей времени восстановления (RTO) и целей точки восстановления (RPO). В этом разделе также подчеркивается важность мониторинга и аудита процессов резервного копирования для обеспечения соответствия требованиям и готовности. Дополнительные сведения см. в разделе "Обзор непрерывности бизнес-процессов" с помощью Базы данных Azure для PostgreSQL.

Ниже приведены некоторые возможные службы безопасности, функции и рекомендации по обнаружению резервных копий и восстановления.

  • Используйте высокий уровень доступности. Реализуйте конфигурации высокого уровня доступности для гибкого экземпляра сервера PostgreSQL, чтобы свести к минимуму время простоя и обеспечить непрерывный доступ к базе данных. Дополнительные сведения см. в статье "Высокий уровень доступности( надежность) в Базе данных Azure для PostgreSQL и настройка высокой доступности.

  • Настройка автоматических резервных копий. База данных Azure для PostgreSQL автоматически выполняет ежедневные резервные копии файлов базы данных и постоянно создает резервные копии журналов транзакций. Резервные копии можно хранить с семи дней до 35 дней. Сервер базы данных можно восстановить в любой момент времени в течение периода хранения резервных копий. RTO зависит от размера данных для восстановления и времени восстановления журнала. Он может варьироваться от нескольких минут до 12 часов. Дополнительные сведения см. в статье "Резервное копирование и восстановление" в Базе данных Azure для PostgreSQL.

  • Настройка реплик чтения: используйте реплики чтения для разгрузки операций чтения с сервера-источника, повышения производительности и доступности. Вы также можете использовать реплики чтения для сценариев аварийного восстановления, что позволяет быстро переключиться на реплику с ошибкой сервера-источника. Дополнительные сведения см. в репликах чтения в Базе данных Azure для PostgreSQL.

  • Защита данных резервного копирования с помощью шифрования ключей, управляемых клиентом: защита данных резервного копирования с помощью шифрования неактивных данных.

Связанный контент

  • Last updated on