Контроль доступа к компьютеру

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

• 1 Программные объекты
• 2 Услуги
• 3 Авторизация
• 4 Идентификация и аутентификация
• 5 Утверждение доступа
• 6 Учетность
• 7 Контроль доступа
  • 7.1 Дискреционное управление доступом
  • 7.2 Обязательно контроль доступа
  • 7.3 Контроль доступа на основе ролей
  • 7.4 Контроль доступа на основе атрибутов
  • 7.5 Модели контроля доступа Break-Glass
  • 7.6 Контроль доступа на основе ответственности
  • 7.7 Контроль доступа на основе хоста ( HBAC)
• 8 См. Также
• 9 Ссылки

В любой модели управления доступом объекты, которые могут выполнять действия в системе, называются субъектами, а объекты, представляющие ресурсы для доступ к которым может потребоваться контролировать, называются объектами (см. также Матрица управления доступом ). Субъекты и объекты следует рассматривать как программные объекты, а не как пользователей-людей: любые пользователи-люди могут оказывать влияние на систему только через программные объекты, которые они контролируют.

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

В некоторых моделях, например в модели возможностей объекта, любой программный объект потенциально может действовать как субъект, так и объект.

По состоянию на 2014 год модели управления доступом, как правило, делятся на два класса: модели, основанные на возможностях, и модели, основанные на списках управления доступом (ACL).

• В модели, основанной на возможностях, наличие неподдающейся подделке ссылки или возможности на объект обеспечивает доступ к объекту (примерно аналогично тому, как p владение ключом от дома дает человеку доступ в свой дом); доступ передается другой стороне путем передачи такой возможности по защищенному каналу
• В модели на основе ACL доступ субъекта к объекту зависит от того, отображается ли его идентификатор в списке, связанном с объектом (примерно аналогично о том, как вышибала на частной вечеринке будет проверять идентификатор, чтобы увидеть, появляется ли имя в списке гостей); доступ передается путем редактирования списка. (Различные системы ACL имеют множество различных соглашений относительно того, кто или что отвечает за редактирование списка и как он редактируется.)

И модели на основе возможностей, и на основе ACL имеют механизмы, позволяющие предоставлять права доступа всем члены группы субъектов (часто сама группа моделируется как субъект).

Системы контроля доступа предоставляют важные услуги авторизации, идентификации и аутентификации (IA), утверждения доступа, и подотчетность, где:

• авторизация определяет, что субъект может делать
• идентификация и аутентификация гарантируют, что только законные субъекты могут войти в систему
• разрешение доступа предоставляет доступ во время операций по ассоциации пользователей с ресурсами, к которым им разрешен доступ, на основе политики авторизации
• подотчетность определяет, что субъект (или все субъекты, связанные с пользователем)

Авторизация включает акт определения доступа-ри игры для предметов. Политика авторизации определяет операции, которые субъекты могут выполнять в системе.

Большинство современных операционных систем реализуют политики авторизации как формальные наборы разрешений, которые являются вариациями или расширениями трех основных типов доступа:

• Чтение (R): Субъект может
  • Прочитать содержимое файла
  • Список содержимого каталога
• Запись (W): Субъект может изменить содержимое файла или каталога с помощью следующих задач:
  • Добавить
  • Обновить
  • Удалить
  • Переименовать
• Выполнить (X): если файл является программой, объект может привести к тому, что программа будет запустить. (В системах в стиле Unix разрешение на выполнение удваивается как разрешение на просмотр каталога, если оно предоставлено для каталога.)

Эти права и разрешения реализуются по-разному в системах на основе управления дискреционным доступом (DAC) и контроль обязательного доступа (MAC).

Идентификация и аутентификация (IA) - это процесс проверки того, что идентичность привязана к объекту, который делает утверждение или утверждение идентичности. Процесс IA предполагает, что произошла первоначальная проверка личности, обычно называемая проверкой личности. Доступны различные методы подтверждения личности, от личной проверки с использованием удостоверения личности государственного образца до анонимных методов, которые позволяют заявителю оставаться анонимным, но известны системе, если они вернутся. Метод, используемый для проверки и подтверждения личности, должен обеспечивать уровень уверенности, соизмеримый с предполагаемым использованием идентичности в системе. Впоследствии объект подтверждает идентичность вместе с аутентификатором в качестве средства проверки. Единственное требование к идентификатору - это то, что он должен быть уникальным в пределах своего домена безопасности.

