Администрирование_в_информационных_системах_Беленькая_М_Н_

Еще один вид статистики, который надо собирать — это статистика по отдельным отношениям БД и по соответствующим индексным файлам. Например, какой объем памяти занят под индексы, под области переполнения, непосредственно под отношение, под рабочую область СУБД (например, процент занятости рабочей области — файла work для СУБД ADABAS).

6.4. Средства защиты от несанкционированного доступа

Еще одна задача администратора базы данных — это защита от несанкционированного доступа. Под этим подразумевается обеспечение защищенности базы данных от любых предумышленных и непредумышленных угроз с помощью различных средств.

Защита БД администратором должна охватывать программное обеспечение, персонал, используемое оборудование, сами данные. Обычно проблемы защиты БД рассматриваются администратором с точки зрения таких потенциальных опасностей [1], как:

—похищение и фальсификация данных;

—утрата целостности;

—потеря доступности;

—утрата конфиденциальности.

Службы администратора должны обеспечить минимизацию потерь от уже происшедших событий и предусмотреть возможные угрожающие ситуации. Более подробно вопросы различных угроз рассматриваются в главе 10. Администратор системы обязательно должен пользоваться всеми необходимыми средствами защиты операционных систем [2] и СУБД [1]. Прежде всего к ним относятся так называемые меры «3А» или «ААА», что означает: Авторизация пользователей, Аутентификация пользователей, Аудит пользователей. Для обеспечения этих мер защиты в ОС и в СУБД всегда существуют специальные средства, которые входят в состав ядра ОС или СУБД, либо представляют собой отдельные утилиты.

Авторизация пользователей (Authorization) — это присвоение администратором имен (идентификаторов) и прав поль-

зователям системы, что позволяет владельцу идентификатора иметь санкционированный доступ к системе или ее объектам. Каждому пользователю в системе должен быть присвоен уникальный идентификатор, например, пользователь SYSLOAD или пользователь MAINT. C точки зрения администратора системы, пользователь SYSLOAD будет заниматься массовыми загрузками данных в БД. Пользователь MAINT будет устанавливать различные продукты в системе. Администратор системы присвоит им различные права доступа к ресурсам системы: первому — права на запись и чтение определенных областей базы данных, второму — права на запись, чтение и удаление из системных областей, где хранится математическое обеспечение СУБД. При этом в системе не должно быть единственного пользователя с правами администратора. Их должно быть минимум два с идентичными правами администратора СУБД и ОС, например Admin и Supervisor. Это делается для того, чтобы сохранить доступ к системе при возможном разрушении системной области СУБД или ОС, где хранится информация о пользователях в системе. Такое дублирование не дает полной гарантии от потери администратора в системе, но уменьшает ее вероятность.

Аутентификация пользователей — это механизм определения того, является ли пользователь тем, за кого себя выдает [1].

Когда каждому пользователю в системе администратором присваивается идентификатор, ему же присваивается и уникальный пароль. При вхождении пользователя в систему он указывает свой пароль, а ОС и СУБД выполняют процесс проверки (аутентификации) соответствия указанных пароля

иидентификатора пользователя. Для обычных пользователей системы ОС и СУБД помогают создать пароли. В состав ОС

иСУБД входят генераторы паролей. АС может применять их для задания паролей пользователей, хотя пользователь может

исам изобрести свой пароль. Но для администраторов систем из-за невозможности запоминания большого числа сгенерированных паролей для различных подсистем ИС и во избежание утраты пароля ответственный администратор системы должен иметь несколько своих комбинаций паролей и сам задавать их всем администраторам систем. Пароли должны быть зашифрованы средствами ИС, например с помощью стандарта DES — стандарт с 56-битным симметричным ключом шифро-

вания, впервые предложенный компанией IBM. Пароли должны периодически меняться.

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

Помимо двух администраторов, которые обладают всеми правами доступа ко всем областям системы и всеми привилегиями, в системе должны быть администраторы с разными правами доступа и привилегиями. Например, пользовательадминистратор Maint (Sysmaint, Dirmaint) имеет права создавать, удалять и архивировать множество БД и соответствующие журналы транзакций, но не имеет привилегии давать права другим пользователям. А пользователь-администратор Load имеет права на чтение/запись/создание определенных областей БД для массовых загрузок информации и создания индексов данных. Массовые загрузки являются отдельной операцией, так как при вводе информации данные индексируются и сортируются ядром СУБД согласно алгоритмам методов доступа. Операция сортировки требует значительных ресурсов памяти и обычно выделяется АБД в отдельный процесс, а СУБД обычно имеет отдельную утилиту, осуществляющую эти действия [17].

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

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

6.5.Способы восстановления

èреорганизации

6.5.1.Способы реорганизации БД

Реорганизация БД — это изменение логической, концептуальной или физической схемы базы данных [1, 11].

Реорганизация происходит при следующих событиях:

—изменение связей между объектами;

—добавление новых типов данных;

—изменение законодательных актов, требующих, например, расщепления записей для хранения в защищенной области;

—создание новой БД на основе уже имеющихся БД, например при слиянии компаний и необходимости объединить БД, поддерживаемые различными СУБД;

