Достаточно ли аутентификации Api Keys для Google reCAPTCHA Enterprise?
В основном существует два способа аутентификации с использованием Google reCAPTCHA Enterprise в облачной среде, отличной от Google (мы используем AWS). Google рекомендует использовать сервисные аккаунты вместе со своим Java-клиентом. Однако этот подход кажется мне менее предпочтительным, чем второй способ аутентификации, который предлагает Google, а именно использование ключей API. Аутентификация с помощью ключа API проста, и это похоже на то, как мы обычно интегрируемся с другими сторонними службами, за исключением того, что вместо имени пользователя и пароля, которые мы должны защитить, у нас есть ключ API, который мы должны защитить. Однако для аутентификации с использованием учетных записей служб требуется, чтобы мы сохранили файл Json в каждой среде, в которой мы запускаем reCAPTCHA, создали переменную среды (GOOGLE_APPLICATION_CREDENTIALS), чтобы указать на этот файл, а затем использовали предоставленный Google Java-клиент (который использует переменную среды/ Json) для запроса ресурсов reCAPTCHA.
Если мы решим использовать аутентификацию по ключу API, мы можем использовать REST API Google вместе с нашим предпочтительным клиентом Http (Akka-Http). Мы просто включаем ключ API в заголовок, который зашифрован как часть TLS при передаче. Однако, если мы выбираем метод учетных записей служб, мы должны использовать Java-клиент Google, который не только добавляет новую зависимость к нашей службе, но также требует собственного контекста выполнения, поскольку использует блокирующий ввод-вывод.
Я считаю, что если есть что-то, что я упускаю из виду — что-то, что подход с учетными записями служб обеспечивает, чего не делает зашифрованный ключ API, — тогда мы должны просто зашифровать ключ API для каждой среды.
Наш ключ сайта заблокирован нашим доменом, и наш ключ API будет зашифрован в нашем исходном коде. Очевидно, что если кто-то получит доступ к нашему незашифрованному ключу API, он сможет выполнить оценку, используя нашу учетную запись, но злоумышленнику будет не только чрезвычайно сложно получить наш ключ API, сценарий просто не кажется мне вероятным. Выполнение бесплатных оценок reCAPTCHA не кажется мне одной из тех вещей, которые был бы склонен делать опытный злоумышленник. Я что-то пропустил? Я предполагаю, что мой вопрос заключается в том, зачем нам создавать учетную запись службы, использовать (низший) Java-клиент, хранить файл Json в каждом модуле, создавать переменную среды и т. д. Что это дает нам, что ключ API вариант нет? Открывает ли он какую-то функциональность, которую я не замечаю?
Я успешно использовал ключи API, и, похоже, он работает нормально. Я еще не пытался использовать учетные записи служб, поскольку для этого требуется ряд вещей, которые я не склонен делать. Но меня беспокоит то, что я пренебрегаю некоторыми уязвимостями безопасности ключей API.
Мои искренние извинения - позвольте мне отказаться от моих предыдущих комментариев. Я не думаю, что правильно истолковал использование слова «клиент» в своих предыдущих чтениях.
Можете ли вы добавить дополнительные сведения о модели угроз, от которых вы защищаете в этом сценарии? Вы обеспокоены тем, что инсайдеры могут получить доступ к ключу и утечь его извне или использовать его для совершения каких-либо злонамеренных действий?
Не беспокойтесь, @esqew. Спасибо за вашу помощь. Это хороший вопрос. Я думаю, что меня беспокоит то, что Google, кажется, предлагает (cloud.google.com/recaptcha-enterprise/docs/getting-started), что вы должны использовать ключи API только в том случае, если (1) ваш сервер развернут на не -Облако Google, локальная версия, поставщик CRM или SaaS, или (2) ваша среда не поддерживает внешние методы проверки подлинности, такие как OAuth и учетные записи служб. Но мне непонятно, почему ключи API не будут использоваться, даже если наша среда поддерживает OAuth и сервисные учетные записи. Например, мы могли бы использовать сервисные аккаунты.
(2 из 2) Но непонятно, зачем нам это делать, если вместо этого можно зашифровать ключ API. Итак, что заставляет меня немного задуматься, так это то, что Google, кажется, подразумевает, что использование ключей API является последним средством, но мне не кажется, что это хуже, чем использование учетных записей служб для многих распространенных сценариев, пока команда берет хороший уход за ключом.
Чтобы ответить на ваш вопрос немного более прямо. Я не слишком беспокоюсь о том, что кто-то получит доступ к ключу. Из всех вещей, которые мы защищаем, наш ключ reCAPTCHA будет наименее интересным. Кроме того, ключ будет зашифрован в состоянии покоя. Но я полагаю, меня беспокоит, что я не подумал о каком-то сценарии, который заставил бы Google рекомендовать не использовать ключи API в пользу этих альтернативных методов. кажется, что Api Keys намного проще, чем другие варианты, и при условии, что можно защитить ключ, он должен отлично сработать.
Ответы 1
После более подробного изучения документации может показаться, что есть только две причины, по которым вы хотите явно выбрать аутентификацию на основе ключа API вместо потока Oauth с выделенными учетными записями службы:
- Среда выполнения вашего сервера не поддерживает потоки Oauth
- Вы переходите с reCAPTCHA (не для предприятий) на reCAPTCHA Enterprise и хотите упростить миграцию
Помимо этого, кажется, что выбор действительно сводится к таким соображениям, как состояние безопасности вашей организации и утвержденные шаблоны аутентификации. Выбор также существенно влияет на такие вещи, как предоставление и управление учетными данными, поэтому, если в вашей организации уже есть надежный набор политик для создания и обслуживания учетных записей служб, вам, вероятно, следует пойти по этому пути. маршрут.
Google скупо упоминает в документах, что их предпочтительный метод аутентификации для reCAPTCHA Enterprise — через сервисные учетные записи, но они также не дают конкретного обоснования нигде, что я видел.
Спасибо, что нашли время изучить это и прокомментировать, @esqew. Я склонен согласиться с вами. Наша ситуация аналогична (2). Хотя мы не переходим с некорпоративного на корпоративный, мы только сейчас внедряем reCAPTCHA и не совсем уверены, в какой степени мы будем его использовать и т. д. Учитывая относительные временные обязательства между использованием ключей API и сервисных учетных записей, и т. д. (и тот факт, что мы действительно не хотим использовать Java-клиент Google), кажется, имеет смысл идти по пути наименьшего сопротивления. Но я с вами: Google явно предпочитает сервисные аккаунты, но, похоже, не объясняет почему.
Я видимо не ясно выразился. Google предоставляет клиент Java, который используется в серверной части для создания оценок и получения оценок. Таким образом, клиент, о котором я здесь говорю, — это не внешний клиент, а, скорее, Java-клиент Google, который они предоставляют для использования создания оценки reCAPTCHA. У меня может быть недопонимание (отсюда и вопрос), но я понимаю основную суть того, как выполнять оценки и ключ безопасности ключа API. Я просто не уверен, что этого достаточно. Я понимаю, что наш сервер делает запросы. Не знаю, с чего ты взял, что мы этим не занимаемся.