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

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

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


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


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


Требования регуляторов Если бизнес-приложение обрабатывает данные, оборот которых регулируется государственными или отраслевыми регуляторами, то к рискам добавляются и санкции с их стороны. Какие-то регуляторы игнорируют (пока?) такие риски - например, среди технологических требований к ФЗ «О персональных данных» требования по анализу кода приложений, обрабатывающих персональные данные, отсутствуют, другие регуляторы продвигают отдельные стандарты разработки, например, PCI Council имеет стандарт PA DSS, описывающий процесс контроля приложений, обрабатывающих данные платежных карт. Похожие требования разной жесткости - от обязательных до лучших практик есть и у других регуляторов. Появление таких требований у российских регуляторов - вопрос времени и квалификации экспертов этих регуляторов. Какими будут санкции за несоблюдение таких требований, пока не понятно, но санкции PCI Council и HIPPA весьма чувствительны.


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

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

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

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