Транзакция (Transaction) - это
Транзакция - это операция перевода денежных средств с одного счёта на другой, а также сделка по купле-продаже финансовых инструментов
Транзакции в экономике, банковские транзакции, транзакции по банковским картам, защита удалённых банковских транзакций, транзакции на рынке Форекс, транзакции в информационных технологиях, свойства транзакций, модели транзакций
Структура публикации
- Транзакция - это, определение
- Транзакции в экономике
- Банковские транзакции
- Виды транзакций
- Онлайн транзакция
- Оффлайн транзакция
- Проведение транзакции
- Транзакции по банковским картам
- Защита удалённых банковских транзакций
- Банковские транзакции в сфере электронной комерции
- Безопасность удалённых банковских транзакций
- Методы защиты удалённых банковских транзакий
- Транзакции на рынке Форекс
- Транзакции в информационных технологиях
- Свойства транзакций
- Модели транзакций
- Плоские транзакции
- Модель вложенных транзакций
- Модель транзакции Хроники
- Модель многоуровневых транзакций
- Модели рабочих потоков
- Классификация систем обработки транзакций
- Обработка транзакций
- Методология транзакций
- Откат транзакции
- Прогон транзакции
- Взаимная блокировка транзакций
- Внедрение транзакций
- Транзакция в психологии
- Цели транзактного анализа
- Техники транзактного анализа
- Источники и ссылки
Транзакция - это, определение
Транзакция - это операция перевода, вывода, ввода денежных средств на счёт. Транзакции бывают оффлайн и онлайн. В информационных технологиях транзакцией называют группу последовательных операций с базой данных, которая является логической единицей работы с данными.
Транзакция - это минимальная логически осмысленная операция, которая имеет смысл и может быть совершена только полностью.
Транзакция - это любая операция с использованием банковского счёта. Различают онлайн-транзакции, выполняющиеся в режиме реального времени между всеми заинтересованными сторонами, и оффлайн-транзакции.
Транзакция - это сделка, урегулирование спора путем соглашения сторон, единица коммуникативного процесса (социального взаимодействия), состоящая из коммуникативного стимула и коммуникативной реакции (напр., вопрос-ответ).
Транзакция - это действие или серия действий, выполняемых одним пользователем или прикладной программой, которые осуществляют доступ или изменение содержимого БД.
Транзакция - это группа последовательных операций с базой данных, которая представляет собой логическую единицу работы с данными.
Транзакция - это банковская операция, состоящая в переводе денежных средств с одного счета на другой.
Транзакция - это банковская операция, которая заключается в том, что денежные средства переводят с одного счета на какой-либо другой банковский счет.
Транзакция - это операция владельца банковской карты со своим счетом. Проще говоря, всякий раз, когда вы используете свою пластиковую карту для оплаты товаров или услуг, перевода денег, снятия средств и пр., вы совершаете транзакцию по карте. Полный цикл банковской транзакции включает в себя запрос, его обработку и ответ.
Транзакция - это совершение сделки по покупке/продаже финансовых инструментов, в том числе и на международном валютном рынке Форекс. Под банковской транзакцией подразумевают осуществление банковской операции по простому банковскому переводу денежных средств с одного счета на другой, при этом транзакция может осуществляться как внутри банка, так и между банками.
Транзакция - это соглашение или сделку, при которой двумя сторонами рассматриваются и принимаются некоторые уступки в ходе заключения сделки (мировая сделка).
Транзакции в экономике
Наиболее распространённым случаем является банковская транзакция по оплате банковской платёжной картой в торгово-сервисном предприятии. Такая транзакция начинается, когда держатель карты решает оплатить товар или услугу и передаёт карту (либо оплачивает сам) кассовому работнику.
Банковские транзакции
Как итоговая часть банковской операции, транзакция может быть инициирована подачей письменного распоряжения в банк, электронным распоряжением через системы интернет-банкинга или иные коммуникационные системы, а также при помощи какого-либо платёжного инструмента.
Виды транзакций
Существуют два вида транзакции: онлайн транзакция и оффлайн транзакция.
Онлайн транзакция
Онлайн транзакция - это операция, при которой перед выполнением по переводу денег держателя электронной карты происходит соединение в реальном времени с прогресинговым центром.
Запрос на транзакцию по пластиковой карте при ее совершении отправляется в так называемый процессинговый центр. Эта организация (юридическое лицо или структурное подразделение), которая обеспечивает взаимодействие меду участниками расчетов. Собственные процессинговые центры есть у большинства российских банков. Их целью является информационное и технологическое обеспечение участников расчетов, а также проведение внутрибанковской обработки транзакций с пластиковыми картами. В случае онлайн-транзакции как раз и используется поддержка процессинговым центром в проведения операции.
Банк-эквайер (тот, который установил терминал в данной розничной точке) отправляет в процессинговый центр запрос на авторизацию транзакции (то есть на ее разрешение). Процессинговый центр связывается с банком-эмитентом (то есть банком, который оформил вам пластиковую карту). И только после проверки и подтверждения информации о пластиковой карте и сверке ее со своими данными, банк-эмитент дает возможность совершения транзакции по данной карте.
Оффлайн транзакция
При оффлайн транзакции не происходит соединение между участниками платежной системы. Возможен и другой путь проведения транзакции, без участия процессингового центра, запроса на авторизацию и прочих операций по авторизации транзакции с банком-эмитентом. Можно провести так называемую оффлайн-трензакцию – при ее совершении не имеет места взаимодействие между участниками платежной системы.
Проведение транзакции
Посредством POS-терминала в целях аутентификации держателя информация карты из терминала передаётся в банк-эквайрер, обслуживающий данный терминал и имеющий соглашение с владельцем торговой точки. В зависимости от договорённостей торговая точка оплачивает банку комиссию за его участие в обработке транзакции. Далее банк-эквайрер передаёт информацию в платёжную систему, обслуживающую данную карту. Там данные попадают в операционный центр, к которому подключены банки-участники платёжной системы. В этом центре проходит проверка на предмет наличия или отсутствия платёжных данных карты в стоп-листе и в зависимости от полученного результата в транзакции отказывается или она одобряется с дальнейшим направлением в банк-эмитент, выпустивший данную карту и обслуживающий привязанный к ней банковский счёт/счета клиента.
Здесь она попадает в процессинговый и авторизационный центр, в котором проводятся расширенные проверки на легальность обрабатываемой транзакции. При подозрении на мошенничество или нарушении условий обслуживания даётся отказ. В зависимости от типа карты (дебетовая или кредитная) и установленного банком приоритета авторизации здесь может проводиться проверка доступного остатка средств на счёте или платёжного лимита, а также сверяться авторизационный PIN-код держателя. При удовлетворении всем проверкам эмитент одобряет операцию и в рамках транзакции, также через платёжную систему, ответ даётся в торговую точку. Путём взаиморасчётов с платёжной системой эмитент перечисляет эквайреру сумму запрашиваемых по транзакции средств, а также комиссию платёжной системы за обработку транзакции. В свою очередь с клиентского счёта банк списывает оплачиваемую и подтверждённую клиентом к оплате сумму денег (для дебетовых карт) или уменьшает доступный платёжный лимит, тем самым резервируя часть средств к последующему списанию (для кредитных карт). Транзакция завершает в момент поступления обратно к торговую точку ответа с одобрением или отказом.
Примерами аналогичных транзакций могут служить комплекс действий при поручении банку перевести денежные средства с одного счёта на другой или операция снятия наличных в банкомате (как с участием банковской карты, так и без неё).
При оффлайн-транзакции операция может проводиться без обращения к банку-эквайреру и следуемых за этим проверочных мероприятий. Это действует для карточных счетов, на которых доступный для траты по карте остаток заранее резервируется банком и в памяти POS-терминала остаются данные о сумме оплаты и реквизитах карты. В пределах доступного карте остатка средства одобряются для списания, но само оно происходит значительно позже после подключения терминала к каналу связи и передачи накопленной информации в обслуживающий банк. В России такой способ оплаты был доступен по картам платёжной системы СБЕРКАРТ.
Транзакции по банковским картам
Интернет открыл перед человеком невиданные ранее возможности. Теперь если мы хотим помыть жалюзи, то смотрим в сети способы этого нелегкого дела. При покупке автомобиля или мобильного телефона – не забываем проконсультироваться в виртуальном мире о лучших моделях и их преимуществах. Во всем этом есть только один неприятный момент – практически в каждой статье встречаются непонятные термины и определения. В этом отношении показательна банковская тематика. Вот уж где действительно шагу нельзя сделать, не «вступив» при этом в какое-нибудь заковыристое словечко. Одно из самых распространенных определений – транзакция, означающая совершение операции по пластиковой карте. Но не все так просто. Анализом того процесса, который таит в себе транзакция, и займемся.
Интересно, что до сих пор так точно и не установлено правильное написание этого слова. Два варианта (транзакция и трансакция) совершенно равноправны и присутствуют в официальных документах различных финансовых учреждений.
Слово имеет латинские корни («transactio» означает договор или совершение). Если обобщать, то транзакцией является любая операция, повлекшая за собой изменение состояния счета клиента.
Так, вполне законно транзакцией называются пополнение карты, снятие наличных в банкомате, осуществление переводов и т.п. Но чаще всего это определение встречается при совершении оплаты платежной картой в торговой точке.
Прокатывая банковскую карту через терминал, кассир вряд ли понимает, какие процессы при этом происходят. А вот клиенту знание процедуры не помешает (все-таки речь идет о его деньгах и их безопасности).
Что же представляет собой типичная транзакция в магазине? Это несколько связанных друг с другом этапов.
1. Прежде всего, нужно понимать, что имеются два основных участника: банк-эмитент (ему принадлежит пластиковая карта) и банк-эквайер (обслуживает торговую точку, предоставляя ей POS-терминал). В чем вообще суть операции? В том, что банк-эквайер хочет получить от банка-эмитента разрешение на проведение транзакции. Прокатывая платежное средство через терминал, кассир отправляет в виде потока зашифрованной информации запрос, содержащий необходимые для осуществления транзакции данные. Это номер карты, срок ее действия, ФИО владельца и т.д. В общем, все, что содержат магнитная полоса или чип.
2. Посланный запрос летит… нет, не в банк. А в специальную организацию, называемую процессинговым центром. Хотя стоит сделать поправку. У некоторых банков (как правило, самых крупных) имеется собственный процессинговый центр. Другие же учреждения вынуждены заключать договор либо с отдельной организацией, либо с другим банком. Процесс, в котором участвует процессинговый центр, называется «запрос на авторизацию». Авторизация (от англ. «authorization») – это разрешение на совершение транзакции. Функция процессингового центра заключается в обработке информации и пересылке ее далее в банк-эмитент.
3. Проверив сведения и сопоставив их со своими данными, банк-эмитент отправляет процессинговому центру разрешение на совершение транзакции, которое заключается в присвоении операции кода авторизации.
4. Окончательный этап прост – получив разрешение, банк-эквайер осуществляет транзакцию, результатом которой является чек из POS-терминала и пересылка денег со счета клиента на счет магазина.
Описанная транзакция называется также «онлайн-транзакцией», что показывает осуществление ее в реальном времени. Как вы понимаете, бывает и транзакция оффлайн. Она может осуществляться с помощью импринтера (устройство, которое делает оттиск лицевой стороны карты). При этом заполняется слип, который позже передается в банк-эмитент для оплаты. Примерно такая же схема может быть в случае оплаты гостиничных услуг или аренды автомобиля.
Популярным вопросом является возможность отмены транзакции. Вообще, следует заметить, что банк может отменить очень многие операции (при желании, конечно). Какие усилия для этого нужно приложить, разбирать не будем (просто знайте, что возможность отмены и исправления ошибки есть).
Конечно же, транзакцию отменить можно. Правда, сейчас мы говорим об операции в ТСП (торгово-сервисном предприятии). В случае снятия наличных в банкомате, к примеру, когда купюры на руках, какая уж тут отмена?
Легче всего аннулировать транзакцию в тот же день, что и производилась оплата. На каждом терминале есть специальная функция. Если же терминал уже отгружен (данные передались в банк), то следует обращаться в финансовое учреждение, которое выпустило «пластик».
Вот как все непросто оказалось с таким простым словом «транзакция».
Защита удалённых банковских транзакций
В наши дни в связи со всеобщей информатизацией и компьютеризацией банковской деятельности значение информационной безопасности удаленных транзакций многократно возросло. В результате повсеместного распространения электронных платежей, пластиковых карт, компьютерных сетей объектом информационных атак стали непосредственно денежные средства как банков, так и их клиентов. Совершить попытку хищения может любой — необходимо лишь наличие компьютера, подключенного к сети Интернет.
Удаленная банковская транзакция – это совокупность операций, которые сопровождают удаленное взаимодействие покупателя и платежной системы. В качестве примеров удаленных транзакций можно привести оплату товаров через Интернет, использование банкоматов, расчеты в точках продаж. Обычно транзакция включает в себя запрос, выполнение задания и ответ. Однако в случает банковских транзакций эти три составляющие представляют собой денежные средства передаваемые по линиям связи. Поэтому вопрос защиты удаленных банковских транзакций является актуальным и существует большое количество механизмов и средств их защиты. В этом направлении прилагаются серьезные усилия, как в практическом, так и в теоретическом плане, используются самые последние достижения науки, привлекаются передовые технологии.
Банковские транзакции в сфере электронной комерции
В наиболее общем виде любая экономика состоит из процесса производства товаров и коммерческой деятельности, основной целью которой является получение прибыли посредством реализации произведенного товара. Коммерческая деятельность, или просто коммерция – это широкое понятие, которое не сводится лишь к продаже какого-либо товара и получению оплаты за него.
Традиционная коммерция – это типичный бизнес-процесс, который можно представить в виде коммерческой транзакции, включающей в себя несколько этапов. Сначала компания производит новую продукцию, затем выходит с ней на рынок, распространяет и обеспечивает послепродажную поддержку. Потребители определяют свою потребность в какой-либо продукции, знакомятся с информацией о ней, ищут места покупки, сравнивают возможные варианты с учетом цены, уровня обслуживания, репутации производителя и лишь после этого что-либо приобретают. Коммерческая транзакция включает также переговоры о цене, форме оплаты и сроках доставки товара, заключение сделки, оплату и выполнение заказа, фиксацию в виде документа факта совершения сделки. Кроме потребителей и поставщиков участниками транзакции являются также платежные системы, банки и другие финансовые учреждения, обеспечивающие перемещение финансовых средств, а также агенты доставки, выполняющие физическую доставку товара потребителям.
В качестве потребителей и поставщиков могут выступать:
- отдельные граждане (физические лица);
- организации и предприятия (юридические лица).
После этапа рекламы и маркетинга поставщик предъявляет потребителю каталог товаров или услуг. Потребитель производит заказ, в котором указывает наименование и тип товара. На основании заказа поставщик направляет ему предложение заключить сделку (оферту).
Оферта может выполняться в виде договора либо, в упрощенном варианте, в виде счета. В случае согласия потребитель возвращает поставщику акцепт. Акцепт может быть реализован в виде подписанного договора либо каким-то другим способом. Оплата товара, в зависимости от возможностей потребителя и поставщика, может быть осуществлена наличным либо безналичным способом. Оплата товара должна быть взаимосвязана с этапом физической поставки товара или услуги потребителю. Коммерческая транзакция завершается этапом фиксации факта окончания сделки, в процессе этого этапа оформляются итоговые документы (счет-фактура, акт, накладные). В простейшем случае, например при розничной продаже товаров относительно невысокой стоимости, оферта представляет собой счет, который передается потребителю по почте, по факсу или при личной встрече. Акцепт в этом случае реализуется в виде оплаты выставленного счета.
Электронная коммерция – это разновидность коммерческой деятельности, в которой взаимодействие между ее участниками на всех или некоторых ее этапах осуществляется электронным способом. Иначе говоря, электронная коммерция предполагает взаимодействие между партнерами с использованием информационных технологий, что существенно повышает гибкость, эффективность и масштабность бизнес-процессов. Электронная коммерция включает в себя не только операции, связанные с куплей-продажей товаров и услуг, но и операции, направленные на поддержку извлечения прибыли, создание спроса на товары и услуги, послепродажную поддержку клиентов и т.п.
На рисунке показано взаимодействие участников коммерческой деятельности.
Электронная коммерция, т.е. технология поддержания внешних бизнес-контактов – это одна из двух базовых составляющих электронного бизнеса. Вторая составляющая – это комплексная автоматизация внутренней деятельности компании.
Виды электронной коммерции.
Электронная коммерция – это использование компьютеров, работающих в Интернет, для того, чтобы трансформировать старые и создать новые бизнес отношения с партнерами и клиентами. Существуют различные приложения, которые обеспечивают новые бизнес решения, которые позволяют улучшить качество товаров и предоставляемых услуг, повышают скорость обслуживания, снижают операционные издержки.
Новая методология ведения бизнеса имеет несколько сфер приложения:
- между различными видами бизнеса - сфера В2В (business-to-business);
- между бизнесом и потребителем - В2С (business-to-consumer);
- между потребителями – С2С (consumer-to-consumer);
- между бизнесом и государственными органами - B2A/B2G (business-to-administration/government);
- между государством и потребителями — А2C, или G2C (administration/government-to-consumer);
- в рамках отдельного бизнеса , или Intra-business.
В2С или "бизнес - потребитель" — категория электронной коммерции, которая является эквивалентом розничной торговли и представлена различными видами электронных магазинов с полным предложением любых потребительских товаров. Этот вид электронной коммерции наиболее интересный и рискованный, при котором поставщик и потребитель, как правило, никогда ранее не имели взаимных деловых контактов. Интернет-магазины, виртуальные банки – классические примеры систем В2С.
В2В или "бизнес - бизнес" — категория электронной коммерции, когда компании осуществляют свою деятельность, начиная от выбора поставщика, или продукта , процесса заказа товаров у поставщиков, получения счетов-фактур, до проведения платежей и других операций на основе использования электронной сети. Этот вид электронной коммерции характеризует взаимодействие между относительно постоянными партнерами, связанными единой цепочкой бизнес-процесса и интенсивным двухсторонним информационным обменом. Как правило, это долгосрочные отношения между крупными компаниями, а также между отдельными подразделениями компании. При этом вопрос взаимного недоверия стоит менее остро и может быть отрегулирован на начальном этапе взаимодействия обменом юридически значимыми подписанными документами. Примерами систем В2В являются международная система передачи банковской и финансовой информации (SWIT).
В2А или "бизнес - администрация" — категория электронной коммерции, которая охватывает все виды трансакций между компаниями и государственными организациями. Пока этот вид электронной коммерции находится в стадии зарождения, но имеет перспективы быстрого развития по таким направлениям, как возмещение налога на добавленную стоимость и уплата корпоративных налоговых платежей.
С2А или "потребители - администрация". Такая категория существует пока только теоретически, ее рост связывают с различного рода выплатами социального назначения.
В основном, электронная коммерция ассоциируется с покупкой и продажей информации, продуктов и услуг через Интернет, но также используется для передачи информации внутри организации через интранет, чтобы улучшить процесс принятия решений и устранить дублирование на различных этапах его выработки.
Новая концепция электронной коммерции строится не только на улучшении проведения транзакций, но и на строительстве устойчиво улучшающихся взаимоотношений с партнерами, клиентами, как существующими, так и потенциальными.
Мобильная коммерция.
Термин мобильная коммерция – одно из словосочетаний, которые начинают все чаще попадаться на страницах газет и журналов, но при этом широкого распространения еще не получили. Мобильная коммерция – это продолжение электронной коммерции, ее перевод в мобильные формы. С появлением электронной коммерции стало возможным совершить покупку, провести платеж, принять участие в аукционе, не отходя от компьютера, если только он подключен к Интернету. Мобильная же коммерция делает пользователя еще более независимым, не привязанным к стационарным устройствам, предоставляя все вышеперечисленные возможности при наличии одного только мобильного телефона или карманного компьютера. Это очень важно для делового человека: часто многое зависит от мгновенно принятого решения, и этому не должны препятствовать такие факторы, как невозможность быстрого оформления сделки или отсутствие доступа к информационным каналам.
Мобильная коммерция способна привнести немало удобств, которые будут по достоинству оценены всеми владельцами мобильных устройств. Так, телефон, сохраняя все свои прежние функции, становится еще и средством идентификации его владельца, выполняет функции кредитной карты и т.д.
Итак, мобильная коммерция – это использование мобильных портативных устройств для общения, развлечения, получения и передачи информации, совершения транзакций через общественные и частные сети.
Наиболее распространенные устройства используемые для мобильной коммерции:
- PDA (Personal Digital Assistant) - портативный карманный компьютер. В это семейство входят устройства, подчас довольно-таки сильно различающиеся между собой. Это могут быть и умещающиеся в ладони бесклавиатурные устройства типа Palm, и более дорогие устройства со встроенной клавиатурой, имеющие размеры среднего органайзера, и, наконец, аппараты, являющиеся уже скорее миниатюрными ноутбуками. Основные операционные системы - Palm OS, Windows CE или EPOC. Связь с Интернетом осуществляется через беспроводной модем или посредством синхронизации с персональным компьютером, подключенным к Сети;
- мобильный телефон с функцией WAP или некоторым собственным микробраузером;
- смартфон - гибрид мобильного телефона и PDA, совмещающий голосовые возможности телефона с функциями обработки и передачи данных, таких как почта, выход в Интернет, работа с файлами и т.д.
Мобильный доступ в Интернет может осуществляться с помощью беспроводного модема, встроенного WAP-браузера или путем синхронизации устройства с другим, уже подключенным к Интернету.
Протокол WAP - результат совместной работы ассоциации WAP Forum, объединяющей производителей устройств и технологий мобильной связи, среди которых можно назвать Nokia, Ericsson, Motorola, телекоммуникационных операторов - Deutche Telecom, France Telecom, AT&T, компании-производителей программного обеспечения и провайдеров услуг - Microsoft, IBM, RSA, Unwired Planet, Symbian. Ассоциация объединяет более 500 членов, охватывает около 90 % рынка беспроводных устройств. Цель ассоциации - разработка единого открытого стандарта для обмена контентом между беспроводными устройствами и Web-сервером.
Повышенное внимание к WAP обусловлено несколькими причинами. Одна из них: Интернет и мобильные устройства являются двумя очень перспективными и быстроразвивающимися отраслями, следовательно, разработка стандарта связи между ними - одно из самых востребованных на сегодняшний день решений. Присутствие же среди разработчиков крупнейших производителей беспроводных устройств, таких как Nokia, Ericsson, Motorola, придает дополнительный вес этому начинанию, да и количество членов ассоциации впечатляет. Однако если раньше о WAP говорили одно только хорошее, то теперь внимание акцентируется в основном на его недостатках, которых оказалось немало.
WAP состоит из следующего набора протоколов:
- WSP (Wireless Session Protocol) - протокол обеспечения обмена данными между клиентом и сервером;
- WTP (Wireless Transaction Protocol) - протокол обеспечения проведения транзакций на основе транспортного механизма запросов и ответов (request and reply);
- WTLS (Wireless Transport Layer Security) - протокол для обеспечения безопасности;
- WDP (Wireless Datagram Protocol) - протокол беспроводной передачи датаграмм.
На рисунке показано, каким образом происходит обмен данными с помощью WAP.
Информация передается между WAP-клиентом и WAP-сервером. В качестве WAP-клиента может выступать обычный мобильный WAP-телефон. С помощью программы-микробраузера направляется запрос по сети беспроводного доступа, который принимается WAP-шлюзом. WAP-шлюз, в свою очередь, направляет URL-запрос, используя протокол HTTP, к запрашиваемому Web-узлу, правда запрашиваемые Web-страницы должны быть написаны на языке WML (Wireless Markup Language). Web-узел формирует ответ в формате WML, передает его на WAP-шлюз, и уже оттуда, в двоичном формате, запрошенная информация передается на мобильный телефон клиента.
Мобильная коммерция обладает рядом ниже перечисленных дополнительных возможностей ведения бизнеса:
- повсеместный доступ – мобильный телефон становится привычной вещью, которая всегда с собой;
- отсутствие многих ограничений электронной коммерции – для того чтобы получить почту, прочитать необходимую информацию, совершить покупку, не нужно находиться рядом с компьютером или интернет-терминалом, достаточно одного мобильного телефона, который и так обычно всюду носят с собой;
- локализация – такие технологии, как GPS (Global Positioning System), позволяют получить доступ к информации, относящейся именно к данному региону, например, предложения о покупке интересующего товара в близлежащих магазинах;
- персонализация – телефон является персональным устройством, по которому можно идентифицировать владельца. На это стоит обратить особое внимание тем, кто предлагает свои услуги мобильным пользователям. В проигрыше останутся компании, рассылающие сообщения без ориентации на отдельных покупателей (или группы покупателей).
Вместе с тем существует и ряд недостатков:
- ограничения, связанные с пропускной способностью сетей и видом самих устройств;
- размеры экрана. Даже с увеличением экрана мобильного телефона, улучшением его технических характеристик, он все равно останется маленьким. Не слишком удобным будет и набор текста.
Интернет коммерция.
Бурное развитие Интернет во всем мире открыло ряд направлений бизнеса: предоставление услуг Интернет, электронная почта, IP-телефония и т.д. На подходе сфера сетевых развлечений и виртуальной реальности, этому способствует впечатляющий прогресс в разработке мультимедиа стандартов и протоколов MPEG-4 и MPEG-7. Банки давно использовали специализированные сети для расчетов, в последнее время они стали осваивать возможности общедоступных сетей. Реклама через Интернет стала высокодоходной деятельностью даже в России. Особое положение в этом ряду занимает электронная коммерция через Интернет. Был разработан торговый протокол IOTP, который перекрывает почти неограниченный спектр услуг, начиная от торговых сделок и оплаты, вплоть до доставки и послепродажного обслуживания, разработан целый спектр платежных протоколов, что сняло последние технические проблемы на пути внедрения торговли через сети Интернет. Одной из проблем была слабая защищенность транспортировки данных по каналам Интернет. Нельзя сказать, что в этой сфере решены все проблемы, но, тем не менее, за последние годы достигнуты впечатляющие успехи. В основном это связано с разработкой эффективных алгоритмов и программ шифрования (симметричных и асимметричных), аутентификации, электронной подписи, сертификации и безопасных каналов.
Открытый торговый протокол Интернет IOTP (Internet Open Trading Protocol) создает базу коммерции через Интернет. Протокол не зависит от используемой платежной системы и т.д.. IOTP способен обрабатывать ситуации, когда продавец выступает в качестве покупателя, обеспечивает оформление и отслеживание доставки товаров и прохождения платежей, или совмещает некоторые или все перечисленные функции.
Рост Интернет и прогресс в электронной коммерции привносят огромные изменения в сферу бизнеса, политики, управления и в само общество. Методы, которые используются партнерами в торговле, обогатились и необратимо изменились. Наиболее заметные изменения характера торговли включают в себя:
- присутствие - операции, требующие личного контакта, становятся исключением, а не правилом. Этот процесс начался при внедрении торговли по почте и по телефону. Электронная коммерция через Интернет еще шире раздвигает область и объем операций, проводимых без личного контакта участников сделок;
-аутентификация. Важной частью личного присутствия является возможность партнеров использование знакомых объектов и диалога для подтверждения того, кем они являются. Продавец демонстрирует различными способами свою способность производить кредитные и платежные операции. Покупатель предъявляет физические свидетельства своей платежеспособности, полученные от государства или финансовой организации. При этом учитывается разнообразная объективная информация: местоположение магазина, внешность, знакомство и поведение участников, знакомство с данной фирмой и ее торговым знаком;
- инструменты платежа. Несмотря на широкое развитие безналичных платежей, заметная часть торговых операций обеспечивается наличными деньгами или даже бартером. Существующая инфраструктура платежной системы по экономическим соображениям не может поддерживать операции с низкими суммами платежей, но и не может от них отказаться;
- стоимость операций. Новое значение низкой стоимости операции в Интернет связано с возможностью того, что продавец может предложить, например, объекты с ценой, составляющей долю денежной единицы, которой не существует в реальности;
- доставка. Внедряются новые методы доставки, включая доставку по сети, например, информации или программных продуктов. Возможна доставка по частям при играх, просмотре, прослушивании и некоторых других виртуальных услугах, при этом она должна быть подтверждена до осуществления платежа. Деньги в этом случае не могут быть возвращены.
Разработки программ для электронной коммерции будут более привлекательны, если они окажутся совместимыми для разных разработчиков. Однако IOTP призван, прежде всего, решить проблему коммуникаций между различными решениями.
IOTP предлагает стандартные рамки для инкапсуляции платежных протоколов. Это означает, что средства платежей смогут лучше взаимодействовать, если они встроены в программы, следующие протоколу IOTP. В результате базовые виды электронных платежей смогут найти более широкое распространение на большем разнообразии рабочих платформ.
Существует несколько преимуществ для продавцов:
- возможность предложить более широкий перечень видов платежей;
- возможность быть более уверены, что покупатель будет иметь программу, необходимую для осуществления покупки;
- при получении платежа и расписки от покупателя о получении товара или услуги они смогут обеспечить клиента гарантией, что он имел дело именно с тем человеком или организацией;
- новые продавцы смогут вступить в этот Интернет-рынок с новыми продуктами и услугами, используя новые возможности, предоставляемые IOTP.
Существует несколько преимуществ для банков и финансовых организаций:
- возможность предоставить услуги IOTP для торговцев;
- возможность найти новые способы для реализации услуг, сопряженных с IOTP(предоставление услуг клиентам продавцов);
- деньги от обработки новых платежей и депозитов (они имеют возможность построить отношения с новыми продавцами).
Для покупателей также имеется несколько преимуществ:
- большой выбор продавцов, с которыми можно иметь дело;
- имеется более удобный интерфейс для осуществления покупки;
- существуют возможности уладить проблемы через продавца (а не через банк);
- существует запись операций, которая может использоваться, например, налоговыми службами.
Протокол описывает содержимое, формат и последовательность сообщений, которые пересылаются между партнерами электронной торговли - покупателями, торговцами и банками или финансовыми организациями.
Протокол спроектирован так, чтобы обеспечить его применимость при любых схемах электронных платежей, так как он реализует весь процесс продажи, где передача денег всего лишь один шаг из многих.
Схемы платежей которые поддерживает IOTP включают MasterCard Credit, Visa Credit, Mondex Cash, Visa Cash, GeldKarte, eCash, CyberCoin, Millicent, Proton и т.д..
Каждая схема содержит некоторый обмен сообщениями, который является характерным именно для нее. Эти схемно-зависимые части протокола помещены в приложения к данному документу.
Документ не предписывает участникам, какое следует использовать программное обеспечение или процесс. Он определяет только необходимые рамки, в пределах которых реализуется торговая операция.
Безопасность удалённых банковских транзакций
Стратегия информационной безопасности банков весьма сильно отличается от аналогичных стратегий других компаний и организаций. Это обусловлено специфическим характером угроз, а также публичной деятельностью банков, которые вынуждены делать доступ к счетам достаточно легким с целью удобства для клиентов.
Обычная компания строит свою информационную безопасность, исходя лишь из узкого круга потенциальных угроз — главным образом защита информации от конкурентов (основной задачей является защита информации от налоговых органов и преступного сообщества с целью уменьшения вероятности неконтролируемого роста налоговых выплат и рэкета). Такая информация интересна лишь узкому кругу заинтересованных лиц и организаций и редко бывает ликвидна, т.е. обращаема в денежную форму.
Рассмотрим факторы, которые должна учитывать информационная безопасность банка.
Хранимая и обрабатываемая в банковских системах информация представляет собой реальные деньги. На основании информации компьютера могут производится выплаты, открываться кредиты, переводиться значительные суммы. Вполне понятно, что незаконное манипулирование с такой информацией может привести к серьезным убыткам. Эта особенность резко расширяет круг преступников, покушающихся именно на банки (в отличие от, например, промышленных компаний, внутренняя информация которых мало кому интересна).
Информация в банковских системах затрагивает интересы большого количества людей и организаций — клиентов банка. Как правило, она конфиденциальна, и банк несет ответственность за обеспечение требуемой степени секретности перед своими клиентами. Естественно, клиенты вправе ожидать, что банк должен заботиться об их интересах, в противном случае он рискует своей репутацией со всеми вытекающими отсюда последствиями.
Конкурентоспособность банка зависит от того, насколько клиенту удобно работать с банком, а также насколько широк спектр предоставляемых услуг, включая услуги, связанные с удаленным доступом. Поэтому клиент должен иметь возможность быстро и без утомительных процедур распоряжаться своими деньгами. Но такая легкость доступа к деньгам повышает вероятность преступного проникновения в банковские системы.
Информационная безопасность банка (в отличие от большинства компаний) должна обеспечивать высокую надежность работы компьютерных систем даже в случае нештатных ситуаций, поскольку банк несет ответственность не только за свои средства, но и за деньги клиентов.
Банк хранит важную информацию о своих клиентах, что расширяет круг потенциальных злоумышленников, заинтересованных в краже или порче такой информации.
Преступления в банковской сфере также имеют свои особенности.
Многие преступления, совершенные в финансовой сфере остаются неизвестными для широкой публики в связи с тем, что руководители банков не хотят тревожить своих акционеров, боятся подвергнуть свою организацию новым атакам, опасаются подпортить свою репутацию надежного хранилища средств и, как следствие, потерять клиентов.
Как правило, злоумышленники обычно используют свои собственные счета, на который переводятся похищенные суммы. Большинство преступников не знают, как “отмыть” украденные деньги. Умение совершить преступление и умение получить деньги — это не одно и то же.
Большинство компьютерных преступлений — мелкие.
Успешные компьютерные преступления, как правило, требуют большого количества банковских операций (до нескольких сотен). Однако крупные суммы могут пересылаться и всего за несколько транзакций. Большинство злоумышленников — клерки. Хотя высший персонал банка также может совершать преступления и нанести банку гораздо больший ущерб — такого рода случаи единичны.
Компьютерные преступления не всегда высокотехнологичны. Достаточно подделки данных, изменения параметров среды автоматизированных систем обработки информации банков (АСОИБ) и т.д., а эти действия доступны и обслуживающему персоналу.
Многие злоумышленники объясняют свои действия тем, что они всего лишь берут в долг у банка с последующим возвратом. Впрочем “возврата”, как правило, не происходит.
Специфика защиты автоматизированных систем обработки информации банков (АСОИБ) обусловлена особенностями решаемых ими задач.
Как правило АСОИБ обрабатывают большой поток постоянно поступающих запросов в реальном масштабе времени, каждый из которых не требует для обработки многочисленных ресурсов, но все вместе они могут быть обработаны только высокопроизводительной системой.
В АСОИБ хранится и обрабатывается конфиденциальная информация, не предназначенная для широкой публики. Ее подделка или утечка могут привести к серьезным (для банка или его клиентов) последствиям. Поэтому АСОИБ обречены оставаться относительно закрытыми, работать под управлением специфического программного обеспечения и уделять большое внимание обеспечению своей безопасности.
Другой особенностью АСОИБ является повышенные требования к надежности аппаратного и программного обеспечения. В силу этого многие современные АСОИБ тяготеют к так называемой отказоустойчивой архитектуре компьютеров, позволяющей осуществлять непрерывную обработку информации даже в условиях различных сбоев и отказов.
Можно выделить два типа задач, решаемых АСОИБ:
- аналитические. К этому типу относятся задачи планирования, анализа счетов и т.д. Они не являются оперативными и могут требовать для решения длительного времени, а их результаты могут оказать влияние на политику банка в отношении конкретного клиента или проекта. Поэтому подсистема, с помощью которой решаются аналитические задачи, должна быть надежно изолирована от основной системы обработки информации. Для решения такого рода задач обычно не требуется мощных вычислительных ресурсов, обычно достаточно 10-20% мощности всей системы. Однако ввиду возможной ценности результатов их защита должна быть постоянной;
- повседневные. К этому типу относятся задачи, решаемые в повседневной деятельности, в первую очередь выполнение платежей и корректировка счетов. Именно они и определяют размер и мощность основной системы банка, для их решения обычно требуется гораздо больше ресурсов, чем для аналитических задач. В то же время ценность информации, обрабатываемой при решении таких задач, имеет временный характер. Постепенно ценность информации, например, о выполнении какого-либо платежа, становиться не актуальной. Естественно, это зависит от многих факторов, как-то: суммы и времени платежа, номера счета, дополнительных характеристик и т.д. Поэтому, обычно бывает достаточным обеспечить защиту платежа именно в момент его осуществления. При этом защита самого процесса обработки и конечных результатов должна быть постоянной.
Несанкционированный доступ (НСД) - наиболее распространенный вид компьютерных нарушений. Он заключается в получении пользователем доступа к объекту, на который у него нет разрешения в соответствии с принятой в организации политикой безопасности. Обычно самая главная проблема определить, кто и к каким наборам данных должен иметь доступ, а кто нет. Другими словами, необходимо определить термин “несанкционированный”.
По характеру воздействия НСД является активным воздействием, использующим ошибки системы. НСД обращается обычно непосредственно к требуемому набору данных, либо воздействует на информацию о санкционированном доступе с целью легализации НСД. НСД может быть подвержен любой объект системы. НСД может быть осуществлен как стандартными, так и специально разработанными программными средствами к объектам в любом состоянии.
Для реализации НСД существует два способа:
- можно преодолеть систему защиты, то есть путем различных воздействий на нее прекратить ее действия в отношении себя или своих программ. Это сложно, трудоемко и не всегда возможно, зато эффективно;
- можно понаблюдать за тем, какие наборы данных, представляющие интерес для злоумышленника, открыты для доступа по недосмотру или умыслу администратора. Такой доступ, хотя и с некоторой натяжкой, тоже можно назвать несанкционированным, его легко осуществить, но от него легко и защититься. К этому же типу относится НСД с подбором пароля, поскольку осуществить такой подбор возможно лишь в случае нарушения правил составления паролей и использования в качестве пароля человеческих имен, повторяющихся символов, наборов типа QWERTY.
В подавляющем большинстве случаев НСД становится возможным из-за непродуманного выбора средств защиты, их некорректной установки и настройки, плохого контроля работы, а также при небрежном отношении к защите своих собственных данных.
Еще один вид компьютерных нарушений - незаконное использование привилегий.
Злоумышленники, применяющие данный способ атаки, обычно используют штатное программное обеспечение (системное или прикладное), функционирующее в нештатном режиме. Практически любая защищенная система содержит средства, используемые в чрезвычайных ситуациях, при сбоях оборудования или средства, которые способны функционировать с нарушением существующей политики безопасности. В некоторых случаях пользователь должен иметь возможность доступа ко всем наборам системы (например, при внезапной проверке).
Такие средства необходимы, но они могут быть чрезвычайно опасными. Обычно эти средства используются администраторами, операторами, системными программистами и другими пользователями, выполняющими специальные функции.
Для того чтобы уменьшить риск от применения таких средств, большинство систем защиты реализует такие функции с помощью набора привилегий — для выполнения определенной функции требуется определенная привилегия. В этом случае каждый пользователь получает свой набор привилегий, обычные пользователи — минимальный, администраторы — максимальный (в соответствии с принципом минимума привилегий). Наборы привилегий каждого пользователя являются его атрибутами и охраняются системой защиты. Несанкционированный захват привилегий приведет, таким образом, к возможности несанкционированного выполнения определенной функции. Это может быть НСД (частный случай), запуск определенных программ и даже реконфигурация системы.
Естественно, при таких условиях расширенный набор привилегий -заветная мечта любого злоумышленника. Он позволит ему совершать практически любые действия, причем, возможно, даже в обход всех мер контроля. Нарушения, совершаемые с помощью незаконного использования привилегий, являются активным воздействием, совершаемым с целью доступа к какому-либо объекту или системе в целом.
Незаконный захват привилегий возможен либо при наличии ошибок в самой системе защиты (что, например, оказалось возможным в одной из версий операционной системы UNIX), либо в случае халатности при управлении системой и привилегиями в частности (например, при назначении расширенного набора привилегий всем подряд). Строгое соблюдение правил управления системой защиты, соблюдение принципа минимума привилегий позволят избежать таких нарушений.
Атаки “салями” более всего характерны для систем, обрабатывающих денежные счета и, следовательно, для банков особенно актуальны. Принцип атак “салями” построен на том факте, что при обработке счетов используются целые единицы (центы, рубли, копейки), а при исчислении процентов нередко получаются дробные суммы.
Например, 6,5 % годовых от 102,87 условных единиц за 31 день составит 0,5495726 тех же единиц. Банковская система может округлить эту сумму до 0,55 единиц. Однако если пользователь имеет доступ к банковским счетам или программам их обработки, он может округлить ее в другую сторону — до 0,54 условных единиц, а разницу в один цент записать на свой счет. Владелец счета вряд ли ее заметит, а если и обратит внимание, то спишет ее на погрешности обработки и не придаст значения. Злоумышленник же получит прибыль в один цент, при обработке 10000 счетов в день (а в некоторых банках и больше). Его прибыль составит 1000 условных единиц, т.е. около 300000 условных единиц в год.
Отсюда и происходит название таких атак — как колбаса салями изготавливается из небольших частей разных сортов мяса, так и счет злоумышленника пополняется за счет различных вкладчиков. Естественно, такие атаки имеют смысл лишь в тех организациях, где осуществляется не менее 5000 - 10000 транзакций в день, иначе не имеет смысла рисковать, поскольку в случае обнаружения преступника просто определить. Таким образом, атаки “салями” опасны в основном для крупных банков.
Причинами атак “салями” являются, во-первых, погрешности вычислений, позволяющие трактовать правила округления в ту или иную сторону, а во-вторых, огромные объемы вычислений, необходимые для обработки счетов. Успех таких атак зависит не столько от величины обрабатываемых сумм, сколько от количества счетов (для любого счета погрешность обработки одинакова). Атаки “салями” достаточно трудно распознаются, если только злоумышленник не начинает накапливать на одном счете миллионы. Предотвратить такие атаки можно только обеспечением целостности и корректности прикладных программ, обрабатывающих счета, разграничением доступа пользователей АСОИБ к счетам, а также постоянным контролем счетов на предмет утечки сумм.
“Скрытые каналы” - пути передачи информации между процессами системы, нарушающие системную политику безопасности. В среде с разделением доступа к информации пользователь может не получить разрешение на обработку интересующих его данных, однако может придумать для этого обходные пути. Практически любое действие в системе каким-то образом затрагивает другие ее элементы, которые при этом могут изменять свое состояние. При достаточной наблюдательности и знании этих связей можно получить прямой или опосредованный доступ к данным.
“Скрытые каналы” могут быть реализованы различными путями, в частности при помощи программных закладок (“троянских коней”).
Например, программист банка не всегда имеет доступ к именам и балансам депозитных счетов. Программист системы, предназначенной для обработки ценных бумаг, может не иметь доступ к предложениям о покупке или продаже. Однако при создании таких систем он может предусмотреть способ получения интересующих его сведений. В этом случае программа скрытым способом устанавливает канал связи с этим программистом и сообщает ему требуемые сведения.
Атаки с использованием скрытых каналов обычно приводят к нарушениям конфиденциальности информации в АСОИБ, по характеру воздействия являются пассивными: нарушение состоит только в передаче информации. Для организации “скрытых каналов” может использоваться как штатное программное обеспечение, так и специально разработанные “троянские” или вирусные программы. Атака обычно производится программным способом.
Примером передачи информации по “скрытым каналам” может служить, например, итоговый отчет, в котором вместо слова “TOTAL” используется слово “TOTALS” - программист сделал так, что при определенных условиях, которые может распознать его программа, должна происходить замена слов. Подобными “скрытыми каналами” могут стать число пробелов между двумя словами, значение третьей или четвертой цифры после запятой в какой-нибудь дроби (на которые никто не обращает внимания) и т.д. “Скрытым каналом” может явиться и передача информации о наличии или отсутствии какого-либо набора данных, его размере, дате создания или модификации и т.д.
Также существует большое количество способов организации связи между двумя процессами системы. Более того, многие операционные системы имеют в своем распоряжении такие средства, так как они очень облегчают работу программистов и пользователей. Проблема заключается в том, что очень трудно отделить неразрешенные “скрытые каналы” от разрешенных, то есть тех, которые не запрещаются системной политикой безопасности. В конечном счете, все определяется ущербом, который может принести организация “скрытых каналов”.
Отличительными особенностями “скрытых каналов” является их малая пропускная способность (по ним обычно можно передавать только небольшое количество информации), большие трудности их организации и обычно небольшой наносимый ими ущерб. Более того, он вообще бывает незаметен, поэтому специальные меры защиты против “скрытых каналов” предпринимают довольно редко. Обычно достаточно грамотно разработанной полномочной политики безопасности.
Под “маскарадом” понимается выполнение каких-либо действий одним пользователем АСОИБ от имени другого пользователя. При этом такие действия другому пользователю могут быть разрешены. Нарушение заключается в присвоении прав и привилегий.
Такие нарушения также называются симуляцией или моделированием. Цель “маскарада” — сокрытие каких-либо действий за именем другого пользователя или присвоение прав и привилегий другого пользователя для доступа к его наборам данных или для использования его привилегий.
“Маскарад” — это способ активного нарушения защиты системы, он является опосредованным воздействием, то есть воздействием, совершенным с использованием возможностей других пользователей.
Примером “маскарада” может служить вход в систему под именем и паролем другого пользователя, при этом система защиты не сможет распознать нарушение. В этом случае “маскараду” обычно предшествует взлом системы или перехват пароля.
Другой пример “маскарада” — присвоение имени другого пользователя в процессе работы. Это может быть сделано с помощью средств операционной системы (некоторые операционные системы позволяют изменять идентификатор пользователя в процессе работы) или с помощью программы, которая в определенном месте может изменить определенные данные, в результате чего пользователь получит другое имя. В этом случае “маскараду” может предшествовать захват привилегий, или он может быть осуществлен с использованием какой-либо ошибки в системе.
“Маскарадом” также называют передачу сообщений в сети от имени другого пользователя. Способы замены идентификатора могут быть разные, обычно они определяются ошибками и особенностями сетевых протоколов. Тем не менее на приемном узле такое сообщение будет воспринято как корректное, что может привести к серьезным нарушениям работы сети. Особенно это касается управляющих сообщений, изменяющих конфигурацию сети, или сообщений, ведущих к выполнению привилегированных операций.
Наиболее опасен “маскарад” в банковских системах электронных платежей, где неправильная идентификация клиента может привести к огромным убыткам. Особенно это касается платежей с помощью электронных банковских карт. Сам по себе метод идентификации с помощью персонального идентификатора (PIN) достаточно надежен, нарушения могут происходить вследствие ошибок его использования. Это произойдет, например, в случае утери кредитной карты, при использовании очевидного идентификатора (своего имени, ключевого слова и т.д.). Поэтому клиентам надо строго соблюдать все рекомендации банка по выполнению такого рода платежей.
“Маскарад” является достаточно серьезным нарушением, которое может привести к тяжелым последствиям, таким как изменение конфигурации системы (сети), утечка информации, нарушения работы АСОИБ. Для предотвращения “маскарада” необходимо использовать надежные методы идентификации и аутентификации, блокировку попыток взлома системы, контроль входов в нее. Также необходимо фиксировать все события, которые могут свидетельствовать о “маскараде”, в системном журнале для его последующего анализа.
Еще один вид нарушений - “Сборка мусора”. После окончания работы обрабатываемая информация не всегда полностью удаляется из памяти. Часть данных может оставаться в оперативной памяти, на дисках и лентах, других носителях. Данные хранятся на носителе до перезаписи или уничтожения. При выполнении этих действий на освободившемся пространстве диска находятся их остатки. Хотя прочитать такие данные трудно, однако, используя специальные программы и оборудование, все же возможно. Такой процесс принято называть “сборкой мусора”.
Он может привести к утечке важной информации. “Сборка мусора” — активное, непосредственное воздействие на объекты АСОИБ при их хранении с использованием доступа. Это воздействие может привести к нарушению конфиденциальности информации.
Для защиты от “сборки мусора” используются специальные механизмы, которые могут быть реализованы в операционной системе и/или аппаратуре компьютера или в дополнительных программных (аппаратных) средствах.
Примерами таких механизмов являются стирающий образец и метка полноты:
- стирающий образец — это некоторая последовательность битов, записываемая на место, освобождаемое файлом. Менеджер или администратор безопасности АСОИБ может автоматически активизировать запись этой последовательности при каждом освобождении участка памяти, при этом стираемые данные уничтожаются физически;
- метка полноты предотвращает чтение участков памяти, отведенных процессу для записи, но не использованных им. Верхняя граница адресов использованной памяти и есть метка полноты. Этот способ используется для защиты последовательных файлов исключительного доступа (результирующие файлы редакторов, компиляторов, компоновщиков т.д.). Для индексных и разделяемых последовательных файлов этот метод называется “стирание при размещении”, память очищается при выделении ее процессу.
Под “взломом системы” понимают умышленное проникновение в систему с несанкционированными параметрами входа, то есть именем пользователя и его паролем (паролями).
“Взлом системы” — умышленное, активное воздействие на систему в целом. “Взлом системы” обычно происходит в интерактивном режиме.
Поскольку имя пользователя не является секретом, объектом “охоты” обычно становится пароль. Способы вскрытия пароля могут быть различны: перебор возможных паролей, “маскарад” с использованием пароля другого пользователя, захват привилегий. Кроме того, “взлом системы” можно осуществить, используя ошибки программы входа.
Таким образом, основную нагрузку на защиту системы от “взлома” несет программа входа. Алгоритм ввода имени и пароля, их шифрование (при необходимости), правила хранения и смены паролей не должны содержать ошибок. Противостоять “взлому системы” также поможет, например, ограничение количества попыток неправильного ввода пароля с последующей блокировкой терминала и уведомлением оператора в случае нарушения.
Кроме того, оператор должен постоянно контролировать активных пользователей системы: их имена, характер работы, время входа и выхода и т.д. Такие действия помогут своевременно установить факт “взлома” и позволят предпринять необходимые действия.
“Люк” — это скрытая, недокументированная точка входа в программный модуль. “Люк” вставляется в программу обычно на этапе отладки для облегчения работы: программный модуль можно вызывать в разных местах, что позволяет отлаживать отдельные его части независимо. Но в дальнейшем программист может забыть уничтожить “люк” или некорректно его заблокировать. Кроме того, “люк” может вставляться на этапе разработки для последующей связи данного модуля с другими модулями системы, но затем, в результате изменившихся условий данная точка входа оказывается ненужной.
Наличие “люка” позволяет вызывать программу нестандартным образом, что может серьезно сказаться на состоянии системы защиты (неизвестно, как в таком случае программа будет воспринимать данные, среду системы и т.д.). Кроме того, в таких ситуациях не всегда можно прогнозировать ее поведение.
“Люк” относится к категории угроз, возникающих вследствие ошибок реализации какого-либо проекта (АСОИБ в целом, комплекса программ и т.д.). Поскольку использование “люков” может быть самым разным и зависит от самой программы, классифицировать данную угрозу как-либо еще затруднительно.
“Люки” могут оказаться в программах по следующим причинам:
- их забыли убрать;
- для использования при дальнейшей отладке;
- для обеспечения поддержки готовой программы;
- для реализации тайного контроля доступа к данной программе после ее установки.
Первый из перечисленных случаев — ненамеренный промах, который может привести к бреши в системе защиты. Два следующих случая — серьезные испытания для системы безопасности, с которыми она может и не справиться. Четвертый случай может стать первым шагом преднамеренного проникновения с использованием данной программы.
Отметим, что программная ошибка “люком” не является. “Люк” — это достаточно широко используемый механизм отладки, корректировки и поддержки программ, который создается преднамеренно, хотя чаще всего и без злого умысла. Люк становится опасным, если он не замечен, оставлен и не предпринималось никаких мер по контролю за ним.
Большая опасность “люков”, особенно в программах операционной системы, компенсируется высокой сложностью их обнаружения. Если не знать заранее, что данная программа содержит “люк”, необходимо обработать килобайты (а иногда и мегабайты) программного кода, чтобы найти его. Понятно, что почти всегда это нереально. Поэтому в большинстве случаев обнаружение “люков” — результат случайного поиска. Защита от них может быть только одна — не допускать появления “люков” в программе, а при приемке программных продуктов, разработанных третьими производителями — проводить анализ исходных текстов программ с целью обнаружения “люков”.
В последнее время участились случаи воздействия на вычислительную систему при помощи специально созданных программ. Под вредоносными программами в дальнейшем будем понимать такие программы, которые прямо или косвенно дезорганизуют процесс обработки информации или способствуют утечке или искажению информации.
Ниже рассмотрим некоторые (самые распространенные) виды подобных программ: “троянский конь”, вирус, “червь”, “жадная” программа, “захватчик паролей”.
“Троянский конь” — программа, выполняющая в дополнение к основным (проектным и документированным) не описанные в документации действия. Аналогия с древнегреческим “троянским конем” таким образом вполне оправдана — в не вызывающей подозрений оболочке таится угроза. Программы такого типа являются серьезной угрозой безопасности АСОИБ.
По характеру угрозы “троянский конь” относится к активным угрозам, реализуемым программными средствами, работающими в пакетном режиме. Он может угрожать любому объекту АСОИБ. Наиболее опасным является опосредованное воздействие, при котором “троянский конь” действует в рамках полномочий одного пользователя, но в интересах другого пользователя, установить личность которого порой невозможно.
Опасность “троянского коня” заключается в дополнительном блоке команд, тем или иным образом вставленном в исходную безвредную программу, которая затем предлагается (дарится, продается, подменяется) пользователям АСОИБ. Этот блок команд может срабатывать при наступлении некоторого условия (даты, времени и т.д., либо по команде извне). Запустивший такую программу подвергает опасности как себя и свой файлы, так и всю АСОИБ в целом.
Наиболее опасные действия “троянский конь” может выполнять, если запустивший ее пользователь обладает расширенным набором привилегий. В этом случае злоумышленник, составивший и внедривший “троянского коня”, и сам этими привилегиями не обладающий, может выполнить несанкционированные привилегированные функции чужими руками. Или, например, злоумышленника очень интересуют наборы данных пользователя, запустившего такую программу. Последний может даже не обладать расширенным набором привилегий — это не помешает выполнению несанкционированных действий.
“Троянский конь” — одна из наиболее опасных угроз безопасности АСОИБ. Радикальным способом защиты от этой угрозы является создание замкнутой среды исполнения программ. В особенности важно разделение внешних сетей (особенно Интернет) и внутренних сетей по крайней мере на уровне протоколов, а еще лучше — на физическом уровне. Желательно также, чтобы привилегированные и непривилегированные пользователи работали с разными экземплярами прикладных программ, которые должны храниться и защищаться индивидуально. При соблюдении этих мер вероятность внедрения программ подобного рода будет достаточно низкой.
Вирус — это программа, которая может заражать другие программы путем включения в них своей, возможно модифицированной, копии, причем последняя сохраняет способность к дальнейшему размножению. Вирус может быть охарактеризован двумя основными особенностями :
- способностью к самовоспроизведению. Это свойство означает, что за время своего существования на компьютере вирус должен хотя бы один раз воспроизвести свою копию на долговременном носителе;
- способностью к вмешательству (получению управления) в вычислительный процесс. Это свойство является аналогом “паразитирования” в живой природе, которое свойственно биологическим вирусам.
Как и “троянские кони” вирусы относятся к активным программным средствам. Классификация вирусов, используемые ими методы заражения, способы борьбы с ними достаточно хорошо изучены и описаны. Эта проблема в нашей стране стала особенно актуальной, поэтому очень многие занимаются ею.
Проблема защиты от вирусов может рассматриваться с двух сторон: как самостоятельная проблема и как одна из сторон проблемы общей защиты АСОИБ. И тот, и другой подходы имеют свои отличительные особенности и, соответственно, свои собственные методы решения проблемы.
В последнее время удалось более или менее ограничить масштабы заражений и разрушений. Тут сыграли свою роль и превентивные меры, и новые антивирусные средства, и пропаганда всех этих мер.
Вообще говоря проблема вирусов может стать тем толчком, который приведет к новому осмыслению как концепций защиты, так и принципов автоматизированной обработки информации в целом.
“Червь” — программа, распространяющаяся через сеть и (в отличие от вируса) не оставляющая своей копии на магнитном носителе. “Червь” использует механизмы поддержки сети для определения узла, который может быть заражен. Затем с помощью тех же механизмов передает свое тело или его часть на этот узел и либо активизируется, либо ждет для этого подходящих условий.
Наиболее известный представитель этого класса - вирус Морриса, поразивший сеть Internet в 1988 г. Наиболее подходящей средой распространения “червя” является сеть, все пользователи которой считаются дружественными и доверяют друг другу. Отсутствие защитных механизмов как нельзя лучше способствует уязвимости сети.
Самый лучший способ защиты от “червя” — принять меры предосторожности против несанкционированного доступа к сети.
Захватчики паролей. Это программы специально предназначены для воровства паролей. При попытке входа имитируется ввод имени и пароля, которые пересылаются владельцу программы-захватчика, после чего выводится сообщение об ошибке ввода и управление возвращается операционной системе. Пользователь, думающий, что допустил ошибку при наборе пароля, повторяет вход и получает доступ к системе. Однако его имя и пароль уже известны владельцу программы-захватчика. Перехват пароля может осуществляться и другим способом - с помощью воздействия на программу, управляющую входом пользователей в систему и ее наборы данных.
Для предотвращения этой угрозы перед входом в систему необходимо убедиться, что вы вводите имя и пароль именно системной программе входа, а не какой-то другой. Кроме того, необходимо неукоснительно придерживаться правил использования паролей и работы с системой. Большинство нарушений происходят не из-за хитроумных атак, а из-за элементарной небрежности. Не рекомендуется покидать рабочее место, не выйдя из системы. Постоянно проверяйте сообщения о дате и времени последнего входа и количестве ошибочных входов. Эти простые действия помогут избежать захвата пароля.
Кроме описанных выше, существуют и другие возможности компрометации пароля. Не следует записывать команды, содержащие пароль, в командные процедуры, надо избегать явного объявления пароля при запросе доступа по сети: эти ситуации можно отследить и захватить пароль. Не стоит использовать один и тот же пароль для доступа к разным узлам.
Соблюдение правил использования паролей — необходимое условие надежной защиты.
Специфической чертой защиты банковских систем является специальная форма обмена электронными данными - электронных платежей, без которых ни один современный банк не может существовать.
Обмен электронными данными (ОЭД) — это межкомпьютерный обмен деловыми, коммерческими, финансовыми электронными документами. Например, заказами, платежными инструкциями, контрактными предложениями, накладными, квитанциями. ОЭД обеспечивает оперативное взаимодействие торговых партнеров (клиентов, поставщиков, торговых посредников и др.) на всех этапах подготовки торговой сделки, заключения контракта и реализации поставки. На этапе оплаты контракта и перевода денежных средств ОЭД может приводить к электронному обмену финансовыми документами. При этом создается эффективная среда для торгово-платежных операций:
- возможно ознакомление торговых партнеров с предложениями товаров и услуг, выбор необходимого товара/услуги, уточнение коммерческих условий (стоимости и сроков поставки, торговых скидок, гарантийных и сервисных обязательств) в реальном масштабе времени;
- заказ товара/услуг или запрос контрактного предложения в реальном масштабе времени;
- оперативный контроль поставки товара, получение по электронной почте сопроводительных документов (накладных, фактур, комплектующих ведомостей и т.д.);
- подтверждение завершения поставки товара/услуги, выставление и оплата счетов;
- выполнение банковских кредитных и платежных операций.
К достоинствам ОЭД следует отнести:
- уменьшение стоимости операций за счет перехода на безбумажную технологию. Эксперты оценивают стоимость обработки и ведения бумажной документации в 3-8 % от общей стоимости коммерческих операций и доставки товаров. Выигрыш от применения ОЭД оценивается, например, в автомобильной промышленности США более чем в 200 условных единиц на один изготовленный автомобиль;
- повышение скорости расчета и оборота денег;
- повышение удобства расчетов.
Суть концепции удаленных электронных платежей заключается в том, что пересылаемые по линиям связи сообщения, должным образом оформленные и переданные, являются основанием для выполнения одной или нескольких банковских операций. Никаких бумажных документов для выполнения этих операций в принципе не требуется (хотя они могут быть выданы). Другими словами, пересылаемое по линиям связи сообщение несет информацию о том, что отправитель выполнил некоторые операции над своим счетом, в частности над корреспондентским счетом банка-получателя (в роли которого может выступать клиринговый центр), и что получатель должен выполнить определенные в сообщении операции. На основании такого сообщения можно переслать или получить деньги, открыть кредит, оплатить покупку или услугу и выполнить любую другую банковскую операцию. Такие сообщения называются электронными деньгами, а выполнение банковских операций на основании посылки или получения таких сообщений - электронными платежами. Естественно, весь процесс осуществления электронных платежей нуждается в надежной защите. Иначе банк и его клиентов ожидают серьезные неприятности. Электронные платежи применяются при межбанковских, торговых и персональных расчетах.
Пересылка денег с помощью системы электронных платежей включает следующие этапы (в зависимости от конкретных условий и самой системы порядок может меняться):
- определенный счет в системе первого банка уменьшается на требуемую сумму;
- корреспондентский счет второго банка в первом увеличивается на ту же сумму;
- от первого банка второму посылается сообщение, содержащее информацию о выполняемых действиях (идентификаторы счетов, сумма, дата, условия и т.д.);
- при этом пересылаемое сообщение должно быть соответствующим образом защищено от подделки: зашифровано, снабжено цифровой подписью и контрольными полями и т.д.;
- с корреспондентского счета первого банка во втором списывается требуемая сумма;
- определенный счет во втором банке увеличивается на требуемую сумму;
- второй банк посылает первому уведомление о произведенных корректировках счета;
- это сообщение также должно быть защищено от подделки способом, аналогичным защите платежного сообщения;
- протокол обмена фиксируется у обоих абонентов и, возможно, у третьего лица (в центре управления сетью) для предотвращения конфликтов.
На пути передачи сообщений могут быть посредники - клиринговые центры, банки-посредники в передаче информации и т.п. Основная сложность таких расчетов - уверенность в своем партнере, то есть каждый из абонентов должен быть уверен, что его корреспондент выполнит все необходимые действия.
Для определения общих проблем защиты удаленных транзакций, можно выделить три основных этапа:
- подготовка документа к отправке;
- передача документа по каналу связи;
- прием документа и его обратное преобразование.
С точки зрения защиты в системах удаленных платежей существуют следующие уязвимые места:
- пересылка платежных и других сообщений между банками или между банком и клиентом;
- обработка информации внутри организаций отправителя и получателя;
- доступ клиента к средствам, аккумулированным на счете.
При пересылке платежных и других сообщений возникают следующие проблемы:
- внутренние системы организаций получателя и отправителя должны быть приспособлены к получению/отправке электронных документов и обеспечивать необходимую защиту при их обработке внутри организации (защита оконечных систем);
- взаимодействие получателя и отправителя документа осуществляется опосредованно - через канал связи. Это порождает такие виды проблем как взаимное опознавания абонентов (проблема установления аутентификации при установлении соединения), защиты документов, передаваемых по каналам связи (обеспечение целостности и конфиденциальности документов), защиты самого процесса обмена документами (проблема доказательства отправления/доставки документа);
- в общем случае отправитель и получатель документа принадлежат к различным организациям и друг от друга независимы. Этот факт порождает проблему недоверия - будут ли предприняты необходимые меры по данному документу (обеспечение исполнения документа).
Рассмотрим перечень угроз, возникающих при пересылке платежных и других сообщений:
- несанкционированный доступ к ресурсам и данным системы (подбор пароля, взлом систем защиты и администрирования, маскарад);
- перехват и подмена трафика (подделка платежных поручений, атака типа "человек посередине");
- IР-спуфинг (подмена сетевых адресов);
- отказ в обслуживании;
- атака на уровне приложений;
- сканирование сетей или сетевая разведка;
- использование отношений доверия в сети.
Причины, приводящие к появлению подобных уязвимостей:
- отсутствие гарантии конфиденциальности и целостности передаваемых данных;
- недостаточный уровень проверки участников соединения;
- недостаточная реализация или некорректная разработка политики безопасности;
- отсутствие или недостаточный уровень защиты от несанкционированного доступа (антивирусы, контроль доступа, системы обнаружения атак);
- существующие уязвимости используемых операционных систем (ОС), ПО, СУБД, веб-систем и сетевых протоколов;
- непрофессиональное и слабое администрирование систем;
- проблемы при построении межсетевых фильтров;
- сбои в работе компонентов системы или их низкая производительность;
- уязвимости при управлении ключами.
Наиболее часто информационное пространство банковской системы используется для передачи сообщений, связанных с движением финансов. Основные виды атак на финансовые сообщения и финансовые транзакции:
- раскрытие содержимого;
- представление документа от имени другого участника;
- несанкционированная модификация;
- повтор переданной информации.
Существует четыре основные формы удаленного банковского обслуживания клиентов:
- домашнее (телефонное) обслуживание;
- расчет с автоматическим кассовым аппаратом (банкоматом);
- расчет в точке продажи;
- финансовый сервис с использованием всемирной сети Интернет. Домашнее банковское обслуживание позволяет клиентам получить доступ к банковским и информационным услугам не выходя из дома.
Достоинства этого вида обслуживания:
- для клиента - большая доступность данных и управление своими финансовыми делами;
- для банка - уменьшение стоимости обслуживания.
Ввод данных для платежа при голосовой связи (идентификатор, номер счета, размер платежа) производится клиентом либо с клавиатуры телефона либо голосом (что менее надежно с точки зрения безопасности, но более технически доступно).
Банковский автомат-кассир (АКА, банкомат) - специализированное устройство, предназначенное для обслуживания клиента в отсутствие банковского персонала. Это наиболее существенная часть банковской системы, предназначенная, в основном, для выдачи наличных денег.
Помимо этой функции АКА может выполнять ряд дополнительных, а числе которых:
- проверка состояния счета клиента;
- изменение параметров счета клиента;
- осуществление различных платежей;
- предоставление информации о:
- страховом полисе клиента;
- котировках ценных бумаг на фондовом рынке;
- покупке и продаже акций;
- обменных курсах валют и т.д.;
Системы, обеспечивающие расчеты продавца и покупателя в точке продажи, (point-of-sale, POS). В основном, все терминалы, подключенные к этим системам, размещены на предприятиях торговли. Большинство таких терминалов установлены в супермаркетах, так как там совершается большое количество покупок в течении дня, а также в других магазинах и на автозаправочных станциях.
Системы POS обеспечивают следующие услуги:
- проверку и подтверждение чеков;
- проверку и обслуживание дебетовых и кредитных карточек;
- использование системы электронных расчетов.
Банки, финансирующие систему расчетов в точке продажи, таким образом расширяют список своих клиентов путем предоставления им больших удобств для покупок в магазинах с использованием удаленных устройств. Торговля, в свою очередь, увеличивает количество клиентов, расширяет управление имуществом, сохраняет время клиентов и уменьшает риск потери наличных денег.
Существует два типа систем POS. Основной из них предполагает, что продавец и покупатель имеют счета в одном и том же банке. Данные, необходимые для платежа, передаются через терминалы системы POS банковскому компьютеру, производится платеж, и деньги переводятся со счета покупателя на счет продавца. В более сложной системе участвуют два или более банков. При платеже сначала вызывается банк покупателя, производится платеж и записывается на магнитную ленту для передачи в расчетную палату. Расчетная палата в свою очередь пересылает данные о платеже в банк продавца, который кредитует платеж.
Проблемы идентификации при удаленном обслуживании.
Персональный номер (идентификатор) (Personal Identification Number, PIN) - это последовательность цифр, используемая для идентификации клиента. Для ввода PIN как в АКА, так и в терминалах систем POS предусмотрена цифровая клавиатура, аналогичная телефонной. По способу назначения можно выделить следующие типы PIN: назначаемые выведенные PIN, назначаемые случайные PIN, PIN выбираемые пользователем.
Клиент различает только два типа PIN: PIN, который назначен ему банком, выдавшим карточку, и PIN, который пользователь может выбирать себе самостоятельно.
В связи с тем, что PIN предназначен для идентификации и аутентификации клиента, его значение должно быть известно только клиенту. Однако на практике PIN трудно удержать в памяти и поэтому клиент банка куда-нибудь его запишет (иногда - на саму карточку). В результате задача злоумышленника бывает сильно облегчена.
Использование PIN, назначенных банком, неудобно даже при небольшом их количестве. Много цифр сложно удерживать в памяти их приходится записывать. Для большего удобства клиента используются PIN, выбираемые им самим. Такой способ определения PIN, во-первых, позволяет клиенту использовать один и тот же PIN для различных целей, и, во-вторых, позволяет задавать PIN как совокупность букв и цифр.
PIN обычно состоит из четырех или шести цифр. Следовательно, для его перебора в наихудшем (для защиты естественно) случае необходимо осуществить 10.000 комбинаций (четырехсимвольный PIN). Такой перебор возможен за короткое время. Поэтому в системах, использующих такой PIN , должны быть предусмотрены меры защиты от подбора PIN.
Всего существуют два основных способа проверки PIN: алгоритмический и неалгоритмический.
Алгоритмический способ проверки заключается в том, что у пользователя запрашивается PIN, который преобразуется по определенному алгоритму с использованием секретного ключа и затем сравнивается со значением PIN, хранившемся на карточке. Достоинством этого метода проверки является:
- отсутствие копии PIN на главном компьютере, что исключает его раскрытие персоналом банка;
- отсутствие передачи PIN между АКА и главным компьютером банка, что исключает его перехват злоумышленником или навязывание результатов сравнения;
- облегчение работы по созданию программного обеспечения системы, так как уже нет необходимости действий в реальном масштабе времени.
Неалгоритмический способ проверки PIN, как это следует из его названия, не требует применения специальных алгоритмов. Проверка PIN осуществляется путем прямого сравнения полученного PIN со значениями, хранимыми в базе данных. Часто сама база данных со значениями PIN шифруется прозрачным образом, чтобы не затруднять процесс сравнения, но повысить ее защищенность.
Идентификация клиента с использованием PIN работает только в следующих случаях:
- отсутствует перехват карточки и/или PIN при передаче от банка клиенту;
- банковские карточки не воруют, не теряют и их невозможно подделать;
- PIN невозможно узнать при доступе к системе другим пользователем;
- PIN иным образом не может быть скомпрометирован;
- в электронной системе банка отсутствуют сбои и ошибки;
- в самом банке нет мошенников.
В качестве альтернативы PIN предлагается применять устройства идентификации, основанные на биометрическом принципе. Их широкое применение сдерживается высокой стоимостью.
Методы защиты удалённых банковских транзакий
С технической точки зрения проблемы защиты удаленных транзакций решаются с помощью нескольких механизмов, отвечающих за обеспечение адекватной безопасности электронных банковских систем. Работа большинства этих механизмов обеспечивается службами сети с расширенным набором услуг (Value-Added Network, VAN). Службы, реализующие обмен электронными документами, должны выполнять следующие функции:
- обеспечить защиту от случайных и умышленных ошибок;
- обеспечить адаптацию к частым изменениям количества пользователей, типов оборудования, способов доступа, объемов трафика, топологии;
- поддерживать различные типы аппаратного и программного обеспечения, поставляемого различными производителями;
- осуществлять управление и поддержку сети для обеспечения непрерывности работы и быстрой диагностики нарушений;
- реализовывать полный спектр прикладных задач ОЭД, включая электронную почту;
- реализовывать максимально возможное число требований партнеров;
- включать службы резервного копирования и восстановления после аварий.
В системах обмена электронными документами должны быть реализованы следующие механизмы, обеспечивающие реализацию функций защиты на отдельных узлах системы и на уровне протоколов высокого уровня:
- равноправная аутентификацию абонентов;
- невозможность отказа от авторства сообщения/приема сообщения;
- контроль целостности сообщения;
- обеспечение конфиденциальности сообщения;
- управление доступом на оконечных системах;
- гарантии доставки сообщения;
- невозможность отказа от принятия мер по сообщению;
- регистрация последовательности сообщений;
- контроль целостности последовательности сообщений;
- обеспечение конфиденциальности потока сообщений.
Полнота решения проблем защиты обмена электронными документами сильно зависит от правильного выбора системы шифрования. Система шифрования (или криптосистема) представляет собой совокупность алгоритмов шифрования и методов распространения ключей. Правильный выбор системы шифрования помогает:
- скрыть содержание документа от посторонних лиц (обеспечение конфиденциальности документа) путем шифрования его содержимого;
- обеспечить совместное использование документа группой пользователей системы обмена электронных документов путем криптографического разделения информации и соответствующего протокола распределения ключей. При этом для лиц, не входящих в группу, документ недоступен;
- своевременно обнаружить искажение, подделку документа (обеспечение целостности документа) путем введения криптографического контрольного признака;
- удостовериться в том, что абонент, с которым происходит взаимодействие в сети, является именно тем, за кого он себя выдает (аутентификация абонента/источника данных).
Следует отметить, что при защите систем обмена электронными данными большую роль играет не столько шифрование документа, сколько обеспечение его целостности и аутентификация абонентов (источника данных) при проведении сеанса связи. Поэтому механизмы шифрования в таких системах играют обычно вспомогательную роль.
О общедоступных сетях распространены нападения хакеров. Это высококвалифицированные специалисты, которые направленным воздействием могут выводить из строя на длительное время серверы АБС (DоS-атака) или проникать в их системы безопасности. Практически все упомянутые угрозы способен реализовать хакер-одиночка или объединенная группа. Хакер может выступать как в роли внешнего источника угрозы, так и в роли внутреннего (сотрудник организации).
Для предотвращения проникновения в систему безопасности используются следующие средства защиты:
- шифрование содержимого документа;
- контроль авторства документа;
- контроль целостности документа;
- нумерация документов;
- ведение сессий на уровне защиты информации;
- динамическая аутентификация;
- обеспечение сохранности секретных ключей;
- надежная процедура проверки клиента при регистрации в прикладной системе;
- использование электронного сертификата клиента;
- создание защищенного соединения клиента с сервером.
Также необходимо применять комплекс технических средств защиты интернет-сервисов:
- брандмауэр (межсетевой экран) - программная и/или аппаратная реализация;
- системы обнаружения атак па сетевом уровне;
- антивирусные средства;
- защищенные ОС, обеспечивающие уровень В2 но классификации защиты компьютерных систем и дополнительные средства контроля целостности программ и данных;
- защита на уровне приложений: протоколы безопасности, шифрования, ЭЦП, цифровые сертификаты, системы контроля целостности;
- защита средствами системы управления БД;
- защита передаваемых по сети компонентов программного обеспечения;
- мониторинг безопасности и выявление попыток вторжения, адаптивная защита сетей, активный аудит действий пользователей;
- обманные системы;
- корректное управление политикой безопасности.
Для проведения безопасных банковских транзакций должны выполняться:
- аутентификация документа при его создании;
- защита документа при его передаче;
- аутентификация документа при обработке, хранении и исполнении;
- защита документа при доступе к нему из внешней среды.
Протоколы защиты удаленных банковских транзакций SSL и SET.
Под протоколом понимается алгоритм, определяющий порядок взаимодействия участников транзакции (владельца карты, торговой точки, обслуживающего банка, банка-эмитента, центра сертификации) и форматы сообщений, которыми участники транзакции обмениваются друг с другом с целью обеспечения процессов авторизации и расчетов. Под устойчивым протоколом подразумевается, то что, он обеспечивает на уровне криптостойкости алгоритмов цифровой подписи и шифрования:
- аутентификацию владельца карты другими участниками транзакции: торговой точкой, обслуживающим банком;
- аутентификацию торговой точки другими участниками транзакции: владельцем карты, обслуживающим банком;
- аутентификацию обслуживающего банка торговой точкой;
- конфиденциальность сообщений, которыми обмениваются участники транзакции через Интернет;
- конфиденциальность информации о реквизитах карты для торговой точки;
- целостность данных, которыми обмениваются участники транзакции;
- невозможность отказа от транзакции – наличие для каждого участника транзакции электронного практически неопровержимого доказательства факта совершения транзакции.
В данный момент наиболее распространенным протоколом, используемым при построении систем электронной коммерции является протокол SSL.
Широкое распространение протокола SSL объясняется в первую очередь тем, что он является составной частью всех известных браузеров и веб-северов. Это, означает, что фактически любой владелец карты, пользуется стандартными средствами доступа к Интернету, получает возможность провести транзакцию с использованием SSL.
Другие достоинства SSL – простота протокола для понимания всех участников транзакции и хорошие операционные показатели (скорость реализации транзакции). Последнее достоинство связанно с тем, что протокол в процессе передачи данных использует симметричные алгоритмы шифрования, которые на два порядка быстрее асимметричных при том же уровне криптостойкости.
В то же время, протокол SSL в приложении к электронной коммерции обладает рядом существенных недостатков.
Протоколы электронной коммерции, основанные на использовании SSL, не поддерживают аутентификацию клиента Интернет-магазином, поскольку сертификаты клиента в таких протоколах почти не используются. Использование «классических» сертификатов клиентами в схемах SSL является делом практически бесполезным. Такой «классический» сертификат, полученный клиентом в одном из известных центров сертификации, содержит только имя клиента и, что крайне редко, его сетевой адрес, большинство клиентов имеют динамический IP-адрес. В таком виде сертификат мало чем полезен для проведения транзакции, поскольку может быть без большого труда получен мошенником. Для того, чтобы сертификат клиента что-то значил при проведении транзакции, необходимо, чтобы он устанавливал связь между номером карты клиента и его банком-эмитентом. Причем любой Интернет-магазин, в который обращается за покупкой владелец карты с сертификатом, должен иметь возможность проверить эту связь, например с помощью своего обслуживающего банка.
Другими словами, такой сертификат должен быть получен клиентом в своем банке-эмитенте. Формат сертификата, специальные процедуры маскировки номера карты в сертификате, номер карты не должен присутствовать в сертификате в открытом виде, процедуры распространения и отзыва сертификатов, а также многое другое в этом случае должно быть оговорено между всеми участниками транзакции. Требуется создание иерархической инфраструктуры центров сертификации. Без создания такой инфраструктуры обеспечение взаимной аутентификации участников транзакции невозможно.
Отсутствие аутентификации клиента в схемах SSL является самым серьезным недостатком протокола, который позволяет мошеннику успешно провести транзакцию, зная только реквизиты карты. Тем более, протокол SSL не позволяет аутентифицировать клиента обслуживающим банком.
Протокол SSL не поддерживает цифровой подписи, что затрудняет процесс разрешения конфликтных ситуаций, возникающих в работе платежной системы. Для доказательства проведения транзакции требуется либо хранить в электронном виде весь диалог клиента и торговой точки (включая процесс установления сессии), что дорого с точки зрения затрат ресурсов памяти и на практике не используется, либо хранить бумажные копии, подтверждающие получение клиентом товара.
При использовании SSL не обеспечивается конфиденциальность данных о реквизитах карты для торговой точки. Протокол SSL не является устойчивым.
Для операций с кредитными карточками используется протокол SET (Secure Electronic transactions). В отличие от SSL протокол SET узко специализирован. Целью SET является обеспечение необходимого уровня безопасности для платежного механизма, в котором участвует три или более субъектов. При этом предполагается, что транзакция реализуется через Интернет, т.е. удаленно.
Рассмотрим функции, которые осуществляет SET на различных уровнях:
- аутентификация. Все участники кредитных операций идентифицируются с помощью электронных подписей. Это касается клиента-покупателя, продавца, банкира, выдавшего кредитную карточку, и банкира продавца;
- конфиденциальность. Все операции производятся в зашифрованном виде;
- целостность сообщений. Информация не может быть подвергнута модификации по дороге в противном случае это будет сразу известно;
- подсоединение. SET позволяет подключить к базовому сообщению дополнительный текст и послать его одному из партнеров;
-безопасность. Протокол должен обеспечить максимально возможную безопасность операции, достижимую в имеющихся условиях;
- совместимость. Должна быть предусмотрена совместимость с любыми программными продуктами и с любыми сервис-провайдерами.
Независимость от транспортного протокола. Безопасность операций не должна зависеть от уровня безопасности транспортного протокола. Такие гарантии особенно важны, так как протокол SET ориентирован для работы в Интернет. На более высоком уровне протокол SET поддерживает все возможности, предоставляемые современными кредитными карточками:
- регистрацию держателя карточки;
- регистрацию продавца;
- запрос покупки;
- авторизацию платежа;
- перевод денег;
- кредитные операции;
- возврат денег;
- отмену кредита;
- дебитные операции.
Необходимым условием создания глобальной системы аутентификации, основанной на использовании асимметричных алгоритмов шифрования, является наличие иерархической однокорневой системы центров сертификации, которая отсутствует в протоколе SSL. Основные функции системы центра сертификации – генерация и распределение сертификатов открытых ключей, обновление сертификатов, а так же генерация и распределение списков отозванных ключей (Certificate Revocation Lists, CRL).
В протоколе SET центр сертификации имеет четырехуровневую архитектуру основанную на использовании протокола X.509.
На верхнем уровне располагается Корневой центр сертификации (Root Certificate Authority, RCA), который отвечает за генерацию сертификатов для центров сертификации следующего нижележащего уровня – Центров сертификации международных платежных систем (Brand Certificate Authority, BCA), генерацию сертификатов для собственных открытых ключей, а также генерацию и распределение CRL для возможно скомпрометированных ключей центра сертификации уровня BCA. Оператором RCA является компания SETCo, специально созданная для развития и распространения стандарта SET.
На втором уровне иерархии системы центра сертификации находятся центры сертификации платежных систем. В настоящее время такие центры сертификации созданы в платежных системах VISA, Europay/MasterCard, American Express. Центр сертификации уровня BCA отвечает за генерацию сертификатов для центров сертификации следующих уровней – GCA, CCA, MCA, PCA, а также за генерацию, поддержку и распространение CRL для сертификатов, ранее подписанных данным BCA. Оператором BCA является соответствующая платежная система.
На третьем уровне системы центра сертификатов SET располагается Геополитический центр сертификации (Geo-Political Certificate Authority, GCA). Наличие центра сертификации уровня GCA позволяет платежной системе проводить более гибкую политику генерации и распределения сертификатов ключей для центров сертификации уровня ССА, МСА, РСА в отдельных геополитических зонах земного шара, а также повышать эффективность процедур генерации, поддержания и распространения CRL по сертификатам, эмитированным GCA. Оператор центра сертификации уровня GCA определяется правилами соответствующей платежной, системы. Например, по правилам систем VISA и MasterCard оператором GCA может быть либо сама платежная система, либо Group Member — банк, имеющий статус Группового участника платежной системы.
На четвертом, нижнем уровне системы центра сертификации SET располагаются три так называемых оконечных (End-Entity) типа центра сертификации: центр сертификации для владельцев платежных карт (Cardholder Certificate Authority, ССА), центр сертификации для торговых точек (Merchant Certificate Authority, МСА) и центры сертификации для платежных шлюзов (Payment Gateway Certificate Authority, РСА). Центры сертификации уровня End-Entity отвечают за генерацию сертификатов для основных участников транзакции — для владельца карты, торговой точки и платежного шлюза. В этом смысле все остальные центры сертификации играют вспомогательную роль, обеспечивая единую общую инфраструктуру центров доверия, позволяющую любым двум непосредственным участникам транзакции надежно аутентифицировать друг друга. Кратко остановимся на основных функциях центра сертификации уровня End-Entity.
Центр сертификации уровня ССА отвечает за генерацию и доставку сертификатов открытых ключей владельцев карт. Запросы на получение сертификатов поступают в ССА от владельцев карт либо через Web-страницы, либо по электронной почте. Для генерации сертификата владельца карты ССА должен поддерживать специальную процедуру идентификации клиента, определенную эмитентом карты. ССА также отвечает за распространение среди владельцев карт списков CRL, сгенерированных RCA, ВСА, ССД, РСА. Оператором ССА могут являться банк-эмитент карточек, для которых выпускаются сертификаты, платежная система или третья сторона, определяемая правилами конкретной платежной системы.
Центр сертификации уровня МСА отвечает за генерацию и доставку сертификатов открытых ключей торговых точек. Запросы на получение сертификатов поступают в МСА от торговых точек либо через Web-страницы, либо по электронной почте. Для генерации сертификата торговой точки МСА должен поддерживать специальную процедуру идентификации торговой точки, определенную обслуживающим банком данной торговой точки. МСА также отвечает за распространение в адрес торговой точки списков CRL, сгенерированных RCA, ВСА, GCA, РСА. Оператором МСА могут являться обслуживающий банк торговой точки, платежная система или третья сторона, определяемая правилами конкретной платежной системы. Центр сертификации уровня РСА отвечает за генерацию и доставку сертификатов открытых ключей платежным шлюзам. РСА также отвечает за генерацию и распространение списка CRL, содержащего ранее эмитированные данным РСА сертификаты открытых ключей, для которых соответствующие им закрытые ключи оказались скомпрометированными на момент рассылки CRL.
РСА отвечает за распространение в адрес платежных шлюзов листов CRL, сгенерированных RCA, ВСА, GCA, РСА. Оператором РСА могут являться обслуживающий банк, платежная система или третья сторона, определяемая правилами рассматриваемой платежной системы.
Схема регистрации владельца карты в центре сертификации (СА) показана на рисунке. Процесс регистрации проходит через семь состояний, начиная с отправки начального запроса и завершая получением сертификата. Эффективность сертификата при идентификации владельца карты сильно зависит от методов, используемых платежной системой карты и эмитентом карты для аутентификации владельца перед выдачей ему сертификата. Это достаточно критический процесс, учитывая то, что на этом этапе еще не используется цифровая подпись.
Сертификаты владельцев карт являются электронным представлением самих платежных карт. Так как они подписаны цифровым образом, их не сможет модифицировать третья сторона. Сертификат владельца карты не содержит номера счета и срока ее действия. Вместо этого там закодирована с привлечением хэш технологии информация о счете и секретный код, известный только программе владельца карты. Если номер счета, срок его действия и секретный код известны, корректность сертификата может быть проверена, но извлечь эту информацию из сертификата, даже зная часть перечисленных параметров практически невозможно. В рамках протокола SET владелец карты передает информацию о счете и секретный код расчетному центру, где эта информация верифицируется.
Сертификат посылается владельцу карты только в случае, когда это одобряется финансовой организацией, выпустившей эту карту. Запрос сертификата указывает на то, что владелец карты намерен выполнить какую-то коммерческую операцию. Полученный сертификат передается продавцу в рамках запроса покупки вместе с платежными инструкциями. Получив сертификат владельца карты, продавец может быть уверен, что счет владельца карты существует и действует, что подтверждено эмитентом карты или его агентом. В рамках SET сертификаты владельцев карты опционны и оставлены на усмотрение платежной системы.
Когда сертификационный центр (СА) получает запрос владельца карты, он дешифрует цифровой конверт, получает симметричный ключ, информацию о счете и секретный код, генерируемый программой владельца карты. Собственно запрос сертификата дешифруется с помощью симметричного ключа. Затем СА использует общедоступный ключ, присланный в запросе, чтобы проверить подпись, сформированную с помощью секретного ключа владельца карты. Если с подписью все в порядке, процесс обработки запроса продолжается. Далее производится верификация самого запроса с привлечением информации о счете. На этом этапе СА взаимодействует с эмитентом карты. Это взаимодействие не регламентируется протоколом SET. В некоторых вариантах на данном этапе для верификации запроса привлекаются возможности платежной системы. Если верификация запроса прошла успешно, сертификат формируется и пересылается владельцу карты.
При этом СА сначала генерирует случайное число, которое комбинируется с секретным кодом, присланным в запросе. Полученный код используется в сертификате для защиты информации о счете владельца карты. Номер счета, срок его действия и секретный код преобразуются с помощью однопроходного хэш-алгоритма. Полученный результат помещается в сертификат. Если номер счета, срок его действия и секретный код известны, сертификат можно верифицировать. После данной процедуры СА цифровым образом подписывает сертификат. Время действия сертификата определяется политикой СА, но часто оказывается равным сроку работы платежной карты (но может оказаться и короче). Сообщение-отклик содержит в себе сертификат, а также секретный код, сформированный СА и логотип платежной системы. Вся эта информация шифруется симметричным ключом, присланным в запросе. Многие из упомянутых процедур и структуры запросов/откликов будут рассмотрены подробно ниже.
Сертификаты продавца индицируют поддержку определенной платежной системы. Так как сертификаты продавца снабжены цифровой подписью, они не могут быть модифицированы третьей стороной. Эти сертификаты одобряются банком продавца и предоставляют гарантию того, что продавец имеет официальное соглашение со своим банком. Для работы в среде SET продавец должен иметь как минимум пару сертификатов для каждой разновидности, поддерживаемой им платежной системы.
Схема процедуры регистрации продавца содержит в себе пять этапов.
Продавец должен зарегистрироваться в СА до того, как он получит платежные инструкции от владельца карты или будет участвовать в транзакциях с расчетным центром. Перед посылкой запроса СА продавец должен получить его общедоступный ключ. Продавец должен также скопировать регистрационную форму в своем банке и идентифицировать получателя в запросе регистрации, посылаемом в СА. Регистрационная процедура начинается с посылки СА запроса сертификата СА, содержащего его общедоступный ключ и соответствующую регистрационную форму. СА идентифицирует банк продавца и выбирает подходящую регистрационную форму. В отклик СА вкладывается эта форма и его сертификат, содержащий общедоступный ключ. Этот сертификат продавец в дальнейшем использует в регистрационном процессе. Раз программа продавца имеет копию СА-сертификата, продавец может воспринимать платежные инструкции и обрабатывать транзакции SET. Прежде чем запрос сертификата будет обработан, продавец должен установить связь со своим банком (получателем). Продавцу нужны две пары общедоступных/секретных ключей - для ключевого обмена и для цифровой подписи. Эти ключи формируются программой продавца. Для регистрации продавец заполняет регистрационную форму, внося туда свое имя, адрес, идентификатор и т.д. Вместе с заполненной формой в СА посылается общедоступный ключ продавца. Эта информация подписывается программой продавца. Далее программа генерирует случайный симметричный ключ, который используется для шифрования запроса сертификата. Сам симметричный ключ шифруется с использованием общедоступного ключа СА и помещается в цифровой конверт. Сформированное таким методом сообщение посылается продавцом в СА.
Когда СА получает запрос продавца, он дешифрует цифровой конверт и извлекает оттуда симметричный ключ, который служит для дешифрации запроса. СА использует ключ, содержащийся в сообщении-запросе, для проверки цифровой подписи (проверка того, что сообщение подписано соответствующим секретным ключом). Если с подписью все в порядке, обработка запроса продолжается, в противном случае прерывается и посылается соответствующее уведомление продавцу.
После этого СА проверяет информацию регистрационного запроса, используя известные данные о продавце. Для этого производится обмен между СА и банком продавца (получателем). После успешной верификации этих данных СА формирует и цифровым образом подписывает сертификат продавца. Время действия сертификата определяется политикой СА. Но это время не должно быть больше длительности контракта между продавцом и его банком. Сертификат шифруется сгенерированным новым симметричным ключом, который в свою очередь шифруется общедоступным ключом продавца. Полученный код образует цифровой конверт отклика. Сообщение-отклик посылается продавцу.
Когда программа продавца получает отклик от СА, она дешифрует цифровой конверт и получает симметричный ключ для дешифрования регистрационного отклика, содержащего сертификат продавца.
Протокол SET работает с четырьмя субъектами: владельцем кредитной карточки, банком, эту карточку выпустившим (эмитент), продавцом и банком, где помещен счет продавца. Помимо этих функциональных субъектов в процессе обычно участвует центры сертификации, в задачу которых входит подтверждение подлинности предъявляемых параметров аутентификации, причем в случае крупных сделок с этими центрами должны взаимодействовать все участники. Основной целью сертификатов является подтверждение того, что присланный общедоступный ключ прибыл от настоящего отправителя, а не от самозванца.
Практика электронной торговли позволяет выделить семь этапов сделки приведенных в таблице.
Порядок следования этапов при определенных условиях может несколько варьироваться. Спецификация SET определяет функции и технику реализации этапов пять, шесть, семь и девять. Таким образом, работа протокола SET инициализируется владельцем карты. Владельцем карты может быть как частное лицо, так и корпоративный клиент, работающие на своих рабочих станциях.
Многие современные WEB-броузеры поддерживают протокол SET. Что позволяет осуществлять торговлю товарами и услугами с использованием WWW-технологии. Номер кредитной карточки имеет определенную структуру (это не случайное число). Первые четыре цифры - код банка, выпустившего карточку. Последняя цифра представляет собой контрольную сумму номера. Вычисление этой контрольной суммы производится по следующему алгоритму.
Каждая цифра номера умножается на его “вес”. Веса меняются 1,2,1,2. Для карт с четным числом цифр, последовательность весов начинается с 2, в противном случае с 1. Если взвешенное число больше 9, из него вычитается 9. Далее вычисляется сумма по модулю 10. Результат всегда должен получаться равным нулю (с учетом кода контрольной суммы). Схема взаимодействия субъектов в протоколе SET показана на рисунке (взаимодействия с центром сертификации не показаны).
Покупатель инициализирует покупку. При этом покупатель выбирает продавца, просматривает его WEB-сайт, принимает решение о покупке, заполняет бланк заказа. Все это делается до вступления в дело протокола SET. Реально взаимодействие участников сделки регламентируется протоколом IOTP. SET начинает свою работу, когда покупатель нажимает клавишу оплаты. При этом сервер посылает ЭВМ-покупателя сообщение, которое и запускает соответствующую программу. Процедура эта может быть реализована с помощью PHP- или CGI-скрипта, или JAVA-аплета.
Программа клиента посылает заказ и информацию об оплате. Для этого формируется два сообщения, одно содержит данные о полной стоимости покупки и номере заказа, второе - номер кредитной карточки покупателя и банковскую информацию. Сообщение о заказе шифруется с использованием симметричного метода (например, DES) и вкладывается в цифровой конверт, где используется общедоступный ключ продавца. Сообщение об оплате шифруется с привлечением общедоступного ключа банка (эмитента кредитной карты). Таким образом продавец не получает доступа к номеру кредитной карточки покупателя. Программа генерирует хэш-дайджест (SHA1) обоих сообщений с использованием секретного ключа покупателя. Это позволяет продавцу и банкиру проконтролировать целостность сообщения, но препятствует прочтению части, ему не предназначенной (например, номера кредитной карты продавцом).
Продавец выделяет часть, адресованную банкиру, и направляет ее по месту назначения. Программа SET WEB-сервера продавца генерирует запрос авторизации серверу банка, где находится счет продавца. При формировании запроса авторизации используется электронная подпись продавца, базирующаяся на его секретном ключе, что позволяет однозначно его идентифицировать. Этот запрос шифруется с помощью ключа сессии и вкладывается в цифровой конверт, где используется общедоступный ключ банка.
Банк проверяет действительность кредитной карточки, дешифрует запрос авторизации продавца и идентифицирует продавца. После этого осуществляется проверка авторизации покупателя. При этом посылается запрос авторизации, снабженный электронной подписью, банку, выпустившему кредитную карточку.
Банк, выпустивший карточку, выполняет авторизацию и подписывает чек, если кредитная карточка покупателя в порядке. Отклик, снабженный соответствующей подписью, посылается банку продавца.
Банк продавца авторизует данную операцию, и посылает подтверждение, подписанное электронным образом, WEB-серверу продавца.
WEB-сервер продавца завершает операцию, выдавая клиенту подтверждение на экран, и заносит результат операции в соответствующую базу данных.
Продавец осуществляет подтверждение выполнения операции своему банку, деньги покупателя переводятся на счет продавца.
Банк, выпустивший карточку, посылает счет покупателю и SET уведомляет покупателя об изменениях на его счету (раз в месяц).
Итак, видно, что каждый шаг реализации протокола SET сопровождается аутентификацией. Это препятствует какому-то внешнему субъекту стать посредником и видоизменять сообщения. Для нормальной работы протокола SET все участники должны зарегистрироваться и снабдить партнеров своим общедоступным ключом.
Протокол SET может использоваться не только в рамках Интернет, но и при заказах по почте или телефону MOTO (Mail Order/Telephone Order). Для понимания основополагающих принципов вышеизложенного могло бы быть достаточно. Более того, квалифицированный программист мог бы написать программы, которые эти принципы реализовали для некоторой замкнутой системы покупатель-банки-продавец. Но функция SET шире, этот протокол рассчитан на международную ничем не ограниченную систему платежей. По этой причине ниже будут приведены некоторые, наиболее важные детали работы протокола, регламентирующие его функционирование.
SET может работать в режиме, когда участники не имеют сертификатов и не прошли аутентификацию. Такой режим сопоставим с использованием SSL для пересылки номера карточки продавцу, и не может рассматриваться как удовлетворительный.
Протокол SET защищает только финансовую информацию, непосредственно сопряженную с платежной транзакцией. Защита информации, содержащейся в заказе, SET не регламентирует.
В SET под владельцем платежной карты подразумевается программа, работающая на рабочей станции клиента-покупателя. Эта программа обеспечивает доступ к серверам продавцов, если требуется, поддерживает диалог между покупателем и продавцом, и реализует платежный процесс. При этом посылается заказ, получается отклик на этот заказ, осуществляются, если требуется, дополнительные информационные запросы и получаются данные о ходе реализации транзакции.
Эта программа выполняет опосредованную связь с получателем. Зашифрованные платежные данные через систему продавца поступают в расчетный центр, где они дешифруются.
Программа продавца предоставляет интерфейс для взаимодействия с программой владельца платежной карты, с программой получателя (Acquirer - банк продавца) и с центром сертификации. Эта программа авторизует транзакцию, инициированную владельцем карты. Выполнение криптографических операций может производиться на аппаратном уровне. Такие криптографические модули могут быть снабжены также аппаратными устройствами генерации и запоминания секретных ключей (например, смарт-карты).
Важной функцией расчетных центров помимо реализации платежей является поддержка списков аннулированных сертификатов CRL (Certificate Revocation List). Это крайне важно для вовлеченных финансовых организаций и фирм предоставляющих платежные средства (например, таких как VISA или MasterCard).
Сертификаты расчетного центра (РЦ) пересылаются банку продавца (получателю) и служат для обработки сообщений авторизации и платежей. Ключ шифрования расчетного центра, который получает владелец карты из сертификата РЦ, используется для защиты информации о счетах владельца карты.
Сам банк продавца (получатель) должен иметь сертификаты для того, чтобы взаимодействовать с сертификационным центром, который может получать и обрабатывать запросы, поступающие непосредственно от продавцов. Банк продавца получает свои сертификаты из платежной системы.
Эмитент карт должен владеть сертификатами, чтобы взаимодействовать с сертификационным центром, который может получать и обрабатывать запросы, поступающие непосредственно от владельцев карт. Эмитент получает сертификаты также из платежной системы.
Протокол SET определяет иерархию сертификационных центров, во главе которой находится RCA (Root Certificate Authority). Далее следуют BCA (Brand-specific CA) и GCA (Geo-political CA). Некоторые платежные системы имеют свои сети, например, VisaNet или BankNet. Эти сети осуществляют авторизацию платежей от эмитента к получателю и имеют свою систему защищенной передачи сообщений.
Цифровая подпись устанавливает соответствие между подписанными данными и уникальным секретным ключом подписанта (покупателя, продавца, банкира или центра сертификации). Секретный ключ математически связан с общедоступным ключом, и таким образом, связывает данные и общедоступный ключ. Фундаментальной целью сертификата является установление соответствия между общедоступным ключом и уникальным идентификатором объекта (или субъекта), гарантируя отсутствие подмены. Следует помнить, что общедоступные ключи пересылаются по незащищенным каналам Интернет. В случае держателя карты сертификат подписи устанавливает соответствие между его общедоступным ключом и индивидуальным кодом PAN (Primary Account Number). Цифровая подпись в сочетании с хэшированием сообщения (вычислением его цифрового дайджеста) гарантирует, кроме того, целостность данного сообщения, блокируя возможность его модификации в процессе пересылки. Сообщения SET следуют рекомендациям ISO/IEC и ITU-T ASN.1 (Abstract Syntax Notation) и кодируется с использованием правил DER (Distinguished Encoding Rules). Механизм пересылки сообщений между объектами SET не регламентируется. Предполагается, что приложения SET могут работать в одном из двух режимов.
Интерактивном, когда объекты взаимодействуют в реальном масштабе времени с малыми задержками между запросами и откликами (например, в рамках технологии WWW).
Не интерактивном, когда задержки между запросом и откликом велики, например, при использовании электронной почты.
В операциях с общедоступными ключами и сертификатами в SET используется алгоритм RSA. Обычно длина ключа составляет 1024 бита и только для Root CA (базового центра сертификации) применяются ключи длиной 2048 бит. Для симметричного шифрования обычно применяется алгоритм DES. Помимо него используется также алгоритм CDMF (Commercial Data Masking Facility), он служит для защиты сообщений между получателем и держателем карты. DES работает с блоками данных 64 бита и предполагает использование для операций шифрования и дешифрования одного и того же 56-битного ключа (каждый байт содержит бит четности). Правила заполнения SET для DES-CBC требуют, чтобы строка заполнителя всегда добавлялась к открытому тексту, подлежащему шифрованию. Заполнитель делает длину блока данных кратной 8 октетам. Алгоритм CDMF осуществляет скремблинг данных, который базируется на DES в несколько облегченной модификации, когда эффективная длина ключа равна 40 бит вместо 56 - для DES.
SET использует усовершенствованный Матиасом и Джонсоном метод хэширования, улучшающий технику OAEP. Базовыми процедурами протокола SET является посылка и прием сообщений. Процесс отправки сообщения представлен в таблице.
Верификация цепочки сертификатов требует, чтобы последовательно проверялся каждый сертификат, и контролировалось его соответствие выпустившему его центру. Например, держатель карты должен проверить сертификаты продавца, центра сертификации продавца, центра сертификации платежной системы (Brand CA), и корневого центра Root CA. Процесс верификации включает в себя следующие компоненты:
- контроль сертификатов X.509;
- контроль сертификатов SET;
- обработку CRL (Certificate Revocation List);
- обработку BrandCRLIdentifier (BCI).
Процедура обработки входящего сообщения рассмотрена в таблице
На практике предполагается, что процесс верификации будет остановлен на уровне, который был успешно пройден ранее. Все приложения SET помимо самих сертификатов контролируют их дату пригодности. Процедура верификации представлена в таблице.
Основу потока платежных сообщений SET составляют пары запрос/отклик, следующие между владельцем карты и продавцом, а также между продавцом и расчетным центром. Основу обмена между владельцем карты и продавцом составляют сообщения PReq/PRes. Сообщение PRes может быть прислано немедленно или спустя некоторое время.
Присылаемая информация зависит от фазы реализации протокола, в которой находится система.
Авторизация продавца в расчетном центре выполняется с помощью сообщений AuthReq/AuthRes. На рисунке показан типичный пример обмена сообщениями при реализации протокола покупки.
На рисунке показаны все возможные сообщения, которые могут иметь место при обработке транзакции (опционные сообщения отмечены курсивом). Следует заметить, что приведенный порядок обмена является рекомендуемым, и допускается его изменение.
Пары сообщений InqReq/InqRes позволяют владельцу карты получать информацию о состоянии транзакции. Запрос InqReq может быть послан в любое время после посылке продавцу PReq. В паре сообщений PReq/PRes владелец карты уведомляет продавца о том, что же он хочет купить. Сообщения AuthRevReq и AuthRevRes используются тогда, когда необходимо возобновить авторизацию. Сообщения CapRevReq и CAPRevRes организуют процесс отмены оплаты покупки, прежде чем сделка будет завершена. Пара CredReq и CredRes сходна с предыдущей парой, но используется после завершения сделки. Сообщения PCertReq/PCertRes обеспечивают для продавца механизм получения сертификата шифрования, который необходим для шифрования сообщения расчетному центру. BatchAdminReq и BatchAdminRes служат продавцу для открытия, закрытия и выяснения статуса транзакции его платежной линии с расчетным центром. Сообщения Error служат для уведомления об ошибках в протоколе или при обработке.
Протокол SЕТ является устойчивым протоколом. Доказательство этого следует из приведенного описания протокола.
SET обладает следующими свойствами:
- мошеннику недостаточно знать реквизиты платежной карты для того, чтобы успешно выполнить SET-транзакцию. Помимо реквизитов карты необходимо иметь закрытый ключ владельца данной карты, а также сертификат соответствующего ему открытого ключа;
- торговая точка при выполнении SET-транзакции точно знает, что владелец карты, совершающий транзакцию, является подлинным, то есть обладает секретным ключом RSA, для которого открытый ключ сертифицирован банком-эмитентом клиента;
- клиент точно знает, что торговая точка, в которой совершается SET-транзакция, является истинной, то есть обладает секретным ключом RSA, для которого открытый ключ сертифицирован обслуживающим банком торговой точки;
- обслуживающий банк точно знает, что владелец карты и торговая точка являются подлинными, то есть обладают сертифицированными ключами;
- информация о реквизитах карты не известна торговой точке;
- торговая точка и владелец карты имеют заверенные подписями соответственно владельца карты и торговой точки подтверждения факта совершения транзакции, что делает невозможным отказ от результатов операции ни одного из участников транзакции.
Сегодня не существует никакого другого (кроме SET) опубликованного устойчивого протокола. Другими словами, на рынке аппаратно-программных решений, реализующих устойчивый протокол для использования в электронной коммерции, не существует альтернативы продуктам, реализующим SET. VISA International предполагает в ближайшее время опубликовать спецификации нового глобального стандарта аутентификации называемого 3D Secure. Однако неочевидно, что этот стандарт будет определять устойчивый протокол.
Протокол SET де-факто является отраслевым стандартом в области пластиковых карт.
Будучи признанным ведущими международными платежными системами (VISA, MasterCard, Europay, AmEx, Diners Club) в качестве стандарта в электронной коммерции, SET де-факто является отраслевым стандартом.
Таким образом, протокол SET является на сегодняшний день единственным открытым и устойчивым протоколом в электронной коммерции.
Транзакции на рынке Форекс
Транзакция - операция по открытию или закрытию той или иной торговой позиции на рынке Форекс. Транзакции отражаются в балансе и истории сделок трейдера.
Forex - международный межбанковский валютный рынок . Особенность его в том, что он не имеет определенного местонахождения, тем не менее, объединяя собой все крупнейшие банки и другие финансовые структуры мира, торгующие на нем валютами разных стран. Кроме того, благодаря существованию современных развитых средств, систем и технологий связи, в его работе может принимать участие каждый.
В чем же заключается работа трейдера , финансового спекулянта, торговца валютами? Цель деятельности на Forex - получение прибыли от торговли валютами. Под влиянием различных факторов - политических, экономических - обменный курс разных валют постоянно меняется, то есть растет или падает. При любом направлении изменения курса возможно получение прибыли.
Крупные участники рынка, национальные банки, крупные коммерческие банки, инвестиционные фонды и др., распоряжаясь огромными средствами, совершают транзакции покупки-продажи валют минимальными размерами лота в миллионы долларов. Они называются операторами рынка. Но, наряду с ними, на рынке Forex существуют мелкие участники, частные инвесторы или трейдеры.
Для того чтобы инвестор, с его небольшими финансовыми средствами мог торговать на рынке валют, существуют фирмы, организации или отделы банков, занимающиеся валютным дилингом - так называемые дилинговые центры и фирмы-брокеры. Они предоставляют трейдеру кредит для торговли и услуги доступа к торговым серверам при помощи специального программного обеспечения или средств связи.
Торговые серверы дают котировки валют. Механизм предоставления кредита называется кредитным плечом. Он увеличивает финансовые средства в распоряжении трейдера для увеличения прибыли. Залог за пользование кредитом называется маржинальным требованием или маржей . Например, для совершения сделки на сумму 1000000 долларов при кредитном плече 1:100, необходима маржа 10000 долларов. Типовые величины кредитного плеча 1:20, 1:50, 1:100, 1:200. Встречается и 1:500.
Заключив контракт с брокером, трейдер открывает у него счет, кладет на него депозит, величиной не меньше маржинального требования, получает специальное программное обеспечение. Все готово для торговли.
Совершение сделок покупки-продажи называется открытием позиции. Трейдер, получив котировки от брокера, анализирует рынок и открывает позицию. Если валюта покупается, такая позиция называется длинной, если продается - короткой. Если, при открытой длинной позиции, цена растет, появляется прибыль или профит. Если падает - убыток или лосс .
При короткой позиции наоборот. В момент закрытия позиции прибыль или убыток фиксируется на счету. Для успешной торговли на Forex трейдер должен давать прибыли расти и обрезать убыток.
Транзакции в информационных технологиях
Транзакция - действие или ряд действий, выполняемых одним пользователем или прикладной программой, которые осуществляют чтение или изменение содержимого базы данных.
Транзакция является логической единицей работы, выполняемой в базе данных. Она может быть представлена отдельной программой, частью программы или даже отдельной командой (например, командой INSERT или UPDATE языка SQL) и включать произвольное количество операций, выполняемых в базе данных. С точки зрения администратора базы данных эксплуатация любого приложения может расцениваться как ряд транзакций, в промежутках между которыми выполняется обработка данных, осуществляемая вне среды базы данных.
Простейшей транзакцией, выполняемой в подобной базе данных, может быть корректировка зарплаты определенного работника, указанного его табельным номером х. Обобщенно подобная транзакция может быть записана, как показано на рисунке.
На рисунке используется обозначение read (staffNo = x, salary), указывающее, что требуется считать элемент данных salary для записи, в которой ключевое значение равно х. В данном примере транзакция состоит из двух операций, выполняемых в базе данных (read и write), и одной операции, выполняемой вне базы данных (salary = salary * 1.1).
Любая транзакция завершается одним из двух возможных способов. В случае успешного завершения результаты транзакции фиксируются (commit) в базе данных, и последняя переходит в новое согласованное состояние. Если выполнение транзакции не увенчалось успехом, она отменяется. В этом случае в базе данных должно быть восстановлено то согласованное состояние, в котором она находилась до начала данной транзакции. Этот процесс называется откатом (roll back), или отменой транзакции. Зафиксированная транзакция не может быть отменена. Если окажется, что зафиксированная транзакция была ошибочной, потребуется выполнить другую транзакцию, отменяющую действия, выполненные первой транзакцией
Такая транзакция называется компенсирующей. Но аварийно завершившаяся транзакция, для которой выполнен откат, может быть вызвана на выполнение позже и, в зависимости от причин предыдущего отказа, вполне успешно завершена и зафиксирована в базе данных. Ни в одной СУБД не может быть предусмотрен априорный способ определения того, какие именно операции обновления могут быть сгруппированы для формирования единой логической транзакции. Поэтому должен применяться метод, позволяющий указывать границы каждой из транзакций извне, со стороны пользователя. В большинстве языков манипулирования данными для указания границ отдельных транзакций используются операторы BEGIN TRANSACTION, COMMIT и ROLLBACK (или их эквиваленты). Если эти ограничители не были использованы, как единая транзакция обычно рассматривается вся выполняемая программа. СУБД автоматически выполнит команду COMMIT при нормальном завершении этой программы. Аналогично, в случае аварийного завершения программы в базе данных автоматически будет выполнена команда ROLLBACK.
Порядок выполнения операций транзакции принято обозначать с помощью диаграммы переходов. Пример такой диаграммы приведен на рисунке. Следует отметить, что на этой диаграмме, кроме очевидных состояний ACTIVE, COMMITTED и ABORTED имеются еще два состояния, описанные ниже.
PARTIALLY COMMITTED. Это состояние возникает после выполнения последнего оператора. В этот момент может быть обнаружено, что в результате выполнения транзакции нарушены правила упорядочения или ограничения целостности, поэтому транзакцию необходимо завершить аварийно. Еще один вариант развития событий состоит в том, что в системе происходит отказ и все данные, обновленные в транзакции, невозможно успешно записать во внешнюю память. В подобных случаях транзакция должна перейти в состояние FAILED и завершиться аварийно. А если транзакция выполнена успешно, то все результаты обновления могут быть надежно записаны во внешней памяти и транзакция может перейти в состояние COMMITTED.
FAILED. Такое состояние возникает, если транзакция не может быть зафиксирована или произошло ее аварийное завершение, когда она находилась в состоянии ACTIVE, Это аварийное завершение могло возникнуть из-за отмены транзакции пользователем или в результате действия протокола управления параллельным доступом вызвавшего аварийное завершение транзакции для обеспечения упорядочиваемости операций базы данных.
Свойства транзакций
Существуют определенные свойства, которыми должна обладать любая из транзакций. Ниже представлены четыре основных свойства транзакций, которые принято обозначать аббревиатурой ACID (Atomicity, Consistency, Isolation, Durability — неразрывность, согласованность, изолированность, устойчивость), состоящей из первых букв названий этих свойств.
Неразрывность. Это свойство, для описания которого применимо выражение "все или ничего". Любая транзакция представляет собой неделимую единицу работы, которая может быть либо выполнена вся целиком, либо не выполнена вообще. За обеспечение неразрывности отвечает подсистема восстановления СУБД.
Согласованность. Каждая транзакция должна переводить базу данных из одного согласованного состояния в другое. Ответственность за обеспечение согласованности возлагается и на СУБД, и на разработчиков приложений. В СУБД согласованность может обеспечиваться путем выполнения всех ограничений, заданных в схеме базы данных, таких как ограничения целостности и ограничения предметной области. Но подобное условие является недостаточным для обеспечения согласованности. Например, предположим, что некоторая транзакция предназначена для перевода денежных средств с одного банковского счета на другой, но программист допустил ошибку в логике транзакции и предусмотрел снятие денег с правильного счета, а зачисление — на неправильный счет. В этом случае база данных переходит в несогласованное состояние, несмотря на наличие правильно заданных ограничений. Тем не менее ответственность за устранение такой несогласованности не может быть возложено на СУБД, поскольку в ней отсутствуют какие-либо средства обнаружения подобных логических ошибок.
Изолированность. Все транзакции выполняются независимо друг от друга. Иными словами, промежуточные результаты незавершенной транзакции не должны быть доступны для других транзакций. За обеспечение изолированности отвечает подсистема управления параллельным выполнением.
Устойчивость. Результаты успешно завершенной (зафиксированной) транзакции должны храниться в базе данных постоянно и не должны быть утеряны в результате последующих сбоев. За обеспечение устойчивости отвечает подсистема восстановления.
Модели транзакций
Модели транзакций делятся на: плоские транзакции, модели вложенных транзакций, модель хроники, модель многоуровневых транзакций, модели рабочих потоков.
Плоские транзакции
Модели плоских транзакций соответствует один управляющий слой, которому подчинено произвольное число элементарных действий. В современных информационных системах - это, как правило, единственная поддерживаемая на прикладном уровне модель транзакций, хотя внутренние компоненты системы (например, SQL) могут включать более изощренные средства обработки транзакций, однако они не доступны на уровне прикладного программирования.
Плоские транзакции - это основные строительные блоки для реализации принципа атомарности, иначе говоря, выделение некоторой последовательности действий в виде плоской транзакции обеспечивает принцип "все или ничего". Во многих прикладных окружениях, в особенности с централизованными обработкой и управлением ресурсами (например, базами данных и файлами), механизм плоских транзакций на протяжении многих лет предоставлял вполне удовлетворительные возможности как для создания, так и для выполнения приложений. Простые преобразования состояний системы вполне укладывались в рамки атомарных единиц работы.
По мере того как данные и вычисления становятся все более распределенными, атомарность плоских транзакций становится значительным неудобством. Согласно правилам обработки плоских транзакций, либо должны успешно завершиться все компоненты глобальной транзакции, либо не должна завершиться ни одна из них. Например, если неудачей завершилось только изменение одной удаленной базы данных под управлением некоторого менеджера ресурсов, то и все остальные компоненты должны быть возвращены в состояние, предшествовавшее началу транзакции. Учитывая количество информации, обрабатываемой в крупной или даже средней организации со множеством серверов LAN на ПК и, возможно, с мобильными базами данных, можно предположить, что вероятность отказа хотя бы одного узла весьма высока. Если применяется модель плоских транзакций, то придется заново выполнять все составные части транзакции, что существенно повышает требования к вычислительным ресурсам и отнимает значительную долю пропускной способности системы.
Очевидно, что в наш век сильно распределенных вычислений необходимо каким-то образом проводить декомпозицию плоских транзакций. Модификация модели плоских транзакций, сохраняющая свойство атомарности, но снижающая потребность в повторном выполнении действий (т. е. в "переработках"), включает понятие контрольных точек, которое мы обсудим в следующем разделе.
Модель вложенных транзакций
Модель вложенных транзакций. Транзакция рассматривается как коллекция взаимосвязанных подзадач или субтранзакций, каждая из которых также может состоять из любого количества субтранзакций. Модель вложенных транзакций была предложена Моссом (Moss) в 1981 году. В этой модели вся транзакция рассматривается как набор связанных подзадач, называемых субтранзакциями, каждая из которых также может состоять из произвольного количества субтранзакций. В данном определении полная транзакция представляет собой древовидную структуру или некоторую иерархию субтранзакций. В модели вложенных транзакций присутствует транзакция верхнего уровня, содержащая некоторое количество дочерних транзакций, каждая из которых, в свою очередь, может включать вложенные транзакции, и т.д. В исходном варианте, предложенном Моссом, выполнять операции в базе данных разрешается только транзакциям самого нижнего уровня (субтранзакциям самого нижнего уровня вложенности).
Приведен пример вложенной транзакции Т1, в которой выполняется резервирование места в гостинице, заказ билетов на самолет и аренду автомобиля. Она включает субтранзакции заказа авиабилетов (Т2), бронирования места в отеле (Т5) и найма автомобиля (Т6). Транзакция заказа авиабилетов тоже является вложенной и состоит из двух субтранзакций: заказа билета для перелета из Лондона в Париж (Т3) и бронирования места на соответствующем рейсе из Парижа в Нью-Йорк (Т4). Завершение работы транзакций должно происходить в направлении снизу вверх. Следовательно, транзакции Т3 и Т4 должны закончить свою работу до завершения работы их родительской транзакции T2, а работа транзакции Т2 должна быть завершена до окончания работы ее родительской транзакции Т1. Однако отмена транзакции на некотором уровне не оказывает влияния на выполнение транзакций более высоких уровней. Вместо этого родительской транзакции разрешается выполнить свою собственную операцию восстановления нормальной работы, воспользовавшись одним из следующих допустимых способов.
Повторить выполнение субтранзакции.
Проигнорировать данный отказ. В этом случае субтранзакция рассматривается как несущественная. В нашем примере несущественной можно считать транзакцию найма автомобиля (Т6) - выполнение всей транзакции оформления заказа может быть продолжено и без нее. Запустить альтернативную транзакцию, называемую резервной субтранзакцией. В нашем примере, если не удастся забронировать место в отеле Хилтон, может быть запущена субтранзакция бронирования места в другом отеле, например Шератон.
Прекратить свое выполнение.
Обновления, выполненные завершенными субтранзакциями промежуточных уровней, должны быть видны только в транзакциях, которые являются по отношению к ним родительскими. Поэтому, когда транзакция Т3 будет завершена, внесенные ею изменения будут видны только в транзакции Т2. Они будут недоступны транзакции Т1 или любой другой транзакции, внешней по отношению к транзакции Т1. Более того, завершение субтранзакции является условно зависимым от нормального завершения или отмены ее родительских транзакций. При использовании данной модели транзакция верхнего уровня обладает всеми четырьмя свойствами (ACID), которыми должны обладать традиционные плоские (не допускающие вложенности) транзакции.
Для модели вложенных транзакций Моссом был предложен и протокол управления параллельным доступом, построенный по принципу жесткой двухфазной блокировки. Субтранзакции родительской транзакции выполняются таким образом, как если бы они были независимыми транзакциями. Субтранзакциям разрешается устанавливать блокировку элемента, если некоторая другая транзакция, уже установившая блокировку, с которой конфликтует данная субтранзакция, является по отношению к ней родительской. Когда субтранзакция завершает работу, установленные ею блокировки наследуются родительской транзакцией. При наследовании блокировки родительская транзакция с большей вероятностью задает исключительный режим блокировки, если и дочерняя, и родительская транзакции устанавливали блокировку одного и того же элемента данных.
Ниже перечислены основные преимущества модели вложенных транзакций.
Модульность. Транзакция может быть разложена на произвольное количество субтранзакций, что способствует повышению степени распараллеливания обработки и расширяет возможности восстановления.
Создание дополнительной степени детализации в механизмах управления параллельным выполнением и восстановлением. Введение нового уровня субтранзакций, помимо уровня основных транзакций.
Достижение распараллеливания обработки в пределах транзакции. Субтранзакции могут выполняться в параллельном режиме.
Возможность управления восстановлением в пределах транзакции. Незафиксированные субтранзакции могут завершаться аварийно, и для них может выполняться откат без каких-либо побочных эффектов для других субтранзакций.
Модель транзакции Хроники
Хроника. Последовательность (плоских) транзакций, которая может передаваться с другими транзакциями.
Концепция хроник (sagas), которая была введена Гарсия-Молина (Garsia-Molina) и Салемом (Salem) в 1987 году, построена на использовании понятия компенсирующих транзакций. СУБД гарантирует, что либо все входящие в хронику транзакции будут успешно завершены, либо будут запущены компенсирующие транзакции, необходимые для устранения достигнутых частичных результатов. В отличие от метода вложенных транзакций, допускающего произвольный уровень вложения, метод хроник разрешает наличие единственного уровня вложения. Более того, для каждой выделенной субтранзакции должна существовать соответствующая компенсирующая транзакция, которая будет семантически правильно аннулировать результаты, достигаемые с помощью данной субтранзакции. Таким образом, если имеется хроника, состоящая из последовательности n транзакций Т1, Т2, ..., Тn с соответствующим набором компенсирующих транзакций С1, C2, ..., Cn, то окончательный результат выполнения хроники будет определяться одной из приведенных ниже последовательностей транзакций.
1.T1, Т2, …, Tn — если вся транзакция была успешно завершена.
2.T1, T2, ..., Ti, Сi-1, ..., C2, С1 — если выполнение субтранзакции Тi было аварийно прекращено.
Поэтому, если обратиться к примеру с резервированием места в гостинице, описанному выше, то при подготовке соответствующей хроники потребуется изменить структуру транзакции с целью удаления вложенной транзакции бронирования авиабилетов: T3, T4, T5, T6.
Вошедшие в хронику субтранзакции представляют собой лист-узлы транзакции верхнего уровня, приведенной в таблице. Не составляет особого труда подготовить и компенсирующие субтранзакции, предназначенные для отмены заказа на авиабилеты, резервирования номера в гостинице и проката автомобиля.
По сравнению с обычными моделями плоских транзакций в хрониках смягчены требования к изолированности отдельных транзакций, поскольку в них допускается выборка промежуточных результатов других параллельно выполняемых транзакций еще до их завершения. Применение хроник оказывается достаточно эффективным в тех случаях, когда входящие в нее субтранзакции относительно независимы и могут быть подготовлены необходимые компенсирующие транзакции, как в рассматриваемом примере. Но в некоторых случаях предварительное определение компенсирующей транзакции может оказаться затруднительным. В этом случае может потребоваться, чтобы было установлено взаимодействие между пользователем и СУБД для определения приемлемой степени компенсации. В других случаях возможность определения компенсирующей транзакции отсутствует. Например, может оказаться невозможным подготовить компенсирующую транзакцию для транзакции по получению наличных денег из автоматического кассового аппарата.
Модель многоуровневых транзакций
Модель вложенных транзакций, требует, чтобы процесс фиксации субтранзакций выполнялся снизу вверх, в направлении транзакции верхнего уровня. Поэтому данную модель принято называть моделью закрытых вложенных транзакций. Это позволяет подчеркнуть, что свойство неразрывности в транзакциях сохраняется до самого верхнего уровня. В противоположность этому, существует и модель открытых вложенных транзакций, в которой неразрывность нарушается и частичные результаты выполнения субтранзакций могут быть доступны вне транзакции. Примером модели открытых вложенных транзакций является модель хроник, рассматриваемая в предыдущем разделе.
Одним из вариантов модели открытых вложенных транзакций является модель многоуровневых транзакции, в которой дерево субтранзакций является сбалансированным. Узлы одного и того же уровня дерева соответствуют операциям одного и того же уровня абстракции в СУБД. Ребра древовидного графа модели многоуровневых транзакций моделируют реализацию операции посредством последовательности операций более низкого уровня. Уровни n-уровневой транзакции обозначаются как L0, L1, …, Ln, где L0 — самый низкий уровень дерева, a Ln — корень дерева. Методы обработки обычных плоских транзакций гарантируют, что на самом низком уровне (L0) конфликты будут отсутствовать. Основная концепция модели многоуровневых транзакций состоит в том, что две операции на уровне Li могут не конфликтовать, даже если их реализации на следующем, более низком уровне Li-1 конфликтуют. Поскольку в ней используется информация о конфликтах на конкретном уровне, модель многоуровневых транзакций позволяет достичь более высокой степени параллельности по сравнению с моделями обработки плоских транзакций.
Модели рабочих потоков
Все обсуждавшиеся в этом разделе модели были разработаны с целью преодоления ограничений, накладываемых моделью плоских транзакций, поэтому не приемлемых для транзакций большой продолжительности. Однако было отмечено, что все эти модели по-прежнему не обладают мощностью, необходимой для удовлетворения потребностей деловых процессов определенных видов. Поэтому были предложены более сложные модели, представляющие собой комбинации моделей открытых и вложенных транзакций. Однако, поскольку эти модели не в полной мере отвечают требованиям ACID плоских транзакций, для них используется более подходящее название — модели рабочих потоков.
Рабочий поток представляет собой некоторый вид деятельности, предусматривающий координированное выполнение множества заданий, осуществляемых различными обрабатывающими субъектами, которые могут представлять собой людей или некоторые программные комплексы (например, СУБД, прикладные программы или службы электронной почты). Рассмотрим пример с подготовкой соглашений о сдаче объектов недвижимости в аренду, который можно найти в учебном проекте DreamHome. Клиент, желающий арендовать некоторый объект недвижимости, устанавливает контакт с соответствующим сотрудником компании, отвечающим за этот объект недвижимости. Этот сотрудник обращается к контролеру компании, в обязанности которого входит проверка кредитоспособности клиента и определение того, может ли компания ему доверять. С этой целью контролер использует соответствующие источники информации, например бюро проверки кредитоспособности. Собрав интересующие его сведения, контролер принимает решение о возможности дальнейшей работы с данным клиентом и сообщает о своем решении сотруднику, который сообщает клиенту о принятом решении.
Перед любыми системами с рабочими потоками стоят две общие проблемы: определение и выполнение рабочего потока. Обе проблемы усложняются тем фактом, что во многих организациях одновременно используется несколько независимых компьютерных систем, предназначенных для автоматизации различных сторон общего процесса. Приведенные ниже определения выделяют основные задачи, которые должны быть решены при определении рабочего потока.
Спецификация задания. Структура выполнения каждого задания, определяемая посредством предоставления набора обозримых извне состояний процесса и набора переходов между этими состояниями.
Требования по координации заданий. Обычно задаются посредством указания зависимостей между процессами выполнения заданий и зависимостей между потоками данных, дополненных условиями завершения рабочего потока.
Требования к корректности выполнения. Ограничения, накладываемые на показатели выполнения рабочего потока с целью обеспечения его соответствия требованиям корректности в данном приложении. Сюда относятся требования по обеспечению устойчивости к отказам, независимости и параллельности обработки, возможностям восстановления и т.д.
Процессам выполнения свойственна семантика открытой вложенности, допускающая доступность промежуточных результатов процесса вне его границ и разрешающая различным компонентам фиксировать результаты своей работы в индивидуальном порядке. Компонентами могут быть другие субъекты обработки, характеризующиеся как семантикой открытой вложенности, так и семантикой закрытых вложенных транзакций, результаты функционирования которых будут доступны для всей системы только после полного завершения работы этого компонента. Следует отметить, что компоненты с семантикой закрытых вложенных транзакций могут состоять только из компонентов с семантикой того же типа. Некоторые из этих компонентов могут расцениваться как жизненно важные, и в случае отказа от их выполнения потребуется прекратить выполнение и их родительских компонентов. Кроме того, могут быть определены компенсирующие и резервные транзакции, речь о которых уже шла выше.
Классификация систем обработки транзакций
С появлением множества стандартизированных систем обработки транзакций нового поколения полезным представляется проведение их классификации с точки зрения спектра предоставляемых ими функций. Подобную классификацию, включающую пять измерений, предложили Абрахам Лефф и Калтон Пу из Колумбийского университета: М - множество машин, P - множество процессов, H - степень неоднородности машин и программного обеспечения, D - множество логических данных,S - множество узлов.
Эта классификация характеризует любую систему обработки транзакций, от простейших (P1, M1, H1, D1, S1) до более сложных многоузловых неоднородных окружений с поддержкой разнотипных наборов данных (Pn, Mn, Hn, Dn, Sn). В статье, написанной в 1991 г., эти авторы представили трехмерную классификацию, которую они применили для оценки различных исследовательских и коммерческих систем.
Обработка транзакций
Обработкой транзакции,в информационных технологиях, называется обработка информации, разделенная на отдельные неделимые операции, называемые транзакциями. Каждая транзакция должна быть успешной или неудачной как единое целое, она не может оставаться в промежуточном состоянии.
Обработка транзакций направлена на поддержание компьютерной системы (как правило, базы данных или каких-либо современных файловых систем) в известном, согласованном состоянии, путем обеспечения того, чтобы любые операции, осуществляющиеся в системе, являются взаимозависимыми и либо все успешно завершены, либо полностью и успешно отменены.
Например, рассмотрим типичную банковскую транзакцию, которая включает в себя перемещение $ 700 с сберегательного счета клиента на расчетный счет клиента. Эта транзакция является одной операцией для банка, но она включает в себя, по крайней мере, две отдельные операции в компьютерных терминах: зачисляются на депозитный счет $ 700, а также кредитуется расчетный счет на $ 700. Если дебетовые операции прошли успешно, а кредитные нет (или наоборот), в книгах банка не будет остатка на конец дня. Поэтому должен быть способ гарантировать, что обе операции либо имели успех, либо провалились, так что никогда не бывает каких-либо несоответствий в базе данных банка в целом. Обработка транзакций предназначена для обеспечения этого.
Обработка транзакций позволяет нескольким отдельным операциям автоматически быть связанными друг с другом, как единая неделимая транзакция. Системы обработки транзакций гарантирует, что либо все операции в транзакции завершены без ошибок, либо ни одна из них. Если некоторые из операций завершены, но с ошибками, а другие без, системы обработки транзакций дает команду на «откат» всех операций транзакции (в том числе удачных), что означает стирание всех следов операции и восстановление системы до согласованного известного состояния, которое было до начала процесса транзакции. Если все операции транзакции завершены успешно, то транзакция фиксируется в системе, и все изменения в базе данных становятся «постоянными» (commited). Транзакции не могут быть отменены, если они уже были сделаны.
Обработка транзакций защищает от аппаратных и программных ошибок, которые могут оставить транзакцию, завершенной частично, с системой, оставленной в неизвестном, противоречивом состоянии. Если в компьютерной системе происходит сбой в середине транзакция, обработка транзакций гарантирует, что все операции в любых незафиксированных (то есть, не полностью обработанных) транзакциях будут отменены.
Транзакции оформлены в строгом хронологическом порядке. Если сделка N+1 намерена коснуться той же части базы данных что и транзакция N, транзакция N+1 не начинается до момента совершения транзакции N. До совершения любых транзакций, все остальные транзакции, затрагивающие ту же часть системы, также должны быть завершены. Не может быть никаких «дырок» в последовательности предыдущих транзакций.
Методология транзакций
Основные принципы всех систем обработки транзакций одинаковы. Однако терминология может варьироваться от одной системы обработки транзакций до другой, и термины, используемые ниже, не обязательно являются универсальными.
Откат транзакции
Системы обработки транзакций обеспечивают целостность базы данных при помощи записи промежуточного состояния базы данных перед её изменением, а затем, используя эти записи, восстанавливают базу данных до известного состояния, если транзакция не может быть совершена. Например, копии информации в базе данных до ее изменения транзакцией, делаются системой перед транзакцией, которая может сделать любые изменения (иногда это называют before image). Если какая-либо часть транзакции не удается до ее совершения, эти копии используются для восстановления базы данных в состояние, в котором она находилась до начала транзакции (Rollback).
Прогон транзакции
Кроме того, можно вести отдельный журнал всех изменений базы данных (иногда это называется after images), это не требует отката неудачных операций, но это полезно для обновления базы данных в случае отказа базы данных, поэтому некоторые системы обработки транзакций обеспечивают эту функцию. Если база данных отказывает совсем, она должна быть восстановлена из последней резервной. Резервные не будут отражать операции, совершенные после ее создания. Однако, как только будет восстановлена база данных, журнал after images может быть применен к базе данных (rollforward), чтобы привести ее в актуальное состояние. Любые транзакции, которые находятся в процессе на момент сбоя, могут быть свернуты. Результат представляет собой базу данных в известное согласованное состояние, которое включает результаты всех транзакций, совершенных до момента отказа.
Взаимная блокировка транзакций
В некоторых случаях, две транзакции могут в ходе их обработки пытаться получить доступ к одной и той же части базы данных в одно и то же время, таким образом, что это будет препятствовать их совершению. Например, транзакция А может получить доступ к части Х базы данных, и транзакция В может получить доступ к Y части базы данных. Если в этот момент транзакция А пытается получить доступ к части Y базы данных, в то время как транзакция B пытается получить доступ к части X, возникает ситуация взаимоблокировки, и ни одна транзакция не может быть произведена. Системы обработки транзакций предназначены для обнаружения таких ситуаций. Обычно обе транзакции отменяются и производится откат, а затем они автоматически запускаются в другом порядке, так что взаимоблокировка не повторится. Или иногда, только одна из транзакций, попавших в тупик, отменяется, производится откат, и автоматически повторяется после небольшой задержки.
Взаимоблокировки могут происходить между тремя или более транзакциями. Чем больше транзакции связаны, тем труднее их обнаружить. Системы обработки транзакций даже установили практическое ограничение на тупиковые ситуации, которые они могут обнаружить.
Внедрение транзакций
Стандартное программное обеспечение обработки транзакций, в частности, Информационная система управления IBM, были впервые разработана в 1960-е годы, и часто тесно связаны с определенными системами управления базами данных. Клиент-серверные вычисления осуществлялись аналогичными принципами в 1980-е годы с переменным успехом. Однако в последние годы, распределенная клиент-серверная модель стала значительно более сложной в обслуживании. Так как число транзакций выросло в ответ на увеличение числа различных онлайновых услуг (особенно в Интернете), практического решения для одной распределенной базы данных не было. Кроме того, большинство онлайн-систем состоят из целого набора программ, работающих вместе, в отличие от строгой модели клиент-сервер, где один сервер мог справляться с обработкой транзакций. Сегодня есть целый ряд систем обработки транзакций, которые работают на межпрограммном уровне и которые работают в масштабах больших систем, включая мейнфреймы.
Основным открытым отраслевым стандартом является X/Open Distributed Transaction Processing (DTP) (см. JTA). Однако, проприетарное среды обработки транзакций такие, как CICS компании IBM по-прежнему очень популярны.
Внедрение современной обработки транзакций сочетает в себе элементы объектно-ориентированной стойкости с сохранением традиционного мониторинга транзакций. Одним из таких внедрений является коммерческий DTS/S1 продукт от Obsidian Dynamics.
Транзакция в психологии
Транзакция - единица коммуникативного процесса (социального взаимодействия), состоящая из коммуникативного стимула и коммуникативной реакции (напр., вопрос-ответ). Основное понятие транзак-тного анализа. Одна из основных когнитивных теорий — транзактный анализ (ТА). Теория ТА была сформулирована Эриком Берном в начале 1960-х годов.
В 1956 году Берну было отказано в членстве в Институте психоанализа. Этот отказ стал поворотной точкой в его жизни. Он ответил на него отходом от психоанализа и посвятил свое время развитию транзактного анализа, который имел психоаналитический оттенок.
Транзактный анализ является оптимистической теорией. Его основное предположение состоит в том, что люди могут измениться, несмотря на любые неудачные результаты в прошлом.
ТА является антидетерминистическим подходом. Его приверженцы полагают, что люди имеют широкие возможности выбора в своей жизни: то, что было однажды решено, может быть позднее пересмотрено и изменено.
ТА сосредоточивается на четырех главных методах понимания и предсказания человеческого поведения.
Структурный анализ: понимание того, что происходит внутри индивида:
- анализ транзакций: описание того, что происходит между двумя или более людьми;
- анализ игр: понимание транзакций между людьми, которые приводят к чувству дискомфорта;
- анализ сценариев: понимание жизненного плана, которому следует человек.
ТА-терапия предписывает консультанту инициирующую роль учителя.
Сначала он должен объяснить клиенту язык и понятия ТА, новый способ мышления о себе.
После того как это будет выполнено, консультант заключает контракт с клиентом на осуществление определенных изменений и помогает ему достичь их. В сущности, консультант помогает клиенту получить способы (то есть навыки), необходимые для изменения существующего положения, и позволяет ему произвести конструктивные изменения с помощью различных приемлемых методов.
ТА-консультанты не слишком полагаются на формальные психологические тесты, хотя консультант оценивает функционирование клиента. Оценка обычно делается с помощью эгограмм или других, менее формальных методов. Цель состоит в том, чтобы определить, как клиент проводит время и из какого эго-состояния он действует.
Цели транзактного анализа
Главные цели ТА сосредоточиваются на помощи клиентам преобразовать себя из «лягушек» в «принцев и принцесс». Человеку мало научиться просто адаптироваться, как это принято в психоанализе. Вместо этого акцент делается на достижении здоровья и автономии. Консультанты помогают своим клиентам идентифицировать и затем восстанавливать искаженные или поврежденные эго-состояния, развивают способность использовать все эго-состояния, применять эго-состояние взрослого с его рассудительной способностью, переписывать неконструктивные жизненные сценарии и занимать позицию «Я — ОК, ты — OK.
Становясь автономными, клиенты демонстрируют больше понимания, открытости и непосредственности, становятся свободными от игр и избавляются от неконструктивных сценариев. Они начинают лучше взаимодействовать со своим прошлым, но в то же самое время остаются свободными от отрицательных влияний прошлого. ТА придает особое значение изучению собственного «Я», с тем чтобы решить, кем человек хочет стать.
Техники транзактного анализа
ТА ввел ряд новых техник для оказания помощи клиентам в достижении своих целей. К числу наиболее общих из этих техник относятся: структурный анализ, транзактный анализ, анализ игр, анализ сценариев.
Имеется еще целый ряд техник.
Терапевтический контракт: определенный, конкретный контракт, который подчеркивает согласованные обязанности консультантов и клиентов. Контракт позволяет каждому из них знать, при каких условиях цели консультирования можно считать достигнутыми.
Дознание: включает в себя обращение ко взрослому эго-состоянию клиента до тех пор, пока консультант не получит «взрослый» ответ. Прием может оказаться очень конфронтационным. При неквалифицированном применении дознание окажется неэффективным и позволит получить только хронологический материал.
Уточнение: идентификация эго-состояния, которое инициировало транзакцию. Уточнение осуществляется от эго-состояния взрослого, как клиента, так и консультанта.
Конфронтация: консультант указывает клиенту на непоследовательность в его поведении или речи. Использование этого приема в ТА ненамного отличается от его применения другими теориями.
Объяснение: происходит между эго-состояниями взрослого. Консультант разъясняет клиенту некоторые аспекты ТА.
Иллюстрация: направлена на просвещение клиента или разъяснение какого-либо пункта. Иллюстрация — это рассказ, который является часто юмористическим и может быть обращен и к ребенку, и ко взрослому эго-состоя-ниям клиента. Подтверждение: Применяется в случаях, когда ранее измененное поведение проявляется повторно, и консультант указывает на это клиенту. Этот прием может быть эффективным только тогда, когда у клиента твердо сформировалось эго-состояние взрослого.
Интерпретация: консультант обращается к эго-состоянию ребенка клиента и объясняет причины его поведения. Этот прием является, главным образом, психодинамической процедурой и используется только когда клиент имеет эффективно функционирующее эго-состояние взрослого.
Кристаллизация: Состоит из транзакции между Взрослыми, в которой клиент осознает, что человек может прекратить играть в игру, если он сильно этого захочет. Следовательно, клиент свободен поступать в соответствии со своим выбором, и процесс ТА на этом фактически заканчивается.
Почти все методы в ТА включают в себя некоторую комбинацию опроса, конфронтации и диалога. Вот перечень вопросов, которые наиболее часто задают ТА-консультанты.
Что из того, что ваши родители когда-либо говорили вам, было самым хорошим и самым плохим?
Какое ваше самое раннее воспоминание?
Что в вашей семье рассказывали относительно вашего рождения? Какая ваша любимая сказка, рассказ или песня?
Как бы вы описали вашу мать и отца? Как долго вы собираетесь прожить?
Чтобы быть наиболее эффективным, ТА-консультант должен всегда быть осторожен при определении силы эго отдельных клиентов. Клиент обычно становится способен к выработке новых жизненно важных решений, по мере того, как он обнаруживает новые аспекты своего «Я».
ТА в настоящее время разделяется на три главные терапевтические школы: классическая школа, школа катексиса и школа перепринятия решений. Все три школы используют контракты в качестве своего главного метода вмешательства и имеют своей заключительной терапевтической целью достижение автономии.
ТА имеет несколько отличительных особенностей.
В подходе используются легко понимаемые и четко определенные термины. Благодаря своей ясной терминологии ТА может использоваться в различных условиях с различными категориями людей, например, со школьниками, которые хотят преодолеть трудности с математикой.
Подход легко и эффективно комбинируется с другими, более действенно-ориентированными теориями консультирования. Совместное использование ТА и гештальт-терапии оказалось наиболее плодотворным.
Согласно теории ТА, ответственность за терапевтические изменения возлагается на клиента. Индивид может выбирать, изменяться или оставаться тем же самым человеком.
Подход ориентирован на цель. Договорный характер процесса консультирования позволяет и консультантам, и клиентам заранее знать, при достижении каких результатов лечение должно быть закончено.
Однако ТА имеет ограничения.
Подход критикуется за его преимущественно когнитивную ориентацию. Понимание — это только начало изменения. ТА обеспечивает понимание, но до тех пор, пока подход не будет скомбинирован с другой, более действенно-ориентированной теорией, он обладает ограниченной эффективностью.
Подход критикуется за его упрощенность, схематизм и популярность.ТА является настолько широко известным, что некоторые люди используют его терминологию, но не применяют теорию. Эти люди интеллектуализируют свои проблемы, но мало что предпринимают, чтобы изменить ситуацию (действительно, в основе ТА лежит добротная теория, но нет столь же добротных методов практического воплощения теории).
Подход не настаивает на аутентичности консультанта (Corey, 1996). В процессе консультирования консультант и клиент считаются равными. Однако, в отличие от подхода Роджерса, в ходе консультирования личности консультанта уделяется незначительное внимание.
Подход не обеспечен сильной исследовательской поддержкой. Для обучения населения умению пользоваться транзактным анализом необходимы определенные методологические усовершенствования (Miller & Capuzzi, 1984).
Подход не претерпел сколько-нибудь значительного развития со времени смерти Э. Берна в 1970 году. Хотя в теории выделились отдельные направления и появились школы ТА, количество новых идей было незначительным. Кроме того, не появилось никаких значительных теоретиков или последователей ТА (в США). Если не произойдет обновления теории и не появятся новые сторонники ее применения, ТА может потерять свое значение одного из главных методов консультирования.
Источники и ссылки
world-and-money.blogspot.com - финансовы блог
poiskslov.com - словари русского языка и решение кроссвордов онлайн
mirslovarei.com - мир словарей
banker.ua - украинский банковский портал
forex-investor.net - сайт компании Forex Investor
mosbankirs.ru - кредиты, ипотека, отделения банков Москвы
db-info.ru - информационный портал о базах данных и СУБД
baza-referat.ru - база рефератов
credit-card.ru - сервис выбора кредитных карт
ya.ru - поисковая система интернета
google.com - поисковая система интернета
youtube.com - видеохостинг
maxiforex.ru - сайт о рынке Форекс
forex-start.com - всё о рынке Форекс
hr-portal.ru - HR сообщество и публикации
malb.ru - малый бизнес шаг за шагом