アプリケーションは、利便性のために、広範な権限を持つ単一の長期間有効なサービスアカウントをしばしば使用します。しかし、このアプローチは、コードが実行するアクションに対するテナントごとの認可モデルとしては安全ではありません。あるテナントからのリクエストが操作をトリガーした場合、特権を持つサービスアカウントは、他のテナントに属するデータにアクセスできることがよくあります。データベースでテナントIDをチェックすることだけに依存するのは不十分です。なぜなら、キャッシュや検索インデックスのような後続の追加機能が、この限定的なチェックを回避する可能性があるからです。セキュリティを確保するためには、サービスアカウントは最大プロセス機能を定義すべきであり、すべてのアクションの認可証明として機能すべきではありません。副作用を実行する前に、オンラインAPIのスコープに一致する認可を強制する必要があります。これは、バックグラウンドタスクに対しても同様です。単一の全能なシークレットではなく、アウトバウンドコールには短期間有効でスコープが限定されたトークンを使用することが望ましいです。テナントID、リソースID、および使用されたサービスIDの正確なログ記録は、インシデント調査のために不可欠です。共有サービスアカウントを使用して、同じコードパスが別のテナントのリソースに正常にアクセスできる場合、それは真のセキュリティではなく、認可の欠如を示しています。共有資格情報はプロセス実行を管理しますが、最終的にどのオブジェクトにアクセスでき、どのオブジェクトを変更できるかを制御するのは認可です。