3. Управління доступом та автентифікація

3.1 Хост повинен деактивувати SSH (Автоматизовано)

Secure Shell (SSH) забезпечує віддалений доступ до оболонки ESXi, уможливлюючи прямий хост консольний доступ або віддалене підключення. Деактивація SSH є заходом безпеки при мінімізації каналів віддаленого доступу до хосту ESXi, обмежуючи його основними підключення лише через клієнт vSphere, vCLI/PowerCLI або опубліковані API. The статус служби має бути встановлено на «Зупинено», дозволяючи ручний запуск і зупинку усунення несправностей або діагностичні заходи, коли це необхідно.

Обмеження віддаленого доступу шляхом дезактивації SSH зменшує потенційні вектори атак, сприяючи безпечне робоче середовище. Увімкнення SSH лише для діагностики чи усунення несправностей забезпечує контрольований доступ відповідно до найкращих практик безпеки.

Немає жодного функціонального впливу; однак цей захід вимагає альтернативних методів для віддаленого керування, наприклад vSphere Client або інструменти командного рядка, які можуть вимагати додаткових конфігурацій або володіння набором інструментів.

3.2 Хост повинен деактивувати оболонку ESXi (Автоматизовано)

Оболонка ESXi — це інтерактивне середовище командного рядка, доступне в Direct Консольний інтерфейс користувача (DCUI) або віддалено через SSH. Дії, що виконуються з ESXi Оболонка обходить усі елементи керування доступом, але реєструється. Рекомендоване налаштування для ESXi оболонку слід зупиняти та запускати вручну лише за потреби, наприклад під час роботи діагностику або усунення несправностей.

Переконайтеся, що такі несуттєві служби, як оболонка ESXi, деактивовано, покращує поза безпеки.

Функціональний вплив не зафіксовано. Однак, якщо потрібні функції оболонки ESXi, потрібна ручна активація.

3.4 Хост повинен деактивувати SLP (Вручну)

Протокол розташування служб (SLP) використовується для виявлення та вибору мережі служби в локальних мережах, що спрощує налаштування, дозволяючи комп’ютерам автоматично знаходити необхідні послуги. Практика дезактивації SLP, коли вона не використовується узгоджується з принципом мінімізації поверхні атаки шляхом вимкнення несуттєвих послуги. Рекомендованим налаштуванням є зупинка служби SLP із можливістю запускати та зупиняти його вручну за потреби.

Дезактивація неосновних служб, таких як SLP, мінімізує потенційні вектори атак, тим самим підвищуючи безпеку хоста.

Немає жодного функціонального впливу, однак для запуску потрібне ручне втручання послугу SLP, коли це необхідно.

3.5 Хост повинен деактивувати CIM (Вручну)

Дезактивація служби загальної інформаційної моделі (CIM), коли вона не використовується, узгоджується з принцип мінімізації поверхні атаки шляхом відключення несуттєвих служб. Це дії допомагають зменшити потенційні вектори атаки, таким чином підсилюючи атаку господаря поза безпеки.

Дезактивація неосновних служб, як-от CIM, зменшує потенційні ризики для безпеки пов’язані з цими службами. Цей захід відповідає принципу найменшого функціональність, яка передбачає, що лише необхідні служби повинні бути активними для виконання експлуатаційні вимоги.

Функціональний вплив не визначено. Однак дезактивація CIM може вимагати від адміністраторів вручну запускати або зупиняти службу, коли це можливо, потенційно впливають на робочі процеси, якщо CIM знадобиться на пізнішому етапі.

3.6 Хост повинен деактивувати SNMP (Вручну)

Простий протокол керування мережею (SNMP) полегшує керування мережевих пристроїв. Мінімізуйте поверхню атаки, вимкнувши несуттєві служби. The рекомендованим параметром є зупинка служби SNMP, якщо вона не потрібна налаштовано безпечно.

Дезактивація SNMP, коли вона не потрібна, зменшує площу атаки, дотримуючись a мінімалістичний підхід до роботи сервісу.

