ZeroNet Blogs

Static ZeroNet blogs mirror

Linux.RU

Новости российского линуксостроения

Если одним из главных объектов инфраструктуры открытых ключей (ИОК) являются сертификаты X509, то центральным субъектом ИОК являются Удостоверяющие Центры (УЦ). Именно УЦ выпускают сертификаты, прекращают их действие (отзыв сертификата), подтверждают их валидность. На страницах Хабрахабр можно найти различные публикации на тему выпуска цифровых сертификатов с использованием OpenSSL. В основном в этих статьях рассматривается применение утилиты openssl, описывается ее интерфейс командной строки и работа с файлами, в которых хранится все: ключи, запросы, сертификаты, в том числе и корневой и т.д. Но если разрабатывать полномасштабный удостоверяющий центр (УЦ) на базе OpenSSL, то естественным является желание избавится от этого многообразия файлов и перейти к работе с базами данных, а также иметь графический интерфейс для выпуска сертификатов и управления ими. А если вспомнить Федеральный Закон от 6 апреля 2011г. №63-ФЗ «Об электронной подписи», то необходимо, чтобы УЦ соответствовал требованиям этого закона, а также «Требованиям к форме квалифицированного сертификата ключа проверки электронной подписи», утвержденных приказом ФСБ России от 27.12.2011 № 795.

У простых граждан создается впечатление, что УЦ это что-то громадное (как же, Центр, почти как Центр Управления Полетами).

С точки зрения ответственности УЦ – это именно так. Ведь сертификаты, выпускаемые УЦ, фактически сегодня приравнены в паспорту.

С программистской точки зрения, все не так страшно. Так родился проект удостоверяющего центра CAFL63. Реализация проекта CAFL63 базируется на трех «китах», а именно OpenSSL, SQLite3 и Tcl/Tk.

Итак, что же такое Удостоверяющий Центр сегодня? Прежде всего это Центр Регистрации, куда с пакетом необходимых документов, частности, удостоверяющих личность и полномочия заявителя, приходят за сертификатами представители юридический лиц, физические лица, индивидуальные предпринимателей. Они могут приходить с готовыми заявками в электронном виде. В ЦР проверяют документы, запрос (заполненные данные, корректность электронной подписи и т.д), и, если все прошло успешно принимают запрос, утверждают его и передают в Центр Сертификации (ЦС). Но это в идеале. На практике, все выглядит по-другому.

Гражданам, организациям нужен сертификат (для доступа на портал Госуслуг, для сдачи налогой отчетности, для участия в торгах), но они не знают что это такое и что с ним делать. Они искренне убеждены, что в УЦ получают электронную подпись типа факсимиле. Но это проблемы просвещения. Поэтому заявители приходят в ЦР УЦ, предъявляют документы. Вместе с сотрудником ЦР идут на отдельное рабочее место и готовят запрос на сертификат.

Подготовленный запрос на электронном носителе, о чем уже говорилось, поступает в ЦР. Что нужно помнить заявителю? Первое и главное забрать носитель с созданным закрытым ключом! Утвержденный запрос на электронном носителе передается в ЦС, где на его основе и будет выпущен сертификат.

Это принципиальная схема работы УЦ. Детали станут понятны ниже. Одно замечание, в целях удобства демонстрации утилита подготовки запроса, ЦР и ЦС объединены в один демонстрационный комплекс. Но никаких проблем с разнесением функционала нет. Самый простой из них, это на каждом рабочем месте иметь по экземпляру CAFL63 и задействовать только требуемый функционал.

Когда реализация проекта шла полным ходом, на глаза попался проект SimpleCA. Изучение этого проекта очень помогло при окончательной реализации УЦ CAFL63.

В состав дистрибутива для платформ Win32/Win64, Linux_x86/Linux_x86_64 помимо исходного кода CAFL63 входит и файл README.txt. После скачивания дистрибутива следует внимательно прочитать файл README.txt.

Итак, запускаем утилиту CAFL63 и на экране появляется стартовая страница:

Работу мы начинаем с нажатия клавиши «Создать БД». База данных УЦ создается средствами кроссплатформенной СУБД SQLite3. БД УЦ содержит несколько таблиц. Главная таблица mainDB содержит всего одну запись, в которой хранится корневой сертификат, закрытый ключ, зашифрованный на пароле, и настройки УЦ. Есть две таблицы, связанные с запросами на сертификаты: текущие запросы reqDB и архив запросов reqDBArc. Для сертификатов создается три таблицы: таблица новых сертификатов certDBNew, таблица архива сертификатов certDB и таблица отозванных сертификатов certDBRev:

. . . 
certdb eval {create table certDB(  ckaID text primary key ,  
               nick text,  sernum text,  certPEM text, subject text, 
                notAfter text,  notBefore text, dateRevoke text,  state text )}
certdb eval {create table certDBRev( ckaID text primary key )}
certdb eval {create table certDBNew( ckaID text primary key )}
certdb eval {create table reqDB (ckaID text primary key, nick  text,  
                    sernum text, subject text, type text, datereq text, status text, reqpem text,
                    pkcs7 text)}
certdb eval {create table reqDBAr (ckaID text primary key, nick  text,  sernum text, 
             subject text, type text, datereq text, status text, reqpem text, pkcs7 text)}
certdb eval {create table crlDB(ID integer primary key autoincrement, signtype text, 
               issuer text, publishdate text, nextdate text, crlpem text)}
. . .

