Данный раздел посвящен мерам, которые ориентированы на людей, а не на технические средства. Именно люди формируют режим информационной безопасности и, в частности, доступности, и они же оказываются главной угрозой.
В этом разделе будут рассмотрены рутинные действия, направленные в первую очередь на обеспечение безотказной работы информационных сервисов.
Можно выделить следующие направления повседневной деятельности:
Поддержка пользователей состоит прежде всего в обучении, консультировании и в оказании помощи при решении разного рода проблем.
Организация обучения должна обладать тремя свойствами:
Занятия, особенно практические, должны быть увязаны с существующими регламентами и инструкциями. Практические занятия должны проводиться на имитационном стенде, с отработкой действий как в штатных, так и нештатных ситуациях.
Рекомендуемая периодичность учебных курсов — не реже одного раза в год. Как считает известный психолог профессор Ильясов, целесообразно раз в полгода проводить "учения" на имитационном стенде, проверяя и закрепляя практические навыки персонала.
В соответствии с рекомендуемой политикой повышения доступности, работа консультационных служб должна быть строго регламентирована и в максимальной степени стандартизована и автоматизирована. Регламент должен касаться общения с пользователем (нужно собрать максимум информации и одновременно успокоить человека), порядка фиксации обращений пользователей и реакции на них. Целесообразно разработать для перечисленных целей стандартные формы. Для автоматизации консультационной службы могут применяться многочисленные системы управления проблемами (Problem Management Tools) и столы справок (Help Desk).
Поддержка программного обеспечения — одно из важнейших средств повышения доступности информации. Прежде всего, необходимо контролировать, какое программное обеспечение выполняется на компьютерах. Использование неавторизованных программ или программ с неавторизованными изменениями должно быть запрещено. Особенно это касается клиентских систем. Целесообразно унифицировать операционную среду этих систем и затем централизованно контролировать пользовательские конфигурации, анализируя управляющую информационную базу (Management Information Base — MIB). Подобный контроль следует сделать регулярным и автоматическим.
Необходимо хранить эталонные копии авторизованного программного обеспечения вместе с документацией. Должны присутствовать и регулярно использоваться утилиты, контролирующие не только общую конфигурацию, но и целостность всех компонентов программного обеспечения на всех компьютерах ИС.
Необходимо наладить централизованное хранение конфигурационных файлов всех компонентов ИС, включая не только компьютеры, но и активное сетевое оборудование. Первое действие, которое следует предпринимать при сбое маршрутизаторов или концентраторов — попытка перезагрузить их с использованием эталонных конфигурационных файлов.
Распространение нового программного обеспечения также необходимо производить централизованно, и порядок такого распространения должен быть регламентирован.
Если синхронизировать меры обеспечения доступности с жизненным циклом сервисов, можно добиться большего эффекта с меньшими затратами.
В жизненном цикле информационного сервиса целесообразно выделить следующие этапы:
На этапе инициации оформляется понимание того, что необходимо приобрести (разработать) новый или значительно модернизировать существующий сервис; выполняются прикидки, какими характеристиками и какой функциональностью он должен обладать; оцениваются финансовые и иные ограничения.
Следует указать, что свойства безотказности, живучести и обслуживаемости в значительной мере определяются именно на этапе инициализации, при выборе основных принципов и архитектурных решений, закладываемых в основу нового сервиса. Есть лишь еще один этап, способный столь же радикально повлиять на доступность — это этап установки, на котором вырабатываются нормы и порядок эксплуатации сервиса.
На этапе закупки (разработки) целесообразно обратить особое внимание на надежность компании-поставщика (разработчика), ее способность обеспечить сопровождение продукта, послепродажное обслуживание, обучение персонала, наконец, на время реакции ее сервисной службы. Все эти моменты должны быть оговорены в контракте на закупку (разработку).
Когда продукт закуплен или разработан, его необходимо установить и сконфигурировать и протестировать. Первоначальная установка должна выполняться на имитационном стенде. Следует разработать и утвердить регламент тестирования продукта на стенде, в том числе набор тестовых примеров. Если это возможно, целесообразно привлечь к тестированию пользователей.
На имитационном стенде должны моделироваться различные, в том числе нештатные, режимы работы. Помимо собственно работоспособности, должны проверяться полнота регистрационной информации, возможность удаленного контроля за продуктом с использованием имеющихся средств. На стенде необходимо протестировать ситуации отказов и использования средств обеспечения живучести, если таковые имеются, равно как и порядок ручного переключения на резервный экземпляр продукта. Должны быть отработаны процедуры устранения неисправностей и деинсталляции продукта, а также другие регламентные документы, необходимые на этапе эксплуатации.
Важным результатом тестирования продукта на имитационном стенде должно стать пополнение базы данных консультационной службы, поддерживающей работу пользователей.
Тестирование должно завершаться подготовкой отчета, содержащего описание проведенных действий и их результаты. На основании отчета, с учетом полноты и комплексности тестирования, принимается решение об установке штатного варианта, его конфигурировании и вводе в пилотную эксплуатацию. Для большой организации, где много пользователей и данных, начальная настройка может стать весьма трудоемким и ответственным делом, которое необходимо детально регламентировать.
Фаза пилотной эксплуатации также должна быть тщательно регламентирована. Не следует совмещать фазы пилотной эксплуатации сразу нескольких продуктов. Заранее должны быть оговорены ситуации, требующие немедленного выключения и деинсталляции продукта.
После успешного завершения пилотной фазы, начинается период штатной эксплуатации — самый длительный и сложный. На этом этапе необходимо контролировать следование регламентам, а также периодическую коррекцию регламентов при изменении условий эксплуатации. Целесообразно не реже одного-двух раз в год проверять действенность используемых средств обеспечения доступности сервисов.
При выведении сервиса из эксплуатации следует позаботиться о сохранности обрабатываемых им данных, чтобы гарантировать возможность их импорта в новый сервис.
Конфигурационное управление позволяет контролировать и фиксировать изменения, вносимые в программную и (что не менее важно) аппаратную и инфраструктурную конфигурации. Необходимо застраховаться от случайных или непродуманных модификаций, уметь как минимум возвращаться к прошлой, работающей версии. Фиксация изменений позволит при необходимости воспроизвести эти изменения для дублирующих ресурсов и восстановить текущую версию после аварии.
Следует регламентировать порядок внесения изменений. Жизненный цикл изменения напоминает цикл нового продукта. На первой фазе (инициация) уполномоченное лицо вносит предложение по изменению текущей конфигурации, после чего определяется круг лиц, которых это изменение затрагивает, и в течение 1-3 недель происходит обсуждение. Затем, когда характер и серьезность изменения точно определены и согласованы, разрабатывается регламент его внесения, назначается ответственный за данное мероприятие. Необходимо предусмотреть не только чисто технические аспекты, но и модификацию консультационной базы данных, информирование пользователей и т.п. Заранее, до внесения изменений, должна быть утверждена процедура их отката, если они по каким-либо причинам окажутся некорректными.
Если это предусмотрено регламентом, изменения должны подвергаться тестированию на имитационном стенде. Рекомендуется также явно выделить фазу пилотной эксплуатации, во время которой все, что связано с внесенным изменением, контролируется особенно тщательно и сохраняется возможность быстрого возврата к прежней версии. Само фактически выполненное изменение должно быть тщательно документировано.
Необходимо разработать регламент внесения срочных изменений, когда под угрозой находится работоспособность ИС и на согласования нет времени. Следует определить круг лиц, имеющих право санкционировать подобные действия, а также порядок фиксации изменений, информирования о них заинтересованных лиц и обсуждения произведенного действия.
Технологию конфигурационного управления необходимо применять и к изменениям в аппаратуре и поддерживающей инфраструктуре. Следует фиксировать все изменения в конфигурации клиентских и серверных компьютеров, в локальной сети, в подключении внешних коммуникаций, в размещении кондиционеров и т.п. Удобно использовать для этой цели карту информационной системы.
Процедурные меры, преследующие цель обеспечения живучести и обслуживаемости, образуют в совокупности набор оперативных мероприятий и регламентов, направленных на обнаружение и нейтрализацию отказов и нарушений доступности. Важно, чтобы в подобных случаях последовательность действий была спланирована и отработана до автоматизма заранее, поскольку меры нужно принимать срочные и скоординированные, а действовать людям придется, возможно, в состоянии стресса.
Для обеспечения живучести на процедурном уровне следует предусмотреть избыточность персонала в каждой из критически важных областей (функциональной и территориальной). Подобная избыточность может достигаться за счет наличия резервных специалистов. Целесообразно заключение договоров с родственными организациями о взаимном привлечении персонала в случае возникновения критических ситуаций.
Другой способ создания избыточности персонала — овладение смежными профессиями, способность заменить коллегу. Для поддержания этой формы избыточности нужны как образовательные меры, так и меры материального и/или морального поощрения.
Резервное копирование необходимо для восстановления программ и данных, поврежденных в результате отказа. Целесообразно делать как минимум два экземпляра копий. Один из них следует оставлять поблизости, второй хранить в безопасном, по возможности удаленном месте.
Регулярно (не реже одного раза в месяц) на имитационном стенде в тестовых целях следует проверять возможность восстановления информации с резервных копий.
Реакция на нарушения доступности информационных сервисов преследует две главные цели:
Для недопущения повторных нарушений необходимо анализировать каждый инцидент, выявлять причины, накапливать статистику, вносить изменения в существующую практику. Заранее все предусмотреть невозможно, поэтому следует запланировать создание рабочей группы (или нескольких групп), анализирующей инциденты и, одновременно, отслеживающей новую информацию в области доступности, рассматривающей новые угрозы, принимающей краткосрочные меры и вырабатывающей рекомендации по корректировке программы повышения доступности с целью принятия долгосрочных мер.
При планировании реакции на инциденты важно руководствоваться соображениями унификации и автоматизации. Например, если в число рассматриваемых рисков входит угроза террористического акта, необходимо или снабдить секретарей, принимающих телефонные звонки, формами для фиксации информации о звонящем (содержание разговора, голос, звуковой фон, психологическое состояние и т.п.), или, что предпочтительнее, обеспечить возможность записи телефонного разговора на магнитофон с целью последующего анализа разговора специалистами (что, впрочем, не отменяет необходимости в аннотации стандартной формы к сделанной записи).
Необходимо стандартизовать процедуру доклада об инциденте и структуру сообщаемой информации. Координаты лиц, которых следует известить об инциденте, должны быть всегда доступны. На случай отсутствия реакции со стороны должностных лиц определенного уровня, должна существовать процедура эскалации докладов, то есть передачи информации на более высокий уровень.
Ни одна организация не застрахована от серьезных аварий, вызванных естественными причинами, злым умыслом, халатностью или некомпетентностью. Планирование восстановительных работ, являясь частным случаем проработки реакции на нарушения доступности, позволяет подготовиться к авариям, уменьшить ущерб от них и сохранить способность к функционированию критически важных сервисов.
Процесс планирования восстановительных работ можно подразделить на следующие этапы:
И при подготовке мер реагирования на нарушения доступности, и при планировании восстановительных работ необходимо проводить измерения, показывающие, за какое время то или иное действие может быть выполнено на практике. Располагая временной метрикой элементарных действий, можно оценивать продолжительность более сложных мероприятий. Если не удается уложиться в отведенное время, нужно или повысить подготовку персонала, или пересмотреть накладываемые ограничения, или разработать альтернативные, возможно, более дорогостоящие процедуры.
Неотъемлемой частью восстановительных работ является оценка нанесенного ущерба. Процессы оценки ущерба и принятия решения о последующих действиях следует в максимально возможной степени унифицировать. С помощью карты ИС (компьютерной или печатной) ответственный оценивает состояние критических ресурсов по трехбалльной шкале — не пострадал, поврежден, разрушен. Как составная часть оценки, относящейся к компьютерным ресурсам, может использоваться отчет центра управления ИС.
|
|
|
|
| Административные меры повышения доступности | Содержание | Программно-технические меры |
| Copyright ╘ 1993-2000, Jet Infosystems |