イデオロギーと金融システム開発の問題。 パート1
私の謙虚な経験では、私たちの国では、ソフトウェア開発者と金融システムの開発者の間に分離はありません。 インタビューで私が会った最大のことは、高負荷下で機能する情報システム（Channel One、Yandexなど）を扱っているかどうかという質問でした。 残りの部分については、彼らは常に特定の情報技術の知識にのみ興味があります。 私の意見では、情報システムの開発は、アーキテクチャの開発と設計の文化全体です。 同時に、アーキテクチャは常に最初の場所にある必要があります：そのバランス、柔軟性、セキュリティ、およびシステムの将来の開発に関する思慮深さ（その柔軟性、思慮深さ、およびビジネスプロセスに焦点を当てないサードパーティシステムとの統合の可能性を含む） 。
違いの例は、現在の情報と金融システムに焦点を当てた従来のシステムの構築です。
財務会計と監査のシステムが作成されています。 彼らが言うように、システムはすべて1つです。 システムが開発され、顧客に受け入れられ、開発され、最終化されます。 数年後、顧客はビジネスプロセス全体を2つの個別のコンポーネントに分割することを決定します。つまり、金融サービスは、財務と会計の2つの部分に分割されます。 このビジネスでは、システムの分離が計画されています。顧客は古いシステムを残したいが、一部の機能（会計活動に関連する）は1C会計で完全に実行されました。 そしてすぐに、2つのシステムの統合について疑問が生じます。 1C-Accounting-素晴らしい金融システム、あるいは1C-Accountingではなく、フレームワーク全体。 重大な1Cの問題については説明しません。組み込みの機能の一部が「縫い付けられている」ため、将来的には問題なく機能しません。 外部データベースから少なくとも1つのディレクトリを統合することは非常に困難です。 メインシステムからのすべての変更を「オンザフライ」でロードすることは、かなり重要なタスクです。 しかし、システムに戻り、この質問を自問してください。システムは1つではなく、2つ（3、4、5、..）であり、これらのシステムに共通するエンティティをどうするか。 1つのシステムでのみ編集および削除が許可されている作成エンティティを省略することもできます（ここでは、ビジネスプロセスをデータベースレベルでも説明できます）。 しかし、たとえば、両方のシステムに共通のディレクトリで何をすべきでしょうか？ 結局のところ、ユーザーはパンを食べない人です。情報を2倍にしてください。 この結果は、壊滅的ではないにしても、これらの一見小さな問題を解決するのに必要なかなりの数の工数を取り除いてしまうかもしれません。 そして、それは彼らがその年の声明を収集し始めた12月末に判明し、例えば契約に関するデータが広がっていることが判明しました。 もちろん、このデータに責任を持つユーザーは、数か月前にどのような理由で自分がやったのかを正確に覚えていません。 製品所有者の論理は、通常、「これはシステムの問題であり、あなたが責任を負います-あなたは問題を解決します」に要約され、問題はデータのようにシステム内ではあまりないことを忘れます。 これはすべて、1つの条件下では発生しませんでした-システムのアーキテクチャと相互作用のルールは、最初から考えられていたはずです。
以下、私たちのチームが直面した困難についてお話したいと思います。 おそらく、数年前にそのような資料に出会ったなら、私たちから多くの時間を費やしてきた（そしてこれからもかかり続ける）問題の多くを回避できただろう。 簡単な言及でさえ、このような理由でこのような問題が発生する可能性があることは十分です。 これで、私自身がこれらのいくつかについて話す準備ができました。 さらに、私たちが議論し、最終的に採用したソリューションの概要を説明します。 それでは始めましょう。
設計段階でのアクセス権システムの承認アルゴリズムとアーキテクチャ計画
明らかに、ビジネスプロセスの実装に関連するすべてのニュアンスは考慮されませんが、それらについて考える価値はあります。
多くの人が選択する最も単純で最も単純なパスは、フォームのデザインを作成することです。
DB_Class_Class_Copy instance.connectionメソッド（ユーザー名、パスワード）
ここで、ユーザー名とパスワードは、クライアントの起動時にユーザーが入力するデータです。
ここでは、1つの大きなセキュリティ問題がすでに明らかになっています。 私たちがシステムを提供している組織、および競合他社であるローカルネットワークとユーザーのマシンでシステムを保守した経験があるのは、まさに偶然です。 地理的に同じ建物内にある同じ組織内のユーザーとサーバー間で送信されるデータを保護する必要があるとは思いもしませんでしたが、発生することがわかりました。
ユーザーのマシンにアクセスできる攻撃者は何ができますか？ 彼は1つの簡単なことをすることができます-静かな環境でメディアにメモリダンプを投げて、ユーザー名とパスワードを引き裂きます。
したがって、ルール1：機密データ（つまり、アクセスに少なくともいくつかの制限があるデータ）は、それらがなければシステムが機能できない期間にのみサーバーの外部に保存する必要があります。 この例では、データベースへの接続を確立した後、すべての変数、ユーザー名とパスワードの内容を破棄する（またはゴミでいっぱいにする）必要があります。
ここで問題を提起します：ユーザーがユーザーであり、彼のコンピューターが彼のコンピューターであることを確認する方法
標準のMS SQLツール（たとえば）では、この問題を解決できません。 さらに、これは破棄する必要があります（少なくとも、上記の例ではセキュリティポリシー全体を強制終了し、次に柔軟性を与えないドメイン許可のために、少なくとも後述します）。
いくつかのシステムの統合では、データベースポリシー以外を使用することは機能しません（または、異なるプログラム間で機能するレイヤーを作成しますが、時間がかかります）。 そのため、最初に他のシステムで変更される可能性のあるデータと、システムでのみ編集できるデータを分離する必要があります。 同時に、それらを単にテーブルで区切るのではなく、異なるデータベースに取り出す必要があります。 しかし、次回はこのことについて書きます。
だから、承認。
最も単純なもの（多くの時間はかかりませんでした）と私たちが思いついた効果的なものは、次のスキームです：
oユーザーがユーザー名とパスワードを入力します
oパスワードは、ローカルマシンのハードウェアに関するすべての可能なデータを使用して、トリッキーなアルゴリズムを使用して変換されます
o入力されたユーザー名と受信したパスワードで接続が作成されます。
したがって、特定のマシンのデータを固定します（攻撃者は、すべてのマシン、少なくとも一意のプロセッサとネットワークカード番号を再作成することはできません）。 一方、コンピューターを自由に使用できる場合でも、ユーザーのパスワードを知る必要があります。
もちろん、私たちは不可解なシステムがないことを理解していますが、私たちの巧妙なアルゴリズムは、コードを分解しようとする人を汗だかせ、したがって時間を与えてくれます。
しかし、最も重要なことは、ユーザーのパスワードを知っていて、コンピューターにアクセスできたとしても、本当に恐ろしいことを成し遂げることは不可能だということです。アクセス権ポリシーはそれを防ぎます。
私たちは、データベース（MS SQL）が提供するツールと構築するものの間の長い間、妥協点を探してきました。 最終的に、データベースによって提供される詳細（各テーブル、プレゼンテーション、およびストレージに対する個々の権利）が十分ではないことを明確に決定しました。ビジネスプロセスのロジック全体がはるかに複雑です。
最終的に、クライアントアプリケーションから次の2レベルのセキュリティシステムスキームを実装しました。
oアプリケーションを起動すると、データベース接続が自動的に作成されます
oユーザーはユーザー名とパスワードを入力します。ユーザー名とパスワードは、ユーザーが実行したい操作のコード（この場合は接続）とともに暗号化された形式でサーバーに送信されます。
oさらに、独自の権利システムは、このアクションの有効性を示す結果を返します（結果コードを受け取った後、プログラムは次のデータ要求でデータが返されることを「理解」します）。
さらに、このスキームはあらゆる場所で使用されているため、最も洗練された権限を考慮して、ビジネスプロセスを完全にシフトできます。
したがって、データベースツールキットには、データベースを使用するさまざまなシステムの作業に関する操作の余地があり、アプリケーションおよびデータベースレベルで詳細なロジックが規定されています。ユーザーアクションの有効性を確認する関数がエラーコードを返す場合、ストアドプロシージャはデータを返しません。
まとめ
結果はかなり退屈で長い記事でしたが、誰かに役立つことを願っています。 これがすべて同じ場合、次回は問題といくつかのシステムの相互作用のロジックについてお話したいと思います。
違いの例は、現在の情報と金融システムに焦点を当てた従来のシステムの構築です。
財務会計と監査のシステムが作成されています。 彼らが言うように、システムはすべて1つです。 システムが開発され、顧客に受け入れられ、開発され、最終化されます。 数年後、顧客はビジネスプロセス全体を2つの個別のコンポーネントに分割することを決定します。つまり、金融サービスは、財務と会計の2つの部分に分割されます。 このビジネスでは、システムの分離が計画されています。顧客は古いシステムを残したいが、一部の機能（会計活動に関連する）は1C会計で完全に実行されました。 そしてすぐに、2つのシステムの統合について疑問が生じます。 1C-Accounting-素晴らしい金融システム、あるいは1C-Accountingではなく、フレームワーク全体。 重大な1Cの問題については説明しません。組み込みの機能の一部が「縫い付けられている」ため、将来的には問題なく機能しません。 外部データベースから少なくとも1つのディレクトリを統合することは非常に困難です。 メインシステムからのすべての変更を「オンザフライ」でロードすることは、かなり重要なタスクです。 しかし、システムに戻り、この質問を自問してください。システムは1つではなく、2つ（3、4、5、..）であり、これらのシステムに共通するエンティティをどうするか。 1つのシステムでのみ編集および削除が許可されている作成エンティティを省略することもできます（ここでは、ビジネスプロセスをデータベースレベルでも説明できます）。 しかし、たとえば、両方のシステムに共通のディレクトリで何をすべきでしょうか？ 結局のところ、ユーザーはパンを食べない人です。情報を2倍にしてください。 この結果は、壊滅的ではないにしても、これらの一見小さな問題を解決するのに必要なかなりの数の工数を取り除いてしまうかもしれません。 そして、それは彼らがその年の声明を収集し始めた12月末に判明し、例えば契約に関するデータが広がっていることが判明しました。 もちろん、このデータに責任を持つユーザーは、数か月前にどのような理由で自分がやったのかを正確に覚えていません。 製品所有者の論理は、通常、「これはシステムの問題であり、あなたが責任を負います-あなたは問題を解決します」に要約され、問題はデータのようにシステム内ではあまりないことを忘れます。 これはすべて、1つの条件下では発生しませんでした-システムのアーキテクチャと相互作用のルールは、最初から考えられていたはずです。
以下、私たちのチームが直面した困難についてお話したいと思います。 おそらく、数年前にそのような資料に出会ったなら、私たちから多くの時間を費やしてきた（そしてこれからもかかり続ける）問題の多くを回避できただろう。 簡単な言及でさえ、このような理由でこのような問題が発生する可能性があることは十分です。 これで、私自身がこれらのいくつかについて話す準備ができました。 さらに、私たちが議論し、最終的に採用したソリューションの概要を説明します。 それでは始めましょう。
設計段階でのアクセス権システムの承認アルゴリズムとアーキテクチャ計画
明らかに、ビジネスプロセスの実装に関連するすべてのニュアンスは考慮されませんが、それらについて考える価値はあります。
1.データベースへの接続。
多くの人が選択する最も単純で最も単純なパスは、フォームのデザインを作成することです。
DB_Class_Class_Copy instance.connectionメソッド（ユーザー名、パスワード）
ここで、ユーザー名とパスワードは、クライアントの起動時にユーザーが入力するデータです。
ここでは、1つの大きなセキュリティ問題がすでに明らかになっています。 私たちがシステムを提供している組織、および競合他社であるローカルネットワークとユーザーのマシンでシステムを保守した経験があるのは、まさに偶然です。 地理的に同じ建物内にある同じ組織内のユーザーとサーバー間で送信されるデータを保護する必要があるとは思いもしませんでしたが、発生することがわかりました。
ユーザーのマシンにアクセスできる攻撃者は何ができますか？ 彼は1つの簡単なことをすることができます-静かな環境でメディアにメモリダンプを投げて、ユーザー名とパスワードを引き裂きます。
したがって、ルール1：機密データ（つまり、アクセスに少なくともいくつかの制限があるデータ）は、それらがなければシステムが機能できない期間にのみサーバーの外部に保存する必要があります。 この例では、データベースへの接続を確立した後、すべての変数、ユーザー名とパスワードの内容を破棄する（またはゴミでいっぱいにする）必要があります。
ここで問題を提起します：ユーザーがユーザーであり、彼のコンピューターが彼のコンピューターであることを確認する方法
標準のMS SQLツール（たとえば）では、この問題を解決できません。 さらに、これは破棄する必要があります（少なくとも、上記の例ではセキュリティポリシー全体を強制終了し、次に柔軟性を与えないドメイン許可のために、少なくとも後述します）。
いくつかのシステムの統合では、データベースポリシー以外を使用することは機能しません（または、異なるプログラム間で機能するレイヤーを作成しますが、時間がかかります）。 そのため、最初に他のシステムで変更される可能性のあるデータと、システムでのみ編集できるデータを分離する必要があります。 同時に、それらを単にテーブルで区切るのではなく、異なるデータベースに取り出す必要があります。 しかし、次回はこのことについて書きます。
だから、承認。
最も単純なもの（多くの時間はかかりませんでした）と私たちが思いついた効果的なものは、次のスキームです：
oユーザーがユーザー名とパスワードを入力します
oパスワードは、ローカルマシンのハードウェアに関するすべての可能なデータを使用して、トリッキーなアルゴリズムを使用して変換されます
o入力されたユーザー名と受信したパスワードで接続が作成されます。
したがって、特定のマシンのデータを固定します（攻撃者は、すべてのマシン、少なくとも一意のプロセッサとネットワークカード番号を再作成することはできません）。 一方、コンピューターを自由に使用できる場合でも、ユーザーのパスワードを知る必要があります。
もちろん、私たちは不可解なシステムがないことを理解していますが、私たちの巧妙なアルゴリズムは、コードを分解しようとする人を汗だかせ、したがって時間を与えてくれます。
しかし、最も重要なことは、ユーザーのパスワードを知っていて、コンピューターにアクセスできたとしても、本当に恐ろしいことを成し遂げることは不可能だということです。アクセス権ポリシーはそれを防ぎます。
2.アクセスポリシー
私たちは、データベース（MS SQL）が提供するツールと構築するものの間の長い間、妥協点を探してきました。 最終的に、データベースによって提供される詳細（各テーブル、プレゼンテーション、およびストレージに対する個々の権利）が十分ではないことを明確に決定しました。ビジネスプロセスのロジック全体がはるかに複雑です。
最終的に、クライアントアプリケーションから次の2レベルのセキュリティシステムスキームを実装しました。
oアプリケーションを起動すると、データベース接続が自動的に作成されます
oユーザーはユーザー名とパスワードを入力します。ユーザー名とパスワードは、ユーザーが実行したい操作のコード（この場合は接続）とともに暗号化された形式でサーバーに送信されます。
oさらに、独自の権利システムは、このアクションの有効性を示す結果を返します（結果コードを受け取った後、プログラムは次のデータ要求でデータが返されることを「理解」します）。
さらに、このスキームはあらゆる場所で使用されているため、最も洗練された権限を考慮して、ビジネスプロセスを完全にシフトできます。
したがって、データベースツールキットには、データベースを使用するさまざまなシステムの作業に関する操作の余地があり、アプリケーションおよびデータベースレベルで詳細なロジックが規定されています。ユーザーアクションの有効性を確認する関数がエラーコードを返す場合、ストアドプロシージャはデータを返しません。
まとめ
結果はかなり退屈で長い記事でしたが、誰かに役立つことを願っています。 これがすべて同じ場合、次回は問題といくつかのシステムの相互作用のロジックについてお話したいと思います。
All Articles