Организация безопасного функционирования бизнес-приложений

Владимир Мамыкин

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

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

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

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

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

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

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

Программа обеспечения безопасности приложений

Для того, чтобы управлять процессами оценки и поддержания безопасности всех имеющихся и разрабатывающихся бизнес-приложений, в отделе информационных технологий Microsoft создана группа специалистов в разных областях, обладающих глубоким пониманием производственных требований корпорации и вопросов безопасности информации. Этой группой была разработана Программа обеспечения безопасности приложений (Application Security Assurance Program, ASAP), направленная на устранение потенциально уязвимых мест во внутренних бизнес-приложениях корпорации путем приведения этих приложений в соответствие с правилами безопасности отдела информационных технологий.

Принципы безопасности

Корпорацией принята политика безопасности приложений, ее основу составляет ряд принципов.

●     Конфиденциальность. Предотвращение раскрытия информации неуполномоченным лицам.

●     Целостность. Предотвращение повреждения, искажения или изменения информации или сервисов.

●     Проверка подлинности. Удостоверение личности в сети перед предоставлением этой личности доступа к данным.

●     Авторизация. Обеспечение доступа к данным только тем лицам, которые были надлежащим образом авторизованы и получили соответствующие права (чтение, запись, изменение и т.д.).

●     Доступность. Обеспечение работоспособности и доступности информационных ресурсов, сервисов и оборудования.

●     Доказательство причастности. Связывание пользователя или объекта с действием, позволяющее доказать связь определенного действия с подозреваемым, отрицающим свою причастность.

Управление рисками

При внедрении новых внутренних приложений в корпоративную сеть Microsoft одновременно применяется несколько методов снижения риска.

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

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

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

●     Юридические аспекты. Разработка терминологии для оценки уровня безопасности в договорах с разработчиками коммерческого программного обеспечения и поставщиками приложений сторонних разработчиков (это относится также к сторонним организациям, хранящим данные корпорации в своих системах).

Создание программы обеспечения безопасности приложений

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

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

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

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

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

Критерии оценки

Группа контроля приложений при выполнении оценки уровня безопасности приложения учитывает целый ряд критериев.

●     Определение приложения. Согласно требованиям ASAP, прежде всего необходимо определить, является ли конкретный программный продукт приложением. Программное обеспечение, которое является ключевым компонентом существующего приложения (например, Web-сервис, компонент COM+, сервис .Net, реплицированная база данных отчетности, пакетное задание), не рассматривается независимо от приложения, к которому этот компонент принадлежит. Изделия, не являющиеся приложениями, должны подчиняться правилам политики управления доменом ИТ-отдела. Если лицо, ответственное за внутренний программный продукт, может ответить утвердительно на все перечисленные далее вопросы, считается, что продукт является приложением. Поддерживает ли программное обеспечение бизнес-функции Microsoft? Предоставляет ли программное обеспечение что-либо большее, чем набор статической информации или данных (скажем, сложнее ли оно, чем Web-узел SharePoint, простая HTML-страница или статическая электронная таблица Excel)?

●     Границы оценки. Высокий риск — связанное с внешним миром приложение, используемое клиентами и партнерами. Средний риск — особо секретные данные (например, бизнес-информация, сведения о клиенте или интеллектуальная собственность) и архитектура с повышенным риском. Низкий риск — менее важные данные или приложения, связанный с которыми риск не является ни средним, ни высоким. Для приложений с более высоким риском производится более глубокая проработка вопросов безопасности. Оценки, выполняемые группой контроля приложений, могут быть ограниченными или всесторонними. Первые используются для уровня сети, операционной системы и таких технологий Microsoft BackOffice, как базы данных и Web-серверы. Выполняется поиск таких уязвимых мест, как неиспользуемые открытые порты маршрутизаторов, разрешения на доступ к файлам, неиспользуемые сервисы, незащищенные пароли и ненужные учетные записи. Всесторонние оценки включают все проверки процесса ограниченной оценки плюс исследование исходного кода приложения и используемых им данных. Поиск уязвимых мест предусматривает проверку Web-страниц, для посещения которых не требуется авторизация; сеансов, в которых не может быть предотвращено заимствование прав или атака с помощью воспроизведения cookie; сообщений об ошибке, раскрывающих конфиденциальную информацию (в том числе, имена серверов или пользователей), данных приложения, которые могут использоваться для вторжения в другое приложение.

Участники

В Microsoft группа контроля приложений работает совместно с отделом корпоративной безопасности и оперативными ИТ-группами над выработкой правил для ИТ-групп производственного подразделения (рис. 1).

Структура процесса обеспечения безопасности приложения

Общая задача ASAP определяется в структуре процесса обеспечения безопасности приложения (рис. 2).

Соблюдение и публикация политики и инструкций

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

Повышение квалификации ИТ-специалистов

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

