Skip to main content

This is documentation for Caché & Ensemble. See the InterSystems IRIS version of this content.Opens in a new tab

For information on migrating to InterSystems IRISOpens in a new tab, see Why Migrate to InterSystems IRIS?

SQL セキュリティ

Caché は、システム・レベルのセキュリティと、SQL 関連セキュリティ機能の追加セットの両方を備えています。Caché の SQL セキュリティは、Caché のデータベース・レベル保護を超えるレベルのセキュリティ機能を提供します。 SQL セキュリティとシステム・レベルのセキュリティの主な違いは以下のとおりです。

  • SQL 保護では、システム・レベルのセキュリティに比べ、詳細な保護が可能です。テーブル、ビュー、およびストアド・プロシージャに対する特権を定義できます。

  • SQL 特権はユーザとロールに与えることができます。 システム・レベルの特権はロールに対してのみ与えられます。

  • SQL 特権を保持することにより、SQL アクションの実行に必要なすべての関連システム特権が暗黙的に与えられます (反対に、システム・レベルの特権はテーブル・レベルの特権を意味しません)。特権の種類については、“SQL 特権とシステム特権” のセクションで説明します。

SQL 特権とシステム特権

SQL 固有のメカニズムを使用してテーブルやその他の SQL エンティティを操作するには、適切な SQL 特権が必要です。システム・レベルの特権では十分ではありません。

Note:

SQL セキュリティとシステム・レベルのセキュリティで、ロールを共有できます。つまり、システム・レベル特権と SQL 特権の両方を 1 つのロールに備えることができます。

Windows マシンの Caché インスタンスについて、以下の例を考えてみましょう。

  • USER ネームスペースに User.MyPerson というクラスがあります。このクラスは SQL に SQLUser.MyPerson テーブルとして投影されます。

  • Test という名前のユーザがいます。このユーザはどのロールにも属しません (したがって、システム特権を何も持ちません) が、SQLUser.MyPerson テーブルに対するすべての特権を持ちます (その他の SQL 特権は持ちません)。

  • Test2 という 2 人目のユーザがいます。このユーザは、%DB_USER ロール (このため、USER データベースに対するデータの読み書きが可能)、および %SQL ロール (このため、%Service_Bindings サービスを通じた SQL アクセスが可能) を持ちます。また、カスタム・ロールを通じて、コンソールと %Development を使用するための特権を持ちます。

ユーザ Test が SQL 固有の任意のメカニズム (ODBC を使用するものなど) を通じて SQLUser.MyPerson テーブル内のデータに対して読み取りまたは書き込みを実行すると、この操作は成功します。これは、接続を確立するために、Caché がユーザ Test を %DB_USER および %SQL ロールのメンバにするためです。これは、%System/%Login/Login イベントなど、接続により生成される監査イベントで確認できます (ユーザ Test が、ターミナルまたは管理ポータルを使用しようとすると失敗します。これは、ユーザ Test がこれらの操作に必要な特権を持たないためです)。

ユーザ Test2 が SQL 固有の任意のメカニズム (ODBC を使用するものなど) を通じて SQLUser.MyPerson テーブル内のデータに対して読み取りまたは書き込みを実行すると、この操作は失敗します。これはユーザ Test2 がこのテーブルに対して必要な特権を持たないからです (ユーザ Test2 が、オブジェクト・メカニズムを使用してターミナルで同じデータを表示しようとすると、この操作は成功します。これはユーザ Test2 が、この種類の接続に必要な特権を持っているためです)。

SQL サービス

%Service_SQL:Use 特権は、ユーザが Caché オブジェクトまたは SQL クライアントを使用して接続し、SQL を使用する機能を制御します。ユーザが Caché に接続しようとすると、該当のネームスペースに対するいずれかの SQL レベルの特権をそのユーザが保持しているかどうかが、サーバで判断されます。ユーザがこのような特権を 1 つ以上持っている場合は、自動的に 2 つのロールが追加されます。1 つは、%Service_SQL:Use 特権を持つ %SQL ロールです。もう 1 つは、ネームスペースの既定のデータベースに対する暗黙のデータベース・ロールです。 このようにロールが自動的に追加されることで、SQL ユーザがデータベース特権を保持している必要はなくなります。これは、それらの特権がサーバから自動的に追加されるからです。

接続の際に実行されるこのロールの追加処理を除き、SQL 文を処理する過程で自動的にロールのエスカレーションが発生することはありません。 SQL 文を実行するユーザは、所定のシステム・レベルの特権を保持している必要があります。

%Service_SQL:Use 特権が必要となるのは、クライアント/サーバ構成で SQL を使用する場合のみです。 例えば、サーバ側の埋め込み SQL 要求を使用するアプリケーションを実行するユーザには、この許可が要求されません。

%CREATE_TABLE コマンドは各ネームスペースに固有のものです。つまり、あるネームスペースについてこの特権を与えられたユーザは、そのネームスペースでのみテーブルを新規に作成できます。

CREATE USER

SQL の CREATE USER 文を使用して、Caché ユーザを作成できます。 新規に作成したユーザにはロールがありません。

状況によっては、ユーザ名を暗黙的に SQL スキーマ名として使用できます。 SQL 識別子では使用できない文字がユーザ名に使用されていると、この処理によって問題が発生します。 例えば、複数ドメイン構成ではユーザ名に “@” 文字が使用されます。

Caché では、区切り識別子の構成パラメータの設定に応じて、この状況が区別して扱われます。

  • 区切り識別子が使用できるようになっていると、特別な処理は発生しません。

  • 区切り識別子が使用できないようになっていると、スキーマ名に使用できない文字がユーザ名から削除されてスキーマ名が形成されます。 例えば、“documentation@intersystems.com” というユーザ名から “documentationintersystemscom” というスキーマ名が生成されます。

これによって、SQL CURRENT_USER 関数から返される値が変化することはありません。 必ず $USERNAME と同じ値が返されます。

変更内容の反映

SQL セキュリティ値の設定が有効になるのは、そのユーザが次回接続したときです。ユーザの現在のセッションの間は有効になりません。

テーブルでの作業で要求される特権

次の文を使用して SQL でユーザを作成することは

CREATE USER <username> IDENTIFY BY <password>

管理ポータルを使用して同じ操作を実行することと同じです。ある特定のテーブルをユーザが操作できるようにするには、管理ポータルを使用するなどして、このテーブルに対する特権を明示的に与える必要があります。

特定のテーブルで作業するために必要な最低限の特権は、関連のテーブルに対する SELECT などの任意の SQL 特権です。SELECT コマンドを実行する権限をユーザが持っている場合は、テーブルの読み取りと使用が可能ですが、書き込みはできません。読み取り、使用、および書き込みの特権は、INSERTUPDATE、および DELETE で得られます。

FeedbackOpens in a new tab