Обліковий запис Microsoft проти локального облікового запису: компроміси безпеки

Рішення на одній сторінці

If you’re a home user with one PC

• Рекомендація за замовчуванням: обліковий запис Microsoft з MFA + Windows Hello + BitLocker, якщо тільки у вас немає жорсткої вимоги залишатися офлайн.
• Чому: кращі варіанти відновлення, визначення місцезнаходження пристрою, сценарії безпарольного входу, безпечніше щоденне використання, якщо ви уникаєте локального адміністратора.
• Коли віддати перевагу локальному: ви регулярно перебуваєте офлайн, створюєте кіоск/лабораторний комп’ютер або розділяєте ідентичності з причин досліджень/OPSEC.

If you’re a small business without centralized IT

• Рекомендація за замовчуванням: віддавайте перевагу Microsoft Entra ID (робочий обліковий запис) для керованих пристроїв. Якщо ви цього не робите, MSA може бути проміжним рішенням, але це не система управління.
• Уникайте: флоту ПК, де кожен пристрій використовує однаковий локальний пароль адміністратора. Це не «просто», це «в один фішинг‑лист від поганого тижня».

If you’re an enterprise

• Рекомендація за замовчуванням: Entra ID/Azure AD або приєднання до AD із жорсткими політиками, LAPS і відповідністю пристроїв. Локальні облікові записи стають лише аварійним доступом, а MSA зазвичай заборонені на корпоративних кінцевих точках.
• MSA на корпоративних пристроях: створює шляхи для витоку даних і тіньову ідентичність. Заблокуйте це політиками і моніторингом.

Правило великого пальця: обирайте ідентичність, яка відповідає вашій моделі відновлення. Якщо ви не можете чітко пояснити, як відновите ключі BitLocker, профілі та адміністраторський доступ о 2 годині ночі, у вас немає плану. У вас є оптимізм.

Моделі загроз, які справді мають значення

1) Вас фішингують

Фішинг досі найрентабельніший набір експлойтів, коли-небудь винайдений. З MSA вкрадений пароль не завжди означає поразку, якщо ввімкнено MFA і нападник не отримав автентифікований сесійний токен. З локальним обліковим записом фішинг менш прямий — бо пароль не використовується онлайн — але нападник часто не за паролем. Він хоче, щоб ви запустили щось, підняли права й стали тим адміністратором, яким ви вже є.

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

2) Ваш ноутбук викрали

Крадіжка пристрою — це проблема зберігання, що ховається в тренчкоті. Без шифрування диска різниця між локальним і MSA майже нульова: нападник просто читає диск як книгу. З BitLocker питання стає: де збережено ключ відновлення і хто може його витягти?

Пристрій, прив’язаний до MSA, часто має ключ BitLocker, схований у акаунті Microsoft. Це зручно. Це також залежність. Якщо ваш акаунт скомпрометовано, нападник може отримати ключ відновлення — залежно від захистів і того, що ще було вкрадено.

3) Ви втрачаєте доступ до свого акаунта

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

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

4) На кінцевій точці запускається шкідливе ПО

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

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

5) Ви в регульованому середовищі

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

Парафразована думка, приписана Gene Kim (автор з DevOps/надійності): Покращення приходить від того, що робота стає видимою і зменшується непередбачена робота — тоді ви можете будувати надійність замість постійного гасіння пожеж.

Як насправді працює кожен тип облікового запису (і де поховані скелети)

Локальний обліковий запис: просто, надійно, легко неправильно зрозуміти

Локальний обліковий запис зберігається в локальній базі Security Accounts Manager (SAM) на машині. Машина перевіряє облікові дані локально. Ніякої хмари. Ніякого зовнішнього провайдера ідентичності.

Це звучить чисто. Але локальна машина тепер — ваш провайдер ідентичності. Це означає:

• Політика паролів — це те, що ви налаштуєте (або забудете налаштувати).
• Скидання пароля — локальна операція (і може перетворитися на інцидент безпеки, якщо виконано неправильно).
• Повторне використання облікових даних між пристроями стає вашим прихованим ворогом.
• Відновлення залежить від наявності іншого шляху адміністратора: окремий локальний адмін, автономні носії відновлення або корпоративні інструменти.

Обліковий запис Microsoft (MSA): хмарна ідентичність, пов’язана з пристроєм

