Администратор базы данных. Администрирование базы данных
 Скачать 52.49 Kb.
|
|
Министерство образования и науки Чеченской Республики Государственное бюджетное профессиональное образовательное учреждение «Гудермесский железнодорожный техникум» 09.02.05 Прикладная информатика (по отраслям) КУРСОВОЙ ПРОЕКТ по дисциплине «Базы данных и знаний» на тему: «Администрирование базы данных»  Выполнил(а): студент(ка) гр. 2П-15 Хамзатов Лом-Али Жимхажиевич Руководитель: преподаватель спец. дисциплин Ганчаев Мансур Салаудинович. Допущен к защите: «___»______________ 20___ г. Подпись __________ Защищен с оценкой __________ «___»____________ 20___ г. Подпись ________ Гудермес 2018 Содержание Введение 3 1. Администратор базы данных основные понятия 51.1 Понятие, классификация и функции администратора базы данных 5 2. Администрирование базы данных 102.1 Управление данными в базах данных 10 2.2 Управление безопасностью в СУБД 14 2.3 Защита коммуникаций между пользователем и сервером 23 Заключение 25 Список использованных источников 26 Введение Современные базы данных – это сложные многофункциональные программные системы, работающие в открытой распределенной среде. Они уже сегодня доступны для использования в деловой сфере и выступают не просто в качестве технических и научных решений, но как завершенные продукты, предоставляющие разработчикам мощные средства управления данными богатый инструментарий для создания прикладных программ и систем. А также Администрирование базами данных предусматривает выполнение функций, направленных на обеспечение надежного и эффективного работоспособности системы баз данных, адекватности содержания базы данных информационным потребностям пользователей, отображения в базе данных актуального состояния предметной области. А также Необходимость персонала, обеспечивающего администрирование данными в системе БД в процессе функционирования, является следствием централизованного характера управления данными в таких системах, постоянно требующего поиска компромисса между противоречивыми требованиями к системе в социальной пользовательской среде. Хотя такая необходимость и признавалась на ранних стадиях развития технологии баз данных, четкое понимание и структуризация функций персонала, занятого администрированием, сложилось только вместе с признанием многоуровневой архитектуры СУБД. Администрирование базы данных заключается в возможности дать исчерпывающие ответы на поставленные вопросы: что представляет собой администрирование базы данных, в чем заключаются его основные функции и задачи, его значение для стабильной и эффективной работы базы данных. Актуальность темы Администрирование базы данных несомненна, можно провести аналогию между администратором баз данных и проверяющим предприятия. Проверяющий защищает ресурсы предприятия, а администратор – ресурсы, которые называются данными. Нельзя рассматривать администратора баз данных только как квалифицированного технического специалиста, так как это не соответствует целям администрирования. Уровень администратора баз данных в идеале организации достаточно высок: чтобы определять структуру данных и право доступа к ним, администратор должен знать, как работает предприятие, и какие используются соответствующие данные. А также стоит отметить, о проблеме администрирования баз данных, внимание стали уделять сравнительно недавно с появлением и развитием современных баз данных. Однако в связи с этим, что совершенствование баз данных и систем управления данными – это явление постоянное и непрерывное, проблема остается достаточно актуальной, следовательно, требует дополнительных исследований и разработки в данной области компьютерных технологий. Цель курсового проекта заключается в изучении администрирования базы данных. Задачи курсового проекта формируются исходя из его цели, заключаются в следующем: 1) Рассмотреть понятие, классификацию и функции администратора базы данных. 2) Рассмотреть обязанности, связи и средства администратора современных систем управления базами данных. 3) Изучить основные направления и принципы администрирования базы данных. Данное исследование проведено с использованием теоретических положений, раскрывающих основные технические характеристики и элементы исследуемого явления. Практическая значимость исследования заключается в его возможном использовании при изучении информационных технологий в высших учебных заведениях. 1. Администратор базы данных основные понятия1.1 Понятие, классификация и функции администратора базы данных Работоспособность базы данных (БД) невозможно без участия ведущих специалистов, разрабатывающих проекты базы данных, работоспособность и развитие базы данных. Такой класс специалистов называется администратором базы данных (АБД). Эта группа специалистов считается основной частью при разработке и управления баз данных. В зависимости от сложности и объема банка данных, от особенностей используемой системы управления базы данных (СУБД), служба администрации базы данных может различаться как по составу и квалификации специалистов, так и по количеству работающих в этой службе. В составе администрации базы данных должны быть системные аналитики, проектировщики структур данных и внешнего по отношению к банку данных информационного обеспечения, проектировщики технологических процессов обработки данных, системные и прикладные программисты, операторы, специалисты по техническому обслуживанию. Если речь идет о коммерческом банке данных, то важную роль здесь будут играть специалисты по маркетингу. А также администраторы базы данных выполняют большой круг разнообразных функций: 1) Анализ предметной области: описание предметной области, выявление ограничений целостности программы и баз данных, определение статуса информации, определение потребностей ресурсов пользователей, определение статуса пользователей, определение соответствия (данных/пользователя), определение объемно-временных характеристик обработки данных. 2) Проектирование структуры базы данных: определение состава и структуры информационных единиц, составляющих базу данных, задание связей между ними, выбор методов упорядочения данных и методов доступа к информации, описание структуры БД на языке обработки данных (ЯОД). 3) Задание ограничений целостности при описании структуры базы данных и процедур обработки БД: задание ограничений целостности присущих предметной области, определение ограничений целостности, вызванных структурой базы данных, разработка процедур обеспечения целостности БД при вводе и обработке данных, обеспечение ограничений целостности банка данных при параллельной работе пользователей в многопользовательском режиме. 4) Первоначальная загрузка и ведение базы данных: разработка технологии первоначальной загрузки и ведения (изменения, добавления, удаления записей) БД, проектирование форм ввода, создание программных модулей, подготовка исходных данных, ввод и контроль ввода. 5) Защита данных от несанкционированного доступа: – обеспечение парольного входа в систему: регистрация пользователей, назначение и изменение паролей – обеспечение защиты конкретных данных: определение прав доступа групп пользователей и отдельных пользователей, определение допустимых операций над данными для отдельных пользователей, выбор/создание программно-технологических средств защиты данных; шифрование информации с целью защиты данных от несанкционированного использования; – тестирование средств защиты данных; – фиксация попыток несанкционированного доступа к информации; – исследование возникающих случаев нарушения целостности защиты данных и проведение мероприятий по их предотвращению. 6) Защита данных от разрушений. Считается одним наилучшим из способов защиты от потери данных, является резервирование. Используется как при физической порче файла, так и в случае, если в БД внесены нежелательные необратимые изменения. 7) Обеспечение восстановления БД: разработка программно-технологических средств восстановления БД, организация ведения системных журналов. 8) Анализ обращений пользователей к БД: сбор статистики обращений пользователей к базе данных, и ее хранение, и анализ (который из пользователей, к какой информации, как часто обращался, какие выполнял операции, время выполнения запросов, анализ причин безуспешных действий обработки (в т.ч. и аварийных) обращений к БД. 9) Анализ эффективности функционирования базы данных и развитие системы: анализ показателей функционирования системы (время обработки, объем памяти, стоимостные показатели), реорганизация и реструктуризация баз данных, изменение состава баз данных, развитие программных и технических средств. 10) Работа с пользователями: сбор информации об изменениях в предметной области, об оценке пользователями работы базы данных, определение регламента работы пользователей с базой данных, обучение и консультирование пользователей. 11) Подготовка и поддержание системных программных средств: сбор и анализ информации о СУБД и других прикладных программ, приобретение программных средств, их установка, проверка работоспособности, поддержание системных библиотек, развитие программных средств. 12) Организационно-методическая работа: это выбор или создание методики проектирования БД, определение целей и направлений развития системы, планирование этапов развития базы данных, разработка и выпуск организационно-методических материалов. Характеристики некоторых типов АБД и занимаемых ими положений: Оперативные (operational) АБД: манипулируют дисковым пространством наблюдают за текущей производительностью системы реагируют на возникающие неисправности БД, обновляют системное ПО и ПО базы данных контролируют структурные изменения БД запускают процедуры резервного копирования данных, выполняют восстановление данных, создают и управляют тестовыми конфигурациями БД. Тактические (tactical) АБД: Реализуют в проект схемы размещения информации, утверждают процедуры резервного копирования и восстановления данных; разрабатывают и внедряют структурные элементы БД: таблицы, столбцы, размеры объектов, индексацию и таким образом делают сценарии (scripts) изменения схемы БД; конфигурационные параметры БД утверждают план действий в случае аварийной ситуации. Стратегические (strategic) АБД: выбирают поставщика БД, устанавливают корпоративные стандарты данных, внедряют методы обмена данных, в рамках предприятия определяют корпоративную стратегию резервирования, и восстановления данных устанавливают корпоративный подход к ликвидации последствий аварии и обеспечению доступности данных. Старшие (senior) АБД: досконально знают свою работу, могут написать любой скрипт, а также могут заменить любого из администраторов АБД. Младшие (junior) АБД: не слишком сильны в написании скриптов имеют большую склонность к использованию средств управления БД. Прикладные (application) АБД: в курсе информационных нужд компании помогают в разработке прикладных задач, отвечают за разработку схемы и ее изменения, вместе с системным АБД, обеспечивают должный уровень резервирования, восстановления данных, занимаются построением тестовых БД. Системные (system) АБД: отвечают за все необходимое для резервирования и восстановления данных, контролируют производительность системы, в целом осуществляют поиск и устранение неисправностей в курсе нынешних и будущих потребностей БД в плане емкости в курсе текущего состояния и нужд БД. Наемные (contract) АБД приглашаются под конкретную задачу или в качестве консультантов передают персоналу необходимые знания, фиксируют свои действия, должны прекрасно разбираться в соответствующей области, хороши в качестве временного персонала, для оценки проекта или системы. Администраторы-руководители: проводят еженедельные совещания, определяют перечень первоочередных задач, устанавливают и оглашают официальный курс и стратегию утверждают и дополняют должностные инструкции, и список обязанностей следят за наличием соответствующей документации. Обязанности, связи и средства администратора современных систем управления базами данных. Поскольку система баз данных может быть весьма большой и может иметь много пользователей, должно существовать лицо или группа лиц, управляющих этой системой. Такое лицо называется администратором базы данных (АБД). Базы данных часто создаются специализированными проектными коллективами на основе договора на разработку информационной системы в целом или базой данных как самостоятельного объекта проектирования. В этом случае служба администрации базы данных должна создаваться как в организации-разработчике, так и в организации-заказчике. На эффективность работы базы данных оказывают влияние множество внешних и внутренних факторов. Возрастание сложности и масштабов базы данных, высокая «цена» неправильных или запоздалых решений по администрированию БД, высокие требования к квалификации специалистов делают актуальной задачу использования развитых средствах автоматизированного (или даже автоматического) администрирования базы данных. Средства администрирования включены в состав всех СУБД. Особенно развиты эти средства в корпоративных СУБД. 2. Администрирование базы данных2.1 Управление данными в базах данных Управляет БД администратор (АБД). Следует отметить, что при рассмотрении всего контура управления БД на физическом уровне, не касаясь характера процессов, протекающих в технических устройствах при обеспечении управления БД, следует учитывать и операционную систему (ОС) ЭВМ, поскольку программы управления БД выполняются непосредственно под управлением ОС и во многих случаях наравне с другими программами, (например, программы решения инженерных расчетных задач) во многопрограммном режиме. СУБД представляет собой специальный пакет программ, с помощью которого, как уже было отмечено, реализуется централизованное управление БД и обеспечивается доступ к данным. В каждой СУБД прежде всего имеются компиляторы (трансляторы) либо интерпретаторы с языка описания данных (ЯОД) и языка манипулирования данными (ЯМД). При создании интегрированных БнД содержащих несколько разнотипных СУБД каждая из которых используется в отдельном локальном БнД и характеризуется наличием своего ЯОД и ЯМД, разрабатывают единые для всего интегрированного банка ЯОД и ЯМД, обеспечивающие работу с данными. И кстати Любого локального банка, входящего в состав интегрированного. ЯОД представляет собой язык высокого уровня, предназначенный для описания схемы БД или ее части. С его помощью выполняется описание типов данных, подлежащих хранению либо выборке из базы, их структур и связей между собой. ЯОД не является процедурным языком. Исходные тексты (описание данных), написанные на этом языке, после трансляции отображаются в управляющие таблицы адресов памяти. В соответствии с полученным описанием СУБД находит в базе требуемые данные преобразует и передает их, например, в прикладную программу (ПП), которой они потребовались, либо определяет место в памяти ЭВМ, куда их требуется поместить, и в каком виде, а также с какими данными установить, связь и какие имеющиеся данные требуется скорректировать. Кстати надо отметить, что в зависимости от алгоритма работы конкретной СУБД возможны различные варианты обработки исходных текстов описаний данных, составленных на ЯОД. В одних случаях описания всегда транслируются вначале, а затем, если нет синтаксических ошибок, выполняется дальнейшая обработка запроса, в котором они присутствовали. В других случаях возможна предварительная трансляция описаний для их отладки и выявления ошибок. После этого обычно с помощью средств используемой ОС готовые отлаженные описания (каждое со своим идентификатором) помещаются в специальную библиотеку, откуда СУБД их выбирает по идентификатору при обработке соответствующих запросов (идентификатор требуемого описания поступает в запросе). Кроме того, может использоваться режим интерпретации описаний при обработке запросов и журнализации. Журнализация – это одно из основных требований к СУБД – надежное хранение данных во внешней памяти. Под надежностью хранения понимается то, что СУБД должна быть в состоянии восстановить последнее согласованное состояние БД после любого аппаратного или программного сбоя. Обычно рассматриваются два возможных вида аппаратных сбоев: так называемые мягкие сбои, которые можно трактовать как внезапную остановку работы компьютера (например, аварийное выключение питания), и жесткие сбои, характеризуемые потерей информации на носителях внешней памяти, так называемые жесткие диски (HDD). Примерами программных сбоев могут быть аварийное завершение работы СУБД (из-за ошибки в программе или некоторого аппаратного сбоя) или аварийное завершение пользовательской программы, в результате чего некоторая обработка данных остается незавершенной. Первую ситуацию можно рассматривать как особый вид мягкого аппаратного сбоя; при возникновении последней требуется ликвидировать последствия только одной обработки данных. Но в любом случае для восстановления БД нужно располагать некоторой дополнительной информацией. Другими словами, поддержание надежного хранения данных в БД требует избыточности хранения данных, причем та их часть, которая используется для восстановления, должна храниться особо надежно. Наиболее распространенный метод поддержания такой избыточной информации – ведение журнала изменений БД. Журнал – это так называемая особенная часть БД, недоступная для пользователя СУБД и поддерживаемая особо тщательно базой защиты (кстати можно поддерживать две копии журнала, располагаемые на разных физических дисках), в первую копию которую поступают записи обо всех изменениях основной части БД. А также во многих СУБД изменения баз данных журнализируются на разных уровнях: иногда запись в журнале имеет соответствие многих логических операции изменения БД (например, операции удаления строки из таблицы реляционной базы данных), а в некоторых случаях запись соответствует минимальной внутренней операции модификации страницы внешней памяти. В большинстве личных системах баз одновременно используются оба подхода. А также во всех случаях и при любых обстоятельствах придерживаются стратегии «предупреждающие» записи в журнале (так бы называемого протокола Write Ahead Log – WAL). Говоря своими словами, эта стратегия заключается в том, что запись об изменении любого объекта базы данных должна попасть во внешнюю память журнала раньше, чем измененный объект попадет во внешнюю память основной части базы данных. Так, как нам известно, что если в СУБД правильно соблюдается протокол WAL, то при помощи журнала можно решить даже очень сложные проблемы восстановления баз данных даже после глобального сбоя. Кстати самая простая операция восстановления — это провести индивидуальный откат изменений в базе данных. Проще говоря, для этого даже не понадобится общесистемный журнал изменений БД, для этого достаточно просто для каждой обработки данных поддерживать локальный журнал изменения операций базы данных, выполненных в этой транзакции, и производить откат транзакции, выполнением обратных данных операций, следуя от конца локального журнала. А в определенных СУБД так и делают, но хочу подметить, что в большинстве систем локальные журналы не поддерживают, а индивидуальный откат транзакции выполняют по общесистемному журналу, для того все записи от одной транзакции и связывают обратным списком (от конца к началу). А также при произошедшим мягком сбое во внешней памяти основной части БД, могут находиться объекты измененные транзакции не закончившимися к моменту сбоя системы базы и могут отсутствовать объекты, измененные транзакциями, которые к этому моменту сбоя успешно завершились по причине использования буферов оперативной памяти. А содержимое которых при мягком сбое просто пропадает. При соблюдении протокола WAL во внешней памяти журнала всегда должны гарантированно находить записи, относящиеся к операциям изменения обоих видов объектов. Для восстановления баз данных после жесткого сбоя используют журналы, а также архивную копию БД. Говоря своими словами, архивная копия баз данных – это полная копия БД к моменту начала работы заполнения журнала (имеется много вариантов более легкого и гибкого объяснения смысла архивной копии). Конечно, для нормальной операции по восстановлению БД после жесткого сбоя необходимо, чтобы журнал не пропал. Как уже пояснялось, к сохранности журнала во внешней памяти в СУБД требуются особо повышенные требования. И так операция по восстановлению БД состоит в том, что, исходя из архивной копии по журналу, воспроизводится работа всех транзакций обработки данных, которые закончились к моменту сбоя. А также в принципе можно даже и воспроизвести работу незавершенных транзакций и продолжить их работу после восстановления базы данных. Однако во многих реальных системах это обычно не делается, поскольку процесс восстановления после жесткого сбоя является достаточно длительным. 2.2 Управление безопасностью в СУБД Системы управления базами данных стали основным инструментом, обеспечивающим хранение больших массивов информации. Современные информационные приложения опираются, как уже говорилось, в первую очередь, на многопользовательские СУБД. В этой связи пристальное внимание в настоящее время уделяется проблемам обеспечения информационной безопасности, которая определяет степень безопасности организации, учреждения в целом. Таким образом, под информационной безопасностью понимают защищенность информации от случайных и преднамеренных воздействий естественного или искусственного характера несанкционированный доступ к данным чреватых нанесением ущерба владельцам или пользователям информации. Также к защите подлежат не только данные в базе, нарушения в защите могут повлиять на другие части системы, к примеру: удаление важных программ вирусами (вредоносные программы), отвечающих за работоспособность базы данных, что повлечет за собой разрушение базы данных. Поэтому защита баз данных охватывает и оборудование, и программное обеспечение, и персонал, и собственно банк данных. Таким образом, защита баз данных предусматривает предотвращение любых преднамеренных и непреднамеренных угроз с использованием компьютерных и некомпьютерных средств контроля. Следует также защищать современные информационные системы; глобальную связанность (выход в Internet); разнородность (различные платформы); технологию «клиент-сервер». Надо отметить, что, разрабатывая систему информационной безопасности, надо помнить, что, только защищая все составные части системы, можно достичь желаемого результата. И так рассмотрим основные программно-технические меры, применение которых позволит решить некоторые из вышеперечисленных проблем. Аутентификация и идентичность; управление доступом; поддержка целостности; протоколирование и аудит; защита коммуникаций между клиентом и сервером; отражение угроз, специфичных для СУБД. Аутентификация и идентичность- это проверка подлинности пользователя приложений базы данных чаще всего осуществляется либо через соответствующие механизмы операционной системы, либо через определенный SQL-оператора, например: пользователь идентифицируется своим именем, а средством аутентификации служит пароль. Авторизация – это предоставление прав (привилегий), позволяющих владельцу иметь законный доступ к объектам базы данных. Аутентификация – это механизм определения, является ли пользователь тем, за кого он себя выдает. Эта процедура позволяет организовать контролируемый доступ к информационной системе (пользователь – идентификатор – пароль). Пароль – это наиболее распространенный метод аутентификации, но он не дает абсолютной гарантии, что пользователь является именно тем, за кого себя выдает. При использовании такого подхода создаются значительные сложности для повторных проверок, и исключает подобные проверки перед каждой транзакцией. Средства аутентификации на основе личных карточек или эквивалентного механизма дали бы приложению большую свободу в реализации контроля подлинностью пользователей. Управление доступом после получения права доступа к СУБД пользователь автоматически получает привилегии, связанные с его идентификатором. Это может относиться к процедурам доступа к объектам базы данных, к операциям над данными. Для основных объектов базы данных могут быть построены таблицы, в которых указывается набор действий, доступных каждому пользователю системы. И каждому возможному действию над данными таблицы ставится в соответствие двоичное значения, общий результат возможных операций получается путем суммирования набранных пользователем значений. Привилегии в СУБД могут быть разделены на две категории: привилегии безопасности и привилегии доступа. Привилегии безопасности позволяют выполнять административные действия, привилегии доступа определяют права доступа субъектов к определенным объектам. До выполнения процедуры присваивания привилегий их необходимо создать. И так привилегии можно подразделить в соответствии с видами объектов, к которым они относятся: таблицы и представления, процедуры, базы данных сервер базы данных. Применительно к таблицам могут быть определены следующие права доступа: право на выборку, удаление, обновление, добавление, право на использование внешних ключей, ссылающихся на данную таблицу. По умолчанию пользователь не имеет никаких прав доступа ни к таблицам, ни к представлениям. По отношению к процедурам можно предоставить право на их выполнение, однако при этом не указываются привилегии на право доступа к объектам, обрабатываемым процедурами. Это позволяет выделять неконтролируемый доступ для выполнения строго определенных операций над данными. По отношению к базе данных выделяемые права на самом деле являются запретительными: ограничение на число операций ввода/вывода строк, число строк, возвращаемым одним запросом. Оператор позволяет реализовать следующие виды ограничений доступа: операционные ограничения (за счет прав доступа операторов выборки, вставки, удаления и обновления, применяемые ко всем или отдельным столбцам таблицы); ограничения по значениям (за счет механизма представлений); ограничения на ресурсы (за счет привилегий к базам данных). СУБД предоставляет специфическое средство управление доступом – представления, которые позволяют делать видимыми только отдельные столбцы базовых таблиц. В результате выполнения запроса к представлению, а не к таблице может быть возвращена таблица из нуля строк, а не код ответа, свидетельствующий о нарушении прав доступа. Это важно, поскольку этот ответ лишает возможности поиска ответа другим путем, например, через анализ кодов, ответов, возвращаемых после обработки SQL-запросов. И так рассмотрим, операцию управление доступом. Этот этап базируется на реализации следующего минимального набора действий: произвольное управление доступом; обеспечение безопасности повторного использования объектов; использование меток безопасности; принудительное управление доступом. А также произвольное управление доступом – это метод ограничения доступа к объектам, основанный на учете личности субъекта или групп, в которую субъект входит. Группа – это именованная совокупность пользователей; объединение субъектов в группы облегчает процесс администрирования баз данных, и строится на основе формальной структуры организации. Эта технология обеспечивает владельцу объекта (представления, сервера базы данных, процедуры, таблицы) передачу по своему усмотрению привилегий другому лицу. Таким лицом в данной ситуации может выступать субъект-пользователь, группа пользователей и такой возможный носитель привилегий как роль. Дальше привилегии можно распределить в зависимости от статуса пользователей (администратор сервера базы данных и база данных, прочие пользователи). А также следует отметить, что особенно важным следует считать поддержание уровня защиты привилегий, администратора сервера базы данных, так как. Хищения его пароля может привести к серьезным проблемам для всей хранящейся информации. Считается что главным достоинство применения произвольного управления доступом – это гибкость в управление защитой, однако такие сопутствующие характеристики как рассредоточенность управления и сложность централизованного контроля создают немало проблем для обеспечения безопасности данных. В качестве дополнения к средствам управления доступа можно отнести безопасность повторного использования объектов, которая должна гарантироваться для областей оперативной памяти, в частности, для буферов с образами экрана, расшифрованными паролем, для магнитных носителей. Следует также обратить внимание и на обеспечение безопасности повторного использования субъектов. Это означает лишение прав для входа в информационную систему всех пользователей, покинувших организацию. Специалисты по управлению безопасностью информации считают достаточным для большинства коммерческих приложений использование средств, произвольного управления доступом. И, тем не менее, остается нерешенной одна немало важная проблема слежение за передачей информации базы данных. Кстати, средства произвольного управления доступом не могут помешать авторизованному пользователю, законным путем получить конфиденциальную информацию и сделать ее доступной для других пользователей. И таким образом это происходит по той причине, что при произвольном управлении доступом привилегии существуют изолированно от данных. Для решения этой проблемы применяют подход, позволяющий осуществить разделение данных по уровням секретности и категориям доступа, называемый метками безопасности. Метка безопасности состоит из двух частей: уровня секретности и списка категорий. Первая составляющая зависит от приложения и в стандартном варианте может выглядеть как спектр значений от «совершенно секретно» до «несекретно». Вторая составляющая метки позволяет описать предметную область, разделяя информацию «по отсекам», что способствует лучшей защищенности. Метки безопасности строк таблиц добавляются к каждой строке реляционного отношения. Каждый пользователь также получает и собственную метку безопасности, которая определяет степень его благонадежности. Пользователь получает доступ к данным, если степень его благонадежности соответствует требованиям соответствующей метки безопасности, а именно: уровень секретности пользователя должен быть не ниже уровня секретности данных; набор категорий, заданных в метке безопасности данных, должен целиком находиться в метке безопасности пользователя. Механизм меток безопасности не отменяет, а дополняет произвольное управление доступом: пользователи по-прежнему могут оперировать с таблицами только в рамках своих привилегий, но получать только часть данных, столбец в метки безопасности не включается в результирующую таблицу. Основная проблема, имеющая место при использовании меток безопасности, поддержание их целостности. Это означает, что все объекты и субъекты должны быть помечены и при любых операциях с данными, метки должны оставаться правильными. При добавлении или изменении строк метки, как правило, наследуют метки безопасности пользователя, который считается инициатором операции. Таким образом, даже если авторизованный пользователь перепишет секретную информацию в общедоступную таблицу, менее благонадежные пользователи не смогут ее прочитать эту информацию и не каким образом не смогут овладеть данными. Принцип принудительного управления доступом основан на сопоставлении меток безопасности субъекта и объекта. Для чтения информации из объекта необходимо доминирование метки субъекта над метким объектом. При выполнении операции записи информации в объект необходимо доминирование метки безопасности (объекта над метким субъектом). Этот способ управления доступом называется принудительным, так как не зависит от воли субъектов. Этот способ нашел применение в СУБД, отличающихся повышенными мерами безопасности. Обеспечение целостности данных не менее важная задача, чем управление доступом. Главными врагами баз данных являются ошибки оборудования, администраторов, прикладных программ и пользователей, а не злоумышленников. С точки зрения пользователей СУБД, основными средствами поддержания целостности данных являются: ограничения правил. Ограничения могут поддерживаться непосредственно в рамках реляционной модели баз данных, а могут задаваться в процессе создания таблицы. Табличные ограничения могут относиться к группе столбцов, отдельным атрибутам. Ссылочные ограничения отвечают за поддержание целостности связей между таблицами. Ограничения накладываются владельцем таблицы и влияют на результат последующих операций с данными. Ограничения являются статическим элементом поддержания целостности, так как, они или разрешают выполнять действие, или нет. Правила позволяют вызывать выполнение заданных процедур при определенных изменениях базы данных. Правила ассоциируются с таблицами и срабатывают при изменении этих таблиц. В отличие от ограничений, которые обеспечивают контроль относительно простых условий, правила позволяют проверять и поддерживать соотношения любой сложности между элементами данных в базе. В контексте информационной безопасности необходимо отметить, что создание правила, ассоциированного с таблицей, может реализовать только владелец этой таблицы. Пользователь, действия которого вызывают срабатывание правила, должен обладать лишь необходимыми правами доступа к таблице. Тем самым правила неявно расширяют привилегии пользователя. Подобные расширения должны контролироваться административно, так как даже незначительное изменение правила может кардинально повлиять на защищенность данных. Существует явное предостережение при использовании правил как инструмента информационной безопасности: ошибка в сложной системе правил чревата непредсказуемыми последствиями для всей базы данных. Также протоколирование и аудит — это проверка того, все ли предусмотренные средства управления задействованы и соответствуют уровню защищенности установленным требованиям. Такая мера как протоколирование и аудит состоит в следующем: обнаружение необычных и подозрительных действий пользователей и идентификация лиц, совершивших эти действия; оценка возможных последствий состоявшегося нарушения; оказание помощи; организация пассивной защиты информации от нелегальных действий пользователя: поддержка точности вводимых данных; поддержка документации в активном виде; корректное тестирование пользователей. Кстати рекомендуется при выполнении организации протоколирования фиксировать факты передачи привилегий и подключения к той или иной базе данных. Следующим вопросом в рассмотрении проблемы обеспечения информационной безопасности является анализ средств поддержания высокой готовности. Если речь идет о СУБД, то необходимо в архитектуре аппаратно-программного комплекса иметь средства, обеспечивающие нейтрализацию аппаратных отказов и восстановление после ошибок обслуживающего персонала или прикладных программ. Сохранение информации базы данных на диски, помещаемые затем в безопасное место, уже длительное время активно применяется для информационных систем. При архивировании сохраняются пространства базы данных и многочисленная сопутствующая информация, необходимая для последующего восстановления. Резервное копирование – это периодически выполняемая процедура получения копии базы данных и ее журнала изменений на носителе, сохраняемом отдельно от системы. Надо помнить, что архив отражает состояние базы данных на время начала архивирования. Резервные копирования логических журналов транзакций сохраняет файлы журналов; интерпретация последних действий позволяет восстановить базу данных до состояния, более позднего, чем момент последнего архивирования. На основании полученной информации из архива и или резервной копии может быть осуществлено восстановление как архивной информации (физическое восстановление), так и более свежие состояние базы данных (логическое восстановление). Можно перечислить возможности службы восстановления на примере СУБД Informix: архивировании в горячем режиме, т.е. без прерывания работы сервера; резервное копирование журналов транзакций; сохранение на удаленных устройствах; сохранение по заранее определенному расписанию без участия оператора; сжатие и шифрование информации. Контрольные точки – это момент синхронизации между состоянием базы данных и журнала транзакция. В это время принудительно выгружаются содержимое буфера оперативной памяти на устройства вторичной памяти. Рассмотренные выше средства сохранения могут обеспечить качественное восстановление с минимальными потерями пользовательской информации, однако работа сервера базы данных будет на некоторое время прервана. Следующий механизм, обеспечивающий высокий уровень отказоустойчивости — это технология тиражирования данных. Тиражирование данных – это асинхронный перенос изменений объектов исходной базы данных в другие базы, принадлежащие различным узлам распределенной системы. В конфигурации серверов базы данных выделяют один основной и ряд вторичных. В обычном режиме работы основной сервер выполняет чтение и обновление данных, обеспечивает перенос зафиксированных изменений на вторичные серверы, в случае отказа основного сервера его функции автоматически или можно в вручную переводятся на вторичный сервер в режим работы “чтение + запись”. После восстановления функций основного сервера, ему может быть присвоен статус вторичного сервера, а вторичному делегированы все полномочия основного (при этом обеспечивается непрерывная доступность данных). Процедура тиражирования осуществляется либо в синхронном режиме, либо в асинхронном. Благодаря первому осуществляется гарантированность полной согласованности данных, то есть, на вторичном сервере будут зафиксированы все транзакции, выполненные на основном. Асинхронный режим улучшает рабочие характеристики системы, не всегда кстати стоит подметить или запомнить, обеспечивая полную согласованность (стоит заметить, что далеко не во всех задачах требуется синхронизация фиксации данных; достаточно поддерживать данные лишь в критические моменты времени). 2.3 Защита коммуникаций между пользователем и сервером Как было сказано выше, администратору приходится сталкиваться не только с управлением баз данных, но и существуют проблемы защиты коммуникаций между пользователем и сервером. В информационных системах не является специфичной для СУБД. Для обеспечения защиты информации выделяется сервис безопасности, в функции которого входит аутентификация, шифрование и авторизация. Эти вопросы были рассмотрены выше. Отражение угроз, привычные функции для СУБД. Однако главный источник угроз для СУБД лежит в самой природе баз данных. Наличие специфического непроцедурного языка SQL, процедура и механизм правил – все это обеспечивает потенциальному злоумышленнику средства для получения информации, на которую он не имеет полномочий. Нередко кстати хочу подметить нужную, но недоступную по статусу информацию можно получить путем логического вывода. Например, используя операцию вставки, а не выбора (на которую прав нет), анализировать коды завершения SQL-операторов, и получать информацию о наборе первичных ключей. Для борьбы с подобными угрозами используется механизм размножения строк для СУБД, поддерживающий метки безопасности. Суть этого метода состоит в том, чтобы в состав первичного ключа добавлять метку безопасности, что обеспечивает одновременное хранение в базовой таблице несколько экземпляров строк с одинаковыми значениями важных ключей. Агрегирование – это метод получения новой информации путем комбинирования данных, добытых легальным путем из различных таблиц базы данных. Бороться с агрегированием все-таки, можно за счет тщательного проектирования модели данных и максимального ограничения доступа пользователя к информации. Таким образом, можно определить некоторые стратегии в области безопасности: минимум привилегий; разделение обязанностей; эшелонированная оборона (сервер базы данных, средства защиты СУБД и операционной системы); разнообразие средств защиты; невозможность перехода в небезопасное состояние; всеобщая поддержка мер безопасности. база данные администратор Заключение Администрирование базами данных предусматривает очень нелегкое выполнение функций, направленных на обеспечение надежного и эффективного функционирования системы баз данных, а также адекватности содержания базы данных быстроты получения доступной информационным потребностям пользователей, отображения в базе данных актуального и понятного состояния предметной области. Администратор БД отвечает за целостность информационных ресурсов компании, фирмы, предприятия эта очень нелегкий труд в нашем современном мире, каждая фирма, а также предприятие хочет, как много больше узнать о конкурентах. Даже чем занимается конкурент и какой доход имеет фирма, вот для этого и нужно очень хорошо знать систему администрирование и защита баз данных. А также на нем лежит ответственность по созданию, обновлению и сохранности связанных между собой резервных копий файлов, исходя из задач предприятия. Администратор БД должен уметь точно определять уязвимые места системы, ограничивающие ее производительность, настраивать SQL и программное обеспечение СУБД и обладать в этой сфере отличным знаниям и умениям решать все эти проблемы быстро и эффективно, а также знаниями необходимыми для решения вопросов оптимизации быстродействия БД. Администратор базы данных (АБД) должен координировать действия по сбору сведений, проектированию и эксплуатации базы данных, а также по обеспечению защиты данных. Он обязан учитывать текущие и перспективные информационные требования предметной области, что является одной из главных задач. Список использованных источников Хубаев Г.Н. Патрушина С.М. Савельева Н.Г. Серия: Учебный курс, cтраниц: 288 Издательство: Феникс, 2014 г. Гуде С.В., Ревин С.Б. Информационные системы. Учебное пособие. – М., 20015г. – 147с. Дунаев С. Доступ к базам данных и техника работы в сети. Практические приемы современного программирования. – М., 2015г. Информатика: Учебник для вузов/Козырев А.А. – СПб., 2012г. Информатика: Учебник для вузов/Острейковский В.А., М: Высшая школа, 2014г. 5-е изд. Информатика: Учебник / Каймин В.А., 3-е изд. перераб. и доп. – М: Инфра-М., 2015г. Информатика: Учебник/Под ред. Н.В. Макаровой, 3-е изд., перераб. и доп. – М.: Финансы и статистика, 2014г. Мейер Д. Теория реляционных баз данных: пер. с англ. – М., 2015г. Ревунков Г.И., Самохвалов Э.Н., Чистов В.В. Базы и банки данных и знаний. Учебник для вузов//Под ред. В.Н. Четверикова. – М., 2013г. Интернет источники: https://ru.wikipedia.org/wiki/ http://www.taurion.ru/access/20 https://works.doklad.ru/view/Ym2qst06q14.html http://desktop.arcgis.com/ru/arcmap/10.3/manage-data/administer-gdb-intro/geodatabase-administration.htm https://works.doklad.ru/view/Ym2qst06q14/all.html https://gudermes.hh.ru/catalog/Informacionnye-tehnologii-Internet-Telekom/Administrator-baz-dannyh |