1c レコードレベルでデータへのアクセスを制限します。 RLS – データアクセス制限の柔軟かつ微調整

24.05.2024

印刷 (Ctrl+P)

データへのアクセスを制限する

データアクセス制限メカニズム (RLS、行レベルセキュリティとも呼ばれます) を使用すると、メタデータオブジェクトのレベルだけでなく、1C:Enterprise データベースオブジェクトのレベルでもアクセス権を管理できます。データへのアクセスを制限するには、次の 1C:Enterprise オブジェクトを使用できます。
●役割、
● セッションパラメータ、
●機能オプション、
● 特権付き共通モジュール、
● キーワードはクエリ言語で許可されます。
リストされたオブジェクトを共有すると、異なる機能を実行するユーザー間でデータへのアクセス権を区別する必要がある場合に、最大限の柔軟性が得られます。
データアクセス制限は、読み取り（読み取り権）、追加（追加権）、変更（変更権）、削除（削除権）のデータ操作（アクセス権）に課すことができます。現在のユーザーは、次の場合に必要な操作を実行できます。
● 読み取りおよび削除操作の場合、データベース内のオブジェクトはデータアクセス制限に準拠している必要があります。
● 追加操作の場合、データアクセス制限は、データベースに書き込む予定のオブジェクトと一致する必要があります。
● 変更操作の場合、データアクセス制限は、変更前 (オブジェクトが読み取られるため) と変更後 (オブジェクトが書き込まれるため) の両方でオブジェクトと一致する必要があります。
データアクセス制限を適用する場合、変更、追加、削除の操作には条件を 1 つだけ指定できますが、読み取り操作には複数のデータアクセス制限を指定できることに注意してください。つまり、オブジェクトのさまざまなフィールドを読み取るためにさまざまな条件を設定でき、条件を設定するときに、特定のフィールドの名前と特別なフィールドであるその他のフィールドの両方を指定できます。最初のケースでは、(データを読み取る) 選択項目に制限が設定されているフィールドが含まれている場合にのみ条件が課されます。2 番目のケースでは、オブジェクトのすべてのフィールドに制限が課されます。制限が明示的に設定されているフィールド。
特定のフィールドに制限を設定した場合、その制限が満たされた場合にそのフィールドが読み取られます。また、その他のフィールドに制限を設定した場合、オブジェクトに含まれるオブジェクトのすべてのフィールドに対して制限が満たされた場合にのみ、オブジェクトデータが読み取られます。データ読み取りリクエスト。
次のタイプのデータベースオブジェクトでは、さまざまなタイプの変更 (追加、変更、削除) にさまざまな制限が課される可能性があります。
● 交換計画、
● ディレクトリ、
●書類、
● 特性の種類の計画、
● 勘定科目表、
● 計算タイプの計画、
● ビジネスプロセス、
● タスク。
次のタイプのデータベースオブジェクトの場合、オブジェクト全体だけでなく、その個々のフィールドの読み取りにも制限を課すことができます。
● 交換計画、
● ディレクトリ、
●書類、
● 文書ログ、
● 特性の種類の計画、
● 勘定科目表、
● 計算タイプの計画、
● 情報レジスタ、
● ビジネスプロセス、
● タスク。
注意！組み込みの 1C:Enterprise 言語からアプリケーションオブジェクトのプロパティを使用してデータベースオブジェクトのフィールドにアクセスすると、使用されているフィールドの値だけでなく、オブジェクト全体が読み取られます。例外は、ビューを受信する場合で、ビューの生成に関与するフィールドの値のみが読み取られます。
アクセス制限はロールに含まれており、ほとんどのメタデータオブジェクトに対して指定でき、クエリ言語のサブセットである特別な言語で記述されます。

データアクセス制限言語

データアクセス制限は、クエリ言語のサブセットである特別な言語で記述されます (クエリ言語の詳細な説明。データアクセス制限言語には、クエリ言語と比較して次の変更があります。
● データアクセス制限リクエストでは、データソースとして常に 1 つのテーブルが存在します。これは、制限が適用されるオブジェクト (制限の主オブジェクト) のテーブルです。
● リクエストの説明が短縮されました。データアクセス制限言語は、クエリ言語の FROM セクションと WHERE セクションのみを使用します。したがって、クエリ言語の説明は次のようになります。
[許可] [異なる] [を選択してください初め<Количество> ]
<選択フィールドのリスト>
[から <Список источников> ]
[どこ<Условие отбора> ]
[グループ化 <Поля группировки> ]
[持つこと]<Условие отбора> ]
[変更のため [ <Список таблиц верхнего уровня> ]]
データアクセス制限クエリ言語の説明は次のとおりです。
[メイン制約オブジェクトのテーブル別名]
[から <Список источников> ]
[どこ<Условие отбора> ]

データアクセス制限言語で使用されるネストされたクエリでは、許可される機能のセットが制限されています。
● セッションパラメータと機能オプションを条件要素として指定できます。
● データアクセス制限リクエストのどの時点でも、制限の記述を簡素化するテンプレートを使用できます。
制約の主要部分は、データアクセス制限の対象となるデータベーステーブルのレコードごとに評価される条件です。制約の主オブジェクトの 1 つのテーブルレコードに対する条件の操作の結果、空ではないテーブル (つまり、1 つ以上のレコードを持つテーブル) が取得された場合、レコードは使用可能であるとみなされます。条件の結果が空のテーブルになる場合、この方法で条件が満たされたレコードはアクセス不可能とみなされます。さらに、メイン制約オブジェクトのテーブルエントリを変更します。
変更操作の実行前と実行後の両方で、エントリが権利に指定された制限に矛盾しない場合、有効とみなされます。

テーブルフィールド

データアクセス制限では、以下を使用できます。
● データアクセス制限が記述されているオブジェクトのテーブルフィールド。
たとえば、Counterparties ディレクトリの要素の読み取りに制限が課されている場合、その制限では Counterparties ディレクトリのフィールドとその表部分を使用できます。特に、Counterparty ディレクトリの要素の読み取りに関する最も単純な制限は次のようになります。

