インフラストラクチャは単純な電子署名です。 パート4：実装の実用的な側面

パート1 、 パート2 、 パート3では、 PEPインフラストラクチャの基本システムが検討されました。 このパートでは、インフラストラクチャの実用的な実装のための設計手順を検討します。 すぐに、説明は一般化されており、チュートリアルでも、指示でも、マニュアルでもないことに注意してください。 第1部で述べたように、記事全体は、複雑で多段階の技術サービスを提供するエージェントの情報システムにPEPを導入する実践に基づく個人的なビジョンにすぎません。 PEPを導入する目的は、個人にサービスを提供する際にドキュメント管理をインターネットに移行し、クライアントが会社のオフィスを訪問する必要性を最小限に抑えることにより、サービスの地域を拡大することです。 この例を単純化するために、複雑なドキュメント管理を行う大企業は考慮せず、ホームオートメーションサービスを提供する抽象的な企業を取り上げます。 そのような会社のサービスの最小バージョンのワークフローは、設計の申請、参照条件との合意、および完了行為で構成されています。

要件とアーキテクチャの説明

設計を開始する前に、利用可能なアーキテクチャの説明を体系化し、関係者の要件を収集する必要があります。 まず、システムエンジニアリングでは、連邦法、地域法、さまざまな部門および企業の規制の要件は、利害関係者の要件ではないことに注意してください。 州はプロジェクトの利害関係者ではなく、州はアナリストおよび設計者として機能し、法律は要件ではなくアーキテクチャ、概念の高レベルの説明を提供します。 この概念は、プロジェクトを行政機関や規制機関の人の状態の観点から成功させるために、必然的に完成品に具現化されなければなりません。



規制制定法で説明されている概念は、ほとんどの場合、さまざまな文書に散在しています。 これらの散らばったすべての記述の単一の概念は、 抜粋と説明を使って形成されます。 抽出は、抽出の詳細を使用して元の文書にトレースされる文書の一部です-元の文書の番号、日付、タイトル、元の文書内の位置（セクション、段落、段落番号）。 実際には、抽出物に不確実性があることが時々あります。その場合、追加の文書が使用されます。通常、説明は、国体からの手紙の形で発行されます。



プロジェクトをユニークにする実際の要件は、プロジェクト結果の設計、計画、実装、運用など、プロジェクト結果のライフサイクルによって人生が変わる可能性のある特定の個人の期待とニーズのみです。 この記事では、これらの要件はプロジェクトごとに固有かつ一意であるため、考慮されません。

PEPアーキテクチャの立法概念

鍵保管システム

署名は、伝達する情報に基づいています。 ターゲットシステムの分析中に示されたように、署名はPDに関する情報を送信します。カウンターパーティのどのPDがエージェントのオフィスシステムにローカルに登録されるかを決定する必要があります。 この質問に対する答えは、ロシア連邦民法の第20条と第21条の抜粋、つまり居住地の名前と場所によって与えられます。 ローカルの信頼空間では、これらのPDで十分ですが、 プローブの法的重要性という目標がある場合は、これらのPDによって許可された登録システムで割り当てられた識別コードが必要です。 ロシア連邦の認可されたシステムは、内務省です。 内務省は、居​​住地の名前と場所について、識別コード-シリーズとパスポート番号を割り当てます。 したがって、ローカル登録が潜在的に許可されたローカルになるためには、名前、居住地、シリーズおよびパスポート番号を登録する必要があります。



次のステップは、 プローブのキー（公開キーと秘密キー）を決定することです。 理論的には、コード、パスワード、およびプローブとしてマップされた他の手段の一意のセットを使用できます。 FZ-63からの抜粋、つまり記事4では、それがどの種類のキーであるかを指定していません。 しかし、署名の重要性を達成する必要があるため、ここでは異なる種類の司法慣行の文書に頼ることができます。 司法慣行が示すように、裁判所で争われている主な点は、選択された署名方法には手書き署名（ALP）の類似物の兆候がないことです。 異なる利害関係者は、この問題を異なる方法で解決します。 LSAの最も重要な兆候は、個人データの譲渡不能性です。公開鍵として、コードを発明することはできません。このコードは、個人署名のモノグラムに似たPDを明確に示す必要があり、パスポートに登録されたモノグラムに似た認証機関に登録する必要があります 現在、SNILSのみがそのようなコードです。 また、公共サービスの提供でPEPの公開鍵として使用され、さらに、電子デジタル署名証明書の情報でPEPの公開鍵として使用されます。 議論は、完全に異なる用途を法的に意図しているため、この役割を果たすためにSNILSがどれだけ認可されるかという問題です。 立法レベルでは、正確にこれらの目的のために新しいコードを導入する提案がありますが、これまでのところ、事実上の慣行が開発されており、変更されていないユニークなSNILSが使用され、認証機関にも登録されています。



