Часть 2

Безопасность и управление доступом в информационных системах.

1 Наиболее распространённая операционная система для машин ЕС ЭВМ. Первоначально представляла собой доработанный и русифицированный вариант OS/360 и OS/370. Обеспечивала пакетную обработку заданий, для написания которых применялся язык JCL.

2 Закон Российской Федерации от 27 июля 2006 г. N 149-ФЗ «Об информации, информационных технологиях и о защите информации»

3 ACL (англ. Access Control List — список контроля доступа, по-английски произносится «экл») — определяет, кто или что может получать доступ к конкретному объекту, и какие именно операции разрешено или запрещено этому субъекту проводить над объектом.

Списки контроля доступа являются основой систем с избирательным управлением доступом. В типичных ACL каждая запись определяет субъект воздействия и операцию: например, запись (Vasya, delete) в ACL для файла XYZ даёт возможность пользователю Vasya удалить файл XYZ. В системе с моделью безопасности, основанной на ACL, когда субъект запрашивает выполнение операции над объектом, система сначала проверяет список разрешённых для этого субъекта операций, и только после этого даёт (или не даёт) доступ к запрошенному действию. При централизованном хранении списков контроля доступа можно говорить о матрице доступа, в которой по осям размещены объекты и субъекты, а в ячейках — соответствующие права. Однако в большом количестве систем списки контроля доступа к объектам хранятся отдельно для каждого объекта, зачастую непосредственно с самим объектом. Традиционные ACL системы назначают права индивидуальным пользователям, и со временем и ростом числа пользователей в системе списки доступа могут стать громоздкими. Вариантом решения этой проблемы является назначения прав группам пользователей, а не персонально. Другим вариантом решения этой проблемы является «Управление доступом на основе ролей», где функциональные подмножества прав к ряду объектов объединяются в «роли», и эти роли назначаются пользователям. Однако, в первом варианте группы пользователей также часто называются ролями. Файловые системы с ACLВ файловых системах для реализации ACL используется идентификатор пользователя процесса (UID в терминах POSIX).

Список доступа представляет собой структуру данных (обычно таблицу), содержащую записи, определяющие права индивидуального пользователя или группы на специальные системные объекты, такие как программы, процессы или файлы. Эти записи также известны как ACE (англ. Access Control Entries) в операционных системах Microsoft Windows и OpenVMS. В операционной системе Linux и Mac OS X большинство файловых систем имеют расширенные атрибуты, выполняющие роль ACL. Каждый объект в системе содержит указатель на свой ACL. Привилегии (или полномочия) определяют специальные права доступа, разрешающие пользователю читать из (англ. read), писать в (англ. write), или исполнять (англ. execute) объект. В некоторых реализациях ACE могут определять право пользователя или группы на изменение ACL объекта. Концепции ACL в разных операционных системах различаются, несмотря на существующий «стандарт» POSIX. (Проекты безопасности POSIX, .1e и .2c, были отозваны, когда стало ясно что они затрагивают слишком обширную область и работа не может быть завершена, но хорошо проработанные части, определяющие ACL, были широко реализованы и известны как «POSIX ACLs».) Сетевые ACLВ сетях ACL представляют список правил, определяющих порты служб или имена доменов, доступных на узле или другом устройстве третьего уровня OSI, каждый со списком узлов и/или сетей, которым разрешен доступ к сервису. Сетевые ACL могут быть настроены как на обычном сервере, так и на маршрутизаторе и могут управлять как входящим, так и исходящим трафиком, в качестве межсетевого экрана

4 Реляционная база данных — база данных, основанная на реляционной модели. Слово «реляционный» происходит от англ. relation (отношение). Для работы с реляционными БД применяют Реляционные СУБД. Использование реляционных баз данных было предложено доктором Коддом из компании IBM в 1970 году. Эти модели характеризуются простотой структуры данных, удобным для пользователя табличным представлением и возможностью использования формального аппарата алгебры отношений и реляционного исчисления для обработки данных.

Реляционная модель ориентирована на организацию данных в виде двумерных таблиц. Каждая реляционная таблица представляет собой двумерный массив и обладает следующими свойствами: каждый элемент таблицы — один элемент данных

все ячейки в столбце таблицы однородные, то есть все элементы в столбце имеют одинаковый тип (числовой, символьный и т. д.) каждый столбец имеет уникальное имя одинаковые строки в таблице отсутствуют порядок следования строк и столбцов может быть произвольным Базовыми понятиями реляционных СУБД являются: атрибут, отношение, кортеж.

5 UID - В Unix-подобных операционных системах, пользователи идентифицируются идентификаторами пользователя (англ. User identifier, UID).

То, что пользователя идентифицирует UID, значит, что операционная система различает пользователей именно по UID (а не например, по логину). Во многих системах существует возможность создать две записи пользователя с разными логинами, но одинаковыми UID; в результате оба логина будут иметь одинаковые права, так как с точки зрения системы они неотличимы (так как имеют одинаковый UID). Это может использоваться злоумышленниками: проникнув в систему и получив права root, взломщик может создать себе аккаунт с UID=0, чтобы потом возвращаться в систему под логином, не привлекающим внимания, но получать права root.

Множество допустимых значений UID зависит от системы; в общем случае UID допускает использование значений от 0 до 65535 с некоторыми оговорками:

Суперпользователь всегда должен иметь UID, равный нулю (0).

Пользователю nobody обычно присваивается или наибольший из возможных UID (в противоположность cуперпользователю), или один из системных UID (см. ниже).

UIDы с 1 по 100 по соглашению резервируются под системные нужды; некоторые руководства рекомендуют резервировать UIDы со 101 по 499 (в Red Hat) или даже 999 (в Debian).

Значение UID ставится в соответствие пользователю в файле /etc/passwd. Файлы теневого пароля и Network Information Service также используют числовые UIDы. Идентификатор пользователя-владельца является необходимым атрибутом файла файловых систем Unix и процессов.

Некоторые операционные системы могут поддерживать 16-битные UIDы, что делает возможным создание 65536 уникальных идентификаторов, хотя современные системы с поддержкой 32-битных UIDов может иметь 4,294,967,296 (232) различных значений идентификаторов.

6 root (от англ. root — корень; читается «рут»), или су́перпо́льзователь — это специальный аккаунт в UNIX-подобных системах с идентификатором (UID, User IDentifier) 0, владелец которого имеет право на выполнение всех без исключения операций.

Cуперпользователь UNIX-систем имеет логин «root» только по умолчанию, и легко переименовывается при необходимости.

Такая схема была придумана для облегчения администрирования. К примеру, на серверах Novell начинающие администраторы нередко допускают ошибку, «даруя независимость» ветви каталогов (теряя над ними всякий контроль); в UNIX подобное невозможно.

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