Цикл статей в 3-х частях
Еще 20 лет назад редко приходилось слышать про «безопасность программного обеспечения» в прессе и даже в кулуарах. Начиная с 2010-х тема безопасности стала все чаще появляться в заголовках статей и просто в разговорах менеджмента компаний. Примерно в то же время начались тектонические сдвиги в разработке требований безопасности к различным средствам защиты информации и требований по разработке безопасного программного обеспечения.
За 20 лет ситуация кардинально поменялась. Теперь о безопасности говорят постоянно. Сдвиги в этой области были обусловлены бурным развитием ИТ-технологий, на рынке появилась каста людей, именуемых «Разработчики», которые писали код, автоматизировали все, что можно было автоматизировать, создавали пользовательские сервисы и информационные системы, способные обслуживать бизнес и государственные структуры.
Большинство из этих разработчиков обладали навыками программирования на различных языках, но ничего не знали о безопасных методах разработки. Не знали они и об уязвимостях, которые вносили в код использованием небезопасных конструкций. С этим надо было что-то делать, и работа над ошибками началась. В 2016 году ФСТЭК России утвердил приказом № 119 требования безопасности к операционным системам. С того времени началось бурное развитие продуктов данного класса на рынке. На сегодняшний день мы имеем порядка 15 операционных систем, имеющих сертификат соответствия данным требованиям.
После 2022 года начался массовый отток из РФ привычных нам зарубежных вендоров программного обеспечения, в том числе и вендоров операционных систем, таких как Microsoft, Red Hat и прочих. Российский бизнес стал массово импортозамещать программное обеспечение, на котором работал десятилетиями. Одними из самых частых вопросов при замещении операционных систем стали:
Какую операционную систему выбрать? Какая из 15 существующих операционных систем безопаснее и больше подойдет для решения наших задач?
В цикле статей на эту тему предлагаю ответить на данные вопросы и помочь читателям разобраться в том, что сейчас происходит на рынке, а также развеять существующие на рынке мифы.
Миф № 1. «Если я приобрету сертифицированную ОС, то могу быть уверенным в ее безопасности».
Часто наличие сертификата соответствия не говорит о полной безопасности продукта. Сертификат соответствия — это всего лишь свидетельство того, что обладающий им продукт соответствует тем или иным требованиям, предъявляемым регулятором в конкретной области. Например, сертифицированные ОС на рынке обычно соответствуют требованиям к ОС согласно приказу № 119 ФСТЭК России, Профилю защиты операционных систем, а также Требованиям доверия согласно приказу № 76 ФСТЭК России.
По сути, приказ № 119 определяет сводные требования безопасности для всех типов ОС (общего назначения, встраиваемые и реального времени) и классов их защиты (с 1-го по 6-ой). Данные требования детализируются и предъявляются в Профиле защиты для ОС конкретного типа и класса защиты. В нем определены различные угрозы для ОС и среды ее функционирования, устанавливаются цели обеспечения безопасности и приводятся функциональные требования безопасности к ОС. Таким образом — наличие сертификата соответствия ОС требованиям приказа № 119 и Профилю защиты конкретного типа и класса защиты будет гарантировать, что ОС реализует функционал, предъявляемый Профилем защиты, а также может противостоять определенным в Профиле защиты угрозам.
Приказ № 76 предъявляет определенные требования к процессу разработки и производства программных и программно-технических средств (далее по тексту - средств), процессу проведения испытаний средств и поддержки уровня заявленной безопасности в процессе эксплуатации средств. В документе предъявляются серьезные требования, направленные на достижение высокого уровня безопасности продуктов, реализация которых при разработке и эксплуатации ОС могла бы свидетельствовать о реальной безопасности программного обеспечения. К сожалению, в современных реалиях не все требования реализуются вендорами так, как предполагалось документом, не все испытания, направленные на обнаружение уязвимостей, приносят результат из-за недостаточной квалификации специалистов, их проводящих. Не все процессы, организованные у вендора, проверяются от начала и до конца их выполнения из-за невозможности валидации процесса в связи с ограниченным по времени сроком сертификации, что зачастую приводит к проверке некоторых процессов путем документального соответствия реализации предписанных процессов и верификации полученных результатов в ходе их выполнения.
Из этого следует, что нельзя назвать сертифицированную по этим требованиям ОС «полностью безопасной», скорее можно сказать, что ОС может обеспечивать защиту от определенных угроз, а также вендор в состоянии проводить обновление данной системы и оказывать техническую поддержку.
На сегодняшний день на российском рынке присутствуют ОС, которые не сертифицированы по требованиям безопасности информации, но при этом могут обеспечивать уровень безопасности не хуже, чем их сертифицированные конкуренты. В связи с этим вам стоит определиться с целями, которые преследует ваша организация и исходя из них подбирать себе ту ОС, которая сможет покрыть все потребности персонала и обеспечить должную защиту обрабатываемой в ней информации. Если информационная система вашей организации, в которую предполагается ставить ОС, относится к государственным информационным системам (выполняете требования 17 приказа ФСТЭК России), автоматизированным системам управления технологическими и производственными процессами (выполняете требования 31 приказа ФСТЭК России), информационным системам обработки персональных данных (выполняете требования 152-ФЗ), либо предполагается применять ОС в значимом объекте критической информационной инфраструктуры (выполняете требования 187-ФЗ), то проще будет выбрать ту ОС, которая имеет сертификат соответствия требованиям по безопасности информации. Однако, проще — не всегда лучше. Есть и другой путь — применение на данных объектах несертифицированной ОС совместно с наложенными средствами защиты информации. Такой подход не всегда хуже, чем применение сертифицированной ОС, т. к. в сертифицированных версиях зачастую пренебрегают удобством для пользователей и урезают определенный функционал в пользу выполнения требований по безопасности информации. Выбрав этот путь вы сможете получить функциональную и удобную в использовании ОС, отвечающую всем требованиям организации и с помощью установки в ее среду СЗИ от НСД выполнить все требования регулятора, предъявляемые к защите информации в данных информационных системах. О всех плюсах и минусах такого подхода можно рассказать много интересного, но это займет не одну страницу текста. Чтобы не запутать читателя, я подниму эту тему в отдельной статье, где расскажу про все нюансы такого подхода и подсвечу детали, на которые стоит обратить внимание. А сейчас продолжим про выбор именно сертифицированной версии ОС.
Как же понять, какую ОС выбрать и какая из них будет более безопасной?
Для того, чтобы ответить на этот вопрос, придется не просто полагаться на наличие сертификата соответствия требованиям безопасности информации, но также провести определенную аналитическую работу при выборе.
Миф № 2. «Большинство сертифицированных ОС отличаются набором средств защиты».
С точки зрения функций безопасности сертифицированных операционных систем — они у большинства идентичны, при условии сравнения ОС одного и того же типа и класса защиты. Чем выше класс защиты, тем больше функциональных требований к безопасности предъявляет Профиль защиты, но если Вы не обрабатываете на своих системах информацию, составляющую гос. тайну, то нет смысла рассматривать ОС с классами выше четвертого, т.к. пользоваться дополнительными функциями защиты, наподобие мандатного разграничения доступа и маркировки документов, вы все равно не будете. Конечно, могут быть случаи, когда отечественные вендоры предлагают какие-то уникальные механизмы безопасности, отличающие их систему от систем конкурентов, но честно говоря, глобальных функций по защите я не встречал, чаще какие-то незначительные доработки существующего (опенсорсного) функционала. Чаще всего вендор ограничивается реализацией только тех функциональных возможностей по защите, требования к которым предъявляет регулятор в Профиле защиты.
Если все сертифицированные операционные системы обеспечивают одни и те же функции по защите информации, то нет разницы, какую покупать? На самом деле есть – и очень большая. Только рассматривать нужно другие аспекты – их мы обсудим в следующей статье по данной теме.
To Be Continued...
Комментарии (29)
Johan_Palych
10.06.2024 11:30+1Вангую, что весь цикл статей закончится рекламой Инферит ОС - МСВСфера АРМ/Сервер
Maksim_Fokin Автор
10.06.2024 11:30+1Нет. Я принципиально пишу не рекламную статью, а делюсь опытом, который собирал больше 10 лет. Ни одного упоминания про любые существующие ОС на рынке вы не увидите. Первая статья была вводной, тут ничего интересного нет. Вторая будет уже более интересной. Далее спойлер - А закончится это всем чек-листом по подбору ОС на нашем рынке.
IsKaropk
10.06.2024 11:30+2А закончится это всем чек-листом по подбору ОС на нашем рынке.
Астра
РЕД
Алт
Я угадал?
Maksim_Fokin Автор
10.06.2024 11:30Я же уже сказал - ни одного названия ОС или вендора вы не увидите в статье. Это не рекламная статья:)
Ostan
10.06.2024 11:30Роса
Какой смысл писать статью в трёх частях, если в конечном итоге количество сертифицированных ОС в России можно пересчитать по пальцам одной руки?
Maksim_Fokin Автор
10.06.2024 11:30Как я сказал в статье - их 15. И их количество продолжает увеличиваться.
andrettv
10.06.2024 11:30А почему в голосовалке нет пункта о наличии и количестве участников программы Bug Bounty, выплаченных вознаграждениях? Соотношении обнаруженных и закрытых уязвимостей, среднем времени их устранения?..
Maksim_Fokin Автор
10.06.2024 11:30Вы считаете, что это массовый критерий, которым пользуется большинство людей при выборе ОС?
andrettv
10.06.2024 11:30Конечно! Поскольку не бывает ПО без уязвимостей, покупателей волнует как у разработчика поставлен процесс управления уязвимостями. Если статистики по обнаруженным/исправленным нет, то либо их никто не тестирует, либо не исправляет, либо исправляет, но так долго, что стыдно это публиковать. Наиболее зрелые компании не ограничиваются внутренним тестированием, т.к. его охват ограничен ресурсами, и запускают публичные программы. Посмотрите, например, результаты https://communityblog.fedoraproject.org/exploring-our-bugs-part-1-the-basics/, https://www.wired.com/story/hack-the-pentagon-bug-bounty-results/. Вот наши площадки https://codeby.school/blog/informacionnaya-bezopasnost/ohota-na-bagi-spisok-ploschadok-dlya-bug-bounty.
Maksim_Fokin Автор
10.06.2024 11:30С вашими доводами полностью согласен и поддерживаю. Я этот момент как раз буду поднимать в следующей части статьи. Существует только одно "но"...На рынке сейчас только одна ОС вышла на такие площадки с программой Bug Bounty. Это круто, когда вендор ОС вкладывает деньги в безопасность, выходит на такие площадки и т.п., но мне кажется (ИМХО), сначала нужно поднять хороший процесс по безопасности внутри компании и только потом выходить на такие площадки. Иначе, как писал Михаил Булгаков:
"Вы, профессор, воля ваша, что-то нескладное придумали! Оно, может, и умно, но больно непонятно. Над вами потешаться будут"
Что в целом и произошло по результатам выхода этой компании на площадку (сужу по статьям на хабре, в которых исследователи описывали как они тестили, как им деньги не платили, какие доисторические уязвимости находили в ключевых компонентах ОС и т.п.).
Когда вендоры ОС в нашей стране достигнут того уровня внутренних процессов по обеспечению безопасности своих продуктов, чтобы можно было выходить на площадки и показывать, что мол "у нас безопасные системы, попробуйте что-нибудь в них найти", тогда такой пункт будет показателем их реальной работы и его и правда можно будет добавить в список. А пока что выход на Bug Bounty площадки таких вендоров - это не показатель их крутой внутренней работы по поиску уязвимостей, а скорее просьба о помощи к народу, вроде "ребята, у меня нет хороших спецов, которые могут найти уязвимости, прошу помощи и готов заплатить вам деньги". Я бы к такому вендору наоборот не пошел (ИМХО). Поэтому, на сегодняшний день, не считаю данный пункт необходимым в списке вопросов.
andrettv
10.06.2024 11:30Белые шляпы, конечно, могут и подождать. А что делать с черными? У них ипотека, им ждать некогда.
Maksim_Fokin Автор
10.06.2024 11:30Я не говорю, что белые шляпы должны подождать. Я говорю лишь о том, что вендор, который хочет сделать хороший и безопасный продукт, должен содержать в своем штате исследователей (белых шляп), и развить для начала внутри все процессы. И когда он почувствует, что его белые шляпы уже ничего нового найти не могут, вот тогда отправляться на площадки Bug Bounty, для обеспечения внешнего элемента проверки, когда внутренние уже не результативны. Иначе получается, что сам вендор сделать ничего не может и передает это дело людям на сторону и зависит чисто от их желания/сообразительности/времени и т.п. При этом на таких площадках чаще всего тестируют Black Box, и если уж ребята с площадки находят у тебя уязвимости не видя кода твоего изделия, то встает вопрос: "А твои то люди чем занимаются в компании? У них есть доступ к коду, есть всевозможные анализаторы и еще кучу приблуд. Почему люди на площадке методом Black Box что-то находят, а твои методом White Box найти не могут?". Тут сразу думается, что либо вендор экономит на специалистах, либо специалисты у него не очень, либо внутренние процессы работают неправильно, либо все вместе взятое. И тогда получается, почему я должен отдавать приоритет этому вендору, если у него внутри такие проблемы? Я лучше отдам приоритет вендору, которого нет на Bug Bounty площадках, но у которого и уязвимости внутри находятся и устраняются, и про которого не пишут на Хабре или других площадках о том, что в составе его ОС уязвимости нулевых годов. И вот только поэтому не вижу смысла этот пункт добавлять:)
Vinni37
10.06.2024 11:30+1Автору как к специалисту в этой сфере вопрос. Вот у нас есть сертифицированная ОС на отдельно стоящем АРМ с интернетом. Нам надо закрыть требование к МЭ типа «В» (межсетевой экран уровня узла). Как рассказал нам один вендор, они не выполняют требования к МЭ в их ОС, т. к. профиль защиты для ОС предполагает куда меньший функционал, чем предъявляется для сертифицированного МЭ. Отсюда вопрос: как быть, если отдельных софтовых МЭ нет, есть только в составе комплексного СЗИ (Dallas или SecretNet)? Но если брать эти СЗИ, тогда зачем сертифицированная ОС? Поправьте, может, я что-то упустил.
Maksim_Fokin Автор
10.06.2024 11:30Хороший вопрос. Вендор, с которым вы общались, прав. МЭ, который входит в состав сертифицированной ОС и правда выполняет не все функции безопасности, которые предусматриваются профилем защиты (далее по тексту - ПЗ) на МЭ типа В. Если быть точнее, то МЭ, который входит в состав ОС, конечно, может выполнять все необходимые функции, но проблема в том, что в соответствии с профилем защиты на ОС половина необходимых для МЭ функций просто не проверяется при сертификации, т.к. ПЗ на ОС не предполагает проверок этих функций. В связи с этим МЭ с одной стороны по функционалу может подходить, но с другой стороны этот функционал никто не проверял при испытаниях, в связи с чем нельзя сказать, что все функции работают так, как предписано профилем защиты на МЭ. Отсюда вытекают требования регулятора приобретать именно тот МЭ, который был сертифицирован на ПЗ к МЭ типа В, т.к. его функциональные возможности точно проверялись и можно быть уверенным, что он будет обеспечивать защиту от угроз, которые приведены в ПЗ на МЭ типа В.
Относительно средств, которые можно применять в таком случае: не только в СЗИ от НСД (Dallas или SecretNet) входят МЭ. На рынке есть ряд самостоятельных продуктов, которые можно применять. Пожалуйста, не сочтите за рекламу, но в реестре ФСТЭК я вижу как минимум следующие самостоятельные средства, которые можно рассмотреть к применению:
ViPNet 4;
ViPNet Personal Firewall 4.5;
ViPNet EndPoint Protection;
С-Терра Клиент. Версия 4.2;
С-Терра Клиент. Версия 4.3;
Diamond VPN/FW;
«ЗАСТАВА-Клиент «VPN/FW «ЗАСТАВА, версия 6».
Vinni37
10.06.2024 11:30ViPNet 4 - Это все же СКЗИ
ViPNet Personal Firewall 4.5 - По слухам умрет в этом году;
ViPNet EndPoint Protection - МЭ как модуль, по факту это СОВ со срочными лицензиями;
С-Терра Клиент. Версия 4.2 - СКЗИ с МЭ;
С-Терра Клиент. Версия 4.3 - СКЗИ с МЭ;
Diamond VPN/FW - очень спорный вариант, по сути СКЗИ с МЭ.
«ЗАСТАВА-Клиент «VPN/FW «ЗАСТАВА, версия 6». - честно не изучали, но я так понимаю тоже СКЗИ с МЭ.
Maksim_Fokin Автор
10.06.2024 11:30Однако же наличие сертифицированного ФСБ СКЗИ в этих продуктах не мешает применять большинство из них именно как МЭ. И самое главное, что на них есть действующий сертификат ФСТЭК на ИТ.МЭ.В4.ПЗ, что позволяет их применять на объектах информатизации для нейтрализации существующих угроз, которые можно закрыть МЭ такого типа и класса защиты.
Если вы ищете на рынке чистый FW без лишнего функционала, добавленного вендорами, то получается, что да, таких экранов не будет. Тут как покупать машину: я хочу, чтобы у нее было 4 колеса, руль и мотор. Больше мне ничего не нужно. Но когда я прихожу к дилерам, то они мне зачем-то дают машину с климат-контролем, автоматом, кожаными сидениями, кучей всякой электроники и т.п. И сколько бы я не искал машину на рынке чисто с 4 колесами, рулем и мотором, я ее не найду. В случае с FW, думаю, работает так же.
Vinni37
10.06.2024 11:30Логика производителей понятна. Но СКЗИ это все же привязка к какой либо сети с доп накладными расходами. Для себя мы склоняемся к варианту СЗИ от НСД с МЭ (Dallas Lock или SecretNet) и не сертифицированная ОС. По цене выходит +- тоже самое местами даже дешевле. При этом возникает вопрос:
Но если брать эти СЗИ, тогда зачем сертифицированная ОС?
Maksim_Fokin Автор
10.06.2024 11:30С точки зрения функционала, что несертифицированная ОС + СЗИ от НСД, что сертифицированная ОС - одинаковы (за исключением пары функций, таких как, например наличие/отсутствие сертифицированного МЭ). Дьявол кроется в деталях. СЗИ от НСД ставится поверх ОС, при этом заменяя важные компоненты ОС (компоненты разграничения доступа, контроля целостности и т.п.) своими компонентами. Кто знает, поломает ли такая замена что-то в ОС или нет? Обычно вендоры СЗИ от НСД пытаются тестировать совместимость своих средств с различными ОС, но даже в таком случае, гарантировать, что все будет работать штатно нельзя. Например, с мажорной версией ОС (чаще всего тестируют именно с ней) их СЗИ будет работать штатно, но после установки обновлений ОС все слетит из-за того, что вендор ОС повысил версию пакета какого-то компонента ради устранения в нем уязвимости, а СЗИ от НСД с пакетом старшей версии работать не сможет.
На практике встречал такие случаи и заканчивались они следующим: пользователь приходил к вендору СЗИ от НСД с проблемой, те отправляли его к вендору ОС. Вендор ОС разбирался в проблеме и отправлял пользователя обратно к вендору СЗИ от НСД. И так по кругу... И доказать, что кто-то из них не прав - тяжело.
Если вы рассматриваете такой вариант применения, то обязательно уточните у обоих вендоров, ведут ли они процесс по взаимной поддержке мажорных и минорных версий СЗИ от НСД и ОС между собой. Тестироваться должно любое изменение одного из продуктов с актуальной версией другого и только после этого попадать к пользователю. Реализация такого процесса у этих вендоров - трудный процесс (один хочет быстрее выпустить обновление, другой ленится переписывать свое изделие, т.к. нужно проводить по новой сертификацию и т.п.). На практике очень трудно найти 2х таких вендоров, которые будут работать как единая команда. Самый идеальный вариант при необходимости применения такого решения найти вендора, который будет поставщиком обоих решений, и в случае каких-либо проблем вы будете обращаться в единое окно.
Описанное выше - это только малая часть проблем, с которыми можно столкнуться при таком подходе. Выбирая его нужно быть осторожным. Я опишу все нюансы, о которых мне известно, в отдельной статье про выбор несертифицированной ОС (выйдет позже...может быть в июле-августе).
Вывод: если хотите работать с меньшим количеством проблем, то лучше брать сертифицированную ОС. Если по тем или иным причинам нет возможности взять сертифицированную ОС, то уточняйте про то, как проводится тестирование совместимости и кто будет отвечать в случае поломки, а также будьте готовы работать на необновленной уязвимой ОС какое-то время, пока вендор СЗИ от НСД не пройдет сертификацию на обновление своего СЗИ, работающего с новой минорной версией ОС.
P.S. В вашем случае я бы все-таки рассмотрел вариант взять сертифицированную ОС и поставить туда МЭ, пусть и с дополнительным функционалом СКЗИ или СОВ. По крайней мере это средство не будет заменять компоненты ОС своими и у вас не образуется зависимая связка этих продуктов.
P.P.S. Посмотрите еще Secret Net Studio 8, в его состав входит МЭ типа В, и вроде как его можно приобрести отдельно как модуль. Если это так, то можно купить сертифицированную ОС + Модуль персонального межсетевого экрана Средства защиты информации Secret Net Studio 8, тогда проблем, думаю, будет меньше, чем применять целиком СЗИ от НСД + несертифицированную ОС.
Einherjar
А куда столько? Not invented here?
Maksim_Fokin Автор
Да уж, согласен. Каждый вендор смотрит на конкурентов, видит в их продуктах какие-то недостатки и пытается сделать свой, в котором эти недостатки устраняет (при этом создавая другие). С одной стороны - это грустно, с другой стороны - это естественный этап отбора. В результате победит сильнейший, а слабые со временем уйдут в небытие...К тому времени на рынке образуется несколько крупных вендоров, которые в конкурентной гонке будут вынуждены делать более качественные продукты, что для простых пользователей несомненно будет плюсом. Конкуренция - двигатель прогресса:)
cat-chi
Вы уверены, что именно так всё происходит? :)
Нет, случаи, когда компания делает что-то с целью "сделать продукт X, лишённый недостатков продукта Y", безусловно нередки.
Однако подозреваю, что с ОСями даже близко не тот случай. Есть действительно пара исключений (Астра, которая изначально делалась ради реализации их мандатной модели, и вероятно тысячелетний Альт).
Но насчёт остальных есть куда более простое объяснение.
Maksim_Fokin Автор
Соглашусь с вами. Речь идет, конечно, не обо всех вендорах на рынке. Бывают разные вендоры, у каждого свои цели - кто-то хочет заработать, кто-то хочет сделать мир лучше и т.п. Можно сказать, что я идеализирую, чтобы никого не обидеть своими комментариями:)
MountainGoat
Ой какие сказки венского леса.
Каждый вендор смотрит на конкурентов, потом на законы, и понимает, что взять ванильный Дебиан ему не позволят, а если заключить контракт с имеющимся вендором, то тот ими сможет крутить как ребёнок куклой. Поэтому никакой альтернативы, кроме как делать "свою" систему у них нет, а так как сделана она через нехочу, то и качество там отсутствует как концепция.
А никакой конкуренции между ними нет, кроме ценовой-договорной. Потому что те, кто принимают решение о закупке системы и те, кто реально будут её эксплуатировать - это совершенно разные люди между которыми нет никакого диалога и связи. Поэтому качество на такую конкуренцию не влияет никак, пока всё хоть как-то работает.
Коммерческих же структур, которые вынуждены считать свою производительность и убытки, во-первых будет всё меньше. Во-вторых, они не будут покупать "российские системы" пока их не заставят, а будут использовать Линукс. А когда заставят, купят самую дешёвую, поставят в угол сервера и будут и дальше использовать Линукс.
Так что эти "операционные системы" и дальше будут плодиться, пока их указом министерства не закроют и не прикажут всем перейти на одну-две.
Maksim_Fokin Автор
То, о чем вы говорите, тоже имеет место быть. Я с этим не спорю. Однако, хотелось бы дать пару своих комментариев. Вы говорите о коммерческом рынке, к большей части которого регулятор не предъявляет никаких требований. В связи с этим они, конечно, могут и свой Линукс сделать и много чего еще. При этом довольно большую часть рынка занимают компании, которые вынуждены приобретать сертифицированные ОС, чтобы выполнить требования регулятора. В таком случае тоже можно пойти по пути "сделать свою ОС, получить на нее сертификат ФСТЭК и внедрить". Однако, чтобы получить сертификат нужно соответствовать тем требованиям, которые я привел в статье. Это значит, что нужно нанять штат людей (кроме разработчиков, QA и т.п.), которые будут заниматься выстраиванием внутренних процессов по разработке безопасного ПО (далее по тексту - РБПО), проводить различные виды тестирований с целью улучшения безопасности ОС (стат. и дин. анализ, фаззинг, пентесты, антивирусные проверки, поиск и устранение известных уязвимостей компонент ОС и т.п.), разрабатывать необходимую документацию (по сертификации порядка 15 документов и по РБПО еще столько же), выполнять SLA регулятора на устранение уязвимостей, на обеспечение поддержки и еще много чего. Реализация всех этих процессов обойдется в "копеечку", плюс еще дальше придется все это сертифицировать - это стоит еще одну "копеечку" и потраченного времени - минимум полгода будут идти испытания. Такие процессы мало кто сможет себе позволить, а те кто может, тот и является сегодня вендором ОС.
Относительно этого высказывания:
Такое можно представить, и я даже знаю несколько компаний, которые пытались так сделать. Существует только одна проблема - если это компания подпадает под требования регулятора, то к ней приходят люди и аттестуют системы, и такие вот "фокусы" вскрываются очень быстро и очень быстро приводятся в порядок. Поэтому, если правильно "заставить", то все будет работать и на полочках лежать не будет. Но это если заставлять будет регулятор. А если "заставляет" руководство коммерческой компании, то тут уже все будет зависеть от зрелости процессов этой компании. Знаю несколько коммерческих компаний, которые сделали ровно так как вы и написали, т.к. внутри контроль отсутствовал от слова "совсем", а внешнего контроля не было. В итоге лежали на полочке купленные средства, а ДИТ продолжал работать по своим правилам на том, на чем хотел.
Но в целом, все о чем вы говорите имеет место быть. И то, о чем я писал в комментарии выше, этому никак не противоречит. В итоге все равно придет к тому, что останутся только самые стойкие и им уже придется бороться за своего клиента.
MountainGoat
При госзакупках практика заключается в том, что финальный поставщик, передающий продукт потребителю, несёт ответственность за все косяки в системе, а уже потом, если останется жив, может спрашивать со своих поставщиков. В суде, если хочет.
Поэтому, если вас угораздило поставить для государства программно-аппаратный комплекс, то есть компы с операционкой, то у вас есть всего два варианта:
Взять Дебиан или Редхат, переклеить на нём логотипы на название своей фирмы, зарегистрировать это как отечественную операционную систему. Впредь нести ответственность, вплоть до уголовной, за любые косяки в ней, если те кому-то сильно навредят. Всю прибыль класть в карман.
Взять Астра Линукс. Без права переклеить в нём логотип на название своей фирмы. Впредь нести ответственность, вплоть до уголовной, за любые косяки в нём, если те кому-то сильно навредят. Прибылью делиться с производителем Астра Линукс.
Вот вам что больше нравится?
Einherjar
Ну если государство за любые косяки без разбирательств грозит уголовной ответственностью, то мне нравится третий вариант: не поставлять программно-аппаратные комплексы вообще - пусть карандашом в столбик считают
cat-chi
Не связываться с B2G вообще ни в каком виде и нигде
MountainGoat
Ну во-первых, G уже год с лишним выпустило закон, позволяющий приказать любому B с ним связаться, причём до выполнения контракта B не имеет права закрыться, а его сотрудники - уволиться. А во-вторых, что вы тогда делаете в этой теме про отечественные ОС? Они больше никому, кроме около-госов, нафиг не сдались.
cat-chi
Хорошо, что не обязательно работать в юрисдикции именно этого G. Но с другими G тоже желания связываться нет.
Пишу комментарии