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

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

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

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

Это важно

Microsoft меняет TLS-сертификаты для базы данных Azure Database для PostgreSQL, чтобы обновить удостоверяющий центр и результирующую цепочку сертификатов.

Если конфигурация клиента использует рекомендуемые конфигурации для TLS, вам не нужно предпринимать действий.

Расписание смены промежуточного сертификата:

  • Обновления для регионов Azure западной части США и Восточной Азии завершены.
  • Обновления для регионов Юг Великобритании и правительственные регионы США начинаются 21 января 2026 года.
  • Обновления для центра США начинаются 26 января 2026 г.
  • Обновления для всех остальных регионов начинаются 28 января 2026 г.

Расписание смены корневого сертификата:

  • Обновления сертификатов корневого ЦС от DigiCert Global Root CA (G1) до DigiCert Global Root G2 в регионах Китая начинаются с 9 марта 2026 г.

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

В разделе "Безопасность сети" описано, как запретить общедоступный доступ и использовать сетевые функции для интеграции 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 Access Control (RBAC) для управления доступом к ресурсам Azure Database для PostgreSQL. Назначьте роли на основе принципа наименьшей привилегии, гарантируя, что пользователи и приложения имеют только необходимые им разрешения. Дополнительные сведения см. в статье "Управление доступом на основе ролей Azure" (RBAC) и управление ролями Microsoft Entra в Базе данных Azure для PostgreSQL.

  • Следуйте лучшим практикам Entra: используйте многофакторную аутентификацию (MFA), политики условного доступа и доступ "just in time" (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" для получения дополнительной информации о 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 Database for PostgreSQL.

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

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

  • Last updated on