Аутентификаторы обычно основаны как минимум на одном из следующих четырех факторов:

• Что-то, что вы знаете, например пароль или личный идентификационный номер (PIN). Это предполагает, что только владелец учетной записи знает пароль или PIN-код, необходимый для доступа к учетной записи.
• Что-то, что у вас есть, например, смарт-карта или токен безопасности. Это предполагает, что только владелец учетной записи имеет необходимую смарт-карту или токен, необходимые для разблокировки учетной записи.
• Что-то, что вы есть, например отпечаток пальца, голос, сетчатка или радужная оболочка глаза.
• Где вы находитесь, например внутри или за пределами брандмауэра компании, или рядом с местом входа в систему с личным устройством GPS.

Утверждение доступа - это функция, которая фактически предоставляет или отклоняет доступ во время операций.

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

Подотчетность использует такие системные компоненты, как контрольные журналы (записи) и журналы, чтобы связать субъект с его действиями. Записанной информации должно быть достаточно для сопоставления субъекта с контролирующим пользователем. Журналы аудита и журналы важны для

• Обнаружения нарушений безопасности
• Повторного создания инцидентов безопасности

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

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

• Более трех неудачных попыток входа в систему за определенный период
• Любая попытка использовать отключенную учетную запись пользователя

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

Определение уровня отсечения: способность диска сохранять свои магнитные свойства и удерживать свое содержимое. Диапазон качественного уровня 65–70%; низкое качество ниже 55%.

Модели контроля доступа иногда подразделяются на дискреционные или недискреционные. Три наиболее широко известных модели - это дискреционный контроль доступа (DAC), обязательный контроль доступа (MAC) и контроль доступа на основе ролей (RBAC). MAC не является дискреционным.

Дискреционный контроль доступа

Дискреционный контроль доступа (DAC) - это политика, определяемая владельцем объекта. Владелец решает, кому разрешен доступ к объекту и какие привилегии у него есть.

В DAC есть две важные концепции:

• Владение файлами и данными: у каждого объекта в системе есть владелец. В большинстве систем DAC первоначальный владелец каждого объекта - это субъект, который вызвал его создание. Политика доступа для объекта определяется его владельцем.
• Права доступа и разрешения: это элементы управления, которые владелец может назначать другим субъектам для определенных ресурсов.

Элементы управления доступом могут быть дискреционными в Системы управления доступом на основе ACL или на основе возможностей. (В системах, основанных на возможностях, обычно нет явного понятия «владелец», но создатель объекта имеет аналогичную степень контроля над своей политикой доступа.)

Обязательный контроль доступа

Обязательный доступ control относится к разрешению доступа к ресурсу тогда и только тогда, когда существуют правила, позволяющие данному пользователю получить доступ к ресурсу. Им сложно управлять, но его использование обычно оправдано при использовании для защиты конфиденциальной информации. Примеры включают определенную правительственную и военную информацию. Управление часто упрощается (сверх того, что может потребоваться), если информация может быть защищена с помощью иерархического контроля доступа или путем внедрения меток конфиденциальности. Что делает метод "обязательным", так это использование правил или меток конфиденциальности.

• Метки конфиденциальности: В такой системе субъектам и объектам должны быть назначены метки. Метка чувствительности субъекта указывает уровень его доверия. Метка конфиденциальности объекта указывает уровень доверия, необходимый для доступа. Чтобы получить доступ к заданному объекту, субъект должен иметь уровень чувствительности, равный или выше запрошенного объекта.
• Импорт и экспорт данных: контроль импорта информации из других систем и экспорта в другие системы (включая принтеров) является важной функцией этих систем, которая должна гарантировать, что метки конфиденциальности должным образом поддерживаются и внедряются, чтобы конфиденциальная информация была должным образом защищена в любое время.

Обычно используются два метода для применения обязательного контроля доступа:

• ( или на основе меток) управление доступом: этот тип управления дополнительно определяет конкретные условия доступа к запрошенному объекту. Система обязательного контроля доступа реализует простую форму контроля доступа на основе правил, чтобы определить, должен ли доступ быть предоставлен или запрещен путем сопоставления:
  • Метка конфиденциальности объекта
  • Метка конфиденциальности объекта
• Управление доступом на основе решеток : их можно использовать для сложных решений по управлению доступом с участием нескольких объектов и / или субъектов. Решетчатая модель - это математическая структура, которая определяет наибольшие нижние и наименьшие верхние значения для пары элементов, таких как субъект и объект.

