1C 8.3からGNU / Linuxへの電子的な報告の問題

こんにちはGiktayms、今日はいくつかの、そして実際に-GNU / Linuxシステムにおける電子レポートの大きな問題の1つについてお話します。

Linux OSから電子レポートを送信する問題は、Habré/ Giktaymsとテーマフォーラム（Mista、Ubuntu、LOR、CryptoPro、テクニカルサポート1C：ITSフォーラム）の両方で長い間議論されてきました。 簡単に言えば、現在2つのソリューションがあります-クラウドベースのCEPを使用してブラウザー経由でレポートを送信するか、Windows（試用版を含む）がインストールされた専用/仮想マシンを使用してレポートを送信します。 当局（連邦税務サービス、PFR、FSS、Rosstat、FSRAR）が提供する特殊なユーティリティを使用してレポートを送信するオプションは、Wine @ Etersoftを使用している場合にのみ可能です。

GNU / Linux用の簿記用のプログラムがそれほど多くないことは秘密ではありません：パイナップル（現在は安静になっています）、ウクライナデビット+（ロシアの法律サポートモジュールは更新されていません、Ktuluはどれだけ知っていますか）および1Cアカウンティング。 これはネイティブアプリケーションを指します。 上記のすべてのうち、執筆時点で1Cのみが国内ソフトウェアの状態レジスタに含まれており、電子文書管理の特別なオペレーターを通じて電子的にレポートを準備および送信するためのメカニズムが含まれています。 ちなみに、1Cアカウンティングでサポートされている演算子は多くありません。ZAOKaluga-Astral（1C-Reportingサブシステムの開発者）、OOO Takskom、OOO NPFフォーラム、神話上の「その他の文書管理演算子」。
残念ながら、1Cからレポートを送信することは、通常の（そして経験豊富な）システム管理者が遭遇する可能性のある多くの困難に満ちています。 もちろん、これらの問題を詳細に検討し、それらを解決する方法を検討します。

私たちが直面している最初の問題は、暗号情報の保護です。 いいえ、彼らの不在ではなく、そうです。 Linuxの場合、インストールおよびさまざまなサブシステムで使用できるいくつかの認定された暗号情報保護ツール（GOSTサポート付き）があります。 この記事の執筆時点で、これらは次のCPSIであり、何かを見落とした場合は修正してください。

• クリプトコム
  この暗号化情報保護ツールは、i686およびamd64プラットフォームで使用でき、主にインターネットバンキングシステム、特にiBankシステム（Gazprombank、UBRIR、Alphaなどの多くの銀行で使用）で使用されます。

  
  

• Lissi CSP
  既存の暗号化情報保護ツールの1つは、暗号化情報保護ツール、Mozilla Firefoxブラウザー、Mozilla Thunderbirdメールクライアントのバージョンに加えて、GOSTファミリーの暗号化アルゴリズムと電子デジタル署名をサポートします。 残念ながら、iTokenプラットフォームのみをサポートし、ruTokenドライバーを使用すると、CIPFの互換性を検証できませんでしたが、メーカーは主張しています。 ただし、Mozilla製品の拡張機能は定期的に証明書を確認し、GOSTアルゴリズムを使用したHTTPS署名、暗号化、および双方向認証を許可します。 1Cとの互換性はテストしていません。
  それにもかかわらず、システムの32ビットバージョンを使用する場合、製品は非常に価値があります。 この場合、プロセスごとに3 GBを超えるメモリを割り当てることができるアプリケーションはないことに注意してください。 DBMSなどの一部のアプリケーションは、shmemでトリックを実行し、各セッションに1つのプロセスを割り当てるため、最大64 GBのメモリを使用できますが、1Cアカウンティングではこのようなテクノロジーを使用しないため、この暗号情報保護を備えた32ビットアーキテクチャーにサーバーをインストールすることはお勧めしません。

  
  

• CryptoPro CSP
  実際、現時点で電子署名と暗号化を使用するための唯一の完全なLinuxソリューションです。 i686、amd64、armhf（Androidを含む）、PowerPCプラットフォームで利用可能です。 これには、Solaris（i686、amd64、sparc）、AIX、FreeBSD、OSX、iOSのバージョンがあることは言うまでもありません。 奇妙なことに（皮肉）、CryptoProが相互作用と電子文書管理のために多くの公的機関によって公式に推奨されています。 CryptoProライセンスは、EDSキーの一部として、およびレポート用の統合サービス契約の一部として提供されることがよくあります。 私の選択は、この暗号情報保護を支持する明確な選択でした。 短所には、RHEL / SLES以外のシステムでのインストールの相対的な複雑さと、ソフトウェアパッケージのアセンブリで発生する欠点（インポートされた文字や依存関係が壊れたエクスポート関数は許可されません）が含まれます。 ほとんどの場合、これらの欠点はユーザーには見えません。なぜなら、 これらの関数は、CryptoProの一部としてさまざまなライブラリを操作するように設計されており、OSカーネルによって最初に呼び出されたときに自動的に有効になります（必要なライブラリはアプリケーションのアドレス空間に既にロードされています）。 2番目のマイナスは、CryptoFoxブラウザーが表示される場合、電子メールクライアントがないことですが、CryptoProでThunderbirdのサポートを拒否しました。 GOSTをサポートするために、NSSの作業バージョンに変更を加える積極的な試みが行われたことに敬意を表さなければなりませんが、それはまだ存在しています。 変更が受け入れられた場合、Open / LibreOffice、Mozilla、Nautilus / Nemo、Thunar、XCAなどのプログラムなど、NSSを使用するすべてのブラウザーとアプリケーションでGOSTサポートが表示されます。

  
  
