AI即架電のAPI認証情報は、フォームやCRMなどの受付連携ごとに分けます。秘密情報をコードへ書かず、利用するプログラムだけが保管先から読み出せるようにしてください。

更新は新しい認証情報へ切り替えた時点では終わりません。発行元で旧い認証情報を失効させ、認証に使えないことを確かめます。発信待ちの依頼や発行済みの別トークンが残る場合は、それぞれの停止条件も確認してください。まず、現在の認証情報と受付連携を一つずつ対応させます。

一つの受付連携に認証情報を一つ割り当てる

問い合わせフォームと求人応募、CRMからの再架電に同じ認証情報を使うと、漏えい時の影響範囲が分かりません。一つを止めただけで複数の受付が動かなくなるため、必要な連携まで巻き込んでしまいます。

認証情報は、受付の種類と実行環境ごとに発行します。本番と検証環境も分けてください。フォームごとの発行に対応しない製品では、自社側の連携基盤で入口を分け、共通キーへ到達できる処理を限定します。

管理台帳には認証情報そのものを書きません。利用する受付と発行元を記録し、管理する役割と保管先の参照名も残します。専用キーなら連携単位で失効できますが、共通キーでは他の受付にも影響します。自社側の入口を分けるだけでは、漏れた共通キーによる直接接続は防げません。

認証情報をコードと設定画面から離す

APIキーをソースコードへ直接書くと、リポジトリの複製やログ出力を通じてコピーが増えます。チャットや表計算へ貼り付けても、誰が保持しているかを追いにくくなります。

認証情報はシークレット管理サービスへ置き、連携プログラムが実行時に読み出します。AWS Secrets Managerの概要では、アプリケーションの認証情報やOAuthトークンなどをライフサイクル全体で管理する方法が案内されています。APIキーをソースコードへ埋め込まずに利用できます。

製品の管理画面へ入力する必要がある場合も、担当者の個人メモには残しません。保管先から一時的に参照し、入力後に画面上で再表示できないかを確認します。表示できるなら、その画面を閲覧できる管理者も絞ってください。

読み書きできる範囲を最小にする

即架電の連携で必要なのは、受付情報を送る操作と処理結果を受け取る操作です。顧客一覧の全件取得や設定変更まで許可する必要があるかは、別に判断します。

認証情報を発行するときは、対象のテナントと実行環境を限定します。利用できるAPIと操作も必要な範囲へ絞ります。フォームから発信依頼を登録する認証情報と、Webhookが正規の送信元か検証する秘密情報も分けた方が良いです。片方が漏れても、もう片方の処理まで偽装されにくくなります。

AWSのシークレットへのアクセス制限は、IAMロールでアクセスを制限し、APIを介してプログラムから利用する考え方を示しています。製品が広い権限の固定キーしか発行できない場合は、その制約を記録し、自社側の接続元や実行処理をさらに狭めます。

新旧の併用可否で更新手順を分ける

認証情報の有効期限を迎えてから差し替えると、問い合わせ直後の発信が止まります。期限がないキーでも放置せず、更新日と担当する役割を決めてください。

新旧のキーを同時に有効にできる製品では、先に新しいキーを発行して保管先へ登録します。連携プログラムを切り替え、管理下のテスト番号へ合成データを一件送ります。依頼が一度だけ登録され、結果が元の受付へ戻ることまで確認してください。保管先の値を書き換えるだけで、発行元のキーが更新されるとは限りません。

同時に有効にできるキーが一つだけなら、無停止の切り替えを前提にしません。受付記録を保持する方法と有人対応への切り替えを決め、自動発信と再送を止めてから差し替えます。再開前に処理済みの受付と未処理の受付を照合し、保留分を重複して送らないようにします。

切り替え後は、新しいキーを使っていることをログなどで確認します。発行元で旧キーを失効させ、発信を発生させない認証確認用の操作で拒否されることを試してください。利用できる確認方法と失効の反映時間は提供元へ確認します。秘密値をログへ出して新旧を見分けてはいけません。

OAuthなど別のトークンを発行する方式では、そのトークンやセッションも失効するかを別に確かめます。また、認証前の新規依頼を拒否できても、すでに受理された発信依頼の取消とは別です。キーの更新だけで、待機中や実行中の発信まで止まるとは判断しないでください。

漏えい時は受付と発信を先に止める

認証情報を公開リポジトリへ誤って置いた場合、ファイルから削除するだけでは足りません。履歴や複製先に残る可能性があるため、発行元で速やかに失効させます。GitHubの説明では、失効したGitHubトークンはGitやAPIの認証に使えません。これはGitHubの仕様であり、利用中のAI電話サービスでは失効対象と反映時間を個別に確認します。

漏えいしたキーから発信依頼を作れる場合は、失効と併せて自動発信と再送を止めます。すでに受理された依頼の取消も確認してください。顧客対応への影響を理由に漏れたキーを使い続けず、安全に受付記録を残せる経路があれば有人対応へ切り替えます。

停止後は最終利用時刻と接続元、実行された操作を確認します。新しい認証情報を発行しても、原因となったコードやログ出力を直す前に再開しません。再開時は一件だけテストし、重複発信や失敗した処理の再送が起きないことを見ます。

六つの記録を認証情報台帳へ残す

管理台帳は秘密情報の保管場所ではありません。担当者が変わっても更新と停止を実行できるように、認証情報の役割と扱い方を残すものです。

  1. 利用する受付連携と目的
  2. 発行元と管理する役割
  3. 実行環境と保管先の参照名
  4. 許可したAPI、操作、対象データ
  5. 発行日、期限、前回更新日、次回確認日
  6. 停止方法と旧い認証情報の失効を試した日

個人名だけを責任者にすると、異動や退職の後に更新できなくなります。役割を決めたうえで、現在の担当者を社内の権限管理へ結び付けます。利用していない認証情報は、台帳に残したままにせず停止してください。

最初の作業は、一つのAPI認証情報を複数の受付連携で共有していないか確認することです。共有している場合は、影響の大きい本番連携から専用の認証情報へ分け、旧い認証情報が使えないところまで試します。