Все таблицы запросов и сертификатов в качестве ключа (primary key) используют значение хэш (sha1) от открытого ключа. Для удобства в дальнейшем значение хэш от значения открытого ключа будем называть CKAID (терминология PKCS#11). Это оказалось очень удобным, например, при поиске сертификата по запросу или наоборот. В БД есть еще одна таблица crlDB, в которой хранятся списки отозванных сертификатов.

Значение открытого ключа хранится как в запросе, так и в сертификате. Поэтому, прежде чем положить их в БД, необходимо извлечь из них открытый ключ и вычислить CKAID. Для извлечения значения открытого ключа удобно воспользоваться пакетом pki (package require pki), который содержит средства для работы с сертификатами и запросами. Однако этот пакет не рассчитан на работу с российской криптографией. В связи с этим на базе входящих в пакет pki процедур parse_cert и parse_csr написать процедуры parce_cert_gost и parse_csr_gost:

...
    ## Convert Pubkey type to string
    set pubkey_type [::pki::_oid_number_to_name $pubkey_type]
    # Parse public key, based on type
    switch -- $pubkey_type {
        "rsaEncryption" {
            set pubkey [binary format B* $pubkey]
            binary scan $pubkey H* ret(pubkey)
            ::asn::asnGetSequence pubkey pubkey_parts
                ::asn::asnGetBigInteger pubkey_parts ret(n)
                ::asn::asnGetBigInteger pubkey_parts ret(e)
            set ret(n) [::math::bignum::tostr $ret(n)]
            set ret(e) [::math::bignum::tostr $ret(e)]
            set ret(l) [expr {int([::pki::_bits $ret(n)] / 8.0000 + 0.5) * 8}]
            set ret(type) rsa
        }
        "1.2.643.2.2.19" -
        "1.2.643.7.1.1.1.1" -
        "1.2.643.7.1.1.1.2" {
#   gost2001, gost2012-256,gost2012-512
            set pubkey [binary format B* $pubkey]
            binary scan $pubkey H* ret(pubkey)
            set ret(type) $pubkey_type
            ::asn::asnGetSequence pubkey_algoid pubalgost
#OID - параметра
            ::asn::asnGetObjectIdentifier pubalgost oid1
#OID - Функция хэша
            ::asn::asnGetObjectIdentifier pubalgost oid2
        }
        default {
            error "Unknown algorithm"
        }
    }
...

В отличии от «родных» процедур, они позволяют работать с объектами не только в формате PEM, но и в формате DER. Для работы со списками отозванных сертификатов CRL была написана процедура parse_crl. Все эти процедуры можно найти в исходном коде, который хранится вместе с дистрибутивом.

Также в пакете pki отсутствуют и российские oid-ы, например, ИНН, СНИЛС и т.д. Эта проблема лекго решается путем добавления российских oid-ов в массив ::pki::oids:

. . . 
    set ::pki::oids(1.2.643.100.1)  "OGRN"
    set ::pki::oids(1.2.643.100.5)  "OGRNIP"
    set ::pki::oids(1.2.643.3.131.1.1) "INN"
    set ::pki::oids(1.2.643.100.3) "SNILS"
#Алгоритмы подписи
    set ::pki::oids(1.2.643.2.2.3) "ГОСТ Р 34.10-2001"
    set ::pki::oids(1.2.643.7.1.1.3.2) "ГОСТ Р 34.10-2012-256"
    set ::pki::oids(1.2.643.7.1.1.3.3) "ГОСТ Р 34.10-2012-512"
. . .

Имея функции parse_cert_gost и parse_csr_gost, значения CKAID (primary key для БД) вычисляется следующим образом:

. . .
    array    set b [parse_csr_gost $req]
    set pem $b(pem)
    set subject $b(subject)
    set pubkey $b(pubkey)
    set key1 [binary format H* $pubkey]
    set ckaID [::sha1::sha1 $key1]
. . . 

Итак, нажимаем кнопку «Создать БД»:

Создание УЦ начинается с выбора каталога, в котором будем хранить БД и задания пароля для доступа к закрытому ключу УЦ. Утилита CAFL63 внимательно следит за длиной пароля:

Пароль хранится в БД УЦ в виде хэша:

. . .
set hash256 [::sha2::sha256 $wizData(capassword)]
. . . 

После нажатия клавишы «Next» начинается процесс формирования самоподписанного корневого сертификата разворачиваемого УЦ. На первом шаге этого процесса выбирается тип и параметры ключевой пары:

Определившись с ключевой парой для корневого сертификата создаваемого удостоверяющего центра, мы приступаем к заполнению формы информацией о владельце (первый скриншот пропущен).

Отметим, что утилита CAFL63 обладает определенным «интеллектом» и поэтому контролирует не только наличие данных в полях, но и правильность (красная подсветка — неправильно) заполнения таких полей как ИНН, ОГРН, СНИЛС, ОГРНИП, адрес электронной почты и др.:

После заполнения полей информацией о владельце УЦ будет предложено определиться с системными настройками УЦ:

Если вы не собираетесь работать с российской криптографией, то можете использовать обычный OpenSSL. Для работы с российской криптографией, необходимо выбрать соответствующую версию, модификацию OpenSSL. Более подробно читайте README.txt в скаченном дистрибутиве. Поскольку предполагается выпуск квалифицированных сертификатов, то необходимо также дать информацию о сертификации самого УЦ и используемом им СКЗИ (см. «Требования к форме квалифицированного сертификата ключа проверки электронной подписи», утвержденные приказом ФСБ России от 27.12.2011 № 795).

После правильного заполнения всех полей, еще раз будет предложено проверить их достоверность и нажать кнопку «Finish»:

После нажатия кнопки «Finish» будет создана БД УЦ, в которой будут сохранены корневой сертифкат УЦ, закрытый ключ, системные настройки, и на экране вновь появится стартовая страница утилиты CAFL63. Теперь, когда у нас создана база данных вновь создаваемого УЦ, мы нажимаем кнопку «Открыть БД», выбираем каталог с БД, попадаем в главное рабочее окно УЦ и нажав кнопку «Просмотр CA УЦ», убеждаемся, что тот корневой сертификат, который мы создали:

Следующим шагом мы подготавливаем шаблоны/профили заявок для юридический лиц, физических лиц, индивидуальных предпринимателей (Средства->Настройки->Типы Сертификатов->Новый ):

После задания имени нового профиля будет предложено определить его состав:

Состав профиля определяет distinguished name (отличительное/уникальное имя владельца сертификата). Каждого профиль имеет свой состав с обязательными (required) или нет полями/oid-ами. Состав профиля для юридических лиц, физических лиц, индивидуальных предпринимателей определяется требованиями ФЗ-63 и «Требованиями к форме квалифицированного сертификата ключа проверки электронной подписи» ФСБ России.

После подготовки профилей УЦ готов к приему заявителей и заявок от них. Как было отмечено выше, заявитель может приходить как с готовой заявкой на сертификат, так и без нее. Если заявитель пришел с готовой заявкой, то после проверки его документов, заявка импортируется в БД УЦ. Для этого необходимо на главном рабочем окне выбрать вкладку «Запросы на сертификаты», нажать кнопку «Импорт запроса/CSR» и выбрать файл с запросом. После этого появится окно с информацией о запросе:

Просмотрев запрос и убедившись в его правильном заполнении можно нажимать кнопку «Import» для занесения его в базу данных. Сразу отметим, что при попытке повторного внесения запроса в БД УЦ будет выдано сообщение:

Запросы в БД УЦ помечаются (колонка «Type») либо как «Locale», созданные в центре регистрации УЦ, либо как «Import», созданные самим заявителем, а также фиксируется время поступления заявки в УЦ. Это может оказаться полезным при разборе конфликтных ситуаций. Поэтому при импорте запроса на сертификат следует указывать кем был создан запрос (см. скриншот). Импортированная заявка находится в БД УЦ и отображается на главном окне на вкладке «Запросы на сертификаты». Поступившие запросы находятся в стадии «рассмотрения» (колонка «Status» вкладки «Запросы на сертификат» и «Архив Запросов» ). По каждому вновь поступившему запросу должно быть принято решение (выпадающее меню при нажатии правой клавиши мышки на выбранном запросе):

Каждый запрос должен быть или отклонен или утвержден:

Если запрос отклоняется, то он перемещается из таблицы текущих запросов reqDB в таблицу архива запросов reqDBArc и, соответсвенно, исчезает на вкладке «Запросы на сертификаты» и появляется на вкладке «Архив Запросов».

Утвержденная заявка остается в таблице reqDB и на вкладке «Запросы на сертификаты» до выпуска сертификата, а потом тоже попадает в архив.

Перед выпуском сертификата надо вместе с заявителем уточнить для каких целей (например, для доступа на портал Госуслуг ) будет использоваться сертификат (Средства->Настройки->Типы Сертификатов ->Физ.лицо ->Редактировать ->Key Usage):

Для выпуска сертификата надо выбрать утвержденную заявку на вкладке «Запросы на сертификаты», нажать правую клавишу мыши и в выпадающем меню при выбрать пункт «Выпустить сертификат». В появившемся виджете необходимо будет выбрать профиль, которому должен соответствовть профиль запроса/сертификата:

Отметим, что в процессе выпуска сертифиата можно уточнить значения того или иного поля:

Сама процедура выпуска сертификата (пункт меню «Выпустить сертификат») мало отличается от процедуры создания корневого сертификата или выпуска заявки:

Выпущенный сертификат сразу же появлется на вкладке «Сертификаты». При этом сам сертификат попадает в таблицу certDBNew БД УЦ и остается там до тех пор, пока он не будет опубликован. Сертификат считается опубликованным после его экспорта в SQL-дамп новых сертификатов, который передается на публичный сервис. Опубликование сертификата приводит к перемещению его из таблицы certDBNew в таблицу certDB.

Если нажать правую клавишу мыши на выбранной строке в закладке «Сертификаты», то появится меню с функциями:

Эти функции позволяют просмотреть как сам сертификат, так и запрос, на основании которого он был выпущен. Можно также экспортировать сертификат в файл или на флэшку заявителя. Важнейшей функцией здесь является функция отзыва сертификата! Есть и такая экзотическая функция как экспорт сертификата в защищенный контейнер PKCS#12. Он используется, когда заявитель хочет получить такой контейнер. Для таких заявителей специально предусмотрена функция генерации запроса с сохранением закрытого ключа в файле (кнопка «Создать запрос/CSR» на вкладке «Запросы на сертификаты» ).

Итак, УЦ начал свою жизнь, выпустил первый сертификат. Одна из задач УЦ – это организация свободного доступа к выпускаемым сертификатам. Публикация сертификатов как правило идет через Web-сервисы. Есть такой сервис и у CAFL63:

Для публикации сертификатов и списков отозванных сертификатов на публичном сервисе УЦ предварительно выгружает сертификаты или в файлы (Сертификаты->Экспорт сертификатов), либо делает SQL –дамп всей таблицы сертификатов, из которой можно создать БД сертификатов и загрузить в нее их, а в последующем делать SQL-дамп новых сертификатов, из которого они будут добавляться в БД публичного сервиса:

Последний скриншот сделан на платформе Windows и наглядно демонстрирует кросплатформенность БД УЦ: она была просто скопирована с платформы Linux. Основополагающая функция УЦ – это публикация списка отозванных сертификатов по аналогии с тем, как это делает МВД относительно утративших силу паспортов. Сертификат может быть отозван по заявлению владельца. Основной причиной отзыва является утрата закрытого ключа или потеря доверия к нему.

Для отзыва сертификата достаточно выбрать его на вкладке «Сертификаты», нажать правую кнопку мыши и выбрать пункт меню «Отзыв сертификата»:

Процедура отзыва не отличается от процедуры утверждения запроса или выпуска сертификата. Отозванный сертификат попадает в таблицу cerDBRev базы данных УЦ и появляется во вкладке «Отозванные сертификаты».

Осталось рассмотреть последнюю функцию УЦ – выпуск CRL — списка отозванных сертификатов. Список CRL формируется на вкладке «Отозванные сертификаты» при нажатии кнопки «Создать СОС/CRL». Все, что требуется от администратора, это ввести пароль УЦ и подтвердить свое намерение выпустить CRL:

Выпущенный CRL попадает в таблицу crlDB базы данных и отображается на вкладке «CRL/СОС».

Для разбора CRL перед его помещением в БД была написана процедура parse_crl:

proc parse_crl {crl} {
    array set ret [list]
    if { [string range $crl 0 9 ] == "-----BEGIN" } {
    array set parsed_crl [::pki::_parse_pem $crl "-----BEGIN X509 CRL-----" "-----END X509 CRL-----"]
    set crl $parsed_crl(data)
    }
    ::asn::asnGetSequence crl crl_seq
    ::asn::asnGetSequence crl_seq crl_base
        ::asn::asnGetSequence crl_base crl_full
        ::asn::asnGetObjectIdentifier crl_full ret(signtype) 
#puts "KEY_TYPE=$ret(signtype)"     
        ::::asn::asnGetSequence crl_base crl_issue
        set ret(issue) [::pki::x509::_dn_to_string $crl_issue]
#puts "ISSUE=$ret(issue)"    
        ::asn::asnGetUTCTime crl_base ret(publishDate)
        ::asn::asnGetUTCTime crl_base ret(nextDate)
#puts "publishDate=$ret(publishDate)"    
    return [array get ret]
}

Для просмотра CRL или его экспорта с целью публикации на публичном сервисе необходимо как всегда выбрать нужную строку, нажать правую кнопку мыши и выбрать пункт меню:

Вот и все, Удостоверяющий Центр готов.

О том как собрать и подключить OpenSSL с российской криптографией можно узнать здесь.

Приложение Удостоверяющий Центр (УЦ) ФЗ-63 Вы можете скачать следующие дистрибутивы:

для Windows (32bit); для Windows (64bit); для Linux (32bit); для Linux (64bit).

habr

Компания Аванпост – российский разработчик систем идентификации и управления доступом к информационным ресурсам предприятия (IDM) – объявила в среду о выпуске нового релиза своего продукта – Avanpost IDM 6.0.

В новой версии ПО, в частности, произошли такие изменения:

  • Продукт теперь полностью совместим с ОС семейства Linux, поддерживает СУБД Postgres при установке на любую ОС. Согласно сообщению компании, при использовании всех поддерживаемых СУБД Avanpost IDM 6.0 при работе в Linux и Windows обеспечивает одинаковую функциональность, реализующую полный набор функций современной IDM-системы. Кроме того, Avanpost IDM 6.0 сохранил совместимость со всеми многочисленными платформонезависимыми и платформозависимыми модулями сопряжения (коннекторами), которые интегрируют Avanpost IDM с всевозможным прикладным и инфраструктурным ПО. Таким образом в новой версии продукта обеспечена защита инвестиций Аванпост, заказчиков и партнеров в создание и развитие базы коннекторов — наиболее полной среди всех IDM-решений, представленных на российском рынке.
  • Существенно изменена архитектура ядра IDM, что подготовило Avanpost IDM к постепенному добавлению недостающих функций решений класса IGA (Identity Governance and Administration). Эти функции будут появляться в минорных версиях (6.1, 6.2 и т. д.) продукта. В соответствии с пятилетней стратегией компании Аванпост, объявленной в феврале 2018 года, именно движение в сторону IGA является основной линией развития Avanpost IDM как для российского, так и для зарубежных рынков. «Начинается большое изменение ландшафта и архитектуры, связанное с цифровой трансформацией предприятий под влиянием бизнес-необходимости», — сказано в сообщении компании.

«Отсутствие энтузиазма в отношении импортозамещения, цифровой трансформации предприятий и цифровизации российской экономики и госуправления, а также попытки замедлить процесс постепенно сменяются позитивным отношением к переменам, а затем и инициативой, идущей от самих организаций-заказчиков», — говорится в релизе.

Справка

Компания Аванпост —российский разработчик систем идентификации и управления доступом пользователей. Аванпост работает на рынке информационных технологий с 2007 года.

В линейке решений компании представлены следующие продукты:

• Avanpost IDM — система централизованного управления доступом к корпоративным ресурсам предприятия; • Avanpost PKI — централизованная система управления и учета элементов PKI-инфраструктуры (токены, сертификаты, лицензии СКЗИ); • Avanpost SSO — система управления аутентификацией пользователей в корпоративных ресурсах организации; • AvanpostWeb SSO — система управления аутентификацией пользователей в корпоративных ресурсах, SaaS-сервисах и облачных продуктах.

Решения компании Аванпост работают как самостоятельные продукты, а также интегрируются в единый программный комплекс, позволяя компаниям-заказчикам автоматизировать все процессы, связанные с контролем и управлением доступом.

Все решения разработаны с учетом требований законодательства РФ (№152ФЗ, СТО БР ИББС, нормативные документы ФСТЭК и ФСБ, PCI DSS), входят в Единый реестр российского ПО, а также сертифицированы в структурах ФСТЭК России.

На текущий момент на счету компании «Аванпост» свыше 60 успешных внедрений, продукты линейки Avanpost используют более 2 миллионов человек. Среди клиентов Аванпост — Федеральная таможенная служба РФ, Федеральная налоговая служба РФ, Департамент информационных технологий г. Москвы, Роснано, МТС Банк, РоссельхозБанк и др.

drussia

Планшеты на российской операционной системе Sailfish выйдут на рынок осенью, пишут «Ведомости» со ссылкой на владельца и генерального директора компании–разработчика мобильных устройств Inoi Сергея Богатова.

Речь идёт о планшете Inoi T8, который, по словам Богатова, в сентябре 2018 года начнёт продаваться в магазинах «Байон.ру». Стоимость оборудования и намеченный объём поставок не называются.

Известно лишь, что планшеты будут относиться к среднему ценовому сегменту, к которому, например, в «М.Видео», относят аппараты по цене от 10 до 25 тыс. рублей.

Помимо планшетов, компания Inoi предлагает смартфоны также на российской ОС Sailfish, которые уже доступны в продаже. Стоимость модели Inoi R7 составляет около 12 тыс. рублей. Ранее в СМИ прошла информация о намерениях Inoi продавать Android-смартфоны стоимостью от 3 до 8 тыс. рублей. В 2016 году компания «Открытая мобильная платформа» (ОМП) разработала на базе Sailfish российскую мобильную операционную систему — Sailfish Mobile OS, которая попала в реестр отечественного программного обеспечения. В марте 2018 года «Ростелеком» получил контроль над ОМП.

Inoi не единственный производитель смартфонов с ОС Sailfish. В октябре 2017 года о планах по выходу на российский рынок заявлял боливийский бренд Accione, созданный при участии консорциума Jolla. Отгрузки смартфонов для корпоративного сектора планировались в начале 2018 года.

3dnews

В конце мая Embox, уже традиционно, принял участие в OSDay. Конференция, как и в прошлом году, проходила в главном здании РАН. На этот раз она была посвящена надежности. Тема надежности ПО стара. Она затронута, например, Фредериком Бруксом в его легендарном произведении “Мифический человеко-месяц”, на которое несколько раз ссылались и на самой конференции. В книге упоминается, что одной из проблем, с которой столкнулись в процессе создания операционной системы OS/360, было отсутствие достаточного количества квалифицированных программистов. Наверное, по этой же причине много времени на конференции было уделено образованию в области системного программирования. В общем, кому интересно, какие, на мой взгляд, интересные идеи высказывались и обсуждались на конференции, прошу под кат.

Открывая конференцию, один из ее основателей Дмитрий Завалишин @dzavalishin, высказал несколько тезисов:

  • Современные программные системы настолько сложны, что надежность требуется для любой из них, а не только для “особенных”, как было раньше
  • Представления о надежности ПО у разных людей могут различаться, например, некоторые считают надежность синонимом безопасности
  • Методы обеспечения надежности могут быть разными, исходя хотя бы из того, что различаются представления о надежности

В первый день ИСП РАН представил доклад, посвященный надежности ПО с академической точки зрения. И хотя это было скорее данью истории, из него было понятно, что проблема далеко не нова, и определения надежности, как и методов ее оценки, очень разнообразны. Доклад хоть и был сильно порезанным (поскольку докладчик пыталась уложиться в 30 минут), был интересен своей научностью.

Инструментальные методы

Методы обеспечения надежности кода можно разделить на несколько категорий. Начну с инструментальных средств, коими славится хозяин конференции — ИСП РАН. Его сотрудником был представлен доклад об опыте верификации кусков ядра Линукса с помощью средства klever. Klever — открытый фреймворк для статической верификации кода. Собственно, проблему, которую решал автор доклада, можно сформулировать следующим образом. Статическая верификация кода слишком сложна, чтобы проверять современные проекты целиком, но можно попробовать выделить некую более-менее изолированную часть, например подсистему ядра Линукс или отдельный драйвер, и, задав ему соответствующее окружение, верифицировать. Далее можно попробовать итеративно проделать это со всем проектом.

Архитектурные методы

Еще одним подходом к построению более надежных систем является использование “архитектурных” приемов. К ним я бы отнес идею о персистентной памяти [ОС Фантом](https://ru.wikipedia.org/wiki/%D0%A4%D0%B0%D0%BD%D1%82%D0%BE%D0%BC_(%D0%BE%D0%BF%D0%B5%D1%80%D0%B0%D1%86%D0%B8%D0%BE%D0%BD%D0%BD%D0%B0%D1%8F_%D1%81%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B0) и архитектуру MILS (Multiple Independent Levels of Security/Safety).

Доклад про MILS касался его свойств по повышению безопасности критических систем и был представлен Лаборатории Касперского. Доклад про сборщик мусора в условиях персистентной памяти представлял не только автор ОС Фантом, но и студент университета “Иннополис”. Естественно, идея использовать manage-языки для увеличения надежности систем не нова. И в докладе, на мой взгляд, важным являлось именно вовлечение студентов в проект с открытым кодом по созданию системного ПО.

Методический подход

Самым многочисленным по количеству докладов, но недооцененным подходом к повышению надежности ПО, на мой взгляд, является “методический”. Если задуматься, то выделение операционной системы в отдельную сущность было нацелено на повышение надежности ПО. Программист получил возможность переиспользовать системные службы, а не разрабатывать их заново.

Доклад по методике разработки критически важного ПО был представлен ФГУП «ГосНИИАС”. Доклад был посвящен разработке по стандарту DO-178С (КТ-178С в русском варианте). Как и в самом стандарте, в докладе было много “занудства”, но ведь когда делаешь самолет, одними фееричными идеями не обойтись, нужно кучу раз проверить, прежде чем внести малейшее изменение. В общем, один раз отмерь, семь раз отрежь, ой, наоборот, конечно. Естественно, доклад был интересен не своим “занудством”, а тем, что, был разработан инструментарий для автоматизации данного процесса, т.е. для уменьшения “занудства”.

Open-Source

Наконец, перехожу к разделу, в котором выступал Embox. Наш доклад назывался “Организация поддержки 3d-ускорения в ОСРВ на основе проектов с открытым кодом”. В нем довольно большая часть была посвящена разъяснению, причем тут надежность. Даже был слайд вида “Надежность и аппаратное 3d-ускорение”. Надежность, конечно, не в 3d-ускорении, а во фразе “на основе проектов с открытым кодом”. Суть в том, что нам удалось добавить к себе поддержку закрытого 3d ускорителя vivante, используя открытые проекты. И хотя используемый нами проект Mesa сильно завязан на интерфейс ядра Линукс, адаптация требует куда меньше усилий и содержит куда меньше строк кода, чем разработка с нуля.

Как я уже отметил, open-source — самая многочисленная категория, с которой так или иначе были связаны доклады на конференции. Например, “Базальт СПО” представил доклад о разработке средства синхронизации файлов clsync. Не буду вдаваться в технические детали, важно другое. Как указано в названии компании, инструмент СПО-шный, и после доклада последовало несколько советов, например, использовать futex-ы, на что докладчик предложил присоединиться к проекту и улучшить его самостоятельно.

Самым интересным в плане opensource, на мой взгляд, был доклад сотрудника Positive Technologies Александра Попова.

Доклад назывался: “Как STACKLEAK улучшает безопасность ядра Linux” и казалось, что он должен был посвящен рассказу об STACKLEAK и с чем его едят. Но основное время доклада было уделено теме, которая выражается во фразе из аннотации к докладу: “Данную работу Александр ведет уже год. Он поделится своим опытом взаимодействия с сообществом разработки ядра Linux”. То есть, в течении года проталкиваются полезные изменения, вовлечено много людей, изменения рассматриваются под микроскопом квалифицированными специалистами работающими в разных подсистемах ядра. Конечно, это не гарантирует полное отсутствие ошибок, но уменьшает их число, а следовательно — повышает надежность кода.

Альтернативный подход

На конференции, как и в прошлом году был представлен доклад, посвященный QP ОС. В тезисах к докладу вы можете увидеть следующее: “Защищённая операционная система QP ОС является полностью отечественной разработкой, созданной «с нуля» коллективом научно-технического предприятия «Криптософт».” В докладе тоже был озвучен принцип разработки «с нуля», причем не только операционной системы, гипервизора, сетевого стека, но и всех подсистем и пользовательских приложений, а также компилятора, виртуальной машины C#, и, я так понимаю, всех остальных средств разработки. На мой вопрос к докладчику, а как же быть с надежностью, ведь коэффициент количества ошибок на тысячу строк кода, никто не отменял. Получил ответ, что под надежностью можно понимать разные вещи, и, что для данной операционной системы надежным считается, если между двумя перезапусками она падает все реже. Уже после доклада, в кулуарах, я посоветовал взять открытый проект для обеспечения более полной поддержки samba. Но получил ответ, что это принципиальная позиция, разрабатывать все самостоятельно, с пояснением, что такой подход имеет право на жизнь. Что ж, я назвал это альтернативным подходом.

Тут нужно отметить, что на конференции была выставка, и был представлен стенд, на котором QP ОС можно было попробовать вживую. Я поигрался с их редактором, он вполне работал. На стенде подтвердили, что не заимствовали даже код библиотек для работы с xml. Кроме того, возможно, подобный подход “все «с нуля»”, происходит из сферы применения, в которой работают разработчики. Сфера эта характерна своей чрезмерной безопасностью, лучше пусть упадет, чем где-нибудь будет закладка. Правда, это не оправдывает отказ от использования открытого кода.

Жесткое реальное время

В данном разделе я не могу не сослаться на еще один доклад, как минимум потому, что докладчик сослался на мое выступление, поэтому и я в праве сделать то же самое. После моего выступления мне был задан вопрос, не мешает ли обеспечению характеристиками реального времени поддержка 3d-ускорителя, ну и вообще, является ли наш проект ОС жесткого реального времени? На последний вопрос я ответил уклончиво, поскольку время на конференции ограничено, а вопрос, что понимать под реальным временем требует достаточно серьезного разъяснения. Упомянутый докладчик выступал сразу после меня с докладом о своей ОСРВ Eremex FX-RTOS и заявил, что в отличие от нашего проекта, их ОС является системой жесткого реального времени. Признаком жесткого реального времени, по мнению докладчика, является отсутствие циклов с переменным числом итераций при заблокированных прерываниях.

Не берусь судить о том, есть ли потенциально бесконечные циклы с заблокированными прерываниями в ОСРВ FX-RTOS или нет, поскольку код закрытый, но, конечно, соглашусь с тем, что такие циклы недопустимы даже в обычных ОС, не говоря уже об ОСРВ!

Кроме того, в ходе доклада было заявлено, что разработчикам удалось полностью избежать блокировку (маскирование) прерываний, правда только на arm cortex-m, но все равно это большое достижение, что по мнению докладчика также указывает на реальное время. В дополнение докладчик достаточно долго остановился на устройстве на базе FX-RTOS, которое отвечало по интерфейсу UART за несколько миллисекунд, что опять же указывает на жесткое реальное время.

Не знаю, у кого из нас альтернативный подход к понятию “реальное время”, просто выскажу свою точку зрения. И как раз отвечу на вопрос, является ли Embox системой реального времени.

Понятие реального времени напрямую связано с предсказуемостью поведения системы при воздействии любых (как внутренних, так и внешних) факторов. Из этого и следует связь понятия реального времени с понятием надежности. Отсюда и представление, о том, что windows, как универсальная ОС, ненадежна, а операционная система реального времени (как и система, построенная на ней) надежна.

Временны́е параметры реакции — один из важнейших факторов предсказуемости, но в системах реального времени важна не столько скорость реакции, сколько разброс времени реакции, и именно он должен быть жестко ограничен. Я встречал определение, где мягкое реальное время определялось как система с малым средним значением отклика системы, а жесткое — с малым максимальным. А поскольку скорость современных процессоров сильно выросла, то время (среднее) исполнения уже не играет той роли, ведь для увеличения скорости реакции достаточно поставить более мощный процессор. Но от влияния алгоритмов и архитектуры избавиться не удается, то есть Линукс с его честным планировщиком, нацеленым на максимальную загрузку процессора, не может считаться системой реального времени. Хотя уверен, что время реакции по UART-у можно сделать достаточно маленьким, но оно будет не стабильным, ведь планировщик может решить, что нужно загрузить процессор какой-то другой задачей, и время отклика непредсказуемо увеличится. Поэтому можно сформулировать следующую характеристику операционных систем реального времени: это операционные системы которые предоставляют лучший контроль для всех своих систем, внутренних в том числе. Взять, например, ARINC-653 с его требованием в части планировщика со статическим расписанием. В этих операционных системах разработчику доступны таблицы планирования, которые он заполняет на момент разработки системы. То есть, разработчик выделяет время (тайм слоты) в общем периоде планирования каждому разделу, все прерывания отключены (кроме таймера, естественно, доступного только планировщику), и разработчик должен сделать такое временно́е расписание, чтобы каждому разделу хватило времени на решение его задачи. При этом планировщик не имеет права как-то менять это расписание.

Если задуматься, какие еще операционные системы предоставляют полный или расширенный доступ к своим “потрохам”, легко прийти к выводу, что современные проекты маленьких ОС не зря имеют гордое имя RTOS (real-time operating system). Поскольку они предоставляют этот доступ, и разработчик уже отвечает за то, чтобы конечная система, построенная на базе RTOS, отвечала всем требованиям, в том числе и предсказуемостью реакции на любое воздействие!

Что касается Embox, то мы тоже предоставляем механизмы контроля всех служб, в том числе и ядра. И с этой точки зрения, Embox — операционная система реального времени. Да, на базе Embox делались системы с MILS-архитектурой (сознательно не называю это ARINC-653, поскольку ARINC-653 — определяется сертификатом на соответствие стандарту), но точно также можно построить и другую архитектуру, которая бы гарантировала достаточную предсказуемость реакции. Один заказчик, например, проверял время реакции на осциллографе, время было с точностью до нескольких тактов процессора и ограничивалось очень жестко. Правда, система была не нагружена, из активных приложений крутился только сервер, который и реагировал на событие. Но заказчик был очень доволен результатом. Поэтому мы считаем, что говорить о реальном времени, можно только в приложении к системе в целом, и за это отвечает разработчик, а операционная система жесткого реального времени, только предоставляет механизмы достижения этого самого реального времени. Мы более аккуратны в своей классификации и у нас написано »Embox — Essential toolbox for embedded development".

Кадры решают все

Странная фраза в названии “Чему нужно учить студентов, чтобы они сразу начинали работать в российских IT-компаниях и оставались там” — это на самом деле вопрос, прозвучавший на панельной дискуссии. Проблеме обучения и образования в сфере IT была посвящена четверть конференции. Понимая всю важность и вместе с тем противоречивость проблемы, организаторы очень интересно подошли к вопросу. Прозвучало четыре доклада, по задумке организаторов, докладчики представляли собой конкурентные подходы. Так, два доклада о курсе с одним и тем же названием «Архитектура ЭВМ и язык ассемблера» на факультете ВМК МГУ. Один доклад делал Георгий Курячий, другой — Вартан Падарян. Собственно, подходы были схожи, и не важно, что в одном курсе изучался ассемблер MIPS, а в другом x86. В обоих случаях преподаватели стремились развить курс в практической области. В продолжение темы про важность практической составляющей обучения был представлен доклад Алексея Хорошилова «Конструирование ядра операционной системы». Данный курс, можно сказать, расширяет представление об архитектуре ЭВМ и позволяет студентам глубже погрузиться в ядро операционной системы. В итоге, вместо конкурирующих подходов получилось, что на факультете ВМК присуствует системный подход, то есть курсы не конкурируют, а дополняют и развивают друг друга. Собственно, так и должно быть. Также прозвучала фраза: “Чтобы научиться программировать, нужно программировать”, — которая, на мой взгляд, определяет общий принцип обучения в IT.

Еще в данной секции выступал Роман Симаков из компании ”РЭД СОФТ” с докладом “Особенности подготовки системных программистов в малых городах”. Остальные докладчики в этой секции были из Москвы, как вы, наверное, догадались.

Доклад по перечисленным проблемам очень мне (и не только мне) напомнил [доклад](http://0x1.tv/%D0%9E%D1%88%D0%B8%D0%B1%D0%BA%D0%B8_%D0%B2_%D0%B3%D0%BE%D1%81%D1%83%D0%B4%D0%B0%D1%80%D1%81%D1%82%D0%B2%D0%B5%D0%BD%D0%BD%D0%BE%D0%BC_%D0%BD%D0%B0%D0%B4%D0%B7%D0%BE%D1%80%D0%B5_%D0%B7%D0%B0_%D0%B2%D1%8B%D1%81%D1%88%D0%B8%D0%BC_%D0%BE%D0%B1%D1%80%D0%B0%D0%B7%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5%D0%BC_%E2%80%94_%D0%B3%D0%BB%D0%B0%D0%B2%D0%BD%D0%B0%D1%8F_%D0%BF%D1%80%D0%BE%D0%B1%D0%BB%D0%B5%D0%BC%D0%B0_%D0%B2%D1%8B%D1%81%D1%88%D0%B5%D0%B3%D0%BE_%D0%BE%D0%B1%D1%80%D0%B0%D0%B7%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F_%D0%B2_%D0%A0%D0%BE%D1%81%D1%81%D0%B8%D0%B8_(%D0%A1%D0%B5%D1%80%D0%B3%D0%B5%D0%B9_%D0%90%D0%B1%D1%80%D0%B0%D0%BC%D0%BE%D0%B2,_OSEDUCONF-2018) “Ошибки в государственном надзоре за высшим образованием — главная проблема высшего образования в России” с конференции OSEDUCONF-2018 описанной мной на хабре.

Сравните: взято со страницы с тезисами текущего доклада |1) При распределении бюджетных средств на специальность в ВУЗе учитывать количество работающих по этой специальности выпускников. Если специалисты не востребованы, то нет смысла финансировать бюджетные места. Да. Выпускники работают, платят налоги, но зарабатывают чем-то другим! Работодатель мог бы при регистрации сотрудника указывать его специальность и ВУЗ и сейчас все это очень легко агрегировать. |2) Изменить коммерческую основу образования. Платить нужно не за подготовку, а за ее результат. IT-компании могли бы заказывать обучение специалистов и оплачивать согласно результатов. Грубо говоря специалисты предприятия присутствуют на экзаменах, оценивают для себя и «подписывают акт приемки» результатов подготовки. Взято из моего обзора доклада на Хабре |В данном докладе автор обозначил проблемы неэффективности нынешнего образования. Возможной причиной этого является забюрократизированность. Про проблему забюрократизированности сильно распространяться не буду, т.к. все, кто связан с образовательным процессом, так или иначе с ней сталкивались. Автор выразил мнение, что основной проблемой образования является то, что контролируется процесс, а не результат. То есть ВУЗу навязывают формальные требования к процессу, и именно они проверяются. Реальной же ценностью образования является востребованность его выпускников.

В обоих случаях основная мысль в том, что ВУЗ должен подготавливать успешных в своей отрасли специалистов, а не отчитываться по количеству мест. Когда автору доклада сказали, что эти идеи не новы, он обиделся, и сказал, что они оригинальные. В этом никто не сомневается, а вот тот факт, что оба доклада были представлены малыми городами (Муромом и Переславль-Залесским), наводит на мысли о том, что проблемы с распределением бюджетных денег на образование достаточно серьезны, и особенно проявляются в малых городах.

Что же касается вопроса из названия статьи, я предложил его автору не думать о том, чему же нужно учить программистов, а развивать саму IT-индустрию. Ясно, что если специалист не найдет применения своим знаниям и умениям, он уйдет туда, где они окажутся востребованы. Именно промышленность формирует требование к специалистам, а не ВУЗы и не государство. Меня поддержал докладчик из ИСП РАН, который сказал, что должно быть “триединство”: образование, наука, промышленность. Без любой из этих составляющих начинают проседать и другие части.

В дополнение сошлюсь на свою статью “Где взять программиста” в которой я постарался предложить свой подход к улучшению образования в IT.

Итоги

Подводя итоги, хочу отметить, что конференция интересна прежде всего своим разнообразием мнений и, конечно, качеством докладов. Я вообще не упомянул о целой секции по безопасности и многих других докладах, не со зла, просто рассказал, о том что было особенно интересно лично мне. А официальный отчет можно почитать тут.

Видео всех докладов с конференции, а не только упомянутых в статье можно посмотреть тут. Там еще много интересного.

habr

Министерство обороны Российской Федерации разработало план-график перехода на использование отечественного программного обеспечения, которое позволит существенно сократить риски в сфере информационной безопасности. Об этом сообщил глава ведомства Сергей Шойгу, выступая на выездном заседании коллегии Минобороны РФ в Севастополе.

«Для дальнейшего стабильного развития оборонной отрасли нами разработан проект плана перехода вооружения и военной техники на отечественное программное обеспечение. Это позволит выйти на качественно новый уровень информационной безопасности в Вооружённых силах», — заявил министр обороны РФ Сергей Шойгу. Он также добавил, что Министерством обороны намечены мероприятия по созданию экосистемы непрерывного совершенствования используемого ведомством и его структурами ПО. «Это ускорит его производство в три раза и в два раза уменьшит себестоимость», — заверил генерал армии.

Фото пресс-службы Минобороны России

По мнению главы Министерства обороны Российской Федерации, значимую роль в развитии информационных и телекоммуникационных технологий Вооружённых сил сыграет военный инновационный технополис «Эра» в Анапе, открытие которого состоится в сентябре 2018 года. «В технополисе планируется проводить комплексные прикладные и поисковые исследования, а также перспективные разработки по восьми приоритетным направлениям — искусственному интеллекту, IT-системам, робототехнике и другим. Эти работы будут выполнять в том числе и четыре сводные научные роты», — приводит слова министра пресс-служба ведомства.

«Сегодня победа куётся не только на поле боя, но и в научных лабораториях», — сказал Сергей Шойгу. Он пояснил, что формирование инновационной инфраструктуры позволит обеспечить развитие и внедрение отечественных аппаратно-программных платформ.

Напомним, что согласно подписанному 7 мая президентом РФ Владимиром Путиным указу «О национальных целях и стратегических задачах развития Российской Федерации на период до 2024 года» все государственные ведомства и организации обязаны к упомянутому сроку перевести свои IT-системы на отечественный софт. Ранее о планах по отказу от иностранного софта в пользу отечественных разработок заявили Управление делами президента РФ, Министерство транспорта РФ, МВД России, «Российские железные дороги» (РЖД), «Ростех», а также другие ведомства и организации.

https://servernews.ru/971575/

По словам Дмитрия Завалишина, одной из главных проблем надежности ОС является высокая сложность программных платформ

Традиционная конференция разработчиков отечественных операционных платформ в этому году в основном была посвящена вопросам надежности ОС.

В Москве в главном здании Российской академии наук состоялась пятая научно-практическая конференция разработчиков российских операционных платформ OS DAY 2018, на которой теоретики и практики системного программирования и разработки ОС обсуждали вопросы надежности операционных систем.

Дмитрий Завалишин, генеральный директор компании DZ Systems, отметил два применяемых сегодня подхода к обеспечению надежности – использование традиционных методов разработки в совокупности с инструментами, позволяющими осуществлять верификацию решений и находить в них проблемные места, и поиск новых парадигм, предоставляющих возможность создания более надежных решений.

Одной из главных проблем надежности ОС является высокая сложность программных платформ. Как поясняют эксперты, современные операционные системы содержат множество связанных процедур, которые образуют единую бинарную программу, выполняемую в ядре. Каждая из многочисленных строк кода ядра имеет доступ к записи информации в ключевые структуры данных, используемые несвязанными с ней компонентами, что может привести к необратимым последствиям.

Чтобы преодолеть эту проблему, считает Завалишин, нужно научиться строить так называемые мягко связанные системы, разбивая крупные программные комплексы на части, надежность которых прорабатывается независимо, а взаимное влияние ограничено.

Тема надежности, которая формировала основную повестку дня конференции OS DAY 2018, сопровождалась широким спектром вопросов, касающихся разработки ОС во всех их проявлениях, включая и определение основных возможностей в области их создания, и обмен опытом, и выделение перспективных технологий.

Участники OS DAY 2018 представили доклады о технологиях надежности и отказоустойчивости операционных платформ, методах их проектирования и разработки, об инструментальных средствах обеспечения надежности программно-аппаратных систем как на этапе разработки, так и в ходе их эксплуатации.

Наряду с этим обсуждались вопросы разработки драйверов, инструменты обеспечения надежности в жизненном цикле программных систем, методики обнаружения дефектов, анализа исходного и бинарного кода. Рассматривались новые подходы к созданию и организации операционных платформ и компонентов операционных систем, а также подходы к разработке ОС общего назначения, встраиваемых операционных систем реального времени и операционных платформ для Интернета вещей.

Как и на предыдущей конференции (см. «Увидеть себя», Computerworld Россия, 15 июня 2017), значительное внимание уделялось организационным вопросам разработки. Один из примеров — применение управления конфигурациями в процессе создания программных продуктов для обеспечения их надежности, сертифицируемости и упрощения вывода на новые рынки.

Александр Федичкин, руководитель центра системной интеграции группы компаний «Свемел», обратил внимание на новое свойство ошибок в программных платформах, которые выходят за пределы «простого неудобства», а их появление приводит к возникновению уязвимостей и создает угрозы информационной безопасности. Отдельная сессия докладов была посвящена решению и предотвращению подобных проблем.

Завершающим аккордом конференции стала панельная дискуссия «Обучение системных программистов», призванная способствовать решению проблемы дефицита высококвалифицированных ИТ-специалистов, которая существует не только в нашей стране, но и во всем мире.

По мнению Арутюна Аветисяна, директора Института системного программирования РАН, в нашей стране необходимо развивать свои модели образования и институты, которые на долгосрочной основе способны воспитывать собственные кадры, а подготовкой молодых специалистов для ИТ-инженерии должны заниматься наставники-практики.

Конференция была проведена консорциумом ведущих российских ИТ-компаний и организаций, в который входят ИСП РАН, DZ Systems, «Лаборатория Касперского», «Базальт СПО», Государственный научно-исследовательский институт авиационных систем, «Свемел», «НПО РусБИТех», «Ред Софт», ассоциация разработчиков компьютерных технологий «Доверенная платформа».

Российские операционные системы в МВД

Доля отечественных операционных систем в центральном аппарате МВД должна достичь в 2018 году 50%, в территориальных подразделениях — 40%, в подведомственных организациях — не менее 30%, а в 2020 году составить 80% во всех подразделениях. Это следует из разработанного в МВД плана-графика, который создан в соответствии с распоряжением Правительства РФ о переходе госорганов на отечественное программное обеспечение в 2016-2018 годах.

Предусмотрены переход на такие российские программные продукты, как антивирусы, почтовые системы, браузеры, текстовые и табличные редакторы и ряд других программных систем, а также подготовка сотрудников к работе с российским ПО.

Согласно опубликованным данным, планы миграции на отечественное ПО разработаны и в других ведомствах, включая Минобороны, Минздрав, Минкультуры, Минэнерго, Минпромторг и ряд других госструктур.

computerworld

НИИ «Масштаб» выпустил версию своей IP-АТС «Александрит», в которой вместо стандартных процессоров Intel использованы отечественные «Эльбрусы» — военным потребовался более полный уровень импортозамещения.

От Intel к «Эльбрусам» Входящий в «Ростех» санкт-петербургский НИИ «Масштаб» выпустил вариант своей цифровой автоматической телефонной станции (АТС) «Александрит» на российских четырехъядерных процессорах «Эльбрус 4С». В организации рассказали CNews, что в стандартной комплектации данная АТС оснащается чипами Intel, и ее адаптация под российское «железо» была осуществлена по просьбе военных, для которых актуальным является полное импортозамещение в используемом ими оборудовании.

«Александрит» был представлен в 2014 г., а о теоретической возможности задействовать в нем отечественные микропроцессоры (в том числе «Байкалы») разработчики, в частности, заверяли в марте 2015 г. Законченная версия на «Эльбрусах» была показана в начале июня 2018 г. на конференции «Цифровая индустрия промышленной России» (ЦИПР) в татарстанском Иннополисе.

«Александрит» представляет собой аппаратно-программное решение в виде сервера (в новой версии — «Эльбрус 4.4») с IP-АТС, хотя софт может продаваться и отдельно. Станция управляется через веб-интерфейс и поддерживает все основные функции: переадресацию, запись разговора и т. д. Для переговоров могут использоваться не только IP-телефоны, но и обычные аппараты.

Базовая версия «Александрита» на Intel

Несмотря на специфичность вышеупомянутого «заказчика», потенциальными потребителями разработчики считают не только госсектор. Модификацию на российских чипах в сравнении с базовой в «Масштабе» называют более простой. Ее цену не сообщают, однако, по данным CNews, на рынке она будет восприниматься как высокая.

Возможности «Александрита»

В базовой версии «Александрита» на процессорах Intel помимо передачи голосового трафика и данных по протоколам IP-телефонии реализовано свыше 30 различных сервисов для индивидуальной настройки под конкретные задачи организации-пользователя.

Среди ее опций и возможностей — система прямого доступа к ресурсам IP-АТС (DISA), автосекретарь (IVR), конференцсвязь трех типов, передача факса с возможностью отправки на e-mail, перехват вызова, автоматический выбор канала связи, модификация номера, выбор одного из 16 уровней классов обслуживания абонентов, музыка на удержании и фоновая музыка, обратный вызов, объединение нескольких IP-АТС в сеть, импорт и экспорт настроек, эхоподавление, повторный набор до 10 последних номеров, удаленное абонентское управление, ограничение и блокировка вызовов, интеллектуальная маршрутизация, поддержка видео, персональная и глобальная телефонная книга, запрет определения номера.

Из документации к АТС можно заключить, что базовой операционной системой для нее выступает отечественный Astra Linux Special Edition — защищенная ОС специального назначения для работы с информацией ограниченного доступа.

«Эльбрусы» для телефонии

Представленная АТС является не первым отечественным решением этого класса на «Эльбрусах». В частности, в конце июля 2017 г. стало известно о том, что на эти чипы свой программно-аппаратный комплекс для IP-телефонии портировал новосибирский производитель ИКТ-оборудования «Элтекс», входящий в число доверенных поставщиков «Ростелекома».

По итогам первых испытаний данного решения его разработчики заявили о производительности системы Softswitch ECSS-10 на уровне не менее 25 вызовов в секунду при емкости свыше 25 тыс. абонентов. Также система продемонстрировала способность поддерживать видеовызовы и транскодировать медиапотоки, доказала возможности масштабирования решения, резервирования в режиме active-active и построения систем с поддержкой географического резервирования.

«Дочка» «Ростеха» создала телекоммуникационный сервер российского производства TSP. Его особенностью является возможность работы с различными процессорными архитектурами: x86 (Intel), «Эльбрус» и «Байкал».

Телекоммуникационный сервер с поддержкой трех процессорных архитектур

Входящее в госкорпорацию «Ростех» НИИ «Масштаб» представило линейку универсальных телекоммуникационных серверных платформ TSP (Telecommunication Server Platform). Презентация состоялась в рамках прошедшей в Иннополисе (республика Татарстан) конференции «Цифровая индустрия промышленной России» (ЦИПР-2018).

Главной особенностью продукта является возможность работы с тремя различными процессорными архитектурами: x86 (Intel), «Эльбрус» и «Байкал». Поддерживаются процессоры Intel Core линеек i3, i5 и i7, Intel Xeon серии E3, «Эльбрус-4С» и «Байкал-Т1».

Процессоры Intel и «Эльбрус» должны устанавливаться в сервер в специальном ComExpress-модуле, который также содержит материнскую плату и оперативную память. Процессоры «Байкал» устанавливаются в другом формате – Smart-модуле, для которого потребуется переходник на ComExpress. Встроенный в TSP контролер автоматически определяется тип используемого процессора.

Cерверная платформа TSP, поддерживающая процессоры Intel Core, Intel Xeon, «Эльбрус-4С» и «Байкал-Т1»

Таким образом, владелец сервера может легко сменить тип используемого процессора без замены остального оборудования. Как объясняют разработчики TSP, такой подход может пригодиться госзаказчикам на случай, если в какой-то момент от них потребуют осуществить полное импортозамещение используемого оборудования.

Установка дополнительного одноплатного компьютера

TSP может управляться локально с консоли по стыку RS-232 либо удаленно по интеллектуальному интерфейсу управления (IPMI) через выделенный порт Ethernet. Сервер оборудован портом Gigabit Ethernet. Также поддерживается установка NIC-модулей со скоростям до 10 Гбит/с.

Процессор «Эльбрус» в ComExpress-модуле

В TSP могут быть установлены до двух накопителей HDD/SSD 2.5 SATA. При этом поддерживается работа RAID-массива при помощи программного или аппаратного контроллера.

Дополнительно в сервер может устанавливаться одноплатный компьютер, выполняющий функции криптошлюза, межсетевого экрана и т.д. Также сервер содержит сторожевой таймер для реализации схемы контроля над зависанием операционной системы.

Процессор «Байкал» в Smart-модуле

TSP может работать при повышенной влажности воздуха: 80% при температуре 25 градусов Цельсия и 100% при температуре 35 градусов Цельсия. Устройство прошло испытания по ГОСТ 1.1 и 1.3.

Сферы применения отечественного телекоммуникационного сервера

В сфере телекоммуникаций TSP могут выполнять функции межсетевых экранов, IP-АТС, маршрутизаторов, шлюзов доступ, мультисервисных узлов связи, криптошлюзов и др. В сфере ИТ TSP способен работать почтовым сервером, телематическим сервером и т.д. Цена устройств не разглашается.

Поскольку TSP производится в России с использованием российских схемотехнических решений, интеграция сервера в конечный продукт позволит обеспечить продукту статус оборудования российского происхождения.

cnews

New blog post

- Posted in Linux.RU by with comments

Blog post body

В Ассоциации разработчиков программных продуктов «Отечественный софт» создан комитет по интеграции отечественного программного обеспечения, в состав которого вошли представители 18 компаний, сообщили D-Russia.ru в ассоциации.

В комитет вошли представители компаний (в алфавитном порядке) ABBYY, «Базальт СПО», БФТ, «Видеомост», «Галактика», «Гарда Технологии», Docsvision, «Код безопасности», «Новые облачные технологии», «Одант», Postgres Professional, «Росплатформа», «Ред Софт», СВС, «Свемел», SDI Solutions, «Форсайт», «Электронные офисные системы».

«Многие производители программных продуктов действуют разрозненно, и возрастающий спрос сталкивается с проблемой совместимости и интеграции программного обеспечения. Задача АРПП — связать производителей и потребителей ПО, мы должны взять на себя функцию сбора и анализа возникающих проблем и предложить мероприятия по их решению, для этого создается эта площадка”, — поясняет исполнительный директор АРПП «Отечественный софт» Ренат Лашин.

Ренат Лашин

Отметим, что в среду 13 июня было подписано постановление о централизованных закупках федеральными органами исполнительной власти отечественного офисного программного обеспечения, ПО для ведения бюджетного учета, а также ПО в сфере информационной безопасности. Согласно постановлению, министерству цифрового развития, связи и массовых коммуникаций с участием Центра компетенций по импортозамещению в сфере информационно-коммуникационных технологий необходимо обеспечить предварительное тестирование отечественного офисного ПО, ПО в сфере ИБ, включённого в единый реестр российских программ, для подтверждения его соответствия заявленным в документации функциональным и техническим характеристикам.

Методология планирования и реализации проектов импортозамещения ПО и СВТ в органах государственной власти АРПП «Отечественный софт», напомним, является одним из учредителей Центра компетенций по импортозамещению в сфере информационно-коммуникационных технологий (наряду с Экспертным центром электронного государства и Институтом развития Интернета).

Главой комитета по интеграции отечественного программного обеспечения АРПП избран заместитель генерального директора компании Postgres Professional Иван Панченко. «Заказчики не понимают, на какой комплект отечественного софта можно заменить готовый набор от ведущего западного производителя. Возможно, нужный софт и есть, но где об этом узнать? Совместим ли он между собой? В реестре не найти ответа на эти вопросы», — прокомментировал Панченко.

Иван Панченко.

Цель комитета, по его словам, — повышение конкурентоспособности отечественного ПО в целом за счет его интеграции. Среди первоочередных задач он назвал создание каталога отечественного ПО, который станет информационной основой для всех дальнейших действий и поможет ориентироваться на рынке, подбирать комплекты ПО для решения конкретных типовых задач, а также проводить исследования для определения проблемных мест во всем диапазоне рынка.

Дмитрий Горбачев, заместитель генерального директора компании «Форсайт», пояснил: «Каталог отечественного ПО не будет дублировать Единый реестр, его основная цель — поиск комплексов решений под конкретные нужды потребителей. Реестр такой возможности не даёт. Каталог будет содержать более полную и актуальную информацию, и, главное, сведения о совместимости ПО. Кроме того, на базе каталога будут проведены исследования, проще говоря — построена карта отечественных программных продуктов, на которой будут видны наши успехи и проблемные области. Наблюдая эту карту в динамике, мы будем видеть, как взрослеет наш рынок».

Дмитрий Горбачев.

Также среди задач: способствование созданию продуктовых партнерств и консорциумов, продвижение отраслевых стандартов (стандартизация — основа интеграции), организация тестирования совместимости, совместная маркетинговая активность по поводу идей и фактов совместимости.

Директор по продажам компания SPIRIT (производитель отечественной системы для видеоконфренций «Видеомост») Юрий Хомяк отмечает: «Известно, что «отечественность» отдельного программного продукта не делает его автоматически абсолютно пригодным для задач импортозамещения. Государственный и корпоративный заказчик нуждается в полном наборе, стеке «бесшовно» совместимых отечественных импортозаместительных решений, покрывающих большинство его требований. Подбор, тестирование и комплексное предложение заказчикам таких решений — и есть на наш взгляд основная задача вновь образованного Комитета. При этом важно, чтобы заказчик получил полноценную альтернативу используемым зарубежным решениям, как минимум не уступающую им по качеству, функционалу, техническим характеристикам — т.е. перешел от «импортозамещения» к «импорто-опережению»! Обладая 26-летней экспертизой, в т.ч. на международном рынке, в разработке коммуникационного софта (видеоконференцсвязь, унифицированные коммуникации, встраиваемые VVoIP-движки, корпоративные мессенджеры), мы убеждены, что сможем принести пользу Комитету по интеграции АРПП».

Юрий Хомяк.

Вице-президент корпорации «Галактика» Евгений Михалицын рассказал, что многие разработчики уже проводят или готовятся к тестированию своего ПО на совместимость с ОС, СУБД, офисными продуктами из реестра и др.: «Корпорация Галактика имеет в этом вопросе значительный опыт и готова им поделиться. При создании такой базы Комитету необходимо не только создавать аналитические отчеты по модернизируемому каталогу отечественного ПО, но и систематизировать сведения по его совместимости».

Евгений Михалицын.

Генеральный директор компании «Базальт СПО» Алексей Смирнов отмечает: «Ключевым связующим звеном между отечественными программными и аппаратными решениями, а также между отдельными программными компонентами является российская операционная система. Работа в рамках Комитета по интеграции позволит создавать на базе отечественной ОС программно-аппаратные комплексы, адаптированные к сценариям их применения у заказчиков. Важно, что объединение усилий поможет нам создавать и развивать механизмы для обеспечения совместимости компонентов этих комплексов на протяжении всего их жизненного цикла, что обеспечит надежность функционирования ИТ-инфраструктур заказчиков».

Алексей Смирнов.

d-russia.ru