社内をパスワードレスにするため頑張った話（後編）

# はじめに

本記事はMicrosoft Security Advent Calendar 2023、12日目の記事になります。

https://qiita.com/advent-calendar/2023/microsoft-security

:::note
いいね👍よろしくお願いします！
:::

# シリーズ3部作です。

https://qiita.com/akihiro_suto/items/1536a623638d5aaa9456

https://qiita.com/akihiro_suto/items/f2d2b637635bebe287ea

https://qiita.com/akihiro_suto/items/89a1dcb364821113ade8

# パスワードレス認証の導入

前編・中編と思うがままに書きましたが、いよいよ最終話です。

認証基盤の整理・統合を進め、SaaSアプリや業務アプリケーションをSSOできるように構成をし、認証をEntra IDに集約してきました。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/80467/4c5a5cee-19e7-5ec7-07e5-0d6b8d04a643.png)

目的は、社内で利用されるパスワードを限りなく少なくし、昨今のセキュリティ侵害の主な要因となっている「パスワード漏洩」から社員や会社を守ることでした。

Entra IDへのログインがそもそもパスワードレスになれば、Entra ID経由でログインするすべてのアプリケーションがパスワードレスでログインできることになります。

# Microsoft Entraの認証強度

https://learn.microsoft.com/ja-jp/entra/identity/authentication/concept-authentication-strengths

**Microsoft Entra認証強度**の表を確認します。

1. 単一要素認証
1. 多要素認証
1. パスワードレス認証
1. フィッシングに強いパスワードレス認証

下に行けばいくほどセキュリティ強度の高い認証です。

今回、社のセキュリティベースラインにしたのが、下表真ん中のパスワードレス認証です。
Microsoft Authenticator を利用した「電話によるサインイン」を使用します。

| 認証方法の組み合わせ | MFA 強度 | パスワードレス MFA 強度 | フィッシングに強い MFA 強度 |
| --- | --- | --- | --- |
| FIDO2 セキュリティ キー | ✅ | ✅ | ✅ |
| Windows Hello for Business | ✅ | ✅ | ✅ |
| 証明書ベースの認証 (多要素) | ✅ | ✅ | ✅ |
| Microsoft Authenticator (電話によるサインイン) | ✅ | ✅ |  |
| 一時アクセス パス (1 回限りの使用と、複数回の使用) | ✅ |  |  |
| パスワード + 使用できるもの| ✅ |  |  |
| フェデレーション単一要素 + 使用できるもの | ✅ |  |  |
| フェデレーション多要素 | ✅ |  |  |
| 証明書ベースの認証 (単一要素) |  |  |  |
| SMS サインイン |  |  |  |
| パスワード |  |  |  |
| フェデレーション単一要素 |  |  |  |

# Microsoft Authenticatorを使用したパスワードレス認証

Microsoft Authenticatorを使用したパスワードレス認証の動作は以下ビデオがわかりやすいです。

<iframe width="560" height="315" src="https://www.youtube.com/embed/pNl5Z4OHALg?si=1BoptAufsdsyZ4Eh&amp;controls=0" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen></iframe>

一般的な多要素認証は、

1. ID（メールアドレス）入力
1. パスワード入力
1. 多要素入力（SMSやメールに送られるコードなど）

という流れですが、

パスワードレス認証は、

1. ID（メールアドレス）入力
1. Microsoft Authenticatorでコード入力

という2ステップで終わります。

**画面に表示されたコード（自分しか知らない）** と、**登録されたデバイス（自分しか持っていない）** という２つの要件をクリアしているため多要素認証です。慣れさえすれば、**メールやSMSを利用した多要素認証よりもはるかに楽で、認証強度が強いです。**

https://www.microsoft.com/ja-jp/security/mobile-authenticator-app

# 認証を行う機材は会社支給かプライベート端末か

さて、Microsoft Authenticatorによるパスワードレス認証をするためには、携帯端末にアプリをインストールする必要があります。ここで多くの企業や組織が悩むといわれているのが、認証機材は会社が貸与すべきなのかどうかという点。

結論からいうと、**組織それぞれの文化があるので、答えはない**です。

自組織では**認証のために端末配布はしない**というルールで運用しています。基本的には私用端末で認証を行ってくださいと。

