У профессионалов безопасности существует свой критерий выбора системы защиты: защита должна делать экономически невыгодной проникновение в систему. Например, у меня дома стоит беспроводная точка доступа Wi-Fi и выделенный канал доступа в Интернет. Я, как параноик в области безопасности, защитил его с помощью встроенного механизма WPA. Взломать это код, наверно, смогут специалисты из ФСБ за несколько месяцев работы сверхмощных компьютеров. Я думаю, что вряд ли эту организацию заинтересует перспектива потратить столько ресурсов, чтобы «украсть» мой предоплаченный трафик стоимостью 25 долларов в месяц. А никаких секретных данных у меня нет — разве что текст этой книги, но наш книжный рынок пока не дошел до такой прибыльности, чтобы воровать книгу прямо с компьютера автора.
Правило «стоимости и затрат» хорошо для крупных компаний и параноиков вроде меня. Для всех остальных более полезно другое правило которое можно легко запомнить и объяснить с помощью старого анекдота:
Два геолога наткнулись в тайге на медведя, а ружья они забыли в лагере. Один геолог бросился бежать. Второй побежал за ним и кричит:
— Это бессмысленно. Медведь легко догоняет лошадь. Тебе не удастся его обогнать!
— А мне это и не нужно. Мне достаточно бежать быстрее тебя!
То есть если вы защитите себя хотя бы минимально, то большая часть охотников за чужими секретами отправится искать более простые цели.
Управляемость. Мы уже говорили о стоимости владения системой. Понятие управляемости очень близко к этой теме. Информационная система не должна отнимать слишком много ресурсов на свое обслуживание. В небольших и средних организациях обычно пренебрегают эти фактором, считая, что он проявляется только при сотнях и тысячах пользователей, но это не всегда правильно. Особенно велики могут быть скрытые потери. Слишком часто пользователи, не привыкшие к нормальному сервисному обслуживанию, могут попытаться решить проблему самостоятельно или обратиться к соседу с просьбой помочь. Я не раз наблюдал ситуацию, когда топ-менеджер с зарплатой не в одну тысячу долларов и приносящий компании серьезные сделки, пытается настроить принтер или разобраться с компьютером своего сотрудника. На фоне этих расходов содержание специалистов по поддержке пользователей или покупка программного обеспечения высокого качества и серьезных поставщиков кажется чистой экономией.
Опора на стандарты. Опора на стандарты. Опора на стандарты. Уж сколько раз твердили миру… Мы живем в эпоху перемен. Перемен столько, что единственная постоянная вещь сегодня — это твердая уверенность в том, что завтра перемены будут продолжаться. Информационные технологии меняются еще быстрее, чем окружающий мир, — им ведь нужно не просто поменяться, а попробовать несколько вариантов и наконец выбрать тот, который наилучшим образом соответствует переменам в реальном мире бизнеса и отношений. Каким образом я могу быть уверен, что все деньги, которые я вложил в ИТ не пропадут и я смогу хоть как-то использовать мои наработки в будущем?
Единственный метод, который может с определенной степенью вероятности гарантировать такую «совместимость с будущим», это опора на стандарты. Если ваша система использует сегодняшние стандарты информационных технологий, то вероятность ее интеграции и применения в будущем очень серьезно возрастает. Если вы используете систему с закрытым форматом данных, с частными протоколами обмена и другими нестандартными интерфейсами, то, скорее всего, вы окажетесь в сложной ситуации в достаточно обозримое время.
Рассмотрев базовые принципы построения информационных систем, можно перейти к основам внедрения информационных систем. Как ни странно, но мир информационных технологий достаточно «стандартизирован» — очень сложно найти ситуации, где не годится одна из небольшого количества стандартных методик. В свое время я объехал немало заказчиков, планируя проекты по внедрению СУБД. И каждый заказчик объяснял мне, что именно его организация и ее структура являются уникальными: «Мол, Клавдия Петровна не подчиняется Сергею Михайловичу, хотя это было бы логично. А вот этот филиал работает непосредственно с поставщиком, а не через центральный офис». Я внимательно выслушивал эти истории, а потом спрашивал, какая все-таки организация отношений у них в компании — матричная или иерархическая Дело в том, что на таком уровне абстракции, как построение иерархии СУБД, меня совершенно не волновали особенности отношений в компании — только связи между различными подразделениями и направление передачи данных. А вся сложность таких отношений была в первую очередь связана с проблемами в управлении компанией, а не с технической реализацией этих отношений: данным совершенно безразличны родственные связи начальника департамента. Более того, за все время работы я не встречал компаний, которые не укладывались бы в иерархическую схему управления с небольшими модификациями. Невольно вспоминаешь «Трудно быть богом» Стругацких: