Office365「Windows接続済み」で自動ログインする件

■EdgeブラウザでOffice365に自動ログインしてしまう

Office365にサインインした時に、「組織がデバイスを管理できるようにする」とした場合（詳しくは前の記事へ）、認証情報がWindowsOSの「アカウント」に登録されます。更に「Azure Active Directory」の「デバイス」に端末情報が登録されます。この状態でEdgeブラウザからOffice365のサインインページに飛ぶと、パスワード入力などユーザが認証操作をすることなくログイン後ページが開きます。
※自動ログインの解除については「前の記事へ」に記載しています。

ブラウザのCookieやローカルストレージのファイルを消してもなお自動ログインができるため、WindowsOSに登録された認証情報を利用してログインしているのだろう、という事は想像できます。

■実際のシーケンスについて

実際のシーケンスがどうなっているかEdgeブラウザのツールで覗いてみました。詳細かつ正確なことは分かりませんでしたので想像します。

• Request-Headesに「authorization」が入っているシーケンスを見ると「graph.microsoft.com」というHOSTにアクセスしている。
• 「要求URL」が「https://graph.microsoft.com/v1.0/me/drive/root」となっている。

■Microsoft Graph について

OSに格納した情報を利用して「Office365の認証を行っている」、或いは「この「graph.microsoft.com」へのアクセスを行っている」のは何となく分かりますが、この「graph.microsoft.com」へのアクセスは一体何をしているのか？Webで手掛かりがないか、検索してみたところ以下のような情報が。

Microsoft ID プラットフォームから取得したアクセストークンを利用して「Microsoft Graph」を呼び出すと、「サインインしているユーザーのプロファイル情報」を返すことができる。

【Microsoft Graph の認証と承認の基本方法】
https://docs.microsoft.com/ja-jp/graph/auth/auth-concepts

もしかしたらOSが保持している「アカウント情報」は、この「graph.microsoft.com」へのアクセスキーやユーザIDなど、そんな情報なのかも知れません。

■そして想像してみる

「組織がデバイスを管理できるようにする」という設定を有効にすると、「Azure Active Directoryのデバイス一覧」に端末情報が登録され、その情報を毎回呼び出しているようなシーケンスを想像しています（デバイスが登録されているから認証OK的な？）。Windows10の「アカウント」-「職場または学校にアクセスする」から登録されているアカウントを「切断」すると「Azure Active Directory」の「デバイス」からも登録情報が削除されるので、以降は通常の認証に戻る・・・と想像しています。

想像だらけの内容になってしまいました。すみません。

—2021年4月追記—
多分、AzureADにデバイス登録すると「プライマリ更新トークン(PRT)」というものがOS上に格納され、この情報を利用すれば、すでに信頼済みとして扱われて認証なしにMS365にアクセスできるようです。

【参考：プライマリ更新トークン(PRT)について】
https://docs.microsoft.com/ja-jp/azure/active-directory/devices/concept-primary-refresh-token

boxのログインIDの変更について

boxではメールアドレスがログインID（ユーザID）となりますが、変更したい場合があると思います。

■ユーザ自身でログインIDを変更する

手順としては、以下になります。

①ユーザ自身で設定画面より「メールアドレスを追加」
②確認メールが飛ぶのでメールを確認
③登録したメールアドレスが「アクティブ」状態になったあとに表示される「プライマリに変更」をクリック

画面上部のユーザアイコンから「アカウント設定」を開くと「ログインとメールアドレス」欄で確認できます。

 

■管理者で変更できるの？

boxの管理画面では以下のようになっており、メールアドレスの追加は画面上ではできませんでした。

メーアドレス（管理画面上は「その他のメール」）の管理者による追加は、APIを利用すれば登録はできましたが、登録したメールアドレスをログインIDに変更（プライマリに変更）することもbox管理画面からはできないようです（変更するようなボタンが無い）。これもAPIを利用すれば出来るはずです（実際、試してはないですがユーザのUpdateで実施するのだと思います）。

【box API : Create email alias】
https://developer.box.com/reference/post-users-id-email-aliases/

【box API : Update user】
https://developer.box.com/reference/put-users-id/

 

