Приложения часто используют одну долгоживущую учетную запись службы с широкими правами доступа для удобства. Однако такой подход не является безопасной моделью авторизации для каждого клиента в отношении действий, выполняемых вашим кодом. Когда запрос от одного клиента инициирует операцию, привилегированная учетная запись службы часто может получить доступ к данным, принадлежащим другим клиентам. Опора только на проверку идентификатора клиента в базе данных недостаточна, поскольку последующие дополнения, такие как кэши или поисковые индексы, могут обойти эту ограниченную проверку.Для обеспечения безопасности учетные записи служб должны определять максимальные возможности процесса, а не служить доказательством авторизации для каждого действия. Перед выполнением любого побочного эффекта должна быть обеспечена авторизация, соответствующая области действия онлайн-API, даже для фоновых задач. Предпочтительнее использовать краткосрочные токены с узкой областью действия для исходящих вызовов, а не один универсальный секрет. Точное ведение журнала идентификатора клиента, идентификатора ресурса и используемой идентификации службы имеет решающее значение для расследования инцидентов.Если один и тот же путь кода может успешно получить доступ к ресурсам другого клиента с использованием общей учетной записи службы, это указывает на отсутствие авторизации, а не на реальную безопасность. В то время как общие учетные данные управляют выполнением процесса, именно авторизация в конечном итоге определяет, к каким объектам можно получить доступ и которые можно изменять.