2018年 10月 08日
ユーザアカウント名は８文字以内にすべきか？ユーザの命名規則の理由と対策
私はほとんど無意識にですが、
「ユーザＩＤは８文字以内の英数字にすべし」
というのが暗黙の考え方としてありました。
ホスト名の命名規則？ 15文字の制限と63バイト、ホスト名の命名権利はあなた
パスワードポリシー強化各種設定のいろいろ、文字数、文字種
https://islandcnt.exblog.jp/241847045/
--
実際、海外の数万人規模の巨大企業でも、単一のディレクトリサービスでその様な ユーザアカウントの Naming Standard (命名規則) で運用している所をよく見ました。近年は、ユーザＩＤもパスワードも管理方法が複雑で、そのポリシーも複雑で統一性がないのでＩＤ管理に複雑な機能が要求されます。
- UNIX系 OS の場合 -
UNIX 系 OS のネーミングスタンダード(命名規則) では、POSIX 準拠した場合、ユーザ ID は 9 バイトで、お尻の１バイトは NULL 文字で、実質８バイト、というのがヘッダファイルのソースでは宣言されており、一応それが「暗黙の決まり」となっているようです。
limits.h
{_POSIX_LOGIN_NAME_MAX}The size of the storage required for a login name, in bytes (including the terminating null).Value: 9
一応の決まりですが実際には、今のディストリビューションやメーカー独自の UNIX 系システムは、独自拡張されており、現在、販売もしくは配布されている多くの Linux ディストリビューションや Unix 系 OS では多くの場合、最小2～最大長32 バイトです。ただし、 UID とユーザ名を関連付けるライブラリにバグがあったりすると、表示上 ８文字以上のユーザ名が UID に化けてしまうと言った問題もでてきます。
アカウントと連動するアプリケーション側が、古い標準に従って８文字に制限している場合もあるので
「システム的には管理運用上ユーザアカウント名は８文字以内」が無難
な(命名規則) であると考えます。
ps doesn't display usernames > 8 characters
ちなみに MySQL は 16 バイトでハードコードされているようで、デフォルトでは、ホストのユーザアカウントを参照するのですが、ユーザ名とパスワード自体が別に管理されているので、システムにログインしなくても使えるわけです。
6.3.1 ユーザー名とパスワード
- Windows の場合 -
Windows (2000/XP) のユーザアカウント文字数の(命名規則) は最小１文字から最大長２０文字でした。数字のみも可能です。
ユーザーアカウントとログオンパスワードの最大文字数について（Windows(R)2000/XP）
Windows10 に関しては情報がみつかりませんでしたが、Windows7 も２０文字なので、恐らく最大２０文字の制限は引きずっているでしょう。AD の場合も２０バイトの様です。
Windows 10でユーザーアカウント名に使用できる文字の制限について
Object namesCommon-Name attribute
それにしても CON とか LPT とかの文字列が使えないってのもなんだか笑わせられます。こんな制限は、DOS 時代を知らない、若い方々には訳が分からないでしょう。俗にいう「CONCONバグ」 の残骸です。こんな制限は古いシステムでも、最新のシステムにも制限があるのですね。
特殊文字はハイフンやアンダースコアは OK の様です。文字間にドットが入っても問題ない様です。カンマは不可。
ちなみに、マイクロソフトアカウントでユーザ作成した際の文字数が５文字を超えると、\Users\xxxxx のユーザフォルダ名は５文字にトランケート（丸めて短くされる）されます。そのため、５文字を超えるユーザアカウントのホームフォルダに何かアプリケーションでアクションを行う場合、ユーザアカウントを参照するソフトウェアが５文字を超えると「色々と楽しくて痛ましい事故？」が起こるようです。例えば
robocopy c:\users\%login_name\*.* \\nas\backup
などとバックアップ用のバッチファイルを書いてユーザに配布すると失敗する訳です。困ったものです。特に初回のユーザ設定で Microsoft アカウントでメールアドレス、"nagainamaedayo@gmail.com" なんて名前で登録すると、ユーザのホームディレクトリは "C:¥user¥nagai" となってしまいます。
User folder name truncated
[Windows 10] ユーザー フォルダーの名前が Microsoft アカウントのアドレスの最初の 5 文字になっているのですが、なぜなのか分かりません。
- メールアドレス -
メールアドレスの命名規則は、ドメイン名も含めた最大長 256 文字、＠以前の、いわゆるローカルアカウント部分は最大６４文字です。これに＠以下のドメインを含めて最大 256 文字という事です。
ローカルなアカウントの部分はドット、ハイフン、アンダースコアは利用可、ただし一番先頭と末尾、連続する事はできません。RFCでは他の特殊文字も使える様ですが、契約先のISPや携帯メールとか、レンタルしたメールサーバー、メーラー（クライアント側）の制限により、その限りではありません。もっと制限がかかっている場合があります。
https://ja.wikipedia.org/wiki/メールアドレス
一般的なマルチユーザのシステム単体(Unix だの VAX だの)では、ローカルホスト内でメールが使えればよかったので「ログイン名＝メールアドレス」です。今時はホスト外にメールを送るのが当然です。エイリアスを使っているので、ほとんど問題にはならないでしょう。管理上面倒と言えば面倒です。
よくエイリアスを使って、ユーザ名のフルネームをFamilyName.GivenName@mydomain.com のようにやっている所がありますが、どんなものでしょうか？ 異字でも同音同名の上司がヘッドハンティングされて、社長になった場合、数字を付けるのでしょうか。まぁメールアドレスは、先取主義だと思うので、システム担当としてはそういう事になりそうですが、当の「社長」さんにとっては、自分だけ本名に余計な数字を付けられて不愉快この上ないかも知れません。
それくらいなら、あらかじめ、「8文字以下のメールアドレス＋何らかのルールの Suffix」 を決め打ちしておいた方が公平だと思います。
- NetIQ eDirectory/LDAP の場合 -
ちなみに NetIQ eDirectory の CN (Common Name : UserID) は64 バイトまで許容しています。と言うより AD や Notes の認証のために LDAP 自体が x.500 の標準として 64 バイトに制限されているようで、eDirectory そのもの自体に制限は無いようです。
attribute length restrictions
しかし、NetIQ のドキュメントではスタンダードな命名規則の事例として、８バイトの英数小文字と ”-” ( ハイフン ) の命名規則を推奨しています。万物共用の命名規則として通用するわけです。
そこで eDirectory や LDAP でユーザアカウントを管理して、長いオブジェクト名や特殊文字を使用すると、マルチベンダーシステムで Windows や Linux のログインや動作で問題が起こります。LDAP との互換性のため、特殊文字にドットは使えません。ドットは、 eDirectory のコンテナ区切り文字です。特殊文字はハイフンだけ許可されます。LDAP サーチする場合は ＣＮ にカンマや＠が入っているとURLと間違えられ問題があるからでしょう。
Sample Standards Document#
Tip: Valid Characters in eDirectory
GroupWise はデフォルトで eDirectory の CN (common name) がメールアドレスのローカル部分になります。
- という事で -
また、Unix 系システムであれば、大文字小文字はケースセンシティブなので、アカウント名に大文字小文字を混在させるのは好ましいものではありません。Windows 系システムではケースセンシティブではありません。
レガシーなホストコンピュータなどのプリケーションの一部では、やっぱり８バイトが最長ユーザアカウントというケースもあり、
どうも「ユーザアカウント長、文字制限は８文字以内の英数小文字とハイフン」
というのが ID 管理を一般化した場合、一番確実なユーザ名を決めるネーミングスタンダード（命名規則）の構築方法でしょう。
セキュリティ上、ユーザ名もパスワード同様に長ければ良いというご意見もありそうですが、、まずアカウント名を解析してからのパスワード解析はクラックするにはちょっと実際の現実感がありません。手元にアカウントリストとハッシュ化されたパスワードリストがあってこそクラックし甲斐があるでしょう。
中には１２文字以上のアカウント名を要求するシステムもあります。先頭７文字は、社内ルールに従い、残りの５文字は統一されたシステムやサービス名を付けるしかありません。
- 文字数を８文字以内にする法則 -
- アカウントの長さは６～７文字の英数字 -
後に述べる「同姓同名問題」を解決させるため、８文字目は丸めて最大７文字とします。８文字使う場合は特例とします。もちろん、ユーザ名が"津・浦子"さんの場合 "tsuu" と短くなるのは構わないとは思いますが、必要に応じて文字を追加して６文字以上(tsuurrk)にする、と言った方法も良いと思います。８文字以上のＩＤを要求する場合、長ければトランケートして８文字に抑え、短すぎる場合、規則に従った文字列を加えると良いでしょう。
もちろん２バイト文字や特殊記号の利用は厳禁、特別に許されても”－”ハイフン位にしておきます。ただ ”-” 文字も検索のスクリプト条件で使われる可能性があるため、好ましいとは言えないという意見もあります。よく"."（ドット、ピリオド）姓名の区切りにしているのを見ますが、これもインターネットアドレスを表現するデリミタになるので、将来何らかのトラブルになる可能性があり、好ましくありません。
Unix 系 OS では最低長２文字以上、MacOS と Windows は１文字でもユーザは作成できますが、MacOSは数字のみのユーザ名は不可です。最小公約数で少なくとも６文字程度の英数字を最低長としておくべきだと考えています。
- ファミリーネーム＋ファーストネームイニシャル -
大規模な組織では、エンドユーザは相手のファーストネームを知らない事がほとんどです。したがって、ファミリーネームに識別子としてファーストネームのイニシャルを添付します。ファーストネームのイニシャルを１文字加えて「同姓異名」を区別します。
よく、イニシャル＋ファミリーネームを使うところがありますが、本人や周囲の人には暗黙の了解ですが、初めて会ったあなたにメールで返事を書きたいと言った場合、ファーストネームを思い出せる人は少ないものです。ファミリーネームを優先的に使った方が良いでしょう。
- 同姓異名、同姓同名の区別 -
同姓同名、同姓異名で、ファーストネーム＋イニシャルがダブる場合、後で追加するユーザは、ファミリーネームを一文字削除して、イニシャルの次の子音を一文字加えるのが一つのアイディアです。
Nakajima Kenji : nakajik
Nakajima Kensaku : nakajkn
Nakajima Kenichi : nakajkc
Nakajima Kenji(2): nakaknj
という感じです。
あるいは何らかの Suffix を決め打ちしておき、同姓同名を回避しておくの、公平な逃げの手段でしょう。
- 社員番号は使わない -
よくある例として、社員番号をユーザ名としている所がありますが、最悪の選択です。社員番号と「ニンゲン」を結び付けてモノゴトを考えられるのは本人と、人事担当だけです。間違っても派遣で来ているヘルプデスクさんや、ログ管理をしている外注さんにはわかりません。ログイン名は「ヒト」をちゃんと認識できる何らかの符号が必要です。
- 回避できない場合は８文字目を数値にする -
Nakakjik と nakajik2 ですね。これで例外があっても８文字に収まります。ここで上の例で最悪だと断じた社員番号の下２桁を使うのも一つの手段でしょう。
- 表記はヘボン式 -
普段あまり意識しないのですが、日本語のユーザ名をローマ字化するための方法として、ヘボン式ローマ字と訓令式（日本式）ローマ字の二種類があります。一般的にパスポートなどの人名表記はヘボン式を基本としているので、ヘボン式に統一すべきでしょう。
ヘボン式ローマ字東京都生活文化局 - ヘボン式ローマ字綴方表
また、外国人の場合、帰化しない限り日本の戸籍名がないので、原則として「通称」を使うことになります。その際も母語のスペルを使うのが原則でしょう。 Bob Smith さんの場合 "SmithB" であり "SuMiSuB" になってはいけないわけです。母語がアルファベットで表記できない場合もあるので、その例外措置も考慮すべきです。
まぁ、例外規則に命名規則＋「本人の希望」というものがあってもいいわけです。
- 使ってはいけない文字（列）がある -
一般的にOSでファイル名として利用できない特殊記号や文字列、システム間で互換性のない文字（列）などは、or 条件の最大公倍数で禁忌とすべきです。
Unix 系OSでは "0","/" などが禁忌文字ですし、mac の場合は "/" だけ。":"や "|" とか "<>" もパイプに相当するためやめた方がいい。おそらく "Null" などの特殊なデバイスを意味するユーザIDもやめるべきでしょう。 Windows 系OSでは前述したように、特殊文字と "CON" とか "LPT1" とかのファイル名は使えません。ユーザアカウントはバッチやシェルで処理する場合もあるので、これらの全システムで禁忌文字は最大公約数として、使用してはいけないと思います。モノによっては "-" も文字列一括変換などのプログラムやシェル、バッチ処理で問題になるようです。たしかに「特殊文字が使えるシェルの書き方」というのがありますが、メンドクサイので禁忌文字とした方が無難でしょう。
また、当たり前ですが機種依存文字（○付数字やカッコつきの「株」「〒」）とかを含め、「ソ」「申」「表」などのシステム依存のいわゆる「５C文字」を含む。
つまりはすべての漢字を含め２バイトの文字は使うべきではありません。
正しい日本語処理を行わないと想定外の動作をするアプリケーションやシェル、バッチファイルがあり得ます。
「英数小文字６～８バイト以内」とするのが && 条件で絞り込んだ最小公約数として命名規則に加えるべきです。
- 改姓をどうするか -
主に姓が変わるのは、お年頃の女性が多いと思いますが、男性でも次男坊、三男坊が一人娘を娶った場合なんかは、戸籍上「婿入り」するわけで、そのような場合はどうするのかという事も決めておかなければなりません。ユーザID＝戸籍名なのか、ユーザID＝通称名とするかですね。
「ユーザID=戸籍名」で、メールアドレスを決めてしまうと、幸か不幸か何度も結婚を繰り返しちゃった女性（男性も）、メールアドレスが頻繁に変わるわけですから、あまり好ましいものとは思えません。
本籍名を使うのか、通称を使うかの判断は「本人の希望があれば」認めるべきですが、業務上「頻繁に変更できない」というルールが必要です。
- 重要なのは文書化しておく事 -
忘れてならない事は、このような運用ルールを文書化し、担当課長のハンコを貰って、オーソライズしてもらう事です。後任者が誤って８文字以上のユーザアカウントを作ってトラブルって、後で仕様変更するような目にあっても、それはルールを超えた例外処理として余分な出費を認めてもらう十分なりゆうになるからです。
- とっても重要 -
命名規則は文書化して、認印（ハンコ）をもらってオーソライズしておくこと。
--
とまぁ、書いてみた訳ですが、実際に古くから運用しているディレクトリサービスで暗黙に８文字運用している現場で、たまたま９文字のユーザアカウントを作ってみると、システム全体に影響がでる現行システムの古い仕様上の互換性との問題点というのが見つかりました。新規登録のルーキーユーザなので、８文字に短くして問題が解決しています。
NetIQ の eDirectory を使ったID管理システム自体が、&& 条件で最小公倍数の 「8 文字英数子文字」をネーミングスタンダードのサンプルにしているので、どのシステムアカウントもこの文字数に従う事が無難です。
もっともこう言った問題点は社内システムでは問題になりますが、今時 google のアカウントを８バイトで確保するのは難しいので、一般的なインターネットサービスではあまり問題にならないかも知れません。ただウェブサービスの一部では、やはり文字数の制限がある訳でして、最低限８文字以上が必須だったりしますし。”８文字”（以下）が無難だ、というのはどこでもあり得る話なのです。
ログインIDが短いと、セキュリティ上問題があるんじゃないかとも思われますが、IDもパスワードもブランクで不明なアカウントを ブルートフォースアタックかける場合、組み合わせは事実上無限なので、総当たり戦ではあまり関係ない、と思うのは私だけでしょうか。
ユーザのログインＩＤの文字数を調べてみると色々なことが解って勉強になりました。最低の「短過ぎるユーザＩＤは何文字が許されるか」も併せて調べるともっと面白いかも知れません。
ユーザ管理とダンパー数PCDAサイクルから考えるセキュリティポリシーの見直し
by islandcenter
| 2018-10-08 16:42
| Identity Management
|
Comments(0)
