Как проверить безопасность BMC на сервере?

Начните с фиксации исходного состояния: модели сервера и BMC, версии firmware, IP-адреса, активных служб, учётных записей, ролей, сертификата и внешней аутентификации. Убедитесь, что подготовлен и проверен физический, локальный или иной утверждённый break-glass-путь. Далее проверьте, что firmware подобрана и обновлена для точной модели и поколения оборудования. BMC должна находиться в выделенной или логически изолированной сети управления, без публикации в интернете. На сетевом уровне разрешайте подключения только от утверждённых рабочих мест, VPN или bastion host и только к нужным службам; результат нужно проверить как с разрешённой, так и с запрещённой сети. Проверьте отсутствие заводских и общих административных учётных записей, наличие персональных аккаунтов с минимальными правами и защищённого локального аварийного доступа. Для веб-интерфейса должно использоваться TLS с сертификатом, соответствующим DNS-имени и доверенным клиентами. HTTP без TLS, Telnet и остальные неиспользуемые службы следует отключать, каждый раз проверяя сохранение нужных функций.

Что включить в чек-лист hardening BMC?

Минимальный чек-лист hardening BMC должен содержать: точную идентификацию сервера, контроллера и версии firmware; сохранение конфигурации, списка служб, аккаунтов, ролей и сетевых параметров; подтверждённый break-glass-доступ до любых изменений. Перед настройкой ограничений определите, какие функции действительно нужны: веб-интерфейс, SSH, Redfish, SNMP, IPMI over LAN, удалённая консоль и virtual media. Обновляйте firmware только пакетом для точной модели, с учётом зависимостей и требований к промежуточным версиям. После обновления подтвердите версию, сеть, журналы и работу консоли. Сеть управления должна быть отдельной или логически изолированной. Доступ к BMC разрешайте только от утверждённых источников и только к необходимым протоколам; встроенную фильтрацию IP используйте как дополнительный слой. Замените заводские реквизиты, создайте персональные аккаунты, назначьте минимальные роли и не отключайте локальный аварийный доступ до проверки внешней аутентификации. Настройте доверенный TLS-сертификат и отключите HTTP, Telnet и другие неиспользуемые службы.

Можно ли открыть iDRAC или iLO в интернет?

Нет, интерфейс BMC не следует публиковать в интернете. iDRAC и iLO позволяют управлять питанием, консолью, носителями и параметрами загрузки вне контроля ОС. Размещайте их в изолированной сети управления и разрешайте доступ только от утверждённых администраторских рабочих мест, VPN и/или bastion host.

Что делать, если после обновления BMC пропал доступ?

Сначала учитывайте ожидаемое поведение: после обновления BMC веб-интерфейс может временно стать недоступным, активные сессии могут быть разорваны, а сам контроллер — перезапущен. Не прерывайте операцию и не считайте кратковременную недоступность признаком необходимости немедленно повторить обновление. Если контроллер сообщил об ошибке или доступ не восстановился после завершения операции, зафиксируйте текст сообщения и текущие обстоятельства. Не запускайте пакет повторно без проверки требований производителя: для некоторых моделей важны исходная версия firmware, зависимости от BIOS или других компонентов, а также обязательные промежуточные версии. Используйте подготовленный до работ локальный, физический или иной утверждённый канал восстановления. После возврата доступа проверьте отображаемую версию firmware, сетевую конфигурацию, журналы и требуемую функцию удалённой консоли. Именно поэтому обновления следует выполнять в согласованное окно обслуживания и только при стабильном питании.

Можно ли отключить все локальные аккаунты после настройки LDAP?

Нет, не отключайте все локальные учётные записи, пока не подтверждён сценарий восстановления. Внешняя аутентификация может стать недоступной из-за проблем LDAP, RADIUS, TACACS+ или MFA. Сохраните минимально необходимый локальный break-glass-доступ, храните его секрет вне BMC и регулярно проверяйте вход.

Почему браузер показывает предупреждение при входе в BMC?

Предупреждение означает, что проверка TLS-сертификата не завершилась успешно. Причиной может быть несоответствие DNS-имени, истёкший срок, неполная цепочка сертификатов или недоверенный издатель. Не продолжайте работу, пока не установите причину; для самоподписанного сертификата сначала сверьте отпечаток независимым каналом.

Защита BMC: безопасная настройка iDRAC, iLO и сети управления

