定期ジョブと人手ログイン：APIはどちらの身元を見るべきか

定期ジョブとログイン画面の前に立つ人は、同じAPIを別の資格情報、別の寿命、別の所有者で呼び出します。ジョブにはネットワーク経路、アプリケーションの身元、権限の集合が必要で、人にはログイン、第二要素、セッションが必要です。両者を混ぜると、人のパスワードが変わるたびに壊れる自動化か、cronジョブを生かすためだけに弱められた多要素ポリシーが生まれます。

三つに見えて一つになる三つの関門

送信元アドレスの規則は、要求がどこから来たかを尋ねます。認証は、誰が呼び出しているのか、どの証明が提示されたのかを尋ねます。認可は、この主体がこの操作を実行してよいかを尋ねます。VPNが変えるのは三つのうち最初の一つだけで、しかもジョブ専用ではなくホスト上のすべてのプロセスについて変えるのですから、インシデント記録では三つの観察を分けておいてください。

だから出口ノードを変えると送信元アドレスによる拒否は直っても、無効なトークンはそのまま残ります。だから有効なAPIトークンがあっても、経路のないジョブからプライベートなエンドポイントに到達できるわけではありません。

対話的な経路は自動化の手本にならない

人のログインをスクリプト化するのは、一度は動くので魅力的です。スクリプトはパスワード、場合によってはワンタイムパスワードの種を保存し、人間を要求するよう設計されたチャレンジに依存します。OAuthの現在の最良のセキュリティ慣行であるRFC 9700は、resource-owner-password-credentials付与を禁じ、それが二要素認証や多段階認証にうまく合わない理由を説明しています。

サポートされる代替は通常、認可サーバーがアプリケーションを認証してトークンを発行する機密クライアントフローです。RFC 6749の4.4節にあるclient-credentials付与がその一例です。存在するからといって、すべてのAPIが受け入れるわけでも、利用者が委任したタスクをそれで置き換えられるわけでもなく、それはサービスの所有者への問いです。コードを書く前に、サービスがどの無人モデルを支えているかを尋ねてください。

VPNがなお適する場所

VPNはプライベートなAPIが必要とするネットワーク経路を提供でき、それは正当な役割です。ただしジョブをアプリケーションに対して認証するものではなく、ジョブが何をしてよいかの範囲を定めるものでもありません。共有の出口アドレスはジョブではなくホストを識別するので、そのアドレスの許可リスト登録はそこで動くすべてのプロセスを通します。

ジョブが共有ランナーで動くなら、この区別は小さくなるどころか大きくなります。同じホスト上の別のワークフローが経路とアドレスを引き継ぎ、APIは両者を区別できません。共有パスワードと同じ弱さが、一段下に移っただけです。制限はアプリケーションが強制できる場所に置き、許可リストをより狭くできないならランナーを分離してください。

二つの設計を正直に比べる

人手のログインは本物の人間、本物の第二要素、監査できるセッションを与えますが、無人では動きません。アプリケーションの身元は無人実行、レビューできる範囲、ローテーションできる資格情報を与えますが、何も委任していない利用者の代わりには動けません。どちらかが他方の弱い版なのではなく、別の問いに答えているのです。誰もいない状態でタスクを動かす必要があるか、操作を特定の利用者に帰属させる必要があるかを問うて選んでください。

どちらも「はい」なら、設計には借り物のパスワードではなく委任モデルが必要です。その決定を、次の保守担当が見つけられる場所に書き残してください。

引き継ぎの前に確かめること

実際のワーカーから許可される操作を一つ、必須の拒否を一つ実行し、両方の結果を残します。次に、夜中に誰かを起こす二つの失敗だからこそ、期限切れの資格情報とネットワーク経路が使えないときの挙動を試してください。

curl -sS -o /dev/null -w '%{http_code}\n' \
  -H "Authorization: Bearer TOKEN" https://api.example.com/v1/records

主体、範囲、ローテーションの所有者、実行環境をその結果のそばに記録します。その記録が、次のローテーションをインシデントではなく日常作業にするのです。監査者が求めるのもその部分です。