Аудит информационной системы. Краткое руководство
Для начала: а зачем вообще проводят аудит информационной системы, особенно когда она внедрена и успешно функционирует? Ответ вроде бы на поверхности, но начинаешь копать глубже и получаешь что-то типа «так надо» или «бизнес-необходимость». Давайте попробуем разобраться, в каких случаях аудит ИС действительно оправдан. На практике мне встречалось несколько ситуаций.
Когда это надо?
Во-первых, когда система подпадала под аудит процессов. Существуют некие бизнес-процессы, система, которая их обслуживает. И присутствует необходимость трансформации процессов, но нет уверенности в том, что система сможет обеспечить их поддержку. Выход один: аудит, в ходе которого будет проверена текущая ИС, и возможность покрытия ей перспективной карты процессов. Тут, правда, возможно множество вариантов: от аудита документации до разворачивания демостенда и различного рода тестирования.
Во-вторых, это ситуация, когда требуется определить некие потребительские или технические характеристики ИС. В таком случае «заходим» не от процессов, а от системы. Определяем метрики, описываем их, снимаем, анализируем — все это тоже аудит, но... с «другой стороны».
В-третьих, ситуация нестабильной работы ИС. Здесь нередко начинают с микромероприятий, то есть с попытки умозрительно вычислить, «где болит» и как «вылечить». Иногда это помогают, иногда — нет.
Следующий по степени распространенности случай — аудит информационной безопасности ИС. Тут причины могут быть самые разные, одна из наиболее распространенных — взлом и/или угрозы компрометации данных в ИС. Этот тип аудита достаточно сложный и специфический. Но, тем не менее, его проводят.
Как готовиться?
Подготовка аудита, как это ни банально, начинается с целеполагания. Я встречал две противоположные ситуации. Первая — когда цели определены и из них следуют вполне определенные задачи и мероприятия. Вторая — когда есть желание провести аудит. Но нет ни целей, ни желания их ставить... Второй случай, кстати, более характерен для варианта «стихийного менеджмента», который сам по себе достаточно сложное явление.
Когда определены цели, имеет смысл составить план проведения аудита. План нужен для того, чтобы, во-первых, не упустить что-то важное, а во-вторых — чтобы спланировать ресурсы и определить контрольные точки, в которых будет получен некий результат.
Следующие шаги в значительной степени зависят от конкретной организации. Например, зачастую аудит ИС сопровождается определенным набором приказов, которые готовятся на предварительном этапе. Иногда аудит представляют как микропроект — в этом случае собирается команда проекта, создается устав (если создается) и т. д.
Как бы то ни было, на выходе подготовительного этапа важно иметь ответ на два важных вопроса: что мы хотим получить в итоге аудита и чьими силами он будет проводиться.
Аудит: начинаем и выигрываем
Собственно, сам аудит проводится в несколько стадий. Для начала, как правило, собирается общая информация об аудируемой ИС. Целевое назначение, количество пользователей, какая имеется в наличии документация, режим поддержки и в чьей зоне ответственности поддержка — все это собирают и проводят первичный анализ. Затем полученная вводная информация соотносится с имеющимися целями, и наступает собственно сам аудит.
Сразу же хочу предупредить, что я описываю максимально обобщенный случай. В реальности обычно, в зависимости от цели, весь объем аудита «собирается» из нескольких из описанных ниже «кирпичиков». Например, проводится аудит технологий, сопровождений и потенциала развития. Или только аудит ИБ. Вариантов множество, весь вопрос в целях и возможностях.
Начинают аудит с определений технологий, на которых построена система, делается прогноз по их развитию и возможности поддержки. На этом этапе система может аудит запросто не пройти. Скажем, если она написана на Delphi 3 и имеет InterBase в качестве базы данных, то с большой вероятностью она — «кандидат на вылет», поскольку стоимость поддержки такой системы высока, а сопутствующие риски просто зашкаливают. И скорее наличие подобной ИС вызовет удивление, чем желание развивать ее дальше. Правда, встречаются и исключения, когда поддерживать ИС на старых технологиях намного выгоднее, чем приобрести новое решение. Но, повторюсь, такая ситуация обычно является исключением и сознательным узким местом, существование которого имеет очень серьезные основания.
Далее выполняется полная инвентаризация сопровождения. В частности, оценивается эксплуатационная документация, дистрибутивы, исходные коды — то есть на данном этапе рассмотрению подлежат все активы, задействованные в ее поддержке. Здесь же оценивается компания-поставщик и компания-разработчик ИС — существуют ли, есть ли сервисные контракты, что они дают, какова их стоимость. Оценивается и потенциал специалистов — как в компании, из тех, что осуществляют поддержку, так и на рынке, из тех, что при необходимости могут быть привлечены для поддержки. После чего вся информация сводится и опять-таки анализируется. С этого этапа системы обычно «вылетают» гораздо реже, чем с предыдущего, потому что, как правило, самые неприятные моменты всплывают на предыдущем шаге. Хотя, бывает, «вылетают». Я видел, как по итогам аудита в одной компании была проведена замена некой opensource CRM-системы. Потому что, несмотря на современные технологии, на которых она построена, никто не знал, как она работает. И это сильно нервировало как директора, так и собственника. Да, был исходный код, была примерно описанная схема БД... но директора по ИТ смущало то, что фактически система функционировала без поддержки, которую известная компания-производитель для своих opensource продуктов не оказывала принципиально — «только через форум в формате живого общения пользователей». Нет, дефекты, конечно, были и исправлялись силами внутренних разработчиков, но вот стоимость такой внутренней поддержки исчислялась достаточно круглой суммой. Справедливости ради отмечу, что данная ситуация не является общим правилом: зачастую компании приобретают хорошие компетенции в области используемых opensource-продуктов и чувствуют себя прекрасно, до тех пор пока не уходят основные носители знаний. А если еще они и документацию не вели... но это немного другая история, про риски.
Следующий этап аудита связан с инфраструктурой. В частности, оценивают требования к аппаратной и программной части ИС. Я не встречал сам, но слышал о том, что есть еще вполне «бодрые» системы, написанные в 1980-х и работающие под управлением MS-DOS (которые вроде бы ввиду мизерных требований к «железу» и не трогают даже). Несмотря на отсутствие поддержки, пользователи чувствуют себя достаточно уверенно в таких системах, за счет накопленного «исторического опыта». Потом, как мне рассказывал знакомый ИТ-директор, в чьем зоопарке живет такой редкий «зверь», она прекрасно виртуализуется, при этом требования к виртуальной машине неприлично низки, а специфика ну очень высока (соответственно, аналогов почти нет, а писать под заказ каждый раз — за рамками бюджета). Так и живут на «минном поле». Там, кстати, была проблема заставить среду виртуализации эмулировать старый процессор и пресловутые 640 кбит основной и сколько-то там расширенной памяти... Но далеко не каждая ИС способна так «легко отделаться». Обычно на этапе аудита ИС в части инфраструктуры выявляют разного рода «северные аномалии», и на основе полученной информации, в числе прочих, принимают решение о том, что делать дальше с ИС — перевести на другую платформу, не трогать или рекомендовать к замене. И стоимость поддержки специфического «железа» может оказаться очень высокой, особенно если такого «железа» в компании больше нет и так или иначе приходится обеспечивать компетенции по его поддержке (самостоятельно или привлекая подрядчика).
Аудит: углубляемся
Следующий интересный «кирпичик» — аудит ИБ-системы. Вообще, тема ИБ по отношению к ИС поистине неисчерпаема, поэтому остановлюсь лишь на основных моментах. Обычно аудит ИС проводится в двух случаях: когда есть реальная угроза вторжения и когда вторжение уже состоялось. Сказать, что и тот и другой аудит технически сложные и дорогие мероприятия, значит не сказать почти ничего. Потому что подобного рода проверка требует от тех, кто ее выполняет, высокой квалификации, внимательности и очень хорошего владения технологиями как разработки, так и взлома. Подобных профессионалов могут «позволить себе» либо очень большие, либо очень специализированные компании. Поэтому, собственно, и стоимость приглашенных спецов если не заоблачная, то где-то в районе неба находится точно. Зато по итогам такого аудита вам будет предоставлен список «дыр» и, возможно, рекомендации по их устранению («возможно» — потому что очень зависит от контракта).
Дальнейший шаг — пользовательский аудит, или взгляд на систему глазами пользователя. И если все предыдущие шаги выполнялись сотрудниками с ИТ-компетенциями, то данный этап в первую очередь фокусируется именно на пользователях. Проводится исследование степени удовлетворенности пользователей системой, собираются пожелания по улучшению, информация о негативных сценариях, вариантах применения, требования к системе и пользовательскому видению развития. По итогам составляется карта пользовательских симпатий к системе и предложения по ее модернизации. Кстати, нередко данный этап незаслуженно исключают из аудита, хотя работаем мы в конечном итоге для блага пользователя. И его мнение относительно ИС надо хотя бы услышать, а еще лучше — учесть. Ведь по итогам такого «пользовательского взгляда» можно сделать достаточно глубокие выводы о роли и месте ИС и векторе ее развития.
Очередной этап — оценка потенциала развития. Но с позиции не технологий, а соответствия бизнес-задаче. Фактически здесь решается, что дешевле: развивать старое решение или приобрести новое, с прицелом на автоматизацию процессов. На этом этапе есть правило: думать как в шахматах, на два шага вперед. Потому что сделанные ошибки впоследствии могут оказаться очень больными с точки зрения бюджета. Например, система может удовлетворять процессам, которые лежат в ближней зоне развития, но быть категорически непригодной в перспективе, в силу тех или иных ограничений. В таком случае лучше и правильнее признать, что аудит системой не пройден и действовать, исходя из этой реальности.
Отмечу, что порядок этапов может быть любым, произвольным, удобным. Ну и как уже говорил выше, совершенно не обязательно проводить полный аудит ИС. Все зависит от целей: важно не упустить ничего, что ложится в канву цели. Главное — понимать, что и зачем делаем и что хотим получить на выходе.
Что делать с аудитом
Последний тонкий момент, связанный с аудитом, — правильная интерпретация его результатов. Предположим, провели аудит ИС, цель которого — определить потенциал развития данной ИС для некоего набора бизнес-процессов. Есть определенные итоги. Как их интерпретировать? Как оценить последствия, перспективы и риски каждого из возможных вариантов развития событий по итогам аудита? Ответы на эти вопросы опять-таки возвращают нас на самый первый, подготовительный этап. Там по-хорошему следовало описать, какие именно результаты как мы можем интерпретировать. Как вариант, это должен быть набор метрик, которые проектируются до аудита и анализируются после. В этом случае задача интерпретации результатов аудита становится несколько проще, но намного усложняется задача подготовительного этапа: там необходимо не просто подготовить аудит, но и спроектировать полный и непротиворечивый набор метрик, с граничными условиями... Это не то чтобы невозможно, но труда требует немалого, а также внимания и глубокого понимания предметной области.
Опубликовано 21.04.2017