iDRAC, iLO и другие BMC следует защищать как отдельные привилегированные компьютеры: обновлять firmware, подключать к изолированной сети управления, пускать только доверенных администраторов и отключать ненужные службы. Не публикуйте интерфейс управления в интернете и не начинайте ограничения, пока не проверен локальный путь восстановления доступа. Возможности контроллера и порядок действий зависят от модели сервера, поколения iDRAC или iLO и версии firmware.

Почему BMC — не обычный сетевой интерфейс

BMC (Baseboard Management Controller) работает независимо от установленной ОС и часто остаётся доступным, когда сервер выключен, завис или ещё не загрузился. iDRAC у Dell и iLO у HPE — реализации BMC с собственными firmware, сетью, учётными записями, веб-интерфейсом и журналами.

Учётная запись BMC обычно позволяет управлять питанием, открывать удалённую консоль, подключать виртуальные носители, менять параметры загрузки и часть аппаратной конфигурации. Поэтому компрометация BMC способна дать атакующему путь к управлению сервером вне контроля ОС. Это отдельная поверхность атаки, а не просто дополнительный IP-адрес сервера.

Не потеряйте канал восстановления

Сброс BMC, изменение его IP-настроек, отключение служб или замена аутентификации могут оборвать удалённое управление. До изменений подготовьте работающий физический или локальный путь: доступ в серверную, локальную консоль либо иной утверждённый способ восстановления. Порядок сброса и восстановления зависит от модели и описан в документации производителя.

О зависимости от версии

Названия разделов веб-интерфейса, кнопок, статусов, набор служб, роли, фильтрация IP-адресов, методы обновления и требования к сертификатам различаются между поколениями iDRAC и iLO, моделями серверов и версиями firmware. Для каждого изменения сверяйтесь с официальным руководством Dell или HPE именно для вашей модели и версии; не переносите путь меню или параметры с другого поколения как универсальные.

1. Зафиксируйте исходное состояние и аварийный доступ

Подготовка к изменению BMC

Цель этапа — иметь сведения для отката и независимый способ вернуть управление, если новая сетевая или аутентификационная настройка не сработает.

1
Идентифицируйте сервер и контроллер
Запишите производителя, модель и поколение сервера, Service Tag Dell или серийный номер HPE, модель BMC, текущую версию firmware и дату последнего обновления. Эти данные нужны для подбора совместимого пакета firmware и руководства. Результат: для каждого сервера есть карточка с точной идентификацией; если данных нет, получите их с шасси, из локальной консоли или существующего интерфейса BMC до начала работ.
2
Сохраните конфигурацию и список доступов
Зафиксируйте текущий IP-адрес или DHCP-назначение BMC, способ подключения — выделенный порт или shared LOM, DNS-имя, активные сетевые службы, учётные записи, их роли, источники доступа, сертификат и параметры внешней аутентификации. Если контроллер поддерживает экспорт конфигурации, сохраните его в защищённом хранилище вместе с датой и моделью. Результат: можно сравнить состояние после изменений и восстановить известные настройки; при отсутствии экспорта документируйте параметры вручную.
3
Определите сценарии эксплуатации
Согласуйте, кому и для чего нужны веб-интерфейс, SSH, Redfish, SNMP, IPMI over LAN, виртуальная консоль и virtual media. Отдельно определите, кто должен получать оповещения и кто владеет BMC. Результат: для каждой включённой службы есть назначение и владелец; службу без сценария пометьте для последующего отключения.
4
Проверьте break-glass-доступ
Подготовьте аварийную учётную запись или физический путь восстановления и проверьте его до смены штатной аутентификации. Аварийный доступ должен быть известен ограниченному кругу ответственных, храниться по правилам управления секретами и регулярно тестироваться. Результат: есть подтверждённый путь входа при недоступности LDAP, RADIUS, TACACS+ или MFA; если тест невозможен, не отключайте локальную аутентификацию.
5
Назначьте окно обслуживания
Выполняйте обновление firmware и изменения, способные перезапустить BMC, в согласованное окно обслуживания. Предупредите пользователей активных виртуальных консолей. Результат: есть время на проверку и откат; если сервер критичен и резервного пути нет, перенесите изменения.

2. Обновите firmware BMC

Firmware BMC — самостоятельный компонент, для которого производитель выпускает исправления, в том числе патчи безопасности. Подбирайте пакет по точной модели и поколению сервера, а не только по названию iDRAC или iLO. Полный процесс приоритизации уязвимостей описан в статье «Управление уязвимостями сервера: CVE, сканирование и приоритизация».

