Sunday, July 23rd, 2017

Процесс подлинности жизненного цикла и вы (Часть 2)

Published on Февраль 2, 2009 by   ·   Комментариев нет

Как настроить вашу подлинность (Identity), и как ее использовать для получения доступа внутри сети? Прочитайте вторую часть этой статьи и вы узнаете все это и многое другое.

Если вы пропустили предыдущую часть этой статьи, то, пожалуйста, прочитайте Процесс подлинности жизненного цикла и вы (Часть 1).

Что делать с подлинностью?

В моей предыдущей статье мы говорили о подлинности и о том, как она используется в сети. Теперь, когда вы знаете предмет обсуждения, возникает вопрос – а что с этим делать?

Вашей первой линией обороны и основой всех ваших политик безопасности (security policies) должен быть хороший процесс управления подлинностью (identity management process). Обратите внимание, что я не произнес слов — хороший продукт для управления подлинностью (identity management product). Если вы выберете что-нибудь позже для автоматизации вашего процесса, то это будет превосходно. Если нет, то это также будет превосходно, если только у вас есть процесс, определенный или используемый вашим бизнесом, который удовлетворяет вашим потребностям и которому вы постоянно следуете. Дополнительно, для удовлетворения вашим операционным нуждам, хороший процесс для управления подлинностью должен также удовлетворять требованию – он должен быть доступен для использования только в определенное время.

По прошествии длительного времени, я собирал некоторые идеи и концепции по реализации, которые бы помогли в создании и использовании хорошего процесса для управления подлинностью (identity management process).

Одно из важнейших требований, о котором я слышал, заключалось в том, что вы никогда не можете удалить сетевую подлинность (network identity) для регулярных требований. Это немного пугает, т.к. до тех пор пока существуют главные по безопасности, есть возможность для их использования по крайней мере для входа в сеть. Какой здесь риск? По умолчанию, сетевая подлинность пользователя (user network identity) или глава по безопасности (security principal) …

Главные по безопасности (Security principals) – это объекты безопасности (security objects) для которых может быть проведена аутентификация в сети. Они противопоставлены объектам старой директории (old directory objects), у которых нет значения для безопасности, но они должны присутствовать в директории для других нужд

…позволяет заходить на рабочую станцию, что может привести к возможности проведения незаметных атак. Существует также причастность пользователей, использующих эту идентификацию для проведения неотслеживаемых действий. Что еще хуже, неиспользуемые главы безопасности (security principals) редко получают такую же заботу и внимание, которую получают активные главы безопасности.

Чрезмерно сложные схемы процесса также приводят к появлению проблем. Это может привести к ошибкам и открытому доступу там, где он не должен быть, или что еще хуже, отказом в доступе там, где он должен быть! Я видел много примеров чрезмерно сложных схем, которые можно было легко обмануть. В одном магазине, я видел, что учетная запись сетевого администратора использовалась практически всеми, потому что так было проще, чем правильно назначить права всем пользователям. Ужас!

Очевидно, что эти результаты противоположны своей изначальной цели – аутентификации и авторизованного доступа для пользователей, которым он необходим, и защите информации от посторонних. Каков мой совет? Сделайте их максимально простыми.

Что вы можете сделать? Создайте процесс, который примет во внимание весь жизненный цикл подлинности (identity) во всех ваших системах в вашей сети или для тех, у которых есть доступ к ней. Затем создайте план.

Создайте таблицу жизненного цикла (lifecycle table). У вас есть начало, середина и конец? Если нет, то добавьте или исключите главы безопасности. Если вы еще ничего не придумали, то по крайней мере сфокусируйтесь на начале и конце жизненного цикла (lifecycle). Это ваша карта и критерий успеха, по которой вы протестируете свое решение. Потратьте на это достаточно времени!

  1. Создайте таблицу типов пользователей (user types). Например: Vendor (поставщик), Contractor (подрядчик), Employee (служащий), Administrator (администратор) и Manager (менеджер) могут быть вашими типами. У вас их может быть больше, но очень важно знать обо всех звеньях цепочки, перед тем как вы зайдете слишком далеко в вашем анализе.
  2. Для каждого типа пользователя в вашей карте, определите подтипы (sub types) и взаимоотношения (relationships). Например, у вас есть больше, чем одна система, которая описывает администратора? Если это так, то нужны ли вам несколько подтипов администраторов?
  3. Опишите наложения (overlap) между вашими типами. У вас есть поставщики, которые являются администраторами? У вас есть подрядчики, которые являются также пользователями? Поставщики, которые также являются администраторами? Может вы создать единый шаблон для доступа (common access pattern)? Если нет, то поиграйте с форматом до тех пор, пока не сможете создать единые требования для доступа.
  4. Далее, вы должны назначить приоритеты для различных ступеней жизненного цикла подлинности (identity lifecycle). Часто циклы выглядят следующим образом: создание, изменение и удаление. Внутри каждого этапа могут быть подъэтапы, которые включают подготовку к работе ресурсов, прав доступа и т.д. Это очень важно, т.к. доступ к ресурсам может быть гибким и часто меняться. Ваш процесс должен учитывать эту гибкость и при этом не должна страдать безопасность.
  5. Рассмотрите, как вы сможете уберечь свой процесс от обмана. Это легко? Это естественно для вашего окружения? Это слишком сложно, и я постоянно должен делать исключения? Должен ли он постоянно нуждаться в поддержке или же он работает в полуавтоматическом режиме? Некоторые из моих учетных записей должны проверяться, но как насчет других классов? Может быть обычный класс Employee быть создан и удален без дополнительных рассмотрений?
  6. Создайте начальную матрицу прав (initial rights matrix) для типов пользователей. Это позволит вам создать главы безопасности и получить основной уровень использования не изготавливая дополнительные схемы функций работы. Это гораздо все более не обычно, чем мы обсуждали в этом документе.
  7. Создайте план гарантирующий удаление подлинности. Это очень важно для усиления ваших политик.
  8. Создайте план реализации (implementation plan).

