Правила и методики
Категория: Политика администрирования | Автор: admin | 29-06-2010, 04:46 | Просмотров: 3241

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

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

  • правила административного обслуживания;
  • перечень прав и обязанностей пользователей;
  • правила для администраторов (пользователей с особыми привилегиями);
  • правила создания "гостевых" учетных записей.

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

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

Сегодня в корпоративной среде UNIX-системы заменили большие мэйнфреймы, и на них возлагается основная вычислительная нагрузка. В UNIX-системах почти все стандартные задачи документированы в форме контрольных списков и инструкций (называемых "run books" или "checklists"), доступных в оперативном режиме или хранящихся в печатном виде. Написанием и поддержкой этих инструкций занимается дополнительная группа системных администраторов (не входящая в состав основного штата системных администраторов, обслуживающих технику и использующих эти инструкции). Тем не менее, такая организация и стандартизация в конце концов окупаются.

Следует рассмотреть вопрос о разработке методик:

  • подключения компьютера;
  • подключения пользователя;
  • настройки и конфигурирования компьютера;
  • установки библиотеки TCP-оболочек на компьютер;
  • настройки резервного копирования для нового компьютера;
  • защиты нового компьютера;
  • перезапуска сложного программного обеспечения;
  • восстановления Web-серверов, которые не отвечают на запросы или не предоставляют данных;
  • разгрузки очереди и перезагрузки принтера;
  • модернизации операционной системы;
  • инсталляции пакета прикладных программ;
  • инсталляции программного обеспечения по сети;
  • модернизации наиболее важных программ (sendmail, gcc, named и т.д.);
  • резервного копирования и восстановления файлов;
  • выполнение аварийной остановки системы (всех компьютеров, всех, кроме наиболее важных компьютеров, и т.д.).

 

Часто проблему можно отнести и к правилам, и к методикам, например:

  • Кто может иметь учетную запись?
  • Что произойдет, если этот пользователь уволится?

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

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

В частности, мы считаем, что управление Internet-адресами, именами компьютеров, идентификаторами пользователей и групп, регистрационными именами должно осуществляться единообразно для всех компьютеров организации. Для больших структур (в частности, транснациональных корпораций) такой подход реализовать непросто, но если вам удастся это сделать, управление значительно упростится. Средства, которые облегчают управление хостами и пользовательскими учетными записями, можно получить по сети. Имеющиеся у нас старые версии addhost и adduser не являются хорошими примерами, однако они еще применяются и, если вы не найдете ничего лучшего, возьмите эти программы на узле ftp.xor.com.

Мы убеждены, что ни в коем случае нельзя предоставлять нескольким пользователям одно и то же регистрационное имя. Это правило гораздо легче внедрить, если сразу же устранить соблазн коллективного использования имени. Хорошая альтернатива несанкционированному применению одного и того же имени — "гостевой" компьютер с либеральными правилами создания учетных записей. Однако сейчас, когда некоторые службы (AOL, Hotmail, Yahoo и др.) предоставляют адреса электронной почты и существует доступ к Internet из библиотек, Internet-кафе и пр., мы не считаем данный метод необходимым.

Многие вопросы регламента относятся не только к вашей локальной административной группе. Это, например:

  • нарушения системы защиты;
  • управление экспортом в NFS;
  • критерии выбора паролей;
  • удаление регистрационных имен;
  • защита материалов знаком авторского права (например, для файлов МРЗ и DVD);
  • программное пиратство.

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

 

Правила безопасности

 

Что именно вы хотите защитить? Данные? Аппаратное обеспечение? Или речь идет о способности быстро восстанавливаться после катастрофы? При проектировании политики безопасности для сети организации вы должны найти разумный баланс между:

  • предлагаемыми услугами и обеспечиваемой безопасностью (больше сервисов = меньше безопасность);
  • простотой и удобством использования и безопасностью (безопасность = 1/удобство);
  • стоимостью средств безопасности и убытками (риском) от ее нарушения.

В 1997 г. одна из подгрупп IETF выпустила 75-страничный документ, озаглавленный Site Security Handbook (Справочник по защите систем) и оформленный как RFC2196. В нем содержатся рекомендации системным администраторам по различным аспектам защиты, правилам использования и методикам работы. Рецепта обеспечения безопасности Internet-узлов здесь нет, но есть другая, не менее ценная, информация.

Документ RFC2196 предлагает включать в правила следующие разделы:

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

Примечательно, что из документа RFC2196 исключена часть о политике аутентификации, определяющая, кто может создавать новые регистрационные имена и расширять привилегии. Предыдущая версия документа Site Security Handbook (регистрационный номер RFCI244) содержала список конкретных политических задач и вопросов, требующих регламентирования, а не просто описание типов политик, что, вероятно, было более полезно системному администратору. Более новый RFC включает рекомендации для каждого типа службы, которая может работать на компьютере, описывает круг возможных проблем, связанных с этими службами, и методы их решения.

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

 

Правила для пользователей

 

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

В правилах для пользователей необходимо регламентировать такие вопросы:

  • использование учетных записей совместно с друзьями и родственниками;
  • выполнение программ дешифровки паролей для расшифровки локального файла passwd;
  • выполнение программ дешифровки паролей для расшифровки файлов passwd других систем;
  • нарушение нормального процесса обслуживания;
  • проникновение в чужие учетные записи;
  • неправильное использование электронной почты;
  • просмотр файлов других пользователей (есть ли возможность чтения? записи? одобряется ли?);
  • публикации в Usenet (запрещены? с оговорками? разрешены?);
  • импорт программ из Internet (запрещен? разрешен? разрешен с проверкой?);
  • использование системных ресурсов (принтеров, дисков, модемов, процессора);
  • копирование лицензионного программного обеспечения;
  • выдача разрешений на копирование лицензионного программного обеспечения другим лицам;
  • копирование защищенных авторскими правами материалов (музыки, фильмов и пр.);
  • всевозможная незаконная деятельность: мошенничество, клевета и др.;
  • вовлечение в деятельность, которая является запрещенной (например, порнография).