Хоча прямого функціонального впливу немає, відсутність SNMP може вимагати альтернативні методи управління та моніторингу мережі.

3.7 Хост повинен автоматично завершувати неактивні сеанси DCUI (Автоматизовано)

Якщо налаштувати тайм-аут сеансу, автоматичні сеанси консолі вмикаються автоматично припинено, тим самим зменшуючи потенційні ризики безпеці, пов’язані з довготривалою активністю сесії. Параметр, який регулює цю поведінку, — це UserVars.DcuiTimeOut із a рекомендоване значення 600 (10 хвилин).

Автоматичне припинення неактивних сеансів DCUI підвищує рівень безпеки за рахунок мінімізація вікна можливостей для несанкціонованого доступу через автоматичний доступ сесії. Він забезпечує належну практику гігієни безпеки, забезпечуючи неактивні сеанси не залишаються відкритими нескінченно довго, що відповідає принципу найменших привілеїв.

Хоча функціональний вплив не вказано, встановлення надто короткого значення часу очікування може створюють незручності користувачам, передчасно припиняючи сесії, можливо перериваючи робочий процес. І навпаки, надто довге значення часу очікування може не пом’якшити належним чином ризики, пов’язані з неактивними сеансами. Отже, зважений підхід до налаштування значення часу очікування сеансу, узгоджене з політикою безпеки організації та робочим процесом користувача, має вирішальне значення.

3.8 Хост повинен автоматично припинити неактивні оболонки (Автоматизовано)

Щоб запобігти, хост має бути налаштований на автоматичне завершення неактивних сеансів оболонки можливий несанкціонований доступ через забуті виходи. Встановлення тайм-ауту для неактивного SSH гарантує, що будь-які неконтрольовані сеанси будуть закриті, тим самим зменшуючи ризик безпеки. Параметр, який регулює цю поведінку, — UserVars.

Автоматичне завершення неактивних оболонок мінімізує ризики, пов’язані з роботою без нагляду сесії. Це проактивний захід для запобігання потенційному несанкціонованому доступу до хосту.

Немає виявленого негативного впливу, пов’язаного із застосуванням цього контролю щоб посилити безпеку господаря.

3.9 Хост повинен автоматично деактивувати служби оболонки (Автоматизовано)

Увімкнення автоматичної деактивації служб оболонки мінімізує поверхню атаки господар. Часове вікно для доступності служб ESXi Shell і SSH визначається UserVars.ESXiShellTimeOut, після чого ці служби припиняються. The рекомендоване значення для цього параметра – 3600.

Автоматичне вимкнення служб оболонки після визначеного періоду часу допомагає зменшити ризик, пов’язаний із потенційним неавторизованим доступом, забезпечуючи більш безпечний ESXi хост-середовище.

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

3.10 Хост не повинен пригнічувати попередження про те, що оболонку ввімкнено (Вручну)

Наявність попереджень для ввімкненого SSH або ESXi Shell дає уявлення про потенційну безпеку ризики. Вимкнення таких попереджень може замаскувати поточні атаки. Параметр, що регулює це поведінка — UserVars.SuppressShellWarning із рекомендованим значенням 0.

Підтримка видимості статусу служби оболонки через попередження має вирішальне значення для моніторингу і раннє виявлення несанкціонованої діяльності, допомагаючи в своєчасному вирішенні потенційних загрози безпеці.

Жодного негативного функціонального впливу цей контроль не пов’язує; це покращує моніторинг і відповідь на потенційні загрози безпеці шляхом забезпечення видимості попереджень, а не видимості пригнічений.

3.11 Хост повинен застосовувати складні паролі (Вручну)

Застосуванням складності пароля керують через Параметр Security.PasswordQualityControl, що дозволяє налаштувати довжину пароля, вимоги до набору символів і обмеження щодо невдалих спроб входу. Рекомендований налаштування: “повторити=3 хв.=вимкнено,15,15,15,15 макс.=64 схоже=заборонити парольну фразу=3”.