Выглядит все это не сложно, но это может занять немного времени, прежде чем все будет тщательно исследовано и разложено по полочкам. Выделите для этого время и помните, что это очень важно, и что это марафон, а не спринт.

Пример информации о жизненном цикле процесса

Пример может выглядеть следующим образом:

Таблица Жизненного цикла

Задача

Вречя процесса

Создание

Начало

Удаление/Архивирование

Конец

Модификация

Середина

Перемещение

Середина

Типы, подтипы и наложения пользователей.

Тип

Доступ к подтипам

Наложение

Поставщик

Гость, Пользователь Интернета

Гость

Подрядчик

Гость, Пользователь Интернета, Администратор

Служащий, Администратор, Менеджер

Служащий

Пользователь, Менеджер Идентификации

Менеджер, Администратор, Сторонние Администраторы, Подрядчик

Менеджер

Пользователь, Менеджер Идентификации

Администратор, Сторонние Администраторы, Служащий

Администратор

Другие Системные Администраторы

Администратор, Сторонние Администраторы, Служащий

Гость

Пользователь Интернета, Временный Доступ

Поставщик

Схема процесса (Process flow):

  1. Новый запрос на доступ (New access request)
    1. Определение типа доступа: Vendor, Contractor, Employee, Manager, Administrator, Guest
  2. Создание новой сетевой подлинности (Create new network identity)
  3. Изменение запроса (Change request)
    1. Определение типа изменения – move (перемещение), additional access (дополнительный доступ), less access (уменьшения прав доступа), и т.п.
  4. Осуществление изменений в запросе (change request)
  5. Конец жизни подлинности (Identity End of Life)
    1. Сохранение необходимой информации (Archive necessary information)
    2. Удаление подлинности и получение доступа в любом месте, где она появляется в сети (обратите внимание, что централизованные директории облегчают это)

Источник www.windowsecurity.com


Смотрите также:

Tags:

Readers Comments (Комментариев нет)




Да человек я, человек! =)

Exchange 2007

Проведение мониторинга Exchange 2007 с помощью диспетчера System Center Operations Manager 2007 (часть 3)

Если вы хотите прочитать предыдущие части этой серии статей, перейдите по ссылкам: Проведение мониторинга Exchange 2007 с помощью диспетчера System ... [+]

Практическое рассмотрение перехода с Exchange 2003 на Exchange 2007 (часть 1)

Введение В этой статье из нескольких частей я хочу показать вам процесс, который недавно использовал для перехода с существующей среды Exchange 2003 ... [+]

Использование инструмента Exchange Server Remote Connectivity Analyzer Tool (часть 2)

Если вы пропустили первую часть этой серии, пожалуйста, прочтите ее по ссылке Использование инструмента Exchange Server Remote Connectivity Analyzer Tool (Часть ... [+]

Мониторинг Exchange 2007 с помощью диспетчера System Center Operations Manager 2007 (часть 2)

Если вы пропустили предыдущую часть этой серии статей, перейдите по ссылке Мониторинг Exchange 2007 с помощью диспетчера System Center Operations ... [+]

Подробное рассмотрение подготовки Active Directory для Exchange 2007 (часть 5)

Если вы пропустили предыдущие части этой серии статей, перейдите по ссылкам: Подробное рассмотрение подготовки Active Directory для Exchange 2007 (часть 1) ... [+]

Установка и настройка Exchange 2007 из командной строки (Часть 3)

If you missed the previous parts in this article series please read: Exchange 2007 Install and Configuration from the command line (Part ... [+]

Использование инструмента Exchange Server Remote Connectivity Analyzer Tool (часть 1)

Инструмент ExRCA Текущий выпуск инструмента предоставляется только в целях тестирования и оснащен 5 опциями: Тест подключения Outlook 2007 Autodiscover Тест подключения Outlook 2003 RPC ... [+]

Развертывание сервера Exchange 2007 Edge Transport (часть 5)

Если вы хотите прочитать предыдущие части этой серии статей, перейдите по ссылкам: Развертывание сервера Exchange 2007 Edge Transport (часть 1) Развертывание ... [+]

Установка и настройка Exchange 2007 из командной строки (часть 2)

Если вы пропустили первую статью данного цикла, пожалуйста, перейдите по ссылке: Exchange 2007 Install and Configuration from the command line (Part ... [+]

Использование интегрированных сценариев Using Exchange Server 2007 – часть 2: генерирование отчетов агента Transport AntiSpam Agent

Если вы пропустили предыдущую часть этой серии статей, перейдите по ссылке Использование интегрированных сценариев Using Exchange Server 2007 – часть ... [+]