ユーザーアカウントの作成はシステム管理者の仕事の一部でしかありません。ユーザーリソースの管理もまた欠かせない重要事項です。従って、次の 3 点についてよく検討する必要があります。
共有データにアクセスできる人
ユーザーがこのデータにアクセスする場所
リソースの悪用を防ぐために施行するバリア
次のセクションではこれらのトピックについて簡単に概説します。
特定のアプリケーション、ファイルまたはディレクトリへのユーザーアクセスは、 そのアプリケーション、ファイル、ディレクトリに適用されているパーミッションによって決定されます。
また、異なるパーミッションを異なるユーザークラスにそれぞれ適用すると役に立ちます。 例えば、共有のテンポラリストレージは、あるユーザーのファイルを他のユーザーが誤って (または故意に)削除しないようにしておきながら、ファイルの所有者にはフルアクセスを許可する必要があります。
別の例として、ユーザーのホームディレクトリに割り当てられたアクセスがあります。 ホームディレクトリでファイルを作成または閲覧できるのはそのディレクトリの所有者だけでなければなりません。 他のユーザーはすべてのアクセスを拒否されます(ユーザーが希望しない限り)。 これによりユーザーのプライバシーを保護し、個人ファイルの悪用の可能性を防ぎます。
しかしながら、複数のユーザーが1台のマシンにある同じリソースにアクセスする必要があるかもしれない 状況が多々あります。このような場合、共有グループの作成は十分に注意する必要があるでしょう。
「はじめに」で述べたように、グループは論理的な構造になっていて、 特定の目的のためにユーザーアカウントをクラスタ化することができます。
組織内のユーザーを管理するときは、特定の部署がアクセスすべきデータ、 他のユーザーはアクセスを拒否されるデータ、全ユーザーで共有すべきデータを 確認しておくとよいでしょう。これを確定することにより、 共有データに対する適切なパーミッションの他に、適切なグループ構造を作成するのに役立ちます。
例えば、売掛金を担当する部署は支払いを滞納しているアカウントの一覧を管理しなければならないとします。 また、集金を担当する部署とその一覧を共有する必要があります。 売掛金担当と集金担当のスタッフをaccountsという グループのメンバーにすると、この情報は共有ディレクトリに置かれ、 グループの読み込みと書き込みのパーミッションを持つことになります (accountsグループが所有)。
共有グループを作成する上で、システム管理者にとって難題となるが次の事項です。
作成するグループ
特定グループを構成するユーザー
このような共有リソースに持たせるパーミッションのタイプ
常識的な手段で考えていくとやりやすいでしょう。 ある可能性として、グループを作成する際に組織の構造をそのまま反映させます。 例えば、ファイナンスの部署があれば、finance というグループを作り、ファイナンスのスタッフは全員このグループに入れます。 財政情報を会社全体で共有するには機密性の点で問題があるが、 上級職の者にとっては極めて重要となる場合には、 financeグループに上級職全員を追加して ファイナンスの部署が利用するディレクトリやデータにアクセスする 上級職のグループレベルパーミッションを許可します。
また、ユーザーにパーミッションを許可する場合に注意しすぎるということはありません。十分に注意を重ねることで、機密情報が漏洩する可能性が少なくなります。
このように組織のグループ構造を作成していく方法により、 組織内共有データへのアクセスの必要性に安全且つ効果的に適合できます。
ユーザー間でデータを共有するとき、セントラルサーバを使用するのが一般的で、このセントラルサーバはネットワーク上の他のマシンに特定ディレクトリを使えるようにします。この方法により、データが同じ場所に保存され、複数のマシン間でデータを同期する必要がなくなります。
この方法を実施する前に、まず中央で保存されているデータへアクセスするシステムを決めます。これを行うときに、システムで使用されているオペレーティングシステムを書き留めておきます。ストレージサーバーは組織内で使用している各オペレーティングシステムに対してそのサーバ内のデータを提供できなければならないため、この情報はこの方法を実施するシステム管理者の能力に重要な役割を果たします。
ネットワーク上の複数のコンピュータ間でデータが共有されると、 ファイル所有権に関する競合の可能性が出てきます。
データが中央で保存され、ネットワーク経由で複数のコンピュータがアクセスできれば利点が生まれます。 しかし、この複数のコンピュータがそれぞれにローカルに保持しているユーザーアカウントの一覧が あると仮定してみてください。 各システムにあるユーザーの一覧が中央サーバーのそれと合致しない場合どうなるでしょうか。 最悪の場合、各システムにあるユーザーの一覧がお互いにまったく食い違っている場合はどうでしょうか。
これは各システムでユーザーとアクセスパーミッションがどのように設定されているかに 大きく依存します。しかし、場合によってはあるシステムのユーザーAが 実際には別のシステムのユーザーBとなっている可能性もあります。 ユーザーAがあるシステムからのアクセスを許可されているデータが 別のシステムからユーザーBによって読み込まれてしまう恐れがあるため、 こうしたシステム間でデータを共有する場合に実質的な問題となります。
こうした理由から、多くの組織が何らかの形でセントラルユーザーデータベースを利用しています。 これにより、別々のシステムのそれぞれのユーザーリストが重複しないようになります。
もうひとつの問題は、中央で保存されるホームディレクトリを持たせるかどうかです。
ネットワーク接続のサーバーにホームディレクトリを統合する主たる利点は、ユーザーがネットワーク上のどのマシンにログインしても自分のホームディレクトリにあるファイルにアクセスできるということです。
一方、ネットワークがダウンしてしまうと、組織全体のユーザーがファイルにアクセスできなくなってしまうという欠点があります。ある環境ではホームディレクトリの統合化が適さないこともあります(ノートブック型PCの使用が普及している企業など)。その組織にとって適すると判断できるなら、ホームディレクトリ統合化の採用によってシステム管理者の負担が軽くなります。