1Password でゼロトラスト認証を組む 2026 — SSO の外側を Unified Access で守る

ゼロトラストは「社内ネットワークだから信頼する」という前提を捨て、すべてのアクセスを毎回検証するセキュリティ設計です。境界 (ファイアウォール) を強くするだけでは、サインイン後のセッションや SSO に載っていない SaaS の認証情報という「内側の鍵」を守りきれません。

本記事では、ゼロトラストの 3 原則 (常に検証・最小権限・侵害前提) を踏まえ、1Password Business が担う「認証情報・シークレットの保護層」を、Unified Access・Device Trust・Passkey/MFA・Secrets Automation の組み合わせで情シス目線に実装する設計を整理します。

ゼロトラストの 3 原則と、1Password が担う「認証情報の保護層」

ゼロトラスト (Zero Trust) のアーキテクチャは、米国 NIST の SP 800-207 で定義されています。ネットワーク上の位置を信頼の根拠にせず、アクセスのたびに文脈で認可を判断する考え方です。

その考え方は実務上、次の 3 原則として要約されることが多く、本記事でもこの一般的なサマリを軸に解説します。

1. 常に検証する (Verify explicitly): ユーザー・デバイス・アクセス対象の文脈ごとに、毎回認証・認可を行う。「社内 LAN にいるから OK」を認めない
2. 最小権限 (Least privilege): 必要なリソースに、必要な期間だけアクセスを許可する。Just-in-Time / Just-enough access が基本
3. 侵害を前提とする (Assume breach): いつか必ず侵害されると想定し、影響範囲を最小化 (マイクロセグメンテーション) し、常時監視・監査する

認証情報という「最も狙われる鍵」

ゼロトラストの議論はネットワークやデバイスに偏りがちですが、攻撃者が実際に狙うのは認証情報 (クレデンシャル) です。漏洩したパスワードや使い回しの API キーが 1 つあれば、境界の堅牢さに関係なく内部へ侵入できます。

1Password は Secret Key + マスターパスワードの 2 層構造を採用し、サーバ側が漏洩してもデータを復元できないゼロ知識アーキテクチャでクレデンシャルを保管します。ゼロトラストの構成要素として見ると、1Password は「アクセスの鍵そのものを安全に保管・配布・失効させる層」を担います。

ゼロトラストの全体像における 1Password の位置

ゼロトラストは単一製品では完成しません。IdP (Okta / Microsoft Entra ID など)、ネットワーク (ZTNA / SASE)、エンドポイント (EDR/MDM)、そして認証情報レイヤが組み合わさって 1 つの統制になります。

1Password はこのうち認証情報・シークレットのレイヤを引き受け、さらに Device Trust でデバイス姿勢の検証、Unified Access で SSO 外アプリの統制までを 1 つの枠組みに広げています。1Password 自身は 2026 年現在、自社を単なるパスワードマネージャーではなく Extended Access Management (XAM) プラットフォームとして位置づけています。

[訳] 1Password が Unified Access を発表。Zero Trust のガバナンスを SSO の背後にあるログインだけでなく『すべてのログイン』に適用する。SSO 外の共有・機密アカウントの発見、文脈に応じた Just-in-Time アクセス、即時のクレデンシャルローテーション/失効、全アプリにアクセスできる単一の従業員ポータルを提供する (1Password 公式)。

SSO 単独で守れない「サインイン後・SSO 外アプリ」のギャップ

多くの企業はゼロトラストの第一歩として SSO (SAML/OIDC) を導入します。ログイン経路を 1 つに集約し、IdP で多要素認証や条件付きアクセスを効かせる構成です。これは正しい土台ですが、SSO だけではゼロトラストは完成しません。

SSO が守れない 3 つの領域

SSO は「SSO に接続済みのアプリへのサインイン」は統制できますが、次の領域はカバーしません。

• SSO に対応しない SaaS の長い裾野 (long tail): 中小ベンダーの業務ツールや旧来サービスは SAML/SCIM に未対応のことが多く、ID/パスワードでの直接ログインが残る
• 共有アカウントと開発者のシークレット: 1 つのアカウントをチームで共有するケースや、開発者がローカルに保存した API キー・トークンは SSO の管理外
• サインイン後のセッション内の振る舞い: SSO はログインの瞬間を検証するが、その後のセッションで未管理端末から機密にアクセスし続ける状態までは見ない

