POP3やIMAPは、言わずと知れた標準的なメール受信プロトコルですが、Google Workplace(旧G Suite)やMicrosoft Exchangeで、今後、継続利用していくことが難しくなってきました。
POP3やIMAPは１度きりのBasic認証であり、パケットスニッファ等による認証情報の盗難や中間攻撃（マンインザミドル）に遭いやすく、その抜本的なセキュリティ対策に向け、各社が足並みをそろえて動き始めたためです。
具体的には、アクセストークンを利用する「OAuth 2.0」を今後は主体的に使っていきましょう、という流れになっているのですが「ちょっと待ってよ、それって何？」と、サーバ管理者もクライアント側も、寝耳に水です。
そこで今回は、OAuth2.0の仕組みと、それらの導入に向けたGoogle Workplace(旧G Suite)やMicrosoft Exchangeの動向などをご紹介していきます。
OAuth2.0とは何だろう？アクセストークンの仕組みについて
OAuth2.0を解説する前に、POP3/IMAPの認証フローを解説いたします。
上記のように、クライアントがメールサーバへ受信メールを要求する際は、メールサーバ本体からパスワードを要求されます。
この①～④のフローは「単一の通信元先で実施される」「ID/パスワード等の認証フローまでもが、暗号化されないままパケットに乗って運ばれる」という、攻撃側の視点からすると「目標が決まっており」「タイミングと条件に寄っては、安直にパケットスニッファが仕掛けられる」という環境であったため、脆弱性が懸念されていました。
BASIC認証とOAuth 2.0の大きな違いは、認証先がメールサーバではなく「認証を目的とした、認証サーバに委ねられること」と「メールサーバへの認証には、アクセストークンが必要になること」です。
認証サーバは認証ID/パスワードにて認証を果たしたクライアントに対し、該当IDを持つユーザの携帯電話や「予め登録しておいたE-mailアドレス宛て」「ブラウザ経由の通知」に「このクライアントへのトークン配布を許可してよいか？」確認通知を送ります。
Gmailなどにおいて、認証コード通知メールが送信されてくる理由が、ここにある訳ですね。
この確認通知を、「認証コードの入力」等によって許可した時にのみ、アクセストークンをクライアントに付与します。
クライアントはこのアクセストークンをもとにサーバへ問合せ、データを受領するというわけです。
OAuth2.0のセキュリティと、導入すべき理由
現在でもリアルタイムにニュースで取り上げられるセキュリティ事件とその損害額が目に付きますが、もはや誰の目にも「他人事ではない」ことは明らかです。
いち早くOAuth2.0として標準化された認証機構は、下記のような多くの強みを持つに至りました。
「認証サーバ＝データサーバ」ではない
認証サーバとデータサーバが同一であれば、認証フローからデータの授受状況までもが、盗聴の被害に遭う確率が高くなります。
前述でも、POP3/IMAPの認証機構は、ここが最大のネックだったのですが、認証サーバが切り離されることで、そのセキュリティリスクが各段に軽減されました。
アクセストークンは、いつでも廃止/更新できる
アクセストークンが外部に漏れることで、データの盗聴などの被害に遭う可能性は拭えませんが、このアクセストークンはID/パスワードと違い「ID/パスワードとは別に、いつでも破棄や更新が可能」なのです。
しかも、定期的に更新を続けることで、このアクセストークンは真新しい物へと入れ替わり、「定期的にパスワード変更」することに近い状態を保つことができます。
認証サーバは、対象メーラー以外のアプローチ対象で、認証確認を問い合わせる
新しいスマホ等のGmail等へのログイン時によく尋ねられるかと思いますが、認証サーバは、ID/パスワードによるログインの際には、ユーザの持つE-mailアドレスや携帯電話へのショートメッセージに「認証コード」なるメッセージを送付します。
アクセストークン発行時には、その認証コードを入力しなくてはならなくなりますが、これは「偽証しようとしたクラッカーが持たないアプローチ方法」になりますので、なりすまし対策に大変有効な認証方法となります。
OAuth2.0の今後の運用とは？Google Workplace(旧G Suite)/Microsoft Exchangeの動向
OAuth2.0が主体的に運用に乗り出した際は、クライアントとの認証機構が大幅に切り替わってしまいます。
上記、２パターンを用意しましたが、企業が採用しているメール機構はこの限りではありません。
アクセストークンの運用方法
しかし、上記いずれにも言えてしまうことは「クライアントがメールを送受信するためには、Google Workplace(旧G Suite)/Microsoft Exchangeが発行した、アクセストークンが必要となる」ことです。
運用管理上、このアクセストークンをどのように運用するか？が悩みの種になってしまうのです。
①アクセストークンは、管理者自らが発行し、提供する
②アクセストークンの利用に、社員のアカウントか、部署の共通スマホ等を用意し、各ユーザ認証の宛先とする
一般的な運用管理では、上記２パターンの運用が主に採用されていますが、①も②も、企業のスタイルに合わせるのが難しいのが現状です。
OAuth2.0の各社取り組み
なお、GoogleもMicrosoftも、法人向けのグループウェアに対し、OAuth2.0採用を積極的に提案し、これまでのBasic認証の廃止を予定しておりましたが、近年のコロナ騒ぎの影響で、廃止までの期間が長引きました。
それぞれのBasic認証廃止時期を、下記に示します。
【Google Google Workplace(旧G Suite) – 2021年2月15日期限】
https://gsuiteupdates.googleblog.com/2019/12/less-secure-apps-oauth-google-username-password-incorrect.html
【Microsoft Exchange – 2020年10月31日期限】
https://docs.microsoft.com/ja-jp/lifecycle/announcements/exchange-online-basic-auth-deprecated
なんと、もう猶予がありません。
従来のOutlookでメール送信が出来なくなる日
上記のグループウェアを採用している運用管理者は、全力でOAuth2.0対応に乗り出す必要がありそうです。
クライアント側のメーラーも、上記期日以降の認証時には、必ずOAuth認証を求められてしまうわけです。
Outlookであれば2016以上のバージョン、その他のメーラーでもAOuth対応でないとメールの送受信ができない日が近々やってきます。
OutlookメーラーでOAuth認証を実施してみよう
取り急ぎ、運用方法等は差し置いて、応急処置的に「OutlookによるOAuth認証」を行う手順を解説いたします。
以下手順においては、Outlook365にてGmailアカウントへOAuth認証してみました。
①Outlookの「ファイル＞情報＞アカウントの設定」へ推移し「メール」タブの新規を押下します。
（編集、で、既存設定を選択する形でも構いません。Gmailの場合、既にOAuth認証済であることもあります。）
②E-mailアドレス（Gmail）を入力すると必ず「問題発生した」通知（OAuth認証失敗）が出ますので「アカウント設定変更」へ推移します。
③アカウントの設定画面で「接続」ボタンを押下すると、別ウインドウ（ブラウザ）で、Gmail認証画面へ推移し、対応するアカウントとパスワードを求められます。
OAuth認証においては、認証先E-mailボックスへの通知であったり、携帯電話への認証コード通知であったり、様々なアプローチ方法があります。
④ログインに成功すると、Googleからの「アクセス許可」確認が行われます。
「許可」すると「アカウントが正常に追加」通知が出ますので、これで認証完了です。
以上のように、ユーザサイドからすると「認証アカウントや端末等」さえ用意しておけば、OAuth認証は、さほど難しくありません。
まとめ
メールの送受信で従来のPOP3やIMAP, SMTPはなじみの方法でしたが
コメント