Как это было на самом деле.
Я не верю что это сделали хакеры. Да есть ссылка по которой хакеры делятся деталями своего "подвига". Но это не убедительно. Эти "аргументы" может каждый создать. Принт скрины это не доказательства.
На самом деле я считаю что был(и) задействованы внутренние ресурсы. ИТ-шники Аэрофлота, или внешние подрядчики оказывающие услуги ИТ. Это не редкость когда крупный бизнес использует внешних исполнителей и это не редкость что они имеют права администрирования на серверах заказчика.
Это уже выходит за рамки анализа ИТ-шных причин взлома, это из разряда "против лома нет приема". Роль хакеров, взявших ответственность на себя, отвести подозрения от настоящих преступников.
Кстати это дает основания для защиты настоящих преступников в суде даже если, по каким то вторичных признакам, к ним приведет расследование взлома. (Очень сомневаюсь что в системах на х86 можно персонифицировать, т.е. связывать те или иные действия с конкретной личностью.)
В самом деле, в суде, адвокат скажет: "Да, это мог сделать мой подзащитный(-ые), но вот же есть хакеры, которые взяли ответственность за взлом на себя, вот принтскрин с рабочей станции гендиректора, который не менял пароль доступа три года, вот принтскрин с AD сервера Аэрофлота, а вот граффити нарисованные из балончика с краской на мусорных баках во дворе офиса Аэрофлота".
Что если бы? Вариант номер 1 - х86.
Как специалист ИТ, работавший/работающий, в том числе, с компьютерной безопасностью на ИБМ МФ (z/OS) и интересовавшийся этими вопросами в случае серверов на х86 на уровне системного программирования в Microsoft Windows, сразу могу сказать, да, выстроить надежную систему информационной безопасности можно хоть на чем.
Но только теоретически. На практике, практически всегда, теоретическими возможностями защиты ПО на х86 пренебрегают. Причем это идет не столько от ИТ-шников, и даже может быть не от ИБ-шников (к чьим возможностям и способностям я очень критически отношусь потому что, работая в большой компании с порядка 400 человек в ИТ, я часто пересекаюсь с действиями ИБ-шников по вопросам их ролей и они меня зачастую умиляют), а от самого руководства бизнесом. Но...
Во-первых, если по настоящему строить систему безопасности на серверах х86 это потребует разработки на основе возможностей Windows внутренней модели контроля доступа к ресурсам, которая вообще говоря должна бы начинаться не с организации пользователя услуг ИТ на х86, а с разработчиков базовых приложений ИТ (ОС, БД, сервера приложений, и т.д. и т.п.).
Этим не занимаются вообще в разряде ПО класса open source, этим не занимаются даже такие вендоры как Microsoft. Недавно выявленная уязвимость, обнаруженная после ряда патчей, их SharePoint тому иллюстрация.
Во-вторых, если бы организации пользователей и вендоры базового ПО отнеслись бы к этому на полном серьезе, то это уже был совсем другой мир х86 серверов, совсем другие цены, и другие требования к квалификации программистов, админов и их менеджеров.
В-третьих, допустим нам удалось создать систему контроля доступа на должном уровне. Это повлечет за собой, на первых порах, огромный поток возмущений и требований типа "почему у меня нет доступа к тому и тому то?" или "почему эта программа у всех работает, а у нас не работает?".
Руководство может притащит откуда то какого ни будь волосатика в очках, свитере и джинсах, у которого есть гениальная программа для нашего бизнеса, и этот волосатик скажет через губу " Моя программа требует системный доступ.". И гендир скажет своему ИТ-шнику и ИБ-шнику: "Ребята, надо, я знаю что вы можете, вы же у меня самые-самые". И ребята сломают то о чем говорилось выше. Да им и не получится это сделать, и они даже подумать об этом не могут в сложившихся реалиях Ит на серверах х86.
Поэтому и не только, но для краткости ограничусь этим, хотя копать тут можно далеко, мы имеем как правило весьма облегченную систему контроля доступа, права админов раздаются на право и налево.
Тем не менее, сказать что вообще ничего не далается в области безопасности на х86 серверах, я конечно же не могу и не буду. Не знаю как в Аэрофлоте и более того в России вообще (хотя есть пара примеров от российских инсайдеров. Очень плохих примеров, никуда не годных примеров), но по компании где я работаю, не в России, я скажу что делается много, даже слишком много. И денег на это тратится тоже очень много, в основном на зарплаты многих и многих работников вовлеченных в эту увлекательную деятельность.
Нет они не создают комплексных систем контроля и управления доступами к компьютерным ресурсам, мониторингом доступа, пресечения несанкционированного доступа. Они, по моему мнению, затыкают дыры. Причем затыкая дыры они создают проблемы самим себе. Например, много уже лет назад пошла мода на двухфакторную аутентификацию. Прикупили на каком то блошином рынке программу (а как иначе, конечно все проблемы на х86 решаются покупкой новых программ) для двухфакторной аутентификации. Поставили ее на сервер, запустили в работу. Однажды сервер "сдох". Персонал, а это были главным образом ИТ-шники же, не может логиниться на сервера. Вот такой был пример укрепления бастионов. С тех прошло много лет, куплено, и внедрено было много других программ. Наверное это вселяет в души наших ИБ-шников (их ну очень много) надежду что они защитили нашу ИТ. Ну-ну. Нет, конечно защитили, двухфакторностью.
Что если бы? Вариант номер 2 - IBM mainframe and z/OS.
Изначально, пра-пра-пра-дед z/OS - OS/360 не имел никакой информационной безопасности. Впрочем у него и многопользовательского доступа тоже не было. Это была система пакетной обработки. Перфокарты, распечатка прогона задания.
Но уже в конце 60-х, начале 70-х этой проблемой в ИБМ занялись по серьезному. И появился компонент системы называемый SAF (System Authorization Facility). Ее роль:
SAF (System Authorization Facility) — это интерфейс, определяемый MVS (Multiple Virtual Storage) в мэйнфреймах IBM, который позволяет программам использовать службы системной авторизации для управления доступом к ресурсам.
Что это значит? Это значит что каждый менеджер ресурсов (под этим понимается любая программа, под управлением которой находятся те или иные, любые, компьютерные ресурсы: данные, программы и их функции, команды системы и подсистем, все что может быть использовано для неправомерной деятельности, или несанкционированного доступа к информации) при появлении запроса от кого или чего-либо обращается к SAF для проверки легитимности поступившего запроса. Ключевое слово КАЖДОГО.
SAF работает "в паре" с RACF (Resource Access Control Facility). RACF имеет и ведет базу данных (свою базу данных, не общего назначения), в которой хранится информация о профилях ресурсов. Профайлы ресурсов поделены на классы. Имеются классы USER, GROUP, DATASET, и GENERAL RESOURCE. C первыми тремя я думаю все понятно (профили их это UserID, GroupID, Data set names, GENERAL RESOURCE класс включает в себя профайлы в классах созданных по произвольной потребности контроля доступа. Например, класс OPERCMDS содержит профайлы контроля доступа к командам оператора MVS, JES, и RACF. Например профайл RACF.TARGET.LIST контролирует доступ к RACF команде TARGET с операндом LIST. Чтобы не создавать профайлы для каждого ресурса (их может очень много) в написании профайлов используются wildcard символ . Профайл RACF.TARGET.* включает правила для всех операндов команды TARGET.
Нечто подобное я видел в руководстве по системному программированию Microsoft Windows. Но я ни разу не слышал о реальном использование такого подхода. Мне конечно известно об Access Control Lists (ACLs), но опять же как часто и насколько обязателен/востребован этот механизм безопасности.
Профайлы RACF содержат информацию о том каким авторизованным процессам и пользователям какой уровня доступ разрешен. Если процесс/пользователь отсутствует в списке авторизованных, то доступ не будет выполнен и запрос процесса/пользователя останется без удовлетворения.
C другой стороны если сделан запрос к ресурсу для которого нет профайла в RACF то тоже запрос не будет удовлетворен.
Любые попытки доступа не предусмотренные политикой профайлов в RACF не только пресекаются, но и регистрируются. По каждому такому случаю создается сообщение, которое может быть преобразовано в, например, SMS администратору. Попытка использования неправильного пароля для пользовательского профиля (USER profile) более трех раз приводит к блокированию профиля. Автоматического разблокирования не предусмотренно, хотя можно в каждом конкретном случае это легко автоматизировать с помощью System Automation.
Профили, используемые для работы пользователя-человека имею сегменты. Эти сегменты дают право, и содержат стартап параметры для использования программ предназначенным для пользователя-человека. Если какого-то сегмента нет то и залогиниться не удастся. Примерами таких программ является Time Sharing Option (TSO) - диалоговая среда для пользователей типа программистов, операторов. Или Unix System Services (OMVS сегмент) - для пользователей Unix в z/OS. Есть программы z/OS, например, WebSphere, пользователи которых управляются самой такой программой, а профиль в RACF используется только для идентификации и аутентификации.
Профили, используемые для работы таких процессов как, например, база данных, или та же System Automation, т.е. когда не требуется процедура аутентификации, паролей не имеют и использовать их для логина в принципе невозможно. Эти профили создаются в классе USER, но во время создания таких профилей выбирается опция NO-PASSWORD. Уместен вопрос о том, а как же тогда используются такие профили, как запустить ту же БД, которая должна выполняться с её профилем не имеющим пароля, ответ прост - есть такой механизм запуска (типа Services в Windows), который позволяет авторизованному профилю запускать процессы для других профилей с указанием лишь имени профиля. Но для этого надо быть авторизованным и именно для этого процесса. Как? Через соответствующий профиль RACF.
Это весьма краткое введение в состояние компьютерной безопасности z/OS. В случае z/OS использование такого подхода к информационной и системной безопасности используется повсеместно и постоянно. Все программы для z/OS пишутся с обязательным использованием стандартов безопасности принятых за норму. Таким образом и через дополнительное ПО (third party) приникнуть в систему делается не возможным.
Кроме специфически мэйнфрэймовских технологий (RACF) в z/OS имеются общепринятые технологии безопасности, как то IP Security, Intrusion Detection System (IDS), и т.п.. RACF обеспечивает все функции работы с цифровыми сертификатами, Key Rings, and Tokens (последние два в других системах могут называться иначе).
Комментарии (75)
apcs660
29.07.2025 17:32Это еще LLM не добрались везде... Смотрю сейчас MCP - авторизация еще в драфте, то есть вызовы анонимные по сути или прикручивай как умеешь.
Все напоминает "сделать демку прототип поскорее и прикрутить в проде".
Мы еще наловим проблем с безопасностью в AI (уже ловим, вернее - новости есть).
На курсах RAG спрашиваю - как пробросить контекст пользователя дальше для фильтрации данных (не возвращать то к чему пользователь не имеет доступа). Впечатление что бегают трололо (мы скрутили какую то демку и ура, она работает, смотри как все просто, введите openai ключ и все будет работать) а нормального решения для многопользовательского окружения или нет или забыли показать. Примеры на 10 документов при которых бедная видюха идет на взлет (ембеддинг) - страшно представить сколько энергии улетит при прогоне 10М документов (в датацентре). А 100М? 500М?
Причем это проблема старая и началась не вчера - копался я к примеру, с lucene индексами и часто вопрос был: как сделать ограничение доступа к определенным записам в индексe? И приходились вкорячивать свой join, индекс для него и тд. чтобы фильтровать во время поиска. Потому что ни один движок на люсин (solr, elastic) нормально фильтрацию не поддерживали, join тоже (на кластере). Вернее решение возможно но за отдельную котлету денег, чем я и занимался.
zVlad909 Автор
29.07.2025 17:32копался я к примеру, с lucene индексами и часто вопрос был: как сделать ограничение доступа к определенным записам в индексe? И приходились вкорячивать свой join, индекс для него и тд. чтобы фильтровать во время поиска. Потому что ни один движок на люсин (solr, elastic) нормально фильтрацию не поддерживали, join тоже (на кластере). Вернее решение возможно но за отдельную котлету денег, чем я и занимался.
Наверное проблема не ограничения "доступа к определенным записам в индексe", а к строкам в таблицах.
Эта проблема давно решена в DB2 for z/OS, и в DB2 for LUW:
Row and column access control:
https://www.ibm.com/docs/en/db2-for-zos/12.0.0?topic=masks-row-column-access-control
Row and column access control (RCAC) overview:
https://www.ibm.com/docs/en/db2/11.5.x?topic=security-row-column-access-control-rcac
apcs660
29.07.2025 17:32увы, Lucene это не DB2 и не совсем база...
zVlad909 Автор
29.07.2025 17:32И зачем, интересно, понадобился этот зверь?
Это поисковик, Search Engine, верно? Где он ищет? В базах данных в том числе. Вот в этих БД и надо защищать информацию, а не в поисковике.
Эта ваша потребность в данном случае не обоснована. Кмк.
apcs660
29.07.2025 17:32да, это по сути, поисковик. Его неправильно использовали - это часто бывает, к сожалению. И рекомендации игнорируются. И кеш используется как основное хранилище. Но если очень нужно и клиент платит, то почему бы не создать франкенштейна? Любые капризы за ваши деньги...
В lucene кешировалась информация из различных источников, в том числе из баз, репозиториев документов, и полнотекстовый поиск в нем был. IBM FileNet частенько кролил, Image Services, ISRA, и напрямую из базы тоже если доступ давали (метаданные). COLD документ формат недавно крякнул, тоже старый IBM стандарт для хранилищ. Но с 390 дела не имел, разок только с AS400, это из ближайших родственников если смотреть
zVlad909 Автор
29.07.2025 17:32Любые капризы за ваши деньги...
Не исключено это тоже имело место быть в достижениях ИТ Аэрофлота.
Но с 390 дела не имел, разок только с AS400, это из ближайших родственников если смотреть
Это очень дальние родственники. Седьмая вода с киселя. В ИБМ много было в свое время денег и их тратили на многие разные поделушки. IBM RISC с AIX вытесняется успешно х86 и Linux. AS400 потому лишь продолжает существование что очень уж его принципы работы и ПО не похоже ни на что, ни на Linux ни на System Z (390).
apcs660
29.07.2025 17:32с AIX примерно тогда же возился.
Привезли IBM Everyplace Suite и я с ней продолбился... Пока не плюнул и не декомпильнул установщик. И что я нашел на 10м диске? Введите путь к базе данных (у меня был оракл) и затем неудаленная статичная переменная, путь к дб2... Вот это баг.забыли после отладки удалить а тестеры зеванули.
AS400 дали на месяц пощупать от IBM - забавная игрушка, починил ее заодно, не работал один порт на сетевую карту. Посмотрел доки, диагностику прогнал да переткнул карту - коллеги сказали "шайтан". Этот холодильник обходили стороной.И еще одна карта была по сути x86 PC - проц, память, видео, клава, мышь свое, а вот диск нарезался на материнской системе - такого тогда не встречал. Ставишь Линукс на комп на карточке расширения. "Виртуалка" в железе.
Хорошая система была 25 лет назад, но дорогая - ценник конский на все. И не мейнфрейм, не знаю ее нишу, вроде банки покупали и магазины, встречал пару раз их позже.
olku
29.07.2025 17:32Извините что вмешиваюсь. В Эластик можно вкрутить плагин, который будет фильтровать поисковые запросы как прокси. Костыль, конечно, из коробки не умеет.
И не смотря на то, что индекс это не RDBMS, он тоже вполне себе база с данными. И иметь row/column контроль хотелось бы.
apcs660
29.07.2025 17:32без проблем, это же публичная дискуссия. Движок был кастомный, рефакторил его, по наследству. Упор был на вертикальное масштабирование - индекс мог быть на нескольких дисках (композитный).
Потом солр зачем то подтянули. Эластик после 5й версии не видел, но впечатление по коду оставил хорошие по сравнению с солр.
Независимо от того какой поисковик, все упирается в люсин, и в нем либо допиливать join с люсиновским JoinUtil классом ( и своим индексом), либо вычисляемые поля сделать (кастомный тип данных в люсин).
Еще было востребована похожая тема - lookup поля когда в индексе хранится число (id, int) а пользователю возвращается текст в локале пользователя (и сортировка по тексту). Если клиенты из разных стран и локали разные, либо тексты меняются часто, то рекролить индекс на сотни млн документов так себе идея (нормализованное хранение лучше). А люсин индекс по сути, если аналогию с базой проводить - это одна таблица. В которой ты делаешь join между записями (если индекс один)
Shadow_ru
29.07.2025 17:32Db2 по сравнению с соларом при поиске в тексте это как гусеница по сравнению с самолётом.
funkerwolf
29.07.2025 17:32А что если бы не забивали на правила ИБ и как минимум все системы поддерживали в актуальном состоянии. Конечно, полно умников с линуксами, но простите какой вам линукс, если с виндой даже справиться не в состоянии...
xVICTORINOXx
29.07.2025 17:32Проблема не в том, что кто-то забивает, а в том, что это бизнес по-русски - максимальные прибыли в кратчайшие сроки, закрывая глаза на всë. У руководства нет понимания важности ИБ, у людей на местах нет возможности быть услышанными снизу, особенно если их предложения либо замедляют получение прибыли, либо уменьшают еë, требуя дополнительных трат на направление. И случается тр, что случается - экономия на важном до первого жареного петуха. И усугубляется это всë ещë и госсектором.
Vadim_1984
29.07.2025 17:32Ну а если от этого прямых убытков (и косвенных в виде репутационных потерь, но это сложно оценить) было меньше, чем мог бы стоить штат сотрудников за время между возникновения проблемами, то как обосновать такой найм бизнесу?
SmileyK
29.07.2025 17:32Руководителю тоже ,тот еще кейс принять верное решение, когда каждое подразделение насыпает и говорит, вот им только и надо поставить, давайте вместо 50 рублей дадим 5, тот еще кейс принять верное решение …
apcs660
29.07.2025 17:32Да что там сложного в линуксе? Он же прост как табуретка. В качестве сервера самое то, вот пользовательский интерфейс бывает страшный или корявый
M_AJ
29.07.2025 17:32Он же прост как табуретка.
Потому в "классическом виде", то есть в виде дистрибудива с большим количеством пакетов, которые активно запускают друг друга, порой оказывается уязвим в самых неожиданных местах, когда какая-нибудь безобидная утилита позволяет повысить привилегии до рута.
По хорошему конечно софт лучше запускать в непривилегированных контейнерах, где вообще нет ничего кроме самой запускаемой софтины, а все что он видит это только ip-адрес другого такого же контейнера, где живет его собеседник, и свой изолированный вольюм, но чтобы оно так работало, его нужно так написать, а старый софт писали по другому, часто вообще не рассчитывая что там кто-то что-то может захотеть сломать.apcs660
29.07.2025 17:32Прямо жизнь в "докере" получается..
Да, вспомнилась давняя история с багом в ssl ping - когда какой то студент в библиотеке SSL в пинге проверку длины сообщения не сделал и эта базовая для многих пакетов библиотека расползлась. Канадскую налоговую (сайт) попинговали и увели десятки тысяч учеток и приватной информации - посылали пинг с декларируемой длиной сообщения в 64к и получали обратно кусок памяти этого размера с сервера. Классика жанра: казалось бы, не те времена, не 80е, а случилось. И просмотрели. Идиотский баг.
sdore
29.07.2025 17:32Статический анализ кода будет им в качестве урока.
apcs660
29.07.2025 17:32Качество разработки поднять всем полезно но как проверить библиотеки? Вот в чем вопрос... Нашел этот баг, он оказывается в вики есть:
Расширение Heartbeat для протоколов TLS и DTLS, обеспечивающее поддержку соединения активными без необходимости постоянного переподключения с полной авторизацией, было предложено RFC 6520 в качестве стандарта в феврале 2012 года. В 2011 году один из авторов RFC Робин Сеггельман реализовал Heartbeat-расширение для OpenSSL и выслал сопровождающим проекта. Код был проверен Стивеном Хэнсоном, одним из четырёх основных разработчиков OpenSSL. Хэнсон не заметил проблем в реализации и добавил уязвимый код в репозиторий OpenSSL 31 декабря 2011 года. Уязвимость распространилась с OpenSSL 1.0.1 14 декабря 2012 года. Поддержка Heartbeat была включена по умолчанию, что и повлияло на распространение уязвимости.
Меня память подвела похоже, раньше читал что студент написал а его код не проверили, махнули рукой. Баг и фикс на уровне детского сада из учебников по "как не надо писать код на С", классика такая что зубы сводит:
Атака реализуется через небольшой модуль Heartbeat-расширения TLS библиотеки OpenSSL. TLS — протокол представления данных поверх TCP, рассчитанный, однако, только на непрерывный поток данных. Если же обмен данными состоит из запросов и ответов, появляется возможность определять какую-то информацию по активности связи, да и после длинного простоя понадобится заново устанавливать TLS-соединение. Чтобы справиться с этой проблемой, клиент и сервер периодически обмениваются пакетами случайной длины, и этим поддерживают связь в активном состоянии и «зашумляют» канал[2].
Чтобы сложнее было отличить пульсовые сообщения от полезного трафика, разработчики использовали следующую тактику: пакет состоит из контрольной строки и ничего не значащего «хвоста». Сервер должен вернуть сообщение, состоящее из такой же строки и своей порции «шума». Длина контрольной строки задаётся 16-битным целым числом[2]. Если эта длина окажется больше, чем весь пакет, уязвимые версии OpenSSL читали память за пределами отведённого буфера (RFC предписывает не отвечать на такие пакеты). За пределами буфера могут встретиться любые данные, в том числе (очень редко) закрытые ключи шифрования сервера, данные других соединений, содержащие идентификационные cookie и многое другое[3].
Heartbleed осуществляется отправкой некорректно сформированного Heartbeat-запроса, в котором реальная длина строки меньше указанной, а число, символизирующее длину передаваемой строки, в свою очередь, больше действительной длины строки. Так можно получить в ответ от сервера больше всего скрытой информации. Таким образом, у жертвы возможно за один запрос узнать до 64 килобайт памяти, которая была ранее использована OpenSSL.
Heartbeat-запрос выглядит так: «вернуть строку x, которая состоит из n символов», и получает ответ — строку x, состоящую из n символов. Heartbleed-запрос выглядит иначе: «вернуть строку x, которая состоит из количества символов n + y», и получает ответ, состоящий из строки x и ещё y символов, находящихся у жертвы в активной памяти.
Несмотря на то, что злоумышленник имеет некоторый контроль над размером блока памяти, он никак не может управлять положением этого блока, и поэтому единственный способ увеличить вероятность получения ценных данных — многократный повтор ошибочного пакета.
У канадцев тогда хорошо пригорело - почему только CRA (налоговая) подняла шум?
kozlyuk
29.07.2025 17:32По статье не видно, чтобы в МФ были какие-то принципиально лучшие средства защиты информации. Вы сами пишете, что в Windows есть API для доступа к системной аутентификации и авторизации, там есть такой же системный журнал событий. В Linux есть единый API для аутентфикации PAM (=pluggable authentication modules), единая точка автризации LSM (local security module) с популярной реализацией SELinux (где на процессы и объекты вещаются "метки", как в RACF). Сейчас в Linux есть еще LSM eBPF hooks, чтобы администратор мог сделать произвольную логику контроля доступа. И в Windows, и в Linux пользователям для сервисов запрещают вход в систему. Проблема не в том, что механизмов нет, а в том, что ими не пользуются. На то разные причины, главными я бы назвал две: 1) контроль доступа нужен не к системным объектам для защиты их целостности, а к бизнес-сущностям для защиты их
доступностиконфиденциальности; 2) гораздо проще наколхозить управление доступом в одном приложении, чем возиться с администрированием в нескольких местах, и, главное, несколькими людьми. Возможно, МФ применяются там, где требование сделать по гайдлайнам платформы возможно форсировать административно — ну, круто. Кстати, мы тут много ругаем Astra Linux и, разумеется, за дело (с), но там движение в эту правильную сторону есть.zVlad909 Автор
29.07.2025 17:32Спасибо за толковуюреакцию, первую пока. Общее замечание. Всякий раз как я когда либо рассказывал на форумах по теме статьи и другим темам, всегда находились люди сходу заявляющиеся то что заявляете и Вы. Но я всякий раз пытался и пытаюсь объяснять что это не совсем, а в большинстве случаях совсем не так. Интересный поинт еще в том что мои оппоненты как правило ничего не знают, никогда не работали с z/OS. Но и такие что работали тоже были моими оппонетами, оказывалось на уровне программиста Cobol, PL/I.
Начнем.
По статье не видно, чтобы в МФ были какие-то принципиально лучшие средства защиты информации. Вы сами пишете, что в Windows есть API для доступа к системной аутентификации и авторизации, там есть такой же системный журнал событий. В Linux есть единый API для аутентфикации PAM (=pluggable authentication modules), единая точка автризации LSM (local security module) с популярной реализацией SELinux (где на процессы и объекты вещаются "метки", как в RACF).
Я меньше всего имел целью статьи писать про аутентификацию. Авторизация же в z/OS это функция "менеджера ресурса" (например БД с данными пользователя), который обращается к SAF/RACF (это не API, а нечто другое, хотя по сути тоже вызов) с просьбой проверить имеет ли некий пользователь (в широком смысле слова, не тот что сидит перед дисплеем с клавиатурой) доступ к ресурсу, который он запросил, скажем, на запись (WRITE) и которым в принципе управляет менеджер ресурса. Так он запрограммирован спрашивать SAF/RACF. SAF, используя БД RACF, ищет в ней профиль ресурса и в листе доступа ищет идентификатор пользователя или имя группы, к которой пользователь присоединен, и если находит, так или иначе, проверяет какой именно доступ авторизован для этого пользователя или группы где он находится. Если доступ на уровне WRITE или выше, то SAF/RACF отвечает менеджеру ресурса Ок, если ниже или вообще нет в списке, отвечает не Ок. Менеджер ресурса продолжает работать с пользователем и предоставляет доступ или отказывает и тогда вся пользовательская программа завершается аварийно с диагностикой "не прошла авторизация".
Никаких "меток" ни на процессы ни на объекты (Я так понимаю ресурсы) RACF не вешает. Вся система авторизации существует и функционирут без воздействия на защищаемые ресурсы.
Можно и так сказать что в z/OS нет уровней авторизации за исключением трех: SPECIAL (это системный админ RACF, как правило этот уровень имеет один аккаунт, пароль которого выдается непосредственно для выполнения работ, под контролем двух-трех "начальников"), OPERATIONS (это кто имеет право делать бэкапы всего, как правило этот уровень имеет защищенный (NO-PASSWORD) аккаунт пакетными заданиями бэкапов запускаемыми поанировщиком заданий по графику), и AUDITOR (не имеет прав ни SPECIAL, ни OPERATIONS, но может анализировать базу RACF и события изменений базы RACF), все остальные это "пользователи" с тем или иным набором прав (в виде доступов), которые им даются для выполнения их обязанностей в системе. При создание "пользователя" у него нет никаких прав доступа ни к чему.
А вот в Windows и Linux есть administrator/root, которым доступно все, и пользователь, которому доступно только то что он сам создал в своей home directory или к чему ему админом/рутом было разрешено пользоваться через три байта доступа в файловой системе, которые может любой админ изменить и которые могут сами изменяться в некоторых случаях. И самим владельцем файла/фолдера может быть изменен доступ на 777 в любой момент.
В z/OS информация о доступе может изменяться только секьюрити администраторм, или делигироваться другим участникам администрирования ресурсов в определенных рамках. Как правило все делается, и не меняется, в процессе установки того или иного приложения. Информация о всех изменениях доступов, в том числе сделанные секьюрити админом, фиксируется в трассировке изменений и попадает в базу данных (DB2) для анализа и контроля (AUDITOR выше).
Ну а теперь мои вопросы:
Сейчас в Linux есть еще LSM eBPF hooks, чтобы администратор мог сделать произвольную логику контроля доступа.
Мог или немог не делать? Какие именно дает это (LSM eBPF hooks) возможности контроля доступа? Как это работает?
И в Windows, и в Linux пользователям для сервисов запрещают вход в систему.
Что это такое "пользователям для сервисов запрещают вход в систему."? Расшифруйте, пожалуйста.
Проблема не в том, что механизмов нет, а в том, что ими не пользуются.
Вот тут то и порылась собака. Вот это и есть, по минимуму, "принципиально лучшие средства защиты информации", которыми реально, повсеместно пользуются на МФ, а "у вас" не пользуются.
На то разные причины, главными я бы назвал две: 1) контроль доступа нужен не к системным объектам для защиты их целостности, а к бизнес-сущностям для защиты их доступности; 2) гораздо проще наколхозить управление доступом в одном приложении, чем возиться с администрированием в нескольких местах, и, главное, несколькими людьми.
Контроль доступа должен быть ко всему, и к системным ресурсам и к бизнес данным. В RACF нет раличий в том что защищается, это одинаково устроено и работает для всего.
-
Это совершенно не верное утверждение. Чем колхозить каждому приложеннию свое управление доступа, заранее обрекая на некачественную/глюкавую реализацию, гораздо разумнее со всех точек зрения использовать фрэймворк предоставляемый в данном случае RACF. Администрирование этим будет как раз то в одном месте и делаться будет не прикладником, а RACF администратором.
Представьте себе комплекс разномастных приложений с разномастными управлениями доступами, поддерживамые разными прикладниками. Это бардак. Это раздувание штатов и расходов на персонал ИТ.
Возможно, МФ применяются там, где требование сделать по гайдлайнам платформы возможно форсировать административно — ну, круто. Кстати, мы тут много ругаем Astra Linux и, разумеется, за дело (с), но там движение в эту правильную сторону есть.
МФ применяться могут везде где применяются нынешние ИТ на х86 для "обычных" бизнесов (необычные это поисковики Google, соцсети Facebook, торговые площадки (да и то бэкэнды для них очень даже хорошо ложаться на МФ), мессэнджеры), даже AI (ИИ) имеют поддержку на МФ начиная с z16.
Странная у вас логика однако "возможно форсировать административно". А что невозможность форсировать административно это хорошо? А хорошо когда в ИТ куча аналогов от разных вендоров и куча разных подходов этого зоопарка администрирования?
Да есть гайдлайны для безопасности. Они вполне нормальные и удобные для решения (программирования) этих мер. С итоге получаем унифицированные решения по контролю доступа, понятны е и прикладниками и администраторами. Вместо разнобоя, от которого открещиваются и админы и прикладники когда их заставляют сопровожлать очередной велосипед, имеем спокойную рабочую обстановку и время для решения других проблем. Их на самом дел еще много остается "у вас". И как раз на МФ в z/OS есть решения многим из них, а "у вас" тоже решаются кто на что горазд. Страдает бизнес-пользователь ИТ и пользователи бизнеса - пассажиры Аэрофлота, которые не смогли улететь.
kozlyuk
29.07.2025 17:32Спасибо за пояснение по работе SAF/RACF. Я пишу "объекты" в рамках того, что есть субъекты доступа (кто делает), объекты доступа (с чем делает) и операции доступа (что делает).
Administrator в Windows — обычный пользователь с заданными изначально широкими правами, на него распространяется действие ACL, и в целом, в Windows и в z/OS контроль доступа мандатный (MAC). В Linux базово дискреционный контроль доступа, он действительно скудный, но посредством LSM, обычно SELinux, добавляется MAC. Вот только все его отключают первым делом, если он по умолчанию включен.
Мог или немог не делать? Какие именно дает это (LSM eBPF hooks) возможности контроля доступа? Как это работает?
Можно написать программу (функцию), которую LSM будет вызывать после своих проверок, чтобы эта функция могла вынести свой вердикт, разрешена ли операция. Таким образом администратор может реализовать произвольную логику ограничения доступа, которая будет жестче системной. Работает через технологию eBPF, которая позволяет загружать код в пространство ядра с гарантиями, что стабильность ядра не пострадает.
Что это такое "пользователям для сервисов запрещают вход в систему."?
В Linux — прописывают /sbin/nologin в качестве login shell для учетной записи. От имени такой учетной записи можно запустить процесс (работая от имени другой), но нельзя выполнить вход в систему. Не помню точно, как это настраивается в Windows, но там службы работают от SYSTEM и других учетных записей, вход от имени которых невозможен.
Контроль доступа должен быть ко всему, и к системным ресурсам и к бизнес данным. В RACF нет раличий в том что защищается, это одинаково устроено и работает для всего.
[...] Администрирование этим будет как раз то в одном месте и делаться будет не прикладником, а RACF администратором.
Прикладной программой пользуется множество организаций, в организации по несколько сотрудников. Организации принадлежат объекты, которые её сотрудники могут создавать, а также совершать над ними разные операции. Сотрудники имеют разные права на определенные операции над всеми объектами определенного типа, принадлежащими организации сейчас или в будущем.
Как в RACF появляются записи о конкретных объектах (ресурсах), создаваемых в рамках программы?
Сотрудники должны обращаться к администратору RACF, который даже не в их организации, за любым изменением прав? Администратор RACF должен отслеживать, кто имеет право обращаться с запросами на изменение? Как администратор RACF поймет, что запрос на изменения легитимен в рамках бизнес-логики? Кто отвечает за результат?
А что невозможность форсировать административно это хорошо?
Возможность формировать административно — не техническая. Полагаю, в программе для МФ возможно реализовать контроль доступа без системных средств. Запретить это могут только люди. О чем я и толкую: дело не в железе или софте МФ, дело в том, было ли при разработке требование, что контроль доступа должен быть централизованным, а более широко — что надо изначально закладываться на безопасность. МФ не предлагает инструментов защиты информации, которых на x86 не было бы (либо вы о них не рассказали в статье). Что мир МФ предлагает, так это живое свидетельство, что сделать так, как описано выше, хотя бы в каких-то условиях возможно.
zVlad909 Автор
29.07.2025 17:32Спасибо за ответы. Пара замечаний если позволите.
обычный пользователь с заданными изначально широкими правами
Мне кажется или в этой фразе есть таки некоторое противоречие. Вообще то у меня есть мои аккаунты с прaвами sudo на Linux серверах.
на него распространяется действие ACL,
Как часто Вы сталкивались с использованием ACL. ACL это файлы (листы) в фолдерах. Их можно иметь, можно не иметь, их можно создавать, можно удалять. Это не имеет ничего общего с тем как работает (по-Вашему тоже самое) z/OS и RACF. И я это объяснял в статье. Вы статью мою читали?
Можно написать программу (функцию), которую LSM будет вызывать после своих проверок, чтобы эта функция могла вынести свой вердикт, разрешена ли операция. Таким образом администратор может реализовать произвольную логику ограничения доступа, которая будет жестче системной.
И ччто делать с этими программами написанными администратором? Таскать ее след ха сервером? А если забудут перетащить.
Вы очень теоретизированно рассуждаете. Практика она сложнее. Если системная логика может быть настроенна как требуется, то и никаких программ (функций) не надо. Тем более за ними нужен будет какой никакой уход.
С другой стороны если предлается такая возможность, то это означает что системная логика ограничена/ущербна и значит надо над ней работать еще. В системах на Windows и Linux очень много недоразвитых средств, с которыми очень проблематично работать. Я знаю о чем говорю. Ваше объяснение про /sbin/nologin хороший пример этому. Это кстати не запрещение, а отфутболивание пользователя у которого есть правильный пароль после того как он заходит, но в процессе выполнения логина выбрасывается. В z/OS и RACF у таких аккаунтов в принципе нет пароля. И никто их не выбрасывает таким примитивным способом, который легко отметить любому админу или sudo-шнику, которых как правило становится все больше и больше по мере жизни сервера и добавления на нем приложений.
Как в RACF появляются записи о конкретных объектах (ресурсах), создаваемых в рамках программы?
Сотрудники должны обращаться к администратору RACF, который даже не в их организации, за любым изменением прав? Администратор RACF должен отслеживать, кто имеет право обращаться с запросами на изменение? Как администратор RACF поймет, что запрос на изменения легитимен в рамках бизнес-логики? Кто отвечает за результат?
Очень просто появляются. Разработчик программы, вместе с программой поставляет набор команд RACF, в которых есть несколько переменных на усмотрение администратора пользователя, в основном по повуду наименований. После просмотра этих команд и изменения имен, они выполняются и все. Программа работает вечно, никаких изменений не требуется.
Почему администратор RACF должен быть обязательно не в их организации? А как сейчас в облаках дела делаются? Вот это точно что облачные админы не в "их организации". И что?
На самом деле никаких запросов на изменение доступа не поступает. Они изначально устанавливаются как надо и изменять не требуется. Все довольны. Маленький секрет может быть в том что доступ для больших коллетивов пользователей делается на уровне групп. Новые пользователи для конкретного приложения просто добавляются в нужную группу(-ы) при создании профайла пользователя и все. Делает это не RACF админ, а Help Desk. Запрос в Help Desk поступает из HR. Я всего лишь создаю инструкции для Help Desk и помогвю им когда у них что-нибудь не получается. Они не эксперты ведь.
Хочу Вас попросить об отдолжении, буду очень благодарен. Прекратите сообщать мне прописнве истины с интерпретацией на уровне Ваших знаний только про системы на х86. И не надо, пожалуйста, использовать обороты типа "в Windows и в z/OS". Это не корректно и не профессионально. Спасибо. Буду рад продолжить общение с Вами если Вы учтете мои просьбы. Отвечу на любые вопросы.
SmileyK
29.07.2025 17:32В вашей теории не хватает еще подхода к изменениям, т.е что бы что-то поменять, нужно запланировать изменения - миграцию, обеспечить обратную совместимость к примеру возьмем exchange - что бы заменить в большой компании безболезненно нужно много учесть всего - так может бахнем и начнем с нуля ?!
Тут больше догадок и пальцем в небо, нужно дать время стабилизировать текущую ситуацию командам, так как важно поставить на рельсы (крыло) операционную работу, дальше ребята будут разгребать и догонять до уровня который был. А лупить кнутом можно и дворника, а зачем ?!
Поздно пить Боржоми когда почки отказали….мы лишь можем созерцать текущее и делать выводы на опыте коллег по цеху …, что бы не наступить на такие же грабли…
zVlad909 Автор
29.07.2025 17:32В моей "теории" (это самая что не на есть практика на самом деле) есть место для переноса приложений Unix, практически простой компиляцией исходников компилятором МФ. С языка С, Java.
Есть в ней и место модным нынче контейнеризированым (тьфу, еле дописал, поди с ошибками) приложением, Докерная технология поддерживается в z/OS.
Есть место приложениях Enterprise Java beans, в WebSphere for z/OS.
DB2 for z/OS понравится и легко на нее перейдут программисты с Оракл и MS SQL, да и вообще в люьой другой RDMS.
Призом будет мощная, надежная, безопасная и устоичивая, компактная!!! система по цене меньше потерь Аэрофлота за один вчерашний день (пишу 29 июля). Да еще и можно сильно сэкономить на персонале, которого в случае МФ потребуется гораздо меньше чем на х86.
SmileyK
29.07.2025 17:32Есть решения, которые работали годами , есть решения под разные операционные системы …. Не бывает плохого языка программирования, не бывает плохой программы, вопрос в применение того или иного к текущим реалиям и требованиям, за модой не угнаться…. Я понимаю Вас, но есть много других факторов… это как разные повара по разному готовят одно и тоже блюдо
PerroSalchicha
29.07.2025 17:32все что может быть использовано для неправомерной деятельности, или несанкционированного доступа к информации) при появлении запроса от кого или чего-либо обращается к SAF для проверки легитимности поступившего запроса. Ключевое слово КАЖДОГО.
Даже в связке Windows / SQL Server происходит всё примерно так же. Задача в том, чтобы эта самая проверка легитимности была настроена.
Это весьма краткое введение в состояние компьютерной безопасности z/OS.
Это всё здорово, но ИТ-инфраструктура компании, это нечто намного большее, чем один навороченный мейнфрейм на z/OS. Ваша z/OS не роутит трафик внутри компании, не содержит корпоративную файлопомойку, не хостит почтовые сервера, не хостит веб-сайты, не хостит файрвол, и ещё много чего не хостит, и не будет.
zVlad909 Автор
29.07.2025 17:32Это всё здорово, но ИТ-инфраструктура компании, это нечто намного большее, чем один навороченный мейнфрейм на z/OS. Ваша z/OS не роутит трафик внутри компании, не содержит корпоративную файлопомойку, не хостит почтовые сервера, не хостит веб-сайты, не хостит файрвол, и ещё много чего не хостит, и не будет.
Ну как же все таки странно устроены люди в России что когда чего то не знают думают об этом только плохо. Меняться надо, соотечественники.
Во-первых, почему один? Но даже один МФ может в разных партициях выполнять много z/OS и одновременно Linux и zVM (витруальные машины). На МФ можно сделать кластер Sysplex называется, до 32 узлов, работающих как одно целое. Не так как кластер где согласование идет по сети во всеми вытекающими.
Может и файлопомойку иметь (Samba, NFS) пожалуйста. Имеется почтовый сервер SMTP. но я за то чтобы для этого использовался Exchaтge. Тем не менее я получаю почту с МФ от моих программ, хотя наш МФ и не ведет корпоративную почту.
Веб-сайты, да ради бога, с начала века на МФ в z/OS есть WebSphere, прекрасный движок для разных веб приложений и Enterprise Java Beans. См. приложение ниже.
z/OS готов хостить весь программный стак TCP/IP приложений. Файрвол (IPSec), DNS server, FTP server, IDS, что еще Вас интереует? RACF может выполнять функции AD.
Сетевая карта МФ (у нашего супер маленького МФ их 4 штуки с двумя портами каждая) т.н. OSA card (почитайте на досуге) это раутер по сути. МФ можно спокойно вывести в паблик сеть и это нисколько не опасно. Без всяких CISCO раутеров.
Если учесть что на МФ может одновременно выполняться тысячи виртуальных машин и ОС в партициях, то в целом МФ это полнофункциональный дата центр со всеми присущими функциями. Мощность может регулироваться в огромном даипазоне.
IBM WebSphere — это бренд корпоративного программного обеспечения, в частности, промежуточного программного обеспечения для приложений и интеграции, используемого для создания и интеграции приложений. Он предоставляет платформу для разработки, развертывания и управления веб-приложениями и микросервисами на базе Java, особенно в контексте Java EE и Enterprise OSGi. WebSphere известен своей масштабируемостью, функциями безопасности и поддержкой различных сред развертывания, включая локальные и облачные.
и ещё много чего не хостит, и не будет.
Если Вы прочитали все выше возьмите эти Ваши слова обратно и не смешите людей. Всего Вам самого наилучшего. А особенно любознательности. Она спасает от позора невежества.
PerroSalchicha
29.07.2025 17:32Если Вы прочитали все выше возьмите эти Ваши слова обратно и не смешите людей. Всего Вам самого наилучшего. А особенно любознательности. Она спасает от позора невежества.
Извините, но дело в том, что я работал в компаниях, использующих пусть не z/OS, но iSeries. Поэтому нет, я как раз прекрасно знаю, о чём я говорю.
Во-первых, да, вы правы, мейнфрейм - штука гибкая и многофункциональная. Но слишком дорогая для утилитарных вещей. Файлопомойка и почта на нём, это примерно как золотой унитаз. Работает, но стоимость не оправдывает назначение.
Во-вторых, что касается управления трафиком в компании, так на мейнфрейме это в принципе организовать невозможно, хоть сто виртуальных хостов там подними. Потому что у вас сетевых карт 4 штуки с двумя портами, а в офисе тысячи точек подключения и несколько внешних каналов, и филиалы. Поэтому будут у вас стоять те самые циски, а может, и не циски, везде, со всеми вытекающими..
Во-третьих, все эти виртуальные машины на линуксах, это машины на линуксах. Со всеми их известными и неизвестными уязвимостями.
Поэтому не надо бросаться громкими словами. Просто вы полюбили один инструмент, и в упор не хотите видеть естественных рамок его применения. Ах, какой у меня классный микроскоп, я могу и амёбу рассмотреть, и костёр от Солнца разжечь, и гвоздь забить.
zVlad909 Автор
29.07.2025 17:32Извините, но дело в том, что я работал в компаниях, использующих пусть не z/OS, но iSeries. Поэтому нет, я как раз прекрасно знаю, о чём я говорю.
z/OS это zSeries, или просто Z. Это настолько разные вещи что зная всё про iSeries вы можете не знать ничего про z/OS и zSeries. И это нормально.
Но слишком дорогая для утилитарных вещей. Файлопомойка и почта на нём, это примерно как золотой унитаз. Работает, но стоимость не оправдывает назначение.
К этому никто и не призывает. Пусть файлопомойка будет на х86 серверах, которые даже если никто к этим помойкам не обращается и они простаивают все таки достаточно дешевы чтобы без напряга списывать потери на них в прочие расходы.
МФ используется на 100% и оправдывает каждый доллар.
Кстати только согласился с Вами и поняд что и тут Вы неправы. Даже при 100% загруженности на МФ остаются не использованые циклы для малоприоритетных работ, которые могут выполняться практически бесплатно, на неиспользованных приоритетными работами остатках.
Почта это другое, пусть она будет на Exchange.
что касается управления трафиком в компании, так на мейнфрейме это в принципе организовать невозможно, хоть сто виртуальных хостов там подними. Потому что у вас сетевых карт 4 штуки с двумя портами, а в офисе тысячи точек подключения и несколько внешних каналов, и филиалы. Поэтому будут у вас стоять те самые циски, а может, и не циски, везде, со всеми вытекающими..
Принципиально не верное понимание. 4 штуки с двумя портами это на самом мааааленьком из возможных МФ. Но дело даже не в этом. Ваши тысячи точек подключения это в том числе сервера, которые будут в случае МФ все на нем и общаться между собой по внутренней сети МФ (HyperSocket, memory based protocol), или в виртуальной сети zVM. WiFi, с которым МФ очень даже дружит, решение для лаптопов и других рабочих станций. Кроме того можно подключить МФ к интернету, толстым каналом, и все тысячи точек завести через VPN (Вы конечно удивитесь, но на МФ и VPN есть) в один порт, ну пусть два, ну сколько Вам надо, столько и будет.
Если кто-то любит медь в наши дни, то да понадобятся свитчи, как концентраторы и переключатели.
все эти виртуальные машины на линуксах, это машины на линуксах. Со всеми их известными и неизвестными уязвимостями.
Я отнюдь не ратую за Линукс. Но если в этом камень преткновения, то это возможно на МФ. МФ сам по себе и виртуальные машины под zVM многие эти уязвимости нивелируют, купируют и отменяют.
Поэтому не надо бросаться громкими словами. Надо изучать матчасть и знать. А не гадать на кофейной гуще. Я серьезно желаю Вам во всем разобраться и готов помочь.
PerroSalchicha
29.07.2025 17:32Кстати только согласился с Вами и поняд что и тут Вы неправы. Даже при 100% загруженности на МФ остаются не использованые циклы для малоприоритетных работ
Файловые хранилища, это не про процессор, это про дисковое пространство и каналы ввода-вывода.
Принципиально не верное понимание. 4 штуки с двумя портами это на самом мааааленьком из возможных МФ
Ну сколько их там будет? 64 штуки? И что это поменяет?
Если кто-то любит медь в наши дни, то да понадобятся свитчи, как концентраторы и переключатели.
Ну так, минуточку, 100% пользователей мейнфремов любят медь в наши дни. Это бизнес размером с рекламное или там туристическое агентство может обойтись вайфаем. А крупный бизнес, это не только кучка серверов в комнате, а везде ноуты и планшеты. Элементы СКУД, камеры, производительные МФУ, рабочие станции - всё это до сих пор соединяется медью. Да и даже для ноутов и планшетов, точки доступа вайфая у вас в крупном офисе отнюдь не через mesh будут соединены, а по-старинке, медью.
виртуальные машины под zVM многие эти уязвимости нивелируют, купируют и отменяют.
Ваш рабочий софт-то вы где возьмёте под zVM?
zVlad909 Автор
29.07.2025 17:32Файловые хранилища, это не про процессор, это про дисковое пространство и каналы ввода-вывода.
Тем более, ввод-вывод на МФ всегда имеется с излишком относительно мощности центрального процессора.
Ну сколько их там будет? 64 штуки? И что это поменяет?
А что Вы ожидается чтобы поменялось? 128 портов? Или 256?
Ну так, минуточку, 100% пользователей мейнфремов любят медь в наши дни.
Это вы про меня? Я сижу дома, работаю с МФ через интернет. Если, как я намекал, подключить МФ к интернету, хотя бы одним портом, то с МФ можно будет работать многим пользователям как бы они ни были подключены к интернету.
Ваш рабочий софт-то вы где возьмёте под zVM?
Какой мой рабочий софт Вы имеете в виду? Мой рабочий софт для работы с МФ это эмулятор 3270.
Antra
29.07.2025 17:32Я сижу дома, работаю с МФ через интернет.
Кстати, как именно? Это МФ одним портом торчит прямо в Интернет с публичным адресом?
Насколько я понял, нет. Если действительно нет, то почему?
PerroSalchicha
29.07.2025 17:32Тем более, ввод-вывод на МФ всегда имеется с излишком относительно мощности центрального процессора.
И дисковое пространство, что ли? По какой цене за терабайт?
А что Вы ожидается чтобы поменялось? 128 портов? Или 256?
Ну, например, 2048 портов, доступных по всему зданию. Это средних размеров офис, этажей пять.
Это вы про меня?
Нет, про вашу компанию в целом. Сидеть дома с удалённым терминалом, это было доступно и четверть века назад, когда это не было мейнстримом, и даже полвека назад. Но у вас наверняка кроме горстки ИТ-шников, есть целая армия пользователей, которым такая роскошь не доступна.
Какой мой рабочий софт Вы имеете в виду?
О, самый разный. Вы можете, например, в терминале 3270 набрать и отправить служебную записку? А хотя бы мессенджер у вас там есть? И это вы, человек, работа которого непосредственно вокруг мейнфрейма вертится. А что говорить про других пользователей, которые занимаются продажами, рекламой, логистикой и так далее.
PereslavlFoto
29.07.2025 17:32... скажет через губу " Моя программа требует системный доступ." ...
Как это решают на мейнфреймах? Поставщик требует системного доступа для своей программы, работа уже оплачена, другого поставщика нет. Что же делать?
zVlad909 Автор
29.07.2025 17:32На МФ "поставщики" знают что системного доступа у них не будет, Поэтому пишут программы с учетом этого. Конечно никто не запрещает им сформулировать более адекватные требования и они безусловно будут удовлетворенны. В z/OS поставщик может даже встроить свою "подсистему", т.е. нечто выполняющееся на уровне полномочий ядра. В пользовательской программе, под контролем, можно даже перейти в состояние супервизор. У меня есть такие программы, самописные. Но все это под контролем и дозированно делается по реальной необходимости. А не чёхом. И при этом не появятся дырки через которые смогут залезать хакеры. Все довольны.
PerroSalchicha
29.07.2025 17:32На МФ "поставщики" знают что системного доступа у них не будет,
Ну так на Windows/Linux тоже, все программы, кроме собственно системных, работают с ограниченными привилегиями. Только дремучее легаси требует повышенных привилегий. Хакеры пролезают не потому, что какая-то программа вот вообще никак не хочет работать не от системного пользователя. Основные векторы атак - это ошибки в распространённых библиотеках. OpenSSL вон года три с уязвимостью нулевого дня сидела, а сколько такого ещё не выявлено?
z/OS здесь безопаснее не потому, что в ней там нет уязвимостей, а потому, что их некому искать. Установленная база машин невелика, круг имеющих доступ к ним также невелик, круг имеющих доступ, квалификацию, время и желание искать уязвимости примерно равен нулю.
zVlad909 Автор
29.07.2025 17:32z/OS здесь безопаснее не потому, что в ней там нет уязвимостей, а потому, что их некому искать. Установленная база машин невелика, круг имеющих доступ к ним также невелик, круг имеющих доступ, квалификацию, время и желание искать уязвимости примерно равен нулю.
Вот что отвечает Гугловский ИИ на простой как правда вопрос: Who is using IBM mainframes? Обратите внимание на упоминание American Airlines ниже. Очень актуально для этой моей статьи, не так ли?
IBM mainframes are primarily used by large organizations in industries that require massive transaction processing and data management, such as banking, insurance, and government. Two-thirds of Fortune 500 companies, 45 of the top 50 banks, and 8 of the top 10 insurers rely on IBM mainframes.
Here's a more detailed look at who uses IBM mainframes:
-
Financial Institutions:
Banks, insurance companies, and financial service providers rely heavily on mainframes for processing high volumes of transactions, managing customer data, and ensuring secure and reliable operations. For example, 44 of the top 50 banks globally use IBM Z mainframes.
-
Government Agencies:
Many government entities utilize mainframes for critical functions like managing public services, processing tax information, and handling large datasets for census and other statistical purposes.
-
Healthcare:
Healthcare organizations use mainframes to manage patient records, process insurance claims, and ensure data security and compliance.
-
Retail:
Large retailers use mainframes for inventory management, point-of-sale processing, and supply chain management.
-
Airlines and Transportation:
Companies like American Airlines have historically used mainframes for reservation systems (like the SABRE system) and continue to rely on them for various operational tasks.
-
Telecommunications:
Major telecommunications companies use mainframes for network management, billing systems, and customer relationship management.
-
Other Industries:
Mainframes are also used in various other sectors, including utilities, manufacturing, and scientific research, wherever large-scale data processing is essential.
The Relevance of Mainframe in 2022 - Planet Mainframe Why do they use them? Mainframes are chosen for their reliability, security, scalability, and ability to handle massive workloads. They are designed to run 24/7 with minimal downtime, making them crucial for businesses that require constant availability and high transaction throughput.
-
HardWrMan
29.07.2025 17:32Автор так упорно указывает, что именно на x86 одни проблемы с безопасностью, что создаётся впечатление, что это проблема самого x86 а не софта на нём. Следует ли при этом понимать, что на IA64 или ARM всё круто и безопасно? Вопрос риторический.
M_AJ
29.07.2025 17:32создаётся впечатление, что это проблема самого x86 а не софта на нём
У x86 и вообще любой фон-неймановской машины действительно есть фундаментальная проблема безопасности — единая память для команд и данных. Из-за этого на них так опасно переполнение стека. Теоретически это можно было исправить, если бы процессор на уровне декодера инструкций выполнял только команды подписанные определёнными ключами, но увы это вероятно негативно сказалось бы на производительности, и (что возможно ещё хуже) программы для машины было бы невозможно собрать на этой же самой машине.
HardWrMan
29.07.2025 17:32У современных х86 уже достаточно методов защиты памяти (это по сравнению с базовым i386). Просто отучите компиляторы организовывать фрейм данных в стеке. Раньше это было оправдано, сейчас же организовать кучу отдельно от кода вполне реально. Тем более всё равно сам код к данным получает доступ через соответствующие сегментные регистры. Опять же, у х86 есть как CS так и SS, но вот такое поведение сразу нивелирует всю задумку инженеров:
VVitaly
29.07.2025 17:32:-) А что у нас с Oracle под zOS? Концепция уже сменилась? Или м.б. Oracle не та компания которой нужны крупные корпоративные клиенты и у них недостаток ресурсов для портирования новых версий?
DB2 - это возможно и хорошо (учитывая что Oracle использовал ее концепции), но... Когда то давно (в начале 2000-х) к нам обратились IBM спецы и заявили что "на раз-два" портируют на неё терминал-сервер приложение написанное под Oracle, и получили наши исходники на PL/SQL. Где то через пол года получили от них информацию - "ну не шмогла я...".
Сама z-System (правда работал я со старой z10 и под AIX где Oracle тогда был) штука крутая, но...
Была задача как справятся (на реальных тестах прикладного приложения 24/7 и под большой нагрузкой) разные виртуальные системы, в частности SPARC, z и p IBM (все при базе Oracle) с масштабированием количества выделенных для OS(Solaris, AIX)/DB vCPU - уж очень это интересовало наших клиентов. Результаты были "интересные" - только p-System под AIX без "заморозки" всех процессов БД в OS на несколько (2-5) секунд это смогла...
persona
29.07.2025 17:32А как обычный программист или дизайнер с макбуком подключается к этому маинфрейму?
gun_dose
29.07.2025 17:32Очень опасное заблуждение думать, что можно позвать каких-то там безопасников, они тебе всё настроят, и будет безопасность. На уровне приложения тоже есть уязвимости. Да, безопасники запрут твоё приложение в песочницу, откуда оно не сможет навредить другим частям системы, но оно по-прежнему может оставаться уязвимым, может быть выведено из строя и т.д. И я что-то очень сомневаюсь, что крутые ребята с сертификатами Cisco или Госуслуг, или даже ребята в погонах в состоянии провести корректный аудит, к примеру, имеет ли эндпоинт какого-нибудь сканера QR-кодов защиту от SQL-инъекций, и если имеет, то является ли она надёжной. Что-то мне подсказывает, что нормальный специалист, способный выполнить эту задачу, стоит значительно дороже, чем кладовщик из Пятёрочки.
Shaman_RSHU
29.07.2025 17:32Для чего все эти выкладки про IBM, z/OS, DB2... Аэрофлот, кажется российская компания и подпадает под требования импортозамещения.
А что у нас из российского хотя бы на 10% покрывает функциональность средств описанных в статье? Ничего, т.к. в основном все направлено не на безопасность, а на зарабатывание денег. Не одна российская компания- разработчик не может себе позволить разрабатывать свои средства ради безопасности. Нужно сначала соответствовать бесконечным бумажкам бесчисленных регуляторов.
В той же AstraLinux сколько всего механизмов безопасности накручено, но все равно до IBM очень далеко.
M_AJ
Допустим, но ваше утверждение, что
вообще не подкреплено ни одним аргументом, даже не очень убедительным.
zVlad909 Автор
А каким агрументом(-ами) это в принципе могло бы быть подтверждено?
Это утверждение сделано в предположении что Аэрофлот ИТ имеет элементарные защитные механизмы, которые бы исключили вторжение хакеров.
Пароль пусть даже гендиректора совершенно не достаточен для уничтожения 7000 серверов, уничтожения баз данных, и скачивания 22 TB данных.
В СМИ вчера проскакивала новость что даже офис был обесточен, с предположением чтобы не дать злоумышленникам продолжать их деятельность. Злоумышленников в офисе?
greenlittlefrog
Украинские хакеры такие суровые, что уничтожают данные по фото
zVlad909 Автор
И меняют пароли по принтскрин AD.
PerroSalchicha
Элементарные (и даже не элементарные) защитные механизмы не исключают вторжение хакеров, а усложняют. Это другое (с). В инфраструктуре крупной компании всегда найдётся тысячи точек входа, и среди них что-то да имеет уязвимости.
zVlad909 Автор
В случае хотя бы ядра ИТ (центральная база данных DB2 for z/OS и сервера приложений на WebSphere (Enterprise Java Beans), добавьте если надо z/OS Container Extensions (Dockers) (cм. ниже приложение), количество уязвимых точек входа резко устремится к нулю. Размер компании не ограничен.
Приложение:
PerroSalchicha
А вы этот вопрос изучали, или выдаёте желаемое за действительное?
Потому что вон последнюю критикал уязвимость в WAS нашли месяц назад.
Причём более чем противную, удалённое исполнение кода через десериализатор, путём отправки пакета специально подобранной структуры.
zVlad909 Автор
WAS это юниксовское приложение, выполняющееся в z/OS в Unix System Services (USS). Кодовая база одинаковая с AIX, HP-UX, IBM i, Linux, Solaris, Windows, z/OS.
Иначе говоря каков поп таков и приход.
Я работал с WebSphere c начала этого века, когда он был построен как классическое MVS приложение. Летал как сокол. Отвечал всем стандартам z/OS.
Был на ИБМ-ских курсах, знал его как свои пять пальцев, но это был еще не WAS, Java не было, просто веб сервер с нттр.
Потом появилась WebSphere version 4. Java. Производительность рухнула на дно. Что-то делали, но с трудои и немного на этой версии 4. Кстати Application Server это Apache, Tomcat. Пропустил пару версий, продолжил с версией 6, ИБМ переписал Java виртуальную машину, пошло побыстрее. ИБМ сделал много улучшений в ибмовском стиле и WebSphere перестал быть Tomcat-ом и стал нормальным продуктом, почти МФ-ского класса. На все таки это Юникс.
Работал с верисиями 7 и 8, сейчас еще есть у меня на МФ сервера под версией 7, и 8.5. 8.5 установлен был в марте 2013 года. Хоть сейчас запускай будут работать, не использовались ни разу, хотя я устанавливал нужные компании приложения и приглашал их протестировать.
Все было готово, настроено, работало. Но кто-то в верхах решил, нет мы будем ранить WAS не на МФ в z/OS, а на IBM RISC в AIX. Хотя база данных все равно оставалась на МФ и лучшим местом для WAS был тоже МФ, потому что исключал сеть и вообще. Кстати на установку WAS на AIX ушло еще полгода после того как я закончил эту работу на МФ, были приглашены ИБМ-ские специалисты, которым полатили ломовые деньги (на МФ я это сделал без чьей либо помощи).
А что мог я, иммигрант, сделать? Ничего. Да и хрен с ними, тупыми канадолами. Дело конечно не в том что я иммигрант. Еще лет 5 перед этими событиями из каждого утюга звучало что с МФ мы не уйдем никогда, у нас важная для провинции индустрия. Заплатили ИБМ за WebSphere $CA400 000 с саппортом и обновлениями до морковкиного заговления. Сейчас мог бы даунлоад WAS 9.5 и установить, но... поезд уже прибывает во Владивосток. Полляма на помойке.
PerroSalchicha
До сих пор там под капотом Томкэт, что ли? Он же там двадцать лет назад был. И не могу сказать, что это плюс.
Нууу, я тоже был на ИБМ-ских курсах по нему, в их учебке в Институте космических исследований в середине нулевых. Раз на раз не приходится, конечно, но в моём случае это был самый халтурный курс из всех, на которых я когда-то был и до этого, и после. Лектор вообще ничего не знала про WAS/ESB, и просто уныло зачитывала документацию.
zVlad909 Автор
Что там под капотом я сказать не могу, давно этого не казсался. Но думаю что по крайней мере это существенно переработано ИБМ. Management Console это вообще чисто ИБМ-ский продукт.
M_AJ
Не знаю, но приводить утверждения, которые невозможно подтвердить аргументами это такое себе.
Быть во внутренней сети офиса это всё равно что быть в офисе. Выключение света это способ защитить то что еще уцелело, или помешать хакерам окончательно замести следы. Дальше с дисков будут сняты дампы, которые будут анализировать, пытаясь найти через какую дыру пролезли и какую инфраструктуру при этом использовали. Потом её обычно пытается ломать противоположная сторона, чтобы затруднить группировке дальнейшую работу, или установить личности атакующих.
p.s. Если злоумышленники и были когда либо в офисе физически, то самое глупое что они могли сделать, это оставаться там в момент когда инфраструктуру стали громить.
SpiderEkb
Да. Но центральный сервер может быть сильно изолирован от внешнего мира. Доступ к нему только из внутренней сети. Причем, доступ авторизованый, в регулярной сменой паролей. Это для тестов.
Доступ к проду еще более ограничен. Даже из внутренней сети.
Доступ к данным на проде - только через очереди или WS в режиме конкретных ответов на конкретные запросы. Прямой доступ имеет только служба сопровождения (несколько десятков человек). Доступ с админскими правами - вообще у нескольких человек.
Плюс система автоматически журналирует все действия по изменению объектов - кто, что, когда. Плюс джоблоги. Все это системное, неотключаемое.
HardWrMan
Я уже видел такое в кино, правда без сети, даже внутренней.
SpiderEkb
Я это каждый день вижу. Доступ к тестовому серверу только из внутренней сети (т.е. даже через VPN корпоративный нет, только с компа в офисе или с виртуального рабочего места через VDI). К проду реальный доступ у нескольких десятков человек (при том, что IT подразделение порядка 5т человек) - дежурная смена сопровождения + несколько человек с административными правами. У остальных - только возможность посылать конкретные запросы и получать ответы в рамках своих должностных обязанностей.
У разработчиков и аналитиков доступа к прому нет. Только к тесту, да и то там все по ролям расписано (уровни доступа). И многие команды заблокированы. И на доступ к конкретному юниту на тесте нужно права получать с обоснованием зачем.
И все пароли меняются не реже чем раз в три месяца. И не менее 12 символов "3 группы из 4-х". И три неправильных попытки - блокировка профайла с разблокировкой по отдельной заявке.
Aggle
А про 7000 серверов, БД и 22 ТБ информация откуда? От самих кулцхакеров? "Так и Вы говорите". (ц)
zVlad909 Автор
Я вообще не верю в то что это сделали хакеры. Поэтому и написал так. В чем проблема?
PerroSalchicha
Это уже теория заговора, и необоснованная, и не особо логичная. Тем и не нравится.
zVlad909 Автор
А логичнее получается что это сделали хакеры? Правильно я Вас понимаю?
M_AJ
Да, логичнее и вероятнее. Это как бы не первый, мягко говоря, случай взлома в истории, и большинство аналогичных взломов произошли без злого умысла сотрудников. В общем, по меткому выражению приписываемому Виктору Пелевину, миром правит не тайная лоха, а явная лажа.
PerroSalchicha
Да, естественно. Что вас смущает в возможности взлома старой (со всеми вытекающими) широко известной, но при этом ранее не пуганной авиакомпании, которая к тому же нанимает бюджетных ИТ-специалистов?
Aggle
Просто интересен источник информации. Что-то похожее распространяли сами хакеры, от "Аэрофлота" я такой информации не видел. Ну и раз уж так - а внутри могли грохнуть всё вышеупомянутое?
zVlad909 Автор
Грохнули или не грохнули и что именно грохнули пока не известно. От Аэрофлота и будет скорее всего ничего внятного. Это корпоративная, больше чем причины крушения самолетов.
Если есть доступ то не важно изнутри или снаружи. Мне не понятно как можно было не обратить внимания на перекачку 20 TB наружу. Может это сделали локально на диск и вынесли диском?
Aggle
Для начала непонятно существовали ли эта перекачка и, если таковая была, было ли это 20 Тб? Вы правы, такое не заметить сложно, даже если там подпольный сервак с раздачей прона наружу стоит.
Antra
20 TB за год при том, что в недавнем посте обсуждалось, как Ростелеком урезал полосу пропускания домашнему пользователю, выкачавшему 6TB за две недели?
SpiderEkb
Ну среди диванных экспертов есть такое мнение:
Konstantin_ivanov
Ну по факту ничего этого не было, Аэрофлот восстановил работу в течении суток, что подтверждает что заявления хакеров не более чем пшик.