Як документувати / відстежувати свої дозволи

Я адміністратор Windows, тому ті, що інтегруються з Windows, ймовірно, будуть найбільш корисні. Моя основна проблема в цьому випадку полягає лише у спільному використанні файлів, але в міру збільшення використання SharePoint це ускладнить лише це.

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

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

Я знаю, що шукаю, повинно вже існувати, але я не знав, де шукати, і я звертаюся до громади.

Редагувати:

Дякуємо за відповіді. Я думаю, що вони торкаються технічної сторони, і, сподіваюся, моє питання не є темою. Я мав би зробити себе яснішим щодо своєї мети. Які системи ви використовуєте, щоб показати аудитору, що на X дату користувач A мав доданий / видалений дозвіл і його було схвалено менеджером Y? Наразі у мене є основна система квитків, але я не вважаю, що вона забезпечує те, що мені потрібно, у простому для розуміння форматі.
На моїй думці я зображую щось, у якому був би звіт про користувача A, який би відображав усі зміни, внесені до їх дозволів. В ідеалі щось, що посилається на Active Directory, було б ідеально, але на даний момент я сподіваюся знайти щось більш базове. Я сподіваюся, що для цього є спеціально додаток.

Дякую!

Вам потрібна система квитків, яка містить 3 речі:

1. Позначення часу, коли дозволи певного користувача були змінені (додані або видалені)
2. Чому їх змінили
3. Можливість пошуку цих змін

Практично всі системи продажу квитків вже надають вам номер 1 у формі дати створення квитка, модифікованої дати тощо. №2 вирішується документувати у квитку. Зазвичай це електронний лист із схваленням від менеджера ресурсів, вставленого в квиток, в якому йдеться про те, що вони можуть мати доступ (або доступ повинен бути видалений) та який тип. №3 є найважливішим і залежить від системи продажу квитків, але якщо у вас система нелегка для пошуку, то ваша робота вирішується для вас. Якщо ви можете просто здійснити пошук користувачем, щоб усі квитки на дозвіл були прив’язані до їх контактної інформації в системі квитків, тоді ви добре, інакше ви фактично документуєте свої зміни в чорну діру.

Поза системою продажів квитків, яка може це зробити для відстеження змін (ви згадуєте, що у вас є основна система квитків, тому, можливо, вам потрібно отримати кращу, яка дозволяє покращити можливість пошуку / звітування), будь-яку програму, утиліту або сценарій, який ви використовуєте надасть лише короткий знімок дозволів. Ви все ще застрягли в "чому?" хто має доступ до того, що може бути належним чином задокументовано окремо від програми, оскільки, ймовірно, вам потрібно буде зафіксувати оригінал електронної пошти чи інший текст схвалення від менеджера ресурсів. Коли у вас є це, де ви ставите це, щоб пов’язати його з результатами програми?

Запуск програми або сценарію для визначення поточних дозволів у структурі файлів також не дає вам приємного сліду аудиту змін дозволів для користувача. Ви по суті застрягли з великим знімком поточних дозволів за один момент часу. При повторному запуску у вас з’явиться ще один великий знімок дозволів на файли. Навіть якщо ви зберегли перший захоплення дозволів і порівняли його з останнім захопленням, і дозволи змінилися, як ви пов'язати це з причиною зміни? Знову ж таки, це повертає нас до системи квитків, оскільки №1, 1,2 і 3 вище будуть задокументовані в одному місці.

Ще одна проблема, яку ви порушили, - це повзання дозволів (коли користувач перенаправляється на інший дозвіл і більше не потребує доступу до ресурсу X, але все одно зберігає його, оскільки той факт, що їм більше не потрібен доступ до ресурсу X, не керував ІТ Департамент під час переходу). ТІЛЬКИ спосіб контролювати це - сказати HR або тому, хто займається переназначенням працівників, що ІТ потрібно повідомити, коли працівник перепризначений, щоб вони могли призначити та скасувати дозволи відповідно. Це воно. Немає жодної магічної програми, яка скаже вам, що користувач має доступ до ресурсу X, але більше не повинен, тому що їх робота зараз Y. Повідомлення людини в якійсь формі має бути надано ІТ, коли це станеться.

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

