1cリクエストが複雑すぎる、スタックオーバーフローの可能性があります。スタックオーバーフロー。アプリケーションサーバーとMSSQLServer間の送信中のデータ暗号化

この記事でも、セキュリティ対策のセットは、開発、展開、システム管理、そしてもちろん組織的な対策など、実装のすべての段階をカバーする必要があることを示しています。情報システムでは、主なセキュリティの脅威は「人的要因」（ユーザーを含む）です。この一連の対策は合理的でバランスが取れている必要があります。それは意味がなく、データ自体のコストを超える保護を組織化するために十分な資金が割り当てられる可能性は低いです。

序章

1C：Enterpriseはロシアで最も普及している会計システムですが、それにもかかわらず、バージョン8.0まで、開発者はセキュリティの問題にほとんど注意を払っていませんでした。もちろん、基本的に、これは製品の価格ニッチと資格のあるITスペシャリストがいない中小企業への焦点によって決定され、安全なシステムの展開と維持にかかる可能性のあるコストは企業にとって法外に高くつくでしょう。バージョン8.0のリリースにより、焦点が変更されたはずです。ソリューションのコストが大幅に増加し、システムがはるかにスケーラブルで柔軟になりました。要件が大幅に変更されました。システムが十分に信頼でき、安全になったかどうかは、非常に個人的な問題です。現代の企業の主要な情報システムは、少なくとも次のセキュリティ要件を満たす必要があります。

内部的な理由によるシステム障害の可能性はかなり低いです。
信頼性の高いユーザー認証と不正なアクションからのデータ保護。
ユーザー権限を割り当てるための効果的なシステム。
障害が発生した場合のオンラインバックアップおよびリカバリシステム。

1C：Enterprise 8.0に基づくソリューションはそのような要件を満たしていますか？単一の答えはありません。アクセス制御システムの大幅な変更にもかかわらず、未解決の問題がまだたくさんあります。システムの開発方法と構成方法によっては、これらの要件がすべて満たされていないか、この実装に十分な程度に満たされている場合がありますが、注意を払う価値があります（これは、プラットフォームの「若さ」の重大な結果です。）記載されている条件を満たすためには、真に巨大な努力を払わなければなりません。

この記事は、1C：Enterpriseプラットフォーム上のソリューションの開発者と実装者、および1C：Enterpriseが使用されている組織のシステム管理者を対象としており、システムのクライアントサーバーバージョンの開発と構成のいくつかの側面について説明しています。組織の視点。情報セキュリティー..。この記事は、ドキュメントの代わりとして使用することはできませんが、まだ反映されていないいくつかのポイントのみを示しています。そしてもちろん、この記事もすべてのドキュメントも、セキュリティ、パフォーマンス、利便性、機能の相反する要件を同時に満たす必要がある、安全な情報システムを構築する問題の複雑さを反映することはできません。

分類と用語

この記事の主要な主題は情報の脅威です。

情報の脅威-データが不正に読み取られたり、コピーされたり、変更されたり、ブロックされたりする可能性。

そして、この定義に基づいて、この記事では情報の脅威を次のように分類しています。

データの不正な破壊
データの不正な変更
データの不正コピー
データの不正な読み取り
データにアクセスできない

すべての脅威は、意図的なものと意図的でないものに分けられます。実装された情報の脅威は呼び出されます インシデント..。システムの機能は次のとおりです。

脆弱性-インシデントにつながる機能 保護対策-インシデントの可能性をブロックする機能

基本的には、これらのケースのみが考慮され、その可能性は、クライアントサーバーバージョンの技術プラットフォーム1C：Enterprise 8.0の使用によるものです（以下、これが1Cまたは1C8.0の意味と矛盾しない場合）。）。システムの使用に関連して、次の主な役割を定義しましょう。

演算子-アプリケーションの役割に限定されたデータを表示および変更する権限を持っているが、管理機能を持っていないユーザー
システム管理者-アプリケーションサーバーとMSSQLサーバーのオペレーティングシステムの管理者権限、MS SQLの管理者権限など、システムの管理者権限を持つユーザー。
情報セキュリティ管理者-1Cインフォベースで特定の管理機能（ユーザーの追加、テストと修正、バックアップ、適用ソリューションの設定など）
システム開発者-アプリケーションソリューションを開発しているユーザー。一般に、彼らは作業システムにアクセスできない可能性があります。
システムに直接アクセスできない人-1Cにアクセスする権限が委任されていないが、何らかの形でシステムの操作に影響を与える可能性があるユーザー（通常、これらはすべて、システムがインストールされている同じActive Directoryドメインのユーザーです）。このカテゴリは、主にシステム内の潜在的に危険な対象を識別するために考慮されます。
自動化された管理スクリプト-特定のアクション（データのインポート/エクスポートなど）を自動的に実行するように設計された、一部の機能が委任されているプログラム

ここで注意すべき点が2つあります。1つは、この分類が非常に大まかなものであり、各グループ内の区分が考慮されていないことです。このような区分は、特定の場合に作成されます。2つ目は、他の人がシステム。1Cの外部の手段を備えている必要があります。

すべてのセキュリティシステムは、適切性と所有コストを念頭に置いて設計する必要があります。一般に、情報システムを開発および実装する場合、システムを保護するための価格は以下に対応する必要があります。

保護されている情報の価値。
インシデントを作成するコスト（意図的な脅威の場合）。
事件が発生した場合の経済的リスク

経済的有効性を評価するよりもはるかに費用のかかる保護を組織化することは無意味で有害です。情報損失のリスクを評価する方法はいくつかありますが、この記事ではそれらについては考慮していません。もう1つの重要な側面は、情報セキュリティ、システムパフォーマンス、システムでの作業の利便性と単純さ、開発と実装の速度、および企業の情報システムに関するその他の要件について、しばしば矛盾する要件のバランスを維持することです。

システムの情報セキュリティメカニズムの主な機能

1C：Enterprise 8.0には、ファイルとクライアントサーバーの2つのバージョンがあります。次の理由により、ファイルバージョンはシステムの情報セキュリティを確保しているとは見なされません。

データと構成は、システムのすべてのユーザーが読み書きできるファイルに保存されます。
以下に示すように、システム認証は非常に簡単にバイパスできます。
システムの整合性は、クライアント部分のコアによってのみ提供されます。

クライアントサーバーバージョンでは、MS SQL Serverを使用して情報を格納し、次の情報を提供します。

より信頼性の高いデータストレージ。
直接アクセスからのファイルの分離。
より良いトランザクションとロックメカニズム。

システムのファイルバージョンとクライアントサーバーバージョンには大きな違いがありますが、アプリケーションソリューションレベルで単一のアクセス制御スキームがあり、次の機能を提供します。

1Cで指定されたパスワードを使用したユーザー認証。
現在のWindowsユーザーによるユーザー認証。
システムユーザーへの役割の割り当て。
役割ごとに管理機能の実行を制限します。
使用可能なインターフェースを役割ごとに割り当てます。
ロールごとにメタデータオブジェクトへのアクセスを制限します。
ロールごとにオブジェクト属性へのアクセスを制限します。
ロールとセッションパラメータによってデータオブジェクトへのアクセスを制限します。
データおよび実行可能モジュールへの対話型アクセスを制限します。
コード実行に関するいくつかの制限。

一般に、使用されるデータアクセススキームは、このレベルの情報システムでは非常に一般的です。ただし、この3層クライアントサーバーアーキテクチャの実装に関連して、比較的多数の脆弱性につながるいくつかの基本的な側面があります。

データ処理の多数の段階、および各段階で、オブジェクトにアクセスするための異なるルールが適用される場合があります。

セキュリティの観点から重要なデータ処理ステップのやや簡略化された図を図1に示します。 1Cの一般的なルールは、このスキームに沿って下に移動するときに制限を減らすことです。したがって、次のいずれかの脆弱性を悪用します。上位レベルすべてのレベルでシステムの動作を混乱させる可能性があります。
レベル間を移動するときに送信データを制御するためのデバッグ手順が不十分です。

残念ながら、システムのすべての内部メカニズムが完全にデバッグされているわけではありません。特に非対話型メカニズムの場合、デバッグには常に時間がかかりますが、責任は大きくなります。この「病気」は1Cだけの問題ではなく、ほとんどのベンダーの多くのサーバー製品に見られます。近年になってようやく、これらの問題への注目が大幅に高まっています。
以前のバージョンから継承した開発者とシステム管理者の平均資格が不十分です。

1C：Enterpriseラインの製品は、当初、開発とサポートの容易さ、および小規模な組織での作業に重点を置いていたため、歴史的に、アプリケーションソリューションの「開発者」とシステムの「管理者」の大部分がそうではないことは驚くべきことではありません。はるかに複雑な製品であるバージョン8.0を操作するのに十分な知識とスキルを持っている。この問題は、フランチャイジー企業がこの問題に体系的に取り組むことなく、クライアントを犠牲にして「戦闘中」にトレーニングするために採用した慣行によって悪化しています。過去数年間でこの状況は徐々に改善している1Cに敬意を表する必要があります。深刻なフランチャイジー企業は、人材の採用とトレーニングの問題に対してより責任あるアプローチになり、1Cからの情報技術サポートのレベルは大幅に向上しています。認定プログラムは、高レベルのサービスに焦点を合わせているようです。ただし、状況をすぐに修正することはできないため、システムのセキュリティを分析する際には、この要素を考慮に入れる必要があります。
プラットフォームの比較的小さな年齢。

同様の焦点と使用目的を持つ製品の中で、これは最も若いソリューションの1つです。プラットフォームの機能は、多かれ少なかれ1年以内に解決されました。同時に、8.0.10以降のプラットフォームの各リリース（システムの現在の機能のほとんどすべてが実装されたのはこのリリースでした）は、以前のリリースよりもはるかに安定しました。プラットフォームの機能の半分はせいぜい使用されていますが、典型的なアプリケーションソリューションの機能はまだ飛躍的に成長しています。もちろん、そのような状況では、安定性について暫定的に話すことができますが、全体として、1C 8.0プラットフォームに基づくソリューションは、機能とパフォーマンスの点で1C7.7プラットフォーム上の同様のソリューションよりも大幅に優れていることを認める必要があります。（そしてしばしば安定性の観点からも）。

そのため、システム（および場合によっては一般的なアプリケーションソリューション）は企業に展開され、コンピューターにインストールされます。まず、1Cセキュリティを設定するのが理にかなっている環境を作る必要があります。そのためには、システム設定がシステム設定の影響を大きく受けるという前提が満たされるように設定する必要があります。

セキュリティを設定するための一般的なルールに従ってください。

安全なシステムを作成するという基本原則に従わなければ、システムの情報セキュリティに疑問の余地はありません。少なくとも次の条件が満たされていることを確認してください。

サーバーへのアクセスは物理的に制限されており、サーバーの中断のない操作が保証されます。
- サーバー機器は信頼性の要件を満たし、障害のあるサーバー機器の交換がデバッグされます。特に重要な領域では、冗長回路が使用されます。ハードウェア（RAID、複数のソースからの電源、複数の通信チャネルなど）;
- サーバーは施錠された部屋にあり、この部屋はリモートで実行できない作業中のみ開かれます。
- サーバールームを開く権利を持っているのは1人か2人だけです。緊急時には、責任者への通知システムが開発されています。
- サーバーの無停電電源装置が提供されます
- 機器の通常の気候モードの操作が保証されます。
- サーバールームには火災警報器があり、洪水の可能性はありません（特に1階と最後の階）。
企業のネットワークと情報インフラストラクチャの設定は正しいです。
- すべてのサーバーにはファイアウォールがインストールおよび構成されています。
- すべてのユーザーとコンピューターはネットワーク上で承認されており、パスワードは推測できないほど複雑です。
- システムオペレータには、システムを正常に操作するための十分な権限がありますが、管理アクションに対する権限はありません。
- ウイルス対策ツールは、ネットワーク内のすべてのコンピューターにインストールされ、有効になっています。
- ユーザー（ネットワーク管理者を除く）がクライアントワークステーションの管理者権限を持っていないことが望ましい。
- インターネットおよびリムーバブルメディアへのアクセスは規制および制限する必要があります。
- セキュリティイベントのシステム監査を構成する必要があります。
主な組織の問題は解決されました：
- ユーザーは、1Cとハードウェアを操作するのに十分な資格を持っています。
- 運用ルール違反の責任はユーザーに通知されます。
- 情報システムの重要な要素ごとに、財政的責任者が任命されました。
- 全てシステムブロック密封され、閉じられています。
- クリーナー、ビルダー、電気技師の指導と監督には特に注意してください。これらの人は、過失により、システムの悪意のあるユーザーによって引き起こされる意図的な危害に匹敵しない損害を引き起こす可能性があります。

注意！このリストは網羅的なものではありませんが、かなり複雑で高価な情報システムを展開するときに見落とされがちなことだけを説明しています。

MS SQL Server、アプリケーションサーバー、およびクライアント側は異なるコンピューターで動作し、サーバーアプリケーションは特別に作成された権限の下で動作します Windowsユーザー;
MS SQLServerの場合
- 混合認証モードが設定されている
- serveradminロールに含まれるMSSQLユーザーは、1Cの作業に参加しません。
- IS 1Cごとに、サーバーへの特権アクセス権を持たない個別のMSSQLユーザーが作成されました。
- ある情報セキュリティのMSSQLユーザーは、他の情報セキュリティにアクセスできません。
ユーザーは、ApplicationServerおよびMSSQLServerファイルに直接アクセスできません。
オペレーターの職場には、Windows 2000 / XP（Windows 95/98 / Meではない）が装備されています。