• Vipnet
  別の認証された暗号情報保護ツール。そのサポートは最初は1Cにあります。 i686およびamd64アーキテクチャ用のベータ版があります。 残念ながら、CIPF自体に加えて、彼らはLinux用の製品をもう持っておらず、ポータルや取引プラットフォームでの本格的な作業は不可能です。

明らかな理由から、CryptoPro CIPが選択されました。これについて詳しく説明します。

まず、Linuxプラットフォームでは、ドキュメントに署名するために多くの人に馴染みのあるCryptoARMアプリケーションがありません。 ただし、アタッチおよびデタッチされた署名を作成するには、コマンドラインユーティリティを使用できます。 デタッチされたデジタル署名を作成して検証するために、それぞれ署名と検証の2つのスクリプトを作成しました。 スクリプトのテキストを以下に示しますが、それらはやや残酷であることに同意しますが、それらは急いで書かれており、その時点でCryptoPro 4.0のベータ版は、署名されたファイルと出力ファイルへのパスの直接転送で奇妙に動作していました。

#!/bin/sh DIR=`dirname $1` /opt/cprocsp/bin/amd64/cryptcp -signf $2 $3 -cert -der -norev "$1" mv "$1.sgn" "$1.p7s" 

 #!/bin/sh DIR=`dirname $1` cp "$1.p7s" "$1.sgn" /opt/cprocsp/bin/amd64/cryptcp -vsignf -der -norev "$1" rm "$1.sgn" 

第二に、これは非常に重要です。次の図があります。 1Cアカウンティングでは、CryptoPro CIPFを使用するための標準設定はバージョン3.6で提供されます。 バージョン3.6は、CryptoFoxの古いバージョンを実行します。 これで、美徳は終わり、頭痛が始まります。 古いバージョンのCryptoFoxには最新のサイトは表示されません。税務署のポータルもどこかに忍び寄っています。 インストールしようとするとき 〜新鮮 〜CryptoFox 31の現在のバージョンは、GOSTアルゴリズムでHTTPSを必要とするサイトに入るとクラッシュします（セグメンテーションフォールト）。 CryptoPro Browser Pluginプラグインが機能していてもクラッシュすることがあります。 ちなみに、暗号化ではなく署名のみをサポートし、NPAPIでのみ動作する非常に古いバージョンでもあります。

バージョン3.9では、状況はさらに面白くなります。1Cはそれを認識しなくなりましたが、CryptoFoxはクラッシュし、古いものと新しいものの両方がクラッシュします。

反対に、バージョン4.0は1Cのようには見えませんが、CryptoPro Browser Plugin 2.0が起動し、CryptoFox作品から政府サイトへの入り口があります（それらについては個別の議論があり、GNU / Linuxから作品を分解すると、もう1つの記事に十分な資料があります） 。 問題は、暗号情報保護のために1つのSKUをインストールすることです。 一般的に、問題はそれほど深刻ではなく、文字通り15秒で解決されますが、CryptoProの技術サポートで解決策を見つけるのに1週間かかりました（そして1CサポートでITSの指示を押してくれました）。 その結果、問題は個別に解決され、最終的にソリューションはCryptoProフォーラムに公開されました。 将来の問題解決方法：

• 1Cアカウンティングでは、任意の暗号化プロバイダーを追加できます。 このメカニズムを使用して、新しい暗号化プロバイダーを追加し、「CryptoPro CSP 4.0」と言う名前を付けます。

  
  
• 暗号プロバイダーの名前とそのタイプを取得するには、CryptoProユーティリティを使用する必要があります。 このデータを取得する最も簡単な方法は、インストール済みの証明書をリストすることです。

 /opt/cprocsp/bin/amd64/certmgr -l 

• 次のデータを示します。
  

  プログラム名	Crypto-Pro GOST R 34.10-2001 KC1 CSP
  プログラムの種類	75
  署名アルゴリズム	GOST R 34.10-2001
  ハッシュアルゴリズム	GOST R 34.11-94
  暗号化アルゴリズム	GOST 28147-89