つまり SSO は「正面玄関」の鍵としては優秀でも、裏口や合鍵 (SSO 外アプリ・共有アカウント・ローカルシークレット) を塞げません。ここがゼロトラストの「常に検証・最小権限」と矛盾する死角になります。

Unified Access が埋める「SSO + その先」

1Password が 2026 年 3 月に一般提供 (GA) を開始した Unified Access は、この死角を埋めるために設計された Extended Access Management の中核機能です。SSO に載っているログインだけでなく、すべてのログインにゼロトラストのガバナンスを適用します。

1Password の発表によれば、主な機能は次のとおりです。

この「SSO + その先 (SSO + beyond)」のアプローチは、ゼロトラスト導入で繰り返し語られるテーマです。生成 AI ツールの無許可利用 (シャドー AI) も同じ SSO 外の領域で起きるため、シャドー AI 対策を 1Password Business で組む設計とあわせて読むと、SSO 外をどう統制するかの全体像が掴めます。

Device Trust でデバイス姿勢を検証する (旧 Kolide)

ゼロトラストの「常に検証する」は、ユーザーだけでなくデバイスにも及びます。どれだけ強い認証を通しても、マルウェア感染した端末や暗号化されていない私物 PC からのアクセスを許せば、侵害前提の原則に反します。

1Password Device Trust は、買収した Kolide の技術を統合し、アクセスを許可する「前に」デバイスの健全性を検証する仕組みです。

デバイス姿勢チェックの中身

Device Trust は、ログインの早い段階で次のようなデバイス姿勢 (device posture) を確認します。

• OS とパッチの状態: 重大な脆弱性が放置された端末を検出
• ディスク暗号化の有無: ディスク暗号化 (FileVault / BitLocker など) が無効な端末をブロック
• スクリーンロック・管理状態: 一定時間でロックされる設定か、MDM 管理下かを確認
• 未管理デバイスの早期遮断: 会社が把握していない端末を、リソースに到達する前にブロック

特徴的なのは、いきなりハードブロックするのではなく「可視化 → 明確なルール提示 → 社員自身による self-remediation (自己修復)」を優先する設計思想です。これは Kolide が元々重視していた「ロックダウンより先に可視性と衛生 (hygiene)」というアプローチを引き継いだものです。

社員が自分で問題を直せるため、IT 部門への問い合わせ (チケット) を減らしながら最小権限を実装できます。

[訳] 1Password Device Trust (旧 Kolide) は、デバイスの健全性・コンプライアンス・管理状態をチェックしてからアクセスを許可する。いきなり厳格なロックダウンから始めるのではなく、可視性・明確なルール・開発者にやさしいセキュリティ衛生を重視するアプローチが特徴 (@frank_be)。

Zscaler 連携によるプレログインブロック

Device Trust は ZTNA 製品との連携でも効果を発揮します。たとえば Zscaler との統合では、Zscaler を稼働させた既知かつ健全な端末だけがリソースにアクセスできるよう、ゼロトラストポリシーを強制します。リスクの高い端末をログイン前 (pre-login) の段階でブロックしつつ、ユーザー側の摩擦は最小に抑えられます。

デバイスレイヤと認証情報レイヤを同じ 1Password の枠内で扱えるため、「誰が・どの端末で・何にアクセスするか」を分断せずに検証できるのが、Extended Access Management としての利点です。

Passkey・MFA・Secrets Automation で多層に検証する

ゼロトラストは「常に検証する」を入口 (認証) でも内部 (シークレット利用) でも効かせる必要があります。1Password はこの両端をカバーします。

Passkey と MFA でフィッシング耐性を高める

1Password は Passkey (FIDO2/WebAuthn) をネイティブに保存・同期でき、フィッシング耐性の高いパスワードレス認証を、従来のパスワードや MFA と併用できます。ゼロトラストの観点では、強固な本人確認 (Passkey) + 端末検証 (Device Trust) + SSO 外統制 (Unified Access) を重ねることで、単一要素では破られない多層の検証が成立します。

ただし「すべてのサービスで Passkey が使える」わけではなく、対応はアクセス先サイト側の実装に依存します。移行は Passkey 対応済みのサービスから段階的に進めるのが現実的です。Passkey と Watchtower を軸にした防御設計は、生成 AI 時代の 1Password フィッシング対策でも詳しく扱っています。

