識別子とユーザ名

イアン・グレイザー

序章

識別子やユーザ名とは？

物理的な世界では、人や物を識別するために様々な方法を使っています。シリアル番号から住所、ナンバープレート、ニックネームまで、人間は識別子を使って似たようなものの集まりから特定のものを選択します。オンラインの世界でも、この行動に違いはありません。コンピュータシステムとそれを扱う人々は、類似したものを区別するために識別子を使用しています。より正式には、ID 管理の文脈では、ID 管理システムがデジタル ID を参照する方法として識別子を考えることができます。

ただし、そのデジタル ID に関連付けられている人は、システムが使用するのと同じ識別子を使用しない場合がある。実際には、使用しない可能性が高い。可能性が高いのは、その人が人間にやさしい識別子を使用していることである。差別化のために、デジタル ID を管理している人がシステムに対して自分自身を識別する方法をユーザ名と呼ぼう。

識別子とユーザ名を検討する理由

システムがデジタル ID をどのように参照するか、そして人々がシステム内で自分のデジタル ID をどのように参照するかは非常に重要です。識別子とユーザ名は、デジタル ID 管理システムで最も一般的に使用されるコンポーネントの 1 つです。識別子とユーザ名は、ユーザビリティ、セキュリティ、顧客満足度、およびシステム運用に意味を持ち、システム間の相関関係およびユーザ・アカウント管理を可能にする（または防止する）。これらは、企業間（B2E）、企業間（B2B）、企業間（B2C）、企業間（B2B2C）、および企業間（B2B2C）のユースケースに適用可能である。

識別子、特にユーザ名を考慮していないと、作業中のプロジェクトやシステムに直接的な悪影響を及ぼす可能性があります。

識別子の種類

識別子には、内部識別子と外部識別子の 2 種類があります。内部識別子は、システムがデジタル ID を参照するための手段です。内部識別子の形式は大きく異なります。内部識別子の一般的な形式の 1 つは、普遍的な一意識別子 (UUID) です。IETF RFC 4122 で指定されている UUID には 4 つのバリエーションまたはバージョンがあります1。1 多くのシステムでは、ランダムに生成された識別子であるUUIDバージョン4（UUID4と呼ばれることが多い）を使用しています。UUID4 の例としては、 d5372288-697b-42bf-928a-562aca0deeaf があります。

しかし、すべての内部識別子がUUIDであるわけではない。システムは、類似したものの集合から特定のものを一意に識別する他の手段を使用することができる。例としては、システムにとっては特定の意味を持つが、システムの外部では意味を持たない識別子、例えば “005o0000000s4Hu. “のような識別子が挙げられる。

識別子の第二の種類は、外部識別子である。外部識別子とは、デジタルIDを管理する者がシステムと対話する際に、そのIDを参照するための手段である。これには、電話番号、電子メールアドレス、ニックネーム、またはハンドルが含まれるが、これらに限定されない。

場合によっては、システム識別子を内部目的と外部目的の両方で使用することができます。電子メール・アドレスは、企業などの組織内、または大学や医師などのドメイン内で一意でなければならないため、メンバーの「ネットID」（電子メール・アドレスの最初の部分）は、企業のシステム内でユーザーの識別子として使用されます。ネットIDは、ファースト・イニシャル、セカンド・イニシャル、ラスト・ネーム、そして一意性を保証する番号で構成されます。

用語

内部識別子：ID 管理システムがデジタル ID を参照する方法

外部識別子：デジタル ID を管理している者が、システムと対話する際にその ID を参照する手段。

ユーザー名: 外部識別子に使用される一般的な用語

ユーザ名の側面

ユーザ名の形式を検討するとき、ID 担当者はユーザ名の 5 つの指針を検討する必要があります。実務者は、少なくとも新しい B2C または B2B2C サービスが作成されているときには、グリーンフィールドの状況でもユーザー名の形式を検討する必要があります。多くの場合、特にB2Bのシナリオでは、ユーザ名は前世代のシステムで確立されたフォーマットを持っており、それらのフォーマットはほとんど神話的な品質を持っています。ユーザ名のフォーマットを単純に変更することは合理的ではありません。言うまでもなく、ユーザ名のフォーマットを変更することは、特に企業の B2B 環境では、軽々しく行うべきことではありません。

