Администрирование ИС

ОСНОВНЫЕ ЗАДАЧИ АДМИНИСТРИРОВАНИЯ ИНФОРМАЦИОННЫХ СИСТЕМ

Администрирование – функциональная поддержка управления системным ресурсом и обеспечения его безопасной и бесперебойной работы

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

• управляющая программа, организующая программа, диспетчер, программа управления

• программа или ответственное лицо

• специалист, отвечающий за проектирование, инсталляцию, конфигурирование, контроль, управление и обслуживание комп. сети, системы или СУБД.

Администрирование ИС заключается:

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

2. в управлении доступом (регистрация пользователей, назначение прав и ограничений)

3. в обеспечении доступности, безопасности и масштабируемости системы

К ИС относятся: ОС, сетевые службы и протоколы, СУБД, Web-серверы, обслуживающие системы и т.п.

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

К обязанностям системного администратора обычно относят следующие задачи:

• подключение и настройка аппаратных устройств;

• установка и обновление программного обеспечения;

• запуск и настройка общесистемных сервисов (конфигурирование системы);

• настройка сетевых протоколов;

• обеспечение печати и отправки почты;

• обеспечение файловых серверов, серверов приложений, web и ftp-серверов;

• управление процессами – изменение их приоритета, принудительное завершение;

• управление общесистемными ресурсами, такими, как дисковые разделы и файловые системы;

• распределение ресурсов;

• определение дисковых квот и управление ими;

• регистрация и управление пользователями;

• настройка групповых политик;

• настройка политики безопасности;

• обеспечение безопасности;

• регистрация и анализ всех инцидентов, связанных с нарушение безопасности;

• резервное копирование информационных ресурсов;

• мониторинг системы в поисках любого возможного системного сбоя, узкого места или уязвимости в защите;

• поиск неисправностей;

• анализ производительности и надежности;

• обеспечение защиты от ошибок пользователей

• мониторинг действий пользователей;

• мониторинг электронной почты;

• мониторинг работы в Internet;

• автоматизация рутинных операций администрирования (командные скрипты управления).

Выполнение перечисленных задач требует особого статуса администратора – статуса суперпользователя системы.

Учетная запись администратора обладает всеми привилегиями – правами и полномочиями – в системе. Администратор может не только выполнить важные настройки системы и сконфигурировать системные службы, но и повредить их, например, случайно. Самый важный принцип администрирования – это принцип минимальных полномочий. Учетная запись любого пользователя должна обладать минимальным, но достаточным для выполнения необходимого задания набором прав. Этот же принцип относится и к самому администратору: не рекомендуется выполнять работу, не требующую высокого уровня полномочий, под учетной записью администратора. Для выполнения обычной работы следует использовать учетную запись с более низким статусом.

Управление пользователями включает такие функции:

• Создание учетной записи пользователя;

• Изменение пароля;

• Отключение/включение учетной записи;

• Удаление учетной записи пользователя.

Другая задача администрирования – управление группами. Управление группами включает в себя:

• создание группы;

• добавление пользователей в группу;

• удаление группы.

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

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

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

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

МОДЕЛИ БЕЗОПАСНОСТИ ИНФОРМАЦИОННЫХ СИСТЕМ

Модель систем дискреционного разграничения доступа

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

• -каждый объект системы имеет привязанного к нему субъекта, называемого владельцем. Именно владелец устанавливает права доступа к объекту;

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

Возможны и смешанные варианты построения, когда одновременно в системе присутствуют как владельцы, устанавливающие права доступа к своим объектам, так и суперпользователь, имеющий возможность изменения прав для любого объекта и/или изменения его владельца. Именно такой смешанный вариант реализован в большинстве операционных систем (UNIX или Windows семейства NT).

Дискреционное управление доступом является основной реализацией разграничительной политики доступа к ресурсам при обработке конфиденциальных сведений согласно требованиям к системе защиты информации.

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

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

• субъект может читать объект, только если иерархическая  классификация субъекта не меньше, чем иерархическая классификация объекта, и неиерархические категории субъекта включают в себя все иерархические категории объекта;

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

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

Ролевое разграничение

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

Ролевое разграничение доступа представляет собой развитие политики дискреционного разграничения доступа, при этом права доступа субъектов системы на объекты группируются с учетом специфики их применения, образуя роли.