Secrets Automation でマシン ID にも最小権限を

ゼロトラストの「最小権限」は人間だけでなく、CI/CD パイプラインや AI エージェントといったマシン ID にも適用されます。API キーをコードや .env に平文で埋め込む設計は、侵害前提の原則に真っ向から反します。

1Password Secrets Automation を使うと、アプリケーションやエージェントは op://vault/item/field 形式の参照だけを保持し、実行直前にだけ実値を解決できます。シークレットをプロンプト・ログ・リポジトリに残さない Just-in-Time の配布が、ゼロトラストの最小権限をマシン側でも担保します。

CI 連携や MCP サーバ統合の具体的な実装は、1Password Secrets Automation 入門と CI 連携実践で手順まで解説しています。

段階的な導入ロードマップ

ゼロトラスト認証を 1Password で組む場合、いきなり全機能を有効化するのではなく、土台から段階的に積み上げるのが定石です。情シス目線での実装順序を 6 ステップに整理します。

ステップ 1〜6 の実装順序

1. SSO 接続を完了: Okta / Microsoft Entra ID / Google Workspace のいずれかと SAML 接続し、ログイン経路を 1 本化する
2. SCIM プロビジョニングを有効化: 入退社・異動に応じて Vault 権限を自動で付与・剥奪し、退職者アクセスを即時停止する
3. 共有 Vault と権限設計を整理: 部署・プロジェクト単位で Vault を分割し、最小権限でアクセス範囲を絞る
4. Device Trust でデバイス姿勢チェックを導入: OS パッチ・ディスク暗号化・管理状態を検証し、未管理端末をログイン前にブロック。self-remediation で社員に自己修復を促す
5. Passkey/MFA への移行を進める: 対応済みサービスから順に Passkey を有効化し、フィッシング耐性を底上げ
6. Secrets Automation で SSO 外・マシン ID を統制: CI/CD や AI エージェントのシークレットを Just-in-Time 配布に移行し、SSO の裾野とマシン側を埋める

AI エージェントにシークレットを安全に渡す設計を深掘りしたい場合は、AI エージェント時代のシークレット管理で Service Accounts と MCP を使った実践パターンを整理しています。

規模別の初期コスト目安

ゼロトラスト実装の土台となる 1Password Business は SSO/SCIM を含む法人プランです。社員規模別の月額目安は次のとおりです。

社員 50 名規模なら基本コストは月額 $399.50 (約 60,000 円)、200 名規模なら $1,598 (約 240,000 円) です。Device Trust や Unified Access といった Extended Access Management の機能は提供形態が分かれるため、最新の組み合わせと費用は公式に確認してください。

社員規模別の損益分岐は 1Password Business プラン徹底比較 2026 で 5・20・50・150 名のケースを試算しています。

まとめ: ゼロトラストの「認証情報レイヤ」を 1Password で固める

1Password は、ゼロトラスト (常に検証・最小権限・侵害前提) の中で、最も狙われる認証情報・シークレットの保護層を担います。SSO だけでは守れない「サインイン後・SSO 外アプリ」のギャップを、Unified Access・Device Trust・Passkey/MFA・Secrets Automation の組み合わせで埋める構成です。

• ゼロトラストは IdP・ネットワーク・エンドポイント・認証情報の各レイヤの合算であり、1Password は認証情報レイヤを担う
• SSO は土台だが「SSO 外アプリ・共有アカウント・ローカルシークレット」は守れない。そこを Unified Access が埋める
• Device Trust (旧 Kolide) はデバイス姿勢を検証し、可視化と self-remediation を優先して最小権限を実装する
• Passkey/MFA は入口、Secrets Automation はマシン側で「常に検証・最小権限」を効かせる
• 導入は SSO → SCIM → Device Trust → Passkey → Secrets Automation の順に段階的に積み上げる

ゼロトラストは単一製品で完成しないため、認証情報レイヤを 1Password で固めつつ、IdP やネットワーク側の統制と組み合わせる前提で設計するのが、2026 年現在の現実解です。

※情報は 2026-05-31 時点の内容です。最新情報は公式サイトをご確認ください。

※本記事には PR を含みます。