Безопасное обновление firmware BMC

1
Проверьте совместимость и примечания к выпуску
В официальном каталоге и руководстве Dell или HPE найдите firmware для точной модели. Прочитайте требования к исходной версии, зависимостям от BIOS или других компонентов, известным ограничениям и необходимости перезагрузки BMC либо сервера. Результат: выбран совместимый пакет и понятен ожидаемый эффект; если есть требуемая промежуточная версия, соблюдайте указанную производителем последовательность.
2
Зафиксируйте версию и обеспечьте питание
Сохраните текущую версию firmware и конфигурацию, убедитесь в стабильном питании и не запускайте обновление при ожидаемом отключении электропитания. Результат: есть точка сравнения и план восстановления; если питание нестабильно, перенесите работу.
3
Установите пакет поддерживаемым способом
Используйте только способ, предусмотренный документацией для этого поколения: интерфейс BMC, механизм обновления платформы, локальную утилиту или другой штатный путь производителя. Не прерывайте операцию и не закрывайте её из-за кратковременной недоступности веб-интерфейса. Результат: контроллер сообщает об успешном завершении; при ошибке не повторяйте обновление вслепую — сохраните сообщение и сверяйтесь с руководством.
4
Подтвердите доступность после обновления
После завершения заново войдите в BMC, проверьте версию firmware, сетевую конфигурацию, журналы и требуемую функцию удалённой консоли. Активные сессии могут быть разорваны, а BMC может перезапуститься — это зависит от контроллера и пакета. Результат: новая версия отображается, управление восстановлено; если доступ не возвращается, используйте заранее подготовленный локальный путь восстановления.

3. Изолируйте сеть управления и разрешите только нужные источники

BMC не следует делать доступным из интернета. Размещайте его в отдельной или логически изолированной сети управления, а доступ разрешайте только от утверждённых рабочих мест администраторов, VPN и/или бастионного хоста. Сетевая сегментация уменьшает экспозицию, но сама по себе не делает BMC безопасным: нужны правила межсегментного доступа, контроль учётных записей и аудит.

Порт подключения BMC и изолированная сеть решают разные задачи

Решение	Когда применимо	Преимущество	Риск и что проверить
Выделенный физический порт BMC	Есть отдельный порт управления и возможность подключить его к сети управления	Физически отделяет трафик BMC от рабочих интерфейсов сервера	Порт всё равно может оказаться в слишком широкой сети. Проверьте, что к нему не ведут несанкционированные маршруты и что доступ ограничен политикой сети.
Shared LOM — BMC использует общий сетевой адаптер	Нет отдельного кабеля или конструкция сервера предполагает совместное использование LOM	Экономит порт и кабель, позволяет использовать существующую сетевую инфраструктуру	Ошибки сегментации или конфигурации общего адаптера могут раскрыть управление в рабочей сети. Требуются особенно тщательная изоляция и проверка разрешённых потоков.
Выделенная или логически изолированная сеть управления	Когда для BMC используется сетевой удалённый доступ — независимо от выбора отдельного порта или shared LOM	Ограничивает, откуда вообще можно достичь BMC	Не заменяет allowlist, VPN, bastion, аутентификацию и мониторинг.

Ограничение сетевого доступа к BMC

1
Выберите утверждённую точку входа
Определите, какие сети, bastion host или VPN-шлюзы являются единственными источниками административных подключений. Не включайте домашние, гостевые и произвольные корпоративные подсети без обоснованного сценария. Результат: есть короткий список разрешённых источников и протоколов.
2
Настройте ограничение источников на уровне архитектуры
Реализуйте политику доступа в сети управления: разрешайте обращения к BMC только от утверждённых источников и только к нужным службам. Если конкретная модель BMC поддерживает IP filtering или allowlist, используйте её как дополнительный слой, а не как единственную защиту. Результат: с доверенной точки доступны только нужные сервисы, а из неразрешённой сети соединение не устанавливается.
3
Проверьте запрет с независимой точки
После изменения проверьте доступ с разрешённого рабочего места и отдельно попытку соединения из сети, которой доступ не положен. Проверяйте как веб-интерфейс, так и SSH или API, если они включены. Результат: разрешённый путь работает, запрещённый недоступен; если штатный доступ перестал работать, восстановите предыдущее правило до дальнейшей диагностики.

