Реализация принципа наименьших привилегий

Независимо от того, являетесь ли вы сотрудником службы безопасности, сетевым администратором, менеджером или руководителем, вы не только знаете, но и обеспокоены тем ущербом, который обычный конечный пользователь может причинить сети. Снова и снова было доказано, что большинство атак исходят из-за границ брандмауэра, выполняемого сотрудниками. Вот почему так важен принцип наименьших привилегий. Если типичные конечные пользователи могут быть ограничены в своих возможностях, то их масштабы ущерба могут быть ограничены и, надеюсь, остановлены.

Введение

Концепция принципа наименьших привилегий становится общепринятой, поскольку компании изо всех сил пытаются защитить сетевые активы и ресурсы. Давление усугубляется проверками безопасности, которые проводятся в связи с законами Сарбейнса-Оксли, HIPAA и т.п. Цель принципа наименьших привилегий состоит в том, чтобы предоставить пользователям только тот доступ и привилегии, которые им необходимы для выполнения поставленной задачи. В большинстве случаев это будет для всего сеанса входа в систему, с момента входа утром до ухода на ночь.

Чего никому не хочется, так это давать пользователям слишком много доступа, особенно административного. Однако компании слишком часто предоставляют пользователям такой доступ. Если вы одна из этих компаний, вы не одиноки. Следующий сценарий может оказаться слишком близким для вас:

Сотрудник А работает в бухгалтерии. Сотрудник А работает с кредиторской задолженностью и не имеет административного доступа к своему компьютеру. После реорганизации отдела бухгалтерского учета Сотрудник А становится ответственным за ведение отчетов на конец месяца для приложения «Расчеты с поставщиками». Когда EmployeeA пытается запустить отчет в первый раз, в приложении появляется сообщение об ошибке, указывающее, что у EmployeeA недостаточно прав для выполнения задачи. Вызывается ИТ-персонал, чтобы попытаться устранить проблему и предоставить Сотруднику А доступ для запуска отчетов. После нескольких часов расследования было установлено, что единственный способ, с помощью которого EmployeeA может запускать отчеты, — это предоставление прав администратора на ее компьютере. Администратор добавляет учетную запись пользователя домена EmployeeA в локальную группу администраторов в локальном диспетчере учетных записей безопасности (SAM) на компьютере EmployeeA. После быстрого выхода из системы и входа в систему EmployeeA теперь может без проблем запускать отчеты.

Если вы съеживаетесь после прочтения этого сценария, это хорошая реакция. Если вы говорите «ну а что еще можно сделать?», эта статья идеально подходит для вас. Конечно, теперь EmployeeA обладает всеми административными возможностями на своем компьютере и может выполнять практически любую задачу, независимо от того, что хочет ограничить администратор домена. Некоторые из этих задач включают в себя удаление группы «Администраторы домена» из локальной группы «Администраторы» и удаление компьютера из домена, чтобы любые параметры групповой политики не влияли на компьютер.

Идеальным решением было бы каким-то образом обеспечить принцип наименьших привилегий для EmployeeA, чтобы она могла запускать отчеты как администратор, но все остальные задачи были ограничены обычным пользователем. Это возможно, но может занять немного работы. Здесь мы рассмотрим некоторые из наиболее распространенных методов обеспечения принципа наименьших привилегий. Мы также рассмотрим плюсы и минусы каждого из решений.

Использование запуска от имени

Функция «Запуск от имени», впервые представленная в Windows 2000, была решением Microsoft для функции суперпользователя в Unix. Концепция функции запуска от имени очень проста. Если мы используем приведенный выше пример в качестве нашей платформы, вы быстро увидите всю мощь этой функции.

Сотрудник А первым делом утром входит в систему со своей стандартной учетной записью пользователя. Эта учетная запись называется EmployeeA. Администратор создает новую учетную запись пользователя домена для EmployeeA и называет ее EmployeeA_SU. Администратор также добавляет учетную запись EmployeeA_SU в локальную группу администраторов на компьютере EmployeeAs. Когда Сотруднику А необходимо запустить отчет из приложения для расчета кредиторской задолженности, он запускает приложение с помощью функции «Запуск от имени» и входит в систему с учетной записью Сотрудника А_SU. На рис. 1 показано, как выглядит интерфейс функции запуска от имени. Закончив работу с отчетами, она закрывает приложение и продолжает свою работу в качестве обычного пользователя.

