トレンド

【連載企画第二弾(第二回)】「認証」で本当に通じている?

Written by 香山 哲司

ジーブレイン株式会社 コンサルティング事業部 シニアコンサルタント(2019年6月~)
2001年、マイクロソフト株式会社(現、日本マイクロソフト株式会社)に入社、エンタープライズサービス部門に所属。
電力・ガス会社、また政令指定都市向けの大規模環境における認証基盤やスマートカード導入の支援を中心的な役割で担当。
2007年CISSPを取得後、
2010年7月(ISC)2より第4回アジア・パシフィック Information Security Leadership Achievements アワードを受賞。
2019年からは、独立行政法人情報処理推進機構(IPA)が運営している国家資格の情報処理安全確保支援士の集合講習認定講師としても活動。

【連載企画第二弾(第二回)】「認証」で本当に通じている?

関連記事

【連載企画第二弾(第一回)】ゼロトラストネットワークから紐解く「認証」が重視される理由

第1回では、ゼロトラストについて筆者なりの解釈や考察を行い、あらためて認証が大切であることの序章として解説しました。コロナ禍をきっかけに新しい時代に相応しいセキュリティ対策として注目され、盛んにその意義が解説されています。そして、目標としていることはここ数年来のサイバー攻撃による教訓から得たものと大きく違いはないと考えています。

具体的には、これまで重点管理策だった境界セキュリティ対策、特にネットワーク技術を応用するセキュリティ対策からデバイス自体のセキュリティ強化や認証の強化に推移してきている点です。第2回は重要なキーワードの「認証」そのものの考察とよくある誤解について解説を進めます。

いたるところに認証

郊外まで足を延ばす機会があると工業団地、工場が立ち並ぶ場所を通ることがあります。そこには、「ISO9001認証取得」といった看板を見かけることがあります。品質管理がしっかりしている工場であることをアピールするためかと思います。

情報セキュリティの世界でもISO27001(ISMS認証)は、情報セキュリティ対策を継続して実施していることを外部に示し、取引先企業や顧客への信頼感を高めるため、企業・組織の自社ホームページに認証取得したことが記載されていることを見かけます。

第三者機関に申請し審査を受け、審査条件を満たし認証されるわけですが、この場合のISO認証の証としての書面にはCertificateと記載されています。

少々古い話ですが、中学生の時はじめて英検の試験を受け無事合格し送られた合格証にもCertificate と書かれており、中学生当時は意味がわからず辞書で調べたことがありました。あれからもうずいぶん年月が経過していますが、現在の英検の合格証明書のサンプルを調べるといまもそのように記載されています。

一方普段の生活に目を向けると、最近はスーパーや衣料品店の買い物も業務効率化、非接触対応、スタッフの負担削減などを目的としてセルフレジを見かけることが多くなりました。自分で商品のバーコードを読み取り料金をクレジットカードで支払いをすると、ここでも「認証されました。」(「承認されました」のケースもあります)と表示されたり音声が流れたりします。またも、認証が出てきます。ここではカードが本物であることや、毎月きちんと支払いをしている、上限金額に達していないなどのチェックになります。しかし適切な表現がないせいか、あるいは概念があやふやなままなのか認証が出てきます。

そしてIT屋として馴染のある「ユーザーIDとパスワードで認証」です。最近ではパスワードだけでは安全ではないので、スマートフォンなどを利用した多要素認証を必須にしましょうと、さらに認証が出てきます。
PKIの分野では デジタル証明書を発行する機関をCAと呼び、しばしば認証局と表現されますが、これもCertificate Authorityのことです。こうしたデジタル証明書を発行するサービスを電子認証サービスとも呼ばれています。

前提知識がない人にとって、認証って何?と思うほどさまざまな場面で使われます。その分野の専門家や高い関心を持つ人の中で暗黙に意味が固定されてやりとりされているか、文脈によって無意識にどの意味で使っているのか区分しているのが実態ではないでしょうか。

認証=基準を満たしたことの証
認証=デジタル証明書発行
認証=本人確認(デバイス確認)

ほかにもあるかもしれませんが、情報セキュリティを本質的に理解する上で大変重要な用語であるにも関わらず出発時点からすでにボタンの掛け違いが起こっていることがあります。
コロナ禍で行政のデジタル化の遅れ、企業においてもデジタル化の成熟度によってITの利活用に大きな差があることが浮かび上がりました。

技術的な課題もさることながら、ITや情報セキュリティにおいて最も重要できちんと議論されるべき「認証」は、多用されるもののこうした微妙な意味の違いを整理されないことが散見されます。大げさに言えば日本語の不幸とさえ思える状況です。

おそらく自分が英検をはじめて受けた年齢の時の知識で「IDとパスワードで認証」と言われれば「合格するかなぁ、、、やった!登録していたIDとパスワードが一致したから合格した!」と思っているはずです。少々滑稽な理解です。

