Список глав рассказа:
Шеркало 07.02 Клиент-банк: Банк, задачи, источники информации
======== Эта глава номер 07.03 ========
Шеркало 07.04 Клиент-банк: бета-тесты, проблемы с почтой, троянский конь, ABSA
- Эй, Шеркало, ты здесь?
- Ой, Ёж, и года не прошло, а ты уже снова объявился?
- А ты не выступало бы! А то ещё реже появляться буду. На чём мы в прошлый раз с тобой прервались?
- Кажется на том, что местный томский ЦБ внедрял в вашем новеньком филиале банка свою систему электронных платежей в конце 1995 года. Я правда не полностью уверено, что этот рассказ о ЦБшной системе совсем уж близко касается заявленной тобой темы, но кажется, нить твоих мыслей уже с третьей попытки начинаю чуть-чуть улавливать.
- Ну вот и отлично, Шеркало. Нить моих мыслей уловить совсем не трудно, она шита грубыми стежками по поверхности. Значит вернёмся к ЦБ.
Модульная архитектура
Я прекрасно понимал, что система электронных платежей местного ЦБ едва ли не единственная в принципе доступная мне для изучения (ну ВРУ же! любое изучение (в технической части) явно ЗАПРЕЩАЛОСЬ со стороны ЦБ!). Ну ладно, скажем, доступная для наблюдения. И это уже много! Других-то работоспособных подобных систем кажется пока нет вообще в природе. И я наблюдал, наблюдал очень внимательно. Ловил каждый малейший технический сбой при мне исправлявшийся, спрашивал о мотивах каждого решения. Но нужно помнить, всё, что я видел - это были всего лишь рабочие места системы Клиент-банк на КЛИЕНТСКОЙ территории. Скажем так, это был "фронтенд", хотя я тогда такого умного слова еще не знал. Но начинал думать с точки зрения фронта, полагая, что со стороны банка уж какое-нибудь подходящее решение потом само собой отыщется.
Так вот, обобщение всех моих наблюдений приводило к чёткой картине трёхмодульной архитектуры программы. Все три модуля были как бы явно независимы друг от друга.
1. Нужен был модуль обмена данными между клиентом и банком. При этом почти единственный доступный в тот момент канал связи - обычная городская телефонная линия по паре медных проводочков. Никаких интернетов тогда ещё в реальном доступе не было!
2. Нужен был модуль относительно стойкой криптографии - нужна ЭЦП, чтобы подтвердить ответственность отправителя за отправляемый документ. Нужно было шифрование, чтобы никто потом не жаловался, что его секретные коммерческие данные открытым текстом гуляют по всему миру. Никакие паллиативы, вроде простого ввода пароля, тут точно не подходили.
3. Нужна была некая специальная офисная программа, по возможности хотя бы с псевдо-оконным интерфейсом (Windows даже версии 3.0 тогда была далеко не на каждом бухгалтерском компьютере, руководители предприятий часто старались экономить на бухгалтерии (им и такое сойдёт!) и выделяли под Клиент-банк заведомо устаревшие компьютеры, так что приходилось сознательно ориентироваться исключительно на MS-DOS интерфейсы) с псевдографическими менюшками, окошечками, формочками ввода, возможностью хранения истории документооборота и с печатью простейших отчётов. Ну и логично, что эта программа, имеющая внятный интерфейс пользователя, должна служить как бы базой, центральной основой всей системы, подключая к себе остальные два пункта - криптографию и транспорт.
То, что все три пункта технически друг от друга независимы, я понял сразу. Посмотрел, как они реализованы в ЦБшной программе, которую я помогал у нас внедрять.
Начну с модуля 3 - основная программа, интерфейс пользователя. В ЦБшной версии мне эта программа не понравилась крайне. Она была написана самостоятельно местными специалистами ЦБ. Нет, технически она работала, окошки/менюшки пользователям кое-как рисовала. Но всё это было сделано в крайне убогом (но весьма распространённом в начале 1990-х годов) стиле дизайна на чистом языке Си в раннем варианте, без интерфейсных библиотек. В стиле: "Мама, мама, что я буду делать? Мама, мама, как я буду жить? У меня нет тёплого пальтишки, у меня нет мягкого бельишки!" Очень распространённый в то время стиль "экономного" Си-интерфейсного дизайна, но, на мой взгляд, вовсе не образец для подражания.
Однако здесь, по пункту 3 у меня вопросов не было никаких. Я со времени работы в бухгалтерии ККП прекрасно владел FoxPro 2.6 for DOS. Все нужные окошки/менюшки/отчётики я прекрасно мог и сам нарисовать, да ещё и гораздо изящнее ЦБшных дизайнеров. Зря я что ли целые вечера просиживал за компьютерами рядом с ККПшными бухгалтершами, и выверял, чуть ли не с секундомером в руке, насколько им удобно редактировать ту или иную форму ввода платежного документа?! С ведением архива документов, с запуском внешних программ и обменом данными у FoxPro тоже ни малейших проблем не было, скорее наоборот. И реализовать на FoxPro отдельную отчуждаемую для клиентов программу в виде *.exe исполняемого файла - да и это элементарно! И пусть все адепты "чистых" компиляторов, типа Клипер или того же Си промолчат. Для написания базового модуля системы Клиент-Банк, FoxPro в тот момент был на голову впереди любой другой среды разработки по большинству параметров. Правда, чисто псевдографический интерфейс программы FoxPro под MS-DOS к 1996 году начал постепенно устаревать, но именно, что только лишь "начал". В реальности FoxPro for DOS действительно устарел уже только в первую пятилетку 2000-х, а до того запуск псевдографической программы на FoxPro в окошке DOS под Windows, да с мышкой, да с полноценным доступом и в локальную сеть, и к периферийным устройствам, выглядел очень прилично, воспринимался как стандартная норма. Так что, выбранная мной ещё в середине 90-х технология, вполне имела запас прочности на 5 с лишним лет вперёд. Немало по тем временам.
Криптография
Идём дальше. Модуль 2 - криптография.
- Сейчас, Ёж, ты конечно же расскажешь, как ты придумал крутой, непрошибаемый алгоритм шифрования. И, вероятно, успешно внедрил его?!
- Нет, Шеркало, ты совсем не угадало!!! ;))
Тут есть несколько нюансов, Шеркало. Начну с самого бесполезного нюанса. Во-первых, очень простой и очень "сильный" (практически "непрошибаемый, только что бесконечным брут-форсом прошибаемый, но это никому, кроме принципиально бессмертных личностей, абсолютно не интересно) алгоритм шифрования действительно существует. Более того, я о нём даже знал ещё со средней школы. Что говоришь? Не может быть, говоришь?! Да элементарно! Этот алгоритм называется "XOR с одноразовым случайным ключом".
Берём некий текст, кодируем его посимвольно в двоичной кодировке (хоть в UTF-8, это не имеет значения). Затем берём строчку ключа шифрования (в той же кодировке). А потом к каждому очередному символу исходного текста, и соответствующему символу ключа шифрования, применяем побитовую операцию XOR (исключающее ИЛИ). На выходе получается зашифрованный текст. Для расшифровки нужно к зашифрованной строке текста повторно применить операцию XOR с тем же самым ключом - получится исходный текст. Что? Слишком просто? И тем не менее, это один из самых крипто стойких известных шифров, ну так я же сказал, что есть нюансы:
а) длина ключа шифрования НЕ должна быть меньше длины шифруемого текста; б) ключ шифрования должен быть абсолютно случайным набором символов (чистый белый шум), не должно быть никакой принципиальной возможности вычислить некоторые символы ключа, даже точно зная значения каких-то других символов этого ключа или значения ранее использованных ключей; в) любой ключ должен использоваться не более ОДНОГО раза, ключ, которым ранее уже хотя бы раз зашифровали одну строку текста, повторно использован для шифрования другой строки ни в каком случае быть не может.
Вот и вся премудрость, Шеркало. Как видишь, создать абсолютно не ломаемый (кроме чистейшего брут-форса) шифр не слишком-то и сложно. Вот использовать его потом в обычной жизни не совсем удобно (более того, практически и не реально). Но у меня сработал другой нюанс: я учился на математика в Университете. И я, по результатам своего математического образования, был абсолютно точно уверен, что разрабатывать свой собственный "сильный" шифр для платёжной системы - это точно не моё собачье дело! Этим обязаны заниматься профессионалы, а не я. Эту аксиому мне вдалбливали чуть ли не с начала первого курса: никогда не пытайся изобретать собственные велосипеды в области криптографии! Только зря потратишь время, а взломщиков ещё и насмешишь. Значит модуль криптографии нужно искать готовый от профессиональных разработчиков.
Так, а что предлагал нам ЦБ? Как раз именно сторонний готовый модуль криптографии и предлагал. Вообще ЦБ потребовал, чтобы мы выделили под платежи стандартную офисную машинку, класса 486DX, с 4-8 Мб памяти (типовая конфигурация офисного компьютера на тот момент). С установленной MS-DOS и своими средствами для доступа к локальной сети офиса. Если доступа в сеть нет - можно будет таскать платёжные документы с этой машины в сеть и обратно через дискетки, без проблем, при желании. Хоть это и крайне неудобно. Ещё к этой машинке мы подключали обыкновенный офисный модем с возможностью через городские телефонные линии периодически дозваниваться до модемов в ЦБ. А с криптографией ЦБшники на уровне Договора о платежах выдвинули жёсткое требование. Нам были предоставлены координаты единственного местного дилера, который имел право реализовывать в нашем регионе криптографическую продукцию одной столичной фирмы-разработчика, которая была сертифицирована страшными-страшными правительственными криптографами.
Мы должны были самостоятельно, от имени своего банка, без упоминания ЦБ (вероятно наши ЦБшники боялись, что руководство ЦБ может наказать их за неутверждённую на высшем уровне инициативу, поэтому не хотели светиться), оплатить местному дилеру покупку специальной аппаратной системы криптозащиты для офисного компьютера. Название этой системы я уже забыл, если честно. Тем более, что я его видел только один единственный раз в момент оформления той покупки. Больше я ничего никогда про эту систему криптографии не слышал. Название фирмы-разработчика, как и её местного дилера я тоже не помню, по той же самой причине. Ну и кто там "в верхах" тогда занимался сертификацией криптографии, я тоже забыл, вот такая память дырявая. Система криптографии выглядела, как типовая плата расширения стандарта ISA, втыкаемая в материнскую плату компьютера. От неё наружу отходил проводок, который оканчивался ванночкой-читалкой, в которую, при включении машины и при работе с ЭЦП, вставлялся внешний аппаратный ключ, запрессованный в кустарную формочку из эпоксидной смолы. Эта крипто-плата имела на борту собственное расширение системы BIOS основного компьютера. Оно загружалось первым и начинало перехватывать все обращения к жёсткому диску машины. При этом все записываемые на диск сектора данных автоматически шифровались присобаченным к ванночке ключом, а все читаемые с диска сектора автоматически расшифровывались. Так что если, попытаться прочитать этот жёсткий диск без правильной инициализации той платы, читался бы только сплошной мусор.
Кроме шифрования "на лету" жёсткого диска, у платы были и другие функции, например, работа с ЭЦП файлов, ограничение на возможность запуска программ только из "белого списка", который утвердит администратор-настройщик криптографии, и ещё, кажется, много чего. Я пытался получить документацию на плату у местного дилера, но он на все мои вопросы грустно отвечал: "Не в курсе я, понимаете? Я не в курсе! Моё дело с вас деньги получить, а в ответ картонную коробочку передать. А что там внутре у нея, я и понятиев не имею, наше дело маленькое..." Представители фирмы-разработчика отвечали на мои запросы ещё быстрее: "У нашей фирмы с вашим банком никаких договорных отношений НЕТ. Идите отседова лесом как можно дальше, пока мы свою крышу не задействовали!" Впрочем, наших ЦБшников такое отношение совсем не смущало. Они успокаивали меня, что как раз у них-то вся необходимая документация есть, они сами эту хитрую плату подключат, и сами всё как надо настроят. Ну и таки да. В итоге действительно подключили и настроили. Правда далеко НЕ с первой попытки, но ведь настроили же? ;)
Вот, а теперь, пока я окончательно и навсегда не закрыл здесь тему об этой чудесной, рекомендованной ЦБ, криптографической плате, хочу сказать о ней парочку поучительных фактов напоследок:
Факт 1 об упомянутой крипто-плате. Я ещё ни разу не озвучивал здесь её ЦЕНУ. Просто у меня не сохранилось с 1995 года документов о её покупке. Однако точно помню, цена там была в долларах, и она сильно зашкаливала не то за 2000, не то за 3000 долларов. И это всё за голую железку, спаянную на коленке в подвальчике-кооперативе, где обычно телефонные аппараты с китайскими микросхемами АОНов за копейки паяли. И без нормальной документации, и абсолютно без всякой тех.поддержки. И секретные ключи, залитые эпоксидной смолой в формочки для печенья... И не то, чтобы меня так уж сильно покоробила цена за откровенно "наколенную поделку", в конце концов, не из моей же личной зарплаты эту фигню оплачивали? Но "осадочек", как говорится, на душе остался...
Факт 2 об упомянутой крипто-плате. Шеркало, ты будешь смеяться, но я эту жутко секретную плату, очень быстро ВЗЛОМАЛ! В смысле, хакнул. Дело произошло буквально через месяц-другой после успешного внедрения этой системы эл.платежей в нашем филиале, в самом начале 1996 года. Меня почему-то вдруг разобрало любопытство, почему это та самая крипто-плата спокойно, прямо с начальной загрузки, перехватывает вектора прерываний BIOS компьютера, берёт всё управление на себя. Но почему-то она не боится, что какая-то другая плата, сможет ещё раньше перехватить критичные прерывания, и в свою очередь начать контролировать весь процесс загрузки и исполнения программ уже от своего имени? Я некоторое время размышлял над этим парадоксом (если ежу колючка под хвост попадёт, тут уж некуда деваться). В итоге нашёл подходящую плату расширения (вполне легальный сетевой адаптер, кстати, ничего особо хакерского), которая при правильных настройках, перехватывала управление нужным образом. Нашёл подходящий софт, вроде специального дебагера, который позволял мне оставаться невидимым супервайзером для атакуемой крипто-платы. Получил полный свободный доступ к якобы "насмерть" зашифрованному жёсткому диску. Получил возможность в любой момент запускать или останавливать любые программы, мимо всяких "белых списков". И т.д. Полноценный взлом аппаратной криптозащиты! Но в первый и последний раз в своей жизни, я отработал роль "БЕЛОГО этичного хакера". Я честно рассказал об уязвимости начальнику ЦБшных ИТ-специалистов (который приятель моего шефа). Он дико вытаращил глаза, не сразу поверил. Потом очень скупо устно поблагодарил. На этом наш разговор прервался. Я рассчитывал, что получу хоть какую-нибудь, пусть не сказочно большую, но вполне материально ощущаемую благодарность. Ведь мы же оба с ним в банках работаем, одно дело делаем? И я оказал ему далеко не самую копеечную, и не самую рядовую услугу. Но нет. Ничего подобного, "спасибом обойдёшься!" Найденную мной дырень в безопасности через 2-3 недели заткнули, впрочем меня это уже не волновало. А в конце 1996 года ЦБшники начали внедрять полностью новую версию своей системы платежей. И там от той несчастной крипто-платы сразу же отказались. А я "этичным" хакерством больше не развлекался - всё равно никто эту бесплатную помощь не ценит.
- Ну а сейчас, Шеркало, пора вернуться от обзора решения ЦБ к моему заявленному модулю 2 - к криптографии...
- ЧТО?!?! ЁЖ?! Ты тут чёртову кучу строк разглагольствовал о криптографии, что я уже пару раз выспаться успело, а оказывается, это была только вводная часть модуля 2?! Ну ты даёшь!
- Так, Шеркало! А ну-ка замолчало! Во-первых, осталось уже немного. Во-вторых, тебе всё равно придётся слушать дальше. Это мои читатели могут отвлекаться или что-нибудь пропускать. А вот ты - не можешь. ЩЛЗ БК!
- Что такое "щлз бк"?
- Это значит "заткнись и слушай дальше!" Такой сокращённый код при радиообмене радистов-коротковолновиков.
Криптография - действительно сложная тема. Мне понадобилось достаточно много времени и усилий, чтобы хоть как-то сориентироваться. И да, кратко мои выводы можно изложить в двух тезисах. Во-первых, изобретать велосипеды в этой области ни в коем случае нельзя! Во-вторых, то что нам предлагает ЦБ, ни в каком случае приемлемым для нашего Клиент-банка назвать нельзя. Ни по цене, ни по функциональности, ни по качеству. Не говоря уж о крайне сомнительной надёжности, вообще неясно, кто этой фигне сможет техническую поддержку оказывать? А других приличных систем в нашей сибирской глуши и не видать! Что же делать?
Тут мне внезапно повезло. Известный программист-криптограф Philip Zimmermann как раз к середине 1990-х годов довёл до ума и выпустил в честное бесплатное распространение свою потрясающую программу PGP (Pretty Good Privacy). Программа, позволяющая эффективно снабжать любые документы надёжно проверяемой электронной подписью (ЭЦП), предполагающая всё сопутствующее необходимое шифрование, работающая на основе распределённой инфраструктуры открытых ключей, которую поддерживали сами независимые ни друг от друга, ни от властей, обычные, извиняюсь за тавтологию, обыватели... Эта программа произвела реальный фурор среди крипто-специалистов. Едва ли не впервые в истории, спецы из государственных служб слежки и контроля, взвыли, что они в общем случае не способны вскрывать криптографию PGP, если только пользователи работали грамотно и не были перевербованы спецслужбами заранее. И вся эта мощь - совершенно легально бесплатно. И всеми своими ключами каждый управляет самостоятельно, в меру своей личной паранойи. Даже сейчас PGP с некоторыми доработками и исправлениями смотрится очень прилично и рекомендуется в качестве одного из допустимых вариантов для защиты личной или коммерческой переписки. Тогда же это была космическая фантастика в кристально-чистом виде!
Кто мне рекомендовал использовать PGP, я точно вспомнить уже не могу. Сейчас бы о таком продукте орал бы в сети непрерывно каждый первый новостной сайт, хоть как-то касающийся компьютерной тематики. Тогда же никакого единого Интернета не было даже в столицах, а в нашем сибирском захолустье и подавно. Был так называемый "флоппи-нет" - добрые люди делали копию попавшей к ним в руки программы, и делились дискеткой с друзьями. Кажется такой добрый человек нашёлся в ИТ-департаменте нашего ГО. Он хотел организовать безопасный обмен данными между ГО и региональными филиалами по открытым междугородним телефонным линиям. А я, получив свою копию дискетки с дистрибутивом PGP и, немного почитав его документацию, понял, что внезапно вытянул выигрышный лотерейный билет!
Кстати, мне всегда очень грустно писать голый сплошной текст, совсем без картинок. Но и придумать, какие бы картинки в эту часть рассказа вставить, чтобы получилось "по теме", я тоже не могу. Пусть ("на безрыбье и рак...") это для разнообразия будет пара экранов вызова PGP из командной строки DOS, с описанием её основных ключиков командной строки. Ещё кстати, именно эта пара экранов составляла процентов примерно 70 от всей используемой мной тогда документации по программе PGP.
Я сознательно нарушаю правила информационной безопасности
Вот именно, что сознательно. Более того, несмотря на свой относительно небольшой опыт работы в банковской сфере, я не стал о возможности такого нарушения ни с кем советоваться, ни со своим шефом, ни с Андреем, ни с ЦБшными, ни с ГОшными ИТ-специалистами. Принял решение сам, на свой страх. Иначе в тот момент не получалось.
Дело в том, что PGP - действительно выдающаяся по своим крипто-возможностям программа. Вот только рассчитана она на сколь-нибудь опытных ИТ-специалистов. Проблема даже не в том, что доступная мне в 1995 году версия PGP имела типичный для DOS/UNIX текстовый интерфейс командной строки (картинки чуть выше) с несколькими не всегда понятными ключами в этой строке (чего простые пользователи очень не любят). Нет. Позже, уже в нулевых годах, мы использовали более современную версию PGP, которая имела вполне красивый графический интерфейс под Windows. Но для простых "советских" бухгалтерш от того легче не стало. Дело даже не в том, что все ключи/команды PGP ориентировались на английский язык. В конце концов, никто не мешал мне написать на своём любимом FoxPro внятную оболочку-вызывалку, которая бы запрашивала необходимые параметры у пользователя в экранной форме, на понятном русском языке, а уже потом на основании полученных данных автоматически формировала бы правильную командную строку вызова PGP со всеми необходимыми ключиками (более того, для рутинных операций шифрования/ЭЦП, я именно как и поступал, только "молча", совсем без лишних вопросов к пользователю, там и так было понятно, какие ключики в строке нужны).
Но вот для нормальной работы с личными криптографическими ключами, для ведения собственной части распределённой базы ключей, пользователь должен был понимать сами принципы работы интерфейса публичных ключей. Именно понимать, а не просто вызубрить несколько предложений! И весь мой опыт работы с тётками-бухгалтершами говорил о том, что ожидать от них такого понимания принципиально невозможно! Вся логика работы PGP предполагала, что свои пары секретных/публичных ключей каждый пользователь генерирует лично сам. Всю свою базу ключей каждый опять же ведёт лично сам, и к своим секретным ключам никого чужого никогда в жизни не подпускает. Тем самым гарантируется наиважнейшее требование системы - отсутствие компрометации секретного ключа. Так вот это требование строго самостоятельного ведения ключевой базы на стороне пользователя, было в наших условиях того времени совершенно нереалистичным. И я вынужденно принял совершенно идеологически неправильное, но единственно возможное тогда (про жёсткие сроки внедрения системы Клиент-банк, поставленные передо мной шефом, все помнят?) решение - ключи пользователей я буду генерировать лично сам, прямо у себя в банке. Желательно, но не обязательно, при личном присутствии клиента, с пояснениями, что происходит на экране. И буду выдавать клиенту готовую ключевую дискетку, на которой будет лежать в том числе его личный, но уже заранее заведомо скомпрометированный секретный ключ.
Но, во-первых, он скомпрометирован не каким-нибудь там Бармалеем? Он скомпрометирован лично МНОЙ и никем иным. А я же ведь не злой разбойник?! Я же ведь добрый и честный Ёж. Так что "...Штирлиц! В наше время никому верить нельзя! Но мне - можно!" (с) Мюллер. Во-вторых, я чуть позже уже в самом конце 90-х и в начале нулевых имел возможность посмотреть на ранние системы Клиент-банк некоторых других банков. И частенько видел там ту же картину - раздача клиентам заведомо компрометированных секретных ключей, изготовленных на территории банка банковскими же специалистами. Кстати, тот же наш местный ЦБ ещё как минимум в 2000-х годах страдал этим же - генерировал ключи для банков на своей территории, на собственном оборудовании. В-четвёртых, юридическая подстраховка этого формального "беспредела", конечно тоже была. Филиальская юристка готовила шаблон нашего первого Договора с клиентами на Клиент-банк. Про сам договор ничего говорить не буду - не моя работа (сама же она взяла образец в каком-то другом банке). Но технические вопросы я в этом договоре просматривал м редактировал. И проследил, чтобы там был явно выделен очень обтекаемый пункт, что типа "криптографические средства для защиты конфиденциальной информации предоставляет Банк, а Клиент соглашается, что эти средства для исполнения условий Договора достаточны". Вот так и подстраховывались. В те времена и такие формулировки прокатывали нормально.
Последний абзац про PGP, чтобы к ней тут больше не возвращаться. Программа - отличная! Её выбор был на тот момент попаданием точно "в яблочко" с первой же попытки. Простая в использовании (не считая работы с базами ключей, но тут уже других вариантов просто не имелось). Крайне надёжная, стабильная, с отличной грамотной диагностикой ошибок. И клиенты, и мы были ей более чем довольны. Серьёзных нареканий не заявлял никто. Правда, меня несколько раз предупреждали "доброжелатели", что PGP - это самый лакомый кусочек для атаки всего мирового сообщества злых и страшных хакеров, поэтому ей ни в коем случае пользоваться нельзя! Не знаю, ничего серьёзного не заметил. Было несколько случаев (штучные единицы за несколько лет работы), когда в банк приходили явно фальшивые платежи от явных злоумышленников, но подписанные правильной ЭЦП. Каждый раз совместно с клиентом и его ИТшниками немедленно организовывали расследование. Каждый раз по логам и хронологии действий выяснялось одно и то же: не было никакого хакерского взлома ключей PGP, а было злоумышленное проникновение некоего инсайдера предприятия (которого руководитель ранее считал своим доверенным лицом) в оставленный без присмотра компьютер с системой Клиент-банк (со свободным доступом к ключевой дискете). Залетевшие руководители обычно благодарили за успешное "спасение их денег". Претензий к нашей банковской работе в итоге по поводу PGP не было получено ни разу.
Уже в моём следующем банке от использования PGP в системе Клиент-банк пришлось отказаться. И дело тут вовсе не в том, что PGP была технически плоха или ненадёжна. Нет. Просто формируемая ЦБ законодательная база постепенно (ООООЧЕНЬ постепенно!) с начала нулевых годов начинала обрастать законами и подзаконными актами, регламентирующими платёжный электронный документооборот в стране. И в этих законодательных актах требовалось, чтобы вся криптография для платежей была обязательно сертифицирована службами ФАПСИ/ФСБ. Ну и Ежу понятно, что сертифицировать PGP никто у нас в стране не собирался ни при каких условиях. Правда, была ещё одна лазеечка, если не ошибаюсь. Поскольку разработка по-настоящему сертифицированной криптографии откровенно задерживалась на многие годы, ЦБ не совсем гласно, на местных уровнях, выпускал списки "временно" допустимых к использованию "почти" сертифицированных крипто-средств. Но понятно, что и в этих списках PGP тоже не было. Так что дальше я её использовал только для внутриофисной переписки. Вот теперь уже точно - ВСЁ!
- Ура! Наконец-то всё!
- Да, Шеркало, с модулем криптографии всё. Теперь переходим к модулю 1 - транспорту электронных документов между клиентом и банком. И только попробуй мне тут тявкни что-нибудь!
Транспорт - для начала почта Sprint
Как я уже раньше говорил, изначально идея с транспортом документов системы Клиент-банк посредством какой-нибудь типовой электронной почты, мне показалась очень здравой. В самом деле, по электронной почте можно штатно передавать вложенные в письма файлы из почтового ящика одной организации в п/я другой организации. Почта под это вроде бы и заточена. Да, каналы связи пока ограничены городскими телефонными линиями с модемами на оконцовках, но это нормально - модемы и телефоны уже многими тысячами людей опробованы. Где чуть быстрее, где чуть медленнее, но в общем, работают приемлемо. Совершенно очевидное решение, и без всяких изобретений велосипедов!
Дьявол (даже не то, чтобы сам дьявол, а скорее его пока ещё размытая, плохо различимая тень), скрывался, как обычно, в мелких деталях. Для начала, ещё не было ни единой сети для электронной почты, ни единых стандартов. Нет, сеть интернет (точнее, её советский предшественник "Релком"), уже начинала точечно-эпизодически проявляться в столично-научной среде, но использовать её в реальной работе с клиентами банка в нашем регионе в то время (и даже ещё несколько лет спустя) было практически абсолютно невозможно. Да, ещё набирала популярность любительская сеть ФИДО - объединение частных энтузиастов-любителей, обменивавшихся друг с другом информацией через телефонные звонки (большей частью со своих домашних телефонов). На практике с использованием ФИДО тоже вылезли достаточно неприятные проблемы (скорее всего это были мои личные проблемы, но тем не менее, взяли и вылезли), об этом напишу в следующей части. Можно было бы попытаться поднять в филиале банка свою собственную систему электронной почты, на базе уже выпускавшихся типовых решений. Только это на то время было крайне дорого и сложно, требовало организации и обслуживания своего выделенного почтового сервера, я такой вариант даже не рассматривал. Разные варианты развития за наш банковский счёт каких-то мелких и нестандартных внутри-домовых и внутри-подъездных сетей обмена данными, которые тоже активно впаривали рекламировали свои услуги, по понятным причинам тоже не рассматривались.
На фоне всей этой удручающей картины, вариант с обменом электронной почтой через сеть Sprint, которая обслуживалась специалистами известного крупного провайдера (к тому же, с центром в США!), казался вполне приемлемым. Тем более, что этот вариант уже успешно обкатывался ранее в бывшем банке шефа, а у нас в любом случае уже был зарегистрирован п/ящик в этой сети. Так что я не видел никаких причин, чтобы не воспользоваться готовым, работающим решением. Клиентскую программу, для дозвона в сеть Sprint тоже переделывать (и даже хоть чуть-чуть дорабатывать) совсем не требовалось. Да программа эта была готовенькая американская, вся на английском языке, но пользователю туда и не требовалось лезть. Всё что требовалось от пользователя - нажать одну единственную кнопочку для запуска этой программы. Потом она через заранее один раз настроенный мной модем, звонила на заранее указанный городской телефон провайдера Sprint, автоматически предъявляла заранее указанные при настройках логин/пароль, отправляла на сервер все письма, скопившиеся с момента последнего сеанса связи в папке "Исходящие", принимала с сервера все поступающие письма в папку "Входящие" и молча завершала свою работу. Всю работу с письмами в папках "Исходящие" и "Входящие" делала моя "основная" программа на FoxPro. Так что английский язык транспортной части простому пользователю никак не мешал.
Архиватор
Из дополнительных программ наверное нужно ещё вскользь упомянуть внешнюю программу-архиватор, которая должна была уменьшать объём передаваемых через модем файлов, а также, в некоторых случаях, упаковывать в один общий файл-архив несколько разных, но логически связанных файлов. Использование внешнего архиватора было необязательным. Дело в том, что программа PGP перед шифрованием любых файлов принудительно их упаковывала. А после дешифрования, соответственно молча, никого не спрашивая, распаковывала. И делала это PGP даже не столько с целью уменьшить размер шифруемых текстов, сколько потому, что принудительная упаковка исходных файлов перед шифрованием, позволяла заметно снизить риск некоторых видов хакерских атак с попытками взлома шифра. Ну а уменьшение объёма файла, это уже просто полезный побочный эффект.
Тем не менее, использовать отдельную внешнюю программу для упаковки файлов, оказалось во многих случаях и удобно, и привычно. Пример уже привёл - объединение нескольких отдельных файлов в общий архив. Разумеется, никакой речи о том, чтобы писать собственный архиватор, и быть не могло! Я не настолько сумасшедший. Использовались стандартные готовые программы для MS-DOS, с вызовом из командной строки. Изначально использовался один из самых известных и популярных в нашей стране архиваторов ARJ. Для разбавки текста, прилагаю картинку:
Несмотря на то, что ARJ работал вполне стабильно, он постепенно терял свою популярность на российских просторах. Да и его платная природа несколько смущала. В более поздних вариантах систем обмена с клиентами, мы старались использовать более стандартные архиваторы на базе pkzip, вызывающие меньше вопросов как с совместимостью форматов упаковки, так и с внешне видимой лицензионной чистотой.
Других примеров интенсивного использования готовых внешних программ, кроме перечисленных почты, криптографии и архиватора, ну и собственно среды разработки FoxPro, конечно, я даже припомнить не могу. Всё остальное делалось мной самим изнутри программы на FoxPro, благо это - очень мощная и разносторонняя оболочка, а отнюдь не узкоспециализированная СУБД. Например, регулярно приходилось формировать из FoxPro средствами вывода текстовых файлов, временный командный файл *.BAT, выполнять его отдельным сеансом MS-DOS и тут же, получив управление обратно в FoxPro, анализировать оттуда результаты исполнения командного файла. Впрочем, это совершенно тривиально и в особых пояснениях вроде не нуждается.
Первая (нулевая) версия банковской части
Когда некие относительно ясно видимые контуры той программы, которую предполагалось ставить на компьютеры клиентов, начали хоть как-то чуть вырисовываться, возникла острая необходимость её тестировать на практике, в сколько-нибудь правдоподобных реальных условиях обмена платёжными документами. Для тестирования клиентской части системы (фронтенд), требовалась хоть как-нибудь плохонько работающая модель ответной банковской части системы (бэкенд, можно сказать). Слово "нулевая" в подзаголовке - это отсылка к известному анекдоту про программистов:
'...Настоящий программист никогда не скажет девушке при знакомстве: "Ты у меня первая!" Нет, он обязательно скажет: "Ты у меня нулевая!"...'
Так вот и у меня тогда не было ни времени, ни возможности разработать свою первую версию банковской части системы Клиент-банк. Нужно было очень быстро слепить и немедленно испытать нулевую версию, чтобы тестировать совершенно новую систему не самостоятельно (ежу понятно, что я сам о требованиях к Клиент-банку тогда вообще ничего толком не знал), а хотя бы на кошках на нескольких реальных клиентах, готовых немножко поработать подопытными кроликами. Такую "нулевую" версию бэкенда я и слепил на коленке, следя, чтобы она вбирала в себя (для экономии времени на разработку) как можно больше уже готовых деталей из клиентской части.
Всё получалось для начала просто. Электронная почта Sprint у банка и у клиентов вообще ничем не отличалась. Мы использовали одну и ту же программу американской разработки, одинаковым образом, через модем и городской телефон соединявшуюся с сервером Sprint. Ну логин/пароль для каждого п/я у всех были индивидуальные, это очевидно. Ну ещё режим соединения с сервером был различный. Например, клиент мог себе позволить по нескольку месяцев вообще не звонить на сервер, если, например, в отпуске был и платежи делать не собирался. Мы же в банке обязаны были выработать для себя относительно регулярный режим обмена документами с сервером, хотя бы десяток раз в рабочий день, чтобы успеть обработать все поступившие клиентские платежи в срок, без задержек. Этот режим, кстати, тогда соблюдался нами исключительно вручную: "о, обед закончился, значит пора снова в Sprint звонить!" Впрочем, кажется раньше уже говорил, ко времени начала эксплуатации системы Клиент-банк, мне в ИТ-отдел приняли грамотную и исполнительную помощницу. Так что обязанности регулярного ручного дозвона до сервера спокойно делились на двоих.
Ни малейших проблем не было с абсолютно одинаковым использованием архиваторов на банковской и клиентской стороне. Вообще никакой разницы. Практически одинаково настраивалась и работала и для банка и для клиентов также криптография PGP. Разумеется, требовалось следить, чтобы наименования (идентификаторы) ключевых пар для всех участников обмена документами были бы строго уникальными и не пересекались. Ну так это и несложно (даже в ручном режиме), и совершенно очевидно. Ну ещё небольшой нюанс - каждый клиент общается в рамках нашей системы только с одним единственным известным ему корреспондентом - с банком. А вот банк обменивается документами одновременно со многими корреспондентами (клиентами). Поэтому есть небольшие, но простые и очевидные отличия, в технической поддержке кольца публичных ключей клиента и банка (термин "pubring" - официально использовался в документации PGP). Но на практике - всё почти одинаково.
Заметно бОльшие отличия требовались в основной запускаемой в банке программе на FoxPro, по сравнению с аналогичной клиентской частью. Самое главное - потоки документов от клиентов в банк и от банка к клиентам, это абсолютно РАЗНЫЕ потоки. Документы, которые банк ожидает от клиентов, и документы, которые клиенты ожидают от банка, они очень слабо пересекаются по своим типам. Ну максимум на 5% есть пересечение, да и то вряд ли. Соответственно, работающие с документами клиентская и банковская части системы (именно то, что я сам писал на FoxPro) автоматически получаются совсем непохожими друг на друга, делать их похожими просто нет логического смысла. Ну и второе, возможно не менее важное, банковская часть Клиент-банка должна быть как-то интегрирована с основными программными сервисами банка (иначе зачем всю эту ерундистику с электронным документооборотом вообще нужно было затевать?!). Впрочем, на клиентской стороне, это требование тоже справедливо, просто менее остро стоит. В итоге банковскую часть системы на FoxPro мне приходилось почти полностью писать заново с нуля, в отличие от сторонних программ.
Однако, Шеркало уже давно спит и даже не возмущается огрехами моего текста. А размер этого текста постепенно выходит за рамки приличия. Прерву-ка я на этом месте данную часть рассказа. Продолжение предполагается, если сил хватит дописать.
Комментариев нет:
Отправить комментарий