Дотримання вказівок NIST 800-63B, розділ 5.1.1.2, не дотримання традиційних правила композиції полегшують прийняття довших, безпечніших парольних фраз, підвищення загальної безпеки.

Зміна складності пароля через Security.PasswordQualityControl може спричинити проблем із встановленням інших продуктів і послуг в екосистемі VMware немає очікуючи таких змін.

3.12 Хост повинен заблокувати обліковий запис після певної кількості невдалих спроб входу (Автоматизовано)

Контроль безпеки передбачає обмеження доступу до облікового запису після певної кількості невдалі спроби входу, діючи як стримуючий фактор проти атак грубої сили. Цей контроль є застосовно для доступу SSH і vSphere Web Services SDK, але не для Direct Інтерфейс консолі (DCUI) і оболонка ESXi. Налаштування за замовчуванням допускає п’ять помилок спроби до блокування облікового запису, з автоматичним розблокуванням через 15 хвилин. Параметр цю поведінку регулює Security.AccountLockFailures із рекомендованим значенням 5.

Впровадження цього контролю підвищує стійкість хоста проти несанкціонованого доступу спроб, зберігаючи цілісність системи. Зриваючи атаки грубої сили, це значно підвищує рівень безпеки, ускладнюючи несанкціонований доступ.

Потенційним недоліком є сценарій ненавмисної відмови в обслуговуванні, особливо з низьким значенням порогове значення для помилок входу. Це може бути використано зловмисно або спрацьовувати випадково блокування, що впливає на доступність системи та, можливо, потребує додаткових адміністративні зусилля для скидання облікового запису.

3.13 Хост повинен розблокувати облікові записи після визначеного періоду очікування (Автоматизовано)

Забезпечення автоматичного розблокування облікових записів користувачів на хості ESXi після a зазначений період сприяє балансу між безпекою та зручністю використання. Цей механізм негайно реактивує неактивні облікові записи, зменшуючи потенціал ризики несанкціонованого доступу. Його налаштовують за допомогою певного параметра, який, коли налаштований, визначає тривалість періоду блокування. Параметр, що регулює це поведінкою є Security.AccountUnlockTime із рекомендованим значенням 900 секунд.

Цей параметр зменшує незручності для нешкідливих користувачів і накладні витрати на адміністраторів, а також уповільнює атаки підбору облікових даних.

Функціональний вплив не помічено. Конфігурація параметра забезпечує безпеку використання балансу, хоча неправильна конфігурація може наразити систему на несанкціонований доступ отримати доступ або порушити роботу користувача.

3.14 Хост повинен налаштувати історію паролів, щоб обмежити повторне використання паролів (Вручну)

Мета полягає в тому, щоб запобігти повторному використанню минулих паролів, діючи як стримуючий фактор проти потенційних порушення безпеки, спричинені використанням старих, скомпрометованих облікових даних. Це досягається шляхом налаштування параметра Security.PasswordHistory, який визначає кількість унікальних паролів, які користувач повинен пройти перед попереднім паролем можна використовувати повторно. Рекомендоване значення цього параметра – 5.

Застосовуючи політику історії паролів, організації ускладнюють роботу зловмисників для отримання несанкціонованого доступу за допомогою старих паролів. Це в свою чергу підвищує загальна безпека.

Вплив зміни параметра Security.PasswordHistory залежить від обране значення. Нижче значення може знизити безпеку, дозволяючи повторне використання пароля швидше, тоді як вище значення підвищує безпеку, але також може збільшити ймовірність розчарування користувача.

3.15 Для хоста має бути налаштовано відповідний максимальний вік пароля (Вручну)

Застосування максимального терміну дії пароля, визначеного Параметр Security.PasswordMaxDays узгоджується з сучасними політиками паролів викладено в розділі 5.1.1.2 NIST 800-63B, який виступає проти примусового періодичного пароля зміни за умови достатньої складності паролів. Параметр керуючий такою поведінкою є Security.PasswordMaxDays із рекомендованим значенням 99999.

