トークンのスコープはホームサーバー自動化のリスクをどのように変えるか？

トークンのスコープを変更すると、盗まれた認証情報でどのアクション、リソース、API、下流システムを認可できるかが定義され、ホームサーバーの自動化に伴うリスクが変わります。

自動化では、ファイルストレージ、DNS、通知、スマートホームデバイス、クラウドバックアップ、カレンダー、コードリポジトリ、AIツールなどの認証情報が必要になることがよくあります。グローバル管理者トークンを使うと、あらゆるワークフローが成功するため設定は簡単ですが、漏洩した環境変数、ログ行、プラグイン、または侵害されたコンテナが、無関係なサービスまで操作できる権限に変わってしまいます。スコープは、侵害が起きる前にその権限を絞り込みます。以下のセクションでは、アクションスコープ、リソース対象、トークンの有効期間、更新権限、ID、拒否テストについて分けて説明します。

ベアラートークンは、保持している人に権限を移転する

ほとんどの自動化トークンはベアラー認証情報です。受信側のAPIは、最初にどのプロセスが取得したかではなく、トークンが正しく提示されたかどうかによってリクエストを認可します。

OAuthアクセストークンは、保護されたリソースに対する委任された権限を表します。攻撃者がシークレットファイル、環境変数、バックアップ、ブラウザーセッション、またはアプリのログからトークンを抜き出した場合、実質的なリスクは、その認証情報に含まれる、または関連付けられた権限全体に及びます。

保存時のトークンを保護することは重要ですが、トークンで実行できる操作を制限すれば、保護が破られた場合の被害を抑えられます。

アクションスコープで読み取りと破壊的操作を分離する

ファイル一覧を取得するワークフローに、共有の削除、ユーザー変更、キーのローテーション、ストレージサービスの管理権限まで必要とは限りません。APIが十分に細かい粒度に対応していれば、スコープによってこの違いを表現できます。

Auth0は、最小権限のスコープを、クライアントの業務上のタスクに合わせた権限と説明しています。通知の自動化には1つのチャンネルへの送信アクセスだけが必要で、バックアップの検証には1つのリポジトリへの読み取りアクセスだけが必要で、書き込み権限は不要かもしれません。

スコープ名だけで安全性を判断しないでください。継承された操作や管理者相当の操作も含め、実際にどのAPIメソッドとリソースが認可されるのかを確認してください。

高リスクの変更は、明示的な承認を必要とする別のトークンに分けるか、限定されたメンテナンスワークフロー内でのみ実行されるようにしてください。

対象の制限によって、どのサービスがトークンを受け入れるかが決まる

トークンのアクション権限が控えめでも、複数のAPIが受け入れられる場合は危険なままです。対象、つまりオーディエンスやリソースの制限によって、認証情報を意図したサービスに結び付けます。

OAuthのリソースインジケーターを使うと、対象制限付きトークンを発行できるため、1つのAPI向けの認証情報が別のAPIに自動的に再利用されることを防げます。各リソースサーバーは、自身が意図された対象であることを検証する必要があります。

これは、1つのIDプロバイダーがストレージ、ダッシュボード、自動化、AIサービス向けのトークンを発行するホームサーバーで特に重要です。どこでも受け入れられるトークンは、サービス間の境界をなくしてしまいます。

-15% OFF

ZimaBoard 2 - あなたの大きなアイデアのためのミニホームサーバー

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

有効期間と更新権限で露出期間が決まる

スコープが狭いトークンでも、永久に有効であれば悪用される機会が長く続きます。短期アクセストークンは盗難後の時間を短縮しますが、リフレッシュトークンや永続的なAPIキーによって、その権限が気付かないうちに復元される可能性があります。

OAuthのセキュリティガイダンスでは、トークンの有効期間を露出を制御する手段として扱っています。自動化の設計では、更新をどこで行うのか、どのIDが更新を要求できるのか、すでに発行されたトークンに失効が反映されるのかも定義する必要があります。

より安全なマシンIDのフローがAPIにない場合に限り、永続的な認証情報を使用してください。ローテーションを行い、所有者を記録し、緊急対応ではなく定常的な手順として交換プロセスを整備しましょう。

1つのグローバルトークンは、ユーザーごとのデータ境界を迂回する

自動化が複数の家族メンバーにサービスを提供しながら、バックエンドでは1つの認証情報を使うことがあります。そのトークンですべてのライブラリやアカウントを読み取れるなら、アプリケーションレベルのユーザー分離は見かけだけのものになります。

ZimaSpaceのユーザーごとのコンテキスト分離に関する説明では、グローバルトークンが、元のサービスでユーザーが期待する権限を迂回する経路になり得ると指摘しています。可能な限り開始したユーザーのIDを維持するか、より狭いスコープと対象を持つ下流トークンに交換してください。

サービスアカウントは共有メンテナンスタスクに適していますが、そのリソースは個人のライブラリや管理者用コントロールから明確に分離する必要があります。

スコープ設計は、拒否されるアクションで検証する

自動化の各ステップ、呼び出すAPI、操作するオブジェクト、実行するアクション、その権限が継続的に必要かどうかを一覧にしてください。すべてのスクリプトファイルに対してではなく、信頼する役割ごとに個別のトークンを発行しましょう。

Curityは、APIの拡大後も理解しやすいスコープ境界の管理を推奨しています。意図した呼び出しが成功することを確認したうえで、無関係な読み取り、書き込み、管理操作、別のAPI対象へのアクセスを試し、それらが失敗することを検証してください。

トークンの値を記録せずに、トークンのIDと付与されたスコープをログに記録します。低リスクの自動化が突然、高リスクのエンドポイントや通常とは異なるリソースを呼び出すようになった場合に検知できるアラートを設定してください。

安全なトークンとは、将来のあらゆるワークフローを便利にするものではありません。悪用された場合に起こり得る最大の結果が、許容範囲内で文書化されたものになるトークンです。

よくある質問

読み取り専用トークンなら常に安全ですか？

いいえ。広範な読み取りアクセスによって、プライベートファイル、ログ、ID、シークレットが露出する可能性があります。書き込み操作がブロックされていても、リソースのスコープと対象は重要です。

すべての自動化に独自のトークンを持たせるべきですか？

信頼する役割、所有者、リソース、リスクレベルが異なる場合は、トークンを分けてください。目的が同じ小規模なスクリプトであれば、所有者とローテーションを明確に管理できる場合に限り、1つの管理されたサービスIDを共有しても構いません。

トークンをローテーションすれば、盗まれたトークンはすぐに無効になりますか？

システムが古い認証情報を失効させるか、受け付けなくなった場合に限ります。リソースサーバーが失効状態を確認しない限り、すでに発行されたアクセストークンは有効期限まで使える可能性があります。