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

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

  20 ноября 2012 Страница персоны
Существует стойкое убеждение, что защита приложений - это, прежде всего, контроль уязвимостей во внешних веб-приложениях, а внутренние приложения защищены принципом неотвратимости наказания. Действительно, теоретическое число пользователей веб-приложения - это все пользователи Интернет, а пользователей бухгалтерского приложения - всего несколько человек; их имена известны, и, случись что, расследование долго не продлится. Поэтому требования к внутренним приложениям по безопасности разительно отличаются от требований к клиентским веб-приложениям. Однако во внутренних приложениях находится ключевая для бизнеса информация. Мало в каких компаниях единственным внутренним приложением является бухгалтерия - на удобной изначально бухгалтерской платформе давно построены и CRM-системы, и системы планирования и бюджетирования, и системы управления предприятием. Информация, которая находится в таких приложениях, несет в себе огромные риски - от угроз крупных штрафов и даже уголовного преследования руководителей (двойная бухгалтерия, например) до коммерческой тайны (специальные цены и скидки, клиентская информация, информация о новых продуктах, планируемых маркетинговых мероприятиях и т.п.). Программисты внутренних бизнес-приложений в небольших компаниях - свои или фрилансеры - являются абсолютно доверенными сотрудниками, чаще всего - вынужденно, поскольку никто не в состоянии проверить качество их работы. Не является ли угроза со стороны таких разработчиков «призрачной»? Что конкретно может сделать ваш программист, если ему это придет в голову? Ставшие уже анекдотами (а иногда и уголовными делами) случаи внезапного отказа бизнес-приложений при отказе от услуг конкретного программиста или компании-разработчика - самая незначительная угроза, которая может возникнуть при потере контроля над разработкой. В силах программиста не только организовать самому себе (или любому наперед известному пользователю или администратору системы) «черный ход», нигде не зарегистрированную учетную запись, которая даст возможность доступа к критическим данным приложения. И эта учетная запись может быть использована не только для похищения данных, но и для их изменения, то есть организации мошенничества. Где гарантия того, что тот, кто авторизован создавать электронные бизнес-процессы, создает только те процессы, о которых его просили? Фальшивые платежные и отгрузочные документы, коммерческие предложения по невыгодным для компании ценам, да еще сделанные от имени ничего не подозревающего авторизованного пользователя, - вполне реальная и довольно просто реализуемая угроза. Раскрыть такое мошенничество практически невозможно - процесс разработки устроен так, что и написанием кода, и обновлением версий программного обеспечения, и архивированием старых версий занимается один и тот же человек. После отработки задачи код с закладкой уничтожается, и на его место под видом обновления пишется код без закладки. И если в больших компаниях формализация требований безопасности к внутренним приложениям и контроль их исполнения хоть как-то поставлен, то в небольших компаниях его нет вовсе - все делают один-два программиста, часто даже не находящиеся в штате компании. "Плохие вещи случаются с другими, а не с нами", - отличное обоснование такой позиции. Потом вдруг окажется, например, что со счета компании через систему ДБО прошел платеж, который никто не видел, или с территории склада была вывезена в неизвестном направлении продукция по легитимным, но нигде не зарегистрированным накладным. После неудачной попытки расследования убытки будут списаны на неведомых хакеров. Когда такая беда случится у вас, вспомните, не сменился ли перед этим у вас 1С-программист или не обидели вы чем-либо старого разработчика? Раз вы даете неограниченные возможности без контроля, появление намерений ими воспользоваться нельзя сбрасывать со счетов. И чем глубже проникла автоматизация в ваш бизнес, тем менее «призрачна» такая угроза.

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

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

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

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