Security Automationは、インシデント対応のプラットフォームから1Passwordのアカウントを操作させる仕組みです。不審なサインインを検知したときに、人手を介さずに該当者を停止する、といった対応ができます。ただし使える環境が限られていて、自動プロビジョニングを設定しているアカウントでは利用できません。IDプロバイダーからのプロビジョニングを前提に設計することが多い日本の導入では、この条件に当たる組織の方が多くなります。そのためこのページは、適用できるかどうかの判定から始めます。続けて、当たらなかった場合の代替、できることの範囲、OAuthアプリケーションの作成、接続、失効と棚卸しを説明します。
使えるかどうかを先に判定する
3つの条件を全て満たす場合だけ設定に進めます。
| 条件 | 内容 |
|---|---|
| 契約 | Enterprise Password Managerを含む契約であること |
| 操作する人 | 所有者、管理者、セキュリティグループのいずれかであること |
| プロビジョニング | 自動プロビジョニングを使っていないこと |
分岐点は3つ目です。IDプロバイダーからの自動プロビジョニングを設定しているアカウントでは、この統合を使えません。アカウントの有効と無効の状態をIDプロバイダー側が持っているためで、外部から1Password側だけを止めても整合しなくなるからです。
【注意】 判定は導入設計の段階で行ってください。プロビジョニングの方式を先に決めてしまうと、あとからこの統合を選ぶ余地がなくなります。自動プロビジョニングの選択そのものは手動、自動プロビジョニング、SCIM Bridgeの比較で扱います。判定の結果は構成の記録に残しておいてください。数年後に検討し直すときに、なぜ使っていないのかが分からなくなります。
自動プロビジョニング環境での代替
条件に当たらなかった場合、同じ目的はIDプロバイダー側で果たします。プラットフォームからの自動化の宛先を1Passwordではなくプロバイダーに向け、そこでアカウントを無効化します。無効化はプロビジョニングの経路を通って1Password側に伝わります。
この形にすると、1Passwordだけでなく他のSaaSも同時に止まります。インシデント対応としてはむしろ望ましい挙動で、対応の窓口がIDプロバイダー1カ所に集まります。設計はプロビジョニング運用の設計で、退職や緊急の停止の手順は退職時の手順で扱います。
気を付けるのは反映までの時間です。間隔はIDプロバイダー側の設定に依存します。即時性が求められる対応では、反映を待つ前提の手順にしないでください。止めたことを確認するまでが手順です。
できることの範囲
指定できるスコープは4つです。
| スコープ | 内容 |
|---|---|
| ユーザーの取得 | 1人分の情報を読む |
| ユーザーの一覧 | 利用者を一覧で読む |
| ユーザーの停止 | アカウントを停止する |
| ユーザーの再開 | 停止したアカウントを戻す |
できるのは参照と停止と再開だけです。保管庫の操作、アイテムの取得、パスワードの変更、アカウントの削除は含まれません。侵害が疑われるアカウントをまず止める、という一点に絞った設計だと理解してください。
自動化の筋書きを組むときは、この4つで完結する範囲だけを対象にします。停止した後の復帰の判断、保管庫のアクセス権の見直し、クレデンシャルの入れ替えは人の作業として残ります。停止までを自動にして、その先を手順書に落とすのが現実的な形です。
OAuthアプリケーションを作成する
サイドバーの統合を開き、ほかに有効な統合がある場合はページの上部でディレクトリーの一覧に切り替えて、OAuth Applicationを選びます。
入力する4つの値
名前、説明、リダイレクトURL、スコープの4つです。名前はあとから区別できるものにします。説明は任意です。リダイレクトURLは、接続先のプラットフォームに登録されているものを入れます。HTTPSでなければ受け付けられません。
スコープの選び方
必要なものだけを選びます。停止だけを自動化するなら、停止と取得の2つで足ります。一覧を取る必要がないのに一覧のスコープを付けると、そのトークンで利用者の情報を全て読めるようになります。
選び直しはできません。作成のあとで内容を変更する手段がないためです。何を自動化するかを先に決めてからこの画面にきてください。
クライアントシークレットの保管
クレデンシャルを生成すると、クライアントIDとクライアントシークレットが表示されます。シークレットが表示されるのはこのときだけです。画面には保管庫に保存する操作があるので、そこで保存先の保管庫を選び、続ける前に保存します。
保存し損ねた場合、取り戻す方法はありません。作り直して、接続先の設定も入れ替えることになります。
【注意】 作成後は内容を一切変更できません。リダイレクトURL、スコープ、名前のいずれも直せません。変えるには新しいアプリケーションを作り、接続先を切り替えてから、古い方を失効させます。トークンの差し替えと同じ順序です。
接続と失効
接続先のプラットフォームには、クライアントIDとクライアントシークレットを渡します。プラットフォームがアクセストークンを取得し、パートナー向けのユーザーAPIに問い合わせる形で動きます。このAPIは公開プレビューの段階です。
対応が用意されているプラットフォームは6つです。設定の手順はそれぞれの提供元が出しています。
| プラットフォーム | 手順 |
|---|---|
| BlinkOps | <a href="https://docs.blinkops.com/docs/integrations/1password-users" target="_blank">1Password Users</a> |
| CrowdStrike | <a href="https://falcon.crowdstrike.com/store-v2/c62503ae5149456baa67aa5399860bac" target="_blank">Falcon Store</a> |
| Elastic | <a href="https://www.elastic.co/docs/reference/kibana/connectors-kibana/one-password-action-type" target="_blank">1Password connector</a> |
| Sumo Logic | <a href="https://www.sumologic.com/help/docs/platform-services/automation-service/app-central/integrations/1password/" target="_blank">1Password integration</a> |
| Tines | <a href="https://www.tines.com/library/stories/1346340/" target="_blank">ストーリーのテンプレート</a> |
| Torq | <a href="https://kb.torq.io/en/articles/13754603-1password" target="_blank">1Password</a> |
一覧にない場合は、<a href="https://www.1password.dev/users-api" target="_blank">1Password Users API</a>を直接呼ぶクライアントを自作するか、プラットフォームの提供元に確認します。設定についての問い合わせ先も、それぞれの提供元です。
失効させるときは、サイドバーの統合から該当のアプリケーションを選び、失効の操作を行います。失効させると接続は即座に切れます。
棚卸しで見るのは3点です。使われていないアプリケーションが残っていないか、スコープが必要以上に広くないか、発行した担当者が在籍しているかです。統合に関する操作は監査ログに残るので、監査ログの読み方の画面と突き合わせて確認できます。
【運用のポイント】 公開プレビューの段階の仕組みなので、事故対応の唯一の経路にはしないでください。自動で止まらなかったときに人が止める手順を、同じ手順書の中に並べて書いておきます。訓練のときは、自動の経路を意図的に止めて、手作業だけで対応できるかを確認してください。