WHERE 名前 = 「レンガ工場」
または次のようにします。

どこ製品名.名前= 「レンガは赤いです」
ここで、Products は、Contractors ディレクトリの表形式の部分です。
● メイン制約オブジェクトのリンクを通じてアクセスできるオブジェクトのテーブルのフィールド。
たとえば、Contractors ディレクトリの Main Manager 属性に Users ディレクトリへのリンクタイプがある場合、アクセス制限は次のような形式になります。

どこ MainManager.コード=「イワノフ」
または：

どこメインマネージャー個人名=「ペトロフスキー」
● 特定の条件およびそれに対する式によって制限の主オブジェクトに関連付けられたオブジェクトテーブルのフィールド。
たとえば、Counterparty ディレクトリの要素の読み取りには次の制限が課される場合があります。

取引相手
から
ディレクトリ.取引先どのように取引相手
左接続ディレクトリ.ユーザー ASユーザー
ソフトウェア = ユーザー.名前
どこ = 「ペトロフスキー」
この制限では、Name フィールドの値によって、Counterparties ディレクトリのこの要素に関連付けられた Users ディレクトリ要素のフィールドが使用されます。

ネストされたクエリ

ネストされたクエリは、使用できるレコードのセットを形成するために使用されます。
● メイン制約オブジェクトのテーブルにリンクします。
● B または NOT B 比較演算のオペランドとして使用します。
ネストされたクエリでは、以下を除く任意のクエリ言語機能を使用できます。
● 階層内の演算子。
● 結果の提案。
● ネストされたクエリの結果には表部分が含まれないようにしてください。
● 一部の仮想テーブル、特に残留と売上高.
Accounts ディレクトリからの読み取りに対する制限の次の例では、制限のメインオブジェクトに関連付けるレコードのセットとしてサブクエリが使用されています。

取引相手
から
ディレクトリ.取引先どのように取引相手
左接続
（選ぶ
ユーザー名、ユーザー名、個人
から
ディレクトリ.ユーザー ASユーザー
どこ
ユーザーコード>「ペテキン」）ASユーザー
による取引相手の名前。 = ユーザー名
どこユーザーの個人名=「ペトロフスキー」
次の例は、個人のパスポートデータディレクトリからの読み取りの制限を示しています。ここでは、ネストされたクエリが使用されています。
比較演算 B のオペランドとして:

どこ
パスポートデータ個人.個人で
(さまざまな選択
労働者.個人個人として
から
情報の登録.従業員労働者として）
ネストされたクエリで表形式の部分からデータを取得する必要がある場合は、ネストされたクエリの FROM セクションで表形式の部分に直接アクセスする必要があります。たとえば、次の代わりに:

SELECT リンク AS リンク、
製品名.名前どうやって製品名
からディレクトリ.取引先
制約内にネストされたクエリとして、次のものを使用する必要があります。

セッションオプション

データアクセス制限リクエストにはセッションパラメータが含まれる場合があります。たとえば、ディレクトリ要素を読み取る場合電子メールレターのグループ以下のアクセス制限を設定できます。

どこ Owner.AccountAccess.User = &CurrentUser
そして所有者.アカウントアクセス.管理= 真

CurrentUser はセッションパラメータです

機能オプション

データアクセス制限リクエストには機能オプションが含まれる場合があります。パラメータに依存しない機能オプションのみを使用できます。たとえば、Items ディレクトリに MainWarehouse 属性がある場合、この属性の読み取り制限は次のようになります。

WHERE 倉庫会計 = TRUE(&W)

倉庫会計が機能的なオプションである場合

使用上の特徴

メイン制約データオブジェクトのすべてのフィールドが、次の種類のデータベースオブジェクトの制限で使用できるわけではありません。
● 累算レジスタでは、アクセス制限には制限の主要オブジェクトの測定値のみを含めることができます。
● 会計記録簿では、制限の主要対象の貸借対照表測定のみを制限に使用できます。
注記。売上高累積レジスターのデータへのアクセスが制限されている条件下で、合計に含まれない測定値が使用される場合、
仮想回転テーブルにアクセスする場合、保存されている合計は使用されず、要求は完全に動作テーブルに従って実行されます。

アクセス制限アクション

アクセス制限は、データベースオブジェクトに対して適切な操作 (ダイアログ、組み込み言語、クエリを通じて) が実行されるたびにチェックされ、次の 2 つの方法のいずれかで動作します。
●すべて。「all」メソッドは、データに対する何らかの操作 (ダイアログ、組み込み言語、またはクエリによる) が、この操作に含まれるすべてのデータベースオブジェクトに対して実行される必要があることを意味します。このような操作で、適切なアクセス制限が満たされていないデータベースオブジェクトの読み取りまたは変更が必要な場合、操作は終了します。
アクセス違反による異常です。
● 許可されます。「許可」メソッドは、データに対する操作を実行するときに、適切なアクセス制限を満たすデータベースオブジェクトのみを読み取る必要があることを意味します。アクセス制限を満たさないデータベースオブジェクトは、このような操作を実行するときに欠落しているとみなされ、操作の結果には影響しません。
1C:Enterprise がデータベースにアクセスするときに、データベースオブジェクトにデータアクセス制限が課されます。 1C:Enterprise のクライアントサーバーバージョンでは、1C:Enterprise サーバーに制限が適用されます。
データに対する各操作を実行するために選択される制限の操作方法は、この操作の目的とその結果の責任の程度によって決まります。特に、「許可」メソッドは、動的リストやその他の対話型アクションを表示するときに使用されます。「all」メソッドは、データベースオブジェクトへの変更を含む、組み込み 1C:Enterprise 言語からアプリケーションオブジェクトを使用した操作を実行するときに使用されます。したがって、たとえば、対応するオブジェクトにかなり複雑な制限が設定されている場合、ディレクトリ、ドキュメントなどのマネージャーの Select() メソッドの選択を構築する際に、結果がバイパスされるため、問題が発生する可能性があります。アクセス権の制限は、Select() メソッドの選択として適切に表現できます。
クエリでは、データアクセス制限の動作を制御できます。この目的のために、クエリ言語はキーワードを提供します。許可された。リクエストで ALLOWED が指定されていない場合、制限は「すべて」の方法で適用されます。 ALLOWED という単語が指定されている場合、「許可」メソッドが選択されます。
クエリで ALLOWED キーワードが指定されていない場合、そのクエリで指定されたすべての選択が、クエリで使用されるデータベースオブジェクトの読み取り制限と競合しないことが重要です。さらに、クエリで仮想テーブルを使用する場合は、対応する選択を仮想テーブル自体に適用する必要があります。
例：

選ぶ
お問い合わせ情報セクションはじめに
から RegisterInformation.ContactInformation.SliceLast(, Type = &Type)
どうやってお問い合わせ情報スライスファースト
どこ
ContactInformationSliceFirst.Type = &Type
オブジェクトテクノロジを使用する場合、ALLOWED モードでのデータへのアクセスはサポートされません。オブジェクトテクノロジは、データの変更など、データに対する最も重要な操作に使用されることが想定されています。オブジェクトテクノロジを使用してすべてのデータを取得するには、設定された制限に関係なく、特権モジュールで、または完全な権限を持つユーザーに代わって必要なアクションを実行できます。オブジェクト技術では許可されたデータのみを取得する手段がありません。

制限を課すメカニズム

1C:Enterprise のデータベースに保存されているデータに対する操作は、最終的には何らかの方法でデータベースにアクセスすることになります。
データの読み取りまたは変更を要求します。データベースへのクエリを実行するプロセスでは、1C:Enterprise の内部メカニズムによりアクセス制限が課されます。ここで:
● 権限のリスト (読み取り、追加、変更、削除)、データベーステーブルのリスト、およびこのリクエストで使用されるフィールドのリストが生成されます。
● 現在のユーザーのすべての役割から、リクエストに関係するすべての権限、テーブル、フィールドに対してデータアクセス制限が選択されます。さらに、ロールにテーブルまたはフィールドのデータへのアクセス制限が含まれていない場合、これは、任意のレコードの必須フィールドの値がこのテーブルで利用可能であることを意味します。つまり、データアクセス制限がないということは、制限があることを意味します。
真実はどこにあるのか。
● 選択した制限に関係するすべてのセッションパラメータと機能オプションの現在の値を取得します。
セッションパラメータの値を取得するために、現在のユーザーはその値を取得する権限を持っている必要はありません。ただし、一部のセッションパラメータの値が設定されていない場合は、エラーが発生し、データベースクエリは実行されません。
機能オプションの受信は、機能オプションの「受信時の特権モード」プロパティの影響を受けます。
このプロパティがクリアされている場合、現在のユーザーは関数オプションが格納されているオブジェクトへの読み取りアクセス権を持っている必要があります。
● 1 つのロールから派生した制約は、AND 演算を使用して結合されます。
● 異なるロールから派生した制約は、OR 演算を使用して結合されます。
● 構築された条件は、1C:Enterprise が DBMS にアクセスする SQL クエリに追加されます。アクセス制限条件からデータにアクセスする場合、権限チェックは (メタデータオブジェクトに対してもデータベースオブジェクトに対しても) 実行されません。さらに、条件を追加するメカニズムは、「すべて」または「許可」制限の選択された操作方法によって異なります。
「すべて」メソッド
「all」メソッドを使用して制限を課す場合、条件とフィールドが SQL クエリに追加されるため、1C:Enterprise はデータベースクエリの実行中に、特定のユーザーに対して禁止されているデータが使用されたかどうかに関する情報を取得できます。禁止されたデータが使用された場合、リクエストはクラッシュします。「all」方式を使用したアクセス制限の適用を図に示します。 1:

米。 1.「全部」方式

「許可」メソッド
「許可」方式を使用して制限を適用すると、現在のユーザーに禁止されているレコードがクエリの結果に影響を与えないように、SQL クエリに条件が追加されます。言い換えれば、「許可」モードで制限が課されると、特定のユーザーに対して禁止されているレコードが欠落しているとみなされます。これを図 3 に模式的に示します。

データアクセス制限に関連するその他のオブジェクト

データアクセス制限を使用する構成を設計する場合、セッションパラメーター、機能オプション、Privileged フラグを持つ共有モジュールなどのメタデータオブジェクトが役立つ場合があります。
セッションオプション
セッションパラメーターは、リクエストでリクエストパラメーターを使用するのと同じ方法で、データアクセス制限で使用できます。
機能オプション
パラメータに依存しない機能オプションは、クエリでクエリパラメータを使用するのと同じ方法で、データアクセス制限で使用できます。
特権付き共通モジュール

共通モジュールに対して Privileged フラグが選択されている場合、このモジュールのプロシージャと関数の実行により、次の重要な詳細が取得されます。
● 1C:Enterprise のクライアントサーバーバージョンでは、サーバー上で実行されるモジュールのみに特権を与えることができます。
● 特権モジュールのプロシージャと関数の実行、およびそれらから呼び出されるすべての処理は、制限システムがオフのときに実行されます。
メタデータオブジェクトとデータの両方に対する権利。したがって、特権モジュールからはあらゆる操作を実行できます。
現在のユーザーが適切な権限を持っていない場合でも、すべてのオブジェクトに適用されます。
特権モジュールは、データアクセス制限で使用されるセッションパラメーターの値を初期設定するように設計されています。
より一般的なモジュールは、制限された権限を持つユーザーによるデータに対するいくつかの総合的なアクションに使用できます。
たとえば、ユーザーの機能にドキュメントの入力と投稿が含まれているが、ドキュメントの投稿によって影響を受けるデータにユーザーがアクセスできないようにする場合、投稿操作の実行を特権モジュールに移すことができます。これにより、ユーザーは他の情報 (レジスターなど) に対する権利を付与せずにドキュメントを投稿できるようになります。
特権モード
データを操作するときに、プログラムで特権モードをインストールすることができます。特権モードでのソフトウェアのインストール
インフォベースデータを使用した大規模な操作の場合には、このチェックが必要になる場合がありますが、データアクセス権をチェックすることは意味がありません。
特権モードの説明については、ここを参照してください。

プリプロセッサの使用

データアクセス制限のテキストを編集する場合、プリプロセッサ命令を使用することができます。次の手順が利用可能です。

＃もし<Выражение>＃それから
#ELSEIF<Выражение>＃それから
＃さもないと
#ENDSIF
<Выражение>– 組み込み言語の任意の論理式。結果はブール型です。式には次のものが含まれる場合があります。
● 比較演算<, >, <=, >= , =, <> ;
● 論理演算 AND、OR、NOT。
● セッションパラメータ – 構文 &Parameter が使用されます。ここで、Parameter はセッションパラメータの名前です。
#IF または #ELSEIF ステートメントの結果が True の場合、アクセス制限ステートメントの結果のテキストには、#THEN キーワードに続くテキストが含まれます。式の結果が False の場合、#THEN キーワードの後のテキストはアクセス制限ステートメントのテキストに配置されません。 #ELSE ステートメントに続くテキストは、前の条件がいずれも満たされない場合、結果のアクセス制限テキストに配置されます。
注記。データアクセス制限のテキストにプリプロセッサ命令が含まれている場合、その制限は編集時の構文チェックに合格せず、コンストラクターを使用して変更できません。
例：

#IF&現在のユーザー<>「クリモバ」#THEN
<текст ограничения доступа>
#ENDSIF
ここ現在の使用者– セッションタイプパラメータディレクトリリンク.ユーザー。
この設計は、アクセス制限を設定するための条件が、ユーザー Klimova を除くディレクトリ内のすべてのユーザーに対してチェックされることを意味します。

アクセス制限文テンプレート

ロールには、ロールフォームの [制限テンプレート] タブに説明されているアクセス制限テンプレートのリストを含めることができます。エディターでアクセス制限テンプレートを編集して、アクセス制限とテンプレートをグループ編集することもできます。
各アクセス制限テンプレートには名前とテキストがあります。テンプレート名は、1C:Enterprise システムで採用されている名前の通常の規則に従います。
テンプレートテキストには、データアクセス制限言語のテキストの一部が含まれており、記号を使用して強調表示されているパラメータが含まれる場合があります。
“#”.
シンボルの後 “#” 次のような場合があります:
● キーワードの 1 つ:
● パラメータ。その後、テンプレート内のパラメータの番号が括弧内に示されます。
● CurrentTable – 制約が構築されているテーブルの完全名のテキストへの挿入を示します。
● 現在のテーブル名– 組み込み言語の現在のバージョンで、命令が適用されるテーブルの完全名 (引用符で囲まれた文字列値として) のテキストへの挿入を示します。
●CurrentAccessRight の名前 – 現在の制限が適用されている権利の名前が含まれます。読み取り/追加/挿入/変更/
更新、削除;
● テンプレートパラメータ名 – 対応するテンプレートパラメータ制約をテキストに挿入することを意味します。
● 「#」記号 – テキストに 1 つの「#」記号を挿入することを示します。

アクセス制限式には次のものが含まれる場合があります。

● アクセス制限テンプレート。形式で指定されます。
#TemplateName(“テンプレートパラメータ 1 の値”, “テンプレートパラメータ 2 の値”, ...)。各テンプレートパラメーターは二重引用符で囲まれます。パラメータテキストに二重引用符文字を指定する必要がある場合は、二重引用符を 2 つ使用する必要があります。
●機能ページの内容 (探している場所、探しているもの)。この関数は、WhereWeLook 文字列内で WhatWeLook 文字列の出現を検索するように設計されています。オカレンスが見つかった場合は True を返し、それ以外の場合は False を返します。

● 文字列連結の + 演算子。
テンプレートテキストの編集を簡単にするには、ロールフォームの [制限テンプレート] タブで、[テンプレートテキストの設定] ボタンをクリックします。表示されるダイアログで、テンプレートのテキストを入力し、「OK」をクリックします。
1C:Enterprise システムは、テンプレートテキストの構文をチェックし、テンプレートを使用する際の構文をチェックし、ロールアクセス制限テンプレートのテキストをリクエストテキストにマクロ置換します。
マクロテンプレートの置換は次のとおりです。
● テンプレートのテキスト内のパラメータの出現を、制約のテキスト内のテンプレートを使用するための式のパラメータ値に置き換えます。
● リクエストテキスト内のテンプレート使用式を結果のテンプレートテキストに置き換えます。
アクセス制限テンプレートを含む条件に対してクエリコンストラクターを呼び出すと、すべてのテンプレートが置き換えられるという警告が発行されます。
以下に制約テンプレートの例を示します。

データアクセス制限を設定する際に、機能に応じてデータへのユーザーアクセスを柔軟に管理するには、
次の原則を遵守してください。
● 事前準備が適切な情報セット (現在のユーザーに依存する場合があります) を選択する必要があります。選択される情報は、データへのアクセス制限を可能な限り簡素化するものである必要があり、また、大きすぎないものである必要があります。セッションパラメータに従って配布します。
● セッションパラメータの値は、セッションモジュールの SetSessionParameters() ハンドラに設定します。
● これが正当化されるデータ (データが機密であるか、システムの整合性を維持するために最も重要なデータ) にアクセス制限を設定します。アクセス制限を設定すると、このデータへのアクセスが遅くなる可能性があることに注意してください。制限が複雑すぎると速度の低下につながる可能性もあります。
● データに対する特定の限られた数の操作が、このデータへのフルアクセスを付与することが現実的ではないユーザーによって実行されるようにする必要がある場合は、これらのアクションを特権モジュールに移動するか、特権モードを明示的に有効または無効にします。プログラムコード内の適切な場所。
● オブジェクト書き込み時にシステムが行う各種チェックのためのデータアクセスは特権モードで行われます。

これにより、設定がこのデータで機能する場合、対応するフィールドのレコードレベルの権限制限を無効にしなくても済みます。
制御モードのみで計画:

● コードの親、所有者、および一意性をチェックするときのディレクトリの場合。
● 数値の一意性をチェックする際の文書、ビジネスプロセス、およびタスク用。
● コードの一意性をチェックするときに交換計画に対して無効になります。
● 親およびコードの一意性をチェックする際の勘定科目表および特性タイプの表に使用します。

データ制約クエリを作成するときに留意すべき制限と考慮事項がいくつかあります。

● オブジェクトテーブルにデータアクセス制限が指定されており、そのようなテーブルとの結合がデータクエリで使用される場合、接続条件 (ソフトウェアリクエストセクション) では、指定されたアクセス制限が適用されたオブジェクトのテーブル部分の使用が制限されます。禁じられている。
● クエリでフィールドが使用されていないテーブルをクエリで指定すると、すべてのデータアクセス制限がこのテーブルに課されます。たとえば、リクエスト SELECT QUANTITY(*) FROM Directory.Counterpartyテストディレクトリに指定されたすべてのアクセス制限を考慮して実行されます。制限は「OR」によって課されます。これは、少なくとも 1 つの条件下で使用可能なすべてのレコードが使用可能になることを意味します。一部のフィールドに条件が指定されていない場合、クエリはテーブル内のすべてのレコードに対して実行されます。
クエリでトップレベルのテーブルが使用される場合、ネストしたテーブルの列に指定された制限は課されません。
クエリでネストしたテーブルを使用する場合、制限はネストしたテーブルとトップレベルのテーブルの両方に適用されます。
たとえば、リクエスト Directory.Counterparty.Agreements から SELECT QUANTITY(*)契約の表部分に関連する制限だけでなく、取引相手ディレクトリのすべての制限も考慮して実行されます。

● 参照メタデータオブジェクトの表現を取得するために必要なフィールドへのアクセスがアクセス制限によって拒否された場合
データまたはオブジェクトへのアクセスがアクセス権レベルで拒否された場合、そのようなオブジェクトの表現を取得しても、現在のトランザクションの進行には影響しません。

データアクセス制限コンストラクター

データアクセス制限テーブルの [アクセス制限] 列のフィールドでコンストラクターを呼び出すには、編集モードに移行し、
[選択] ボタンをクリックし、開いたフォームで [クエリビルダー…] ボタンをクリックします。
コンストラクターフォームが画面に表示されます。

米。 3. 制約デザイナーの「テーブルとフィールド」タブ

その助けを借りて、データアクセス制限を設定するための条件が作成されます。
[テーブルとフィールド] タブで、データベースリストから必要なオブジェクトを選択し、それらをテーブルリストに移動します。複数のテーブルが指定されている場合、[リンク] タブがデザイナーフォームに追加されます。

米。 4. 制約デザイナーの「リンク」タブ

[リンク] タブでは、テーブルフィールド間のリンクに適用される条件が形成されます。新しい条件を入力するには、「追加」ボタンをクリックし、「Table1」列のテーブルの 1 つを選択します。「Table2」列で、フィールドが最初のフィールドに関連するテーブルを選択します。条件のリストの下には、テーブルをリンクするための条件を作成するために使用できるコントロールがあります。
単純条件タイプを選択した場合、Field1とField2に指定したテーブルの関連フィールドが選択され、比較条件が設定されます。比較されないフィールドが選択されている場合、「リンク条件」列の条件リストの行に「条件が正しく入力されていません」というテキストが表示されます。
[条件] タブで、必要に応じて、ソースデータが選択される条件を指定する必要があります。

米。 5. 制約デザイナーの「条件」タブ

選択したフィールドごとに、条件のタイプを選択し、パラメーターの名前を指定する必要があります。パラメータとしてセッションパラメータを使用できます。複数の条件が許可されます。この場合、条件テーブルフィールドの条件列には、条件テキストが数行に渡って表示されます。
リクエストの作成中はいつでも、「リクエスト」ボタンをクリックすることでリクエストのテキストを表示できます。

権限制限やテンプレートの一括編集

アクセス権制限およびテンプレートのグループ編集モードは、[役割] ブランチのコンテキストメニューの [すべてのアクセス制限] コマンドによって呼び出されます。開いたフォームには、「アクセス制限」と「制限テンプレート」という 2 つのタブが含まれています。

米。 6 すべての権限制限とテンプレート

ブックマークにアクセス制限入力されたすべてのアクセス制限を一般リスト (すべての役割、オブジェクト、権限、フィールドの組み合わせ) で表示できます。
複数のロール、オブジェクト、権利、およびロールの組み合わせに対するアクセス制限を一度に追加できます。
さまざまな基準でリストをフィルタリングできます。

米。 7. アクセス制限の選択

グループ編集モードでは、リストで選択した制限を削除できます。
選択した制限を編集することが可能です。この場合、フィールドの構成やアクセス制限を変更できます。
グループ編集モードでは、選択した制限を他のロールにコピーすることもできます。

ブックマークに制約テンプレートアプリケーションソリューションに存在するすべてのアクセス制限テンプレートを確認できますが、テンプレートテキスト自体からは最初の 10 行のみがテーブルに表示され、テンプレートテキストが 10 行を超える場合は「…」記号で終わります。テンプレート編集ウィンドウにテンプレートの全文が表示されます。

図 8. すべてのアクセス制限テンプレート

複数のロールのアクセス制限テンプレートを一度に追加できます。

ディレクトリエントリレベルでのアクセスを設定します。

この設定は少し前に設定に含まれていたもので、個人的には非常に便利な設定だと思います。

この設定は、このディレクトリの要素によってディレクトリへのアクセスを制限する必要がある場合に必要です。たとえば、マネージャーは、アクセスが許可されている取引相手のみの顧客とレポートや文書ログのみを表示する必要があり、会計士は、ディレクトリのすべての要素 (たとえば、「取引先」) に完全なアクセス権を持っている必要があります。」

ソフトスターター構成の例を使用して例を検討することを提案します。

この段階では、一連のユーザーグループを定義する必要があります。

管理者;

営業マネージャー。

購買マネージャー;

第 2 段階では、ディレクトリへのアクセスグループが決定されます。

購入者;

サプライヤー;

通常、上記のグループのリストは経営陣と話し合われてから初めてプログラムに入力されます。

ここで、1C で実行する必要がある実際の設定を説明する必要があります。

「レコードレベルでのアクセス制限」を有効にしてみましょう。サービス - ユーザーとアクセスの管理 - レコードレベルでパラメータにアクセスします。図を参照してください。 1.

「レコードレベルでパラメータにアクセス」という処理フォームが開きます。図を参照してください。 2.

このフォームでは、実際に「オブジェクトの種類ごとにレコードレベルでのアクセスを制限する」フラグによる制限を有効にし、制限を適用するディレクトリを選択する必要があります。この記事では、「Counterparty」ディレクトリについてのみ説明します。

次に、記事の冒頭で定義したユーザーと請負業者のグループが必要になります。

請負業者グループは「ユーザーグループ」ディレクトリに入力されます (図を参照)。 3.

ディレクトリ要素「ユーザーグループ」のフォームが開きます。図を参照してください。 4.

ウィンドウの左側にはアクセスオブジェクト (ここでは「取引相手」) が表示され、右側にはグループのメンバーであるユーザーが表示されます。この例では「管理者」です。

定義するユーザーグループごとにこの設定を完了する必要があります。グループのメンバーではないユーザーが 1 人も残らないようにする必要があります。

3 番目のステップでは、「カウンターパーティアクセスグループ」を入力する必要があります。ディレクトリ「カウンターパーティアクセスグループ」がこれを担当します。図を参照してください。 5.

この例では、バイヤー、サプライヤー、その他です。図を参照してください。 6.

この段階では、「カウンターパーティ」ディレクトリの各要素にアクセスグループを割り当てる必要があります。図を参照してください。 7。

取引相手のアクセスグループは「その他」タブで割り当てられます。私は通常、補助的な標準処理を使用してデータをグループに割り当てます。「ディレクトリとドキュメントのグループ処理」では、この詳細に対して希望のグループを一括設定できます。

この段階は最高潮の段階です。この段階では、「取引先アクセスグループ」への「ユーザーグループ」のアクセスが設定されます。これは、「レコードレベルでのアクセス権の設定」処理を使用して設定されます。図を参照してください。 8.

ユーザーグループとカウンターパーティアクセスグループの関係は赤色で強調表示されます。「購買管理者」グループと「販売管理者」グループの場合、関係はまったく同じ方法で構成されます。たとえば、「供給者」のみ、または「購入者」のみなど、アクセスオブジェクトのみがアクセス権を持つオブジェクトとして指定されます。「リスト内の表示」などのフラグは、「アクセスオブジェクト」の権限です。名前からして、これらの権利の機能は明らかだと思います。

上記の操作を行うと、「Counterparty」ディレクトリへのアクセスが制限されるようになります。

残りのディレクトリも同様に構成されます。

重要：

制限付きアクセスは「完全な権利」ロールには適用されません。

ユーザー役割のセットには「ユーザー」役割が含まれている必要があります。

独自のロールがある場合は、「取引相手」ディレクトリに関連する「ユーザー」ロールと同様に、テンプレートと制限を自分のロールに挿入する必要があります (取引相手ディレクトリをクリックして、ユーザーロールのコードを参照してください)。

ロールは、特定のユーザーがこのオブジェクトに対してどのオブジェクトとどのようなアクションを実行できるかを決定するメタデータオブジェクトです。各ロールには権限が含まれており、データベース管理者が設定した権限に応じてアクセス制限が発生します。テクノロジープラットフォームは、基本とインタラクティブの 2 種類の権利を提供します。基本とは、読み取り、変更、追加、および削除の権限を意味します。対話型のものは、対話型削除、対話型追加などのフォームで編集や削除などの操作を行う場合にのみ実行されます。

このようにして、特定のディレクトリ、ドキュメント、その他のメタデータオブジェクト、およびその全体へのアクセスをきっぱり有効にすることができます。アクセスを与えることも、奪うこともできます。少しも与えられないでしょう。しかし、たとえば、巨大なディレクトリがあり、各ユーザーがそのディレクトリ内の特定の要素のみを参照する必要がある場合、状況がよく発生します。つまり、特定の条件に従って、オブジェクト要素の選択が発生する必要があります。そして、1C 8.1 テクノロジープラットフォームのバージョンから、RLS (レコードレベルセキュリティ) と呼ばれる、レコードレベルでデータへのアクセスを制限するための非常に強力なメカニズムが登場しました。制限は、満たされた場合にアクセスを許可するかどうかを決定する一連の特定の条件です。

動的 RLS システムを使用する場合のアクセス制限は、基本操作 (読み取り、変更、追加、および削除) に適用されます。他のすべての操作には条件が 1 つしかないのに対し、読み取り操作には複数のレコードレベルの制約を適用できるという重要な機能があります。このメカニズムを使用すると、特定のレコードだけでなく、レコードの特定のフィールドにも制限を課すことができます。どの時点でフィールドや特殊フィールドを指定する必要があるか<Прочие поля>.

RLS の構文と言語

データ制約言語はクエリ言語にすぎませんが、非常に必要なものが取り除かれています。条件が TRUE と評価された場合は、現在のユーザーにデータへのアクセスが許可され、FALSE と評価された場合は拒否されます。本格的なクエリ言語との主な違いは何ですか?

RLS クエリには常に 1 つのデータテーブルのみが存在し、それが実際に条件に使用されます。
FROM および WHERE 構造のみが使用されます。
このような状況では、機能オプションとセッションパラメータをクエリパラメータとして指定できます。
仮想テーブルの使用は許可されません。
テンプレートを使用して制限を作成することが可能
TOTAL 演算子と IN HIERARCHY 演算子は適用できません。

制限を作成する方法を検討します。たとえば図の場合。 1 は最も単純な制限を示しています。これは、ユーザーには「Sibirskaya Korona LLC」という特定の名前を持つ取引相手が 1 つだけ表示されるという事実にあります。特定のフィールドでフィルタリングできます。たとえば、親フォルダー「従業員」にある請負業者のみをユーザーに表示したいとします。

制限テキストは手動で入力することも、通常のクエリビルダーを使用して入力することもできます。この場合のクエリデザイナーも完全ではありませんが、RLS に対する制限が与えられます。任意の & パラメータを制約リクエストに渡すこともできます。

制限の仕組み

RLS を使用すると、ユーザーに十分な権限がないことを示すエラーが表示される場合があります。これは、制限の運用方法が原因である可能性があります。

全て。つまり、制限を課すプロセスでは、必要なすべてのデータベースデータに対して操作が実行されます。ただし、データの読み取りや変更を行う場合、一部のレコードの制限が満たされていない場合、アクセス権違反により緊急障害が発生します。
許可された。制限を課した結果、条件を満たすレコードのみを読み取る運用方法。この場合、緊急障害は発生しません。要件を満たさないオブジェクトは欠落しているとみなされます。

ALLOWED メソッドは動的リストを生成するときによく使用されます。そうでないと、権利侵害に関するエラーが常に表示されます。 ALL メソッドは、組み込み言語およびクエリ関数によってオブジェクトを取得する場合に使用されます。実際、これらのメソッドはどこにインストールされているのでしょうか? デフォルトは「すべて」です。

RLS でのテンプレートの使用

制限をより便利に使用できるように、1C Enterprise システムではテンプレートの使用が提供されています。つまり、同じ制約を使用する場合、または一部のパラメーターのみが異なることがわかっている場合は、独自のテンプレートを作成します。したがって、通常、繰り返し制約コードをプロシージャとして設計できます。テンプレートには名前とテキストがあります。テキストには制限のプログラムコードが含まれており、プロシージャと同様にパラメータを使用でき、パラメータはプレフィックス # で強調表示されます。

1C: 組み込みテンプレートを使用した Accounting 8.2 構成の例を考えてみましょう。 ACCOUNTANT ロールを開いて、「制約テンプレート」タブに移動しましょう。ここで使用されるテンプレートは BasicCondition で、次のコンテンツを読み取ります。

#Parameter(1)=UserAccessRightSettings.AccessObject が表示されます。これは、送信されるデータに応じて変化するパラメーターそのものです。さらに、制限を導入したい場合は、次のようなテンプレートを使用します。

つまり、代わりに

#Parameter(1)=UserAccessRightSettings.AccessObject

テンプレートテキストには次のようになります

組織=UserAccessRightSettings.AccessObject.

または、より単純なテンプレート上で。テンプレート #MyLimitations の名前は次のとおりです。

WHERE #Parameter(1) = &CurrentUser

パラメータを #MyLimitations(“Executor”) テンプレートに渡すと、次の結果が得られます。

WHERE Executor= &CurrentUser。

結果

レコードレベルでデータへのアクセスを制限するメカニズムは非常に強力ですが、この「荒野」では簡単に迷ってしまう可能性があるため、その設定には多くの経験が必要です。これにより、データを部分的に区切ることができます。一方で、さまざまな条件を追加すると、わずかではありますがシステムのパフォーマンスが低下します。 1C プラットフォームでは、ユーザーのリクエストに制限の形で追加のリクエストが追加されます。他のすべての点で、これは開発者にとって素晴らしいことです。

1C:Enterprise プラットフォームの 8 番目のバージョン (現在は 8.3) には、「7」に関連して多くの変更が加えられており、その中で、レコードレベルでアクセス権を制限するメカニズムは特に注目に値します。 RLS を使用せずにロールのみを使用することも理論的には可能ですが、RLS を使用すると、より詳細なアクセス設定を実現できます。ただし、この仕組みを適切に動作させるには、その本質を明確に理解し、1C での十分な開発経験が必要です。

RLSとは何ですか？

この機能の本質は、特定のユーザーまたはユーザーのグループがデータベーステーブルのテーブルまたはフィールドにアクセスすることを開発者が防止できることです。通常、制限は、1C ユーザーが機密の機密情報を表示および編集できないようにするために使用されます。たとえば、グループに含まれる会社の従業員を、その組織のドキュメントのみの表示に制限します。また、レコードレベルでアクセス権を制限するメカニズムを使用して、インターフェイスから不要な情報を削除できます。

RLS 制限のクエリを作成できるようにするには、ロールを作成するか、既存のロールを取得する必要があります。 1C 8.3 での RLS のセットアップは、次のユーザーアクションに使用できます。

追加;
読む;
消去;
変化。

アクセスをカスタマイズするための幅広い可能性に加えて、RLS には欠点もあります。

リクエストは構文ルールを考慮して組み込み言語で作成する必要があるため、開発者の資格要件。
状況を迅速にデバッグする能力の欠如。
ロジックを記述する可能性が限られている: 複雑すぎる条件は依然として文書や参考書のモジュールに記述する必要があります。
データベースのクライアントサーバーバージョンでは、クエリに含まれるテーブルが暗黙的に増大する可能性があります。さらに、このプロセスを追跡することは非常に困難です。
リソース要件。 RLS 制限は、クライアントマシンとサーバーで大量の電力を消費します。
ほとんどのドキュメントは無料で入手できます。

1C RLS の設定後に発生する可能性のあるもう 1 つの問題は、レポートです。実際、開発者は考えられる RLS 制限を用意し、許可されたデータのみを表示するような方法でレポートを作成しています。ユーザーが異なる RLS 制限を設定している場合、同じパラメータのレポート内のデータが異なる場合があります。これにより疑問が生じる可能性があるため、RLS でレポートを設計したりクエリを作成したりするときは、これらの状況を考慮する必要があります。

RLS 制約を作成する

RLS 制限を追加するには、目的のロールを見つけてダブルクリックして開く必要があります。

開いたウィンドウには、「権利」と「制限テンプレート」の 2 つのタブが含まれています。特定のアクションに特定の制限を課すには、それを選択し、右下の部分にある緑色のプラスをクリックする必要があります。 1C に組み込まれている言語で 1C RLS 制限を設定できる行が表示されます。

1C 構文を知っている場合 (手の甲など)、「アクセス制限」フィールドに直接書き込むことができます。 1C 開発者は、クエリコンストラクターを開く機能を提供しています。これは、作成できる制限を示し、役立ちます。これを開くには、3 つの点のボタン (選択) または F4 をクリックする必要があります。すると、「クエリデザイナー...」ボタンのあるウィンドウが表示されます。

表示されるウィンドウでは、このディレクトリだけでなく、他のシステムオブジェクトに対しても制限を設定できます。これを行うには、「テーブルとフィールド」タブにテーブルとフィールドを追加する必要があります。「Nomenclature」ディレクトリのフィールドに制限を登録し、「OK」をクリックします。変数の名前には注意してください。RLS パラメータはユーザーセッションの開始時に設定され、メタデータオブジェクトに含まれている必要があります。

「制約テンプレート」タブでは、同じ RLS 設定を 1C 8.3 にコピーするときに必要なクエリを指定します。テンプレートを追加した後、アクセス権設定でその名前を使用できます。

複数のロールに同時に制限を追加することもできます。これを行うには、構成ツリーで「役割」セクションを右クリックし、「すべての役割」を選択する必要があります。

結論として、この記事は 1C 開発コンサルタントを対象としており、主に 1C:Enterprise 開発の経験がある人に役立つことを指摘しておきます。一見単純そうに見えますが、セマンティクスの知識と、権利を正しく分配するための自社または顧客の組織のビジネスプロセスの構造を理解するには、一定レベルの知識と経験が必要です。

1C には、アクセス権のシステムが組み込まれています (このシステムは 1C ロールと呼ばれます)。このシステムは静的です。管理者が 1C 権限を割り当てたので、静的になります。

さらに、動的アクセス権システム (RLS 1C と呼ばれます) もあります。その中で、ユーザーが作業している間に、指定されたパラメーターに基づいて 1C 権限が動的に計算されます。

さまざまなプログラムで最も一般的なセキュリティ設定の 1 つは、ユーザーグループに対する一連の読み取り/書き込み権限と、グループへのユーザーの追加または除外です。たとえば、同様のシステムが Windows AD (Active Directory) で使用されています。

このような 1C のセキュリティシステムは 1C ロールと呼ばれます。 1C ロールは、設定の [全般/ロール] ブランチにあります。 1C ロールは、1C 権限が割り当てられるグループとして機能します。ユーザーはこのグループに含まれるか、このグループから除外されます。

1C 役割の名前をダブルクリックすると、1C 役割の権利エディターが開きます。左側には 1C オブジェクトのリストがあります。どれかを選択すると、右側にアクセス権のオプションが表示されます (少なくとも、読み取り、追加、変更、削除)。

最上位のブランチ (現在の構成の名前) については、1C 管理者権限とさまざまなオプションを起動するためのアクセスが確立されます。

すべての 1C 権利は 2 つのグループに分けられます。「単純な」権利と、同じ権利に「インタラクティブ」が追加されたものです。それはどういう意味ですか？

ユーザーがフォーム (処理など) を開いてボタンを押すと、組み込み 1C 言語のプログラムがドキュメントの削除などの特定のアクションを実行します。「単純に」1C 権限は、これらのアクション (プログラムで実行される) を許可する責任があります。

ユーザーがジャーナルを開き、キーボードを単独で使用して何かを開始する場合 (新しい文書の入力など)、これらは「対話型」1C 権限です。

ユーザーは複数のロールにアクセスできる場合があり、その場合、権限は累積されます。

ロールを使用してアクセス権を設定できる可能性の内訳 - 1C オブジェクト。つまり、ディレクトリへのアクセスを有効にすることも、無効にすることもできます。ちょっとオンにすることはできません。

この目的のために、1C RLS と呼ばれる 1C 役割システムの拡張機能があります。これは、アクセスを部分的に制限できる動的アクセス権システムです。たとえば、ユーザーには特定の倉庫および組織のドキュメントのみが表示され、残りは表示されません。

気をつけて！紛らわしい RLS 1C スキームを使用する場合、さまざまなユーザーが異なるユーザーから生成された同じレポートを調整しようとすると、疑問が生じる可能性があります。

あなたは特定のディレクトリ (組織など) と特定の権利 (読み取りなど) を取得します。 1C ロールの読み取りを許可します。 [データアクセス制限] パネルでクエリテキストを設定します。クエリテキストは、設定に応じて TRUE または FALSE を返します。設定は通常、情報レジスタに保存されます (たとえば、構成情報レジスタのアカウンティングおよびユーザーアクセス権の設定)。

このクエリは、ディレクトリエントリごとに (読み取りを実装しようとするときに) 動的に実行されます。したがって、セキュリティクエリが TRUE を返したレコードはユーザーに表示されますが、残りのレコードは表示されません。
RLS 1C 制限の対象となる 1C 権利は、灰色で強調表示されます。