• 暗号プロバイダーを保存し、ライブラリへのパスを指定します：/opt/cprocsp/lib/amd64/libcapi20.so

完了、1Cはインストールされた暗号プロバイダーを確認します。 どうやら-証明書を追加してレポートを設定することですべてを実行できますが、ここにはありません。 小さな白いシベリアのキツネは、私たちが予期していなかった場所-開発者自身1Cから忍び寄ってきました。 歴史的に、電子文書管理サブシステム、1C-Reporting、1Cコア、および構成は、さまざまな人々、さらにはさまざまな企業によって記述されています。 「エンタープライズアカウンティング3.0」など、1C 8.3用の1Cレポート機能を使用して構成を作成する場合、開発者はためらうことなくEDCOサブシステム全体を変更せずに「そのまま」転送し、パラドックスをもたらしました。 1Cアカウンティング自体は、暗号化情報保護ツール、証明書、ドキュメントのインストール、署名、暗号化を可能にしますが、同時に電子ドキュメント管理システム（古いバージョン）はインストールされた単一の証明書を認識しないため、ドキュメント管理オペレーターから初期構成を取得することさえできません-単に解読するものはありません。 解読するのではなく、ありますが、EDCOサブシステムは、外部コンポーネント（Windowsのみ）を使用して、暗号情報保護を操作する独自のメカニズムを使用し、1C自体が構成の一部として使用する暗号情報保護を操作するための組み込みメカニズムの存在については何も知りません。

それでも、EDIサブシステム（EDCOと混同しないでください）は、取引先とすべての関連する証明書を確認し、電子文書管理システムに接続できます。 しかし、報告していません。
Linuxの場合、外部構成データベースを使用したClient-EDI構成の直接操作には制限があり、このためには機能する1Cサーバーが必要です。 構成の基本バージョンでは、クライアントサーバーバージョンの1C展開の使用が許可されないため、このような構成でのClient-EDIとアカウンティングのLinuxへの統合は不可能であり、完全に機能する構成でのみ機能します。 ほとんどの構成では、取引先との交換を有効にできます。1Cレポートが機能していなくても機能します。

コンフィギュレーターを開いてデバッグモードを有効にすると、次の図が表示されます。
Forms 1C-ReportingはGeneral-> General Modules-> Cryptography EDCO Clientを使用します。これは、外部コンポーネントAddin.EDONative.CryptSの作業に依存しています。
（電子通信チャネルを介してトランスポートコンテナを交換する機能を持たない）電子デジタル署名と暗号化を処理するための同じ機能が、一般->一般モジュール->電子署名顧客に実装されます。これは、LinuxファミリーのOSでの作業を考慮し、XMLDSigを操作する外部コンポーネントの両方を正しくロードします。および暗号プロバイダーモジュール。 このライブラリはすべての証明書を正しく表示し、ドキュメントの署名と暗号化を可能にし、メモリ内のオブジェクトとハードディスク上のファイルの両方を操作する機能が含まれています。 このライブラリは、1C-Reportingサブシステム（EDCO）を除き、1C内でデジタル署名を処理するためのすべての標準メカニズムで使用されます。

つまり、1C EDCOサブシステムの作業を実装するには、1Cレポートフォームを書き換えて組み込みメカニズムを使用するか、EDCOKlient Cryptographyをオーバーロードして外部コンポーネントを使用せず、呼び出しを証明書、デジタル署名、および暗号化情報保護を備えた組み込みクライアントに転送するように書き直すだけで十分です。
1Cテクニカルサポートとのコミュニケーションでは、この問題を認識しているという回答しか得られませんでしたが、GNU / Linux OSを使用しているクライアントは少なすぎます（必要性は広がっていません）。

UPD：
タキは、ソースの詳細な調査の後、マスターの仕事を開始することができました。 Takskomからコンテナを復号化することに固執している間、証明書はすでに表示されています。 CryptoPro 4の最新バージョンでのみ動作します。次のように起動します。 表現の名前は役割を果たしませんが、1C-EDCOの「内部」は次のようになります。

検証に必要なのは、フィールドProgram nameとProgram typeです。 プログラムの名前は、暗号化プロバイダー2.0のバージョンとの互換モードを指します。ベータバージョン4.0では名前はありませんでした。

主な問題はここに隠されています：一般->一般モジュール->暗号化EDCOM ServiceCustomer.GetCryptoproviders

  = (1, ); 

Linuxの場合、削除します。 または、CryptoProバージョン3.9以降のチェックを追加します。
一般->一般モジュール->暗号化EDCOCustomerServer.Get Crypto Providers.Crypto ProviderCryptoPro
名前： Crypto-Pro GOST R 34.10-2001 KC1 CSP
クライアント用、または
名前： Crypto-Pro GOST R 34.10-2001 KC2 CSP
サーバー用。