管理コンソールのサイドバーに開発者があります。ここに並ぶのは、エンジニアが日々使う道具そのものではなく、管理者が決めるポリシーと、組織で共有する資源の設定です。道具の導入手順は<a href="https://www.1password.dev/" target="_blank">1Passwordの開発者向けドキュメンテーションサイト</a>にまとまっていて、本ガイドでは扱いません。ただし、何を管理者が決めて何をエンジニアに任せるかの線引きだけは、管理者側で決めないと進みません。決めないまま任せると、各自がばらばらの保管庫とサービスアカウントを作り、あとから棚卸しができなくなります。このページでは、役割の分担、開発者画面に何があるか、先に決めるポリシー、そろえておく共有資源、サービスアカウントの棚卸しを説明します。
管理者が決めることとエンジニアが決めること
| 領域 | 管理者 | エンジニア |
|---|---|---|
| ポリシー | 決める | 従う |
| 保管庫とグループ | 設計する | 使う |
| サービスアカウント | 発行できる人を決め、棚卸しする | 用途ごとに使う |
| 環境変数のまとまり | 共有するものを用意する | 自分の作業で使う |
| コマンドラインの道具とSSHキー | 関与しない | 各自で導入する |
| コミットの署名 | リポジトリー側の規則で求める | 設定する |
管理者が触らない領域まで抱え込むと、導入が止まります。逆に、ポリシーと共有資源を決めずに任せると、統制の効かない場所にクレデンシャルが増えます。上の表の左半分が管理者の担当範囲だと考えてください。
開発者の画面に並ぶもの
開発者の画面には、自動化のために発行したものの一覧と、パーミッションのタブがあります。
| 区分 | 何のためのものか |
|---|---|
サービスアカウント | 人が介在しない処理から保管庫にアクセスするためのアカウント |
Connectサーバー | 自社の環境に置いて、保管庫の内容をアプリケーションに渡すサーバー |
環境 | プロジェクトごとの環境変数をまとめたもの |
エージェントとワークロード | 自動で動く処理に発行するもの |
パーミッション | 上記を誰が発行できるかを決めるタブ |
このほかに、外部のツールに与えたパーミッションを扱う連携許可の管理があります。ここでアクティブな連携を確認できます。
パーミッションのタブが管理者にとっての要です。既定では所有者と管理者だけがサービスアカウントを発行できます。エンジニアのグループに発行を任せるなら、このタブで設定します。任せるかどうかは、棚卸しを誰がやるかとセットで決めてください。発行を任せて棚卸しを管理者が持つ形にすると、把握していないトークンが増えます。
先に決めるポリシー
ポリシーの共有と許可と認証に、開発者向けの機能に関わる設定があります。エンジニアに案内する前に決めておく設定です。
端末のスキャンを有効にするか
ローカルディスクのスキャンを有効にすると、端末に平文で置かれた秘密鍵や環境変数のファイルを検出したレポートが作られます。インサイトに出る開発者シークレットの数字もここから出ます。従業員の端末を見る仕組みなので、有効にする前に対象と目的を周知してください。検出した後の進め方は開発者のシークレットを見つけて是正するで扱います。
開発者向けの機能をどこまで開けるか
デベロッパー権限は、SSHの設定ファイルの自動生成と、環境変数のまとまりを各自が使えるかどうかを決めます。エージェンティック権限は、AIエージェントに自動入力をさせるかどうかを決めます。後者は早期アクセスの段階の機能です。
生成AIを使う業務の扱いが社内で固まっていない段階では、エージェンティック権限は止めたまま始め、方針が決まってから開けるのが無難です。止めておいても他の機能には影響しません。
サイドバーに表示するかどうか
サイドバーナビゲーションでは、所有者と管理者以外のチームメンバーに、開発者と統合をサイドバーに表示するかどうかを決めます。
【注意】 隠しても機能は止まりません。直接のリンクからは開けますし、既に動いている統合やツールも影響を受けません。見せない設定であって、使わせない設定ではありません。使わせないことが目的なら、
デベロッパー権限の側で止めてください。監査の説明でこの2つを取り違えると、実態と食い違った回答をすることになります。
生体認証でのロック解除を認めるか
開発者向けの道具の多くは、デスクトップアプリの生体認証で認証します。生体認証でのロック解除を禁止していると、作業のたびにアカウントのパスワードを入力することになり、道具が使われなくなります。認証のポリシーを厳しくするときは、認証のロック解除と自動ロックがこの点に影響します。設定はロックと自動ロックの強制で扱います。
共有資源をそろえる
ポリシーが決まったら、エンジニアに渡す土台を作ります。3つあります。
保管庫とグループは、プロジェクトや担当領域の単位で作ります。個人に直接アクセス権を与えず、グループ経由にしておくと、入社と異動のたびに保管庫を触らずに済みます。設計は保管庫の分割パターンとカスタムグループの設計で扱います。
環境変数のまとまりは、クレデンシャルの種類ではなく、アクセスの境界で分けます。開発、検証、本番のように環境が分かれているなら、それぞれに1つずつ作ります。用途で混ぜると、本番の値に開発の担当者が届いてしまいます。
サービスアカウントは、用途ごとに1つ作ります。失効の単位と、監査で追う単位がそのままこれになるためです。1つのアカウントを複数の処理で使い回すと、どれか1つに問題が起きたときに全部を止めることになります。
サービスアカウントの棚卸し
定期に見る観点は3つです。スコープが必要以上に広くなっていないか、終了したプロジェクトのものが残っていないか、発行した担当者が在籍しているかです。人が持つアカウントと違って、退職者の整理では引っかかりません。サービスアカウントだけを対象にした点検の回を作ってください。
サービスアカウント単位の使用状況レポートを作れます。どの保管庫のアイテムがいつ使われたかを確認できるので、動いていないアカウントを見つける手掛かりになります。作り方は利用状況と定着のレポートで扱います。トークンの発行と失効は監査ログに残るので、監査ログの読み方と突き合わせると、いつ誰が作ったかまで追えます。
【運用のポイント】 サービスアカウントを止めると、そのトークンを使っている処理が止まります。棚卸しで消す前に、誰の担当のどの処理が使っているかを記録しておいてください。名前と説明にプロジェクト名と担当部署を入れる規則にしておくと、この調査が不要になります。命名の規則はアイテムの設計と命名規則の考え方をそのまま使えます。
本ガイドで扱う範囲
このページで扱ったのは、ポリシー、共有資源、発行のパーミッション、棚卸しの4つです。いずれも管理者が決めなければ進まない領域です。
コマンドラインの道具の導入、SSHキーの設定と署名、SDKの使い方、CI/CDへの組み込みは扱いません。読む相手がエンジニアで、必要な粒度も違うためです。これらは<a href="https://www.1password.dev/" target="_blank">1Passwordの開発者向けドキュメンテーションサイト</a>にまとまっているので、社内のオンボーディングの資料からはそちらを案内してください。日本語版はありません。管理者側は上の4つに集中する形が、結果として早く回ります。
短命なクレデンシャルを発行する仕組みは別の製品で扱います。位置付けはCredential Brokerの概要にあります。