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