Используя Intel AMT внутри какой-то большой сети вполне логично возникает вопрос использования двусторонней (mutual, взаимной, клиент-серверной и другие подобные термины) аутентификации, т.е. когда при создании HTTPS-соединения идёт проверка не только сертификата сервера (в таком случае - АМТ-компьютера), но и обратный процесс, когда сервер (АМТ-компьютер) проверяет сертификат запрашивающей стороны (того, кто хочет им управлять). И лишь только после успешной проверки покажет привычный web-интерфейс или даст доступ, например, Командиру.

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

И если у него не будет правильного, то получит отлуп:

Подобная защита является распространённой в критически важных системах, настроим такую же и для Intel AMT.

Для этого я сначала проверяю/устанавливаю сертификаты на АМТ-компьютер, где будет настроена mutual-аутентификация. Захожу на нужный АМТ-компьютер с помощью Командира:

В закладке Security переходим в хранилище сертификатов:

Смотрим какие стоят доверенные root-сертификаты:

В моём случае тут два - один, как видно, остался от предыдущей работы этого компьютера с MeshCentral-сервером. Это не важно, важно лишь то, что АМТ-компьютер будет согласится принять лишь сертификат выданный от имени этих рутов, т.е. будет проверять, что представленный пытающейся присоединиться стороной сертфикат в качестве рута имеет один из этого списка.

Итак, проверили, запомнили и, если нужно, экспортировали или, наоборот, установили нужный трастовый рут.
Далее главная закладка - настройки TLS. В общем случае она обычно имеет следующий вид:

Внизу стоит галка "Accept Non-TLS Connectoins", что обозначает, что ваш АМТ-компьютер будет доступен также и без HTTPS (т.е. на порту 16992) - снимаем.

Далее ставим галку "Include Remote Authentication (Console)", которая как раз и включает проверку АМТ-компьютером сертификата удалённого сервера, который хочет им управлять. Появятся дополнительные настройки:

• Trusted Root Certificates — показывает сколько/какие рут-сертфикаты имются в хранилище сертификатов.
• Trusted Certificate Names — позволяет перечислить FQDN-имена (именно FQDN, имена из одного слова дадут ошибку), которые примет АМТ-компьютер в процессе mutual-аутентификации. Это первая стадия проверки - только имена/шаблоны из данного списка, обязательная стадия проверки их рут-сертификатов также остаётся.

Реальной какой-то привязки к домену нет, т.е. нет проверки, что запрос пришёл именно с такого-то сайта. Потому указывать можно любой, лишь в FQDN-форме и лишь с условием после получить сертификат, подписанный рутом из списка доверенных в хранилище АМТ-сертификатов.

Для этого я на компьютере, где когда-то создавался рут-сертификат AMT-guide запускаю Manageability Director и создаю новый сертификат с именем "apple.rom" от имени рута AMT-guide, который имеется в доверенных на АМТ-компьютере:

Ещё раз повторюсь на счёт имени, специально выбрал не существующее "apple.rom", чтобы показать, что связи с реальными адресами нет, потому Common Name можно было выбирать любым, лишь в FQDN-формате.

Полученный сертификат экспортирую в pfx:

И ставлю его на систему, с которой планирую управлять АМТ-компьютером.

В результате при запросе можно указать данный сертификат:

После проверки получаем доступ к привычной консоли:

В случае Командира проще: ничего указывать не надо, он сам переберёт все установленные в системе сертификаты и если найдёт подходящий - автоматически подключится к АМТ-компьютеру.

Итого, отключение доступа без TLS + взаимная аутентификация = максимальная защита вашего АМТ-компьютера.

п.с. Напоминаю, что VNC-порт для Intel AMT KVM не получится защитить подобным образом.