SNILSを参照して、追加のキーを作成することはかなり可能です。それをセカンダリと呼びましょう。 これはある種の一意のログインである可能性があります。 手書きの署名の類似物について話す場合、そのようなログインはフルネームのイニシャルの手書きの記録です。 手書き署名の場合、 PEPの場合、イニシャルの記録はモノグラムをキャンセルしません-SNILSはキャンセルしません。



任意のパスワードを秘密鍵として使用できます。 ただし、このパスワードは署名の目的でのみ使用し、サイトへのアクセスなどの他の役割を組み合わせないことが非常に望ましいです。 したがって、2つの技術的な問題が解決されます： PDの所有者のみが知っている秘密鍵があります（パート2で分析された手書き署名の運動技能に類似）と電子署名イベントがあります-PEPの秘密鍵の入力は、モノグラムを視覚化するときの手の動きに似ています。



さらに、所有者が「手」を動かしたことを確認できます。 このために、2番目の公開キー（電話番号）が使用されます。 コード付きのSMSが電話番号に送信されます。この場合、1回限りの秘密キーの役割を果たします。 署名中にコードを入力することは、秘密鍵を使用することに似ています。 この電話番号の適用では、コードの予測可能性を確保することが望ましいため、署名時の秘密鍵はPDの所有者のみに知られています。 電話番号を単に追加の公開鍵として使用することは許可されていますが、その使用により署名の事実が確認されます。 この場合、送信されたコードは秘密鍵ではなく、秘密鍵は別個でなければなりません。



上記のすべてを要約すると、 PD処理システムでは、次の情報を保存する必要があります。

1. 取引相手の個人データ -居住地の名前と住所;
2. 個人データの承認された登録の識別コード -パスポートの番号とシリーズ;
3. 承認された公開キー（署名サンプル） -SNILS。
4. セカンダリ公開キー（必要な場合） -サイトログイン、電子メールアドレス、電話番号。

要するに、これは一種の電子パスポートのキャストを形成します。これは、SNILSが手書き署名のモノグラムのアナログである、従来のパスポートのローカルに承認されたアナログです。

取引先の個人データ報告システム

次のステップは、エージェントシステムでのAPの登録方法の問題を解決することです。 ここで、FZ-152およびFZ-63でPDを操作するアーキテクチャの説明に内在する大きな矛盾に遭遇します。 連邦法-152の第9条からの抜粋は、次のとおりです。

連邦法で規定されている場合、個人データの処理は、個人データの主題の書面による同意がある場合にのみ実行されます。 書面での書面による同意は、電子署名付きの連邦法に従って署名された電子文書の形式で書面での個人データの対象者の書面による同意と同等とみなされます。

問題は、 プローブの場合、電子署名を生成するためにPDを取得する必要があり、 PDを収集するために、電子署名によって既に署名された同意を取得する必要があることです。 さらに、連邦法63条9項の抜粋によると、簡単な電子署名を使用するための合意が必要です。 それは悪循環であり、一見したところ、同意書の手書き署名と個人訪問への同意によってのみ破ることができます。 ただし、 プローブの使用に関する特定の形式の契約、つまり加入契約（公募）を使用し、 PDの受領を同意の署名と組み合わせると、すべてをリモートで実行することができます。 したがって、オプションが実質的にない場合、法律は、個人的な訪問なしにタスクを行う場合、 PEPシステムで使用するカウンターパーティPDを登録するための次のアルゴリズムを規定しています。

