図 1。

についての研究は何ですか

私たちの研究の最初の部分では、経済的な観点から銀行のキャッシュレス支払いシステムの運用を検討しました。 次に、これらの支払いを実現する銀行のITインフラストラクチャの内部構造を見てみましょう。

免責事項
記事には機密情報は含まれていません。 使用されるすべての資料は、ロシア銀行のウェブサイトを含むインターネットで公開されています。

第1章ITインフラストラクチャの一般的な説明

主な用語

前世紀の90年代、 ロシアのFSTECの GOSTおよび規制文書​​（ロシア連邦大統領の下の国家技術委員会）では、この用語がよく使用されます- 自動システム 。 「GOST 34.003-90情報技術（IT）。 自動化システムの一連の標準。 自動化システム。 用語と定義」は、この用語の次の定義を示します。

自動化システム ; AC：確立された機能を実行するための情報技術を実装する、人員とその活動のための自動化ツールのセットで構成されるシステム。

しばらくして、 情報システムという新しい用語が使用されるようになりました。 アートの段落3。 2006年7月27日の連邦法第2項N149-「情報、情報技術、および情報保護」では、この用語は次のように定義されています。

情報システム -データベースに含まれる一連の情報と、その処理を保証する情報技術および技術的手段。

この研究の目的のために、両方の用語は同義で使用されます。

このアプローチの妥当性は、2013年2月11日付ロシア連邦FSTEC命令N 17の情報システムの保護に関する 「国家情報システムに含まれる国家秘密ではない情報の保護要件の承認」 において、国家規制当局が自動化システムの国家標準に導かれるよう命じているという事実によって証明できます 。

情報システムに加えて、銀行のITインフラストラクチャでは、 情報サービス 、またはしばしばロボットと呼ばれる別のタイプの要素を区別できます。

情報サービスの概念を定義することは非常に難しいので、 情報システムとの主な違いを列挙してください 。

1. 情報サービスは 情報システムよりもはるかに単純ですが、同時に複数の情報システムがその作業の結果を使用できるため、後者のコンポーネントと呼ぶことはできません。
2. 情報サービスは、単純な日常業務を自動化するように設計されています。
3. 情報サービスにはデータベースが含まれていません。
4. 情報サービスは、人が参加することなく（または最小限の参加で）自動的に動作します。

自動銀行システム

銀行の情報インフラストラクチャの中核は、 自動化された銀行システムまたはABSと略されます。

ロシア銀行標準STO BR IBBS-1.0-2014「ロシア連邦の銀行システムの組織の情報セキュリティの確保。 一般」では、 ABSを次のように定義しています。

銀行技術プロセスを実装する自動システム。

この定義により、銀行のほぼすべてのITシステムを要約できます。 同時に、普通の銀行の従業員は、 ABSを銀行口座、銀行口座間の取引（キャッシュフロー）、および残高を考慮するシステムと呼びます。 2番目の定義は、1番目の定義と矛盾せず、より明確に定義しているため、さらに使用します。

現代のロシアの銀行で最も一般的なのは、次のABSです。

• Diasoft FA＃ 、
• 21世紀の反転 、
• RS-Bank 、
• CFT銀行 。

一部の、特に大規模な銀行は流通を使用していませんが、 ABS向けに特別に設計されています。 しかし、そのようなケースは、特に大規模な銀行と同様に、実際にはまれです。

銀行は異なるメーカーの複数のABSを同時に使用することがあります。 これは、銀行がABSから別のABSに切り替えようとしたときによく発生しますが、ささいな理由はありません。

応用情報システム

ABSはかなり多数のタスクを自動化するという事実にもかかわらず、銀行のすべてのニーズをカバーしているわけではありません。 ABSがまったく行わないタスク、または銀行が望むことを行わないタスクがあります。 したがって、個々のビジネスプロセスを自動化する他の情報システムは、 ABSに接続（統合）されます。 将来、このような情報システムは応用情報システムと呼ばれます 。

適用される情報システムの例は次のとおりです。

