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

Пример различий построение обычных систем, которые ориентируются на текущую информацию, и финансовых систем.

Создается система финансового учета и аудита. Система, что называется, все в одном. Система разрабатывается, принимается заказчиком, развивается и дорабатывается. Через пару лет заказчик придумывает разделить весь бизнес процесс на две обособленные составляющие, а именно: финансовая служба делится на две части: финансовую и бухгалтерию. Под это дело планируется разделение систем: заказчик хочет чтобы старая система осталась, но некоторый функционал (связанный с бухгалтерской деятельностью) полностью проходил в 1С-Бухгалтерии. И тут сразу же встает вопрос интеграции двух систем. 1С-Бухгалтерия — замечательная финансовая система, вернее даже не 1С-Бухгалтерия, а весь фреймворк. Я даже не буду говорить про существенные проблемы 1С: часть встроенного функционала настолько “вшита” что изменить ее без последствий в будущем не получится; очень сложно интегрировать хоть один справочник из внешней базы. Скажу только что “на лету” подгружать в нее все изменения из основной системы — довольно нетривиальная задача. Но вернемся к нашей системе и зададимся вот каким вопросом: коль скоро у нас теперь не одна система, а целых две (три, четыре, пять,..) то что делать с сущностями, которые становятся общими для этих систем. Мы даже можем опустить те сущности создание, редактирование и удаление которых разрешено только в одной из систем (тут бизнес процесс можно расписать даже на уровне баз данных). А вот что делать, скажем, с общими для обеих систем справочниками? Ведь пользователи — это такие люди, которых хлебом не корми — дай только задвоить какую-нибудь информацию. Результаты этого могут быть если не катастрофическими, то отберут довольно много человеко-часов, которые потребуются на решение этих, казалось бы, маленьких проблем. А еще окажется что выяснилось это в конце декабря, когда начали собирать отчетность за год, а данные, скажем, по договорам расползаются. Пользователи же, отвечающие за эти данные, конечно же не помнят по какой причине несколько месяцев назад они сделали именно то что сделали. Логика product owner’а обычно сводится к тому что “это проблема системы, вы за нее отвечаете — вы и решайте проблему”, забывая что проблема может быть не столько в системе, сколько в данных. Всего бы этого не случилось при одном условии — архитектура системы и регламент взаимодействия были бы продуманы с самого начала.

Здесь и далее я хотел бы рассказать о тех трудностях, с которыми наша команда столкнулась. Возможно если бы несколько лет назад мне на глаза попался подобный материал, мы бы избежали многих проблем, которые отобрали (и продолжают отбирать) у нас кучу времени. Мне бы хватило даже простого упоминания что такая-то проблема может возникнуть потому-то и потому-то. Сейчас я сам готов рассказать о нескольких подобных. Вдобавок я постараюсь изложить те пути решения, которые мы обсуждали и которые в итоге приняли. Итак, начнем.

Алгоритм авторизации и планирование архитектуры системы прав доступа на этапе проектирования

Очевидно что все нюансы, связанные с реализацией бизнес-процесса, не учесть никогда, но подумать над ними стоит.

1. Соединение с базой данных.

Самый простой и незамысловатый путь, который избирают многие — сделать конструкцию вида:

экземпляр_класса_работы_с_БД.метод_соединения(имя_пользователя, пароль)

где имя_пользователя и пароль — данные, которые пользователь вводит при запуске клиента.

Уже здесь видна одна большая проблема связанная с безопасностью. Так уж получилось что у нас есть опыт сопровождения системы в организации, в которой мы обслуживаем систему, а конкуренты — локальную сеть и машины пользователей. Мы никогда бы не могли подумать, что придется защищать данные передаваемые между нашими пользователями и нашими серверами внутри одной организации, территориально расположенной в одном здании, но оказывается и такое бывает.

Что может сделать злоумышленник, у которого есть доступ к машине пользователя? Он может сделать одну простую вещь — скинуть дамп памяти на носитель и уже в спокойной обстановке выдрать имя пользователя и пароль.

Поэтому правило №1: конфиденциальные данные (а именно те данные, на доступ к которым есть хоть какие-то ограничения) должны храниться за пределами сервера только в тот период времени, когда без них невозможно функционирование системы. В данном примере необходимо после установления соединения с базой уничтожить (либо заполнить мусором) все переменные, содержание имя пользователя и пароль.

Теперь ставим задачу: как проверить что пользователь — это пользователь и что его компьютер — это его компьютер?

Стандартными инструментами MS SQL (для примера) данную проблему не решить. Более того, от нее надо отказываться (как минимум из-за доменной авторизации, которая, во-первых, убивает всю политику безопасности в примере выше, а во-вторых, не дает никакой гибкости, о которой пойдет речь дальше).

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

Итак, авторизация.

Самое простое (что не заняло много времени) и действенное что мы придумали — это следующая схема:

o Пользователь вводит имя_пользователя и пароль
o Пароль преобразуется по хитрому алгоритму, используя все возможные данные о железе локальной машины
o Создается подключение с введенным именем пользователя и полученным паролем.

Таким образом мы прикручиваем данные конкретной машины (у злоумышленника не получится воссоздать их все, как минимум уникальный номер процессора и сетевой карты). С другой стороны, даже имея в своем распоряжении компьютер необходимо знать еще и пароль пользователя.
Конечно мы понимаем что непробиваемых систем не бывает, но наш хитрый алгоритм заставит попотеть тех, кто попытается дизассемблировать код, а значит даст нам время.
Но самое главное: даже зная пароль пользователя и имея доступ к компьютеру — не получится совершить что-то действительно страшное: помешает политика прав доступа.

2. Политика прав доступа

Мы долго искали золотую середину между инструментами, которые предлагает нам база данных (MS SQL) и тем что мы надстраиваем. В конце концов однозначно было решено, что той детализации, которая предоставляется БД (отдельные права на каждую таблицу, представление и хранимку), не достаточно — вся логика бизнес-процесса существенно сложнее.
В конце концов мы реализовали следующую схему двухуровневой системы безопасности со стороны клиентских приложений:

o При запуске приложения автоматически создается соединение с БД
o Пользователь вводит логин, пароль, которые передаются на сервер в зашифрованном виде с кодом операции, которую пользователь хочет произвести (в данном случае подключение)
o Дальше собственная система прав возвращает результат, которые говорит о допустимости данного действия (после получения кода результата программа “понимает” вернутся ей данные в следующем запросе на получение данных).

Дальше эта схема используется везде, что позволяет полностью переложить бизнес-процесс с учетом самых изощренных прав.
Таким образом инструментарий БД дает нам пространство для маневров в части работы разных систем с БД, а детальная логика прописывается на уровне приложения и базы данных: хранимая процедура никогда не вернет данные, если функция проверяющая допустимость действий пользователя вернет код отказа.

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

Идеология и проблемы разработки финансовых систем. Часть 1