章 6章. ユーザーアカウントとリソースアクセスの管理
ユーザーアカウントとグループの管理は、組織内のシステム管理に欠かせない重要事項です。しかし、これを効果的に行うには、優秀なシステム管理者としてはまずユーザーアカウント及びグループとは何か、そしてこれらの役割について理解する必要があります。
ユーザーアカウントの主な役割とは、コンピュータシステムで各個人の身元を証明することです。 次に重要な役割は、各個人ごとにリソースやアクセス権の調整ができるようにすることです。
リソースには、ファイル、ディレクトリ、デバイスなどが含まれます。 こうしたリソースへのアクセスの管理は、 システム管理者にとって日常的な作業の大きな部分を占めます。 リソースへのアクセスはグループで管理されるのが一般的です。 グループとは論理的な構成で、共通の目的でユーザーアカウントをクラスタ化するために使用します。 例えば、組織内に複数のシステム管理者がいれば、 ひとつのシステム管理者グループに全員をまとめることができます。 次に、このグループに重要なシステムリソースへのアクセス許可を与えます。 このように、グループはリソースとアクセスの管理に強力なツールとなります。
次のセクションではユーザーアカウントとグループについて詳細に説明していきます。
6.1. ユーザーアカウントを管理する
前に述べたように、ユーザーアカウントは個人をシステムに対して識別し認証する方法です。 ユーザーアカウントはいくつかの異なる構成要素からなります。最初に、ユーザー名があり、 次にパスワード、アクセス制御情報と続きます。
次のセクションではこれらの構成要素を詳細に見ていきます。
6.1.1. ユーザー名
システムから見ると、ユーザー名とは"あなたは誰ですか?"という質問に対する答えになります。 このように、ユーザー名はひとつの主要な必要条件を持ち、 それは固有のものでなければなりません。つまり、各ユーザーはそのシステム上で その他すべてのユーザーとは異なるユーザー名を持つ必要があります。
この必要条件のため、ユーザー名をどのように作成するかを —前もって—決定することは重要なことになります。 さもないと、新しいユーザーがアカウントを要請するたびに対応せざる得ない状況になり得ます。
ユーザーアカウントに必要とされるのが命名規則です。
6.1.1.1. 命名規則
ユーザー名に命名規則を作成することで、多くの問題を回避することができます。 その度ごとにユーザー名を作成する(合理的な名前を見つけるのがだんだん難しくなってくる) 代わりに、事前に一定の作業を行っておいて命名規則が次々と必要になるユーザーアカウントすべてに 使用されるようにしておきます。命名規則はシンプルなものでも、 説明自体だけでも文書化するのに数ページ必要とするものでも構いません。
独自の命名規則の明確な性質は、いくつかの要素を考慮する必要があります。
組織の規模
組織の構成
組織の性質
命名規則がサポートする必要があるユーザー数を示すため、組織の規模は重要な要素です。 例えば、規模がかなり小さい組織なら各自が自分のファーストネームを使うことができるかもしれません。 規模が大きくなると、この命名規則では機能しなくなってきます。
組織の構成も最適な命名規則に関連してきます。 明確に定義されている構成の組織なら、命名規則にその構成要素を取り入れるのがよいでしょう。 例えば、組織の部署コードを各ユーザー名の一部に取り入れることができます。
組織の全般的な性質からも命名規則を選択することができます。極秘データを扱う組織なら、ある個人をその名前で識別できてしまうようなつながりを持たせることを避ける命名規則を選ぶことができます。このような組織では、Maggie McOmieのユーザー名をLUH3417とすることができます。
他の組織や会社で使用されている命名規則です。
ファーストネーム(john、paul、george など)
ラストネーム(smith、jones、brown など)
ファーストネームのイニシャルにラストネームを続ける(jsmith、pjones、gbrown など)
ラストネームに部署コードを続ける(smith029、jones454、brown191 など)
 | ヒント |
|---|---|
ユーザー名を形成するのに異なるデータを付け加える命名規則である場合、ユーザー名としては不快であったりおかしなユーザー名になってしまう可能性があることに注意してください。したがって、ユーザー名の生成を自動化している場合であっても、何らかの形で再確認するプロセスがあった方が良いでしょう。 |
ここで説明している命名規則について一般的なことの一つは、命名規則によっては、最終的に同じユーザー名を2人に与えてしまうことが起きる可能性があるということです。これはコリジョン(衝突)と呼ばれます。各ユーザー名が固有でなければならないため、コリジョンに関する問題に対処する必要があります。次のセクションではこれを説明しています。
6.1.1.1.1. コリジョンに対処する
コリジョンは必ず出てきます。どんなに努力してもいずれはコリジョンに対処する必要性が出てきます。 命名規則にはコリジョンをプランに入れておく必要があります。 以下に、いくつかの方法を示します。
重複しているユーザー名に順番を付ける(smith、smith1、smith2、など)
重複しているユーザー名にユーザー固有のデータを付ける(smith、esmith,、eksmith、など)
重複しているユーザー名に組織の情報を付ける(smith、smith029、smith454、など)
いずれの命名規則においてもコリジョンの解決方法を考えておく必要があります。 ただし、組織外の人が個人のユーザー名を正確に見分けるのが難しくなってきます。 従って、ほとんどの命名規則のマイナス面としては、 誤った宛先の電子メールが増える可能性が高くなるということです。
6.1.1.2. 名前変更に対処する
各ユーザー名に基づく命名規則を使用している場合は、いずれは名前変更の作業を行う必要性が必ず出てきます。実際の名前は変わっていなくても、ユーザー名の変更が必要なときがあります。ユーザー名が気に入らないといった理由から、組織内で上級職に就くことになったため準じて"より適切な"ユーザー名を取得したいなどさまざまです。
その理由に関わらず、ユーザー名を変更するときには気をつけなければならいことがあります。
影響をおよぼすすべてのシステムに対して変更を行います。
基本となるユーザー識別は変更せず維持します。
すべてのファイルの所有権とユーザー固有のリソース(必要であれば)を変更します。
電子メール関連事項を処理します。
まず最初に行うべき事項で最も重要なことは、元のユーザー名を使用していたシステムのすべてに対して その新しいユーザー名がユーザー名として伝達されていることを確認することです。 さもないと、ユーザー名に依存するオペレーティングシステム機能はいずれも、 あるシステムでは機能するが他のシステムでは機能しないことがあります。 特定のオペレーティングシステムはユーザー名に基づいたアクセス制御技術を採用しており、 このようなシステムは特にユーザー名の変更から生じる問題に対して脆弱です。
多くのオペレーティングシステムが、ユーザー固有のプロセス処理のほとんどを ユーザー識別番号のような形式で採用しています。ユーザー名の変更に伴う問題を最小限に抑えるには、この識別番号を新と旧のユーザー名間で不変にしておくようにします。これを怠ると、ユーザーが旧ユーザー名では以前に所有していたファイルやリソースに全くアクセスできなくなってしまうという事態が頻繁に発生することになります。
ユーザー識別番号を変更しなければならない場合は、すべてのファイルとユーザー固有のリソースの所有権を変更して新しいユーザー識別に反映させる必要があります。これは、常に見落として何かを忘れたままにしてしまっているような、エラーを起こしやすいプロセスとなることがあります。
電子メールに関連する問題として、おそらく、ユーザー名の変更が非常に 難しいことがひとつあります。 その理由としては、対策を講じない限り、 旧ユーザー名宛ての電子メールは新ユーザー名には配信されないからです。
残念ながら、電子メールにおけるユーザー名変更に関わる影響は複雑です。 基本的には、ユーザー名を変更するということは、 ある人物の正しいユーザー名を知る者がいなくなるということになります。 この変更は組織の全員に通知すればよいわけですから、 それほどの問題となるようには見えないかもしれません。 しかし、この人物に電子メールを送信している外部の人はどうでしょう? こうした人にはどのように通知すれば良いのでしょう? 社内や社外のメーリングリストはどのように対応すればよいでしょう? どのようにしてこれらを更新することができますか?
こうした問題を解決するのは簡単なことではありません。最適な解決策としては、旧ユーザー名に送信された電子メールはすべて自動的に新ユーザー名に転送されるといった電子メールエイリアスを作成することでしょう。こうすれば、そのユーザーは電子メールを送信する人すべてにユーザー名が変更になったことを警告するよう求められます。時が経つにつれ、エイリアスを使って配信されてくるメッセージが 少なくなってきます。それから最終的にこのエイリアスを削除すればよいわけです。
エイリアスを使うということは、あるレベルで、誤った推測(esmithに変更になっているユーザーがいまだにejonesだと思われている)を永存させるのが正しい宛先に電子メールが確実に届くようにする唯一の方法です。
 | 重要 |
