Войти
access-co ntrol list(ACL) по отношению к компьютеру файловой системе - это список разрешений, связанных с объект. ACL определяет, каким пользователям или системным процессам предоставлен доступ к объектам, а также какие операции разрешены для данных объектов. Каждая запись в типичном ACL определяет тему и операцию. Например, если у файлового объекта есть ACL, содержащий (Алиса: чтение, запись; Боб: чтение), это даст Алисе разрешение на чтение и запись файла, а Бобу - только на чтение.
Многие типы операционных систем реализуют ACL или имеют историческую реализацию. Впервые в файловой системе из Multics в 1965 году.
ACL файловой системы - это структура данных (обычно таблица), содержащая записи, определяющие права отдельного пользователя или группы на определенные системные объекты, такие как программы, процессы или файлы. Эти записи известны как записи управления доступом (ACE) в Microsoft Windows NT, OpenVMS, Unix-like и macOS. операционные системы. Каждый доступный объект содержит идентификатор своего ACL. Привилегии или разрешения определяют конкретные права доступа, например, может ли пользователь читать, записывать или выполнять объект. В некоторых реализациях ACE может контролировать, может ли пользователь или группа пользователей изменять ACL для объекта.
PRIMOS содержал ACL по крайней мере еще в 1984 году.
В 1990-х годах модели ACL и RBAC были тщательно протестированы и использовались для управления правами доступа к файлам.
POSIX 1003.1e / 1003.2c Рабочая группа предприняла попытку стандартизировать ACL, в результате чего получилось то, что теперь известно как «POSIX.1e ACL» или просто «POSIX ACL». Черновики POSIX.1e / POSIX.2c были отозваны в 1997 году из-за того, что участники потеряли интерес к финансированию проекта и обратились к более мощным альтернативам, таким как NFSv4 ACL. По состоянию на декабрь 2019 г. в Интернете не было живых источников проекта, но его все еще можно было найти в Интернет-архиве.
в большинстве Unix и Unix-подобных операционных систем (например, Linux с 2.5.46 или с ноября 2002 года, BSD или Solaris ) поддерживают списки ACL POSIX.1e (не обязательно проект 17). ACL обычно хранятся в расширенных атрибутах файла в этих системах.
ACL NFSv4 намного мощнее чернового ACL POSIX. В отличие от проекта ACL POSIX, как часть сетевой файловой системы, ACL NFSv4 определяется фактически опубликованным стандартом.
ACL NFSv4 поддерживаются многими Unix и Unix-подобными операционными системами. Примеры включают AIX, FreeBSD, Mac OS X, начиная с версии 10.4 («Tiger ») или Solaris с файловой системой ZFS, поддерживают списки ACL NFSv4, которые являются частью стандарта NFSv4. Существуют две экспериментальные реализации списков контроля доступа NFSv4 для Linux: списки контроля доступа NFSv4 для файловой системы Ext3 и более поздняя версия Richacls, которая обеспечивает поддержку списков контроля доступа NFSv4 для файловой системы Ext4. Как и POSIX ACL, NFSv4 ACL обычно хранится как расширенные атрибуты в Unix-подобных системах.
ACL NFSv4 организован почти идентично спискам ACL Windows NT, используемым в NTFS. NFSv4.1 ACL - это надмножество как NT ACL, так и чернового ACL POSIX. Samba поддерживает сохранение NT ACL общих файлов SMB разными способами, одним из которых является ACL с кодировкой NFSv4.
Microsoft Active Directory Directory Служба реализует сервер LDAP, который хранит и распространяет информацию о конфигурации пользователей и компьютеров в домене. Active Directory расширяет спецификацию LDAP, добавляя тот же тип механизма списка контроля доступа, который Windows NT использует для файловой системы NTFS. Затем Windows 2000 расширила синтаксис для записей управления доступом, чтобы они могли не только предоставлять или запрещать доступ ко всем объектам LDAP, но также и к отдельным атрибутам в этих объектах.
На некоторых типы проприетарного компьютерного оборудования (в частности, маршрутизаторы и коммутаторы ), список управления доступом содержит правила, которые применяются к номерам портов или IP адреса, доступные на хосте или другом уровне 3, каждый со списком хостов и / или сетей, которым разрешено использовать службу. Хотя дополнительно можно настроить списки управления доступом на основе имен сетевых доменов, это сомнительная идея, поскольку отдельные заголовки TCP, UDP и ICMP делают не содержать доменных имен. Следовательно, устройство, применяющее список управления доступом, должно отдельно преобразовывать имена в числовые адреса. Это представляет собой дополнительную поверхность атаки для злоумышленника, который пытается поставить под угрозу безопасность системы, которую защищает список управления доступом. Как отдельные серверы, так и маршрутизаторы могут иметь сетевые ACL. Списки контроля доступа обычно можно настроить для управления как входящим, так и исходящим трафиком, и в этом контексте они аналогичны брандмауэрам . Как и брандмауэры, ACL могут регулироваться правилами и стандартами безопасности, такими как PCI DSS.
Алгоритмы ACL были перенесены в SQL и в реляционную базу данных. системы. Многие «современные» (2000-е и 2010-е) системы на основе SQL, такие как системы планирования ресурсов предприятия и системы управления контентом, использовали модели ACL в своих модулях администрирования.
Основной альтернативой модели ACL является модель управления доступом на основе ролей (RBAC). «Минимальную модель RBAC», RBACm, можно сравнить с механизмом ACL, ACLg, где в качестве записей в ACL разрешены только группы. Баркли (1997) показал, что RBACm и ACLg эквивалентны.
В современных реализациях SQL ACL также управляют группами и наследованием в иерархии групп. Таким образом, «современные списки контроля доступа» могут выражать все, что выражают RBAC, и являются особенно мощными (по сравнению со «старыми списками контроля доступа») в своей способности выражать политику контроля доступа с точки зрения того, как администраторы рассматривают организации.
Для обмена данными и для «сравнений высокого уровня» данные ACL могут быть преобразованы в XACML.
