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

2023.03.26 コラム

インターネット上でのウェブサービスやアプリサービスは、通常、その１つ１つのサービスの機能は限定されています。これに対してユーザーは、できれば一つの場所でまとめて仕事を片付けたいと思う傾向があります。

そのため、サービス提供側がスピーディーにユーザー利便性を高めようとすると、必ず相互連携が必要となります。ただ、相互連携を行おうとすると、そこには、面倒な認証・認可プロセスが待ち構えています。

ユーザーは面倒さを嫌うので、この認証・認可の問題を解消するために、自動化が進むことになります。自動化によりユーザーは利便性を得られるのですが、これまでは、その代償として自分のデータを差し出してきました。

しかし、サイバー空間内での犯罪が急増し、データが盗まれて悪用されるリスクが増えてきました。加えて、それらを問題視した当局は厳しい規制を課すようになり、ユーザーのデータの扱いを間違えるだけで、多大な違反金を支払わなければならない場合も出てきました。

ユーザーのデータはビジネスに役立ちますが、データを持つことが企業リスクになることも考慮しなければならなくなりました。

前回は、サイバー世界での認証・認可のプロセスの重要性を認識するために、あえて現実のフィジカル世界での認証・認可のプロセスであるマイナンバーカード取得等を例にあげ、申請から取得までの個々のプロセスの意味を確認しました。

フィジカル、サイバーのどちらの世界でも認証・認可のプロセスは等しく重要なはずですが、フィジカル世界での厳格性と比べて、サイバー世界でのプロセスが少し緩いのではないかということを指摘しました。

緩くなりやすいのはなぜでしょうか？　大きな理由の１つとして、サイバー世界の方がフィジカル世界よりも関係者が多くて複雑だということが挙げられます。現実世界では登場者は人間だけであり、しかも人間は思考力・判断力を持つ優秀な存在です。

これに対してサイバー世界では、人間以外にも、ウェブサービスやアプリのようなソフトウェアがあり、また、コンピュータ、ストレージ、ネットワーク機器、センサ等のハードウェアがあります。

つまり、情報セキュリティを守るということは、人、ソフトウェアおよびハードウェア間に信頼関係を構築することと言い換えることができます。仮にソフトウェアやハードウェアを擬人化して考えると、人間の数の数倍の関係者がいることになります。

しかし、これら関係者のコミュニケーション能力や思考力は非常に限定されていて融通が利かず、人間と比べると大きく劣ります。話が通じない相手と協力しながらセキュリティを守らなければならないので、相当に面倒なことだと言えます。

サイバー利用の大目的はフィジカル世界の生産性の向上ですが、とは言え、セキュリティを犠牲にして良いわけはありません。今後、製品のIoT化、自動化、無人化が進むと、セキュリティが製品運用の安全性にも影響を与えることが予想されます。

ＩｏＴ化が進む状況を受け、サイバー世界での認証・認可の緩さが問題視されるようになり、厳格性を高める活動が進行中です。その核となるのが先進認証・認可のプロセスであり、今回はこれを中心に議論します。

現在の標準的なウェブサービスにおける問題がどこにあるかを確認するために、やさしい具体例で考えてみます。

今、あなたは企業の担当者であり、ユーザーの問い合わせに回答することが仕事だとします。そのツールとして、問い合わせフォームのウェブアプリＡと、それに返信するための電子メールアプリＢを使用します。ただ、これらのアプリは別々の会社が作成しており、事前には相互につながっていません。

ユーザーは問い合わせをする際、自分のEmailアドレスをIDとして使い、他者のなりすましを防ぐためにパスワードを記入し、問い合わせ内容を送信します。すると、アプリAは、ユーザーEmailアドレス、パスワードおよび問い合わせ内容を紐づけてデータベースに保存します。

あなたはアプリAに入り、問い合わせに対する回答を記載して保存します。そうすると、アプリAは、先ほど作成したユーザーのデータベースに回答内容を追加します。

仮にこの段階でユーザーが自分のEmailアドレスとパスワードを使ってアプリＡにアクセスすれば、企業の回答内容を読むことができるでしょう。しかし、それはユーザーの手間になるため、通常は、企業が電子メールで回答内容をユーザー宛てに送付します。

もしアプリAに電子メール機能があれば、アプリAだけでユーザーに回答を送信する所まで出来るのですが、あいにく電子メール機能がありません。そのため、企業は、他社のアプリBを使って返信する必要が生じます。

アプリBがユーザーに対して、企業の回答内容を電子メールで返信するには、アプリAの作成したデータベースに入って、必要な情報を入手しなければなりません。

一番簡単な方法は、アプリＢはアプリＡから、ユーザーのEmailアドレスとパスワードを教えてもらってデータベースにアクセスし、必要な情報を得るやり方です。でも、これは、アプリＢがユーザーになりすまして必要情報を入手したとも言えます。

ユーザーの許可を得ずにこれを行うと違法ですから、アプリAは問い合わせ時にユーザーに対して、アプリBがユーザー情報にアクセスすることの許可を取る必要があります。アプリAは、おそらく、「アプリBがお客様情報のアクセスを許可しますか？」という類の質問をしてくるでしょう。