以上、備忘録でした。

 

 

Office365とboxについて

案件で「Office365」と「box」の両方を利用するというお客様のご支援をしてますが、ユーザの利用環境がPC、スマートデバイスで、デバイスを固定したい、という要件がありました。そのため、クライアント証明書を利用したアクセス制御を実施しました。

その際、アプリとかOS標準機能でクライアント証明書が利用できるか否か調査をしたので情報を共有します。

 

 

最近のアプリはOAuthに対応しているものが多く、認証時には組み込みブラウザ（WebView）が起動します。ただ、そのブラウザが「クライアント証明書」を利用できるか？もっと言うと、OS領域に格納されている証明書にアクセスできるか？は実装に依存します。なので検証してみないと分からないというのが実情です。

boxはSSO設定を行っても、直接ログインとSSOでログインする中間の状態を保てるので、便利ですね。「完全SSOに移行」という設定を行うと全てIdPにリダイレクトされる動きになります。

多要素認証の誤った認識

様々な案件で多要素認証の仕組みを導入させていただいておりますが、以下のような質問をよくいただきます。

社内では利便性を考え、パスワード認証でOKとするが、社外アクセスにはOTP（ワンタイムパスワード）を要求したい。でも社内でパスワード認証を行った端末を社外に持ち出すとそのまま利用できてしまうのは問題だから、そのような場合にはOTPを要求して欲しい。

あくまで私が思っていることですが、これ、ちょっと誤った考え方だと思っています。

多要素認証を導入するのはアカウントが漏洩したとき、第三者が利用できない（利用を困難にする）仕組みであり、本人が利用している限り、認証済みであれば何処にいようとそのまま利用出来て良いのです。

Google、マイクロソフト、Amazon、Appleなどもその思想に沿って機能を実装してるんじゃないかと思います。なので「今後はこの端末を信頼する」などの確認を行うと、以降は追加で認証を求めなくなります。また、スマートフォン向けアプリ（FacebookとかTwitterなど）は一度認証すると利用している限り認証は求められませんよね。

繰り返しになりますが、本人が使っているなら追加で認証するのは面倒なだけなんです。端末を紛失したら・・・という部分はデバイス管理の仕組みで対処すべきです。

まあ、いろんな考え方があるので、これが正しとは一概には言えませんけど。

FIDO Web Authentication を利用してOffice365にログインする

■FIDO WebAuthnとは？
ユーザーの認証をパスワードではなく、指紋や静脈、顔や虹彩などの生体情報を使った認証や、比較的簡単なPINコードなどを用いて認証を行うことにより、長く続いてきたパスワード認証をやめて安全な認証を行いましょう、というのがFIDOの考え方です。

2019年4月の段階では「FIDO 2（ファイドツー）」となっています。更にこの「FIDO 2」をWebの分野でも採用していこうという動きが始まり、Webブラウザで「FIDO 2」に対応する標準仕様「WebAuthn」を策定、2019年3月にW3C勧告になりました。

既にChrome/Edge/firefoxなどのブラウザは「FIDO Web Authn」に対応していて、FIDO対応デバイスを利用した認証を仲介することができるようになっています。具体的な仕様について、以下のページを見ると詳しく解説されていますが、簡単に表現すると、G SuiteやOffice365をブラウザで利用しようと思ったときに、端末に接続されているFIDO対応デバイス（指紋認証デバイスやFIDO U2Fデバイス）をブラウザが検出して認証情報を渡してあげるようなイメージです。

【株式会社技術評論社:パスワードレス認証WebAuthnの勘所と対応状況】
https://gihyo.jp/dev/column/newyear/2019/webauthn

■今回の検証概要
Office365そのものはFIDO認証に対応していないので、フェデレーション構成を組み、FIDOに対応したIdP（IDaaS）を利用しました。なお、「Microsoftアカウント」へのサインインではFIDOデバイスを利用してログインする仕組みが用意されていますので、IdPが無くてもFIDO対応デバイスで認証することができます。

【用意するもの】
・「FIDO対応」の認証デバイス
・「FIDO WebAuthn」に対応したブラウザ
・「FIDO対応認証デバイス」に対応した認証サービス（IDaaSなど）

