最初の隠れ家。
アクティビティで初めて電子デジタル署名に遭遇したとき、オークションサイトで働いていました。 文書に署名する要件は、勝者が増加のために落札したオークションの支払いを拒否する可能性のあるオプション（英語の方法）と、その後の保険金の返還の要求（保証の支払い）のために現れました。 アナリストは一般にこれがどのように起こるかについてほとんど考えていなかったので、私は1人の賢い開発者に対処し、いくつかの法的詳細に取りかかりました。 そして、私がすべての技術的ポイントを正しく理解したという事実ではありません。
状態システムをアナリストとして完成させる役割のプロジェクトに2回目に遭遇したが、問題の本質を理解していないプログラマーもプロジェクトマネージャーも間違った方向に進み、最初は正しいことをしていると考え、2回目は期限を守るために顧客を欺いた。
この分野でのさらなる作業のために、古い会社は小さなテーブルに集まり、問題を少し議論しなければなりませんでした。
2番目の余談、少し本質
カザフスタン共和国の私たちは、Webサービスを使用してさまざまなシステムを統合するための非常に重要なプロジェクトになりました。 異なるシステムが互いに情報の要求を送信し、要求に対する必要な情報を含む回答を受け取ります。 そして、問題の核心に移る前に、ばかげた例を考えてみましょう。
航空宇宙機関は、薬局での潜在的な宇宙旅行者の登録に関する情報を迅速に取得したいと考えています。 薬物中毒者登録局は、登録された個人のデータベースを所有しています。 発生するアクション：
1.代理店の従業員は、潜在的な観光客のデータを示す問い合わせ状を部門に書き込み、権限のある人で署名し、スタンプを入れ、出向番号を事務員に登録し、ファックス/レターで送信し、すぐに着信番号を示すファックス/レターを送信するよう要求します手紙の日付。
2.局長官は手紙を受理し、番号と日付を割り当てて特別なジャーナルに登録し、不特定の実行ルートに沿って手紙を送り、手紙の着信番号と日付を庁に送る。
3.代理店の従業員は、着信番号と日付を受け取り、要求が満たされることを確信して事業に取り掛かります。
4.部門の従業員は、データベース/ファイルキャビネット内の潜在的な観光客の存在を確認し、リクエストの識別情報、署名、スタンプを示すリクエストへの応答を含む手紙を書き、発信番号を店員に登録し、ファックス/レターで送信します。 そして理想的には、彼は答えの着信番号と日付を尋ねます。
5.機関の長官は、手紙を受け入れ、手紙の着信番号と日付を登録し、要求している従業員に手紙を送ります。 そして理想的には、着信番号と日付を部門に送信します。
どうやら、これらのすべての官僚的な手順が必要なのですか：
1.代理店は、リクエストが到着したことを知っており、処理を開始する必要があります。
2.代理店は、所定の時間内に応答を受信しない場合、何らかの措置を講じることがあります。
3.応答に誤ったデータが含まれている場合、代理店は何らかの措置を講じることができます。
4.代理店は、送信した要求と受信した応答について、いつでも委員会に報告できます。
5.部門は、要求を受信せず、登録しなかった場合、要求を受信しなかったと主張する場合があります。
6.局は、要求に対する応答が庁によって受信されたと主張する場合があります。
7.部門は、要求に対する応答のタイミングについて報告する場合があります。
8.局は、応答が送信した形式で正確に受信されたと主張する場合があります。
9.部門は、薬物中毒者が行ったすべての回答について、依頼を示して薬物中毒者の権利に関する委員会に報告することができます。
つまり これらの手順はすべて、2つの当事者の誤解、誤解、および相互の非難を減らし、論争のある問題を解決するために必要です。 情報システムの相互作用の類似性を考慮して、情報システムの機能におけるリスクを軽減します。
私を取り巻く混乱の中で、すべてがどのように起こるのか
実際、ほとんどの場合、1つのWebサービスと1つのWebサービスクライアントを使用して2つのシステムの統合が行われる状況があります。 この場合、次のアクションが最も頻繁に発生します。
1.クライアントは、認定認証局（AUC）によって発行された証明書を使用して安全な接続を確立し、要求を送信します。
2.サービスは、ユーザーを承認および識別し、応答を作成し、責任者の電子デジタル署名を使用して応答に署名することにより、理解できないチェックを行います（必要な知識を持たない開発者がすべてのチェックを行うことはできませんが、すべてが正常に機能することを証明することがあります） （微妙な違いもあります）、クライアントに応答を送信します。 すべてが単一のセッションで同期的に発生します。
3.クライアントは応答を受信し、それを保存し（EDSの正確さを確認することさえできず、それを見た）、システムにデータを入力します（保存された要求へのリンクを保存することもあります）。
私が見る問題：
開発者が不完全なlunduhiである場合、システムの機能中に次の問題が発生し、上記のペーパーワークフローで解決されます。
1.クライアントは、リクエストが受け入れられなかったり、処理されなかったりすることを証明しない場合があります。
2.したがって、サービスは、サービスからリクエストを受信していないと主張する場合があります。
3.サービスは、要求の長期処理中にトランスポート媒体の問題が原因で回答が来ないと主張する場合があります。
4.サービスは応答を送信したと主張する場合がありますが、クライアントは応答を受信しないか、保存しません。
5.クライアントは、回答を受け取らないと主張する場合があります。
6.委員会は、インシデントを調査する際に、さまざまなクライアントのすべてのリクエストの有効性とこれらのリクエストに対する回答を確認することはできません。
そして、開発者がlunduhiである場合、ここでは一般的に管轄権の問題になります。 私の意見では、すべては信頼と、これまで誰もこの問題を提起したくないという事実に基づいています。
それはそうあるべきだと思う...
EDSとワークフローに関する法律は何を教えてくれます：
2003年1月7日付けのカザフスタン共和国の法律N 370-II「電子文書および電子デジタル署名について」
第2章電子文書
第7条電子文書管理の要件
1.電子文書は、電子的に作成、送信、保存、および提出できます。 この法律の要件に準拠した電子文書は、紙の文書と同等です。
2.電子文書は、情報通信ネットワークを介して送信された瞬間から送信されたとみなされます。
3.受信電子文書は、受信者の情報システムに記録された後に到着したと見なされます。
4.受領通知には、電子文書とその送信者の受領の事実と時間に関するデータが含まれていなければなりません。 作成者が受信していない場合、文書は受信者によって受信されていないと見なされます。
（ここで私はRKから来たことを再び思い出しました。何をすべきか、現地の法律が手元にあり、同様のロシアの法律は少し非類似です。誰かがこの方向で掘ることができれば、私は喜んでいます。同様の要件。）
そして、ここにワークフローがあります、あなたは尋ねるかもしれません。 さらに、クライアントが送信するリクエスト（SOAP、XML RPCなど）は、紙のリクエストに類似したテキストで、「情報を提供してください... blablabla」というテキストを含む手紙です。 そして、答えも文書です。
そして何をすべきか？
紙のワークフローモデルを使用します。 これを行うには、非同期Webサービスの技術を適用できます。 マルチスレッドの観点ではありません。 写真では非常に簡単です：
技術的には、次の手順を実行する必要があります。
1.要求側は、必要なパラメーターを使用して要求を生成します。 要求はEDSによって署名され、「タイムスタンプ」が添付されます。 リクエストは送信されたリクエストのログに保存され、レスポンダーに送信されます。
2.応答側は要求を受け入れ、要求の送信者、署名が正しいこと、タイムスタンプおよび要求の入力パラメーターを確認し、要求を着信要求ログに保存し、ISにさらに処理する要求を送信し、署名されたデジタル署名と要求の受け入れに関するタイムスタンプメッセージで要求者に応答します処理します。
3.要求側は、正しい署名とタイムスタンプの処理要求の受け入れ時にメッセージを確認し、メッセージを保存して、送信した要求を処理受け入れ済みとしてマークします。
4.応答側は、応答の生成後、それに署名し、タイムスタンプを追加し、送信された応答のログに応答を保存し、要求側に応答を送信します。
5.要求側が応答を受け入れ、応答の送信者を検証し、正しく署名し、タイムスタンプを付け、送信済み要求のログに要求を満たしたとマークし、応答からISにデータを送信し、署名されたデジタル署名と応答の受け入れに関するタイムスタンプメッセージで応答側に返信します。
6.応答側は、正しい署名とタイムスタンプの応答の受け入れ時にメッセージをチェックし、メッセージを保存し、受信した要求のログに要求が満たされ、応答が配信されたことを記録します。
このアプローチにより、当事者の法的責任を最大限に活用してデータ交換を整理し、伝送の問題を迅速に診断できます。 相互の呪いではなく、両側の統合リーダーは、障害が発生した段階を明確に把握します。
そして、この法的力をすべて与えるには：
1.署名を生成するための証明書は、IPの責任者（IPの所有者）からの文書に署名する権利とともに、認定認証センター（カザフスタンには単一の「NUT」-国民）によって発行/認証されなければなりません。
2. SSL接続を確立するための証明書も、認定された認証機関によって発行/認証される必要があります。
3.デジタル署名を生成するために、承認されたGOSTに従って署名を生成する認証済みの暗号プロバイダーが使用されます。
そしてあとがきとして。
この記事が誰かに役立ち、意思決定に役立つことを願っています。 そして、提案された方法が遅かれ早かれ、何らかの規範的な法的行為によって修正され、電子文書管理を使用するときに可能な限り誤解が生じないことを願っています。 Medvedev（スマイリー）に書き込みます。 複数のIP統合プロジェクトがあるため、これらのプロジェクトに固有の典型的なエラーと体系化されたリスクを説明する新しいトピックが表示される場合があります。
はい。 一部の人にとっては、プレゼンテーションスタイルが完全に読めないように思えるかもしれません。 まあ、すみません、それが脳の仕組みです。