クラウドアプリケーションは、ユーザ名の混乱を招く可能性があります。マルチテナント・アプリケーションでは、ユーザ名は共通であるべきです。つまり、あるアプリケーションでのデジタル ID のユーザ名は、別のアプリケーションで使用されるものと同じです。しかし、場合によっては、ユーザがSaaSアプリケーションにアカウントを設定し、別のユーザ名を選択することがあります。このアプリケーションがその後に ID 管理環境にインターフェイスされる場合、変換メカニズムが必要になる。複数のユーザー名を管理する API ゲートウェイまたは ID プロバイダ・サービスはオプションである。

ID 実務者が考慮すべき 5 つの指針となる原則は、以下のとおりである。

秘密ではない。

公開データとして分類されている必要があります。

記憶に残るものでなければならない

ユニークであること

回収可能であること

シークレット

ユーザ名のアンチパターンとしての米国の「社会保障番号（SSN）」には教訓がある。2

SSNは内部識別子としての意味を持っていました。元々は、社会保障庁が人間と稼いだ賃金、そして最終的には資格に結びつけるために使用するもので、ビジネス・プロセスに使用するものでした。社会保障庁はこの内部識別子を人々や雇用者と共有して、ビジネスプロセスを実行させていました。しかし、この内部識別子の使用は拡大しました。企業は、人々が自分自身を企業に識別するための方法として SSN を使用し始めました。この二次利用は、唯一の人が自分のSSNを知っているだろうという考えに基づいていたので、それが秘密であるため、SSNの保有者は正しい人であると仮定されます。そして、ここで物事がうまくいかなくなったのです。

この特定の秘密の必要性は、私たちの経済全体のビジネスプロセスの非常に多くに浸透していました。この必要性は、データブローカーなどが違反をしたときの被害のための巨大な増幅器を生み出しました。

SSNの教訓は、ユーザ名は秘密にできないということです。内部識別子を組織外の関係者と共有した場合、その内部識別子を公開情報に変えたことになるので、秘密にすることはできません。

秘密のように扱わなければならないユーザ名や内部識別子を持っている場合は、ユーザ名ではなく認証機構を持っていることになります。そして、これはパスワードと同じように扱う必要があることを意味します。

後日の高度なトピックへのポインタとして、これを考えてみてください。人は、指紋、顔の形状、または虹彩を秘密にしておくことはできません。このため、システムまたはプロセスは、外部識別子としてバイオメトリクスを使用することができます。しかし、それらは「単なる」識別子であるため、人が実際にバイオメトリクスを提示する意思があることを確認するために、ある程度の認証が必要となります。この程度の不確実性があるからこそ、生気検出と注意検出が非常に重要になるのです。たとえば、指が本物であること、血液が流れていること、ゼラチンでできた偽物ではないことを確認しなければ、指紋バイオメトリクスを受け入れることはできません。3

パブリック

ユーザ名が秘密でないことを確認するだけでは不十分である。アイデンティティの実務者は、データ分類スキームでユーザ名を公開として分類する必要があります。この操作は、従業員、パートナー、および顧客にも適用される。

ユーザ名を公開として分類することは、個人に関連する属性が公開されていることを意味するわけではない。そのような属性は、ユーザ名に合理的に、あるいは安全に使用することはできません。単純な4段階のデータ分類システムを考えてみましょう。

公開：このデータは、組織の境界を越えて自由に、かつ低レベルの懸念なく共有することができます。

制限付き：このデータは、ビジネスプロセスに不可欠なデータであり、組織の境界を離れることができない可能性が高い。データ対象者、従業員、請負業者のみがこのデータにアクセスすることができます。

機密：このデータは業務運営に不可欠なものです。このデータが組織の境界を越えた場合、重大な危害が発生する可能性があります。