MSA — це онлайн‑ідентичність, що використовується для сервісів Microsoft. У Windows вхід під MSA створює локальний профіль, який зв’язаний з цією хмарною ідентичністю. Пристрій кешує матеріал автентифікації, щоб ви могли входити офлайн.

Ключові деталі, що мають значення в інцидентах:

• Ви часто можете увійти офлайн із кешованими обліковими даними, навіть якщо служби Microsoft недоступні.
• Потоки відновлення можуть включати електронну пошту, SMS, підказки автентикатора, коди відновлення та перевірки ризику.
• Деякі налаштування й облікові дані можуть синхронізуватися (залежно від версії Windows і налаштувань).
• Ключі BitLocker можуть бути ескроу до MSA, що одночасно є і страховкою, і привабливою ціллю.

Робочий обліковий запис (Entra ID) — це інша тварина

Люди змішують «обліковий запис Microsoft» і «робочий обліковий запис» в одному реченні, потім дивуються, чому політика поводиться по‑різному. Обліковий запис Entra ID може застосовувати умовний доступ, відповідність пристроїв, безпарольну автентифікацію і централізований ескроу ключів. Якщо ви ведете бізнес, це зазвичай саме те, що вам насправді потрібно.

Жарт №1: локальний обліковий запис — це як ховати запасний ключ під килимок біля дверей — чудово, поки в когось також не буде килимка.

Компроміси безпеки, пункт за пунктом

1) Витік облікових даних і стійкість до фішингу

MSA перемагає, якщо ви ввімкнете MFA і використовуєте сучасний вхід (Windows Hello). Облікові записи тільки з паролем — це погано, бо їх атакують у масштабі інтернету. Перевага в тому, що можна зняти залежність від пароля за допомогою Hello і жорстких MFA‑політик для акаунта.

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

Операційний висновок: якщо ви використовуєте MSA, поводьтесь із ним як із продакшном: MFA, коди відновлення в офлайні та періодичний перегляд активності акаунта.

2) Крадіжка токенів і викрадення сесій

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

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

3) Відновлення: скидання паролів, розблокування пристрою, ключі BitLocker

Відновлення MSA може бути відмінним, коли воно працює: ви забули пароль, підтверджуєте MFA — і повертаєтесь у роботу. Але воно може бути жорстоким, коли не працює: подорожі, втрата телефону, блокований емейл або акаунт, помічений за незвичною активністю.

Локальне відновлення — під вашим контролем, але лише якщо ви підготувалися: окремий обліковий запис адміністратора, документований сейф паролів і ключі BitLocker, збережені поза пристроєм.

Операційний висновок: якщо ви використовуєте локальні облікові записи, ви повинні створити шлях відновлення, який не покладається на «я це запам’ятаю». Пам’ять не є контролем.

4) Приватність і синхронізація даних

MSA збільшує ймовірність того, що налаштування, ключі і персональні дані потраплять у сервіси Microsoft. Частина з цього навмисна (OneDrive), частина — тонка (синхронізація налаштувань, профілі Edge), а частина — зумовлена політикою в корпоративних контекстах.

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

5) Адміністративні межі та принцип найменших привілеїв

Найбільша «вогнепальна пастка» Windows — це не MSA. Це «щоденна робота як локальний адмін». Обидва типи акаунтів можуть мати адмінські права. Але MSA сприяє зручним налаштуванням, що часто закінчуються привілеями адміністратора, тому що «це мій ПК». Нападникам це подобається.

Операційний висновок: створіть окремий локальний обліковий запис адміністратора і використовуйте стандартний акаунт для щоденної роботи. Це нудно. Але працює.

6) Корпоративне управління і відключення доступу

Локальні облікові записи не відключаються централізовано. MSA не керується централізовано (у корпоративному сенсі). Entra ID створено для відключення доступу при звільненні. Якщо ви керуєте бізнесом, не будуйте шар ідентичності з особистих акаунтів і не сподівайтесь, що HR ніколи не помилиться.

7) Стійкість до збою хмарних сервісів та проблем з акаунтом

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

Операційний висновок: для критичних систем (лабораторні прилади, кіоски, виробничі лінії) локальні облікові записи або домен/Entra з сильними офлайн‑політиками передбачуваніші за споживчі MSA‑потоки.