Такое разграничение доступа является составляющей многих современных компьютерных систем. Как правило, данный подход применяется в системах защиты СУБД, а отдельные элементы реализуются в сетевых операционных системах.

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

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

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

МНОГОПОЛЬЗОВАТЕЛЬСКАЯ МОДЕЛЬ РАЗГРАНИЧЕНИЯ ДОСТУПА В ОС LINUX

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

Первоочередная задача для вычислительных систем любого масштаба - разделять повседневную работу и изменение самой системы. В многопользовательской модели эта задача решается просто: разделяются "обычные" пользователи и администратор(ы).

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

Полномочия администратора обычно не ограничены.

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

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

Учетные записи

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

Система определяет пользователя по его учетной записи, где хранится имя пользователя и другая связанная с ним системная информация. Английский эквивалент термина учетная запись - account, "счет".

Учетная запись (account) - объект системы, при помощи которого Linux ведет учет работы пользователя в системе. Учетные записи могут быть созданы во время установки системы или после установки. Все учетные записи пользователей хранятся в файле /etc/passwd, изменять который может только администратор. Каждая учетная запись состоит из сведений-полей, разделенных символом :

Ниже приведен список сведений учетной записи.

1. Входное имя (login name) - название учетной записи пользователя, которое нужно вводить при регистрации в системе. Входное имя должно быть уникальным.

2. Пароль пользователя

Лишь в некоторых версиях Linux пароль (в хэшированном виде) хранится в этом поле, в большинстве случаев это лишь ссылка на файл /etc/shadow, в котором и хранятся хэшированные пароли. Первые два символа хэшированного пароля являются “затравкой” (salt) – числом, используемым для инициализации алгоритма шифрования. При каждой смене пароля затравка выбирается случайным образом

3. Идентификатор пользователя uid

Linux связывает входное имя c идентификатором пользователя в системе - UID (User ID). UID - это положительное целое число, по которому система и отслеживает пользователей. Обычно это число выбирается автоматически при регистрации учетной записи, однако оно не может быть произвольным. В -Идентификатор пользователя, UID - уникальное число, однозначно идентифицирующее учетную запись пользователя в Linux. Таким числом также снабжены все процессы Linux и все объекты файловой системы. Используется для персонального учета действий пользователя и определения прав доступа к другим объектам системы.

4. Идентификатор группы gid

Кроме идентификационного номера пользователя, с учетной записью связан идентификатор группы. Группы пользователей применяются для организации доступа нескольких пользователей к некоторым ресурсам. У группы, так же, как и у пользователя, есть имя и идентификационный номер - GID (Group ID). В Linux пользователь должен принадлежать как минимум к одной группе - группе по умолчанию. -Пользователь может входить более чем в одну группу, но в учетной записи указывается только номер группы по умолчанию. Данные о группах хранятся в файле /etc/group.

5. Полное имя

Помимо входного имени (login) в учетной записи содержится и полное имя (имя и фамилия) использующего данную учетную запись пользователя. Эта информация носит справочный характер.

6. Домашний каталог

Файлы всех пользователей в Linux хранятся раздельно, для каждого пользователя определен собственный домашний каталог, в котором он хранит свои данные. Доступ других пользователей к домашнему каталогу пользователя может быть ограничен. –

7. Командная оболочка

Каждому пользователю нужно предоставить способ взаимодействия с системой: передача ей команд и получение от нее ответов. Для этой цели служит специальная программа - командная оболочка (или интерпретатор командной строки) shell, bash. Она должна быть запущена для каждого пользователя, который зарегистрировался в системе Обязательными для заполнения являются поля UID, GID, home directory.

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

• Изменение корневого каталога (команда chroot)

• Установка системных часов

• Создание файлов устройств

• Увеличение лимитов использования ресурсов

• Повышение приоритетов процессов

• Задание сетевого имени системы

• Конфигурирование сетевых интерфейсов

• Останов системы

РОЛЕВОЕ УПРАВЛЕНИЕ ДОСТУПОМ