• リモートバンキングシステムインターネットクライアントバンク（ RB ICB 、たとえばiBank2 、 BS-Client 、 InterBank ）、
• 支払いカード処理（例： TranzWare 、 SmartVista 、 Way4 ）、
• コンタクトセンターオートメーションシステム（ Avaya Call Center 、 Cisco Unified Contact Centerなど ）、
• 借り手の自動採点システム（ FICOなど ）、
• その他

銀行の規模と銀行が提供するサービスに応じて、 適用される情報システムの数を単位から数百の量で測定できます。

インフラ情報システム

主要なビジネスプロセスを自動化するABSおよび応用情報システムに加えて、銀行には相当数のサポートインフラストラクチャ情報システムもあります 。 そのようなシステムの例は次のとおりです。

• Active Directory
• ドメインネームサービス（DNS）
• 企業メール
• 従業員向けのインターネットアクセスサービス。
• 構内のアクセス制御および管理システム（ACS）。
• IPビデオ監視;
• IPテレフォニー。
• などなど。

情報サービス

銀行は、 BIKおよびFIASディレクトリのダウンロード、公式Webサイトでの通貨レートの公開など、単純なルーチン機能を実行する膨大な数の異なる情報サービスを使用しています。

サードパーティの情報システムのクライアント部分

別の言及は、銀行外部の情報システムのクライアント部分です。 例として、以下を引用します。

• 状態情報システムとの統合モジュール： GIS GMP 、 GIS住宅および共同サービス 。
• 外部支払いシステムのクライアント部分。
• 取引所の交換。
• などなど。

情報システムを統合する一般的な方法

通常、 情報システムの統合には次のメカニズムが使用されます 。

1. API（たとえば、Webサービス）を介した統合。
2. DBMSによる統合：
   
   • ストアドプロシージャへのアクセスのみを提供する。
   • ストアドプロシージャとデータベーステーブルへのアクセスを提供します。
3. ファイル共有：
   • コンピュータネットワークを介して;
   • 疎外されたコンピューターストレージメディア（OMNI、フラッシュドライブなど）を介して。
4. サービス指向アーキテクチャ（SoA）を実装します 。

統合モジュール

統合モジュールとは、ITインフラストラクチャの他の要素の統合を実装するITインフラストラクチャの仮想要素を意味します。

この機能は、ITインフラストラクチャの個別の特殊な要素（ 情報サービスなど ）と統合情報システムのコンポーネントの両方として実装できるため、この要素を仮想と呼びました。 さらに、統合可能な情報システム間で情報を「手動で」転送する人でさえ、統合モジュールとして機能できます。

銀行のITインフラストラクチャの例

図1では、上記の種類の要素を含む典型的な銀行情報インフラストラクチャの断片を見ることができます。

第2章キャッシュレス支払いのインフラ

このスキーム（ 図1 ）を非現金支払いの観点から見ると、銀行が以下を使用してそれらを実装していることがわかります。

• パートナー銀行との直接的な通信関係、
• 国際決済システム（MPS）（ VISA 、 MasterCardなど ）。
• ロシア銀行との特派員関係。

パートナーバンクとの技術的に直接のコルレス関係は、以下を使用して編成できます。

• 銀行が法人にサービスを提供するために使用する従来のRB銀行システム（この例（ 図1 ）では、この方法が使用されています）。
• 銀行間決済システム（例： SWIFT ）;
• 専用の支払いメッセージングシステム（ REX400 、 TELEXなど ）。
• 相互作用する銀行の1つによって開発された特殊なソフトウェア。

プラスチックカードを提供する支払いシステムへの接続は、処理システムの一部である標準モジュールを介して実行されます。

銀行が正常に機能するためには、これらすべての支払い方法の情報セキュリティを確保する必要があります。 それらを1つの大規模な研究の枠組みで検討することは非常に問題です。したがって、可能な損失、方向の観点から最も重要なものの1つ、つまり銀行とロシア銀行との支払い相互作用に集中します。

ロシア銀行との支払い相互作用を確保するためのインフラストラクチャ

図 2。
他の銀行のクライアントの住所に送られた支払いの実行例により、ロシア銀行との銀行の支払い相互作用のITインフラストラクチャを検討します。