秘密：このデータは組織的に極めて機密性の高いデータです。アクセスできるのは、ごく一部の限られたグループの人々とシステムだけです。

理想的な世界では、航空会社やホテルのロイヤルティ番号(別の種類の識別子)は「制限付き」に分類される可能性が高いです。ユーザ名は「公開」に分類されなければなりません。航空会社やホテルのロイヤルティ番号は、「公開」でありながら価値を持つ属性を含む識別子の問題を示しています。

さらに、ユーザ名を「公開」に分類することは、識別子を秘密にすることはできないという考えを強めます。

明確にするために、データ分類システムにおいて、ユーザ名を公開データとして分類することが推奨されています。これは、ユーザ名が公開されるべきだという意味ではありません(例えば、公開サイトに掲載されるなど) - それは自業自得の列挙攻撃です。

記憶に残る

アメリカ文学のカノンの一部はハーマン・メルヴィルの「モビー・ディック」だその最初の文は “私をイシュマエルと呼べ “とあるユーザー名であるイシュマエルは、その文章の中で最も重要な部分ではなく、「私を呼ぶ」という部分が重要なのです。何かに名前をつける力は、それをコントロールする力です。そして、イシュマエルは自分自身に名前をつけることで、読者から離れて、作者から離れて、自分自身をコントロールするのです。

自己決定を支えるためには、人々は自分自身に名前をつけなければならないし、デジタルの世界では、これは極めて重要なことである。B2CとB2B2Cの設定では、ユーザー名は自己生成される必要がありますが、これはつまり、その人が自分の好みのユーザー名を作る力を持つべきだということです。B2BやB2Eの設定でも、自分で生成したユーザー名を考慮することが重要です。

多くの企業では、標準的なユーザー名のフォーマットを持っており、B2CとB2Bのユースケースではそのフォーマットを採用しています。標準的なユーザー名のフォーマットは、First Initial, Last Nameです。例えば、サリー・スミスは “ssmith “というユーザー名を取得し、それが一意でない場合はランダムな番号が追加されます。このような習慣的なユーザー名のフォーマットは、合理的には有効ですが、B2Cのユースケースでは非常に重要な自己決定欲求をサポートしていません。

覚えやすいユーザー名をサポートしていないということは、アカウント復旧のための電話が増え、画面上でのヘルプが増え、カスタマーサポートの必要性が高まることを意味します。また、登録時に使用した識別子を忘れてしまうことが多いため、識別子の重複にもつながります。

ユーザー名スキームを構築する際には、ユーザーに選択肢を提供する必要があります。ユーザー名として電子メールを聞かれて、次の画面で「私と話すのに電子メールは使わないでください」と答えた場合、認知的な不協和音が大きくなります。選択肢を提供するために、メールアドレスやユーザーが作成したニックネームなど、複数のユーザー名をサポートすることを検討してください。複数のスキームをサポートすることで複雑さが増しますが、それによってもたらされるユーザーのエンパワーメントは、自己決定と顧客満足度を高めます。

ユニーク

ユーザ名は一意である必要があります。内部識別子は一意である必要があります。どちらの記述にも議論の余地はありませんが、ここにはニュアンスがあります。

ユーザ名は一意でなければならないというだけでは不十分で、一意性の範囲を考慮しなければなりません。ユーザ名は一意なのか？

個々のサービスレベルで？

テナントレベル(マルチテナントの場合)なのか?

サービスまたはサービスのセットを持つ名前空間内で?

すべてのサービスにまたがるグローバルなものですか？

普遍的に？

設計されているスコープの明確なイメージがありますか？将来的に内部システムの合併が含まれるかもしれないか、あるいは将来的に様々な合併・買収活動をサポートしなければならないかもしれないか、実務家は検討する必要があります。

