ユーザー アカウントは、データベースへの接続を識別します。ユーザーがアクセスできる内容は、ユーザー アカウントに対して付与または拒否されるデータベースおよびデータセットの権限によって決定されます。ユーザー アカウントは、権限の管理を簡素化するために、実行する必要のあるタスクに基づいてグループ化できます。
ユーザー アカウント
ユーザー アカウントは、データベースに接続するユーザーまたはクライアント アプリケーションを識別するための一意な名前とパスワードです。ArcGIS では、ユーザー アカウントはどのユーザーがどのデータを所有しているかを決定します。また、ユーザー アカウントは、ユーザーまたはクライアント アプリケーションのデータベースまたはジオデータベースとそのデータセットへのアクセスの種類を制御できるようにします。
SQL Server では、ログインおよびデータベース ユーザー アカウントを作成するか、ネットワークまたはオペレーティング システムのログインをデータベース ユーザー アカウントにマップできます。
ArcGIS の外部では特殊文字を含むユーザー名を作成できますが、これらのユーザー名を使用する際は、常に区切り文字が必要となります。ArcGIS は、SQL Server に渡すときに自動的に区切り文字を追加します。ログインする際に指定する必要はありません。たとえば、ユーザー名が map.user の場合、ArcGIS から SQL Server にログインするときに、「"map.user"」ではなく、「map.user」と入力します。通常の識別子と区切り文字が追加された識別子の詳細については、SQL Server のドキュメントをご参照ください。
データの所有権
ArcGIS では、ジオデータベースまたはデータベース内にテーブル、フィーチャクラス、ビューを作成したユーザーは、それらのデータセットを所有します。たとえば、ジオデータベース管理者はジオデータベースを作成し、その際にデータベースに作成されるジオデータベース システム テーブルの所有者になります。同様に、フィーチャクラスを作成するユーザーは、そのフィーチャクラスを所有します。
ジオデータベースに接続してデータセットを作成する場合は、ジオデータベースへの接続に使用するユーザー名がデータを所有するユーザーです。
データを所有するユーザーは、データベース内にユーザー名と同じ名前のスキーマを持つ必要があります。
たとえば、契約社員である Boris と Basil にジオデータベースでのデータセットの作成が許可されているとします。Boris と Basil は同じコンピューターを使用しています。Boris と Basil が ArcGIS でのジオデータベースへの接続に Basil のアカウントを使用した場合、Boris と Basil が作成したデータセットはすべて Basil によって所有され、Basil のスキーマに格納されてしまいます。
Boris が作成したデータを Boris のスキーマに格納するには、データを作成する前にデータベース接続プロパティを変更して、Boris のユーザー名でデータベースに接続する必要があります。
データを所有しているユーザーのアカウントはデータベースから削除できないので、データの所有者を知ることは重要です。また、データセットに対する他のユーザーのアクセス レベルを制御するのは、そのデータセットを作成したユーザーです。
ユーザー アクセス
データベースは、接続を行うユーザー アカウントを検証できなければなりません。つまり、データベース管理者はユーザーをデータベースに追加する必要があります。データベースは、ユーザーのリストを確認して、ユーザーに接続が許可されていることを確認します。このプロセスは認証と呼ばれます。
SQL Server データベースで使用される認証方式には、オペレーティング システム認証とデータベース認証の 2 種類があります。
オペレーティング システム (OS) 認証では、ユーザーはコンピューターにログインし、認証のための情報はユーザーのコンピューターのオペレーティング システムからデータベースに提供されます。接続しているユーザーはコンピューターへのログインだけが必要であり、データベースに個別にログインする必要はありません。データベース管理者は、既存のアカウントをデータベースに追加して、ユーザーの既存のアカウントを認識するようにデータベースを設定する必要があります。
データベース認証を使用する場合、ユーザーはサーバーにログインした後、データベースに個別にログインする必要があります。
データベース管理者は、ユーザーを追加した後、データベースで実行可能な操作と実行不可能な操作を決定するために権限を割り当てる必要があります。データベースは、認証されたユーザーがデータベースへのアクセスや変更を試みたときに、これらの権限を確認します。このプロセスは認証と呼ばれます。ArcGIS では、データ所有者は自分のデータに対する権限を他のユーザーやグループに付与することもできます。
ユーザーに割り当てられる権限の種類は、ユーザーが実行する必要がある作業の種類に依存します。データベースに接続し、特定のデータを表示するだけでよいユーザーもいれば、 データセットを新規作成する必要があるユーザーもいます。次のセクションでは、権限の管理を簡素化するために、ユーザー アカウントをグループ化する方法について説明します。
グループまたはロール
ほとんどのデータベース管理システムには、データベース管理者がユーザーに必要なデータ アクセスに基づいてユーザーをグループ化し、そのグループに権限を割り当てるための方法が用意されています。これにより、ユーザーごとに権限を変更する手間が省け、ユーザー数が多い場合に、膨大な数の権限を簡単に管理できるようになります。この場合は、グループを利用して、ユーザーに共通の役割に基づいて権限を割り当てることができます (データベース管理システムによっては、グループをロール、タイプ、特権とも呼びます)。
ユーザーの一般的なカテゴリ (グループ) は、データを表示するユーザー、データを編集するユーザー、そしてデータを作成するユーザーです。
エンタープライズ ジオデータベースでは、ほとんどの場合、グループへの権限の割り当てによって、ユーザー レベルでの権限の割り当てが設定できなくなることはありません。たとえば、(ジオデータベース管理者を含む) データ作成者のグループにはデータベースにデータを作成するのに必要な最低限の権限を割り当てておき、ジオデータベース管理者ユーザーにのみ追加の権限を割り当てることができます。権限の優先順位はデータベース管理システムごとに異なるため、ロールおよび個別のユーザーの権限の振舞いの詳細については、データベース管理のドキュメントをご参照ください。
また、ほとんどのデータベース管理システムでは、複数のグループがあらかじめ定義されています。そのうちの 1 つは、PUBLIC ロールです。
PUBLIC グループまたはロールは、基本的にデータベースに接続するユーザーに相当するので、PUBLIC に割り当てられた権限はすべて、データベースに接続するユーザー全員に適用されます。すべてのユーザーに特定の権限が必要な場合があります。たとえば、SQL Server または DB2 のデータベースに接続するには、ユーザーは CONNECT 権限を付与されている必要があります。すべてのユーザーは接続するためにこの権限が必要なため、SQL Server および DB2 では、デフォルトでこの権限が PUBLIC に付与されています。
データベースの作成時にデフォルトで PUBLIC に高度な権限が割り当てられることがありますが、 セキュリティ上の理由から、PUBLIC への権限の割り当ては必要な場合だけにしてください。
事前に定義されているその他のグループについては、データベース管理システムのドキュメントをご参照ください。
ユーザーのグループ化のヒント
次に、データベース管理システムでユーザーをグループ化するためのヒントをいくつか紹介します。
- システムとオブジェクトの権限ごとに異なるグループ (ロール) を作成します。 これにより、データベース管理者がデータベース権限をシステム グループに付与することで管理し、データの所有者が自分のデータセットの権限をオブジェクト グループに付与するという役割分担が可能になります。
- グループ (ロール) の種類を反映したわかりやすい命名規則を選択します。 たとえば、すべての境界データを編集できるグループには、LANDBASE_EDITORS という名前を付けることができます。
- ジオデータベース管理者には権限を直接割り当て、その他のユーザーの権限はグループ (ロール) に割り当てます。 ジオデータベース管理者は特別な存在です。ほとんどの場合、ジオデータベースの管理者は 1 人だけであり、大きな論理グループには属しません。経験豊富なデータベース管理者は、そうしたアプリケーション管理者アカウントに直接権限を割り当てることを適切な設計であると考えます。対照的に、管理者でないユーザーのアカウントには、担当する業務、プロジェクトでの役割、その他組織内での論理的な分類を表すグループから権限が適用されます。
- 管理者でないユーザー アカウントへの直接的な権限の割り当てとロールの混在を避けます。 管理者でないユーザー アカウントにロールからの権限と直接割り当てられた権限の両方が適用されると、適切に計画されたはずのセキュリティ モデルが管理不能となってしまい、正常な状態に戻すのに膨大な時間と労力が必要になります。データへのアクセスを許可する際にデータの所有者が従うポリシーを設定してください。
まれに、管理者でないユーザー アカウントが特異なセキュリティ要件を持つ場合があります。この場合は、ロール ベースのセキュリティ モデルが複雑になるのを避けるため、一部の特権を直接割り当てることを検討してください。これらのケースは文書化し、例外として扱ってください。