最初の部分から覚えているように、最初にクライアントは支払い注文を銀行に転送する必要があります。 彼はこれを2つの方法で行うことができます。

1. 銀行の支店に直接出頭し、認証済みの支払い注文を紙のフォームで送信する。
2. RB RBMシステムを介して支払い注文を送信します。

ここで重要なのは、 RBS IKBシステムは、クライアントと銀行の間で法的に重要な電子文書の流れを提供するシステムであり、それ自体では支払いを行わないということです。 そのため、クライアントが銀行口座を開設すると、通常2つの契約を締結します。 1つ目は銀行口座サービス契約、2つ目はRB RBMシステムを使用した電子文書管理の実装に関する契約です。 2番目の契約が締結されない場合、クライアントは自分のアカウントを引き続き使用できますが、銀行支店に個人的にアクセスする必要があります。

クライアントが紙のフォームで支払い注文を送信した場合、それに基づいて銀行の従業員はABSで電子支払い注文を行います。 RB IKBを介して注文が送信された場合、統合モジュールを介してABSに自動的に入力されます。

資金の転送に関する注文を行ったのはクライアントであるという事実の証拠で、最初のケースでは彼が個人的に署名した紙の文書であり、2番目のケースではRB RBの契約に従って認証された電子文書です。

通常、暗号化電子署名は、クライアントの電子文書（ RB ICBの法人）の認証に使用され、SMS確認コードは、クライアントの文書に使用されます-個人。 法的観点から、どちらの場合も、銀行は通常、電子署名を証明するために手書き署名アナログ（TSA）の法的制度を適用します。

ABSに入ると、銀行の内部規則に基づく支払い注文が制御を通過し、実行のためにロシア銀行の支払いシステムに送信されます。

ロシア銀行の決済システムとの相互作用の技術的手段

ロシア銀行の支払いシステムとやり取りするために使用されるハードウェア（ソフトウェア）は、特派員を務めるロシア銀行の領土事務所によって異なる場合があります。 銀行口座。

モスクワ地域でサービスを提供する銀行の場合、 次のソフトウェアが使用されます。

• AWP KBR-ロシア銀行の顧客の自動化された職場。
• UTA-ロシア銀行クライアント向けの特別なファイルインタラクションソフトウェア（ユニバーサルトランスポートアダプター）;
• SCAD署名 -暗号情報保護の手段（暗号保護）「ハードウェアとソフトウェアの複合署名クライアント」バージョン5、ロシア連邦セキュリティサービスの証明書-SF / 114-2680 （暗号保護KS1のレベル）、暗号保護レベルKS2- SF / 124-2681 （暗号保護のレベル） KC2）。 SCADは暗号化文書認証システムの略です。

AWP CBD

AWP KBRは、銀行の承認された従業員が送信する支払い文書を暗号化およびデジタル署名するとともに、ロシア銀行から受け取った支払い文書の電子署名を解読および検証するソフトウェアです。 しかし、より正確に言うと、CBDのAWSの作業は支払いドキュメントではなく、2つのタイプの電子メッセージ（ES）で動作します。

• 電子決済メッセージ（EPS）、たとえば、ED101「支払い注文」。
• 電子サービスおよび情報メッセージ（ESIS）、たとえば、ED201「ES制御の結果の通知」。

電子メッセージのリストとフォーマットは、ロシア銀行が電子バンキングメッセージの統一フォーマットのアルバム（UFEBS）を発行することによって確立されます。

CBDのAWSが支払いを処理するには、UFEBS形式の電子支払いメッセージを含むファイルに変換する必要があります。 このような変革には、ロシア銀行の決済システムとのABS統合モジュールが責任を負います。 技術的な観点から、UFBS形式はXMLに基づいているため、このような変換は非常に簡単です。

電子メッセージファイルは、 ABS統合モジュールを開いたままにして、ファイルシステムの特別なフォルダー（通常はネットワークフォルダー）に配置されます。このフォルダーは、ステータスが「Entered」の電子メッセージ用にKBR AWPで構成されます。 前述の図（ 図2. ）では、このフォルダーは「フォルダー1」として指定されています。