Граница материала

Проектирование VLAN, адресации, маршрутизации, VPN и bastion host здесь не рассматривается как процедура. Требования к такой архитектуре разобраны в статье «Сегментация серверной сети: VPN, bastion host и защищённый административный доступ». Не заменяйте её правилами firewall гостевой ОС: BMC функционирует вне этой ОС.

4. Замените заводские реквизиты и распределите роли

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

Учётные записи, роли и аварийный доступ

1
Создайте новую персональную учётную запись администратора
Создайте отдельную учётную запись для каждого администратора с ролью, достаточной для его задач. Сразу проверьте вход в отдельной сессии, не закрывая текущую. Результат: новый пользователь входит и выполняет только разрешённые операции; если вход не работает, исправьте роль или аутентификацию, не удаляя действующий доступ.
2
Измените или отключите неиспользуемые стандартные аккаунты
После проверки новой учётной записи замените заводской секрет стандартной записи либо отключите её, если это допускает ваш сценарий и документация модели. Не оставляйте общие административные логины для повседневной работы. Результат: нет активной учётной записи с известными или заводскими реквизитами; если стандартная запись нужна для предусмотренного производителем восстановления, защитите её как break-glass-доступ.
3
Настройте роли вместо общей административной роли
Разделите полномочия, если контроллер это поддерживает: мониторинг, работа с консолью, управление питанием, изменение конфигурации и управление пользователями не обязательно должны быть доступны одному человеку. Результат: у оператора нет лишних прав; если предустановленных ролей недостаточно, документируйте остаточный риск и ограничивайте доступ сетевой политикой.
4
Подключите внешнюю аутентификацию только после теста
LDAP/Active Directory, RADIUS, TACACS+ и схемы с многофакторной аутентификацией доступны не на всех iDRAC и iLO и могут требовать отдельной интеграции. Настройте их по руководству модели, проверьте вход тестового пользователя и отказ при отсутствии нужной группы или роли. Результат: внешний пользователь получает корректные права, а локальный аварийный вход сохранён.
5
Защитите аварийную учётную запись
Оставьте минимально необходимый локальный break-glass-доступ, если это требуется для восстановления при недоступности внешнего каталога. Храните секрет вне самого BMC, назначьте владельца и процедуру использования с последующей ротацией. Результат: аварийный доступ не используется ежедневно, но проверен; не отключайте все локальные аккаунты до подтверждения сценария восстановления.

5. Защитите веб-доступ TLS-сертификатом и отключите лишние службы

Для веб-интерфейса BMC включайте защищённое соединение TLS. Сертификат должен соответствовать имени, по которому администраторы открывают BMC; клиент должен проверять имя и доверенную цепочку сертификатов. Предупреждение браузера означает, что проверка не завершилась успешно: причиной может быть несоответствие имени, истёкший срок, неполная цепочка или недоверенный издатель. Не продолжайте работу, не установив причину. Для контролируемого самоподписанного сертификата сначала сверьте отпечаток по независимому каналу и настройте доверие именно к проверенному сертификату.

Выбор источника сертификата для BMC

Вариант	Когда подходит	Условие безопасности
Публичный центр сертификации	BMC открывают по имени в контролируемом публичном домене, а политика организации допускает публично доверенный сертификат	CA должен поддерживать применимый способ подтверждения владения именем. Не публикуйте интерфейс BMC в интернете только ради выпуска или продления сертификата: при возможности используйте проверку через DNS или другой предусмотренный CA способ. Публичные CA не выпускают сертификаты для внутренних имён и частных IP-адресов.
Внутренний центр сертификации	Обычный выбор для внутренней сети управления, включая внутренние DNS-имена	Корневой и промежуточные сертификаты должны быть доверены административным клиентам. Импортируйте сертификат и необходимую цепочку в формате, который поддерживает конкретный BMC.
Самоподписанный сертификат	Изолированная среда малого масштаба, где можно контролируемо распространить доверие к конкретному сертификату	Сверьте отпечаток по независимому каналу, затем установите именно этот сертификат в доверенное хранилище административных клиентов либо применяйте явное закрепление сертификата. Не обходите обычное предупреждение браузера без такой проверки; контролируйте последующую замену сертификата.

Настройка TLS и минимального набора служб

