製品進化とマネジメント風景第85話認証・認可の技術進化と経営マネジメント（1）

2023.03.13 コラム

今日、ビジネスを行う上での基盤的な情報サービスは、マイクロソフトやグーグルなどの情報インフラ提供会社が重要な位置を占めています。ただ、これらの会社であっても、単独で提供しているソフトウェアサービスの量は少なく、それだけでは今日の企業ニーズを満たすことはできません。

情報サービスインフラは一種のエコシステム（生態系）であり、そのエコシステム上には多数のサードパーティー企業が共生しており、彼らが作成したソフトウェアサービスが星の数ほどあります。

その結果、エコシステムでは、様々なサービスの有機的な組み合わせが常に生まれており、それらは現在のビジネスニーズを満たすだけでなく、新たなビジネスの創出にも寄与しています。この傾向は、ＩｏＴ化が進むとさらに加速するでしょう。

日常的な場面でも、１社のソフトウェアサービスだけでは情報や機能が不足し、複数社のサービスを組み合わせて使っていますが、その割合が増えてきました。

ただ、複数社のサービスを使用するとき、仮にそれぞれを独立して使用しなければならない場合はかなり不便です。そこで便利に使うため、ユーザーは自分の権限やデータを複数のソフトウェアに委譲し、ソフトウェア同士が連携できるようにします。このようにする使い方も増えてきました。

その結果、便利さは増し生産性は向上するのですが、その裏で、認証・認可にかかわるリスクが次第に増大しつつあります。正しく理解して使いこなさないと、いずれ情報セキュリティ事故を起こすことになるでしょう。

上記の話は抽象的で分かりにくいと思うので、身近な例で説明します。

今、あなたは、Ａ社のクラウドサービスを契約しており、大きなデータ保存領域を使える権限を持っています。そこに大量の写真データを保管しており、今、Ｂ社の写真印刷ウェブサービスを使い、綺麗な印刷をしたいと考えているとしましょう。

あなたは、Ｂ社の写真印刷サービスを使うために、ユーザーＩＤとパスワードを入力し、Ａ社のクラウドサービス上に行き、そこで印刷コマンドを打ち込むと、プリンターから綺麗な写真が出力されました。

このような使い方をしている人は多いと思いますが、デフォルト状態では出来ません。異なる会社のサービスはそれぞれ独立しており、つながっていないからです。では、仮に、２つのサービスがつながっていない、ひと昔前の状態だとどうなるでしょうか？

まず、A社のクラウドサービスにログイン認証して入り、そこから印刷したい写真ファイルを自分のパソコンにダウンロードします。次にＢ社の写真印刷サービスにログイン認証し、ダウンロードした自身のパソコンのデータにアクセスし、プリントします。これだけでも面倒ですが、もし、３、４つのサービスを連携する必要があったら、本当に面倒な作業になりますね。

今日のサービスでは、SSO（シングル・サインオン）により、ログイン認証はＢ社の1社だけで済み、Ａ社のデータをわざわざ自分のパソコンにダウンロードしなくても、Ｂ社のサービスからＡ社のクラウドデータをアクセスして印刷することができます。

これができるのは、事前にあなたがＢ社のサービスに対して、Ａ社のデータ保管領域に入るための許可証を与え、しかも、対象の写真データを読み取る権限を与えたからです。

許可を与えたことは覚えていると思いますが、B社サービスにA社サービスに関する何の情報を与えたのか、どこまでの権限を与えたのか、はっきりと覚えていない人も多いのではないでしょうか？　　

SSOは確かに便利なのですが、このようなリスクがあるのです。例えば、B社に提供した情報の中に、A社サービスのログイン認証に使うＩＤとパスワード情報を与えていませんか？　もしB社のセキュリティが不十分でＩＤ情報が漏れたら、誰かがA社クラウドになりすまして侵入し、データを見たり持ち出したりする可能性があります。

B社のサービスに対してＡ社サービスの権限を与える際には、必ず許可を求める表示されます。しかし、その質問内容が曖昧な場合もあり、不必要に過大な権限を与えてしまうことが生じます。例えば、対象ファイルを印刷する以外にも、他の写真をすべて見る権限や、データを転送する権限などです。