1. 資格のある弁護士によって開発されたシンプルな電子署名の使用には、署名を使用せずに匿名で受け入れなければならない同意が必要です。 これは、 PEPを介したPDの提供に対する同意の電子署名の法的根拠を提供します。 法律は、匿名契約を編成するオプションを提供します。これは、ユーザーの無制限のサークルが参加できる加入契約です（公募）。 これは、登録時にユーザーが最初に見るべきものです。 オファーへの参加（受け入れ）の事実は、秘密鍵の形成と入力によって確認されます。 このプロセスは、再利用可能な秘密鍵（パスワード）または1回限りの秘密鍵が将来使用されるかどうかによって異なります。
2. 上記の個人データを入力するためのフォーム、つまり、氏名、居住地、シリーズおよびパスポート番号、SNILSなどには、 個人データの提供への同意を含める必要があります 。 同意自体は個人的なものでなければならず、連邦法-152の第9条にリストされているモデル条項に加えて、同意は公開キーをリストするPEPによって署名されていることを示す条項を含める必要があります：SNILS +二次キー（ある場合）。 フォーム全体が1つのアクションで署名されます（個人データと同意）。 詳細については、署名システムデバイスについては、「秘密キーに基づく公開キー転送システム」のセクションで説明します。
3. これらの手順を実行した後、ユーザーはシステムにログインし、 PEPによって署名されたアプリケーション、アプリケーション、控訴、苦情を提出する機会を得ます。 同意は取り消される可能性があるため、維持する必要があります。

保存されたPDのリストを決定したら、FZ-152の記述に固有のアーキテクチャを設計する必要があります。 このアーキテクチャの実装は、 PDを不正アクセスから保護する技術的および組織的な手段で構成されています。 取るべき主なステップ：

1. PDを使用するためにFSTECが認定したプラットフォームを選択してください。 プラットフォームは、法律の要件に従って、最低限のバージョンでは、 PDへのアクセスの分離とPDへのアクセスのすべての操作のロギングを保証する必要があります。 私の実践では、通常、MS SharePoint 2013/2016、Bitrix、Alfresco、Liferay、およびそれに応じてデータベースとして-MS SQL Server、PostgreSQL（認定AltLinuxの一部として）、MySQLのオプションが考慮されました。 当然、他のオプションも可能です。 このオプションまたはそのオプションを支持する選択は、所有コストの比較分析に基づいて、エージェントの技術部門の期待に基づいて行われます-どのプラットフォームが彼らに同行しやすいか。
2. 個人データ処理ポリシーを作成する
3. 開発されたPD処理ポリシーに基づいて、追加の認定PD保護ツールと個人データオペレーターとしての登録が必要かどうかを判断する必要があります。 このステップを実行するための特定の方法があります。特にPDが法律で「秘密」という言葉、たとえば医療秘密をラップしている場合は、 資格のある専門家を引き付ける方が良いでしょう。

最も単純なケースでは、 PDをサービス提供の目的でPDのサブジェクトを識別する以外の目的に使用できず、 PDを状況に応じて第三者に譲渡できない場合、資格のある情報セキュリティスペシャリストの許可を得て、ステップ3をスキップすることができます。

トラストスペース

次のステップは、 PEPの信頼空間の問題を解決することです。 AP処理システムのストレージのAPのソースがエージェントのサイトである場合、これはローカルの信頼空間であり、エージェントのみが信頼できます。 信頼のステータスを向上させるには、 PDの承認された登録で発行された元のドキュメントで、元のパスポートでこのデータを検証する必要があります。 サイトを介してパスポートのスキャンされたコピーを受信することは、 PDの複雑なエントリであり、 PDを入力することと大差ないため、オリジナルです。 スキャンされたパスポートのコピーをリモートで要求することはあまり意味がなく、データの信頼性を高めることはありませんが、同時にPD保護の要件のレベルを上げます。 また、取引相手の側からは、パスポートのスキャンされたコピーのリクエストは否定的な反応を引き起こすことが多いため、このオプションを拒否する必要があります。 検証のために、カウンターパーティの個別の訪問として使用できます。また、サービス提供の任意の段階と組み合わせて、カウンターパーティとの個人的なやり取りを行うこともできます。 政府の電子サービスは、 ESIAとの調整を使用します 。 また、個人データの電子検証のための別のメカニズムを作成する予定です。 したがって、個人データ処理システムのPDレコードには、確認済み/未確認の2つのステータスがあります。 同様のステータスは、公共サービスのポータルで使用されます。

署名システム

