Новости

Практическая криптография в банках

При оказании финансовых услуг физическим и юридическим лиц банкам приходится заботиться не только о конкурентноспособных процентных ставках, выгодных условиях кредитования и эффективном обслуживании клиентов, но и о безопасности. Модули криптографии встраиваются в банковские информационные системы и обеспечивают безопасность данных, предоставляющих коммерческий интерес для злоумышленников. Однако без соответствующих лицензий применять криптоалгоритмы финансовые компании не вправе. Как быть? В этой колонке мы попытались рассказать, что и как подлежит лицензированию в банковских ИС.

Криптоалогритмы используются в "толстых" клиентах "клиент--банк", с которыми сегодня работают юридические лица, и в "тонких" клиентах, например в решениях Интернет-банкинга. Помимо этого, криптоалгоритмы позволяют проверять авторство и целостность электронных документов по ЭЦП (электронной цифровой подписи) и могут использоваться для организации безопасного электронного документооборота в банке. Банковские услуги, связанные с использованием и распространением шифровальных алгоритмов и средств, требуют получения соответствующих лицензий -- это определяется постановлением Правительства РФ от 23 сентября 2002 г. № 691 "Об утверждении Положений о лицензировании отдельных видов деятельности, связанных с шифровальными (криптографическими) средствами". Иначе говоря, в лицензировании нуждаются все системы, которые реализуют алгоритмы криптографического преобразования информации и шифрования данных при передаче по каналам связи, а также программные средства цифровой подписи, обеспечивающие верификацию документов и проверку их подлинности на основе криптографических преобразований.

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

Российские криптографические системы на уровне алгоритмов достаточно криптостойки и надежны, однако их реализация в виде конечного продукта порой хромает. К примеру, до сих пор некоторые криптографические программы работают под DOS -- они появились 15 лет назад и с тех пор не переводились на новые платформы. Справедливости ради нужно отметить, что в отличие от других продуктов российский рынок средств криптозащиты невелик и достаточно монополизирован -- это, собственно, и замедляет рост инвестиций в разработку модулей криптографии с современными возможностями, интерфейсами, гибкостью и функционалом.

Кроме того, существует проблема несовместимости криптоалогоритмов, созданных российскими разработчиками на основе стандартов ГОСТа. Так, если двумя разными фирмами разработаны криптографические продукты на базе одного и того же стандарта, то в конечном счете они "не поймут" друг друга. Несовместимы они и с западными продуктами.

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

Между тем можно предложить очень простое решение этой проблемы: надо провести разграничение между "коммерческой" или общей и государственной криптографией. Коммерческая криптография должна опираться на одинаковые стандарты во всем мире, поскольку современный бизнес, а тем более банковский, нередко выходит за рамки отдельно взятой страны. Государственные же стандарты на криптографию нельзя распространять где-либо, они будут использоваться в пределах госструктур и, как это делается в США, обновляться каждые пять лет (на уровне алгоритма). К самому этому алгоритму коммерческие структуры не должны иметь доступа. Таким образом, удастся одновременно применять общедоступные "коммерческие" алгоритмы и обеспечивать сохранность гостайны.

Говоря о процедуре сертификации, прежде всего отметим, что банкам совершенно не обязательно иметь целиком сертифицированную информационную систему. Многие современные решения состоят из "кубиков", одним из которых как раз и является криптоалгоритм. При этом "кубик" или модуль, который реализует криптозащиту, представляет собой "черный ящик", в который входит исходная информация, а выходит зашифрованная. Этот модуль и должен быть сертифицирован. Корпоративные клиенты, получая ПО "клиент--банк" или частные клиенты с клиентскими модулями для управления счетами через Интернет, могут поинтересоваться наличием сертификата на модуль криптозащиты.

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

Западные компании (к примеру, банки, которые выходят на российский рынок) оказываются в еще более сложном положении -- они вынуждены предоставлять исходные коды банковских систем, подлежащих лицензированию. Однако именно эти коды, как правило, защищены авторским правом и лицензиями другой страны. Можно ли легализовать западные средства и как это сделать? Один из способов, далеко не самый лучший, таков: продолжать использование западных средств, получив разрешение на их импорт. При этом банк вынужден будет объяснять, почему используется этот алгоритм, и доказывать, что именно эта криптографическая система необходима для решения бизнес-задач. Другой, более простой подход -- использовать решения западных вендоров (ПО или оборудование), в которые дистрибьюторы или российские представительства западных вендоров встраивают ГОСТовские криптоалгоритмы. Таким образом, функционал решения можно полностью сохранить и в то же время, не нарушая российского законодательства, применять его в банках и других предприятиях. Одним из примеров такого устройства западного производителя стал SSL VPN шлюз iGate американской компании SafeNet (дистрибьютор в России -- компания Rainbow Technologies) для защищенного удаленного доступа, необходимого для систем Интернет-банкинга.

Российская федеральная служба по техническому и экспертному контролю уже начала работать в направлении упрощения сертификации и лицензирования западных продуктов. Однако пока дело не продвинулось дальше перевода и формального введения в действие соответствующего стандарта: ИСО/МЭК 15408 - 2002. Поэтому на практике получается, что решение, которое прошло сертификацию в другой стране, нуждается в переводе технической документации на русский язык и проведении сертификации по тем же общим критериям.

Еще одна область, где применяются криптоалгоритмы, связана с ЭЦП, генерацией и идентификацией ключей. В России закон об ЭЦП пережил два изменения, в стадии разработки находится и третья редакция. В принципе этот закон нужен, но в том виде, в котором он реализован сейчас, он практически бесполезен. Первая редакция закона оказалась неудачной. Ко второй версии появились и начали работать удостоверяющие центры, однако массового внедрения ЭЦП не произошло -- ведь нужно решить вопрос не только получения ключей, но и их последующего использования. К примеру, прежняя редакция усложнила процедуру смены ключей, и операционисты должны были сравнивать сертификаты практически вручную. В условиях стремительного роста розничных банковских услуг и соответственно клиентской базы это серьезно замедляло работу. Таким образом, чтобы сделать закон о цифровой подписи по-настоящему жизнеспособным, его еще предстоит изменить и дополнить.


Роман Косичкин, технический специалист компании Rainbow Technologies.

Дэян Момчилович, руководитель отдела по работе с партнерами компании Rainbow Technologies.

Использование материалов этой статьи без согласования с редакцией журнала "Intelligent Enterprise" запрещено.

Возврат к списку

 

Защита банкоматов

Имя* Компания* Email* Телефон

* - Поля, обязательные для заполнения

Компрометация приложений для смартфонов

Имя* Компания* Email* Телефон

* - Поля, обязательные для заполнения

Семинар ATAR

Фамилия* Имя* Должность* Компания* Email* Телефон* Защита от автоматического заполнения Введите символы с картинки*

* - Поля, обязательные для заполнения

Заполните поля

Защита от автоматических сообщений
CAPTCHA
Введите слово на картинке*

Заполните поля

Защита от автоматических сообщений
CAPTCHA
Введите слово на картинке*

Для получения БЕСПЛАТНОГО БИЛЕТА заполните, пожалуйста, Форму:

Количество билетов ограничено

Фамилия* Имя* Отчество* Название компании* Должность* Телефон рабочий* Телефон мобильный* E-mail*

* - Поля, обязательные для заполнения