Записки автоматизатора. Профессиональная исповедь
Шрифт:
Я начал именно с примера, чтобы не пугать читателя высоконаучными словами. Но в приведенном случае были нарушены принципы проектирования баз данных, описанные в классических работах 1970-х годов. Таблица базы «Складские карточки» не находится в третьей нормальной форме. Про это уже столько понаписано, что мне и добавить нечего. Появление новых СУБД и новых способов поддержания зависимостей в базе данных совершенно ничего не меняет: грабли продолжают работать даже при использовании триггеров и джобов (заданий, запускаемых автоматически в определенные моменты суток или через определенные временные интервалы).
Все попытки поддерживать целостность
Кстати, неумелое использование перечисленных инструментов, на мой взгляд, приводит к последствиям более страшным, чем их полное неиспользование.
Вы задумывались, что произойдет, если джоб, который стартует каждые 15 минут, в среднем работает два часа? А что будет, если выполнение триггера займет две минуты? В обоих случаях последствия могут быть разнообразными, но всегда неприятными и, что еще хуже, непредсказуемыми.
Не знаю, влияет ли на это постоянное увеличение быстродействия компьютеров, но почему-то очень-очень многие программисты предполагают, что код, который они написали, будет выполнен мгновенно. Последовательность этих «мгновений», воплощенная в информационной системе, заставляет пользователей минутами дожидаться хоть какой-нибудь реакции на нажатие кнопок. Но хуже другое: в конфликт начинают вступать процессы, о взаимодействии которых никто не подумал, потому что все мыслили эти процессы мгновенными.
Если в системе появляются элементы документооборота, то документы (проекты договоров, заявки на материальное снабжение, предложения по изменению справочников и т. п.), созданные или исправленные одним пользователем, необходимо отправлять на согласование другим пользователям. Стадию прохождения документа по цепочке обычно называют статусом документа. Цепочки таких согласований бывают достаточно длинными. Естественно, встает вопрос, кто должен увидеть и кто обработать документ, находящийся в соответствующем статусе.
Поскольку в учетной системе этот вопрос не самый главный, разработчик иногда решает его с наскока и наиболее простым способом: адресация документов и права доступа к ним настраиваются по логинам пользователей, то есть в цепочку согласований включаются физические лица.
В результате все проблемы заменяемости сотрудников и изменения штатного расписания оказываются практически неразрешимыми: все перенастройки приходится выполнять вручную. Если этого не делать, то документ, отправленный на согласование по подчиненности, окажется у начальника, уволенного месяц назад, а не у того, кто стал исполнять его обязанности.
Феодализм все-таки давно пройденная формация. И если начальник управления уволился, то все отделы, входящие в управление, станут подчиняться новому начальнику, которого назначат, а не ходить в гости к старому, чтобы решать производственные вопросы. Поэтому при настройке цепочек согласования и утверждения документов привязываться нужно к функциональным ролям сотрудников или к должностям в штатном расписании, а не к физическим лицам.
Традиционный ляп разработки связан со способом назначения прав доступа на просмотр, создание и изменение объектов информационной системы. Обычно этот вопрос остается на периферии круга решаемых
В результате в системе доступа образуются зияющие дыры. Наиболее традиционная дыра состоит в предположении, что вновь заводимому в систему пользователю позволено все, пока ограничения доступа не будут прописаны в явном виде. То есть в системе «разрешено все, что не запрещено». Но использование этого демократического принципа по отношению к информационным системам категорически противопоказано.
При заведении нового пользователя в систему его права должны быть пусты. Только после задания роли у пользователя появляются права в соответствии с этой ролью.
Права, контрольные механизмы и прочие средства информационной безопасности (ИБ) – отдельная история при разработке и внедрении всех систем. Мало того что требования ИБ не принято закладывать при разработке систем (иначе откуда тогда столько систем, хранящих пароль на доступ к базе данных в виде незашифрованного текстового файла?), так даже и те средства, которые в системах все-таки реализованы, при внедрении систем не настраиваются почти никогда (наверное, на это уже не хватает сил после борьбы с функциональностью). Например, из десятка компаний, в которых мне пришлось побывать за год, на половине администраторскими правами в приложении были наделены все пользователи, и практически на всех пользователей в базе данных присутствовали учетные записи с паролями «по умолчанию». И если настраивать межсетевые экраны уже многие научились, то добыча любой информации изнутри локальной сети – до сих пор задача, с которой может справиться любой, кто умеет давить на кнопки.
При этом компании достаточно серьезно говорят о конфиденциальности… Вон она, эта конфиденциальность, – висит в открытом доступе. – Д. К.
Права по разным ролям у одного пользователя должны объединяться, а не интерферировать способом, неизвестным даже самому разработчику. А это тоже бывает достаточно часто
Смежный вопрос, тоже связанный с защищенностью системы, – это протоколирование действий пользователя. Любых действий и любого пользователя. Почему-то разработчик, если его на это сподвигнуть, еще предусматривает фиксацию изменений, влияющих на финансовую отчетность (накладных, платежных поручений и кассовых ордеров), но традиционно плюет на протоколирование изменений сопутствующих справочников и, что еще страшнее, на протоколирование действий администратора системы.
А ведь с помощью таких дырок можно безнаказанно ломать и финансовые документы. Если некто хочет ликвидировать накладную о выдаче товара себе, любимому, или своему любимому контрагенту, можно не трогать саму накладную, а удалить контрагента этой накладной или заменить его на другого. То есть «всего-навсего» изменить справочник контрагентов. При отсутствии протоколирования действий администратора системы все можно провернуть еще проще: некто прописывает логин нового пользователя системы с правами изменять накладные, входит под этим логином в систему, удаляет накладную, потом снова заходит с правами администратора и удаляет «засвеченный» логин.