このプロセスはエンドユーザーには分かりにくく、危険がいっぱいだと思っています。実は、この問題を回避するため、当社はマイクロソフト社のクラウドサービスに変えました。マイクロソフトのクラウドでは、他社のソフトウェアサービスに委譲する権限を細分化して提示し、何と何の権限を与えるかを明示します。過大な権限を与えないことに配慮しており、ここのクラウドを使うことをしました。

SSOを利用する際に重要となるのは、認証時のユーザーＩＤと認可する権限内容ですが特にＩＤは重要です。「ＩＤの重要性など常識だ！」という反応が返ってくると思いますが、実はＩＤの定義を本当に正しく認識している人は意外に少ないのではないかと思います。

リアルな世界と違い、インターネット上で貴方が本当に貴方であることを証明するのはかなり難しい問題だからです。「ユーザーＩＤとパスワードを知っている人は必ず貴方だ」と言い切ることはできませんよね？

ビジネスでも私生活でも、サイバーフィジカルな世界に関わらざるを得ないならば、ＩＤの定義を正しく理解する必要があります。

ＩＤはユーザーの実在性、正当性を示す情報の総体を意味しますが、ここでは、インターネットの使用を意識し、あえてデジタルＩＤと呼ぶことにします。そして、デジタルＩＤの中のほんの一部が前述のユーザーＩＤとパスワードです。

デジタルＩＤの中には、他人の知らない情報が多数含まれています。パスワードはその代表例ですが、そのような情報をクレデンシャル情報と呼び、それを知っていることで、アクセスしている人やモノの真正性、正当性を証明します。

人間の場合では、性別、生年月日、住所、マイナンバー、パスポードナンバー、車の免許証、健康保険証、クレジットカード番号、パスワード、生体情報（指紋、顔、虹彩、DNA、歯型）、電話番号、勤務先会社、社員番号などの１つ１つがデジタルＩＤを構成する要素です。

IoTの時代となり、人間ではないモノも、人と同じようにインターネットを使うようになりました。モノの場合、製造元、製品番号、シリアル番号、製造年月日などがデジタルIDを構成します。モノによっては、これらの情報について偽造や改ざんを出来ないようにする特別な装置や仕掛けが付加されています。

我々はインターネット上で何気なくユーザーIDとパスワードを使ってサービスを受けていますが、そこに至るまでに少なくとも３段階のチェックが実施されています。それは、「識別」、「認証」、「認可」の順番で進んでいきます。　　

最初の「識別」では、サービスを受ける前に、実在する本人（あるいは本モノ）とユーザーIDが紐付いているかどうかを確認します。

「ユーザーIDとパスワードだけで十分だ」という人がいるかもしれませんが、これだけだとソフトウェアロボットが本人になりすますことが出来てしまいます。重要な個人情報や金銭を扱うサービスでは明らかに不十分です。「識別」は、特に念入りに行う必要があるプロセスなのです。

「識別」において本人の真正性が確認されたら、次は「認証」です。デジタルIDの中のクレデンシャル情報を用いてユーザーIDの正当性を示すプロセスです。このクレデンシャル情報は大きく３つに分類されています。

第１はユーザーの記憶による情報であり、その代表がパスワードです。第２はユーザーが所有しているモノと関連づけられます。例えば、サービス利用先から配布されたワンタイムパスワード生成用カード、スマートフォンに紐づいたSMSや電子メール、あるいはスマホにインストールされた認証ソフトなどです。第３はユーザーの身体的な特徴に基づくものであり、その代表が指紋や顔の情報です。

最後の「認可」では、認証された後、このユーザーに対して、どこまでのサービスを提供するか、その権限の割り当てをします。認証を経ずに認可をすることも可能ですが、そうなると、ユーザーIDさえ知っていれば、誰でもそのサービスのすべて（例えばデータ消去権限）を使えるようになってしまうため、問題となる場合が多いでしょう。

上記の説明だけではピンと来ない人もいるでしょうから、誰でも経験している事例を２つ挙げて説明します。マイナンバーカードの発行と、ネット銀行サービスの利用です。

