認証と認可、再び（No335）

前々回は認証と認可という用語のお話、前回はシングルサインオンとディレクトリサービスという用語のお話をしました。

さて、今回は、前々回に書き切れなかった認証と認可を意識して区別することのメリット、特にディレクトリサービス導入時の注意点についてお話します。

はじめに

このメルマガでは、基本的に一回完結型で構成するようにしています。ですので、前回の内容を知らなくても（わからなくても）読み進んでいただけます。

ところが、今回の「認証と認可」では、まず概念を理解していただき、次にその概念を利用したサービスを知っていただく必要があります。

このプロセスを経て、ようやく認証と認可を意識的な分別に意味があることが理解いただけると思っています。

ご覧になっていない方は以下のバックナンバーも併せてご覧ください。
一層理解が深まると思います。

　No333 「認証」と「認可」の違いってわかりますか？
　　https://note.com/egao_it/n/n1a83c9611796

　No334 シングルサインオンとディレクトリサービス
　　https://note.com/egao_it/n/n8666bff5aa60

まずは前回と前々回のおさらいからです。

認証と認可

まず、用語として定義すると、次のようになります。
　認証：利用者が本人であることを確認するプロセス
　認可：利用者が利用可能なサービスの範囲を決めるプロセス

実際のログイン処理では、この両者は混然一体となっていることが通常で、両者の違いを意識することがないのでわかりづらいかもしれません。

例えば、通信販売のシステムを運営側の視点で見てみます。

このシステムにログインする時のIDとパスワードが正しいかを判断するところまでが認証で、それ以降の以下の記載は全て認可の範囲となります。

この場合、担当する業務や役割（ロール）によって、必要な機能／情報が大きく違ってきます。
梱包担当者には、購入された商品の個数や型番が必要です。
発送担当者には、お客さんの住所や氏名が必要です。
経理担当者は、売上情報が必要です。

システム開発時にはロールを定め、各ロールに必要な機能や情報を決めます。
業務担当者にログインIDと適切なロールを割り当て、それでログインをしてもらいます。

こうすることによって、利用できる機能範囲を自由に制限することができます。

この一連の仕組みを認可と呼びます。

整理します。

システムを利用する際は最初に認証を行います。
IDとパスワードを使うことが多いですが、生体認証（バイオメトリックス）や専用機器（スマートトークンや車のキーレスエントリーなど）を利用する場合もあります。

ここまでが認証の範囲です。

次に、システムはログインユーザに予め決められたロールを割り当てます。
そして、そのロールにふさわしい画面を表示します。

このロールの割当てが認可の機構となります。

多くのシステムでは各画面の表示前にロールを確認します。
そのロールでアクセスできない画面へのアクセスは拒否されます。
例えば一般利用者（お客さん）がユーザサポート担当者の画面にはアクセスできません。
こういった制御は認可システムによって行われます。

余談
　管理者側画面へのアクセス制限は上記の認可システムだけではありません。
　特定ロケーション（例えば社内）からのアクセスしか許可しないことが多いです。
　

ディレクトリサービス

このような認可情報の格納先としてディレクトリサービスがよく利用されます。

英語の辞書を見ますと、ディレクトリ（directory）というのは住所録や人名簿の意味だそうです。ディレクトリサービスの「ディレクトリ」はこの人名簿の意味になります。

組織内のメンバ名簿＋関係者名簿といったイメージですね。

つまり、その組織内のサービスを利用できる人を管理するサービスということです。

ディレクトリサービスには、氏名、メールアドレス、ログインID、パスワードなどが含まれています。（内容は自由に選べます）

このログインIDとパスワードを使って、ログイン作業を行います。

個々のシステムではIDもパスワードも要りませんから、全ての情報をディレクトリサービスで一元管理できるようになります。

これがディレクトリサービスの最大の効用です。

認証と認可の識別

ようやく認証と認可の識別の話ができるようになります。

ディレクトリサービスには２つの機能があります。
一つは、認証、つまり、IDとパスワードによる本人確認機能です。
もう一つは認可、つまり、その人が属する職種、役職、所属部署などを保持する機能です。

これを見ますと、ディレクトリサービスで、認証も認可も両方できそうですし、実際にそのような利用を目指して設計をされています。

認証についてはディレクトリサービスで問題ないのですが、認可の全てをディレクトリサービスに頼ることはできません。

というのは、同じ役職や同じ職種でも利用範囲が異なるのはよくある話だからです。
最初に答えを書いてしまうと、原則的な情報はディレクトリサービス、例外的な情報は各システムで実現すべきです。

つまり、氏名や役職など、どのシステムでも利用するであろう情報はディレクトリサービスで、それ以外の情報は個別システム側で実現するのが無難だということです。

もちろん、原則はその組織にとっての原則です。他社と同じである必要は全くありません。

さて、前々回にも書いた人事システムを例にして説明します。