署名処理システムの目的は、他の文書に対する不耐性を保証することです。 エージェントと取引相手の両方は、取引相手が特定の文書に署名したPEPが 、その後、彼が知らない別の文書に帰することができないことを確認する必要があります。 一般に、立法行為はPEPに不寛容などの機能を提供しませんが、署名の法的重要性のためにこれは重要です。 プローブを特定のドキュメントに関連付けるには、エージェントのシステムにプローブの電子レジストリが必要です。各レジストリは一意の増分識別番号を受け取ります。 増分により、署名をその作成時間にバインドできます。小さい数字は、署名が以前に受信されたことを示します。 実際、このようなPEP番号はPEPセカンダリ公開キーです。 登録簿は、 PEPの実際の具体化に加えて、取引相手のPD 、文書の識別番号と日付、署名の時刻、およびPEPをリンクする必要があります。



レジストリは、署名処理システムの別の重要な機能を提供します。署名付きの文書を電子から紙に変換します。 裁判所などの多くの組織は、事務処理を採用しています。 必要に応じて、そのような組織に署名付きの文書を送信できるようにするには、システムに文書を電子から紙に変換するサービスが必要です。 署名済みドキュメントをPDFに変換します。 紙の形式で簡単な電子署名を視覚化する場合、 PEP公開キー（プライマリおよびセカンダリ）を視覚化する必要があります。つまり、設計、フルネーム、SNILS、電話番号（使用する場合）、および一意のPEP識別番号に基づいて視覚化します。 それらは、通常はドキュメントの内容の下に、一般に認められた書類の規則に従って、たとえば次のように視覚化されます。

簡単な電子署名で署名：

Ivanov Ivan Ivanovich、SNILS 000-000-000 00、電話（000）000-00-00。

署名登録番号：2017/01/31 10:05:47から0000000

また、省庁間電子文書管理（MEDO）の方法論的な推奨事項に依存し、PDF / A標準で視覚化することもできます。

秘密鍵を使用して公開鍵を送信するシステム

システムは、 パート2で詳細に分解されます。 アーキテクチャは、連邦法63の第12条に基づいて構築されています。つまり、システムは以下を保証する必要があります。

1. 署名手続きを開始しているというカウンターパーティへの通知。 通知には、署名した文書の詳細が表示されている必要があります。理想的には、文書は読み取り用に開かれている必要があります。 取引相手は、署名の事実と瞬間の両方を確認するために、秘密の秘密鍵を入力する必要があります。
2. ドキュメントが署名されていることをユーザーに通知します。 技術的には、署名手順は、プローブのレジストリにエントリを作成し、一意の番号を割り当てることで構成されます。 署名の登録番号、文書の登録番号、およびSMSによる署名の時刻を複製することをお勧めします。 したがって、ユーザーは実質的に「ドキュメントの2番目のコピー」を手に入れます。

オフィスシステムの適応

事務システムの適応により、署名後の文書の不変性を確保する必要があります。 PEPは、その構造上、どのような形でもこの役割を果たせません。 事務システムに入るすべての文書は、片面と多面の2種類に分類できます。 声明や控訴など、カウンターパーティによってのみ署名された一方的な文書は、通常、不変性を必要としません。 変更、編集、逸脱する可能性があります。 そのような文書の場合、相手方のPEPのみで十分です。場合によっては、オフィスシステムへの入場時にエージェントの強化された署名によって認証することができます。 一方的な文書とは対照的に、多国間の文書は不変でなければならないため、そのような文書ではエージェントが最初の署名を行い、文書の不変を保証するために暗号を使用してこの署名を強化する必要があります。 PEPが置かれた後に文書が変更されないことを相手方に保証するために、署名の時間が重要です。 強化されたエージェントの署名は、取引相手のPEPよりも早い時間にあるべきであり、この事実は独立した情報源によって記録されるべきです。 したがって、強化された署名はタイムスタンプ（OID 1.2.643.2.2.34.25）を設定できる必要があります。 これらの条件が満たされることは、相手方と代理人の間の信頼と、第三者の信頼の両方を提供することを目的としています。

おわりに

最近、公開鍵インフラストラクチャの複雑さとコストのために、個人との文書管理において単純な電子署名への移行に向けた顕著な傾向がありました。 公共サービスのポータルは、個人向け公共サービス の 大部分をPEPに転送します。 この記事が、インターネットを介して個人にサービスを提供する際に、 PEPインフラストラクチャの開発と適用に関心を持つ人々に役立つことを願っています。