В качестве первого пункта предварительного замечания напомню наблюдения/размышлизмы камрадессы Zdrasti на тему индустриализации управления, с выведением *стандартизованных* винтиков иерархии управления, произвольно и в любой момент заменяемых без наблюдаемого ущерба производственному процессу мастеров бананового администрирования (MBA).
Однако тут остаётся проблема в виде наследования технологической традиции. И тут привлекаются монстры типа SAP (которому и хочется и боязно [потерять рынок Державы]), внедрение решений которого по организации приятного, тёплого и сухого, бытия дефективно-минет.жимента, с открытием кучи вкусных вакансий, обычно сопряжено с индустриализацией (в первую очередь стандартизацией) управленческого и даже основного производственного процессов. Что порождает экономию на адаптации очередного летуна от минетжимента.
Дополнительно рекомендую реконструкцию побочных эффектов *импорота* такого рода технологий с точки зрения *нашей* государственной безопасности.
И сверху, в качестве методологического обеспечения действа — стандартизация всех процессов согласно специально разработанным (кто озвучил крамольный вопрос о причинности, т.е. целях Действа?) стандартам группы ISO-900X.
А теперь можно переходить к предмету статьи, развивающем тему побочных эффектов деятельности профессионалов от как бы «информационной безопасности».
Во времена достаточно далёкие, ещё докоронакризисные, в поле моего зрения попадался корпоративный регламент по «информационной безопасности». В котором особенно «порадовал» факт оптимизации под задачу оправдания *закупки* проприетарных решений ныне вроде свалившей (но аккуратно, посредством «приостановки» деятельности) фирмы майкросовт — иносказательные требования поддержкии централизованной базы пользователей в реализации «домен» (про который старательно не допускается детализации, позволяющей разработку конкуррентной альтиернативы), и полное отсутствие упоминаний технологий, поддержка которых в самой распространённой ОС… досейчас мягко говоря оставляет желать лучшего (в первую очередь авторизация с использованием механизма «publickey»).
Откуда следует прискорбный вывод о победном шествии стандарта использования *парольного* механизма авторизации.
В результате локальные профессионалы ИБ уже не первый год ведут войну с ветряными мельницами пытаются продавить формат работы: один пользователь — одна учётная запись. Потому что при использовании парольного механизма авторизации имя пользователя является единственным доступным [и известным сочинителям регламентов] идентификатором.
Каковое лобби разбивается вдребезги об особенности реализации одного товарного ключевого элемента инфраструктурного программно-аппаратного комплекса (где в случае проявления следствий сочинённых на безопасном удалении от живой практики требований к построению информационной системы получится… красиво).
С точки зрения эксплуатации (аудита информационной безопасности) лично мне куда интереснее *инвариант* shell'а интерпретатора командной строки, собранного с *патчем* (!) отправки вводимых команд на удалённый syslog-сервер. Но это — хуже высшей математики. Поэтому встречается разве в виде устного Предания и неоффициальных патчей для понимающих.
Дальше ещё «веселее» (уже в кавычках, ибо ближе к моей личной практике).
Решение задачи администрирования GNU/Linux. Эти… эрудированные (см. исходный комментарий) профессионалы ничтоже сумняшеся согласовали использование удалённых подключений с правами пользователя root (что местами считалось правилом дурного тона ещё как бы не лет *двадцать* (!!!) тому назад) с использованием… пра-а-авильно, всё таго же *парольного* (!) механизма авторизации.
Ну и конечно же для разработанных нормативных документов основного риска выстраиваемой системы (адЪ в смысле централизованной базы пользователей в пакете с практическим инвариантом парольного механизма авторизации и неизбежным следствием в виде выработки у пользователя привычки втыкать свои регистрационные данные куда ни попадя где не спросят) не существует. Вероятно в силу априорной невозможности. Сарказм выкл.
Напоследок напомню, что во времена пышного расцвета технологии [парольного механизма авторизации] умные люди осторожные мастера своего дела рекомендовали использовать *оригинальные* (!) пароли для *различных* сервисов. Но этот тезис не выдержал испытания ростом числа сервисов. К тому же его давило профессиональное кармадрочерство на «силу» пароля… С выходом на утверждение стандарта использования *сохранённых* паролей.
К чему я это? Ах, да. К моде аборигенов ада к выставлению разнообразных запретов. В том числе на использование сохранённых паролей (хотя, чисто теоретически, идентификация данной опции требует специальной закладки на уровне протокола).
О том, что только на моей памяти второй десяток лет не видно даже намёков на постановку вопроса о разработке технологии безопасной передачи паролей (в силу организационных… особенностей, делающих надлежащее решение невозможным) скромно умолчу.
Со вполне фееричными… памятниками в виде практики распространения *несменяемых* (в интерфейсе пользователя) паролей к ключевым элементам инфраструктуры в cleartext и практически в общем доступе ☹
И напоследок, вишенкой на торт комментарий из обсуждения статьи о блокировке сервисов Meta (Facebook и прочие):
Так. Фейс и Инсту можно резать к чертям, а вот WhatsApp надо бы оставить он для работы важен
Пишу сюда потому что в поле моего зрения тоже наблюдается нездоровая популярность сервиса ☹
Комментарии
Даёшь ЧебурАську!
На днях прилетело очередное печальное подтверждение Тенденции:
Оповещение от отдела кадров: мы вас зарегистрировали у подрядчика, необходимо пройти по ссылке и задать *пароль* на личный кабинет (то есть по факту к ПД сотрудника может получить доступ *любой* «майор посередине», прочитавший письмо).
Тогда как *правильным* решением (без копирования вредных, но таких удобных и потому популярных практик) является: вот Вам ссылка на Ваш личный кабинет у подрядчика…
Ещё одна вишенка на торт (компилляция пересказа пары сообщений корпоративной переписки):
Крайне интересно наблюдать как *сочинителей* регламентов *парольной* (!) и антивирусной защиты удивляет встреча с адекватно настроенным пакетным фильтром на GNU/Linux.
О том, что *выключенный* пакетный фильтр на самой распространённой ОС (той самой, где дыры в *неотключаемых* сервисах живут годами) является если не стандартом конфигурации, то одним из распространённых вариантов нормы.
По мотивам упомянутого… события и наглядной иллюстрацией новейших тенденций вьеб-морда радует сообщением:
Интересно насколько глубоко смогли закопать условно-работоспособность?..
> то дешифруемые строки паролей пользователей.
Возможно, но не обязательно.
Может быть и вынос проверки качества пароля в окна его ввода.
В предлагаемом объяснении («вынос проверки качества пароля в окна его ввода») логично было бы *сразу* вернуть пользователю ошибку проверки *нового* пароля *вместо* сохранения результатов проверки с последующей рассылкой оповещений о необходимости исправления.
Вам не кажется?..
Если так, то да. Но сначала таких деталей не было
Хотя и в этом случае есть шанс, что разработчики написали что-то асинхронное, в стиле djb qmail или админки nic.ru :)
Ну да, конечно… С *недельными* задержками…
Сразу вспоминаю фигуранта примера тематической статьи и событие, принудившее того к пониманию формулировки задачи.