システム開発者の推奨事項とドキュメントの読み方をおろそかにしないでください。「方法論の推奨事項」セクションのITSのディスクには、システムのセットアップに関する重要な資料が公開されています。次の記事に特に注意してください。

アプリケーションの機能は1Cで動作します：エンタープライズサーバー
データ配置1C：Enterprise 8.0
1Cの更新：ユーザーによるEnterprise 8.0 マイクロソフトウィンドウズ管理者権限なし
管理者権限を持たないユーザーに代わってユーザーのリストを編集する
SQL Server2000およびSQLServerデスクトップエンジン（MSDE）を実行するためのWindows XPSP2ファイアウォール設定の構成
1C用のCOM + Windows XP SP2パラメーターの構成：Enterprise8.0サーバー操作
1C用のWindowsXP SP2ファイアウォールパラメータの構成：Enterprise8.0サーバーの操作
HASP LicenseManagerのWindowsXPSP2ファイアウォール設定の構成
SQL Server2000を使用してインフォベースのバックアップコピーを作成する
1Cのインストールと構成に関する質問：「client-server」オプションのEnterprise 8.0（最も重要な記事の1つ）
特殊性 Windowsの設定 1Cをインストールする場合のServer2003：Enterprise8.0サーバー
クライアントサーバーバージョンでの情報ベースへのユーザーアクセスの規制（最も重要な記事の1つ）
サーバー1C：エンタープライズおよびSQL Server
1C：Enterprise8.0を「クライアントサーバー」バージョンでインストールするための詳細な手順（最も重要な記事の1つ）
1Cでの組み込み言語の使用：エンタープライズサーバー

ただし、ドキュメントを読むときは、受け取った情報に注意してください。たとえば、「クライアントサーバー」オプションでの1C：Enterprise 8.0のインストールと構成に関する質問では、USER1CV8SERVERユーザーに必要な権限はありません。非常に正確に記述されています。以下のリストへのリンクがあります。たとえば、[ITS1]は「1Cでの作業の特殊性：エンタープライズサーバー」という記事を意味します。記事へのすべてのリンクは、執筆時点（2006年1月）の最新のITS号の時点で提供されています。

Windows認証と組み合わせたユーザーの認証機能を使用する

2つの可能なユーザー認証モードのうち：組み込みの1CとWindows OS認証との組み合わせ-可能であれば、組み合わせた認証を選択する必要があります。これにより、ユーザーが作業中に複数のパスワードと混同されることはありませんが、同時にシステムのセキュリティレベルが低下することはありません。ただし、Windows認証のみを使用するユーザーの場合でも、作成時にパスワードを設定し、その後で1C認証を無効にすることを強くお勧めします。与えられたユーザー..。 Active Directory構造が破壊された場合にシステムを確実に回復するには、1C認証を使用してシステムに入ることができるユーザーを少なくとも1人残す必要があります。

アプリケーションソリューションの役割を作成するときは、「予約済み」の権限を追加しないでください

アプリケーションソリューションの各役割は、この役割によって定義されたアクションを実行するために最低限必要な一連の権限を反映している必要があります。ただし、一部の役割は単独では使用できない場合があります。たとえば、インタラクティブな起動の場合外部治療別の役割を作成して、外部処理を使用する必要があるすべてのユーザーに追加できます。

ログとシステムログを定期的に確認する

可能な限り、ログとシステム操作プロトコルのレビューを規制および自動化します。適切な構成とログの定期的なレビュー（重要なイベントのみによるフィルタリング）により、不正なアクションを早期に検出したり、準備段階で防止したりすることができます。

クライアントサーバーバージョンのいくつかの機能

このセクションでは、クライアントサーバーバージョンのいくつかの機能とそれらがセキュリティに与える影響について説明します。読みやすくするために、次の指定が受け入れられます。

注意！脆弱性の説明

システムへのアクセスを制御する情報の保存

情報セキュリティユーザーのリストを保存する

このISのユーザーのリストと、ISで使用できるロールに関するすべての情報は、MS SQLデータベースのParamsテーブルに格納されます（[ITS2]を参照）。このテーブルの構造と内容を見ると、ユーザーに関するすべての情報が、FileNameフィールドの値が「users.usr」のレコードに格納されていることが明らかになります。

ユーザーはMSSQLデータベースにアクセスできないと想定しているため、侵入者はこの事実自体を使用することはできませんが、MS SQLでコードを実行できる場合は、（！）1Cからのアクセス..。同じメカニズム（マイナーな変更を含む）をシステムのファイルバージョンに使用できます。これは、ファイルバージョンの特性を考慮すると、安全なシステムの構築への適用性を完全に排除します。

おすすめ：現在、このような変更からアプリケーションを完全に保護する方法はありません。ただし、MS SQL Serverレベルでトリガーを使用すると、プラットフォームのバージョンを更新したり、ユーザーのリストを変更したりするときに問題が発生する可能性があります。。このような変更を追跡するには、1Cログを使用するか（ユーザーを指定せずにコンフィギュレーターモードで「疑わしい」ログインに注意を払う）、SQLプロファイラーを常に実行し続ける（システムパフォーマンスに非常に悪い影響を与える）か、アラートを構成します。メカニズム（ほとんどの場合、トリガーを使用して一緒に）

サーバーにIBリストに関する情報を保存する

1Cアプリケーションサーバーごとに、それに接続されているMSSQLデータベースのリストに関する情報が格納されます。各インフォベースは、アプリケーションサーバーとMSSQLサーバーの間で独自の接続文字列を使用します。アプリケーションサーバーに登録されている情報ベースに関する情報は、接続文字列とともに、サーバーのディレクトリにあるsrvrib.lstファイルに保存されます。<Общие данные приложений>/ 1C / 1Cv8（たとえば、C：/ドキュメントと設定/すべてのユーザー/アプリケーションデータ/ 1C / 1Cv8 / srvrib.lst）。情報セキュリティごとに、混合MSSQL認証モデルを使用する場合のMSSQLユーザーパスワードを含む完全な接続文字列が格納されます。このファイルの存在により、MS SQLデータベースへの不正アクセスを恐れることができます。推奨事項に反して、特権ユーザー（ "sa"など）を使用して少なくとも1つのデータベースにアクセスすると、 1つのISの脅威に加えて、MSSQLを使用するシステム全体が脅威にさらされます。

MS SQLサーバーで認証とWindows認証を混在させて使用すると、このファイルにアクセスするときにさまざまな種類の問題が発生することに注意してください。したがって、Windows認証の主なネガティブプロパティは次のようになります。

1セットの権限（おそらく冗長）の下でのアプリケーションサーバーおよびMSSQLサーバー上のすべての情報セキュリティの操作
パスワードを指定せずに1Cアプリケーションサーバープロセスから（または、一般的にはUSER1CV8SERVERユーザーまたはその類似物から）、パスワードを指定せずに情報セキュリティに簡単に接続できます。

一方、攻撃者がユーザーのコンテキストUSER1CV8SERVERから任意のコードを実行することは、指定されたファイルを取得することよりも難しい場合があります。ちなみに、このようなファイルの存在は、異なるコンピューター上のサーバー機能を分離するためのもう1つの議論です。

おすすめ： srvrib.lstファイルには、サーバープロセスからのみアクセスできる必要があります。このファイルを変更するには、必ず監査を設定してください。

残念ながら、デフォルトでは、このファイルはほとんど完全に読み取れません。これは、システムを展開するときに考慮する必要があります。理想的には、アプリケーションサーバーは、操作中（このサーバーで実行されているユーザー接続による読み取りと書き込みを含む）にこのファイルの読み取りと書き込みを防止します。

サーバー上で情報セキュリティを作成する際の承認の欠如

注意！認証エラーは、1C：Enterpriseプラットフォームのリリース8.0.14で修正されました。このリリースでは「1C：Enterprise Server Administrator」の概念が導入されていますが、管理者のリストはサーバー上で指定されていますが、システムは以下のように動作するため、この可能な機能を忘れないでください。

おそらく、このセクションの最大の脆弱性は、アプリケーションサーバーにほぼ無制限の情報セキュリティを追加できることです。その結果、アプリケーションサーバーへの接続にアクセスできるユーザーは、アプリケーションサーバーで任意のコードを実行する機会を自動的に取得します。。例を見てみましょう。

システムは、次のバリアントでインストールする必要があります

MS SQL Server 2000（例：ネットワーク名SRV1）
サーバー1C：Enterprise 8.0（ネットワーク名SRV2）
1Cのクライアント部分：Enterprise 8.0（ネットワーク名WS）

WSで作業しているユーザー（以下、USER）は、SRV2に登録されているIBの1つに少なくとも最小限のアクセス権を持っているが、SRV1およびSRV2への特権アクセス権を持っていないことを前提としています。一般に、リストされているコンピューターの機能の組み合わせは状況に影響を与えません。システムは、ドキュメントおよびITSディスクの推奨事項を考慮して構成されました。状況は図に反映されています。 2.2。

1Cユーザーのみがアプリケーションサーバープロセスに接続する権利を持つように、アプリケーションサーバーでCOM +セキュリティを構成します（詳細[ITS12]）。

srvrib.lstファイルは、USER1CV8SERVERユーザーに対して読み取り専用である必要があります（サーバーに新しいIBを追加するために一時的に書き込みを有効にします）。

MS SQLに接続するには、TCP / IPプロトコルのみを使用します。この場合、次のことができます。
ファイアウォールを使用して接続を制限します。

非標準のTCPポートの使用を構成します。これにより、「外部」IS1Cの接続が複雑になります。

アプリケーションサーバーとSQLサーバー間で送信されるデータの暗号化を使用します。

サードパーティのMSSQLサーバーを使用できないようにサーバーファイアウォールを構成します。

イントラネットセキュリティツールを使用して、許可されていないコンピュータがに表示される可能性を排除します地元のネットワーク（IPSec、グループセキュリティポリシー、ファイアウォールなど）;

いかなる状況においても、アプリケーションサーバーに対するUSER1CV8SERVER管理者権限を付与しないでください。

サーバー上で実行されているコードを使用する

1Cのクライアントサーバーバージョンを使用する場合、開発者はクライアントとアプリケーションサーバー間でコード実行を分散できます。コード（プロシージャまたは関数）をサーバー上でのみ実行するには、「Server」プロパティが設定されている一般モジュールに配置する必要があります。モジュールの実行が許可されている場合は、サーバーだけでなく、「＃サーバーの場合」に限定されたセクションにコードを配置します。

＃サーバーの場合
OnServer関数（Param1、Param2 = 0）エクスポート//この関数は、その単純さにもかかわらず、サーバー上で実行されます
Param1 = Param1 + 12;
Param1の返却;
EndFunction
＃EndIf

サーバー上で実行されるコードを使用する場合は、次の点に注意してください。

コードは、アプリケーションサーバーでUSER1CV8SERVER権限で実行されます（COMオブジェクトとサーバーファイルが利用可能です）。
すべてのユーザーセッションはサービスの1つのインスタンスによって実行されるため、たとえば、サーバー上のスタックオーバーフローにより、すべてのアクティブなユーザーが切断されます。
サーバーモジュールのデバッグは困難ですが（たとえば、デバッガーでブレークポイントを設定することはできません）、実行する必要があります。
クライアントからアプリケーションサーバーへの、またはその逆の制御の転送には、大量の送信パラメータを含む大量のリソースが必要になる場合があります。
インタラクティブツール（フォーム、スプレッドシートドキュメント、ダイアログボックス）、外部レポート、およびアプリケーションサーバーでのコード処理はできません。
グローバル変数（「エクスポート」表示で宣言されたアプリケーションモジュール変数）の使用は許可されていません。

詳細については、[ITS15]およびITSの他の記事を参照してください。

アプリケーションサーバーには、特別な信頼性要件が必要です。適切に構築されたクライアントサーバーシステムでは、次の条件を満たす必要があります。

クライアントアプリケーションのアクションによってサーバーが中断されることはありません（管理上の場合を除く）。
サーバーを実行できませんプログラムコードクライアントから受け取った;
リソースはクライアント接続全体に「公平に」分散され、現在の負荷に関係なくサーバーの可用性を確保する必要があります。
データロックがない場合、クライアント接続は互いの作業に影響を与えないはずです。
サーバーにはユーザーインターフェイスはありませんが、監視およびログツールを開発する必要があります。

一般に、1Cシステムはこれらの要件に近づくように構築されています（たとえば、サーバー上で外部処理を強制的に実行することは不可能です）が、それでもいくつかの不快な機能があります。

おすすめ：実行のサーバー側を開発するときは、インターフェースの最小性の原則に従うことをお勧めします。それらの。クライアントアプリケーションからサーバーモジュールへのエントリの数は非常に制限する必要があり、パラメータは厳密に規制する必要があります。 おすすめ：サーバー上でプロシージャと関数のパラメータを受け取るときは、パラメータを検証する必要があります（パラメータが期待されるタイプと値の範囲に対応しているかどうかを確認してください）。これは標準ソリューションでは実行されませんが、独自の設計に必須の検証を導入することが非常に望ましいです。 おすすめ：サーバー側で要求テキスト（さらにはRunコマンドパラメーター）を生成するときは、クライアントアプリケーションから受信した文字列を使用しないでください。

