SCIM Bridgeは、IDプロバイダーと1Passwordのサーバーの間に自社で置く中継のサービスです。人とグループの変更をIDプロバイダーから受け取り、1Passwordのアカウントに反映させます。将来廃止される予定で、新しく選ぶ理由はRipplingで自動化したい場合にほぼ限られます。一方で、既に運用している組織は、使い続けるか移行するかを決める必要があります。このページでは、SCIM Bridgeを使う場面、鍵を自社の環境に置くことの意味、SCIM Bridgeが扱う情報、監視に使える入り口、運用に要るもの、判断の目安を説明します。方式そのものの比較は手動、自動プロビジョニング、SCIM Bridgeの比較で扱います。
SCIM Bridgeを使う場面
SCIM Bridgeを選ぶかどうかは、使っているIDプロバイダーと、今の運用の状態で決まります。
Ripplingで自動化する場合
Ripplingは自動プロビジョニングに対応していないため、自動化するならSCIM Bridgeを使います。置き場所は、自社の基盤か、Rippling側でホストする自動ホスティングの2つです。どちらを選ぶかで、鍵を誰が持つかが変わります。選び方はRipplingとの統合で扱います。
既にSCIM Bridgeを運用している場合
Entra ID、Okta、JumpCloud、OneLogin、Google Workspaceと接続しているSCIM Bridgeは、自動プロビジョニングへ移行できます。当面は使い続けられますが、廃止予定のサービスを更新し続けることになります。移行の時期を決め、手順はSCIM Bridgeから自動プロビジョニングへの移行で確かめてください。
それ以外のIDプロバイダーの場合
Rippling以外のIDプロバイダーについて、SCIM Bridgeとの接続手順は用意されていません。上の5つなら自動プロビジョニングを使い、どれにも当たらなければ人の管理を手動で行います。
鍵を自社の環境に置くという意味
SCIM Bridgeを自社のサーバーで動かすと、アカウントの暗号の鍵を扱えるのは自社だけになります。自動プロビジョニングは同じ処理を1Passwordの基盤で動かしますが、隔離された環境と署名の仕組みで、1Password社にも鍵の中身が見えない形にしています。
自社に置けば安全、とは限りません。何を信頼する前提なのかを比べると、違いが分かります。
| 観点 | 自動プロビジョニング | SCIM Bridge |
|---|---|---|
| 基盤の安全 | 1Passwordの基盤がアクセス制御で守られている | 自社のデプロイ先がアクセス制御で守られている |
| 動くソフトウェア | 隔離された環境の処理に悪意のあるコードがない | 自社のSCIM Bridgeに悪意のあるコードがない |
| 公開鍵 | 処理の前に全ての公開鍵を検証する | 1Passwordのサーバーから受け取った公開鍵を検証せずに信用する |
| 招待できるドメイン | 設定した時点の許可ドメインを署名で固定する | サーバー上の許可ドメインを検証せずに信用する |
SCIM Bridgeは、鍵を自社に置く代わりに、公開鍵と許可ドメインの真正性を確かめません。デプロイ先のクラウドのアカウントを多くの人が触れる状態なら、1Passwordに任せるより弱い構成になります。SCIM Bridgeを選ぶなら、デプロイ先のプロジェクトやリソースグループに触れる人を、1Passwordの管理者と同じ水準で絞ってください。
SCIM Bridgeが扱う情報と扱わない情報
SCIM Bridgeが1Passwordとやり取りするのは、暗号化された人とグループの情報だけです。アイテムや保管庫の中身は送りません。通信はSRPとTLSで守られます。
| 情報 | 扱い |
|---|---|
| 人とグループの情報 | 暗号化してIDプロバイダーと1Passwordの間で受け渡す |
| IDプロバイダーの名前 | 1Passwordに送る |
| プロビジョニングの操作の記録 | 既定で記録する。自社のサーバーにだけ残り、1Passwordには共有されない |
| ヘルスモニタリングの結果 | オンにした場合だけ、Checklyが定期的に稼働を確かめる |
ヘルスモニタリングをオンにすると、1Passwordは状態の情報だけを見られるベアラートークンをChecklyに渡します。アカウントのそれ以外の情報は共有されません。使うには、ChecklyからSCIM Bridgeへの通信を受け入れる必要があります。外からの通信を絞っている環境では、この点を先に決めてください。
監視に使える入り口
SCIM Bridgeには、IDプロバイダーの統合とは別に、状態を確かめるための入り口があります。特に断りがなければ、デプロイに使ったscimsessionファイルと対になるベアラートークンで認証します。
| パス | 用途 |
|---|---|
/app | ステータスページ。状態の確認とログのダウンロード |
/health | ヘルスモニタリングがオンのとき、各部の状態をJSONで返す |
/monitoring | Checklyが使う。Checkly専用のトークンで認証する |
/ping | 稼働しているかの確認。認証なし |
/metrics | Prometheusでのメトリクスの収集 |
社内の監視ツールで死活だけを見るなら、認証の要らない/pingを使います。ベアラートークンを監視ツールに登録しなくて済みます。
運用に要るもの
SCIM Bridgeを動かすには、コンテナのサービス本体、Redisのキャッシュ、ドメイン名が要ります。Azure Container AppsのようにDNSと証明書を管理してくれるサービス以外では、公開のDNSレコードも作ります。証明書は既定でLet's Encryptから自動で取得されますが、この方式では443番ポートをインターネットに常に開けておく必要があります。
同時に動かせるSCIM Bridgeは1つだけです。冗長化の仕組みはなく、複数を動かす構成はサポートされていません。止まっている間は同期が止まるだけで、既存のアカウントと情報に影響はなく、デプロイし直してもデータは失われません。待機系を用意するより、デプロイし直す手順を記録しておく方が確実です。
デプロイで受け取るscimsessionファイルとベアラートークンは、組み合わせるとアカウントの情報にアクセスできます。ベアラートークンはIDプロバイダーにだけ渡し、scimsessionファイルは誰にも渡しません。廃止予定のバージョンの通知を受けたら、90日以内に更新します。
判断の目安
| 状況 | 判断 |
|---|---|
| Ripplingを使い、クラウドの基盤と運用の担当がいる | 自社の基盤にデプロイする |
| Ripplingを使い、基盤を持たない | 鍵をRipplingに預けていいなら自動ホスティング。預けられなければ手動で管理する |
| 5つのIDプロバイダーのどれかでSCIM Bridgeを運用している | 自動プロビジョニングへ移行する |
| 上のどれにも当たらない | 手動で管理する |
移行を決める前に、Security Automationを使っているかを確かめてください。自動プロビジョニングのアカウントでは使えなくなります。判定はSecurity Automationと外部サービスの統合で扱います。
【注意】 自動プロビジョニングへ移行したアカウントは、SCIM Bridgeに戻せません。試しに切り替えることはできないので、移行の条件を全て確かめてから進めてください。