Authentication ! Authentication ! Authentication !

大事なことは3回言うというのは、少々くどいかもしれません。今回の連載における認証はAuthenticationを訳した場合の認証で、平たく言えば本人確認です。つまり「誰であるか?」を確認するわけですが、実際には人の認証とデバイス認証などもあり必ずしも人間だけが対象でははありません。

日本語の認証は、いろいろな切り口で似て非なる意味を持ちますので、前述のような注意が必要です。「デジタル証明書で認証する」は Digital Certificate でAuthentication するということになるのですが、先ほどの訳を機械的にあてはめると「デジタル認証で認証する」となってしまいかねず、いったい何のことかさっぱりわからなくなります。余談ですが、経験上PKIが苦手という人が案外多かったのですが、公開鍵方式が少々トリッキーであることに加えてこのあたりも一因しているように感じています。

さらに認証がやっかいな理由の1つが、ITの世界でのAuthenticationにも大きくわけて2つの区分があることです。ローカル認証とネットワーク認証の違いです。
象徴的な事例をご紹介したいと思います。

あるPC修理業者とやりとりがあり、管理者パスワードを伝えたところどうしてもログオンできないと言うのです。

パスワードを詳細に伝えるために 富士山のF 数字の1(アルファベット小文字のlではない)などのように齟齬が発生しないように分解しながらできるだけ正確に伝わるように詳細に伝えてもログオンできないとのことなのです。

もしかしたら「英語キーボード、日本語キーボードの配列の違い?」とありがちな点も確認しましたが、そこも問題ありませんでした。
ふと「ローカル認証とネットワーク認証」を混同しているのでは?を思い出しました。
以下のWindowsにサインインする画面が具体例と言えるでしょう。

左側のユーザー名を入力するフィールドには user01@test.onmicrosoft.com いわゆるUPN(User Principal Name)の形式で表現され、サインイン先;職場または学校アカウントとなっています。あまりなじみのない画面かもしれませんが、これはAzure AD Joinをした端末がインターネット越しのクラウドサービスAzure ADに対してサインインしようとしたもので、ネットワーク認証する先ともいえます。

右側のユーザー名を入力するフィールドには .¥AdminUser001(実際には異なるアカウント名です)としています。これも一般にはあまりなじみのない表現かもしれませんが、このコンピューターに明示的にサインインする場合の方法です。サインイン先が、先ほどの「職場または学校アカウント」ではなく「MACHINE02」となっていることがわかります。MACHINE02とはこのコンピューターのマシン名であり、ローカル認証する先ともいえます。

もうおわかりかと思いますが、修理業者はサインイン先;職場または学校アカウントとなっている状況のまま AminUser001と入力していたため、「そのようなアカウントはAzure ADには存在しない」ことが認証エラーの原因であり、パスワード間違いではなかったのです。もっと早くサインイン先がどこかを確認すべきでした。
.¥をユーザー名の前に入力してもらうことですんなり解決でした。

ローカル認証とネットワーク認証の違いを簡単に図で示すと以下のように表現できます。端末自身にアカウントが登録されている、ネットワーク越しのサーバーやクラウドサービスにアカウントが登録されているかの違いがあります。

筆者の経験範囲ではありますが、Azure AD Joinで運用している事例は極めて少ないように思います。MS365自体はかなり普及していますが、たいていの場合、オンプレミスにADが存在し、Hybrid Azure AD Joinとして構成される場合、もしくはAzure AD Registeredとして構成される場合が多いようです。Azure ADアカウントのUPN形式で直接サインインする事例は少ないのでしょう。

以下の画像はAzure ADポータルの一部です。当該デバイスがどのタイプでAzure ADに結合されているかを示したものです。赤枠部の「統合の種類」では”Azure AD joined”となっていますので、Azure ADアカウントでサインインできる環境になっていることを示しています。

さて、具体例としてWindowsを例としましたが、これがスマホ利用であれ、Webアプリケーションであれ、DBを利用する業務アプリケーションであっても同様です。

ローカル認証とネットワーク認証はしばしばきちんと区分されず、「認証が重要」とざっくりとした目標になりがちです。

認証強化の象徴とも言える「生体認証」や「多要素認証」などもそれぞれどのようなメカニズムなのかを把握したうえで、どのリスクを低減しようとしているのかきちんと整理した上で採用すべきソリューションも変わってくることになります。
しかし、現実によくある議論は、

・顔認証・指紋認証のどちらが本人確認手段としてすぐれているか?
・利便性を損なわないのはどの方式か?
・普及していて、シェアが高いのはどの方式か?

こうした観点での議論になりがちです。しかしこれらを分析したところで、どのようなリスク低減を目指しているのか部分的にしか浮かび上がってきません。

次回は、2段階認証、2要素認証;多要素認証の気になる点をさらに分解して解説していきます。