一般的な推奨事項は、安全な構築の原則に精通することです。 ウェブ-データベースアプリケーションと同様の原則に取り組んでいます。類似性は非常に重要です。まず、Webアプリケーションと同様に、アプリケーションサーバーはデータベースとユーザーインターフェイスの間の中間層です（主な違いは、Webサーバーがユーザーインターフェイスを形成することです）。第二に、セキュリティの観点から、クライアントから受信したデータは信頼できません。外部レポートと処理を開始することが可能です。

パラメータの受け渡し

サーバー上で実行される関数（プロシージャ）にパラメータを渡すことは、かなり微妙な問題です。これは主に、アプリケーションサーバープロセスとクライアントの間でそれらを転送する必要があるためです。制御がクライアント側からサーバー側に移されると、送信されたすべてのパラメーターがシリアル化され、サーバーに移され、そこで「解凍」されて使用されます。サーバー側からクライアント側に移動すると、プロセスが逆になります。ここで、このスキームは、参照および値によるパラメーターの受け渡しを正しく処理することに注意してください。パラメータを転送する場合、次の制限が適用されます。

プリミティブ型、参照、ユニバーサルコレクション、システム列挙値、値ストレージなど、変更不可能な値（つまり、値を変更できない値）のみをクライアントとサーバー間で（両方向に）転送できます。他の何かを転送しようとすると、クライアントアプリケーションがクラッシュします（サーバーが誤ったパラメーターを転送しようとしても）。
パラメータを渡す場合、大量のデータ（たとえば、100万文字を超える文字列）を転送することはお勧めしません。これは、サーバーのパフォーマンスに悪影響を与える可能性があります。
サーバーからクライアントへ、またはその逆の両方で、循環参照を含むパラメーターを渡すことはできません。このようなパラメーターを渡そうとすると、クライアントアプリケーションがクラッシュします（サーバーが誤ったパラメーターを渡そうとしても）。
非常に複雑なデータのコレクションを転送することはお勧めしません。ネストレベルが非常に大きいパラメーターを渡そうとすると、サーバーがクラッシュします（！）。

注意！現時点で最も不快な機能は、おそらく複雑な値のコレクションを渡す際のエラーです。したがって、たとえば、次のコードは次のとおりです。NestingLevel = 1250;
M = 新しいアレイ;
TransmittedParameter = M;
MF = 1の場合ネスティングレベルサイクルによる
MVint =新しい配列;
M.追加（MVintr）;
M = MVintr;
サイクルの終わり;
ServerFunction（PassedParameter）;

すべてのユーザーが切断された状態でサーバーがクラッシュします。これは、制御が埋め込み言語コードに移される前に発生します。

サーバー側で安全でない機能を使用する。

すべての埋め込み言語機能をアプリケーションサーバーで実行されるコードで使用できるわけではありませんが、利用可能なツールの中でも、次のように大まかに分類できる多くの「問題」構造があります。

構成に含まれていないコードを実行する機能を提供できる（「コード実行」グループ）
クライアントアプリケーションにユーザーのファイルとオペレーティングシステムに関する情報を提供したり、データの操作に関係のないアクションを実行したりすることができます（「権利の侵害」）
サーバーの緊急停止を引き起こす可能性がある、または非常に大きなリソースを使用する可能性がある（「サーバー障害」グループ）
クライアントの作業で障害を引き起こす可能性があります（「クライアント障害」グループ）-このタイプは考慮されません。例：サーバーに可変値を渡す。
プログラミングアルゴリズムのエラー（無限ループ、無制限の再帰など）（「プログラミングエラー」）

私が知っている主な問題の構成要素（例を含む）を以下に示します。

プロシージャ実行（<Строка>)

コード実行。文字列値として渡されるコードを実行します。サーバーで使用する場合は、クライアントから受信したデータがパラメーターとして使用されていないことを確認する必要があります。たとえば、次の使用法は無効です。
＃サーバーの場合
サーバー（Param1）エクスポートでの手順
実行（Param1）;
手順の終了
＃EndIf

「COMObject」と入力します（コンストラクターNew COMObject（<Имя>, <Имя сервера>))

アプリケーションサーバー（または他の指定されたコンピューター）でUSER1CV8SERVER特権を持つ外部アプリケーションCOMオブジェクトを作成します。サーバーで使用する場合は、クライアントアプリケーションからパラメーターが渡されないようにしてください。ただし、サーバー側では、インポート/エクスポート、インターネット経由でのデータ送信、非標準機能の実装などにこの機能を使用すると効果的です。

関数GetCOMObject（<Имя файла>, <Имя класса COM>)

権利の侵害とコードの実行。前のものと同様に、ファイルに対応するCOMオブジェクトのみを取得します。

プロシージャと関数ComputerName（）、TempFilesDirectory（）、ProgramsDirectory（）、Windowsユーザー（）

権利侵害。サーバー上でそれらを実行した後、サーバーサブシステムの構成の詳細を確認できるようにします。サーバーで使用する場合は、データがクライアントに送信されないか、適切な許可なしにオペレーターが使用できないことを確認してください。参照によって渡されたパラメーターでデータを返すことができるという事実に特に注意してください。

ファイル（CopyFile、FindFiles、CombineFiles、およびその他多数）を操作するためのプロシージャと関数、および「ファイル」タイプ。

権利侵害。サーバー上でそれらを実行することにより、USER1CV8SERVERユーザー権限でアクセス可能なローカル（およびネットワーク上にある）ファイルへの一般的なアクセスを取得できるようにします。意図的に使用すれば、サーバー上のデータのインポート/エクスポートなどのタスクを効果的に実装できます。

これらの機能を使用する前に、必ず1Cのユーザー権限を確認してください。ユーザー権限を確認するには、サーバーモジュールで次の構造を使用できます。
＃サーバーの場合
プロシージャExecuteWorkwith File（）エクスポート
RoleAdministrator = Metadata.Role.Administrator;
ユーザー= SessionParameters.CurrentUser;
User.Roles.Contains（RoleAdministrator）の場合
//これはファイルを操作するためのコードが実行される場所です
EndIf;
＃EndIf
これらの手順や関数を使用する場合は、必ずパラメータを確認してください。そうしないと、サーバーでコードを実行する場合など、誤ってまたは故意に1Cアプリケーションサーバーに修復不可能な損害を与えるリスクがあります。
パス= "C：\ドキュメントと設定\すべてのユーザー\アプリケーションデータ\ 1C \ 1Cv8 \";
MoveFile（Path + "srvrib.lst"、Path + "Here'sWhereFile"）;
サーバーでこのようなコードを実行した後、上記のようにUSER1CV8SERVERユーザーがコードを変更する権限を持っている場合、サーバープロセスを再起動した後（デフォルトでは、すべてのユーザーがログアウトしてから3分後）、サーバーの起動に関して大きな質問が発生します。。しかし、それは可能であり、完全な除去ファイル..。

タイプ「XBase」、「BinaryData」、「Read XML」、「Write XML」、「Transform XSL」、「Write ZipFile」、「ReadZipFile」、「ReadText」、「WriteText」

権利侵害。これらは、サーバー上で実行することにより、特定のタイプのローカル（およびネットワーク上にある）ファイルにアクセスし、ユーザー権限USER1CV8SERVERで読み取り/書き込みを行うことができます。意図的に使用すれば、サーバーへのデータのインポート/エクスポート、一部の機能のロギング、管理タスクの解決などのタスクを効果的に実装できます。一般に、推奨事項は前の段落と同じですが、クライアントとサーバーの部分の間でこれらのファイルのデータ（ただし、これらすべてのタイプのオブジェクトではない）を転送する可能性を考慮する必要があります。

システム情報タイプ

権利侵害。データが誤って使用され、アプリケーションのクライアント部分に転送された場合に、アプリケーションサーバーに関するデータを取得できるようにします。使用するときは、使用する権利を制限することをお勧めします。

タイプ「InternetConnection」、「InternetMail」、「InternetProxy」、「HTTPConnection」、「FTPConnection」

権利侵害。サーバーで使用する場合は、USER1CV8SERVER権限でアプリケーションサーバーからリモートPCに接続します。推奨事項：

メソッドを呼び出すときのパラメーターの制御。

ユーザー権利の管理1C。

ネットワークにアクセスするためのユーザーUSER1CV8SERVERの権限に対する厳しい制限。

1Cアプリケーションサーバーのファイアウォールの正しい構成。

正しく使用すると、たとえば、アプリケーションサーバーからの電子メールの送信を整理すると便利です。

タイプ「InformationBaseUserManager」、「InformationBaseUser」

権利侵害。（特権モジュールで）誤って使用された場合、ユーザーを追加したり、既存のユーザーの許可パラメーターを変更したりする可能性があります。

関数形式

サーバーがクラッシュします。はい！この一見無害に見える関数は、そのパラメーターを制御せずにサーバー上で実行すると、サーバーアプリケーションの異常終了を引き起こす可能性があります。エラーは、たとえば、数値をフォーマットし、先行ゼロや多数の文字に出力モードを使用すると明らかになります。
フォーマット（1、 "CHT = 999; CHVN ="）;
このエラーが次のプラットフォームリリースで修正されることを願っていますが、今のところ、サーバーで実行できるこの関数へのすべての呼び出しで、呼び出しパラメーターを確認してください。

値を格納するためのプロシージャと関数（ValueInStringInternally、ValueInFile）

サーバーがクラッシュします。これらの関数は、コレクション内の循環参照や非常に深いネストを処理しないため、非常に特殊な場合にクラッシュする可能性があります。

関数内のパラメーターの境界および特別な値のエラー。実行制御。

サーバーの使用時に発生する可能性のある問題の1つは、サーバー機能の大きな「責任」です（1つの接続のエラーと1つの「リソーススペース」の使用によりサーバーアプリケーション全体が異常終了する可能性）すべての接続に対して）。したがって、ランタイムの主なパラメータを制御する必要があります。

組み込みの言語関数については、それらの起動パラメーターを確認してください（主な例は「フォーマット」関数です）
ループを使用する場合は、ループ終了条件がトリガーされていることを確認してください。ループが潜在的に無限である場合は、反復回数を人為的に制限します。MaximumIterationCount= 1,000,000;
反復回数= 1;
さよなら
偽の値を返すことができない関数（）
AND（反復カウンター<МаксимальноеЗначениеСчетчикаИтераций) Цикл
// ....ループの本体
反復カウンター=反復カウンター+1;
サイクルの終わり;
IfIterationCount> MaximumIterationCounterValue Then
// ....過度に長いサイクル実行のイベントを処理します
EndIf;
再帰を使用する場合は、最大ネストレベルを制限してください。
クエリを作成して実行するときは、非常に長い選択や大量の情報の選択を防ぐようにしてください（たとえば、「IN HIERARCHY」条件を使用する場合は、空の値を使用しないでください）。
インフォベースを設計するときは、数値に十分な桁容量のマージンを提供します（そうしないと、加算と乗算が非可換および非結合になり、デバッグが困難になります）
実行可能要求では、作業のロジックに存在がないか確認してください NULL値と正しい仕事 NULLを使用した条件とクエリ式。
コレクションを使用する場合は、アプリケーションサーバーとクライアント間でコレクションを転送する機能を制御します。

クライアント側への端末アクセスを使用してアクセスを制限する

ターミナルサーバーでクライアント側のコードを実行することにより、ターミナルアクセスを使用してデータへのアクセスを制限し、パフォーマンスを向上させるための推奨事項を見つけることは珍しくありません。はい、適切に構成されていれば、端末アクセスを使用するとシステムのセキュリティ全体のレベルを実際に高めることができますが、残念ながら、実際の使用ではシステムのセキュリティが低下するだけであるという事実に対応できることがよくあります。これが何に関連しているのかを理解してみましょう。現在、ターミナルアクセスを整理する一般的な方法は2つあります。これらは、Microsoftターミナルサービス（RDPプロトコル）とCitrix Metaframe Server（ICAプロトコル）です。一般に、Citrixツールははるかに柔軟なアクセス管理オプションを提供しますが、これらのソリューションのコストは大幅に高くなります。全体的なセキュリティレベルを下げる可能性のある、両方のプロトコルに共通する基本機能のみを検討します。ターミナルアクセスを使用する場合の主な危険は3つだけです。

過剰な量のリソースを占有することにより、他のユーザーの作業をブロックする機能
他のユーザーのデータへのアクセス。
ターミナルサーバーからユーザーのコンピューターへのデータの不正コピー

いずれの場合も、ターミナルサービスでは次のことができます。

作業の信頼性を高めます（端末コンピュータで障害が発生した場合、ユーザーはその後同じ場所から作業を続けることができます）
クライアントアプリケーションとそれが保存するファイルへのアクセスを制限します。
ユーザーの職場からターミナルアクセスサーバーにコンピューティング負荷を転送します
システム設定をより集中的に管理します。ユーザーの場合、保存された設定は、システムにログインしたコンピューターに関係なく有効になります。
場合によっては、システムへのリモートアクセスにターミナルソリューションを使用できます。

1人のユーザーのターミナルサーバーへの可能な接続の数を制限する必要があります

リソースに関する1Cクライアントアプリケーションの「無駄遣い」のため、ターミナルサーバーへの1人のユーザー（オペレーター）の同時接続の最大数を制限することが不可欠です。アクティブに使用される接続は、アプリケーションの1つのインスタンスだけで最大300MBのメモリを使用できます。メモリに加えて、プロセッサ時間も積極的に使用されますが、これもこのサーバーのユーザーの安定性には寄与しません。この制限は、サーバーリソースの過剰使用を防ぐだけでなく、他の誰かのアカウントが使用されるのを防ぐことができます。ターミナルサーバーの標準設定によって実装されます。