|---|---|
電子メールにエイリアスを使用する場合は、旧ユーザー名が再使用される可能性のないよう何らかの必要な手順を必ずとるようにしてください。これを怠り、新規のユーザーに旧ユーザー名が使用されると、電子メールの配信(以前にユーザーだった人及び新規のユーザーどちらか)に混乱が生じる恐れがあります。実際にどのような混乱が発生するのかは、オペレーティングシステムでどのように電子メール配信が施行されるかによりますが、可能性が高いものとして次の 2 つがあります。
|
6.1.2. パスワード
ユーザー名が"あなたは誰ですか?"という質問に答えを返すと、 パスワードがその要求に対する応答になり、必然的に以下のようになります。
"証明してください!"
もう少し改まった言い方をすれば、ユーザー名によって示されるユーザーであるという その人物の確実性を提供する方法がパスワードです。 パスワードベースの認証体系の効果は、そのパスワードの状態に大きく依存します。
パスワードの機密性
パスワードの推測に対する耐性
brute-force attack(総当たり攻撃)に対するパスワードの耐性
こうした問題を適切に対処するパスワードは堅固と言われ、問題に対処できないものは脆弱と言われています。堅固なパスワードは推測されたり、見抜かれたりする可能性が少ないため、こうしたパスワードを作成することは、組織の安全確保にとって重要なことになります。堅固なパスワードを使うよう強制するオプションが 2 つあります。
システム管理者がユーザー全員のパスワードを作成する
システム管理者はパスワードをユーザー自身に作成させながら、 そのパスワードが十分に堅固であることを確認する
ユーザー全員のパスワードを作成するとパスワードは堅固になりますが、 組織が大きくなるにつれてたいへんな作業になってきます。 さらに、ユーザーが自分のパスワードを書き留めてしまう危険が増してきます。
こうした理由から、ほとんどのシステム管理者はユーザー自身にパスワードを作成させる傾向にありますが、 有能な管理者はこのパスワードが堅固であるか確認する手順も行っています。
堅固なパスワードの作成に関するガイドラインについては、Red Hat Enterprise Linux セキュリティガイドのワークステーションセキュリティの章をご覧ください。
パスワードを機密にしておく必要性は、各システム管理者が習慣的に警戒する事項でしょう。しかし、この点こそ多くのユーザーに見落とされがちなところでもあります。実際、ユーザー名とパスワードの違いすら理解していないユーザーが多いのです。こうした現実を踏まえた上で、一定のユーザー教育を行うことが重要であり、これによって、パスワードは給料小切手と同じくらい大切に扱うべきであることを理解してもらいます。
パスワードはできるだけ他人が推測できないようなものにします。 堅固なパスワードとは、 攻撃者がたとえユーザーのことを良く知っていてさえも推測できないようなパスワードのことです。
パスワードへの brute-force attack(総当たり攻撃)とは、 正しいパスワードが最終的には見つかるであろうという期待のもとにあらゆる文字の組合わせを 入念に試みるということです (一般的にはパスワードクラッカー(パスワード攻撃ツール)と呼ばれる プログラムを用いる)。 堅固なパスワードは、非常に広範囲にわたり試行しなければならないパスワードの組合わせで、 攻撃者がそのパスワードをを検索するのに時間がかかるような方法で構成してください。
堅固なパスワードと脆弱なパスワードについては次のセクションで詳しく解説します。
6.1.2.1. 脆弱なパスワード
前に述べたように、脆弱なパスワードは次の3つのテストのいずれかを満たしません。
秘密にしているか
他人から推測されないよう耐性があるか
総当たり攻撃に対して耐性があるか
次のセクションでは脆弱なパスワードについて示します。
6.1.2.1.1. 短いパスワード
短いパスワードは、総当たり攻撃を受けやすいため脆弱です。 これを例証するために、次のテーブルを見てください。 総当たり攻撃でテストする必要があるパスワードの組合わせ数を表示しています (パスワードの構成を小文字のみに限定)。
このように、考え得るパスワードの組合わせ数はパスワードの長さが増加するにつれ 劇的に増えていきます。
 | 注記 |
