Как это было на самом деле.
Я не верю что это сделали хакеры. Да есть ссылка по которой хакеры делятся деталями своего "подвига". Но это не убедительно. Эти "аргументы" может каждый создать. Принт скрины это не доказательства.
На самом деле я считаю что был(и) задействованы внутренние ресурсы. ИТ-шники Аэрофлота, или внешние подрядчики оказывающие услуги ИТ. Это не редкость когда крупный бизнес использует внешних исполнителей и это не редкость что они имеют права администрирования на серверах заказчика.
Это уже выходит за рамки анализа ИТ-шных причин взлома, это из разряда "против лома нет приема". Роль хакеров, взявших ответственность на себя, отвести подозрения от настоящих преступников.
Кстати это дает основания для защиты настоящих преступников в суде даже если, по каким то вторичных признакам, к ним приведет расследование взлома. (Очень сомневаюсь что в системах на х86 можно персонифицировать, т.е. связывать те или иные действия с конкретной личностью.)
В самом деле, в суде, адвокат скажет: "Да, это мог сделать мой подзащитный(-ые), но вот же есть хакеры, которые взяли ответственность за взлом на себя, вот принтскрин с рабочей станции гендиректора, который не менял пароль доступа три года, вот принтскрин с AD сервера Аэрофлота, а вот граффити нарисованные из балончика с краской на мусорных баках во дворе офиса Аэрофлота".
Что если бы? Вариант номер 1 - х86.
Как специалист ИТ, работавший/работающий, в том числе, с компьютерной безопасностью на ИБМ МФ (z/OS) и интересовавшийся этими вопросами в случае серверов на х86 на уровне системного программирования в Microsoft Windows, сразу могу сказать, да, выстроить надежную систему информационной безопасности можно хоть на чем.
Но только теоретически. На практике, практически всегда, теоретическими возможностями защиты ПО на х86 пренебрегают. Причем это идет не столько от ИТ-шников, и даже может быть не от ИБ-шников (к чьим возможностям и способностям я очень критически отношусь потому что, работая в большой компании с порядка 400 человек в ИТ, я часто пересекаюсь с действиями ИБ-шников по вопросам их ролей и они меня зачастую умиляют), а от самого руководства бизнесом. Но...
Во-первых, если по настоящему строить систему безопасности на серверах х86 это потребует разработки на основе возможностей Windows внутренней модели контроля доступа к ресурсам, которая вообще говоря должна бы начинаться не с организации пользователя услуг ИТ на х86, а с разработчиков базовых приложений ИТ (ОС, БД, сервера приложений, и т.д. и т.п.).
Этим не занимаются вообще в разряде ПО класса open source, этим не занимаются даже такие вендоры как Microsoft. Недавно выявленная уязвимость, обнаруженная после ряда патчей, их SharePoint тому иллюстрация.
Во-вторых, если бы организации пользователей и вендоры базового ПО отнеслись бы к этому на полном серьезе, то это уже был совсем другой мир х86 серверов, совсем другие цены, и другие требования к квалификации программистов, админов и их менеджеров.
В-третьих, допустим нам удалось создать систему контроля доступа на должном уровне. Это повлечет за собой, на первых порах, огромный поток возмущений и требований типа "почему у меня нет доступа к тому и тому то?" или "почему эта программа у всех работает, а у нас не работает?".
Руководство может притащит откуда то какого ни будь волосатика в очках, свитере и джинсах, у которого есть гениальная программа для нашего бизнеса, и этот волосатик скажет через губу " Моя программа требует системный доступ.". И гендир скажет своему ИТ-шнику и ИБ-шнику: "Ребята, надо, я знаю что вы можете, вы же у меня самые-самые". И ребята сломают то о чем говорилось выше. Да им и не получится это сделать, и они даже подумать об этом не могут в сложившихся реалиях Ит на серверах х86.
Поэтому и не только, но для краткости ограничусь этим, хотя копать тут можно далеко, мы имеем как правило весьма облегченную систему контроля доступа, права админов раздаются на право и налево.
Тем не менее, сказать что вообще ничего не далается в области безопасности на х86 серверах, я конечно же не могу и не буду. Не знаю как в Аэрофлоте и более того в России вообще (хотя есть пара примеров от российских инсайдеров. Очень плохих примеров, никуда не годных примеров), но по компании где я работаю, не в России, я скажу что делается много, даже слишком много. И денег на это тратится тоже очень много, в основном на зарплаты многих и многих работников вовлеченных в эту увлекательную деятельность.
Нет они не создают комплексных систем контроля и управления доступами к компьютерным ресурсам, мониторингом доступа, пресечения несанкционированного доступа. Они, по моему мнению, затыкают дыры. Причем затыкая дыры они создают проблемы самим себе. Например, много уже лет назад пошла мода на двухфакторную аутентификацию. Прикупили на каком то блошином рынке программу (а как иначе, конечно все проблемы на х86 решаются покупкой новых программ) для двухфакторной аутентификации. Поставили ее на сервер, запустили в работу. Однажды сервер "сдох". Персонал, а это были главным образом ИТ-шники же, не может логиниться на сервера. Вот такой был пример укрепления бастионов. С тех прошло много лет, куплено, и внедрено было много других программ. Наверное это вселяет в души наших ИБ-шников (их ну очень много) надежду что они защитили нашу ИТ. Ну-ну. Нет, конечно защитили, двухфакторностью.
Что если бы? Вариант номер 2 - IBM mainframe and z/OS.
Изначально, пра-пра-пра-дед z/OS - OS/360 не имел никакой информационной безопасности. Впрочем у него и многопользовательского доступа тоже не было. Это была система пакетной обработки. Перфокарты, распечатка прогона задания.
Но уже в конце 60-х, начале 70-х этой проблемой в ИБМ занялись по серьезному. И появился компонент системы называемый SAF (System Authorization Facility). Ее роль:
SAF (System Authorization Facility) — это интерфейс, определяемый MVS (Multiple Virtual Storage) в мэйнфреймах IBM, который позволяет программам использовать службы системной авторизации для управления доступом к ресурсам.
Что это значит? Это значит что каждый менеджер ресурсов (под этим понимается любая программа, под управлением которой находятся те или иные, любые, компьютерные ресурсы: данные, программы и их функции, команды системы и подсистем, все что может быть использовано для неправомерной деятельности, или несанкционированного доступа к информации) при появлении запроса от кого или чего-либо обращается к SAF для проверки легитимности поступившего запроса. Ключевое слово КАЖДОГО.
SAF работает "в паре" с RACF (Resource Access Control Facility). RACF имеет и ведет базу данных (свою базу данных, не общего назначения), в которой хранится информация о профилях ресурсов. Профайлы ресурсов поделены на классы. Имеются классы USER, GROUP, DATASET, и GENERAL RESOURCE. C первыми тремя я думаю все понятно (профили их это UserID, GroupID, Data set names, GENERAL RESOURCE класс включает в себя профайлы в классах созданных по произвольной потребности контроля доступа. Например, класс OPERCMDS содержит профайлы контроля доступа к командам оператора MVS, JES, и RACF. Например профайл RACF.TARGET.LIST контролирует доступ к RACF команде TARGET с операндом LIST. Чтобы не создавать профайлы для каждого ресурса (их может очень много) в написании профайлов используются wildcard символ . Профайл RACF.TARGET.* включает правила для всех операндов команды TARGET.
Нечто подобное я видел в руководстве по системному программированию Microsoft Windows. Но я ни разу не слышал о реальном использование такого подхода. Мне конечно известно об Access Control Lists (ACLs), но опять же как часто и насколько обязателен/востребован этот механизм безопасности.
Профайлы RACF содержат информацию о том каким авторизованным процессам и пользователям какой уровня доступ разрешен. Если процесс/пользователь отсутствует в списке авторизованных, то доступ не будет выполнен и запрос процесса/пользователя останется без удовлетворения.
C другой стороны если сделан запрос к ресурсу для которого нет профайла в RACF то тоже запрос не будет удовлетворен.
Любые попытки доступа не предусмотренные политикой профайлов в RACF не только пресекаются, но и регистрируются. По каждому такому случаю создается сообщение, которое может быть преобразовано в, например, SMS администратору. Попытка использования неправильного пароля для пользовательского профиля (USER profile) более трех раз приводит к блокированию профиля. Автоматического разблокирования не предусмотренно, хотя можно в каждом конкретном случае это легко автоматизировать с помощью System Automation.
Профили, используемые для работы пользователя-человека имею сегменты. Эти сегменты дают право, и содержат стартап параметры для использования программ предназначенным для пользователя-человека. Если какого-то сегмента нет то и залогиниться не удастся. Примерами таких программ является Time Sharing Option (TSO) - диалоговая среда для пользователей типа программистов, операторов. Или Unix System Services (OMVS сегмент) - для пользователей Unix в z/OS. Есть программы z/OS, например, WebSphere, пользователи которых управляются самой такой программой, а профиль в RACF используется только для идентификации и аутентификации.
Профили, используемые для работы таких процессов как, например, база данных, или та же System Automation, т.е. когда не требуется процедура аутентификации, паролей не имеют и использовать их для логина в принципе невозможно. Эти профили создаются в классе USER, но во время создания таких профилей выбирается опция NO-PASSWORD. Уместен вопрос о том, а как же тогда используются такие профили, как запустить ту же БД, которая должна выполняться с её профилем не имеющим пароля, ответ прост - есть такой механизм запуска (типа Services в Windows), который позволяет авторизованному профилю запускать процессы для других профилей с указанием лишь имени профиля. Но для этого надо быть авторизованным и именно для этого процесса. Как? Через соответствующий профиль RACF.
Это весьма краткое введение в состояние компьютерной безопасности z/OS. В случае z/OS использование такого подхода к информационной и системной безопасности используется повсеместно и постоянно. Все программы для z/OS пишутся с обязательным использованием стандартов безопасности принятых за норму. Таким образом и через дополнительное ПО (third party) приникнуть в систему делается невозможным.
Кроме специфически мэйнфрэймовских технологий (RACF) в z/OS имеются общепринятые технологии безопасности, как то IP Security, Intrusion Detection System (IDS), и т.п.. RACF обеспечивает все функции работы с цифровыми сертификатами, Key Rings, and Tokens (последние два в других системах могут называться иначе).