マイナンバーカードの発行では、まず、住民票登録、税金の支払い記録などの情報に基づいて、マイナンバーカード申請用の書類が郵送されてきます。この段階が「識別」に当たります。

次はその書類を持参して市役所に行きます。その際、自分であることを証明するためにID証明書の提示が求められます。この段階が「認証」に相当します。認証に求められる証明書は顔写真付きのものを求められます。市役所の職員が顔認証をするためです。

もし、顔写真付きの証明書がない場合、２種類の提示が求められます。顔認証が出来ず、本人だと断定できないためです。しかし、本人でない人が、別系統の２種類の証明書を提示できる確率は非常に低いため、２種類を提示すれば「認証」されます。これは、最近耳にすることが多くなった「多要素認証」を実施しているわけです。

「認証」されると、次は「認可」に向けた申請です。カード発行の申請書を記載し、パスワードを登録し、写真撮影をし、地方公共団体情報システム機構（国と地方公共団体が共同して管理する組織）に宛てに郵送します。

「認可」されるとマイナンバーカードが発行されます。カードが市役所に届くと、公布通知書が郵送で自宅に送付され、それから電話でカード受領のための予約をしてから受け取りに行きます。

マイナンバーカードの場合には、上述したように「認証」プロセスが２回あり、「認証」に使う要素数も多く、確かに安全性が高いのですが少し過剰かもしれません。カードの送付は、個人的には書留郵便で十分だと思います。書留は、届くまでの中継地点で記録が残されトレーサビリティが確保され、最終的に手渡しされるためです。

マイナンバーカードに「認可」された初期の権限は、今のところ、個人や法人の税務の電子サービスや年金情報を確認できるくらいです。私自身は恩恵を感じていますが、人によっては物足りないかもしれません。

マイナンバーカードがあなたの所有品になると、今度はあなたが、マイナナンバー情報を活用するソフトウェアやサービスに対して「認可」を与える立場に変身します。

例えば、カードを健康保険証にも使いたいならば、あなたが「認可」すれば使えるようになります。また、確定申告で、生命保険会社から保険料支払いの電子証明書を受領したいならば、マイナポータルで連携を「認可」すれば受領できるようになります。

さて、ここから２番目の例であるネット銀行サービスに移ります。まず、口座を開く所で「識別」のプロセスが実施されます。この部分は前述のマイナンバーカードの手続きを少し簡略化した形で行われ、ワンタイムパスワードを生成するカードが本人住所宛てに送付されます。（確か、書留だったと記憶しています）

ネット銀行のログイン認証では必ず多要素認証が求められます。銀行によって多少の差はありますが、ユーザーIDとパスワードによるチェック、電子証明書（SSL証明書）によるチェック、生体情報によるチェック、そして、最後に銀行発行カードで生成したワンタイムパスワードによるチェックが行われます。

ログインすれば口座残高を見ることは認可されます。しかし、送金等の取引サービスは認可しないのが普通です。取引サービスの認可には、別のパスワードによる認証が行われます。面倒ですが、認証と認可がしっかり分離されている良い例です。

いかがだったでしょうか？　２つの例は、単一のサービスを提供するものであり、シンプルなものです。しかし、かなり面倒な手続きをしています。一部、過剰なプロセスもないわけではありませんが、必要だから実施しているのです。

上記の例に比べると、複数のソフトウェアサービスを連携させる際の手間の少なさは気になりませんか？　サイバー世界でもフィジカル世界でも情報セキュリティの重要度は変わりません。ですから、気にするのは正常な反応だと思います。

サイバー世界でも、識別・認証・認可をフィジカル世界に近づけようとする取り組みが先進認証・認可プロセスとして出始めています。次回はそこに重点を置いて議論したいと思います。

今回は、SSOという便利さの裏の仕組みを十分に理解してチェックしないと、危ないぞという話をしました。この話をしたのは、当社が重視する製品の安全性を確保するために情報セキュリティの重要性が増しているからです。

貴社はサイバー・フィジカルな世界の両面で製品の安全性を確保できていますか？