спо и ппо что это
СПО или ППО: где уязвимостей меньше?
СПО-комьюнити (слева) численно превосходит команду Microsoft (справа) и… проигрывает
Софтверная часть в ИКТ-продуктах и решениях приобретает сегодня все большее значение, поскольку только с ее помощью можно гибко и оперативно реализовывать возможности, заложенные в сервисной модели предоставления и потребления ИКТ-ресурсов, которая с распространением виртуализации и облаков становится доминирующей.
Движимые в последние годы заботой о безопасности своих продуктов не меньше, чем их функциональностью, лидирующие ИКТ-вендоры все активнее внедряют у себя комплексные программы безопасной разработки ПО, подобные программе Microsoft Security Development Lifecycle, ставшей для Microsoft обязательной с 2004 г.
Параллельно с проприетарным ПО (ППО), ответственность за качество и сопровождение которого лежит на плечах его разработчика, на рынке существует и свободное (СПО) — его разработкой и поддержкой занимается добровольное сообщество сторонников такого ПО.
К попыткам сравнить информационную безопасность (ИБ) СПО и ППО программисты и пользователи обращаются настойчиво и регулярно. Так, жаркие дискуссии на эту тему разгорелись на круглом стола “Информационная безопасность экосистемы открытого ПО” в рамках апрельского форума Russian Open Source Summit ‘2013. Тогда в дискуссии приняли участие эксперты, представлявшие вендоров, разработчиков программных продуктов, искушенных в применении как СПО, так и ППО, корпоративных пользователей и регуляторов, занимающихся вопросами сертификации ПО обоих типов.
Конференция ZeroNights ‘2013, прошедшая в Москве в первой декаде ноября этого года, тоже предоставила свою площадку для сравнительно обсуждения информационной безопасности СПО и ППО. На этот раз организаторы предпочли формат ток-шоу, сведя в словесном поединке руководителя программы информационной безопасности из компании Microsoft Андрея Бешкова и представительное комьюнити апологетов СПО (в максимуме достигавшее на сцене численности в пять человек) во главе с генеральным директором компании РОСА Владимиром Рубановым.
Сразу сообщу, что “сражение” завершилось полной победой Андрея Бешкова — он был конструктивен, логичен, убедителен. Представители сообщества СПО пытались противопоставить ему задор, азарт и эмоции, которых, однако, оказалось недостаточно, чтобы склонить в свою пользу зал и рефери на “ринге”.
Апологеты СПО и в этот раз были нерациональны в своей оценке деятельности софтверных компаний, сосредоточенных на разработке и продвижении ППО. Можно ли обвинять, например, Microsoft в том, что в свое время ее создатели потратили усилия на разработку ОС массового применения, добившись в результате доминирования в этом сегменте (а потом и не только в этом)? Кто мешал и мешает сообществу СПО занять то место, которое ныне занимают такие компании, как SAP, Oracle, CA? Сообщество пользователей будет, как мне представляется, только признательно, если бесплатно получит программные продукты и поддержку того же качества, какое сегодня получает от этих вендоров, выплачивая им немалые деньги.
Для потребителя не имеет никакого значения, на базе каких заготовок разработана та программа, которая вертится внутри его компьютера или иного устройства. Но свои требования к ИБ этой программы он обязательно предъявит, и требования эти зависят от того, к какому пользовательскому сегменту он относится — к индивидуальным или корпоративным пользователям, к сегменту массового потребления или к специальным, режимным структурам.
Кстати, любая компания-разработчик, которая на базе СПО создает продукт и начинает продвигать его по рыночным правилам, действует так же, как упомянутые выше софтверные гиганты: она берет на себя бремя обновления версий, исправления ошибок, сертификационных аттестаций (если нужно) и требует за это вознаграждения от пользователей. Возможно, старт у таких разработок получается менее затратным и быстрым, поскольку начинаются они не с чистого листа, а с неких СПО-наработок. Зато потом всё у них идет “по-взрослому” — по законам коммерции.
Поклон тем энтузиастам-альтруистам от программирования, которые тратят свое время и интеллект на создание и распространение бесплатных программ. Но это — совершенно иная софтверная ниша, работающая в основном на индивидуального потребителя. Как только какая-нибудь СПО-наработка втягивается в сферу корпоративного потребления, у нее появляется пользователь, который требует от разработчика ответственности за ее качество, включая ИБ, на коммерческой основе. Возможно, это будет внутренний разработчик, но и он не избежит такой ответственности.
От обсуждения концептуальной информационной безопасности СПО и ППО, мне кажется, нужно отказаться, а сосредоточиться на сравнении ИБ конкретных программных продуктов, четко разделяя при этом их назначение: индивидуальные пользователи, массовый или корпоративный рынок, режимные структуры — и не забывать при этом, что требования к ИБ у пользователей этих сегментов разное.
Сторонники СПО в контексте сравнительного обсуждения безопасности СПО и ППО нередко поднимают тему национальной безопасности, зависимости страны от зарубежных разработок. Тема правильная, но чтобы ее закрыть, недостаточно разработать национальную BIOS или операционную систему на базе СПО. Впрочем, хоть с чего-то начинать нужно…
Информационная безопасность экосистемы открытого ПО
В 2010 г. в нашей стране принято правительственное решение о переводе к 2015 г. федеральных органов исполнительной власти и федеральных бюджетных учреждений на использование СПО. Глава Минкомсвязи РФ оценивает потенциал страны для внедрения СПО как большой, отмечая вместе с тем малое количество качественных рыночных СПО-продуктов. Из его слов, высказанных на встрече в мае 2013 г. руководства министерства с представителями экспертного сообщества, где обсуждались вопросы создания Национальной программной платформы (НПП) и поддержки СПО, также следует, что руководство страны все еще не определилось с подходами к поддержке СПО.
Одним из ключевых требований к СПО, согласно ГОСТ Р 54 593-2011 «ИТ. СПО. Общие положения» (действует с 1.01.2012), является информационная безопасность (ИБ). Половина участников опроса, проведенного PC Week/RE в I квартале 2013 г., убеждена в том, что система разработки СПО обеспечивает его безопасность, в то же время 41% респондентов сомневаются в этом, а остальные 9% затруднились дать определенный ответ.
Однако, по мнению Олега Лекшина (ИВК), у «самотестирования» и «самопроверок» сообществом СПО своих продуктов есть существенный недостаток, о котором следует помнить: в среде СПО нужно выделять программные продукты, используемые широко, и те, что известны мало. Первые действительно хорошо и оперативно тестируется сообществом пользователей и разработчиков, и уязвимости в них быстро устраняются. Зато вторые по причине их слабой проверки следует признать небезопасными.
Александр Максимовский (ФСБ РФ) отмечает, что ведущие мировые вендоры ППО преуспели в качестве своих ПП для широкого потребления и выгодно отличаются этим от вендоров продуктов с открытым кодом. Это означает, что в модели продвижения СПО в среде массового потребления ПО есть что исправлять.
Вместе с тем очевидно, что использование безопасного инструмента разработки ПП, несомненно, будет способствовать повышению ИБ конечного ПП. Поэтому трудно согласиться с мнением некоторых участников круглого стола, считающих неактуальным обсуждение вопросов безопасности экосистемы СПО и предлагающих сосредоточиться только на возможности обеспечения ИБ с использованием СПО.
Заказчики и поставщики
Особенности экосистемы СПО быстро вывели заседание круглого стола на обсуждение модели отношений между заказчиком программных продуктов и их поставщиком.
Немало качественных ПП делается в экосистеме СПО исключительно на энтузиазме, поскольку инновация является хорошим способом самовыражения, а люди не всегда требуют за самовыражение деньги. Однако полагаться только на энтузиазм бизнес не может.
По экспертной оценке специалистов веб-сайтов InfirmIT.com, Tamingthe Beast.net и CloudTweaks.com, в числе главных недостатков СПО находится его, как они выражаются, бесхозность, которая ставит пользователей СПО в зависимость от настроений группы разработчиков того или иного СПО-продукта продолжать работу над ним, ведь при отсутствии такого настроения пользователи должны быть готовы к тому, чтобы сопровождать продукт собственными силами.
По данным исследования компании Zenoss, главной причиной выбора не в пользу свободного ПО у респондентов исследования было отсутствие хорошей технической поддержки и плохая сопроводительная документация.
Апологеты СПО, в свою очередь, обращают внимание на то, что модель СПО освобождает пользователей ПП от зависимости от владельцев ППО, которые, руководствуясь собственными бизнес-планами, могут прекратить поддержку своих разработок в любое время. Сторонники СПО считают надежность поддержки ПП фундаментальным свойством схемы СПО. По их мнению, если какому-либо заказчику потребуется наладить поддержку ПП, созданного как СПО, он всегда может найти команду специалистов, которая это сделает. Пользователь СПО-продукта может получить доступ к его кодам, среде сборки, репозиторию поддержки и продлить жизнь СПО-продукта также усилиями собственных разработчиков. Поменять провайдера поддержки в экосистеме СПО гораздо проще, чем в экосистеме ППО. Стало быть, как считают последователи экосистемы СПО, она способствует улучшению отношений между заказчиком и поставщиком.
К несомненным преимуществам модели СПО по сравнению с моделью ППО сторонники первой также относят возможность не нагружать ПП избыточным функционалом. Движимые целью извлечения максимальной прибыли вендоры ППО нередко продвигают заведомо несбалансированные по функционалу ПП, не оптимально реализующие бизнес-функцию, на поддержку которой они изначально сориентированы, заставляя тем самым заказчика платить за то, чем тот пользоваться не собирается.
Как на недостаток иностранного ППО г-н Прохаска указывает на то, что лицензионные соглашения на него регламентируются совсем не российскими законами, защищают привилегии вендоров, понуждают заказчиков молчаливо соглашаться с тем уровнем ИБ, который закладывает в него разработчик, в то время как в ситуации с СПО лицензионные соглашения работают, по его мнению, в пользу заказчика.
Сравнивая качество поддержки в экосистемах СПО и ППО, Олег Лекшин обращает внимание на то, что существует множество форумов, на которых многочисленные члены сообщества разработчиков СПО обсуждают варианты одного и того же ПП. Однако организовать учет и анализ всех этих вариантов в целях поддержки ПП очень сложно. Вместе с тем количество специалистов-разработчиков СПО в мире намного больше, чем у любого современного софтверного гиганта, занимающегося разработкой ППО. Это, как он полагает, придает технической поддержке в модели СПО свойства надежности и масштабируемости.
В то же время среди лидеров разработчиков проприетарного ПО преобладают крупные компании, функционирование системы поддержки которых, как выразился г-н Лекшин, предсказуемо, хотя данная система и обладает большой инерционностью при отработке обращений к ним пользователей, что создает явные неудобства для последних.
В услуге поддержки ПП существенным фактором является ее продолжительность. Нередко можно услышать мнение, что чем она длительнее, тем лучше для заказчика. Однако требовать от вендоров «вечной» поддержки бессмысленно, хотя бы потому, что оборудование, с которым работает ПП, изнашивается и морально устаревает.
Основные фонды российских предприятий списываются в среднем через десять лет, примерно с такой же периодичностью предприятия стараются обновлять ПО, а по многим категориям фондов цикл этот имеет тенденцию сокращаться. Согласно наблюдениям Елены Соломатиной (НЦПР) жизненный цикл ПО у тех заказчиков, с которыми ей приходилось работать, составляет семь лет, более длительная поддержка ПП является исключением.
Будучи исполнителями специальных заказов на ПП (например, закрытого ПО для государственных структур), разработчики берут на себя обязательства по срокам поддержки, диктуемым заказчиком и составляющим порой десятилетия. Взаимодействие таких особенных заказчиков с внешними поставщиками и исполнителями работ определяется установленными регламентами, такими как принятый 7 июня 2013 г. закон № 114-ФЗ «О внесении изменений в Федеральный закон «О размещении заказов на поставки товаров, выполнение работ, оказание услуг для государственных и муниципальных нужд».
Российские заказчики, реально озабоченные вопросами ИБ, предпочитают, как отмечает Аркадий Тагиев (РОСА), заключать договоры с российскими же разработчиками ПП, которые в состоянии выполнить весь объем требований, предъявляемых к ПП, использовать для этого любые средства разработки, в том числе и СПО (и в этом случае взять на себя обязанности по документированию и проверке конечного ПП). Такой ПП живет до тех пор, пока заказчик не потребует его утилизации.
Важным фактором при этом является финансирование работ, в том числе и по поддержке ПП. Случается, что порой заказчику бывает выгоднее привязаться к работающему ПО и под него покупать подержанное оборудование, на котором оно все еще работает.
Г-жа Соломатина усматривает несколько проблем в отношениях разработчиков СПО с госзаказчиками, прежде всего, касающихся ценообразования. По ее мнению, те цены, которые предлагают госзаказчики, не всегда соответствуют ожиданиям разработчиков.
Другой важной проблемой в этой области она называет регулирование прав на интеллектуальную собственность. В соответствии с типовым договором на разработку программный продукт может оказаться собственностью либо заказчика, либо разработчика, либо в совместном владении. Однако госзаказчики, особенно представляющие силовые структуры, на практике реализуют исключительно передачу ПП в свою собственность (разработчик может потом участвовать в конкурсе на поддержку, имея некоторые преференции как провайдер, хорошо знающий объект поддержки). В то же время зарубежные вендоры ППО сохраняют права собственности на свои ПП, даже при их продаже в силовые структуры нашей страны.
Через стандарты и сертификаты к ИБ СПО
Чтобы получить качественный, в том числе и по критериям ИБ, программный продукт и убедить в этом потенциальных заказчиков, разработчикам, по мнению некоторых участников круглого стола, достаточно следовать государственным стандартам по разработке ПП.
Как отметил г-н Тагиев, залогом безопасности и надежности ПП является сопроводительная документация, используя которую как раз и можно проверить свойства продукта.
Однако объем кода любого ПП за последние пару десятилетий увеличился в несколько раз (иные эксперты утверждают, что на порядки), и документировать процесс разработки с той же подробностью, что и в 80-е годы (пожелание о чем высказали некоторые участники круглого стола), нереально. В стране назрела потребность пересмотреть с учетом этого действующие в данной области ГОСТы.
Основные выводы
В ходе горячего обсуждения вопросов состояния информационной безопасности экосистемы СПО, представляемой некоторыми участниками в начале дискуссии «Информационная безопасность экосистемы СПО» в виде «сферического коня в вакууме», ИБ СПО обрела-таки конкретные черты.
Сегодня требования к ИБ программных продуктов во многом определяются не рыночными механизмами, а давлением со стороны регуляторов, прежде всего из числа государственных структур. Понимание же ИБ как одного из наиболее важных потребительских качеств ПО в эпоху бума информационных технологий только начинает приходить как к пользователям, так и к разработчикам ПО. Пока же в их рядах преобладает отношение к ИБ как к «налогу», который «выплачивается» только под внешним контролем.
В мире существуют и доступны для бесплатного использования стандарты и готовые методики разработки безопасного ПО, одинаково пригодные как для модели СПО, так и для модели ППО. Но поскольку для разработчиков на первом плане стоят функционал и сроки, а для пользователей функционал и удобство применения, то требовать ИБ от программных продуктов пока некому, кроме, разве, регулятора.
Разработчики СПО, участвовавшие в дискуссии, признали, что видят в повышении ИБ своих продуктов перспективы для развития их собственного бизнеса и рынка СПО в целом. Более того, они считают безопасность и стабильность открытого кода локомотивом роста популярности СПО и отмечают при этом, что свойства самой экосистемы СПО позволяют ПП, созданным на базе СПО, проще проходить процедуры сертификации. Они подчеркивают, что среди таких ПП есть имеющие весьма высокие ИБ-сертификаты, в том числе и российские.
По мнению наших экспертов, нынешнее состояние экосистемы СПО и уровень подготовки российских программистов, предпочитающих работать по этой модели, вполне могут соответствовать самым высоким требованиям к ИБ со стороны российских заказчиков, в том числе в спецпроектах. Главным при этом признаются факторы сроков и объемов финансирования.
Можно надеяться, что состоявшееся обсуждение вопросов состояния ИБ экосистемы СПО поможет стимулировать поиск новых путей взаимодействия между специалистами, которые занимаются обеспечением ИБ на общегосударственном и корпоративном уровнях, и сообществом, объединяющим энтузиастов СПО.
Понятие системного программного обеспечения и прикладного программного обеспечения. Отличие спо и ппо. Кольцевая схема вычислительной системы
Оглавление
^ Сервисное СПО – это программы и программные комплексы, которые расширяют возможности базового программного обеспечения и организуют более удобную среду работы пользователя.
ОС – совокупность программных средств, обеспечивающая управление аппаратной частью компьютера и прикладными программами, а так же их взаимодействие между собой и пользователем.
ОС выполняя роль посредника, служит двум целям: эффективно использовать компьютерные ресурсы и создавать условия для эффективной работы пользователя.
Операционные системы различаются особенностями реализации алгоритмов управления ресурсами компьютера, областями использования.
Ресурс – всякий объект, который может распределяться внутри системы.
Вычислительная система (ВС) – это взаимосвязанная совокупность аппаратных средств вычислительной техники и программного обеспечения, предназначенная для обработки информации.
Процесс – часть задания, которая выполняется на отдельном устройстве.
1. Отслеживание состояния занятости процессора каким-либо процессом (какое время и в каком режиме);
2. Решение о выделении времени процессора какому-либо процессу на основе какой-либо стратегии;
3. Выделение процессорного времени;
4. Освобождение процессора от процесса.
Диспетчеризация – задача динамического кратковременного планирования (тактика).
Область, не занятая ОС будет выделена заданию пользователя; если объем доступной памяти больше объема задания, то появится фрагмент.
| Преимущества | Недостатки |
| 1. Простота | 1. Однозадачность |
| 2. Неэффективное использование ресурса ОП (размер фрагмента может быть очень большим) |
Различают статическое и динамическое распределение.
Статическое – выделяется раздел, а потом поступает задание.
Динамическое – сначала поступает задание, а потом выделяется раздел.
| Преимущества | Недостатки |
| 1. Реализация мультипрограммирования | 1. Необходим предварительный анализ по количеству запланированных заданий |
| 2. Более эффективное использование ресурсов | 2. Наличие фрагментации внутри раздела |
| 3. Достаточная простота алгоритмов | 3. Ограничение на размер задания |
Устройство — искусственный объект, имеющий внутреннюю структуру, созданный для выполнения определённых функций.
^ Устройства ввода: клавиатура, мышь, микрофоны, сканеры, графические планшеты.
Устройства вывода: мониторы, колонки, принтеры, плоттеры, виртуальные манипуляторы.
^ Драйвер устройства – программа ОС для управления работой периферийных устройств: дисководами, дисплеем, клавиатурой, мышью, принтером.
Достоинства и недостатки:
+: можно использовать этот режим для устройств, не работающих по схеме разделения, количество обслуживаемых процессов не ограничено
–: дополнительная схема управления.
Логический диск или том — часть долговременной памяти компьютера, рассматриваемая как единое целое для удобства работы. Термин «логический диск» используется в противоположность «физическому диску», под которым рассматривается память одного конкретного дискового носителя.
Для операционной системы не имеет значения, где располагаются данные — на лазерном диске, в разделе жёсткого диска, или во флеш-памяти. Для унификации представляемых участков долговременной памяти вводится понятие логического диска.
В таблице определяется, в каком каталоге (папке) находится тот или иной файл. Благодаря этому при переносе файла из одной папки в другую в пределах одного тома, не осуществляется перенос данных из одной части физического диска на другую, а просто меняется запись в таблице размещения файлов. Если же файл переносится с одного логического диска на другой (даже если оба логических диска расположены на одном физическом диске), обязательно будет происходить физический перенос данных (копирование с дальнейшим удалением оригинала в случае успешного завершения).
Файловая система – набор соглашений, определяющих организацию данных на носителе информации.
Реализация файловой системы связана с такими вопросами, как поддержка понятия логического блока диска, связывания имени файла и блоков его данных, проблемами разделения файлов и проблемами управления дискового пространства.
Наиболее распространенные способы выделения дискового пространства: непрерывное выделение, организация связного списка и система с индексными узлами.
Файловая система часто реализуется в виде слоеной модульной структуры. Нижние слои имеют дело с оборудованием, а верхние с символическими именами и логическими свойствами файлов.
Статья на вики
| Транслятор (англ. translator — переводчик) — это программа-переводчик. Она преобразует программу, написанную на одном из языков высокого уровня, в программу, состоящую из машинных команд. |
Трансляторы реализуются в виде компиляторов или интерпретаторов. С точки зрения выполнения работы компилятор и интерпретатор существенно различаются.
Компилятор (англ. compiler — составитель, собиратель) читает всю программу целиком, делает ее перевод и создает законченный вариант программы на машинном языке, который затем и выполняется.
Интерпретатор (англ. interpreter — истолкователь, устный переводчик) переводит и выполняет программу строка за строкой.
После того, как программа откомпилирована, ни сама исходная программа, ни компилятор более не нужны. В то же время программа, обрабатываемая интерпретатором, должна заново переводиться на машинный язык при каждом очередном запуске программы.
| Откомпилированные программы работают быстрее, но интерпретируемые проще исправлять и изменять. |
Двухпросмотровый ассемблер с оверлейной структурой.Управляющая программа
Общие таблицы и подпрограммы
Подпрограммы и таблицы первого просмотра
Подпрограммы и таблицы второго просмотра
а) Ассемблер записывает объектную программу непосредственно в оперативную память для немедленного использования.
б) Ассемблер создает объектную программу, которая будет использоваться позднее.