Два примера соглашений вы найдете на нашем сервере www.admin.com. Одно предназначено для студентов первых курсов, у которых наличие регистрационного имени является привилегией, а не правилом. Оно является более жестким. Второй документ предназначен для преподавателей, сотрудников и студентов старших курсов.

В качестве примера простого и краткого соглашения мы приводим документ, который требуется подписать для доступа к компьютерам факультета компьютерных наук Университета Мельбурна:

Я, нижеподписавшийся, настоящим объявляю, что буду придерживаться приведенных ниже правил:

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

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

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

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

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

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

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

Я понимаю, что должен придерживаться Правил 8.1.R7 Университета Мельбурна (изложены в Дневнике студента), которые также определяют и регулируют порядок использования вычислительных средств университета.

Я понимаю, что действия, противоречащие изложенным выше принципам, повлекут за собой жесткие взыскания, включая отказ в изучении темы или предмета, временный запрет или лишение доступа к университетским вычислительным средствам, временное или полное исключение из университета, штраф и/или другие действия, предусмотренные Crimes (Computer) Act 1988 г.

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

 

Правила для администраторов

 

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

 

Если для доступа в систему с правами root применяется программа типа sudo, администраторам следует выбирать надежные пароли и не делить учетные записи с кем попало. Регулярно проверяйте пароли системных администраторов при помощи программы crack. Кроме того, важно, чтобы они не использовали команду sudo tcsh, поскольку этим нарушается способность sudo регистрировать события и выполняемые команды.

Некоторые системные администраторы злоупотребляют своими возможностями. Таким сотрудникам лучше предложить другие должности.

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

Есть еще один успешно проверенный нами метод: поместить пароль root в конверт и спрятать его в известном месте. Администраторы обычно пользуются в своей работе программой sudo; если по какой-либо причине им понадобится пароль root, они вскроют конверт. После этого пароль root меняется и прячется в новый конверт. Конечно, отпарить конверт ничего не стоит, но доступ к тому месту, где он хранится, имеют только администраторы.

 

Правила и методики для экстренных случаев

 

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

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

У хакеров сейчас в моде взламывать Web-узлы. Для системных администраторов компании, предоставляющей услуги Web-хостинга, такой взлом — очень большая неприятность. Тут же начинаются телефонные звонки от обеспокоенных клиентов, СМИ и от партнеров компании, увидевших новость по CNN. Кто будет отвечать на все эти звонки? Что он скажет? Кто возьмет на себя ответственность за исправление ситуации? Какими будут обязанности каждого из членов персонала? Если ваш бизнес на виду у широкой общественности, все это нужно очень тщательно продумать, и возможно, даже провести учения.

 

Планирование на случай аварий

 

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

Существует несколько типов аварий и непредвиденных ситуаций:

  • нарушение защиты (60% нарушений защиты обычно происходит внутри организации);
  • внешние воздействия на технику: скачки напряжения и отключение питания, поломки кондиционеров и вентиляторов, потопы, ураганы, землетрясения, метеоры, вторжения пришельцев из космоса;
  • человеческие ошибки: удаленные или поврежденные файлы и базы данных, потерянная конфигурационная информация (возможно, ваша система зеркалирования данных работает с такой скоростью, что ошибка успевает распространится в ней до того, как вы сообразите, что произошло?);
  • неожиданный выход из строя аппаратного обеспечения: отказ сервера, поломка жесткого диска, нарушение работы сети.

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

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

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

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

План аварийных мероприятий лучше проверить заранее. Если вы основательно готовились к выживанию в случае аварий, ожидавшихся 1 января 2000 года, возможно, стоит оставить кое-что из запасов — например, фонари с аккумуляторами. (Есть очень удобные — они вставляются розетку и зажигаются, когда отключается электричество, так что их сразу легко найти.)

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

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

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

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

 

В одной из крупных правительственных лабораторий США недавно создали новый машинный зал и установили в нем кластер из 256 процессоров Alpha, предназначенный для обработки больших научных моделей. Все было подключено к источникам бесперебойного питания и продумано до деталей. И вот однажды недолгое отключение питания вывело всю систему из строя на целых четыре часа. Почему? Оказалось, что компьютер, который управлял кондиционером, не был подключен к ИБП. Он отключился и отключил систему кондиционирования. Так что тестируйте системы как можно тщательнее.

 

Непредвиденные обстоятельства

 

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

Когда CNN или Sladshot объявляет, что ваш Web-узел отключен, пользователи могут ринуться смотреть, как дела, и в результате трафик возрастет настолько, что может разрушить то, что вы только что починили. Если ваш Web-узел не рассчитан на 25-процентное увеличение трафика, подумайте о том, чтобы использовать простое программное обеспечение, балансирующее нагрузку. Оно может просто направлять лишние обращения на сервер, возвращающий одну и ту же страницу: "Извините, узел слишком загружен и в данный момент мы не можем обработать ваш запрос".

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



 (голосов: 0)
Версия для печати | Комментариев: 0
Информация
Посетители, находящиеся в группе Гости, не могут оставлять комментарии в данной новости.


 
Логин
Пароль
 

 
Locations of visitors to this page