Як було сказано вище, створіть групу безпеки для кожної акції. У моєму середовищі ми мали б акції під назвою FIN_Yearly, GEN_Public, MGM_Reports (у кожного відділу є своя абревіатура). Потім групи безпеки будуть названі SG_FIN_YearlyAdmin, SG_FIN_YearlyUser, SG_GEN_PublicAdmin тощо. Користувач лише для читання, адміністратор читається / пише.

Звідси ви можете створити, наприклад, SG_FinancialsManager; групи безпеки, які включають інші групи безпеки з метою спрощення доступу на основі завдань, які вони виконують. Ми особисто цього не робимо, оскільки це трохи затуманило відстеження. Замість того, щоб перевірити SG-пакет акцій та побачити купу SG із дозволами, натомість у нас є список користувачів. Особисті переваги, дійсно, і залежатимуть від розміру вашого сайту. Зазвичай ми використовуємо шаблони користувачів для управління новими користувачами на певних позиціях.

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

Насправді існує кілька комерційних додатків для цього. Територію іноді називають "управління інформацією".

Кілька прикладів:

Varonis Data Governance Suite
http://www.varonis.com/products/data-governance-suite/index.html

Quest One Identity Manager - управління управлінням даними
http://www.quest.com/identity-manager-data-governance

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

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

Я не знаю про їх документування / відстеження , але призначаю їх групам.

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

Журнали аудиту модифікації мого облікового запису повідомляють мені, коли вони отримали / втратили доступ, щоб записати про це, а групи доступу до ресурсів - це як правило відомчі групи (HR, IT, продажі, фінанси тощо), тож управління переділами зазвичай означає зміну групи членство все одно.

Це, як правило, найкраще працює в менших середовищах - для великих середовищ або для тих, де ACL отримують дійсно складний Zoredache - це хороший сенс щодо того, що система, яка робить перегляд ACL, також певною мірою робить документування.

Для ініціювання запиту на додавання / видалення доступу, переназначення користувачів тощо. Я б запропонував електронний папір (система квитків) - це гарантує, що користувачі не будуть прослизати через щілини, але вимагає загального корпоративного входу для релігійного використання електронної системи. .
Перевага перед папером полягає в тому, що ви отримуєте те, що ви можете шукати, і кожен може виконати свою частину процесу зі свого столу (менеджери можуть схвалити швидше, оскільки між офісним поштовим конвертом не рухається, ІТ можуть надати / відкликати доступ, як тільки як квиток з’являється в чиїйсь бункер тощо)

Найкращий спосіб, коли я можу зробити налаштування дозволів, - це рольова основа.

GG_HR GG_Finance Etc, як правило, відображається на позиції чи бізнес-підрозділі.

Звідти ви створюєте локальні групи, які мають дозвіл на ресурсі, тобто принтері або в каталозі Фінанси. LG_RoomXPrinter LG_Finance_Read LG_Finance_FullControl

Ви створюєте глобальні групи для цих локальних груп LG-> GG, потім у свою групу, засновану на ролях, ви додаєте глобальні групи на основі дозволів.

GG_Finance <- LG_Finance_FullControl, LG_RoomXPrinter

Це полегшує те, коли люди потрапляють у роль, яку ти просто додаєш до свого облікового запису до однієї групи, і їхні дозволи переходять від цієї ролі, і набагато простіше їх відстежувати. (Також чудово, якщо ви використовуєте якусь систему управління ідентичністю). Набагато простіше, ніж відстежувати, хто має які індивідуальні дозволи, ви знаєте, що якщо вони в групі HR, вони мають X дозволів.

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

Дві чудові утиліти:

1. AccessEnum: http://technet.microsoft.com/en-us/sysinternals/bb897332
2. AccessChk: http://technet.microsoft.com/en-us/sysinternals/bb664922

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

Справді слід розглянути можливість активації змін дозволу на файли / папки, а потім збирати журнали безпеки файлового сервера (вручну або за допомогою будь-якого інструменту управління журналом подій або SIEM, як Splunk) та використовувати його для вашої документації. Проаналізуйте всі зміни у файлі DACL. Крім того, ви доповните це AccessEnum та AccessChk, як було запропоновано вище.

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