Я администратор Windows, поэтому те, которые интегрируются с Windows, будут наиболее полезны. Моя основная проблема на данный момент связана только с общими файловыми ресурсами, но по мере роста использования SharePoint это только усложнит задачу.
У меня настроены все мои каталоги, и разрешено множество групп безопасности, настроенных с политикой минимального доступа. Моя проблема заключается в отслеживании всего этого по причинам, связанным с персоналом и соблюдением требований.
Пользователю A необходимо разрешение на ресурс 1. Ему необходимо получить одобрение от менеджера ресурса 1, а затем менеджер менеджеров также должен утвердить этот доступ. Как только все это будет сделано, я могу внести изменения. На данный момент мы просто отслеживаем это на бумаге, но это такое бремя и, вероятно, выйдет из строя, когда пользователь A будет переназначен и больше не должен иметь доступ к ресурсу 1 среди других сценариев.
Я знаю, что то, что я ищу, уже должно существовать, но я не знал, где искать, и обращаюсь к сообществу.
РЕДАКТИРОВАТЬ:
Спасибо за ответы. Я думаю, они касаются технической стороны, и, надеюсь, мой вопрос не не по теме. Я должен был более четко сформулировать свою цель. Какие системы вы используете, чтобы показать аудитору, что на дату X пользователю A было добавлено / удалено разрешение, и оно было одобрено менеджером Y? В настоящее время у меня есть базовая система продажи билетов, но я не вижу, чтобы она доставляла то, что мне нужно, в удобном для понимания формате.
На мой взгляд, я представляю что-то, что будет иметь отчет о пользователе A, в котором будут показаны все изменения, внесенные в его разрешения. В идеале было бы идеально что-то связанное с Active Directory, но на данный момент я надеюсь найти что-то более простое. Надеюсь, что специально для этого есть приложение. Я считаю, что это должно быть требованием для крупных предприятий, и такое программное обеспечение существует.
Спасибо!
Для этого существует несколько коммерческих приложений. Эту область иногда называют «Управление данными».
Пара примеров:
Пакет управления данными Varonis
http://www.varonis.com/products/data-governance-suite/index.html
Quest One Identity Manager - издание для управления данными
http://www.quest.com/identity-manager-data-governance
Я не использую их, но изучив тему и просмотрев несколько демонстраций, объем того, что может потребоваться, объяснил бы рынок. Эти приложения очень сложные и недешевые. Некоторые из них имеют очень сложные методы подключения к платформам хранения для отслеживания списков управления доступом. Даже если это не входит в ваш бюджет, демонстрации могут быть полезны, чтобы получить представление о том, что такое приложение делает с функциональной точки зрения.
Одно наблюдение, которое я сделал при просмотре этого, заключается в том, что они обычно не проводят аудит на уровне файлов. Если бы они это сделали, не было бы возможности масштабировать его до сотен миллионов или миллиардов документов. Таким образом, они обычно отслеживают разрешения только на уровне каталога.
Если у вас уже есть система продажи билетов, я бы предложил создать новую группу или тег и т. Д. В вашем приложении для этих типов запросов и попросить пользователей отправлять билеты для изменения разрешений. Если ваша система продажи билетов позволяет пересылать билеты другим пользователям или добавлять их в заявку, добавьте необходимых менеджеров и запросите подтверждение. Это позволит вам вести учет для вашей работы.
Как упоминалось выше, создайте группу безопасности для каждого общего ресурса. В моей среде у нас были бы акции с именами FIN_Yearly, GEN_Public, MGM_Reports (у каждого отдела есть собственный акроним). Группы безопасности тогда будут называться SG_FIN_YearlyAdmin, SG_FIN_YearlyUser, SG_GEN_PublicAdmin и т. Д. Пользователь доступен только для чтения, Admin - для чтения / записи.
Отсюда вы можете создать, например, SG_FinancialsManager; группы безопасности, которые включают другие группы безопасности для упрощения доступа в зависимости от выполняемых ими заданий. Мы лично этого не делаем, так как это немного запутывает отслеживание. Вместо того, чтобы проверять SG общего ресурса и видеть кучу SG с разрешениями, у нас есть список пользователей. Личные предпочтения, на самом деле, и будут зависеть от размера вашего сайта. Обычно мы используем пользовательские шаблоны для управления новыми пользователями на определенные должности.
Если ваша система продажи билетов позволяет вам просматривать предыдущие билеты, вы в значительной степени справились. Если кто-то просит вас удалить разрешения пользователя, вы можете отслеживать это. Если пользователь затем спрашивает, почему у него больше нет доступа, вы можете предоставить ему билет. Если менеджер спросит вас, у кого к чему есть доступ, отобразит запрошенную группу безопасности.
Вам нужна система продажи билетов, которая предусматривает 3 вещи:
Практически все билетные системы уже предоставляют вам номер 1 в виде даты создания билета, даты изменения и т. Д. № 2 - это ваше право задокументировать в билете. Обычно это письмо с подтверждением от менеджера ресурсов, вставленное в заявку, в котором говорится, что у них есть доступ (или доступ должен быть удален) и какого типа. №3 является наиболее важным и зависит от системы продажи билетов, но если у вас есть система, в которой нелегко искать, то ваша работа вам подойдет. Если вы можете просто выполнить поиск по пользователю, чтобы все билеты разрешений были привязаны к их контактной информации в системе продажи билетов, тогда вы в порядке, в противном случае вы по существу документируете свои изменения в черной дыре.
Вне системы продажи билетов, которая может делать это для отслеживания изменений (вы упоминаете, что у вас есть базовая система продажи билетов, поэтому, возможно, вам нужно получить лучшую, которая позволяет улучшить возможности поиска / отчетности), любое приложение, утилита или сценарий, который вы используете предоставит только снимок разрешений. Вы все еще не знаете, почему? Кто к чему имеет доступ, что может быть должным образом задокументировано только отдельно от приложения, поскольку вам, вероятно, потребуется захватить исходное электронное письмо или другой текст утверждения от менеджера ресурсов. Когда вы его получите, куда вы его поместите, чтобы связать с результатами приложения?
Запуск приложения или сценария для определения текущих разрешений в файловой структуре также не предоставляет вам хороший контрольный журнал изменений разрешений для пользователя. По сути, вы застряли с большим снимком текущих разрешений на определенный момент времени. Когда вы запустите его снова, у вас будет еще один большой снимок прав доступа к файлам. Даже если вы сохранили первый захват разрешений и сравнили его с последним захватом, и разрешения изменились, как вы увяжете это с причиной изменения? Опять же, это возвращает нас к системе продажи билетов, поскольку пункты 1,2 и 3, указанные выше, будут задокументированы в одном месте.
Еще одна проблема, которую вы подняли, - это сползание разрешений (когда пользователю переназначается другое разрешение и ему больше не нужен доступ к ресурсу X, но он все равно сохраняется, потому что тот факт, что им больше не нужен доступ к ресурсу X, не был запущен ИТ-специалистами. Отдел во время перехода). ЕДИНСТВЕННЫЙ способ контролировать это - сообщить HR или тому, кто занимается переназначением сотрудников, что ИТ-отдел должен быть уведомлен, когда сотрудник переназначен, чтобы они могли назначать и отзывать разрешения соответствующим образом. Вот и все. Не существует волшебного приложения, которое сообщило бы вам, что у пользователя есть доступ к ресурсу X, но больше не должно этого делать, потому что теперь их работа - Y. Когда это произойдет, ИТ-отдел должен в той или иной форме сообщить человеческое уведомление.
Я не знаю о документирование / отслеживание их, но я назначать их с группами.
Пользователю A нужен доступ к ресурсу №1. Они получают разрешение, и я добавляю их в группу доступа.
Они продолжают заниматься своими делами, пока в один прекрасный день не будут переназначены / уволены / что-то еще, после чего я удаляю их из группы доступа.
Журналы аудита изменения моей учетной записи сообщают мне, когда они получили / потеряли доступ, поэтому есть запись об этом, а группы доступа к ресурсам обычно представляют собой группы отделов (HR, ИТ, продажи, финансы и т. Д.), Поэтому управление переназначениями обычно означает изменение их группы членство в любом случае.
Это, как правило, лучше всего работает в небольших средах - для больших сред или тех, где списки 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.
Вы можете просто отслеживать их групповое движение, когда они запрашиваются через вашу систему управления заданиями, или запускать сценарии, чтобы выяснить, кто входит в какие группы на основе ролей.
Две отличные утилиты:
AccessEnum также позволяет сохранять результаты, а затем сравнивать их в будущем, что будет полезно для поиска изменений.
Вам действительно стоит подумать о включении аудита изменений прав доступа к файлам / папкам, а затем собрать журналы безопасности файлового сервера (вручную или с помощью любого инструмента управления журналами событий или SIEM, например Splunk) и использовать их для своей документации. Проанализируйте все изменения файловых DACL. Кроме того, вы дополняете это AccessEnum и AccessChk, как предложено выше.
И это не освобождает вас от необходимости устанавливать надлежащие разрешения безопасности и назначать их только через группы.