Відповідність сучасним стандартам безпеки шляхом налаштування відповідного максимуму password age може допомогти підтримувати баланс між безпекою та зручністю використання. Це налаштування скасовує необхідність періодичної зміни пароля, яка не була показана значно підвищити безпеку.

Налаштування параметра Security.PasswordMaxDays може вплинути на інтерфейси користувача vSphere, вимагаючи адреса електронної пошти для конфігурації сповіщень. Це вимагає або надання ан адресу електронної пошти або використання PowerCLI для налаштування, причому останнє також вимагає налаштування SMTP-сервера на vCenter Server для сповіщень електронною поштою. Різні нормативні рамки відповідності мають різні думки щодо цієї практики.

3.16 Хост повинен налаштувати час очікування сеансу для API (Вручну)

Призначений тайм-аут гарантує, що сеанси не залишаються відкритими на невизначений термін зменшення вікна впливу потенційних загроз безпеці. Параметр керуючий така поведінка є Config.HostAgent.vmacore.soap.sessionTimeout із рекомендованим налаштування 30 секунд.

Час очікування сеансу гарантує, що потенційні загрози безпеці від неавторизованих користувачів або Шкідливе програмне забезпечення, що використовує відкриті сесії, значно зменшується.

Немає функціонального впливу під час налаштування цього елемента безпеки, що робить його a вдосконалення з низьким рівнем ризику для забезпечення безпеки середовища ESXi.

3.17 Хост повинен автоматично завершувати неактивні сеанси клієнта хоста (Вручну)

Налаштування хоста для автоматичного припинення неактивних сеансів хост-клієнта допомагає пом’якшити ризики безпеки, пов’язані з сесіями без нагляду, які потенційно можуть бути використані. Рекомендованим параметром для цього елемента керування є значення тайм-ауту 900. Параметр регулює цю поведінку UserVars.HostClientSessionTimeout.

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

Функціональний вплив не згадується, але забезпечення збалансованого значення часу очікування є необхідний для запобігання випадковому завершенню сеансу, зберігаючи безпеку.

3.18 Хост повинен мати точний DCUI. Список доступу (Вручну)

Параметр DCUI.Access у VMware ESXi використовується для визначення списку користувачів, які дозволено доступ до прямого інтерфейсу користувача консолі (DCUI) хоста ESXi, особливо коли ввімкнено режим блокування. Цей параметр допомагає контролювати і захист доступу до хосту ESXi, дозволяючи лише авторизованим користувачам перевизначати Режим блокування та доступ до DCUI, особливо в сценаріях, коли хост стає ізольованим від vCenter. Параметр, який регулює таку поведінку DCUI.Доступ.

Правильно налаштований список DCUI.Access гарантує, що лише авторизовані користувачі можуть перевизначати Режим блокування для доступу до DCUI, що забезпечує захист від втрати керування особливо якщо хост втрачає з’єднання з vCenter.

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

3.19 Хост повинен мати точний список виняткових користувачів (Вручну)

Створення точного списку виняткових користувачів є важливим для керування привілеями користувачів під час режиму блокування. Користувачі в цьому списку зберігають свої привілеї, що робить їх обов’язковими включати лише ті, які необхідні для прямого доступу до хосту, наприклад облікові записи служб для сторонніх розробників рішення. Забезпечення правильного ведення списку зменшує ризик, пов’язаний із несанкціонованим доступом дії, особливо під час сценаріїв ізоляції хоста в режимі блокування.

Список виняткових користувачів має вирішальне значення для збереження необхідних операційних можливостей підтримуючи безпечне середовище. Ретельно керуючи цим списком, організації може балансувати між безпекою та функціональністю, забезпечуючи критичні операції продовжувати безперешкодно в режимі блокування.

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

3.20 Хост повинен увімкнути режим блокування (Автоматизовано)