8) Перепризначення пристрою та питання «власності»

MSA прив’язує пристрої до особистої ідентичності таким чином, що може вас здивувати під час перепродажу, передачі чи повернення корпоративного майна. Локальні облікові записи можна чистіше відновити — за умови що ви можете розшифрувати диск і видалити всі дані.

З BitLocker «чиста чистка» включає роботу з ключами відновлення і станом активації. Тут вибір ідентичності перетинається з управлінням зберіганням і життєвим циклом пристрою.

Цікаві факти та історичний контекст (корисно, а не тривіально)

1. Windows NT представив модель SAM у 1990‑х, заклавши локальні бази облікових записів і аутентифікацію на основі NTLM, яка й досі залишає операційні відбитки.
2. Microsoft Passport (кінець 1990‑х/початок 2000‑х) був ранньою спробою уніфікованої ідентичності Microsoft; він еволюціонував у те, що зараз називаємо Microsoft Account.
3. Windows 8 активно просував онлайн‑вхід, зробивши MSA за замовчуванням для багатьох користувацьких сценаріїв і задавши тон «cloud‑first» онбордингу.
4. BitLocker дебютував у Windows Vista, і вибір ескроу ключів постійно був джерелом як відновлень, так і компрометацій.
5. Windows Hello з’явився з Windows 10, перемістивши розмову від «складності пароля» до «аутентифікації, прив’язаної до пристрою», що є реальним плюсом за правильної конфігурації.
6. Credential Guard (Windows 10 Enterprise+) змінив спосіб захисту матеріалів автентифікації в пам’яті, зменшивши деякі класичні атаки дампінгу облікових даних — коли його включено й підтримується.
7. Azure AD став Entra ID під час ребрендингу Microsoft — важливо, бо «Microsoft account» і «робочий обліковий запис» не взаємозамінні.
8. Local Administrator Password Solution (LAPS) існує тому, що спільні локальні паролі адміністратора були (і лишаються) основною причиною латерального пересування в Windows‑середовищах.

Три корпоративні міні-історії (аніомізовано)

Міні-історія 1: Інцидент через хибні припущення

Компанія мала невеликий віддалений офіс з кількома ноутбуками на Windows 11. Ніякого домену. Ніякого MDM. Локальна IT‑контактна особа припустила, що «вхід обліковим записом Microsoft» означає, що пристрій «запасний у хмарі» і отже відновлюваний після будь‑якої проблеми.

Ноутбук вкрали під час поїздки. BitLocker був увімкнений, що добре. Користувач був спокійний, бо «він зашифрований і ключ в мому обліковому записі Microsoft». Потім електронну пошту користувача — яка використовувалася як MSA — також скомпрометували через переслану фішингову ланцюжок. Нападник зайшов у скриньку, скинув пароль MSA і пройшов достатньо запитів відновлення, аби отримати дані акаунта.

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

Хибне припущення полягало не в тому, що «хмара небезпечна». Хибне припущення було в тому, що відновлення означає безпеку. Відновлення — це інструмент. У чужих руках він знімає замки.

Міні-історія 2: Оптимізація, що обернулась проти

IT‑команда хотіла швидшого онбордингу для підрядників. Вони стандартизували один локальний обліковий запис адміністратора для всіх ноутбуків підрядників, бо це спростило образи та підтримку. Пароль крутили «інколи», що на практиці означало «коли хтось пам’ятає».

Це працювало блискуче — поки ноутбук підрядника не інфікувався. Шкідливе ПЗ зібрало локальні облікові дані і почало перевіряти їх на сусідніх кінцевих точках через VPN. Оскільки пароль адміністратора був спільним, латеральний рух нападника виглядав як дуже продуктивна робота техпідтримки.

Інцидент локалізували швидко, але вартість відновлення була високою: перевстановлення систем, зміна паролів, аудит доступів і пояснення, чому «оптимізований онбординг» став «колапсом довіри у флоті».

Команда пізніше впровадила унікальні локальні паролі для кожного пристрою (у стилі LAPS) і зробила звичайні облікові записи користувачів нормою. Онбординг став трохи менш «плавним». Безпека стала значно менш драматичною.

Міні-історія 3: Нудна, але правильна практика, що врятувала день