|---|---|
この表は6文字の長さまでしか示していませんが、 6文字のパスワードが安全面において十分な長さであるという推奨では決してありません。 一般に、パスワードは長いほど安全性に優れています。 |
6.1.2.1.2. 限られた文字の組合わせ
パスワードを構成する文字の数は総当たり攻撃を図る攻撃者にとって大きく影響します。 例えば、小文字だけのパスワードで使われる異なる26文字の代わりにデジットも使ったらどうなるでしょうか。 つまり、パスワードを構成する1文字は、26文字中の1文字ではなく36文字中の1文字となります。 6文字のパスワードの場合なら、 考え得るパスワードの組合わせ数が308,915,776から2,176,782,336に増えることになります。
この他にもまだいろいろなことができます。 小文字と大文字も混ぜた英数字のパスワードにすると、 6文字のパスワードの考え得る組合わせ数は56,800,235,584まで増大します。 その他の文字(句読点)を加えると、さらにこの組合わせ数は増大し、 総当たり攻撃を困難にさせます。
しかし、1つ注意する必要があるのは、パスワードに対する攻撃は総当たり攻撃がすべてではないということです。 次のセクションで脆弱なパスワードとなり得るその他の特性について解説します。
6.1.2.1.3. 見覚えのある単語
パスワードに対する多くの攻撃は、ほとんどの人がパスワードは記憶できるものにする傾向がある事実に 基づいています。また、ほとんどの人にとって覚えやすいパスワードとは単語を含むパスワードです。 したがって、ほとんどのパスワード攻撃は辞書ベースになっています。 つまり、攻撃者はパスワードを構成する単語を見つけるために辞書を使用します。
 | 注記 |
