Можно ли остановить хищение информации из баз данных?

Вид материалаДокументы

Содержание


История администрирования БД
Обязанности администратора
Роль администратора в управлении БД
Обеспечение информационных систем (ИС)
Классификация АБД
В чем нуждается администратор БД?
Сколько нужно администраторов БД?
Как удержать администратора БД?
Подобный материал:
Работа Администратора

Можно ли остановить хищение информации из баз данных?


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


Итак, имеются следующие исходные данные:


- многие не догадываются о том, что их базы данных крадут;


- кража и причиненный ущерб имеют латентный характер;


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


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


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


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


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


Технические способы защиты


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


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


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


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


- шифрование трафика между клиентской рабочей станцией и сервером БД, что предотвратит попытки кражи информации на сетевом уровне;


- криптографическое преобразование тех данных, которые необходимо защитить. Это значительно снизит риск потери информации;


- хранение аутентификационной информации и ключей шифрования на персонализированном съемном носителе, например, на смарт-карте или USB-ключе. Это позволит устранить проблему «забытых паролей» и повысить персональную ответственность сотрудника;


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


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


Взято с сайта Connect.ru


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


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


Казалось бы, можно возложить эти задачи на системного администратора или в крайнем случае создать отдельную единицу — администратора информационной безопасности в составе ИТ- подразделений.


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


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


Второй вариант лучше предыдущего, но не намного. В этом случае финансирование защиты информации будет осуществляться по остаточному принципу. Будет ли руководство фирмы прислушиваться к мнению какого-то там администратора информационной безопасности? Тем более если мнение последнего будет противоречить мнению начальника службы ИТ? А ведь любое предположение администратора информационной безопасности будет «портить жизнь» персоналу ИТ-службы. Как вы думаете, долго ли начальник ИТ-службы будет терпеть самостоятельного администратора информационной безопасности?


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


«Люди, ведающие воротами, оружием и охраной, зачастую действуют автономно от сотрудников, занимающихся ИТ, — комментирует Крис Кристиансен, аналитик IDC. — Необходимо, однако, иметь информацию о том, кто был в здании, куда пошел, к каким информационным системам мог получить доступ. Две службы, отвечающие за безопасность, должны работать скоординированно, и тогда каждая из них станет сильнее». Наверное, в будущем мы увидим объединение служб физической и информационной безопасности, однако, на мой взгляд, это эволюционный процесс и на данном этапе еще довольно сложно найти людей, которые были бы специалистами в обоих вопросах.


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


Вместе с тем стоит помнить, что не бизнес существует ради безопасности, а безопасность существует ради бизнеса! На предприятии должна быть создана устойчивая «треугольная» структура — «аудит — служба защиты информации — ИТ-служба». Необходимо четко определить границы ответственности, чтобы служба информационной безопасности не превратилась в не подвластного никому, все контролирующего монстра.


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


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


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


Взято с сайта osp.ru


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


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


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


Криптография предполагает наличие трех компонент: данных, ключа связи и криптографического преобразования.


При зашифровании исходными данными будет сообщение, а результирующими - зашифрованное сообщение. При расшифровании они меняются местами.


Ключ - конкретное секретное состояние некоторых параметров алгоритма криптографического преобразования данных. В данном случае термин "ключ" означает уникальный битовый шаблон. Считается, что правила криптографического преобразования известны всем, но, не зная ключа, с помощью которого пользователь закрыл смысл сообщения, требуется потратить невообразимо много усилий на восстановление текста сообщения. Длина ключа, согласно ГОСТ 28147-89, равна 256 бит.


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


В СКЗИ "Верба" используется определенный ГОСТ 28147-89 симметричный алгоритм криптографического преобразования данных в режиме гаммирования, который подразумевает процесс наложения по определенному закону гаммы шифра на открытые данные (под гаммой понимается псевдослучайная двоичная последовательность, вырабатываемая по заданному алгоритму). ГОСТ 28147-89 также определяет процесс выработки имитовставки, который единообразен для любого из режимов шифрования данных. Имитовставка - это последовательность данных фиксированной длины, которая вырабатывается по определенному правилу из открытых данных и ключа либо перед шифрованием сообщения, либо параллельно с шифрованием. Имитовставка передается по каналу связи или в память ЭВМ после зашифрованных данных. Выработка имитовставки обеспечивает защиту от навязывания ложных данных, вероятность необнаружения которого зависит от длины имитовставки и равна 10-9. Поступившие зашифрованные данные расшифровываются, и из полученных блоков данных вырабатывается новая имитовставка, которая затем сравнивается с имитовставкой, полученной из канала связи или из памяти ЭВМ. В случае несовпадения имитовставок все расшифрованные данные считаются ложными.


