パスワードレスを目指す組織が、なぜパスワードマネージャーを導入したのか🤔

# はじめに

以前、組織をパスワードレスにしていった奮闘記を書きました。
社内からパスワードを排除すべく、Microsoft Authenticatorを利用したパスワードレス認証を導入し、SaaSをかたっぱしからシングルサインオン（SSO）に変更していきました。

少し前の記事ですが「パスワードレス奮闘記」もぜひ読んで、イイね👍押してもらえると嬉しいです😊

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

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

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

# パスワードレスの設計図

パスワードレスの設計の中核として、弊組織ではMicrosoft Entra IDをIDaaSとして利用しています。少し前まではAzure Active Directoryと呼ばれていた製品です。

https://www.microsoft.com/ja-jp/security/business/identity-access/microsoft-entra-id

ユーザーはEntra IDに対してパスワードレスでサインインをします。

パスワードレス認証の具体的な流れとしては、

iPhoneやAndroidデバイスにMicrosoft Authenticatorアプリをインストールしておき、サインインを試行すると画面には２桁の数字が表示されます。その数字をデバイスにインストールしたMicrosoft Authenticatorで入力するとサインインが完了します。

https://www.microsoft.com/ja-jp/security/mobile-authenticator-app?msockid=2cd7e832be786b6e2fe3fc31bf926a08

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/80467/651a895b-e8a7-81d6-bd34-d76f09246f94.png)

Microsoft Authenticatorを利用したパスワードレス認証は、**プロセスの中でパスワードを利用することがありません**。また、多要素疲労攻撃にも強いことから、Microsoftの条件付きアクセスで利用する **「認証強度」** では、「MFA strength」よりも強い **「Passwordless MFA strength」** にカテゴライズされています。

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

| Authentication method combination | MFA strength | Passwordless MFA strength | Phishing-resistant MFA strength |
| --- | --- | --- | --- |
| FIDO2 security key | ✅ | ✅ | ✅ |
| Windows Hello for Business | ✅ | ✅ | ✅ |
| Certificate-based authentication (Multi-Factor) | ✅ | ✅ | ✅ |
| **Microsoft Authenticator (Phone Sign-in)** | ✅ | ✅ |  |
| Temporary Access Pass (One-time use AND Multi-use) | ✅ |  |  |
| Password + something you have<sup>1</sup> | ✅ |  |  |
| Federated single-factor + something you have<sup>1</sup> | ✅ |  |  |
| Federated Multi-Factor | ✅ |  |  |
| Certificate-based authentication (single-factor) |  |  |  |
| SMS sign-in |  |  |  |
| **Password** |  |  |  |
| Federated single-factor |  |  |  |

:::note alert
上記の表をみてもパスワードのみの認証は認証強度が弱いですね。
:::

## SaaSもパスワードレスで認証したい

Entra IDへパスワードレス認証が可能になっても、そのままだと認証できるサービスはMicrosoft 365だけです。そのため、各種SaaSをシングルサインオンで認証ができるようにしていきます。

:::note
シングルサインオン（SSO）は、一度の認証で複数のサービスにアクセスできる仕組みです。認証にはIDプロバイダが利用され、認証情報を共有することで各サービスへの再ログインが不要となり、利便性とセキュリティを向上させます。
:::

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/80467/f9694ff8-861e-883a-fb53-c6039f4dc888.png)

Entra IDからSSOできるアプリケーションおよび設定手順はMicrosoftのドキュメントに大量に記載されていますし、ここにのっていないアプリケーションでも、Entra IDとのSSOを提供しているSaaSは数多くあります。

:::note
SaaSを契約する際に、SSOに対応しているかきちんと確認しましょう。
:::

https://learn.microsoft.com/ja-jp/entra/identity/saas-apps/tutorial-list

## オンプレミスアプリケーションの認証にもパスワードを使いたくない

企業にはオンプレミスサーバーで構築されたアプリケーションもあるはずです。ネットワークの制限がある場合も多く、また認証がEntra IDに統合されておらず、オンプレActive Directoryで認証を管理している場合や、アプリケーションごとにユーザー管理を行っているケースもあるでしょう。

### Azure Virtual Desktopの構築

弊環境ではVPNの導入も候補にあがりましたが、アプリケーションへの認証のこと考え、Azure環境とオンプレミス環境を専用線（Azure ExpressRoute）でつなぎ、Hybrid AD JoinをしたAzure Virtual Desktopを構築しました。

Entra Joinした端末から、Windows Hello for Business（顔認証）を利用してPCにログインします。物理PCからAVDを立ち上げて、オンプレミス環境にアクセスします。

### いまならMicrosoft Entra Private Accessも候補に