1
Подготовьте сертификат для имени BMC
Определите стабильное DNS-имя интерфейса управления и получите сертификат TLS от внутреннего или публичного CA в соответствии с архитектурой. Проверьте в руководстве модели поддерживаемый контейнер, алгоритм, размер ключа, необходимость промежуточных сертификатов и порядок импорта. Закрытый ключ храните и передавайте как секрет. Результат: подготовлен совместимый сертификат и полная цепочка; если формат не принимается, не меняйте криптографические параметры наугад — сверяйтесь с ограничениями firmware.
2
Импортируйте сертификат и проверьте имя
Импортируйте сертификат штатным механизмом BMC, затем откройте интерфейс по его утверждённому DNS-имени с административной рабочей станции. Проверьте срок, издателя, отсутствие предупреждения о недоверии и соответствие имени. Результат: браузер строит доверенную цепочку; при ошибке имени или цепочки верните рабочий сертификат либо исправьте выпуск до отключения старого пути.
3
Отключите небезопасные и неиспользуемые службы
В первую очередь проверьте необходимость HTTP без TLS и Telnet: обычно их отключают, если нет документированного исключения. Затем сопоставьте остальные службы с утверждёнными сценариями эксплуатации. Результат: включены только нужные протоколы; после каждого отключения повторно проверьте требуемые операции.
4
Проверьте доступ после каждого изменения
Открывайте новую сессию и проверяйте нужную функцию до закрытия старой: веб-интерфейс, консоль, API или SSH. Результат: штатные сценарии работают через разрешённую сеть; если перестала работать виртуальная консоль или автоматизация, временно верните только связанную службу и уточните зависимость в документации модели.

Какие службы BMC проверять на необходимость

Не отключайте функцию только потому, что она кажется лишней: сначала подтвердите сценарий восстановления и зависимости конкретной модели.

Служба или функция	Обычно отключают, если	Что может зависеть от неё
HTTP	Веб-интерфейс доступен по HTTPS	Старые процедуры или инструменты, использующие незашифрованный веб-доступ
Telnet	Нет утверждённого исключения для устаревшего оборудования	Наследуемая автоматизация; безопаснее заменить её поддерживаемым защищённым методом
SSH	Нет CLI-администрирования и автоматизации через SSH	Командное управление, диагностика или скрипты — зависит от BMC
IPMI over LAN	Нет инструментов мониторинга или управления, использующих IPMI	Системы управления инфраструктурой и автоматизация; доступность и настройки различаются по поколениям
Redfish	Нет API-автоматизации или системы управления, использующей Redfish	Современная автоматизация инвентаризации и управления; не предполагайте, что Redfish заменяет IPMI на любой модели
SNMP и traps	Мониторинг не получает данные или оповещения через SNMP	Мониторинг аппаратных событий; при отключении настройте альтернативное наблюдение
Virtual console	Нет потребности в удалённой консоли	Диагностика зависшей ОС, вход в BIOS/UEFI, аварийное восстановление
Virtual media	Нет потребности монтировать ISO или иные носители удалённо	Установка ОС, восстановление и загрузка диагностических носителей

Виртуальная консоль и virtual media — не обязательно лишние

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

6. Включите аудит, внешнюю доставку событий и регулярный контроль

Настройка не закончена, пока изменения BMC можно обнаружить и расследовать. Просматривайте локальные журналы контроллера и, если это поддерживает конкретное поколение, отправляйте события в систему централизованного журналирования, удалённый syslog или через SNMP traps. Состав событий, экспорт и протоколы доставки различаются у iDRAC и iLO.

Проверка аудита и сопровождение BMC

1
Включите и проверьте журналы BMC
Убедитесь, что BMC сохраняет события входа, неудачной аутентификации, изменения конфигурации, операций питания и обновлений firmware, если эти категории доступны для модели. Выполните контролируемый вход тестовой учётной записью и найдите соответствующую запись. Результат: формируется аудиторский след с временем, пользователем и действием; если событие не видно, проверьте включённые категории аудита и синхронизацию времени.
2
Настройте удалённую доставку событий
Если BMC поддерживает удалённый syslog или SNMP traps, настройте утверждённый получатель и проведите тестовое событие. Зафиксируйте, какие поля передаются и кто реагирует на сообщения об изменении настроек, новых пользователях, входах и обновлениях firmware. Результат: тестовое событие видно в приёмнике; если доставка не работает, не считайте локальный журнал достаточной заменой — устраните проблему по документации BMC и платформы сбора.
3
Документируйте конечную конфигурацию
Для каждого BMC запишите владельца, модель, версию firmware, сетевой способ подключения, разрешённые источники, включённые службы, роли, внешние провайдеры аутентификации, сертификат и срок его действия, путь к журналам и процедуру экстренного восстановления. Результат: другой уполномоченный администратор может проверить конфигурацию и восстановить доступ без догадок.
4
Пересматривайте конфигурацию регулярно и после изменений
Периодически проверяйте новые firmware и бюллетени производителя, актуальность пользователей и ролей, срок сертификата, список разрешённых источников, состояние журналирования и работоспособность break-glass-процедуры. Проверяйте то же после замены сетевого оборудования, изменения каталога пользователей или внедрения новой системы мониторинга. Результат: конфигурация не расходится с документированной политикой.