ただここは議論が分かれるところ。

### 業務が始まるのはいつなのか

議論が分かれる、「認証端末は誰のものを使うべきなのか」問題を少し深堀りしてみます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/80467/05a98689-d67f-3201-c550-27eca254cb7a.png)

上図のように、業務を開始する前には大体の人が行っていることがあります。

1. 朝起きて
1. 朝食食べて
1. 着替えをして
1. 洗面・化粧

この場合通勤については、通勤中の事故は労災の対象になったりしますし、通勤費を支給している会社がほとんどだと思うので、業務時間とみてもいいでしょう。その後会社について、パソコンつけて、業務開始となります。今はリモート勤務もあるので、通勤がないパターンもありますよね。

### では、認証はどこに位置するのか

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/80467/c76f654c-8552-ba1d-1d5b-7ecac90d624f.png)

では、認証はどこに入るのでしょうか。業務開始ラインの右か左か。ここがあいまいなため、議論がわかれてしまうのだと考えています。

自組織では、**認証は業務開始前** と定義しています。なので、認証のための端末は配布していません。

ゼロトラストの考え方では、アカウントの保護はもっとも重要です。正確な本人認証こそがゼロトラストセキュリティの入り口だと考えて全体の設計をしています。つまり、本人認証ができていない段階では、業務に入ることもできていない状態だということです。

例えばアメリカに入国する際も、パスポート（ID）を見せて、何しに来たのか軽く質疑応答があり、それから入国ですよね。本人確認がされる前には入国できません。

国内でもローン契約などをする際は、本人確認を運転免許証などでしたうえで契約が結ばれます。本人確認があいまいなまま結ばれる契約は本来ありませんし、契約を結ばないまま利用できるサービスも基本的にはありませんよね。

極論をいうと、毎朝、情シス前に並んでもらって、社員証で本人確認をしたうえでアカウントを有効にする…という作業をしても、本人確認の強度は同じといえば同じです。（同じなのか？🤔）

ただ、実際にそれを行うことはできません。めんどくさすぎて運用が破綻します。業務が回りません。セキュリティとユーザー利便性、**「どっちを取るか」** という議論になりがちですが、パスワードレス認証は本来 **両方取りたい** という考え方からはじまっていると思っています。SMSなどを用いた多要素認証よりも格段に楽です。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/80467/ce8dcd2f-56c9-2291-aee3-bef5ad7ac1e5.png)

さらに、**認証のためだけの携帯端末** を配布したとしたら、それはそれで管理側もユーザー側も大変になります。管理側の手間は想像通りですが、ユーザー側も認証のためだけに、一日一回使うかどうかわからないものを常に充電して、肌身離さず持ち歩き、OSのアップデートも定期的にして、なくしちゃったら情シスに報告して、場合によっては始末書とか？

# 言い方次第。やらないのはもったいない

わかってます、今言っていることは、言い方次第です😂経営陣や情シス内、ユーザー部門がいかに腹落ちするか、させるかが重要です。

ただ、 **携帯端末を配らないと「パスワードレス認証ができない！」** 、 **「多要素認証できない！」** と思っているのなら、それはあまりにももったいないと思います。詭弁かもしれませんが、いま書いたことをネタに、もう一度議論、再考してみてください。

## 私用端末が古い、ガラケー、持っていない

このパターンも数件ありました。

こういう人にはFIDOセキュリティキーを配布しましょう。大体5,000円くらいで購入することができます。詳細は割愛しますが、携帯端末を配布するよりもユーザー・管理者ともによっぽど楽ですし、認証強度としては最強になります。

有名どころではこういったものがあります↓

https://www.yubico.com/yubikey/?lang=ja

https://store.google.com/jp/product/titan_security_key?hl=ja

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/80467/8f839006-ea3c-c48c-b5ad-6898a5f15645.png)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/80467/024624e5-e1f1-e457-a1e9-b1cb4cb46ae2.png)

# パスワードレス認証のトラブル

パスワードレス認証に移行すると、アプリでの認証になるため、パスワード認証と違いトラブル？問い合わせも多くなります。以下その一例と対応事例を記載。

## 端末を家に忘れてくる