Microsoft Entra IDを使っている環境であれば、今ならMicrosoft Entra Private Accessも候補にあがります。Microsoftが満を持して（ようやく？）提供開始したゼロトラストネットワークアクセス（ZTNA）ソリューションです。

https://learn.microsoft.com/ja-jp/entra/global-secure-access/overview-what-is-global-secure-access

https://www.nri-secure.co.jp/blog/explanation-of-zero-trust-network-access

## オンプレアプリのアクセスも含めた設計図

AVDやPrivate Accessを加えました。Entra IDからパスワードレスで認証できる世界観が広がってきました。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/80467/5d196e14-f3c2-c7d3-be42-02fb0e775436.png)

## Entra ID パスワードベースのシングルサインオン

Entra IDにはパスワードベースのシングルサインオンという機能もあります。
導入したSaaSがSSOや多要素認証に対応しておらず、かつ利用人数が少なければ、管理者側でパスワードをランダムで割り当てると、ユーザーにパスワードを意識させないことができます。

https://qiita.com/akihiro_suto/items/2f7825bfc0cb8a506e4d

![パスワードベースのSSO.gif](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/80467/aacdcbe7-80e7-2a6b-3380-19bfae521b5e.gif)

# パスワードレス実現へ、現実的な問題にぶち当たる

ここまでくると、組織内のパスワード運用はかなり減らせます。ユーザーからも、「〇〇のサービスはシングルサインオンに対応できませんか？」といった嬉しい問い合わせをもらったりもします。ただ、やはり100％にはなりません。パスワード運用が残るのはどういったケースが、列挙してみます。

## 🙅SSOに対応していないSaaS

これから利用をはじめるSaaSは、SSOが利用できるSaaSにすべきです。対応していないSaaSは強い気持ちで導入見送りしています。ただ、やはり、企業には歴史があり、過去に導入していてそれなりに利用ユーザーがおり、乗り換えがすぐには難しいサービスもあるでしょう。そういったサービスがSSOに対応していない場合、パスワード運用が残ってしまいます。

人数が多い場合、パスワードベースのSSOも運用困難です。

## 🙅SSO対応のプラン高い問題

上記につながる課題となりますが、「SSO対応のプランはだいたい上位プラン」問題があります。

**サービスとしてSSOに対応はしているけど、契約プランが最上位でないと使えません**。ということです。「エンタープライズプランのみ」となっていることが多いです。

その他機能としてもリッチになるので、Win-Winになるケースもあります。ただ、現在すでにシンプルなプランで業務が回っている場合、上位プランに変更しても受けられるメリットがSSOのみになり、投資対効果が低くなります。通常プランと最上位プランは価格が倍くらい違うこともあり、SSOのためだけに投資額を倍にする必要があるのかという議論になります。

結果として、長期的にはサービスの乗り換えやSSOに移行パスワード運用を続けようという判断になることもあるでしょう。

また、子会社を含めたテナント統合を進めていくケースも、この「SSO高い問題」がネックになり、認証をIdPに統合できないケースが考えられます。子会社のみで利用しているSaaSのプラン変更を親会社がすべて費用負担するわけにもいかず、結局、投資対効果を検討した結果、プラン変更は行われず、パスワード運用が残ってしまいます。

## 🙅管理者のみパスワード運用になるSaaS

プランを最上位に切り替え、SSOを有効にすることができたとしても、**管理者はSSOにできない** SaaSも多くあります。
**SSOはIdPに認証を委任する = IdPが止まったら認証できない** ことになるため、「管理者（Adminロール）はパスワード認証のみ」とすることでIdPに不具合が起きた際に、管理画面ログイン後、SSOを停止、一般ユーザーをパスワード認証へ切り替える…という設計です。こういったSaaSが良い悪いという話ではなく、設計の話なので避けられません。

一般ユーザーはSSOでログインをすることができますが、管理者のみはパスワード運用が残り続けるため、パスワードの管理が必要になります。**管理者ユーザーのパスワード**なので、**厳重な保管・運用**が必要になります。

:::note
利用しているIdPの稼働率は常に気にしておく必要があります。
Entra IDであれば、**ID > 監視と正常性 > 正常性** から稼働率を確認することができます。

https://entra.microsoft.com/#view/Microsoft_AAD_DXP/ScenarioHealthSummary.ReactView

確認すると、2024年3月～2024年8月まで、稼働率99.999%でした。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/80467/4fc7379c-fdca-762c-e50f-bb8c07e5544c.png)
:::

## Serverやネットワーク機器

