AUT-0464· Безпека та відповідність
Перевірка аварійного доступу адміністратора
Команда регулярно перевіряє працездатність резервного доступу та розбирає кожне його використання.
Чернетка · Оцінка потребує перевірки
01 / Проблема
Резервний обліковий запис адміністратора створили на випадок відмови звичайного входу, але ніхто не перевіряє, чи він працює і чи сповіщення про використання доходить до команди.
02 / Результат
Для кожного аварійного облікового запису є актуальний список уповноважених, дата й результат погодженої перевірки, підтвердження сигналу моніторингу та окрема перевірка кожного реального використання.
03 / Процес
ТригерНастав строк погодженого навчального тесту аварійного доступу або система моніторингу повідомила про його використання.
Визначити облікові записи, власника контролю, уповноважених користувачів, джерело журналів та процедуру відновлення доступу.
До навчального тесту повідомити команду моніторингу про погоджений час і перевірити, що тест не буде сприйнятий як непогоджений інцидент.
Уповноважений адміністратор за затвердженою процедурою перевіряє вхід і потрібну контрольну дію. Система координації не зберігає секрети й не входить під привілейованим записом.
Перевірити фактичне отримання сигналу моніторингу, його одержувачів, часові мітки та зв'язок із запланованим тестом; пропущене сповіщення залишити відкритим винятком.
Оновити список уповноважених, підтвердити доступність захищеного способу отримання облікових даних і переглянути зміни в команді чи політиці входу.
Кожний позаплановий сигнал створює окремий терміновий випадок для відповідального. Він зберігає посилання на журнали, з'ясовує підставу та перевіряє виконані адміністративні дії.
Погодити результат: санкціоноване використання, навчальний тест або невирішена подія; невідомий користувач чи неповний журнал потребує ескалації.
За рішенням відповідального оновити процедуру, контроль або спосіб зберігання секретів. Не закривати випадок тільки тому, що доступ згодом відновили.
Зберігати дату, учасників, результат і посилання на журнал за погодженим строком; не копіювати пароль, ключ чи код другого фактора до задачі або сповіщення.
04 / Реалізація2 варіанти
Приклад · Подієве сповіщення та контроль тестів
Журнал Entra зафіксував використання аварійного запису. Інтеграція створила термінову задачу з ID події, часом і посиланням на джерело. Черговий класифікував сигнал як санкціоновану аварію, перевірив журнал дій і зафіксував рішення.
Спосіб реалізації
- Читати тільки погоджені поля журналу; не передавати пароль, код MFA чи надлишкові персональні дані.
- Створювати одну задачу на унікальний ID входу й перевіряти доставку та повторні події.
- Зв'язувати планові тести, журнали сигналу, післяподієве рішення й відкриті заходи.
Що потрібно для реалізації
- Є документована аварійна процедура, окремо визначені уповноважені й захищене місце зберігання облікових даних.
- Погоджені строк тестування, безпечна контрольна дія, спосіб попередження моніторингу та критерії успіху.
- Доступні журнали входу й аудиту або призначений відповідальний, який перевіряє їх у джерельній системі.
- Визначені терміновість сповіщення, ескалація невідомого використання та правила збереження доказів.
- Підтверджений канал доставки журналів, одержувачі сигналу, унікальний ID події та тестовий маршрут.
Обмеження
- Microsoft радить щонайменше два аварійні облікові записи та перевірку не рідше ніж раз на 90 днів для Microsoft Entra; це рекомендація вендора для його середовища, не універсальна норма.
- Не створює резервні облікові записи, не змінює політики автентифікації й не виконує тестовий вхід замість уповноваженого адміністратора.
- Не зберігає паролі, секрети, коди MFA чи особисті пристрої; матеріали моніторингу залишаються у джерельній системі з її правами доступу.
- Сповіщення не доводить, що всі журнали повні або що використання було безпечним; людина перевіряє події та адміністративні дії.
- PlanFix може координувати графік, відповідальних, винятки та посилання на докази; робота з обліковим записом і журнали потребують окремої системи ідентичності та моніторингу.
- Години попередні; налаштування IAM, моніторингу, безпечного сховища та відновлення доступу не включені.
- Конкретний API, затримка журналу та повнота подій залежать від IAM і моніторингу; це перевіряють перед підключенням.
Що потрібно уточнити (2)
- Чи потрібно вести аварійні записи для кількох окремих середовищ?
Погодьте власника, джерело журналів, чергу сповіщень і процедуру для кожного середовища.
- Чи потрібно автоматично створювати випадок з журналу входу?
Перевірте API або шлюз журналів, унікальний ID події, затримку доставки та підтвердження сигналу.