■結果だけ言うと・・・
具体的な設定手順は利用するIDaaSによって異なりますので割愛します。基本的にはIDaaSにFIDO対応デバイスを登録するだけだと思います。で、結果ですが、ブラウザを利用したアクセスではFIDO対応デバイスを利用した認証でログインできました。ただ、先進認証ではNGでした。つまり、OutlookなどOfficeアプリケーションの認証ではFIDO認証は利用できません。アプリケーションに組み込まれているWebViewがFIDOに対応していないのでしょう。どうしようもないですね。

■FIDO2 対応のスマートデバイス
FIDOアライアンスはAndroidがFIDO2認定を取得したことを発表しました。そのため、Android 7.0以降を搭載している互換性あるデバイスは、箱から取り出したその時点、あるいはGoogle Play開発者サービスの自動更新後に、FIDO2認定を受けている状態になるとのことです。

こちらもFIDOに対応したIDaaSを利用して試してみました。

AndroidデバイスとChromeを利用してIDaaSに接続、FIDO対応デバイスの登録を行いました。ちゃんとFIDO対応デバイスの検出をしてくれました。メニューを見ると、BluetoothやNFC、USBで接続しているFIDO対応デバイスも利用できそうですね。今回はパターン認証で登録してみました。

実際の認証時にも同じような画面が表示され「パターン」でちゃんと認証できました。

■まとめ
どうなんでしょう・・・現段階ではまだ微妙な印象を持ちました。特にOfficeアプリケーションやスマホアプリの認証でFIDO対応デバイスが利用できないとなると、まだ時期尚早かなと思います。Officeアプリケーションの先進認証が全てのアプリケーションに実装される前みたいな状況で、あれはできるけど、これはできない、となってしまっているので、足並みが揃うまで待った方が無難と（私は）判断しています。ただ、パスワード認証を無くそう！という流れは正しいと思うので、そう遅くない時期にFIDOが一気に普及するのでは、と思っています。それまではOTPを使いましょう。

Cloud Access Security Broker (CASB) が話題

Cloud Access Security Broker (CASB)という言葉を最近よく耳にします。

それは何か？と調べてみると・・・

1. 企業が使っているクラウドサービスを特定、格付けして変なサービス使ってないか、分析する。
2. 使ってOKのサービスを対象にデータ共有、損失防止の管理をする。
3. ユーザの行動分析と異常を検知して脅威から保護する。

という事らしいが、「２」番目は、クラウドストレージとかに機密情報ファイルをアップしていないか？権限は適切か？などをチェックするということで、その他は簡単に申し込めるクラウドサービスが多いので、変なものを利用していないかチェックする、という事なんだと思います。

※「２」番目の件に関しては、Googleのストレージに保存されたファイルの監視機能やAPIを提供しているので、この辺りの機能を指しているものと思います。

【Google Cloud Platform データ漏洩の防止】

https://cloud.google.com/security/data-loss-prevention/preventing-data-exfiltration?hl=ja

 

で、CASBが注目される背景を自分の人生に照らし合わせてみると・・・

• プロジェクト内で便利なサービスがあるよ！ってことで、特段気にせず「cybozu live」を使ってたけど、スケジュール表とか仕様書とか共有してたなー。でも2019年4月15日で終了するようで、ファイルとか削除しなきゃー、でもログインIDも忘れちゃったよー、大丈夫かなー。
• タスク管理に便利だからって「Trello」使ってますよー、無料だしー、でも案件の名前とか入れちゃってるよねー。
• Webサイトの分析したいので、「SimilarWeb」に登録してみましたよー、無料だしー。
• お客さんがBoxでファイル共有するから、無料アカウント作ったよー、でちょっと使ってみよー、意外に便利だねー。

という感じで、クラウドサービスをガンガン使っちゃってます。

多分、このようないわゆる「ジャドーIT」を見つけ出して、しっかり管理しないと駄目ですよ、という状況になってきたのでCASBみたいなものが必要になってきたのだと思います。

 

