認証と認可の違い

認証は「誰（何）が行動しているか」を確立する

認証は、主張されたアイデンティティに対する信頼を確立するか、プリンシパルに関連付けられた資格情報を検証します。 NIST の認証の定義は いくつかの状況における本人確認をカバーしています。プリンシパルは、人だけでなく、アプリケーションやサービスアカウントである場合もあります。

API key は一般的に、プロバイダーのモデルに応じて、呼び出し元アプリケーションまたはアカウントを識別します。ブラウザーのセッション cookie は、サインインしているユーザーを表すことができます。どちらの値も、サーバーが呼び出し元を認識できるという理由だけで、完全な権限ポリシーとして説明すべきではありません。

実用的な例として、サービス用の資格情報を受け付ける社内レポートサービスを想像してください。資格情報を受け入れることで、そのリクエストがレポートアプリケーションから来たことは確立できます。しかし、そのアプリケーションがどの顧客データセットを読み取れるかまでは確立できません。ログや共有アーティファクトには実際の資格情報を残さないようにしつつ、認識されたプリンシパルを安全な診断情報として記録してください。

認可はリソースに対するアクションを評価する

認可は、適用されるポリシーの下で、プリンシパルが要求されたアクションを実行できるかどうかを決定します。 NIST の認可の定義は アクセスを与えたり評価したりすることを説明しています。有用な決定には、主体、アクション、リソース、および関連するコンテキストが含まれます。

プロジェクト API において、プロジェクトを読むこと、設定を編集すること、削除することは、それぞれ異なるアクションです。ユーザーは、あるプロジェクトは読むことが許可され、別のプロジェクトは編集することが許可されている場合があります。ロール名だけでは、そのロールが適切なリソーススコープとアクションにマッピングされていない限り、結果を説明できません。

オブジェクトの所有権を明示的にしてください。エンドポイントがプロジェクト ID を受け取った場合は、プロジェクトを解決し、そのオブジェクトへのアクセスを評価し、呼び出し元がサインインしているかどうかだけをチェックしないようにします。予測可能な ID が権限境界として機能してはなりません。同じルールを、プロジェクトのデータを露出させるエクスポート、添付ファイル、バックグラウンドジョブにも適用してください。

資格情報、セッション、トークンはクレームの運搬体である

資格情報やトークンは、システムが評価する情報や証拠を運びますが、その存在だけであらゆるアクセス決定が済むわけではありません。所持しているだけで使用できてしまう場合があるため、ベアラー資格情報には特に注意が必要です。 OAuth bearer-token specification はそのセキュリティモデルを定義し、トークンに関連するエラー条件を説明しています。

認証スキームは分けて扱ってください。特定のヘッダーに生のキーを期待するAPIは、自動的にOAuthベアラートークンのエンドポイントになるわけではありません。トークンパラメータを受け入れるブラウザ接続は、RESTリクエストヘッダーとは異なるトランスポート面を持ちます。対象サービスごとに文書化されている方法を使用してください。

また、認証と暗号化を区別してください。TLSは転送中の通信を保護しますが、認証と認可はアプリケーション境界でのアイデンティティとアクセスを制御します。有効な暗号化接続であっても、未認証のリクエストや、認識されている呼び出し元であっても実行を許可されていないリクエストを運ぶ可能性があります。

あらゆる関連リクエストで権限を強制する

アクセス制御は、要求されたリソースとアクションに対してサーバー境界で強制されるべきです。 OWASP の認可ガイダンス は、最小権限、デフォルト拒否、およびすべてのリクエストでの権限検証を推奨しています。これらの原則は、省略されたチェックが意図しない許可付与になってしまうことを防ぐのに役立ちます。

クライアントインターフェースは、使いやすさのために権限を反映させることができますが、隠されたコントロールによって直接リクエストが防がれるわけではありません。そのアクションがWebインターフェース、API、スケジュールされたタスク、またはエクスポートワーカー経由で届く場合でも、同じポリシーを適用してください。バックグラウンド処理にも、文書化されたアイデンティティとスコープが必要です。

