Rambler's Top100
Реклама
 
Блоги Рустэм ХАЙРЕТДИНОВ

Безопасность заказных приложений. VI

  06 декабря 2012 Страница персоны
Использование сертифицированного программного обеспечения, в сертификате которого написано: «отсутствие недекларированных возможностей (НДВ)», создает иллюзию защищенности. Так ли это?

Если дело касается операционных систем или системных предложений – это во многом соответствует действительности (не будем в этом блоге спорить с профессиональными параноиками, утверждающими, что в любом программном обеспечении есть НДВ, и некоторые из них невозможно найти в принципе). Но чем больших настроек требует ПО, тем больше вероятность того, что сам по себе сертификат ни о чем не говорит. Кроме базового функционала, который и проходит сертификацию в специализированных лабораториях, многие высокоуровневые приложения имеют встроенные средства расширения функционала, вплоть до собственного языка программирования, которыми можно изменить сертифицированный функционал до неузнаваемости.

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

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

Затем выходит новая инструкция соответствующего ведомства по начислению заработной платы или учету кадров, на которую надо быстро отреагировать. С помощью встроенных языков программирования продукт изменяется так, чтобы новый функционал соответствовал требованиям ведомственных инструкций. Внимание, вопрос – осталась ли система аттестованной, а продукт (не базовый, а реально обрабатывающий персональные данные) – сертифицированным? Какие функции, кроме требуемых, появились в обновленном коде? Кто может подтвердить их отсутствие или наличие?

Как вообще сертифицировать системы, меняющиеся быстрее процесса сертификации? Проверять только измененные конструкции – самое простое решение, но оно неполное – изменения в коде могут влиять не только на данные, но и на процессы. То есть совсем не факт, что кусок кода, нормально отработавший в «песочнице», поведет себя так же, будучи интегрированным в рабочую систему.

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

Оставить свой комментарий:

Для комментирования необходимо авторизоваться!

Комментарии по материалу

Данный материал еще не комментировался.

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

Согласен