次に、処理の過程で、電子メッセージのステータスが「制御済み」、「送信済み」などに変更されます 。これは、 KBRワークステーションで設定された適切なフォルダーに電子メッセージを含むファイルを移動することで技術的に実装されます 図（ 図2 ）では、これらのフォルダーは「フォルダー2」として指定されています。

発信電子メッセージの技術処理（銀行の内部規則により確立）の特定の時点で、 SCAD署名と責任ある従業員の秘密暗号キーを使用した電子署名により暗号化および署名されます。

SCAD署名

SCAD署名は、ロシア銀行の注文によりValidata LLCによって開発された暗号情報保護ツールであり、ロシア銀行の支払いシステムの情報を保護するように設計されています。 この暗号化情報保護対策は公開されておらず（CBR Webサイトに掲載されている文書を除く）、ロシア銀行がその支払いシステムの参加者にのみ配布しています。 この暗号情報保護システムの特徴的な機能は次のとおりです。

1. この暗号情報保護システムは、ロシアのビジネスサークルで一般的な他の暗号情報保護システム （たとえば、 Crypto-PRO CSP 、 VIPNET CSPなど）とは異なり 、オペレーティングシステムから分離された独自の公開キー基盤（PKI）を実装します。 これは、証明書を含む公開キーディレクトリ、信頼できる証明書のリスト、失効した証明書のリストなどがユーザーの秘密キーで暗号化されて保護されているため、攻撃者がユーザーの知らない間に信頼できる証明書をインストールすることはできません。
   ご注意 SKZI Verba-OWは同様の主要モデルを実装しています。
2. 前の機能から次の機能が続きます。 CIPFでは、作業キーを作成するために、最初に特別な登録キーを使用して証明書のディレクトリを作成する必要があります。 作業キーの有効期限が切れると、新しいキーが生成されますが、それらを生成するには、有効な以前の作業キーが必要です。 キーは、 認証センターとしてロシア銀行が参加する分散スキームに従って作成されます。
3. CIPFは、プライベートキーをコンピューターのメモリに転送せずに、電子署名および暗号化機能をボード上で実行する機能キーキャリア（ vdToken ）との連携をサポートしています。
4. ロシア銀行の決済システムとのやり取りに使用される暗号キーには、次の2つのタイプがあります。
   • 「暗号化のみ」 -電子メッセージを暗号化/復号化できます。
   • 「暗号化と署名」 -最初の場合と同じことを行い、電子メッセージに署名することもできます。

UTA

暗号化および署名された電子メッセージは、図（ 図2 ）の特別なフォルダーに配置されます。これは「フォルダー3」です。 UTAはこのフォルダを継続的に監視し、そこに新しいファイルがある場合、次のいずれかの方法でロシア連邦の中央銀行に転送します。

• 「インターネット上」。ただし、実際にはこれは完全に真実ではありません。 インターネットの代わりに、ロシア連邦中央銀行に専用の通信チャネルを提供する専門の通信オペレーターが使用されますが、IPアドレス可能なネットワークなので、送信はインターネット経由であると言います。
• 「モデムで。」 最初のタイプの通信の事故の場合、公衆電話網を介したモデム接続の形で予備があります。
• すべての通信チャネルに障害が発生した場合、OMNI（疎外されたコンピューター記憶媒体）への電子メッセージの配信は宅配便業者によって提供されます。 ちなみに、これは、失効したライセンスを持つ銀行が清算中に支払いを行う方法の1つです。

UTAは、中央銀行に到着すると（最初または2番目の方法）、中央銀行が発行したAPIを介して電子メッセージを送信します。 通信セッション中、 UTAは中央銀行から入力電子メッセージも受信します。

UTAが動作するすべての電子メッセージは暗号化され、電子署名で署名されることに注意してください。

暗号化された電子メールを受信すると、 UTAは受信した暗号化されたメッセージとともにそれをフォルダに転送します。 暗号化キーとAWP KBRの助けを借りて承認された従業員が電子署名をチェックし、メッセージを解読します。

