Лицензирование, сертифицирование и т.п.

уж если на то пошло, то сертифициовать нужно каждую версию всего софта. По сути любое обновление.
Та программа к которой я имею отношение обновляется очень часто. Бывает каждый день несколько дней подряд по обновлению накатить. (Это не исправления багов, а следствия выхода новых законов, новых начальников, новых пожеланий и требований.....). А если считать отчеты (а через них так же возможно утечку организовать) - тогда вообще труба

voral написал:

уж если на то пошло, то сертифициовать нужно каждую версию всего софта. По сути любое обновление.
Та программа к которой я имею отношение обновляется очень часто. Бывает каждый день несколько дней подряд по обновлению накатить. (Это не исправления багов, а следствия выхода новых законов, новых начальников, новых пожеланий и требований.....). А если считать отчеты (а через них так же возможно утечку организовать) - тогда вообще труба

для примера та же win xp имеет три сертификата соответствия, на sp1, sp2, sp3. И если не ошибаюсь срок действия на какойто sp в этом году истечет.

Но вернемся к нашим баранам.
Просто правильно ли я понял, стоит например в фирме (не гос учереждении) сервак с linux (не alt и и не mandriva), приходят злые дядечки с проверкой, и обана организация попадает на бабки за то что ос на серваке не сертифицирована? и без разницы что есть фаерволы и другие средства защиты.

voral написал:

уж если на то пошло, то сертифициовать нужно каждую версию всего софта. По сути любое обновление.

да.

voral написал:

Та программа к которой я имею отношение обновляется очень часто. Бывает каждый день несколько дней подряд по обновлению накатить. (Это не исправления багов, а следствия выхода новых законов, новых начальников, новых пожеланий и требований.....).

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

jeff87 написал:

Просто правильно ли я понял, стоит например в фирме (не гос учереждении) сервак с linux (не alt и и не mandriva), приходят злые дядечки с проверкой, и обана организация попадает на бабки за то что ос на серваке не сертифицирована?

ну так и должно быть ИМХО.

jeff87 написал:

и без разницы что есть фаерволы и другие средства защиты.

да. см выше. атака на маздай98 в сертифицированном крипто-бункере http://linuxforum.ru/viewtopic.php?pid=151148#p151148

Можно вызвать фирму-лицензиата,того же ФСТЭК и она за денюжку сертифицирует.

drBatty написал:

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

Это как? Данные в базе, код в программе. Для обновлений надо менять и структуру базы и код (иногода одно из, иногда и то и дугое). Код работает с данными....... Или я не понял о чем вы....
Как вы себе представляете "код не меняется"? Отчет это что? Я могу и в отчете сделать "закладку", и в основном коде, и в хранимой процедуре, и в UDF на стороне сервера. Да даже и в любом запросе к базе (Firebird 2.5. позволяет цепляться к нескольким базам)

voral написал:

Данные в базе, код в программе. Для обновлений надо менять и структуру базы и код (иногода одно из, иногда и то и дугое). Код работает с данными....... Или я не понял о чем вы....

почему с выходом нового закона необходимо менять код? у вас в коде жёстко вбито, что должно быть 173 столбца? почему код не может сам добавить нужный столбец/таблицу/БД ?
расскажите.

voral написал:

Я могу и в отчете сделать "закладку", и в основном коде, и в хранимой процедуре, и в UDF на стороне сервера. Да даже и в любом запросе к базе (Firebird 2.5. позволяет цепляться к нескольким базам)

это по вашему "плюс"? oO

drBatty написал:

почему с выходом нового закона необходимо менять код? у вас в коде жёстко вбито, что должно быть 173 столбца? почему код не может сам добавить нужный столбец/таблицу/БД ?
расскажите.

В "куда" он будет добавлять? В алгоритм начислений? В алгоритмы юридической кухни? В алгоритмы обмена с внешними организациями? И т.д. и т.п.
Поверьте была бы возможность "еще больше разделить" разделили бы за 12 лет. Ну это может быть некая специфика. Но могу и более общий пример привести: в организациях со длинной/сложной структурой подчинения, да еще которая находится под контролем всяких обществ и организаций. Каждый от большого начальника до маленького шишонка в каждом отделе хочет получить отчет одному ему понятных сочетаний цифр. Пи чем уже получается не посто выборка, а некий дополнительный функционал по коду. Безусловно можно это обойти если довести алгоритм начислений до безумной степени детализации (да и то это не будет гарантиовать) - но в результате и база раздуется до терабайтов, и запросы/отчеты сводные будут нехило формиоваться.

В прочем, что то отошли. Короче хотите верьте хотите нет предложенный вами путь нам в нашей ситуации не подходит.

drBatty написал:

[quote=voral]Я могу и в отчете сделать "закладку", и в основном коде, и в хранимой процедуре, и в UDF на стороне сервера. Да даже и в любом запросе к базе (Firebird 2.5. позволяет цепляться к нескольким базам)

