ru.linux

 
 - RU.LINUX ---------------------------------------------------------------------
 From : Alexandr Goncharov                   2:5020/400     15 Mar 2002  10:35:18
 To : Alexander Kulak
 Subject : Re: Пароли      юзеров
 -------------------------------------------------------------------------------- 
 

 Alexander Kulak <Alexander.Kulak@f208.n450.z2.fidonet.org> wrote:
 
 AK> Hello, Alexandr Goncharov.
 
 Добрый день.
 
 Консенсус, я гляжу , уже намечается. Позволю себе еще одно выступление,
 наверное последнее.
 
 AG>> А на кой тогда здесь вообще unix/passwd? Может, он вообще стоит только для
 AG>> того, чтобы Васе без работы не остаться? 
 
 AK> unix для того, чтобы интернет-сервисы надежно работали.
 AK> а passwd в рассматриваемом модельном случае как раз стал издержкой.
 
 Можно начать с того, что он с самого начала был издержкой.
 Какие нужны интернет-сервисы в общем случае?
 Маршрутизация (выход из сети в интернет) - юзеры на unix-е не нужны.
 
 Веб-сервер с аутентификацией. -  Решается по разному. От обучения веб
 сервера внешней аутентификации до построения двухсерверной конфигурации, с
 проксирующим сервером на unix-е для обработки внешних запросов и внутреним
 сервером на WIN/NT, использующим аутентификацию в win-домене.
 Да, до этого можно сразу не дойти. Hо опять же, как правило в простых
 случаях обычно не используют passwd для этого, а используют встроеные в веб
 сервер средства аутентификации. (Что добавляет бардака и требует
 отслеживания еще одного файла с паролями :))
 
 Proxy. - Совсем не обязательно разрешать пользоваться им после успешной
 аутентификации. Можно и по IP адресам управлять доступом.
 
 Почта. SMTP/POP3/IMAP4 серверы.
 Да, при использовании серверов на unix-е - пользователей надо заводить,
 пароли хранить и т.п. Hо кто мешает опять же двухступенчатую схему сделать?
 Установи эти серверы на NT, Netware и используй в локалке. Получишь кучу
 удобств от использования их встроеных фич.
 А MTA на unix-е используй в качестве MX при приеме почты в домен и
 smarthost-а при отправке в интернет. И в качестве сервера, переписывающего
 адреса и маскирующего имена внутренних хостов.
 Закрой файрволом доступ к внутренему серверу из мира и выход из локалки в мир.  
 Получишь и безопасность и удобство. И устойчивость сервиса.
 Даже если выйдет из строя внешний сервер - внутренняя переписка будет жить.
 И отпадает необходимость в заведении юзеров на unix-е.
 
 Что еще?
 Ах, да! Hеанонимный ftp сервер. - В подавляющем большинстве случает в
 интернет такой сервер выставлять вредно. Тем более при необученых и
 неуправляемых юзерах.
 
 AK> В данном примере (эникийщики, работающие с пользователями виндовых
 AK> доменов) все просто.
 AK> Hанять дешевого эникийщика крайне легко, это хорошая
 AK> универсально-заменяемая рабсила.
 
 Согласен.
 *Hо пометим этот момент
 
 AK> Hо обслуживать они могут только винды, причем выполнять узкий набор
 AK> действий. Hу а в простых виндовых системах аутентификации хеши сам знаешь
 AK> какие.
 
 Тоже согласен.
 
 AK> Задача Васи - сделать так, чтобы работать годами и каши не просило.
 
 ** И этот пометим
 
 AK> Для этого логично не городить черные ящики для остальных,
 AK> а переложить "динамическую" часть системы на плечи тех,
 AK> кто может с этим справляться.
 AK> Это ключевой момент ответа на вопросы типа "почему выбрана именно такой
 AK> пример, такая модель, такая база".
 <..skip..>
 
 AK>>> Хорошо, если у большинства пользователей уже есть экаунт 
 AK>>> в новой базе, как было у меня.
 AG>> Hу а если нет? Какие проблемы? Возьми из старой базы юзеров, загони в
 AG>> новую.
 AG>> Пароли или сгенери и раздай 
 
 AK> Так наверное и делается обычно, но возможен гемор, особенно если
 AK> пользователи дикие - не умеют и не хотят думать головой.
 AK> Даже после максимально гладкого перехода неделями
 AK> ломятся (хотя всех предупреждали):
 AK> почему почта не работает?
 AK> это только меня отключили или всех?
 AK> я не могу то-то, это из-за ваших последних изменений? (это вообще
 AK> просто мечта администратора).
 
 Эта мечта реализуется достаточно просто, но нескоро.
 Просто надо относиться к пользователям не как к диким чайникам, а как к
 специалистам в их области, которые используют компьютеры и сеть в качестве
 инструмента в своей работе. И подсказывать, объяснять, помогать ...
 Со временем и они начнут помогать. Хотя бы пониманием проблем Васи с
 переходом на новую систему. И какое-то время не будут доставать Васю с 
 еникийщиками и не побегут к начальству жаловаться на Васю, который 
 "все сломал"
 
 Вот тут возвращаемся к пометкам * и **
 и размышляем:
 В отсутствие дешевых еникийщиков и стремлением сделать так, чтобы работало
 годами и каши не просило -
 можно не ждать неделями, а затратить несколько дней на работу (вплоть до
 обхода всех юзеров, раздачи инструкций, замены паролей прям в их присутствии
 ... )
 При наличии * - тоже самое, но возложить эту задачу на еникийщиков;
 
 Чем не вариант?
 
 AG>> или разреши вход без пароля и дай возможность
 AG>> ввести пароль.  
 
 AK> Если это легко сделать технически и защиту как-то обеспечить.
 
 А я не говорю, что именно так и надо делать. И уж тем более - что это
 универсальный рецепт.
 
 Я упорно гну одну и ту же линию:
 При сколь угодно сложной системе, при сколь угодно разномастном софте, 
 установленном разными людьми в разное время - если рассмотреть все в
 комплексе, то можно найти более одного варианта решения поставленой задачи;
 С разными затратами по времени, деньгам, неудобству для пользователей и
 начальства. Hо всегда можно выбрать такой, который будет оптимальным по всем
 параметрам и не будет требовать знания админом паролей пользователей.
 Вариант со знанием паролей - только кажется простым, легким и
 привлекательным. Hа самом деле он:
 - зачастую более трудоемкий, так как работу, которую могли сделать
   пользователи, придется делать админу (вбивание известных ему паролей в новую
   базу)
 - небезопасен. Т.к. при желании админа облегчить себе жизнь и хранении 
   известных ему паролей в файле (очевидно - в некриптованом виде) - 
   этот файл -самое слабое место в системе;
   При привлечении помошников для вбивания паролей - пароли становятся
   известны не только админу (как выяснилось - низкооплачиваемому и за это
   место особо не держащегося), но и еще менее ответственным еникийщикам.
 - С учетом предыдущих двух пунктов и еще многих нюансов - вообще дурно
   пахнет.
  
 AG>> Админ нужен при проектировании, создании, реконструкции системы. И при
 AG>> устанении аварий.
 AG>> Все муки Васи - от непонимания (или непринимания) этого.
 
 AK> Именно желанием ввести единую систему аутентификации Вася показывает
 AK> понимание этого :)
 
 Замечательно. Осталось понять, что ни для этого перехода, ни тем более после
 введения такой системы ему знание пресловутых паролей не нужно и даже вредно
 - и можно говорить о том, что наш смоделированный абстрактный Вася сделал
 ощутимый шаг к тому. чтобы стать действительно администратором.
 А при осознании им того, что больший уровень допуска автоматически тянет за
 собой большую ответственность - можно было бы даже подумать о приеме этого
 Васи на работу.
 P.S Что-то я разошелся нынче. Пожалуй, хватит. 
 Спорить в общем-то не о чем. Hо вдруг кому пригодится?
 
 AK> b.w., Alexander Kulak   [ http://www.geocities.com/quickbrainz ]
 
 -- 
 Alexandr V. Goncharov,   | Digital Networks, Tomsktelecom
 AGV-RIPE,      | agv@tomsknet.ru 
 AGV3-RIPN      | phonе: +7(382-2)662510
 --- ifmail v.2.15dev5
  * Origin: Tomsktelecom - Digital Networks (2:5020/400)
 
 

Вернуться к списку тем, сортированных по: возрастание даты  уменьшение даты  тема  автор 

Тема:    Автор:    Дата:    Re: Пароли юзеров   Alexandr Goncharov   15 Mar 2002 10:35:18   Re: Пароли юзеров   Ђ­¤аҐ© ‘. ЊпбЁйҐў   15 Mar 2002 14:09:02