Реалізація режиму блокування обмежує прямий доступ до хостів ESXi, обов’язковий керування через vCenter Server для підтримки визначених ролей і контролю доступу, пом’якшення ризики, пов’язані з несанкціонованою або недостатньо перевіреною діяльністю. Користувачі-виключення список служить механізмом перевизначення, дозволяючи визначеним користувачам прямий доступ навіть у режим блокування. Цей режим пропонує збалансований підхід між безпекою та операційна гнучкість порівняно з суворішим режимом блокування, який, якщо підключення до Сервер vCenter втрачено, тому потрібно перебудувати хост.

Увімкнення звичайного режиму блокування забезпечує централізоване керування через vCenter Сервер, що забезпечує дотримання організаційного контролю доступу та політики аудиту. Це захід значно знижує ризик несанкціонованої діяльності шляхом обмеження безпосереднього хоста доступ, сприяючи більш контрольованому та контрольованому робочому середовищу.

Активація режиму блокування може перешкоджати прямому доступу до хоста для певних операцій як резервне копіювання та усунення несправностей. Хоча тимчасова деактивація є варіантом, забезпечення правильна реактивація після операції має вирішальне значення для підтримки належної безпеки.

3.21 Хост повинен увімкнути режим суворого блокування (Автоматизовано)

Увімкнення режиму блокування вимикає прямий локальний доступ до хосту ESXi, потрібен хост керувати віддалено з vCenter Server. Деякі операції, як-от резервне копіювання та усунення несправностей, вимагають безпосереднього виконання доступ до хоста. У цих випадках режим блокування можна тимчасово вимкнути базу для конкретних хостів за потреби, а потім знову ввімкнено, коли завдання буде виконано. Примітка. Режим блокування не поширюється на користувачів, які входять за допомогою авторизованих ключів. Крім того, користувачам у списку DCUI.Access для кожного хоста дозволено перевизначати режим блокування та увійдіть до DCUI. За замовчуванням «кореневий» користувач є єдиним користувачем, указаним у DCUI.Access список.

Режим блокування обмежує доступ хоста ESXi до сервера vCenter для забезпечення ролей і засоби контролю доступу, реалізовані у vCenter, завжди застосовуються, і користувачі не можуть їх обійти їх, увійшовши безпосередньо на хост. Змусивши всю взаємодію відбуватися через vCenter Сервер, ризик того, що хтось ненавмисно отримає підвищені привілеї або виконає роботу завдань, які належним чином не перевірені, значно скорочується. Додатково суворе блокування will disabled DCUI – вимкнення DCUI запобігає всій локальній активності, а отже, змушує дії виконуватися на сервері vCenter, де їх можна централізовано перевіряти та контролювати.

Якщо ввімкнено режим блокування, хост буде доступний лише через vCenter запобігання «локального» доступу. Вимкнення DCUI може створити потенційну ситуацію “блокування”, якщо хост стане ізольованим від сервера vCenter. Відновлення після “локауту” сценарій вимагає перевстановлення ESXi. Залиште DCUI увімкненим і замість цього ввімкніть режим блокування та обмеження доступу користувачів до DCUI за допомогою DCUI.Access список.

3.22 Хост має заборонити доступ до оболонки для облікового запису dcui (Вручну)

Обліковий запис dcui, який використовується для ізоляції процесу для інтерфейсу користувача Direct Console (DCUI), має доступ до оболонки, який, коли його деактивовано, мінімізує поверхню атаки. Ця дія є профілактичним заходом для підвищення безпеки системи.

Дезактивація доступу до оболонки для облікового запису dcui зменшує можливості використання доступні потенційним зловмисникам. Це розумний крок до посиленої безпеки.

Відмова в доступі до оболонки для облікового запису dcui не впливає на функціонування, роблячи його ефективним контролем безпеки з низьким рівнем ризику.

3.23 Хост має заборонити доступ до оболонки для облікового запису vpxuser (Вручну)