という事で、実際にちょっとだけ触ってみました。マイクロソフト社の「Cloud App Security」の評価版を申し込んでみましたが、ここでもアカウントを勝手に作って登録しちゃいましたｗ

内容としては「Cloud App Security」には、いろんなサービスを格付けしたDBを持っており、通信ログなんかを読み込んで、分析すると、危ないサービス利用してますね！というのが分かる感じです。ポリシーに違反しているログがあると警告を出したりすることも、もちろんできます。（多分、NW機器やFirewallなどと連携して、API経由でネットワークから遮断することもできると思います。）

■Cloud App Securityに登録されているクラウドサービスカタログ。スコアが記載されていて、自分のサービス（マイクロソフト社）のスコアはほどんど「10」（最高に安全）ですね！

 

■クラウドサービスをクリックすると、詳細な情報が見られます。以下はOffice365です。

■G Suiteは・・・スコア「9」ですか・・・赤い×マークがちらほら。

 

で、分析するログデータ（データソース）は自動的に取り込むこともできますし、手動でアップロードすることもできます。メジャーなNW機器のログファイルであれば事前に定義されているので、種類を選択して、ファイルをアップするだけで良いです。

 

■データソース取り込み画面。「Check Point」とか「Cisco」とか、結構あります。

 

 

■事前定義されていないファイルはカスタムログで取り込み可能。

 

■ログを取り込み、分析させると、素晴らしいレポートができます！

■ポリシーに引っかかるような通信はシャットアウトできますが、そのポリシーもいくつか事前に定義済みです。

 

という感じのサービスでしたが、ぜんぜん本格的に利用していないので、詳しいことはわかりません。ただ、規模が大きい会社ですと、必要になるものなんだろうと感じました。

見ていただいたようにCASBも単体で完結するサービスではなくて、NW機器やセキュリティサービスと連携して初めて可視化できるものなので、その意味でも比較的規模感のある企業向けのものかな、と思います。

CASBを調べていて、ふと思ったのですが、ログインIDとして「Facebook」や「Twitter」を利用できる（OpenID Connect）クラウドサービスが増えていますけど、認証シーケンス内で、属性情報を渡す同意をしてはいるものの、渡した情報って最終的に消してもらえるんですかね？って心配になります。

いや、消されないでしょう。サービスの作りによりますが「Facebook」から渡された情報を自分のID（自動発行）と紐づけして、DBに格納すると思いますが、例えばユーザが「Facebook」のアカウントを削除しても、渡されたサービス側は「Facebook」アカウントが削除されたことは分かりませんからね。実際、案件でも”そうなったら、ごみデータ”になっちゃうね、って話してますｗ

こういう「Cloud ID Management」サービスがあったら良いですね。具体的な実装のアイデアあるので誰か作ってください！

 

Adobe Creative Cloud とのSAML連携・クライアント証明書認証の検証

ある案件にて、Adobe Creative Cloud とのフェデレーションを行う検証をしましたので、メモ。
それとクライアント証明書を利用して端末を固定して認証できるかも検証しました。

■IdPの設定
・EntityID:　https://www.okta.com/saml2/service-provider/spxxxxxxxxxxxxx
・Assertion Consumer Service：　https://adbe-xxxxxxx-dot-com-7890-prd.okta.com/auth/saml20/accauthlinktest
・NameIDPolicy：　「urn:oasis:names:tc:SAML:2.0:nameid-format:persistent」
・AdobeCC側でのユーザ識別は「Named ID」の値を利用する仕様
→「Named ID」にユーザ名を入れること。
・姓名も必須属性としているが、実際は利用されていない様子。
→念のため、送付するよう設定。姓：「FirstName」　名：「LastName」

※xxxは実際のものに設定してください。他にも個別情報部分は適当に変えています。
※AdobeCCの管理者コンソールから、メタデータがダウンロードできるので、それを見るのが良いです。

■Adobe CC側の設定
・IdP証明書： IdPの証明書をアップロード
・IdP発行者：IdPのEntityIDを登録
・IdPログインURL：IdPのログインURLを登録
・IdPバインディング： HTTP-REDIRECT
・ユーザーログイン設定： メールアドレス
→Named IDの値がメールアドレス形式かチェックする、という設定らしい。。。意味あるのか？

