Определение ПАП
Уж с чем с чем, а с понятием программно-аппаратная (реже аппаратно-программная) платформа (ПАП) наш ИТ-рынок определился и понимает его практически однозначно. Программно-аппаратная платформа состоит из взаимосвязанной совокупности следующих основных элементов:
- аппаратной составляющей платформы, представляющей собой комплекс технических средств, объединенных в одно отдельное средство вычислительной техники (СВТ);
- базового программного обеспечения, обеспечивающего заявленное функционирование комплекса технических средств, конфигурирование системы и реализующего другие системные функции;
- общесистемного ПО, реализующего описанный функционал платформы;
- программных средств разработчика;
- комплекта документации, регламентирующего процесс внедрения указанной платформы в состав информационных систем заказчика, включая разрешительные документы по специальному применению платформы и сертификаты, устанавливающие соответствие требованиям регуляторов.
Аппаратная составляющая платформы определяется в основном архитектурой ее центрального процессора, а также аппаратными реализациями дополнительного оборудования в едином конструктиве СВТ, например сетевыми интерфейсами, адаптерами ввода-вывода, видеоадаптерами и интерфейсами и т. д.
Основным компонентом базового программного обеспечения (программной составляющей платформы) является операционная система (ОС), обеспечивающая работоспособность прикладного программного обеспечения на выбранном типе процессора, а также комплекс специальных программных средств (драйверов и специализированных библиотек), обеспечивающих функционирование аппаратного окружения процессора на платформе (контроллеры шины, сетевые адаптеры, интерфейсы ввода-вывода, мультимедиа и пр.).
К общесистемному ПО можно отнести прикладные программные средства, специализированные средства мониторинга и контроля функционирования платформы, средства удаленной настройки, интерфейсы взаимодействия с пользователем, встроенные средства информационной безопасности и т. п.
В качестве средств разработчика обычно рассматриваются всевозможные SDK, реже компиляторы различных языков программирования (Cи, Cи++), отладчики, профилировщики и иные системные инструменты и библиотеки.
В связи с тем, что рассматриваемые платформы часто имеют узкую функциональную направленность, в состав документации обычно входит стандартный набор эксплуатационных документов, формуляр изделия, описывающий и аппаратную, и программную составляющие платформы, прошедшие необходимые проверки, подтвержденные соответствующими сертификатами соответствия и предписаниями на эксплуатацию в информационных системах заказчика.
Российские ПАП
Как видим, общие определения позволяют отнести к разряду ПАП практически любые СВТ, начиная от стандартных серверов, рабочих станций или терминалов вплоть до активного сетевого оборудования. И это совершенно справедливо. История развития ИТ-отрасли РФ знает десятки различных платформ, поставляемых ранее и живущих поныне. Многие из этих платформ изначально разрабатывались на принципах импортозамещения, например ПАП «Багет», «Эльбрус», «Комдив». Они ориентировались на различные типы центральных процессоров, имеющих различную архитектуру (например, х86, MIPS, ARM). При этом необходимо учитывать тот факт, что любой процессор характеризуется не только его архитектурой, т. е. набором команд, но и микроархитектурой – конкретной реализацией заявленного производителем набора команд. Прежние ПАП часто отличались оригинальными сочетаниями архитектуры и микроархитектуры, что, конечно же, не способствовало ни достаточной производительности изделий, ни широкому охвату прикладного ПО.
В итоге это привело к их повсеместному вытеснению более открытыми решениями, но далеко не во всех областях. Традиционные ПАП до сих пор работают в специализированных информационных системах, и кажется, что так будет всегда. Почему? Потому что здесь имеется неубиваемый довод, идущий со стороны информационной безопасности и справедливый для любых закрытых платформ: чем более закрытой (менее популярной и распространенной) является платформа (или приложение), тем меньше экспертизы для ее взлома. Значительная часть несанкционированной экспертизы как раз привязана именно к архитектуре процессора атакуемой системы. Поэтому взлом закрытых систем весьма дорог с точки зрения трудозатрат, поскольку известно о них не много, а риск разоблачения нарушителя, чаще всего внутреннего, весьма велик. В подобном случае проблемы информационной безопасности ставятся выше проблем с производительностью, удобством работы и вообще целесообразностью применения такой платформы. Но если речь идет о закрытой информационной системе, то применение такой платформы можно считать вполне разумным.
Имеется и еще один важный аспект в относительной стабильности закрытых платформ на рынке – отработанная годами функциональность, отсутствие избыточных вычислительных мощностей и периферийного оборудования, минимум окружения среды исполнения. Эта тенденция полностью противоречит известному закону Мура, вернее, она его полностью игнорирует, утверждая, что первичность требований рынка очевидно вступает в противоречие с требованиями обеспечения информационной безопасности платформы. Почему? Потому что навязываемая потребителям парадигма постоянного наращивания функциональности аппаратного и программного обеспечения не позволяет сколько-нибудь долго оставаться в рамках надежных, апробированных решений с доказанной безопасностью. Конкуренция среди производителей элементной базы, аппаратного и программного обеспечения заставляет сокращать сроки разработки новых продуктов, что ведет к снижению качества тестирования и выпуску продуктов с различными известными дефектами, в том числе с дефектами защиты. Таким образом, нарочитая сложность многих ПАП является основным препятствием на пути обеспечения их же безопасности. Этот разумный вывод и сегодня позволяет существовать многим специализированным ПАП, в особенности решающим задачи в режиме реального времени. Такие платформы обеспечивает минимум функциональности аппаратуры и ОС, достаточную для реализации основного функционала и сервисов безопасности.
Безопасность ПАП
Когда-то считалось, что именно требования безопасности для платформ являются главными, определяющими. Однако со временем функциональность платформы все же победила. ПАП должна прежде всего работать, а уж после этого быть защищенной. Тогда платформы стали несколько более открытыми, потому что появились сначала UNIX-, а потом и вовсе Linux-подобные ОС в качестве практически стандартной основы для программной составляющей платформы (взамен, например, ОС2000 в ПАП «Багет»). Для систем реального времени в качестве базового ПО стала выступать QNX или специальный Linux реального времени. Вот тогда-то и вспомнили об архитектуре и микроархитектуре процессоров, тогда и появились несколько основных направлений развития отечественной аппаратной составляющей платформ – на основе MIPS- и ARM-архитектур в силу их коммерческой доступности. По понятным причинам основная на сегодня архитектура Intel х86 здесь не рассматривается. Сегодня этот очевидный тренд становится определяющим даже не столько в силу декларируемого импортозамещения, а просто в силу естественного прогресса отрасли.
Соответственно все проблемы ИБ тут же спроецировались на возможности ОС по разграничению доступа, работе с пользователями, контролю целостности и поддержке криптосредств. От аппаратной части ПАП сегодня требуется наличие штатных слотов расширения (PCI и пр.). Требования к базовому ПО ПАП уперлись в основном в вопрос портирования тех или иных дистрибутивом Linux под известные архитектуры, поэтому, например, ПАП «Эльбрус» сегодня поддерживает не только свою собственную архитектуру, но и известную архитектуру SPARC. В то время как ПАП «Байкал» поддерживает и ARM, и MIPS. Для конечного пользователя, впрочем, разницы почти никакой, ведь базовым ПО на всех этих изделиях является одна из разновидностей ОС Linux, а вот для разработчиков разница в применяемом варианте ОС чрезвычайно существенна.
Широкие возможности ОС Linux привели к появлению довольно мощных ПАП типа «Холст», в состав общесистемного ПО которого входили уже и офисный пакет, и СУБД, а базовой ОС являлась ОС МС ВС. Еще дальше продвинулась ПАП «Каркас», оснащаемый ОС Astra Linux, включающий в состав платформы к тому же дополнительное средство защиты информации АПМДЗ «Максим», осуществляющее контроль доступа к собственно СВТ и соответствующее СЗИ из состава ОС.
Что касается средств разработки ПО, то они стали достаточно стандартными и представляют собой 32- и 64-битные SDK, поставляемые в составе ПАП или запрашиваемые отдельно у разработчика. Прочие средства разработки отдаются на откуп третьим производителям из состава распространенных средств Open Source.
Вспомним еще, что указанные ПАП чаще всего применяются в защищенных информационных системах. Поэтому для их применения необходимо пройти сертификационные мероприятия на соответствие требованиям регуляторов, например ФСТЭК РФ или МО РФ. Все дистрибутивы базовой ОС проходят обязательную сертификацию по определенному (2-му или 3-му) уровню контроля недекларированных возможностей (НДВ), а также по определенному (2-му или 4-му) классу защиты от несанкционированного доступа (НСД) в соответствии с руководящими документами ФСТЭК РФ. Межсетевые экраны (МЭ), которые также являются ПАП по сегодняшним требованиям регуляторов, проходят проверки в соответствии с Руководящими документами для МЭ. Инструменты разработчика, различные офисные приложения, СУБД, серверы и другие программные пакеты также проходят сертификационные проверки и включаются в дистрибутив базовой ОС программной составляющей ПАП. Аппаратная составляющая чаще всего проходит специальные проверки на аппаратные закладки с выдачей предписания на эксплуатацию на объекте заказчика.
Конечно же, сертификация программного продукта сама по себе не гарантирует его полной безопасности. Дело в том, что значительная часть атак пользуется уязвимостями в ПО, которые не были своевременно выявлены разработчиками. Сертификация также не в состоянии выявить их в полном объеме. Особенно это касается закрытых платформ, использующих для своих программных компонентов закрытые репозитории собственных сборок Linux, оторванных от открытого сообщества и развиваемых по собственному усмотрению самими разработчиками ПАП. В связи с этим сегодня в качестве проверок таких программных средств в системе сертификации применяется проверка на защищенность ПО в соответствии с актуальными угрозами, совершенными атаками и опытом по их отражению из открытого сообщества. Вряд ли закрытое решение сможет выдержать такую проверку… И здесь требуется определенная степень открытости и доверенный репозиторий программных пакетов, на основе которого и можно собирать базовую ОС ПАП.
Сетевые ПАП
Заметим, что буквально все активное сетевое оборудование также можно смело считать ПАП, поскольку оно полностью подходит под определение последней. Все изделия этой области развивались на проприетарных ОС, которые и сегодня закрыты (Cisco, Huawai и пр.). Раньше такие ОС были действительно разными, но сегодня практически все являются клонами того же Linux. Разумеется, никаких проверок на соответствие требованиям регуляторов они не проходили, хотя известно несколько десятков недекларированных возможностей изделий той же Cisco. Однако смысл применения ОС Linux в качестве базовой ОС, контролирующей активное сетевое оборудование и интегрирующей его в ИТ-ландшафт корпоративной ИС, ЦОД или иного объекта еще более значим, причем не только с точки зрения информационной безопасности.
Сегодняшний долгосрочный тренд в этой области ПАПостроения – реализация сетевой инфраструктуры как единой программно-аппаратной платформы и предоставления функционала сквозных (end-to-end) сетевых услуг. В таком случае система управления инфраструктурой должна централизовать все высокоуровневые функции управления, а также иметь полную модель управляющих данных и параметров состояния всей сети в целом. Реализация такого подхода приводит к созданию ПАП на базе сетевой ОС (Network Operating System, NOS) Linux, что открывает широкие возможности для гибридного управления, когда высокоуровневые функции делегируются выше и координируются из общего центра, а на местах есть полный набор управляющих данных для полноценного выполнения всех функций, присущих сетевой ПАП. То есть каждое сетевое устройство имеет собственное управление, что позволяет сохранить классический децентрализованный подход к построению сетей, и сохраняет отказоустойчивость и надежность сети на столь же высоком уровне. При этом обеспечивается существенная возможность централизованного управления всеми устройствами сразу посредством специализированных безагентских систем управления конфигурациями (например, Ansible). Заметим, что таким образом можно управлять любыми СВТ, функционирующими под управлением различных ОС, включая ОС Linux и ОС MS Windows.
Такое решение по управлению (конфигурированию, развертыванию, обновлению) сетевой инфраструктурой базируется на одном новом и существенном факте из жизни современных отрытых платформ: они должны иметь внутреннюю способность к быстрому изменению под влиянием внешних быстро меняющихся условий функционирования, частому изменению настроек не только конкретного коммутатора, маршрутизатора или другого активного элемента сетевой инфраструктуры, но и целых групп сетевого и серверного оборудования и установленного на нем ПО. Более того, имеет место также резкое сокращение интервалов между внедрениями новых версий ПО. К этому приводят различные причины, например, распространение обновлений безопасности, ускоренное добавление новых функций, интеграция различных элементов ИС, автоматизация и роботизация операций по администрированию.
Заключение
Сейчас необходимым условием новой парадигмы управления является по меньшей мере функционирование аппаратного компонента ПАП под управлением операционной системы Linux. Тогда вполне достижимым становится согласованное администрирование и даже оркестрация всей инфраструктуры ИС, начиная с прикладного уровня. Выгоды такого подхода чрезвычайно велики. Однако же здесь возникает определенная особенность реализации функций ИБ: складывается впечатление, что появляется своего рода новый глобальный администратор, имеющий широкие полномочия и технические возможности по настройке СВТ (в том числе и СЗИ) с помощью систем управления конфигурациями и других высокоуровневых инструментов. Это не здорово с точки зрения ИБ, но сколько еще вопросов предстоит решить по пути внедрения всего того потенциала, который называется сегодня загадочным, еще не до конца понимаемым термином – DevOps…