это по вашему "плюс"? oO[/quote]
А где вы увидели, что я это в "плюс" записал? Я к тому, что разделяй не разделяй путей организации утечки масса. И поэтому вообще ЛЮБОЕ изменение связанное с подобной системой (даже изменение структуры базы, даже новый отчет) по сути является отклонением от сертифициованной системы со всеми вытекающими.

voral написал:

В "куда" он будет добавлять? В алгоритм начислений? В алгоритмы юридической кухни? В алгоритмы обмена с внешними организациями?

да, а что?

voral написал:

Поверьте была бы возможность "еще больше разделить" разделили бы за 12 лет.

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

voral написал:

в каждом отделе хочет получить отчет одному ему понятных сочетаний цифр. Пи чем уже получается не посто выборка, а некий дополнительный функционал по коду. Безусловно можно это обойти если довести алгоритм начислений до безумной степени детализации (да и то это не будет гарантиовать) - но в результате и база раздуется до терабайтов, и запросы/отчеты сводные будут нехило формиоваться.

почему нельзя сделать встроенный недоязык, как например сделали в 1С?
так сделано не только в СУБД, но и во многих других программах.
а "до безумной степени детализации" я и не предлагаю - как раз наоборот.

voral написал:

Я к тому, что разделяй не разделяй путей организации утечки масса. И поэтому вообще ЛЮБОЕ изменение связанное с подобной системой (даже изменение структуры базы, даже новый отчет) по сути является отклонением от сертифициованной системы со всеми вытекающими.

ИМХО это свидетельствует об очень плохом изначальном проектировании (которого наверное и не было).

drBatty написал:

[quote=voral]В "куда" он будет добавлять? В алгоритм начислений? В алгоритмы юридической кухни? В алгоритмы обмена с внешними организациями?

да, а что?[/quote]
Да потому, что это нужен скриптовой язык. Т.. прежде чем совершать каждый расчет нужно будет не только все условия наложить. Но и парсить саму формулу. Как ни крути быстродействие пострадает. Поймите я согласен, что в принципе, технически можно задаться и сделать это. Но это не целесообразно.

drBatty написал:

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

Это безусловно. Эта система не имела четкого ТЗ. Мы даем новые возможности, клиент понимает, что можно выжать еще больше - мы делаем. И так далее.... В принципе реальный и правильный процесс: в идеале должен работать компьютер, а не человек.
Да к тому же третья делфа поднадоела, да и мы (азаботчики) уже под макосью да под линуксом сидим. :)
Я думаю это можно сказать вообще про все долгоиграющие проекты: тут и опыт и новые технологии и т.д и т.п. Только вот переписывать не рентабельно. (Мы новых клиентов на этот проект не ищем) Да и коме этого проекта есть чем заниматься.

drBatty написал:

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

Все причины выше:
1. Переписывать по собственной инициативе - нет времени и желания
2. Быстродействие снизится. А тут есть подвижки вообще к единой базе.....
3. Переписывать по инициативе клиента - его не волнуют внутенности да еще за большие деньги. :)

Мы очень отклонились от темы. Если интересно обсуждение давайте в личку....

voral написал:

1. Переписывать по собственной инициативе - нет времени и желания

угу. просто в один "прекрасный" день, ваши клиенты поставят себе новую программку. не страшно?

voral написал:

2. Быстродействие снизится. А тут есть подвижки вообще к единой базе...

почему-же? часто скрипт работает быстрее программы на C. к тому-же скрипт - переносим на что угодно. потому для вашей программы CPU так и будет 80486м процессором(хоть и частотой 1000МГц), а для скрипта - последним i7 (или что там сейчас?)
кроме того, скрипты быстрее писать. надеюсь понятно, зачем это?

voral написал:

Мы очень отклонились от темы

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

есть и ещё один момент - не хотят серифицировать слишком хорошие программы, вроде GnuPG...

drBatty написал:

почему нельзя сделать встроенный недоязык, как например сделали в 1С?

Нельзя. Так как документами ФСТЭК по 152-ФЗ определено (очень криво определено, в сугубом противоречии с оранжевой книгой и РД ГТК) требование обеспечения целостности. Так вот, целостность на системах с ПД должна обеспечиваться не методами проверки контрольных сумм, как делают во всем мире, а исключительно применением компиляторов с языков высокого уровня и отсутствием в системе, обрабатывающей, хранящей или передающей ПД каких либо средств разработки и отладки программного обеспечения. Причем должна быть обеспечена и невозможность изменения исполняемого объектного кода в ходе его исполнения.

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

Ну а дальше - любое обновление ПО и вся твоя аттестация накрывается медным тазом. Изволь аттестоваться по новой.

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

у а дальше - любое обновление ПО и вся твоя аттестация накрывается медным тазом. Изволь аттестоваться по новой.