1つの接続で複数の1Cクライアントアプリケーションを同時に実行することを許可しないでください

前の段落と同じ理由で口述されましたが、技術的には実装がより困難です。問題は、ターミナルサーバーを使用して1Cの再起動を防ぐことはほとんど不可能であるため（理由は以下で説明します）、適用されたソリューションのレベルでこの機能を実装する必要があります（これも良くありません）ソリューション、アプリケーションの誤った終了の場合にいくつかの「ハング」セッションが発生する可能性があるため、アプリケーションモジュールといくつかのリファレンスブックで適用されたソリューションを改良する必要があり、1Cからの更新の使用が複雑になります。でいくつかのアクション（レポートの生成など）を起動できるように、ユーザーが2つのアプリケーションを実行できるようにしておくことが非常に望ましいです。バックグラウンド-残念ながら、クライアントアプリケーションは実際にはシングルスレッドです。

1Cでリソースを大量に消費するコンピューティングタスクを起動する権限を持つユーザーにターミナルサーバーへのアクセス権を付与したり、他のユーザーがアクティブに作業しているときにそのような起動を防止したりすることはお勧めしません。

もちろん、ターミナルサーバーへのアクセスは、データマイニング、地理的スキーム、インポート/エクスポート、およびアプリケーションのクライアント側に深刻な負荷をかけるその他のタスクを使用しないユーザーのみに任せることをお勧めします。それにもかかわらず、そのようなタスクを解決する必要がある場合は、次のことが必要です：これらのタスクが他のユーザーのパフォーマンスに影響を与える可能性があることをユーザーに通知するには、そのようなプロセスの開始と終了のイベントをログに記録します、スケジュールされた時間にのみ実行を許可するなど。

各ユーザーがターミナルサーバーの厳密に定義されたディレクトリにのみ書き込むことができ、他のユーザーがそれらにアクセスできないようにする必要があります。

まず、共有ディレクトリ（1Cがインストールされているディレクトリなど）への書き込み機能を制限しない場合、攻撃者はすべてのユーザーのプログラムの動作を変更できます。次に、あるユーザーのデータ（一時ファイル、レポート設定を保存するためのファイルなど）は、ターミナルサーバーの別のユーザーが利用できないようにする必要があります。通常、このルールは通常の設定で満たされます。第三に、攻撃者は依然としてパーティションを「散らかす」機会があり、ハードディスクにスペースが残っていないようにします。 Windows 2000以降、Windows OSにはクォータメカニズムがあることに反対するでしょうが、これはかなり高価なメカニズムであり、実際に使用されることはほとんどありません。

アクセスの設定に関する以前の質問が一般的に非常に簡単に実装できた場合、ファイルへのユーザーアクセスを規制するなどの（一見）単純なタスクが簡単に実装されています。まず、クォータメカニズムを使用しない場合、大きなファイルを保存できます。第二に、システムは、他のユーザーが利用できるようにファイルを保存することがほとんど常に可能であるように構築されています。

タスクを解決するのが完全に難しいことを考えると、ほとんどのファイルイベントを監査することをお勧めします

クライアントワークステーションのディスクデバイス、プリンター、クリップボードの接続（マッピング）を無効にする必要があります。

RDPおよびICAでは、サーバーへの端末コンピューターのディスク、プリンター、クリップボードのポートの自動接続を整理することができます。この可能性がある場合、ターミナルサーバーでの無関係なコードの起動とターミナルアクセスクライアントでの1Cからのデータの保存を禁止することはほとんど不可能です。これらの機能は、管理者権限を持つ個人にのみ許可してください。

ターミナルサーバーからのネットワークファイルアクセスを制限する必要があります。

これが行われない場合、ユーザーは不要なコードを再度実行したり、データを保存したりできます。通常のログはファイルイベントを追跡しないため（ちなみに、プラットフォーム開発者が実装することをお勧めします）、ネットワーク全体でシステム監査を構成することはほとんど不可能です（サービスを提供するのに十分なリソースがありません）。、ユーザーがデータを送信したり、印刷したり、電子メールで送信したりできる方がよいでしょう。ターミナルサーバーがユーザーのリムーバブルメディアと直接連携しないことに特に注意してください。

安全なシステムを作成するときは、いかなる状況でもアプリケーションサーバーをターミナルサーバーに置いたままにしないでください。

アプリケーションサーバーがクライアントアプリケーションと同じコンピューターで起動された場合、通常の操作を中断する可能性が多くあります。何らかの理由でターミナルサーバーとアプリケーションサーバーの機能を分離できない場合は、アプリケーションサーバーが使用するファイルへのユーザーアクセスに特に注意してください。

ターミナルサーバーで1C：Enterpriseを除くすべてのアプリケーションを起動する可能性を排除する必要があります。

これは、願いの項目を実装するのが最も難しいものの1つです。まず、ドメインのグループセキュリティポリシーを適切に構成する必要があります。すべての管理用テンプレートとソフトウェア制限ポリシーを正しく構成する必要があります。自分でテストするには、少なくとも次の機能がブロックされていることを確認してください。

この要件の実装は複雑であるため、ターミナルサーバーで「追加の」1Cセッションを起動する可能性があります（他のアプリケーションが制限されている場合でも、Windowsによる1Cの起動を禁止することは原則として不可能です）。

通常のログブックの制限を考慮してください（すべてのユーザーが1台のコンピューターからプログラムを使用します）

明らかに、ユーザーはターミナルモードで1Cを開くため、ターミナルサーバーはログに記録されます。ユーザーがどのコンピューターから接続したか、ログは報告しません。

ターミナルサーバー-セキュリティまたは脆弱性？

したがって、北ターミナルの主な機能を検討すると、北ターミナルはコンピューティング負荷を分散するための自動化に役立つ可能性があると言えますが、安全なシステムを構築することは非常に困難です。ターミナルサーバーの使用が最も効果的なケースの1つは、機能が制限され、専用のインターフェイスを持つユーザーに対して、Windowsエクスプローラーなしで1Cをフルスクリーンモードで起動することです。

クライアントサイドワーク

Internet Explorer（IE）の使用

1Cクライアント部分の通常の操作の条件の1つは、InternetExplorerコンポーネントの使用です。これらのコンポーネントには十分注意する必要があります。

注意！まず、スパイウェアまたはアドウェアモジュールがIEに接続されている場合、1CでHTMLファイルを表示してもロードされます。これまでのところ、この機能の意識的な使用は見ていませんが、1Cが実行されているときに、ポルノネットワークの1つのロードされた「スパイ」モジュールに会ったことがあります（ウイルス対策プログラムが更新されていない、の症状見つかったもの：ファイアウォールを設定するとき、1Cがポート80でポルノサイトに接続しようとしていることは明らかでした）。実際、これは保護が包括的であるべきであるという事実を支持する別の議論です。

注意！次に、1Cシステムでは、表示されたHTMLドキュメントでフラッシュムービー、ActiveXオブジェクト、VBScriptを使用し、データをインターネットに送信し、PDFファイルを開くこともできます（！）。ただし、後者の場合は「開くか保存するか」を要求します。 ..一般的に、あなたの心が望むものは何でも。組み込みのHTML表示および編集機能の完全に賢明な使用例ではありません。

新しいHTMLドキュメントを作成します（[ファイル]-> [新規]-> [HTMLドキュメント]）。
空白のドキュメントの[テキスト]タブに移動します。
テキストを（完全に）削除します。
このドキュメントの[表示]タブに移動します
ドラッグアンドドロップを使用して、SWF拡張子の付いたファイル（これらはフラッシュムービーファイルです）を開いているエクスプローラーからドキュメントウィンドウに、たとえばブラウザーのキャッシュから移動しますが、FLASHおもちゃで楽しむこともできます。
なんて可愛らしいです！ 1Cでおもちゃを走らせることができます！

システムセキュリティの観点から、これは完全に間違っています。これまでのところ、この脆弱性による1Cへの特別な攻撃は見ていませんが、時間と情報の価値の問題であることが判明する可能性があります。

HTMLドキュメントフィールドを操作するときに表示されるいくつかのマイナーなポイントがありますが、主な2つがリストされています。ただし、これらの機能にクリエイティブにアプローチすれば、1Cを操作するための本当に驚くべきインターフェイス機能を整理できます。

外部レポートの使用と処理。

注意！外部レポートと処理-一方では、追加の印刷可能なフォーム、ルーチンレポート、特殊なレポートを実装するための便利な方法ですが、他方では、多くのシステムセキュリティ制限を回避し、アプリケーションサーバーの操作を中断する潜在的な方法です。（例については、上記の「パラメーターの受け渡し」を参照してください）。 1Cシステムでは、「外部処理のインタラクティブな開始」の役割の権限セットに特別なパラメータがありますが、これで問題が完全に解決されるわけではありません。完全な解決策を得るには、ユーザーの輪を大幅に狭める必要があります。外部処理を使用して実装された標準ソリューションの外部印刷フォーム、ルーチンレポート、およびその他の標準機能を管理できる人。たとえば、SCPのデフォルトでは、すべての基本的なユーザーロールには、追加の印刷可能なフォームの参考書を操作する機能があります。これは、実際には、外部処理を使用する機能です。

典型的なソリューションとプラットフォームの標準メカニズムの使用（データ交換）

標準的なメカニズムのいくつかは潜在的に危険であり、まったく予想外の方法です。

リストの印刷

システム内の任意のリスト（たとえば、ディレクトリや情報のレジスタ）を印刷したり、ファイルに保存したりできます。これを行うには、コンテキストメニューと[アクション]メニューから利用できる標準機能を使用するだけで十分です。

ユーザーがリストに表示する事実上すべてを外部ファイルに出力できることに注意してください。アドバイスできる唯一のことは、プリントサーバーでドキュメントを印刷するためのプロトコルを維持することです。特に重要なフォームの場合、リストを表示するオプションがこのパネルから使用できないように、保護されたテーブルフィールドに関連付けられたアクションパネルを構成し、コンテキストメニューを無効にする必要があります（図6を参照）。

分散データベースでのデータ交換

データ交換形式は非常に単純で、ドキュメントに記載されています。ユーザーが複数のファイルを上書きできる場合、システムに不正な変更を加えることができます（ただし、これにはかなりの時間がかかります）。分散データベース交換プランを使用して周辺機器ベースを作成する機能は、通常のオペレーターが利用できないようにする必要があります。

XML標準データ交換

一般的な構成（「取引管理」と「エンタープライズアカウンティング」など）間の交換に使用される標準のデータ交換では、交換ルールでオブジェクトをロードおよびアンロードするためのイベントハンドラーを指定することができます。これは、ファイルからハンドラーを取得し、ファイルのロードとアンロードの標準処理のための「実行（）」プロシージャによって実現されます（「実行（）」プロシージャはクライアント側で起動されます）。明らかに、悪意のあるアクションを実行するような偽の交換ファイルを作成することは難しくありません。汎用ソリューションのほとんどのユーザーロールでは、交換はデフォルトで有効になっています。

おすすめ：大多数のユーザーのXML交換へのアクセスを制限します（IS管理者のみに任せます）。この処理の起動のログを維持し、たとえば、交換ファイルを送信して保存しますメールでロードする前にIB管理者に連絡してください。

一般的なレポート、特にレポートコンソールの使用

もう1つの問題は、デフォルトで汎用レポート、特にレポートコンソールレポートにユーザーがアクセスできることです。このレポートは、情報セキュリティに対するほぼすべての要求を満たすことができ、1C権利システム（RLSを含む）が非常に厳密に構成されている場合でも、ユーザーが多くの「追加の」情報を取得できることを特徴としています。サーバーに、すべてのリソースシステムを使用するような要求を実行するように強制します。

フルスクリーンモードの使用（デスクトップモード）

プログラムの機能へのアクセスが制限された特殊なインターフェイスを編成する効果的な方法の1つは、使用されるインターフェイスのメイン（および場合によっては唯一）形式のフルスクリーンモードです。この場合、アクセシビリティに関する質問はありません。たとえば、[ファイル]メニューとすべてのユーザーアクションは、使用するフォームの機能によって制限されます。詳細については、ITSディスクの「デスクトップモードの実装の機能」を参照してください。

バックアップ

1Cのクライアントサーバーバージョンのバックアップは、dt拡張子の付いたファイルにデータをアップロードする方法と、SQLを使用してバックアップを作成する方法の2つの方法で実行できます。最初の方法には非常に多くの欠点があります。排他的アクセスが必要であり、コピー自体の作成にはるかに時間がかかり、場合によっては（IB構造に違反している場合）アーカイブを作成できませんが、1つの利点があります-最小アーカイブのサイズ。 SQLバックアップの場合は、逆になります。構造が単純で圧縮が不足しているため、SQLサーバーを使用してバックグラウンドでコピーが作成されます。これは非常に高速なプロセスであり、SQLの物理的な整合性が維持されている限りです。データベースに違反していない場合、バックアップは実行されますが、コピーのサイズは、拡張状態（圧縮は実行されません）のIBのサイズと一致します。 MS SQLバックアップシステムの追加の利点により、それを使用する方が便利です（3種類のバックアップが許可されます：完全、差分、トランザクションログのコピー、定期的に実行されるタスクの作成が可能、迅速に展開バックアップコピーおよびバックアップシステム。必要なディスクスペースのサイズなどを予測する機能を実装しました）。システムセキュリティの観点からバックアップを編成する主なポイントは次のとおりです。

ユーザーがバックアップを利用できないように、バックアップの保存場所を選択する必要があります。
MS SQLサーバーから物理的に離れた場所にバックアップを保存する必要性（自然災害、火災、攻撃などの場合）
バックアップにアクセスできないユーザーにバックアップを開始する権限を付与する機能。