Фінансовий відділ мав просту, дратівливу політику: на кожному ноутбуці було два локальні облікові записи — один стандартний для щоденної роботи і один окремий локальний адмін, пароль якого зберігали у сейфі з контрольованим доступом. Ключі відновлення BitLocker експортували і зберігали в тому ж сейфі, проставлені за ID активу.

Потім оновлення Windows пройшло не так і спричинило BitLocker recovery при перезавантаженні на кількох машинах (таке трапляється, коли змінюються вимірювання прошивки/TPM). Користувачі панікували, бо бачили синій екран відновлення, а машини були потрібні для payroll.

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

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

Жарт №2: найнадійніший фактор автентифікації досі — «хтось це записав», і саме тому аудитори п’ють.

Практичні завдання: команди, виводи, що це означає і яке рішення прийняти

Це команди Windows, які ви можете виконати в піднятому Command Prompt або PowerShell. Мета не в тому, щоб запам’ятати їх. Мета — виміряти реальність перед тим, як змінювати налаштування ідентичності і ризикувати опинитися відрізаним.

Завдання 1: Визначте, за ким ви увійшли (локальний чи прив’язаний до Microsoft)

cr0x@server:~$ whoami
desktop-9q2k3l1\alex

Що означає вивід: Префікс імені машини вказує на локальний обліковий запис або локальний контекст профілю. Для акаунтів, пов’язаних з MSA, Windows часто все одно показує префікс машини, бо профіль фізично локальний навіть якщо він зв’язаний.

Рішення: Не робіть припущень. Підтвердіть це наступним завданням (WMI), щоб перевірити, чи акаунт підключений до Microsoft.

Завдання 2: Перелічіть локальні облікові записи і подивіться, що є для відновлення

cr0x@server:~$ net user
User accounts for \\DESKTOP-9Q2K3L1

-------------------------------------------------------------------------------
Administrator            DefaultAccount           Guest
alex                     localadmin
The command completed successfully.

Що означає вивід: У вас є принаймні один кандидат на окремого адміністратора (localadmin). Якщо ви бачите лише свого щоденного користувача, ви на один крок від «я не можу підвищити привілеї».

Рішення: Переконайтесь, що є окремий локальний адмін з паролем у сейфі перед тим, як змінювати модель входу.

Завдання 3: Перевірте членство в локальній групі (чи ви випадково адмін?)

cr0x@server:~$ net localgroup administrators
Alias name     administrators
Comment        Administrators have complete and unrestricted access to the computer/domain

Members

-------------------------------------------------------------------------------
Administrator
localadmin
alex
The command completed successfully.

Що означає вивід: alex є локальним адміном. Це зручно і небезпечно одночасно.

Рішення: Видаліть щоденних користувачів із групи Administrators. Використовуйте UAC з окремим адмінським акаунтом для підвищення прав.

Завдання 4: Перевірте, чи пристрій приєднано до домену, Entra або це робоча група

cr0x@server:~$ dsregcmd /status
+----------------------------------------------------------------------+
| Device State                                                         |
+----------------------------------------------------------------------+
AzureAdJoined : NO
EnterpriseJoined : NO
DomainJoined : NO
DeviceName : DESKTOP-9Q2K3L1

+----------------------------------------------------------------------+
| User State                                                           |
+----------------------------------------------------------------------+
NgcSet : YES
WorkplaceJoined : NO

Що означає вивід: Не приєднано до домену і не приєднано до Azure/Entra. Це автономна кінцева точка. NgcSet : YES вказує, що Windows Hello налаштовано.

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

Завдання 5: Перевірте статус BitLocker (шифрування не опціональне для ноутбуків)

cr0x@server:~$ manage-bde -status c:
BitLocker Drive Encryption: Configuration Tool version 10.0.22621
Copyright (C) Microsoft Corporation. All rights reserved.

Volume C: [OS]
[OS Volume]

    Size:                 476.31 GB
    BitLocker Version:    2.0
    Conversion Status:    Fully Encrypted
    Percentage Encrypted: 100.0%
    Protection Status:    Protection On
    Lock Status:          Unlocked
    Identification Field: None
    Key Protectors:
        TPM

Що означає вивід: Диск повністю зашифровано і захищено TPM. Хороша базова лінія.

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

Завдання 6: Перерахунок захисників відновлення BitLocker (і їхнє резервне копіювання)

