古い1Passwordのアプリが残ると、後から有効にしたポリシーが効かない端末が生まれます。1Passwordには、古いアプリからのサインインを禁止する設定と、使えるリリースの系統を絞って自動更新を強制する設定の2つがあります。名前は似ていますが、守れる範囲は大きく違います。前者だけを有効にしても、社員のアプリは最新版にそろいません。このページでは、2つの設定の役割の違い、最低バージョンで締め出されるもの、有効にする順序、リリースチャンネルによる更新の強制、更新が止まる端末の扱い、ほかのポリシーとの関係を説明します。
2つの設定の役割の違い
どちらの設定も、ポリシーの共有と許可ポリシーの画面にあります。変更できるのは、所有者、管理者、設定の管理を持つグループのメンバーです。
| 設定 | 効くこと | 効かないこと |
|---|---|---|
1Passwordアップデート | 決められたバージョンに満たないアプリからのサインインを止める | 基準を超えたアプリを最新版に上げること |
リリースチャンネル | 使えるリリースの系統を絞り、自動更新を強制する | 古いアプリからのサインインを止めること |
1Passwordアップデートは締め出すための設定、リリースチャンネルは最新に保つための設定です。組織として最新版をそろえたいなら、軸になるのはリリースチャンネルの方です。
最低バージョンで締め出されるもの
1Passwordアップデートで古いアプリを禁止すると、次のバージョンに満たないものがサインインできなくなります。
| 対象 | 必要なバージョン |
|---|---|
| Mac、iOS、Androidのアプリ | 7.6以降 |
| Windowsのアプリ | 7.6.778以降 |
| Linuxのアプリ | 8.0.34以降 |
| ブラウザー拡張機能 | 1.20.0以降 |
| 1Password CLI | 1.2.0以降 |
| SCIM Bridge | 1.1.1以降 |
基準は現行のバージョンよりかなり古いところに置かれています。この設定で止まるのは、以前の世代のアプリを入れたまま使い続けている端末です。
見落としやすいのは、人が操作しない2つです。古いCLIを組み込んだまま動いているスクリプトは、有効にした日からサインインできなくなります。古いSCIM Bridgeは同期が止まります。更新の手順は運用、更新、トラブル対応で扱います。
締め出された社員も、1Password.comには引き続きサインインできます。完全に使えなくなるわけではありませんが、アプリと自動入力が止まるため業務には響きます。
有効にする順序
1Passwordアップデートは、止まる人がいない状態を作ってから有効にします。
レポートのデバイスレポートで、古いアプリを使っている端末と持ち主を洗い出します。この一覧が、有効にしたときに止まる人の一覧です。- 持ち主に更新を依頼します。更新を組織で管理する入れ方で配った端末は、管理者が新しいバージョンを配り直します。
- CLIを使うスクリプトとSCIM Bridgeのバージョンを、それぞれの担当者に確かめてもらいます。
- 台数が0になったことを確かめてから有効にします。
レポートの読み方はサインイン試行と端末のレポートで扱います。
リリースチャンネルで更新を強制する
リリースチャンネルでは、組織で使えるリリースの系統を選びます。選んだ内容は次の更新の周期から効き、系統を絞ると自動更新も強制されます。この設定はMDMで配った自動更新の設定より優先されます。
本番版だけに絞る
全社の標準として勧める形です。ベータ版やナイトリー版を選んでいた社員も、次の更新で本番版に切り替わります。
本番版とベータ版に絞る
情報システム部門などが新しいバージョンを先に試したい組織の形です。ポリシーはグループごとに分けられないため、ベータ版を選べるのは社員全員です。ベータ版を選ばない社員には本番版が届きます。
系統を絞らない
社員はナイトリー版まで自由に選べ、自動更新するかどうかも各端末の設定に任されます。最新版をそろえる手段がなくなるため、MDMで更新を厳密に管理している組織以外には勧めません。
更新が止まる端末の扱い
MacとWindowsのアプリは、週に1回更新を確かめます。ロックされていれば、自動更新の設定がオンのときに自分で更新します。ロックが解除されている間は、更新があることを知らせるだけです。常に開いたままの共用端末や、自動ロックを長くしている端末ほど、更新が遅れます。自動ロックの固定はロックと自動ロックの強制で扱います。
Macのアプリは、1Password.pkgのインストーラーで配ると自分では更新せず、組織が新しい版を配り直す前提で動きます。1Password.appのインストーラーで配れば、自動更新が働きます。Windowsのアプリも、入れ方によっては配り直しが要ります。MDMで配っている組織は、リリースチャンネルを絞る前に、パイロットの端末で自動更新がどう働くかを確かめてください。入れ方の違いはMac版アプリのデプロイとWindows版アプリのデプロイ、設定の配り方はMDMによる設定の配布で扱います。
iOSとAndroidのアプリは、それぞれのストアの自動更新に従います。Linuxはパッケージの管理の方法で更新の手順が変わります。
ほかのポリシーとの関係
いくつかのポリシーは、それ自体が新しいバージョンを求めます。ロックの方法と時間の固定は、アプリと拡張機能の8.11.18以降でだけ効きます。1Passwordアップデートの基準はこれよりずっと古いため、有効にしていても固定が効かない端末は残ります。
Device Trustと組み合わせて拡張機能で業務のアプリを守る場合も、拡張機能に最低のバージョンがあります（Chromeは8.10.80.23以降、FirefoxとSafariは8.11.4以降）。仕組みはDevice Trustと組み合わせると何ができるかで扱います。
【運用のポイント】 新しいポリシーを有効にするときは、そのポリシーが求めるバージョンを先に確かめ、
デバイスレポートで足りない端末が残っていないかを見てください。リリースチャンネルで自動更新をそろえておけば、この確認は数分で終わります。