詳細については、MSSQLのドキュメントを参照してください。

データ暗号化

不正アクセスからデータを保護するために、さまざまな暗号化手段（ソフトウェアとハードウェアの両方）がよく使用されますが、その実現可能性は、使用の正確さとシステムの全体的なセキュリティに大きく依存します。最も一般的な手段を使用したデータ送信とストレージのさまざまな段階でのデータ暗号化と、暗号化手段を使用したシステム設計の主な間違いについて検討します。

保護できる情報処理には、いくつかの主要な段階があります。

システムのクライアント部分とアプリケーションサーバー間のデータ転送
アプリケーションサーバーとMSSQLServer間のデータ転送
MS SQL Serverに保存されているデータ（物理ディスク上のデータファイル）
情報セキュリティに保存されているデータの暗号化
外部データ（情報セキュリティに関連して）

クライアント側とアプリケーションサーバーに保存されているデータ（保存されているユーザー設定、情報セキュリティリストなど）の場合、暗号化が正当化されるのはごくまれなケースであるため、ここでは考慮しません。暗号化ツールを使用する場合、それらを使用するとシステム全体のパフォーマンスが大幅に低下する可能性があることを忘れてはなりません。

TCP / IPプロトコルを使用する場合のネットワーク接続の暗号化保護に関する一般情報。

すべてを保護せずにネットワーク接続不正な監視とアクセスに対して脆弱です。それらを保護するために、ネットワークプロトコルレベルでデータ暗号化を使用できます。ローカルネットワークで送信されるデータを暗号化するには、オペレーティングシステムが提供するIPSecツールが最もよく使用されます。

IPSecツールは、DESおよび3DESアルゴリズムを使用した送信データの暗号化、およびMD5またはSHA1ハッシュ関数を使用した整合性チェックを提供します。 IPSecは、トランスポートモードとトンネルモードの2つのモードで動作できます。トランスポートモードは、LAN接続を保護するのに適しています。トンネルモードを使用して、個々のネットワークセグメント間のVPN接続を整理したり、オープンデータチャネルを介してローカルネットワークへのリモート接続を保護したりできます。

このアプローチの主な利点は次のとおりです。

ActiveDirectoryツールを使用してセキュリティを一元管理する機能。
アプリケーションサーバーおよびMSSQLサーバーへの不正な接続を除外する機能（たとえば、アプリケーションサーバーでの情報セキュリティの不正な追加から保護することができます）。
ネットワークトラフィックの「リスニング」の排除。
アプリケーションプログラム（この場合は1C）の動作を変更する必要はありません。
そのようなソリューションの標準。

ただし、このアプローチには制限と欠点があります。

IPSecは、ソースコンピューターと宛先コンピューターでのデータの改ざんや盗聴からデータを直接保護しません。
ネットワークを介して送信されるデータの量は、IPSecを使用しない場合よりもわずかに多くなります。
IPSecを使用する場合、いくつかより多くの負荷中央処理装置に。

IPSec機能の実装の詳細な説明はこの記事の範囲を超えており、IPプロトコルの基本原則を理解する必要があります。接続保護を適切に構成するには、対応するドキュメントをお読みください。

これとは別に、VPN接続を編成する際には、1Cとのライセンス契約のいくつかの側面について言及する必要があります。事実、技術的な制限はありませんが、ローカルネットワークの複数のセグメントを接続したり、別のコンピューターをローカルネットワークにリモートアクセスしたりする場合は、通常、いくつかの基本的な消耗品が必要です。

システムのクライアント部分とアプリケーションサーバー間の送信中のデータ暗号化。

での暗号化に加えてネットワークプロトコル、ITSの記事「クライアントサーバーバージョンでの情報ベースへのユーザーアクセスの規制」に記載されているCOM +プロトコルのレベルでデータを暗号化することが可能です。実装するには、コンポーネントサービスで1CV8アプリケーションの呼び出しの「パケットプライバシー」認証レベルを設定する必要があります。このモードに設定すると、パッケージは認証され、データ、送信者のIDと署名を含めて暗号化されます。

アプリケーションサーバーとMSSQLServer間の送信中のデータ暗号化

MS SQL Serverは、次のデータ暗号化ツールを提供します。

アプリケーションサーバーとMSSQL Serverの間でデータを転送するときに、Secure Sockets Layer（SSL）を使用することができます。
ネットワークライブラリMultiprotocolを使用する場合、RPCレベルでのデータ暗号化が使用されます。これはSSLよりも暗号化が弱い可能性があります。
共有メモリプロトコルが使用されている場合（これは、アプリケーションサーバーとMS SQL Serverが同じコンピューター上にある場合に発生します）、暗号化はどのような場合でも使用されません。

特定のMSSQLサーバーのすべての送信データを暗号化する必要性を確立するには、「サーバーネットワークユーティリティ」ユーティリティを使用します。それを実行し、[全般]タブで[プロトコル暗号化を強制する]チェックボックスをオンにします。暗号化方法は、クライアントアプリケーション（つまり、1Cアプリケーションサーバー）で使用されている方法に応じて選択されます。 SSLを使用するには、ネットワーク上で証明書発行者を適切に構成する必要があります。

特定のアプリケーションサーバーに対して送信されるすべてのデータを暗号化する必要性を確立するには、「クライアントネットワークユーティリティ」ユーティリティ（通常は「C：\ WINNT \ system32 \ cliconfg.exe」にあります）を使用する必要があります。前の場合と同様に、[全般]タブで、[プロトコル暗号化を強制する]チェックボックスをオンにします。

この場合の暗号化の使用は、特に大量の情報を返すクエリを使用する場合に、システムのパフォーマンスに大きな影響を与える可能性があることに注意してください。

TCP / IPプロトコルを使用するときにアプリケーションサーバーとMSSQL Serverの間の接続をより完全に保護するために、デフォルト設定にいくつかの変更を加えることをお勧めします。

まず、標準ポート以外のポートを設定できます（デフォルトではポート1433が使用されます）。通信に非標準のTCPポートを使用する場合は、次の点に注意してください。

MS SQLServerとアプリケーションサーバーは同じポートを使用する必要があります。
ファイアウォールを使用する場合は、このポートを許可する必要があります。
MS SQLServer上の他のアプリケーションで使用できるポートを設定することはできません。参考までに、http：//www.ise.edu/in-notes/iana/assignments/port-numbers（SQL Server Books Onlineから取得したURL）を参照してください。
MS SQL Serverの複数のインスタンスを使用する場合は、構成についてMS SQLのドキュメントを必ずお読みください（「ネットワーク接続の構成」のセクション）。

次に、MSSQLサーバーのTCP / IPプロトコル設定で、[サーバーを非表示]チェックボックスを選択できます。これにより、MS SQLServerサービスのこのインスタンスに対するブロードキャスト要求への応答が禁止されます。

ディスクに保存されているMSSQLデータの暗号化

ローカルディスクにあるデータを暗号化するためのソフトウェアおよびハードウェアツールの選択肢はかなり豊富です（これは、EFSを使用するWindowsの標準機能であり、eTokenキー、およびJetico BestcryptやPGPDiskなどのサードパーティプログラムを使用します）。これらのツールによって実行される主なタスクの1つは、メディアが失われた場合（たとえば、サーバーが盗まれた場合）にデータを保護することです。 Microsoftは、暗号化されたメディアにMS SQLデータベースを保存することを推奨しておらず、これは非常に合理的であることに特に注意してください。この場合の主な問題は、生産性の大幅な低下と考えられる問題故障からの信頼性。システム管理者の生活を複雑にする2番目の要因は、MS SQLサービスが最初にデータベースファイルにアクセスするときにすべてのデータベースファイルが利用可能であることを確認する必要があることです（つまり、暗号化されたメディアに接続するときに対話型アクションを除外することが望ましい）。

システムパフォーマンスの顕著な低下を回避するために、MSSQLの機能を使用して複数のファイルにデータベースを作成できます。もちろん、この場合、MS SQLデータベースは、インフォベースの作成時に1Cサーバーによって作成されるべきではなく、個別に作成されるべきです。コメント付きのTSQLスクリプトの例を以下に示します。

マスターを使用
行く
-データベースSomeDataを作成し、
CREATE DATABASE SomeData
-そのデータは完全にファイルグループPRIMARYにあります。
一次上
-メインデータファイルは暗号化されたメディア上にあります（論理ドライブ E :)
-初期サイズは100MBで、次の方法で自動的に200MBに拡張できます。
-20Mbステップ
（NAME = SomeData1、
FILENAME = "E：\ SomeData1.mdf"、
サイズ= 100MB、
MAXSIZE = 200、
FILEGROWTH = 2）、
--2番目のデータファイルは暗号化されていないメディアにあります（論理ドライブC :)
-初期サイズは100MBで、制限まで自動的に増やすことができます
-現在のファイルサイズの5％のステップのディスク容量（64 Kbに切り上げ）
（NAME = SomeData2、
FILENAME = "c：\プログラムファイル\ microsoftsqlサーバー\ mssql \ data \ SomeData2.ndf"、
サイズ= 100MB、
MAXSIZE =無制限、
FILEGROWTH = 5％）
ログオン
-トランザクションログを部分に分割することもできますが、これは行わないでください。
- 以来このファイルはより頻繁に変更され、定期的にクリーンアップされます（たとえば、
-データベースのバックアップコピーを作成します）。
（NAME = SomeDatalog、
FILENAME = "c：\プログラムファイル\ microsoftsqlサーバー\ mssql \ data \ SomeData.ldf"、
サイズ= 10MB、
MAXSIZE =無制限、
FILEGROWTH = 10）
行く
-データベースの所有権をユーザーに代わってすぐに付与することをお勧めします
-1Cが接続されます。これを行うには、現在のベースを宣言する必要があります
-作成したばかり、
SomeDataを使用する
行く
-そしてsp_changedbownerプロシージャを実行します
EXEC sp_changedbowner @loginame = "SomeData_dbowner"

データファイルサイズの自動拡張に関する小さな余談。デフォルトでは、新しく作成されたデータベースの場合、ファイルサイズは現在のファイルサイズの10％ずつ増加します。これは、小さなデータベースには完全に受け入れられるソリューションですが、大きなデータベースにはあまり適していません。たとえば、データベースサイズが20 GBの場合、ファイルは一度に2GB大きくなるはずです。このイベントが発生することはめったにありませんが、数十秒間続く可能性があり（この時点では、他のすべてのトランザクションは実際にはアイドル状態です）、データベースをアクティブに操作しているときに発生すると、障害が発生する可能性があります。ディスクスペースがほぼ完全にいっぱいになったときに発生する比例ゲインの2番目の悪影響は、不十分なために早期に障害が発生する可能性です。フリースペース..。たとえば、40 GBのディスクパーティションが1つのデータベース（より正確には、このデータベースの1つのファイル）に完全に割り当てられている場合、緊急に（非常に緊急に、中断するまで）必要なデータベースファイルのクリティカルサイズ情報ストレージを再編成するためのユーザーの通常の作業）は、35GBのデータファイルサイズです。 10〜20 MBの増分を設定すると、39GBに達するまで作業を続けることができます。

したがって、指定されたリストでは、データベースファイルの1つのサイズを5％単位で増やすように指定されていますが、データベースサイズが大きい場合は、10〜20MBの固定増分を設定することをお勧めします。データベースファイルのサイズの増加の増分の値を設定するときは、ファイルグループ内のファイルの1つが最大サイズに達する前に、ルールが適用されることを考慮する必要があります：1つのファイルグループのファイルそれらがすべていっぱいになると、すべてが同時に成長します。したがって、上記の例では、SomeData1.mdfファイルが最大サイズの200 MBに達すると、SomeData2.ndfファイルのサイズは約1.1GBになります。

このようなデータベースを作成した後、保護されていないファイルSomeData2.ndfとSomeData.ldfが攻撃者に利用可能になったとしても、データベースの真の状態、つまりデータ（データベースの論理構造に関する情報を含む）を復元することは非常に困難です。）は複数のファイルに分散されます。さらに、重要な情報（たとえば、このデータベースを構成するファイルに関する情報）は暗号化されたファイルに含まれます。

もちろん、暗号化手段を使用したデータベースファイルの保存を使用する場合は、バックアップ（少なくともこれらのファイル）を暗号化されていないメディアで実行しないでください。適切な「BACKUPDATABASE」コマンド構文を使用して、個々のデータベースファイルをバックアップします。データベースのバックアップをパスワード（「BACKUPDATABASE」コマンドの「PASSWORD =」および「MEDIAPASSWORD =」オプション）で保護する可能性があるにもかかわらず、そのようなバックアップは暗号化されないことに注意してください。

ディスクに保存されているアプリケーションサーバーとクライアントのデータを暗号化する

ほとんどの場合、1C：Enterprise（クライアント側とアプリケーションサーバー）が使用するファイルを暗号化されたメディアに保存することは、コストが不当に高いため正当化できるとは見なされませんが、そのような必要性がある場合は、アプリケーションサーバーとクライアントに注意してください。アプリケーション側では、一時ファイルが作成されることがよくあります。多くの場合、これらのファイルはアプリケーションの終了後も残る可能性があり、1Cによる削除を保証することはほとんど不可能です。したがって、1Cで一時ファイルに使用されるディレクトリを暗号化するか、RAMドライブを使用してディスクに保存しないように見えます（後者のオプションは、生成されるファイルのサイズとRAMの容量の要件のために常に可能であるとは限りません。 1C：エンタープライズアプリケーション自体）。

