Кілька місяців тому аналітики компанії Varonis, розробника програмних рішень в сфері ІБ, провели дослідження стану інформаційної безпеки в 56 фінансових організаціях по всьому світу (банки, страхування, інвестиційні агентства).

Висновок звіту виявився досить невтішний – практично в кожній другій компанії (44%) понад тисячу файлів були доступні абсолютно кожному співробітнику підприємства, а в кожній п'ятій – близько 10 тисяч файлів виявилися загальнодоступними для всього персоналу.

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

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

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

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

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

При цьому забутьте про такий підхід як «створити пароль на папку». Це незручно, не забезпечує надійний захист і тому – давно неактуально. Користувач має увійти в систему зі своїми акаунтом (ідентифікація), автентифікувати себе за допомогою пароля і автоматично отримати доступ до всіх дозволених ресурсів.

Здавалося б, призначити користувацькі права на робочі ресурси не так складно. Однак це завдання може стати «судним днем» для ІТ-служби, якщо таких папок сотні, а при зміні прав доступу до одній папці «злітають» права на інші. Щоб подібного кошмару не сталося, потрібно слідувати певному регламентому, в якому буде чітко прописано шлях вирішення подібного завдання.

Незалежно від того, в якій системі організація зберігає робочі файли – традиційна екосистема Windows або хмарна типу Google Doc, One Drive, Bitrix24, тощо – слід дотримуватися правила, що доступ до файлів завжди повинен задаватися на рівні каталогів, навіть якщо в цьому каталозі зберігається всього один файл. Розподіляти доступ до окремих файлів недоцільно.

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

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

Також до плутанини може призвести застосування явної заборони на доступ до файлів або каталогу (deny permissions). Потрібно пам'ятати, що коли у групи користувачів немає дозволу на читання чи запис в певну групу – це рівносильно забороні на доступ. Якщо одному зі співробітників потрібно обмежити доступ до файлового ресурсу – потрібно просто видалити його «обліковку» з групи, якій дозволено вхід в цей каталог.

Будь-яка система розмежування повноважень дозволяє надавати доступ мінімум двох типів: «Тільки на читання (Read Only)» і RW «Читання і запис (Read & Write)». Наприклад, група співробітників департаменту реклами в компанії може мати доступ Read & Write до каталогу, що містить документи з маркетингу, і Read Only – до папок з продажу та Public Relations. Одночасно все відділи можуть володіти дозволом Read Only на перегляд файлів у відділі Public Relations.

Багато компаній сьогодні працюють з документами в хмарних системах, наприклад, Google Docs. Ці системи надають такий спокусливий інструмент надання доступу як «пряме посилання» на файл чи папку. Цим інструментом потрібно користуватися дуже акуратно.

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

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

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

Ми спеціально не згадували в цьому тексті інструменти, за допомогою яких розмежуються права.

Звичайно компаніям, у яких ІТ інфраструктура побудована на базі продуктів Microsoft, доцільно використовувати можливості файлової системи NTFS. Однак сьогодні є безліч рішень для розмежування прав доступу до файлової «шари» і навряд чи варто зациклюватися тільки на Windows.

Варто лише запам'ятати кілька базових принципів:

- один користувач – один акаунт;

- ресурси відкриваються тільки для групи, а не для одного акаунта;

- з Deny Permissions потрібно бути дуже обережним, оскільки примусова заборона може поламати всю систему дозволів.

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

Довіряйте, але розділяйте, і завжди будьте в безпеці.