cr0x@server:~$ manage-bde -protectors -get c:
BitLocker Drive Encryption: Configuration Tool version 10.0.22621
Copyright (C) Microsoft Corporation. All rights reserved.

Volume C: [OS]

All Key Protectors

    TPM:
      ID: {D6A0B7A9-2B6E-4A45-9F8B-9A7D2D2E4A01}

    Numerical Password:
      ID: {B2C3D4E5-F607-489A-9ABC-0123456789AB}
      Password:
        123456-123456-123456-123456-123456-123456-123456-123456

Що означає вивід: Існує пароль для відновлення (numerical password). Саме його ви вводите на екрані відновлення BitLocker.

Рішення: Резервно скопіюйте його в безпечне сховище (хвіст паролів, надруковано і заховано або корпоративний ескроу). Якщо ви покладаєтесь на «думаю, він у моєму Microsoft акаунті», перевірте це до того, як він стане потрібен.

Завдання 7: Перевірте, чи Windows Hello налаштовано і доступно

cr0x@server:~$ certutil -csp "Microsoft Platform Crypto Provider" -key
Microsoft Platform Crypto Provider
========================
Key Container = d1f4a2c3-1111-2222-3333-444455556666
Unique container name: d1f4a2c3-1111-2222-3333-444455556666
Provider = Microsoft Platform Crypto Provider

Що означає вивід: Наявність Platform Crypto Provider вказує на ключі, захищені TPM, часто використовувані Windows Hello.

Рішення: Надавайте перевагу Hello (PIN/біометрія) з міцними захистами пристрою; це зменшує експозицію паролів. Не плутайте PIN із «слабким» паролем: він прив’язаний до пристрою, а не до веб‑пароля.

Завдання 8: Перевірте збережені Windows облікові дані (тихі точки хмарного повороту)

cr0x@server:~$ cmdkey /list
Currently stored credentials:

Target: LegacyGeneric:target=MicrosoftAccount:user@example.com
Type: Generic
User: user@example.com

Target: Domain:target=TERMSRV/rdp-gw
Type: Domain Password
User: DESKTOP-9Q2K3L1\alex

Що означає вивід: У вас збережені облікові дані для MSA і для RDP. Збережені креденшіали зручні й для нападників теж.

Рішення: Видаліть застарілі облікові дані, особливо для акаунтів, які ви намагаєтесь від’єднати від машини.

Завдання 9: Перевірте журнал безпеки Windows на предмет невдалих входів (хтось пробує?)

cr0x@server:~$ wevtutil qe Security /q:"*[System[(EventID=4625)]]" /c:3 /f:text
Event[0]:
  Log Name: Security
  Source: Microsoft-Windows-Security-Auditing
  Event ID: 4625
  Task: Logon
  Level: Information
  Keywords: Audit Failure
  TimeCreated: 2026-02-05T10:02:11.0000000Z
  Message: An account failed to log on.

Що означає вивід: Подія 4625 — невдалий вхід. Деталі (тут не показані) включають тип входу і джерело. Повторні невдачі можуть вказувати на грубу силу або неправильно налаштовані сервіси.

Рішення: Якщо ви бачите повторні віддалені невдалі входи, вимкніть непотрібний віддалений доступ і перевірте відкриття порту/експозицію RDP.

Завдання 10: Підтвердіть стан RDP (не відкривайте його легковажно)

cr0x@server:~$ reg query "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server" /v fDenyTSConnections

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server
    fDenyTSConnections    REG_DWORD    0x1

Що означає вивід: 0x1 означає, що підключення RDP заборонені (RDP відключено). Якщо 0x0, RDP увімкнено.

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

Завдання 11: Перевірте профіль брандмауера і вхідні правила

cr0x@server:~$ netsh advfirewall show currentprofile
Public Profile Settings:
----------------------------------------------------------------------
State                                 ON
Firewall Policy                        BlockInbound,AllowOutbound
LocalFirewallRules                      N/A (GPO-store only)
LocalConSecRules                        N/A (GPO-store only)

Що означає вивід: Публічний профіль УВІМКНЕНО і блокує вхідні з’єднання за замовчуванням. Добре для ноутбуків, що переміщуються між мережами.

Рішення: Якщо ви покладаєтесь на локальні облікові записи для безпеки, але вхід відкритий, ви побудували красну огорожу з відкритими воротами.

