Обеспечение безопасности в ФСГ

Федеральная Система «Город-Волгоград»

Оглавление

Обеспечение безопасности в ФСГ. 1

Глава 1. О мерах по обеспечению конфиденциальности информации, передаваемой в Систему «Город» 3

1.1. Основной режим.. 3

1.2. Дополнительный режим.. 3

1.3. Резюме. 3

Глава 2. Защита рабочего места по приёму платежей ФСГ на основе терминального сервера. 3

2.1. Защита компьютера оператора. 3

2.2. Защита трафика. 3

Глава 3. Описание Архитектуры WEB – Mailex. 3

3.1. Архитектура. 3

3.2. Требования к рабочему месту. 3

3.3. Защита данных. 3

О мерах по обеспечению конфиденциальности информации, передаваемой в Систему «Город»

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

1.  С юридической точки зрения, гарантия конфиденциальности передаваемой информации оговаривается в Договоре, заключаемом между Системой «Город» и Вашим банком.

2.  С технической точки зрения, информация Системы «Город» хранится в таблицах СУБД Oracle – защищенной системе управления базой данных, обеспечивающей безопасность хранимых данных на уровне современных мировых стандартов. В состав СУБД Oracle входят средства контроля прав доступа, которые обеспечивают гибкое и эффективное управление правами различных пользователей на работу с хранимой информацией.

НЕ нашли? Не то? Что вы ищете?

3.  Обмен информацией между рабочим местом кассира и БД Системы «Город», происходящий в закодированном виде, исключает возможность ее перехвата третьими лицами «по пути».

4.  Можно выстроить порядок, при котором реестр платежей формируется без использования данных об абоненте (например: только № Договора, дата и сумма оплаты). Таким образом, при идентификации абонента будет использоваться полная информация о клиенте, а при составлении агентом-сборщиком платежей реестра для Вашего банка – урезанная.

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

6.  Системой предусмотрена персонификация ответственности за конфиденциальность информации. Система ежедневно автоматически формирует реестры собранных платежей. После формирования реестры становятся доступными для получения их ответственным сотрудником банка-кредитора.

7.   

В связи с изложенным выше, мы предлагаем на Ваше рассмотрение два режима работы, на которые, индивидуально для каждого поставщика услуг, может быть настроена Система «Город».

1.1. Основной режим

Система имеет следующую информацию об абоненте:

    минимально – номер договора и задолженность на дату отправки реестра;

максимально - Ф. И.О., адрес, номер договора, сумма задолженности и период, за который она образовалась.

1.1.1. Преимущества основного режима работы

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

1.1.2. Недостатки основного режима работы

В момент приема платежа кассиру на мониторе будет видна конфиденциальная информация об абоненте Вашего банка.

1.2. Дополнительный режим

Система не имеет информации о задолженностях абонента, а только информацию, его идентифицирующую, и платежные реквизиты Вашего банка.

1.2.1. Преимущества дополнительного режима работы

Ваш банк передает в Систему информацию о своих абонентах, но не афиширует размер их вносов по кредитам.

1.2.2. Недостатки дополнительного режима работы

Абонент может по каким-либо причинам заплатить неправильную сумму, при этом, если она оказалась меньше требуемой, возникнет необходимость начислить пени, что приведет к ухудшению отношений с ним, а если больше – либо делать возврат, либо учитывать ее в авансовых платежах, что приведет к дополнительной работе бухгалтерии и усложнению системы внутреннего контроля.

1.3. Резюме

Таким образом, Вам предстоит определиться с приемлемым уровнем конфиденциальности информации, передаваемой в Систему «Город», находя разумную середину между минимизацией предоставляемых сведений и вероятностью ошибок при приеме платежей. При этом следует учитывать, что с помощью минимизации объема передаваемой конфиденциальной информации Вы, с одной стороны, сможете максимально защититься от внешних попыток проникнуть в базу клиентов и внутреннюю кредитную политику Вашего банка, а с другой – получите увеличение вероятности ошибок операторов и объема работы бухгалтеров по разноске электронных реестров Системы. Кроме того, при этом придется смириться с увеличением временных затрат на разъяснительную работу с Вашими клиентами.