また、一意性は、識別子の種類によっても意味合いがあります。ユーザ名と内部識別子は、同一の一意性の範囲を持つ必要はありません。例えば、内部識別子はグローバルに一意である必要がありますが、ユーザ名は企業内のシステムのサブセットでのみ一意である可能性があります。内部識別子は、サービススコープで一意でなければなりません。例えば、特定のエンタープライズサービスで一意でなければなりません。データ主体の再識別の可能性を軽減するためには、これらの識別子はグローバルにスコープされた一意のものでなければなりません。一方、ある人が電子メール・アドレスを使用して複数のシステムにログインする場合、サービスレベルでスコープされた一意のユーザ名となります。

また、同じシステム内では、ユーザ名と内部識別子を同じ値にしてはいけません。ある意味では、これは米国が社会保障番号で犯した間違いの一つである。4 実務者は、どちらか一方を後から変更することは非常に困難だからというだけの理由で、同じ値にすべきではありません。さらに、一般的に選択されるユーザ名のスキームはメールアドレスであり、これは結婚や離婚などのライフイベントに基づいて、その人の人生の中で変化する可能性があります。ユーザ名と内部識別子が同じスキームでは、このようなユーザ名の変更に対応するには、「古い」ユーザ名/内部識別子を持つすべてのシステムが変更を認識し、更新する必要があります。

最後の考慮点は、ユーザ名の再利用です。ヤフーの電子メールでは、かつて他の誰かが使用していた電子メールアドレスを使用することができます。電話番号も定期的に再利用されます。この場合、ユーザー名はまだ固有のものであるかもしれませんが、そのユーザー名を所持している人が変わってしまっています。この過渡期は、メールや電話の新しい所有者が攻撃者のように見えるという理由以外の理由がない場合には、難しい状況です。

回復可能

ユーザ名は回復可能である必要があります。つまり、人をデジタル ID に戻す方法が必要です。回復とは、その人をデジタル ID に再接続することを意味し、必ずしも同じユーザー名を繰り返し使用することを意味するわけではありません。

この点で、回復とは、ログインに使用した電子メールアドレスを思い出させるだけではありません。使用した電子メール・アドレスは、アクセスできない昔の職場の電子メール・アドレスであることを相手に伝えることを考えてみてください。これでは、ヘルプデスクに電話するか、新しいサービスに移るしかありません。

リカバリは再関連付けであり、これを安全に行うためには、多くの場合、個人が自分の主張する通りの人物であることを再証明する必要があります。特にB2Cのシナリオでは、このような再証明プロセスは、セキュリティと顧客満足度に大きな影響を与えるため、かなりの検討が必要です。

結論

識別子は ID システムに必要であり、内部識別子と外部識別子は異なる目的を果たす。2 つのタイプの識別子は同じものになる可能性がありますが、IAM 実務者は注意して検討する必要があります。ユーザ名としても知られる外部識別子は、以下の 5 つの指針を考慮する必要がある。

ユーザ名は秘密と考えてはならない。

ユーザ名は公開データとして分類されなければならない。

ユーザ名は記憶に残るものでなければなりません。

ユーザ名は一意でなければならない。

ユーザ名は回復可能でなければならない。

各原則は、ID 管理システムを開発する際に ID 担当者が考慮すべき意味合いを持っている。ユーザ名フレームワークを構築することは、「ID オーケストレーション」タスクの一部である。

Leach, P., Mealling, M., and R. Salz, “A Universally Unique IDentifier (UUID) URN Namespace”, RFC 4122, DOI 10.17487/RFC4122, July 2005, https://www.rfc-editor.org/info/rfc4122.
キャロリン・パケット「社会保障番号の話」『社会保障公報』第 69 巻第 2 号、2009 年、https://www.ssa.gov/policy/docs/ssb/v69n2/v69n2p55.html .
John Leyden, “Gummi be defeat finger print sensors” The Register, 16 May 2002, https://www.theregister.co.uk/2002/05/16/gummi_bears_defeat_fingerprint_sensors/ .
Pucket, see Expanding Uses of the SSN , https://www.ssa.gov/policy/docs/ssb/v69n2/v69n2p55.html .

bok

IDPro Body of Knowledgeの日本語訳を載せていきます