Завдання 12: Перевірте, чи налаштовано кешовані входи (поведінка офлайн‑входу)

cr0x@server:~$ reg query "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /v CachedLogonsCount

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon
    CachedLogonsCount    REG_SZ    10

Що означає вивід: Кешовані входи дозволяють користувачам входити, коли провайдер ідентичності недоступний (переважно концепт домену, але це корисний індикатор офлайн‑припущень).

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

Завдання 13: Перевірте, який акаунт налаштовано як «власник» для інтеграції Office/OneDrive

cr0x@server:~$ reg query "HKCU\Software\Microsoft\OneDrive\Accounts" /s

HKEY_CURRENT_USER\Software\Microsoft\OneDrive\Accounts\Personal
    UserEmail    REG_SZ    user@example.com
    UserName     REG_SZ    user

Що означає вивід: Налаштовано персональний OneDrive. Навіть якщо ви використовуєте локальний вхід у Windows, синхронізація хмари може бути активною через додатки.

Рішення: Якщо ваша мета — «тільки локально», ви також повинні відключити або переналаштувати хмарні акаунти на рівні додатків.

Завдання 14: Перелічіть локальну політику безпеки щодо блокування акаунтів (захист vs самодозвіл)

cr0x@server:~$ net accounts
Force user logoff how long after time expires?:       Never
Minimum password age (days):                          0
Maximum password age (days):                          42
Minimum password length:                              12
Length of password history maintained:                24
Lockout threshold:                                    10
Lockout duration (minutes):                           15
Lockout observation window (minutes):                 15

Що означає вивід: Політика блокування існує. Забагато суворості — і ви можете заблокувати себе через проблемний сервіс. Забагато поблажливості — і брутфорс стає дешевшим.

Рішення: Встановіть розумний поріг і розслідуйте повторні невдачі замість того, щоб лише нескінченно піднімати поріг.

Швидкий посібник діагностики: знайдіть вузьке місце без гадань

Сценарій A: «Я не можу увійти» (після зміни типу облікового запису або пароля)

1. Перше: Підтвердіть, що у вас є альтернативний шлях адміністратора.
   • Перевірте, чи існує інший локальний адмін (net user, net localgroup administrators).
   • Якщо ні — припиніть імпровізувати. Використайте середовище відновлення і підготуйтеся до відновлення профілю або відновлення з резервної копії.
2. Друге: Визначте, чи це проблема кешу офлайн проти помилки автентифікації в хмарі.
   • Пристрій офлайн? Чи доступна мережа?
   • Спробуйте локальний метод входу (PIN), якщо Hello налаштовано.
3. Третє: Перевірте журнал безпеки на предмет невдач і типів входів.
   • Подія 4625 дасть знати, чи це інтерактивний вхід, мережевий, RDP тощо.
4. Четверте: Якщо спрацьовує BitLocker recovery, трактуйте це як зміну стану зберігання/TPM.
   • Отримайте ключ відновлення з методу ескроу і зайдіть.
   • Потім розберіться, що змінилося (прошивка, налаштування завантаження, скидання TPM).

Сценарій B: «Цей пристрій постійно просить облікові дані / підказує»

1. Перше: Шукайте застарілі збережені облікові дані (cmdkey /list).
2. Друге: Підтвердіть тип акаунта і стан приєднання (dsregcmd /status).
3. Третє: Перевірте, чи додатки окремо увійшли (OneDrive/Office/профілі Edge).
4. Четверте: Якщо це робочий пристрій, перевірте помилки відповідності/умовного доступу (часто проявляється як повторні підказки).

Сценарій C: «Ми бачимо неочікуваний доступ до хмарних даних»

1. Перше: Визначте, чи Windows‑вхід використовує MSA, і чи та сама ідентичність застосовується в браузері/додатках.
2. Друге: Поверніть паролі і відкличте сесії для хмарної ідентичності.
3. Третє: Перевірте пристрій на шкідливе ПЗ і ознаки крадіжки токенів; не обмежуйтесь лише зміною паролів.
4. Четверте: Переоцініть: чи має цей пристрій використовувати Entra ID з умовним доступом і відповідністю?

Типові помилки: симптом → корінь → виправлення

1) Симптом: «Я перейшов на локальний акаунт і тепер OneDrive/Office працює дивно»

