Как вы документируете / отслеживаете свои разрешения

Я администратор Windows, так что те, кто интегрируется с Windows, вероятно, будут наиболее полезными. Моя главная проблема на данный момент заключается только в общих файловых ресурсах, но с увеличением использования SharePoint это только усложнит ситуацию.

У меня есть все мои каталоги, и многие группы безопасности, которые настроены с политикой наименьшего необходимого доступа, разрешены. Моя проблема отслеживает все это по причинам HR и соблюдения.

Пользователю A необходимо разрешение на ресурс 1. Он должен получить одобрение менеджера ресурса 1, а затем менеджер менеджеров должен также одобрить этот доступ. Как только все это будет сделано, я могу внести изменения. На данный момент мы просто отслеживаем это на бумаге, но это такое бремя и, вероятно, выпадет из соответствия, когда пользователь А будет переназначен и больше не должен иметь доступ к ресурсу 1 среди других сценариев.

Я знаю, что я ищу, должно уже существовать, но я не знал, где искать, и я обращаюсь к сообществу.

РЕДАКТИРОВАТЬ:

Спасибо за ответы. Я думаю, что они касаются технической стороны, и, надеюсь, мой вопрос не по теме. Я должен был прояснить свою цель. Какие системы вы используете, чтобы показать аудитору, что на дату X пользователь А получил или добавил разрешение, которое было одобрено менеджером Y? В настоящее время у меня есть базовая система продажи билетов, но я не вижу, чтобы она доставляла то, что мне нужно, в удобном для понимания формате.
На мой взгляд, я представляю что-то, что будет иметь отчет о пользователе А, который будет показывать все изменения, которые были внесены в их разрешения. В идеале что-то, связанное с Active Directory, было бы идеально, но на данный момент я надеюсь найти что-то более простое. Я надеюсь, что есть приложение специально для этого.

Благодарность!

Вам нужна система билетов, которая обеспечивает 3 вещи:

1. Отметка времени, когда разрешения были изменены (добавлены или удалены) для конкретного пользователя
2. Почему они были изменены
3. Возможность поиска этих изменений

Почти все системы продажи билетов уже предоставляют вам номер 1 в форме даты создания, изменения даты и т. Д. № 2 зависит от вас, чтобы документировать в билете. Обычно это подтверждающее электронное письмо от менеджера ресурсов, вставленное в заявку, в котором говорится, что у них может быть доступ (или доступ должен быть удален) и что за тип. № 3 является наиболее важным и зависит от системы тикетов, но если у вас есть система, которую нелегко искать, то ваша работа исключена для вас. Если вы можете просто выполнить поиск по пользователю, чтобы все билеты разрешений были привязаны к его контактной информации в системе создания билетов, то у вас все хорошо, в противном случае вы, по сути, документируете свои изменения в черной дыре.

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

Запуск приложения или сценария для определения текущих разрешений в файловой структуре также не дает вам возможности отслеживать изменения разрешений для пользователя. По сути, вы застряли с большим снимком текущих разрешений в определенный момент времени. Когда вы запустите его снова, у вас будет еще один большой снимок прав доступа к файлам. Даже если вы сохранили первый захват разрешений и сравнили его с последним захватом, а разрешения изменились, как вы связываете это с причиной изменения? Опять же, это возвращает нас к системе тикетов, поскольку #s 1,2 и 3, приведенные выше, будут задокументированы в одном месте.

Еще одна проблема, которую вы затронули, - это ползучесть разрешений (когда пользователь переназначается на другое разрешение и ему больше не нужен доступ к ресурсу X, но он все равно сохраняется, потому что тот факт, что ему больше не нужен доступ к ресурсу X, не был запущен ИТ-отделом. Депт при переходе). Единственный способ контролировать это - сообщить персоналу отдела кадров или тому, кто занимается перераспределением сотрудников, о том, что ИТ-отдел должен быть уведомлен о переназначении сотрудника, чтобы они могли назначать и отзывать разрешения соответствующим образом. Вот и все. Не существует волшебного приложения, которое сообщало бы вам, что пользователь имеет доступ к ресурсу 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

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

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

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

Пользователю А нужен доступ к ресурсу № 1. Они получают разрешение, и я добавляю их в группу доступа.
Они занимаются своими делами до тех пор, пока однажды их не назначат / уволят / с чего бы то ни было, после чего я удаляю их из группы доступа.

Журналы аудита изменений моих учетных записей сообщают мне, когда они получили / потеряли доступ, поэтому есть запись об этом, и группы доступа к ресурсам, как правило, представляют собой группы отделов (HR, IT, Sales, Finance и т. Д.), Поэтому управление переназначениями обычно означает изменение их группы. членство в любом случае.

Это лучше всего работает в небольших средах - в больших средах или в тех, где ACL-списки становятся действительно сложными. Zoredache делает хороший вывод о том, что система, которая выполняет ACL-твикинг, также в некоторой степени выполняет документирование

Для инициирования запроса на добавление / удаление доступа, переназначение пользователей и т. Д. Я бы предложил электронную бумагу (систему продажи билетов) - это гарантирует, что пользователи не пробьются сквозь трещины, но требует общего корпоративного бай-ина, чтобы использовать электронную систему неукоснительно ,
Преимущество перед бумагой заключается в том, что вы получаете то, что можете искать, и каждый может выполнить свою часть процесса со своего рабочего места (руководители могут одобрить это быстрее, поскольку нет никакого перемещения почтового конверта между офисами, ИТ-специалисты могут предоставить / отозвать доступ, как только как билет появляется в чьей-то корзине и т. д.)

Лучший способ установки разрешений - это ролевая установка.

GG_HR GG_Finance Etc, как правило, сопоставляется с позицией или бизнес-единицей.

Оттуда вы создаете локальные группы, которые имеют разрешение на ресурс, т. Е. На принтер или каталог финансов. LG_RoomXПринтер LG_Finance_Читать 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, как предложено выше.

И это не освобождает вас от настройки надлежащих разрешений безопасности и назначения их только через группы.