端末自体をなくしたわけではないが、自宅に置いてきてしまう！という事例がそこそこ起きます。その場合、配布しているPCがEntra ID Join していて Hello for Bussinessでの認証になっていれば問題なく利用できますが、そうではない場合、パスワードで認証できるようにしてあげる必要があります。

「パスワードレス除外」というセキュリティグループを作成しておいて、条件付きアクセスでパスワードレス認証の除外グループに追加しておきます。端末を自宅に忘れてきているユーザーから連絡をもらった場合は、そのグループに入れてあげることで一時的にパスワードでの認証を可能にしてあげています。

実際の運用としては、**除外グループへの入れっぱなし** が怖いため、Logic Appsを利用してそのグループを監視。24時間以上前にグループに入ったユーザーは削除していくことにしています。これでうっかりパスワード認証のままになることを防いでいます。

## 機種変更しちゃう

Authenticatorをインストールしている機種を、機種変更してそのまま下取りに出しちゃった！みたいな話もよくあります。

まず、機種変更前の注意事項は、MicrosoftのJapan Azure Identity Support Blogでまとめてくれているので、このブログ記事を周知しています。

https://jpazureid.github.io/blog/azure-active-directory/move-authenticator-to-new-phone/

それでもたまにあるため、現在はAuthenticatorで登録されているデバイスの機種名を取得し、古い端末を利用している人にはプロアクティブに機種変更時の案内を定期送信する仕組みを検討しています。

AppleやGoogleの新機種発表イベント前とかに送れば、一定の成果はあるのかなと考えています。

# 結果

社員ユーザーはパスワードレスを強制。ゲストユーザーには多要素認証を強制にするポリシーを実装したため、弊テナントの認証状況はこんな感じになっています。

単要素が少し残っていますが、ゲスト招待されている別テナントが単要素でログイン可能だとこちらにも出てしまうためです。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/80467/7010a995-dde1-3c63-7de7-23b1eb364f33.png)

危険なユーザーや、危険なサインインについても、Entra IDが自動検知し、自動処理を行ってくれているため、情シスが個別に対応をする必要はありません。

不正サインイン試行は毎日のように確認されていますが、パスワードレス認証のためことごとくはじかれています。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/80467/b80c4967-1e24-3125-3c3a-a8c54509ba21.png)

# まとめ

ということで、3回にわけて思いついた順でパスワードレス認証にしていった経緯を書きました。パスワードレスは強固でかつ利便性も高く、いろいろハードルはあるけど超絶おススメです。せっかくM365への認証をパスワードレスにしたなら、周辺のSaaSアプリのSSO化も忘れずに。パスワードレス認証はまだ一般的とは言えない認証プロセスのため、ユーザーから不満の声があがることもあるでしょう。でも、情シスから**正しい情報発信を発信を明るく**行えば、徐々に理解は深まっていくものです。

GoogleやDocomoがパスキー認証に取り組むニュースを最近よく目にするようになってきました。パスワードレスが当たり前の世界もおそらくそう遠くはないと思います。**当たり前になってから取り組み始めるのではなく、今から取り組むのがかっこいいと思います。** 一緒に頑張りましょう。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/80467/4c5a5cee-19e7-5ec7-07e5-0d6b8d04a643.png)

# 謝辞

実際には弊社環境もまだ少しパスワード認証が残っています。それも2024年1月~2月にはSSOにできるめどがたっているため、アドベントカレンダーもあり、年末の区切りとしてまとめさせてもらいました。いい機会をいただき、感謝です。

また、このプロジェクトは決してひとりで進めたわけではなく、情シスのメンバー、会社の経営層やユーザーの理解・協力なしでは実現できませんでした。パスワードレスを目指すために、設計図を書いたり都度相談に乗ってもらったネクストリードの方々にも最大限の感謝をおくります！

https://qiita.com/organizations/nextread_inc

**創業100周年目前の、ドメスティックかつ、トラディショナルな企業が、パスワードレスに取り組んだ話でした。お付き合いいただきありがとうございます。**

# シリーズ

https://qiita.com/akihiro_suto/items/1536a623638d5aaa9456

https://qiita.com/akihiro_suto/items/f2d2b637635bebe287ea

https://qiita.com/akihiro_suto/items/89a1dcb364821113ade8