電子メッセージのタイプに応じて、さらに処理が実行されます。 これが支払いメッセージである場合、統合モジュールを介してABSに送信され、 ABSでアカウントの残高を変更するアカウンティングエントリが形成されます。 ABS （統合モジュール）とCBDのAWSの相互作用は、オープン形式の標準形式ファイルを使用することに注意することが重要です。

機能する過程で、 KBR AWSは作業のジャーナルを維持します。これは、テキストファイルの形式で、またはDBMSの制御下で動作するデータベースの助けを借りて実装できます。

代替処理スキーム

システムの「クラシック」スキームを調べました。 実際には、多くの種類があります。 それらのいくつかを考えてみましょう。

多様性1.メッセージの送受信の輪郭の分離
スキームは2つのAWS KBRで実装されています。 1つ目は人間の参加で動作し、メッセージのみを送信します。2つ目は自動モードで動作し、メッセージのみを受信します。

バラエティ2.フルオートマチック
AWP KBRは、人間の介入なしで完全に自動的に動作するように構成されています

バラエティ3.分離されたAWS KBR
AWP KBRは、銀行のネットワークに接続されていない専用コンピューターとして機能します。 電子メッセージは、OMNIを使用して人間のオペレーターによって彼に送信されます。

CBDのAWSからABSへの電子署名の転送

ロシア銀行は、支払いを処理するための新しい技術スキームに切り替えることを計画しています。このスキームでは、電子メッセージは以前のようにAWP KBRではなく、 ABS （より正確には、 ABS統合モジュール-AWP KBR ）にサブスクライブされます。

このアプローチを実装するために、 AWS KBRの新しいバージョンがリリースされ 、 AWS KBR-N （new）として知られるようになりました。 CBDの古いバージョンと新しいバージョンのワークステーションを通過する情報フローのスキームを比較すると、すべての主要な変更を確認できます。

従来のAWS KBRの情報フローのスキームを検討してください。 スキームのソースは、CBD「ロシア銀行の顧客の自動化された職場」のAWSの公式文書です。 プログラマーズガイド。 CBRF.61209-04 33 01.」


図 3。
注。

• 「AS KBR」（ロシア銀行の顧客の自動システム）という名称は、前の図のABSに対応しています。
• 「SVO SVK」という指定は、前の図の指定UTAに対応しています。
• KA-電子メッセージの認証コード（電子署名）。
• ZK-セキュリティコードは別の種類の電子署名ですが、元のメッセージによって変更なしで形成されるKAとは異なり、ZKはマークアップせずに重要なデータの下でのみ生成されます。 UFESのドキュメント「電子メッセージの保護（ESパッケージ）」で、宇宙船と宇宙船の技術的なニュアンスの詳細を読むことができます。 法的観点から見ると、LCは情報保護の技術的手段であり、CAはロシア銀行の支払いシステムの契約と規則に従って、電子署名として認識されています。

次に、新しいAWB KBR-Nの同様のスキームを見てみましょう。 ソース「ロシア銀行の顧客の自動化された職場」NEW。 プログラマーズガイド。 CBRF.61289-01 33 01 "


図 4。

暗号化の観点から、 AWP KBR-Nは、電子メッセージの暗号化/復号化、およびそれらの電子署名のチェックを担当します。 電子署名の生成は、 ABS統合モジュールに転送されました。

このモジュールでは、 KBR-N AWPから受信したメッセージの署名も検証する必要があると想定するのは論理的です。 技術的な観点からはこれは必須ではありませんが、セキュリティの観点からは重要です。ABSとKBR-N AWPの間で送信されるメッセージの整合性が保証されるためです。

ABS 、 AWS KBR-N 、 UTA間の相互作用のためのファイルインターフェースに加えて、 IBM WebSphere MQインターフェースが追加されました。これにより、銀行のサービス指向ITインフラストラクチャを構築し、支払いを送信する複数のオペレーターの同時運用の組織で古いスキームの問題を解決できます。

おわりに

銀行のIT支払いインフラストラクチャの内部構造を調査しました。 以下の部分では、ここで発生する情報セキュリティへの脅威について検討します。