ユーザが一番最初にやることは、Adobe サイトへ行って、ログインして、PhotoShopとか、アプリケーションをダウンロードすることです。これはOS既定のブラウザからアクセスするので、証明書の利用はできます。が、その後、アプリケーションのインストール時に認証が求められますが、これはアプリ内に実装された「WebView」を利用しており、証明書認証ができませんでした（証明書を選ぶ画面がでないです）。

【アプリインストール時に起動するWebView画面】

なお、iPad/iPhoneの場合、アプリのダウンロードはApp Storeからとなります。

とりあえずID/Passで認証を行い、アプリをインストールすると、ランチャーみたいなアプリが入ります。既に認証済なので、ログイン状態ですが、敢えてログアウトして再度、ログインを試みました。やはりWebViewが起動するので、証明書は利用できませんでした。

【Adobe CCのランチャー画面】

また、アプリを起動するとログインできるメニューがありました。Office365でもExcelとかの画面右上に「サインイン」とかありますよね。それと同じ感じです。こちらはOS既定のブラウザが起動するので証明書を利用した認証ができました。

【各アプリからのログイン】

試しにAdobeCCのランチャーからではなく、Windowsのプログラムメニューからアプリケーションを起動してみました（Adobe CCのランチャーはログオフ状態）。すると、サインインしてくださいという画面が表示されますが、これもWebViewでしょうか・・・なんかデザインが今までのサインイン画面と違うのでもしかしたら・・・なんと！証明書が利用できました！

【アプリケーション直接起動】

 

という検証結果でした。アプリのインストール時に証明書が利用できれば、とりあえず端末を固定して（証明書を利用して）利用を開始させることができたのですが、残念ながら。

IdPでIPアドレス制御して、社内からしかログインできないようにして、ユーザは（証明書を利用した）VPN接続して利用する、という方法しか端末を固定することができないような気がします。

あと、iPad/iPhoneでは、証明書ストア（キーチェーン）へのアクセスはアプリからは出来ないようですので、そもそも証明書認証ができません。OS上にインストールされたブラウザ（Safariとか）なら当然ながら証明書の利用ができます。マイクロソフト社のAuthenticatorを利用すればできるかも知れませんが、それはアプリ側が呼び出してくれないとダメですからね。というか、完全にアプリの実装に依存しているので、WebViewもSafariベースのもので実装すればいいのでは無いでしょうか。

アプリ屋の方々と是非お話してみたいです。

FIDOについて

人々をパスワードから解放しましょう！というコンセプトのもと、考え出された認証方式です。

FIDOには2つの認証方式があり、「U2F」と「UAF」を呼ばれています。

• UAF （ Universal Authentication Framework）とは対応デバイスを用いたパスワードを使わない認証方式
• U2F （Universal Second Factor ）とは現在の2要素認証の技術を進化させた認証方式

U2Fは、対応したUSB keyを端末に指してボタンを押すとトークンが送信されて認証が行われるので、ユーザはパスワードを覚えておく必要がありません。当然ですが、サービス側がFIDO U2Fに対応している必要があり、初期設定として、トークンの登録が必要です。

UAFは、スマートフォンなど対応したデバイスで認証を行い、認証済みトークンをサービス側に送るという仕組みです。ユーザとデバイス間で認証が行われ、デバイスとサービス間では認証は行われないのがポイントです。
デバイスでの認証はPINでも指紋や光彩などの生体認証でも、何でもよいので、ユーザはパスワードを入力必要がありません。

とまあ、こんな感じですが、FIDOに対応したデバイスからは何時でも誰でもセキュアにアクセスできます、というコンセプトがあり、コンシューマー向けの仕様とのことです。で、で、日本の場合には、特定の端末から特定の人がというエンタープライズ向けの仕様が必要なのですが、このような仕様が盛り込まれるのはまだ先だそうです。

マイクロソフト社が、FIDO2.0の作成に関わっているようですが、企業向けの仕様に仕上がるのは時間がかかる、とNoc Noc Labsの代表の方が申しておりました。