Очень часто администратору приходится назначать одни и те же разрешения нескольким пользователям БД. Для упрощения этой задачи администратор может создать в БД специальный объект-контейнер, называемый ролью (role). Роль – это аналог групп пользователей, объединенных общим набором привилегий. Роль – это групповой набор учетных записей пользователей, наделенных одинаковыми правами. При создании роли назначаются разрешения на объекты БД, а затем в роль включаются пользователи. Кроме того, в каждой БД предопределен фиксированный набор ролей, права которых нельзя изменять. Еще один фиксированный набор ролей определен на уровне SQL Server - серверные роли.

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

MS SQL Server имеет предопределенный набор серверных ролей:

Полное имя	Имя	Описание
Bulk Insert Administrators (Администраторы сплошной вставки данных)	bulkadmin	Может выполнять операции вставки типа "bulk insert" (групповая или потоковая вставка) - только профессиональный администратор
Database Creators (Создатели баз данных)	dbcreator	Может создавать, изменять или удалять базы данных – одна из основных ролей (только профессиональный администратор)
Disk Administrators (Администраторы диска)	diskadmin	Может управлять файлами диска (команды типа ALTER DATABASE – изменение начального размера БД, квот приращений)
Process Administrators (Администраторы процесса)	processadmin	Может управлять процессами, запущенными в SQL Server, основная задача членов этой роли – уничтожение процессов, заблокировавших ресурсы БД
Security Administrators (Администраторы безопасности)	securityadmin	Может управлять учетными записями и разрешениями CREATE DATABASE, а также просматривать (читать) журнал ошибок (только профессиональный администратор) – одна из основных ролей
Server Administrators (Администраторы сервера)	serveradmin	Может управлять конфигурированием всего сервера и выключать его (только профессиональный администратор)
Setup Administrators (Администраторы настройки)	setupadmin	Может управлять связанными серверами: создавать их, удалять и конфигурировать; может назначать хранимые процедуры, автоматически выполняемые при запуске SQL Server
System Administrators (Системные администраторы)	sysadmin	Может выполнять любые действия в SQL Server –самая важная серверная роль (только профессиональный администратор)

При подключении к SQL Server рекомендуется использовать ту учетную запись, которая предоставляет необходимый минимум полномочий для выполнения текущей работы, а учетную запись sa и роль sysadmin использовать только тогда, когда действительно необходимо выполнить административные функции.

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

MS SQL Server также предоставляет администратору возможность создавать новые роли БД. Наиболее простой и удобный способ создания новой роли предоставляет консольная служба Enterprise Manager . Или более сложный – при помощи хранимой процедуры sp_addrole.

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

Таким образом, роли упрощают администрирование – для большой группы равноправных пользователей удобнее сначала создать роль с соответствующим набором привилегий, затем создать учетные записи (с правами на уровне public – только доступ) и добавить их в роль. Все права роли автоматически передадутся учетным записям. Причем одна и та же учетная запись может обладать разным набором привилегий (согласно роли) для разных БД.

РОЛИ ПРИЛОЖЕНИЙ – application roles

MS SQL Server поддерживает возможность создания ролей для приложений. Особенность роли приложения заключается в том, что она не содержит пользователей баз данных. Назнваченные ей разрещения получает приложение, которое запросит доступ к SQL Server, указав имя роли и заданный для этой роли пароль. Преимущество ролей приложений перед обычными ролями пользователей заключается в том, что с их помощью администратор регулирует доступ к БД определенным пользователям в рамках конкретных приложений. В этом случае пользователи не смогут подключиться к серверу, например, посредством Query Analyzer (редактор и средство выполнения запросов) и выполнять SQL-команды. Разрешения роли приложения более приоритетны, чем разрешения пользователя БД.

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

Создать роль приложения так же просто, как и роль пользователя – при помощи Enterprise Manager (или хранимая процедура sp_addapprole).

НЕЯВНЫЕ СРЕДСТВА УСИЛЕНИЯ ЗАЩИТЫ БД

Чтобы максимально обезопасить данные от нежелательных изменений, можно применить технологию представлений (VIEWS – фактически хранимый запрос), ограничивающую не только доступ пользователя к конкретным таблицам БД, но и набор доступных для него столбцов и строк данных. Идея проста: если пользователю не требуется доступ к некоторым таблицам или столбцам таблицы БД, нужно создать представление (хранимый запрос), в котором исключить определенные таблицы или столбцы, а также наборы данных за счет логического условия. Затем пользователю предоставляются права на созданное представление, а не таблицы БД.

8