—увеличение объема данных, что вызывает необходимость переноса данных на другие физические носители или системы ввода-вывода;

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

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

Реорганизация на месте. Все запросы пользователей блокируются на время проведения реорганизации. После ее завершения пользователям вновь разрешается доступ к БД. Это достаточно опасная стратегия, так как существует вероятность потерять данные. Кроме того, эта стратегия мо-

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

Реорганизация путем выгрузки и загрузки. Работа пользователей останавливается, ядро СУБД работает в автономном режиме. Данные выгружаются, реорганизуются и вновь загружаются. Эта стратегия надежна с точки зрения опасности потерь данных. Недостаток — требуется много ресурсов и времени для реализации.

Реорганизация приращениями. Эта стратегия не предусматривает остановки работы пользователей (запуск ядра СУБД в автономном режиме), а выполняется по мере ссылок на элемент данных. При этом необходимая реорганизация протекает приращениями, когда пользователь ссылается на какую-нибудь единицу данных в БД. Такая реорганизация обычно производится ядром СУБД в процессе работы.

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

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

6.5.2. Восстановление БД

Восстановление БД — это процесс возвращения БД в состояние, утраченное в результате сбоя или отказа [1]. Существует множество различных сбоев и отказов, способных повлиять на функционирование БД. Каждый из них может привести к потерям данных или их целостности. Соответственно для

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

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

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

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

Подчеркнем, что процесс восстановления БД средствами СУБД отличается от процесса восстановления данных средствами операционной системы. При использовании утилит операционной системы системный администратор не разби-

рается с вопросом целостности данных, а копирует/восстанавливает все данные на конкретном носителе, не оценивая, на сколько они непротиворечивы.

С учетом перечисленных причин возникновения отказов выделяют три типа восстановления БД.

Аварийное восстановление происходит в двух случаях. Во-первых, если что-то произошло со средой хранения

данных (media failor), АБД восстанавливает данные по последней копии на другом носителе (жестком диске), которую он сливает с журналом транзакций.

Во-вторых, если произошел сбой по питанию, либо произошло прерывание работы ядра СУБД, либо прерывание работы операционной системы. В этом случае ядро СУБД производит автооткат транзакций и само обеспечивает восстановление. Но АБД должен учесть, что при совместном прерывании операционной системы и СУБД, обе системы производят автооткат и транзакция СУБД не идентична транзакции операционной системы [49]. В этом случае может быть разрушена целостность БД, и администратору базы данных придется восстанавливать ее с помощью последних копий и журналов транзакций.

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

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

В любом случае процедуры копирования и восстановления БД крайне ответственны и требуют от администратора базы данных продуманного и подготовленного подхода. Все возможные в организации стратегии восстановления [17] и действия должны быть подготовлены АБД заранее, до возникновения ситуации восстановления. При этом профессионалы всегда говорят, что есть три способа восстановления: резервное копирование, резервное копирование и резервное копирование (backup, backup, backup).

Дополнительная информация

1.www.ibm.com

2.www.oracle.com

3.www.sql.ru

4.www.ibmdatabasemag.com

5.www.db2portal.com

Контрольные вопросы

1.Каковы задачи администрирования данных и администрирования БД?

2.Каковы действия по инсталляции СУБД?

3.Зачем АБД задает параметры запуска ядра СУБД?

4.На что влияет коэффициент свободного пространства?

5.Зачем нужен параметр очистки буферного пула

6.Зачем нужен мониторинг СУБД администратору системы?

7.Какую статистику необходимо собирать АБД по БД в целом? По запросам приложений? По отдельным отношениям БД?

8.Что означает аббревиатура ААА в контексте мер защиты от несанкционированного доступа?

9.Каковы стратегии реорганизации БД, применяемые администратором базы данных?

10.Почему перед копированием БД АБД должен производить тестирование множеств БД на целостность?

Глава 7

ПОДКЛЮЧЕНИЕ ИС К УЗЛУ ОПЕРАТОРА СВЯЗИ

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

Операторы связи используют для передачи данных (ПД) специализированные и неспециализированные сети ПД, в частности телефонные сети общего пользования (ТФОП). Несмотря на то что сеть ТФОП предназначена для передачи аналоговых сообщений, с помощью технологий ISDN и xDSL ее линии можно использовать для цифровой передачи данных. Для подключения ИС к узлу связи оператора, предпочтительно использовать выделенные линии, поскольку они обладают необходимыми для передачи данных характеристиками.

Выделенная линия — это линия, выделенная для передачи данных, с широкой полосой пропускания. Не следует путать выделенную линию с частной линией. Частная линия — это линия, выделенная в пользование только конкретному абоненту на определенное время.

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

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

Основным вопросом при подключении ИС к узлу оператора связи является организация связи на участке от ИС до узла связи оператора.

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

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

В данной главе рассматриваются способы подключения ИС к узлу оператора связи (способы организации последней мили) на основе использования: медного кабеля (разд. 7.1) и неограниченных сред (разд. 7.2). Оптоволоконные технологии излагались в главе 3. В разделе 7.3 рассматриваются непосредственно действия администратора системы по подключению ИС к узлу оператора связи.