組み込みの1Cツールによるデータ暗号化。

1Cで暗号化を使用するための標準的な可能性は、暗号化パラメーターを使用してZipファイルを操作するためのオブジェクトを使用することに限定されます。次の暗号化モードを使用できます。128、192、または256ビットのキーを持つAESアルゴリズムと、元々Zipアーカイバで使用されていた古いアルゴリズム。 AESで暗号化されたZipファイルは、多くのアーカイバ（WinRAR、7zip）で読み取ることができません。暗号化されたデータを含むファイルを生成するには、パスワードと暗号化アルゴリズムを指定する必要があります。最も単純な例この機能に基づく暗号化-復号化機能を以下に示します。

関数EncryptData（データ、パスワード、暗号化方法=未定義）エクスポート

//データを一時ファイルに書き込みます。実際、すべてのデータをこの方法で保存できるわけではありません。
ValueInFile（TempFileName、Data）;

//一時データをアーカイブに書き込みます
Zip =新しいZipFileレコード（一時的なArchiveFileName、パスワード、暗号化方式）;
Zip.Add（TemporaryFileName）;
Zip.Write（）;

//受信したアーカイブからデータを読み取ります羊
EncryptedData = NewValueStore（NewBinaryData（TemporaryArchiveFileName））;

//一時ファイル-削除

EndFunction関数DecryptData（EncryptedData、Password）エクスポート

// 注意！渡されたパラメータの正確性は監視されません

//渡された値をファイルに書き込みます
TempFileName = GetTempFileName（ "zip"）;
BinaryArchiveData = EncryptedData.Get（）;
BinaryArchiveData.Write（TemporaryArchiveFileName）;

//新しく書き込まれたアーカイブの最初のファイルを抽出します
TempFileName = GetTempFileName（）;
Zip =新しいReadZipFile（TemporaryArchiveFileName、Password）;
Zip.Extract（Zip.Elements、TemporaryFileName、ZipFilePath RecoveryMode.NotRecover）;

//書き込まれたファイルを読み取ります
データ= ValueFromFile（TemporaryFileName + "\" + Zip.Elements.Name）;

//一時ファイルを削除します
DeleteFiles（TemporaryFileName）;
DeleteFiles（TempArchiveFileName）;

データを返す;

EndFunction

もちろん、このメソッドは理想的とは言えません。データはクリアテキストで一時フォルダーに書き込まれます。メソッドのパフォーマンスは率直に言って悪くはありません。データベースのストレージには非常に大きなスペースが必要ですが、これが唯一の方法です。プラットフォームの組み込みメカニズムのみに基づく方法。さらに、他の多くの方法よりも優れています。この方法では、データを暗号化と同時にパックします。このメソッドの欠点なしに暗号化を実装する場合は、外部コンポーネントに暗号化を実装するか、MicrosoftCryptoAPIなどを使用してCOMオブジェクトを作成して既存のライブラリを参照する必要があります。例として、受信したパスワードに基づいて文字列を暗号化/復号化する機能を示します。

関数EncryptStringDES（UnencryptedString、パスワード）

CAPICOM_ENCRYPTION_ALGORITHM_DES = 2; //この定数はCryptoAPIからのものです

Encryption Engine.Content = UnencryptedString;
Encryption Engine.Algorithm.Name = CAPICOM_ENCRYPTION_ALGORITHM_DES;
EncryptedString = Encryption Engine.Encrypt（）;

EncryptedStringを返します。

EndFunction // EncryptStringDES（）

関数DecryptStringDES（EncryptedString、パスワード）

//注意！パラメータはチェックされません！

暗号化エンジン=新しいCOMObject（ "CAPICOM.EncryptedData"）;
暗号化メカニズム.SetSecret（パスワード）;
試み
Encryption Engine.Decrypt（EncryptedString）;
例外
// 間違ったパスワード！;
払い戻しは未定義です。
試みの終わり;

暗号化Engine.Contentを返します。

EndFunction // DecryptStringDES（）

空の値を文字列またはパスワードとしてこれらの関数に渡すと、エラーメッセージが生成されることに注意してください。この暗号化手順を使用して取得された文字列は、元の文字列よりもわずかに長くなります。この暗号化の特異性は、文字列を2回暗号化すると、結果の文字列が同一にならないというものです。

暗号化ツールを使用する際の主な間違い。

暗号化ツールを使用する場合、同じ間違いが頻繁に発生します。

暗号化を使用する場合のパフォーマンスの低下を過小評価します。

暗号化は、かなり大量の計算を必要とするタスクです（特に、DES、3DES、GOST、PGPなどのアルゴリズムの場合）。また、効率的で最適化されたアルゴリズム（RC5、RC6、AES）を使用している場合でも、メモリ内の不要なデータ転送や計算処理から逃れることはできません。そして、これは多くのサーバーコンポーネント（RAIDアレイ、ネットワークアダプタ）。暗号化にハードウェア暗号化またはハードウェアキー導出を使用する場合、追加のパフォーマンスのボトルネックが発生する可能性があります。追加のデバイスとメモリ間のデータ転送の速度です（このようなデバイスのパフォーマンスは決定的な役割を果たさない場合があります）。少量のデータ（メールメッセージなど）の暗号化を使用する場合、システムの計算負荷の増加はそれほど目立ちませんが、すべてを完全に暗号化する場合、これらすべてがシステムのパフォーマンスに大きな影響を与える可能性があります。全体として。

過小評価現代の機会パスワードとキーの選択について。

現時点では、このテクノロジの機能は、40〜48ビットの長さのキーを小規模な組織で取得でき、56〜64ビットの長さのキーを大規模な組織で取得できるようになっています。それらの。少なくとも96ビットまたは128ビットのキーを使用するアルゴリズムを使用する必要があります。ただし、ほとんどのキーは、ユーザーが入力したパスワードに基づいてハッシュアルゴリズム（SHA-1など）を使用して生成されます。この場合、1024ビットキーも役に立たない可能性があります。まず、推測しやすいパスワードがよく使われます。選択を容易にする要因は次のとおりです。1つの大文字小文字のみを使用する。パスワードでの単語、名前、表現の使用。既知の日付、誕生日などを使用します。パスワードを生成するときに「テンプレート」を使用する（たとえば、組織全体で3文字、次に2つの数字、次に3文字）。適切なパスワードは、大文字、数字、句読点の両方のかなりランダムなシーケンスである必要があります。キーボードから入力された最大7〜8文字のパスワードは、これらのルールに従っている場合でも、妥当な時間内に選択できるため、パスワードは少なくとも11〜13文字の長さであることが望ましいです。理想的な解決策は、たとえばさまざまなスマートカードなどを使用して、パスワードを使用してキーを生成することを拒否することですが、この場合、暗号化キーキャリアの損失から保護する可能性を提供する必要があります。

キーとパスワードの安全でない保管。

このエラーの典型的な例は次のとおりです。

ユーザーのモニターに貼り付けられたステッカーに書かれた長くて複雑なパスワード。
保護されていない（またはシステム自体よりもはるかに弱い保護されている）ファイルにすべてのパスワードを保存する
パブリックドメインでの電子キーの保管。
ユーザー間での電子キーの頻繁な転送。

キーがドアのそばの敷物の下にあるのに、なぜ装甲ドアを作るのですか？

最初に暗号化されたデータを安全でない環境に転送します。

セキュリティシステムを編成するときは、その目的を果たしていることを確認してください。たとえば、プログラムが開いた形式で実行されているときに、最初に暗号化されたファイルが一時フォルダーに配置され、そこから簡単に読み取れる状況（1Cとは関係ありません）に遭遇しました。暗号化されたデータを明確な形式でバックアップすることは、このデータから「それほど遠くない」場所にあることも珍しくありません。

暗号化ツールの誤用

送信されたデータの暗号化では、データが使用されている場所で利用できないとは期待できません。たとえば、IPSecサービスは、アプリケーションサーバーがアプリケーションレベルでネットワークトラフィックをリッスンすることを妨げるものではありません。

したがって、暗号化システムの実装におけるエラーを回避するために、それを展開する前に、（少なくとも）次のことを行う必要があります。

探し出す：
- 何を保護する必要がありますか？
- どのような保護方法を使用する必要がありますか？
- システムのどの部分にセキュリティを提供する必要がありますか？
- 誰がアクセスを制御しますか？
- 暗号化はすべての適切な場所で機能しますか？
情報の保存場所、ネットワークを介した送信方法、および情報へのアクセス元のコンピューターを決定します。これにより、システム展開前のネットワーク速度、容量、および使用率に関する情報が提供され、パフォーマンスの最適化に役立ちます。
システムの脆弱性を評価する他の種類攻撃。
システムセキュリティ計画を作成して文書化します。
システムを使用することの経済効率（正当化）を評価します。

結論

もちろん、大まかなレビューでは、1Cのセキュリティに関連するすべての側面を示すことは不可能ですが、いくつかの予備的な結論を導き出しましょう。もちろん、このプラットフォームは理想的とは言えません。他の多くのプラットフォームと同様に、安全なシステムを編成するという独自の問題があります。しかし、これは決してこれらの問題を回避できないことを意味するものではなく、逆に、システムを正しく開発、実装、および使用することで、ほとんどすべての欠点を取り除くことができます。問題のほとんどは、特定のアプリケーションソリューションとその実行環境の不十分な詳細から発生します。たとえば、大幅な変更がない一般的なソリューションは、十分に安全なシステムの作成を意味するものではありません。

会社購入者、開発者、ディーラー、アフィリエイトパートナー向けのユニークなサービスです。さらに、ロシア、ウクライナ、カザフスタンで最高のオンラインソフトウェアストアの1つであり、幅広い品揃え、多くの支払い方法、迅速な（多くの場合即時の）注文処理、個人セクションでの注文履行プロセスの追跡を顧客に提供します。

Informix®DataBlade™APIプログラマーガイドは、からダウンロードできます。「スタックスペースの管理」セクションでは、カスタム関数（UDR）を作成する方法について説明します。この記事では、追加情報とデバッグのヒントを提供します。

以下の情報は、UDRがユーザー定義の仮想プロセッサー（VP）で実行されているか、CPUVPで実行されているかに関係なく有効です。スレッドスタックは、UDRが実行される直前にユーザー定義のvCPUに移動できます。

UDRにはどのサイズのスタックが割り当てられていますか？

UDRに使用できるスタックのサイズは、UDRがどのように作成されたかによって異なります。

UDRが独自の専用スタックを使用できるようにするSTACK修飾子を使用します。

STACK修飾子なし。これは、UDRが、サーバーによって割り当てられたスタックを、要求を行うスレッドと共有することを意味します。この場合のスタックサイズは、onconfig構成ファイルのSTACKSIZEパラメーターの値によって決定されます。

STACK修飾子

CREATEPROCEDUREまたはCREATEFUNCTION式には、UDRが実行する必要のあるスタックスペースの量をバイト単位で指定できるオプションのSTACK修飾子があります。

UDRの作成時にSTACK修飾子を使用すると、サーバーはUDRが実行されるたびにスタックスペースの割り当てと割り当て解除を行います。実際に使用可能なサイズは、バイト単位のSTACKから、関数の引数の数に応じていくらかのオーバーヘッドを引いたものです。

STACK値がonconfigファイルのSTACKSIZE値よりも小さい場合（次のセクションを参照）、UDRに割り当てられたスタックのサイズは自動的にSTACKSIZE値に丸められます。

STACKSIZE構成パラメーター

onconfig構成ファイルには、ユーザースレッドのデフォルトのスタックサイズを定義するSTACKSIZEパラメーターが含まれています。

UDRの作成時にSTACKを指定しない場合、サーバーはそのUDRを実行するために追加のスタックスペースを割り当てません。代わりに、UDRは、要求を満たすために割り当てられたスタックスペースを使用します。使用可能なスタックサイズは、SQLレベルで関数を実行するオーバーヘッドによって異なります。

スレッドスタックは、リクエストを行う特定のスレッドに1回割り当てられます。サーバーがUDR呼び出しごとに追加のスタックを割り当てる際にリソースを浪費しないため、UDRが1つのスレッドをスタックと共有するとパフォーマンスが向上します。一方、使用されるスタックUDRのサイズがSTACKSIZE値に近づくと、複雑な要求の一部として関数を呼び出すときにスタックオーバーフローが発生する可能性があります（この場合、UDRを実行するために使用できるスタックスペースが少なくなります）。

STACKSIZEを高く設定しすぎないように注意してください。これは、すべてのユーザースレッドに影響します。

いつスタックサイズを管理する必要がありますか？

Y UDRが再帰呼び出しを行う場合、またはUDRが要求スレッドスタックでデフォルトで使用可能なスタックスペース（STACKSIZE）よりも多くのスタックスペースを必要とする場合は、スタックスペースを管理する必要があります。

UDRを実行するためにスタックを増やすには、次の2つの方法があります。

UDRを作成するときにSTACK修飾子を指定します。

mi_call（）を使用して再帰呼び出しを行います（例については、Informix DataBlade APIプログラマーズガイドを参照してください）。

STACKでサイズを指定せず、mi_call（）を使用して現在のスタックを増やすことなく、UDRが多くのスタックスペースを必要とする処理を実行すると、スタックオーバーフローが発生します。

mi_ *のようないくつかの関数は、独自の実行のために新しいスタックセグメントを追加することに注意してください。これらのセグメントは、UDRの呼び出し元に戻ると解放されます。