Корінь проблеми: Ідентичність входу в Windows і ідентичність додатків відокремлені. Ви змінили вхід ОС, але додатки все ще до MSA увійшли.

Виправлення: Вийдіть із OneDrive/Office/профілів Edge явно; видаліть збережені облікові дані (cmdkey); перевірте зв’язки акаунтів у Settings > Accounts.

2) Симптом: «Екран відновлення BitLocker після рутинного оновлення»

Корінь проблеми: Зміни вимірювань TPM (оновлення прошивки, зміни конфігурації завантаження, перемикання Secure Boot) можуть викликати відновлення.

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

3) Симптом: «Я можу увійти офлайн, але не можу в онлайн‑сервіси»

Корінь проблеми: Кешовані облікові дані дозволяють локальний вхід, але оновлення хмарних токенів не вдається (акаунт заблоковано, змінено вимогу MFA або мережа фільтрує).

Виправлення: Виправте стан хмарного акаунта (MFA, скидання пароля) і перевірте мережу/DNS. Не видаляйте локальний профіль, якщо ви не впевнені, що він пошкоджений.

4) Симптом: «Helpdesk не може відключити користувача; дані продовжують синхронізуватися»

Корінь проблеми: Користувач використовував MSA на корпоративному пристрої. Системи відключення не контролюють його.

Виправлення: Примусово забороніть використання споживчих MSA для входу й автентифікації додатків на керованих пристроях; переведіть користувачів на Entra ID.

5) Симптом: «Кілька машин скомпрометовано після інфекції одного ноутбука»

Корінь проблеми: Спільний локальний адмін‑пароль або повторне використання локальних облікових даних між кінцевими точками.

Виправлення: Впровадьте унікальні локальні паролі для кожного пристрою (LAPS), приберіть щоденні адмінські права і регулярно аудитуйте членство локальних адміністраторів.

6) Симптом: «Користувач не може підвищити привілеї після зміни налаштувань акаунта»

Корінь проблеми: Єдиний адміністратор був акаунтом користувача, і він було перетворено/змінено; запити UAC тепер не проходять.

Виправлення: Підтримуйте окремий локальний адмінський акаунт. Якщо вже відрізані, використайте середовище відновлення, щоб увімкнути Administrator або безпечно скинути локальні адмінські облікові дані.

7) Симптом: «Повторні блокування акаунтів»

Корінь проблеми: Застарілі облікові дані кешуються в сервісах, запланованих завданнях, змонтованих дисках або RDP‑клієнтах і продовжують робити спроби входу.

Виправлення: Знайдіть джерело через журнали подій безпеки (4625/4740 у доменних контекстах), видаліть збережені креденшіали (cmdkey), оновіть завдання/сервіси.

Контрольні списки / покроковий план

Plan A: Ви хочете безпечно використовувати обліковий запис Microsoft (персональний пристрій)

1. Увімкніть MFA для облікового запису Microsoft. Віддавайте перевагу застосунку‑автентифікатору або апаратним методам, коли це можливо.
2. Налаштуйте Windows Hello (PIN/біометрія). Переконайтесь, що пристрій зашифровано (BitLocker).
3. Створіть окремий локальний акаунт адміністратора з довгим випадковим паролем, збереженим у сейфі. Ваш щоденний акаунт залишайте стандартним користувачем.
4. Експортуйте/збережіть ключ відновлення BitLocker принаймні в двох місцях: один цифровий сейф і один офлайн‑резерв (збережіть безпечно).
5. Аудитуйте збережені облікові дані і видаляйте застарілі записи (cmdkey /list потім видалити).
6. Підтвердіть базові налаштування брандмауера і вимкніть непотрібні віддалені сервіси (особливо RDP).
7. Протестуйте відновлення: переконайтесь, що можете отримати ключ BitLocker і увійти за допомогою резервного адміна.

Plan B: Ви хочете працювати з локальними акаунтами (приватність/офлайн/критична робоча станція)

