Невыдуманные истории
Категория: Политика администрирования | Автор: admin | 29-06-2010, 05:05 | Просмотров: 2570

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

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

 

Ошибка начальника (номер один)

 

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

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

 

Ошибка начальника (номер два)

 

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

% mail boss I like my new job, everyone is ao helpful, thank you. Working here for you will be really fun ...

Начальник прочел это сообщение и в ответ послал шутливое грубо-сексуальное замечание относительно размера ее бюста. Другие сотрудники (everyone было общим псевдонимом для всех сотрудников) отметили необходимость наличия символа возврата каретки между именем получателя и самим сообщением.

Через несколько часов начальник позвонил главному администратору (который к тому времени прочел и сообщение секретарши, и ответ босса) и сказал, что допустил ошибку (вероятно, вместо r поставил R?), поэтому копии сообщения нужно изъять из почтового ящика everyone, т.е. у нескольких тысяч служащих. Нечего и говорить, что администратор отказался.

 

Дэн, твое новое имя — Лестер

 

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

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

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

 

Кого увольнять?

 

Администратор-новичок и ученик оператора нашли способ проникновения в студенческие компьютеры вычислительного центра. Этими компьютерами управляла другая группа, известная своими крайне консервативными взглядами. Новички хотели сохранить "черный ход". Когда они собирались редактировать файл /etc/passwd, старший администратор дал им совет — вместо vi воспользоваться редактором vipw. После создания "черного хода" новички им не пользовались, в отличие от старшего администратора, который был в конце концов на этом пойман. Кого следует уволить?

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

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

 

Упрямец Джо

 

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

  • Уволили бы Джо?
  • Вынесли бы ему строгое предупреждение?
  • Просто пожурили бы?
  • Ничего не сделали?

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

Спустя несколько недель все повторилось. На этот раз почту читал другой человек: Том. Старший администратор вызвал его и предъявил доказательства — журнальные файлы. Оказалось, однако, что в то время, когда Том якобы читал почту, он на самом деле был на баскетбольном матче.

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

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

 

Приглашения на свадьбу

 

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

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

Обстоятельства, которые стали причиной такого поступка жениха, можно рассматривать как особые, однако были нарушены письменные правила. Служащий был ценным работником. Что делать? Все кончилось тем, что его уволили — правда, с неохотой. Он подал в суд, но проиграл дело.

 

Порнографические GIF-изображения

 

Как-то летом друг одного студента пришел к нему в гости в компьютерную лабораторию. Студент показал другу, как просматривать GIF-файлы и где найти "интересные картинки". Он посадил друга за последнюю станцию у задней стены, а сам стал делать домашнее задание. Закончив все дела, оба ушли.

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

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

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

 

Перенос данных

 

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

К своему удивлению, после загрузки станции с нового диска он увидел, что часы отстают на 297 дней. Что делать: немедленно очистить диск, посмотреть данные, вернуть диск обратно'' Первым его побуждением было удалить все файлы, но, подумав, администратор решил проверить данные и посмотреть, чьи они.

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

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

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

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

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

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

 

Билл должен умереть!

 

Один студент работал на компьютере в факультетской лаборатории. Не закрывая сеанса, он пошел за каким-то документом в другое помещение. В его отсутствие кто-то послал сообщение электронной почты по адресу president@whitehouse.gov.

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

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

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

Файл ~/.history, содержащий список ранее введенных студентом команд, показал, что он регулярно пользуется программой pine, тогда как злосчастное сообщение было послано с помощью mail, причем до отправки и после нее имели место длительные периоды бездействия. Большинство пользователей для чтения и записи почты применяет одну и ту же программу, поэтому сразу же встал вопрос о незаконном проникновении в пользовательскую учетную запись.

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

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


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


 
Логин
Пароль
 

 
Locations of visitors to this page