Проверку BMC включают в общий базовый контроль безопасности сервера, но проводят отдельно от проверки гостевой ОС. Для общего baseline и приоритизации мер используйте обзор «Базовая защита сервера: как составить security baseline». Настройка Linux, Windows, SSH, RDP и межсетевого экрана гостевой ОС не заменяет защиту контроллера управления.

Термины в статье

Allowlist: Allowlist — перечень разрешающих записей или правил: система допускает только те субъекты, объекты, действия или значения, которые им соответствуют.
TLS: TLS — криптографический протокол защиты прикладных данных при передаче по сети, обеспечивающий их конфиденциальность и целостность, а также аутентификацию сервера и, при настройке, клиента.
Аварийная учётная запись: Аварийная учётная запись — специально защищённая привилегированная учётная запись для восстановления доступа при отказе штатных средств администрирования или аутентификации.
Аудиторский след: Аудиторский след — упорядоченный по времени набор записей о действиях и изменениях, позволяющий установить, кто, когда, над чем и с каким результатом выполнил операцию, а также откуда поступил запрос.
Бастионный хост: Бастионный хост — специально защищённый промежуточный сервер, через который ограничивают и контролируют административный доступ к системам в изолированных сегментах сети.
Внутренний центр сертификации: Внутренний центр сертификации — контролируемый организацией центр сертификации, выпускающий сертификаты для её систем; доверие к нему на клиентах настраивают явно.
Закрытый ключ: Закрытый ключ — секретная часть асимметричной ключевой пары для создания подписей, расшифрования данных или подтверждения владения ключом при аутентификации.
Многофакторная аутентификация: Многофакторная аутентификация — метод проверки личности, требующий подтверждений из двух или более независимых факторов: знания, владения или биометрии.
Окно обслуживания: Окно обслуживания — согласованный интервал времени для плановых работ с ИТ-системой, когда допустимы ограничение функциональности, перезапуск или недоступность сервиса.
Патч безопасности: Патч безопасности — обновление ПО, ОС или прошивки, устраняющее конкретную уязвимость либо снижающее риск её эксплуатации без обязательного изменения функциональности.
Поверхность атаки: Поверхность атаки — совокупность точек, через которые можно воздействовать на систему или получить к ней доступ; включает интерфейсы, учётные записи, ПО и зависимости.
Привилегированная учётная запись: Привилегированная учётная запись — учётная запись с правами управления системами, данными или политиками доступа, превышающими полномочия обычного пользователя.
Принцип наименьших привилегий: Принцип наименьших привилегий — правило предоставления пользователю, службе или процессу только тех прав и на тот срок, которые необходимы для выполнения конкретной задачи.
Самоподписанный сертификат: Самоподписанный сертификат — сертификат X.509, подписанный закрытым ключом, соответствующим открытому ключу в самом сертификате; автоматически доверенным он не считается.
Сертификат TLS: Сертификат TLS — цифровой документ X.509, содержащий открытый ключ и идентификаторы субъекта и подписанный издателем; доверие к связи определяется цепочкой и политикой клиента.
Сетевая сегментация: Сетевая сегментация — архитектурное разделение сети на изолированные зоны с правилами межзонного обмена, ограничивающее область распространения инцидента.
Централизованное журналирование: Централизованное журналирование — сбор и хранение журналов разных систем в общем сервисе для унифицированного поиска, контроля целостности и анализа.
Цепочка сертификатов: Цепочка сертификатов — последовательность от конечного сертификата через сертификаты центров сертификации к точке доверия, позволяющая проверить подписи и построить путь доверия.