Искандер Конеев
Источник: www.osp.ru/cio/2002/04/172123
Выбор автоматизированной информационной системы любого уровня — вспомогательной или основной для бизнес-деятельности — серьезный шаг для предприятия. Об основных требованиях по информационной безопасности, предъявляемых к автоматизированной системе, а также о вопросах информационной безопасности, которые следует учитывать при выборе той или иной автоматизированной системы, пойдет речь в данной статье
Выбор автоматизированной информационной системы любого уровня — вспомогательной или основной для бизнес-деятельности — серьезный шаг для предприятия и обычно имеет статус отдельного проекта, оформляемого соответствующими документами. Одним из таких документов может быть техническое задание или технические требования к системе, где должны быть определены критерии оценки различных параметров системы: информационной архитектуры, бизнес-функций, интерфейсов и многого другого. В этом списке, видимо, окажутся и требования к информационной безопасности (подсистеме безопасности) системы. Весовые коэффициенты, то есть значимость того или иного параметра для данной системы и для организации в целом, должны быть расставлены в соответствии с потребностями предприятия.
Здесь будут перечислены только те параметры, которые не должны быть упущены при рассмотрении требований. Возможно, они покажутся иными по отношению к списку требований, выдвигаемых другими документами по стандартам информационной безопасности, но эти требования представляются наиболее существенными и, главное, они получены в результате долговременной эксплуатации автоматизированных систем и участия в их разработках.
Спорным может показаться и подход к оценке путем выставления весовых коэффициентов. Форма оценки может быть изменена — от построения классов защищенности (по аналогии с известными государственными стандартами по безопасности) и отнесения конкретной системы к тому или иному классу до составления анкет с пометками о том, присутствует ли данный параметр в системе, и простым подсчетом пометок в конечном результате. Задача данного материала — натолкнуть специалистов и руководителей на размышления о различных составляющих информационной безопасности в автоматизированной системе.
В статье рассмотрены пример автоматизированной банковской системы и некоторые разделы, специфичные именно для таких систем. Однако аналогии легко перенести на любую систему, занимающуюся учетом тех или иных объектов, работой с клиентами и т. п., ведь в большинстве автоматизированных систем присутствуют некие наборы учетных параметров (аналог банковских счетов), взаимодействия между внутренними объектами/субъектами (аналог банковских транзакций) и другие схожие черты.
Предполагается, что система многофилиальна, то есть используется работниками, размещенными в различных, географически удаленных подразделениях организации.
Аббревиатура АС расшифровывается как «автоматизированная система». В статье нет объяснений ряда технических терминов, таких как названия механизмов и средств информационной безопасности, предполагается, что читатель с ними знаком.
Термины «конфиденциальность», «целостность», «доступность» и ряд других используются как понятия информационной безопасности. Это, например, означает, что в понятие «доступность» входит такой раздел, как катастрофоустойчивость.
В статье автоматизированная система рассматривается в отрыве от остального информационного пространства предприятия, однако понятно, что ряд специфических механизмов и технологий, присутствующих в конкретной организации, могут и должны оказать влияние на перечень предъявляемых требований. Например, если в организации уже функционирует система идентификации и аутентификации, скажем Kerberos, то в требованиях должна быть указана необходимость поддержки протокола Kerberos.
Общие требования
Подсистема безопасности АС должна работать на уровне ядра АС таким образом, чтобы ни одно значимое действие в рамках системы — будь то действие пользователя или процесса — не происходило без участия подсистемы безопасности.
Схема безопасности, реализованная в подсистеме, должна быть отделена от средств безопасности самой операционной системы, на которой будет реализована АС, в том смысле, что сбой или уязвимость подсистемы безопасности операционной системы не должны влиять на работу подсистемы безопасности АС. То есть если организация считает, например, средства криптографической защиты, предоставляемые MS Win2000, достаточно надежными, она может снять этот вопрос в требованиях к приложению. Если же Windows — корпоративный стандарт, но при этом для конфиденциальных данных периодические «дыры» в ОС считаются существенной угрозой, значит, приложение должно само заботиться о криптографии. Таким образом, вопрос оставляется на усмотрение лица, принимающего конкретное решение.
Механизмы безопасности подсистемы должны быть реализованы в форме широко известных в мире, опробованных и одобренных стандартов и протоколов.
Подсистема безопасности должна обеспечивать замкнутое сохранение данных, связанных с АС (собственно модулей системы, системных и прикладных данных) таким образом, чтобы:
1) невозможно было получить логический доступ к указанным данным вне рамок работы приложения АС;
2) любые перемещения данных из/в систему происходили под контролем подсистемы безопасности.
Специальные требования
Идентификация и аутентификация
Работа любого субъекта (пользователя или процесса) в АС должна быть идентифицирована системой.
Основным средством аутентификации пользователей в АС должна быть схема «имя пользователя/пароль», при этом система должна допускать возможность расширения процедур аутентификации на основе смарт-карты, touch memory, дискеты. При этом должна присутствовать возможность дифференцированного считывания информации с токена — пароля или ПИН-кода при аутентификации, ключа при шифровании или электронно-цифровой подписи.
Парольная политика должна предусматривать возможность настройки по следующим параметрам:
минимальная длина пароля;
минимальный срок жизни пароля;
максимальное количество ошибок при вводе пароля;
время блокировки счета пользователя после достижения заданного количества ошибок;
поддержка истории паролей;
определение примитивных и слабых паролей;
требование ввода старого пароля при замене новым паролем;
возможность наличия нескольких (до трех) паролей у одного бюджета пользователя.
К дополнительным требованиям к работе с бюджетами пользователя можно отнести следующие:
возможность изменить пароль пользователя, кроме него самого, должен иметь администратор безопасности, при этом он не должен иметь возможности получить информацию о старом, заменяемом пароле;
при входе пользователя в систему должно присутствовать предупреждение о запрете использования чужих паролей и несанкционированного доступа;
при входе пользователя в систему ему должна быть представлена информация о предыдущем успешном входе в систему (дата и время), а также количество ошибок при вводе пароля между двумя последними успешными входами в систему (если таковые были) с указанием даты и времени;
бюджет пользователя должен иметь возможность привязки к конкретному рабочему месту (сетевой адрес), к конкретному времени работы по дням недели и часам (отдельно для интерактивной работы и запуска процессов, а также для удаленной работы);
бюджет пользователя должен иметь уникальный системный идентификатор, который должен формироваться автоматически при регистрации нового пользователя и должен быть доступен уполномоченному администратору только на чтение;
бюджет пользователя должен иметь возможность ручной блокировки уполномоченным администратором без изменения пароля бюджета, а также возможность выставления признака требования немедленной смены пароля пользователем либо запрета смены пароля;
бюджет пользователя должен иметь поля для описательной текстовой информации и возможность расширения для привязки дополнительных полей, например, изображения.
Авторизация и доступ
Для определения единообразного уровня доступа субъектов к информационным объектам, являющимся первичной информационной единицей, система должна предусматривать возможность следующего распределения доступа:
к группе или нескольким группам объектов;
к объекту;
к набору частей объекта.
Например, если информационными объектами являются клиенты, то должна присутствовать возможность определения единообразного доступа к клиентам для конкретного пользователя по следующим критериям:
конкретный клиент;
все клиенты типа А и Б;
все клиенты, у которых пользователь является ответственным контролером или у которых ответственные контролеры принадлежат к той же группе, что и данный пользователь;
только ряд полей в карточке клиента.
Доступ к информационным объектам должен включать следующие виды ограничений:
нет доступа к объекту;
доступ (к объекту/части объекта) только на чтение;
доступ (к объекту/части объекта) только на изменение - отдельно с чтением и без чтения;
удаление информационного объекта;
добавление информационного объекта;
нет доступа на чтение;
нет доступа на изменение;
нет доступа на добавление;
нет доступа на удаление.
Кроме доступа к конкретным информационным объектам, должно быть предусмотрено разделение доступа к функциям, выполняющим процессы над объектами. Отдельно должны быть выделены функции, выполняющие массовые изменения данных в информационных объектах.
Схема определения доступа должна предусматривать возможность группового или ролевого доступа, то есть создание абстрактного профиля прав пользователя. При включении нового пользователя в конкретную группу он автоматически должен наследовать все права, присущие пользователям данной группы. При этом суммарные права пользователя должны проверяться на непротиворечивость, должен применяться принцип поглощения более широкими разрешительными правами более узких (суммирование прав) и принцип преимущества запретительных прав над разрешительными. Также должна присутствовать возможность копирования (наследования) прав пользователя с возможностью последующей корректировки.
Для каждого информационного объекта должен существовать владелец объекта (с возможностью в дальнейшем заменить одного владельца на другого) с полными правами доступа. Система должна контролировать обязательное наличие хотя бы одного пользователя (владельца или администратора) для каждого информационного объекта.
Пользовательский интерфейс настройки прав доступа должен быть прост и интуитивно понятен.
Доступ к бюджетам пользователя
АС должна поддерживать возможность отдельного распределения доступа пользователя:
к карточке (реквизитам) счета (тип счета, балансовый код Главной книги, описание, процентные реквизиты, настройки типов комиссий, уровень неснижаемого остатка, лимит овердрафта и другие параметры);
к остатку счета (в частности, к операциям со счетом).
Виды доступа к карточке счета: чтение, изменение, открытие счета, закрытие счета, блокировка, снятие блокировки и т. д. Возможно дополнительное разделение карточки счета на несколько непересекающихся групп реквизитов и свойств с независимой настройкой прав на них.
Доступ к остатку должен включать следующие независимо настраиваемые уровни: чтение остатка, дебетовые операции, кредитовые операции, возможность просмотра истории оборотов по счету (с отдельной настройкой прав на просмотр дебетовых и кредитовых оборотов с полными реквизитами корреспондентов или без них, а также на авторизацию операций). Для каждого вида операций система должна предусматривать возможность ограничения максимально разрешенной суммы, установленной индивидуально по этой операции для данного счета, а также возможность скрыть от пользователя информацию о клиенте счета, в том числе и при сохранении права на операции со счетом.
При распределении доступа пользователей к счетам (как к карточке, так и к остатку) должен использоваться удобный интерфейс, позволяющий быстро настраивать права на отдельный счет и на целые группы счетов. Группировать счета можно:
по типам счетов (перечень);
по кодам Главной книги (в частности, по маскам кодов);
по типам и группам клиентов;
по валютам;
по филиалам;
по подразделениям организации;
по уровню ответственности (свои счета, то есть счета, у которых данный пользователь является ответственным контролером, или счета группы, то есть счета, у которых ответственные контролеры состоят в одной группе с данным пользователем).
Пользовательский интерфейс распределения доступа должен предусматривать и механизмы для указания исключений по аналогичным правилам (например, все счета группы А, кроме счетов, принадлежащих группе В).
Дополнительные права
Система должна предусматривать дополнительные возможности по установке разграничений доступа к информационным объектам или их частям. Примером такого разграничения является понятие овердрафта (принижение минимально допустимого остатка). Необходимо разграничивать права использования овердрафта следующим образом:
разрешен ли овердрафт вообще;
размер овердрафта для конкретного счета, для группы счетов;
размер овердрафта для данного пользователя;
размер овердрафта для данной операции;
размер овердрафта для вида валюты.
Конфиденциальность данных безопасности и прочих данных
Информация о критических атрибутах профиля пользователя (пароли, ключи) должна сохраняться в виде, исключающем возможность прямого доступа к ним пользователей, минуя средства системы, причем как для постоянной, так и для оперативной памяти. Это означает, что указанные данные при постоянном хранении должны быть защищены средствами криптографии с предоставлением доступа только либо самому пользователю, либо процессам подсистемы безопасности, либо администратору, уполномоченному подсистемой безопасности. При хранении данных в оперативной памяти должна исключаться возможность получения несанкционированного доступа к ним.
При этом пароли должны сохраняться в виде хеш-значений, а ключи — иметь возможность аварийного доверенного восстановления.
Система должна обеспечивать возможность настраиваемой криптографической защиты данных (вплоть до полного сокрытия всех данных) как при архивном, так и при операционном хранении.
Системы при передаче данных по каналам связи от места хранения до конечного пользователя в рамках локальной сети должны использовать только защищенные соединения, при этом защита должна быть осуществлена минимум на транспортном, предпочтительнее — на сетевом уровне.
Для распределенного варианта работы организации, когда основная база данных находится в центре, а конечный пользователь — в удаленном филиале, требуется наличие у организации защищенных каналов связи. АС при этом должна обеспечивать защиту соединения минимум на прикладном, предпочтительно — на транспортном уровне.
Целостность данных
АС должна поддерживать логическую целостность бизнес-данных, то есть изменения должны носить характер транзакционно-ориентированных, выполняющихся в целом от начала до конца либо, в случае сбоя, не выполняющихся совсем. При этом каждая транзакция должна проверяться на непротиворечивость в соответствии с настраиваемыми в АС правилами. Прохождение транзакции в АС должно быть разбито на этапы, сопровождаемые настраиваемым количеством подтверждений (ввод, авторизация и пр.)
Способы же авторизации транзакций должны настраиваться по выбору организации:
несколько авторизаторов для одного пользователя;
один авторизатор для группы пользователей;
один авторизатор для данного типа операций.
АС должна иметь настройку на обеспечение апеллируемости на ряд критически важных транзакций путем использования электронно-цифровых подписей. Должна присутствовать возможность варьировать количество подписей на одну транзакцию в вариантах:
без подписи;
одна подпись;
две подписи;
три подписи.
Также должна присутствовать возможность включения/исключения полей записей транзакции в/из группы параметров для цифрового подписывания.
Система должна предусматривать формирование шаблона транзакции, когда ряд значимых полей заполняется автоматически, без возможности корректировки пользователем.
Система должна иметь собственную встроенную или внешнюю подсистему проверки целостности файлов, модулей и системных данных самой АС на предмет их несанкционированной модификации.
Никакие системные или прикладные данные не должны удаляться в рамках АС без следов. Должна присутствовать настройка на запрет удаления отдельных категорий данных. Система также должна фиксировать информацию, необходимую для идентификации факта, объекта и субъекта процесса удаления. Система должна предусматривать возможность восстановления удаленных данных в течение определенного промежутка времени.
Доступность данных
АС должна предусматривать возможность устойчивой работы при появлении сбоев, то есть возможность конфигурации для работы кластера из двух и более географически распределенных узлов. При этом выход из строя некритического количества узлов не должен сказываться на общей функциональности системы.
Процессы, требующие от системы монопольного использования ресурсов и препятствующие интерактивной работе пользователей, должны быть перенесены на время наименьшей активности (ночь) и в сумме занимать не более 10-15% суточного рабочего времени системы.
Система должна быть реализована в трехуровневой архитектуре клиент-сервер с тем, чтобы вывод из строя рабочего места пользователя или получение злоумышленником несанкционированного доступа к нему не сказывался на работе серверной части системы, а сбой сервера приложений не влиял на состояние данных системы.
Система должна обладать возможностью балансирования нагрузки между отдельными узлами, модулями и функциями, а также иметь подсистему предупреждения о работе в режиме, приближенном к максимальной загрузке.
АС должна иметь возможность резервного копирования и восстановления средствами самой системы. Резервное копирование должно осуществляться на различные носители по выбору организации, в том числе в дискретном (разорванном) виде, то есть общий объем резервной копии может быть распределен между двумя или более носителями меньшего объема.
Резервное копирование должно предусматривать как сохранение прикладных, так и системных данных, и осуществляться в режиме с криптографической защитой по заранее установленному графику от одного до нескольких раз в день либо вручную по команде оператора. При этом процедура не должна забирать ресурсы системы в монопольное использование.
В системе следует предусмотреть механизм облегченного восстановления потерянных в результате сбоя операционных данных со времени последнего резервного копирования.
Удаленная работа
Система должна предусматривать возможность работы пользователей в удаленном режиме по выделенным, коммутируемым каналам либо средствами Интернета. Для этого она должна иметь либо собственную встроенную систему создания виртуальной частной сети, либо возможность тесной интеграции с межсетевым экраном.
В случае реализации защиты соединения на уровне выше сетевого система должна обладать защитой системы маршрутизации сетевых пакетов.
Системы настройки аутентификационных механизмов, авторизации, прав доступа и прочих элементов схемы безопасности должны четко различать варианты локальной и удаленной работы и, соответственно, иметь возможность применения различных правил в зависимости от режима доступа.
Аудит и мониторинг
Прежде чем сказать об аудите и мониторинге, необходимо подчеркнуть ряд важных моментов. Например, список событий, подлежащих аудиту, может зависеть от того, какова форма представления электронных материалов, которые будут служить доказательствами при возможных будущих расследованиях или судебных разбирательствах. Необходимо также учесть, с одной стороны, возможность пополнения списка таких событий, а с другой — исключение возможности несанкционированного редактирования списка событий.
Другой заслуживающий внимания пункт — возможное увеличение загрузки ресурсов системы при расширенном, всеохватывающем аудите. Хотя конкретные количественные показатели такой загрузки зависят от того, как был написан программистом модуль аудита, тем не менее этот параметр должен быть измерен. Вопрос только в том, измерять его отдельно или в совокупности с работой остальных подсистем. Рекомендуемый подход — проанализировать работу АС в целом при полной загрузке с включением всех подсистем и проверить соответствие производительности текущему аппаратному и системно-прикладному обеспечению. Если полученное соответствие устраивает — принимать параметр производительности в целом.
Система аудита АС должна различать бизнес-значимые и системно-значимые события. Для бизнес-значимых событий должны фиксироваться параметры, которые не отражаются напрямую в прикладных данных системы, например такие, как время запуска процедуры массовой работы со счетами, имя пользователя и сетевой адрес его рабочей станции. Для системно-значимых событий должна происходить фиксация любых изменений, которые так или иначе могут отразиться на работе системы. Такой список должен включать следующие события (но не ограничиваться ими):
добавление, удаление пользователя или изменение атрибутов пользователя;
изменение настроек криптографической защиты данных;
изменение настроек контроля целостности;
изменение настроек удаленного доступа;
изменение настроек резервного копирования;
изменение настроек, влияющих на работоспособность и производительность системы;
запуск, остановка процедур системного характера и обмен данными с процедурами системного характера;
сообщения администратору, имеющие отношение к безопасности системы.
При этом информация, фиксируемая в регистрационных журналах, должна обеспечивать однозначную идентификацию субъекта, причины, времени, местоположения и результата произведенного действия.
Все бизнес-значимые действия пользователей в АС, как успешные, так и неудачные, начиная от попытки установления связи и до завершения сессии, должны быть зафиксированы. Журнал будет использован для исследования корректности работы АС, мониторинга действий пользователей, расследования сложных или подозрительных событий и т. д.
Все события должны быть разбиты на типы (открытие счета, регистрация клиента, корректировка карточки счета и пр.) и категории (клиенты, счета, пользователи, системные события, безопасность и т. д.).
Каждый тип событий характеризуется уровнем доступа или тем, интересы каких пользователей могут затронуть события данного типа и для кого они будут доступны при просмотре журнала. Возможны следующие уровни:
система в целом - уровень центрального администратора системы (доступны все события в системе);
филиал - уровень администратора филиала организации (доступны все события, относящиеся к данному филиалу);
сотрудник - уровень сотрудника филиала (доступны только те события, которые относятся к нему или затрагивают его интересы);
Каждое событие должно обладать как минимум следующими реквизитами:
автор (пользователь, который породил это событие);
время (календарная дата и время, когда событие произошло);
категория события;
события;
объект события;
описание события (конкретные подробности события и объекта);
филиал организации, затронутый событием.
При работе с журналом событий должна быть обязательно предусмотрена возможность фильтрации событий, то есть возможность показывать не все события, соответствующие данному периоду, а только те, которые в настоящий момент нужны. Список параметров фильтрации должен включать все указанные выше реквизиты событий.
Регистрационные журналы системы должны обладать возможностью защиты от изменений со стороны любого субъекта, кроме процесса его формирования (доступ только на чтение уполномоченным администраторам). Доступ на чтение регистрационного журнала должен зависеть от установленного для данного администратора фильтра прав.
Регистрационный журнал должен обладать механизмами обеспечения его юридической доказательности (например, системная или административная цифровая подпись).
Аудит событий должен включать возможность формирования шаблонов событий, подозрительных на злоумышленные. При наступлении событий, соответствующих такому шаблону, система должна выдавать оповещение уполномоченному лицу.
Система должна предусматривать мониторинг и управление работой пользователей, включая следующие возможности:
отображение текущих сессий пользователей в системе;
отправка системного или административного сообщения пользователю или группе пользователей;
автоматическое завершение сессии пользователя при достижении определенного времени бездействия в системе;
ручное принудительное завершение сессии пользователя (группы пользователей) администратором.
Бизнес-отчеты
Система формирования бизнес-отчетов должна укладываться в схему прав пользователя, то есть пользователь не должен получать в рамках отчета информации больше, чем доступно ему в рамках разрешения на чтение.
Разрешение на получение консолидированных (сводных) отчетов может определяться отдельно.
Интерфейсы
Для обмена данными с другими системами АС должна обеспечивать наличие соответствующих интерфейсов таким образом, чтобы подсистема безопасности АС могла:
продолжать контроль экспортируемых данных в рамках правил, определенных в АС, до тех пор пока контроль над данными не возьмет на себя система, в которую производится экспорт;
принимать на себя контроль импортируемых данных от другой системы после получения от этой системы сигнала о готовности импортируемых данных;
устанавливать на импортируемые данные правила доступа, авторизации, контроля целостности и пр. в соответствии с предопределенным шаблоном для импортируемых данных.
Поддержка системы производителем
Система должна обладать полной и исчерпывающей документацией по безопасности, а именно должны быть описаны:
процедуры и обязанности по безопасности для пользователя;
процедуры и обязанности по безопасности для бизнес-администратора (прикладного администратора);
процедуры и обязанности по безопасности для системного администратора;
руководство для администратора безопасности системы.
Поставщик должен:
представить соответствующие сертификаты на механизмы безопасности, реализованные в системе (предпочтительно широко известных сертифицирующих компаний или государственные сертификаты);
регулярно информировать уполномоченных сотрудников организации об обнаруженных ошибках и слабых местах системы, а также своевременно предоставлять изменения и обновления к системе;
организовать службу оперативной поддержки, в том числе по вопросам безопасности для консультирования уполномоченных работников организации и оказания им практической помощи, например, в вопросах устранения последствий нарушений информационной безопасности.
Расширение функциональности безопасности
АС должна предоставлять механизм для самостоятельной разработки специалистами организации автоматизированных процедур и модулей по информационной безопасности, например, через систему API и GSSAPI.
Примером возможного расширения функциональности может служить переход на биометрические средства аутентификации пользователей в системе.
Оценка системы
Для успешной оценки системы по перечисленным критериям необходимо расставить некую балльную оценку параметров. Возможно, придется составить документ в виде анкеты с ответами типа: да/нет/нет, информации/примечания и оценивать полученные ответы соответственно.
Для ряда параметров можно предусмотреть альтернативные варианты ответов, например, требование, предъявляемое к созданию виртуальных туннелей, можно адресовать не к АС, а к операционной системе. Необходимо лишь, чтобы оценку реальной системы по составленным критериям производили подготовленные, квалифицированные специалисты, в количестве, необходимом для того, чтобы исключить субъективность оценок.