Взято с сайта security.ru


Роль администратора базы данных (АБД)


Дэн Хотка

(The DBA Role, by Dan Hotka)

Oracle Magazine RE - Июнь 2002


Источник: сайт pinnaclepublishing.com, журнал Oracle Professional, October 2001


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


Среди моих работ есть доклад, называющийся "Роль администратора БД", который я иногда читаю, если ко мне обращаются с просьбой провести презентацию тематического характера. Мне кажется, что предлагаемый материал может оказаться довольно полезным для членов сообщества Oracle Professional . Статья дает общее представление о том, чем занимается администратор БД, его обязанностях и специализации относительно реляционных БД Oracle. По окончании доклада многие слушатели подходят ко мне со словами: "Как жаль что здесь нет моего начальника, чтобы он мог это услышать". Так вот теперь он сможет это прочитать!

Должностная инструкция


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


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


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

Стереотип администратора


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


История администрирования БД Oracle

Платформа Oracle не всегда была такой “ навороченной ” . Во времена Oracle V4 администратор БД зачастую оставался лишь разработчиком. Едиственным способом резервирования данных было "холодное" резервирование, то есть копирование всего программного обеспечения БД Oracle и файлов данных только при "выключенной" БД. Выход Oracle V5 и появление SQL*net ознаменовали собой развитие нового подхода клиент-сервер. Кроме того, в Oracle V5 были включены дополнительные средства настойки, такие как explain plan , средства аудита и тому подобное. В помощь администратору БД предоставлялся ряд дополнительных функций, призванных облегчить его работу. Начиная с Oracle V6 стало происходить разделение администраторов по специализациям. Корпорация Oracle выпустила целый пакет приложений; внедрила параллельный сервер; размеры баз данных можно было уже смело охарактеризовать, как очень большие; по этим причинам системой становилось все труднее управлять, что еще более усугубялось наличием ошибок и разрушением данных. Кроме того, в Oracle V6 впервые были введены триггеры и язык PL/SQL, а заинтересованной общественности представлен механизм репликации. Сложность же пакета Oracle V7 достигла небывалых до той поры высот, воплотив понятие целостности ссылочных данных или отношения первичный/внешний ключ на уровне БД. Это позволило упростить написание приложений , однако добавило лишней головной боли администраторам БД. Oracle V8, в свою очередь, познакомил всех с разбиением таблиц и индексов, и массой новых средств индексации. Oracle8i поднял планку еще выше благодаря поддержке файловой системы Интернет, Java-триггеров и т . д.


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


Обязанности администратора


Что касается обязанностей администратора БД, то у него их множество. Среди наиболее важных - резервное копирование и воостановление информации. Механизм резервирования и восстановления данных обязан учитывать зависимость бизнеса от информации. Другими словами, если в Вашей прикладной системе приема заказов через Интернет любая потеря информации является абсолютно недопустимой, то использование схемы "холодного" резервирования, т.е. подразумевающую полную остановку и отключение БД, в данном случае, совершенно неприемлемо. Для того, чтобы найти наилучшее решение, соответсвующее запросам предприятия, администратор должен хорошо разбираться в многообразии методов резервирования и восстановления, знать плюсы и минусы каждого из них.


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


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





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


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


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


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


Роль администратора в управлении БД Oracle


Существует множество спецализаций, связанных с Oracle-приложениями, начиная, в первую очередь, непосредственно с самих конечных пользователей. Вот кто настоящие клиенты администратора. Если Вы имеете дело с Интернет-системой, то иногда прямая связь с пользователями просто невозможна. Предполагается, что все люди, о которых идет речь в этой статье, работают в одной компании. Так вот, пользователям необходим доступ к отдельным объектам базы данных, составляющим их приложение. Обязанность администратора обеспечить им необходимые права для выполнения соответствующих операций. Кроме того, администратор может взаимодействовать с пользователями по вопросам, касающимся функционирования БД и уж тем более когда он выполняет мероприятия по настройке системы.


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


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


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


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