その他、管理者シナリオでパスワード管理が必要になるケースはサーバー関連のパスワードがあります。Azure SQL ServerはEntra IDでのログインも選ぶことができるようにになっていますが、まだまだ残るオンプレミス資産（サーバー）の中にはパスワードでしか認証を行えないものも多くあります。その他、ネットワーク機器へのログインも、SSOができないものも多いです。パスワードの管理には気を使います。

# パスワードマネージャー導入を決意

ということで、Entra IDをいかにフル活用しても、当面の間、パスワード運用はユーザーシナリオ、管理者シナリオともに残ってしまうことがわかります。特に管理者シナリオの方は、漏洩したら大きな問題になるため、慎重に保管方法を検討する必要があります。

そこで、**パスワードマネージャーの導入を検討し始めました**。

:::note
パスワードマネージャーの比較は、先人の記事を参考にしました。

https://qiita.com/ken_hikita/items/d1a227bd0dc49328d043

https://qiita.com/ishiayaya/items/24f5f9d8fed28339671f
:::

## Keeperを選定した理由

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/80467/2869589d-04ba-aa03-6e88-b3728fd2f99e.png)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/80467/97f468cf-a697-04db-18a1-e705584436fa.png)

先人の知見（ブログ）を参考に製品選定をあらかた行い、弊組織では、**1passwordとKeeperを実際に導入し、比較検討を進め**ました。

大前提として、1passwordとKeeperともに素晴らしい製品で、どちらを導入しても組織の要件を満たすことは可能でした。そのうえで、**なぜKeeper導入を決めたのか**。ポイントは以下になります。

## 日本語サポートの有無

Keeperはやはり**サポートを日本語で受けられる**のが大きな魅力でした。日本支社があり、日本の代理店もあり、サポート面での充実を感じることができました。将来的に、全社、また子会社も含めて導入を進めていくためには日本語でサポートしてもらう体制は必須だなと考えていたため、製品導入の大きな決め手となりました。

1Passwordも英語に問題さえなければ、なんどもカスタマーサクセスの担当がメールで、「なにか困ったらすぐにミーティングしよう」と連絡をくれたので、言語の壁さえなければ、丁寧なサポートが期待できるはずです。

## SSOやプロビジョニング設定の容易さ

![ssoconnect.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/80467/d24052ed-26e0-3993-5170-c3c02e0abb91.png)


1PasswordもKeeperもIdPを起点としたSSOやユーザープロビジョニングが可能です。

ですが…

以下ドキュメントを斜め読みをしてもらえるとわかるように、**Keeperのほうが圧倒的に設定が楽**です。基本的には**KeeperとEntra ID側で画面をポチポチするだけで、設定が終わり**ます。

**Keeper**

https://docs.keeper.io/jp/v/keeper-sso-connect-cloud-jp/identity-provider-setup/azure-o365-keeper

https://docs.keeper.io/jp/v/enterprise-guide-jp/user-and-team-provisioning

**1Password**

https://support.1password.com/sso-configure-entra/

https://support.1password.com/scim/

特に現時点で**1Passwordはユーザーをプロビジョニングする際**にAzureやAWSなどに**SCIMブリッジをデプロイする必要があり**、管理・運用を考えると少し煩雑になります。

※SCIMブリッジはサンプルコードも提供されていますし、やればすぐに終わります。でも、ちょっとハードル高く感じました🫣

https://github.com/1Password/scim-examples

## SIEMとのログ連携

パスワードマネージャーを運用するのであれば、やはりログをSIEMに取り込んで、統合ログ監視ができるように設定しておきたいものです。1PasswordとKeeperはともに簡単な設定で、SentinelやSplunkなどのSIEM製品にログを取り込むことが可能です。

https://docs.keeper.io/jp/v/enterprise-guide-jp/event-reporting/azure-sentinel

https://support.1password.com/1password-sentinel-integration/

こちらはKeeperの画面ですが、主要なSIEMやストレージにはUIで送信設定をすることができます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/80467/88784fc1-66f7-a90a-0671-e9769bffde59.png)

# Keeper（パスワードマネージャー）を導入して、パスワード管理はどう変わったか

Keeper（パスワードマネージャー）を導入するとパスワード管理が可視化されます。

## ユーザー目線

自分の管理しているパスワードが個別に強度の強弱や使いまわしがないか…などチェックできます。「セキュリティ監査」の画面で緑ゲージになるように各SaaSやアプリケーションの設定を変えていけばよいですね。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/80467/636ea6d1-b5ec-7f9b-5471-654925dc034b.png)

Windows、Mac、モバイル、またブラウザの拡張機能など、パスワードが必要になる様々な端末やシーンに対応したアプリケーションが用意されており、パスワード入力、管理、新規作成のフローの効率が上がります。