Дезактивація доступу до оболонки для облікового запису vpxuser покращує безпеку шляхом примусового застосування Позиція «Лише API» для попередньо визначених користувачів ESXi без root-прав, таких як vpxuser і dcui.

Цей контроль зменшує площу атаки, обмежуючи шляхи, через які система конфігурації можна змінювати відповідно до сучасних принципів найменших привілеїв гарантуючи, що привілейована автентифікація через vCenter Server залишається надійною контрольовані.

Деактивація доступу до оболонки не дозволяє користувачам надавати доступ до оболонки іншим або зміна паролів користувачів, які мають доступ до командної оболонки, що вимагає хост-за-хостом перенастроювання через авторизований обліковий запис, якщо потрібні зміни. Це могло б потенційно вплине на робочі процеси сторонніх розробників і потребує збереження принаймні одного повний привілейований користувач для необхідних конфігурацій.

3.24 Хост повинен відображати банер входу для DCUI та хост-клієнта (Вручну)

Увімкнення банера входу в інтерфейс користувача прямої консолі (DCUI) і хост Клієнтські інтерфейси забезпечують механізм для відображення юридичних або організаційних повідомлень оголошення при вході. Параметр, який регулює таку поведінку Annotations.WelcomeMessage, рекомендованим значенням є вирівняний текстовий рядок з організаційними чи юридичними консультаціями.

Банер входу служить першою лінією правового захисту від несанкціонованого доступу та зловживання із зазначенням умов використання системи. Це також сприяє зміцненню організаційні політики безпеки серед авторизованих користувачів.

Реалізація маскує параметри “F2/F12” та інформацію про IP-адресу в DCUI, потенційно вимагають додаткової документації або навчання, щоб переконатися, що користувачі обізнані ці зміни.

3.25 Хост повинен відображати банер входу для підключень SSH (Вручну)

ESXi полегшує відображення повідомлень для входу, головним чином спрямованих на запобігання неавторизованим отримувати доступ і інформувати законних користувачів щодо зобов’язань щодо використання системи, зокрема під час підключення SSH. Текст для цього відображення визначається певним параметром, який бажано налаштувати, особливо коли SSH активний, хоча він і є рекомендовано тримати SSH у зупиненому стані, за винятком сценаріїв усунення несправностей. The Параметр, який регулює цю поведінку, — Config.Etc.Issue.

Відображення банера входу служить попереднім стримуючим фактором для неавторизованих користувачів підсилення відповідності законодавства та політики для авторизованих користувачів. Він інкапсулює a проактивний захід безпеки, а також узгодження з декількома відповідними мандатами, які вимагають використання банерів для входу.

Немає функціонального впливу, пов’язаного з цим контролем безпеки; однак, відсутність банера для входу може становити ризик з точки зору правового захисту та відповідності дотримання, особливо під час з’єднань SSH, де може статися потенційне зловживання. Це доцільно проконсультуватися з юридичними консультантами, щоб створити відповідний текст банера організаційно-правові реквізити.

3.26 Хост повинен увімкнути найвищу підтримувану версію TLS (Вручну)

Хост має бути налаштований для роботи з найвищою версією TLS, яка підтримується забезпечити безпечний зв’язок. ESXi 8 за замовчуванням поставляється з увімкненим TLS 1.2, хоча за потреби можливе повторне ввімкнення інших протоколів. Працевлаштування найвищих версія TLS допомагає захистити від відомих уразливостей, наявних у старих версіях. Параметр, який регулює цю поведінку, — це UserVars.ESXiVPsDisabledProtocols із рекомендоване значення “sslv3,tlsv1,tlsv1.1”.

Використання найвищої версії TLS, що підтримується, підвищує рівень безпеки на забезпечення захисту комунікацій за допомогою сучасних стандартів шифрування. Це зменшує ризики, пов’язані з відомими вразливими місцями в застарілих версіях TLS.

Якщо не ввімкнути найвищу підтримувану версію TLS, хост може стати жертвою уразливості, наявні в старіших версіях, потенційно порушують конфіденційність і цілісність комунікацій.