Рис. 1. Использование функции «Запуск от имени» позволяет вводить разные учетные данные для определенных приложений.

Опять же, вы можете сказать «да» или «нет» этому сценарию. Для тех из вас, кто говорит «да», рассмотрим следующую проблему. Что мешает пользователю первым делом утром войти в систему с учетной записью EmployeeA_SU? Если вы не запретите такое поведение, что практически невозможно сделать, не нарушая функцию «Запуск от имени» для пользователя, он сможет выполнить эту задачу. Для тех из вас, кто говорит «нет», о каком решении вы думаете?

Использование группы опытных пользователей

Возможно, вы рассматриваете возможность использования группы опытных пользователей, которая доступна на клиентах и рядовых серверах. Эта группа хранится в локальном SAM каждого компьютера, а не в базе данных Active Directory. Идея группы состоит в том, чтобы обеспечить промежуточный уровень доступа между стандартным конечным пользователем и локальным администратором. В прошлом группа «Опытные пользователи» использовалась для предоставления пользователям доступа к определенным функциям операционной системы и обычного доступа к ресурсам. Однако группа «Опытные пользователи» не решает всего спектра задач, связанных с приложениями и операционной системой. Многие приложения и задачи операционной системы требуют административного доступа.

Microsoft осознала это и движется к принципу наименьших привилегий в будущих выпусках операционной системы. Поскольку группа «Опытные пользователи» в большинстве случаев не предоставляет желаемого доступа, Microsoft обесценивает возможности группы «Опытные пользователи» в следующей версии Windows под кодовым названием Longhorn. Неясно, как Microsoft будет повышать необходимые привилегии, которые в настоящее время имеет группа опытных пользователей, но ясно, что концепция наименьших привилегий является горячей темой и ее следует учитывать в каждой ситуации.

Использование прав пользователя для минимальных привилегий

Распространенным методом настройки минимальных привилегий для пользователей на их компьютерах является использование прав пользователя. Права пользователей обеспечивают систематический способ повышения привилегий с помощью групповой политики. Некоторые примеры общих прав пользователя для доступа с наименьшими привилегиями включают:

• Изменить системное время
  
• Установить драйверы устройств
  
• Локальный вход
  
• Добавляем рабочие станции в домен
  
• Действовать как часть операционной системы
  
• Резервное копирование файлов и папок

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

Наименее привилегированный доступ к приложению

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

Чтобы получить решение, отвечающее всем вашим требованиям, вам может потребоваться изучить стороннее решение. Есть из чего выбирать, но один из них лучше других решает концепцию доступа к приложениям с наименьшими привилегиями — это PolicyMaker Application Security от DesktopStandard. Основным преимуществом этого решения является то, что оно идеально согласуется с собственной реализацией и развертыванием групповой политики, которая присутствует в каждой установке Active Directory.

Технология Application Security может показаться сложной, но на самом деле она проста. Инструмент работает, добавляя новую запись в токен безопасности для приложения, которому требуются повышенные привилегии. Чтобы понять, как это работает, давайте поработаем с исходным примером, чтобы увидеть, как работает Application Security.

Новая групповая политика создается для EmployeeA с помощью PolicyMaker Application Security. Новая политика указывает, что группа администраторов будет добавлена к маркеру безопасности для приложения расчетов с поставщиками, для которого пользователю необходимо запускать отчеты. Групповая политика автоматически применяется к EmployeeA при фоновом обновлении. Когда EmployeeA запускает приложение "Расчеты с поставщиками", маркер безопасности создается из исходного маркера безопасности, созданного при входе в систему, а также дополнительной информации, предоставляемой новой политикой. Когда EmployeeA пытается запустить отчет из приложения кредиторской задолженности, задача разрешается. Когда Сотрудник А выходит из приложения "Расчеты с поставщиками", созданный маркер безопасности удаляется, что лишает Сотрудника А административного доступа к любым другим функциям или приложениям операционной системы.

Резюме

Каждая компания должна внедрить принцип наименьших привилегий, прежде чем конечные пользователи получат слишком большой контроль над своим компьютером и сетью. Встроенные возможности запуска от имени, опытных пользователей и прав пользователей могут обеспечить некоторое облегчение, но они имеют негативные последствия, которые делают их далеко не идеальными решениями. Если вы выходите за рамки стандартных функций операционной системы Windows, вы можете найти решения, которые органично вписываются в то, что предоставляет Active Directory, эффективным и совершенным способом, обеспечивающим доступ с минимальными привилегиями.