Аудит прав доступу: хто бачить дані компанії

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

Переліку облікових записів недостатньо

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

Користувач може отримати доступ до даних через:

• членство в одній або кількох групах;
• вкладену групу з Active Directory або Microsoft Entra ID;
• дозволи, успадковані від батьківської папки;
• прямий виняток для конкретного файлу або каталогу;
• роль адміністратора системи;
• зовнішній гостьовий обліковий запис;
• посилання для конкретних осіб або для будь-кого, хто його отримає;
• спільний обліковий запис або пароль;
• сервісний обліковий запис, який використовує застосунок чи автоматизація.

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

Спочатку визначте дані, ролі та власників

Перевірку не варто починати з експорту всіх облікових записів користувачів. Спочатку потрібно визначити, які дані захищає компанія, хто ухвалює рішення про надання доступу до них і яким робочим ролям вони потрібні.

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

Основою є матриця ролей і систем:

Роль	Система або дані	Необхідний доступ	Спосіб надання	Власник
Бухгалтер	Бухгалтерська папка на NAS	читання й запис	група UCETNI	керівництво компанії
Менеджер із продажів	CRM	звичайний користувач	роль у застосунку	керівник відділу продажів
Фахівець із персоналу	Кадрові документи	читання й запис	група PERSONALNI	керівництво компанії
Зовнішній IT-фахівець	Адміністрування серверів	адміністрування протягом необхідного часу	окремий обліковий запис	директор

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

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

Що має охоплювати аудит у компанії

Обсяг аудиту залежить від систем, які використовує компанія, а не лише від кількості працівників. Невелика компанія з NAS, Microsoft 365, VPN, бухгалтерською програмою та кількома зовнішніми співробітниками може мати складнішу систему дозволів, ніж більша компанія із централізованим керуванням ідентичностями.

Зазвичай потрібно перевірити щонайменше:

1. облікові записи користувачів, адміністраторів, гостей і служб;
2. групи, вкладене членство та ролі в застосунках;
3. спільні папки на NAS і Windows Server;
4. SharePoint, OneDrive, Teams і спільні поштові скриньки;
5. VPN, віддалене адміністрування та доступ постачальників;
6. публічні й зовнішні посилання для спільного доступу;
7. спільні паролі, багатофакторну автентифікацію та аварійні облікові записи;
8. облікові записи колишніх працівників і доступи без визначеного власника;
9. API-ключі, інтеграційні облікові записи й автоматизації, пов’язані з конкретною людиною.

Важливий також рівень дозволів. Недостатньо зазначити, що користувач «має доступ». Аудит повинен розрізняти читання, запис, видалення, надання спільного доступу, зміну дозволів і повне адміністрування.

Windows Server: поєднайте дозволи спільного доступу та NTFS

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

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

Перевірка має з’ясувати:

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

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

Synology і QNAP: перевірте локальні та доменні групи

На пристроях Synology з DSM і QNAP з QTS користувач може отримати доступ через локальний обліковий запис NAS, локальну групу, обліковий запис з Active Directory або ACL, успадковані від батьківської папки. Окрім звичайних спільних папок, потрібно також перевірити домашні каталоги, дозволи застосунків, групи адміністраторів і можливі підключення до хмарних служб.

Аудит NAS має дати відповіді на ті самі запитання, що й перевірка Windows Server:

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

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

Microsoft 365: перевірте ролі, гостей і посилання

У Microsoft 365 доступ може виникнути через групу Microsoft 365, групу безпеки, команду, сайт SharePoint, прямий дозвіл, зовнішнього гостя або посилання для спільного доступу. Усі ці способи потрібно оцінювати разом.

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

Перевірка має охоплювати:

• зовнішніх гостей та останню відому мету їхнього доступу;
• анонімні посилання й посилання з необмеженим строком дії;
• прямі дозволи поза звичайним членством у команді;
• власників команд і сайтів SharePoint;
• дозволи для окремих папок і документів;
• спільні поштові скриньки та права Full Access, Send As і Send on behalf;
• адміністративні ролі в Microsoft Entra ID;
• робочі облікові записи, які водночас використовують найвищу адміністративну роль.

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

Звільнення працівника: заблокуйте доступ, але не видаляйте все без перевірки

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

Під час аудиту потрібно насамперед шукати:

• активні облікові записи колишніх працівників;
• зовнішніх співробітників без визначеної дати завершення доступу;
• невикористовувані локальні облікові записи на серверах і NAS;
• доступи, прив’язані до приватних адрес електронної пошти;
• профілі VPN та облікові записи віддаленого адміністрування;
• API-ключі й сервісні облікові записи, пов’язані з конкретною людиною;
• спільні паролі, які досі знає працівник, що звільняється.

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

Спільні облікові записи приховують, хто вніс зміну

Облікові записи на кшталт sklad, recepce або admin, пароль до яких знають кілька людей, не дають змоги надійно пов’язати конкретну дію з конкретною людиною. Крім того, після звільнення працівника неможливо скасувати лише його доступ, не змінивши пароль для всіх інших.

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

Для важливих облікових записів потрібно використовувати багатофакторну автентифікацію. У системах, які їх підтримують, ключі доступу (passkeys) або апаратні ключі на основі FIDO2 краще захищають від підроблених сторінок входу, ніж код, переписаний із повідомлення. Проте компанія також повинна передбачити резервний спосіб входу, втрату пристрою й аварійний доступ. Практичні відмінності описано в огляді MFA у компанії: passkeys і FIDO2 замість SMS.

Яким має бути корисний результат

Результатом аудиту не повинні бути кілька технічних експортів без пояснень. Компанії потрібні щонайменше три взаємопов’язані результати.

Матриця ролей і систем

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

Перелік виявлених проблем

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

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

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

План усунення недоліків і перевірки

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

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

Відокремте усунення недоліків від збирання даних

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

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

1. підтвердити проблему з власником даних;
2. з’ясувати залежності облікового запису або групи;
3. зафіксувати початкові налаштування;
4. підготувати процедуру відновлення попереднього стану;
5. внести обмежену зміну;
6. перевірити очікуваний і небажаний доступ;
7. лише після цього переходити до інших облікових записів або папок.

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

Як часто перевіряти права доступу

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

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

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

NIS2 і GDPR: аудит не є сертифікатом відповідності

Керування доступом належить до заходів безпеки, передбачених захистом персональних даних і кібербезпекою. Аудит може задокументувати фактичний стан, власників дозволів і виконані виправлення. Однак сам по собі він не доводить повної відповідності GDPR, директиві NIS2 або českého zákona č. 264/2025 Sb., o kybernetické bezpečnosti.

Кого охоплює новий закон, пояснює стаття NIS2 і zákon 264/2025 Sb.. Відповідність також залежить від керування ризиками, резервного копіювання, реагування на інциденти, керування постачальниками, безперервності роботи та інших заходів. Тому твердження «ми провели аудит доступу, отже всі вимоги виконано» не є обґрунтованим висновком.

Найпоширеніші запитання

Скільки часу триває аудит прав доступу?

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

Чи потрібно під час аудиту змінювати паролі?

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

Чи завжди посилання «будь-хто, хто має посилання» є помилкою?

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

Чи достатньо видалити колишнього працівника з груп?

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

Як зрозуміти, що аудит не був лише формальністю?

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

Де нас знайти

ITHOPE — компанія з Брно, Чехія: ми робимо відновлення даних з дисків, RAID і NAS, сервіс ПК та ноутбуків та IT для бізнесу, усе у власній лабораторії за адресою Viniční 3587/216, 615 00 Brno.

Телефон +420 775 556 063 (цілодобово). Пристрій можна привезти особисто або надіслати курʼєром (Zásilkovna, PPL).