Надеемся, что приведенная выше информация относительно мер по обеспечению конфиденциальности сведений, предоставляемых в Систему «Город», носила исчерпывающий характер, и Вы получили ответы на все Ваши вопросы. Во всем остальном остаемся в Вашем полном распоряжении.

Защита рабочего места по приёму платежей ФСГ на основе терминального сервера.

1.4. Защита компьютера оператора.

Как и при работе с любой системой, если злоумышленник установит на рабочем месте вредоносное программное обеспечение, он может действовать от имени оператора. Так как ФСГ физический и сетевой доступ к рабочему месту оператора не контролирует, это ответственность Агента.

1.5. Защита трафика.

Рассматривается два варианта.

1.5.1. Основной вариант. Защита трафика от рабочего места до ФСГ.

На компьютере оператора ставится клиентская часть программного обеспечения CFT-VPN. Сертификат сервера присутствует у клиента с момента инсталляции ПО. При регистрации в Системе оператор получает закрытый ключ и X.509 сертификат клиента. Терминальный клиент на стороне оператора настраивается на работу с локальным хостом, в качестве которого выступает клиентская часть CFT-VPN. Сертификат клиента явно регистрируется на CFT-VPN со стороны ФСГ.

При открытии сессии:

Клиент CFT-VPN направляет серверу CFT-VPN запрос инициализации сессии. Сервер формирует непредсказуемое число, подписывает его своей ЭЦП и высылает клиенту. Клиент проверяет подпись сертификатом сервера, формирует разделяемый секрет, который шифруется сертификатом сервера. Пакет, включающий шифрованный секрет и непредсказуемое число сервера, подписывается клиентом. Сервер проверяет подпись клиента, убеждается в том, что сертификат клиента зарегистрирован и что подписанное клиентом непредсказуемое число совпадает с отправленным ему значением. Уникальный идентификатор сертификата передаётся приложению для идентификации клиента. Разделяемый секрет расшифровывается и используется для защиты тела транспортных пакетов (применяется шифрование и контроль целостности путём проверки MAC). Трафик защищается в обе стороны.

1.5.2. Второй вариант. Защита трафика от Агента до ФСГ.

Центр работает с Агентом по VPN. Защита трафика от рабочего места оператора до Агента – ответственность Агента.

Обмен реестрами. Описание Архитектуры WEB – Mailex

Приложение Web-Mailex реализует Web-интерфейс для отправки и получения реестров в системе ГОРОД. Конфиденциальность информации обеспечивается при помощи шифрования канала связи (HTTPS), –целостность и достоверность - при помощи электронно-цифровой подписи.

1.6. Архитектура

1.7. Требования к рабочему месту

    Персональный компьютер с центральным процессором архитектуры IA-32 с предустановленной операционной системой Microsoft Windows 2000 или Microsoft Windows XP. Браузер Microsoft Internet Explorer версии 5.5 и выше с поддержкой 128 битного шифрования Более 20 Мб свободного места на локальном жестком диске.

1.8. Защита данных

Защита данных обеспечивается как на канальном уровне (SSL соединение), так и на прикладном (при помощи ЭЦП запросов пользователей).

1.8.1. Аутентификация и авторизация

ü  При установлении SSL соединения используется двухсторонняя аутентификация с взаимной проверкой сертификатов обеих сторон (пользователя и сервера).

ü  Авторизация пользователя в системе выполняется на основе проверки ЭЦП авторизационного запроса.

ü  Сертификат пользователя должен быть зарегистрирован во внутренней базе данных сервера.

ü  Авторизованный пользователь имеет право на выполнение прикладных операций: получение данных о реестрах, обмен реестрами.

ü  Все действия пользователей в системе журналируются.

1.8.2. ЭЦП

В системе используется формат XML Signature. Целостность файлов обеспечивается проверкой хэш-кода.