Проектирование, разработка, испытание и проверка безопасных приложений.

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

Проверка используемых в производстве приложений

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

●     оценка вновь появившихся приложений, которые еще не были проверены;

●     оценка приложений, не проверявшихся в течение прошедшего года;

●     оценка приложений, для которых предусмотрено регулярное сканирование для обнаружения уязвимых мест;

●     сканирование уязвимых мест, удостоверяющее стойкость среды приложения к вторжениям;

●     контроль безопасности, подтверждающий соответ­ствие имеющихся старых приложений требованиям стандартов безопасности.

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

Реагирование на инциденты нарушения безопасности.

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

Управление безопасностью приложений

Безопасная инфраструктура разделяется на пять основных архитектурных компонентов: сеть, узел, приложение, учетная запись, доверие. Для каждой из этих областей характерны свои уязвимые места.

Создание безопасных сетей для поддержки приложений

Топология сети организации должна быть проанализирована с точки зрения сетевой безопасности. В частности, сегментация сети минимизирует «неявные» доверительные отношения между серверами, нередко используемые при проведении атак. Сетевые экраны должны максимально ограничивать число открытых портов для входящего и исходящего трафика — как для внутренних, так и для внешних сетей. На серверах экранов должны быть установлены и включены лишь самые необходимые компоненты ОС. Сетевой экран уровня приложений с функциями прокси-сервера (например, Internet Security and Acceleration (ISA) Server) является более эффективным решением, чем простой экран, выполняющий фильтрацию пакетов. ISA Server позволяет реализовывать дополнительные правила, допускающие использование только определенных коммуникационных запросов и протоколов. Администрирование маршрутизатора должно осуществляться исключительно в локальной сети, а не в удаленном режиме (из глобальной сети или по коммутируемому соединению).

Системы распознавания сетевых атак, как минимум, должны осуществлять мониторинг сети на наличие атак, проводимых в целях получения информации о системе; атак с использованием уязвимостей; DoS-атак.

Секретные данные, передаваемые по внешним или внутренним каналам, должны шифроваться для обеспечения безопасности. Следует использовать методы шифрования на основе отраслевых стандартов (например, SSL или IPSec).

Настройка безопасных узлов для приложений

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

Параметры списков доступа ACL должны быть правильно настроены для всех общих ресурсов и других элементов системы и баз данных, а также объектов COM+ в целях предотвращения несанкционированного доступа. На всех серверах, независимо от их назначения, должны выполняться антивирусные программы, активно сканирующие все области системы и все общие каталоги. На каждом сервере необходимо организовать аудит и ведение журналов, а также архивацию и восстановление данных.

Уровень приложений

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

Код сеанса (уникальный идентификатор, определяющий пользователя и связывающий его с запросами, передававшимися на сервер в течение последнего времени) играет роль постоянного подтверждения подлинности. При отсутствии более надежных методов проверки подлинности, например, обычной или встроенной проверки подлинности Windows, любой человек, располагающий кодом сеанса, может олицетворять соответствующего пользователя в Web-приложении до истечения срока действия сеанса. Срок действия сеанса обычно истекает после 5-20 минут бездействия, но в любом случае он должен иметь достаточную длину для предотвращения взлома методом грубой силы.

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

Приложения должны проходить формальную проверку на безопасность конструкции перед написанием программного кода для обеспечения безопасной архитектуры и методов разработки. После написания программного кода необходимо выполнить предварительную оценку безопасности, подтверждающую, что все недостатки, выявленные на этапе проверки конструкции, устранены и приложение отвечает требованиям безопасности. Для выявления известных уязвимостей необходимо выполнить проверку с помощью сканеров безопасности в среде тестирования. Должны быть произведены проверки для обнаружения атак с вложением программного кода, атак типа cross-site scripting, DoS-атак, с переполнением буфера и т.д.

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

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

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

Общие вопросы разработки приложений

Безопасность приложений должна обеспечиваться с самого начала процесса разработки.

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

Следует избегать использования файлов cookie для управления сеансами.

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

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

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

Моделирование угроз

Моделирование состоит из следующих этапов: обнаружение известных угроз в системе, расположение угроз по убыванию уровня риска; определение адекватной реакции на угрозы; определение методов, позволяющих снизить угрозы; выбор наиболее подходящих методов, позволяющих снизить угрозы.

Отдел информационных технологий использует для определения угроз модель STRIDE (Spoofing identity — «имитация подлинности», Tampering with data — «манипулирование данными», Repudiation — «искажение авторства», Information disclosure — «раскрытие информации», Denial of service — «отказ в обслуживании» и Elevation of privilege — «получение дополнительных привилегий»).

Моделирование архитектуры включает четыре этапа: выбор компонентов, расположение компонентов, определение подключений и определение компонентов среды.

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

***

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