Немногие системы реализуют MAC; XTS-400 и SELinux являются примерами таких систем.

Управление доступом на основе ролей

Управление доступом на основе ролей (RBAC) - это политика доступа, определяемая системой, а не владельцем. RBAC используется в коммерческих приложениях, а также в военных системах, где также могут существовать многоуровневые требования безопасности. RBAC отличается от DAC тем, что DAC позволяет пользователям контролировать доступ к своим ресурсам, тогда как в RBAC доступ контролируется на системном уровне, вне контроля пользователя. Хотя RBAC не является дискреционным, его можно отличить от MAC прежде всего способом обработки разрешений. MAC контролирует разрешения на чтение и запись в зависимости от уровня доступа пользователя и дополнительных меток. RBAC контролирует наборы разрешений, которые могут включать сложные операции, такие как транзакция электронной торговли, или могут быть такими же простыми, как чтение или запись. Роль в RBAC можно рассматривать как набор разрешений.

Для RBAC определены три основных правила:

1. Назначение ролей: субъект может выполнять транзакцию, только если субъект выбрал или ему была назначена подходящая роль.
2. Авторизация роли: субъект активная роль должна быть авторизована для субъекта. С помощью правила 1, приведенного выше, это правило гарантирует, что пользователи могут брать на себя только те роли, для которых они авторизованы.
3. Авторизация транзакции: субъект может выполнить транзакцию, только если транзакция авторизована для активной роли субъекта. С помощью правил 1 и 2 это правило гарантирует, что пользователи могут выполнять только те транзакции, для которых они авторизованы.

Также могут применяться дополнительные ограничения, и роли могут быть объединены в иерархию, где роли более высокого уровня подчиняют разрешениям, принадлежащим более низким -уровневые подроли.

Большинство ИТ-поставщиков предлагают RBAC в одном или нескольких продуктах.

Управление доступом на основе атрибутов

В управлении доступом на основе атрибутов (ABAC) доступ предоставляется не на основе прав субъекта, связанного с пользователем после аутентификации, но на основе атрибутов пользователя. Пользователь должен подтвердить так называемые утверждения о своих атрибутах механизму контроля доступа. Политика управления доступом на основе атрибутов определяет, какие утверждения должны быть удовлетворены, чтобы предоставить доступ к объекту. Например, иск может быть «старше 18 лет». Доступ предоставляется любому пользователю, который может доказать это утверждение. Пользователи могут быть анонимными, если аутентификация и идентификация не требуются строго. Однако требуются средства для анонимного доказательства претензий. Это может быть достигнуто, например, с помощью анонимных учетных данных. XACML (расширяемый язык разметки управления доступом) является стандартом для управления доступом на основе атрибутов. XACML 3.0 был стандартизирован в январе 2013 года.

Модели управления доступом «Брейк-стекло»

Традиционно доступ имеет целью ограничение доступа, поэтому большинство моделей управления доступом следуют «принципу отказа по умолчанию», т. Е. если конкретный запрос доступа не разрешен явно, он будет отклонен. Такое поведение может противоречить обычным операциям системы. В определенных ситуациях люди готовы пойти на риск, связанный с нарушением политики контроля доступа, если потенциальная выгода, которая может быть достигнута, перевешивает этот риск. Эта потребность особенно заметна в сфере здравоохранения, где отказ в доступе к картам пациентов может привести к смерти пациента. Break-Glass (также называемое «разбить стекло») пытается смягчить это, позволяя пользователям отменять решение о контроле доступа. Break-Glass может быть реализован либо специфическим способом контроля доступа (например, в RBAC), либо общим (т.е. независимым от базовой модели контроля доступа).

Контроль доступа на основе ответственности

В Согласование прав доступа с потребностями управления с метамоделью ответственности (ReMMo) в рамках архитектуры предприятия была определена выразительная метамодель ответственности, которая позволяет представить существующие обязанности на бизнес-уровне и, таким образом, позволяет проектировать права доступа, необходимые для выполнения этих обязанностей на прикладном уровне. Предложен способ более точного определения прав доступа с учетом выравнивания ответственности и RBAC.

Управление доступом на основе хоста (HBAC)

Инициализм HBAC означает «управление доступом на основе хоста».

• Средство управления доступом к ресурсам