もし、NOと回答すると問い合わせができなくなります。YESと回答すると、ユーザーのEmailアドレスとパスワードがアプリBに渡り、アプリBはその情報でアプリＡのデータベースにアクセスし、企業の回答をユーザーに返信します。

上述の仕組みは一種のSSO (シングル・サインオン)ですが、問題はユーザーの許可を取ったとはいえ、ユーザーのクレデンシャル情報であるパスワードをアプリBに渡してしまうことです。

仮に、アプリBからパスワードが漏れれば、他者がユーザーになりすましてアプリＡのデータベースにアクセスできてしまいます。もし、ユーザーが同じパスワードを別のサイトやアプリでも使用していたならば、そこでもなりすましが行われることになるでしょう。

実はまだ、上記と類似のことを実施しているウェブサービスが多数あります。一部の情報インフラ会社は、現状の仕組みの持つ脆弱性を問題視し、利便性を維持しつつもユーザーのクレデンシャル情報を他社に渡さない方式に変わりつつあります。

従来型と区別するために先進認証などと呼ばれています。この仕組みでは認証と認可を分離しており、採用すればセキュリティは確実に向上します。

先進認証の特徴は２つありますが、上記の例に当てはめて説明しましょう。１番目は、アプリＡに入る際、ユーザーは、パスワードによる単段認証ではなく、多要素認証をして入ることを求められるようになります。これはすでに一般化しつつありますね。

多要素認証には、３つの型、すなわち、ユーザー記憶ベース、ユーザー所有機器ベース、ユーザーの身体的特徴ベースの中から、２つ以上の異なる型を組み合わせる方法です。ポピュラーなのは、パスワードとスマホ認証の組み合わせや、ユーザーの顔（あるいは指紋）とスマホ認証を組み合わせる場合が多いようです。

２番目の特徴は前述しましたが、アプリＡはアプリＢにユーザーのクレデンシャル情報は渡さないことです。これは重要なことです。では、アプリＢはどうやって、ユーザーの連絡先や問い合わせに対する回答の情報を入手するのでしょうか？　

それには、まず、企業の担当者がアプリＡにアプリBを登録します。その際、アプリBに対してアプリケーションIDを発行します。また、同時に、アプリBがユーザーのデータベースにアクセスするためのパスワード（アクセストークンなどと呼ばれる）を発行します。これらはユーザーのクレデンシャル情報ではありません。

特にこのパスワード（アクセストークン）は英字の大小文字と数字を組み合わせた数百字から構成されています。とんでもない長さのパスワードです。しかも、時間制限付きです。制限時間は調整可能であり、標準的には１時間から数ヶ月の間で設定されます。（原理的にはどのようにでも設定できます）

企業の担当者が、アプリBにそのIDとパスワードをセットすると、アプリBはユーザーのデータベースにアクセスでき、問い合わせの回答を電子メールで送信し、ミッションは完了します。

上記は、セキュリティが適切なSSOの例です。このSSOですが、４つの方式があります。エージェント方式、リバースプロキシ方式、代理認証方式、およびフェデレーション方式です。すべてを説明すると長くなるので、ここでは、主流になりつつある代理認証方式とフェデレーション方式の２つに触れます。

代理承認方式は、ユーザー側のパソコンすべてに常駐型エージェントを導入し、そのエージェントがSSOサーバーと認証・認可のやり取りを行う方式です。一元管理が可能ですが、クライアント・ユーザの数が増えてくると、全エージェントが通信するので、ネットワーク上の問題が生じて反応が悪くなる場合があります。

フェデレーション方式はIDを認証するプロバイダによって認証されたユーザー情報をサービス提供側に安全に受け渡すことを目的とした方式です。当然、識別としての事前の登録が必要であり、その際に、複数のサービスの間で必要なユーザー情報がやり取りされます。

上述で説明したアプリA,Bの例はこの方法であり、最近、勢力を増してきているOpenID Connectプロトコルを使った方法です。

SSOを使用する際に忘れてはならないことは、連携するアプリに対して与える権限を必要最小限に限定することであり、ユーザーに対してもそれが明確に示して許可を得ることです。あるクラウド会社では、権限移譲をすべて記録に残し、裁判での証拠として提出できる所まで配慮しています。

ただ、権限を細分化し、細かく表示している会社はまだ少数であり、連携するアプリに過大な権限を与えている場合が多いですね。そのアプリからユーザー情報や企業の秘密情報が漏洩すれば、社会問題になるでしょう。

当然ですが、ユーザー情報の管理責任がある企業の役員は、善管注意義務を怠ったとされ、もし、大きな経済損失が生じた場合、あるいは、漏洩問題で株価が大きく下がった時には株主から訴えられることになるでしょう。

当社は製品の安全性を守るためのコンサルティングをする会社ですが、情報セキュリティが安全性に及ぼす影響が増えてきているため、両者が公差する部分についてもサポートしております。