マルチテナントアプリケーションでは、テナント間の境界を直接テストしてください。あるワークスペースで編集権限を持つユーザーが、識別子を変更するだけで別のワークスペースで同等のアクセスを得られてはなりません。否可となったリクエストもテストセットに含め、存在するが別のプリンシパルに属するオブジェクトへのリクエストも含めてください。

認証情報のローテーションと権限変更は異なる影響を持つ

認証情報のローテーションは、呼び出し元を認証するために使用される証拠を置き換えます。権限変更は、認識された呼び出し元が何を行えるかを変更します。この2つの操作は異なる問題を解決し、実装によっては実行中のセッションやアプリケーションに異なる影響を与えます。

シークレットが漏えいした場合、ファイルからそれを削除しても認証情報は無効にはなりません。プロバイダーが提供する無効化プロセスを使用し、承認されたシークレットストアを通じて代替値を配布してください。ユーザーのロールが変更された場合は、認可ポリシーを更新し、アクティブなセッションやキャッシュされた判断がいつその変更を反映するかを理解しておきましょう。

どのアプリケーションが認証情報を使用しているかの運用記録を保持しつつ、その記録にはシークレット自体を保存しないでください。これにより、ローテーション時に影響を受けるデプロイメントを特定しやすくなります。同様に、バックグラウンドジョブがどの権限に依存しているかを文書化してください。「アクセスが急に動かなくなった」という一般的なメッセージでも、アイデンティティ、リソーススコープ、およびデプロイ構成が区別できれば、はるかに調査しやすくなります。

Scrapeless 接続へのこの区別の適用

Scrapeless API キーは Scrapeless へのリクエストを認証しますが、プロダクトへのアクセスやリクエストの有効性は、なお別個に評価する必要があります。現在の Scrapeless API key handling の手順では、トランスポート方法を区別し、受け入れられたキーがすべてのプロダクトリクエストの成功を証明するものではない理由を説明しています。

「 Scrapeless Agent Browser」の場合、認証情報を含む接続URLはシークレットとして扱ってください。URLをログに記録したり診断のために共有したりする前に、機微な値をマスクしてください。すべてのAPIが同じヘッダーやトークン構文を使うと仮定するのではなく、選択したブラウザクライアントで文書化されている接続方法に従ってください。

この区別は、対象Webサイトにも適用されます。インフラストラクチャサービスを呼び出す権限は、そのサービスを通じてあらゆるリソースへアクセスする権限ではありません。収集は、意図された認可スコープ内に留めてください。 API authentication overview は追加の背景情報を提供しており、現在の Scrapeless pricing はアイデンティティ検証ではなく、機能と予算の計画に含めるべき事項です。

リソースポリシーを変更する前にアイデンティティを診断する

アクセス調査では、どのコンポーネントが判断を行い、どのアイデンティティを認識したかを明らかにする必要があります。文書化されたスキームを用いて、意図した認証情報が期待されたサービスに届いたかを確認してください。シークレットを含むヘッダーや接続URLを公開するのではなく、マスクされたレスポンスと相関識別子を確認してください。

アイデンティティが確立されたら、要求されたアクションとリソーススコープを検査します。所有者、ロール割り当て、およびコンテキストに応じた制限を確認してください。エラーを消すためだけに、広範な管理者権限を付与することは避けましょう。診断が狭ければ、変更が適切な場合にも、ポリシー変更は狭い範囲に留めるべきです。

成功したリクエストと並行して、否定的なテストも保持してください。認証情報なし、無効な認証情報、必要なアクセス権のない有効な呼び出し元、意図した権限を持つ呼び出し元をテストします。これらのケースにより、認証と認可が独立して強制されているかどうかが分かります。また、機密なポリシー詳細を開示することなく、その違いを説明するための具体的なボキャブラリをサポートチームに提供できます。

結論

認証と認可の違いは、呼び出し元を認識することと、特定のアクションを許可することの違いです。認証情報は秘密に保ち、あらゆる関連境界でスコープされた権限を強制し、成功ケースと同じくらい意図的に否可ケースもテストしてください。明確な診断は、認証に使用される情報を晒すことなく、プリンシパルとリソースに対する判断を特定します。

参考文献

• Scrapeless API キーを取得し保護する
• Scrapeless Agent Browser
• API のアイデンティティと認証情報の概念