Рекомендации по безопасности для рабочих нагрузок Oracle в акселераторе целевой зоны Azure Виртуальные машины
В этой статье описывается, как безопасно запускать рабочие нагрузки Oracle в Azure Виртуальные машины акселератор целевой зоны на каждом этапе их жизненного цикла. В этой статье рассматриваются определенные компоненты проектирования и содержатся подробные рекомендации по обеспечению безопасности инфраструктуры Azure как службы (IaaS) для рабочих нагрузок Oracle.
Обзор
Безопасность важна для любой архитектуры. Azure предлагает широкий спектр средств для эффективной защиты рабочей нагрузки Oracle. Цель этой статьи — предоставить рекомендации по безопасности для плоскости управления Azure, связанной с рабочими нагрузками приложений Oracle, развернутыми на Виртуальные машины. Подробные сведения и рекомендации по реализации мер безопасности в Базе данных Oracle см . в руководстве по безопасности Базы данных Oracle.
Большинство баз данных хранят конфиденциальные данные. Реализация безопасности только на уровне базы данных недостаточно для защиты архитектуры, в которой развертываются эти рабочие нагрузки. Глубокая защита — это комплексный подход к безопасности, реализующий несколько уровней механизмов защиты для защиты данных. Вместо того чтобы полагаться на одну меру безопасности на определенном уровне, например сосредоточиться только на механизмах сетевой безопасности, стратегия защиты использует сочетание различных мер безопасности уровня для создания надежной системы безопасности. Вы можете разработать подробный подход к защите рабочих нагрузок Oracle с помощью надежной платформы проверки подлинности и авторизации, защищенной сетевой безопасности и шифрования неактивных данных и передаваемых данных.
Рабочие нагрузки Oracle можно развернуть как облачную модель IaaS в Azure. Вернитесь к матрице общей ответственности для более четкого понимания конкретных задач и обязанностей, назначенных поставщику облачных услуг и клиенту. Дополнительные сведения см. в статье Общая ответственность в облаке.
Следует периодически оценивать службы и технологии, используемые для обеспечения соответствия мер безопасности изменяющимся ландшафтом угроз.
Использование централизованного управления удостоверениями
Управление удостоверениями — это фундаментальная платформа, которая управляет доступом к важным ресурсам. Управление удостоверениями становится критически важным при работе с различными типами персонала, такими как временные интерны, сотрудники с неполным временем или полный рабочий день. Эти сотрудники требуют различных уровней доступа, которые необходимо отслеживать, поддерживать и быстро отменять при необходимости. Существует четыре отдельных варианта использования управления удостоверениями, которые следует учитывать для рабочих нагрузок Oracle, и для каждого варианта использования требуется другое решение для управления удостоверениями.
Приложения Oracle: пользователи могут получать доступ к приложениям Oracle без необходимости повторного ввода учетных данных после того, как они авторизованы с помощью единого входа. Используйте интеграцию идентификатора Microsoft Entra для доступа к приложениям Oracle. В следующей таблице перечислены поддерживаемые стратегии единого входа для каждого решения Oracle.
Приложение Oracle Ссылка на документ E-Business Suite (EBS) Включение единого входа для EBS R12.2 JD Эдвардс (JDE) Настройка единого входа JDE PeopleSoft; Включение единого входа для PeopleSoft Гиперион Документация по поддержке Oracle #2144637.1 Siebel Документация по поддержке Oracle #2664515.1 Безопасность на уровне операционной системы (ОС): рабочие нагрузки Oracle могут выполняться в различных вариантах ОС Linux или ОС Windows. Организации могут повысить безопасность виртуальных машин Windows и Linux в Azure, интегрируя их с идентификатором Microsoft Entra. Дополнительные сведения см. в разделе:
- Войдите на виртуальную машину Linux в Azure с помощью идентификатора Microsoft Entra и OpenSSH.
- По состоянию на июль 2023 года Oracle Linux (OL) и Red Hat Enterprise Linux (RHEL) совместимы с двоичными файлами 100 %, что означает, что любые инструкции, связанные с RHEL, применимы к OL.
- По состоянию на июль 2023 года IBM перестала делиться исходным кодом RHEL. Возможно, что OL и RHEL могут разойтиться в будущем, что приведет к недопустимости предыдущей инструкции.
- Войдите на виртуальную машину Windows в Azure с помощью идентификатора Microsoft Entra.
- Войдите на виртуальную машину Linux в Azure с помощью идентификатора Microsoft Entra и OpenSSH.
Azure Key Vault для хранения учетных данных: Key Vault — это мощный инструмент для облачных приложений и служб, которые можно использовать для защиты хранения секретов, таких как пароли и строка подключения базы данных. Key Vault можно использовать для хранения учетных данных для виртуальных машин Windows и Linux в централизованном и безопасном режиме независимо от ОС.
- Вы можете избежать необходимости хранить учетные данные в виде обычного текста в файлах кода или конфигурации с помощью Key Vault. Вы можете получить учетные данные из Key Vault во время выполнения, который добавляет дополнительный уровень безопасности в приложение и помогает предотвратить несанкционированный доступ к виртуальным машинам. Key Vault легко интегрируется с другими службами Azure, такими как Виртуальные машины, и вы можете управлять доступом к Key Vault с помощью идентификатора Microsoft Entra. Этот процесс гарантирует, что доступ к сохраненным учетным данным может получить только авторизованные пользователи и приложения.
Защищенные образы ОС. Центр безопасности Интернета (CIS) защищенный образ для Windows или Linux в Azure имеет несколько преимуществ. Тесты CIS по всему миру признаны лучшими рекомендациями по защите ИТ-систем и данных. Эти образы предварительно настроены для удовлетворения рекомендаций по безопасности CIS, которые могут сэкономить время и усилия в обеспечении защиты ОС. Защищенные образы ОС могут помочь организациям повысить уровень безопасности и соответствовать платформам безопасности, таким как Национальный институт стандартов и технологий (NIST) и периферийных компонентов Interconnect (PCI).
Ужесточение ОС
Убедитесь, что ОПЕРАЦИОННая система ужесточена, чтобы устранить уязвимости, которые можно использовать для атаки на базу данных Oracle.
- Используйте пары ключей Secure Shell (SSH) для доступа к учетной записи Linux вместо паролей.
- Отключите учетные записи Linux, защищенные паролем, и включите их только по запросу в течение короткого периода.
- Отключите доступ для привилегированных учетных записей Linux (корневой или Oracle), который разрешает вход только к персонализированным учетным записям.
- Вместо прямого входа используйте sudo для предоставления доступа к привилегированным учетным записям Linux из персонализированных учетных записей.
- Запись журналов аудита Linux и журналов доступа sudo в журналах Azure Monitor с помощью служебной программы SYSLOG Для Linux.
- Применение исправлений безопасности и исправлений ОС или регулярное обновление из надежных источников.
- Реализуйте ограничения, чтобы ограничить доступ к ОС.
- Ограничение несанкционированного доступа к серверу.
- Управление доступом к серверу на уровне сети для повышения общей безопасности.
- Рассмотрите возможность использования управляющей программы брандмауэра Linux для локальной защиты в дополнение к группам безопасности сети Azure (NSG).
- Настройте управляющая программа брандмауэра Linux для автоматического запуска.
- Проверьте сетевые порты, прослушиваемые для понимания потенциальных точек доступа, и убедитесь, что группы безопасности сети Azure или управляющая программа брандмауэра Linux управляют доступом к этим портам. Используйте команду
netstat –l
Linux для поиска портов. - Псевдоним потенциально разрушительных команд Linux, таких как
rm
иmv
, чтобы принудительно применить их в интерактивном режиме, чтобы вам было предложено по крайней мере один раз перед выполнением необратимой команды. При необходимости расширенные пользователи могут запускать команду unalias. - Настройте единые системные журналы базы данных Oracle для отправки копий журналов аудита Oracle в журналы Azure Monitor с помощью служебной программы SYSLOG Для Linux.
Использование сетевой безопасности
Безопасность сети является основным компонентом многоуровневого подхода к безопасности для рабочих нагрузок Oracle в Azure.
Используйте группы безопасности сети. С помощью группы безопасности сети Azure можно фильтровать сетевой трафик между ресурсами Azure в виртуальной сети Azure. Группа безопасности содержит правила безопасности, разрешающие или запрещающие входящий сетевой трафик к ресурсам Azure или исходящий сетевой трафик из ресурсов Azure. Группы безопасности сети могут фильтровать трафик между локальными сетями в Azure и из Azure с помощью диапазонов IP-адресов и определенных портов. Дополнительные сведения см. в разделе "Группа безопасности сети".
В следующей таблице перечислены назначения входящих портов для виртуальных машин базы данных Oracle:
Протокол Номер порта Service name Комментарий TCP 22 SSH Порт управления для виртуальных машин Linux TCP 1521 Прослушиватель TNS Oracle Другие номера портов, часто используемые для целей безопасности или балансировки нагрузки подключения TCP 3389 RDP Порт управления для виртуальных машин Windows Решите, как подключиться к виртуальной машине: виртуальная машина, на которой находится рабочая нагрузка базы данных Oracle, должна быть защищена от несанкционированного доступа. Доступ к управлению учитывается из-за более высоких разрешений, необходимых для пользователей управления. В Azure авторизованные пользователи имеют несколько механизмов безопасного управления виртуальной машиной.
- Microsoft Defender для облака JIT-доступ обеспечивает интеллектуальное использование механизмов безопасности сети Azure для предоставления ограниченных времени возможностей для доступа к портам управления на виртуальной машине.
- Бастион Azure — это решение как услуга (PaaS), которое вы развертываете в Azure. Бастион Azure размещает коробку прыжка.
Вы можете использовать любое решение для безопасного управления виртуальной машиной базы данных Oracle. При желании можно объединить оба решения для расширенного многоуровневого подхода.
Как правило, JIT-доступ сводит к минимуму, но не устраняет риск, ограничивая время, когда доступны порты управления для SSH или RDP. JIT оставляет возможность доступа к другим сеансам с хвостом во время полученного окна JIT. Такие хвосты по-прежнему должны нарушиться мимо предоставленных портов SSH или RDP, поэтому риск воздействия мал. Однако такие воздействия могут сделать JIT-доступ менее приемлемым для блокировки доступа из открытого Интернета.
Бастион Azure по сути является затверденным полем перехода, который помогает предотвратить доступ из открытого Интернета. Однако существует множество ограничений для Бастиона Azure, которые следует рассмотреть.
Использование X-Windows и виртуальная сеть вычислений (VNC): программное обеспечение базы данных Oracle обычно требует использования X-Windows, так как подключение между виртуальной машиной Linux в Azure и компьютером или ноутбуком может проходить через брандмауэры и группы безопасности Сети Azure. Из-за этого следует использовать перенаправление портов SSH для туннелирования подключений X-Windows или VNC через SSH. Пример использования
-L 5901:localhost:5901
параметра см. в разделе "Открыть клиент VNC" и протестировать развертывание.Параметры взаимодействия между облаком: включение подключения между рабочими нагрузками базы данных Oracle, которые выполняются в Azure и рабочих нагрузках в Oracle Cloud Infrastructure (OCI). Вы можете создавать частные каналы или конвейеры между приложениями с помощью взаимодействия Azure или OCI между определенными регионами в Azure и OCI. Дополнительные сведения см. в статье "Настройка прямого взаимодействия между Azure и Oracle Cloud Infrastructure". Эта статья не охватывает создание брандмауэров на обеих сторонах взаимодействия Azure или OCI, что обычно является требованием для любых входящих или исходящих подключений между облаками. Этот подход использует рекомендации по сети Microsoft Zero Trust.
Безопасность на основе политик Azure
Встроенные определения политик Azure для рабочих нагрузок Oracle в Виртуальные машины акселераторе целевой зоны отсутствуют. Однако Политика Azure предоставляет комплексное покрытие основных ресурсов, используемых любым решением Oracle в Azure, включая виртуальные машины, хранилище и сети. Дополнительные сведения см. в статье Определения встроенных политик в Политике Azure.
Вы также можете создавать настраиваемые политики для решения требований организации к преодолению разрыва. Например, используйте пользовательские политики Oracle для принудительного шифрования хранилища, управления правилами NSG или запрета назначения общедоступного IP-адреса виртуальной машине Oracle.
Использование шифрования для хранения данных
Шифрование передаваемых данных: применяется к состоянию данных, перемещаемых из одного расположения в другое и обычно через сетевое подключение. Данные при передаче можно зашифровать несколькими способами в зависимости от характера подключения. По умолчанию необходимо вручную включить шифрование данных для передаваемых данных в центрах обработки данных Azure. Дополнительные сведения см. в документации azure по шифрованию данных при передаче.
- Рекомендуется использовать функции шифрования сети и целостности данных Oracle в собственном коде. Дополнительные сведения см. в разделе "Настройка собственного сетевого шифрования базы данных Oracle" и целостности данных.
Шифрование неактивных данных: при записи в хранилище необходимо также защитить данные, пока они неактивно. Конфиденциальные данные могут быть предоставлены или изменены при удалении или доступе носителей во время использования. Таким образом, данные должны быть зашифрованы, чтобы гарантировать, что только авторизованные и прошедшие проверку подлинности пользователи могут просматривать или изменять их. Azure предоставляет три уровня шифрования неактивных данных.
- Все данные шифруются на самом низком уровне, когда они сохраняются на любом служба хранилища Azure устройстве с шифрованием на стороне службы хранилища. Шифрование на стороне службы гарантирует, что не нужно удалять или уничтожать носитель хранилища, когда клиент Azure будет выполнен с помощью хранилища. Данные, которые всегда шифруются неактивных данных, могут быть потеряны окончательно, если ключ, управляемый платформой, удаляется. Шифрование на стороне службы быстрее и безопаснее, чем попытка удалить все данные из хранилища.
- Azure также предоставляет возможность двойного шифрования хранимых данных в инфраструктуре хранилища с помощью шифрования инфраструктуры хранилища, который использует два отдельных ключа, управляемых платформой.
- Кроме того, шифрование дисков Azure — это шифрование неактивных данных, управляемое в гостевой ОС (BitLocker для Windows и DM-CRYPT для Linux).
Инфраструктура хранилища имеет до трех возможных уровней шифрования неактивных данных. Если у вас есть параметр Oracle Advanced Security, база данных Oracle также может шифровать файлы базы данных с прозрачным шифрованием данных (TDE) и предоставлять другой уровень шифрования неактивных данных.
Параметр Oracle Advanced Security также предлагает функцию, называемую редактированием данных, которая является формой динамического маскирования данных. При получении данных база данных маскирует значение данных без изменения значения хранимых данных.
Эти несколько уровней шифрования неактивных данных представляют собой само определение глубинной защиты. Если по какой-то причине одна из форм шифрования неактивных данных скомпрометирована, существуют и другие уровни шифрования для защиты данных.
- Управление ключами. Если вы реализуете Oracle TDE в качестве другого уровня шифрования, важно отметить, что Oracle не поддерживает собственные решения по управлению ключами, такие как Key Vault, предоставляемые Azure или другими поставщиками облачных служб. Вместо этого расположение по умолчанию для кошелька Oracle находится в файловой системе виртуальной машины базы данных Oracle.
Дополнительные сведения см. в статье "Подготовка Oracle Key Vault в Azure ", чтобы узнать, как использовать Oracle Key Vault в качестве решения для управления ключами Azure.
Интеграция следов аудита
Мониторинг журналов приложений является важным для обнаружения угроз безопасности на уровне приложения. Используйте решение Microsoft Sentinel для рабочих нагрузок Базы данных Oracle. Соединитель аудита Oracle Database извлекает и получает все записи аудита базы данных Oracle в журналы Azure Monitor с помощью стандартного интерфейса SYSLOG в отрасли. Этот процесс позволяет проверять эти записи вместе с записями аудита инфраструктуры Azure и записями аудита гостевой ОС (Linux или Windows). Решение Microsoft Sentinel — это облачное решение для управления безопасностью и событиями (SIEM), созданное для рабочей нагрузки Oracle, работающей на виртуальной машине Linux или Windows. Дополнительные сведения см. в разделе Соединитель аудита базы данных Oracle для Microsoft Sentinel.
Следующий шаг
Сведения о планировании требований к емкости для рабочих нагрузок Oracle в Azure см. в статье "Планирование емкости" для переноса рабочих нагрузок Oracle в целевые зоны Azure.