1. Створіть два локальні акаунти: один стандартний для щоденної роботи, один — лише для адміністратора.
2. Встановіть міцну політику локальних паролів (довжина, історія, блокування) відповідно до вашого середовища.
3. Увімкніть BitLocker і зберігайте ключі відновлення офлайн та в контрольованому сейфі. Не зберігайте їх тільки на машині.
4. Вимкніть або вийдіть із споживчих сервісів синхронізації (OneDrive personal, синхронізація профілів браузера), якщо ваша мета — справді локальна робота.
5. Загартуйте віддалений доступ: тримайте вхід блокованим, вимкніть RDP, якщо він не потрібен, і уникайте експозиції портів.
6. Резервні копії: впровадьте стратегію бекапу, яка не залежить від тих самих локальних облікових даних після катастрофи.
7. Документуйте кроки відновлення так, ніби ви пишете інструкцію для свого майбутнього себе в стресі — бо так воно й буде.

Plan C: Корпоративні кінцеві точки (що потрібно впровадити)

1. Стандартизувати Entra ID або приєднання до AD для входу користувачів і управління пристроями.
2. Блокувати споживчі MSA для входу й автентифікації додатків там, де політика дозволяє; моніторити винятки.
3. Впровадити LAPS (або еквівалент) для унікальних локальних адмін‑паролів і обмежити їх використання.
4. Використовувати умовний доступ і вимагати відповідних пристроїв для доступу до хмари.
5. Централізувати ескроу ключів BitLocker і тестувати отримання ключів у робочих процесах служби підтримки.
6. Розділити ролі адміністраторів і за замовчуванням прибрати локальний адмін з профілів стандартних користувачів.

FAQ

1) Чи є обліковий запис Microsoft «безпечнішим» за локальний?

За умов MFA і Windows Hello часто так щодо щоденних ризиків. Без MFA MSA — цінна мішень, орієнтована в інтернеті. Локальний акаунт може бути безпечнішим лише за умови доброї гігієни паролів і суворих адміністраторських прав.

2) Чи можу я використовувати Windows Hello з локальним обліковим записом?

Так, на багатьох системах можна використовувати PIN з локальним акаунтом. Властивості безпеки залежать від конфігурації пристрою і підтримки TPM. Перевага та сама: менше експозицій паролів.

3) Чи видалить перехід з MSA на локальний мої файли?

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

4) Де зберігати ключі відновлення BitLocker?

У контрольованому сейфі паролів з журналом доступу, якщо можливо, плюс друга офлайн‑копія, що зберігається безпечно. Якщо ви ескроуєте ключі лише в MSA і цей акаунт скомпрометовано або недоступний — ви створюєте єдину точку відмови.

5) Якщо мій пристрій вкрали, чи може нападник скинути мій Microsoft акаунт і отримати ключ BitLocker?

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

6) Я часто офлайн. Чи MSA завадить мені входити?

Зазвичай ні, бо Windows кешує облікові дані, і Hello може працювати офлайн. Більша проблема — відновлення акаунта і оновлення токенів сервісів, коли ви підключитесь. Заплануйте сценарій «я змінив пароль і тепер офлайн».

7) Чому підприємства не люблять споживчі облікові записи Microsoft на корпоративних пристроях?

Тому що вони обходять управління: немає централізованого відключення, непослідовне застосування політик і нечіткі межі даних. Підприємства хочуть Entra ID/AD акаунти, пов’язані з HR‑життєвим циклом і контролями безпеки.

8) Яке найбільш практичне покращення безпеки незалежно від типу облікового запису?

Припиніть використовувати щоденний акаунт як локального адміністратора. Зробіть стандартного користувача обліковим записом за замовчуванням, тримайте окремий адмін‑акаунт для підвищення прав і зашифруйте диск.

9) Якщо у мене вже є MSA на ПК, чи варто його видаляти?

Не автоматично. Якщо він захищений MFA, у вас є коди відновлення, і ви розумієте, де зберігаються ключі BitLocker, це може бути надійною конфігурацією. Причина змінити — це чітка вимога: модель приватності, офлайн‑обмеження або управління.

Висновок: кроки, які ви реально можете зробити

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

Зробіть ці три речі цього тижня:

1. Перевірте статус BitLocker і підтвердіть, що можете отримати ключ відновлення без пристрою.
2. Створіть окремий локальний акаунт адміністратора з паролем у сейфі; приберіть щоденний акаунт з Administrators.
3. Загартуйте ідентичність, яку ви зберігаєте: MFA і коди відновлення для MSA або жорстка політика локальних паролів і гігієна облікових даних для локальних акаунтів.

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