Читаем Записки автоматизатора. Профессиональная исповедь полностью

Права, контрольные механизмы и прочие средства информационной безопасности (ИБ) – отдельная история при разработке и внедрении всех систем. Мало того что требования ИБ не принято закладывать при разработке систем (иначе откуда тогда столько систем, хранящих пароль на доступ к базе данных в виде незашифрованного текстового файла?), так даже и те средства, которые в системах все-таки реализованы, при внедрении систем не настраиваются почти никогда (наверное, на это уже не хватает сил после борьбы с функциональностью). Например, из десятка компаний, в которых мне пришлось побывать за год, на половине администраторскими правами в приложении были наделены все пользователи, и практически на всех пользователей в базе данных присутствовали учетные записи с паролями «по умолчанию». И если настраивать межсетевые экраны уже многие научились, то добыча любой информации изнутри локальной сети – до сих пор задача, с которой может справиться любой, кто умеет давить на кнопки.

При этом компании достаточно серьезно говорят о конфиденциальности… Вон она, эта конфиденциальность, – висит в открытом доступе. – Д. К.

Права по разным ролям у одного пользователя должны объединяться, а не интерферировать способом, неизвестным даже самому разработчику. А это тоже бывает достаточно часто

Смежный вопрос, тоже связанный с защищенностью системы, – это протоколирование действий пользователя. Любых действий и любого пользователя. Почему-то разработчик, если его на это сподвигнуть, еще предусматривает фиксацию изменений, влияющих на финансовую отчетность (накладных, платежных поручений и кассовых ордеров), но традиционно плюет на протоколирование изменений сопутствующих справочников и, что еще страшнее, на протоколирование действий администратора системы.

А ведь с помощью таких дырок можно безнаказанно ломать и финансовые документы. Если некто хочет ликвидировать накладную о выдаче товара себе, любимому, или своему любимому контрагенту, можно не трогать саму накладную, а удалить контрагента этой накладной или заменить его на другого. То есть «всего-навсего» изменить справочник контрагентов. При отсутствии протоколирования действий администратора системы все можно провернуть еще проще: некто прописывает логин нового пользователя системы с правами изменять накладные, входит под этим логином в систему, удаляет накладную, потом снова заходит с правами администратора и удаляет «засвеченный» логин.

Грабли модные: xml внутри базы данных

При каждом скачке в развитии вычислительной техники у разработчиков информационных систем возникает эйфория, связанная со снятием ограничений на объемы хранимой информации и скорости ее переработки. Но всякий раз выясняется, что, даже вооружившись современными высокопроизводительными серверами, все можно спроектировать настолько плохо, что работать это не будет. Или будет работать годами.

Перейти на страницу:
Нет соединения с сервером, попробуйте зайти чуть позже