Системный АБД больше заботится о программной среде Oracle в целом, нежели об ее отдельных элементах. В его обязанности входит поддержка аппаратно-программной вычислительной среды в оптимальном состоянии, обеспечивающем максимальную производительность для приложений, использующих среду в своих нуждах. Кроме того, к ним относится выработка соответствующих рекомендаций и принятие решений относительно резервирования/восстановления файлов. Системный администратор БД занимается всем, что касается вопросов производительности и проблем, способных оказать влияние на среду СУРБД Oracle. Он также ответственен за реализацию любых репликаций (replication) и параллельного функционирования, если эти механизмы задействованы в его системе . Обслуживание SQL*Net и Net8 тоже возлагается на системного АБД. В добавок ко всему вышеперечисленному, системный АБД отвечает за любой Web-сервер, с которого осуществляется доступ к базе данных, особенно если этот сервер на платформе Oracle.


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


Сетевой администратор обеспечивает связность элементов вычислительной сети. Без сомнения, под этим подразумеваются пользовательские АРМ, организация и администрирование внутренней и внешней сетей, а также информирование руководства о текущем состоянии системы и рекомендации относительно ее перспектив. Совместно с системным АБД, сетевой администратор осуществляет управление вспомогательными файлами SQL * Net или Net8, необходимыми конечным пользователям для подсоединения к среде Oracle.


Обеспечение информационных систем (ИС)


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


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


Классификация АБД


Существует несколько видов администраторов БД, а их обязанности вполне могут отличаться от компании к компании. Вот характеристики некоторых типов АБД и занимаемых ими положений:
  1. Оперативные (operational) АБД:
    1. манипулируют дисковым пространством
    2. наблюдают за текущей производительностью системы
    3. реагируют на возникающие неисправности БД
    4. обновляют системное ПО и ПО базы данных
    5. контролируют структурные изменения БД
    6. запускают процедуры резервного копирования данных
    7. выполняют восстановление данных
    8. создают и управляют тестовыми конфигурациями БД
  2. Тактические (tactical) АБД:
    1. реализуют схемы размещения информации
    2. утверждают процедуры резервного копирования и восстановления данных
    3. разрабатывают и внедряют структурные элементы БД: таблицы, столбцы, размеры объектов, индексацию и т.п.; сценарии(scripts) изменения схемы БД; конфигурационные параметры БД
    4. утверждают план действий в случае аварийной ситуации
  3. Стратегические (strategic) АБД:
    1. выбирают поставщика БД
    2. устанавливают корпоративные стандарты данных
    3. внедряют методы обмена данных в рамках предприятия
    4. определяют корпоративную стратегию резервирования и восстановления данных
    5. устанавливают корпоративный подход к ликвидации последствий аварии и обеспечению доступности данных
  4. Старшие (senior) АБД:
    1. досконально знают свой персонал
    2. пользуются высоким спросом
    3. могут написать скрипт, который освободит их из запертого сундука, брошенного в океан, и чрезвычайно гордятся своими произведениями
    4. тратят уйму времени на подготовку младших АБД
    5. очень ценятся руководством и получают бешеные деньги
  5. Младшие (junior) АБД:
    1. мечтают стать старшим АБД
    2. не слишком сильны в написании скриптов
    3. имеют большую склонность к использованию средств управления БД
    4. тоже неплохо получают
  6. Прикладные (application) АБД:
    1. в курсе информационных нужд компании
    2. помогают в разработке прикладных задач
    3. отвечают за разработку схемы и ее изменения
    4. вместе с системным АБД обеспечивают должный уровень резервирования/ восстановления данных
    5. занимаются построением тестовых БД
  7. Системные (system) АБД:
    1. отвечают за все необходимое для резервирования и восстановления данных
    2. контролируют производительность системы в целом
    3. осуществляют поиск и устранение неисправностей
    4. в курсе нынешних и будущих потребностей БД в плане емкости
    5. в курсе текущего состояния и нужд БД
  8. Наемныю (contract) АБД :
    1. приглашаются под конкретную задачу или в качестве консультантов
    2. передают персоналу необходимые знания
    3. фиксируют свои действия!
    4. должны прекрасно разбираться в соответствующей области
    5. хороши в качестве временного персонала, для оценки проекта или системы
  9. Администраторы-руководители :
    1. проводят еженедельные совещания
    2. определяют перечень первоочередных задач
    3. устанавливают и оглашают официальный курс и стратегию
    4. утверждают и корректируют должностные инструкции и список обязанностей
    5. следят за наличием соответствующей документации


Виды окружений ИС Oracle


Тип и размер центра сильно зависит от величины и возможностей компании. Маленькие центры, такие как dot-coms (.com - организации, имеющие только сайт в Интернете - прим.ред .) , небольшие производственные фирмы, или даже крупные отделы, только-только переходящие на Oracle, вполне могут обойтись одним АБД, выполняющим весь спектр задач. С одной стороны это хорошо: ясно к кому обращаться, кто за все отвечает. С другой стороны не все так однозначно. АБД в одних вопросах более копметентны нежели в других в зависимости от подготовки, поэтому иногда нелегко найти специалиста, который бы одновременно хорошо разбирался в администрировании приложений и был на “ ты ” с "железом" и средствами резервирования\восстановления данных Oracle. Кроме того, возлагая всю ответственность на одного человека, следует учитывать его склонности к обучению, сверхурочной работе и т.п.


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


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


В чем нуждается администратор БД?


Потребности администратора зависят от его обязанностей и квалификации. Основной вопрос, на который следует ответить, звучит следующим образом: чем занят обслуживающий персонал Вашей БД и чем Вы хотите, чтобы он занимался? Если ответы на первую и вторую часть этого вопроса не совпадают, то надо определить, что нужно, чтобы привести их в соответствие. Поскольку опытные АБД не только редки, но и недешевы, то, в нашем случае, идеальным выбором стало бы привлечение иструментальных средств. Они могут сделать из младшего АБД старшего и освободить его от лишних манипуляций, чреватых ошибками и отнимающих уйму времени.
  1. Профилактический монитор:
    1. избавляет администратора от экстренных мер
    2. разгружает администратора по вечерам и выходным
    3. ускоряет приобретение опыта
  2. Средства диагностики:
    1. превращают младшего АБД в старшего, позволяя последнему сконцентрироваться на других задачах
  3. Средства анализа:
    1. помогают при планировании роста БД и будущих затрат
  4. Средства технического обслуживания:
    1. помогают при резервном копировании и восстановлении данных, сокращая время операции и уменьшая число ошибок
    2. помогают при реорганизациях, экономя время, уменьшая количество ошибок и длительность профилактических окон (maintenance window)
    3. способствуют высокой доступности данных, создавая “ незаметные ” с точки зрения системы профилактические окна и помогая при резервировании / восстановлении системы.


Сколько нужно администраторов БД?


У каждой компании свои потребности, основанные на характере используемых приложений. Не существует двух контор с абсолютно одинаковыми запросами, тем не менее Gartner предлагает по этому поводу несколько рекомендаций:

оцените сложность и изменчивость БД по пятибальной шкале

добавьте по два очка за каждую дополнительную БД

учтите доходность системы

расставьте приоритеты на основе следующей таблицы:


всего занятость администратора

< 5 20%

5 или 6 25%

7 или 8 50%

> 8 полная


Как удержать администратора БД?


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


Резюме


Должность администратора БД бесспорно может считаться одной из самых недооцениваемых на предприятии. Этот человек в ответе практически за все, что только может пойти не так. Довольно неблагодарно считать устойчивое функционирование системы само собой разумеющимся фактом, а противоположную ситуацию - исключительно виной администратора БД. АБД нуждается в разнообразии средств, способных сделать его работу более продуктивной и избавить от авралов по вечерам и выходным. Кроме того, инструментальные средства позволяют АБД сосредоточится на выполнении своих непосредственных обязанностей вместо того, чтобы заниматься “пожаротушением”, решением неотложных проблем и выполнением рутинных, но от этого не менее подверженных ошибкам, процедур, таких как резервное копирование и реорганизации. Взято с сайта citforum.ru