何かがうまくいかない場合はどうなりますか？

スタック使用量の監視

監視の目的は、スタックオーバーフローの原因となっている特定のUDRを特定して、特定のUDR専用のSTACK値を変更できるようにすることです。

「onstat-gsts」を使用してスタックの使用状況を監視する

「onstat-gsessession_id」を使用してSQLクエリを実行しているセッションを観察します

識別後 SQLクエリその結果、スタックオーバーフローが発生するため、元のリクエストの一部であるUDRを個別に実行して、スタックの使用状況を判断する必要があります。

UDRのSTACK値を動的に設定できます。例えば：

関数MyFoo（lvarchar、lvarchar）を（スタックを追加= 131072）;で変更します。

STACK値を変更した後、元のクエリをテストして、安定して動作することを確認する必要があります。

STACKSIZEを増やす

または、STACKSIZE値を増やしてみてください。これで問題が解決したかどうかを確認してください。（後で古い値を返すことを忘れないでください）。

STACKSIZEを増やしても機能しない場合、問題はメモリの破損である可能性があります。ここにいくつかの提案があります：

メモリ落書きとメモリプールのチェックを有効にします。 UDRのメモリ割り当てに関する記事の「デバッグの問題」セクションでは、これを行う方法について説明しています。

mi_lvarcharの使用を再検討してください。引数としてnullで終了する文字列を受け取ることを期待する関数にmi_lvarcharが渡される場所に特に注意してください。

CPU（またはユーザー）VPの数を1つに減らして、問題をより迅速に再現します。

mi_print_stack（）-Solaris

Informix Dynamic Server for Solaris OCには、UDRで呼び出すことができるmi_print_stack（）関数が含まれています。デフォルトでは、この関数はスタックフレームを次のファイルに保存します。

/tmp/default.stack

出力ファイルの名前を変更することはできませんが、DBTEMP環境変数の値を変更することでその場所を変更できます。ユーザーinformixが$ DBTEMPディレクトリに書き込めることを確認してください。 mi_print_stack（）の実行中に発生したエラーは、$ MSGPATHに出力されます。

この機能は、SolarisOCでのみ使用できます。

用語集

この記事で使用されている用語と略語：

UDR	ユーザー定義のルーチン
副社長	仮想プロセッサ

2016年4月14日バージョン3.22インターフェイスを変更し、レジスタを転送する際のエラーを修正し、組織と会計ポリシーを転送する手順を変更しました。プラットフォーム8.3.7.2027BP 3.0.43.174
2016年3月17日バージョン3.24バグを修正しました。プラットフォーム8.3.8.1747BP 3.0.43.241
2016年6月16日バージョン3.26バグを修正しました。プラットフォーム8.3.8.2088BP 3.0.44.123
2016年10月16日バージョン4.0.1.2バリューストアの転送を修正し、リリース3.44のアカウンティングポリシーの転送を変更しました。*。プラットフォーム8.3.9.1818BP3.0.44.164。
2017年4月19日バージョン4.0.2.7ディレクトリに関連付けられたレジスタを転送するためのアルゴリズムが変更され、エラーが修正され、リンクの書き換えを伴う転送が修正されました。
2017年5月29日バージョン4.0.4.5移動の転送を変更し、転送されたドキュメントの移動の表示を追加しました。
2017年5月30日バージョン4.0.4.6ソース内の既存のディレクトリのリストに入力する際のバグを修正しました（shoyに感謝）
2017年6月17日バージョン4.0.5.1動きを転送するためのアルゴリズムが変更されました。
2017年7月19日バージョン4.0.5.4BP2.0からのCIの転送が変更されました。予期せぬことに、UT 10.3からの転送はSmilegmによって実行されました。このバージョンでは、転送はこのような状況に合わせてわずかに修正されています）））
2017年8月10日バージョン4.0.5.5BP2.0から転送する際のエラーを修正しました
2017年9月19日バージョン4.4.5.73.0.52の接続チェックを修正しました。*
2017年11月28日バージョン4.4.5.9修正されたバグ
2017年12月6日バージョン5.2.0.4リンク検索アルゴリズムが再設計されました。 BP 1.6から転送手順が追加され、BPへの厳密なバインドがなくなりました。「ほぼ」同一の構成を安全に使用してデータを転送できます。私はすべてのコメントを迅速に修正しようとします。
2017年12月8日バージョン5.2.1.3BP.2.0からBP3.0に給与シートを転送するためのアルゴリズムが追加されました。同じ構成間で共有するための変更が含まれています。
2017年12月19日バージョン5.2.2.2これらのレジスタの次元にあるディレクトリの情報の独立したレジスタの転送を修正しました。

2017年12月6日新しい処理バージョン5.2.0.4。重要な変更の中には、BP1.6からBP3.0に移行する機能があります。主な変更点は、参照リンクの検索の管理です。以前のバージョンでは、検索はGUIDによるものでしたが、このバージョンでは、「必要条件による」検索を有効にできます。

2018年1月17日バージョン5.2.2.3下位ディレクトリおよび情報の定期的なレジスタのエラーが修正されました。

2018年7月19日バージョン5.2.2.8バグを修正しました。

ここで、参考図書の検索の詳細を設定できます。この体制自体は、すでにデータが含まれている既存のデータベースで交換が必要な場合（たとえば、2つの組織の会計を1つのデータベースにマージするため）、労働者の多数の要求で「発生」しました。

2015年12月21日プラットフォーム8.3.7.1805とBP3.0.43.29がそれぞれリリースされました新しいバージョン処理3.1：-）（以下の説明）。新機能-2つのBPベース間の残高と売上高を比較する機能（すべてのアカウントについて、アカウントのチャートが一致する場合、または分析の有無にかかわらず、別々に一致するアカウントについて）。
2016年1月3日バージョン3.5-ソースデータベースに接続するためのメカニズムを変更しました-BSP2.3.2.43に準拠しました。マイナーなバグを修正しました。プラットフォーム8.3.7.1845、BP 3.0.43.50
2016年2月16日バージョン3.6-ムーブメントで転送されるドキュメントに「手動修正の設定」フラグを追加しました。移動の固定転送-期間の開始日より前の日付のドキュメントは、移動なしで転送されます。プラットフォーム8.3.7.1917、BP 3.0.43.116
2016年3月22日バージョン3.10-参照オブジェクトを強制的に上書きするための「常にリンクを上書きする」フラグを追加しました（転送速度は大幅に低下しますが、必要な場合もあります）。「準備」タブが追加されました。このタブでは、ソースと宛先の勘定科目表の対応（勘定科目コードのあるレベル）と定数の転送を構成できます。プラットフォーム8.3.7.1970、BP 3.0.43.148

2016年4月3日バージョン3.11ソースに存在するドキュメントのリストの入力が変更されました。入力は勘定科目表に従った動きに従って行われ、期間中のリンクだけで行われました。 //サイト/パブリック/ 509628 /

処理は、XML、JSON、およびその他の中間ファイルを使用せずに、ITSからの「MXLのアンロードとロード」と同様に任意の期間のデータを転送することを目的としています。COMを介してデータベースからデータベースに交換します。 3.10より前のバージョンでは、comcntr.dllの登録が提供される（OSが「許可する」場合）BSPのアルゴリズムに従って接続が使用され、確立できない場合はさまざまなメッセージが使用されます。たとえば、接続-" 情報ベースは更新中です」など。ISソースとしての受信者の選択のチェックを追加しました-警告が発行されます。

次の用途に使用できます：

1. ISソースからISレシーバーへの規範的および参照情報（NSI）の転送（NSI全体の転送はユーザーの要求に応じて実行され、必要な参考書などは転送用のリンクによって転送されます）。

2.選択した期間のドキュメントの転送。

3.「壊れた」IBからのすべての情報の転送（1C：エンタープライズモードで開始されている場合）。データのアップロードまたはConfiguratorの起動は不可能です。

処理機能-受信者とソースの情報セキュリティは2.0から3.0まで異なる転送が可能です-エディションは異なりますが、転送は機能します!!! 不一致の属性は無視されるか、転送アルゴリズムを指定する必要があります。

コメント： データ変換は使用されません！そして、理由を聞かないでください！最も腐食性の高い-BP3.0はほぼ毎日変更されますが、転送ルールを最新の状態に保つ力はもはやありません-ここではすべてが簡単です:-)。

もう1つの処理機能は、レシーバーのISで起動されることです（機能の点で最も近いアナログは、ソースからレシーバーまで逆に機能します）。

作業の開始-処理期間を指定し、ソースから組織を指定する必要があります。組織はレシーバーに転送されます。

組織が移管されると、会計方針と「付随する」情報レジスタが移管されます。したがって、ソースで最初に組織を選択したとき、それがレシーバーに表示されるまでに時間がかかります。

ソースとレシーバーの勘定科目表は同じである必要があり、バージョン2で異なる勘定科目はありません。*はレシーバーに転送され、勘定科目と分析の対応の設定は将来含まれる予定です。アカウントは、レシーバーにないコードで転送されます。作成しないでください!!!

残りのオブジェクトは内部識別子（GUID）によって転送されるため、いくつかの重要な参考書、たとえば-通貨に注意を払う必要があります。

「クリーンな」ベースと交換する場合は、交換前の最初の開始時に記入した参考書を削除することをお勧めします。このために、ディレクトリのこれらの要素を取得して削除できるページが処理用に提供されています。少なくとも、「RUB」通貨を削除する必要があります。 - 以来重複はほぼ避けられません（原則として、BP 3.0に組み込まれている重複の検索と置換を交換した後、これは簡単に修正できます）。

処理中、最初の入力フォームが開いているときに、ディレクトリを削除するためのページへの呼び出しが推定されました。

処理を開くと、最初の記入時に記入された参考図書を削除するためのページが表示されます。

バージョン3.22以降、インターフェースが変更され、すべての準備操作がブックマークされ、いつでも利用できるようになりました。

ソースとレシーバーの勘定科目表の対応を確認し、アカウントの対応を必ず示すことが重要です。

事前定義されたディレクトリ要素を削除する必要はありません。それらは（GUIDではなく）構成識別子によって転送されます。

ディレクトリやドキュメントから選択フォームを使用して、転送するオブジェクトを選択できます（このオブジェクトに関連付けられている情報レジスタは自動的に移行されるため、個別に選択する必要はありません）。レジスタの転送は一時的に無効になります-転送するレジスタのリストを作成する必要があります-何かを転送する必要がありますが、この段階では、ディレクトリに転送されるもので十分です。転送するレジスタのリストは次のようになります。テンプレートでは、将来のバージョンで。

2.0と交換する場合、詳細の一部（たとえば、連絡先）は、処理に組み込まれているアルゴリズムに従って引き継がれます。 2.0と3.0では保存方法が異なります。状況は、多くの文書（たとえば、債務調整）でも同様です。

オブジェクトタイプのリストは、バージョン3.22ではさまざまな方法で入力できます。これはサブメニューに配置され、変更は図に書き込まれます。

処理の使用が単純化されています。交換するディレクトリを選択することはできませんが、受信側のタイプのリストに、ソースに少なくとも1つのレコードがあるタイプのディレクトリのみを入力するだけです。

処理には組み込みのレイアウトがあり、ソースから宛先に転送する必要のないディレクトリが一覧表示されます（レイアウト「転送から除外」）。このレイアウトへの参照を追加（削除）できます。参照データ全体を転送する必要がない場合は、タイプを選択せずにリストを取得することもできるドキュメントを転送するだけで十分です。トランザクションがあるすべてのソースドキュメントに入力するだけです。

移動のある伝票の転送が提供されます。交換3.0から3.0の場合、勘定科目表によると1対1で機能し、2.0から3.0の交換ではエラーが発生する可能性があるため、移動のない伝票を転送してから、単に再転記することをお勧めします。レシーバーでそれら。動きのある原稿を転送する場合、「手動修正」フラグが設定されます。

「転記済み」属性は、ソースと同じようにレシーバの伝票に設定されますが、移動（転送されていない場合）は、たとえばBP 3.0グループ伝票処理に組み込まれている処理を使用して伝票が転記された後にのみ表示されます（推奨オプション）、またはこの処理から（ここに[ドキュメントの投稿]ボタンがあります）。

恒久的な交換に使用する予定の場合は、受信者のIS（「登録」ボタン）に登録できます。「1回限り」の転送の場合は、[ファイル]-[開く]から簡単に使用できます。

2015年12月21日-バージョン3.1プラットフォーム8.3.7.1805およびBP3.0.43.29（3.0.43のバージョン2.15。*機能しません-構成が大幅に変更されました）。

かわった：

接続オプションを選択するためのダイアログ、クライアント/サーバーフラグは、その設定に応じて、ファイルベースフォルダーの選択が使用可能であるか、サーバー上のベースの名前とサーバーの名前のフィールドのいずれかで常に使用可能です。それ自体（ダイアログバージョン2.15のエラーが修正されました）

- 新機能： さまざまな詳細度でのソースとレシーバーのベース間の残差と回転の調整のメカニズム：

調整オプションの選択は、図から明らかだと思います。

シンクライアントとシッククライアントでは使用方法に違いがあります。シッククライアントでは、ファイル比較ウィンドウがすぐに表示されます。

シンクライアントでは、プログラムによるボタンの押下で倒錯しませんでした。比較ウィンドウを表示するための簡単なオプションを提案します。

シンクライアントであるIMHOでの比較は、次の点でより便利です。違いをナビゲートするためのボタンがあります。これは、マウスでスクロールするよりも大量のテーブルに便利です。

