Comments 174
Да есть ссылка по которой хакеры делятся деталями своего "подвига". Но это не убедительно. Эти "аргументы" может каждый создать. Принт скрины это не доказательства.
Допустим, но ваше утверждение, что
был(и) задействованы внутренние ресурсы. ИТ-шники Аэрофлота, или внешние подрядчики оказывающие услуги ИТ.
вообще не подкреплено ни одним аргументом, даже не очень убедительным.
...вообще не подкреплено ни одним аргументом, даже не очень убедительным.
А каким агрументом(-ами) это в принципе могло бы быть подтверждено?
Это утверждение сделано в предположении что Аэрофлот ИТ имеет элементарные защитные механизмы, которые бы исключили вторжение хакеров.
Пароль пусть даже гендиректора совершенно не достаточен для уничтожения 7000 серверов, уничтожения баз данных, и скачивания 22 TB данных.
В СМИ вчера проскакивала новость что даже офис был обесточен, с предположением чтобы не дать злоумышленникам продолжать их деятельность. Злоумышленников в офисе?
Украинские хакеры такие суровые, что уничтожают данные по фото
Это утверждение сделано в предположении что Аэрофлот ИТ имеет элементарные защитные механизмы, которые бы исключили вторжение хакеров.
Элементарные (и даже не элементарные) защитные механизмы не исключают вторжение хакеров, а усложняют. Это другое (с). В инфраструктуре крупной компании всегда найдётся тысячи точек входа, и среди них что-то да имеет уязвимости.
В случае хотя бы ядра ИТ (центральная база данных DB2 for z/OS и сервера приложений на WebSphere (Enterprise Java Beans), добавьте если надо z/OS Container Extensions (Dockers) (cм. ниже приложение), количество уязвимых точек входа резко устремится к нулю. Размер компании не ограничен.
Приложение:
Чем zCX похож на Linux и чем отличается от него? (Последнее обновление: 02.06.2021)
IBM zCX — это виртуальное программное решение Docker, включающее все необходимые программные компоненты, позволяющие пользователю развертывать и управлять Linux на образах Docker Z (архитектуры s390x) в z/OS. Это программное решение включает коммерческое ядро Linux, поддерживаемое и обслуживаемое IBM, и предоставляет интерфейс командной строки (CLI) Docker для реализации полнофункциональной среды Docker. Пользователи входят в экземпляр zCX через Secure Shell (SSH) и работают в оболочке Bash, как на любой другой платформе Linux. Эта среда Linux разработана для поддержки Docker CLI и не предназначена для использования в качестве универсальной операционной среды. Пользователям запрещено выполнять большинство операций с правами root, поэтому ядро остаётся правильно настроенным для работы Docker. Если пользователям нужна полнофункциональная среда Linux, им следует создать образ Docker с любым необходимым дистрибутивом Linux и запустить его через Docker CLI.
В случае хотя бы ядра ИТ (центральная база данных DB2 for z/OS и сервера приложений на WebSphere (Enterprise Java Beans), добавьте если надо z/OS Container Extensions (Dockers) (cм. ниже приложение), количество уязвимых точек входа резко устремится к нулю.
А вы этот вопрос изучали, или выдаёте желаемое за действительное?
Потому что вон последнюю критикал уязвимость в WAS нашли месяц назад.
Причём более чем противную, удалённое исполнение кода через десериализатор, путём отправки пакета специально подобранной структуры.
Потому что вон последнюю критикал уязвимость в WAS нашли месяц назад.
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 и установить, но... поезд уже прибывает во Владивосток. Полляма на помойке.
Потом появилась WebSphere version 4. Java. Производительность рухнула на дно. Что-то делали, но с трудои и немного на этой версии 4. Кстати Application Server это Apache, Tomcat.
До сих пор там под капотом Томкэт, что ли? Он же там двадцать лет назад был. И не могу сказать, что это плюс.
Был на ИБМ-ских курсах
Нууу, я тоже был на ИБМ-ских курсах по нему, в их учебке в Институте космических исследований в середине нулевых. Раз на раз не приходится, конечно, но в моём случае это был самый халтурный курс из всех, на которых я когда-то был и до этого, и после. Лектор вообще ничего не знала про WAS/ESB, и просто уныло зачитывала документацию.
До сих пор там под капотом Томкэт, что ли? Он же там двадцать лет назад был. И не могу сказать, что это плюс.
Что там под капотом я сказать не могу, давно этого не казсался. Но думаю что по крайней мере это существенно переработано ИБМ. Management Console это вообще чисто ИБМ-ский продукт.
Могу засвидетельствовать, что там чистый нетронутый Tomcat. A Management Console это всего лишь ещё одна аппликация, написанная на Java ( и JSP). Там нет ничего специального для Z.
Java на Z своя IBM-овская. А то, что написано на Java - ничем не отличается ни на Windows, ни на Linux, ни на Z. Вот она, переносимость!
С ним лучше не спорить, он курсы IBM прочитал — опасный короче))
А каким агрументом(-ами) это в принципе могло бы быть подтверждено?
Не знаю, но приводить утверждения, которые невозможно подтвердить аргументами это такое себе.
Злоумышленников в офисе?
Быть во внутренней сети офиса это всё равно что быть в офисе. Выключение света это способ защитить то что еще уцелело, или помешать хакерам окончательно замести следы. Дальше с дисков будут сняты дампы, которые будут анализировать, пытаясь найти через какую дыру пролезли и какую инфраструктуру при этом использовали. Потом её обычно пытается ломать противоположная сторона, чтобы затруднить группировке дальнейшую работу, или установить личности атакующих.
p.s. Если злоумышленники и были когда либо в офисе физически, то самое глупое что они могли сделать, это оставаться там в момент когда инфраструктуру стали громить.
Быть во внутренней сети офиса это всё равно что быть в офисе.
Да. Но центральный сервер может быть сильно изолирован от внешнего мира. Доступ к нему только из внутренней сети. Причем, доступ авторизованый, в регулярной сменой паролей. Это для тестов.
Доступ к проду еще более ограничен. Даже из внутренней сети.
Доступ к данным на проде - только через очереди или WS в режиме конкретных ответов на конкретные запросы. Прямой доступ имеет только служба сопровождения (несколько десятков человек). Доступ с админскими правами - вообще у нескольких человек.
Плюс система автоматически журналирует все действия по изменению объектов - кто, что, когда. Плюс джоблоги. Все это системное, неотключаемое.
Но центральный сервер может быть сильно изолирован от внешнего мира. Доступ к нему только из внутренней сети.
Я уже видел такое в кино, правда без сети, даже внутренней.
Я это каждый день вижу. Доступ к тестовому серверу только из внутренней сети (т.е. даже через VPN корпоративный нет, только с компа в офисе или с виртуального рабочего места через VDI). К проду реальный доступ у нескольких десятков человек (при том, что IT подразделение порядка 5т человек) - дежурная смена сопровождения + несколько человек с административными правами. У остальных - только возможность посылать конкретные запросы и получать ответы в рамках своих должностных обязанностей.
У разработчиков и аналитиков доступа к прому нет. Только к тесту, да и то там все по ролям расписано (уровни доступа). И многие команды заблокированы. И на доступ к конкретному юниту на тесте нужно права получать с обоснованием зачем.
И все пароли меняются не реже чем раз в три месяца. И не менее 12 символов "3 группы из 4-х". И три неправильных попытки - блокировка профайла с разблокировкой по отдельной заявке.
В моей конторе ещё фактором аутентификации является сертификат с внешнего носителя. То есть придётся физически украсть флешку с сертом и знать пароль к контейнеру (а там всего 10 попыток без возможности сбросить эти попытки), чтобы попасть в сеть организации.
Все это очень безопасно, но не забывайте аналогию с очень защищённым забором на фронтальной стороне и деревянным обветшалым сбоку.
Взломы чаще выполняются с "черного хода" когда никакие флэшки и сертификата не нужны.
Из живого примера при внедрение мфа для впн существовал адрес для входа без мфа. Могу предоставить ситуацию когда кто-то это забыл/сохранил для слоупоков, ленивых топов/каких то особых клиентов/подрядчиков.
Пароль пусть даже гендиректора совершенно не достаточен для уничтожения 7000 серверов, уничтожения баз данных, и скачивания 22 TB данных.
А про 7000 серверов, БД и 22 ТБ информация откуда? От самих кулцхакеров? "Так и Вы говорите". (ц)
Я вообще не верю в то что это сделали хакеры. Поэтому и написал так. В чем проблема?
В чем проблема?
Это уже теория заговора, и необоснованная, и не особо логичная. Тем и не нравится.
А логичнее получается что это сделали хакеры? Правильно я Вас понимаю?
Да, логичнее и вероятнее. Это как бы не первый, мягко говоря, случай взлома в истории, и большинство аналогичных взломов произошли без злого умысла сотрудников. В общем, по меткому выражению приписываемому Виктору Пелевину, миром правит не тайная лоха, а явная лажа.
Да, естественно. Что вас смущает в возможности взлома старой (со всеми вытекающими) широко известной, но при этом ранее не пуганной авиакомпании, которая к тому же нанимает бюджетных ИТ-специалистов?
Просто интересен источник информации. Что-то похожее распространяли сами хакеры, от "Аэрофлота" я такой информации не видел. Ну и раз уж так - а внутри могли грохнуть всё вышеупомянутое?
Грохнули или не грохнули и что именно грохнули пока не известно. От Аэрофлота и будет скорее всего ничего внятного. Это корпоративная, больше чем причины крушения самолетов.
Если есть доступ то не важно изнутри или снаружи. Мне не понятно как можно было не обратить внимания на перекачку 20 TB наружу. Может это сделали локально на диск и вынесли диском?
Ну среди диванных экспертов есть такое мнение:
Поговорил с ребятами, аудировавших Аэрофлот. То, что случилось вчера вызывает огромное количество вопросов. Главный — зачем тратить столько усилий (по словам группировки, пролезали год), чтобы всего на 10 часов вызвать легкие (скорее некритичные) для пассажиров неудобства. Зачем стирать все данные учета, отчета, корп-почты, но при этом оставлять данные бронирований, баллов систем лояльности и пользовательских данных? Не логично, не так ли?
У ребят, кажется, мнение солидарное — кажется, есть прямая закономерность: проверки в Мин.Трансе → «самоубийство» Министра — > стирание всех данных операционной деятельности Аэрофлота (напомню, один из главных получатель гос.субсидий). Тогда объяснимо, почему в заявлении так глупо и не уместно подсвечивается «Глава не менял пароль от компьютера уже 3 года».
Ну по факту ничего этого не было, Аэрофлот восстановил работу в течении суток, что подтверждает что заявления хакеров не более чем пшик.
Ну а кто тут враг если трубят про полное импортозамещение ПО, при том что древняя винда с трёхлетний паролем на страже?
Это еще LLM не добрались везде... Смотрю сейчас MCP - авторизация еще в драфте, то есть вызовы анонимные по сути или прикручивай как умеешь.
Все напоминает "сделать демку прототип поскорее и прикрутить в проде".
Мы еще наловим проблем с безопасностью в AI (уже ловим, вернее - новости есть).
На курсах RAG спрашиваю - как пробросить контекст пользователя дальше для фильтрации данных (не возвращать то к чему пользователь не имеет доступа). Впечатление что бегают трололо (мы скрутили какую то демку и ура, она работает, смотри как все просто, введите openai ключ и все будет работать) а нормального решения для многопользовательского окружения или нет или забыли показать. Примеры на 10 документов при которых бедная видюха идет на взлет (ембеддинг) - страшно представить сколько энергии улетит при прогоне 10М документов (в датацентре). А 100М? 500М?
Причем это проблема старая и началась не вчера - копался я к примеру, с lucene индексами и часто вопрос был: как сделать ограничение доступа к определенным записам в индексe? И приходились вкорячивать свой join, индекс для него и тд. чтобы фильтровать во время поиска. Потому что ни один движок на люсин (solr, elastic) нормально фильтрацию не поддерживали, join тоже (на кластере). Вернее решение возможно но за отдельную котлету денег, чем я и занимался.
копался я к примеру, с 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
увы, Lucene это не DB2 и не совсем база...
И зачем, интересно, понадобился этот зверь?
Это поисковик, Search Engine, верно? Где он ищет? В базах данных в том числе. Вот в этих БД и надо защищать информацию, а не в поисковике.
Эта ваша потребность в данном случае не обоснована. Кмк.
да, это по сути, поисковик. Его неправильно использовали - это часто бывает, к сожалению. И рекомендации игнорируются. И кеш используется как основное хранилище. Но если очень нужно и клиент платит, то почему бы не создать франкенштейна? Любые капризы за ваши деньги...
В lucene кешировалась информация из различных источников, в том числе из баз, репозиториев документов, и полнотекстовый поиск в нем был. IBM FileNet частенько кролил, Image Services, ISRA, и напрямую из базы тоже если доступ давали (метаданные). COLD документ формат недавно крякнул, тоже старый IBM стандарт для хранилищ. Но с 390 дела не имел, разок только с AS400, это из ближайших родственников если смотреть
Любые капризы за ваши деньги...
Не исключено это тоже имело место быть в достижениях ИТ Аэрофлота.
Но с 390 дела не имел, разок только с AS400, это из ближайших родственников если смотреть
Это очень дальние родственники. Седьмая вода с киселя. В ИБМ много было в свое время денег и их тратили на многие разные поделушки. IBM RISC с AIX вытесняется успешно х86 и Linux. AS400 потому лишь продолжает существование что очень уж его принципы работы и ПО не похоже ни на что, ни на Linux ни на System Z (390).
с AIX примерно тогда же возился.
Привезли IBM Everyplace Suite и я с ней продолбился... Пока не плюнул и не декомпильнул установщик. И что я нашел на 10м диске? Введите путь к базе данных (у меня был оракл) и затем неудаленная статичная переменная, путь к дб2... Вот это баг.забыли после отладки удалить а тестеры зеванули.
AS400 дали на месяц пощупать от IBM - забавная игрушка, починил ее заодно, не работал один порт на сетевую карту. Посмотрел доки, диагностику прогнал да переткнул карту - коллеги сказали "шайтан". Этот холодильник обходили стороной.И еще одна карта была по сути x86 PC - проц, память, видео, клава, мышь свое, а вот диск нарезался на материнской системе - такого тогда не встречал. Ставишь Линукс на комп на карточке расширения. "Виртуалка" в железе.
Хорошая система была 25 лет назад, но дорогая - ценник конский на все. И не мейнфрейм, не знаю ее нишу, вроде банки покупали и магазины, встречал пару раз их позже.
Извините что вмешиваюсь. В Эластик можно вкрутить плагин, который будет фильтровать поисковые запросы как прокси. Костыль, конечно, из коробки не умеет.
И не смотря на то, что индекс это не RDBMS, он тоже вполне себе база с данными. И иметь row/column контроль хотелось бы.
без проблем, это же публичная дискуссия. Движок был кастомный, рефакторил его, по наследству. Упор был на вертикальное масштабирование - индекс мог быть на нескольких дисках (композитный).
Потом солр зачем то подтянули. Эластик после 5й версии не видел, но впечатление по коду оставил хорошие по сравнению с солр.
Независимо от того какой поисковик, все упирается в люсин, и в нем либо допиливать join с люсиновским JoinUtil классом ( и своим индексом), либо вычисляемые поля сделать (кастомный тип данных в люсин).
Еще было востребована похожая тема - lookup поля когда в индексе хранится число (id, int) а пользователю возвращается текст в локале пользователя (и сортировка по тексту). Если клиенты из разных стран и локали разные, либо тексты меняются часто, то рекролить индекс на сотни млн документов так себе идея (нормализованное хранение лучше). А люсин индекс по сути, если аналогию с базой проводить - это одна таблица. В которой ты делаешь join между записями (если индекс один)
Db2 по сравнению с соларом при поиске в тексте это как гусеница по сравнению с самолётом.
не так давно занесла меня нелегкая в исходники базы на java, H2 - глянуть а как они join реализовали. И увидел я использование Lucene для полнотекстового поиска внутри. Ссылка на класс
И как оно соотносится со скоростью поиска в DB2 ?
возможно я проскочил через ступеньку и не развернул мысль: "с соларом" имелся в виду "solr"? A solr это lucene, по факту. И вот копаюсь я с добавлением индекса в люсин чтоб ускорить join который в нем слабое место и нахожу использование lucene для тесктового поиска внутри слабенькой но все таки классической реляционной базы H2. Конвергенция, не поймешь что куда засунули... Так что почему бы и DB2 не засунуть под капот обратный индекс для текстового поиска? С DB2 не так чтобы каждый день в обнимку провожу (я не DBA), но формально во всех продуктах которые делал, ее поддержка подразумевалась (последняя контора где работал была IBM партнер). Заглянул и что я вижу: прикрутили текстовый поиск к DB2 с внешним сервером:
Text Search Server:
This is the core component responsible for indexing and searching text data. It can be installed on the same system as the DB2 database server (integrated setup) or on a separate system (stand-alone setup). Communication between the DB2 database and the text search server occurs via TCP/IP.
Text Search Indexes:
Unlike traditional DB2 indexes that are managed within the database, text search indexes are stored separately on the file system, managed by the text search server. These indexes are created for specific text columns in DB2 tables and are populated with the text content.
https://www.ibm.com/docs/en/db2/11.1.0?topic=text-db2-search
Интересно а как они join поддерживают когда сервак снаружи? У меня подобная проблема были при создании гибридного поиска (когда поиск разнесен и нужно объединить), это какие битсеты нужно передавать, для мержа, объем будет немаленький, скажем для 100М документов битсет даже сжатый место съест...
Не засунут, потому что тогда для взлома их чудесных записей все что надо будет - пройтись по вывернутому индексу люсьена и можно будет с некоторой долей вероятности восстановить текст в записи, даже не имея к ней доступа. А если будут делать валидаторы под каждую запись - скорость чудесным образом рухнет. Вооот. Поэтому и строгают внешние всякие системы отгораживаясь великолепными соглашениями о софте, только что бы их прекрасные продукты не пострадали.
то какие битсеты нужно передавать, для мержа
Джойн с низкой селективностью всегда боль и страдания для любой системы.
Пройтись по люсину физически? Если про файлы, то шифруют, на уровне адаптера. файловой системы - скорость падает раза в полтора /два... А если тащить security в люсин - то это либо join ( всегда, но маленькую выборку с высокой селективностью так как security записей мало обычно - сотня другая групп и пользователей) но join это и память и время выполнения еще сильнее падают. А join с низкой селективностью - это стоп фактор для простых реализаций join через итератор, на коленке.
Вытаскивается текст из токен стримов достаточно хорошо из люсин индексов, приходилось писать парсеры для миграции. Основная проблема это то что в люсин поля хранятся после обработки ( токенизация всякая разная, приведение к регистру и тд и тп, в общем фарш а не исходный текст).
А что если бы не забивали на правила ИБ и как минимум все системы поддерживали в актуальном состоянии. Конечно, полно умников с линуксами, но простите какой вам линукс, если с виндой даже справиться не в состоянии...
Проблема не в том, что кто-то забивает, а в том, что это бизнес по-русски - максимальные прибыли в кратчайшие сроки, закрывая глаза на всë. У руководства нет понимания важности ИБ, у людей на местах нет возможности быть услышанными снизу, особенно если их предложения либо замедляют получение прибыли, либо уменьшают еë, требуя дополнительных трат на направление. И случается тр, что случается - экономия на важном до первого жареного петуха. И усугубляется это всë ещë и госсектором.
Ну а если от этого прямых убытков (и косвенных в виде репутационных потерь, но это сложно оценить) было меньше, чем мог бы стоить штат сотрудников за время между возникновения проблемами, то как обосновать такой найм бизнесу?
Руководителю тоже ,тот еще кейс принять верное решение, когда каждое подразделение насыпает и говорит, вот им только и надо поставить, давайте вместо 50 рублей дадим 5, тот еще кейс принять верное решение …
Да что там сложного в линуксе? Он же прост как табуретка. В качестве сервера самое то, вот пользовательский интерфейс бывает страшный или корявый
Он же прост как табуретка.
Потому в "классическом виде", то есть в виде дистрибудива с большим количеством пакетов, которые активно запускают друг друга, порой оказывается уязвим в самых неожиданных местах, когда какая-нибудь безобидная утилита позволяет повысить привилегии до рута.
По хорошему конечно софт лучше запускать в непривилегированных контейнерах, где вообще нет ничего кроме самой запускаемой софтины, а все что он видит это только ip-адрес другого такого же контейнера, где живет его собеседник, и свой изолированный вольюм, но чтобы оно так работало, его нужно так написать, а старый софт писали по другому, часто вообще не рассчитывая что там кто-то что-то может захотеть сломать.
Прямо жизнь в "докере" получается..
Да, вспомнилась давняя история с багом в ssl ping - когда какой то студент в библиотеке SSL в пинге проверку длины сообщения не сделал и эта базовая для многих пакетов библиотека расползлась. Канадскую налоговую (сайт) попинговали и увели десятки тысяч учеток и приватной информации - посылали пинг с декларируемой длиной сообщения в 64к и получали обратно кусок памяти этого размера с сервера. Классика жанра: казалось бы, не те времена, не 80е, а случилось. И просмотрели. Идиотский баг.
Статический анализ кода будет им в качестве урока.
Качество разработки поднять всем полезно но как проверить библиотеки? Вот в чем вопрос... Нашел этот баг, он оказывается в вики есть:
Расширение 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 (налоговая) подняла шум?
По статье не видно, чтобы в МФ были какие-то принципиально лучшие средства защиты информации. Вы сами пишете, что в Windows есть API для доступа к системной аутентификации и авторизации, там есть такой же системный журнал событий. В Linux есть единый API для аутентфикации PAM (=pluggable authentication modules), единая точка автризации LSM (local security module) с популярной реализацией SELinux (где на процессы и объекты вещаются "метки", как в RACF). Сейчас в Linux есть еще LSM eBPF hooks, чтобы администратор мог сделать произвольную логику контроля доступа. И в Windows, и в Linux пользователям для сервисов запрещают вход в систему. Проблема не в том, что механизмов нет, а в том, что ими не пользуются. На то разные причины, главными я бы назвал две: 1) контроль доступа нужен не к системным объектам для защиты их целостности, а к бизнес-сущностям для защиты их доступности конфиденциальности; 2) гораздо проще наколхозить управление доступом в одном приложении, чем возиться с администрированием в нескольких местах, и, главное, несколькими людьми. Возможно, МФ применяются там, где требование сделать по гайдлайнам платформы возможно форсировать административно — ну, круто. Кстати, мы тут много ругаем Astra Linux и, разумеется, за дело (с), но там движение в эту правильную сторону есть.
Спасибо за толковуюреакцию, первую пока. Общее замечание. Всякий раз как я когда либо рассказывал на форумах по теме статьи и другим темам, всегда находились люди сходу заявляющиеся то что заявляете и Вы. Но я всякий раз пытался и пытаюсь объяснять что это не совсем, а в большинстве случаях совсем не так. Интересный поинт еще в том что мои оппоненты как правило ничего не знают, никогда не работали с 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 есть решения многим из них, а "у вас" тоже решаются кто на что горазд. Страдает бизнес-пользователь ИТ и пользователи бизнеса - пассажиры Аэрофлота, которые не смогли улететь.
Спасибо за пояснение по работе 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 не было бы (либо вы о них не рассказали в статье). Что мир МФ предлагает, так это живое свидетельство, что сделать так, как описано выше, хотя бы в каких-то условиях возможно.
Спасибо за ответы. Пара замечаний если позволите.
обычный пользователь с заданными изначально широкими правами
Мне кажется или в этой фразе есть таки некоторое противоречие. Вообще то у меня есть мои аккаунты с пр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". Это не корректно и не профессионально. Спасибо. Буду рад продолжить общение с Вами если Вы учтете мои просьбы. Отвечу на любые вопросы.
(zVlad909) в Windows и Linux есть administrator/root, которым доступно все
(kozlyuk) Administrator в Windows — обычный пользователь с заданными изначально широкими правами
(zVlad909) Мне кажется или в этой фразе есть таки некоторое противоречие. Вообще то у меня есть мои аккаунты с прaвами sudo на Linux серверах.
В Windows нет понятия суперпользователя, "administrator/root" — это "яблоки/апельсины". Administrator прописано много привилегий, Backup Operators прописано меньше, можно составить свой набор. Чем это принципиально хуже уровней авторизации, которые вы описываете абзацем выше в своем первом ответе?
Как часто Вы сталкивались с использованием ACL. ACL это файлы (листы) в фолдерах. Их можно иметь, можно не иметь, их можно создавать, можно удалять. Это не имеет ничего общего с тем как работает (по-Вашему тоже самое) z/OS и RACF.
Я мало работал с Windows, но знаю, что ACL есть не только у файлов. Документация говорит, что ACL можно навесить на любой объект AD DS и даже сделать кастомные виды прав. Есть место, где можно делать записи о любых объектах и описывать права доступа к ним, есть системный API для проверки доступа — это "ничего общего"?
С другой стороны если предлается [расширять системную логику программами/функциями], то это означает что системная логика ограничена/ущербна и значит надо над ней работать еще.
Полистал документацию на z/OS и увидел exits, в частности, в RACF (SA23-2288-60 Security Server RACF Macros and Interfaces). Означает ли это ограниченность/ущербность системной логики z/OS? Кстати, RACF описан как optional компонент, который вообще можно заменить на совместимый. Получается, на МФ бардак все-таки возможен?
В z/OS и RACF у таких аккаунтов в принципе нет пароля.
Как и в Linux, как и в Windows.
По моему вопросу "Как в RACF появляются записи о конкретных объектах (ресурсах), создаваемых в рамках программы?", возможно, мы друг друга не поняли. Я имел в виду, что в программе можно создавать однотипные объекты, и вопрос был в том, как в RACF попадает запись о конкретном объекте (его профиль). Объекты создаются слишком часто для ручного заведения, иногда скриптами через HTTP API. Насколько я понял из документов, при установке программы администратор должен создать новые классы ресурсов в CDT (SA23-2289-60 Security Server RACF Security Administrator's Guide, Ch. 10) — возможно, вы это имели в виду; затем программа при создании объекта обращается к RACROUTE REQUEST=DEFINE (SA23-2294-60 Security Server RACF Macros and Interfaces). Точнее, обращаться должен привилегированный микросервис, потому что "RACROUTE REQUEST=DEFINE caller must be authorized (APF-authorized, in system key 0–7, or in supervisor state)". Вроде бы RACF позволяет сделать так, чтобы этот микросервис мог работать только с профилями ресурсов определенного класса (обсуждается рядом с работой с CDT).
Почему администратор RACF должен быть обязательно не в их организации? А как сейчас в облаках дела делаются? Вот это точно что облачные админы не в "их организации". И что?
Например, в AWS IAM в каждой организации есть администраторы, которые могут заводить пользователей и раздавать им доступы. Разработчики системы не знают, как захотят распределить доступы в каждой организации. У кого-то все сидят под одной учеткой, у кого-то несколько видов пользователей разной степени бесправности. Сотрудники приходят, уходят, меняют свои роли, но в Help Desk обращаться не нужно.
Моя задача взята из практики и, как мне кажется, является типовой. Мне интересно, как механизмы z/OS могут удовлетворять возникающие требования.
Буду рад продолжить общение с Вами если Вы учтете мои просьбы.
Давайте не будем больше опускаться на такой тон.
Я мало работал с Windows, но знаю, что ACL есть не только у файлов. Документация говорит, что ACL можно навесить на любой объект AD DS и даже сделать кастомные виды прав. Есть место, где можно делать записи о любых объектах и описывать права доступа к ним, есть системный API для проверки доступа — это "ничего общего"?
Во-первых, мне про это известно и я вроде даже в статье про это писал.
Во-вторых, есть то оно есть, но нигде, никем не используется. Вот когда будет использоваться так как в z/OS тогда и будем говорить "в Windows и в z/OS". На х86 есть несколько способов виртуализации памяти, несколько колец привелигированности команд процессора. но используется только один способ виртуальной памяти и два кольца. На МФ один способ по памяти и два состояния привелигированности: супервизор и пользователь.
Можно не значит есть и работает.
В Windows нет понятия суперпользователя, --- Administrator прописано много привилегий,
Вы сами себя слышите? Рут в Линуксе и SPECIAL в z/OS тоже можно назвать простыми пользователям. но с расширенными правами. В z/OS у пользователей могут быть атрибуты, если их нет то это просто пользователь, если есть то это пользователь с дополнительными правами.
Я имею SPECIAL в z/OS и у меня есть администратор на window cерверах и sudo тот же root в Линукс. Разницы между ними я не вижу, ее нет.
Полистал документацию на z/OS и увидел exits, в частности, в RACF (SA23-2288-60 Security Server RACF Macros and Interfaces). Означает ли это ограниченность/ущербность системной логики z/OS? Кстати, RACF описан как optional компонент, который вообще можно заменить на совместимый. Получается, на МФ бардак все-таки возможен?
Молодец! Мне очень приятно такое слышать. Надеюсь Вы и не только про exits там почитали.
Я знаю про эти exits конечно же, но Вы про ваши "функции" пишите когда еще базовые не используются, а мы на МФ их не используем когда все базовые используют на полную мощность. Есть разница?
На моих системах, ни до меня ни мною не было написано ни одной програмы выхода RACF. Как Вы заметили их не мало. Я хочу Вас уверить что в целом по z/OS их в десятки раз больше и некоторыми из них пользуются, и я пользуюсь.
Да RACF имеет и другие реализации. ACF2, ACF3, Top Secret. От других вендоров. Строго говоря это все просто разные варианты диалогов и комманд (интерфейс) к чему то одному - SAF. Все они работают по одной и той же логике заданой системной SAF. По сути это просто разные фронтэнды (уже сказал выше) для одного и того же процесса, одного в итоге движка. ИБМ всегда оставляла возможности другим производителем софта для MVS что-нибудь дописывать, но все эти вещи работают строго в рамках заданых ИБМ.
Есть два варианта планировщика заданий JES2, и JES3 (Job Entry System). Оба не совсем ИБМ продукты:
Precursors
OS/360's batch job processing had limited operational flexibility and performance, which was addressed by two field-developed packages called the Houston Automatic Spooling Priority (HASP) and the Attached Support Processor (ASP).
Так или иначе но это совсем не то что мы видим в мире Windows и Linux, где все кому не лень придумывают свои концепсии, технологии, принципы в направлениях где это должно быть реализованно в ОС и использованно прикладными программами. Вместо это эти системные функции ратащили в прикладные программы и возвели их в ранг заменителей системы.
Если то что Вы нашли и можно назвать бардаком, то весьма строго контролируемым бардаком.
Я имел в виду, что в программе можно создавать однотипные объекты, и вопрос был в том, как в RACF попадает запись о конкретном объекте (его профиль).
Я Вас понял. Объясняю. Помните я писал что контроль доступа начинается с "менеджеров ресурсов (объектов, если хотите)". Вот эти менеджеры и задают правила контроля доступа через принятую в z/OS (не важно RACF, ACF, or Top Secret). Эти менеджеры формулируют понятие ресурсов (например DFSMS имеет массу комманд и их исполнение должно авторизоваться по разному, одни команды могут доступны любому пользователю, другие администраторам storage, третьи только правам OPERATIONS. Для защиты этих объектов (ресурсов) DFSMS имеет набор классов профайлов (нечто подобное есть и в Windows, но нет менеджеров, которые это бы использовали, в этом и состоит прикол). Это например классы DATASET, DASDVOL, GDASDVOL, PSFMPL, TAPEVOL, VMBATCH, VMCMD, VMMDISK, VMNODE, and VMRDR. Не все эти классы могут активизированны. Но если DFSMS получает запрос от чего угодно на функции или ресурсы (объекты) контролируемые и управляемые DFSMS то он обязательно (так он запрограммирован) обратится к SAF, через макро RACROUTE (SA23-2294-40z/OS Security Server RACROUTE Macro Reference) на предмет что есть по поводу его классов и профайлов в связи с запросов доступа от такого пользователя (субъекта). Если даже нет таких классов, то будет отлуп на запрос.
DFSMS входит в состав z/OS поэтому его классы добавляются во время генерации (инсталяции) z/OS. А если мы добавляем к z/OS например DB2, то в процессе её инсталяции будет поток команд для RACF с цель создания классов для профацлов контролируемых DB2 как менеджером ресурса - база данных. Профайлы в эти классы добавляет админ RACF по мере надобности.
Рассмотрим простой пример с наборами данных. Каждый пользователь, менеджер рессурсов использует наборы данных. Доступ к наборам данных контролируется классом DATASET. Профайлы в этом классе строятся по правилам наименования наборов данных. Например наборы данных имена которых начинаются с SP.SMFDATA будут представленны профайлом SP.SMFDATA.** и этот прфайл будет иметь лист уровне доступа для разных групп и аккаунтов с назначеным им уровнем доступа, например:
CIMVS - ALTER
SPOPER - READ
SPTE - WRITE
И что главное это не в файле фолдера как с ACL, а в специальной базе данных RACF. Т.е. это не зависит ни от мета где этот набор ни от него самого. Профайл может сущестывовать даже если нет ни одного такого набора данных.
Я смотрю Вы уже читаете про RACROUTE, но еще не ознакомились с принципами раобты. Поэтому у Вас недопонимание.
Объекты создаются слишком часто для ручного заведения, иногда скриптами через HTTP API.
Среда в RACF для опять же "менеджера ресурсов" создается до того как ресурсы будут создаваться, и это не какой то произвольной программы роль создавать профайлы в RACF (иначе это бы потеряло смысл контроля доступа), а воля секьюрити администратора, согласованная конечно с пользователем менеджера ресурса для его работы в оговоренных рамках.
Я ни разу не кодировал програм с RACROUTE макро, но устанавливал простенькую програмку в exit DB2 c этой макро. Это было нужно приложению использующему DB2.
Очень рекоммендую Вам не забегать вперед сразу в написание программ не ознакомившись с принципами работы того что Вы вроде как собрались программировать. Это очень ошибочный путь отбирающий время и затрудняющий нахождение правильного пути.
Например, в AWS IAM в каждой организации есть администраторы, которые могут заводить пользователей и раздавать им доступы. Разработчики системы не знают, как захотят распределить доступы в каждой организации. У кого-то все сидят под одной учеткой, у кого-то несколько видов пользователей разной степени бесправности. Сотрудники приходят, уходят, меняют свои роли, но в Help Desk обращаться не нужно.
Это бардак. Каждый пользователь-человек должен иметь свой персональный аккаунт в системе контроля доступа. С именем фамилией и учетным номером. Пользователи должны быть оъединены в группы по ролям в приложении. Пользователи с несколькими ролями могут быть мемберами нескольких группы. Каждая группа добавляется с присвоенным ей уровнем доступа к каждому ресурсу нужному для выполнения роли.
Вот как это имеется в иду должно быть чтобы применять RACF. Так это и должно быть для целей информационной безопасности. Хелп деск или что-то другое, но за этим необходимо следить и управлять. Иначе раньше или позже наступит то что с Аэрофлотом.
Давайте не будем больше опускаться на такой тон.
Это легко, если Вы учтете мои пожелания:
Хочу Вас попросить об отдолжении, буду очень благодарен. Прекратите сообщать мне прописнве истины с интерпретацией на уровне Ваших знаний только про системы на х86. И не надо, пожалуйста, использовать обороты типа "в Windows и в z/OS". Это не корректно и не профессионально.
Очень рекоммендую Вам не забегать вперед сразу в написание программ не ознакомившись с принципами работы того что Вы вроде как собрались программировать.
Моя цель — разобраться, как именно архитектура безопасности в МФ позволяет удовлетворить типовые требования приложений, чтобы обрести свежий взгляд на известные мне проблемы. Программировать МФ я вряд ли буду. Я ссылаюсь на конкретный макрос, потому что он выполняет операцию, о которой я спрашивал.
То, что вы расписали про DMSFS и его классы ресурсов, я как раз понимаю. Однако меня интересует не защита целых датасетов, а защита конкретных бизнес-сущностей, которые обычно представлены строками с таблицах БД, причем часто данные одной сущности (объекту доступа) хранятся в нескольких строках нескольких таблиц, например, заказ и его позиции. Напомню, что требования заключаются в том, чтобы доступ к заказу был только у сотрудников организации (программа-минимум), а еще у разных групп (ролей) сотрудников одной организации может быть разный доступ, причем правила доступа каждая организация определяет сама в соответствии со своими бизнес-процессами.
В DB2 и других СУБД есть row/column-level security (вы даже упоминали их в соседних ветках), но даже в DB2 эти механизмы связаны с RACF только через учетные записи, а все правила доступа хранятся не в RACF.
Зайдем со стороны RACF; как я понял из его документации, можно создать новый класс ресурса для определенных бизнес-сущностей. Непонятно, как этим дальше пользоваться для защиты таких ресурсов, для начала — как RACF конкретный ресурс идентифицирует, чтобы какие-либо правила доступа применять. Макрос RACROUTE позволяет делать запись о ресурсе в RACF, но вы говорите, что не пользовались RACROUTE, — видимо, это не является типовым способом решения моей задачи. (Для DMSFS есть специальный атрибут: "When a user has the ADSP attribute, RACF always automatically creates a discrete profile every time the user defines a permanent DASD or tape data set".) Переходить на хранение в датасетах значит потерять возможности БД (SQL, транзакции, ссылочную целостность), но так хотя бы понятно, как разграничение доступа может работать. Чтобы организация могла выстраивать правила доступа для своих сотрудников, вроде бы можно выдать администратору от организации SPECIAL на уровне группы. Учетные записи и группа должны быть сугубо под приложение, иначе SPECIAL позволит менять доступы, касающиеся не только приложения.
Тут же вопрос, который не специфичен для МФ, он касается и row/column-level security в любой СУБД. Приложение-сервер обычно работает под служебной учетной записью. Клиенты делают запросы по API (напрямую или через UI) после аутентификации через то же API, а не сидят в интерактивной сессии МФ. Как обеспечивается, чтобы операции пользователя, запущенные через API, выполнялись с правами учётки этого пользователя? Во-первых, нужен какой-то механизм имперсонации. Во-вторых, и это главное, программа-сервер должна не забывать эту имперсонацию делать, иначе получим, что все принадлежит де-факто служебному пользователю. (Не могу найти статью про приложения "зеленого экрана" для МФ. В любом случае, такой интерфейс не во всех случаях подходит: иногда нужен HTTP для стандартного взаимодействия, иногда нужен богатый UI с графикой.)
Итого мне видится, что для типичного клиент-серверного приложения с РСУБД на бэкенде контроль доступа не получается сконцентрировать в RACF (да и вообще RACF тут будет только для аутентификации). Например, SAF+RACF нельзя задействовать как security reference monitor (с интересом слежу за тредом про EAL), если захочется сертифицировать свое приложение, хотя для ОС он таковым является.
есть то оно [Windows ACL] есть, но нигде, никем не используется
ACL применяется для системных объектов: файлов, ключей реестра. Не имею никакого опыта с AD DS, но тоже предполагаю, что для произвольных бизнес-сущностей ACL не применяют из-за тех же примерно проблем, что описаны выше для RACF, плюс работа с ACL в Windows очень замороченная.
Рут в Линуксе и SPECIAL в z/OS тоже можно назвать простыми пользователям. но с расширенными правами.
Root — это особый пользователь с правами, которые никому больше выдать нельзя. Можно только выдать право стать рутом. Отсюда подход Linux, состоящий в том, чтобы ограничивать права, которых слишком много, а не выдавать только необходимые, и вечные дыры оттого, что не всё ограничили.
Я знаю про эти exits конечно же, но Вы про ваши "функции" пишите когда еще базовые не используются, а мы на МФ их не используем когда все базовые используют на полную мощность. Есть разница?
eBPF тоже для особых случаев. Я писал про них, когда еще не прочитал об exits, как о технологии, позволяющей обеспечит максимальную гибкость и гранулярность правил доступа. Ну, а сначала слова, что если есть возможность расширять системную логику, значит, она "неполноценна/ущербна", а потом — что в z/OS полно exits и ими пользуются, звучали как двойной стандарт.
Если то что Вы нашли и можно назвать бардаком, то весьма строго контролируемым бардаком.
Наличие выбора — не бардак. Я говорю о том, что RACF может не быть в системе (если это то, что имеется в виду под "optional"), и даже если он есть, то не все сценарии покрывает, и это позволяет развести бардак. Собственно, Security Server RACF Security Administrator's Guide (Ch. 2) так и говорит, что RACF не панацея, а главное — отношение к безопасности.
Однако меня интересует не защита целых датасетов, а защита конкретных бизнес-сущностей, которые обычно представлены строками с таблицах БД, причем часто данные одной сущности (объекту доступа) хранятся в нескольких строках нескольких таблиц, например, заказ и его позиции.
Мне кажется Вам, для начала, надо посмотреть вот это:
https://www.ibm.com/docs/en/db2-for-zos/12.0.0?topic=configuration-access-control
Access to Db2 objects is also controlled by RACF. Db2 acts as a resource manager for those objects and calls RACF when a user attempts to access one of those objects. A set of Db2-specific classes are defined in RACF, and profiles in those classes are used to protect the Db2 resources.
Labeled Security only: Db2 uses RACF for row-level security to check the right of the user to access a field in a row, based on the labels for mandatory access control. RACF checks if the current security label of the user allows the type of access, based on the security label of the row and the rules of mandatory access control.
В CREATE TABLE на уровне колонки есть clause "AS SECURITY LABEL". Вот его описание (но этого может быть мало, надо смотреть детали в DB2 мануале, имейте также в виду что это уровень очень старой версии DB2 - version 9, current version is 13):
AS SECURITY LABEL
Specifies that the column will contain security label values. This also indicates that the table is defined with multilevel security with row level granularity. A table can have only one security label column. To define a table with a security label column, the primary authorization ID of the statement must have a valid security label, and the RACF SECLABEL class must be active. In addition, the following conditions are also required:
v The data type of the column must be CHAR(8).
v The subtype of the column must be SBCS.
v The column must be defined with the NOT NULL and WITH DEFAULT
clauses.
v The WITH DEFAULT clause must not specify a default value (DB2
determines the default value)
v No field procedures, check constraints, or referential constraints are defined on the column......
В текущей версии 13 документ называется "Securing DB2":
https://www.ibm.com/docs/en/db2-for-zos/13.0.0?topic=securing-db2
Вот здесь про Security Labels usage:
Спасибо! Именно это я искал, но не в тот раздел документации DB2 смотрел. Я читал про row/column access control (RCAC) и label-based access control (LBAC), но они опираются не на RACF, а на собственные механизмы DB2. На практике я бы их и применил, однако в этом треде речь про разграничение доступа средствам RACF.
Итак, чтобы пометить объект, который будет доступен только сотрудникам организации, причем некоторым — только для чтения:
Завести категорию (category) для организации, чтобы использовать её для всех объектов организации. Только пользователям-сотрудникам организации разрешается при аутентификации брать метки (labels), которая содержащие категорию этой организации, путем выдачи права на эти метки только этим пользователям напрямую или через группу.
Завести два уровня доступа (level): LOW, HIGH; для каждой организации завести метки к категорией этой организации и каждым из уровней.
Дать привилегию на write down для пользователей-администраторов организации.
Дать администраторам организации авторизацию RACF SPECIAL на уровне группы, куда входят пользователи организации, чтобы они могли назначать доступные метки.
Работать будет так:
Пользователи, желающие выбирать данные, подключаются к базе с меткой, содержащей категорию их организации и уровень HIGH (далее пишу "пользователи с уровнем HIGH" для краткости).
Администраторы организации создают объекты (вставляют строки) с меткой, содержащей категорию организации и уровень LOW ("объекты с уровнем LOW"). Таким образом, остальные пользователи, вошедшие с уровнем HIGH, могут читать эти строки, но не могут писать в них, так как не имеют привилегии write down.
Пользователи, желающие добавлять или менять данные, подключаются к базе с уровнем LOW (если им это разрешено) и создают объекты, которые получают такой же уровень, поэтому пользователи и с уровнем LOW, и с уровнем HIGH смогут их читать.
Может ли пользователь, подключившись с уровнем LOW, добавлять или изменять строки в таблице, по идее, можно разграничивать метками на самой таблице. Но не соображу, как, потому что, если у таблицы уровень HIGH, то при подключении с уровнем HIGH в нее можно писать, а не должно быть (пользователи подключаются с уровнем HIGH для чтения). Есть ощущение, что это конфликт между защитой конфиденциальности ("no write down, no read up") и защитой целостности ("no write up, no read down"). Возможно, здесь как-то помог бы discretionary access control, который должен сработать после mandatory, но я не увидел описания.
Уровней может быть больше двух. Чем выше уровень, с которым подключается пользователь, тем больше есть уровней, строки с которыми он сможет читать, но не менять. Вообще, уровни не всегда строго иерархичны. В концепции multi-level security (MLS) это должны быть иерархии уровней в разных категориях. Организация технически может использовать больше одной категории, но, как я понимаю, никаким запросом нельзя выбрать строки, метки которых содержат разные категории, что не даcт просмотреть одним запросом все объекты, принадлежащие организации, например.
Итого контроль доступа к объектам приложения в РСУБД сконцентрировать в RACF хотя бы в некоторых случаях можно, я действительно был неправ. Описанная выше схема, если она идеоматична, всё равно оставляет вопросы, да и простой и удобной в управлении мне не кажется.
но они опираются не на RACF, а на собственные механизмы DB2. На практике я бы их и применил, однако в этом треде речь про разграничение доступа средствам RACF.
я исходил из того, что можно как-то описать для RACF сами бизнес-объекты, а не их метки.
Мы продолжаем топтаться на метсе. Секьюрити в z/OS разбито на две части: SAF/RACF и иенеджеры ресурсов (DB2, JES, DFSMS, SDSF, NetView, TSO, CICS, WebSphere, etc... все что является материализаторами защищаемых ресурсов, которыми управляют эти менеджеры русорсов.
Естественно RACF не может "залезть" в DB2 и защищать её "бизнес объекты". Только сама DB2 может это делать. Но RACF тоже не лаптем щи хлебает. Он является носителем системной секьюрити полиси (правил) и арбитром применения этой полиси.
Менеджеры ресурсов обращаются к RACF за принятием решения о том достоин ли "субъект" получения запрошенного доступа к запрашиваемому "объекту". Если RACF дает добро, то доступ предоставляется, если нет то нет. Решение принимает RACF, рашение исполняется, в данном случае (а их столько сколько разнообразных менеджеров может быть в z/OS.
Разве выполнение правил, описанных через GRANT, обеспечивает RACF, а не сама DB2?
DB2 и RACF работают совместно, каждый по своему, для защиты ресурсов (всех ресурсов). У каждого есть свой объем работы для этого.
DB2 GRANT оператор описывает доступ к ресурсам специфическим для DB2. Например к таблицам и например к возможности создавать индексы на таблице. Эта информация хранится в соответствующей таблице DB2 каталога. RACF для такого способа защиты доступа не используется. Не только конечно таблицы, но и почти все другие ресурсы DB2 можно контролировать изнутри, используя таблицы каталога и start-up параметры самой подсистемы DB2.
Но тот же самый доступ к таблицам и другим ресурсам может быть контролируемым через RACF. Инсталлируя DB2, тот кто это делает, выбирает между одним и другим способами. Все про этот метод описано вот здесь:
Там где я работаю используется первый подход. Его имплементировали, хрен знает когда, в начале 90-х. Я проработал DB2 DBA шесть лет, с другой DB2 DBA, которая работала уже давно и особо ничего менять не желала. Ушла на пенсию в 2016 году. Да и я те шесть лет был больше занят внутренними проблемами DB2 (производительность, SQL tunning, DB2 utilities automation, etc...).
Меня перевели на z/OS в 2006 году. И я сразу оказался один на один со всеми z/OS без старослужащих, и как только я осознал роль и значение RACF я начал перевод там где это было сделано без RACF под RACF. Тут уместно обозначить что разные менеджеры ресурсов исторически имели два варианта контроля доступа: без RACF и с RACF. Имеются стандартные процедуры перевода туда и сюда. Но вот WebSphere начиная с версии 4 уже был ориентирован полностью на RACF. И конечно общая тендеция уже десятилетия это использование RACF. Это имеет массу преимуществ. Но как видите есть и альтернативы.
Вернемся к DB2. Есть и такие ресурсы DB2, как например сама DB2, её адрессные пространства (их всегда несколько), и доступ к ней самой, которые контролируются только через RACF. Пользователи DB2, их верификация и аутентификация всегда идет через RACF. Т.е. как минимум мы имеел смесь вариантов контроля доступа в случае DB2 и можно делать уклон в ту или другую сторону. Конечно правильнее это подход с уклоном в RACF.
Ваш интерес к методике RACF заслуживает всяческих похвал. Но Вы еще не преодолели привычные для Вас подходы к оценки новых для Вас технологий, приобретенные на системах типа Windows и Linux, где проблемы либо существенно упрощены либо наоборот слишком запутаны, искусственно, как правило, запутаны. (Имперсонализация, как пример). RACF технолоргия лишена и упрощенчества и излишней запутанности. RACF чем то напоминает виртуальные машины: есть супервизор, который организует доступ ВМ к ресурсам сервера, и есть ОС ВМ, которая занимается выполнениемс прикладных программ, не парясь многозадачностью и виртуализацией памяти. Классическая ОС для ВМ на МФ - CMS это однопользовательская, однозадачная система без собственной виртуальной памяти и ввода-вывода. Их совокупность на многих ВМ и образует многопользовательскую, многозадачную обстановку с виртуализацией памяти ВМ и достойным вводом-выводам.
Т.е. речь идет об иерархии управления, разделении функции по уровням. Каждый кровень делает свою, специфичную уровню, работу. А вместе получается эффективный комплекс.
Подходы Windows и Linux это использовать систему лишь для загрузки прикланой программы и предоставлении файловой системы (даже это порой не надо) и все остальное делать этой прикладной программой. Самим заниматься пользователями их верификацией, аутентификацией и авторизацией. И в каждой такой программе делать это по своему. Это очень не правильный подход, но другого увы нет. Вот и получается то что есть.
Итого контроль доступа к объектам приложения в РСУБД сконцентрировать в RACF хотя бы в некоторых случаях можно, я действительно был неправ. Описанная выше схема, если она идеоматична, всё равно оставляет вопросы, да и простой и удобной в управлении мне не кажется.
Практики работы с Security Labels, and Security Levels у меня нет. Я не тот кто склонен копать вглубь без конкретной проблематики.
Могу лишь сказать что раз в RACF (и в данном случае DB2, причем в RAСF этого шире чем только для DB2) есть завязки решения проблемы (в данном случае проблемы разграничения доступа к данным по уровням секретности) то это есть полноценное и достаточно удобное решение. Другое дело что этим решением надо уметь пользоваться, что приходит лишь на практике.
Если Вы знаете более простые и удобные решения для этой проблемы я бы с удовольствием об этом узнал.
Зайдем со стороны RACF; как я понял из его документации, можно создать новый класс ресурса для определенных бизнес-сущностей. Непонятно, как этим дальше пользоваться для защиты таких ресурсов, для начала — как RACF конкретный ресурс идентифицирует, чтобы какие-либо правила доступа применять.
Это все определяется на уровне менеджера ресурсов, не на уровне RACF. Менеджеров ресурсов может быть бесконечное множество, а RACF один. Им лишь задается некая схема защиты ресурсов и обеспечиваются типовые функции для верификации (интерфейс RACROUTE). Как это используется менеджером ресурсов зависит только от него одного. Я думаю когда Вы ознакоминеть в Securing DB2 Вам станет понятнее.
Макрос RACROUTE позволяет делать запись о ресурсе в RACF, но вы говорите, что не пользовались RACROUTE, — видимо, это не является типовым способом решения моей задачи.
Записи о ресурсах называются профили. Их из программ, в данном случае менеджеров ресурсов, не создают. Они создаются в процессе инсталяции и использования вне менеджера ресурсов. Иначе какой смысл? Назовем это секьюрити полиси, или список правил, защиты ресурсов которые хочет пользователь, а не разработчик менеджера рессурсов. Разработчик должен обеспечить правильные обращения к RACF и правильную реакцию на ответы RACF.
(Для DMSFS есть специальный атрибут: "When a user has the ADSP attribute, RACF always automatically creates a discrete profile every time the user defines a permanent DASD or tape data set".)
Это немного про другое. Вы "залезли в дебри" специфического менеджера ресурсов коим является DFSMS. Я даже не знаю что и сказать без обращения к маниуалу DFSMS по поводу ADSP, кроме того что это разумно создавать. Не стоит увлекаться частностями пока не будет понят более общий подход к контролю доступа.
Вот объяснение ADSP в RACF команде ADDUSER:
ADSP
Specifies that all permanent tape and DASD data sets created by the new user are to be automatically RACF-protected by discrete profiles. ADSP specified on the ADDUSER command overrides NOADSP specified on the CONNECT command.
If SETROPTS NOADSP is in effect, RACF ignores the ADSP attribute at logon or job initiation.
NOADSP
Specifies that the new user is not to have the ADSP attribute. NOADSP is the default value if you omit both ADSP and NOADSP.
Я с этим еще не сталкивался, но вижу что это может быть логично, но полагаю это работает только когда нет predefined generic profile. Что может быть и нежелательно, по сравнению с generic profiles. Надо читать более подробное описание как это работает. в любом случае это не то что Вам нужно.
Как обеспечивается, чтобы операции пользователя, запущенные через API, выполнялись с правами учётки этого пользователя?
Это очень интересный вопрос. Есть два подхода к доступу БД на МФ. Через ODBC data source, где надо проставить UserId и пароль. Грубый тупой способ. Или использовать DB2 клиента с укзанием использования RACF (в WebSphere это граммотно сделано). Тогда это будет выполнятся так как Вы пишите, т.е. "с правами учётки этого пользователя".
Во-первых, нужен какой-то механизм имперсонации. Во-вторых, и это главное, программа-сервер должна не забывать эту имперсонацию делать, иначе получим, что все принадлежит де-факто служебному пользователю.
Только сегодня читал про эту имперсонализацию. С ходу не понял зачем так хотя во введении к описанию так и была поставлена проблема что программа-сервер должна исходить из прав клиентского аккаунта, а не прав программы-сервера. Хотя, если говорить о БД, то в каждой из них есть SQL оператор GRANT, или аналогичный, для прав пользователя на объекты БД (таблицы, etc...).. DB2 всегда имеет дело с аккаунтом клиента. В то время как аккаунт программы-сервера имеет права на объекты системы в которых хранятся объекты БД. В случае с DB2 наборы данных.
(Не могу найти статью про приложения "зеленого экрана" для МФ. В любом случае, такой интерфейс не во всех случаях подходит: иногда нужен HTTP для стандартного взаимодействия, иногда нужен богатый UI с графикой.)
"Зеленый экран" это терминал (тип устройства 3270), который управляется через системный ввод-вывод также как и ввод-вывод на диски, ленты и любое другое внешнее устройство МФ. Это не клиент-сервер который коммуницирует через сеть, по протоколу TCP/IP (хотя на самом деле 3270 эмуляторы нынче, и давно, как правило коммуницируют через TCP/IP, но только как транспорта. TCP/IP на МФ, "превращает" трафик по IP в стандартный ввод-вывод МФ. Приложениями такими являются TSO, CICS, NetView. Кстати даже в рамках символьного 3270 интерфейс может быть достаточно удобным для работы, не для игр конечно:
Есть много клиент-сервер приложений с GUI для МФ чеоез браузер. Более того, сегодня можно полностью управлять z/OS через такие приложения. Но такие как я предпочитают 3270.
Итого мне видится, что для типичного клиент-серверного приложения с РСУБД на бэкенде контроль доступа не получается сконцентрировать в RACF (да и вообще RACF тут будет только для аутентификации). Например, SAF+RACF нельзя задействовать как security reference monitor
Это все не верно. Но продолжим завтра. Смотрим Securing DB2 manaul,там все написано. Поздно. Спасибо за диалог.
Например, SAF+RACF нельзя задействовать как security reference monitor (с интересом слежу за тредом про EAL), если захочется сертифицировать свое приложение, хотя для ОС он таковым является.
Как то очень витеивато сказано, требует расшифровки. Так все же является RACF security reference monitor-ом или нет? Ответ да, является. Что означает "если захочется сертифицировать свое приложение" в связи с RACF не очень понятно.
Не имею никакого опыта с AD DS, но тоже предполагаю, что для произвольных бизнес-сущностей ACL не применяют из-за тех же примерно проблем, что описаны выше для RACF,
Это Вами описанные проблемы RACF, но не действительно существующие проблемы. Их нет. Просто Вы еще не знаете всех возможностей и как это сделано. Я всячески стараюсь и буду стараться помогать Вам в этом, но, пожалуйста, не спешите делать выводы. Для вас еще очень рано.
Ну, а сначала слова, что если есть возможность расширять системную логику, значит, она "неполноценна/ущербна", а потом — что в z/OS полно exits и ими пользуются, звучали как двойной стандарт.
Тут надо отделять мух от котлет, кмк. Да могут быть и много программ выхода для того чтобы особо продвинутый пользователь мог добавить к тому что дается из коробки, или изменить то как дается из коробки на то что надо.
Неполноценность/ущербнрсть начинается тогда когда из коробки получаешь благие намерения создателей ОС, а чтобы из них сделать что-то достойное надо попотеть. И никто в итоге этим не заморачивается, или каждый делает какого то своего уродца.
В случае z/OSи RACF мы имеем законченый продукт для безопасности/секьюрити, не требующий никаких дописок на основе программ выхода. Да и сами эти выходы скорее чтобы отмазатьсяч от сильно дотошных пользователей (я много таких встречал) которым можно ответить: "Хочешь добавить свои хотелки, вот прграмма выхода - дерзай". И уверю Вас таких на деле мало остается, дай бог бы все что дает RACF освоить и внедрить правильно. Выходы это уже изыски какие то.
А вот то что мы имеем в Windows и Linux очень сильно не дотягивает до RACF. Но зато есть "функции". Дерзайте, мол, ребята пишите свой RACF.
Наличие выбора — не бардак. Я говорю о том, что RACF может не быть в системе (если это то, что имеется в виду под "optional"), и даже если он есть, то не все сценарии покрывает, и это позволяет развести бардак. Собственно, Security Server RACF Security Administrator's Guide (Ch. 2) так и говорит, что RACF не панацея, а главное — отношение к безопасности.
Optional значит что если не RACF то ACF2, ACF3, or TopSecret. Optional в Z/OS являются не только RACF. Многие возможности формально считаются опциональными, но как то так получается что все они заказываются и используются.
Не думаю что где-то есть установка z/OS без всех опциональных компонент. В zVM есть GCS (Group Control System), который есть минимальный MVS для приложений (в первую очередь VTAM) для виртуальной машины. В этом случае, например, безопасность осуществляется zVM, и опять же RACF.
Вы этот фрагмент имели в виду говоря "не панацея"?
Management's decision to install RACF is not, by itself, enough to ensure adequate security at your location. Indeed, if management were to ignore security concerns after simply selecting any software protection package, the eventual result would most likely be the failure of the security undertaking.
В переводе на русский это звучит вот так:
Решение руководства установить RACF само по себе недостаточно для обеспечения надлежащего уровня безопасности вашего объекта. Более того, если бы руководство игнорировало вопросы безопасности, просто выбрав любой пакет защиты программного обеспечения, конечным результатом, скорее всего, стал бы провал всего проекта по обеспечению безопасности.
eBPF тоже для особых случаев. Я писал про них, когда еще не прочитал об exits, как о технологии, позволяющей обеспечит максимальную гибкость и гранулярность правил доступа.
Да, для особых, ностолько что для 90% случаев не имеет никокго смысла:
eBPF (extended Berkeley Packet Filter) is a revolutionary technology within the Linux kernel that allows for the execution of sandboxed programs in a privileged context, such as the operating system kernel. It is a secure and efficient way to extend the capabilities of the kernel at runtime without requiring modifications to the kernel source code or the loading of kernel modules.
В z/OS (точнее MVS) есть такой механизм (revolutionary, никак не меньше) называется подсистема (subsystem). Этот механизм позволяет "without requiring modifications to the kernel source code" расширить "the capabilities of the kernel". Этот механизм появился до появления Linux.
Но какое это имеет отношение к нашим коллоквиумам по RACF?
Да, для особых, ностолько что для 90% случаев не имеет никокго смысла:
Знаете, что такое "особый"? Думаю, 90% еще заниженная оценка, если брать все системы. Зато, когда eBPF имеет смысл, на нем вырастают целые бизнесы (Cilium, G-core и CloudFlare во многом).
Этот механизм позволяет "without requiring modifications to the kernel source code" расширить "the capabilities of the kernel".
Не процитированное в eBPF ключевое, а "secure and efficient way". Ядро в момент загрузки eBPF-программы проверяет, что программа не зависнет и не упадет. Это резко снизило порог входа для наблюдения за ядром и модификации его поведения, как в плане требований к людям, так и в плане готовности компаний пробовать на продакшне.
Но какое это имеет отношение к нашим коллоквиумам по RACF?
Никакого. eBPF LSM hooks былы упомянуты в контексте того, какие возможности есть в Linux, потому что про аналог, RACF exits, в статье не упоминалось.
Никакого. eBPF LSM hooks былы упомянуты в контексте того, какие возможности есть в Linux, потому что про аналог, RACF exits, в статье не упоминалось.
Ничего общего между RACF и "eBPF LSM", равно как и между RACF exits и "eBPF LSM hooks" нет, от слова совсем. Вы это притянули за уши и это Ваш выбор. Реальность совсем другая.
Вчера я ушел спать вот на этом месте:
Итого мне видится, что для типичного клиент-серверного приложения с РСУБД на бэкенде контроль доступа не получается сконцентрировать в RACF (да и вообще RACF тут будет только для аутентификации).
Написал что это не верно, и ушел.
Вот объясните мне Вашу логику почему "для типичного клиент-серверного приложения с РСУБД на бэкенде контроль доступа не получается сконцентрировать в RACF"? Почему для такого типичного клиент-сервер приложения как WebSphere это получается, а для вашего, типичного, нет?
Что Вы понимаете под клиентом и бэкэнд? Что происходит на клиентской стороне и что на бэкэнде. Кмк, все значимое происходит на бэкэенде. Значимое в смысле, хотя бы, данных в БД. В самом деле если даже БД окажется на клиентской стороне, то про клиент-сервер говорить не приходится.
А нормальным для МФ варианта является размещение и WebSphere со всеми ее AS на МФ. Тогда вообще роль клиента своидится к предоставлению так или иначе идентификатора. И все. Все остальное происходит на бэкэнде: МФ, z/OS, DB2, WebSphere и RACF. На клиенте браузер и сам клиент.
А вот смысла (да и механизма как) что "RACF тут будет только для аутентификации" я себе представить не могу. Расскажите. Интересно. А где по-Вашему будет все остальное? Как?
Дополнение к ранее прописанным сведениям про Security Labels в DB2. Эти метки существуют не только в DB2 как таковом но и в RACF, точнее именно в RACF они и определяются. А связущим звеном является профиль пользователя в котором может быть (может и не быть) т.н. Security Label:
SECLABEL(security-label)
Specifies the user's default security label, where security-label is an installation-defined security label name that represents an association between a particular security level and zero or more security categories.
If the user does not enter a security label when entering the system, and none is assigned based on the user's port of entry, this value becomes the user's current security label.
A security label corresponds to a particular security level (such as CONFIDENTIAL) with a set of zero or more security categories (such as PAYROLL or PERSONNEL).
When no profile exists in the SECLABEL class for security-label, the ADDUSER command fails and the user is not added.
А это про security levels, тоже задается при создании юзера и хранится в его прифиле:
SECLEVEL(security-level)
Specifies the user's security level, where security-level is an installation-defined security level name that must be a member of the SECLEVEL profile in the SECDATA class. The security-level that you specify corresponds to the number of the minimum security level that a user must have to access the resource.
When you specify SECLEVEL and the SECDATA class is active, RACF adds security level access checking to its other authorization checking. If global access checking does not grant access, RACF compares the security level allowed in the user profile with the security level required in the resource profile. If the security level in the user profile is less than the security level in the resource profile, RACF denies the access. If the security level in the user profile is equal to or greater than the security level in the resource profile, RACF continues with other authorization checking.
В вашей теории не хватает еще подхода к изменениям, т.е что бы что-то поменять, нужно запланировать изменения - миграцию, обеспечить обратную совместимость к примеру возьмем exchange - что бы заменить в большой компании безболезненно нужно много учесть всего - так может бахнем и начнем с нуля ?!
Тут больше догадок и пальцем в небо, нужно дать время стабилизировать текущую ситуацию командам, так как важно поставить на рельсы (крыло) операционную работу, дальше ребята будут разгребать и догонять до уровня который был. А лупить кнутом можно и дворника, а зачем ?!
Поздно пить Боржоми когда почки отказали….мы лишь можем созерцать текущее и делать выводы на опыте коллег по цеху …, что бы не наступить на такие же грабли…
В моей "теории" (это самая что не на есть практика на самом деле) есть место для переноса приложений Unix, практически простой компиляцией исходников компилятором МФ. С языка С, Java.
Есть в ней и место модным нынче контейнеризированым (тьфу, еле дописал, поди с ошибками) приложением, Докерная технология поддерживается в z/OS.
Есть место приложениях Enterprise Java beans, в WebSphere for z/OS.
DB2 for z/OS понравится и легко на нее перейдут программисты с Оракл и MS SQL, да и вообще в люьой другой RDMS.
Призом будет мощная, надежная, безопасная и устоичивая, компактная!!! система по цене меньше потерь Аэрофлота за один вчерашний день (пишу 29 июля). Да еще и можно сильно сэкономить на персонале, которого в случае МФ потребуется гораздо меньше чем на х86.
Есть решения, которые работали годами , есть решения под разные операционные системы …. Не бывает плохого языка программирования, не бывает плохой программы, вопрос в применение того или иного к текущим реалиям и требованиям, за модой не угнаться…. Я понимаю Вас, но есть много других факторов… это как разные повара по разному готовят одно и тоже блюдо
все что может быть использовано для неправомерной деятельности, или несанкционированного доступа к информации) при появлении запроса от кого или чего-либо обращается к SAF для проверки легитимности поступившего запроса. Ключевое слово КАЖДОГО.
Даже в связке Windows / SQL Server происходит всё примерно так же. Задача в том, чтобы эта самая проверка легитимности была настроена.
Это весьма краткое введение в состояние компьютерной безопасности z/OS.
Это всё здорово, но ИТ-инфраструктура компании, это нечто намного большее, чем один навороченный мейнфрейм на z/OS. Ваша z/OS не роутит трафик внутри компании, не содержит корпоративную файлопомойку, не хостит почтовые сервера, не хостит веб-сайты, не хостит файрвол, и ещё много чего не хостит, и не будет.
Это всё здорово, но ИТ-инфраструктура компании, это нечто намного большее, чем один навороченный мейнфрейм на 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 известен своей масштабируемостью, функциями безопасности и поддержкой различных сред развертывания, включая локальные и облачные.
и ещё много чего не хостит, и не будет.
Если Вы прочитали все выше возьмите эти Ваши слова обратно и не смешите людей. Всего Вам самого наилучшего. А особенно любознательности. Она спасает от позора невежества.
Если Вы прочитали все выше возьмите эти Ваши слова обратно и не смешите людей. Всего Вам самого наилучшего. А особенно любознательности. Она спасает от позора невежества.
Извините, но дело в том, что я работал в компаниях, использующих пусть не z/OS, но iSeries. Поэтому нет, я как раз прекрасно знаю, о чём я говорю.
Во-первых, да, вы правы, мейнфрейм - штука гибкая и многофункциональная. Но слишком дорогая для утилитарных вещей. Файлопомойка и почта на нём, это примерно как золотой унитаз. Работает, но стоимость не оправдывает назначение.
Во-вторых, что касается управления трафиком в компании, так на мейнфрейме это в принципе организовать невозможно, хоть сто виртуальных хостов там подними. Потому что у вас сетевых карт 4 штуки с двумя портами, а в офисе тысячи точек подключения и несколько внешних каналов, и филиалы. Поэтому будут у вас стоять те самые циски, а может, и не циски, везде, со всеми вытекающими..
Во-третьих, все эти виртуальные машины на линуксах, это машины на линуксах. Со всеми их известными и неизвестными уязвимостями.
Поэтому не надо бросаться громкими словами. Просто вы полюбили один инструмент, и в упор не хотите видеть естественных рамок его применения. Ах, какой у меня классный микроскоп, я могу и амёбу рассмотреть, и костёр от Солнца разжечь, и гвоздь забить.
Извините, но дело в том, что я работал в компаниях, использующих пусть не 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 многие эти уязвимости нивелируют, купируют и отменяют.
Поэтому не надо бросаться громкими словами. Надо изучать матчасть и знать. А не гадать на кофейной гуще. Я серьезно желаю Вам во всем разобраться и готов помочь.
Кстати только согласился с Вами и поняд что и тут Вы неправы. Даже при 100% загруженности на МФ остаются не использованые циклы для малоприоритетных работ
Файловые хранилища, это не про процессор, это про дисковое пространство и каналы ввода-вывода.
Принципиально не верное понимание. 4 штуки с двумя портами это на самом мааааленьком из возможных МФ
Ну сколько их там будет? 64 штуки? И что это поменяет?
Если кто-то любит медь в наши дни, то да понадобятся свитчи, как концентраторы и переключатели.
Ну так, минуточку, 100% пользователей мейнфремов любят медь в наши дни. Это бизнес размером с рекламное или там туристическое агентство может обойтись вайфаем. А крупный бизнес, это не только кучка серверов в комнате, а везде ноуты и планшеты. Элементы СКУД, камеры, производительные МФУ, рабочие станции - всё это до сих пор соединяется медью. Да и даже для ноутов и планшетов, точки доступа вайфая у вас в крупном офисе отнюдь не через mesh будут соединены, а по-старинке, медью.
виртуальные машины под zVM многие эти уязвимости нивелируют, купируют и отменяют.
Ваш рабочий софт-то вы где возьмёте под zVM?
Файловые хранилища, это не про процессор, это про дисковое пространство и каналы ввода-вывода.
Тем более, ввод-вывод на МФ всегда имеется с излишком относительно мощности центрального процессора.
Ну сколько их там будет? 64 штуки? И что это поменяет?
А что Вы ожидается чтобы поменялось? 128 портов? Или 256?
Ну так, минуточку, 100% пользователей мейнфремов любят медь в наши дни.
Это вы про меня? Я сижу дома, работаю с МФ через интернет. Если, как я намекал, подключить МФ к интернету, хотя бы одним портом, то с МФ можно будет работать многим пользователям как бы они ни были подключены к интернету.
Ваш рабочий софт-то вы где возьмёте под zVM?
Какой мой рабочий софт Вы имеете в виду? Мой рабочий софт для работы с МФ это эмулятор 3270.
Я сижу дома, работаю с МФ через интернет.
Кстати, как именно? Это МФ одним портом торчит прямо в Интернет с публичным адресом?
Насколько я понял, нет. Если действительно нет, то почему?
Совершенно необязательно чтобы что-то там торчало в интернет.
Есть внутренняя сеть. В ней есть виртуальные рабочие места (через VDI) И вот на этом рабочем месте уже можно запустить терминал к тестовому серверу. В нашем случае - софтверный эмулятор терминала 5250.
Чтобы со всем этим работать хватает самого слабенького компа. У меня под это выделен отдельный старый ноут Samsung NP300 с древним двухядерным Celeron B820 1.7ГГц, 8 Гб памяти и 512Гб SSD. Работает под Linux Mint. Там, собственно, на нем нужно запускать только VMWare Horizon Client и все.
Есть еще второй ноут, помощнее, под виндой. Там через VPN есть доступ до внутренних Jira/Confluence/Bitbucket/Jenkins/Artifactory/KTalk/RocketChat/CiscoJabber. Но к серверу - только с виртуалки через VDI (на ней, в принципе, можно полноценно работать, но мне удобнее на основном, а с виртуалки только то, что требует работы непосредственно с сервером).
То, что так можно (и нужно) - это понятно.
Но в данном топике речь шла о "заменить все на МФ, чтобы стало безопасно", а вы предлагаете всякие дополнительные решения.
А если делать по уму, через эшелонированную защиту, и без МФ хорошо защищено будет :)
Ну я не говорю что все менять надо. Я говорю что все это вполне реально. И у нас так сделано изначально было.
А дураков учить надо. И если он не понимает иначе как дубиной по лбу - значит учить дубиной по лбу.
Резонное замечание. Да хотелось бы чтобы даже в одиночку МФ мог заменить Дата Центр. Чисто теоритически why not.
У МФ есть т.н. Open System Adapter (OSA) card, это своего рода раутер. В софтвере z/OS есть fair wall (IPSec), IDS. Конечно грузить z/OS функциями защиты от нападений из Интернета не есть хорошая идея. Но зачем то этим фукции существуют. От нападений в LAN?
Я не силен в той части networking что непосредственно в Интернет смотрит (proxy server надо полагать), и допускаю что понадобится некоторое оборудование дополнительно к имеющемуся на МФ. Это оборудование можно добавить в саму стойку МФ в имеющиеся стандартые свободные слоты.
А если делать по уму, через эшелонированную защиту, и без МФ хорошо защищено будет :)
Вот в том и беда что по уму сделать без МФ не получается. Другими словами то что надо сделать по уму в МФ (z/OS) это то как только и можно сделать. И здесь не только сетевые компонеты имеются в виду, но и как устроено внутри системы (z/OS) тоже.
Я могу гарантировать что если МФ открыить принимать трафик из Интернет т.е. TCP/IP то никакие хакеры ничего сделать не смогут в смысле разрушения или кражи информации. я даже могу дать юзер айди и пароль, м даже доступ к скажем TSO и место на диске. Ничего криминального и в этом случае сделать на МФ не получится.
Кстати ИБМ предоставляет доступ к своим МФ для студентов. Пожалуйста заходите, что хакеру прикинуться студентом? не вопрос.
Вот например об этом:
https://mainframenation.com/mainframe/how-to-get-a-mainframe-access/
Кстати ИБМ предоставляет доступ к своим МФ для студентов. Пожалуйста заходите, что хакеру прикинуться студентом? не вопрос.
Не МФ, но "для начала" можно попробовать "что попроще" - регистрируемся на PUB400, получаем валидный профайл, заходим и пробуем сломать его изнутри. Для начала хотя бы увеличить себе лимит дискового пространства и лимит на количество личных библиотек.
Кстати, как именно? Это МФ одним портом торчит прямо в Интернет с публичным адресом?
Насколько я понял, нет. Если действительно нет, то почему?
В моей компании МФ не "торчит" в интернет с публичным адресом. Но такая возможность у МФ есть и она задокументирована в соответствующем руководстве. Честно говоря не смог пока найти строгих подтверждений этому утверждению. Есть и так и не так. В одних местах пишется LAN в других WAN тоже. Странно. Буду искать.
Ну допустим нет такой возможности чтобы МФ "торчал" в Интернет. Но через корпоративную VPN (хотя в софтваре z/OS в TCP/IP есть функция VPN) с ним можно работать.
Тем более, ввод-вывод на МФ всегда имеется с излишком относительно мощности центрального процессора.
И дисковое пространство, что ли? По какой цене за терабайт?
А что Вы ожидается чтобы поменялось? 128 портов? Или 256?
Ну, например, 2048 портов, доступных по всему зданию. Это средних размеров офис, этажей пять.
Это вы про меня?
Нет, про вашу компанию в целом. Сидеть дома с удалённым терминалом, это было доступно и четверть века назад, когда это не было мейнстримом, и даже полвека назад. Но у вас наверняка кроме горстки ИТ-шников, есть целая армия пользователей, которым такая роскошь не доступна.
Какой мой рабочий софт Вы имеете в виду?
О, самый разный. Вы можете, например, в терминале 3270 набрать и отправить служебную записку? А хотя бы мессенджер у вас там есть? И это вы, человек, работа которого непосредственно вокруг мейнфрейма вертится. А что говорить про других пользователей, которые занимаются продажами, рекламой, логистикой и так далее.
И дисковое пространство, что ли? По какой цене за терабайт?
Тоже самое пространство что и х86 сервера используют можно подключать к МФ (SCSI протокол) через FCP, который на МФ поддерживается FICON cards.
Конечно для МФ надежности такие варианты плохо подходят, по нормальному нужна диски с RAID-5, типа Dell VMAX или PMAX, которые кстати у нас используются и для МФ и для х86 серверов (SAN).
Нет, про вашу компанию в целом. Сидеть дома с удалённым терминалом, это было доступно и четверть века назад, когда это не было мейнстримом, и даже полвека назад. Но у вас наверняка кроме горстки ИТ-шников, есть целая армия пользователей, которым такая роскошь не доступна.
Это было доступно гораздо раньше. Сидеть дома и через VPN конектиться к МФ может любой из нашей компании с более чем 10 000 сотрудников.
О, самый разный. Вы можете, например, в терминале 3270 набрать и отправить служебную записку? А хотя бы мессенджер у вас там есть? И это вы, человек, работа которого непосредственно вокруг мейнфрейма вертится. А что говорить про других пользователей, которые занимаются продажами, рекламой, логистикой и так далее.
МФ это не персональное устройство, это сервер, бэкэнд. На каком бэкэнд х86 сервере у Вас есть мессенджер?
Я пользуюсь естественно не только МФ, да и не пользуюсь я им, а обеспечиваю других им. У самого у меня на МФ нет ничего кроме того что нужно МФ и пользователям МФ. Это очевидно. Это даже смешно объяснять.
Ну, например, 2048 портов, доступных по всему зданию. Это средних размеров офис, этажей пять.
Я уже говорил про свитчи, концентраторы, мультиплексоры. Помню на ВЦ ЖД в зале рядом с ЕС 1045 стоила пара мультиплексоров с кучей проводов разходящихся по всей ЮУрЖД с одной стороны и одним кабелем подключенным к одному каналу EC 1045. Все это давно решено, сейчас гораздо мощнее. 2048 медных можно легко превратить, скажем в 4 fiber optic:
OSA-Express cards can connect to fiber optic cables, enabling high-bandwidth and long-distance data transmission.
Тоже самое пространство что и х86 сервера используют можно подключать к МФ (SCSI протокол) через FCP, который на МФ поддерживается FICON cards.
Ок, принимается :)
Это было доступно гораздо раньше. Сидеть дома и через VPN конектиться к МФ может любой из нашей компании с более чем 10 000 сотрудников.
Это не важно, все равно же большинство сидит в офисе, разве не так?
МФ это не персональное устройство, это сервер, бэкэнд. На каком бэкэнд х86 сервере у Вас есть мессенджер?
А я ничего и не говорю про серверы. Я говорю про устройства. Вам на работе нужен мессенджер, значит, у вас будет х86 или там ARM-устройство в качестве терминала, оно будет с какой-то там общеизвестной ОС, оно будет физически в вашей корпоративной сети, и о-па, оно будет уязвимой точкой входа эту самую сеть.
Я уже говорил про свитчи, концентраторы, мультиплексоры.
Да. И многие из них - управляемые, а значит, подверженные уязвимостям.
Вот и ответ, почему вашего одного МФ никак не хватит, чтобы сделать вашу сеть безопасной. Клиентских и вспомогательных устройств у вас все равно будет масса.
Это не важно, все равно же большинство сидит в офисе, разве не так?
Вы что в самом деле считаете что каждый пользователь дорлжен быть напрямую подключен к МФ чтобы с ним работать?
оно будет с какой-то там общеизвестной ОС, оно будет физически в вашей корпоративной сети, и о-па, оно будет уязвимой точкой входа эту самую сеть.
В сеть может быть, но не на МФ, а если и на МФ то с настолько органиченным доступом что только тихонько попёрдывать удастся.
Кстати несколько лет назад я обнаружил что в нашей сети есть злоумышленник, который пытается зайти на МФ с разными аккаунтами похожими на то что могло бы быть на МФ.
Оказалось это наши ИБ-шники запускают какой то сканер потенциальных дырок, который видимо нашел IP и порт МФ и давай всякие имена подбирать. Я заблокировал IP этого ихнего сервера.
Вы что в самом деле считаете что каждый пользователь дорлжен быть напрямую подключен к МФ чтобы с ним работать?
Я считаю, точнее, утверждаю, что каждый пользователь - это клиентская машина, которая может стать точкой взлома вашей корпоративной сети, совершенно не зависимо от того, насколько красивую систему безопасности вы выстроили на МФ.
В сеть может быть, но не на МФ, а если и на МФ то с настолько органиченным доступом что только тихонько попёрдывать удастся.
А у вас в сети нет, что ли, пользователей, имеющих несколько больше привилегий на МФ? Руководителей, разработчиков, администраторов? А если есть, они входят туда не с таких же клиентских машин, как и все остальные?
Я считаю, точнее, утверждаю, что каждый пользователь - это клиентская машина, которая может стать точкой взлома вашей корпоративной сети, совершенно не зависимо от того, насколько красивую систему безопасности вы выстроили на МФ.
Взломанная клиентская машина не значит взломаный МФ.
А у вас в сети нет, что ли, пользователей, имеющих несколько больше привилегий на МФ? Руководителей, разработчиков, администраторов? А если есть, они входят туда не с таких же клиентских машин, как и все остальные?
Несколько больше чем какие? Входят с клиентских машин, и что?
Вы продолжаете настаивать что взлом каких то машин означает взлом МФ. Это не так, да и на машинах, с которых заходят на МФ с максимальными привелегиями не лохи сидят, чтобы их можно было бы легко взломать. Взламывают лохов, не граммотных пользователей с чьими правами на МФ ничего сделать не возможно.
Взломанная клиентская машина не значит взломаный МФ.
Нет, конечно. А также не означает взломанный виндовый сервер, и не означает разваленную инфраструктуру Аэрофлота. Но со взлома произвольной клиентской машины легко начинается атака на всю сеть.
Вы продолжаете настаивать что взлом каких то машин означает взлом МФ.
Ну зачем вы придумываете за меня какую-то несуразицу, которую я никогда не писал, и даже не намекал на это? Я везде писал про взлом корпоративной сети, и много раз это повторял. Естественно, взломав один произвольный компьютер, вы не потрёте DB2 на МФ, равно как и не потрёте MS SQL Server. Но вы получите какой-то доступ в сеть, и можете начать сбор информации о ней. Имея доступ к сеть, у вас уже будет намного проще задача взломать второй компьютер, третий, четвёртый. На какой-то из них когда-то зайдёт инженер техподдержки (да вы даже сами сможете его пригласить, снеся юзеру что-нибудь нужное для его работы), и вот у вас уже более продвинутые права саппорта, вы можете смотреть системные логи, управлять сессиями пользователей и так далее. А от прав саппорта недалеко добраться и до админских сессий. И вот через какое-то время нахождения в сети у вас будут и креды для МФ.
... скажет через губу " Моя программа требует системный доступ." ...
Как это решают на мейнфреймах? Поставщик требует системного доступа для своей программы, работа уже оплачена, другого поставщика нет. Что же делать?
На МФ "поставщики" знают что системного доступа у них не будет, Поэтому пишут программы с учетом этого. Конечно никто не запрещает им сформулировать более адекватные требования и они безусловно будут удовлетворенны. В z/OS поставщик может даже встроить свою "подсистему", т.е. нечто выполняющееся на уровне полномочий ядра. В пользовательской программе, под контролем, можно даже перейти в состояние супервизор. У меня есть такие программы, самописные. Но все это под контролем и дозированно делается по реальной необходимости. А не чёхом. И при этом не появятся дырки через которые смогут залезать хакеры. Все довольны.
На МФ "поставщики" знают что системного доступа у них не будет,
Ну так на Windows/Linux тоже, все программы, кроме собственно системных, работают с ограниченными привилегиями. Только дремучее легаси требует повышенных привилегий. Хакеры пролезают не потому, что какая-то программа вот вообще никак не хочет работать не от системного пользователя. Основные векторы атак - это ошибки в распространённых библиотеках. OpenSSL вон года три с уязвимостью нулевого дня сидела, а сколько такого ещё не выявлено?
z/OS здесь безопаснее не потому, что в ней там нет уязвимостей, а потому, что их некому искать. Установленная база машин невелика, круг имеющих доступ к ним также невелик, круг имеющих доступ, квалификацию, время и желание искать уязвимости примерно равен нулю.
z/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.
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.
Обратите внимание на упоминание American Airlines ниже. Очень актуально для этой моей статьи, не так ли?
Нет, просто совпадение. В мире есть многие тысячи авиакомпаний, ни сном, ни духом не ведавшие про мейнфреймы, и прекрасно обходящиеся без них. В том числе и с точки зрения безопасности. МФ в American Airlines, как и в ряде других старых и крупных авиакомпаниях - это просто исторически прижившаяся штука, они компьютеризировали свой бизнес ещё тогда, когда это была единственная форма компьютеризации.
Банкинг, то особая тема, там есть готовые решения "из коробки" как раз под i/OS, z/OS, такие как Midas, Arksys и иже с ними. Ну т.е.это тот самый случай, когда ты берёшь машину и софт, и оно сразу решает задачи твоего бизнеса.
Решения для авиакомпаний на мейнфреймах какие-то есть, но насколько я знаю, они все половинчатые и требуют значительных усилий по доработке и интеграции.
Бесполезная рекламная статья, переспамленная поисковыми запросами.
точно. во всей статье нет ни намёка на тему в заголовке "что было бы"
Это было оставленно на усмотрение читателя. Поэтому в статье два раздела с обзоров средств защиты. Прочитав которые читатель в праве ответить на "что было бы". К сожалению шансов иметь МФ в России очень мало. 30 лет с упорством достойным лучшего применения в России выкорчевывались МФ-ские скилсы и применения.
Критиковать задним числом оно всегда проще.
Автор так упорно указывает, что именно на x86 одни проблемы с безопасностью, что создаётся впечатление, что это проблема самого x86 а не софта на нём. Следует ли при этом понимать, что на IA64 или ARM всё круто и безопасно? Вопрос риторический.
создаётся впечатление, что это проблема самого x86 а не софта на нём
У x86 и вообще любой фон-неймановской машины действительно есть фундаментальная проблема безопасности — единая память для команд и данных. Из-за этого на них так опасно переполнение стека. Теоретически это можно было исправить, если бы процессор на уровне декодера инструкций выполнял только команды подписанные определёнными ключами, но увы это вероятно негативно сказалось бы на производительности, и (что возможно ещё хуже) программы для машины было бы невозможно собрать на этой же самой машине.
У современных х86 уже достаточно методов защиты памяти (это по сравнению с базовым i386). Просто отучите компиляторы организовывать фрейм данных в стеке. Раньше это было оправдано, сейчас же организовать кучу отдельно от кода вполне реально. Тем более всё равно сам код к данным получает доступ через соответствующие сегментные регистры. Опять же, у х86 есть как CS так и SS, но вот такое поведение сразу нивелирует всю задумку инженеров:
У x86 и вообще любой фон-неймановской машины действительно есть фундаментальная проблема безопасности — единая память для команд и данных.
Признак, аппаратно запрещающий выполнение кода на страницах данных, в х86 появился этак четверть века назад.
У x86 и вообще любой фон-неймановской машины действительно есть фундаментальная проблема безопасности — единая память для команд и данных. Из-за этого на них так опасно переполнение стека.
Не любой. На МФ такой проблемы нет, так как нет стека. Это проблема машин c аппаратной реализацией стека.
Автор так упорно указывает, что именно на x86 одни проблемы с безопасностью, что создаётся впечатление, что это проблема самого x86 а не софта на нём. Следует ли при этом понимать, что на IA64 или ARM всё круто и безопасно? Вопрос риторический.
Спасибо за вопрос. Вопрос вполне заслуживает реакции. Вот фрагмент из самого начала статьи:
Как специалист ИТ, работавший/работающий, в том числе, с компьютерной безопасностью на ИБМ МФ (z/OS) и интересовавшийся этими вопросами в случае серверов на х86 на уровне системного программирования в Microsoft Windows, сразу могу сказать, да, выстроить надежную систему информационной безопасности можно хоть на чем.
Но только теоретически. На практике, практически всегда, теоретическими возможностями защиты ПО на х86 пренебрегают. Причем это идет не столько от ИТ-шников, и даже может быть не от ИБ-шников (к чьим возможностям и способностям я очень критически отношусь потому что, работая в большой компании с порядка 400 человек в ИТ, я часто пересекаюсь с действиями ИБ-шников по вопросам их ролей и они меня зачастую умиляют), а от самого руководства бизнесом.
Половина статьи посвещена средствам безопасности х86. Они есть, но их не используют.
Конечно в перую очередь это проблема софта и в первую очередь ОС. ОС на х86 минималистские, большмнство проблем решается в приложениях в том числе безопасность. Это порочный путь, но этот путь выбран действующими лицами и они упорствуют в том что так и должно быть. Я в этом убедился окончательно, отвечая на комментарии к этой статье.
:-) А что у нас с 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) секунд это смогла...
:-) А что у нас с Oracle под zOS? Концепция уже сменилась? Или м.б. Oracle не та компания которой нужны крупные корпоративные клиенты и у них недостаток ресурсов для портирования новых версий?DB2 - это возможно и хорошо (учитывая что Oracle использовал ее концепции), но... Когда то давно (в начале 2000-х) к нам обратились IBM спецы и заявили что "на раз-два" портируют на неё терминал-сервер приложение написанное под Oracle, и получили наши исходники на PL/SQL. Где то через пол года получили от них информацию - "ну не шмогла я...".
Мое мнение у Оракла не было шансов конкурировать с DB2 под z/OS.
Не знаю кто занимался переводом Oracle PL/SQL на DB2, но явно птицы не высокого полета. Я могу себе представить какие могли быть у ИБМ Россия спецы по DB2 for z/OS. Никакие. Не на чем им было появиться тогда, не было ни почвы ни семян. А если и были то они сидели там где их DB2 и не ходили никуда. И я уже уехал тогда из России.
Кстати, меня русскоговорящие ИБМ-цы пытались вытащить из Челябинска, но их англоговорящему начальнику не понравился мой, никакой, английский. Было это в начале 1998 и я тогда уже 5-6 лет отработал с SQL/DS и DB2/2.
А во второй половине 1998 года я прочитал статью про Оракл (возможно про то какой Оракл хороший и даже лучше чем DB2) в какой то отраслевой брошюре (ЖД?) и позвонил по телефону указанному в статье. Оказалось это работник в представительстве Оракл. Поговорили, еще поговорили. Он предлагает мне пойти на работу в Оракл. Я был абсолютно свободным на тот момент, собирался на Канаду, но без особого энтузиазма, согласился. И наступил август 1998, дефолт. Мне позвонили из Оракл и сказали мол мы сейчас не о расширении, а о сокращении думаем. Вот так я и оказался в Канаде.
Как Вам такое объяснение "ну не шмогла я..."? Это шутка.
Сама z-System (правда работал я со старой z10 и под AIX где Oracle тогда был) штука крутая, но...Была задача как справятся (на реальных тестах прикладного приложения 24/7 и под большой нагрузкой) разные виртуальные системы, в частности SPARC, z и p IBM (все при базе Oracle) с масштабированием количества выделенных для OS(Solaris, AIX)/DB vCPU - уж очень это интересовало наших клиентов. Результаты были "интересные" - только p-System под AIX без "заморозки" всех процессов БД в OS на несколько (2-5) секунд это смогла...
Много тестов подобного рода пришлось мне анализировать за последние 20 лет. Вывод прост. Результаты тестов всегда совпадают с поставленной перед тестом целью. Даже если постановщики бьют себя копытом в грудь мол мы объективные. Получается это и потому что проводят тесты специалисты одного направления, например p-System, а специалистов, например Z, просят сконфигурировать то что им кажется должно быть на Z. Типа, как у нас на p-System, мы же должны сравнивать апплс-то-апплс. Могу ошибаться но не сильно. Много видел таких тестов, последнее время их гораздо меньше стало.
:-) Ну российские спецы IBM по DB2 сразу сказали что пробовать и не будут... Тупо исходники в европейское отделение отправили. А уж кто там занимался - не интересовался. IBM тогда (на фоне спада интереса к DB2) активно продвигал софт типа "автоматической адаптации написанного на PL/SQL под DB2", со словами "наш софт портирует 90% исходников - вам руками останется поправить 10%"....
А вот насчет тестов - вы не очень правы. Я там конечно с "прикладной стороны смотрел", но вендорам всем "вводные давали одинаковые". Не думаю что в Монпелье спецы по системам совсем слабые (что по z что по p-System) и те и другие тюнили системы после начала тестов не слабо. Но... Они же и объясняли сами "почему такой результат". Сам я в Монпелье с ними и общался за пару командировок недели по 3 каждую. На результаты прикладной производительности нашего софта они "смотрели с уважением" когда я им объяснял что делает система, т.к. их же системы работали с другим (но аналогичным) прикладным софтом по всему миру и знали сколько ресурсов "жрет" подобный софт при примерно такой же прикладной производительности.
Интересно что несколько клиентов у нас на p-System еще "сидят", но поддержку 12 Oracle в этом году мы "заканчиваем"....
активно продвигал софт типа "автоматической адаптации написанного на PL/SQL под DB2", со словами "наш софт портирует 90% исходников - вам руками останется поправить 10%"....
В PL/SQL как Вы и сами знаете ничего такого хитрого нет. Это Вам не Адабас или IDMS с их навигационными языками манипулирования переводить в SQL. Я не помню с какого года в DB2 появился свой "PL/SQL" не прямой, но аналог Оракловского.
Но я бы не стал в лоб переводить "PL/SQL" даже в этот аналог. Подходить к эту процессу надо было творчески, но видимо и в Европе не нашдось для вашего кейсов специалитов, Не нашлось не значит что их не было. Кстати а что Вы сами не попробывали?
А вот насчет тестов - вы не очень правы. ....
К тестированию разных платформ надо подходить очень аккуратно. Говорить что что там с "заморозкой" на 2-5 секунды что-то делала, а что-то другое сделало это без "заморозки", это значит не понимать что вы собственно сравнивали.
Результаты были "интересные" - только p-System под AIX без "заморозки" всех процессов БД в OS на несколько (2-5) секунд это смогла...
В любом случае я не берусь комментировать те усилия, но и не могу согласиться что все было сделано корректно, начиная с постановки цели (критерия) тестирования.
Очевидно что p-System и z-Systем это очень разные по суди звери и то что одной доступно на раз-лва-три другой может быть затруднительно, но и наоборот тоже имеет место быть. Возможно ваш критерий был в пользу особенностей Р, но наверняка не только это входило в оценку пригодности. Тестировали ли вы другие критерии тоже, или только один? Была ли возможность у тех кто заряжал Z провести инвестигэйшн и поработать над производительностью в свете ваших ожиданий? Вопросом может быть много и результаты могли бы быть разные. Только так я отношусь к разного рода "тестированиям". Очень скептически. В двух словах они описываться не должны.
DB2 - "жестко" связывает с одним вендором, и инфраструктурой. А компании разработчику софта "хочется" широкого рынка сбыта под требования разных клиентов. Вот по этой причине - Oracle (до определенного этапа), а сейчас еще и PG.
Ситуация с тестами простая. Есть клиенты нашего прикладного ПО (или потенциальные клиенты). Есть поставщики/вендоры оборудования (или комплекса услуг типа IBM/Oracle). Все вендоры заинтересованы в "больших и надежных" клиентах. Клиентам всегда нужно производительность-надежность-масштабируемость-безопасность и по "минимальной цене поддержки/эксплуатации". На это еще "сверху ложатся" скажем так "интересы конкретных людей в компаниях у клиентов". :-)
Вот и получается ситуация когда клиент "говорит" вендору - "Хотите чтоб наша компания стала вашим клиентом? Ну продемонстрируйте на прикладных тестах что вы можете. Синтетика и теория - это одно, а реальные показатели - может быть другое."
Периодически и сама наша компания "ища рынки сбыта" самостоятельно пробует работу нашего прикладного софта под разными платформами, вендорами, OS (предваряя запросы наших клиентов). С разными вычислительными мощностями в различных конфигурациях и т.п.
Иногда приходится "проверять громкие заявления вендоров о прорыве в технологиях" и т.п.
Все вроде бы просто. "Есть требования бизнеса клиента"(это enterprise) - "Есть прикладное решение"(или несколько) - "Есть ресурсы/решения конкретного вендора"(или разных).
До приобретения комплекса бизнес клиента хочет - "А покажите на деле что можете! А что будет если "уронить"? А время восстановления и % потерь? А если у нас завтра бизнес вдвое вырастет? А где логи всех действий в системе (изменений в прикладной базе)? А соответствие PCI/DSS? А интеграция с .....?" Вот на такие вопросы дают ответы тесты (конкретные цели ставит заказчик конечно же)... :-)
Зачастую познавательно слушать "перепалку" спецов вендора по платформе/OS с их же спецами по работе Oracle DB (на платформе/OS) кто из них "накосячил" с конфигурацией системы/комплекса.
DB2 - "жестко" связывает с одним вендором, и инфраструктурой. А компании разработчику софта "хочется" широкого рынка сбыта под требования разных клиентов. Вот по этой причине - Oracle (до определенного этапа), а сейчас еще и PG.
Что мешает иметь версии и для Оракл с PG и для DB2 (причем обоих: for z/OS, and for LUW). Рынок ваш станет еще шире.
Оракл это тоже один вендор, причем весьма капризный и не эффективный в саппорте. Я последние 3-4 года плотно работал и работаю в теме с Оракл, у меня есть аккаунт на их сайте.
После DB2 Оракл выглядит чем-то недоделанным, но одновременно и переделанным. Нет в нем гармонии я бы сказал. Вавилонская башня - вот это что. DB2 совсем другой продукт. Особенно for z/OS, но думаю и for LUW тоже хорош потому что разработан на опыте for z/OS.
Ситуация с тестами простая. ...
Хорошее начало, но дальше Вы написали много из чего становится понятно что совсем не простая. Выбор платформы в ИТ очень не простая тема и никакими тестами с замером временных показателей её не решишь. Даже наоборот.
Ну а по всем наброшенным Вами критериям качества платформы/OS c позиции клиента, а именно:
"А покажите на деле что можете! А что будет если "уронить"? А время восстановления и % потерь? А если у нас завтра бизнес вдвое вырастет? А где логи всех действий в системе (изменений в прикладной базе)? А соответствие PCI/DSS? А интеграция с .....?" Вот на такие вопросы дают ответы тесты (конкретные цели ставит заказчик конечно же)... :-)
МФ выигрывает. На эти вопросы можно и без тестов ответить и показать. "% потерь" например равен нулю.
:-) Вот тесты на реальных приложениях и показывают "что заявлено" и "как по факту".... А выбор (неважно чего) - это всегда "компромис"...
Быстро, качественно, недорого - выбирайте любые два пункта.
:-) Вот тесты на реальных приложениях и показывают
Принципиальный изъян такого подхода (тестирования одного приложения на разных платформах, включая МФ) состоит в том что МФ предназначен для работы многих приложений, и элементов (возможно не всех) инфраструктуры организации. И чем больше приложений и элементов инфраструктуры на одном МФ тем лучше, правильнее и дешевле.
Иными словами намерения использовать целый МФ для одного приложения изначально обречено на провал, по экономическому критерию, не по техническому конечно. Попытки брать самый маленький МФ тоже мало перспективы потому что даже самый маленький МФ уже не мал на самом деле будет и естественно не дешев.
На х86 (мне тут подсказали, правда в невежливой форме (надеюсь накажут грубияна), что х86 это не правильно, но для моих статей это не есть принципиальная разница, я мог бы писать не-МФ), или в облаке можно подобрать, под любое отдельное приложение не-МФ, любую конфигурацию, удовлетворяюшую приложению и это будет дешево. Удовлетворяющую чтобы приложение жило и удовлетворяло наиболее очевидные ожидания клиента. Будет ли это удовлетворительно с точки зрения безопасности, доступности, устойчивости к катастрофам? Не факт.
На х86, или в облаке есть конечно решения и для безопасности и и для устойчивости и для катастров, но это уже будут совсем другие деньги. В тестах этим не заморачиваются обычно.
А как обычный программист или дизайнер с макбуком подключается к этому маинфрейму?
Точно так же как и к любому другому серверу. К МФ можно подключаться с любого смартфона тоже.
Не совсем понятно что дизайнеру с макбуком делать на мейнфрейме... Он не для дизайнеров, он для других задач.
А для программиста не проблема - запустил терминал (или его программный эмулятор), подключился к серверу и делай что тебе надо.
Если говорить о разработке, то весь код пишется на десктопе. Потом забрасывается на сервер и там запускается сборка.
Не совсем понятно что дизайнеру с макбуком делать на мейнфрейме... Он не для дизайнеров, он для других задач.
Это общий вопрос к посылу статьи - дескать, делайте всё на мейнфрейме, и всё будет защищено. А на поверку оказывается, что кроме мейнфрейма в корпоративной сети все равно будут сотни и тысячи мелких устройств, которые будут подвержены всё тем же уязвимостям. А если злоумышленник уже сидит в сети, то в один прекрасный момент какой-то кейлоггер попадёт на терминал сотрудника с административными правами мейнфрейма, и злоумышленник уже и там окажется. И спасёт компанию в таком случае только то, что злоумышленник с высокой долей вероятности нихрена не поймёт, что ему там в этой самой z/OS можно делать.
Это общий вопрос к посылу статьи - дескать, делайте всё на мейнфрейме, и всё будет защищено.
Я такого посыла не увидел. Это что-то из мира x86 - делать все в одном месте.
У любой крупной компании есть разделения mission и business critical частей (систем). На изолированном от внешнего мира МФ предлагается держать mission critical системы.
Что значит "изолированном от внешнего мира МФ"?
Если то, что к БД или другому сервису, бегущему на нем, невозможно подключиться непосредственно из Интернета - это само собой разумеется. Ораклы на x86 тоже в Инет выставляют разве что по ошибке.
А если уж админ не обязан именно идти в серверную и подключаться физически к консольному порту (а, к примеру, подключается через VDI, KVM over IP и т.п., приходим опять к тому, что x86/ARM админа могут хакнуть, спереть пароли кейлоггером и пойти от его имени в МФ в точности, как он сам. Другое дело, что я, к примеру, не знаю что потом в это z/OS делать :) Но я и не хакер.
Или вы имели ввиду не просто защищенный сегмент, а реально air gap или "диод"?
А если злоумышленник уже сидит в сети, то в один прекрасный момент какой-то кейлоггер попадёт на терминал сотрудника с административными правами мейнфрейма, и злоумышленник уже и там окажется. И спасёт компанию в таком случае только то, что злоумышленник с высокой долей вероятности нихрена не поймёт, что ему там в этой самой z/OS можно делать.
Никакой злоумышленник внутри нашей сети не попадет на терминал "сотрудника с административными правами мейнфрейма". Хотя бы потому что нет такого терминала. Более того чтобы войди в систему с моими креденшиал (UserID) надо это делать с моего лаптопа. Трафик между моим лаптом и МФ зашифрован.
Более того чтобы войди в систему с моими креденшиал (UserID) надо это делать с моего лаптопа
Ну так я про это и говорю. Терминал-то всегда есть, вопрос только, откуда он запускается. Что у вас там на ноуте? Ведь не z/OS же. Винда? Линукс? В корпоративный VPN он входит? Тогда какие у вас есть здравые основания полагать, что на вашем ноуте в один не прекрасный для вас момент не окажется кейлоггер, подсаженный туда злоумышленником? Который там с другой машины узнал креды вашего саппорта, удалённо к вам подключился, пока вы в сети, закачал вам на машину кейлоггер и прописал его в автозагрузку. Вы настолько самостоятельный специалист, что на вашу машину удалённо саппорты не ходят, и в группу администраторов принципиально не занесены, несмотря на корпоративные политики? Ок, вас вычёркиваем, зато они занесены в группу администраторов на машине Васи, Пети или Джона, злоумышленник подсадит кейлоггер туда. Какая разница, если результат-то он получит?
....удалённо к вам подключился, пока вы в сети, закачал вам на машину кейлоггер и прописал его в автозагрузку.
Вы большой фантазер. Я не использую клавиатуру для верификации и аутентификации.
Вау, круто! Если даже на свой ПК/ноут пользователи вашей организации заходят исключительно с помощью какого-то аппаратного устройства, причем пин вводится непосредственно на нем, ваши бэкенды значительно сложнее взломать, чем у большинства. Даже если это "обычный postgresql на x86".
Если есть возможность закачать кейлоггер, то значит и что угодно. Если это можно запустить на выполнение, то это может быть например автономный агент, после логина в "мейнфрейм" блокирующий клавиатуру / экран и выполняющий нужные команды в терминале.
Вы большой фантазер.
А в чём фантазии, позвольте уточнить? В том, что озвучил самый типичный вектор взлома, вроде бы фантазий нет. Ну ок, у вас там не клавиатура, а аппаратный ключ, это только усложнение задачи. Подсадят вам не кейлоггер, а демона, который будет в ваш свисток закидывать сессионный запрос на верификацию, пришедший на машину взломщика, получать ответ, и передавать это на машину взломщика. Да, это надо проводить, когда ваша машина физически в сети, но опять же таки, надо - сделают. Вопрос лишь в том, чтобы ваша организация попала в круг интересов взломщиков.
И то, далеко не факт, что в вашей компании нет вороха системных учёток, которые используют классический логин/пароль.
Ну вот у нас используются Indeed Key на телефоне (до этого - RSA Software token). Т.е. первое что вводится - 6 цифр, которые генерируются приложением на телефоне и меняются каждый 30 секунд. Приложение (точнее, сгенерированный им после установки идентификатор) зарегистрировано на внутреннем сервере идентификации и связано с конкретным профайлом пользователя. Идентификатор привязан к конкретному телефону (т.е. поменял телефон, установил на новый приложение - нужно регистроваться заново).
Т.е. первый этап - логин + код, второй этап - логин + пароль.
Т.е. чтобы воспользоваться профайлом конкретного человека вам еще в его телефон залезть надо.
А в чём фантазии, позвольте уточнить? В том, что озвучил самый типичный вектор взлома, вроде бы фантазий нет.
Я не специалист по защите от взломов персональных компьютеров (ПК), но думаю что за последние годы с этим была проведена определенная работа и она дает результаты.
Вижу это по моему рабочему лаптопу, который мне был выдан компанией и только с которого я могу выполнять свою работу на МФ и вообще в сети компании.
Не думаю что каким то там белорусским и/или украинским хакерам удастся поставить на мой лаптоп кейлогер или демон.
Вот поэтому и не только я считаю что Вы все таки фантазер. Рассказывете про свои фантазии основанные на там что все кругом дураки.
По поводу Аэрофлота я остаюсь в убеждении что это были не хакеры, а инсайдеры или партнеры Аэрофлота, у которых был доступ. Т.е. у них был администротор/суперюзер доступ в сети Аэрофлота. Остально придумано для отвода глаз.
И вот здесь то и всплывают особенности секьюрити на МФ, описанные мною выше. Кроме этого давно-давно на МФ существует практика когда, например, и DBA и программист могут логиниться к продакшн системе только для выполнения согласованных работ, под контролем проверяющего и специальным образом выданного на время выполнения работ доступа. Это лишь один пример из практики внесистемной безопасности.
Да и общесистемные аккаунты с высокими/высочайшими привелегиями не используются для ежедневной работы. И это не только на МФ, но и на х86 серверах уже тоже понимают и начинают своими способами контролировать это. У нас с этим на х86 серверах (знаю потому что у меня есть админ аккаунт на три-четыре х86 сервака, в том числе продакшн) проведены были соответствующие мероприятия, которые может быть не 100% надежные, но с ума свести любого хакера точно смогут. Даже если этот хакер будет уже в нашей сети, т.е. инсайдер).
Я кстати сам был взломщиком. В 80-е НИИЭВМ поставил защиту на свою СВМ ЕС. Тогда они уже брали деньги к пользователей за эту систему. Они мне давали некий ключ для каждого моего заказчика и я переводил НИИЭВМ деньги за эти ключи.
Было интересно как же это у них устроено. Покопавшись пару часов я открыл их "секрет" и успещно снял защиту. Я знал того (Иван Ш.) кто в НИИЭВМ этим занимался и в очереднкю командировку в Минск рассказал ему о моих находках. Он сделал изменения в защите. Я снова посмотрел и понял что в принципе это тоже самое (а другого не могло быть), но времени для полного взлома этой новой защиты понадобится гораздо больше и остановился. Ивану конечно рассаказал, чтобы он знал что если кто-то и сломает его защиту, то это буду не я. Это было просто ради любопытства.
Для этого используется эмулятор терминала, например Rumba, который работает в Windows. Я с ним работал в авиакомпании KLM в 1998 году.
Сейчас этих эмуляторов...
Для IBM i сама IBM предлагает бесплатный пакет IBM i Access Client Solutions Среди многих полезных компонент там есть и эмулятор терминала IBM5250.
Аппаратные терминалы давно уже в прошлом (может и сохранились где, не знаю) - все работают на эмуляторах. Даже для андроида как-то видел версию (еще коллегам прикола ради показывал как с планшета на андроиде можно на нашем сервере работать).
Для IBM i сама IBM предлагает бесплатный пакет IBM i Access Client Solutions Среди многих полезных компонент там есть и эмулятор терминала IBM5250.
Я его даже писал когда-то. Мне надо было, чтобы терминал был встроен в банковское "суперприложение", поэтому делал мимулятор терминала на Delphi. Там в принципе не бог весть какой сложный протокол для реализации. Разрабатывался-то в 1970-е годы, поэтому дубовый и прямолинейный.
Ну, насколько знаю, там блочный протокол обмена.
И сколько видел этих самописных терминалов - они все в чем-то да ограничены. В плане поддержки всех возможностей DDS для дисплейных файлов.
И сколько видел этих самописных терминалов - они все в чем-то да ограничены.
Ну, я старался поддерживать совместимость :) Вроде никто не жаловался.
Минимальная совместимость поддерживается обычным телнетом. По крайней мере простенькие экранные формы.
А вот сложные формы со всеми возможностями дисплейного DDS - тут уже сложнее. Там же не "картинка" идет, а структуры с управляющими кодами. DDS это описание типа такого:
*
A R MSGSFL TEXT('*** Message subfile ***')
A SFL SFLMSGRCD(24)
A FLDKEY SFLMSGKEY
A FLDPGM SFLPGMQ
*
*-------------------------------------------------------------------------
*
A R OPTION SFLCTL(MSGSFL)
A SFLSIZ(0020)
A SFLPAG(0001)
A TEXT('*** Message control ***')
A BLINK
A OVERLAY
A PUTOVR
A 82 SFLDSP
A 83 SFLDSPCTL
A 82 SFLINZ
A 82 SFLEND
A N82 ERASE(MSGSFL)
A FLDPGM SFLPGMQ
A ZLCTXT R O 23 2REFFLD(CMD)
A OVRDTA
A COLOR(BLU)После компиляции структура его во многом схожа со структурой обычной таблицы БД - то же набор полей с атрибутами (на AS/400 что описание таблицы и ее структуру можно посмотреть командами DSPFD/DSPFFD, что описание и структуру дисплейных или принтерных файлов - все они описываются однотипно, с помощью DDS)
Зачем?? У IBM-ских эмуляторов есть API для внешних аппликаций. Называется HLLAPI.
Очень опасное заблуждение думать, что можно позвать каких-то там безопасников, они тебе всё настроят, и будет безопасность. На уровне приложения тоже есть уязвимости. Да, безопасники запрут твоё приложение в песочницу, откуда оно не сможет навредить другим частям системы, но оно по-прежнему может оставаться уязвимым, может быть выведено из строя и т.д. И я что-то очень сомневаюсь, что крутые ребята с сертификатами Cisco или Госуслуг, или даже ребята в погонах в состоянии провести корректный аудит, к примеру, имеет ли эндпоинт какого-нибудь сканера QR-кодов защиту от SQL-инъекций, и если имеет, то является ли она надёжной. Что-то мне подсказывает, что нормальный специалист, способный выполнить эту задачу, стоит значительно дороже, чем кладовщик из Пятёрочки.
Для чего все эти выкладки про IBM, z/OS, DB2... Аэрофлот, кажется российская компания и подпадает под требования импортозамещения.
А что у нас из российского хотя бы на 10% покрывает функциональность средств описанных в статье? Ничего, т.к. в основном все направлено не на безопасность, а на зарабатывание денег. Не одна российская компания- разработчик не может себе позволить разрабатывать свои средства ради безопасности. Нужно сначала соответствовать бесконечным бумажкам бесчисленных регуляторов.
В той же AstraLinux сколько всего механизмов безопасности накручено, но все равно до IBM очень далеко.
Для чего все эти выкладки про IBM, z/OS, DB2... Аэрофлот, кажется российская компания и подпадает под требования импортозамещения.
Под требование подпадает, но что-то мне подсказывает что на деле у Аэрофлота все, или почти, все импортное. И так у многих в России. Более того то импортное что в использовании гораздо хуже по качеству в том числе по безопасности чем перечислено в цитате выше. Почему бы этому импортному не быть "IBM, z/OS, DB2"?
Да, надо было раньше этим заниматься, но все же.
Нечто похожее говорил Вассерман не далее как вчера по радио Спутник в своей программе.
Не специалист ни разу, так что минусуйте! Не всё поняла, но очень интересно. Коммент для поднятия морального духа автора статьи.
Да вопрос не в том какая архитектура может стоят, вопрос уровня бардака в инфраструктурах. В 99% случаях у всех бардак в ИТ инфраструктуре. Даже в zos встречал.
Да, именно так. Мы работаем с IBM i (AS/400). Там 5 уровней защиты на уровне ОС Мы работаем на 40-м уровне. Выше только 50-й уровень по классу С2
Министерство обороны США определяет уровень защиты класса С2, как обеспечивающий «селективную защиту и, путем включения возможностей аудита, ответственность субъектов за их действия»
Правительством США определены уровни защиты от А до D, где А — наивысший уровень защиты, а D — самый низкий. Классы B и С имеют несколько подуровней. Уровень защиты С2 — уровень, наивысший из обычно используемых в бизнесе.
Но этим надо одумляться и заниматься. И, естественно, более высокий уровень защиты доставляет пользователям (а иногда и разработчикам) больше "неудобств" за счет большего количества разных ограничений.
Вроде утверждается что уровень "А" есть только в теории, так как по оценкам в таком режиме тратится 90%+ ресурсов системы на собственно обеспечение безопасности.
Этакое воплощение машинной паранойи :)
Кстати, Microsoft получала сертификацию класса С2 для Windows :)
Интересная тема. Добавлю про МФ
В период с 1988 по 1990 год IBM® усовершенствовала MVS™, RACF®, JES2, JES3, TSO, VTAM®, DFP и PSF для соответствия критериям B1. MVS/ESA версии 3 выпуска 1 модификации уровня 3 прошла формальную оценку Агентства национальной безопасности и получила обозначение безопасности B1. В течение нескольких лет последующие версии RACF, MVS/ESA и OS/390® разрабатывались с учетом соответствия критериям B1, хотя формальная оценка не проводилась. Но со временем в MVS были добавлены новые функции, такие как системные службы UNIX, которые нельзя было использовать в системе с обозначением безопасности B1. Кроме того, конфигурации клиентов развивались и требовали сетевого взаимодействия, которое нельзя было использовать в системе B1. В конечном итоге, Общие критерии и ISO 15408 заменили старые стандарты правительства США, описанные в «Оранжевой книге».
В новой системе стандартов (без перевода):
z/OS V1R12 has been certified to meet the requirements of the Common Criteria assurance level EAL4, augmented by ALC_FLR.3 for the following protection profiles:
Operating System Protection Profile (OSPP) Version 2.0 (dated 6/10/2010)
OSPP Extended Package - Labeled Security (OSPP-LS), Version 2.0 (dated 5/28/2010)
OSPP Extended Package - Extended Identification and Authentication (OSPP-EIA), version 2.0 (dated 5/28/2010)
For information about the certified configuration, see the first z/OS V1R12 edition of z/OS Planning for Multilevel Security and the Common Criteria, GA22-7509-10. The certification report is published on the OCSI web site.
The RACF component of z/OS V1R12 is being evaluated for conformance to the requirements of the Common Criteria assurance level EAL5, augmented by ALC_FLR.3. At the time this information was published, the evaluation was not complete. To find out whether the certification report has been published, visit the OCSI web site.
С переводом:
z/OS V1R12 сертифицирована на соответствие требованиям уровня гарантии Common Criteria EAL4, дополненного ALC_FLR.3, для следующих профилей защиты: Профиль защиты операционной системы (OSPP) версии 2.0 (от 10.06.2010 г.) Расширенный пакет OSPP — маркированная безопасность (OSPP-LS), версия 2.0 (от 28.05.2010 г.) Расширенный пакет OSPP — расширенная идентификация и аутентификация (OSPP-EIA), версия 2.0 (от 28.05.2010 г.) Информацию о сертифицированной конфигурации см. в первом издании z/OS V1R12 «Планирование многоуровневой безопасности и общих критериев z/OS», GA22-7509-10. Отчет о сертификации опубликован на веб-сайте OCSI. Компонент RACF системы z/OS V1R12 проходит оценку на соответствие требованиям уровня гарантии Common Criteria EAL5, дополненного ALC_FLR.3. На момент публикации данной информации оценка не была завершена. Чтобы узнать, был ли опубликован отчёт о сертификации, посетите веб-сайт OCSI.
Позже:
Функциональность z/OS (смоделированная на основе профиля защиты Common Criteria для операционных систем общего назначения версии 4.2.1 (OSPP) от 22 апреля 2019 г.) и гарантии были оценены и сертифицированы на уровне EAL4. Функциональность RACF (также смоделированная на основе OSPP) и гарантии были оценены на уровне EAL5.
А ну ка давайте обсудим Windows Security. Может кто сподобися создать пост для отдельной ветки комментарий. Я пытася как то то не получилось.
Для открытия поста согу предложить книгу и фрагмент из нее (если есть что-нибудь долее свежее, предложите свое)?
https://www.kufunda.net/publicdocs/Windows 10 System Programming, Part 2 (Pavel Yosifovich).pdf
Privileges
A privilege is the right (or denied right) to perform some system-level operation, that is not tied to a particular object. Example privileges include: loading device drivers, debug processes from other users, take ownership of an object, and more. A full list can be viewed in the Local Security Policy snapin (figure 16-11). For each privilege (“policy” column), the tool lists the accounts that are granted that privilege.
Super Privileges
An exhaustive discussion of all available privileges is beyond the scope of this book. Some privileges, however, do bear special mention. There is a set of privileges that are so powerful that having any of them allows almost complete control of the system (some allow even complete control). There are sometimes affectionally called “Super Privileges”, although this is not an official term.
Take Ownership
An object’s owner can always set who-can-do-what with the object (see the “Security Descriptors” section for mode details). The SeTakeOwnershipPrivilege (SE_TAKE_OWNERSHIP_NAME) allows its yielder to set itself as an owner of any kernel object (file, mutex, process, etc.). Being an owner, the user can now give himself/herself full access to the object.
For example, suppose an employee leaves a company, and some files/folders he/she owned are now inaccessible. An administrator can exercise the take ownership privilege and set the administrator as the owner, allowing full access to the object to be set.
В z/OS super privilege имеет имеет только юзер с RACF SPECIAL. Есть еще уровень GROUP SPECIAL, это уровень SPECIAL делегированный определенной группе(-ам).
Таким оборазом привелегий в z/OS гораздо меньше (SPECIAL, OPERATIONS, AUDITOR), но контроль доступа в z/OS как раз таки в основном завязан на объектах (я не говорю что их нет в Windows), так что даже юзеру с RACF SPECIAL может быть закрыт доступ к любым объектам!!!!
Даже в zos встречал.
Расскажите, интересно.
МФ мало кому по карману, а ещё и лицензию надо каждый год продлевать. Специалистов тоже мало. Ну и - пожизненное рабство от одной единственной компании. Страшно связываться.
А потери от взломов всем по карману получается?
А быть связанным с х86 не страшно? С недоделанными ОС типа Windows и Linux не страшно?
3-4 года назад компания где я работаю перевела свое основное приложение с МФ (z/OS, DB2, Cobol, CICS) на Oracle, Linux. Перевели потому что вендор этого приложения очередную версию сделал без сертификации на МФ (хотя сделать это было не только просто, а очень просто). Большинство МФ пользователей этого вендора остались на последней МФ версии.
Переход был гладким. Но в эксплуатации далеко не все что имелось, например, DR удалось сделать на том же уровне как было на МФ. Вместо одного МФ далеко, очень далеко не самого мощного, а следовательно и не такого уж и дорогого сейчас это приложение стоит на более чем 30 серверах х86. Не маленьких серверах. Только БД стоит на двух серверах с минимум 16 коров (МФ имел 4 на все приложение) и памяти раз в десять больше чем имелось на МФ.
Более того на МФ (одном МФ) не только продакшн стояла (БД, сервер транзакций CICS, т.е. все приложение), но и Dev, QA, Training, Sandbox все в полном комплекте приложения, QA full size, остальные в сокращенными БД. И все это работало и днем и ночью и имело прекрасное решение для DR.
Для поддержки всей этой инфраструктуры на МФ, в последние года и для миграции с МФ, включая репликацию из DB2 в SQL Server, использовался ровно один специалист. Сейчас штат поддержки на х86 этого приложения существенно шире, а за репликацию с Оракл на SQL Server отвечает тот же специалист что поддерживал МФ. МФ тот до сих пор up and running, и за его софт (лицензию) компания платит ежемесячно. Примерно $15000.
Есть у нас еще один МФ. В 10 раз менее мощный чем первый. На нем приложение в IDMS, ADS, Cobol, Assembler, CICS. (прикол, на этом МФ 64 GB активировано из 128, две партиции: продакщн и девелопмент сконфигурированы с памятью по 1 GB каждый. Т.е. из 64 используются только 2. по производительности никогда никаких претензий не было).
Переводят с МФ уже лет десять. 11 августа собираются соскакивать. Миграция данных из IDMS в SQL Server сделана мною. Пользователи этого приложения на МФ в ужасе и уходить не хотят. Но на них давят.
Это рабство?
Что за бред я прочитал сейчас? Кто-нибудь этому "профессиАналу в сфере IT", скажите что ли, что w2k3 полно версий на x64, которые в большинстве и используются. А вот x86 как раз сейчас и уже давно НЕ используются из-за ограничений RAM.
@moderator, автор статьи хотел пожаловаться на этот комментарий, а дальше вам решать.
А собственно - какая разница? По сравнению с мейнфреймами (любыми, хоть System/360 даже) - отличия x86 от x86-64(который MS обычно зовет x64) - мелкие и несущественные.
Я новичок на Хабре, но провел много лет на другом форуме. На том форуме была такая опция попросить модераторов обратить внимание на грубияна и поставить его/её в угол на время или навсегда.
Может и на Хабр есть такая опция, подскажите.
Как приятно видеть что есть что-то что никогда не меняется - zVlad :)
Пламенный привет! Давно не виделись :)
Вы в России или в Канаде сейчас?
Привет! Да, мир тесен. Не узнаю Вас в гриме, однако.
В Канаде, чёрт бы её подрал. Застрял я тут походу.
Почему не меняюсь? Очень даже меняюсь. Мне вот 70 недавно стукнуло.Время летит.
Вот закончу с МФ в нашей компании и сосредоточусь на х86. Есть у меня уже репликация из Оракл в SQL Server, начальство предлагало заняться контейнерами или PostgreSQL. Я согласился на последнее, но пока начальство дальше не пошло.
Но все на самом деле зависит от того когда продастся мой коттедж. В Канаде нынче рынок недвижимсти встал колом.
Как у Вас дела?
Что если бы в Аэрофлоте были ИБМ МФ и z/OS