https://www.keepersecurity.com/ja_JP/download.html?t=d

## 管理者目線

管理者はチームの運用状況をウォッチすることができます。どの程度利用されているか（activity）はもちろんのこと、チームメンバーがパスワードをどのように管理しているかを見ることができます。

**アクティビティ**
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/80467/05cffa6a-c8ac-a83c-6c39-0e7ba429314f.png)

また**ユーザーごとのセキュリティ監査**画面も有用です。使いまわしをしていないか、弱いパスワードがないか…。ここの画面を確認して、ユーザーと協力してパスワード変更や多要素認証の設定に取り組めば組織全体のパスワード耐性を上げていくことができそうです。

**ユーザーごとのセキュリティ監査**
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/80467/9812e176-173d-73c0-73a7-99146d2f746d.png)

また、あらゆるイベントをトリガーにしてアラートをあげられます。例えば、ユーザーが高リスクなパスワードを登録したら、そのユーザーにアラートが飛ぶ…などというように設定できます。ユーザーは意図せず使いまわしや脆弱なパスワードを設定しがちです。念には念を入れてこういったアラート設定もしておきたいですね。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/80467/93d8ea83-2116-355d-7d4e-685b78c84cc7.png)

# 🙆共有機能がいい

Keeperには保存したアイテムのセキュアな共有方法が用意されています。管理者目線で考えると、意外とユーザーや外部の方とパスワードのやり取りをすることって多いんです。一時的にテナント内で作業してもらうためにアカウントを払い出すとき…や、サーバーへのアクセスパスを渡すとき…など。メール本文に記載してパスワードを渡すのは少し違和感ありますよね。

そんな時にKeeperの共有機能が役に立っています。

## アクセス権を付与する

Keeperユーザーだったら、オブジェクトごとに権限を付与することができるので、メールアドレスを追加して権限付与します。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/80467/688f517f-faa7-bc4c-6d98-3bfe4f0de969.png)

また、フォルダにアクセス権をつけて、そのフォルダ内に入っているものはすべて共有する…という設計も可能です。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/80467/9be2c64e-2762-ce6b-5ffa-c46438492f98.png)

## ワンタイムリンクはデバイス1台までの制限が可能

Keeperアカウントを持っていない人と共有するシナリオがこちらです。
1台のデバイスのみでアクセスできるリンクを発行できるのがポイントで、共有リンクを利用したときは、意図せぬデータ漏洩が起こるリスクはつきものです。が、1台のデバイスからのみしかアクセスできないため、共有リンクが複数ユーザーで共有されたり、メールで転送されたりするリスクを限りなく抑えることができます。

- **Keeperアカウントを持っていない人へリンクを共有する**
- **リンクには有効期限が設定できる**
- **1台のデバイスのみで閲覧可能**

**「ワンタイム共有を作成」** をクリック。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/80467/82f166de-84a8-abfc-cdaa-d3867769c4d6.png)

有効期限を決定します。**有効期限は最短1時間、最長180日までの中から設定でき**ます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/80467/86c23afb-0006-ac02-e245-272d98fa5f06.png)

### ワンタイムリンクの共有方法

**リンクを共有**

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/80467/1b807954-9073-f344-854d-3bd2939b559e.png)

**メールで共有**

ただこちらはメールに貼り付けられる本文をコピーするだけです…笑

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/80467/bab93664-c282-49eb-7f1e-abf5e163d95a.png)

**QRコードで共有**

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/80467/4bbd0a1e-074b-fa3a-56b7-0c057702bd42.png)

### 🙆発行したワンタイムリンクの管理もできるよ

共有したワンタイムリンクはアイテムの画面で管理することができます。何個、だれに、いつまで発行されているかを確認できます。上の方で何個かワンタイムパスのリンクやQRコードをそのまま貼っていますが、この管理画面で削除しているため、すでにアクセスすることができなくなっています。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/80467/1c937c5c-8cb7-1a9d-59a4-932bb656c72d.png)

# まとめ

ということで、Entra IDなどのIdPを中心にパスワードレスを目指す組織に、なぜパスワードマネージャーが必要なのかをまとめました。

パスワードレスを目指す組織すべてが真のパスワードレスに到達できるわけではないです。様々な事情でパスワードをなくせない場合もあるでしょう。その場合も**よりベター**を目指し続ける行動が必要だと考えています。ベストにはできないかもしれないけど、よりベターに。

長めのブログになりましたが、ここまでお読みいただきありがとうございました。いいね👍、ストック🍜、よろしくお願いします。

![keeper-secrets-manager-desktop-bkg-1920x1080.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/80467/3d7da6d4-fea0-7c0d-454c-a2f6288a2e63.png)