2016年3月22日バージョン3.10-参照オブジェクトを強制的に上書きするための「常にリンクを上書きする」フラグを追加しました（転送速度は大幅に低下しますが、必要な場合もあります）。「準備」タブが追加されました。このタブでは、ソースと宛先の勘定科目表の対応（勘定科目コードのあるレベル）と定数の転送を構成できます。プラットフォーム8.3.7.1970、BP 3.0.43.148

- 新機能：伝票を転送する前に、ソースと宛先の整合性、および確立された定数の整合性について勘定科目表を確認することをお勧めします。

これを行うために、これらの対応を設定できる「準備」タブを追加しました。

アカウントの対応のテーブルに記入するためのアルゴリズムは単純です-ソースに存在する売上高が分析され、そこで見つかった各アカウントは、レシーバーのコードによって一致するものが検索されます。一致するものが見つからない場合は、アカウントコードはテーブルに表示され、受信者のアカウントを選択する必要があります。これは転送時に使用されます。科学の対応は、コードのレベルで確立されます。

確立された定数の対応を確認して転送するには、対応するテーブルを使用します。

必要に応じて記入し、転送します。フラグが付いている定数のみが引き継がれます...

プログラムスタックは、LIFOキュー（後入れ先出し-後入れ先出し）に基づいて編成されたメモリの特別な領域です。「スタック」という名前は、プレートのスタックを使用した構造の原理に類似しています。プレートを互いに重ねて配置し（スタックに追加する方法、「プッシュ」、「プッシュ」）、次に上から順にピックアップします（スタックから値を取得する方法、「pop」、「pop」）。プログラムスタックは、呼び出しスタック、実行スタック、マシンスタックとも呼ばれます（「スタック」（抽象データ構造）と混同しないようにするため）。

スタックとは何ですか？これにより、サブルーチンの呼び出しを簡単に整理できます。呼び出されると、関数はいくつかの引数を受け取ります。また、ローカル変数をどこかに格納する必要があります。さらに、ある関数が別の関数を呼び出すことができることを考慮に入れる必要があります。別の関数もパラメーターを渡し、その変数を格納する必要があります。スタックを使用すると、パラメーターを渡すときに、それらをスタックに配置するだけで済みます。そうすれば、呼び出された関数は、パラメーターをそこから「プッシュ」して使用できるようになります。ローカル変数も同じ場所に格納できます。コードの先頭で、関数はスタックメモリの一部を割り当て、制御が戻ると、それをクリアして解放します。高水準言語のプログラマーは通常、そのようなことについては考えません-コンパイラーはそれらに必要なすべてのルーチンコードを生成します。

エラーの結果

今、私たちは問題に非常に近づいています。その抽象的な形では、スタックは、新しい要素を無限に追加できる無限のストレージです。残念ながら、私たちの世界では、すべてが有限であり、スタックの下のメモリも例外ではありません。関数の引数がスタックにプッシュされたときに終了するとどうなりますか？または、関数はその変数にメモリを割り当てますか？

スタックオーバーフローと呼ばれるエラーが発生します。スタックはユーザー定義関数（および上のほとんどすべてのプログラム）の呼び出しを整理するために必要なので現代語オブジェクト指向のものを含め、何らかの形で関数に基づいて構築されているため、呼び出すことができなくなります。したがって、オペレーティングシステムが制御を取得し、スタックをクリアして、プログラムを終了します。ここで、とスタックオーバーフローの違いを強調することができます-最初のケースでは、間違ったメモリ領域にアクセスするとエラーが発生し、この段階で保護がない場合、その時点では現れません-偶然の一致で、プログラムは正常に動作します。アクセスされているメモリのみが保護されている場合、それが発生します。スタックの場合、プログラムは必ず終了します。

正確には、このイベントの説明は、ネイティブコードにコンパイルするコンパイラにのみ当てはまることに注意してください。管理対象言語では、仮想マシンには管理対象プログラム用の独自のスタックがあり、その状態を監視するのははるかに簡単であり、オーバーフローが発生したときにプログラムに例外をスローする余裕さえあります。 CおよびC ++言語では、このような「贅沢」は期待できません。

エラーの理由

何がそのような不快な状況につながる可能性がありますか？上記のメカニズムに基づくと、1つのオプションはネストされた関数呼び出しが多すぎることです。このシナリオは、再帰を使用する場合に特に発生する可能性があります。無限再帰（「遅延」評価のメカニズムがない場合）は、この方法で中断されます。これは、便利なアプリケーションがある場合とは異なります。ただし、スタックに割り当てられたメモリの量が少ない場合（たとえば、マイクロコントローラでは一般的です）、単純な一連の呼び出しで十分な場合があります。

もう1つのオプションは、大量のメモリを必要とするローカル変数です。 100万個の要素のローカル配列、または100万個のローカル変数（何が起こるかわからない）を持つことは最善のアイデアではありません。このような貪欲な関数を1回呼び出すだけでも、スタックオーバーフローが発生しやすくなります。大量のデータを取得するには、ヒープメモリのメカニズムを使用することをお勧めします。これにより、不足のエラーを処理できます。

ただし、ヒープメモリは（オペレーティングシステムがこれを行うため）割り当てと割り当て解除の点で非常に低速です。直接アクセス手動で割り当てて解放する必要があります。スタック上のメモリは非常に迅速に割り当てられ（実際には、1つのレジスタの値を変更するだけで済みます）、さらに、関数が戻ってスタックがクリアされると、スタックに割り当てられたオブジェクトに対してデストラクタが自動的に呼び出されます。もちろん、スタックからメモリを取得したいという欲求はすぐに生じます。したがって、オーバーフローする3番目の方法は、スタック内でのプログラマーの自己割り当てです。 Cライブラリは、この目的のために特別にアロカ関数を提供します。動的メモリmallocを割り当てるための関数に、それを解放するための「ツイン」がある場合、関数allocaにはそれがありません。つまり、関数の制御が戻った後、メモリは自動的に解放されます。おそらくこれは状況を複雑にするだけです-結局のところ、関数を終了する前にメモリを解放することはできません。マニュアルページによると、「allocaはマシンとコンパイラに依存します。多くのシステムでは、その実装に問題があり、多くのバグが含まれています。その使用は非常に軽薄であり、嫌われています」-それはまだ使用されています。

の例

例として、MSDNにある再帰ファイル検索のコードを考えてみましょう。

Void DirSearch（String * sDir）（try（//渡されたフォルダー内のサブフォルダーを検索します。String* d = Directory :: GetDirectories（sDir）; int numDirs = d-> get_Length（）; for（int i = 0; i< numDirs; i++) { // Find all the files in the subfolder. String* f = Directory::GetFiles(d[i],textBox1->文章）; int numFiles = f-> get_Length（）; for（int j = 0; j< numFiles; j++) { listBox1->アイテム->追加（f [j]）; ）DirSearch（d [i]）; ））catch（System :: Exception * e）（MessageBox :: Show（e-> Message）;））

この関数は、指定されたディレクトリ内のファイルのリストを取得し、ディレクトリであることが判明したリストアイテムを呼び出します。したがって、ファイルシステムのツリーが十分に深い場合、論理的な結果が得られます。

「スタックオーバーフローが発生するのはなぜですか？」という質問から抜粋した2番目のアプローチの例。 Stack Overflowと呼ばれるサイトから（このサイトは、見た目はスタックオーバーフローだけでなく、プログラミングトピックに関する質問と回答のコレクションです）：

#define W 1000 #define H 1000 #define MAX 100000 // ... int main（）（int image; float dtr; initImg（image、dtr）; return 0;）

ご覧のとおり、main関数では、メモリはint型とfloat型の配列用にスタックに割り当てられ、それぞれ100万要素であり、合計で8メガバイト弱になります。デフォルトでVisualC ++がスタック用に1メガバイトしか予約していないことを考えると、答えは明白になります。

そして、LightsparkFlashプレーヤープロジェクトのGitHubリポジトリから抜粋した例を次に示します。

DefineSoundTag :: DefineSoundTag（/ * ... * /）（// ... unsigned int soundDataLength = h.getLength（）-7; unsigned char * tmp =（unsigned char *）alloca（soundDataLength）; // .. 。）

うまくいけば、h.getLength（）-7は、次の行のオーバーフローを回避するのに大きすぎないでしょう。しかし、メモリ割り当てで節約された時間は、「潜在的な」プログラムクラッシュの価値がありますか？

結果

スタックオーバーフローは致命的なエラーであり、再帰関数を含むプログラムに最も一般的に影響します。ただし、プログラムにそのような関数が含まれていない場合でも、ローカル変数の量が多いか、スタック上のメモリの手動割り当てでエラーが発生するため、オーバーフローが発生する可能性があります。すべての古典的なルールは引き続き有効です。選択肢がある場合は、再帰ではなく反復を優先し、コンパイラの代わりに手作業を行わない方がよいでしょう。

書誌リスト

E.タネンバウム。コンピュータアーキテクチャ。
ウィキペディア。スタックオーバーフロー。
スタックオーバーフロー。スタックオーバーフローC ++。

このコンテキストでは、スタックは、プログラムの実行中に割り当てる最初のバッファーの最後のスタックです。最後に、最初（LIFO）は、最後に置いたものが常に最初に返されることを意味します。スタック上の2つのアイテム、「A」、次に「B」をヒットした場合、スタックから最初にポップしたものは「 B」と次は「A」になります。

コード内で関数を呼び出すと、関数呼び出し後の次のコマンドがスタックに格納され、関数呼び出しによって上書きされる可能性のあるメモリスペースがすべて格納されます。選択した関数は、それ自体のローカル変数により多くのスタックを使用できます。完了すると、使用していたローカル変数スペースが解放され、前の関数に戻ります。

スタックオーバーフロー

スタックオーバーフローとは、プログラムが意図したよりも多くのメモリをスタックに使用した場合です。組み込みシステムでは、スタックに使用できる関数は256バイトのみであり、各関数が32バイトの場合、関数2への関数呼び出しは8回のみで、深い関数1は関数3を呼び出し、関数4は呼び出します...関数8を呼び出し、関数9を呼び出しますが、関数9はスタック外のメモリを上書きします。これにより、メモリやコードなどが上書きされる可能性があります。

多くのプログラマーは、関数Aを呼び出し、次に関数Bを呼び出し、次に関数Cを呼び出し、次に関数Aを呼び出すことによってこの間違いを犯します。ほとんどの場合は機能しますが、入力を1つ間違えると、コンピューターまで永久に循環します。スタックがいっぱいであることを学習します。

再帰関数もこれを引き起こしますが、再帰的に記述している場合（つまり、関数がそれ自体を呼び出す場合）、これを認識し、静的/グローバル変数を使用して無限の再帰を防ぐ必要があります。

通常、使用しているOSとプログラミング言語がスタックを管理しますが、これは手に負えません。コールグラフ（各関数が何を呼び出すかをメインポイントから示すツリー構造）を見て、関数呼び出しの深さを確認し、意図されていないループと再帰を特定する必要があります。意図的なループと再帰は、相互に何度も呼び出す場合、エラーがないか人為的にチェックする必要があります。

優れたプログラミング手法、静的および動的テストを除けば、これらのシステムでできることはあまりありません。上級.

組み込みシステム

組み込みの世界、特に信頼性の高いコード（自動車、航空、宇宙）では、広範なコードチェックと検証を行いますが、次のことも行います。

再帰とループを禁止する-ポリシーのコンプライアンスとテスト
コードとスタックを離れた場所に保管します（フラッシュ内のコード、RAM内のスタックであり、一致することはありません）
スタックの周りにガードストライプを配置します-マジックナンバーで埋めるメモリの空の領域（通常は割り込みプログラムですが、ここには多くのオプションがあります）、そしてガードストリップを見ると毎秒数百または数千回それらが上書きされていないことを確認してください。
メモリ保護を使用します（つまり、スタックで実行したり、スタックに直接読み取りまたは書き込みを行ったりしないでください）
割り込みは二次関数を呼び出さない-フラグを設定し、データをコピーし、アプリケーションに処理を任せます（そうしないと、関数呼び出しツリーの奥深くに8が入り、割り込みが発生し、割り込み内にさらにいくつかの関数が含まれる可能性があります終了し、バーストを引き起こします）。複数の呼び出しツリーがあります。1つはメインプロセス用で、もう1つは割り込みごとにあります。あなたの割り込みがお互いに割り込むことができるなら...まあ、ドラゴンがいます...

高水準言語とシステム

しかし、オペレーティングシステムで実行されている高級言語では：

減らすローカルストレージ変数（ローカル変数はスタックに格納されます）。ただし、コンパイラーはこれについて非常に賢く、呼び出しツリーが小さい場合はヒープに大きなチャンクを配置することがあります）
再帰を回避または厳しく制限する
プログラムをどんどん小さな関数に割り込まないでください。ローカル変数を無視しても、各関数呼び出しはスタック上で最大64バイトを消費します（32ビットプロセッサ、プロセッサレジスタの半分、フラグなどを保持します）。
コールツリーを浅く保つ（上記と同様）

Webサーバー

スタックを制御できるか、表示できるかは、サンドボックスによって異なります。他の高級言語と同じようにウェブサーバーを処理できる可能性があります。オペレーティング・システム、ほとんど手に負えませんが、使用されている言語とサーバースタックを確認してください。たとえば、SQLサーバーでスタックを分割することができます。

1cリクエストが複雑すぎる、スタックオーバーフローの可能性があります。 スタックオーバーフロー。 アプリケーションサーバーとMSSQLServer間の送信中のデータ暗号化

序章