|---|---|
辞書ベースのパスワード攻撃プログラムの多くが複数言語の辞書を使用しています。 このため、パスワードに英語以外の単語を使ったからと言って堅固なパスワードになっているとは言えません。 |
6.1.2.1.4. 個人的な情報
個人的な情報(家族やペットの名前、誕生日、個人の識別番号)を含むパスワードは、 辞書ベースのパスワード攻撃で発見されるかもしれないし、されないかもしれません。 しかし、攻撃者が知人であった場合 (または、攻撃者がその人の私生活を調査するに十分な興味を持っている場合)、 簡単にパスワードを推測することができてしまうかもしれません。
パスワードクラッカーの多くが辞書の他にも一般名称、日付、他の情報などをパスワード検索に取り入れています。 したがって、犬の名前が「Gracie」だとは知らなくても、 優れたパスワードクラッカーを使えばパスワードが"mydogisgracie"であることを見つける可能性があります。
6.1.2.1.5. 単純なトリック
今まで述べてきた事項をパスワードの基本としますが、文字列の並びを逆転しても堅固なパスワードにはなりません。パスワードクラッカーのほとんどがこうしたトリックを考え得るパスワードの組合わせに対して行っています。次の例のように、パスワードクラッカーはよくある単語内の文字を特定の数字に入れ替える手法も行います。
drowssaPdaB1
R3allyP00r
6.1.2.1.6. 複数のシステムに同じパスワードを使用
堅固なパスワードを作成したとしても、全く同じパスワードを複数のシステムに使用するのはよくありません。 システムが何らかの中央認証サーバーを使用するよう設定される場合、 できることはほとんどありませんが、それ以外はシステムごとに異なるパスワードを使うようにします。
6.1.2.1.7. パスワードを何かに書き留める
堅固なパスワードを脆弱にしてしまう要因として、書き留めてしまうことがあげられます。パスワードを紙に書き留めることによって、秘密にしておくこと以上に物理的な安全性を考慮する必要が出てきます — パスワードを書き留めた紙を安全に保管する必要が出てくるわけです。このため、パスワードを書き留めておくのはよくありません。
ただし、パスワードを書き留めておくのに合理的な必要性を要する組織もあります。例えば、重要なスタッフ(システム管理者など)を失った場合の回復手続きの一部としてパスワードを書面化しておく組織などです。こうした場合、パスワードが書かれた書面は物理的に安全な場所に保管され、この書面にアクセスするには複数人数が共同で行なう必要があります。多重施錠の保管室や銀行の貸金庫などがよく利用されます。
緊急措置としてこのパスワード保管方法を試みる場合、 いかに安全に書面化したパスワードを保管しようとも、 その存在はシステムの安全性に対して危険性を増加させることになるということに留意してください。パスワードが書面化されていること(また、保管場所)が周知の場合には、特に注意してください。
書き留めたパスワードが回復プランの一部でもなく、 保管室にも保管されない普通のユーザーのパスワードは、次のような場所に置かれてしまっています。
デスクの引き出し(錠あり、錠なし)
キーボードの下
財布の中
モニタの側面にテープで張り付け
こうした場所は書き留めたパスワードを保管しておくのに適切な場所ではありません。
6.1.2.2. 堅固なパスワード
脆弱なパスワードについて解説してきましたが、 次のセクションでは堅固なパスワードについて解説します。
6.1.2.2.1. 文字数の多いパスワード
パスワードは長いほど総当たり攻撃の成功率が低下します。 したがって、オペレーティングシステムがサポートする範囲で、 比較的長いパスワードをユーザーに設定します。
6.1.2.2.2. 使用する組合わせ文字数を拡大させる
大文字と小文字を混ぜた英数字のパスワードを積極的に使用するようにし、 すべてのパスワードに英数字以外の字を少なくとも1字は必ず使用するようにしてください。
t1Te-Bf,te
Lb@lbhom
6.1.2.2.3. 覚えやすいパスワード
記憶できなければパスワードは堅固とは言えません。 ただし、覚えやすいものと簡単に他人から推測されるものとは似通っています。 従って、ユーザーには簡単に他人が推測できないけれど覚えやすいパスワードの作成に関するヒントを いくつか与えてください。
例えば、気に入ったことわざや言い回しを用いて、各単語の先頭の文字を使うところからはじめて新しいパスワードをつくります。覚えやすく(基になっている言い回しが覚えやすいわけですから)、単語を含まないパスワードになります。
| 注記 |
|---|---|
言い回し中の各単語の最初の文字を使うだけでは、堅固なパスワードを作るのに十分とは言えないので気をつけてください。必ず大文字と小文字を混ぜた英数字を使い、特殊文字を少なくとも 1 字は使うことでパスワードの組合せ文字数を増やすように注意します。 |
6.1.2.3. パスワードエージング
できる限り、パスワードエージングを実施してください。 パスワードエージングは、パスワードが有効である期間に制限を設定する機能です (多くのオペレーティングシステムで利用可能)。 パスワードの有効期間が切れると、ユーザーは新しいパスワードの入力を求められ、 そのパスワードは再び有効期間が切れるまで使用できます。
パスワードエージングを設定するにあたりシステム管理者を悩ませるのが有効期限です。
パスワード有効期限に関して全く相反する点が2つあります。
ユーザーにとっての便宜性
安全性
極端に言えば、パスワードの有効期限を99年に設定するとユーザーにとって不便を感じることがほとんど なくなります。しかし、安全性を強化することはまったくありません。
一方、パスワードの有効期限を99分にすれば、ユーザーにとって非常に不便なものとなりますが、 安全性が飛躍的に向上します。
ユーザーの便宜性と組織の安全性に対するニーズとのバランスをとることです。 ほとんどの組織にとって、週から月単位によるパスワードの有効期限が一般的です。
6.1.3. アクセス制御情報
ユーザー名とパスワードの他に、ユーザーアカウントにはアクセス制御情報もあります。 この情報は使用しているオペレーティングシステムにより形式が異なります。 ただし、情報の種類は概ね次の通りです。
システム全体におけるユーザー固有のID
システム全体におけるグループ固有のID
ユーザーがメンバーとなっている追加のグループ/機能の一覧
ユーザー作成のファイルやリソースにはすべてデフォルトのアクセス情報が適用される
ユーザーのアクセス制御情報がデフォルトのままで特に変更することなく使用できる組織もあります。スタンドアローンやパーソナルワークステーションなどのような場合がこれにあたります。これ以外、特に、異なるグループのユーザー間で共有しているネットワーク経由のリソースを使用することが多い組織では、ユーザーのアクセス制御情報をかなり変更する必要があります。
ユーザーのアクセス制御情報を正しく管理するために必要とされる作業負担は、そのオペレーティングシステムのアクセス制御機能をどの程度まで広範囲に利用するかによって異なります。こうした機能に大きく依存することは悪くありませんが(実際、依存せざるを得ないでしょう)、システム環境を管理する労力がさらに求められる可能性があり、各ユーザーアカウントに誤設定が起きる可能性が大きくなるとも言えます。
故に、こうした環境を必要とする組織の場合、ユーザーアカウントの作成と正しい設定を行うために 正確な手順を文書化して明確にしておく必要があります。 実際、異なる種類のユーザーアカウントが複数ある場合、 それぞれを個別に文書化する必要があります(ファイナンスの新規ユーザーアカウント作成方法、 オペレーションの新規ユーザーアカウント作成方法など)。
6.1.4. アカウントとリソースアクセスの日常的な管理方法
唯一の不変は変化であるということわざのように、ユーザーのコミュニティを扱うことも同じことが言えます。社員が入社したり、退社したり、部署の移動があったりします。システム管理者は、こうした組織内で起きる日常的な変化に対応できなければなりません。
6.1.4.1. 新入社員
組織に新しい人材を迎える場合、通常、様々なりソースへのアクセス権が与えられます (任務による)。デスク、電話、そして玄関の鍵なども与えられるかもしれません。
また、組織内の 1 台または複数のコンピュータへのアクセス権も与えられるかもしれません。システム管理者にとって、こうしたことが迅速に適切に行われるよう手配することが責務となります。どのように行いますか。
すべてのことを行う前に、まず最初に新しい人の到着を知る必要があります。 これは組織や企業によって取り扱いが異なります。ここに、いくつか例をあげます。
新しい人材が入社したら、会社の人事部がシステム管理者に通知する手順を作成します。
上司となる人が新しい社員のアカウントを要請するために記入して使用できる書式を作成します。
方法は組織や企業によってそれぞれ異なりますが、こうした方法を決めたら、行わねばならないアカウント関連の作業すべてがシステム管理者に通達されるよう非常に信頼のおけるプロセスを整えることが極めて重要となります。
6.1.4.2. 解雇
社員はいつか会社を辞めていきます。満足した状況で辞めていく人もあれば、不満があるため辞めていく人もいるかもしれません。いずれの場合も、適切な行動がとれるように事情に通じておくことが重要です。
少なくとも、適切な行動として次のようなことが必要になります。
すべてのシステム及び関連リソースに対してそのユーザーアクセス権を無効にします (通例、ユーザーのパスワードを変更/ロックする)
後日に必要となるものが含まれている場合のために、そのユーザーのファイルのバックアップを取ります
そのユーザーのマネージャがユーザーのファイルにアクセスできるように手配します
最も優先順位が高いのは、新たに解雇されたユーザーに対してシステムの安全を確保することです。特に、組織に対して悪意を抱かれる恐れのある状況で解雇された場合には重要です。しかし、そこまで極端な状況ではなくとも、新たに解雇された人によるアクセスを迅速に且つ確実に無効にすることは組織の最大関心事となります。
ここではプロセスの必要性を説明します。このプロセスで解雇者全員をシステム管理者に通知します — 実際に解雇される日よりも前に通知がある方がよいでしょう。つまり、人事部と協力して予定されている解雇者全員が必ずシステム管理者に通知されるようにしなければなりません。
| ヒント |
|---|---|
解雇に応じてシステムの"ロックダウン"を行うときには、正しいタイミングが大切です。解雇プロセスが完了してからロックダウンが行われると、解雇したばかりの人による許可のないアクセスが行なわれる可能性があります。一方、解雇プロセスが開始される前にロックダウンが行われると、退職を迫られていると感じさせる可能性があり、全ての関係者にとってプロセスをめんどうなものにしてしまいます。 解雇プロセスは通常、解雇される人、その人の上司、人事部の代表者によるミーティングで 開始されます。従って、このミーティングの開始によって解雇者の通知をシステム管理者が受けるような プロセスを定めると、ロックダウンのタイミングが適切なタイミングとなります。 |
アクセスを無効にしたら、解雇した人のファイルのバックアップコピーを作成します。このバックアップは、組織の標準的なバックアップの一部であっても、旧ユーザーアカウント専用のバックアップ手順であっても構いません。データ保持の規則、万一の違法解雇の訴訟に備えた証拠保管、その他などすべての事項がバックアップの取り扱いについて最も適切な方法を決定する役割を果たします。
いずれの場合も、次の段階で誤ってファイルを削除してしまう(上司が退社した人のファイルにアクセス)恐れがあるため、この時点でバックアップを行っておいた方がよいでしょう。誤ってファイルを削除してしまった状況になった場合、ここで作成したバックアップで回復が容易となり、解雇者の上司やシステム管理者にとってプロセスが楽になります。
この時点で、解雇された人のファイルに対してその上司がどのようなアクセスを必要としているのかを 確定する必要があります。組織、企業やその人の任務などにより、 アクセスは不要であったり、すべてに対するアクセスが必要であったりします。
その人が電子メール以外にもシステムを使用していた場合は、 上司によってそのファイルは厳密に調べられ、保存しておく必要のあるものと破棄してもよいものに 分ける必要があるかもしれません。このプロセスにより、 少なくともいくつかのファイルは解雇された人の任務を引き継ぐ人に渡されることになるでしょう。 プロセスの最後の手順となるこの作業では、システム管理者が作業を手伝うか、 上司が処理する役目を担う必要があるかもしれません。 ファイルや組織が運営する作業内容によりその手順はさまざまです。
6.1.4.3. 職務の変更
社員などが解雇されたときにアカウントをロックダウンするために必要な一連の手続きや 新しいユーザーのアカウント作成への対応は、いずれも比較的単純なプロセスです。 しかし、組織内での職務が変更する場合はそう簡単にはいきません。 アカウントの変更を必要とする人もあれば、必要としない人もいます。
新しい職務に合うようユーザーのアカウントが適切に再設定されるようにするには、 少なくとも次の3人が関与します。
システム管理者
ユーザーの元の上司
新たに上司となる人
この3者間において、ユーザーの旧職務の完全終了のために行うべきこと、 及び新職務に対してユーザーのアカウント準備に必要とされるものを確定することができるでしょう。 既存ユーザーアカウントをシャットダウンして新しいユーザーアカウントを作成するなどに 相当するようなさまざまな方法でこの手順は考えられます。 実際、信頼性においてこの手順をすべての変更に適用する組織もあります。
ただし、ユーザーのアカウントは保持したまま適当な変更を行って新しい職務をサポートする方が一般的です。この方法では、慎重にアカウントを見直してそのアカウントにそのひとの新しい職務に適切なリソースと特権だけを持たせていることを確認する必要があります。
新旧の両職務に関連する作業を同時に行う移行時期がよくあるため、 事態はさらに複雑になります。 この移行時期に、ユーザーの新旧の両マネージャによりタイムフレームを設けて システム管理者と協力してもらうことができます。