О проблеме отражения провалов в образовании рукой.водителей на инфраструктуре предприятия

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

Однако тут остаётся проблема в виде наследования технологической традиции. И тут привлекаются монстры типа SAP (которому и хочется и боязно [потерять рынок Державы]), внедрение решений которого по организации приятного, тёплого и сухого, бытия дефективно-минет.жимента, с открытием кучи вкусных вакансий, обычно сопряжено с индустриализацией (в первую очередь стандартизацией) управленческого и даже основного производственного процессов. Что порождает экономию на адаптации очередного летуна от минетжимента.

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

И сверху, в качестве методологического обеспечения действа — стандартизация всех процессов согласно специально разработанным (кто озвучил крамольный вопрос о причинности, т.е. целях Действа?) стандартам группы ISO-900X.

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

Во времена достаточно далёкие, ещё докоронакризисные, в поле моего зрения попадался корпоративный регламент по «информационной безопасности». В котором особенно «порадовал» факт оптимизации под задачу оправдания *закупки* проприетарных решений ныне вроде свалившей (но аккуратно, посредством «приостановки» деятельности) фирмы майкросовт — иносказательные требования поддержкии централизованной базы пользователей в реализации «домен» (про который старательно не допускается детализации, позволяющей разработку конкуррентной альтиернативы), и полное отсутствие упоминаний технологий, поддержка которых в самой распространённой ОС… досейчас мягко говоря оставляет желать лучшего (в первую очередь авторизация с использованием механизма «publickey»).

Откуда следует прискорбный вывод о победном шествии стандарта использования *парольного* механизма авторизации.

В результате локальные профессионалы ИБ уже не первый год ведут войну с ветряными мельницами пытаются продавить формат работы: один пользователь — одна учётная запись. Потому что при использовании парольного механизма авторизации имя пользователя является единственным доступным [и известным сочинителям регламентов] идентификатором.

Каковое лобби разбивается вдребезги об особенности реализации одного товарного ключевого элемента инфраструктурного программно-аппаратного комплекса (где в случае проявления следствий сочинённых на безопасном удалении от живой практики требований к построению информационной системы получится… красиво).

С точки зрения эксплуатации (аудита информационной безопасности) лично мне куда интереснее *инвариант* shell'а интерпретатора командной строки, собранного с *патчем* (!) отправки вводимых команд на удалённый syslog-сервер. Но это — хуже высшей математики. Поэтому встречается разве в виде устного Предания и неоффициальных патчей для понимающих.

Дальше ещё «веселее» (уже в кавычках, ибо ближе к моей личной практике).

Решение задачи администрирования GNU/Linux. Эти… эрудированные (см. исходный комментарий) профессионалы ничтоже сумняшеся согласовали использование удалённых подключений с правами пользователя root (что местами считалось правилом дурного тона ещё как бы не лет *двадцать* (!!!) тому назад) с использованием… пра-а-авильно, всё таго же *парольного* (!) механизма авторизации.

Ну и конечно же для разработанных нормативных документов основного риска выстраиваемой системы (адЪ в смысле централизованной базы пользователей в пакете с практическим инвариантом парольного механизма авторизации и неизбежным следствием в виде выработки у пользователя привычки втыкать свои регистрационные данные куда ни попадя где не спросят) не существует. Вероятно в силу априорной невозможности. Сарказм выкл.

Напоследок напомню, что во времена пышного расцвета технологии [парольного механизма авторизации] умные люди осторожные мастера своего дела рекомендовали использовать *оригинальные* (!) пароли для *различных* сервисов. Но этот тезис не выдержал испытания ростом числа сервисов. К тому же его давило профессиональное кармадрочерство на «силу» пароля… С выходом на утверждение стандарта использования *сохранённых* паролей.

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

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

Со вполне фееричными… памятниками в виде практики распространения *несменяемых* (в интерфейсе пользователя) паролей к ключевым элементам инфраструктуры в cleartext и практически в общем доступе ☹

И напоследок, вишенкой на торт комментарий из обсуждения статьи о блокировке сервисов Meta (Facebook и прочие):

Так. Фейс и Инсту можно резать к чертям, а вот WhatsApp надо бы оставить он для работы важен

Пишу сюда потому что в поле моего зрения тоже наблюдается нездоровая популярность сервиса ☹