この人事システムでは、各部長が評価を行い、人事部が最終評価を行い、各メンバはその結果を閲覧できる、という方式を採っているものとします。

整理すると、こんな感じになります。

　・評価を行う人＝部長
　・最終評価を行う人＝人事部のメンバ
　・結果を閲覧できる人＝各メンバ

これなら、確かに上記のディレクトリサービスに、役職と所属部署の属性を登録しておけば、認可できそうです。
　・評価を行う人　→　役職＝部長
　・最終評価を行う人　→　所属部署＝人事部
　・結果を閲覧できる人　→　条件なし（誰でも）

ですが、次の条件を付けるとどうなるでしょうか？

・一部の部署には部長がいないので課長が評価を行う

この条件をディレクトリサービスに加えようとしても、うまく追加できません。
なぜなら、役職と所属部署だけでは上の条件を表現できないからです。

かといって、対象となる課長さんをディレクトリサービス上で部長扱いにすると、他のシステムにも部調権限でアクセスできてしまいます。

「じゃあ『評価を行う人』属性で回避しよう」と歪んだ対応を取るとディレクトリに個別システムの都合を持ち込むことになります。
これを繰り返すと、恐ろしく運用の難しいディレクトリになってしまいます。

上記の課長さんが異動で別の課に異動した場合を考えてください。
新しい部署に部長さんがいれば、「評価を行う人」属性を「なし」に設定しないといけないわけです。
こういった各システムの個別事情を増やすと、運用ミスが続発する使えないディレクトリサービスになってしまいます。

これが、ディレクトリサービスでの認可情報の利用の難しさです。

ディレクトリに含むべき認可情報とは？

上の例でわかるのは、ディレクトリに何でもかんでも突っ込むとロクなことにならないという点です。

上記と全く逆に、例外を全く排除したディレクトリは実態を示しておらず使いものにならない、となるかもしれません。

どの例外をディレクトリサービスに組み込み、どの例外を個別システムの情報とするかについての明確な基準などなく、個別に考えるしかないのです。

上の例（一部の部署には部長がいないので課長が評価を行う）であれば、人事システム内に認可システムを組み込むのがおそらくは現実的です。

「おそらくは」とあいまいな書き方になるのは、これが組織のポリシーや考え方に従うべきことであり、大げさに言えばその組織のあり方や将来像によるからです。

そもそも論になりますが、ディレクトリサービスで認可処理を全面採用するのなら、組織の例外を減らすなどの業務改善をセットにすべきで、それが正しい姿と言えます。

ディレクトリ設計のベンダーまる投げは禁止！

ところが、これを「ディレクトリの定義はITのことだから」と外部のシステム開発会社やベンダーにまかせる会社の多いこと。

ディレクトリサービスの運用の難しさを知っているベンダーであれば「それはお客様が主体となって決めていただく必要があります」と言います。

これは「何が原則で何が例外か」はお客さんしかわからないからです。
例外を次々とディレクトリに持ち込むと運用困難なディレクトリになることを知っているからです。

ですが、この考え方を知らないベンダーはたくさんあります。
彼らは自分達のシステム開発の都合や過去に組んだシステムに合わせてディレクトリ構成を決定してしまいます。

その組織の原則がディレクトリに反映されていませんから、別システムをディレクトリ対応しようとした時になって「なんじゃこりゃ！？」となるわけです。

まとめ

認証というのは、本人であることを証明することです。
例えば写真入りの社員証を守衛さんに見せて入室することは認証です。

一方の認可は、特別な部屋に入るための（写真なしの）IDカードのようなものです。
IDカードを持っていることが即ち、入室の許可を得ているものと考えます。

認証を必要とするシステムでは必ずといっていいほど認可も行っています。

例えば役職や部署によってアクセスできる機能が異なるといったものです。

認証と認可を担うシステムとしてディレクトリサービスがあります。

このディレクトリサービスでは認可情報を追加できるのですが、ここには原則となる情報のみを追加すべきであり、例外ケースについては個々のシステム側で実現するべきです。

何が原則で何が例外になるかは組織によってまちまちですので、ディレクトリ構成も組織によってまちまちとなるのが本来です。

ですが、「ITのことはわからないから」と外部ベンダーにまかせてしまうと、その企業に合わないディレクトリとなってしまい、運用に四苦八苦しているケースがまま見受けられます。

今回は「認証と認可をごっちゃにしていると、ディレクトリサービス導入でひどい目に合う」ことについてお話をしました。

次回もお楽しみに。

（本稿は 2023年11月に作成しました）

このNoteは筆者が主宰するメルマガ「がんばりすぎないセキュリティ」からの転載です。
誰もが気になるセキュリティに関連するトピックを毎週月曜日の早朝に配信しています。
無料ですので、是非ご登録ください。
https://www.mag2.com/m/0001678731.html
また、公式サイトでも最新版を公開していますので、そちらもどうぞ。

https://www.egao-it.com/